ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Pretty quickly you arrive at something where you'll have submission,
relay, and delivery criticality at a minimum. This gets to be complex
I agree that the function-centric nature of SMTP participants is one of
the core dilemmas in such a design.
This problem also exists in the current model, of course. If the first-hop
server doesn't support BDAT then the average joe is likely to get an error
which they do not understand. As far as that goes, I'm not sure how
productive it would be to set expectations and requirement thresholds
higher than the current service offers.
With that in mind, if an extension actively requires the participation of
a router and must be rejected if that router doesn't understand it, then
we are at the same level of functionality as we have today. However, we
would also have the ability to define a default position of "ignore"
whereby unrecognized options could be safely passed.
Actually, an (admittedly complex) single SMTP extension to allow for
envelope elements that can pass through relays that don't understand
them could be defined now.
...once you upgraded the infrastructure to allow the new extension to work
through all of the hops. :/
Header signatures and encryption can be accomplished by using nested
messages.
Completely impractical. I have to send a message to myself (or save it to
the Drafts folder) and then forward the resulting message, which destroys
secondary context such as threading, unless of course I have a tool that
does all of this on my behalf. Even then, somebody can take the embedded
message out of its context and all of the intended features and benefits
will be lost.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/