*Proof of delivery* allows a message originator to verify that
a message was delivered to the intended recipient(s). This service
counters the threat of falsely acknowledged receipt. It is provided on a
per-recipient basis using symmetric or asymmetric encryption techniques.

The message originator requests the service from each message recipient (i.e., proof may be requested from some recipients, but not from others). The recipient returns the proof in a delivery report. Although the report is created by the delivering MTA, the proof included in the report is generated by the recipient MTS user (e.g., the recipient UA). The proof is computed as a function of the recipient's name, the time the message was delivered, and the following information from the subject message: the content identifier, the security label, and the plaintext content.

To generate the proof using an asymmetric encryption algorithm, the
recipient signs the report using its private key. The message
originator validates the signature using the recipient's public key
certificate. This certificate may be transferred in the report, or
obtained by some other means. An asymmetric *proof of delivery* also
provides *non-repudiation of delivery* (see sec. 11.6.6).

If a symmetric encryption algorithm is used, the recipient computes the
*proof of delivery* using a symmetric encryption key. The originator
uses the same key to validate the proof. The X.400 Recommendations do not
define how this key is distributed between the communicating parties. A
symmetric *proof of delivery* does not provide *non-repudiation of
delivery*.

A message recipient is not mandated to return *proof of delivery*.
That is, even if the originator requests the service, the recipient has
the option of not returning the proof. Thus, not receiving *proof of
delivery* does not imply non-delivery of the subject message.

Fri Oct 7 16:17:21 EDT 1994