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 (email@example.com) wrote:
> On 11 Feb 2004, Ben Finney <firstname.lastname@example.org> 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 <email@example.com> http://kmself.home.netcom.com/
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
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040210/3ba37955/attachment.pgp
More information about the linux-elitists