LISTSERV at Work
Tweet This

Find Out How LISTSERV Can Help You Comply with DMARC Requirements

DMARC Support in LISTSERV

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:

>21 Apr 2014 12:21:56 Processing mail from user@YAHOO.COM for TEST2
>21 Apr 2014 12:21:56 "From:" address rewritten due to p=reject DMARC rule
>> Old address: user@YAHOO.COM
>> New address: 00000003f16b4808-dmarc-request@LISTSERV.EXAMPLE.COM
>21 Apr 2014 12:22:36 From MAILER@LISTSERV. EXAMPLE.COM: X-ADMMAIL 00000003f16b4808-dmarc-request@LISTSERV.EXAMPLE.COM
>21 Apr 2014 12:22:36 -> Forwarded to user@YAHOO.COM

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:

Paused - enter a command:
debug flags +trace_dns
1 Feb 2017 15:10:05 From LISTSERV@LISTSERV.EXAMPLE.COM: debug flags +trace_dns
* Debug flags for this session: 00000200
*
00000001 TRACE_DIST       [Trace DISTRIBUTE processing - OFF]
00000002 TRACE_MIME       [Trace MIME parser - OFF]
00000004 TRACE_LISTS      [Trace (a few) list-related functions - OFF]
00000008 TRACE_SPAM       [Trace spam filter calls - OFF]
00000010 TRACE_EMM        [Trace Embedded Mail-Merge processor - OFF]
00000020 TRACE_DEV        [Temporary ad hoc tracing for development use - OFF]
00000040 TRACE_FSAV       [Trace FSAV calls - OFF]
00000080 TRACE_LDAP_CALLS [Trace LDAP library calls - OFF]
00000100 TRACE_LDAP_DATA  [Trace data obtained from LDAP - OFF]
00000200 TRACE_DNS         Trace DNS lookups
08000000 HOLD_DISTBG      [Do not process background DISTRIBUTE jobs - OFF]
10000000 HOLD_XB64        [Hold X-B64 jobs instead of processing them - OFF]
20000000 KEEP_JOBFILES    [Keep successfully processed job files - OFF]
40000000 TRACE_TCPGUI     [Additional TCPGUI tracing - OFF]

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.

Paused - enter a command:
debug query txt _dmarc.yahoo.com
1 Feb 2017 15:10:43 From LISTSERV@LISTSERV.EXAMPLE.COM: debug query txt
_dmarc.yahoo.com
1 Feb 2017 15:10:43 DBG> Looking up TXT records for _DMARC.YAHOO.COM
1 Feb 2017 15:10:43 DBG> Trying 8.8.8.4
1 Feb 2017 15:10:43 DBG> One record found
* _DMARC.YAHOO.COM IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"

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

1 Feb 2017 15:21:37 DBG> Looking up TXT records for _DMARC.EXAMPLE.COM
1 Feb 2017 15:21:37 DBG> Trying 8.8.8.4
1 Feb 2017 15:21:37 DBG> No record found
* DNS query for _DMARC.EXAMPLE.COM returned no TXT record.

Finally, turn off the debug flag:

Paused - enter a command:
debug flags -trace_dns
1 Feb 2017 15:11:00 From LISTSERV@LISTSERV.EXAMPLE.COM: debug flags -trace_dns
* Debug flags for this session: 00000000
*
* 00000001 TRACE_DIST       [Trace DISTRIBUTE processing - OFF]
* 00000002 TRACE_MIME       [Trace MIME parser - OFF]
* 00000004 TRACE_LISTS      [Trace (a few) list-related functions - OFF]
* 00000008 TRACE_SPAM       [Trace spam filter calls - OFF]
* 00000010 TRACE_EMM        [Trace Embedded Mail-Merge processor - OFF]
* 00000020 TRACE_DEV        [Temporary ad hoc tracing for development use - OFF]
* 00000040 TRACE_FSAV       [Trace FSAV calls - OFF]
* 00000080 TRACE_LDAP_CALLS [Trace LDAP library calls - OFF]
* 00000100 TRACE_LDAP_DATA [Trace data obtained from LDAP - OFF]
* 00000200 TRACE_DNS        [Trace DNS lookups - OFF]
* 08000000 HOLD_DISTBG      [Do not process background DISTRIBUTE jobs - OFF]
* 10000000 HOLD_XB64        [Hold X-B64 jobs instead of processing them - OFF]
* 20000000 KEEP_JOBFILES    [Keep successfully processed job files - OFF]
* 40000000 TRACE_TCPGUI     [Additional TCPGUI tracing - OFF]

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.

© L-Soft 2018. All Rights Reserved.




Powered by LISTSERV Maestro