Tech Tip (LISTSERV) – Issue 3 – 2006

Q: How can I use SPF and DomainKeys to increase LISTSERV's deliverability?

Answer by Liam Kelly
Senior Consulting Analyst, L-Soft

As anti-spam and anti-phishing filters tighten, deliverability has increasingly become an issue for mailing list administrators. Fortunately, there are steps that administrators can take to authenticate and protect their organizational identities. Once the email is authenticated and the source verified, then recipients can better determine whether the source is trusted or not.

The two most common tools for authenticating email are SPF (Sender Policy Framework) and DomainKeys [1]. This Tech Tip will discuss the usage of LISTSERV with each. It is not meant to be an exhaustive document about SPF or DomainKeys but is meant as an introduction to how LISTSERV integrates with the two.

SPF (Sender Policy Framework)

The current version of SPF (version one) works by checking the domain name of the sender of a message against the list of servers authorized to send email on behalf of that domain (the SPF record). If the sending server is listed as authorized to send on behalf of that user, the SPF record matches, and the recipient can be reasonably confident that the Return-Path is valid and that the message origin is what it claims to be. Otherwise, the match fails and the receiving server may decide whether to reject the message or flag it as suspicious. Because LISTSERV discussion list messages generally get sent with a MAIL FROM of "owner-listname@...", there should be no need to configure LISTSERV to do anything differently in order to use SPF for outbound email. [2]

SPF configuration for the sending domain is done entirely in the public DNS server. First, make an inventory of all servers that send outbound email for your domain, including all servers specified as SMTP_FORWARD hosts in your LISTSERV configuration. Once you have an exhaustive list, the next step is to create the SPF record in your public DNS server. The SPF record is a specially formatted TXT record that lists the servers authorized to send mail for your domain. The easiest way to create the record format is to use an SPF wizard (like the one found at www.openspf.org/wizard.html). Once you've got your TXT record format, install it in your public DNS server. A sample SPF record might look as follows:

For additional information about SPF record creation, see www.openspf.org.

DomainKeys

While SPF checks the envelope's MAIL FROM address, DomainKeys checks a digital signature of the message body itself (including important headers). LISTSERV 14.5 and later can be configured to digitally sign messages that it distributes. Like SPF, DomainKeys requires changes to your DNS; unlike SPF, it also requires some configuration of LISTSERV. To use DomainKeys with LISTSERV, you must create a digital key pair, configure your DNS to use the public key, and then configure LISTSERV to use the private key. Each step is detailed below:

1. Create the public and private key pair

DomainKeys uses a standard cryptographic key pair, consisting of a private and a public key. The sender signs the message using the private key, and the recipient checks the signature against the public key to verify the identity of the sender. A detailed discussion of cryptographic keys is beyond the scope of this document, but the private key should be a 768-bit RSA key [3]. The public key should be derived from the private key in PEM format. (On Linux/UNIX, openssl is the standard tool for creating such keys. On Windows, there is no standard tool, but any application that can create a 768-bit RSA key pair may be used. L-Soft has used the Windows port of openssl successfully. It is available for download at gnuwin32.sourceforge.net/packages/openssl.htm and the openssl syntax for creating the key pair is accessible online at domainkeys.sourceforge.net/keygen.html.)

2. Install the public key in DNS

Once you have a key pair, the next step is to install the public key in your DNS server. (The details of the DNS configuration for individual DNS servers are beyond the scope of this document; please consult your DNS vendor to make sure that your DNS server supports the TXT records necessary for DomainKeys.) There are two relevant types of entries for DomainKeys: the policy record and the selector record. The policy record is a TXT record that tells receiving domains your DomainKeys signing policy [4], and the selector record contains the public key against which to verify. The selector record entry should be a TXT entry containing the PEM key with line breaks removed. So the actual DNS entry might look something like:

If the above were a DNS entry for example.org, then signing a message and specifying a selector of "sample" would tell the receiving server to look up the public key for sample._domainkey.example.org to compare it against the signed message.

