Keith Moore wrote:
no it would have exactly the same problem - there's no way to know
whether the destination MTA supports the feature, so there's no way
to guarantee a delivery report.
That's what the Delivery-Alert list is for. If the listed feature isn't
supported, an error is triggered. This is substantially different from
having header fields be ignored as would be the case in the scenario
proposed by Paul -- that would be a silent error.
(eg, encrypt the content headers as a blob, sign the transfer
headers as a blob).
You can't do that very easily with the existing setup.
sure you can. all you have to do is prepend
content-type: message/rfc822<CRLF><CRLF>
In the current model, you cannot ensure that all of the systems in the
etransfer path support the necessary feature without imposing an
additional break-point (such as a mandatory extension). This is
significantly more difficult than designing a protocol to use such a
mechanism by default.
I must say that these arguments in favor of a new format aren't
getting any more persuasive - all they're doing is demonstrating
that we aren't even close to needing one.
Addding seven more layers of bubblegum and baling wire to the existing
service will not be as efficient or effective as designing for these
features from a blank slate.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/