I disagree with Paul's comment below also. I agree with David's response.
Nice job David.
The only difference is that the MDN carries additional status
information.... over and above what the ESS receipt carries. With all the
work that was done by the EDIINT and the MDN workgroups on receipts, I
would have hoped that some of that functionality would have been included
in the ESS stuff.
Lack of this functionality makes use of this a lot harder for the EDIINT
workgroup, of which SMIME is a base standard, and other groups like the fax
group. So please tell me know how to formally get this functionality into
the ESS stuff, without causing delays or problems for the authors. I
would think all we need to do is steal from the MDN status codes and stick
a couple of new fields into the receipt body. That does not seem hard to
From: David P. Kemp [SMTP:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Wednesday, April 15, 1998 3:06 PM
Subject: Re: Rethinking Receipt
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
ESS-style receipts are different than either of these.
I'm not up to speed on DSNs and MDNs, so forgive me for the
possibly stupid question:
DSN: server-to-server notification of transit
MDN: human recipient tells sender what he did with the message
ESS Receipt: UA-to-UA notification that sender's signature verified
reply: user does a reply-to email or news
Assuming all four of the above message types use integrity and
authentication protection provided by CMS/ESS,
and assuming that all four have a requirement to provide an integrity-
protected link from the response back to the original message it is
then why do you regard using an ESS SignedContentReference (or
eSSSecurityReceipt) a layering violation for some of the message types
(DSNs/MDNs) and not for others (ESS Receipts)?
How about the reply case, where the user wants to say "I agree with
your proposal" and wants to guarantee that his reply is unambiguous
without including the entire original text in the reply?