RFC 7960

Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

📅 published September 2016, from ietf

RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows 📧✨

okay so this RFC is literally about when DMARC and indirect email flows clash 💅 It's an Informational doc, which means it's sharing info, not a standards-track spec 🫶 It came out in September 2016 with ISSN 2070-1721. The editors are F. Martin (LinkedIn), E. Lear (Cisco Systems GmbH), T. Draegen (dmarcian, inc.), E. Zwicky (Yahoo), and K. Andersen (LinkedIn), all listed as Ed. 🌸 The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 🦋

Abstract 🎀

DMARC gives domains a way to express domain-level policies and preferences for email message validation, disposition, and reporting 💖 But when messages don't flow directly from the author's administrative domain to the final Recipients, DMARC can cause some seriously disruptive interoperability issues 😭 These flows are called "indirect email flows". This doc describes those issues and presents possible ways to address them ✨

Status of This Memo 🌈

This doc is not an Internet Standards Track spec. It's published for informational purposes 🍓

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets 💜

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7960 🔗

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This doc 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 doc 🫶 Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🔥

Table of Contents 📜

1. Introduction ....................................................3
   1.1. Document Conventions .......................................4
2. Causes of Interoperability Issues ...............................4
   2.1. Identifier Alignment .......................................4
        2.1.1. DKIM Identifier(s) ..................................5
        2.1.2. SPF Identifier(s) ...................................6
        2.1.3. Multiple RFC5322.From Addresses .....................6
   2.2. Message Forwarding .........................................6
   2.3. Message Modification .......................................7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
   3.1. Message Handling System ....................................8
        3.1.1. Message Submission Agents ...........................8
        3.1.2. Message Transfer Agents .............................9
               3.1.2.1. Message Encoding ...........................9
               3.1.2.2. Header Standardization ....................10
               3.1.2.3. Content Validation ........................10
        3.1.3. Message Delivery Agents ............................10
   3.2. Mediators .................................................11
        3.2.1. Alias ..............................................11
        3.2.2. ReSenders ..........................................12
        3.2.3. Mailing Lists ......................................12
               3.2.3.1. Mailing List Operational Effects ..........13
        3.2.4. Gateways ...........................................13
        3.2.5. Boundary Filters ...................................14
   3.3. Combinations ..............................................15
4. Possible Mitigations of Interoperability Issues ................15
   4.1. Mitigations in Current Use ................................16
        4.1.1. Mitigations for Senders ............................16
               4.1.1.1. Identifier Alignment ......................16
               4.1.1.2. Message Modification ......................17
        4.1.2. Mitigations for Receivers ..........................17
               4.1.2.1. Identifier Alignment ......................17
               4.1.2.2. Policy Override ...........................17
        4.1.3. Mitigations for ReSenders ..........................18
               4.1.3.1. Changes to the RFC5322.From ...............18
               4.1.3.2. Avoiding Message Modification .............18
               4.1.3.3. Mailing Lists .............................18
   4.2. Proposed and In-Progress Mitigations ......................20
        4.2.1. Getting More Radical: Requiring New
               Communication Paths between MUAs ...................21
5. Security Considerations ........................................21
6. References .....................................................22
   6.1. Normative References ......................................22
   6.2. Informative References ....................................23
Appendix A.  Example SPF Bounce ...................................24
  A.1.  Initial Message ...........................................24
  A.2.  Notification Message ......................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................27

1. Introduction ✨

DMARC [RFC7489] gives domains a way to express domain-level policies and preferences for message validation, disposition, and reporting 💅 The DMARC mechanism, especially with restrictive policies, runs into several different kinds of interoperability issues caused by third-party message sourcing, message transformation, or rerouting 😭 In particular, DMARC with restrictive policies causes problems for many Mailing Lists 🙈

When this doc was written, the DMARC base spec had been published as Informational RFC 7489 [RFC7489], and it had seen significant deployment across the email community 🚀

Cases where email doesn't flow directly from the author's administrative domain to the recipient's domain(s) are collectively called "indirect email flows" in this doc. Since DMARC adoption is already widespread and still growing, the impact of DMARC-based rejection policies on indirect email flows can be significant for a select subset of general email traffic 🦋

A few known causes of interoperability issues get presented first, followed by a look at the parts of the Internet Mail Architecture [RFC5598] where these issues can pop up 🧩

Last up, known and possible ways to address interoperability issues get presented. There are often multiple ways to fix any given issue. This doc really tries to be comprehensive, but it shouldn't be treated as complete 🌸

Heads up that some practices in use at the time of this doc may or may not be "best practices", especially as future standards evolve 👀

1.1. Document Conventions 📝

The notation this doc uses for structured fields is taken from [RFC5598], Section 1.3 🎀

The term "notification message" ([RFC5321], Section 4.5.5) refers to a message with a null RFC5321.MailFrom 💌

The terms "Organizational Domain" and "Authenticated Identifiers" are specified in DMARC ([RFC7489], Section 3) 🫶

