draft-ietf-dmarc-interoperability-11.txt   draft-ietf-dmarc-interoperability-12.txt 
DMARC F. Martin, Ed. DMARC F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: May 15, 2016 Cisco Systems GmbH Expires: June 2, 2016 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
dmarcian, inc. dmarcian, inc.
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
K. Andersen, Ed. K. Andersen, Ed.
LinkedIn LinkedIn
November 12, 2015 November 30, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-11 draft-ietf-dmarc-interoperability-12
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting. preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 15, 2016. This Internet-Draft will expire on June 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16 4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 16
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 19 Paths Between MUAs . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Interoperability issues between DMARC and indirect email flows arise Interoperability issues between DMARC and indirect email flows arise
when conformance to the DMARC specification leads a receiving when conformance to the DMARC specification leads a receiving
implementation to apply DMARC based policy restrictions to messages implementation to apply DMARC based policy restrictions to messages
that are both compliant with the architecture as specified in that are both compliant with the architecture as specified in
[RFC5598] and viewed as legitimate by the intended recipient. [RFC5598] and viewed as legitimate by the intended recipient.
Note that domains which assert a "p=none" policy and email which Note that domains which assert a "p=none" policy and email which
passes standard DMARC validation do not have any interoperability passes standard DMARC validation do not have any interoperability
issues. issues.
Email messages that do not conform to other email specifications but Email messages that do not conform to IETF email specifications but
are considered legitimate by the intended recipients are not are considered legitimate by the intended recipients are not
discussed in this document. The rest of this section describes discussed in this document. The rest of this section describes
several conceptual causes of interoperability issues. several conceptual causes of interoperability issues.
2.1. Identifier Alignment 2.1. Identifier Alignment
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
source validation. The DMARC [RFC7489] mechanism refers to source source validation. The DMARC [RFC7489] mechanism refers to source
domains that are validated by DKIM or SPF as Authenticated domains that are validated by DKIM or SPF as Authenticated
Identifiers. DMARC requires an Authenticated Identifier to be Identifiers. DMARC requires an Authenticated Identifier to be
related to the domain found in the message's RFC5322.From header related to the domain found in the message's RFC5322.from header
field [RFC5322]. This relationship is referred to as Identifier field [RFC5322]. This relationship is referred to as Identifier
Alignment. Alignment.
DMARC allows for Identifier Alignment to be achieved in two different DMARC allows for Identifier Alignment to be achieved in two different
modes: strict and relaxed. Strict mode requires an exact match of modes: strict and relaxed. Strict mode requires an exact match of
either of the Authenticated Identifiers to the message's RFC5322.From either of the Authenticated Identifiers to the message's RFC5322.from
header field [RFC5322]. Relaxed mode allows for Identifier Alignment header field [RFC5322]. Relaxed mode allows for Identifier Alignment
if Authenticated Identifiers and the message's RFC5322.From header if Authenticated Identifiers and the message's RFC5322.from header
field [RFC5322] share the same Organizational Domain. In general, field [RFC5322] share the same Organizational Domain. In general,
interoperability issues between strict and relaxed modes are the interoperability issues between strict and relaxed modes are the
same, with strict mode constraining the application of possible same, with strict mode constraining the application of possible
solutions. The mitigations described in this document generally solutions. The mitigations described in this document generally
require a relaxed mode of Identifier Alignment. require a relaxed mode of Identifier Alignment.
DKIM provides a cryptographic means for a domain identifier to be DKIM provides a cryptographic means for a domain identifier to be
associated with a particular message. As a standalone technology associated with a particular message. As a standalone technology
DKIM identifiers are not required to be relevant to the content of a DKIM identifiers are not required to be relevant to the content of a
message. However, for a DKIM identifier to align in DMARC, the message. However, for a DKIM identifier to align in DMARC, the
signing domain of a valid signature must be part of the same signing domain of a valid signature must be part of the same
Organizational Domain as the domain in the RFC5322.From header field Organizational Domain as the domain in the RFC5322.from header field
[RFC5322]. [RFC5322].
In addition, DKIM allows for the possibility of multiple valid In addition, DKIM allows for the possibility of multiple valid
signatures. The DMARC mechanism will process Authenticated signatures. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational Authenticated Identifier is found (if any). However, operational
experience has shown that some implementations have difficulty experience has shown that some implementations have difficulty
processing multiple signatures. The impact on DMARC processing is processing multiple signatures. The impact on DMARC processing is
clear: implementations that cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
may incorrectly flag messages as "failing DMARC" and erroneously may incorrectly flag messages as "failing DMARC" and erroneously
apply DMARC based policy to otherwise conforming messages. apply DMARC based policy to otherwise conforming messages.
SPF can provide two Authenticated Identifiers. The DMARC relevant SPF can provide two Authenticated Identifiers. The DMARC relevant
Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
[RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the [RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the
RFC5321.MailFrom address is absent (as in the case of "bounce" RFC5321.mailfrom address is absent (as in the case of "bounce"
messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated
domain in RFC7208.MAILFROM must be part of the same Organizational domain in RFC7208.MAILFROM must be part of the same Organizational
Domain as the domain in the RFC5322.From header field to be aligned. Domain as the domain in the RFC5322.from header field to be aligned.
It is important to note that even when an SPF record exists for the It is important to note that even when an SPF record exists for the
domain in RFC5322.From [RFC5322], SPF will not authenticate it unless domain in RFC5322.from [RFC5322], SPF will not authenticate it unless
it is also the domain checked by SPF. Also note that the it is also the domain checked by SPF. Also note that the
RFC7208.MAILFROM definition is different from the RFC5321.MailFrom RFC7208.MAILFROM definition is different from the RFC5321.mailfrom
[RFC5321] definition. [RFC5321] definition.
2.2. Message Forwarding 2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of Section 3 describes forwarding behavior as it relates to the
behaviors. Section 3 describes forwarding behavior as it relates to components of the Internet Mail Architecture.
the components of the Internet Mail Architecture.
All forwarding behavior involves the retransmission of email. As All forwarding behavior involves the retransmission of email. As
discussed above, in order for SPF to yield an Authenticated discussed above, in order for SPF to yield an Authenticated
Identifier that is pertinent to DMARC, the domain of the Identifier that is pertinent to DMARC, the domain of the
RFC7208.MAILFROM must be in alignment with the RFC5322.From header RFC7208.MAILFROM must be in alignment with the RFC5322.from header
field. Forwarding introduces specific issues to the availability of field. Forwarding introduces specific issues to the availability of
SPF-based Authenticated Identifiers: SPF-based Authenticated Identifiers:
o If the RFC5321.MailFrom is present and the forwarder maintains the o If the RFC5321.mailfrom is present and the forwarder maintains the
original RFC5321.MailFrom, SPF validation will fail unless the original RFC5321.mailfrom, SPF validation will fail unless the
forwarder is an authorized part of the originator's email sending forwarder is an authorized part of the originator's email sending
infrastructure. If the forwarder replaces the RFC5321.MailFrom infrastructure. If the forwarder replaces the RFC5321.mailfrom
with its own domain, SPF might pass but Identifier Alignment with with its own domain, SPF might pass but Identifier Alignment with
the RFC5322.From header field will fail. the RFC5322.from header field will fail.
o If the RFC5321.MailFrom is empty (as in the case of Delivery o If the RFC5321.mailfrom is empty (as in the case of Delivery
Status Notifications), the RFC5321.Helo domain of the forwarder Status Notifications), the RFC5321.Helo domain of the forwarder
will likely be in different organizational domain than the orignal will likely be in different organizational domain than the orignal
RFC5322.From header field's domain. SPF may pass but Identifier RFC5322.from header field's domain. SPF may pass but Identifier
Alignment with the RFC5322.From header field will fail. Alignment with the RFC5322.from header field will fail.
In both cases, SPF cannot yield relevant Authenticated Identifiers, In both cases, SPF cannot yield relevant Authenticated Identifiers,
and DKIM must be relied upon to produce results that are relevant to and DKIM must be relied upon to produce results that are relevant to
DMARC. DMARC.
2.3. Message Modification 2.3. Message Modification
Modification of email content invalidates most DKIM signatures, and Modification of email content invalidates most DKIM signatures, and
many message forwarding systems modify email content. Mailing list many message forwarding systems modify email content. Mailing list
processors are a common example of such systems, but other forwarding processors are a common example of such systems, but other forwarding
skipping to change at page 7, line 17 skipping to change at page 7, line 17
o Message Transfer Agent (MTA) o Message Transfer Agent (MTA)
o Message Delivery Agent (MDA) o Message Delivery Agent (MDA)
o Message Store (MS) o Message Store (MS)
Of these components MSA, MTA, and MDA are discussed in relation to Of these components MSA, MTA, and MDA are discussed in relation to
interoperability with DMARC. interoperability with DMARC.
A Mediator is a hybrid of several component types that is given [RFC5598] Section 5 also defines a Mediator is a hybrid of several
special consideration in this section due to the unique issues component types. A Mediator is given special consideration in this
Mediators face when attempting to interoperate with DMARC. section due to the unique issues they face when attempting to
interoperate with DMARC.
3.1.1. Message Submission Agents 3.1.1. Message Submission Agents
An MSA accepts messages submitted by a Message User Agent (MUA) and An MSA accepts messages submitted by a Message User Agent (MUA) and
enforces the policies of the hosting ADministrative Management Domain enforces the policies of the hosting ADministrative Management Domain
(ADMD) and the requirements of Internet standards. (ADMD) and the requirements of Internet standards.
MSAs are split into two sub-components: MSAs are split into two sub-components:
o Author-focused MSA functions (aMSA) o Author-focused MSA functions (aMSA)
o MHS-focused MSA functions (hMSA) o MHS-focused MSA functions (hMSA)
MSA interoperability issues with DMARC begin when an aMSA accepts a MSA interoperability issues with DMARC begin when an aMSA accepts a
message where the RFC5322.From header field contains a domain that is message where the RFC5322.from header field contains a domain that is
outside of the ADMD of the MSA. The ADMD will almost certainly not outside of the ADMD of the MSA. These issues manifest themselves in
be capable of sending email that yields Authenticated Identifiers one of several ways, such as when someone uses a mail service with
aligned with the domain found in the RFC5322.From header field. their own domain but has failed to properly configure an SPF record;
Examples of this issue include "forward-to-friend" functionality or when an MUA attempts to transmit mail as someone else. Examples
of the latter issue include "forward-to-friend" functionality
commonly found on news/article websites or "send-as" functionality commonly found on news/article websites or "send-as" functionality
present on some MUAs. present on some MUAs.
When an hMSA takes responsibility for transit of a message containing When an hMSA takes responsibility for transit of a message containing
a domain in the RFC5322.From header field that is outside of the a domain in the RFC5322.from header field that is outside of the
hMSA's ADMD, the hMSA faces DMARC interoperability issues if the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
domain publishes a DMARC policy of "quarantine" or "reject". These domain publishes a DMARC policy of "quarantine" or "reject". These
issues are marked by the inherent difficulty of establishing issues are marked by the inherent difficulty of establishing
alignment with the domain present in a message's RFC5322.From header alignment with the domain present in a message's RFC5322.from header
field. Examples of this issue include: field. Examples of this issue include:
o Pseudo-open relays - a residential ISP that allows its customers o Pseudo-open relays - a residential ISP that allows its customers
to relay non-local domains through its infrastructure. to relay non-local domains through its infrastructure.
o Embedded devices - cable/DSL modems, firewalls, wireless access o Embedded devices - cable/DSL modems, firewalls, wireless access
points, printers that send email using hardcoded domains. points, printers that send email using hardcoded domains.
o Devices that send mail on behalf of a user - scanners, security o Devices that send mail on behalf of a user - scanners, security
cameras, alarms that send mail as their owner or a device user. cameras, alarms that send mail as their owner or a device user.
o Email service providers - ESPs that service customers who are o Email service providers - ESPs that service customers who are
using domains that publish a DMARC "reject" policy. using domains that publish a DMARC "reject" policy.
o Calendaring software - an invited member of an event modifies the o Calendaring software - an invited member of an event modifies the
event causing calendaring software to emit an update that claims event causing calendaring software to emit an update that claims
to come from the creator of the event. to come from the creator of the event.
3.1.2. Message Transfer Agents 3.1.2. Message Transfer Agents
MTAs relay a message until the message reaches a destination MDA. MTAs relay a message until the message reaches a destination MDA. As
such, they are in a position to introduce interoperability problems.
3.1.2.1. Message Encoding 3.1.2.1. Message Encoding
An MTA may modify the message encoding, for instance by converting An MTA may modify the message encoding, for instance by converting
8-bit MIME sections to quoted-printable 7-bit sections. This 8-bit MIME sections to quoted-printable 7-bit sections. This
modification is outside the scope of DKIM canonicalization and will modification is outside the scope of DKIM canonicalization and will
invalidate DKIM signatures that include message content. invalidate DKIM signatures that include message content.
An MTA could also re-encode the message without changing the encoding An MTA could also re-encode the message without changing the encoding
type, receiving a MIME-encoded message and producing a semantically type, receiving a MIME-encoded message and producing a semantically
skipping to change at page 9, line 35 skipping to change at page 9, line 35
and can cause DMARC interoperability issues. The SIEVE 'addheader' and can cause DMARC interoperability issues. The SIEVE 'addheader'
and 'deleteheader' filtering actions can modify messages and and 'deleteheader' filtering actions can modify messages and
invalidate DKIM signatures, removing DKIM-supplied Authenticated invalidate DKIM signatures, removing DKIM-supplied Authenticated
Identifiers as inputs to the DMARC mechanism. There are also SIEVE Identifiers as inputs to the DMARC mechanism. There are also SIEVE
extensions that modify the body. SIEVE alterations may only become extensions that modify the body. SIEVE alterations may only become
an issue when the email is reintroduced into the transport an issue when the email is reintroduced into the transport
infrastructure. infrastructure.
3.2. Mediators 3.2. Mediators
See [RFC5598] for a complete definition of Mediators. Mediators [RFC5598] forward messages through a re-posting process.
Mediators share some functionality with basic MTA relaying, but have
Mediators forward messages through a re-posting process. Mediators greater flexibility in both addressing and content modifications.
share some functionality with basic MTA relaying, but have greater
flexibility in both addressing and content modifications.
DMARC interoperability issues are common within the context of DMARC interoperability issues are common within the context of
Mediators, which are often used precisely for their ability to modify Mediators, which are often used precisely for their ability to modify
messages. messages.
The DMARC design does not cope with some Mediator functionality such The DMARC design does not cope with some Mediator functionality such
as content modifications that invalidate DKIM signatures and as content modifications that invalidate DKIM signatures and
RFC5321.MailFrom rewriting to support SPF authentication of resent RFC5321.mailfrom rewriting to support SPF authentication of resent
mail when the new Recipient receives the message from the Mediator mail when the new Recipient receives the message from the Mediator
rather than the initial organization. rather than the initial organization.
3.2.1. Alias 3.2.1. Alias
An Alias is a simple re-addressing facility that provides one or more An Alias is a simple re-addressing facility that provides one or more
new Internet Mail addresses, rather than a single, internal one. A new Internet Mail addresses, rather than a single, internal one. A
message continues through the transfer service for delivery to one or message continues through the transfer service for delivery to one or
more alternative addresses. more alternative addresses.
skipping to change at page 10, line 47 skipping to change at page 10, line 47
not assume such a relationship. not assume such a relationship.
3.2.2. ReSenders 3.2.2. ReSenders
ReSenders "splice" a message's addressing information to connect the ReSenders "splice" a message's addressing information to connect the
Author of the original message with the Recipient(s) of the new Author of the original message with the Recipient(s) of the new
message. The new Recipient sees the message as being from the message. The new Recipient sees the message as being from the
original Author, even if the Mediator adds commentary. original Author, even if the Mediator adds commentary.
Without Authenticated Identifiers aligned with the Author's Without Authenticated Identifiers aligned with the Author's
RFC5322.From header field domain, the new Recipient has no way to RFC5322.from header field domain, the new Recipient has no way to
achieve a passing DMARC evaluation. achieve a passing DMARC evaluation.
Examples of ReSenders include MUA-level forwarding by resending a Examples of ReSenders include MUA-level forwarding by resending a
message to a new recipient or by forwarding a message "inline" to a message to a new recipient or by forwarding a message "inline" to a
new recipient (this does not include forwarding a message "as an new recipient (this does not include forwarding a message "as an
attachment"). An additional example comes in the form of calendaring attachment"). An additional example comes in the form of calendaring
software that allows a meeting attendee (not the meeting organizer) software that allows a meeting attendee (not the meeting organizer)
to modify the content of an invite generating new invitations that to modify the content of an invite generating new invitations that
claim to be reissued from the meeting organizer. claim to be reissued from the meeting organizer.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
Because DMARC is already widely deployed, many operators already have Because DMARC is already widely deployed, many operators already have
mitigations in use. These mitigations vary in their effectiveness mitigations in use. These mitigations vary in their effectiveness
and side effects, but have the advantage that they are currently and side effects, but have the advantage that they are currently
available. available.
4.1.1. Mitigations for Senders 4.1.1. Mitigations for Senders
4.1.1.1. Identifier Alignment 4.1.1.1. Identifier Alignment
o MTAs handling multiple domains may choose to change o MTAs handling multiple domains may choose to change
RFC5321.MailFrom to align with RFC5322.From to improve SPF RFC5321.mailfrom to align with RFC5322.from to improve SPF
usability for DMARC. usability for DMARC.
o MTAs handling multiple domains may also choose to align o MTAs handling multiple domains may also choose to align
RFC5321.HELO/EHLO to RFC5322.From, particularly when sending non- RFC5321.HELO/EHLO to RFC5322.from, particularly when sending non-
delivery (also known as "bounce") messages (ref [RFC5321] section delivery (also known as "bounce") messages (ref [RFC5321] section
3.6.3). Dynamically adjusting the RFC5321.HELO based on the 3.6.3). Dynamically adjusting the RFC5321.HELO based on the
RFC5322.From may not be possible for some MTA software. RFC5322.from may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces with an aligned domain to o MTAs may choose to DKIM sign bounces with an aligned domain to
allow DKIM-based DMARC pass. allow DKIM-based DMARC pass.
o MTAs sending email on behalf of multiple domains may require o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid SPF Domain Owners to provide DKIM keys to use DKIM to avoid SPF
validation issues, given the requirement for DMARC alignment with validation issues, given the requirement for DMARC alignment with
the RFC5322.From header field. Managing DKIM keys with a third the RFC5322.from header field. Managing DKIM keys with a third
party has security risks that should be carefully managed (see party has security risks that should be carefully managed (see
also [RFC6376] section 8). Methods involving CNAMEs and/or also [RFC6376] section 8). Methods involving CNAMEs and/or
subdomains may alleviate some risks. subdomains may alleviate some risks.
o Senders who are sending on behalf of users in other Administrative o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's Domains may choose to use an RFC5322.from under the sender's
control. The new From can be either a forwarding address in a control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with domain controlled by the Sender, or a placeholder address, with
the original user's address in a RFC5322.Reply-to header field. the original user's address in a RFC5322.Reply-to header field.
However, performing this modification may cause the recipient's However, performing this modification may cause the recipient's
MUA to deviate from customary behavior. MUA to deviate from customary behavior.
o 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.
o Senders can use domains with distinct DMARC policies for email o Senders can use domains with distinct DMARC policies for email
sent directly and email known to use indirect mail flows. sent directly and email known to use indirect mail flows.
However, for known brands, all active domains are likely to be However, for known brands, all active domains are likely to be
targeted equally by abusers. targeted equally by abusers.
4.1.1.2. Message Modification 4.1.1.2. Message Modification
o Senders can maximize survivability of DKIM signatures by limiting o Senders can maximize survivability of DKIM signatures by limiting
the header fields they sign and using relaxed canonicalization. the header fields they sign and using relaxed canonicalization.
Using the DKIM length tag to allow appended signatures is Using the DKIM length tag to allow appended signatures is
skipping to change at page 16, line 29 skipping to change at page 16, line 34
o Receivers can amalgamate data from their user base to create lists o Receivers can amalgamate data from their user base to create lists
of forwarders and use such lists to inform DMARC local policy of forwarders and use such lists to inform DMARC local policy
overrides. This process may be easier for large receivers where overrides. This process may be easier for large receivers where
data and resources to create such lists are more readily available data and resources to create such lists are more readily available
than at smaller sites where the recipient footprint and other than at smaller sites where the recipient footprint and other
resources may be scarce. resources may be scarce.
4.1.3. Mitigations for ReSenders 4.1.3. Mitigations for ReSenders
4.1.3.1. Changes to the RFC5322.From 4.1.3.1. Changes to the RFC5322.from
Many ReSender issues can be avoided by using an RFC5322.From header Many ReSender issues can be avoided by using an RFC5322.from header
field under the ReSender's control, instead of the initial field under the ReSender's control, instead of the initial
RFC5322.From. This will correct identifier alignment issues and RFC5322.from. This will correct identifier alignment issues and
allow arbitrary message modification as long as the ReSender signs allow arbitrary message modification as long as the ReSender signs
the message with an aligned domain signature. When ReSenders change the message with an aligned domain signature. When ReSenders change
the RFC5322.From, it is desirable to preserve the information about the RFC5322.from, it is desirable to preserve the information about
the original initiator of the message. the original initiator of the message.
A first option is to use the Original-From [RFC5703] (or X-Original- A first option is to use the Original-From [RFC5703] (or X-Original-
From) header field for this purpose in various contexts (X- header From) header field for this purpose in various contexts (X- header
fields name are discouraged by [RFC6648]). However, handling of fields name are discouraged by [RFC6648]). However, handling of
Original-From (or X-Original-From) is not defined anywhere. It is Original-From (or X-Original-From) is not defined anywhere. It is
not currently used consistently or displayed to the user, and in any not currently used consistently or displayed to the user, and in any
situation where it is used, it is a new unauthenticated identifier situation where it is used, it is a new unauthenticated identifier
available for exploitation unless included within the scope of the available for exploitation unless included within the scope of the
new DKIM signature(s). new DKIM signature(s).
Another option for ReSenders is to rewrite the RFC5322.From header Another option for ReSenders is to rewrite the RFC5322.from header
field address to a locally controlled address which will be forwarded field address to a locally controlled address which will be forwarded
back to the original sender (subject to its own ReSender forwarding back to the original sender (subject to its own ReSender forwarding
mitigations!). mitigations!).
4.1.3.2. Avoiding Message Modification 4.1.3.2. Avoiding Message Modification
o Forwarders can choose to add email header fields instead of o Forwarders can choose to add email header fields instead of
modifying existing headers or bodies, for instance to indicate a modifying existing headers or bodies, for instance to indicate a
message may be spam. message may be spam.
skipping to change at page 17, line 25 skipping to change at page 17, line 30
o Forwarders can choose to reject messages with suspect or harmful o Forwarders can choose to reject messages with suspect or harmful
content instead of modifying them. content instead of modifying them.
4.1.3.3. Mailing Lists 4.1.3.3. Mailing Lists
[RFC6377] provides some guidance on using DKIM with Mailing lists. [RFC6377] provides some guidance on using DKIM with Mailing lists.
The following mitigation techniques can be used to ease The following mitigation techniques can be used to ease
interoperability issues with DMARC and Mailing lists: interoperability issues with DMARC and Mailing lists:
o Configuring the Mailing List Manager (MLM) to alter the o Configuring the Mailing List Manager (MLM) to alter the
RFC5322.From header field to use the domain of the MLM is a RFC5322.from header field to use the domain of the MLM is a
mitigation policy that is now present in several different Mailing mitigation policy that is now present in several different Mailing
List software distributions. Since most list subscribers prefer List software distributions. Since most list subscribers prefer
to know the identity of the author of the original message, to know the identity of the author of the original message,
typically this information may be provided in the display name typically this information may be provided in the display name
part of the RFC5322.From header field. This display name needs to part of the RFC5322.from header field. This display name needs to
be carefully crafted as to not collide with the original display be carefully crafted as to not collide with the original display
name of the author, nor contain something that looks like an email name of the author, nor contain something that looks like an email
address or domain name. These modifications may to some extent address or domain name. These modifications may to some extent
defeat the purpose of DMARC itself. It may make it difficult to defeat the purpose of DMARC itself. It may make it difficult to
ensure that users of all email clients can easily reply to the ensure that users of all email clients can easily reply to the
author, the list, or all using the email client features provided author, the list, or all using the email client features provided
for that purpose. Use of RFC5322.Reply-To header field can for that purpose. Use of RFC5322.Reply-To header field can
alleviate this problem depending on whether the mailing list is alleviate this problem depending on whether the mailing list is
configured to reply-to-list, reply-to-author or reply-to-fixed- configured to reply-to-list, reply-to-author or reply-to-fixed-
address, however it is important to note that this header field address, however it is important to note that this header field
can take multiple email addresses. When altering the RFC5322.From can take multiple email addresses. When altering the RFC5322.from
there are three possibilities: there are three possibilities:
1. change it to put the mailing list email address, 1. change it to put the mailing list email address,
2. change it to a locally-defined address which will be forwarded 2. change it to a locally-defined address which will be forwarded
back to the original sender, or back to the original sender, or
3. "break" the address by modifying the domain to a non-existent 3. "break" the address by modifying the domain to a non-existent
domain (such as by adding a suffix like ".invalid".) domain (such as by adding a suffix like ".invalid".)
The latter modification may create issues because it is an invalid The latter modification may create issues because it is an invalid
domain name, and some MTAs may pay particular attention to the domain name, and some MTAs may pay particular attention to the
validity of email addresses in RFC5322.From and the reputation of validity of email addresses in RFC5322.from and the reputation of
the domains present there. the domains present there.
o Configuring the MLM to "wrap" the message in a MIME message/rfc822 o Configuring the MLM to "wrap" the message in a MIME message/rfc822
part and to send as the Mailing List email address. Many email part and to send as the Mailing List email address. Many email
clients (as of August 2015), especially mobile clients, have clients (as of August 2015), especially mobile clients, have
difficulty reading such messages and this is not expected to difficulty reading such messages and this is not expected to
change soon. change soon.
o Configuring the MLM to not modify the message so that the DKIM o Configuring the MLM to not modify the message so that the DKIM
signature remains valid. Some Mailing Lists are set up this way signature remains valid. Some Mailing Lists are set up this way
skipping to change at page 19, line 32 skipping to change at page 19, line 35
In practice a number of operators are using strict alignment mode in In practice a number of operators are using strict alignment mode in
DMARC in order to avoid receiving new and innovative forms of DMARC in order to avoid receiving new and innovative forms of
unwanted and unauthentic email through systems purporting to be unwanted and unauthentic email through systems purporting to be
mailing list handlers. The receiving ADMD has no knowledge of which mailing list handlers. The receiving ADMD has no knowledge of which
lists the user has subscribed to and which they have not. One avenue 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 of exploration would be for the user to authorize mailing lists as
proxies for authentication, at which point the receiving ADMD would proxies for authentication, at which point the receiving ADMD would
be vesting some trust in the mailing list service. The creators of be vesting some trust in the mailing list service. The creators of
DKIM foresaw precisely this possibility at the time by not tightly DKIM foresaw precisely this possibility at the time by not tightly
binding any semantics to the RFC5322.From header field. Some binding any semantics to the RFC5322.from header field. Some
experimental work has taken place in this area, as mentioned above. experimental work has taken place in this area, as mentioned above.
Additional work might examine a new communication path to the user to Additional work might examine a new communication path to the user to
authorize some form of transitive trust. authorize some form of transitive trust.
5. IANA Considerations 5. IANA Considerations
This document contains no actions for IANA. [RFC Editor: Please This document contains no actions for IANA. [RFC Editor: Please
delete this section prior to publication.] delete this section prior to publication.]
6. Security Considerations 6. Security Considerations
This document is an analysis of DMARC's impact on indirect email This document is an analysis of DMARC's impact on indirect email
flows. It describes the possibility of accidental denial-of-service flows. It describes the possibility of accidental denial-of-service
that can be created by rejections of messages by DMARC-aware Mail that can be created by rejections of messages by DMARC-aware Mail
Receivers. Receivers.
In Section 4.1.1.1, discusses the importance of appropriate DKIM key In Section 4.1.1.1, discusses the importance of appropriate DKIM key
management vis a vis third party email senders. management vis a vis third party email senders.
In Section 4.1.3.3, warns that rewriting the RFC5322.From header In Section 4.1.3.3, warns that rewriting the RFC5322.from header
field and changing the domain name should not be done with any field and changing the domain name should not be done with any
domain. domain.
7. Acknowledgments 7. Acknowledgments
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull,
Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the
IETF DMARC Working Group's wiki page listing all known IETF DMARC Working Group's wiki page listing all known
interoperability issues with DMARC and indirect email flows. interoperability issues with DMARC and indirect email flows.
skipping to change at page 20, line 29 skipping to change at page 20, line 32
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <http://www.rfc-editor.org/info/rfc2045>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
3463, DOI 10.17487/RFC3463, January 2003, RFC 3463, DOI 10.17487/RFC3463, January 2003,
<http://www.rfc-editor.org/info/rfc3463>. <http://www.rfc-editor.org/info/rfc3463>.
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, DOI 10.17487/RFC5228, Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
January 2008, <http://www.rfc-editor.org/info/rfc5228>. January 2008, <http://www.rfc-editor.org/info/rfc5228>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Tests, Iteration, Extraction, Replacement, and Enclosure", Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, DOI 10.17487/RFC5703, October 2009, RFC 5703, DOI 10.17487/RFC5703, October 2009,
<http://www.rfc-editor.org/info/rfc5703>. <http://www.rfc-editor.org/info/rfc5703>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <http://www.rfc-editor.org/info/rfc6377>. September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, DOI 10.17487/ Application Protocols", BCP 178, RFC 6648,
RFC6648, June 2012, DOI 10.17487/RFC6648, June 2012,
<http://www.rfc-editor.org/info/rfc6648>. <http://www.rfc-editor.org/info/rfc6648>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>. <http://www.rfc-editor.org/info/rfc7208>.
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC [RFC7372] Kucherawy, M., "Email Authentication Status Codes",
7372, DOI 10.17487/RFC7372, September 2014, RFC 7372, DOI 10.17487/RFC7372, September 2014,
<http://www.rfc-editor.org/info/rfc7372>. <http://www.rfc-editor.org/info/rfc7372>.
8.2. Informative References 8.2. Informative References
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, DOI 10.17487/ Message Authentication Status", RFC 7601,
RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
Authors' Addresses Authors' Addresses
Franck Martin (editor) Franck Martin (editor)
LinkedIn LinkedIn
Mountain View, CA Mountain View, CA
USA USA
Email: fmartin@linkedin.com Email: fmartin@linkedin.com
Eliot Lear (editor) Eliot Lear (editor)
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Tim Draegen (editor) Tim Draegen (editor)
 End of changes. 54 change blocks. 
73 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/