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.
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.
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).
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>
to the message. of course, existing UAs may not handle this transparently.
but then again, they won't handle your proposal transparently either.
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.
Keith