RFC 6377

DomainKeys Identified Mail (DKIM) and Mailing Lists

📅 published September 2011, from ietf

Part 1 of 6 💖

okay bestie, this is RFC 6377 🦋, titled "DomainKeys Identified Mail (DKIM) and Mailing Lists." It was written by M. Kucherawy from Cloudmark ✨ and published in September 2011 as a Best Current Practice 💅 (that makes it BCP 167, ISSN 2070-1721). Its header doesn't list anything it obsoletes or updates, so no drama there 🙈

Abstract

DomainKeys Identified Mail (DKIM) lets an ADministrative Management Domain (ADMD) take on some responsibility for a message 📬. Based on what people have learned from actually deploying DKIM, this document gives guidance on using DKIM in scenarios that involve Mailing List Managers (MLMs) 🌸.

Status of This Memo

This memo documents an Internet Best Current Practice 🎀.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 and it got public review before the Internet Engineering Steering Group (IESG) approved it for publication. For more on BCPs, check Section 2 of RFC 5741 🧚.

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6377 💜.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  MLMs in Infrastructure . . . . . . . . . . . . . . . . . .  4
     1.3.  Feedback Loops and Other Bilateral Agreements  . . . . . .  5
     1.4.  Document Scope and Goals . . . . . . . . . . . . . . . . .  6
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Messaging Terms  . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  DKIM-Specific References . . . . . . . . . . . . . . . . .  6
     2.4.  'DKIM-Friendly'  . . . . . . . . . . . . . . . . . . . . .  7
     2.5.  Message Streams  . . . . . . . . . . . . . . . . . . . . .  7
   3.  Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Roles and Realities  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Types of Mailing Lists . . . . . . . . . . . . . . . . . .  8
     3.3.  Current MLM Effects on Signatures  . . . . . . . . . . . . 10
   4.  Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Author-Related Signing . . . . . . . . . . . . . . . . . . 12
     4.2.  Verification Outcomes at Receivers . . . . . . . . . . . . 12
     4.3.  Handling Choices at Receivers  . . . . . . . . . . . . . . 13
     4.4.  Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
   5.  Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  DKIM Author Domain Signing Practices . . . . . . . . . . . 14
     5.3.  Subscriptions  . . . . . . . . . . . . . . . . . . . . . . 15
     5.4.  Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
     5.5.  Author-Related Signing . . . . . . . . . . . . . . . . . . 16
     5.6.  Verification Outcomes at MLMs  . . . . . . . . . . . . . . 16
     5.7.  Signature Removal Issues . . . . . . . . . . . . . . . . . 17
     5.8.  MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
     5.9.  Verification Outcomes at Final Receiving Sites . . . . . . 20
     5.10. Use with FBLs  . . . . . . . . . . . . . . . . . . . . . . 20
     5.11. Handling Choices at Receivers  . . . . . . . . . . . . . . 21
   6.  DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
     7.1.  Security Considerations from DKIM and ADSP . . . . . . . . 22
     7.2.  Authentication Results When Relaying . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 25
   Appendix B.  Example Scenarios . . . . . . . . . . . . . . . . . . 25
     B.1.  MLMs and ADSP  . . . . . . . . . . . . . . . . . . . . . . 25
     B.2.  MLMs and FBLs  . . . . . . . . . . . . . . . . . . . . . . 25

1. Introduction ✨

DomainKeys Identified Mail [DKIM] lets an ADministrative Management Domain (ADMD) take some responsibility for a [MAIL] message 💌. That responsibility can be taken by an Author's organization, an operational relay (Mail Transfer Agent, or MTA), or one of their agents. The claim is made with a cryptographic signature 🔐. Messages travel from the Author to the recipient through relays that usually don't make any big changes to the content, so the DKIM signature stays valid 🦋.

Intermediaries are a different story 👀. Mailing List Managers (MLMs) actively take delivery of messages, reformat them, and repost them, which often invalidates DKIM signatures 💔. The goal of this document is to explore using DKIM in scenarios with intermediaries and to recommend best current practices based on what has been learned. The questions it digs into include:

Under what circumstances is it advisable for an Author, or its organization, to apply DKIM to mail sent to mailing lists?
What are the trade-offs regarding having an MLM verify and use DKIM identifiers?
What are the trade-offs regarding having an MLM remove existing DKIM signatures prior to reposting the message?
What are the trade-offs regarding having an MLM add its own DKIM signature?

These are open questions, and there may be no definitive answers 🤷‍♀️. Still, based on experience since the original version of [DKIM] was published and started being deployed gradually, there are some views worth considering and some recommended procedures 🌈.

There are two categories of MLMs in relation to DKIM: participating and non-participating 🎀. Each type has its own issues with DKIM-signed messages that they handle, produce, or both, so each gets its own section.

The best general recommendation for dealing with MLMs is that the MLM, or an MTA in the MLM's domain, applies its own DKIM signature to each message it forwards, and that assessors on the receiving end take the MLM's domain signature into account when they make their assessments. (See Section 5, especially Section 5.2.) We get that this isn't always possible or practical, and it might not always be enough, so this document also provides additional guidance 💅.

1.1. Background

