Postfix anti-antivirus (was Re: [linux-elitists] procmail recipe for mydoom?)

Karsten M. Self
Wed Feb 4 09:23:27 PST 2004

on Wed, Feb 04, 2004 at 09:44:55AM +1100, Jeff Waugh ( wrote:
> <quote who="Derek Vadala">
> > > No, I'm arguing that doing this kind of stuff (talking to
> > > MTA-independent anti-virus or anti-spam software) at SMTP time is
> > > boofheaded. So the rest of your points are mostly irrelevant, or perhaps
> > 
> > Have you gone mad? Dealing with this stuff at SMTP time is precisely how
> > you keep your shit working during an major outbreak, when you are managing
> > high-volume (more than half a million messages per day) transports with
> > AV/Spam checking and many thousand windows users on the inside.
> Yes, but doing it at SMTP time using MTA-only tools means avoiding massive
> failure as well as reduced CPU/RAM/disk overhead from using the heavier AV
> and SPAM tools.
> Right now, one of the mail systems I administer is either rejecting or
> discarding over 85% of mail going through it, which ends up being about 200
> mails per minute. All via in-MTA tests during the SMTP conversation. Then
> what's left is handed off to content filtering (spamassassin and clamav) for
> policy-driven and more thorough (read: cpu, ram and disk-intensive) spam/AV
> detection.
> The important bit is that the safe checks are done and the mail is on disk
> before we start talking to ("dangerous") third parties

Forgive me for failure to comprehend, but, assuming some part does

   - Preliminary tests (known spam IPs, etc.) pass.
   - You've opened the DATA connection.
   - You've received, but not accepted the data.
   - You shell out for AV / spam filter tests, while holding open DATA
   - Your wobble wibbles.

You never accepted the data.  The remote side eventually times out.  You
re-wobble your wibble, come back online, and accept the message on

What exactly is your risk / threat model, and what have you lost?

> and the lack of this information at SMTP time doesn't really affect
> what we're going to do with the mail anyway -> if it's spam, we're
> going to discard it. If it's a virus, we're going to discard it. 

I've been going a few rounds with Brad Templeton over challenge-response
systems.  I say they're broken by design, he disagrees -- but he's added
some points to his "best practices" web page.

One of Brad's requirements for an email system is that it *not* drop
mail on the ground, and I rather much agree.  A large part of our
disagreement is that I feel the proper time for notification is SMTP
negotiation, while he feels (wrongly IMO in the face of legion forged
messages) that a notification email is both acceptable and desired.

In the possibly long odds that a known, legitimate user is sending
viruses or mail tagged as spam, a 55x reject with "Virus rejected see
<url>" or "Spam rejected see <url>" would be highly preferred.  There's
odds of fixing the problem on their end, your you finding out about a
misconfiguration at yours.

> So given that there's no strong benefit to doing it during the SMTP
> conversation... 

Check your diaper.  And premises.

> why bother with all of those breakage points?

What, again, exactly, are you worried about breaking?


Karsten M. Self <>
 What Part of "Gestalt" don't you understand?
   LNX-BBC:  Bootable GNU/Linux -- Don't leave /home without it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : 

More information about the linux-elitists mailing list