In order for DomainKeys support to work with LISTSERV, the following requirements must be met:
Note: Generally, L-Soft Support cannot assist you in setting up your DomainKeys DNS records. However, the relevant sections of the Internet Draft for DomainKeys are reproduced below for your convenience.
While the disposition of inbound email is ultimately a matter for the receiving system, the introduction of authentication in email creates a need for the sender domain to indicate their signing policy and preferred disposition of unsigned email, in particular, whether a domain is participating in DomainKeys, whether it is testing, and whether it signs all outbound email.
Recipient systems SHOULD only retrieve this policy TXT record to determine policy when an email fails to verify or does not include a signature. Recipient systems SHOULD not retrieve this policy TXT record for email that successfully verifies. Note that "testing mode" SHOULD also be in the Selector TXT record if the domain owner is running a DomainKeys test.
There is an important implication when a domain states that it signs all email with the "o=-" setting, namely that the sending domain prefers that the recipient system treat unsigned mail with a great deal of suspicion. Such suspicion could reasonably extend to rejecting such email. A verifying system MAY reject unverified email if a domain policy indicates that it signs all email.
Of course, nothing compels a recipient MTA to abide by the policy of the sender. In fact, during the trial, a sending domain would want to be very certain about setting this policy, as processing by recipient MTAs may be unpredictable. Nonetheless, a domain that states that it signs all email MUST expect that unverified email may be rejected by some receiving MTAs.
Important: Please be aware that these sites are not controlled by or supported by L-Soft.
brisbane._domainkey.
example.com IN TXT "
t=y; g=; k=rsa; p=MHww ... IDAQAB"
Note: We strongly recommend the use of the "
t=y" test flag when you are first trying out DomainKeys. Otherwise a simple mistake in your DomainKeys configuration could cause verification failure for mail coming from your domain, and other sites that have implemented DomainKeys will reject your mail. Always test first!
By default, the key called DEFAULT is used (if one exists). So in the sample above, the key for
EXAMPLE.COM will be fetched from
DEFAULT.DKIM whereas the key for
EXAMPLE.CA will come out of
CA.DKIM.
In particular, the 'd=' parameter in the key must match or be a parent of the domain you want to sign for. Thus the key for EXAMPLE.COM can be used to sign for EXAMPLE.COM and *.EXAMPLE.COM, but not for EXAMPLE.CA. LISTSERV will skip any invalid entries. Keys are kept in memory, so you can have as many .dkim files as you want.
If there is no DKIM_SIGN variable or if you are running a LISTSERV version without DomainKeys support, LISTSERV does not attempt to load any keys and the DomainKeys feature is bypassed.
|
•
|
"Misc-Options= NO_DKIM_SIGNATURE" can be added in the list header (or made the system default via the DEFAULT_MISC_OPTIONS configuration variable) to override this.
|
|
•
|
Incoming DomainKeys or DKIM signatures submitted to a mailing list will be removed unless " Misc-Options= KEEP_DKIM_SIGNATURE" is set in the list configuration. This is necessary because these signatures almost never match after the message has been processed. The worst thing that could possibly happen to your deliverability is a DomainKeys signature that does not match and causes the message to be flagged as suspicious.
|
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DomainKeys is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for subscribers on systems that have implemented the client side of DomainKeys. The DKIM specification may be more robust in this respect, but even DKIM signatures will probably not survive when posted through a mailing list. Use the
KEEP_DKIM_SIGNATURE option at your own risk.
A new DKIM=NO|YES option has been added to DISTRIBUTE (default: NO). This will fail if running a LISTSERV version without DomainKeys support, but otherwise it always succeeds. Messages originating from domains for which LISTSERV has been configured to sign will be signed, while those originating from other domains won't be.
Once you have become comfortable with DomainKeys signatures, you may want to have LISTSERV sign every message that it generates, regardless of its source. Setting DKIM_SIGN_ALL=1 in the site configuration file tells LISTSERV to try to sign every message for which it has a suitable private key, as defined in the DKIM_SIGN configuration parameter. For example:
|
•
|
LISTSERV will not sign messages that already have a DomainKeys signature. Double DomainKeys signatures are disallowed in most cases and, even when allowed, there is a risk that they may not be handled correctly by all implementations. This does not apply if the incoming DomainKeys signature has been discarded (for example, a mailing list without "Misc-Options= KEEP_DKIM_SIGNATURE"). In that case, the message can be signed without risk of false positive.
|
Note: In LISTSERV 14.5 and following, Embedded Mail Merge is enabled by default, so unless it has been explicitly disabled (that is, with EMBEDDED_MAIL_MERGE=0 in the site configuration file), this will not be an issue for most sites.