DKIM signatures let an agent of the email architecture (see [EMAIL-ARCH]) claim responsibility for a message by attaching a validated domain-level identifier to it as it passes through a relay 🧚. Although that's not the only option, it most commonly happens as a message passes through a boundary Mail Transport Agent (MTA) leaving an ADministrative Management Domain (ADMD) and heading out across the open Internet 🌍.

A DKIM signature fails to verify if any part of the message covered by one of its hashes gets altered 😭. MLMs commonly alter messages to add information specific to the mailing list they serve. Common modifications are listed and described in Section 3.3. Be warned, though: MLMs vary wildly in behaviour, and they often let subscribers pick individual behaviours 🙈. On top of that, the MTA might make changes that have nothing to do with the MLM's changes.

The DKIM Signatures specification [DKIM] deliberately refuses to tie the signing domain (the "d=" tag in a DKIM signature) to any other identifier in a message. Any ADMD that handles a message can sign it, no matter where it came from or what its Author domain is 🌸. In particular, DKIM doesn't give any meaning to a match between the content of a "d=" tag and, for example, a domain name in the RFC5322.From field, and there isn't any obvious loss of value when they don't match either 🤔. Since any DKIM signature is only an assertion of "some" responsibility by an ADMD, a DKIM signature added by an MLM has no more or less meaning than a signature with any other "d=" value 💖.

1.2. MLMs in Infrastructure

An MLM is an autonomous agent that takes delivery of a message and can repost it as a new message, or bundle it into a digest along with other messages for the list's members (see [EMAIL-ARCH], Section 5.3) 📮. Here's the tea: in the non-digest case, the RFC5322.From field of the reposted message is usually the same as the original's, and recipients see it as "from" the original Author instead of the MLM 😳. That creates confusion about responsibility and autonomy for the reposted message, and it has big implications for how DKIM gets used.

Section 3.3 covers some things MLMs commonly do that produce broken signatures, which lowers the perceived value of DKIM 📉.

Also, while there are published standards for MLM behaviour (e.g., [MAIL], [LIST-ID], and [LIST-URLS]), adoption has been spotty at best 🥲. So efforts to specify DKIM use in the context of MLMs need to be incremental and value-based 🍓.

Some MLM behaviours are well established, and their effects on DKIM signature validity can be argued to frustrate wider DKIM adoption. Still, those behaviours are not standards violations. So this memo specifies practices for all parties involved, while defining the minimum changes possible to the MLMs themselves 🫶.

A DKIM signature on a message expresses some responsibility for the message taken by the signing domain. One open issue this document addresses is how a signature might be used by a recipient's evaluation module after the message has gone through a mailing list and may or may not have been rendered invalid 🔍. The document also considers how that invalidation might have happened 🧐.

Quick note: where this document talks about an MLM validating DKIM signatures or Author Domain Signing Practices ([ADSP]) policies, the validation could actually be done by the MTA or an agent attached to it, with the results relayed over a trusted channel that isn't specified here. See [AUTH-RESULTS] for more on that 🎀. This document doesn't favour any particular arrangement of these agents over another. It just talks about the MLM doing the work itself, because it's simpler 👑.

1.3. Feedback Loops and Other Bilateral Agreements

A Feedback Loop (FBL) 💌 is a bilateral agreement between two parties to swap abuse reports. Typically, a sender signs up with a receiving site to get abuse reports from that site about mail coming from the sender. Iconic behavior, honestly 🫶

An FBL reporting address (aka the address where FBL reports get sent) is part of this bilateral registration. Some FBLs require DKIM use by the registrant. Wild, right? 👀

See Section 6 for additional discussion. 📖

FBLs tend to use the [ARF] or the [IODEF] formats. 🦋

1.4. Document Scope and Goals

Okay so this document talks through the issues above to make the way DKIM and MLMs interact way smoother 🌸 The general vibe is that changes should happen at the Signer and Verifier, not at the MLM. ✨

Wherever possible, the discussion of MLMs is kept conceptually separate from MTAs, even though the two are super tightly integrated in a lot of implementations. This is on purpose, to show that MLM services and responsibilities are functionally independent from an MTA's. Main character energy for MLMs 💅

Some parts of this document explore possible changes to common practice by Signers, Verifiers, and MLMs. The suggestions are mostly predictive, based on the current email infrastructure, what DKIM can do as it gets more widely deployed, and working group consensus. Ngl, there's no real implementation history backing these up yet, and their efficacy, performance, and security characteristics haven't been fully explored. So take them as ideas, not gospel 🧚

2. Definitions

2.1. Key Words

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 🔑

2.2. Messaging Terms

See [EMAIL-ARCH] for a general description of the current messaging architecture and for definitions of various terms used in this document. It's the glossary bestie you didn't know you needed 📚

2.3. DKIM-Specific References

Readers are encouraged to get familiar with [DKIM] and [ADSP], which are the core spec documents, plus [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT], which are DKIM's main tutorial docs. Read these first, trust me 🎀

2.4. 'DKIM-Friendly'

The term "DKIM-friendly" describes an email intermediary that, when handling a message, makes no changes that cause valid [DKIM] signatures on the message at input to fail to verify on output. Slay if you can keep that promise 💖

