Navigation * Home / News / Proof of Delivery

Email receipt is proof of delivery?

© L J Davies, Kalypton, all rights reserved.

Many systems have been created to provide some form of email receipt as a mechanism to show proof of delivery.

Such systems are not fully compliant as the definition of proof of delivery is that the data was received and was capable of being read, processed and understood by the recipient.

An email receipt simply shows that something may have been received. It does not prove that the recipient received the message that was sent nor does it show that the recipient could read the message had he chosen to do so. Proof of delivery is an integral part of non-repudiation and means that the sender can prove that the recipient received the document in a form that the recipient could read if he so wished. A read receipt simply shows that the recipient opened a message. It does not show that the recipient could actually read the message. There is no guarantee that the sender will receive a read or delivery receipt.

Need to show that an email was read by the recipient

Some products provide the ability to indicate that a recipient has actually opened a message as a required element of proof.

This does not add to compliance or legal effect as the only requirement is for the sender to be able to prove delivery to the organisation.

It is irrelevant, once a sender can prove delivery, whether or not the recipient actually reads the message for it to have any effect. As with standard contract law and the principles of legal service, once the sender can prove that the recipient has received a document then it is for the recipient to decide whether or not to read it. The sender has achieved all that he needs to in order to give effect to the message.

In the commercial arena the sender only has to prove delivery to an organisation, as primary liability lies with the organisation.

The Requirements of a Messaging Solution

It is a mistake to concentrate solely on the issues of compliance without taking into consideration operation requirements. This chapter is therefore split into two parts, compliance requirements and operational requirements.

Compliance requirements

A fully compliant messaging solution must satisfy the following:

• A message coming into the organisation must be archived before any other processing can take place.

• A message leaving an organisation must be archived after all other processing has taken place.

• All messages must be stored for the required retention period.

• It must be possible to delete or alter a message if required to do so by law before the expiry of the retention period and any such change must be controlled and audited.

• Once the retention period has expired, any messages containing personal data must be deleted.

• It must be possible to demonstrate that an archived message has not been changed since it was archived unless a change is required by law.

• It must be possible to demonstrate that an archived message has not been deleted before its retention has expired, unless required by law.

• It must not be possible to expunge a message from the archive until its retention period has expired unless it is required by law.

• Any access or attempted access to a message must be logged.

• Access to messages must be fully controlled and audited.

• Message retrieval must be restricted to those who have authorisation to retrieve the relevant messages.

• Legal discovery requests must be fully satisfied within 24 hours.

• There must be support for message content scanning to meet regulatory requirements.

• A user must be able to retrieve messages that they have sent or received.

• All the requirements of non-repudiation must be satisfied.

Operational requirements

In addition to the requirements of compliance there are a number of additional capabilities required for a messaging solution. Future regulatory developments may lead to some of these requirements becoming mandatory.

• The ability to recover an end user’s mailbox.

• The ability to provide message confidentiality.

• The ability to scan for viruses.

• The ability to filter for spam.

• The ability to perform content analysis for operational requirements.

• The ability of a user to manage their mailboxes without affecting the integrity of the archive.

• The ability of a user to utilise the archive as a knowledge store.

• The ability of a user to work online and offline with the same search functionality.

• The ability to assist in the operational efficiency and management of the email server.

• The ability to operate transparently with no impact on the user desktop.

In particular, a compliant system must be designed to help meet fully, as a minimum, the following legal and regulatory requirements and best practice standards.

1. The BSI Code of Practice for Legal Admissibility of Electronic Documents and e-Commerce Transactions, BSI DISC PD 5000: 2002;

2. The BSI Code of Practice for legal admissibility and evidential weight of information stored electronically, BSI-DISC PD 0008:1999 and the forthcoming international derivative of it, ISO TC 15801;

3. Financial Services Act 1986;

4. Regulation of Investigatory Powers Act 2000;

5. SEC Rule 17a-4 under the Securities and Exchange Act 1934;

6. NARA GRS20 (US Federal Government);

7. US DOD 5015.2; and

8. Data Protection Act 1998.

CONCLUSIONS

The list of requirements for a fully compliant solution is long and difficult to meet. Many existing products claim compliance. Few, if any, meet all the requirements. Most suffer to some extent from the misconceptions described earlier.

Organisations may feel safe because they are using current “best of breed” solutions. This is a false sense of security. From a legal perspective:

• If an organisation uses a system that it knows is non-compliant then it can be held liable (even though it may be “best of breed”).

• If an organisation knows of a system that is compliant but fails to use it then it can be held liable.

The bottom line from a legal perspective – if an organisation cannot use a compliant system then it should not communicate via electronic mail!