Adjustments and Stuff

My conclusions on SpamBlocker3/ClamAV/SpamAssassin. Problems, adjustments, etc. This is not a Howto but rather just feedback that one can take or leave. No disclaimer is required because no advice is given. If you think something might work for you give it a shot.

There are some nice new tricks in the new exim.conf that can cut back on spam considerably. However, there are a couple of caveats to make an admin ask himself if they are really worth it. Lets start with the main problem and work are way down followed by a few of my own adjustments and additions:
------------

deny message = Forged Gmail, not sent from your account.
senders = *@gmail.com
condition = ${if match {$sender_host_name}{\N(gmail|google).com$\N}{no}{yes}}

This is a great new addition in that it will block those nasty spam messages coming off of one host and saying they are for example a gmail account. However here are the issues. As I recall Gmail lets you POP your gmail account and therefore the $sender_host_name doesn't always match the email addy domain. Calls regarding this have been minimal, solution below.

Tell them to use the SMTP server of for instance Gmail and not to use their dsl, cable, or dialin ISP's. Easy resolve.

Here is the BIG issue. Server softwares such as some e-commerce platforms allow for the configuration where when a Consumer places an order, and the Merchant gets the confirmation of the order, the confirmation comes From: the Consumer. This makes it easy for the Merchant to reply to the confirmation email in order to email the Consumer. But guess what happens when the Consumers' email address is a gmail address. The e-commerce software function dies with the error: Forged Gmail, not sent from your account.

Although it currently works badly for our purposes due to our use of two softwares that allow the above configuration, I still think it is a step in the right direction. For now here is the modification I made that allows the software to send if and only if it comes from "localhost".

Forged Gmail, not sent from your account.

deny message = Forged Gmail, not sent from your account.
senders = *@gmail.com
condition = ${if match {$sender_host_name}{\N(gmail|google).com|localhost$\N}{no}{yes}}

This seems to work. I made the changes to all of these except for paypal.com. I only use Gmail here as an example.

In a perfect world there could be added a condition that if $sender_host_name doesn't match gmail and localhost is used that some sort of wrapper is used to log the entry into a /var/log/localforgeries log file. This way Admins can keep an eye on local script that may have been exploited which used a From:*@yahoo.com email address.
------------

Next I added a few parameters to the existing and these work great. I have already seen several bonified denies from what seem like spammers trying to hit the MX of record and doing a sloppy job of it.

smtp_banner = "SMTP" #added
message_size_limit = 20M
smtp_receive_timeout = 5m
smtp_accept_max = 100
message_body_visible = 3000
print_topbitchars = true
smtp_accept_max_nonmail = 7 #added
smtp_max_unknown_commands = 1 #added
smtp_accept_max_per_host = 5 #added

Google the last 3 for more info on those. The SMTP banner should really be a default as it leaves both spammers and hackers in the dark as to what MTA is being used. Always a good option not give them a starting point for their illegal activities.
------------

SORBS.ORG is still reporting DSL and Dialup customers that aren't really spammers but rather got stuck with an IP that previously was. This is a HUGE headache and accounts for about 30% of my customer support calls in a day. So if you want to cut back about 30% comment out the entry for safe.dnsbl.sorbs.net like so.

# deny using safe.dnsbl.sorbs.net
# deny message = Email blocked by SORBS - Some message here.
# hosts = !+relay_hosts
# domains = +use_rbl_domains
# !authenticated = *
# dnslists = safe.dnsbl.sorbs.net
-------------

I believe highly in fine tuning. The more fine tuning one does the more room is left for research and development. The use of sbl.spamhaus.org and not sbl-xbl.spamhaus.org is just that kind of instance. I have changed the sbl.spamhaus.org to sbl-xbl.spamhaus.org and commented out the cbl.abuseat.org like so.

# deny using spamhaus
deny message = Email blocked by SPAMHAUS - Some message here.
# only for domains that do want to be tested against RBLs
hosts = !+relay_hosts
domains = +use_rbl_domains
!authenticated = *
dnslists = sbl-xbl.spamhaus.org

#....snip....#

# deny using cbl
# deny message = Email blocked by CBL - Some message here.
# hosts = !+relay_hosts
# domains = +use_rbl_domains
# !authenticated = *
# dnslists = cbl.abuseat.org
----------------