All words that begin with capital letters take their formal meanings from these references 💜

2. Causes of Interoperability Issues 🔍

Interoperability issues between DMARC and indirect email flows happen when following the DMARC spec leads a receiving implementation to apply DMARC-based policy restrictions to messages that are both compliant with the architecture in [RFC5598] and seen as legitimate by the intended Recipient 😤

Domains that assert a p=none policy, and email messages that pass standard DMARC validation, don't have any interoperability issues 🥳

Email messages that don't conform to IETF email specs but are still considered legitimate by the intended Recipients aren't discussed in this doc 🙅

The rest of this section describes several conceptual causes of interoperability issues ✨

2.1. Identifier Alignment 🔗

Note to operators and administrators: the identifiers used by the Sender Policy Framework (SPF) are technical parts of the SMTP transport process. As described below, they may or may not have a meaningful relationship to the content or source of the message itself. This "relationship by proximity" can be a point of confusion for non-technical end users, whether they're recipients or senders 🤓

DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF [RFC7208] to do message source validation 🛡️ The DMARC [RFC7489] spec refers to source domains validated by DKIM or SPF as "Authenticated Identifiers" 🪪 To be used by DMARC, an "Authenticated Identifier" must also be related to the domain in the message's RFC5322.From header field [RFC5322] 💅 That relationship between an Authenticated Identifier's domain and the domain of the RFC5322.From is called "Identifier Alignment" 💖

DMARC lets Identifier Alignment be determined in two modes: strict and relaxed 🎀 Strict mode requires an exact match between the domain of any Authenticated Identifier and the message's RFC5322.From header field [RFC5322]. Relaxed mode allows Identifier Alignment if the Authenticated Identifiers and the message's RFC5322.From header field [RFC5322] share the same Organizational Domain 🌈 Generally, DMARC interoperability issues are the same under strict and relaxed alignment, but strict alignment limits the possible solutions because its matching requirement is more rigorous 😬 Some of the mitigations in this doc only work with the relaxed mode of Identifier Alignment 🫠

2.1.1. DKIM Identifier(s) 🔐

okay bestie, so DKIM gives you a cryptographic way to attach one or more domain identifiers to a message 💌 on its own, DKIM identifiers don't have to be related to where the message content came from 🤷‍♀️ BUT for a DKIM identifier to align in DMARC, the signing domain of a valid signature has to be part of the same Organizational Domain as the domain in the RFC5322.From header field [RFC5322]. that's the whole game 🎀

DKIM also allows a message to carry multiple valid signatures 🦋 those can come from the same domain or different domains, and the DKIM spec doesn't put any restrictions on it 🌈 DMARC will keep checking the Authenticated Identifiers based on DKIM signatures until it finds an aligned one (if there is one at all) 🔍 but ngl, operators have noticed that some implementations struggle with multiple signatures 😭 Implementations that can't handle multiple DKIM signatures may wrongly flag messages as "not passing" (DMARC alignment) and then apply DMARC-based policy to messages that were actually fine 💀 not it.

2.1.2. SPF Identifier(s) 🌸

The SPF spec [RFC7208] defines two Authenticated Identifiers for each message 💜 they come from:

a. the RFC5321.MailFrom [RFC5321] domain, and

b. the RFC5321.HELO/.EHLO SMTP domain.

Here's the tea ☕ in the SPF spec, the RFC7208.MAILFROM [RFC7208] value is based on RFC5321.MailFrom, unless that value is absent (like with notification messages). In that case, the second one, the RFC5321.HELO/.EHLO identifier value, gets used. This "fallback" definition has occasionally been misunderstood by MTA operators, since notification messages are often an "automatic" feature of MTA software 🤖 and some MTA software doesn't let you apply a DKIM signature to those notification messages at all 😤

See Appendix A for an example treatment of this scenario 📖

For DMARC validation/alignment purposes, the hybrid RFC7208.MAILFROM [RFC7208] identifier's domain gets used if and only if it's aligned with the RFC5322.From [RFC5322] domain. How alignment of the validated domain gets decided depends on whether the DMARC record says "strict" or "relaxed", as described above for the DKIM identifiers and in [RFC7489] ✨

2.1.3. Multiple RFC5322.From Addresses 👯

[RFC5322] permits only one From header field, but that field can contain multiple mailboxes 📬 since this is an extremely rare usage, DMARC says the handling of this situation is implementation dependent 🤔

🚨 Multiple domains are a red flag! An attacker could add their own domain to the RFC5322.From field, slip in arbitrary new content, and sign the message. So DMARC recommends applying the strictest policy to such messages (Section 6.6.1 of [RFC7489]) 🛡️

2.2. Message Forwarding 📨

Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture 🏛️

