[Top] [All Lists]

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

2004-03-23 13:41:25

Further discussion and text welcome. But let me suggest a different way to look at the problem...

Well down below the surface of what 821, 1123, and 2821 say explicitly, there is a tradeoff between:

        * try as much as possible to reject a bad (for any
        variation of "bad") message at SMTP time, so no "bounce
        message" is generated by the rejecting system.
        * optimize speed and throughput of the SMTP process by
        accepting dubious messages and then bouncing them as
        required, rather than taking the time to, e.g., do
        potentially-complex sender or recipient verification at
        SMTP command time.

At least as I understood it at the time, 821 more or less assumed that the first was preferable and that the second was a fallback for the cases where the first was impossible. By the time 2821 rolled around, the assumption had shifted the other way, i.e., that maybe it wasn't so smart to tie up incoming connections while the SMTP server went through a potentially-complicated and time-consuming process to figure out if it could make delivery to a mail store. Maybe it is time to shift that assumption back the other way again and to strongly encourage "figure out if you like the message before accepting it for delivery".

But note (1) that choice has always been up to the implementer and, for many implementation, the site. And (ii) there really is enough flexibility in 2821 now for a site to toss bounce messages that it has substantive reason to believe cannot be properly delivered. The text just insists, as I think it should, that the decision to discard a bounce message (or to discard an incoming message without any indication to the presumed sender) be treated as a very serious one and not taken lightly.

Finally, please think about a question: there are a number of "authenticated MTA" proposals floating around. If you assume that they will be successful and widely deployed, as their authors do, then is it desirable to weaken important integrity mechanisms within the mail environment in order to address a problem that will be solved in another way?


--On Tuesday, 23 March, 2004 11:27 -0600 bz <bz+ietf(_at_)chemserv(_dot_)chem(_dot_)lsu(_dot_)edu> wrote:

It seems to me that SMTP has a serious flaw that is being
exploited by virus  writers, spammers and 'joe jobbers', to
cause grief to innocent people. That  flaw is the 'bounce

The philosopy is simple, and dates back to earlier days of
communications by  radio and telegraph: once one accept a
message for relay or delivery, one is  responsible for making
sure it is delivered or one must notify the sender  that it
could not be delivered. I understand the theory.

The problem occurs when 'the sender' is misidentified and
notice is sent to  an innocent third party. The notice becomes
a form of abuse.

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.