Another addition is that I added a couple of recommended ACL usages recommended by comrads on both the Exim and Spamassassin mailing lists.

# acl_smtp_connect = check_connect
acl_smtp_helo = check_helo #added
acl_smtp_vrfy = check_vrfy #added
acl_smtp_rcpt = check_recipient
acl_smtp_data = check_message

#....snip....#

begin acl

#Right below the future implementation of the check_connect MX record check.

check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if match {$sender_helo_name} {\.} {no}{yes}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$} {yes}{no}}
accept

check_vrfy:
deny message = VRFY not allowed - it assists spammers.
----------------

Last but not least I monitored the loads very carefully and saw great spikes due to SpamAssasin scanning friendly file attachments such as users sending others files, pictures, etc. The scores were all very low and I never did see a real piece of spam for this test. In the end I tested the theory that normally spam is always small in size (less than say 80k). So why scan the big stuff and risk the load on the server. So I decided not to scan any piece of mail greater than 80k in size.

In the Spamcheck_Director:

Below this:
{!def:h_X-Spam-Flag:} \

Added this:
{!>={$message_size}{80k}} \

#....snip....#

Below this:
deny message = This message contains an attachment of a type which we do not accept (.$found_extension)
demime = bat:comifrf:scr:vbs

Added this:
warn message = X-Spam-Flag: Skipped scanning; size greater than 80KB
condition = ${if >={$message_size}{80k} {1}{0}}


And that about does it. Everything is smoooooth as silk over here now. Spam is very low or identified properly so that the customer can choose their desired options. Customers aren't calling anymore. Softwares on the servers are running accordingly and so far no vulnerability problems. Now I need a vacation but then again I needed one before I even started.

Big Wil

deliver_queue_load_max should be also included into SpamBlocker v3

Why? What's your rationale?

Jeff

Because now exim also delivers mails when server load is 20+ etc.

one of the most interesting settings is the banner perhaps

Jeff, what are your words on this.. since your the maintainer/creater of spamblocker..
If you agree with the above suggestions then perhaps they can be implemented in a next version ? (perhaps the current beta3 brach?)

Smtalk has a good one. I did a little research and it looks like it is best used in combination with a couple others. I was just having a pretty heavy "exim moment" due to httpd being hit hard and webalizer doing its own thing at primetime hours (don't know what is up with that) and I tried these entries. It quieted exim down while httpd finished doing its thing. Nice.

deliver_queue_load_max = 3.0
queue_only_load = 3.0
queue_run_max = 1

Big Wil

smtalk said:

Because now exim also delivers mails when server load is 20+ etc.

Click to expand...

Good point. The old Sun Cobalt RaQs have this enabled in their sendmail.cf. I still have a few clients running RaQs. They call me several times a week to tell me to restart their email server (they get an email when it goes down), and by the time I log in the serverload has dropped and the MTA is already running again.

Often, though not always, the MTA is the cause of the load going so high. So it just bounces around all day.

Still, possibly worth adding.

Jeff

BigWil said:

queue_run_max = 1

Click to expand...

What's your rationale for only one queue run?

Hooray! I'm finally getting some ideas. Which is exactly what I was hoping for when I took the time to set up these new subforums .

Jeff

There should be also something like this in configuration:

auto_thaw = 3d

And you should take a look at http://exim.org/exim-html-4.66/doc/html/spec_html/ch14.html to add more great features to SpamBlocker.

Why 3 days instead of the default?

Thanks.

Jeff

So... will these be added/modified to SpamBlocker3?

Seems worth.

jlasman, take a look at http://www.tldp.org/HOWTO/Spam-Filtering-for-MX/exim.html and write a "future releases" plan, in this way it will be easier to release a final and bug-free version
e.g.

• 2007-04-21 SpamBlocker v3 beta2 release. New features added.
• 2007-05-29 SpamBlocker v3 beta3 release. New features added.
• 2007-06-18 SpamBlocker v3 RC1 (Release Candidate 1) release. Feature frozen.
• 2007-08-01 SpamBlocker v3 final release.

Just a question.

BigWil said:

Next I added a few parameters to the existing and these work great. I have already seen several bonified denies from what seem like spammers trying to hit the MX of record and doing a sloppy job of it.

smtp_banner = "SMTP" #added
message_size_limit = 20M
smtp_receive_timeout = 5m
smtp_accept_max = 100
message_body_visible = 3000
print_topbitchars = true
smtp_accept_max_nonmail = 7 #added
smtp_max_unknown_commands = 1 #added
smtp_accept_max_per_host = 5 #added

Google the last 3 for more info on those. The SMTP banner should really be a default as it leaves both spammers and hackers in the dark as to what MTA is being used. Always a good option not give them a starting point for their illegal activities.
------------

Click to expand...

BigWil said:

#Right below the future implementation of the check_connect MX record check.

check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if match {$sender_helo_name} {\.} {no}{yes}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$} {yes}{no}}
accept