Lowkey, a lot of MTA and MLM features that users find helpful have side effects that do make DKIM signatures unverifiable. Those don't get the label. 💀

2.5. Message Streams

A "message stream" is a group of messages coming from within an ADMD that differ in intent, origin, and/or use. It splits them up somehow (for example, by changing the value of the "d=" tag in the context of DKIM) so they stay tied to users but are still distinct when Verifiers or Receivers evaluate and handle them. Basically, sorting the mail into separate lanes 🛣️✨

A good example is user mail from a company's employees versus operational or transactional mail from automated sources, or marketing or sales campaigns. Each of these could have different sending policies, or you might want to insulate one from the others. For instance, if a marketing campaign gets reported by lots of spam filters, the marketing stream's reputation could tank without automatically punishing the transactional or user streams. Nobody gets caught in the crossfire 🙈

3. Mailing Lists and DKIM

It's important to make some distinctions between the different styles of intermediaries, how they're typically implemented, and the effects they have in a DKIM-aware environment. Let's get into it 💜

3.1. Roles and Realities

Across DKIM activities, there are several key roles in a message's transit. Most are defined in [EMAIL-ARCH], but they're reviewed here for quick reference 🔍

Author: The agent that provided the content of the message being sent through the system. The Author hands that content to the Originator to kick off the message's journey to its intended final recipients. The Author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). ✍️
Originator: The agent that accepts a message from the Author, makes sure it conforms to relevant standards such as [MAIL], and then sends it on toward its destination(s). This is often called the Mail Submission Agent (MSA). 📮
Signer: Any agent that attaches one or more DKIM signature(s) to a message on its way to its ultimate destination. There's typically a Signer running at the MTA that sits between the Author's ADMD and the general Internet. The Originator and/or Author might also be a Signer. 🖊️
Verifier: Any agent that does DKIM signature validation. One is typically running at the MTA that sits between the public Internet and the Receiver's ADMD. Any agent that handles a signed message can do verification, but this document only considers that action and its outcomes either at an MLM or at the Receiver. Filtering decisions could be made by this agent based on verification results. 🕵️‍♀️
Receiver: The agent that is the final transit relay for the message and does final delivery to the recipient(s). Filtering decisions based on results made by the Verifier could be applied by the Receiver. The Verifier and the Receiver could be the same agent. This is sometimes the same as, or coupled with, the Mail Delivery Agent (MDA). 📬

In simple user-to-user mail, these roles are pretty straightforward. But when you send to a list and the mail gets relayed to all of that list's subscribers, the roles get blurry for the average user, since particular agents can hold multiple important but separable roles. The definitions above are here so we can talk about the mechanisms more precisely 🧠

3.2. Types of Mailing Lists

There are four common MLM implementation modes:

aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one that makes no changes to the message itself as it redistributes. Any modifications are limited to changes to the [SMTP] envelope recipient list (RCPT commands) only. There are no changes to the message header or body at all, except for the addition of [MAIL] trace header fields. The output of such an MLM is considered a continuation of the Author's original message transit. An example is an address that expands directly in the MTA, like a list of local system administrators used for relaying operational or other internal-only messages. See also Section 3.9.2 of [SMTP]. 🪞
resending: A resending MLM (see Sections 5.2 and 5.3 of [EMAIL-ARCH]) is one that may make changes to a message. The output of such an MLM is considered a new message; delivery of the original was completed before the reposted message was distributed. These messages are often reformatted, such as with list-specific header fields or other properties, to make discussion easier among list subscribers. 🔁
authoring: An authoring MLM is one that creates the content being sent as well as starting its transport, rather than basing it on one or more messages received earlier. This is not a "mediator" in terms of [EMAIL-ARCH] since it originates the message, but after creation, its message processing and posting behavior otherwise match the MLM paradigm. Typically, replies are not generated, or if they are, they go to a specific recipient and not back to the list's full set of recipients. Newsletters and bulk marketing mail are examples. 📰
digesting: A special case of the resending MLM is one that sends a single message made of an aggregation of recent MLM submissions, which might be a message of [MIME] type "multipart/digest" (see [MIME-TYPES]). This is obviously a new message, but it may contain a sequence of original messages that may themselves have been DKIM-signed. Digest energy 🗂️

In the rest of this document, we distinguish two relevant steps, corresponding to the following SMTP transactions:

