John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
--On Monday, 30 April, 2007 13:46 -0400 "David F. Skoll"
<dfs(_at_)roaringpenguin(_dot_)com> wrote:
John C Klensin wrote:
[David Skoll proposed:]
A proper failure report SHOULD consist of a notification
sent to the Return-Path of the original message. Where
this is not possible (because of a blank Return-Path) or
not desirable (because the Return-Path is untrusted for
local policy reasons), the server MUST record enough
information for a human operator to reconstruct the nature
of the delivery failure, the original Return-Path and the
addresses of the original recipients.
... one could probably replace the strong clause starting with
", the server MUST..." with some words that non-normatively
advised that behavior...
OK; fair enough. I think, though, that if we're going to make
it permissible to silently drop undeliverable messages (which
is what people want to avoid backscatter but is IMO totally
against the spirit of the original RFC), then we must put
something in writing that says what a well-behaved server is
expected to do. I could live with a SHOULD.
Speaking personally, I believe that we cannot "make it
permissible" to silently drop messages, absent policy
considerations about the individual message, without requiring
support for delivery notifications.
Let's step back a pace or two.
The "spirit of the original RFC" was that no-one would be trying
to game the system; thus MailFrom was quite likely to be correct,
and barring that, was unlikely to annoy anyone. This "spirit" is
so far expired that it's not even a good joke anymore.
We need to let go of the pretense that NDNs-as-we-know-them-today
implement this "spirit".
If you've followed me this far, the question should be, "What
is the best way available to notify someone able to fix a small
problem that the message will not be read?"
There's actually some rather good work towards that, called BATV:
http://www.mipassoc.org/batv/
which enables the use of a MailFrom which cannot be delivered to
the "sender" unless it passes some checks by the "originating"
mailserver. This sort of mechanism can automate delivery of NDNs
to a server with good information about whether they match
something sent through that server.
We certainly cannot mandate BATV in 2821bis, but we can set the
stage for solutions of that ilk -- by allowing delivery servers
to refuse to send NDNs without "satisfactory" assurance that the
MailFrom address is useful to reach the sender.
That would _not_ be a fundamental change from RFC821 -- the
"satisfactory" assurance was a given when 821 was written.
And we're only fooling ourselves if we pretend that MUSTard in
2821bis will keep NDNs from being dropped in practice.
The alternatives essentially make email completely unpredictable,
Not _all_ alternatives...
since there are all sorts of perfectly good reasons why one
would not be able to validate the forward and reverse paths at
the same time.
(What does that have to do with it?)
And adding such a requirement would be as much out of scope for 2821
as requiring some particular model of sender validation.
Requiring delivery notifications is at least as unlikely to be
obeyed in practice as requiring NDNs.
We should not expect to "jawbone" our way to our visions of how
email "should" work: we should be content to document the protocol,
leaving it to the folks who manage email systems to balance the
tradeoffs.
Predictability of delivery is already dead. Users have stopped
expecting it. Honestly, we _have_ reached the stage where NDNs
are optional: if we want them to work "better", we should be
designing systems to give assurance of their utility.
--
John Leslie <john(_at_)jlc(_dot_)net>