SpamBlocker-Powered exim.conf, Version 4

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
 
After installing SpamBlocker 4.0 my spam dropped dramatically so I just wanted to say thank you for the great work on this, I do have one question however. I am getting the "R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)" from connections made by a machine that is on my network, it can not be configured to connect using anything but port 25 because the software is quote old.

I know I can comment out that section of the exim.conf file so that those connections are allowed but I am quite sure this will likely cause an increase in spam. I tried adding the ip address of that one server to the "whitelist_hosts_ip" file but am still getting that error message. Is there any way to whitelist a single address that is causing this problem other than commenting that entire section out of the exim.conf file?
 
I was able to come up with a solution to my problem without the need to whitelist the server that was causing the error. The software I was having problems with runs on a machine running IIS Server and after some research I found that I could configure the local IIS Virtual SMTP Service on that machine to accept unauthenticated email on port 25 and then relay it through my server with authentication on port 587 by entering our mail server as a "Smarthost". Then I simply had to tell the software to use "localhost" as the smtp server instead of our mail server and all is good.

After installing SpamBlocker 4.0 my spam dropped dramatically so I just wanted to say thank you for the great work on this, I do have one question however. I am getting the "R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)" from connections made by a machine that is on my network, it can not be configured to connect using anything but port 25 because the software is quote old.

I know I can comment out that section of the exim.conf file so that those connections are allowed but I am quite sure this will likely cause an increase in spam. I tried adding the ip address of that one server to the "whitelist_hosts_ip" file but am still getting that error message. Is there any way to whitelist a single address that is causing this problem other than commenting that entire section out of the exim.conf file?
 
Last edited:
I'm glad you got it working. It's possible that the whitelist isn't checked until after the block caused by the incorrect helo reported by that system. I don't remember and I don't have time to look at it right now.

Check it for me and let me know; I can change the order if it will help.

Jeff
 
Jeff,

I think that must be the case because whitelisting either the sender email address or ip address of the problem mail server still resulted in the error ("R1: HELO should be a FQDN or address literal"). However, my solution is better anyway as it eliminates the need for the whitelisting completely so I am not in need of this change now. It may be useful for others however.

Thanks again.

I'm glad you got it working. It's possible that the whitelist isn't checked until after the block caused by the incorrect helo reported by that system. I don't remember and I don't have time to look at it right now.

Check it for me and let me know; I can change the order if it will help.

Jeff
 
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.

....

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

Hi Jeff,
I'm aware of the fact you create(d) SpamBlocker as a labor of love. We all appreciate that very much! I didn't write my post to give you a lot of work to do for the community, I was curious about your opinion and experiences with all I found. You're working on exim.conf for a long time as far as I know and therefore your experiences are worth a lot more that everything I could find on the internet. SpamBlocker isn't created in a few hours, but evolved because of your experiences, therefore I'm glad you took the time to respond to my post. I will work on the rules to try to get them better, but I share a lot of your opinions.

One note. I'm not sharing your thought's fully on nolisting and delaying servers. It's unfair to let a good server wait, I share that opinion, but with nolisting you let good servers connect to a non-existing server, isn't that unfair either? It takes possibly less time, but you're faking good servers, I don't think either of these solutions is a problem for good senders. Delaying too long isn't fair and maybe we can build a delay structure for deny acl's, than the good servers aren't affected but others are delayed and maybe won't come back again because of the delay in breaking the SMTP transaction. I'll do some homework and testing with this later. If I have anything to share, I'll do it on these forums, off course.
 
One note. I'm not sharing your thought's fully on nolisting and delaying servers. It's unfair to let a good server wait, I share that opinion, but with nolisting you let good servers connect to a non-existing server, isn't that unfair either? It takes possibly less time, but you're faking good servers,
If you send users to a server which doesn't answer you let the sending server decide how long to wait; I think that the best approach.
Delaying too long isn't fair and maybe we can build a delay structure for deny acl's, than the good servers aren't affected but others are delayed and maybe won't come back again because of the delay in breaking the SMTP transaction. I'll do some homework and testing with this later. If I have anything to share, I'll do it on these forums, off course.
How do you decide who are the bad servers?

Jeff
 
If you send users to a server which doesn't answer you let the sending server decide how long to wait; I think that the best approach.
Delaying too long isn't fair and maybe we can build a delay structure for deny acl's, than the good servers aren't affected but others are delayed and maybe won't come back again because of the delay in breaking the SMTP transaction. I'll do some homework and testing with this later. If I have anything to share, I'll do it on these forums, off course.[/QUOTE]
How do you decide who are the bad servers?

