SpamBlocker 4.3.0, BlockCracking, Easy Spam Figther, and new exim.pl

Ah, ESF does run it's own version of SA. A size check is done, but only on one of the 3 calls (repeated calls used the previous SA run).. so the last 2 run SA when they should have been skipped.
I've released Easy Spam Figher 1.7... but it's not yet in the versions.txt.

The only changed file is check_message.conf, so if you'd like to try it out, type:
Code: 
cd /etc/exim.easy_spam_fighter
wget -O check_message.conf http://files1.directadmin.com/services/easy_spam_fighter/1.7/check_message.conf
/etc/init.d/exim restart
and let me know either way how it goes.

This is the diff where I added the extra conditions.
I also added a header for when the message is too large, and not scanned.
http://files1.directadmin.com/services/easy_spam_fighter/1.7/diff/check_message.conf-1.6-to-1.7.diff

John
 
http://forum.directadmin.com/showthread.php?t=37821&p=253446#post253446 and further replies.

This issue isn't fixed in the latest DirectAdmin exim.conf release (4.2.3). After updating we had the same issue again.

Previous argument about case insensitivity can be solved by using EQI instead of EQ.
eq {<string1>}{<string2>}
eqi {<string1>}{<string2>}

The two substrings are first expanded. The condition is true if the two resulting strings are identical. For eq the comparison includes the case of letters, whereas for eqi the comparison is case-independent.

http://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
 
Last edited:
unihostbrasil said:
Check if your "spamcheck_director" at exim.conf or exim.spamassassin.conf have this rule, and try lowering i

Also make sure that the high CPU consumption is not a I/O or memory bottleneck on your server.

Be sure that you are using the updated rules of Spamassassin:
Click to expand...

I had already changed this value to 200. Memory was not a bottleneck because it started a few weeks after i made a change on the server.

I've updated the Spamassassin rules and there was alot of updating!

DirectAdmin Support said:
Ah, ESF does run it's own version of SA. A size check is done, but only on one of the 3 calls (repeated calls used the previous SA run).. so the last 2 run SA when they should have been skipped.
I've released Easy Spam Figher 1.7... but it's not yet in the versions.txt.

The only changed file is check_message.conf, so if you'd like to try it out, type:
Code: 
cd exim.easy_spam_fighter
wget -O check_message.conf http://files1.directadmin.com/services/easy_spam_fighter/1.7/check_message.conf
/etc/init.d/exim restart
and let me know either way how it goes.

This is the diff where I added the extra conditions.
I also added a header for when the message is too large, and not scanned.
http://files1.directadmin.com/services/easy_spam_fighter/1.7/diff/check_message.conf-1.6-to-1.7.diff

John
Click to expand...

I've updated the files! And after updating (Spamassassin & ESF) the issue haven't come back!
So i don't know which of the two fixed the issue but it's gone now!

Thanks!
 
It's most likely the check_message.conf fix. Old SA rules shouldn't cause load, and worst case they'd just not catch spam.. or possibly flag when they shouldn't.
Load would be SA crunching on over-sized messages/attachments, which is what the check_message.conf fix is for.
Either way, glad to hear it's fixed :)
I'll throw 1.7 into the versions.txt shortly.

John
 
So this morning i woke up to see this message.

rejected after DATA: failed to expand ACL string "${if => {$message_size}{200K}}": missing { after "="
in my exim log

Does anyone has a solution? It stopped working around 5 hours ago.

Edit:!

In the changed file

/etc/exim.easy_spam_fighter/check_message.conf

i removed the = from the newly added rule and now it's working again.

Only problem is now... Files with a bigger size (or lower) than 200 are not getting scanned
 
Last edited:
Thanks for the report, sorry about that.
It should be >= instead of =>. I've updated 1.7.

As for the scanning of files larger than 200K, that's a ESF variable.
Create the file
Code: 
/etc/exim.easy_spam_fighter/variables.conf.custom
and in it, place:
Code: 
EASY_SPAMASSASSIN_MAX_SIZE == 600K
using the double == so that exim accept the variable override.

John
 
DutchTSE said:
http://forum.directadmin.com/showthread.php?t=37821&p=253446#post253446 and further replies.

This issue isn't fixed in the latest DirectAdmin exim.conf release (4.2.3). After updating we had the same issue again.

Previous argument about case insensitivity can be solved by using EQI instead of EQ.
eq {<string1>}{<string2>}
eqi {<string1>}{<string2>}

The two substrings are first expanded. The condition is true if the two resulting strings are identical. For eq the comparison includes the case of letters, whereas for eqi the comparison is case-independent.

http://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
Click to expand...
John, did you miss this post? :)
 
