ietf-smtp
[Top] [All Lists]

Re: Do the must 'bounce' rules need to be relaxed for virus infected messages?

2004-03-23 13:23:14
On Tue, 23 Mar 2004 09:43:50 PST, Dan Wing <dwing(_at_)Cisco(_dot_)COM>  said:

I think the RFCs need to 'relax' the requirement for notice of 
non delivery so as to reflect the new 'current best practices' 
for handling virus infected messages and other messages with 
forged 'return path' information. 

No, let's not.

Then we have 2 alternatives, each even more ugly:

1) Live with the current status quo, where we are deluged by double-bounces and
the like caused by viruses and spam that have bad information in the 821 MAIL
FROM: or 822 From:/Sender: headers.

2) Deploy a scheme that allows validation of the 821/822 From data before
accepting the mail. This would obviate the need to do queued processing and
allow rejections right up front, possibly before the DATA command.
Unfortunately, it would prohibit the very common 'accept, queue, and check in
background' processing style that is the primary cause of the bogus bounces.  I
can't say I'm totally overwhelmed by SPF, I'm even more underwhelmed by
Microsoft's proposal, and neither one fully addresses the problem (for
instance, SPF only deals with the right-hand part of the address, so it does
nothing for double bounces caused by a broken LHS in a MAIL FROM).

In addition, deploying the second will effectively hose MX processing for many
people, because to do it right, a secondary MX would have to be able to answer
"Will this RCPT TO accept this MAIL FROM?" rather than just queue it, so it
would require a much higher level of intelligence on the part of the secondary
MX (Hint - if the sender is talking to the secondary MX because the primary is
not available, the secondary probably can't contact the primary to ask the
question either....)

Quite frankly, when auto-generated A/V notices are running literally 20% of
your total non-spam mail volume, trying to justify standards adherence is a
really slippery slope, especially when you *know* a priori that the bounce/
notice will be going to the wrong place.  And the day we got hit by a quarter
million 'netsky', trying to sell management on the idea that we should
knowingly send a quarter million virus notifications to the wrong people in
order to be standard compliant was an *impossible* sell....

Attachment: pgpevq4C4vsoD.pgp
Description: PGP signature