Botnet 0.4 Spam Assassin plugin
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
>>> 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
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
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
>> 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:
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
More information about the MailScanner