SLUG Mailing List Archives
[SLUG] Mid-DATA spam/AV detection considered harmful [Was: Virus scanning bounce strategy]
- To: slug@xxxxxxxxxxx
- Subject: [SLUG] Mid-DATA spam/AV detection considered harmful [Was: Virus scanning bounce strategy]
- From: Jeff Waugh <jdub@xxxxxxxxxxxxxx>
- Date: Sun, 1 Feb 2004 16:01:37 +1100
- User-agent: Mutt/22.214.171.124+cvs20040105i
<quote who="Theo Julienne">
> A much nicer way is to reject the emails at SMTP time ( at response to
> DATA ) - unfortunatly this requires patches with most MTAs, but it leaves
> the "bounce" up to the mail server/client that sent it.
It sounds good, but unless you have an *incredibly* robust protocol and
architecture for doing it, you're doomed.
Know any MTAs that write to disk during or before DATA? How are you going to
guarantee that your MTA -> AV/SPAM protocol/connection won't fail? How do
you communicate that failure to the MTA? What should the MTA do? What
happens if the failure means you can't communicate the cause or response to
the MTA? What should the MTA's default behaviour be? Can your spam/AV gear
handle streaming analysis, and provide a mechanism for immediate response?
Do you just kill the connection, or try to provide a sane response to the
SMTP client? Legitimate (albeit bad) mail should get a sane message, but the
crappy SMTP clients in your average worm won't handle the reponse. Are you
going to build that entire AV/SPAM infrastructure into the MTA to get around
Think about the common response case for spam and viruses: Drop the fucker
and get on with life. Despite the prevalence of dumb SMTP clients in modern
worms, most fall back to a sensible upstream MTA, so if you reject a mail
(causing a bounce if the client is sane), you're most likely adding to the
network noise, which no one appreciates. So we're still stuck discarding
Is there a huge benefit to dynamic, mid-DATA detection? Perhaps the only
worthy remaining argument is bandwidth, but is it worth the cost? How much
do you think you can realistically save? Safely?
With postfix, I can safely cut most worms off at the pass by using body and
header checks (which are part of the MTA's standard operation, and do not
rely on any external protocols or daemons). Everything else that gets past
my in-MTA policy checks (standard postfix stuff, cutting off around 50% of
spam/worms with minimal CPU/RAM requirements) is safely written to disk and
queued for Amavis SPAM/AV detection, after which good mail is punted back
through the system while bad mail is discarded or quarantined.
Reliable, understandable, cautious. :-)
GVADEC 2004: Kristiansand, Norway http://2004.guadec.org/
"I believe in true love. But I am easily satisfied." - Miguel de Icaza