DMARC Compliant Mailing Lists

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.

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.

List enrollment processes are needed to select an alias for each subscriber and verify that the alias is unique and not previously used. Additioinally, the translation table of actual address to alias address must be published for use by the rewriting gateways.
A new server or function module is necessary to rewrite the From address on messages posted to the list, and then apply a DKIM signature.
A new message flow path is necessary for member-to-member communication using the list alias domain.

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 |->| 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.

| 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.

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.

Any form of aliasing introduces the possibility of identify misrepresentation or identity obfuscation. Misrepresentation neecds to be controlled by the list operator during the enrollment process. Obfuscation may or may not be acceptable, based on the policies and purposes of the mailing list. A thorough discussion of the issues related to digital identity and enrollment can be found in NIST SP-800-63
The proposed design causes list messages to appear as if they are direct messages from the list domain, rather than forwarded messages that passed through the list domain. As a result, the list domain will bear the reputation consequences, if any inappropriate messages are forwarded to the list. The best defense against this risk is for the list domain to perform effective spam filtering.
Subscribers within the list domain should be fully notified of the limitations of the aliasing strategy, and that their identity cannot be fully protected from other subscribers within the list domain.