How can I use remote spamd with Easy Spam Fighter?

Before it was enought to add extra parameters to spamc in exim.conf:
Code: 
spamcheck:
 ...
  transport_filter = /usr/bin/spamc -d ip.add.re.ss -u ${lookup{$domain}lsearch*{/etc/virtual/domainowners}{$value}}

But this setting doesn't work for ESF and it connects to local spamd.
 
I believe you'd add:
Code: 
[COLOR=#000000]spamd_address = 192.168.99.45 387[/COLOR]
to the file:
Code: 
/etc/exim.easy_spam_fighter/variables.conf.custom
Adjust IP and port as needed. I've not yet tested it, but that should be on the right track.

John
 
I installed SB 4.3 yesterday with ESF rebuilt into Exim, but I couldn't receive any mail after the initial changes (I could send fine). The Exim mainlog contained the error message "Failed to connect to socket /var/run/dovecot/lmtp for dovecot_lmtp_udp." I rebuilt Exim and Dovecot and updated them to the latest versions, but the error still was present. I found this thread reporting the same issue http://forum.directadmin.com/showthread.php?t=50489, so I went into the exim.conf file and changed the line
Code: 
transport = dovecot_lmtp_udp
to
Code: 
transport = virtual_localdelivery
That fixed the issue, mail is going both ways now, and so far it seems the spam flow has decreased. My question is, does this affect any of the new SB functionality? Do I need LMTP built into Dovecot??
 
Instead of changing the transport, have you tryed to rebuild dovecot conf to match SB 4.3?

Code: 
cd /usr/local/directadmin/custombuild
./build dovecot_conf

Regards
 
I did rebuild dovecot, but I'm still on CB1 (I know I should have migrated to CB2 long ago). I did a ./build update and then built Exim to 4.85 and Dovecot is now at 2.2.16. I believe those are the latest versions, so maybe I didn't build something into them that I should have.
 
In fact, i'd sayd rebuild dovecot_conf not dovecot...

Rebuild exim and dovecot doesnt force CB to rebuild their configuration at all, use the specific command i gave u ;)

NOTE: I didnt thot SB 4.3 was released to CB 1, if is that the case, it should be able to update dovecot configuration, if not, maybe smtalk need ot fix it :)

Regards
 
Thanks for the replies Andrea. I did initially try the command you suggested yesterday from within the custombuild directory, but CB1 doesn't have that option (running the command resulted in the list of available ./build commands). There is ./build exim_conf, but no ./build dovecot_conf. I installed SB 4.3 using the commands DirectAmin Support lists in the initial post, I only used CB to rebuild Exim & Dovecot. Obviously my dovecot build needs to be modified if I want to use that transport. The question is, does it really matter what transport I am using? Am I missing some of the benefits of SB 4 by using the old transport method?
 
Well personally i do use in production since quite a long time now, and it is stable and working pretty fine i must say :)

Regards
 
TomJones said:
Thanks for the replies Andrea. I did initially try the command you suggested yesterday from within the custombuild directory, but CB1 doesn't have that option (running the command resulted in the list of available ./build commands). There is ./build exim_conf, but no ./build dovecot_conf. I installed SB 4.3 using the commands DirectAmin Support lists in the initial post, I only used CB to rebuild Exim & Dovecot. Obviously my dovecot build needs to be modified if I want to use that transport. The question is, does it really matter what transport I am using? Am I missing some of the benefits of SB 4 by using the old transport method?
Click to expand...
Hi Tom,

Thanks for the report.
I've changed the first post to reflect the new CB2.0 install methods, as CB2.0 is now needed to setup a lot of the variables/config files... not to mention it's much easier :)

I'm also going to change everything to BETA.

John
 
You must log in or register to reply here.
Back
Top