Every forwarding operation involves retransmitting the email 🔁 as we said above, for SPF to produce an Authenticated Identifier that's relevant to DMARC, the domain of the RFC7208.MAILFROM has to be in alignment with the RFC5322.From header field. Forwarding causes specific problems for SPF-based Authenticated Identifiers:

  • If the RFC5321.MailFrom is present and the forwarder keeps the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure 😬 If the forwarder swaps the RFC5321.MailFrom for its own domain, SPF might pass, but Identifier Alignment with the RFC5322.From header field will fail 💔
  • If the RFC5321.MailFrom is empty (like with Delivery Status Notifications), the RFC5321.HELO/.EHLO domain of the forwarder will likely be in a different Organizational Domain than the original RFC5322.From header field's domain. SPF may pass, but Identifier Alignment with the RFC5322.From header field will fail 🙃

In both cases, SPF can't produce relevant Authenticated Identifiers, so DKIM has to carry the load to produce results that are relevant to DMARC 🦸‍♀️

2.3. Message Modification ✂️

Changing email content invalidates most DKIM signatures, and lots of message-forwarding systems modify content 🙈 Mailing List processors are a classic example, but other forwarding systems make changes too 💅

Although DKIM has a length flag so content can be appended without invalidating the signature, in practice (especially with MIME-encoded [RFC2045] messages), a Mailing List processor does more than just append content (see Section 5.3 of [RFC5598] for details) 😵‍💫 Plus, the length flag is seldom used because of security issues (see Section 8.2 of [RFC6376] for additional security considerations). So this method is only mentioned here for completeness 🫠

DKIM describes two canonicalizations for preparing the header and body for DKIM processing: simple and relaxed 🎀 relaxed is designed to handle trivial changes to whitespace and folding that, at least in the header case, generally don't have any semantic significance. But relaxed canonicalization is more computationally intensive, so it may not have been the go-to in early DKIM deployments, which left some deployments using the less forgiving "simple" canonicalization 🥲 The prevalence is unknown, but some DKIM verifiers have problems evaluating relaxed canonicalization correctly 👀

3. Internet Mail Architecture, DMARC, and Indirect Email Flows 🏗️

This section covers the components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can show up 🔍

3.1. Message Handling System 📬

Section 4 of [RFC5598] describes six basic components that make up the Message Handling System (MHS) 💜

  • Message
  • Message User Agent (MUA)
  • Message Submission Agent (MSA)
  • Message Transfer Agent (MTA)
  • Message Delivery Agent (MDA)
  • Message Store (MS)

Of these, the MSA, MTA, and MDA are the ones discussed in relation to DMARC interoperability 🫶

Section 5 of [RFC5598] also defines a Mediator as a hybrid of several component types 🧚 A Mediator gets special attention in this section because of the unique issues they face when trying to interoperate with DMARC 😭

3.1.1. Message Submission Agents 📮

An MSA accepts messages submitted by a Message User Agent (MUA) and enforces the policies of the hosting ADministrative Management Domain (ADMD) and the requirements of Internet standards 📜

MSAs are split into two sub-components:

  • Author-focused MSA functions (aMSA)
  • MHS-focused MSA functions (hMSA)

MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain outside the ADMD of the MSA 🚩 This can happen in a few ways, like when someone uses a mail service with their own domain but never properly set up an SPF record, or when an MUA tries to send mail as someone else 👀 Examples of the latter include "forward-to-friend" features on news/article websites, or "send-as" features on some MUAs 📰

When an hMSA takes responsibility for transit of a message whose RFC5322.From header field contains a domain outside the hMSA's ADMD, the hMSA runs into DMARC interoperability issues if that domain publishes a DMARC policy of "quarantine" or "reject" 😬 These issues show up as the inherent difficulty of establishing alignment with the domain in the message's RFC5322.From header field. Examples include:

  • Partially open relays - a residential ISP that lets its customers relay non-local domains through its infrastructure 🏠
  • Embedded devices - cable/DSL modems, firewalls, wireless access points, and printers that send email using hardcoded domains 🖨️
  • Devices that send mail on behalf of a user - scanners, security cameras, and alarms that send mail as their owner or a device user 📷
  • Email service providers - ESPs that serve customers using domains that publish a DMARC "reject" policy 💼
  • Calendaring software - an invited member of an event modifies the event, causing the calendaring software to send an update that claims to come from the event's creator 📅💀

3.1.2. Message Transfer Agents 🚚

MTAs relay a message until it reaches a destination MDA 🛣️ Some common message-handling strategies break the integrity of DKIM signatures. A restrictive DMARC policy plus a broken DKIM signature turns latent interoperability problems into overt problems 🚨

3.1.2.1. Message Encoding 🔤

An MTA may modify the message encoding, for instance by converting 8-bit MIME sections to quoted-printable 7-bit sections 🔄 This modification is outside the scope of DKIM canonicalization and will invalidate DKIM signatures that include message content 💔

An MTA could also re-encode the message without changing the encoding type: it receives a MIME-encoded message and produces a semantically and semiotically equivalent MIME body that isn't identical to the original 🪞 This is typical of systems that use some other message representation internally 🧠

