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?
john
--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
message'.
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.