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.