3.1.2.2. Header Standardization 🧾

An MTA may rewrite headers to bring them into compliance with existing RFCs. For example, some common MTAs will fix comprehensible but non-compliant date formats so they become compliant ones 📅

Header rewriting is outside the scope of DKIM canonicalization and will invalidate DKIM signatures 😩 All downstream DMARC processing will be unable to use DKIM to produce Authenticated Identifiers because of the header rewriting 🙅‍♀️

Providing solutions for issues relating to non-RFC-compliant emails is outside the scope of this document 📝

3.1.2.3. Content Validation 🛡️

An MTA may also implement security-motivated changes to message content, dropping or altering sections of messages, which causes DKIM signatures to break 🔐

3.1.3. Message Delivery Agents 📥

The MDA transfers a message from the MHS to a mailbox 📫 Like the MSA, the MDA has two sub-components:

  • MHS-focused MDA functions (hMDA)
  • Recipient-focused MDA functions (rMDA)

Both the hMDA and the rMDA can redirect a message to an alternative address 🔀 DMARC interoperability issues related to redirecting messages are described in Section 3.2 🧩

Sieve [RFC5228] functionality often lives in the rMDA sub-component and can cause DMARC interoperability issues 🫣 The Sieve 'addheader' and 'deleteheader' filtering actions can modify messages and invalidate DKIM signatures, which removes DKIM-supplied Authenticated Identifiers as inputs to the DMARC mechanism 💀 There are also Sieve extensions [RFC5703] that modify the body 📝 Sieve alterations may only become an issue when the email is reintroduced into the transport infrastructure ✨

3.2. Mediators

Okay bestie, so Mediators 💅 are the ones that forward messages through a re-posting process, and they're basically cousins of plain MTA relaying but with way more freedom in both addressing and content changes ✨. [RFC5598] is where they're defined, so go check that out 🦋.

Mediators are lowkey DMARC's biggest headache 😭. Interoperability issues are super common here, and that's literally because Mediators get used precisely for their ability to modify messages 🙈.

The DMARC design just doesn't cope with some Mediator stuff 💀. Like, content modifications that break DKIM signatures? Not handled. And RFC5321.MailFrom rewriting, which is needed so SPF can still authenticate re-sent mail when the new Recipient gets the message from the Mediator instead of the original organization? Also not handled 😤.

3.2.1. Alias

An Alias is a simple re-addressing facility 💖. Instead of one internal address, it gives you one or more brand new Internet Mail addresses 🌸. The message keeps moving through the transfer service until it reaches one or more alternative addresses 🧚.

Aliases can be done with mailbox-level forwarding (think "dot-forwarding" 🍓), with Sieve-level forwarding (through the Sieve "redirect" action ✨), or with other methods 🌈. Here's the tea ☕: if an Alias keeps the message content intact and doesn't make big header changes, DKIM signatures may stay valid 🫶. BUT Aliases often stretch the delivery path outside the originating ADMD's SPF record(s), so SPF can get messy 😬.

Examples of Aliasing include:

  • Forwarding email between free email (freemail) providers so you can try different interfaces while keeping your original email address 💅;
  • Consolidating a bunch of email addresses into one account to centralize processing 👑; and
  • Services that give you "activity-based", "role-based", "vanity", or "temporary" email addresses, like universities and professional associations 🎀. For example, professional or alumni institutions might give members an Alias for as long as they're a member, but not want to store their emails long-term 🦋.

Most of the time, the aMSA providing Alias services has no administrative relationship with the ADMD of the originator or the Final Recipient 🙈. So if you're fixing an Alias-related DMARC failure, you SHOULD NOT assume such a relationship exists 💀.

Oops, wait, I need to fix that. Here's the correct line:

Most of the time, the aMSA providing Alias services has no administrative relationship with the ADMD of the originator or the Final Recipient 🙈. So solutions to Alias-related DMARC failure should not assume such a relationship 💅.

3.2.2. ReSenders

ReSenders are the "splicers" 🧚 of the group. They splice a message's addressing info to connect the Author of the original message with the Recipient(s) of the new message ✨. The new Recipient sees the message as coming from the original Author, even if the Mediator adds commentary 💜.

Without Authenticated Identifiers aligned with the Author's RFC5322.From header field domain, the new Recipient has no way to get a passing DMARC evaluation 😭. Yikes.

Examples of ReSenders include MUA-level forwarding, where you resend a message to a new Recipient or forward it "inline" to them (this does NOT include forwarding a message "as an attachment" 🙅). Another example is calendaring software that lets a meeting attendee (not the meeting organizer) change the content of an invite, generating new invitations that claim to be reissued from the meeting organizer 🗓️💀.

3.2.3. Mailing Lists

A Mailing List receives messages as an explicit addressee and then reposts them to a list of subscribed members 🌈. It's basically an elaborate version of what ReSenders do 💅.

