There are several "real problems" that a new message format could solve.
For example, the use of an envelope container would certainly "fix" the
problem that we have now with feature blackholes. Currently, a single
legacy server between two DSN-aware systems prevents that service from
functioning, while an envelope block that contained this data as a
separate unit could survive these kinds of systems (not 821 hosts, but
hosts which were aware of the new format but which were unaware of a
particular envelope extension). Surely you consider these blackholes as
"real problems"?
no, I don't - because most of the (mail) transport level features I can
think of are inherently per-hop and require per-hop negotiation.
let's put it this way - what real problems would you hope to solve by
having end-to-end conveyance of (mail) transport level features,
and what's preventing you from adding such features to SMTP (say
by adding a "generic feature" frob to MAIL and/or RCPT) with considerably
less barrier to deployment and less disruption to the installed base?
If you want to do something useful for email, how about figuring out
how to make it really reliable, or spam-proof, or virus proof?
What I am thinking about is that we have an opportunity to do all of this,
as well as to fix several other problems. None of these issues alone
warrant an overhaul, but cumulatively they certainly do.
which issues are the ones that warrant an overhaul of the message format?
Moreover, they are actually feasible as part of an overhaul.
it's not clear that the overhaul is feasible.
Keith