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 (firstname.lastname@example.org) 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
> 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
Check your diaper. And premises.
> why bother with all of those breakage points?
What, again, exactly, are you worried about breaking?
Karsten M. Self <email@example.com> http://kmself.home.netcom.com/
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
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040204/055f8e4c/attachment.pgp
More information about the linux-elitists