Mailing Lists share the same DMARC interoperability issues as ReSenders (Section 3.2.2) 🫶, and they very commonly modify headers or content in ways that break DKIM, including:

  • prepending the RFC5322.Subject header field with a tag, so people can spot the Mailing List in a subject line list 🏷️;
  • adding a footer to the email body with administrative instructions 📝;
  • removing some MIME-parts or converting the message to text only 🎀;
  • encrypting the body with the Recipient's key using PGP (Pretty Good Privacy) or S/MIME 🔐;
  • enforcing community standards by rewriting banned words 🙅‍♀️; and
  • letting moderators add arbitrary commentary to messages (discussed in [RFC6377]) 💬.

Any of those modifications would invalidate a DKIM signature 💀.

Header and content changes are super common for Mailing Lists and are often central to how they work today 💖. Plus, MUAs have come to rely on those Mailing List modifications to show messages to end users in the ways they expect 🦋.

3.2.3.1. Mailing List Operational Effects

Mailing Lists may also have these DMARC interoperability issues 😬:

  • Subscribed members may not receive email from members who post using domains that publish a DMARC "p=reject" policy 🚫.
  • Mailing Lists may read DMARC-related email rejections as an inability to deliver email to the Recipients who are checking and enforcing DMARC policy 🤔. That can lead to subscribers who are checking and enforcing DMARC policy being accidentally suspended or removed from the Mailing List 😭.

3.2.4. Gateways

A Gateway does the basic routing and transfer work of message relaying 🚪, but it's also allowed to modify content, structure, addressing, and/or other attributes 💅. It does this so the message can get into a messaging environment that runs on different standards or potentially incompatible policies 🌸.

Gateways share the same DMARC interoperability issues as ReSenders (Section 3.2.2) 🫶. They may also share the same DMARC interoperability issues as MTAs (Section 3.1.2) 🧚.

Receiver systems on the non-SMTP side of a protocol Gateway may be unable to evaluate DKIM and SPF 😵. If a message goes through a second protocol Gateway back into the SMTP domain, those transformations commonly break the original DKIM signature(s) 💔.

Gateway-level forwarding can cause DMARC interoperability issues if the Gateway is set up to rewrite the message into alternate receiving domains 🌈. For example, an acquisition might lead an acquiring company to decommission the acquired company's domains by rewriting messages to use the acquiring company's domain 🏢. Since the RFC5322.To header field is usually DKIM-signed, this kind of rewriting will invalidate those DKIM signatures 💀.

3.2.5. Boundary Filters

To enforce security boundaries, organizations can have messages analyzed for conformance with their safety policies 🛡️. A filter might change the content to make it safe, like by removing or otherwise altering content that's deemed unacceptable 🧼.

Boundary Filters share the same DMARC interoperability issues as ReSenders 🫶.

Issues may come up with SPF and DKIM evaluation if it's performed after the filter has made modifications 😬.

Examples of Boundary Filters include:

  • Malware scanning 🦠: To protect readers and its reputation, an MTA that transfers a message may remove content believed to be harmful, reformulate content into canonical formats to make it more trustworthy or easier to scan, and/or add text in the body saying the message has been scanned 🔍. Any such modifications would invalidate a DKIM signature 💀.
  • Spam filtering 🗑️: To protect its reputation and help other MTAs, an MTA may modify a message to indicate its decision that the message is likely unwanted, and/or add text in the body saying that filtering has been done 🙅.
  • Other text additions ✍️: An MTA may add an organizational disclaimer or advertisement, for instance 📣.
  • URL alteration 🔗: Some systems rewrite or alter embedded URLs as a way to control the potential threat from malware 🛡️.
  • Secondary MX services 📬: The secondary MX for an organization may be external to the normal mail processing for that organization, and it may queue messages and forward them to the primary when it becomes available ⏳. This won't invalidate DKIM, but it will stop the primary from validating SPF normally 😭. In this case, though, it is inappropriate for a primary MX server to perform an SPF check against its own secondaries 🙅‍♀️. Instead, the secondary MX should do this check and use some trusted mechanism to pass the results of the SPF, DKIM, and DMARC evaluation(s) to the primary MX server 🫶.

3.3. Combinations

Indirect email flows can be combined 🔀. For example, a university student may subscribe to a Mailing List using their university email address, while that university address is set up to forward all emails to a freemail or post-education corporate account provider where a more permanent email address for them exists 🎓✨.

Within an organization, a message may pass through various MTAs (Section 3.1.2), each doing a different job (authentication, filtering, distribution, etc.) 🧚💅.

4. Possible Mitigations of Interoperability Issues 🛠️

Solutions to interoperability issues between DMARC and indirect email flows vary a lot in scope and implications 🌈. They range from improvements to underlying processing, like proper handling of multiple DKIM signatures, all the way to more radical changes to the messaging architecture 🔥. This section describes possible ways to address interoperability issues 💖. Heads up though: these particular mechanisms may not be considered "best practices" and may, in some cases, violate various conventions or expectations 🙈.

