Keith Moore wrote:
you have no idea about whether the ultimate destination MTA
supports such a feature.
Agreed - but the same would apply to an 'envelope blob' mechanism
(which is what we were talking about)
right, but the envelope blob mechanism wouldn't be appropriate for
requesting delivery notifications either.
Sure it would. In fact, an trace-level envelope flag was provided in the
list of features I want, which has delivery success as one of the
standardized values. I'm not sure about the appropriateness of that, but
DSNs are very desirable as a standardized element. Even if it wasn't part
of the core service, it would be simple to add as an envelope extension.
<Return-Path>foo(_at_)bar</Return-Path>
<Forward-Path>bar(_at_)foo</Forward-Path>
<Original-Recipient>baz(_at_)bar</Original-Recipient>
<Env-Extension>dsn.cs.utk.edu (pick a namespace)</Env-Extension>
<Delivery-Alerts>dsn.cs.utk.edu</Delivery-Alerts>
The delivery process would examine for any alerts, process them if they
were understood and supported, and return one of the (standardized)
DSN-like error responses if not. Failures also only need to use the
envelope data, and since the envelope is provided to the MUAs, the
originator system can act upon this information as appropriate.
actually, it's not at all clear whether the envelope blob is useful
for anything -
The original intention is two-fold, first is to separate the transfer and
content headers so that they can be handled separately (eg, encrypt the
content headers as a blob, sign the transfer headers as a blob).
With the ability to sign transfer headers, part of the problem with
verifiable mail can also be addressed. EG, we can do recursive envelope
signatures, thereby proving that the message could only have been sent
through the path it is claimed to have been sent through. This means that
faking the transfer path should become impossible.
<Received-From>
<Host-Id (eg an x509 subject)>submission.host.name</Host-Id>
<Envelope-Sig>signature-of-envelope as received</Envelope-Sig>
</Received-From>
<Received-From>
<Host-Identifier>originator.host.name</Host-Identifier>
<Envelope-Sig>signature-of-envelope as received</Envelope-Sig>
</Received-From>
<Return-Path>foo(_at_)bar</Return-Path>
<Forward-Path>baz(_at_)foo</Forward-Path>
Crypto is my weakpoint so I will assume that there is some problem with
the above that the experts here will point out and fix. I am aware of the
problem with key availability and have some things in mind for that.
You can't do that very easily with the existing setup.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/