13.3 How does LISTSERV comply with DMARC?
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 containing "p=reject" or "p=quarantine". There is nothing to configure, it is done automatically. If additional ISPs (besides Yahoo.com and AOL.com) decide to implement either the "p=reject" or "p=quarantine" rule, LISTSERV will automatically detect this and adjust its behavior accordingly.
As we have already noted in the previous section, the DHS BOD 18-01 requires US federal executive branch agencies to implement "p=reject", so all such agencies which have complied with the directive to date will be automatically covered as well.
Note: LISTSERV also rewrites addresses for hosts with "p=quarantine" because the definition of "p=quarantine" is unclear, but seems to all but guarantee messages from users at those hosts will end up in recipients' spam folders if the From: address is not rewritten. What does a "quarantine" policy mean in a DMARC record? Given the real-world, non-technical use of the term, quarantine means "set aside for additional processing". The definition is at the appreciation of the manager of the receiving email infrastructure. It may mean deliver to the "junk folder" but it may also mean hold in a database for further review by dedicated personnel, or simply add a specific tag to the message before delivery. Because this definition is unclear, and there is no mechanism available for LISTSERV to obtain further information regarding how a specific host implements the quarantine, L-Soft made the design decision to treat "p=quarantine" identically to "p=reject". |
If the message comes from such a domain, LISTSERV rewrites the "From:" address to the format
[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, it is routed back to LISTSERV, which forwards it to the original "From:" address. The token is unique to each sender and only works via the same LISTSERV instance.
Best of all, there is no need for anyone to change their habits and/or their mail folder filing rules for incoming mail.
It should be noted this is not a "full" implementation of DMARC as LISTSERV does not attempt to validate SPF records in DNS, nor does it attempt to verify DKIM signatures from any sending domains. It simply looks for a "p=reject" or "p=quarantine" in the originating domain's DMARC record, and automatically processes the From: address accordingly.
This is what it 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-re-written address will be written to the list message archives files, if any. This keeps message threading and searching just like it was before. The original non-re-written 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.