MLM Input: Originating user is Author; originating ADMD is Originator and Signer; MLM's ADMD is Verifier; MLM's input function is Receiver.
MLM Output: MLM (sending its reconstructed copy of the originating user's message) is Author; MLM's ADMD is Originator and Signer; the ADMD of each subscriber of the list is a Verifier; each subscriber is a Receiver.

Much of this document focuses on the resending class of MLM, since it has the most direct operational conflict with DKIM 😤

Splitting the whole MLM operation into these two phases lets the DKIM-specific MLM issues get isolated and handled in a logical way. The main issue is that when an MLM repackages and reposts a message, it's actually building a completely new message. So the MLM is introducing new content into the email ecosystem, consuming the Author's copy, and creating its own. Once you see it that way, the dual role of the MLM and its ADMD is super clear 👑

Some issues about these activities are discussed in Section 3.6.4 of [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 🫶

3.3. Current MLM Effects on Signatures 💅

okay so, as we covered above, an aliasing MLM doesn't touch any existing signature, and an authoring MLM is always making brand-new content 🌸 so there's never an existing signature to break. BUT 😭 a resending MLM usually changes the RFC5322.Subject header field, adds some list-specific header fields, and/or edits the message body. Let's go through how each of those affects DKIM verification 🔍

Subject tags 🏷️: a super popular MLM feature is "tagging" the RFC5322.Subject field by sticking the list's name on the front of it, like [example] for a list called "example". Changing the RFC5322.Subject field on new submissions (adding a list-specific prefix or suffix) will invalidate the Signer's signature if that header field was in the hash when the signature was created. Section 5.5 of [DKIM] lists RFC5322.Subject as a field that should be covered because it holds important user-visible text, so this is expected to be a problem for any list that makes these changes 💀

List-specific header fields 📮: some lists add header fields for list admin stuff, like the ones defined in [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in [MAIL]. A typical MUA is unlikely to put fields like that in an original message, and DKIM is resilient to header fields being added in general (see the notes about the h= tag in Section 3.5 of [DKIM]). So this is not seen as a concern ✨

Other header fields 🎀: some lists add or replace header fields like Reply-To or Sender to show the message is being sent in the context of the mailing list. That way the list gets identified (Sender) and any user replies go to the list (Reply-To). If these fields were in the original message, one or more of them may have been part of the signature hash, and those signatures will be broken 😩

Minor body changes 🌈: some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, list policy, and so on. Changes to the body will alter the body hash computed at the DKIM Verifier, so these render any existing signatures covering those parts of the message body unverifiable. [DKIM] does include the ability to limit the length of the body covered by its body hash so appended text won't interfere with signature validation, but this has security implications 🙈

Major body changes 🧚: some MLMs make bigger changes to message bodies when getting them ready for redistribution, like adding, deleting, reordering, or reformatting [MIME] parts, "flattening" HTML messages into plain text, or inserting headers or footers within HTML messages. Most or all of these changes will invalidate a DKIM signature 💔

MIME part removal 📎: some MIME-aware MLMs remove large MIME parts from submissions and swap them for URLs, to shrink the distributed message and to prevent accidental automated malware delivery. Except in some cases where a body length limit was applied when the DKIM signature was generated, the signature will be broken 😭

There reportedly still exist some mailing lists run manually by a human list manager 🧑‍💻, whose process for getting a message ready for distribution could include all of the above or even some other changes. Wild, right? 🙃

Generally speaking, unless MLM developers and operators make a big move toward more DKIM-friendly practices, an MLM subscriber can't expect signatures applied before the message was processed by the MLM to still be valid when delivered to a Receiver 🫠. That kind of evolution isn't expected in the short term because of general development and deployment inertia. And even if an MLM currently passes messages through unmodified so Author signatures validate, a configuration change or software upgrade to that MLM could make that no longer true 👀

4. Non-Participating MLMs 🦋

This section talks about the issues with sending DKIM-signed mail to or through an MLM that is not DKIM-aware 🙅‍♀️. Basically, the header fields introduced by [DKIM] and [AUTH-RESULTS] carry no special meaning to a non-participating MLM.

In an idealized world, if an Author knows the MLM a message is going to is a non-participating resending MLM, they need to be cautious about whether or not to send a signed message to the list 🤔. The MLM could make a change that invalidates the Author's signature without removing it before redistribution. So list recipients would get a message that purports to be from the Author but carries a DKIM signature that won't verify 😬. Some mail filtering software incorrectly penalizes a message containing a DKIM signature that fails verification, and that can have detrimental effects outside of the Author's control. (More on this below.) This problem gets worse if there are Receivers applying signing policies (e.g., [ADSP]) and the Author publishes any kind of strict policy, i.e., a policy that asks Receivers to reject or otherwise deal severely with non-compliant messages 😱

For domains that do publish strict ADSP policies, the originating site SHOULD use a separate message stream (see Section 2.5), like a signing and Author subdomain, for the "personal" mail 💌. That means a subdomain that's different from the domain(s) used for other mail streams. This lets each one build its own independent reputation, and stricter policies (including ADSP) can be applied to the mail stream(s) that don't go through mailing lists or maybe don't get signed at all 🌟

But all of this assumes a level of infrastructure understanding that isn't expected to be common 🥲. So it'll be up to site administrators to figure out how to support users who want to take part in mailing lists as DKIM adoption grows.

In general, stricter practices and policies are likely to work only for mail streams with the most end-to-end control by the originating organization. That usually excludes mail going through MLMs 🚫. So site administrators who want to use ADSP with a "discardable" setting SHOULD separate the controlled mail stream that deserves this handling from other, less controlled mail streams, like personal mail that transits MLMs. (See also Section 5.7 below.) 🫶

4.2. Verification Outcomes at Receivers 📬

There's no reliable way to tell that a piece of mail arrived via a non-participating MLM 🫣. So sites whose users subscribe to non-participating MLMs SHOULD make sure those user mail streams aren't subject to strict DKIM-related handling policies 🛡️.

4.3. Handling Choices at Receivers ⚖️

To exempt some mail from the expectation of signature verification (as discussed in Section 4.1), receiving ADMDs would need to register non-participating lists and confirm that mail transited them. But that takes excessive effort and even then is likely to be unreliable, so it's not a scalable solution 😮‍💨.

Treating a verification failure as having special meaning is a violation of the basic DKIM Signatures specification [DKIM] 🚨. The only valid, standardized basis for going beyond that specification is specific ADSP direction.

Using restrictive domain policies like [ADSP] "discardable" is an extra challenge 💅. In that case, when a message is unsigned or its signature can no longer be verified, discarding the message is requested. There's no exception in the policy for a message that may have been altered by an MLM, and there's no reliable way to identify that kind of mail either. So participants SHOULD honor the policy and disallow the message 🙅.

4.4. Wrapping a Non-Participating MLM 🎁

One way to add DKIM support to an otherwise non-participating MLM is to "wrap" it, or basically place it between other DKIM-aware components (like MTAs) that provide some DKIM services 🧁. For example, the ADMD operating a non-participating MLM could have its DKIM Verifier act on messages from list subscribers, enforcing some of the features and recommendations of Section 5 on behalf of the MLM. Then the MTA or MSA receiving the MLM Output could also add a DKIM signature for the MLM's domain ✨

5. Participating MLMs 🌸

This section talks about issues with DKIM-signed mail that transits an MLM that is DKIM-aware 🧠.

5.1. General 🌷

Changes that merely add new header fields, like the ones specified by [LIST-ID], [LIST-URLS], and [MAIL], are generally the most friendly to a DKIM-participating email infrastructure 🥰. Adding them won't affect any existing DKIM signatures unless those fields were already present and covered by a signature's hash, or a signature was created specifically to disallow their addition (see the note about h= in Section 3.5 of [DKIM]).

That said, putting headers and footers on message bodies is super common and isn't expected to fade away no matter what documents any standards body produces 📄. This sort of change will invalidate the signature on a message where the body hash covers the entire message 😤. So the following sections also discuss and suggest other processing alternatives 🔄.

Using the l= tag to bound the portion of the body covered by the DKIM body hash is a possible fix for this incompatibility, but it isn't workable for [MIME] messages. Plus it has security considerations (see Section 3.5 of [DKIM]). So its use is discouraged 🚫.

Expressions of list-specific policy (e.g., rules for participation, small advertisements, and so on) are often added to outgoing messages by MLM operators 📣. There's currently no header field proposed for relaying general operational MLM details beyond what [LIST-URLS] already supports. This sort of info is commonly added as footer text appended to the body of the message, or as header text prepended above the original body 🙃. It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy 🔔. It is also RECOMMENDED that standard header fields, rather than body changes, be used to express list operation parameters 🗂️. Yes, these periodic mailings will be repetitive, of course, but since they're generally the same each time, they can be easily filtered if desired 💖

5.2. DKIM Author Domain Signing Practices 💅

okay so ADSP is literally the hardest one 😭🫶. An Author domain that posts a "discardable" policy is basically saying "only send through lists that just alias me" 🙅‍♀️. Any MLM that changes a message from that domain, or strips its signature, is gonna get the message hit with severe action by Verifiers or Receivers 💀. So a resending MLM SHOULD reject outright any mail from an Author whose domain posts that kind of policy 🚫, because those messages are likely to get discarded or rejected by any ADSP-aware recipients. (See also Section 5.3 👀.)

Where that rejection of "discardable" mail isn't enforced, and the mail reaches a Verifier running ADSP checks that fail, the message SHOULD be either discarded (accepted at the [SMTP] level but dropped without delivery) or rejected by returning a 5xx error code 🫣. If you go the rejection route, Section 5.11 has some advice on doing it in a potentially meaningful way ✨.

The reason for all this is easiest to see with an example 🧁. Suppose the following:

users U1 and U2 are subscribers of list L;
U1 is within an ADMD that advertises a "discardable" policy using ADSP;
L alters submissions prior to resending in a way that invalidates the DKIM signature added by U1's ADMD;
U2's ADMD enforces ADSP at the border by issuing an SMTP error code; and
L is configured to remove subscribers whose mail is bouncing.

So a submission to L from U1 gets received at U2, but since the DKIM signature fails to verify, U2's ADMD rejects it based on ADSP 💔. That rejection lands back at L, which proceeds to remove U2 from the list. the mailing list drama is real 🙃.

See also Appendix B.5 of [ADSP] for further discussion 📖.

5.3. Subscriptions 🎀

At subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain 🔎. If the policy specifies "discardable", the MLM SHOULD disallow the subscription or present a warning that the subscriber's submissions to the mailing list might not be deliverable to some recipients because of the published policy of the subscriber's ADMD ⚠️.

Of course, such a policy record could be created after subscription, so this is not a universal solution 🥲. An MLM implementation MAY do periodic checks of its subscribers and issue warnings where such a policy is detected, or simply check upon each submission ⏰.

5.4. Exceptions to ADSP Recommendations 🦋

Where an ADMD has established some out-of-band trust agreement with another ADMD, such that an Authentication-Results field applied by one is trusted by the other, the above recommendations for MLM operation with respect to ADSP do not apply 🙌. Why? Because it's then possible to establish whether or not a valid Author signature can be inferred, even if one isn't present on receipt 🧠.

For example, say domains example.com and example.net have an explicit agreement to trust one another's authentication assertions 🤝. Now consider a message with an RFC5322.From domain of example.org that is also bearing a valid DKIM signature by the same domain, and it arrives at a mailing list run by example.com. On evaluation, example.com validates the signature and adds an [AUTH-RESULTS] field indicating this ✅. But the MLM also makes changes to the message body that invalidate the signature 😬. The MLM then re-signs the modified message using DKIM and sends it on to the list's subscribers, one of whom is at example.net.

On arrival at example.net, the DKIM signature for example.org is no longer valid, so ADSP would generally fail 💀. However, example.net trusts the assertion in example.com's Authentication-Results field that there was a valid signature from example.org, so the ADSP failure can be ignored 🫶. trust bestie, it's giving secure friendship ✨.

An important thing to know is that Authors rarely have any direct influence over how an MLM is managed 🫠. An intermediary that isn't careful about filtering out junk mail, or diligent about unsubscription requests, can trigger recipient complaints that reflect back on whichever agent appears responsible for the message. In this case, that's the Author, via the address found in the RFC5322.From field 😤. In the future, as DKIM signature outputs (the signing domain) get used as inputs to reputation modules, there may be a desire to insulate one's reputation from the unknown results of sending mail through an MLM 🛡️. In that case, Authors SHOULD create a mail stream specifically used for generating DKIM signatures when sending traffic to MLMs 🎀.

This suggestion can be made more general 💡. Mail that is transactional or generally end-to-end in nature, and not likely to be forwarded around by either MLMs or users, SHOULD be signed with a mail stream identifier different from the one used for a stream that serves more varied uses 💅.

5.6. Verification Outcomes at MLMs 🔍

MLMs typically attempt to authenticate messages posted through them 📬. They usually do this through the trivial (and insecure) means of checking the RFC5322.From field email address (or, less frequently, the RFC5321.MailFrom parameter) against a list subscription registry 🥱. DKIM enables a stronger form of authentication: the MLM can require that messages using a given RFC5322.From address also have a DKIM signature with a corresponding d= domain 🔐. This feature would be somewhat similar to using ADSP, except that the requirement for it would be imposed by the MLM and not the Author's organization 💖.

(Note, however, that this goes beyond DKIM's documented semantics. It is presented as a possible workable enhancement 🤓.)

As described, the MLM might conduct DKIM verification of a signed message to attempt to confirm the identity of the Author 🕵️‍♀️. Although it is a common and intuitive conclusion, few signed messages will include an Author signature (see [ADSP]) 🙈. MLM implementers adding such support would have to accommodate this 🫠. For example, an MLM might be designed to accommodate a list of possible signing domains (the d= portion of a DKIM signature) for a given Author, and determine at verification time if any of those are present 🧩. This enables a more reliable method of authentication, at the expense of having to store a mapping of authorized signing domains for subscribers and trusting that it will be kept current 📚.

A message that cannot be thus authenticated MAY be held for moderation or rejected outright 🚧.

This logic could apply to any list operation, not just list submission 🌸. In particular, this improved authentication MAY apply to subscription, unsubscription, and/or changes to subscriber options that are sent via email rather than through an authenticated, interactive channel such as the web 🌐.

When it comes to verifying signatures on submissions, MLMs SHOULD add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM, and what the outcome of the evaluation was 📝. Downstream agents might or might not trust the content of that header field, depending on their own a priori knowledge of the operation of the ADMD generating (and, preferably, signing) that header field 🤷‍♀️. See [AUTH-RESULTS] for further discussion.

5.7. Signature Removal Issues 🧼

A message that arrives signed with DKIM means some domain, prior to MLM Input, has made a claim of some responsibility for the message 🫶. An obvious benefit to leaving the input-side signatures intact, then, is preserving that original assertion of responsibility, so the Receivers of the final message have an opportunity to evaluate it with that information available to them 🧐.

However, if the MLM is configured to make changes to the message prior to reposting that would invalidate the original signature(s), further action is RECOMMENDED 🚨. The goal is to stop invalidated signatures from arriving at final recipients, where they could trigger unwarranted filter actions 😩. (Note, however, that such filtering actions are plainly wrong. [DKIM] stipulates that an invalid signature is to be treated as no signature at all 💀.)

A possible solution would be to:

Attempt verification of all DKIM signatures present on the input message;
Apply local policy to authenticate the identity of the Author;
Remove all existing [AUTH-RESULTS] fields (optional);
Add an [AUTH-RESULTS] header field to the message to indicate the results of the above;
Remove all previously evaluated DKIM signatures;
Affix a new signature that includes in its hashes the entire message on the output side, including the Authentication-Results header field just added (see Section 5.8).

Removing the original signature(s) seems particularly appropriate when the MLM knows it is likely to invalidate any or all of them, due to the nature of the reformatting it will do 🪄. This avoids false negatives for list subscribers in their roles as Receivers of the message 🥰. Although [DKIM] stipulates that an invalid signature is the same as no signature, it is anticipated that there will be some implementations that ignore this advice 🙄.

The MLM could re-evaluate existing signatures after making its message changes, to determine whether or not any of them have been invalidated 🔁. The cost of this is reduced by the fact that, presumably, the necessary public keys have already been downloaded, and one or both of the message hashes could be reused 🧮.

Per the discussion in [AUTH-RESULTS], a Receiver's choice to put any faith in the veracity of the header field requires an a priori assessment of the agent that created it 🕵️. Absent that assessment, a Receiver cannot interpret the field as valid 🚫. Thus, the final recipients of the message have no way to verify on their own the authenticity of the Author's identity on that message 😭. However, if that field is the only one on the message when the Verifier gets it, and the Verifier explicitly trusts the Signer that included the Authentication-Results field in its header hash (in this case, the MLM), the Verifier is in a position to believe that a valid Author signature was present on the message 🥹.

This can be generalized as follows: a Receiver SHOULD consider only [AUTH-RESULTS] fields bearing an authserv-id that appears in a list of sites the Receiver trusts, and that is also included in the header hash of a [DKIM] signature added by a domain in the same trusted list 👑.

Since an aliasing MLM makes no substantive changes to a message, it need not consider the issue of signature removal, as the original signatures should at least arrive at the next MTA unmodified 🌷. It is possible that future domain-based reputations would prefer a richer data set on receipt of a message, and, in that case, signature removal would be undesirable 🤔.

An authoring MLM is closed to outside submitters, so much of this discussion does not apply in that case 🔒.

5.8. MLM Signatures ✨

Okay bestie, so DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own signatures when distributing messages. 💅 The MLM is responsible for the changes it makes to the original messages it resends, and it should show that with a signature. 🫶 This also helps with getting feedback from any FBLs that are set up so undesired list mail can trigger the right action. 🔥

MLM signatures will likely be how recipient systems recognize list mail, and they give the MLM's ADMD a chance to build a good reputation for the list itself. 🌈

A signing MLM, like any other MLM, is free to skip redistributing a message if that message wasn't signed according to its own local configuration or policy. It could also redistribute the message but not sign it. 🙈 However, selective signing is NOT RECOMMENDED. Basically, that would create two message streams from the MLM, one signed and one not, and that can confuse DKIM-aware Verifiers and Receivers. 💀

A signing MLM could add a List-Post: header field (see [LIST-URLS]) using the DNS domain that matches the one in the d= tag of the DKIM signature the MLM adds. ✨ Verifiers or Receivers can use this to figure out which DKIM signature came from the MLM. 🦋 This is not required, though. It is believed the reputation of the Signer will be a more critical data point than this suggested binding. 🍓 Also, this binding isn't recognized by any current specification document, so keep that in mind. 🧚

A DKIM-aware resending MLM SHOULD sign the entire message after it is prepared for distribution (i.e., the MLM Output from Section 3.2). Any other setup might generate signatures that will not validate. 😭

DKIM-aware authoring MLMs sign the mail they send according to the regular signing guidelines given in [DKIM]. 💖

One concern is that having an MLM apply its signature to unsigned mail might cause some Verifiers or Receivers to read the signature as giving more authority or authenticity to the message content than [DKIM] defines. ⭐ This is an issue beyond MLMs, and it mostly involves receive-side processing that's outside the scope of [DKIM]. It's still worth noting here. 👑

5.9. Verification Outcomes at Final Receiving Sites 🌸

In general, Verifiers and Receivers SHOULD treat a signed message from an MLM like any other signed message. Honestly, it would be hard to tell any difference, since specifications such as [LIST-URLS] and [LIST-ID] aren't universally deployed and can be trivially spoofed. 🙈

However, because the Author domain will commonly be different from the MLM's signing domain, there may be a conflict with [ADSP] as discussed in Sections 4.3 and 5.7, especially where an ADMD has misused ADSP. 🔥

5.10. Use with FBLs 🎀

An FBL operator might want to act on a complaint from a user about a message sent to a list. 👀 Some FBLs could choose to generate feedback reports based on DKIM verifications in the subject message. Those operators SHOULD send a report to each domain with a valid signature that has an FBL agreement established, because DKIM signatures are claims of some responsibility for that message. 💅 Authors usually have limited control over how a list runs, so this is exactly why MLM signing matters so much. 🫶

MLM operators SHOULD register with FBLs from major service providers. 🦋 In the context of DKIM, there SHOULD be an exchange of information with the FBL provider, including which signing domain the MLM will use, if any. 📬

If the FBL wants to be more specific, it MAY act solely on a DKIM signature where the signing domain matches the DNS domain found in a List-Post: header field (or similar). 🧚

Using FBLs this way SHOULD be made explicit to list subscribers. 💜 For example, if the MLM's ADMD policy is to handle an FBL item by unsubscribing the user who was the apparent sender of the offending message, telling subscribers about that ahead of time would help avoid surprises later. 🌈

A DKIM-signed message sent to an MLM, then distributed to all of a list's recipients, could lead to a complaint from one of the final recipients for some reason. ✨ That could be a real complaint from a subscriber who finds the message abusive or otherwise unwanted. It could also be an automated complaint, such as a Receiver detecting an invalidated DKIM signature or some other condition. 🤖 It could even be a complaint from antagonistic behavior, which is common when a subscriber is having trouble unsubscribing and then starts filing complaints about every submission to the list. 😤 That would result in a complaint in an FBL report back to the message Author. But the original Author has no involvement in running the MLM itself, so the FBL report is not actionable and is therefore undesirable. 🙅‍♀️

5.11. Handling Choices at Receivers 💅

A recipient that explicitly trusts signatures from a particular MLM MAY want to extend that trust to an [AUTH-RESULTS] header field signed by that MLM. 🫶 The recipient MAY then do additional processing of the message, using the results recorded in the Authentication-Results header field instead of the original Author's DKIM signature. That can include processing the message according to ADSP requirements. 👑

Receivers SHOULD ignore or remove all unsigned externally applied Authentication-Results header fields, and those not signed by an ADMD that the Receiver can trust. See Sections 5 and 7 of [AUTH-RESULTS] for more discussion. 🧹

During DKIM and ADSP evaluation in an SMTP session (a common implementation), an agent MAY decide to reject a message during that session. If it does, [SMTP] stipulates that 550 is the correct response code. ✨ However, if the SMTP server supports [ENHANCED] status codes, a status code that isn't normally used for "user unknown" (5.1.1) is preferred, so a 5.7.0 code SHOULD be used. 🎀 If the rejecting SMTP server supports this, it can tell apart messages rejected on purpose for policy reasons and messages rejected because of other delivery issues. 🦋 In particular, a policy rejection SHOULD be relayed using the enhanced status code above and some appropriate wording in the text part of the reply. Those MLMs that automatically try to remove users with prolonged delivery problems (such as through account deletion) SHOULD therefore detect the difference between a policy rejection and other delivery failures, and act accordingly. 🍓 It would also be beneficial for SMTP servers doing this to use appropriate wording in the text portion of the reply, perhaps explicitly including the string "ADSP" so relevant data is easier to search for in logs. 🔍

The preceding paragraph does not apply to an [ADSP] policy of "discardable". In cases where the submission fails that test, the Receiver or Verifier SHOULD discard the message but return an SMTP success code, i.e., accept the message but drop it without delivery. 🗑️ An SMTP rejection of such mail, instead of the requested discard action, causes more harm than good. 😭

6. DKIM Reporting 📊

As mechanisms become available for reporting forensic details about DKIM verification failures, MLMs will benefit from using them. 🧐

MLMs SHOULD apply DKIM failure-reporting mechanisms as a way to give Signers feedback about issues with DKIM infrastructure. 🔧 This matters most for MLMs that use DKIM verification to authenticate list configuration commands and submissions from subscribers. 🔐

7. Security Considerations 🔐

This document provides suggested or best current practices for use with DKIM and, as such, does not introduce any new technologies for consideration. ✨ However, the following security issues should be considered when implementing the practices described in this document. 😳 Please take these seriously, bestie. 💀

7.1. Security Considerations from DKIM and ADSP 🛡️

Readers should be familiar with the material in the "Security Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as appropriate. 📖

7.2. Authentication Results When Relaying 🚨

Section 5 recommends adding an [AUTH-RESULTS] header field to show the authentication status of a message received as MLM Input. ✨ Per Section 7.2 of [AUTH-RESULTS], Receivers generally should not trust that data without a good reason, such as an a priori agreement with the MLM's ADMD. 🙅‍♀️

Those agreements are strongly advised to include a requirement that those header fields be covered by a [DKIM] signature added by the MLM's ADMD. 🫶 That's the move. 👑

8. References 📚

8.1. Normative References 💎

[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

8.2. Informative References 🦋

[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[LIST-URLS] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

Appendix A. Acknowledgements 🎀

The author wishes to thank the following people for their review and constructive criticism of this document: Serge Aumont, Daniel Black, Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and Alessandro Vesely. 🫶💖

B. Example Scenarios ✨

okay so this bit is all about a couple of MLM (mailing list manager) scenarios that were a big part of why this whole project started 💅 and for each one we get the recommended fix. let's gooo 🦋

B.1. MLMs and ADSP 💌

Problem:

Author ADMD advertises an ADSP policy of "dkim=discardable" 🙈
Author sends DKIM-signed mail to a non-participating MLM, which invalidates the signature 💀
Receiver MTA checks DKIM and ADSP at SMTP time and is configured to reject ADSP failures, so rejects this message 😭
process repeats a few times, after which the MLM unsubscribes the Receiver 💔

Solution: MLMs MUST refuse mail from domains advertising ADSP policies of "discardable" unless the MLMs are certain they make no changes that invalidate DKIM signatures. 🫶

Wait, I need to be careful here: the original says "should refuse," and that's a SHOULD in the source text, which I have to keep exactly. Here is the corrected line:

Solution: MLMs SHOULD refuse mail from domains advertising ADSP policies of "discardable" unless the MLMs are certain they make no changes that invalidate DKIM signatures. 🫶

B.2. MLMs and FBLs 🚨