Greetings,
The concept of "receipts" for email messages is one that is certainly used in
various environments with varying degrees of protection for the parties. I am
not convinced that any existing system currently implements receipt capability
with the "strongest" level of protection for both the sender and recipient. That
strong level can be described as:
Alice wants to send message, M, to Bob. She wants to get a receipt proving that
Bob received M from Alice. She does not want Bob to see or read M before she is
capable of having the receipt. Bob wants to make sure that if he signs a
receipt, that Alice will let him see the message M. In otherwords, the system
must make it possible for Alice to receive the receipt at the same time that
Bob received the message. Both parties are protected from the other cheating.
This is possible and is discussed in depth in "Certified Electronic Mail" by
Professor Doug Tygar and myself presented at ISOC 94. (see www.eit.com/~ali)
This capability is very useful especially in electronic commerce.
In the strongest system, MSP, I believe it is possible for the recipient to read
the message before signing the receipt. This implies that the message is
available in cleartext in the system and if the recipient finds a way to bypass
the UA, they could read the message without generating a receipt. (Steve,
please correct me. I had a copy of MSP but since I moved, I would be interested
to have a pointer again...)
The IETF receipt working group is deliberately not going to address "strong"
receipt capability. It can be called a simple receipt notification capability
similar to the delivery notification. As I recall from the last meeting, the
recipient has the option to not generate the receipt at all, even after reading
the message! One easy way for Unix users to do this is: cat /usr/spool/mail/xyz
In conclusion, I caution the reader that just because someone claims they have
do "receipt", it does not mean that they do it "all"...
Regards,
Ali
p.s.
I am just catching up with hundreds of mail and the topic of "receipts" in this
thread motivated me to respond. I appologize if my response is out of scope or
already mentioned.
From: Steve Kent <kent(_at_)bbn(_dot_)com>
X.400 and MSP differ in the return receipt facility. In X.400,
the receipt signature is computed by the deliver MTA on the ciphertext.
In MSP, it is computed by the receiving UA on the plaintext. This has
significanct implications for the service provided, the data that the
originatior must retain, etc.
From: Ned Freed <NED(_at_)innosoft(_dot_)com>
(3) Non-repudiation of or proof of receipt. This is basically the same service
as proof of delivery, the difference being that an appropriately
constructed read receipt is signed by the recipient rather than a delivery
receipt being signed. Work is already underway to define the formats for
read receipts. (A new working group is being formed and I expect a draft
specification to appear as an Internet Draft any time now.)