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

Karsten M. Self
Tue Feb 10 23:45:52 PST 2004

on Wed, Feb 11, 2004 at 02:27:05PM +1100, Martin Pool ( wrote:
> On 11 Feb 2004, Ben Finney <> wrote:
> > On 11-Feb-2004, Jeff Waugh wrote:
> > > Sure, I totally agree that if every MTA rejected malware, we would be
> > > in a wonderful, blissful state of joy. But the reality is that they
> > > don't
> > 
> > That reality can be changed.
> > 
> > > and you can guarantee that matched, modern worms forge their sender
> > > envelope and address. So rejecting them *HAS NO PURPOSE* at all.
> > 
> > Non sequitur.  The fact that worms come with forged sender addresses
> > does not render the rejection purposeless.
> Could you explain what purpose it achieves?


  - If the header data was forged, you've just shoved the problem one
    hop upstream.  Closer to the source.

  - If that hop is in fact the _origin_ (direct transmission from
    infected host), you've Done The Right Thing, and that host sucks
    back its spew.

  - If that hop is a smarthost, and it's handling delivery at receipt,
    it turns around and tells the originating SMTP server "no go".
    Which is Doing The Right Thing. 

  - If your reject was based on a misclassification of the content or
    condition, the person who's been unfairly stuffed by you:
    1. Knows their message wasn't successfully sent.

    2. Has a chance of identifying the reason why.

  - In the chance you're dealing with a not-quite-smart host that turns
    around and generates a nondelivery notice to a spoofed party:

    1. It's Not Your Fault.

    2. The not-quite-smart host is misconfigured.

    3. The host can be identified as spewware on an appropriate DNSBL
       list, allowing Right Thinking People Everywhere (RTPE) to shitcan
       all spew originating from it.  The host's admins might care to
       address that situation if it bothers them.

It's a bit like the two approaches to warning messages in programming:

  - You can get rid of them by disabling warnings.

  - You can get rid of them by _enabling_ strict error checking, and
    fixing the bugs (or avoiding the bug-inducing conditions).

I don't know about you & Mr. Waugh, but I strongly favor the second

Frequently, n00bs complain that there's too much pain involved in
rooting out the errors.  The proper response is that there's more pain
involved in not doing so.

> >   - You (the MTA trying to send it to me) shouldn't have accepted it
> >     either.
> If it's something that everyone in the world would agree ought to be
> dropped, then there is no point in saying so.  

Everyone may agree that it _should_ be dropped.  But if you don't say
that you dropped a specific item, and if you can't be absolutely sure
you're dropping the right stuff, it's better to be explicit about these

> The sending SMTP machine clearly doesn't care.  

Check your assumptions.

> The appropriate way to report that is with mail to their postmaster,
> not a rejection.  

A rejection *is* a notice to the postmaster.  If he's not watching his
reject logs, he's /dev/nulling postmaster@ anyway, dollars to doughnuts.

> The forged sender who will receive the bounce has little control over
> it; at most they can complain to the relay but so can you.

What do I have to complain about?  I got mail I didn't want.  I rejected
it.  That's my complaint.

If the originating MTA can't deal with that properly and generates a
spoofed nondelivery mail, then yes, that recipient should bitch.  But I
have no basis for determining that's going to happen, now do I?


Karsten M. Self <>
 What Part of "Gestalt" don't you understand?
    Bye bye boys!  Have fun storming the castle!
    - Princess Bride
-------------- 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