[ On Tuesday, February 18, 2003 at 12:14:05 (+0300), Alexander Sabourenkov wrote: ]
> Subject: Re: [Exim] bouncing viruses
>
> > 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.
Yeah, well, we all know how well many existing virus scanners comply to
this rule, not to mention lots of other mail handling software. Don't
try to read too much into irrelevant rules taken out of context like
you're doing here.
> > 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.
"common option" What the heck are you talking about?
Dropping a message in the bit bucket is extremely trival for a anything
in the path to do!
> You must either bounce or deliver.
No. You _MUST_NOT_ bounce it. There is no possible way to securely
verify that the sender address is valid!!! NEVER EVER trust any data
sent by some third party across the network until, and unless, that data
can be very securely verified it in some way. Even more importantly if
you've identified some problem with the content of the message then it
becomes parmount that you drop all trust in the envelope too, even if
you think you've already verified it in some way.
You _can_ throw junk like that right in the trash where it belongs
(though more about this below)
Alternatively you _CAN_ just deliver it as any other normal message
would be delivered.
> > 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.
You're lucky. Your experience is not universal by any stretch.
> Virus scanners are not error-proof. False positives do happen.
Exactly, that's why the really best option is to simply not run virus
scanners at the MTA level and to simply deliver the message to its
intended destination. If you want to protect the destination MUAs then
either "fix" them, or install scanners directly in front of them where
the human user can participate in the decision of how to dispose of the
junk.
> Besides,
> sender_verify on an MX without virus scaner will happily reject most of
> the forged senders.
That's irrelevant here. The problem is with the messages that get past
any verification of the envelope sender address. Those are the ones you
have to really be careful of because if they're actually forged then you
really don't want to annoy the person that address belongs to. I've had
stupid virus scanners cause effective denial of service attacks against
my personal mailbox because they blindly bounce back their stupid
notices to the supposed sender. Software authors MUST learn to always
follow this rule: NEVER EVER trust any data sent by some third party
across the network until, and unless, that data can be very securely
verified it in some way.
> > PLEASE, pester away at them!!! :-) Education is the only way out of
> > this pit.
>
> Yes. And dropping messages in no way helps educate users.
Yes, in truth only the intended recipient can determine for certain
whether the content of a message is valid or not.
The whole concept of attempting to run virus scanners at gateways is
broken by design. It solves _NOTHING_ except the irrelevant headaches
of people who've bought into the use of software that's vulnerable by
design.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
