DKIM Signing Settings
Signatures expire after [XX] days ("x=" tag, 7 days recommended)
If you wish to limit the number of days that a DKIM signature can be considered valid, activate this option and specify the desired number of days. Messages with expired signatures will always fail verification. This option corresponds to the signature's "x=" tag. This option is enabled by default, with the value set to 7 days.
Signatures include creation time stamp (include t= tag)
When this option is enabled, the signature creation time stamp ("t=" tag) will be included in the signature. This is enabled by default.
Signatures include query method(s) (include q= tag)
By default this option is enabled. It causes the signature to include the query method tag (e.g. "q=dns").
Signatures include body length count (include l= tag)
Enable this option if you wish to include the body length count tag in DKIM signatures.
Signatures include original header content (include z= tag)
Click this option if you wish to include the "z=" tag in the DKIM signature. This tag will contain a copy of the message's original headers. This can potentially make signatures quite large.
Signatures include reporting requested (include r=y tag)
Enable this option if you wish include the r=y tag in your signed messages. The presence of this tag indicates to receiving servers who honor the tag that you wish to receive AFRF failure reports from them when they encounter messages purporting to be from your domain but fail DKIM verification. To receive these reports, however, you must also configure a DKIM reporting TXT record in your domain's DNS. See RFC-6651: Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting, for syntax and instructions on how to do that. Since this option requires DNS changes, it is disabled by default.
Canonicalization
Canonicalization is a process whereby the message's headers and body are converted into a canonical standard and "normalized" before the DKIM signature is created. This is necessary because some email servers and relay systems will make various inconsequential changes to the message during normal processing, which could otherwise break the signature if a canonical standard was not used to prepare each message for signing. Currently there are two canonicalization methods used for DKIM signing and verification: Simple and Relaxed. Simple is the strictest method, allowing little to no changes to the message. Relaxed is more forgiving than Simple, allowing several inconsequential changes.
Canonicalize headers using: Simple, Relaxed
This is the canonicalization method used for the message headers when signing the message. Simple allows no changes to the header fields in any way. Relaxed allows for converting header names (not header values) to lower case, converting one or more sequential spaces to a single space, and other innocuous changes. The default setting is "Simple."
Canonicalize body using: Simple, Relaxed
This is the canonicalization method used for the message body when signing the message. Simple ignores empty lines at the end of the message body—no other changes to the body are allowed. Relaxed allows for blank lines at the end of the message, ignores spaces at the end of lines, reduces all sequences of spaces in a single line to a single space character, and other minor changes. The default setting is "Simple."
DKIM Verification Settings
Verifier honors body length count (l= tag)
When this option is enabled, MDaemon will honor the body length count tag when it is found in an incoming message's DKIM signature. When the actual body length count is greater than the value contained in this tag, MDaemon will only verify the amount specified in the tag — the remainder of the message will remain unverified. This indicates that something was appended to the message, and consequently that unverified portion could be considered suspect. When the actual body length count is less than the value contained in this tag, the signature will not pass verification (i.e. it will receive a "FAIL" result). This indicates that some portion of the message was deleted, causing the body length count to be less than the amount specified in the tag.
Verifier requires signatures to protect the Subject header
Enable this option if you wish to require the DKIM signature of incoming messages to protect the Subject header.
Valid signatures from 'Approved List' domains add this to Spam Filter score:
The value specified here will be added to the Spam Filter score of any DKIM signed messages that receive a "Pass" result when the domain taken from the signature appears on the Approved List. When a message’s signature is verified but the domain is not on the Approved List, the Spam Filter score will not be adjusted—the verified signature will have no effect on the score. However, normal Spam Filter processing and scoring will still be applied to that message.
|
Ordinarily the value specified here should be a negative number so that the spam score will be reduced for messages containing a valid cryptographic signature when the domain taken from the signature is on the Approved List. MDaemon’s default value for this option is -0.5. |
See:
