Re: [Exim] bouncing viruses

Hello.

First of all, please calm down.

Greg A. Woods wrote:
[ ... ]

> Who the heck cares? Nobody has the "right" to send e-mail to any and
> every abitrary mail server from an address that their ISP has allocated
> as a generic and probably dynamic (or at least potentially dynamic)
> workstation address.

That is not in any way determined by _you_ . To some extent it may be
detemined by ISP policy. All _you_ can do is to do not accept mail from
them _yourself_ . And that's it.

> I sure as heck am not ever going to allow anyone
> to send me e-mail from a client station which may just previously have
> been used by a spammer to send junk out if I can possibly avoid it!

:-/

> Remember, the RFC 822 headers of a message are, from the mailer's
> perspective, part of the body; and every MTA should be adding a
> "Received:" header and thus will be modifying the body of the message.
> I.e. your paranoia is bogus and silly.

Not at all. The 822 and its successor 2822 explicitly state that MTA
MUST NOT modify message in any way except by adding one Received: header.

> Well, actually there's a heck of a lot more more pragmatic reason: If
> you can't decicde whether or not you're going to accept _and_ deliver a
> message by the time the client has sent at least one approved "RCPT TO:"
> command, well then for all practical purposes you're going to have to
> accept and either deliver or bounce or bit-bucket the message. It's

Bit-bucket is not a common option. You must either bounce or deliver. Yes
there can be exceptions for some narrowly defined types of content,
but they must be few and well thought-out. Your sweeping approach
will generate only insane amounts of headaches in real world.

> almost impossible to reliably and effectively reject a message after the
> DATA command has started, and besides you still burn all the wasted

Not at all. Quite surprisingly, I have yet to see any problems with
stupid clients retrying after 550 to end of DATA. I look after around several
thousand client exims, plus MXs for our corporate domain. All viruses
are rejected by custom local scan - no problems at all.

> bandwidth anyway. Since you should not ever try bouncing messages
> containing known viruses and worms, your only remaining sane choices are
> to either deliver (perhaps with slightly modified content) or to
> bit-bucket the message.

Virus scanners are not error-proof. False positives do happen. Besides,
sender_verify on an MX without virus scaner will happily reject most of
the forged senders.

> PLEASE, pester away at them!!! :-) Education is the only way out of
> this pit.

Yes. And dropping messages in no way helps educate users.

--

./lxnt