Click to expand...

I basically use all of the tricks on this thread, but, after minor testing, will have to pass on the smtp banner advice for now, though I like it.

I wonder if in fact, if somebody implemented both, on the one hand you won't advertise your smtp correctly, but might not allow mail from anybody who behaves just like you.

This is the warning on dnsstuff.com for using smtp_banner ="SMTP" on exim.conf

WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.

Click to expand...

the greeting should look really like this:

220 cp.example.com ESMTP Exim 4.63 Tue, 03 Jul 2007 00:58:49 -0400

Could this actually affect mail delivery to other servers? or does this work ONLY when receiving emails, and doesn't affect your outgoing mail?


Thanks.

I suppose what you could do is to use "cp.example.com SMTP' as the banner. Myself I don't much care for half of the tests used at DNSStuff including this one. But if you would prefer the above should suppress that error.

Again, the purpose of using 'SMTP' is to not give away what the mail server software and version are. If you give hackers a place to start they are more prone to attack you. If you give them a generic answer such as 'SMTP' then they have to spend a large amount of time trying to figure out which server the machine is running and in doing so they will probably make enough mistakes that detection will be much easier.

And no it wouldn't effect outgoing just connections inbound.

BigWil

Good enough! Thanks!

BigWil said:

My conclusions on SpamBlocker3/ClamAV/SpamAssassin. Problems, adjustments, etc. This is not a Howto but rather just feedback that one can take or leave. No disclaimer is required because no advice is given. If you think something might work for you give it a shot.

Click to expand...

I've been attempting to add some of your ideas to SpamBlocker3, but ...
This doesn't appear to work:
My tests show that single word helo's are being accepted (first condition), and that IP#s alone are being blocked by your second condition, but IP#s in brackets (which many spammers use) are accepted.

Have you tried this using this command:
followed immediately by this comand:
For me, it gets accepted.

I'd really like to include these; they'll block lots of spam, but currently they don't seem to work .

Any ideas?

Jeff

Jeff,

Good catches and thanks for giving me an easy way of testing. I feel like an idiot doing the trial and error I was previously. :-(

Here ya go:


Seems to catch the single words and the IPs inside of brackets.

Big Wil

BigWil said:

good catches and thanks for giving me an easy way of testing. I feel like an idiot doing the trial and error I was previously. :-(

Click to expand...

Don't feel like an idiot... if you do, then I have to, for accepting your code into my new alpha (the new beta running only on my system) without testing it.

We all live and learn.

Thanks for the quick fix.

I'll test it and hopefully be able to include it.

Jeff

I have gotten feedback from valid customers today that are using a Mac with Entourage.

2007-09-17 10:13:09 H=static-69-95-157-215.man.choiceone.net ([192.168.1.100]) [69.95.157.215] rejected EHLO or HELO [192.168.1.100]: Your server announces itself ([192.168.1.100]) with a plain IP address which is in breach of RFC2821.

I am going to add their static IP to the allowed hosts but I sure hope this doesn't become a habbit. If only every IT guy knew how to setup a network properly so the workstations actually have a name on the network, the world would be a brighter place.

Well adding them to the allowed hosts didn't work of course because the check_helo runs first. Any ideas?

Big Wil

Editing what was here completely.

I am going to test some new ones and will post the ones that work well here. The (Singleword) isn't exactly a good idea as there is hardly ever a . in it unless it is a mailserver connecting. Whenever a remote user is sending mail direct from their workstation it almost always uses something like (Singleword) which equates to the workstation name. So unless we could check to see if they are authenticating first then this is pretty much useless.

The [nnn.nnn.nnn.nnn] is in fact RFC2821 compliant and we can't block those.

However there are other ways to fill the holes and I just found a goldmine. I will convert them to the typical Spamblocker syntax and give them a shot. Will post results shortly.

Big Wil