Find Out How LISTSERV Can Help You Comply with DMARC Requirements

By Nathan Brindle
Senior Product Engineer, L-Soft

The recent issuance of the U.S. BOD 18-01 includes in its checklist for compliance a requirement for U.S. government agencies to implement the DMARC p=reject policy for all second-level domains and mail-sending hosts no later than October 16, 2018.

Implementation of this aggressive DMARC policy can and will create problems for U.S. government agencies that are running LISTSERV versions older than 16.0-2014b.

To properly comply with BOD 18-01, L-Soft recommends that all such affected agencies should upgrade to LISTSERV 16.0-2017a, the latest release version. This is a free upgrade for agencies with a current LISTSERV maintenance contract.

Background

In mid-2014, Yahoo, followed by AOL, implemented aggressive DMARC authentication policies that caused severe problems for email list operators. This was due to the fact that a mailing list manager such as LISTSERV cannot authenticate "foreign" mailing list postings being distributed on the outbound side because the mailing list manager has no authority to do so for any mail other than that which comes from its own domain and is covered by its domain's DMARC record in DNS. At the time, DMARC was still rather new, and adoption of DMARC at any level was not guaranteed, which made the situation even worse.

The solution that L-Soft developed for LISTSERV does not require anyone to make compromises or lose any functionality – not even the Yahoo and AOL subscribers.

When LISTSERV receives a posting to a mailing list, it queries DNS to see if the sending domain in the "From" address has a DMARC record configured with p=reject. There is nothing to configure. LISTSERV performs this query automatically. Because of this, LISTSERV will automatically detect the existence of the p=reject rule for any given domain and will adjust its behavior accordingly.

If the message comes from a domain using p=reject, LISTSERV rewrites the "From" address to token-dmarc-request@LISTSERV.EXAMPLE.COM (see example below). The poster's full name is left unchanged. Most mail clients do not show the actual address, only the name, so most users will not see any obvious difference.

If a list member decides to send a private reply to the sender (i.e. not to the list) via the re-written special address, LISTSERV receives it and forwards it to the original "From" address. The token is unique to each sender and works only via the same LISTSERV instance on which it was generated. Thus there is no need for anyone to change their habits and their mail folder filtering rules for incoming mail.

This is what the process looks like in the LISTSERV log file:

The original, non-rewritten address will be written to the list message archive files. This makes message threading and searching just like it was before. The original non-rewritten address will also be written to the Reply-To message header line if the list is configured for Reply-To= Sender or Reply-To= Both.

On Windows, handling of the tokenized forwarding address is automatic. On Unix platforms, admins will need to implement a wildcard alias for *-request@ email addresses. L-Soft support has published suggestions for this for Postfix and sendmail.

The TRACE_DNS Debugging Flag

The TRACE_DNS debug flag is useful for debugging problems with DMARC lookups from LISTSERV, as in conjunction with the DEBUG QUERY TXT hostname command, it can show you exactly what information LISTSERV is receiving (or not receiving) from its DNS servers.

To use the feature, issue the LISTSERV administrator command DEBUG FLAGS +TRACE_DNS. For instance:

Next, enter the command DEBUG QUERY TXT hostname with whatever hostname is configured in DNS with the DMARC TXT record that LISTSERV should be referencing.

If there is no DMARC record for the hostname you specify, the response will be different:

Finally, turn off the debug flag:

These example commands were issued from the LISTSERV command line. Note that the commands may also be issued by email or through the "LISTSERV Command" screen of the web interface.

Questions? Please feel free to contact our technical support group at support@lsoft.com.

Tip: For more information regarding DMARC and how to publish a DMARC record in your organization's DNS zone file, please see the official DMARC site. Note that in order to make DMARC work properly, you must deploy appropriate SPF and DKIM records as well.

Subscribe to LISTSERV at Work.