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
<b...@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
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
