We changed from SpamBlocker 2.1.1 to 4 and it works great!
Thanks! I almost decided to respond with a rather curt
You can always make any changes yourself but then i decided that your post is well thought out and deserves a better reply.
So here goes:
1. Some time ago we had a problem (2 times, different servers) that ClamAV stopped working. It wasn't running anymore and therefore every incoming mail was denied! This happened with 2.1.1 but I expect the same effect with the newest SpamBlocker. I searched for a solution and came across the parameter /defer_ok. This means (as far as I understood) that mail go through clamav, but if it can't handover the e-mail to clamav it will be skipped. This is from the Exim manual:
- You can append /defer_ok to the malware condition to accept messages even if there is a problem with the virus scanner. Otherwise, such a problem causes the ACL to defer.
Source:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch41.html
Do you really want malware to be accepted if ClamAV has stopped? I don't. Post this in a separate thread in this subforum if you'd like to see a discussion on it. Frankly, I'd rather see a system for monitoring ClamAV and restarting it if necessary. DirectAdmin has such a system but it requires that ClamAV have it's own start/stop script.
The /defer_ok can be used for spamassassin either. Possibly it needs another approach, but I'm not very familiar with that.
I don't think there's anything similar for using exim with SpamAssassin; perhaps something can be programmed, but I'm not going to take the time to look into that; feel free to do the homework and suggest a definitive solution.
2. You're using the demime directive. I don't know about a different way, but I read: "There is another content-scanning configuration option for Local/Makefile, called WITH_OLD_DEMIME. If this is set, the old, deprecated demime ACL condition is compiled, in addition to all the other content-scanning features."
Probably I misunderstood, but it looked to me that demime is deprecated.
Source:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch41.html
This is confusing to me as well, since
demime is used further down in many examples on the page to which you've linked. Thankfully I don't need to worry about compile time options; I don't compile exim. I use the default exim installation provided by DirectAdmin. Feel free to contact DirectAdmin
support for more information on how they use compile-time options.
3. There are a lot of differences in approaches for rbl checking. You're checking in the recipient state (acl_check_recipient) of the SMTP transaction which happens very often, but I also read about checking this within the connect ACL (acl_connect). At the connect state there only is a connection from the sending SMTP server and it could be rejected very early in the process. Disadvantage should be alot more RBL lookups.
Increased RBL lookups are generally not a major issue because RBL results are cached in your local resolving nameserver, and are generally only one packet in each direction. But there are other disadvantages, many discussed over the years on the exim mailing list. Some conditions can't be checked until after the recipient is accepted. If you think there are good reasons why we should be checking certain options at connect time rather than at reciept time, then please do some Googling to make sure there are advantages to your approach, that there are no disadvantages to your approach, and then open up a separate thread to discuss them.
Maybe you can think of more advantages than disadvantages. See
http://slett.net/spam-filtering-for-mx/exim-final.html#acl_connect_final for more details. There're also some HELO check which maybe interesting.
How recent are these approaches? The page to which you link is NOT dated. If you feel these ACLs are better than mine, then please contact the authors to see when they were created, and if the authors still believe this is the best way to do things. Maybe I should look at some of these, but I don't have the time to do exhaustive tests just based on hunches. I need definitive reasons to look into them.
4. I don't understand why we wouldn't accept messages larger than 1000K to be scanned by clamav.
# Accept but put warning into headers if message over 1000k
warn message = X-Antivirus-Scanner: Skipped scanning; size over 1000K. You should use an Antivirus Scanner
condition = ${if >={$message_size}{1000k} {1}{0}}
In SpamBlocker 2.1.1 this limitation wasn't there and I never came across problems or had performance issues with it. The exim.conf accept messages of 20MB by default and we put the same into clamd.conf, so there shouldn't be a problem, right? Messages larger than 1000K have attachments that should be scanned in my opinion.
My recollection is that the official release of SpamBlocker 2.1.1 didn't have any clamav code in it at all.
Setting ClamAV is your personal decision. My default is based on my experiences. It works for us. If it's not working for others then either they have made changes themselves, or they've made posts on these forums which I haven't seen. For now I'm going to leave this setting the way it is in my distribution file. If you feel this is an important issue begin a separate thread and see if others find it as important as you do.
5. Why are you using the whitelisting approach with dnswl.org? This list is used by SpamAssassin for scoring messages:
# DNSWL
score RCVD_IN_DNSWL_LOW 0 -1 0 -1
score RCVD_IN_DNSWL_MED 0 -4 0 -4
score RCVD_IN_DNSWL_HI 0 -8 0 -8
Besides that I think that allowing all whitelisted IP's/servers will lead to much more spam. When used I think that only high, or medium and high, trust servers should be accepted. See:
The following config snippit scans an email for spam unless the sending ip is a medium or high trust level in dnswl.org:
warn
! dnslists = list.dnswl.org&0.0.0.2
spam = nobody:true
Trust Level Description
High Never sends spam.
Medium Extremely rare spam occurrences, corrected promptly.
Low Occasional spam occurrences, actively corrected but less promptly.
This is the default for most categories.
None Legitimate mail server, may also send spam.
This is the default for some categories (eg Email Marketing Provider).
I don't know how to use this exactly by now, but such approach looks better to me than also allowing Low trust servers and the None trustlevel.
Source:
http://dnswl.org/tech#exim
Bottom line is by whitelisting all we keep these from being blocked by other blocklists, and then we can let SpamAssassin handle the fine points.
You're welcome to create a more granular ACL entry if you'd like, and write later and let us know if it works better than my approach.
6. SMTP transaction delay. Connecting SMTP servers are delayed at several states within the transaction. This starts at the acl_connect:
acl_connect:
accept delay = 5s
hosts = *
With this setting it takes 5 seconds before the server is sending it's greeting.
The idea is that spam sending servers are configured for high delivery rates and slowing them down would send them away. Maybe the first 5 seconds wouldn't be enough, but the delay can be added at every deny statement for example. With every HELO check that gives a deny you could delay the session 2 more seconds or something like that.
See:
http://tldp.org/HOWTO/Spam-Filtering-for-MX/smtpdelays.html
and
http://www.deer-run.com/~hal/sysadmin/greet_pause.html
The concept is primitive but effective as far as I understand everything I've read. Don't delay to much, because that could deny legitimate e-mail.
I don't like to delay servers; I think it's unfair to the good senders out there. Instead I use
nolisting which is easy to implement, works well, and blocks those spammers that don't wait for errors, while not impacting good neighbor servers.
Anyway, those are my opinions. Responses to this thread may very well get lost by me; I highly recommend creating separate threads for each issue you'd like to continue to discuss.
Always remember that I write the SpamBlocker-powered exim.conf file as a labor of love; you're welcome to create your own, trying out your ideas. Perhaps the best ideas will come from a merger of your ideas and mine.
Jeff
