Hi.
A recent note from Frank raises the issue again about
prohibitions on non-delivery notifications ("bouncing"
messages), at least to unauthenticated sites. I thought we had
closed that issue out but, since it has come up again, I'd like
to assign an issue number and see if we can have a clear and
quick discussion.
For context, that note mentions...
Unrelated, for some extremely important text see also
http://www.spamcop.net/fom-serve/cache/329.html#bounces
Some of the key sentences in that note are:
Upgrade and/or configure your mail server software so that
this situation is never encountered. Configure your software
to either reject messages during delivery or accept them
permanently. Do not let your software make choices about
delivery after it has accepted a message.
My impression is that the general issue of prohibiting sending
out an NDN message when it cannot be definitively rejected at
SMTP envelope time has been ruled out of scope. I also think
that several examples have been given in which it is impossible
to make the decisions while the server still has the connection
open from the client, at least without significant changes to
the SMTP model, some interesting extensions, or both.
To take just one example, such a rule would require that a
"backup MX" --a server configured to pick up mail for a
destination site iff that site is temporarily broken or off-net)
to have a definitive list of deliverable addresses on the target
system and domain. Similar issues arise with gateway servers
for areas with poor online connectivity to the Internet
backbone, such as many developing countries or at least rural
areas in them. Requiring that servers of either type have
current knowledge of deliverable addresses is technically
burdensome (especially since we have no protocols for securely
exchanging such lists) and raises a number of security and
privacy issues. We have, historically, tried to encourage such
intermediate MX-associated servers as a means of making the
Internet accessible to more people and keeping the mail system
as robust as possible. And we have historically had an email
model in which senders can reasonably expect that a message will
either be delivered or an NDN will come back -- that "delivery
notification" messages --which raise their own set of privacy
concerns-- are not necessary.
Thinking about these issues have even caused some people to wish
that we had not deprecated the practice of relays constructing
reverse-paths by adding their own identifiers to them --
something that has not been a regular practice on the Internet
since the mid- 1980s. I can only suggest to them that this
would not solve the problem: return paths are as easy to spoof
as Received headers. But more on that in my next note (issue
26).
The net result is that the consequences of going to a "never
bounce" model are fairly large: it is not just a matter of
saying "don't do that any more" despite the language in the
quoted text and at the link above. Partially because of the
operational model changes needed to really get it right, I don't
think it is in scope for the 2821bis effort. But we need to
settle that one way or the other and get on with our lives.
john