Receivers sometimes need to deliver email messages that don't conform to any standard or protocol, but that end users still want 📬. Mitigating the impact of DMARC on indirect email flows matters a lot to receivers running services where ease of use and compatibility with existing email flows is a priority 🫶.

DMARC provides a mechanism (local policy) for receivers to make decisions about identity alignment acceptability based on information outside DMARC, and to communicate those decisions as "overrides" to the sender 🗝️. This can help ease some interoperability issues, but care is needed so it doesn't create loopholes for abuse 🚨.

To complicate things further, mitigation may not be wanted if the email is in a high-value or high-risk (security-related) transactional category, like financial transactions or medical records 🏥. In those cases, mitigating DMARC's impact on indirect email flows may not be desirable (counterproductive or allowing for abuse) ⚠️.

As a final note, mail systems are diverse and widely deployed 🌍. Systems of various ages and capabilities are expected to preserve interoperability with the rest of the SMTP ecosystem 🫶. For instance, Qmail is still used, even though the base code hasn't been updated since 1998 🦖. ezmlm, once a popular MLM, is still deployed but hasn't been updated since 1997, although a new version (ezmlm-idx) exists 📮. Old versions of other open- and closed-source MTAs are still commonly in operation 🕰️. When dealing with aging or unsupported systems, some solutions may be time-consuming and/or disruptive to implement 😩.

4.1. Mitigations in Current Use

Because DMARC is already widely deployed, many operators already have mitigations in use 🎉. These mitigations vary in effectiveness and side effects, but they have the advantage that they're available right now 💖.

4.1.1. Mitigations for Senders

4.1.1.1. Identifier Alignment 💖

  • okay so MTAs handling multiple domains may choose to change RFC5321.MailFrom to align with RFC5322.From, which makes SPF way more usable for DMARC ✨
  • MTAs handling multiple domains may also choose to align RFC5321.HELO/.EHLO to RFC5322.From, especially when sending notification messages 🔔. Dynamically adjusting the RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible for some MTA software 😭
  • MTAs may choose to DKIM-sign notification messages with an aligned domain, which lets them get a DKIM-based DMARC pass 🫶
  • MTAs sending email on behalf of multiple domains may require Domain Owners to provide DKIM keys so they can use DKIM and avoid SPF validation issues, given the DMARC alignment requirement for RFC5322.From 🔑. Managing DKIM keys with a third party has security risks that should be carefully managed (see also [RFC6376], Section 8) 🔐. Methods involving CNAMEs and/or subdomains may alleviate some risks 🌸
  • Senders who are sending on behalf of users in other administrative domains may choose to use an RFC5322.From under the sender's control. The new From can be either a forwarding address in a domain controlled by the Sender or a placeholder address, with the original user's address in an RFC5322.Reply-to header field. However, doing this may cause the Recipient's MUA to deviate from customary behavior 👀
  • When implementing "forward-to-friend" functionality, one approach to avoid DMARC failures is to pass a well-formed message to the user's MUA so that it may fill in an appropriate identity and submit through its own MSA 💅
  • Senders can use domains with distinct DMARC policies for email sent directly and email known to use indirect mail flows. However, for most well-known brands, all active domains are likely to be targeted equally by abusers 🥲

4.1.1.2. Message Modification 🛠️

  • Senders can maximize survivability of DKIM signatures by limiting the header fields they sign and using relaxed canonicalization. Using the DKIM length tag to allow appended signatures is discouraged due to the security risk created by allowing arbitrary content to be appended to legitimate email 🚨
  • Senders can also maximize survivability by starting with RFC-compliant headers and common body formats 🍓
  • In order to minimize transport-based conversions, Senders can convert messages to a lowest denominator MIME content-transfer encoding such as quoted-printable or base64 before signing ([RFC6376], Section 5.3) 📦

4.1.2. Mitigations for Receivers 🎀

4.1.2.1. Identifier Alignment 🔍

  • Receivers should update DKIM handling libraries to ensure that they process all valid DKIM signatures and check each signature for alignment 🧐

4.1.2.2. Policy Override ⚖️

  • Receivers can amalgamate data from their user base to create lists of forwarders and use such lists to inform DMARC local policy overrides. This process may be easier for large receivers where data and resources to create such lists are more readily available than at smaller sites, where there are fewer accounts that receive forwarded mail and other resources may be scarce 💁

4.1.3. Mitigations for ReSenders 🦋

4.1.3.1. Changes to the RFC5322.From 💌

Many ReSender issues can be avoided by using an RFC5322.From header field under the ReSender's control, instead of the initial RFC5322.From. This will correct Identifier Alignment issues and allow arbitrary message modification as long as the ReSender signs the message with an aligned domain signature. When ReSenders change the RFC5322.From, it is desirable to preserve the information about the original initiator of the message 🎀

