PDF(27.6 KB) View with Adobe Reader on a variety of devices
ePub(112.9 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(84.1 KB) View on Kindle device or Kindle app on multiple devices
Updated:July 29, 2022
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how the Email Security Appliance (ESA) handles DomainKeys Identified Mail (DKIM) authentication results.
Why does the ESA handle the DKIM authentication result "permfail" as "hardfail"?
The ESA content filter condition DKIM Authentication has several options, as shown in this image:
When the condition DKIM Authentication Result is set to Hardfail, permfail messages appear in the mail log file and tracked messages, as shown in this example:
Message 815204 DKIM: permfail body hash did not verify [final] (d=sub.example.com s=selector1-sub-com firstname.lastname@example.org)
The ESA considers permfail to be the same as hardfail and includes the result in the Authentication-Results header as dkim=hardfail. The ESA names for DKIM events are different than RFC6376 names. In Authentication-Results headers (and tracked messages), ESA must show proper RFC6376 strings, whereas the content filter uses different event names.
These events are mapped: RFC6376.PERMFAIL == ESA Content Filter Hardfail
Signature and message body hash verification failures constitute the majority of verification failures. Body hash verification errors indicate that the body of the message does not agree with the hash (digest) value in the signature. Signature verification errors indicate that the signature value does not correctly verify the signed header fields (which include the signature itself) on the message.
There are several possible causes for these two errors. The message might have been modified in transit (perhaps by a mailing list or forwarder); the signature or hash values might have been calculated or applied incorrectly by the signer; the wrong public key value might have been published in the Domain Name System (DNS); or the message might have been spoofed by an entity that does not possess the private key that is needed in order to calculate a correct signature.
It is very hard to distinguish these causes by analysis of the message, although the origin IP address can provide some helpful forensics in the case of a spoofed message. However, for privacy reasons we do not have access to the messages themselves, so any such analysis is not possible.
There are messages whose signatures are not verified for other reasons, often because of easily avoided configuration errors in the public key (selector) records that are published in DNS.