Table of Contents Previous Next Index

Section 21 Authenticating Message Origin with DomainKeys Signatures

Section 21 Authenticating Message Origin with DomainKeys Signatures
LISTSERV Maestro lets you use DomainKeys signatures to authenticate that the messages (sent for a specific email job) do indeed originate from the domain in the “From:” address. Major ISPs already check every incoming mail to see if it is signed with a valid DomainKeys signature. Once DomainKeys has become an accepted standard for message origin verification, the current policy of only informing the recipient about the DomainKeys verification result in an additional header entry may change, and an ISP may opt to not even deliver the message to the recipient or to mark it as coming from an unsure origin. Therefore, in order to achieve good deliverability, signing messages with a valid DomainKeys signature can become more important in the future.
Support for DomainKeys signatures in LISTSERV Maestro works on three levels:
LISTSERV as the mail distribution engine must be configured to support DomainKeys signatures for certain address domains, which requires creating a valid private/public RSA key pair and additional configuration of LISTSERV parameters. See the LISTSERV documentation for further details about setting up DomainKeys at a LISTSERV host.
The LISTSERV Maestro Administration Hub lets you enable or disable DomainKeys signatures on the application default level and the group/single user level.
To define application-wide default settings for DomainKeys signatures, open the Administration Hub, click on the Global Settings menu, select Maestro User Interface, and then finally select Default DomainKeys Settings. The DomainKeys Settings screen opens, allowing you to define the default behavior for DomainKeys signatures.
This screen also lets you define whether or not users are allowed to change the DomainKeys signature settings for each job.
Digitally signing email messages following the DomainKeys standard is a means to assert that the message indeed originated from the domain that is claimed in the "From:" address. The digital signature is created for the whole message, which has the additional benefit that the recipient (once he or the receiving MTA has verified the signature) can be sure that the message has not been modified on its path from the sender to the recipient.
Before enabling DomainKeys support in the application, bear in mind that if DomainKeys signatures are enabled for a mail job, then all messages from the mail job must be run through a signature computation, which in most cases slows down mail job delivery.
Note: Changing the settings on this screen only applies to mail jobs that have not yet been authorized for delivery.
Figure 21-1 The DomainKeys Settings Screen
To define the DomainKeys signature settings for a group, go to the Accounts and Identities screen, and then click on the name of the group. The Group Overview screen opens. Click on the Group menu, and then select DomainKeys Settings.
If your company or organization has decided that all messages that are sent using LISTSERV Maestro are to be signed with a DomainKeys signature, then choose Yes, use DomainKeys signing and The user must use the setting supplied above without changes for each mail job.
If your organization has decided that all messages sent from certain groups using LISTSERV Maestro are to be signed with a DomainKeys signature, then you can create a less strict policy by defining group-level deviations from the application-wide default settings. For example, one group may require the use of DomainKeys signatures while another group may not.
If it is not possible to agree on a strict policy for these settings even on the lowest group and/or single user level, then you should first choose a suitable default for enabling or disabling DomainKeys signatures, and then select the The user may change the setting supplied above on a per-job basis option.
Important: Before actually using such a setup, make sure to educate your users about the pros and cons of DomainKeys signatures. In a high volume environment, one reason to opt against DomainKeys signatures is that mail job delivery performance is impacted. LISTSERV uses highly optimized algorithms to perform the signing and the throughput benefits from modern CPU extensions such as SSE2, so one option to use DomainKeys even in high volume environments is to acquire better hardware to run LISTSERV. On the other hand, not using DomainKeys may cause deliverability problems in the future if many of your subscribers have accounts with ISPs that enforce DomainKeys signatures on incoming mails or mark mails that lack such a signature as “coming from unsure origin” to warn the user about possible forgery or a phishing attempt.
The LISTSERV Maestro User Interface interacts with LISTSERV to determine if the supplied sender address is supported by one of the DomainKeys that were deployed to the LISTSERV host when DomainKeys was configured. This check is performed at several stages during the life cycle of an email job. The sender definition settings of an email job are only accepted as valid if either DomainKeys signing is switched off or if the check succeeds at the LISTSERV host that is configured for the account. After this, an additional check is performed when the email job is authorized for delivery. If the email job is configured for future delivery, then there is a considerable time window during which the administrator may opt to change the DomainKeys settings at the LISTSERV host. Therefore, if DomainKeys has been disabled during this time window, then the email job delivery will fail with an appropriate error message.
In addition, the system also performs consistency checks between the settings for the current email job and the settings that are defined for the current account in the Administration Hub. These checks ensure that the settings of the email job are the same as the default settings if the administrator has defined that users may not change the DomainKeys settings on the job level. Once the email job has been authorized for delivery, these additional checks are not repeated. This means that if the settings in the Administration Hub are changed, then this change will only affect email jobs that have not yet been authorized for delivery. Jobs that are authorized will not be affected from subsequent changes in the Administration Hub.