PDF(59.6 KB) View with Adobe Reader on a variety of devices
ePub(98.9 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(79.2 KB) View on Kindle device or Kindle app on multiple devices
Updated:December 15, 2016
Document ID:200881
Bias-Free Language
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 details about DKIM authentication results handling on the Email Security Appliance (ESA).
Why is the ESA handling DKIM authentication result permfail as hardfail?
The ESA content filter condition DKIM Authentication has several options availabe as the image below is highlighting.
If the condition match on Hardfail it will include messages that show up as permfail in the mail log file and message tracking as shown in the example below:
Message 815204 DKIM: permfail body hash did not verify [final] (d=sub.example.com s=selector1-sub-com i=@sub.example.com)
The ESA considers permfail as hardfail and puts the result into the Authentication-Results header as dkim=hardfail. There is a difference between ESA's naming of DKIM events and RFC6376 naming. In Authentication-Results headers (and message tracking) ESA needs to show proper RFC6376 strings, while the content filter uses different event names.
The event mapping for RFC6376.PERMFAIL == ESA Content Filter Hardfail
The majority of verification failures are due to signature and message body hash 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 (including the signature itself) on the message. There are several causes for these two errors: the message may have been modified (perhaps by a mailing list or forwarder) in transit; the signature or hash values may have been calculated or applied incorrectly by the signer; the wrong public key value may have been published in DNS; or the message may have been spoofed by an entity not in possession of the private key needed to calculate a correct signature. It is very hard to distinguish these causes by analysis of the message, although the origin IP address may provide some helpful forensics in the case of spoofing. However, for privacy reasons we don’t have access to the messages themselves, so any such analysis isn’t possible. There is a number of messages whose signatures don’t verify for other reasons, often because of easily avoided configuration errors in the public key (selector) records published in DNS. For more details please refer to the link below.