Jeff[/QUOTE]
Well, after a failing HELO (deny acl) Exim will stop processing the request, or am I missing the point? At the failing of the deny ACL we can send a delay before aborting the transaction. That's what I meant.
 
Now I'm confused. After the deny ACL denies, why would you then send a delay?

Jeff
 
Now I'm confused. After the deny ACL denies, why would you then send a delay?

Jeff
Well, I'm not sure at the moment if it will work. The idea is to delay the connecting mailserver within a deny ACL.
So, when a server fails in the HELO check we delay them 5 or 10 seconds before aborting the connection. The idea is to let those (possible) bad senders wait longer and hopefully they decide that our servers let them wait too long and won't come back again. They can't afford to let all connections stall for 5-10 seconds. They want to send as much crap as possible in a short period of time, delays will extend this time and they don't want that and hopefully decide to ignore those servers.

Like I said, I'm not sure if this will work the way I think but I've seen solutions in mailservers where deny ACL's won't fail the connection directly but set a value for the delay period. In every deny ACL there are +5 seconds for the delay, at the end of the SMTP transaction this delay will follow before failing. The principle I wrote about looks like this, but without adding seconds in every ACL. failing the connection as soon as possible sounds like the best option to me.
 
If you're using the word deny as as the first word, then the deny is going to happen. If you want to write a delay rather than a deny, you need to study how ACLs work so you can use a different format.

Jeff
 
I am getting these errors on two mail servers after upgrading to version 4:


2010-11-08 10:17:03 H=(snt0-omc4-s8.snt0.hotmail.com) [65.55.90.211] temporarily rejected EHLO or HELO snt0-omc4-s8.snt0.hotmail.com
2010-11-08 10:17:04 H=(smtp.conn) [178.215.233.95] temporarily rejected EHLO or HELO smtp.conn
2010-11-08 10:17:05 H=(microsof-e9f21c) [92.113.71.178] temporarily rejected EHLO or HELO microsof-e9f21c
2010-11-08 10:17:09 H=(smtp.conn) [178.215.233.85] temporarily rejected EHLO or HELO smtp.conn
 
Are these occuring when those servers are trying to to send to you? Or when you're trying to send to them?

We don't use that error message at all. So I don't know where it's coming from if you're using a standard Spamblocker-Powered exim.conf file, Version 4, for DirectAdmin.

If these occur when sending email, then you'd have to find out why those senders don't like you; are you sending spam, for exzmple.

If these occur when receiving email and you're sure you've made no major modifications to my exim.conf file, then I'd like to log into your server and look... please contact me by email to see if we can arange this.

Jeff
 
Hi jal,

ive instaled version 4 of your spamblocker and seems ive not any email problem, but, seems that i still receive spam email daily as usual, are the rbl and antispam rules enabled by default?

Ive alraedy enabled spamassassiin and clamav lines

Thanks

Have a nice day
 
Is about one month that use spamblocker 4... but sometimes my customers call me at telephone to say me that some legitimate mail were rejected. When i went to verified in rejectelog "Email blocked by hostkarma.junkemailfilter.com" is the frequently reason of the reject.

So i would ask if a comment out in exim.conf at EDIT41 is a possible solution:

Code:
# hostkarma.junkemailfilter.com=127.0.0.2

But if so, however, all domains exclude this check right? there is no way to customize these controls for each domain?

Thanks in advance
 
ive instaled version 4 of your spamblocker and seems ive not any email problem, but, seems that i still receive spam email daily as usual, are the rbl and antispam rules enabled by default?

Ive alraedy enabled spamassassiin and clamav lines
Verify to make sure that there's nothing in your /etc/virtual/skip_rbl_domains file and that either all domains are listed in your /etc/virtual/use_rbl_domains file or that it's a symbolic link to your /etc/virtual/domains file.

Jeff
 
Is about one month that use spamblocker 4... but sometimes my customers call me at telephone to say me that some legitimate mail were rejected. When i went to verified in rejectelog "Email blocked by hostkarma.junkemailfilter.com" is the frequently reason of the reject.

So i would ask if a comment out in exim.conf at EDIT41 is a possible solution:

Code:
# hostkarma.junkemailfilter.com=127.0.0.2

But if so, however, all domains exclude this check right? there is no way to customize these controls for each domain?
That's correct. Note that hostkarma.junkemailfilter.com is an optional list (see the readme file).

Jeff
 
thanks jeff, that files didnt exist so ive created the first one and made the simbolic link for the second one.

thanks a lot, as always
 
You're very welcome. Be sure to verify the ReadMe file and make sure all the required files exist.

Jeff
 
Back
Top