L-Soft international, Inc.




Using LISTSERV® with DomainKeys







February 2006

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. L-Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document.


Permission is granted to copy this document, at no charge and in its entirety, provided that the copies are not used for commercial advantage, that the source is cited and that the present copyright notice is included in all copies, so that the recipients of such copies are equally bound to abide by the present conditions. Prior written permission is required for any commercial use of this document, in whole or in part, and for any partial reproduction of the contents of this document exceeding 50 lines of up to 80 characters, or equivalent. The title page, table of contents and index, if any, are not considered part of the document for the purposes of this copyright notice, and can be freely removed if present.


Copyright © 2005-2006, L-Soft international, Inc.

All Rights Reserved Worldwide.


LISTSERV is a registered trademark licensed to L-Soft international, Inc.

L-SOFT is a trademark of L-Soft international.

LSMTP is a registered trademark of L-Soft international, Inc.

UNIX is a registered trademark of X/Open Company Limited.

Microsoft is a registered trademark and Windows 2000, Windows 2003, Windows, Windows NT and Windows XP are trademarks of Microsoft Corporation.

All other trademarks, both marked and not marked, are the property of their respective owners.


Some of L-Soft's manuals for LISTSERV are available in ASCII-text format from LISTSERV and in PDF at ftp.lsoft.com. Many are also available on the World Wide Web at http://www.lsoft.com/manuals/index.html


L-Soft invites feedback on its manuals. Please feel free to send your comments by

Using LISTSERV® with DomainKeys


Last update: 28 Feb 2006



Creating DomainKeys RSA keys and configuring DNS

LISTSERV Configuration

Starting LISTSERV with DomainKeys support

Using DomainKeys with LISTSERV



DomainKeys support requires LISTSERV 14.5.


In order for DomainKeys support to work, we further assume that



DomainKeys support is available for LISTSERV Classic and HPO, on all operating systems except for VM. It is not available in LISTSERV Lite.

Creating DomainKeys RSA keys and configuring DNS


The following is an excerpt from the controlling Internet Draft for DomainKeys.


3.2.2 Public-key signing and verification algorithm
The default signature is an RSA signed SHA1 digest of the complete
For ease of explanation, the openssl command is used throughout this
document to describe the mechanism by which keys and signatures are
One way to generate a 768 bit private-key suitable for DomainKeys, is
to use openssl like this:
$ openssl genrsa -out rsa.private 768
Which results in the file rsa.private containing the key information
similar to this:
To extract the public-key component from the private-key, use openssl
like this:
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
Which results in the file rsa.public containing the key information
similar to this:
-----END PUBLIC KEY-----
This public-key data is placed in the DNS.
3.2.3 Public-key representation in the DNS
There is currently no standard method defined for storing public-keys
in the DNS. As an interim measure, the public-key is stored as a TXT
record derived from a PEM format [PEM], that is, as a Base64
representation of a DER encoded key. Here is an example of a 768 bit
RSA key in PEM form:
-----END PUBLIC KEY-----
To save scarce DNS packet space and aid extensibility, the PEM
wrapping MUST be removed and the remaining public-key data along with
other attributes relevant to DomainKeys functionality are stored as
tag=value pairs separated by semicolons, e.g.:
brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048
bits. Signers MUST support at least one of the verifier supported key
The current valid tags are:
    g = granularity of the key. If present with a non-zero length
        value, this value MUST exactly match the local part of the
        sending address. This tag is optional.
        The intent of this tag is to constrain which sending address
        can legitimately use this selector. An email with a sending
        address that does not match the value of this tag constitutes
        a failed verification.
    k = key type (rsa is the default). Signers and verifiers MUST
        support the 'rsa' key type. This tag is optional.
    n = Notes that may be of interest to a human. No interpretation is
        made by any program. This tag is optional.
    p = public-key data, encoded as a Base64 string. An empty value
        means that this public-key has been revoked. This tag MUST be
    t = a set of flags that define boolean attributes. Valid
        attributes are:
        y = testing mode. This domain is testing DomainKeys and
            unverified email MUST NOT be treated differently from
            verified email. Recipient systems MAY wish to track
            testing mode results to assist the sender.)
        This tag is optional.

LISTSERV Configuration


LISTSERV's DomainKeys support is configured by doing two things.

1. Supply one or more private keys.


Each private key is stored as a text file in LISTSERV's main or home directory (that is, the directory where the *.list files are) and must be named xxx.dkim, where xxx is the arbitrary name you choose to give the key. If you only use one key, it is recommended to name it default.dkim.


The file is created in the usual openssl/RSA format, with one minor modification. Here is an example:


d=example.com; s=test







The first line in the file must include a specification for the 'd=' and 's=' parameters of the DomainKeys signature (in whatever order, as long as they are both there). Per the controlling Internet Draft for DomainKeys, these variables specify the domain for which you are signing ("d=") and the "selector" that is used to form the query for the public key ("s=").  For instance, let’s say that your public key is registered as follows in the DNS:


brisbane._domainkey.example.com IN TXT "t=y; g=; k=rsa; p=MHww ... IDAQAB"


The domain would then be d=example.com, and the selector would be s=brisbane.


Please see the DomainKeys documentation for more information.


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!

2. Supply a DKIM_SIGN configuration variable.


In your site configuration file, add a DKIM_SIGN= variable containing a blank-separated list of domains that you are able and willing to sign for. You can use wildcards, but only of the form '*.EXAMPLE.COM'. You can't use, for instance, 'SALES.EXAMPLE.*'. For each entry in the list, specify the key to be used, as follows:




(Under unix, don't forget to export DKIM_SIGN .)


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.

Starting LISTSERV with DomainKeys support


LISTSERV loads the keys at startup and makes simple verifications.


8 Dec 2005 12:07:42 Loading DomainKeys private keys...

8 Dec 2005 12:07:42 -> Loaded DEFAULT (d=EXAMPLE.COM; s=TEST; RSA-768)

8 Dec 2005 12:07:42 -> Loaded CA (d=EXAMPLE.CA; s=TEST; RSA-768)

8 Dec 2005 12:07:42 DomainKeys support enabled


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.

Using DomainKeys with LISTSERV

With mailing lists


·         If DomainKeys support has been enabled in the configuration, LISTSERV will sign all outbound messages for mailing lists, including administrative messages, welcome messages, etc.




If desired, either or both options can be specified for all lists via the DEFAULT_MISC_OPTIONS= site configuration variable.



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.

Signing other types of messages


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:












Restrictions and implementation choices



Note that in LISTSERV 14.5, 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.


*end of document*