A first option is to use the Original-From [RFC5703] (or X-Original-From) header field for this purpose in various contexts (X- header field names are discouraged by [RFC6648]). However, handling of Original-From (or X-Original-From) is not defined anywhere. It is not currently used consistently or displayed to the user, and in any situation where it is used, it is a new unauthenticated identifier available for exploitation unless included within the scope of the new DKIM signature(s) 🚩

Another option for ReSenders is to rewrite the RFC5322.From header field address to a locally controlled address that will be forwarded back to the original sender (subject to its own ReSender forwarding mitigations) 🔁

4.1.3.2. Avoiding Message Modification 🙅

  • Forwarders can choose to add email header fields instead of modifying existing headers or bodies, for instance, to indicate a message may be spam 🙈
  • Forwarders can minimize the circumstances in which they choose to fix messages, preferring to preserve non-compliant headers to creating DKIM failures 🧯
  • Forwarders can choose to reject messages with suspect or harmful content instead of modifying them 🚫

4.1.3.3. Mailing Lists 📬

[RFC6377] provides some guidance on using DKIM with Mailing lists. The following mitigation techniques can be used to ease interoperability issues with DMARC and Mailing lists:

  • Configuring the Mailing List Manager (MLM) to alter the RFC5322.From header field to use the domain of the MLM is a mitigation policy that is now present in several different Mailing List software distributions. Since most list subscribers prefer to know the identity of the Author of the original message, typically this information may be provided in the display name part of the RFC5322.From header field. This display name needs to be carefully crafted so as to not collide with the original display name of the Author, nor contain something that looks like an email address or domain name. These modifications may to some extent defeat the purpose of DMARC itself. It may make it difficult to ensure that users of all email clients can easily reply to the Author, the list, or all using the email client features provided for that purpose. Use of the RFC5322.Reply-To header field can alleviate this problem depending on whether the Mailing List is configured to reply-to-list, reply-to-author, or reply-to-fixed-address; however, it is important to note that this header field can take multiple email addresses. When altering the RFC5322.From, there are three possibilities:
    1. change it to put the Mailing List email address,
    2. change it to a locally defined address that will be forwarded back to the original sender, or
    3. "break" the address by modifying the domain to a non-existent domain (such as by adding a suffix like ".invalid").

The latter modification may create issues because it is an invalid domain name, and some MTAs may pay particular attention to the validity of email addresses in RFC5322.From and the reputation of the domains present there. 🫣

  • Configuring the MLM to "wrap" the message in a MIME message/rfc822 part and to send as the Mailing List email address. Many email clients (as of the publication of this document), especially mobile clients, have difficulty reading such messages, and this is not expected to change soon 📱
  • Configuring the MLM to not modify the message so that the DKIM signature remains valid. Some Mailing Lists are set up this way and require few additional changes to ensure the DKIM signature is preserved. Moving lists that currently modify mail to a policy like this may be too much of a change for the members of such lists 🤷
  • Rejecting posts or membership requests from domains with a DMARC policy other than "p=none". However, members or potential members of such Mailing Lists may complain of unfair exclusion 😤
  • To alleviate unsubscribes to the Mailing List due to the messages bouncing because of DMARC, the MLM needs to not act on notification messages due to message authentication issues. [RFC3463] specifies Enhanced Mail System Status Codes, which help differentiate between various failure conditions. Correctly interpreting Extended SMTP error messages is useful in this case. In particular, extended status codes for SPF and DKIM causes are defined in [RFC7372], and DMARC-related failure indications are discussed in DMARC ([RFC7489], Section 10.3) 🧠

All these techniques may provide some specific challenges to MUAs and different operational usages for end users (like rewriting filters to sort emails in folders). There will be some time before all implications are understood and accommodated ⏳

4.2. Proposed and In-Progress Mitigations 🔮

The following mitigations are based on Internet-Drafts (I-Ds) that are still in process. They are described here to offer an exploratory path for solutions. These solutions should not be used in a production environment. Because of the transient nature of I-Ds, specific citations are not included because a number of them will inevitably become obsolete, and those that gain consensus in the community will become RFCs and should be discovered as such.

  • Third-party authorization schemes provide ways to extend Identifier Alignment under control of the Domain Owner.
  • Ways to canonicalize messages that transit Mailing Lists so that their alterations can be isolated from the original signed content.
  • Mechanisms to record message transformations applied at each hop so they can be reversed and the original signed content recovered.
  • "Conditional" DKIM signatures, whereby the Author domain indicates its signature is only good if accompanied by a signature from an expected downstream relay.
  • Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, creating a provable chain of custody as well as a view of message authentication results at each handling step.

4.2.1. Getting More Radical: Requiring New Communication Paths between MUAs 🚀

