Now consider DSNs. Here the tradeoff is very different: Carrying the
information in the envelope has some costs associated with it, but the
benefit is that the resulting mechanism is reliable. A header-based
mechanism is inherently unreliable. The WG debated this and decided that
reliability was worth the cost. And while I'm sure that the purists were
pleased that this envelope information didn't get added to the header, I
don't recall this as being a deciding factor.
The problem, here, though is that the actual choice is very often between
an unreliable implementation (via header fields) and a useless
implementation (via envelope, which doesn't happen to be supported end-to-
end, and thus cannot work end-to-end).
And yes, I really do believe that the current definition is practically
worthless. Far too many MUAs and MTAs don't support it, and I see no signs
of this changing in the near future.
It is certainly true that a number of MTAs and UAs don't support DSNs. However,
a very significant number of them do, including most of the major players, so
many that at least in my own experience I find that when I use DSNs they work
most of the time. And even when they don't work up to final delivery I get a
result that is at least of some utility -- often knowing that a messasge is no
longer on the local server is sufficient.
Bottom line is that I disagree with your assessment that not enough clients
and servers support this extension to be useful.
Now, a header solution is certainly less reliable, but I suspect it would
have the desired effect in significantly more situations.
This approach was tried, albeit informally, for many years prior to the
development of NOTARY. But again speaking from my own experience, I found
that this mechanism was almost never worth the bother of using it.
So once again I disagree with you -- I think your prediction that such a
scheme, were it developed now, would somehow deploy to a much greater extent
than DSns have, is hopelessly optimistic. (And remember that were we to switch
we'd effectively be starting over.)
And finally, remember that if what you're after is a true end to end header
based receipt, we have one of these too. It s called an MDN and it is defined
in RFC 2298. The semantics are somewhat different, of course, and that makes it
a useful service to have in addition rather than isntead of, DSNs.
Ned