draft-ietf-dmarc-interoperability-18.txt   rfc7960.txt 
DMARC F. Martin, Ed. Internet Engineering Task Force (IETF) F. Martin, Ed.
Internet-Draft LinkedIn Request for Comments: 7960 LinkedIn
Intended status: Informational E. Lear, Ed. Category: Informational E. Lear, Ed.
Expires: January 19, 2017 Cisco Systems GmbH ISSN: 2070-1721 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
July 18, 2016 September 2016
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues between Domain-based Message Authentication,
draft-ietf-dmarc-interoperability-18 Reporting, and Conformance (DMARC) and Indirect Email Flows
Abstract Abstract
DMARC (Domain-based Message Authentication, Reporting, and Domain-based Message Authentication, Reporting, and Conformance
Conformance) introduces a mechanism for expressing domain-level (DMARC) introduces a mechanism for expressing domain-level policies
policies and preferences for email message validation, disposition, and preferences for email message validation, disposition, and
and reporting. However, the DMARC mechanism enables potentially reporting. However, the DMARC mechanism enables potentially
disruptive interoperability issues when messages do not flow directly disruptive interoperability issues when messages do not flow directly
from the author's administrative domain to the final recipients. from the author's administrative domain to the final Recipients.
Collectively these email flows are referred to as indirect email Collectively, these email flows are referred to as "indirect email
flows. This document describes these interoperability issues, and flows". This document describes these interoperability issues and
presents possible methods for addressing them. presents possible methods for addressing them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 19, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7960.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions .......................................4
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues ...............................4
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Alignment .......................................4
2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5 2.1.1. DKIM Identifier(s) ..................................5
2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 2.1.2. SPF Identifier(s) ...................................6
2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6 2.1.3. Multiple RFC5322.From Addresses .....................6
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6 2.2. Message Forwarding .........................................6
2.3. Message Modification . . . . . . . . . . . . . . . . . . 7 2.3. Message Modification .......................................7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
3.1. Message Handling System . . . . . . . . . . . . . . . . . 8 3.1. Message Handling System ....................................8
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8 3.1.1. Message Submission Agents ...........................8
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9 3.1.2. Message Transfer Agents .............................9
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9 3.1.2.1. Message Encoding ...........................9
3.1.2.2. Header Standardization . . . . . . . . . . . . . 10 3.1.2.2. Header Standardization ....................10
3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10 3.1.2.3. Content Validation ........................10
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10 3.1.3. Message Delivery Agents ............................10
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Mediators .................................................11
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Alias ..............................................11
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. ReSenders ..........................................12
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Mailing Lists ......................................12
3.2.3.1. Mailing List Operational Effects . . . . . . . . 13 3.2.3.1. Mailing List Operational Effects ..........13
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4. Gateways ...........................................13
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 14 3.2.5. Boundary Filters ...................................14
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Combinations ..............................................15
4. Possible Mitigations of Interoperability Issues . . . . . . . 15 4. Possible Mitigations of Interoperability Issues ................15
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 16 4.1. Mitigations in Current Use ................................16
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16 4.1.1. Mitigations for Senders ............................16
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.1.1. Identifier Alignment ......................16
4.1.1.2. Message Modification . . . . . . . . . . . . . . 17 4.1.1.2. Message Modification ......................17
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17 4.1.2. Mitigations for Receivers ..........................17
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17 4.1.2.1. Identifier Alignment ......................17
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17 4.1.2.2. Policy Override ...........................17
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17 4.1.3. Mitigations for ReSenders ..........................18
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 18 4.1.3.1. Changes to the RFC5322.From ...............18
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18 4.1.3.2. Avoiding Message Modification .............18
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 4.1.3.3. Mailing Lists .............................18
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 20 4.2. Proposed and In-Progress Mitigations ......................20
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New
Paths Between MUAs . . . . . . . . . . . . . . . . . 20 Communication Paths between MUAs ...................21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations ........................................21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. References .....................................................22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Normative References ......................................22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Informative References ....................................23
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Example SPF Bounce ...................................24
8.2. Informative References . . . . . . . . . . . . . . . . . 23 A.1. Initial Message ...........................................24
Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 23 A.2. Notification Message ......................................25
A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments ...................................................26
A.2. Notification message . . . . . . . . . . . . . . . . . . 23 Authors' Addresses ................................................27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
DMARC [RFC7489] introduces a mechanism for expressing domain-level DMARC [RFC7489] introduces a mechanism for expressing domain-level
policies and preferences for message validation, disposition, and policies and preferences for message validation, disposition, and
reporting. The DMARC mechanism, especially when employed with reporting. The DMARC mechanism, especially when employed with
restrictive policies, encounters several different types of restrictive policies, encounters several different types of
interoperability issues due to third-party message sourcing, message interoperability issues due to third-party message sourcing, message
transformation, or rerouting. In particular, DMARC with restrictive transformation, or rerouting. In particular, DMARC with restrictive
policies causes problems for many mailing lists. policies causes problems for many Mailing Lists.
At the time of the writing of this document, the DMARC base At the time of writing this document, the DMARC base specification
specification is published as Informational RFC 7489 [RFC7489] and has been published as Informational RFC 7489 [RFC7489] and has seen
has seen significant deployment within the email community. significant deployment within the email community.
Cases in which email does not flow directly from the author's Cases in which email does not flow directly from the author's
administrative domain to the recipient's domain(s) are collectively administrative domain to the recipient's domain(s) are collectively
referred to in this document as indirect email flows. Due to referred to in this document as "indirect email flows". Due to
existing and increasing adoption of DMARC, the impact of DMARC-based existing and increasing adoption of DMARC, the impact of DMARC-based
email rejection policies on indirect email flows can be significant email rejection policies on indirect email flows can be significant
for a select subset of general email traffic. for a select subset of general email traffic.
Several known causes of interoperability issues are presented, Several known causes of interoperability issues are presented,
followed by a description of components within the Internet Mail followed by a description of components within the Internet Mail
Architecture [RFC5598] where interoperability issues can arise. Architecture [RFC5598] where interoperability issues can arise.
Finally, known and possible methods for addressing interoperability Finally, known and possible methods for addressing interoperability
issues are presented. There are often multiple ways to address any issues are presented. There are often multiple ways to address any
given interoperability issue. While this document strives to be given interoperability issue. While this document strives to be
comprehensive in its review, it should not be treated as complete. comprehensive in its review, it should not be treated as complete.
Note that some practices which are in use at the time of this
document may or may not be "best practices", especially as future Note that some practices that are in use at the time of this document
standards evolve. may or may not be "best practices", especially as future standards
evolve.
1.1. Document Conventions 1.1. Document Conventions
The notation used in this document for structured fields is taken The notation used in this document for structured fields is taken
from [RFC5598] section 1.3. from [RFC5598], Section 1.3.
The term "notification message" [RFC5321] section 4.5.5 is used to The term "notification message" ([RFC5321], Section 4.5.5) is used to
refer to a message with a null RFC5321.MailFrom. refer to a message with a null RFC5321.MailFrom.
The terms "Organizational Domain" and "Authenticated Identifiers" are The terms "Organizational Domain" and "Authenticated Identifiers" are
specified in DMARC [RFC7489] section 3. 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 2. Causes of Interoperability Issues
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 that assert a "p=none" policy and email messages
passes standard DMARC validation do not have any interoperability that pass standard DMARC validation do not have any interoperability
issues. issues.
Email messages that do not conform to IETF 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. discussed in this document.
The rest of this section describes several conceptual causes of The rest of this section describes several conceptual causes of
interoperability issues. interoperability issues.
2.1. Identifier Alignment 2.1. Identifier Alignment
Note to operators and administrators: The identifiers which are used Note to operators and administrators: The identifiers that are used
by SPF are technical components of the transport process for SMTP. by the Sender Policy Framework (SPF) are technical components of the
They may or may not, as described below, bear a meaningful transport process for SMTP. They may or may not, as described below,
relationship to the content or source of the message itself. This bear a meaningful relationship to the content or source of the
"relationship by proximity" can be a point of confusion for non- message itself. This "relationship by proximity" can be a point of
technical end users, either recipients or senders. confusion for non-technical end users, either recipients or senders.
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF
source validation. The DMARC [RFC7489] specification refers to [RFC7208] to perform message source validation. The DMARC [RFC7489]
source domains that are validated by DKIM or SPF as "Authenticated specification refers to source domains that are validated by DKIM or
Identifiers". To be used by DMARC an "Authenticated Identifier" must SPF as "Authenticated Identifiers". To be used by DMARC, an
also be related to the domain found in the message's RFC5322.From "Authenticated Identifier" must also be related to the domain found
header field [RFC5322]. This relationship between an Authenticated in the message's RFC5322.From header field [RFC5322]. This
Identifier's domain and the domain of the RFC5322.From is referred to relationship between an Authenticated Identifier's domain and the
as "Identifier Alignment". domain of the RFC5322.From is referred to as "Identifier Alignment".
DMARC allows for Identifier Alignment to be determined in two DMARC allows for Identifier Alignment to be determined in two
different modes: strict and relaxed. Strict mode requires an exact different modes: strict and relaxed. Strict mode requires an exact
match between the domain of any of the Authenticated Identifiers and match between the domain of any of the Authenticated Identifiers and
the message's RFC5322.From header field [RFC5322]. Relaxed mode the message's RFC5322.From header field [RFC5322]. Relaxed mode
allows for Identifier Alignment if Authenticated Identifiers and the allows for Identifier Alignment if Authenticated Identifiers and the
message's RFC5322.From header field [RFC5322] share the same message's RFC5322.From header field [RFC5322] share the same
Organizational Domain. In general, DMARC interoperability issues are Organizational Domain. In general, DMARC interoperability issues are
the same for both strict and relaxed alignment, but strict alignment the same for both strict and relaxed alignment, but strict alignment
constrains the possible solutions because of the more rigorous constrains the possible solutions because of the more rigorous
matching requirement. Some of mitigations described in this document matching requirement. Some of the mitigations described in this
only work with the relaxed mode of Identifier Alignment. document only work with the relaxed mode of Identifier Alignment.
2.1.1. DKIM Identifier(s) 2.1.1. DKIM Identifier(s)
DKIM provides a cryptographic means for one or more domain identifier DKIM provides a cryptographic means for one or more domain
to be associated with a particular message. As a standalone identifiers to be associated with a particular message. As a
technology DKIM identifiers are not required to be related to the standalone technology, DKIM identifiers are not required to be
source of the message's content. However, for a DKIM identifier to related to the source of the message's content. However, for a DKIM
align in DMARC, the signing domain of a valid signature must be part identifier to align in DMARC, the signing domain of a valid signature
of the same Organizational Domain as the domain in the RFC5322.From must be part of the same Organizational Domain as the domain in the
header field [RFC5322]. RFC5322.From header field [RFC5322].
In addition, DKIM allows for the possibility of multiple valid In addition, DKIM allows for the possibility of multiple valid
signatures. These multiple signatures may be from the same or signatures. These multiple signatures may be from the same or
different domains, there are no restrictions within the DKIM different domains; there are no restrictions within the DKIM
specification. The DMARC mechanism will process Authenticated specification. 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. Implementations that cannot process processing multiple signatures. Implementations that cannot process
multiple DKIM signatures may incorrectly flag messages as "not multiple DKIM signatures may incorrectly flag messages as "not
passing" (DMARC alignment) and erroneously apply DMARC-based policy passing" (DMARC alignment) and erroneously apply DMARC-based policy
to otherwise conforming messages. to otherwise conforming messages.
2.1.2. SPF Identifier(s) 2.1.2. SPF Identifier(s)
The SPF specification [RFC7208] defines two Authenticated Identifiers The SPF specification [RFC7208] defines two Authenticated Identifiers
for each message. These identifiers derive from: for each message. These identifiers derive from:
a. the RFC5321.MailFrom [RFC5321] domain, and a. the RFC5321.MailFrom [RFC5321] domain, and
b. the RFC5321.HELO/.EHLO SMTP domain. b. the RFC5321.HELO/.EHLO SMTP domain.
In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
defined to be based on RFC5321.MailFrom unless that value is absent defined to be based on RFC5321.MailFrom unless that value is absent
(as in the case of notification messages) in which case, the second (as in the case of notification messages), in which case, the second
(RFC5321.HELO/.EHLO) identifier value is used. This "fallback" (RFC5321.HELO/.EHLO) identifier value is used. This "fallback"
definition has occasionally been misunderstood by operators of MTA definition has occasionally been misunderstood by operators of MTA
systems since notification messages are often an "automatic" feature systems since notification messages are often an "automatic" feature
of MTA software. Some MTA software does not provide the ability to of MTA software. Some MTA software does not provide the ability to
apply a DKIM signature to such notification messages. apply a DKIM signature to such notification messages.
See Appendix A for an example treatment of this scenario. See Appendix A for an example treatment of this scenario.
For the purposes of DMARC validation/alignment, the hybrid For the purposes of DMARC validation/alignment, the hybrid
RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
skipping to change at page 6, line 32 skipping to change at page 6, line 41
2.1.3. Multiple RFC5322.From Addresses 2.1.3. Multiple RFC5322.From Addresses
[RFC5322] permits only one From header field, but it may contain [RFC5322] permits only one From header field, but it may contain
multiple mailboxes. Since this is an extremely rare usage, DMARC multiple mailboxes. Since this is an extremely rare usage, DMARC
specifies that the handling of this situation is implementation specifies that the handling of this situation is implementation
dependent. dependent.
Because the presence of multiple domains can be used by an attacker Because the presence of multiple domains can be used by an attacker
(an attacker could add their domain to the RFC5322.From field, (an attacker could add their domain to the RFC5322.From field,
provide arbitrary new content, and sign the message) the DMARC provide arbitrary new content, and sign the message), the DMARC
specification recommends that the strictest policy be applied to such specification recommends that the strictest policy be applied to such
messages (section 6.6.1 [RFC7489]). messages (Section 6.6.1 of [RFC7489]).
2.2. Message Forwarding 2.2. Message Forwarding
Section 3 describes forwarding behavior as it relates to the Section 3 describes forwarding behavior as it relates to the
components of the Internet Mail Architecture. components of the Internet Mail Architecture.
All forwarding operations involve the retransmission of email. As All forwarding operations involve 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/.EHLO domain of the Status Notifications), the RFC5321.HELO/.EHLO domain of the
forwarder will likely be in a different organizational domain than forwarder will likely be in a different Organizational Domain than
the original RFC5322.From header field's domain. SPF may pass but the original RFC5322.From header field's domain. SPF may pass,
Identifier Alignment with the RFC5322.From header field will fail. but Identifier 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
systems also make modifications. systems also make modifications.
Although DKIM provides a length flag so that content can be appended Although DKIM provides a length flag so that content can be appended
without invalidating the signature, in practice, particularly with without invalidating the signature, in practice, particularly with
MIME-encoded [RFC2045] messages, a mailing list processor will do MIME-encoded [RFC2045] messages, a Mailing List processor will do
more than simply append content (see Section 5.3 of [RFC5598] for more than simply append content (see Section 5.3 of [RFC5598] for
details). Furthermore, the length flag is seldom used due to details). Furthermore, the length flag is seldom used due to
security issues (see Section 8.2 of [RFC6376] for additional security security issues (see Section 8.2 of [RFC6376] for additional security
considerations), therefore, this method is only here mentioned for considerations). Therefore, this method is only mentioned here for
completeness. completeness.
DKIM describes two canonicalizations for use when preparing header DKIM describes two canonicalizations for use when preparing the
and body for DKIM processing: simple and relaxed. The latter is header and body for DKIM processing: simple and relaxed. The latter
designed to accommodate trivial modifications to whitespace and is designed to accommodate trivial modifications to whitespace and
folding which, at least in the header case, generally have no folding that, at least in the header case, generally have no semantic
semantic significance. However, the relaxed canonicalization is more significance. However, the relaxed canonicalization is more
computationally intensive and may not have been preferred in the computationally intensive and may not have been preferred in the
early deployment of DKIM, leaving some deployments using the less early deployment of DKIM, leaving some deployments using the less
forgiving "simple" canonicalization. While the prevalence is forgiving "simple" canonicalization. While the prevalence is
unknown, there are some DKIM verifiers which have problems evaluating unknown, there are some DKIM verifiers that have problems evaluating
relaxed canonicalization correctly. relaxed canonicalization correctly.
3. Internet Mail Architecture, DMARC, and Indirect Email Flows 3. Internet Mail Architecture, DMARC, and Indirect Email Flows
This section describes components within the Internet Mail This section describes components within the Internet Mail
Architecture [RFC5598] where interoperability issues between DMARC Architecture [RFC5598] where interoperability issues between DMARC
and indirect email flows can be found. and indirect email flows can be found.
3.1. Message Handling System 3.1. Message Handling System
skipping to change at page 8, line 22 skipping to change at page 8, line 28
o Message User Agent (MUA) o Message User Agent (MUA)
o Message Submission Agent (MSA) o Message Submission Agent (MSA)
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.
[RFC5598] Section 5 also defines a Mediator as a hybrid of several Section 5 of [RFC5598] also defines a Mediator as a hybrid of several
component types. A Mediator is given special consideration in this component types. A Mediator is given special consideration in this
section due to the unique issues they face when attempting to section due to the unique issues they face when attempting to
interoperate with DMARC. 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. This situation manifests in one of outside of the ADMD of the MSA. This situation manifests in one of
several ways, such as when someone uses a mail service with their own several ways, such as when someone uses a mail service with their own
domain but has failed to properly configure an SPF record; or when an domain but has failed to properly configure an SPF record or when an
MUA attempts to transmit mail as someone else. Examples of the MUA attempts to transmit mail as someone else. Examples of the
latter situation include "forward-to-friend" functionality commonly latter situation include "forward-to-friend" functionality commonly
found on news/article websites or "send-as" functionality present on found on news/article websites or "send-as" functionality present on
some MUAs. 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 Partially-open relays - a residential ISP that allows its o Partially open relays - a residential ISP that allows its
customers to relay non-local domains through its infrastructure. customers 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, and 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, and 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 the calendaring software to emit an update that
to come from the creator of the event. claims 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.
Some common message handling strategies break the integrity of DKIM Some common message-handling strategies break the integrity of DKIM
signatures. A restrictive DMARC policy along with a broken DKIM signatures. A restrictive DMARC policy along with a broken DKIM
signature causes latent interoperability problems to become overt signature causes latent interoperability problems to become overt
problems. 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
and semiotically-equivalent MIME body that is not identical to the and semiotically equivalent MIME body that is not identical to the
original. This is characteristic of systems that use some other original. This is characteristic of systems that use some other
message representation internally. message representation internally.
3.1.2.2. Header Standardization 3.1.2.2. Header Standardization
An MTA may rewrite headers to bring them into compliance with An MTA may rewrite headers to bring them into compliance with
existing RFCs. For example, some common MTAs will correct existing RFCs. For example, some common MTAs will correct
comprehensible but non-compliant date formats to compliant ones. comprehensible but non-compliant date formats to compliant ones.
Header rewriting is outside the scope of DKIM canonicalization and Header rewriting is outside the scope of DKIM canonicalization and
will invalidate DKIM signatures. All downstream DMARC processing will invalidate DKIM signatures. All downstream DMARC processing
with be unable to utilize DKIM to yield Authenticated Identifiers due with be unable to utilize DKIM to yield Authenticated Identifiers due
to header rewriting. to header rewriting.
Providing solutions for issues relating to non RFC-compliant emails Providing solutions for issues relating to non-RFC-compliant emails
is outside the scope of this document. is outside the scope of this document.
3.1.2.3. Content Validation 3.1.2.3. Content Validation
An MTA may also implement security-motivated changes to the content An MTA may also implement security-motivated changes to the content
of email messages, dropping or altering sections of messages, causing of email messages, dropping or altering sections of messages, causing
breakage of DKIM signatures breakage of DKIM signatures.
3.1.3. Message Delivery Agents 3.1.3. Message Delivery Agents
The MDA transfers a message from the MHS to a mailbox. Like the MSA, The MDA transfers a message from the MHS to a mailbox. Like the MSA,
the MDA consists of two sub-components: the MDA consists of two sub-components:
o MHS-focused MDA functions (hMDA) o MHS-focused MDA functions (hMDA)
o Recipient-focused MDA functions (rMDA) o Recipient-focused MDA functions (rMDA)
Both the hMDA and the rMDA can redirect a message to an alternative Both the hMDA and the rMDA can redirect a message to an alternative
address. DMARC interoperability issues related to redirecting of address. DMARC interoperability issues related to redirecting of
messages are described in Section 3.2. messages are described in Section 3.2.
SIEVE [RFC5228] functionality often lives in the rMDA sub-component Sieve [RFC5228] functionality often lives in the rMDA sub-component
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 [RFC5703] that modify the body. SIEVE alterations may extensions [RFC5703] that modify the body. Sieve alterations may
only become an issue when the email is reintroduced into the only become an issue when the email is reintroduced into the
transport infrastructure. transport infrastructure.
3.2. Mediators 3.2. Mediators
Mediators [RFC5598] forward messages through a re-posting process. Mediators [RFC5598] forward messages through a re-posting process.
Mediators share some functionality with basic MTA relaying, but have Mediators share some functionality with basic MTA relaying but have
greater flexibility in both addressing and content modifications. 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 re-sent
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.
Aliases can be implemented by mailbox-level forwarding (e.g., through Aliases can be implemented by mailbox-level forwarding (e.g., through
"dot-forwarding") or SIEVE-level forwarding (through the SIEVE "dot-forwarding"), Sieve-level forwarding (through the Sieve
'redirect' action) or other methods. When an Alias preserves message "redirect" action), or other methods. When an Alias preserves
content and does not make significant header changes, DKIM signatures message content and does not make significant header changes, DKIM
may remain valid. However, Aliases often extend the delivery path signatures may remain valid. However, Aliases often extend the
outside of the scope covered by the originating ADMD's SPF record(s). delivery path outside of the scope covered by the originating ADMD's
SPF record(s).
Examples of Aliasing include: Examples of Aliasing include:
o Forwarding email between free email (freemail) providers to try o Forwarding email between free email (freemail) providers to try
different interfaces while maintaining an original email address; different interfaces while maintaining an original email address;
o Consolidating many email addresses into a single account to o Consolidating many email addresses into a single account to
centralize processing; centralize processing; and
o Services that provide "activity-based", "role-based" , "vanity" or o Services that provide "activity-based", "role-based", "vanity", or
"temporary" email addresses such as universities and professional "temporary" email addresses such as universities and professional
associations. For instance professional or alumni institutions associations. For instance, professional or alumni institutions
may offer their members an alias for the duration of their may offer their members an Alias for the duration of their
membership but may not want to deal with the long term storage of membership but may not want to deal with the long-term storage of
emails. emails.
In most cases, the aMSA providing Alias services has no In most cases, the aMSA providing Alias services has no
administrative relationship to the ADMD of the originator or the administrative relationship to the ADMD of the originator or the
final recipient, so solutions to Alias-related DMARC failure should Final Recipient, so solutions to Alias-related DMARC failure should
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.
3.2.3. Mailing Lists 3.2.3. Mailing Lists
A Mailing List receives messages as an explicit addressee and then A Mailing List receives messages as an explicit addressee and then
reposts them to a list of subscribed members. The Mailing List reposts them to a list of subscribed members. The Mailing List
performs a task that can be viewed as an elaboration of the ReSender performs a task that can be viewed as an elaboration of the ReSender
actions. actions.
Mailing Lists share the same DMARC interoperability issues as Mailing Lists share the same DMARC interoperability issues as
ReSenders (Section 3.2.2), and very commonly modify headers or ReSenders (Section 3.2.2) and very commonly modify headers or message
message content in ways that will cause DKIM to fail, including: content in ways that will cause DKIM to fail, including:
o prepending the RFC5322.Subject header field with a tag, to allow o prepending the RFC5322.Subject header field with a tag, to allow
the recipient to easily identify the mailing list within a subject the Recipient to easily identify the Mailing List within a subject
line listing; line listing;
o adding a footer to the email body to contain administrative o adding a footer to the email body to contain administrative
instructions; instructions;
o removing some MIME-parts from the email or converting the message o removing some MIME-parts from the email or converting the message
to text only; to text only;
o PGP-encrypting or S/MIME encrypting the body with the receiver's o encrypting the body with the Recipient's key using PGP (Pretty
key; Good Privacy) or S/MIME;
o enforcing community standards by rewriting banned words; o enforcing community standards by rewriting banned words; and
o allowing moderators to add arbitrary commentary to messages o allowing moderators to add arbitrary commentary to messages
(discussed in [RFC6377]). (discussed in [RFC6377]).
Any such modifications would invalidate a DKIM signature. Any such modifications would invalidate a DKIM signature.
Header and content modifications are common for many mailing lists Header and content modifications are common for many Mailing Lists
and are often central to present mailing list functionality and and are often central to present Mailing List functionality and
usage. Furthermore, MUAs have come to rely on mailing list message usage. Furthermore, MUAs have come to rely on Mailing List message
modifications to present messages to end users in expected ways. modifications to present messages to end users in expected ways.
3.2.3.1. Mailing List Operational Effects 3.2.3.1. Mailing List Operational Effects
Mailing Lists may also have the following DMARC interoperability Mailing Lists may also have the following DMARC interoperability
issues: issues:
o Subscribed members may not receive email from members that post o Subscribed members may not receive email from members that post
using domains that publish a DMARC "p=reject" policy. using domains that publish a DMARC "p=reject" policy.
o Mailing Lists may interpret DMARC-related email rejections as an o Mailing Lists may interpret DMARC-related email rejections as an
inability to deliver email to the recipients that are checking and inability to deliver email to the Recipients that are checking and
enforcing DMARC policy. This processing may cause subscribers enforcing DMARC policy. This processing may cause subscribers
that are checking and enforcing DMARC policy to be inadvertently that are checking and enforcing DMARC policy to be inadvertently
suspended or removed from the Mailing List. suspended or removed from the Mailing List.
3.2.4. Gateways 3.2.4. Gateways
A Gateway performs the basic routing and transfer work of message A Gateway performs the basic routing and transfer work of message
relaying, but it also is permitted to modify content, structure, relaying, but it is also permitted to modify content, structure,
addressing, and/or other attributes as needed to send the message addressing, and/or other attributes as needed to send the message
into a messaging environment that operates under different standards into a messaging environment that operates under different standards
or potentially incompatible policies. or potentially incompatible policies.
Gateways share the same DMARC interoperability issues as ReSenders Gateways share the same DMARC interoperability issues as ReSenders
(Section 3.2.2). (Section 3.2.2).
Gateways may also share the same DMARC interoperability issues as Gateways may also share the same DMARC interoperability issues as
MTAs (Section 3.1.2). MTAs (Section 3.1.2).
Receiver systems on the non-SMTP side of a protocol gateway may be Receiver systems on the non-SMTP side of a protocol Gateway may be
unable to evaluate DKIM and SPF. If a message passes through a unable to evaluate DKIM and SPF. If a message passes through a
second protocol gateway back into the SMTP domain, the second protocol Gateway back into the SMTP domain, the
transformations commonly break the original DKIM signature(s). transformations commonly break the original DKIM signature(s).
Gateway-level forwarding can introduce DMARC interoperability issues Gateway-level forwarding can introduce DMARC interoperability issues
if the Gateway is configured to rewrite the message into alternate if the Gateway is configured to rewrite the message into alternate
recipient domains. For example, an acquisition may lead an acquiring receiving domains. For example, an acquisition may lead an acquiring
company to decide to decommission the acquired company's domains by company to decide to decommission the acquired company's domains by
rewriting messages to use the domain of the acquiring company. Since rewriting messages to use the domain of the acquiring company. Since
the RFC5322.To header field is usually DKIM-signed, this kind of the RFC5322.To header field is usually DKIM-signed, this kind of
rewriting will invalidate such DKIM signatures. rewriting will invalidate such DKIM signatures.
3.2.5. Boundary Filters 3.2.5. Boundary Filters
To enforce security boundaries, organizations can subject messages to To enforce security boundaries, organizations can subject messages to
analysis for conformance with their safety policies. A filter might analysis for conformance with their safety policies. A filter might
alter the content to render it safe, such as by removing or otherwise alter the content to render it safe, such as by removing or otherwise
skipping to change at page 14, line 27 skipping to change at page 14, line 31
Examples of Boundary Filters include: Examples of Boundary Filters include:
o Malware scanning: To protect readers and its reputation, an MTA o Malware scanning: To protect readers and its reputation, an MTA
that transfers a message may remove content believed to be harmful that transfers a message may remove content believed to be harmful
from messages, reformulate content to canonical formats in order from messages, reformulate content to canonical formats in order
to make them more trustworthy or easier to scan, and/or add text to make them more trustworthy or easier to scan, and/or add text
in the body to indicate the message has been scanned. Any such in the body to indicate the message has been scanned. Any such
modifications would invalidate a DKIM signature. modifications would invalidate a DKIM signature.
o Spam filtering: To protect reputation and assist other MTAs, an o Spam filtering: To protect its reputation and assist other MTAs,
MTA may modify a message to indicate its decision that the message an MTA may modify a message to indicate its decision that the
is likely to be unwanted, and/or add text in the body to indicate message is likely to be unwanted and/or add text in the body to
that such filtering has been done. indicate that such filtering has been done.
o Other text additions: An MTA may add an organizational disclaimer o Other text additions: An MTA may add an organizational disclaimer
or advertisement, for instance. or advertisement, for instance.
o URL alteration: Some systems will rewrite or alter embedded URLs o URL alteration: Some systems will rewrite or alter embedded URLs
as a way to control the potential threat from malware. as a way to control the potential threat from malware.
o Secondary MX services: The secondary MX for an organization may be o Secondary MX services: The secondary MX for an organization may be
external to the normal mail processing for the organization, and external to the normal mail processing for the organization, and
queue and forward to the primary when it becomes available. This it may queue and forward to the primary when it becomes available.
will not invalidate DKIM but will prevent the primary from This will not invalidate DKIM but will prevent the primary from
validating SPF normally. In this case, however, it is validating SPF normally. In this case, however, it is
inappropriate for a primary MX server to perform an SPF check inappropriate for a primary MX server to perform an SPF check
against its own secondaries. Rather, the secondary MX should against its own secondaries. Rather, the secondary MX should
perform this function and employ some trusted mechanism to perform this function and employ some trusted mechanism to
communicate the results of the SPF, DKIM, and DMARC evaluation(s) communicate the results of the SPF, DKIM, and DMARC evaluation(s)
to the primary MX server. to the primary MX server.
3.3. Combinations 3.3. Combinations
Indirect email flows can be combined. For example, a university Indirect email flows can be combined. For example, a university
student may subscribe to a mailing list (using his university email student may subscribe to a Mailing List (using his university email
address) while this university email address is configured to forward address) while this university email address is configured to forward
all emails to a freemail or a post-education corporate account all emails to a freemail or a post-education corporate account
provider where a more permanent email address for this student provider where a more permanent email address for this student
exists. exists.
Within an organization the message may pass through various MTAs Within an organization, the message may pass through various MTAs
(Section 3.1.2), each of which performs a different function (Section 3.1.2), each of which performs a different function
(authentication, filtering, distribution, etc.) (authentication, filtering, distribution, etc.).
4. Possible Mitigations of Interoperability Issues 4. Possible Mitigations of Interoperability Issues
Solutions to interoperability issues between DMARC and indirect email Solutions to interoperability issues between DMARC and indirect email
flows vary widely in their scope and implications. They range from flows vary widely in their scope and implications. They range from
improvements to underlying processing, such as proper handling of improvements to underlying processing, such as proper handling of
multiple DKIM signatures, to more radical changes to the messaging multiple DKIM signatures, to more radical changes to the messaging
architecture. This section describes possible ways to address architecture. This section describes possible ways to address
interoperability issues. Note that these particular mechanisms may interoperability issues. Note that these particular mechanisms may
not be considered "best practices" and may, in some cases, violate not be considered "best practices" and may, in some cases, violate
skipping to change at page 16, line 4 skipping to change at page 16, line 4
desired if the email in question is of a certain category of high desired if the email in question is of a certain category of high
value or high risk (security-related) transactional messages (dealing value or high risk (security-related) transactional messages (dealing
with financial transactions or medical records, for example). In with financial transactions or medical records, for example). In
these cases, mitigating the impact of DMARC due to indirect email these cases, mitigating the impact of DMARC due to indirect email
flows may not be desirable (counterproductive or allowing for abuse). flows may not be desirable (counterproductive or allowing for abuse).
As a final note, mail systems are diverse and widely deployed. As a final note, mail systems are diverse and widely deployed.
Systems of various ages and capabilities are expected to preserve Systems of various ages and capabilities are expected to preserve
interoperability with the rest of the SMTP ecosystem. For instance, interoperability with the rest of the SMTP ecosystem. For instance,
Qmail is still used, although the base code has not been updated Qmail is still used, although the base code has not been updated
since 1998. ezmlm, a once popular mailing list manager, is still since 1998. ezmlm, a once popular MLM, is still deployed but has not
deployed but has not been updated since 1997, although a new version, been updated since 1997, although a new version (ezmlm-idx) exists.
ezmlm-idx exists. Old versions of other open and closed source MTAs Old versions of other open- and closed-source MTAs are still commonly
are still commonly in operation. When dealing with aging or in operation. When dealing with aging or unsupported systems, some
unsupported systems, some solutions may be time-consuming and/or solutions may be time-consuming and/or disruptive to implement.
disruptive to implement.
4.1. Mitigations in Current Use 4.1. Mitigations in Current Use
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.
skipping to change at page 16, line 40 skipping to change at page 16, line 39
for some MTA software. for some MTA software.
o MTAs may choose to DKIM-sign notification messages with an aligned o MTAs may choose to DKIM-sign notification messages with an aligned
domain to allow a DKIM-based DMARC pass. domain to allow a 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
the original user's address in an RFC5322.Reply-to header field. original user's address in an 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 o When implementing "forward-to-friend" functionality, one approach
to avoid DMARC failures is to pass a well-formed message to the 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 user's MUA so that it may fill in an appropriate identity and
submit through its own MSA. 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 most well-known brands, all active domains are likely However, for most well-known brands, all active domains are likely
skipping to change at page 17, line 29 skipping to change at page 17, line 29
Using the DKIM length tag to allow appended signatures is Using the DKIM length tag to allow appended signatures is
discouraged due to the security risk created by allowing arbitrary discouraged due to the security risk created by allowing arbitrary
content to be appended to legitimate email. content to be appended to legitimate email.
o Senders can also maximize survivability by starting with RFC- o Senders can also maximize survivability by starting with RFC-
compliant headers and common body formats. compliant headers and common body formats.
o In order to minimize transport-based conversions, Senders can o In order to minimize transport-based conversions, Senders can
convert messages to a lowest denominator MIME content-transfer convert messages to a lowest denominator MIME content-transfer
encoding such as quoted-printable or base64 before signing encoding such as quoted-printable or base64 before signing
([RFC6376] Section 5.3). ([RFC6376], Section 5.3).
4.1.2. Mitigations for Receivers 4.1.2. Mitigations for Receivers
4.1.2.1. Identifier Alignment 4.1.2.1. Identifier Alignment
o Receivers should update DKIM handling libraries to ensure that o Receivers should update DKIM handling libraries to ensure that
they process all valid DKIM signatures and check each signature they process all valid DKIM signatures and check each signature
for alignment. for alignment.
4.1.2.2. Policy Override 4.1.2.2. Policy Override
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 there are fewer accounts that receive
resources may be scarce. forwarded mail and other 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
field names are discouraged by [RFC6648]). However, handling of field names 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 that 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.
o Forwarders can minimize the circumstances in which they choose to o Forwarders can minimize the circumstances in which they choose to
fix messages, preferring to preserve non-compliant headers to fix messages, preferring to preserve non-compliant headers to
creating DKIM failures. creating DKIM failures.
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 so as to not collide with the original be carefully crafted so as to not collide with the original
display name of the author, nor contain something that looks like display name of the Author, nor contain something that looks like
an email address or domain name. These modifications may to some an email address or domain name. These modifications may to some
extent defeat the purpose of DMARC itself. It may make it extent defeat the purpose of DMARC itself. It may make it
difficult to ensure that users of all email clients can easily difficult to ensure that users of all email clients can easily
reply to the author, the list, or all using the email client reply to the Author, the list, or all using the email client
features provided for that purpose. Use of RFC5322.Reply-To features provided for that purpose. Use of the RFC5322.Reply-To
header field can alleviate this problem depending on whether the header field can alleviate this problem depending on whether the
mailing list is configured to reply-to-list, reply-to-author or Mailing List is configured to reply-to-list, reply-to-author, or
reply-to-fixed-address, however it is important to note that this reply-to-fixed-address; however, it is important to note that this
header field can take multiple email addresses. When altering the header field can take multiple email addresses. When altering the
RFC5322.From there are three possibilities: RFC5322.From, 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 that 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 the publication of this document), especially clients (as of the publication of this document), especially
mobile clients, have difficulty reading such messages and this is mobile clients, have difficulty reading such messages, and this is
not expected to change soon. not expected to 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
and require few additional changes to ensure the DKIM signature is and require few additional changes to ensure the DKIM signature is
preserved. Moving lists that currently modify mail to a policy preserved. Moving lists that currently modify mail to a policy
like this may be too much of a change for the members of such like this may be too much of a change for the members of such
lists. lists.
o Rejecting posts or membership requests from domains with a DMARC o Rejecting posts or membership requests from domains with a DMARC
policy other than "p=none". However members or potential members policy other than "p=none". However, members or potential members
of such Mailing Lists may complain of unfair exclusion. of such Mailing Lists may complain of unfair exclusion.
o To alleviate unsubscribes to the Mailing List due to the messages o To alleviate unsubscribes to the Mailing List due to the messages
bouncing because of DMARC, the MLM needs to not act on bouncing because of DMARC, the MLM needs to not act on
notification messages due to Message Authentication issues. notification messages due to message authentication issues.
[RFC3463] specifies Enhanced Mail System Status Codes, which help
[RFC3463] specifies Enhanced Mail System Status Codes which help
differentiate between various failure conditions. Correctly differentiate between various failure conditions. Correctly
interpreting Extended SMTP error messages is useful in this case. interpreting Extended SMTP error messages is useful in this case.
In particular, extended status codes for SPF and DKIM causes are In particular, extended status codes for SPF and DKIM causes are
defined in [RFC7372] and DMARC-related failure indications are defined in [RFC7372], and DMARC-related failure indications are
discussed in DMARC [RFC7489] section 10.3. discussed in DMARC ([RFC7489], Section 10.3).
All these techniques may provide some specific challenges to MUAs and All these techniques may provide some specific challenges to MUAs and
different operational usages for end users (like rewriting filters to different operational usages for end users (like rewriting filters to
sort emails in folders). There will be some time before all sort emails in folders). There will be some time before all
implications are understood and accommodated. implications are understood and accommodated.
4.2. Proposed and In-Progress Mitigations 4.2. Proposed and In-Progress Mitigations
The following mitigations are based on Internet Drafts (I-Ds) which The following mitigations are based on Internet-Drafts (I-Ds) that
are still in process. They are described here to offer exploratory are still in process. They are described here to offer an
path for solutions. These solutions should not be used in a exploratory path for solutions. These solutions should not be used
production environment. Because of the transient nature of I-Ds, in a production environment. Because of the transient nature of
specific citations are not included because a number of them will I-Ds, specific citations are not included because a number of them
inevitably become obsolete and those which gain consensus in the will inevitably become obsolete, and those that gain consensus in the
community will become RFCs and should be discovered as such. community will become RFCs and should be discovered as such.
o Third-party authorization schemes provide ways to extend o Third-party authorization schemes provide ways to extend
identifier alignment under control of the domain owner. Identifier Alignment under control of the Domain Owner.
o Ways to canonicalize messages that transit mailing lists so that o Ways to canonicalize messages that transit Mailing Lists so that
their alterations can be isolated from the original signed their alterations can be isolated from the original signed
content. content.
o Mechanisms to record message transformations applied at each hop o Mechanisms to record message transformations applied at each hop
so they can be reversed and the original signed content recovered. so they can be reversed and the original signed content recovered.
o "Conditional" DKIM signatures, whereby the author domain indicates o "Conditional" DKIM signatures, whereby the Author domain indicates
its signature is only good if accompanied by a signature from an its signature is only good if accompanied by a signature from an
expected downstream relay. expected downstream relay.
o Mechanisms to extend Authentication-Results [RFC7601] to multiple o Mechanisms to extend Authentication-Results [RFC7601] to multiple
hops, creating a provable chain of custody as well as a view of hops, creating a provable chain of custody as well as a view of
message authentication results at each handling step. message authentication results at each handling step.
4.2.1. Getting More Radical: Requiring New Communication Paths Between 4.2.1. Getting More Radical: Requiring New Communication Paths between
MUAs MUAs
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. Security Considerations
This document contains no actions for IANA. [RFC Editor: Please
delete this section prior to publication.]
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.
Section 4.1.1.1 discusses the importance of appropriate DKIM key 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.
Section 4.1.3.3 warns that rewriting the RFC5322.From header field to 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. create an artificial domain name should not be done with any domain.
7. Acknowledgments 6. References
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull,
Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the
IETF DMARC Working Group's wiki page listing all known
interoperability issues with DMARC and indirect email flows.
Tim Draegen created the first draft of this document from these
contributions and by hamfistedly mapping contributions into the
language of [RFC5598].
8. References
8.1. Normative References 6.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", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 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>.
skipping to change at page 23, line 5 skipping to change at page 23, line 14
[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", [RFC7372] Kucherawy, M., "Email Authentication Status Codes",
RFC 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 6.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, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
Appendix A. Appendix A - Example SPF Bounce Appendix A. Example SPF Bounce
This example illustrates a notification message "bounce". This example illustrates a notification message "bounce".
A.1. Initial Message A.1. Initial Message
Here is the message as it exits the Origin MTA (segv.d1.example): Here is the message as it exits the Origin MTA (segv.d1.example):
Return-Path: <jqd@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]) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0) (authenticated bits=0)
skipping to change at page 23, line 48 skipping to change at page 25, line 5
Message-ID: <54B84785.1060301@d1.example> Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800 Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example> From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org To: no-recipient@dmarc.org
Subject: Example 1 Subject: Example 1
Hey gang, Hey gang,
This is a test message. This is a test message.
--J. --J.
A.2. Notification message A.2. Notification Message
When dmarc.org rejects the message without a DKIM signature, it When dmarc.org rejects the message without a DKIM signature, it
specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local which has specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has
no SPF record. dmarc.org has a reject policy in place for such non- no SPF record. dmarc.org has a reject policy in place for such non-
passing cases. Since there is no DKIM signature on the notification passing cases. Since there is no DKIM signature on the notification
message, the failed SPF lookup results in a dmarc=fail and d1.example message, the failed SPF lookup results in a dmarc=fail, and
could be expected to discard the notification message itself: d1.example could be expected to discard the notification message
itself:
Return-Path: <> Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1]) Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
by mx.d1.example with ESMTPS id Lkm25302jJR5 by mx.d1.example with ESMTPS id Lkm25302jJR5
for <jqd@d1.example> for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST) Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example; Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=; permitted sender hosts) smtp.mail=;
skipping to change at page 25, line 19 skipping to change at page 26, line 25
Message-ID: <54B84785.1060301@d1.example> Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800 Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example> From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org To: no-recipient@dmarc.org
Subject: Example 1 Subject: Example 1
Hey gang, Hey gang,
This is a test message. This is a test message.
--J. --J.
Acknowledgments
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf
E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF
DMARC Working Group's wiki page listing all known interoperability
issues with DMARC and indirect email flows.
Tim Draegen created the first draft of this document from these
contributions and by ham-fistedly mapping contributions into the
language of [RFC5598].
Authors' Addresses Authors' Addresses
Franck Martin (editor) Franck Martin (editor)
LinkedIn LinkedIn
Mountain View, CA Mountain View, CA
USA United States of America
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)
dmarcian, inc. dmarcian, inc.
PO Box 1007 PO Box 1007
Brevard, NC 28712 Brevard, NC 28712
USA United States of America
Email: tim@dmarcian.com Email: tim@dmarcian.com
Elizabeth Zwicky (editor) Elizabeth Zwicky (editor)
Yahoo Yahoo
Sunnyvale, CA Sunnyvale, CA
USA United States of America
Email: zwicky@yahoo-inc.com Email: zwicky@yahoo-inc.com
Kurt Andersen (editor) Kurt Andersen (editor)
LinkedIn LinkedIn
2029 Stierlin Court 2029 Stierlin Court
Mt. View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: kandersen@linkedin.com Email: kandersen@linkedin.com
 End of changes. 119 change blocks. 
271 lines changed or deleted 272 lines changed or added

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