DomainKeys
DomainKeys is an email verification system that can be utilized to prevent spoofing (forging another person's email address in order to pose as a different message sender). Further, because most spam messages contain spoofed addresses, DomainKeys can help greatly in the reduction of spam even though it wasn't specifically designed to be an anti-spam tool. Finally, DomainKeys can also be used to ensure the integrity of incoming messages, or ensure that the message hasn't been tampered with between the time it left the sender's mail server and arrived at yours. In other words, with DomainKeys the receiving server can be sure that the arriving message is from the sender indicated and that no one changed that message in any way.
In order to ensure the validity and integrity of messages, DomainKeys uses a public and private key-pairs system. An encrypted public key is published to the sending server's DNS records and then each outgoing message is signed by the server using the corresponding encrypted private key. For incoming messages, when the receiving server sees that a message has been signed, it will retrieve the public key from the sending server's DNS records and then compare that key with the message's DomainKeys signature to determine its validity. If the incoming message cannot be verified then the receiving server knows it contains a spoofed address or has been tampered with or changed. A failed message can then be rejected, or it can be accepted but have its spam score adjusted.
To configure MDaemon to verify incoming DomainKeys signed messages, use the options provided on the DomainKeys Verification tab located at Security SPF/DomainKeys… To configure MDaemon to sign outgoing messages, use the options provided on the DomainKeys Signing tab of that same dialog. MDaemon's main interface includes a DomainKeys tab (located under the Mail tab) that can be used for monitoring DomainKeys activity in real time, and you can log DomainKeys activity using the option at Setup Logging… Options.
For more on DomainKeys, visit: http://antispam.yahoo.com/domainkeys.
Use this tab to configure MDaemon to look for DomainKeys signatures in incoming remote messages and to attempt to verify them when found. When an incoming message has been signed, MDaemon will retrieve the public key from the sending server's DNS record and then use that key to test the message's DomainKeys signature to determine its validity. If the signature verification process returns a "Fail" result then MDaemon will retrieve the sending domain's DomainKeys Policy. If the policy does not indicate that DomainKeys is merely being tested, then the message can be rejected outright or accepted but have its spam score adjusted upward. If a message is not signed, then MDaemon will still retrieve the sending domain's DomainKeys Policy to determine whether or not all of that domain's messages should be signed and whether it is test mode. If the domain is not merely testing DomainKeys, and it indicates that all messages should be signed, then the message will receive a "Fail" result and treated accordingly. When a message is not signed and the domain's DNS record does not contain a DomainKeys Policy, then the message will be processed normally as if the DomainKeys system wasn't being used. Messages that receive a "Pass" result will continue through normal processing and have their spam scores adjusted accordingly.
DomainKeys Verification
Perform DomainKeys processing on incoming messages
Click this option to enable DomainKeys verification of incoming remote messages.
…send 550 error code
When this check box is enabled and the DomainKeys verification process returns a "Fail" result, MDaemon will return the 550 code and reject the message during the SMTP process unless the sending domain's DomainKeys Policy indicates that it is merely testing DomainKeys. If the domain's policy indicates it is testing DomainKeys then the message will be processed normally.
…and then close the connection
Click this option if you wish to close the connection to a sending server when DomainKeys verification of a message receives a "Fail" result and the message is rejected according to the previous option. If this option is disabled then the message will still be rejected according to the previous option but the connection will be allowed to continue.
Add this to the Spam Filter score for PASS result
The value specified here will be deducted from the Spam Score of any DomainKeys signed messages receiving a "Pass" result.
Add this to the Spam Filter score for FAIL result
The value specified here will be added to the Spam Score of any DomainKeys signed messages receiving a "Fail" result when the "…send 550 error code" option above is disabled and the sending domain's DomainKeys Policy does not indicate that DomainKeys is being tested. When the site's DomainKeys Policy indicates Testing, then a failed DomainKeys verification will not cause the Spam Score to be modified in any way.
Authenticated sessions exempt form DomainKeys
Click this option if you want to exempt messages from DomainKeys verification when the message session is authenticated via AUTH, POP before SMTP, or the IP Shield.
White list
Click this button to open the DomainKeys exception list. Messages originating from any IP addresses specified on the list will not be subject to DomainKeys verification.
Connections from Trusted IPs are exempt form DomainKeys
Use this option if you want connections from Trusted IP addresses to be exempt from DomainKeys verification.
Cache DomainKeys results
Click this option if you wish to cache the DomainKeys information found during the DNS lookup. By temporarily caching DomainKeys information contained in a domain's DNS record, you can increase the efficiency of processing DomainKeys signed messages that arrive in the near future from the same domain.
Cache
This button opens the DomainKeys cache. When using the Cache DomainKeys results option above, this file will list any currently cached information.
Authentication-Results header
Whenever a message is authenticated using SMTP AUTH, SPF, or DomainKeys, MDaemon will insert the Authentication-Results header into the message listing the results of the authentication process. If MDaemon is configured to accept messages even when they fail authentication, then the Authentication-
DOMAINKEYS
Results header will contain a code to identify the reason for the failure. These following are the result codes for DomainKeys:
good
bad
no signature no key bad key
internal err bad format
no resources revoked file error
The message had a signature, the verification process proceeded, and the
signature verified. The message passed. The message had a signature, the verification process proceeded, and the signature did not verify. The message failed.
The message did not contain a DomainKeys signature.
The message had a signature, but no public key exists for the selector in DNS.
The message had a signature and a public key exists for the selector, but it is not a properly formatted key. An undefined internal processing error occurred. The message or signature parameters are not in a valid format or are using
improper syntax.
A memory or disk allocation attempt failed.
The message had a signature, but the public key has been revoked.
The verification code could not access, find, or open the message file.
Use the options contained on the DomainKeys Signing tab to control whether or not some outgoing messages will be signed, and to designate which messages should be signed. You can also use this tab to designate selectors and generate corresponding public and private keys suitable for use with the DomainKeys specification. A default selector ("MDaemon") and a default public and private key are created for you automatically on startup. All keys are unique-they are never the same from one site to another, regardless of the selector specified. By default, keys are generated with a secure bit depth of 1024 bits.
DomainKeys Signing
Sign outgoing messages
Click this option if you wish MDaemon to sign some outgoing messages. In order for a message to be signed: it must meet the criteria designated under the Define which messages are eligible for signing button, it must be destined for a non-local address, and it must be received by MDaemon for delivery on an authenticated session via SMTP AUTH. Mailing list messages are never signed. There is also a Content Filter action, "Sign with DomainKeys selector…" that you can use to cause messages to be signed.
Sign using this selector
From the drop-down list, choose the selector whose corresponding public/private key pair you wish MDaemon to use when signing messages. If you wish to create a new key pair with a different selector, then type the desired selector name here and click "Create new public and private keys" below. If you wish some messages to be signed using an alternate selector, create a Content Filter rule using the "Sign with DomainKeys selector…" action.
Create new public and private keys
Click this button to generate a public/private key pair for the selector specified above. A public/private key pair will be generated for the selector, and the file dns_readme.txt will be generated and automatically opened. This file contains example DomainKeys data that you will need to publish to your domain's DNS records listing your DomainKeys Policy and the public key for the designated selector. The file lists samples for both testing and not testing status, and for whether you are signing all messages or just some messages originating from your domain. If you are currently testing DomainKeys or this selector, then you will need to use the information contained in the Testing entries for either the Policy or the selector, depending on what you are testing. Otherwise you will need to use the Not Testing entries.
All keys are stored in PEM format, and all selectors and keys are stored under the \MDaemon\Pem folder in the following way:
\MDaemon\Pem\<Selector>\rsa.public - public key for this selector
\MDaemon\Pem\<Selector>\rsa.private - private key for this selector
Define which messages are eligible for signing
When you have enabled the sign outgoing messages option above, click this button to open the list of domains and addresses that MDaemon will use to determine whether or not a message should be signed. For each address listed, you must also designate whether or not the message should be to or from that address in order for it to qualify to be signed. Wildcards are permitted.
