ned+ietf-822(_at_)mrochek(_dot_)com wrote:
I'm not sure how productive it would be to set expectations and
requirement thresholds higher than the current service offers.
Which greatly diminishes the value of any replacement format.
I don't know if you think I've promised something grand from this. All I
promised from this particular feature would be the capability to transfer
options through routers without having to upgrade the router. That is
still there.
But as my analysis shows this doesn't buy you as much as you originally
claimed.
It buys you the option to implement features on top of mail without having
to get every MTA on the planet to salute first, and without having to
write things into the message headers (the other current option).
I want a "rescind" feature. I don't want to generate another message, and
I don't want the delivery server to have to poke around in message headers
since the original message may have been encrypted. An envelope feature is
the right way to do this today, but every MTA in between me and the
recipients has to be upgraded before it will work. Under the
pseudo-proposed system, it is an option with an alert. If the delivery
server doesn't support the option, then I get a failure-trace message back
from the server telling me so.
Yes, you could add this feature to SMTP today. You could add lots of
things to SMTP today. Lots of hammering on lots of code to make any of
them work on a broad scale.
...once you upgraded the infrastructure to allow the new extension
to work through all of the hops. :/
A vastly simpler task than getting everything to use an entirely
different format for everything.
I don't know if you've think I promised everything would use it. I am
pretty sure I said that backwards compatibility with legacy servers and
mailboxes is necessary.
Header signatures and encryption can be accomplished by using
nested messages.
Completely impractical.
Funny, I use this capability on a daily basis as part of an internal
setup at Sun.
I'd like to see one of these messages, please. I'm particularly interested
to see how it handles the Subject header field in such a way as to protect
the message's privacy while at the same time functioning to serve
Subject-based threading.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/