Botnet 0.4 Spam Assassin plugin

[René Berber]

John Rudd wrote:
> René Berber wrote:
[snip]
>> 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.

I haven't seen where SA can be configured to add the information that the user
used smtp_auth.

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

But if you use your ISP and it doesn't require authentication then the first
line is going to produce a score always...

> 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)

Thanks for your reply, I'm already using most of your recommendations
(smtp_auth, greet pause, gray-list) I'll just have to put together the pieces to
reach full benefit.
-- 
René Berber