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

Ben Finney ben@benfinney.id.au
Tue Feb 10 21:36:08 PST 2004


On 11-Feb-2004, Jeff Waugh wrote:
> <quote who="Jim Richardson">
> > How do you differentiate between say, Spamassassin, and the various
> > qmail- bits? are they not also "external processes" to the smtp
> > conversation? 
> 
> Because the *smtpd process (in qmail and postfix speak) pulls in the
> mail and puts it in the queue for processing. ie, it puts it *on the
> disk*. If you're analysing mail during the SMTP transaction, you
> can't. Well, you could, but no one does.

Okay.  So, since this is a differentiation that seems pertinent to the
discussion, it seems the term "external processes" is sub-optimal; many
on this list have already demonstrated confusion about it, and your
definition doesn't seem to fit very well with the existing knowledge of
the terms "external" and "process" in the context of SMTP transactions.

How about "SMTP-time decisions" and "post-SMTP-time decisions"?

I argue (frequently in this thread) that SMTP-time decisions are
appropriate for rejecting mail based on any information available at the
time of the SMTP transaction.

> If something goes wrong, the MTA has to figure it out and send a
> failure message or do something sane. That can be incredibly hard to
> do right.

Which MTA are you referring to?  From the context of the post, I'd
assume you mean "the receiving MTA, whether it's a relay or
destination".

But in that case, I don't see how rejecting at SMTP time makes it more
complicated; if I can determine I don't want the message at SMTP time,
it's best to do so rather than lose the SMTP connection, decide
post-SMTP that I don't want it, and *then* have to figure out what to
do.

It's not an exact science; there are plenty of cases where I might not
know it's unwanted until post-SMTP time, and that complicates the issue.
However, that's an argument for rejecting as much known-bad mail at SMTP
time as I can.

> If a mail gets through my harsh but simple MTA checks, I want it
> safely on the disk and ready for any stupid crack rock policy stuff I
> want to throw at it.

I agree.  How does "reject known-bad mail at SMTP time" conflict with
"queue mail that gets through the SMTP-time checks"?

The disagreement here seems to be what you consider valid for "harsh but
simple MTA checks".  I think there are plenty of content checks that are
appropriate for that set.

> *That's* where things like AV and anti-spam tools work best. If they
> fail, it's okay - I have a carrier grade queueing system backing them
> up. ;-)

Can you explain what failure model you're imagining?  Are content
checks going to be more unreliable than other MTA checks?

-- 
 \           "Oh, I love your magazine. My favorite section is 'How To |
  `\          Increase Your Word Power'. That thing is really, really, |
_o__)                       really... good."  -- Homer, _The Simpsons_ |
Ben Finney <ben@benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040211/ea214258/attachment.pgp 


More information about the linux-elitists mailing list