In practice, a number of operators are using strict alignment mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic email through systems purporting to be Mailing List handlers. The receiving ADMD has no knowledge of which lists the user has subscribed to and which they have not. One avenue of exploration would be for the user to authorize Mailing Lists as proxies for authentication, at which point the receiving ADMD would be vesting some trust in the Mailing List service. The creators of DKIM foresaw precisely this possibility at the time by not tightly binding any semantics to the RFC5322.From header field. Some experimental work has taken place in this area, as mentioned above. Additional work might examine a new communication path to the user to authorize some form of transitive trust. 🤝

5. Security Considerations 🚨

This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial of service that can be created by rejections of messages by DMARC-aware mail receivers. 😱

Section 4.1.1.1 discusses the importance of appropriate DKIM key management vis-a-vis third-party email senders. 🔑

Section 4.1.3.3 warns that rewriting the RFC5322.From header field to create an artificial domain name should not be done with any domain. 💀

6. References ✨

6.1. Normative References

6.2. Informative References

Appendix A. Example SPF Bounce ✨

Okay so this appendix is a little showcase of a notification message, aka a "bounce" 💌 Let's see how it plays out!

A.1. Initial Message

Here's the message right as it leaves the Origin MTA (segv.d1.example):

 Return-Path: <jqd@d1.example>
 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
     (authenticated bits=0)
     by segv.d1.example with ESMTP id t0FN4a8O084569;
     Thu, 14 Jan 2015 15:00:01 -0800 (PST)
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
     s=20130426; t=1421363082;
     bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
     h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
      Content-Transfer-Encoding;
     b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
      bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
      gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 To: no-recipient@dmarc.org
 Subject: Example 1

 Hey gang,
 This is a test message.
 --J.

A.2. Notification Message

So here's the drama 😭 When dmarc.org rejects the message without a DKIM signature, it sets the RFC5321.HELO/.EHLO domain to dmarc.org.local, which has no SPF record. dmarc.org has a reject policy in place for these non-passing cases. There's no DKIM signature on the notification message either, so the failed SPF lookup ends up as dmarc=fail, and d1.example could be expected to discard the notification message itself. Iconic, right? 💅

 Return-Path: <>
 Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
    by mx.d1.example with ESMTPS id Lkm25302jJR5
    for <jqd@d1.example>
    (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Thu, 14 Jan 2015 15:00:24 -0800 (PST)
 Authentication-Results: mx.d1.example;
    spf=none (d1.example: dmarc.org.local does not designate
    permitted sender hosts) smtp.mail=;
    dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
 MIME-Version: 1.0
 Received: from segv.d1.example (segv.d1.example [198.51.100.1])
  by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
  14 Jan 2015 15:00:24 -0800 (PST)
 From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
 To: jqd@d1.example
 Subject: Delivery Status Notification (Failure)
 Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
 Date: Thu, 14 Jan 2016 23:00:24 +0000
 Content-Type: text/plain; charset=UTF-8

 This is an automatically generated Delivery Status Notification

 Delivery to the following recipient failed permanently:

      no-recipient@dmarc.org

 Technical details of permanent failure:
 Your message was rejected by the server for the recipient domain
   dmarc.org by mail.dmarc.org [192.0.2.1].

 The error that the other server returned was:
 550 5.1.1 <no-recipient@dmarc.org>... User unknown

 ----- Original message -----
 Return-Path: <jqd@d1.example>
 Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
     [203.252.0.131]) (authenticated bits=0)
     by segv.d1.example with ESMTP id t0FN4a8O084569;
     Thu, 14 Jan 2015 15:00:01 -0800 (PST)
     (envelope-from jqd@d1.example)
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
     s=20130426; t=1421363082;
     bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
     h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
      Content-Transfer-Encoding;
     b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
      bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
      gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 To: no-recipient@dmarc.org
 Subject: Example 1

 Hey gang,
 This is a test message.
 --J.

Acknowledgments 🫶

Huge thanks to Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf E. Sonneveld, Tim Draegen, and Franck Martin, who all contributed to the IETF DMARC Working Group's wiki page listing every known interoperability issue with DMARC and indirect email flows. Legends. 🌸

Tim Draegen then turned the first draft of this document out of those contributions, ham-fistedly mapping them into the language of [RFC5598] 💜

Authors' Addresses 💌

 Franck Martin (editor)
 LinkedIn
 Mountain View, CA
 United States of America

 Email: fmartin@linkedin.com


 Eliot Lear (editor)
 Cisco Systems GmbH
 Richtistrasse 7
 Wallisellen, ZH  CH-8304
 Switzerland

 Phone: +41 44 878 9200
 Email: lear@cisco.com


 Tim Draegen (editor)
 dmarcian, inc.
 PO Box 1007
 Brevard, NC  28712
 United States of America

 Email: tim@dmarcian.com


 Elizabeth Zwicky (editor)
 Yahoo
 Sunnyvale, CA
 United States of America

 Email: zwicky@yahoo-inc.com


 Kurt Andersen (editor)
 LinkedIn
 2029 Stierlin Court
 Mountain View, CA  94043
 United States of America

 Email: kandersen@linkedin.com
📦 where this page comes from