Email Authenticity Report

In some situations, there may be uncertainty as to whether a body of email data is authentic or not. Fortunately, there is forensic value in the digital signatures applied by mail servers for anti-spam purposes. Increasingly, mail addressed to outside recipients have digital signatures automatically applied by the sender's mail server. These signatures were designed and intended for anti-spam purposes, but, as it turns out, have forensic value too.

In the best case, DKIM digital signatures can attest:

• to the fact that an email originated from the sender's domain (non repudiation of origin)
• to the integrity of certain email headers (such as sent date, subject, etc.) and body content (non repudiation of omissions)

In reality, the level of assurance varies according to the nature of the specific signature in question.

The Email Authenticity Report scans selected emails and verifies the digital signatures embedded inside them. The diagram below outlines the specific signature check types that are supported.
 

• Sender Policy Framework (SPF)
• Domain Keys Identified Mail (DKIM) 
• Authenticated Received Chain (ARC)
• Secure/Multipurpose Internet Mail Extensions (S/MIME) 

Generating a Report

When performing a records request and exporting data from MailArchiva, there is the option to generate an Email Authenticity Report in the Export dialog. Perform a search, select items to include in the report, click Export, check "Include Email Authenticity Report", select export format (for example,  HTML - Search results only), click Export.

Interpreting The Results

Sender Policy Framework (SPF)

The SPF check is designed to protect against spoofing.  It is performed by the receiving mail server to verify whether an email originates from a mail server listening to an authorized ip address.  If an SPF check succeeds, it asserts that the email being received originated from one of the authorized IP addresses listed in the sender's SPF DNS record.

The Email Authenticity Report does not perform the SPF check itself, since it is not appropriate to perform SPF checks long after an email is received. The reason being, SMTP Mail-From field information may be lost or altered after the fact, and also, the IP address of the mail server may have been legitimately changed.

As such, the Email Authenticity Report  merely outputs the value of the "Received-SPF" header. Unless this header is signed, it is possible that the header could be modified by an attacker. Thus the result of an SPF check is outputted for informational purposes only.
 

Domain Keys Identified Mail (DKIM)

DKIM signatures are applied by the sender's mail server. A DKIM signature typically covers select specified email header fields (not necessarily all of them). The body of a message always falls under the signature. To determine the header fields included in a DKIM check, hover the mouse over the check result to obtain a detailed explanation. For example, the explanation below, asserts that the From, Subject, To, Content-Type, Mime-Version and Date header fields were not modified from the point at which the email was processed by the sender's mail server. Furthermore, the body of the message was also not modified (since the body hash is by default always present and included as part of the signature).

It is important to note that DKIM signature failure does not necessarily mean the message was doctored. In rare situations, intermediate mail servers such as a mailing list or forwarding service, may add or modify one of the headers protected by the signature. Furthermore, signature checks have been known to fail due to the rare case where the encoding of a message is converted from 8 bit to ASCII during a transfer from one mail server to another.

Refer to Breaking DKIM On Purpose And By Chance for a more detail analysis of the limitations of DKIM signatures.

Authenticated Received Chain (ARC)

As stated earlier, the possibility exists for DKIM signature checks to report a false negative. In rare cases, an intermediate server, such as a mailing list server, may modify a header field (e.g. subject) that falls under coverage of the signature. The ARC standard counteracts this problem, by enabling each mail server along the chain to digitally sign the validation results of the message that it received. In this manner, the ARC signature scheme greatly minimizes the potential for false negatives.