[Mailman-Users] Spam to list-owner

[Brad Knowles]

on 12/19/08 10:31 PM, Lindsay Haisley said:

> SpamAssassin has to do a fairly intensive examination of the mail body
> and may reject based on this examination, but because of the way SMTP
> works, it's a bad practice to wait until after the DATA section of a
> mail transaction is complete to reject an email at the front door.

The only real legitimate reason I've ever heard given for why programs 
like SpamAssassin should run after the original message has been 
received is because of the SMTP dialog timeouts listed in RFC 1123 
section 5.3.2, and the fact that certain types of processing might take 
longer than would otherwise be considered reasonable during that SMTP 
dialog process.

However, I think that has long since fallen by the wayside.  These days, 
having a few extra seconds of delay is actually likely to make spammers 
go away and try someone else, which was the entire point of Ken 
Simpson's invited talk at LISA 2007, entitled "Using Throttling and 
Traffic Shaping to Combat Botnet Spam" (see 
<http://www.usenix.org/events/lisa07/tech/tech.html#simpson>).  They 
build commercial tools to intentionally add a delay before the 
connection ever hits your MTA, and they find that a short mandatory 
delay actually results in a significant reduction in spam -- just a few 
seconds is enough.

Moreover, there are lots of things that can only be feasibly done by 
more complex processing systems like SpamAssassin, and you might as well 
hold the sender open while you do that processing.  If the message is 
rejected, then you've spent the same amount of CPU time as you would 
have anyway, you helped slow the spammers down, and you didn't accept 
the message.  If the message is accepted, then the sender probably 
wasn't held open very long.


Speaking as the former chair of the Best Current Practices subgroup of 
the IETF/IRTF Anti-Spam Research Group, I can assure you that running 
SpamAssassin (and similar tools) in this "interactive mode" really is 
Best Current Practice.

>                                                                     One
> runs into, at very least, some theoretical logical conundrums, and even
> though it might be arguably OK to reject spam for all "rcpt to"
> recipients at once, it takes the choice away from individual users re.
> how severe they want to filter for spam.  There are other
> considerations.

Tools like SpamAssassin can give you per-user controls.  If you're not 
making use of those, then you can't realistically argue the point that 
you need them and therefore the SpamAssassin processing should be done 
elsewhere.

> So if I can't refuse potential spam at the SMTP front door, what
> difference does it make whether it gets detected in Mailman or the MTA?

If it's done in the MTA, you save a lot of work with re-injecting of the 
message and all the work of starting up the Mailman modules, just to 
have the message rejected at a later stage.

You really, really want to do as much work as you possibly can as early 
as possible in the pipeline.

> Mailman already has a SpamDetect module which is reasonably useless, and
> discards (not rejects) spam internally.

Once you've accepted a message, if you decide it's spam, then you 
*CANNOT* reject the message.  Your only choices are to tag it and pass 
it on to a later stage, or to drop it.

Anything else makes you a source of "backscatter", a.k.a., "blowback", 
and you are then a tool of the spammers to join in a DDoS attack against 
some poor sucker in a distributed Joe Job attack.  And being a source of 
backscatter will get you blacklisted about as fast as if you were a 
front-line spammer yourself.

>                                          What I'd really like is a way
> to hook SpamAssassin, or a similarly effective tool, into Mailman so
> that I can get a lot more fine-grained control and set meaningful
> parameters on a per-list basis.  The further forward I shove it, the
> harder it is to exercise this kind of control.

Take a closer look at the kinds of controls that SpamAssassin gives you.

At this point, the only legitimate reason for providing any kind of 
hooks for tools like SpamAssassin or SpamBayes in the Mailman code is 
for those people who do not have this level of control over their MTA, 
so they simply have no choice -- either it's done inside of Mailman, or 
it's not done at all.

-- 
Brad Knowles
<brad at shub-internet.org>        If you like Jazz/R&B guitar, check out
LinkedIn Profile:                 my friend bigsbytracks on YouTube at
<http://tinyurl.com/y8kpxu>    http://preview.tinyurl.com/bigsbytracks