NOTE: The following document was created by individuals collaborating to integrate DMARC support into the MailMan 2 codebase, and which subsequently appeared in version 2.1.16. It is included here with permission of said individuals as supplemental material around the use of DMARC and mailing list software.

This document was not produced or endorsed by DMARC.org, and is offered for informational purposes only.


DRAFT: Requirements Doc for MLM Patches to Support Basic DMARC Compliance


Introduction:

The DMARC specification relies on the domain portion of the "address-spec" found in the 5322.From header.  This is the primary policy key used to tie SPF and DKIM results to the content of an email.  Although DMARC is largely a drop-in solution that provides Domain Owners a degree of control over how their Domains are used in email, mailing lists often break DMARC by using the email addresses of posters to the list.

Problem statement:

To preserve the identity of people authoring and distributing email via mailing lists, Mailing List Management software (MLMs) often leave the 5322.From intact when re-sending posts to the list.  When mailbox receivers then attempt to use DMARC to validate the authenticity of such email, the domain found in the 5322.From header might publish a DMARC record that instructs receivers to reject non-authenticated messages such as those sent by the MLM.  This can be due to SPF failing (or yielding an authenticated domain identifier that is not related to the domain found in the 5322.From header) and DKIM signatures failing (due to email content modification such as the insertion of footers and/or mailing list headers).  This causes problems for Domain Owners who deploy DMARC when their domain is used by participants of mailing lists.

Solution statement:

MLM operators have expressed a willingness to interoperate with DMARC-based controls, but need an easy upgrade path to mail list software that can interoperate automatically with DMARC.  Operators are willing to set configuration options, but cannot be expected to go beyond "set and forget" solutions.

The simplest solution for DMARC compliance is to ensure that the "address-spec" in the RFC5322.From header is that of the mailing list, rather than using the address of the poster.  At the same time, the MLM should preserve the displayed identity of the poster to the list without including their full email address.  This can be accomplished by modifying the RFC5322.From "display name" before the message is sent to mailing list subscribers.



Requirements:

The primary requirement is to allow MLM operators an easy way to upgrade existing software packages to turnkey DMARC compliance.  Additional features other than are required for basic DMARC compliance are out of scope.

Basic DMARC compliance in this context means that MLM software must not send messages with an email address of a poster to the list within the RFC5322.From header.

The RFC5322.From header for email sent through a mailing list must be of the form:

    "[Display Name] via [List Name]" <[List Email Address]>

The MLM can populate the fields according to:

  1. "Display Name" which may be:
    1. the concatenation of the "First Name" and "Last Name" fields, if they exist in the MLM software, or
    2. the "Full Name" field, if it exists in the MLM software, or
    3. the RFC5322.From "display name" from the posted message (unless it is an email address), or
    4. the local part of the RFC5322.From "address-spec" from the posted message.
  2. "List Name" which may be:
    1. the full discussion list name, or
    2. an abbreviated list name, if available in the MLM software.
  3. "List Email Address" is the address of the list itself.

NOTE: The inclusion of more than one domain in the RFC5322.From field is dangerous.  Recent studies by two major senders show that ~95% of all cases in which there is one domain in the RFC5322.From "display name" and different domain in the RFC5322.From "address-spec" are fraudulent.  This practice should be discouraged as there are efforts underway to increase "spam scores" within inbound filtering when this is detected.  The MLM documentation should provide guidance on display name abuse when the administrator activates "DMARC Compatibility Mode".

Examples:

BAD: "Jane Smith via DMARC.org" <mailinglist@dmarc.listser ver.com>

BAD: "jane@example.com via DMARC" <mailinglist@dmarc.listser ver.com>

BAD: "jane (example.com) via DMARC"  <mailinglist@dmarc.listser ver.com>

GOOD: "John Doe via DMARC Mailing List" <mailinglist@dmarc.org>

GOOD: "Jane Smith via DMARC" <mailinglist@dmarc.listser ver.com>

GOOD: "honeybear95 via DMARC" <mailinglist@dmarc.org>
(where the poster of the message is "honeybear95@example.com")


Replying to the post

Mailing lists usually offer three possibilities:

  1. to reply to the poster
  2. to reply to the list
  3. to reply to a specific email address

Currently, in case of [2] and [3] the reply-to header is used. Because of this specification the poster email address is not anymore available, it is therefore suggested in order to keep all these options valid to add the email address of the poster to the reply-to: field after normal processing.

For instance in the case of [1],[2],[3] respectively:
  1. Reply-To: "John Doe" <john@example.com>
  2. Reply-To: "John Doe" <john@example.com>, "DMARC Mailing list" <mailinglist@dmarc.listser ver.com>
  3. Reply-To: "John Doe" <john@example.com>, "DMARC Mailing list" <replytothislist@dmarc .listserver.com>

Note on DKIM, DK, and authentication headers:

It is not necessary to remove such headers from the list post. It is perfectly normal to have multiple of such headers in an email message, the invalid ones are considered as non existent by the receiver software but provide clues for the human on the path of the post. It is expected that the Mail Server (MTA) where the Mailing List reside will add proper DKIM headers using the keys associated with the Mailing list domain before sending the email to the final recipients.

Note on the Sender field:

The sender field that may be present in the poster email, should be treated as usual by the Mailing List software. This specification does not indicate a modified usage.