Postfix anti-antivirus (was Re: [linux-elitists] procmail recipe for mydoom?)
Sun Feb 15 17:01:57 PST 2004
On 10 Feb 2004, "Karsten M. Self" <firstname.lastname@example.org> wrote:
> - 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.
None of these have any effect in practice. It might be emotionally
satisfying to have rejected the nasty virus, but it does nothing but
cause damage to third parties. Absolutely nothing. I doubt if an
SMTP reject has ever caused even one machine to be disinfected. Do
you know of one?
> - If your reject was based on a misclassification of the content or
> condition, the person who's been unfairly stuffed by you:
Tell me, do you often accidentally reject viruses that you really
wanted to receive?
If you're really worried about misclassification, you can drop the
messages in a mailbox or defang them. This is at least as good as
rejects at making sure real mail is not lost. (For example: what if
the mail came from a robot that is not smart enough to understand the
bounce and adapt?)
The flood of false and forged bounces is making genuine bounces harder
to find and use. When a problem occurs with a genuine message it may
be lost in the noise.
> 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.
The host can be blacklisted regardless of whether you reject or absorb
> 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).
It is more a case of being liberal in what you accept, when you're
accepting data from random people on the Internet.
Who wants a browser that pops up warnings for every malformed HTML
page, even though in a sense they deserve a complaint? At most, have
an optional strict mode for use by web developers.
> 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?
Yes, you do. This is my point: if you reject, the forged sender is
likely to get a bounce; if you absorb the message, they will not. You
have the power to stop that bounce happening. It makes absolutely no
difference to you: neither one will stop virus infections or stop
people trying to send viruses to you.
I am not saying it's your fault that the bounce happened. I'm just
saying that, since it makes no difference to you, it would be polite
to prevent them.
-------------- 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/20040216/6a5c30fc/attachment.pgp
More information about the linux-elitists