| Internet-Draft | DMARC Compliant Mailing Lists | October 2021 |
| Foster | Expires 6 April 2022 | [Page] |
Mailing Lists often make changes to a message before it is retransmitted. This invalidates DKIM signatures, causing a DMARC test on the RFC5322.From addres to fail. A DMARC-compliant mailing list is one which uses member alias addresses to identify the document as sent by a specific author via the mechanism of the list. An appropriate aliasing mechanism will not only prevent DMARC FAIL, but will also allow messages between members, will look natural to senders and recipients, and will allow list organization domains to advance to p=reject. This document describes an aliasing approach which meets these goals.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 April 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Mailing Lists often make changes to a message before it is retransmitted. This invalidates DKIM signatures, causing a DMARC test on the RFC5322.From addres to FAIL. This problem has created a standoff between mailing lists and domain owners. Many domains which participate in mailing lists feel unable to publish a DMARC policy other than NONE, even if their messages are fully DMARC-compliant at origination.¶
Some domain owners publish p=reject anyway, creating difficulties for mailing lists if their users subscribe. In some cases, mailing lists allow participation by users from DMARC-enforcing domains by rewriting those RFC5322.From addresses, often by changing author@authordomain to author=authordomain@listdomain. This rewriting mechanism aliases the author into the list domain, which avoids the DMARC FAIL result, but produces other problems.¶
Previous proposals to adddress these problems have required new software logic and new trust configurations for every organization that participates with mailing lists. Under these proposals, success will depend on the list activating the new authentication signals, the evaluator implementing logic to check those signals, the evalautor trusting the list's reputation when the valid signals are present, and the list operator knowing that the evaluator will use the signals to trust list messages. Such an outcome is difficult to achieve on a large scale, so it becomes necessary to seek a solution which is wholely in control of the mailing list operator.¶
A DMARC-compliant mailing list is one which uses a permanent alias addresses for each member. The alias provides subscribers with a stable identifier within a domain controled by the list organization. This identifier is implemented to allow replies to the author address, to look natural to senders and recipients, and to allow participating domains to advance to p=reject. This document describes an aliasing approach which meets these goals.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
Many closed-group communication systems use member identifiers which allow communication between members, without enabling communication outside of the group environment. Examples include social networking products, online games, and web forums. These environments typically have controls which validate member identity, controls which determine whether members can communicate with each other, controls which limit unacceptable content, and administrative monitoring to maintain good order. The closed communication environment serves to minimize any risk assocoated with interacting with strangers.¶
Email mailing lists are a hybrid environment, providing some of the benefits and controls of other group communication systems, but lacking other elements. The benefits include an enrollment which establishes initial identity, sender authentication mechanisms which verify identity at time of submission, content filters which limit inappropriate messages, and list operator involvement to manage problems.¶
On the negative side, mediators that make changes to an author's message arouse suspicion, since any specific change may be helpful, innocuous, cause misrepresentation, or cause harm. Consequently, the existence of an in-transit change means that the reputation of the change agent is more important than the reputation of the originator. This is even more applicable for mediators that can be trusted to have checked source identity, source reputation, and content risk before determining that the message can be forwarded.¶
For the reputation of the mediator to be the focus of attention by mediators which use existing evaluation strategies, the RFC5322.From address must point to the mediator organization and should be signed by the mediator organization. In short, the message must produce DMARC PASS. The purpose of From-rewrite is not to fix a defect in the design of DKIM or DMARC, but rather to point the evaluator to the organization most responsible for the final state of the document.¶
List members are given a permanent alias email address, within the list organization. When list messages are transmitted from the Mailing List Management software (MLM), or between list members, the author's actual email address is rewritten with the author's member alias. When messages are destined to a member alias address, the RFC5321.RcptTo address is rewritten with the member's actual email address. Because the alias email address is registered and permanent, and supported by necessary infrastructure, it can be used for member-to-member communication.¶
For technical reasons, the alias addresses should use a dedicated subdomain within the list organization. A single subdomain could be used for multiple mailing lists, or each list could have its own subdomain, based on organizational preference and technical considerations. For domain example.com, a shared alias domain could be "authoralias@lists.example.com" while a list-specific alias domain could be "authoralias@techtopics.example.com"¶
After a member is unsubscribed, his alias should not be reused, except to reinstate that member, so that there is no identity confusion between past and present subscribers.¶
These features require interoperability between the list enrollment process, where list member aliases are configured, and the mail processing gateways where address replacement occurs.¶
Several infrastructure additions are needed to support the alias implementation.¶
The first diagram illustrates a possible mailing list configuration without aliasing. Messages flow in through the incoming gateway, and are forwarded to the list domain mail store. Mailing List Managerment (MLM) software processes messages for the list address, and replicates accepted messages to all recipients. Both internal and external recipients can be delivered to the mail store for delivery or forwarding. Optionally, list messages may be archived.¶
+----------------+ +-------------+ +--------------+
| List Domain MX |->| List Domain |->| List Domain |
| Inbound Gwy | | Mail Store | | Outbound Gwy |
+----------------+ +-------------+ +--------------+
In | | Out
+----------------+ +--------------+
| Journal/Audit |<-| Mailing List |
| /Archive (opt) | | Manager |
+----------------+ +--------------+|
The second diagram illustrates a possible mailing list configuration after aliasing is enabled. Messages flow in through the incoming gateway, and are forwarded to the list domain mail store. Mailing List Managerment (MLM) software processes messages for the list address, and replicates accepted messages to all recipients. Outbound messages are forwarded to a smarthost server which performs rewriting of the From address, based on an actual-to-alias address translation table published from the MLM. Additionally, a DKIM signature is applied once all rewriting has been completed. Finally, messages are relayed to an appropriate server or gateway for delivery.¶
+---------------------+ +----------------+ +----------+
| List Alias MX |-->| From Address |->| Outbound |
| Inbound Gwy | | Rewrite Server | | Gateway |
| MailFrom-RcptTo chk | +----------------+ +----------+
| Receiver rewrite | |In
| Content Filters | +----------------+
+---------------------+ | Journal/Audit |
| /Archive (opt) |
+----------------+
The third diagram illustrates a possible mailing configuration of the alias domain used for member-to-member messages. The incoming gateway has the most complexity. It validates the sender identity, verifies that the sender actual address and receiver alias addrss are subscribers to a common list, translates the recipient address to an actual address, and performs content filtering. Accepted messages are forwarded to a smarthost server for rewriting of the From address and application of a DKIM signature. This may be the same smarthost server used for outbound messages from the MLM. Based on list owner policy, messages or message characteristics may be captured for audit or archive purposes. Finally messages are relayed to an appropriate server or gateway for delivery.¶
+---------------------+ +----------------+ +----------+
| List Alias MX |-->| From Address |->| Outbound |
| Inbound Gwy | | Rewrite Server | | Gateway |
| MailFrom-RcptTo chk | +----------------+ +----------+
| Receiver rewrite | |In
| Content Filters | +----------------+
+---------------------+ | Journal/Audit |
| /Archive (opt) |
+----------------+
While any aliasing scheme could be rolled out on a limited basis to only some subscribers, the benefits of aliasing are maximized when all members are configured with aliases.¶
As has been well documented, a list without aliasing can encounter problems when the author domain enforces DMARC.¶
Without aliasing, a list message can be easily spoofed by an attacker. The attacker need only know a list to which the victim subscribes, the visual characteristics of the list message, and an RFC5322.From domain which does not enforce DMARC. Incoming email filters will see an SPF PASS based on the attacker domain, and a From domain without DMARC policy. Unless the message is blocked based on attacker domain reputation or content filtering, the spoofed message will be released to the victim. Similarly, the victim recipient will have no visual clues to raise suspicion.¶
Once a list migrates to aliases for all subscribers, list messages will be from the list organization, list messages will earn DMARC PASS, and list-related domains can be protected with DMARC p=reject to ensure that spoofing attempts are hindered. Recipients will have the visual clue that list-related messages always come from a specific domain within the list organization.¶
Some evaluators will filter messages based on the RFC5322.From address. Most commonly, this is used to block addresses from unexpected or untrusted geographies and domains. A mailing list may have a more diverse participation than these filters expect. Without aliasing, some list messages may be blocked by these filters. The subscriber is likely to perceive these missing mesage events as strangely random. Even when the cause is identified, an acceptable resolution may not exist, since the evaluator cannot know the set of all necessary exceptions for all present and future list subscribers.¶
When aliasing is enabled, any filtering performed by the recipient system on the RFC5322.From address will see a list organization domain, rather than an author domain. This helps to ensure that list messages are delivered consistently. If list messages are inappropriately blocked by content filtering, the recipient system manager can safely implement a whitelist rule based on the DMARC-verifiable From domain.¶
Some evaluators will block external messages that claim to be from an internal domain, when the evaluator does not check DMARC or the sender domain does not enforce DMARC. List posts will always generate these bounce-back messages, because the post is relayed back to the author and may also be sent to other subscribers in the same domaion as the author. With aliasing, messages are never be blocked by such filters, because list-related messages will always be from the list organization, not the author's organization.¶
If a message is inappropriately blocked for any of the above reasons, the mailing list management software may detect the block as a reason to disable the recipient account from future deliveries. By avoiding false blocks, the list also avoids false account suspensions.¶
When a user chooses "Reply All" to a list msessage, the author receives one copy to his own address and one copy from the list expansion. With aliasing, the incoming gateway will see both names, and can optionally be configured to suppress the duplication.¶
When an alias name is registered, the subscription process could also collect a Friendly Name to use along with the alias name. When an RFC5322.From address is replaced with an alias, the registered Friendly Name could be inserted as well. This standardization may help avoid subscriber reconfiguration of the Friendly Name to insert content that is objectionable, or misleading.¶
Mailing lists are intended to be a closed group. By using aliases, membership in the group is verified by the alias domain address. When a user leaves a group, he loses the ability to send messages to list members using their member alias, and list members lose the ability to contact him using his member alias address. In most cases, the alias will be the only address that other members know. Actual addresses may be leaked in message headers, but they are not published explicitly in the From address.¶
Upon evidence satisfactory to the list owner, a subscriber can migrate to a new primary mailing account while preserving his member alias, and thereby retain his identity within the mailing list.¶
This memo includes no request to IANA.¶