3. Supply the private key to LISTSERV

Install the private key in LISTSERV's main or home directory (the directory containing the *.list files). If you have only one private DomainKeys key (as will be the case for most sites), create a file called "default.dkim". The file should contain the domain and selector names, as well as the private key. The format is as follows:

In default.dkim, the "d" parameter is the domain hosting the policy record (in this case, "example.com"), and the "s" parameter is the selector name ("sample") that contains the public key.

4. Configure LISTSERV to sign for domains

Next, we need to tell LISTSERV for what domains it should sign messages. Add a DKIM_SIGN setting to your LISTSERV site configuration file (SITE.CFG or go.user). For example, if we were willing to sign for example.org and all *.example.org subdomains:

After editing the site configuration, restart LISTSERV. At restart, the LISTSERV log should contain an entry something like the following:

Once you've enabled DomainKeys in LISTSERV, LISTSERV will sign all outbound mailing list messages for which it has a suitable private key, including administrative messages, welcome messages, etc. If you want LISTSERV to also sign list postings from senders outside your own domain, add "Sender=List" in the list configuration, so that the Sender header address of list postings will contain a domain for which LISTSERV is able to sign [5]. To disable DomainKeys signing for a particular list, set "Misc-Options= NO_DKIM_SIGNATURE" in the list configuration.

To have LISTSERV also sign non-list-specific administrative messages, set the DKIM_SIGN_ALL parameter in LISTSERV's site configuration:

Conclusion

SPF and DomainKeys are relatively new technologies that promise enormous benefit in the fight against fraudulent email. However, publishing SPF records is quickly becoming standard Internet practice, and many major Internet Service Providers already verify SPF records as part of their inbound email filtering. Publishing SPF records in your DNS can, therefore, benefit the deliverability of your LISTSERV mail immediately. DomainKeys usage is not as prevalent yet but is gaining ground. Signing LISTSERV messages with DomainKeys most likely offers only limited deliverability increases today, but those benefits should increase as DomainKeys becomes more widespread.

For additional information about SPF, DomainKeys and using the two with LISTSERV, see the References section below.

Notes

[1] For the purposes of this document, examples will focus on SPF and DKIM implementations. While SenderID/SIDF (developed by Microsoft) and DKIM (DomainKeys Identified Mail) exist as alternatives to SPF and DomainKeys (respectively), the function and syntax are nearly identical to the examples given and may be treated as such for LISTSERV's purposes.

[2] Note that SPF version one checks the envelope (RFC 2821) MAIL FROM (and in some cases the HELO/EHLO domain), not the (RFC 822) message body From: line. Microsoft's SenderID (SIDF) implementation does not adhere to the same process; it looks first for a Sender: header and then a From: line in the message body before falling back to the SPF-style RFC 2821 implementation. This means that for optimal delivery to sites using Microsoft's SIDF implementation, it may be necessary to configure your discussion lists with "Sender=List" so that the From: line of the message does not trigger false positives in the SIDF anti-spoofing algorithm.

[3] See domainkeys.sourceforge.net/keygen.html for more details about creating the key pair.

[4] Creating the policy record is beyond the scope of this document, but see dkim.org/specs/draft-allman-dkim-base-01.html for details.

[5] Use this option with caution: in so doing you assume implicit responsibility for the messages that LISTSERV signs, including any spam that may come through a poorly configured or poorly moderated discussion list. Digitally signing and redistributing spam email through your discussion list is sure to cause trouble for your domain!

References

www.lsoft.com/manuals/1.8e/LISTSERV-DKIM-config.html
www.openspf.org/
antispam.yahoo.com/domainkeys
domainkeys.sourceforge.net
en.wikipedia.org/wiki/DomainKeys
en.wikipedia.org/wiki/Sender_Policy_Framework
www.chiark.greenend.org.uk/~sgtatham/putty/download.html
www.openssl.org/
dkim.org/specs/draft-allman-dkim-base-01.html