Botnet 0.4 Spam Assassin plugin

John Rudd jrudd at ucsc.edu
Mon Nov 27 22:40:51 GMT 2006


René Berber wrote:
> John Rudd wrote:
> 
>> Scott Silva wrote:
>>> Wayne spake the following on 11/27/2006 12:27 PM:
>>>> At 14:17 27/11/2006, you wrote:
>>>>
>>>> Do not know if I am alone with this problem but I have had to remove
>>>> BOTNET as it was doing it's job too well - it was deleting all mail
>>>> which originated from genuine ADSL addresses I even tried adding these
>>>> addresses to white-lists and other files saying not to be read as spam -
>>>> they still were. If the problem of genuine use of adsl addresses can be
>>>> addressed I will try again.
>>>>
>>> That is a problem. There is so little "genuine" use of ADSL for mail
>>> that the
>>> author might not have took that into account. I am very resistant to
>>> accept
>>> e-mail from ADSL or cable connections because it is 99.9% spam, and the
>>> originator should be using a smarthost on their ISP.
>>>
>> I did take it into account.  I'm of the "they should be using their
>> Corporate/ISP's mail server, or get their DNS fixed" opinion.  Or use a
>> hosted email server that has better RDNS if their ISP is lame.
> 
> Question: If someone sends a message from home to their workplace, there is only
> one relay line (two if you count the local delivery line which usually does not
> have an IP address) and it contains a ADSL address, does your plugin score on
> that relay line or skips?

It will not skip that received line unless you specifically put that 
relay into your skip/pass list ... or if they're using SMTP-AUTH and SA 
correctly puts that information into the pseudo-header AND you've set 
the botnet_pass_auth option.

> The point here being that if it scores it gives a false score, just like the
> useless half point I see SA adds to that line by using RBLs that list dynamic
> addresses... the first relay line should be ignored, and that makes bot-net
> detection ineffective.

I would say that the first line should NOT be ignored.  Instead:

1) You should require that such submitters use SMTP-AUTH, and possibly 
have them connect to a back-end system (where spam scanning happens on 
your front-end systems).  To avoid having your back-end systems targeted 
by adversaries (to get around your AV/AS scanning), have them require 
SMTP-AUTH and only allow non-SMTP-AUTH transactions from trusted IP 
addresses (such as your front end systems).

2) You shouldn't spam scan messages at all if they've come from an 
SMTP-AUTH transaction OR make sure that your MTA's SMTP-AUTH 
fingerprints are properly recognized by SA and use the botnet_pass_auth 
option.


In my setups, I have the arrangements:

1) front end and back end systems:  the front ends to the spam scanning 
but don't spam scan messages relayed from the back ends; the back ends 
only accept messages from local IPs or via SMTP-AUTH.

2) 2 MTA's on one host, which act like the above front end and back end 
arrangement, except that the 'back end' MTA doesn't relay out through 
the 'front end' MTA.  For example, I have sendmail listening on port 25, 
and doing AV/AS scanning; then I have CommuniGate Pro running on another 
port and "blacklisting the world" (which can only be bypassed by 
SMTP-AUTH or being on a "client IP address).  Sendmail then relays 
messages to CGP when its done with them.  Legitimate users (local or 
not) submit messages to CommuniGate Pro with SMTP-AUTH, and thus their 
messages never get seen by SpamAssassin nor the Botnet plugin.

3) One MTA that only passes messages to SpamAssassin if they weren't 
from an SMTP-AUTH session, nor from a local IP.  (I will soon be 
retiring sendmail on the machine in example #2, and the CGP rule which 
will be invoking SpamAssassin will exempt for messages that are 
authenticated)

In any of those cases, the answer is "make the legitimate but non-local 
user use SMTP-AUTH to one of the SMTP-AUTH enabled hosts".  This doesn't 
even require the use of multiple machines (and thus a higher cost of 
operation).


>> My means of mitigating the problem are the "botnet_pass_auth",
>> "botnet_skip_ip", and "botnet_pass_ip" options, which allow you to
>> handle known good senders.
> 
> Not very usefull since dynamic IP addresses are "dynamic".

botnet_pass_auth would be useful in that case, if your MTA is able to 
properly inform SA when a message was authenticated.

>> Or you can set the score for BOTNET_CLIENT to 0.  That will, however,
>> significantly reduce the effectiveness of the plugin.

And, of course, this one is still an option.  BOTNET_NORDNS alone is 
what AOL does.  Add BOTNET_BADDNS to that, and you're slightly better 
than AOL at blocking botnets.  It's not as good as the full effect of 
BOTNET, but it's better than nothing, IMO.

Other things that will help:

zen.spamhaus.org
a Greet-Pause of 20-30 seconds (you'll need exemptions for verizon, 
livejournal, .mac, I think myspace, and facebook)
some amount of Greylisting

(in my experience, these 4 techniques have HUGE overlap in results, so 
if you do 2 or 3 of them, you get a small trickle or results on the 
other 1 or 2; my preference is: 3 second greet pause, zen.spamhaus.org, 
direct botnet blocking in the milter (ie. same code, but applied before 
spam assassin, and only applied to the direct mail relay; exempts if 
postmaster or abuse are the only recipients or for smtp-auth), no 
greylisting)





More information about the MailScanner mailing list