draft-ietf-dmarc-interoperability-01.txt   draft-ietf-dmarc-interoperability-02.txt 
DMARC Working Group F. Martin, Ed. DMARC Working Group F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: September 21, 2015 Cisco Systems GmbH Expires: October 30, 2015 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
Eudaemon Eudaemonic Development LLC
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
March 20, 2015 April 28, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-01 draft-ietf-dmarc-interoperability-02
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 originate from third party sources, are modified in transit, messages do not flow directly from the author's administrative domain
or are forwarded enroute to their final destination. Collectively to the final recipients. Collectively these email flows are referred
these email flows are referred to as indirect email flows. This to as indirect email flows. This document describes interoperability
document describes interoperability issues between DMARC and indirect issues between DMARC and indirect email flows. Possible methods for
email flows. Possible methods for addressing interoperability issues addressing interoperability issues are presented.
are presented.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 21, 2015. This Internet-Draft will expire on October 30, 2015.
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 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.3. Message Modification . . . . . . . . . . . . . . . . . . 5 2.3. Message Modification . . . . . . . . . . . . . . . . . . 5
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 5 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6
3.1. Message Handling System . . . . . . . . . . . . . . . . . 5 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7
3.1.2.2. Header Standardization . . . . . . . . . . . . . 7 3.1.2.2. Header Standardization . . . . . . . . . . . . . 7
3.1.2.3. Email Address Internationalization . . . . . . . 7 3.1.2.3. Email Address Internationalization . . . . . . . 8
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12
4. Possible Solutions to Interoperability Issues . . . . . . . . 12 4. Possible Mitigations of Interoperability Issues . . . . . . . 12
4.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 12 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13
4.2. Message Modification . . . . . . . . . . . . . . . . . . 13 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13
4.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 14 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13
4.3.1. Original-Authentication-Results . . . . . . . . . . . 14 4.1.1.2. Message Modification . . . . . . . . . . . . . . 13
4.4. Message Handling Services . . . . . . . . . . . . . . . . 14 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14
4.4.1. Message Transfer Agents . . . . . . . . . . . . . . . 14 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14
4.4.1.1. Encoding . . . . . . . . . . . . . . . . . . . . 14 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14
4.4.1.2. Filters . . . . . . . . . . . . . . . . . . . . . 14 4.1.2.3. Email Address Internationalization . . . . . . . 14
4.4.1.3. Email Address Internationalization . . . . . . . 15 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14
4.5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14
4.5.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 15 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15
4.6. Getting More Radical: Requiring New Communication Paths 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15
Between MUA and the Message Store . . . . . . . . . . . . 16 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Getting More Radical: Requiring New Communication
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Paths Between MUAs . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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. DMARC is used to combat exact-domain phishing, to gain reporting. The DMARC mechanism can encounter several different types
visibility into email infrastructure, and to provide email egress of interoperability issues due to third-party message sourcing,
controls. Due to wide adoption, the impact of DMARC-based email message transformation or rerouting.
Cases in which email does not flow directly from the author's
administrative domain to the recipients are collectively referred to
in this document as indirect email flows. Due to existing and
increasing adoption of DMARC, the impact of DMARC-based email
rejection policies on both direct and indirect email flows can be rejection policies on both direct and indirect email flows can be
significant. significant.
The DMARC mechanism can encounter several different types of Several known causes of interoperability issues are presented,
interoperability issues due to third-party message sourcing, message followed by a description of components within the Internet Mail
transformation or rerouting. These cases in which mail does not go Architecture [RFC5598] where interoperability issues can arise.
directly from the author's administrative domain to the recipients
are known collectively as indirect email flows.
The next section describes interoperability issues between DMARC and
indirect email flows. These issues are first described in the
context of configuration behavior that DMARC requires from underlying
authentication technology, and then described as they appear in
context of the Internet Mail Architecture [RFC5598].
Lastly, possible methods for addressing interoperability issues are Lastly, known and possible methods for addressing interoperability
presented. There are often multiple ways to address any given issues are presented. There are often multiple ways to address any
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.
1.1. Document Conventions 1.1. Document Conventions
Notation regarding structured fields is taken from [RFC5598]. Notation regarding structured fields is taken from [RFC5598].
Organizational Domain and Authenticated Identifiers are specified in Organizational Domain and Authenticated Identifiers are specified in
DMARC [RFC7489]. DMARC [RFC7489].
2. Causes of Interoperability Issues 2. Causes of Interoperability Issues
What do we mean by "interoperability issues"? We say that DMARC Interoperability issues between DMARC and indirect email flows arise
introduces interoperability issues or problems, when conformance to when conformance to the DMARC specification leads an implementation
the DMARC specification leads an implementation to reject a message to apply DMARC based policy to messages that are both compliant with
that is both compliant with the architecture as specified in the architecture as specified in [RFC5598] and viewed as legitimate
[RFC5598] and would have been viewed as legitimate in the eyes of the by the intended recipient. To be clear, this document does not
intended recipient. Therefore, we can already conclude that DMARC address emails considered legitimate by the intended recipient but
poses no interoperability problems when legitimate messages properly which are not conformant to other email specifications. The rest of
validate through its specified processes. The rest of this section this section describes several conceptual causes of interoperability
delves into how legitimate messages may get rejected. issues.
2.1. Identifier Alignment 2.1. Identifier Alignment
A fundamental aspect of message source validation is understanding DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
what defines the source that is validated. Each of the underlying source validation. The DMARC [RFC7489] mechanism refers to source
mechanisms that DMARC uses (DKIM [RFC6376] and SPF [RFC7208]) takes a domains that are validated by DKIM or SPF as Authenticated
different approach. Therefore, the DMARC [RFC7489] mechanism Identifiers. DMARC requires an Authenticated Identifier to be
attempts to predictably specify the domain of the originator that relevant to the domain found in the message's RFC5322.From header
will be used for its purposes (reporting/message disposition). This field [RFC5322]. This relevancy is referred to as Identifier
step is referred to as Identifier Alignment. Alignment.
Identifier Alignment can be strict, where the domains exactly match
each others, or relaxed where the domains are part of the same
Organizational Domain. There are, in general, the same
interoperability issues between strict and relaxed alignment, however
in strict mode the possible solutions are more constrained when
possible. This Document mainly implies relaxed Identifier Alignment.
DKIM provides a cryptographic means for a domain to be associated DKIM provides a cryptographic means for a domain to be associated
with a particular message. DKIM does not make any constraints on with a particular message. DKIM does not make any constraints on
what domains may or must present this association. However, for a what domains may or must present this association. However, for a
DKIM identifier to align in DMARC, the signing domain must be part of DKIM identifier to align in DMARC, the signing domain of a valid
the same Organizational Domain as the domain in the RFC5322.From signature must be part of the same Organizational Domain as the
header field [RFC5322], and the signature must be valid. domain in the 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. 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: if an implementation cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
it may lead to perfectly valid messages being flagged as not may erroneously apply DMARC based policy to otherwise legitimate
authentic. messages.
SPF provides two Authenticated Identifiers the first one is SPF can provides two Authenticated Identifiers based on two different
RFC7208.HELO [RFC7208] based on RFC5321.HELO/EHLO and the second one SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM
is RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom [RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for
[RFC5321] domain or, if the RFC5321.MailFrom address is absent (as in alignment. The SPF validated domain in RFC7208.MAILFROM must be part
the case of "bounces"), on the domain found in the HELO/EHLO SMTP of the same Organizational Domain as the domain in the RFC5322.From
command. Local policies, as well as DMARC often only use the header field to be aligned. It is important to note that even when
RFC7208.MAILFROM identifier. Again, for an SPF identifier to align an SPF record exists for the domain in RFC5322.From, SPF will not
in DMARC, the validated domain must be part of the same authenticate it unless it is also the domain in RFC7208.MAILFROM,
Organizational Domain as the domain in the RFC5322.From header field. furthermore, RFC7208.MAILFROM definition is different from
Even when an SPF record exists for the domain in RFC5322.From, SPF RFC5321.MailFrom [RFC5321] definition.
will not authenticate it unless it is also the domain SPF checks.
While aligning RFC5322.From and RFC5321.MailFrom is usually possible,
it can be difficult to change the domain in the HELO/EHLO used for
bounces to the domain in the RFC5322.From header field, especially
when several mail streams share the same sending IP address.
2.2. Message Forwarding 2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of Message forwarding is a generic concept encapsulating a variety of
behaviors. Section 3 describes forwarding behavior as it relates to behaviors. Section 3 describes forwarding behavior as it relates to
the components of the Internet Mail Architecture. the components of the Internet Mail Architecture.
All of these behaviors involve mail being retransmitted by a new SMTP All of these behaviors involve email being retransmitted by a new
server. As discussed above, for SPF to cause a DMARC pass, the SMTP server. As discussed above, for SPF to cause a DMARC pass, the
domain of the RFC5321.MailFrom or RFC5321.HELO/EHLO must be aligned domain of the RFC7208.MAILFROM, must be aligned with that of the
with that of the RFC5322.From header field. If the forwarder keeps RFC5322.From header field:
the RFC5321.MailFrom, the SPF validation will fail altogether unless
the forwarder is an authorized part of the originator's mail sending o If the RFC5321.MailFrom is not empty and if the forwarder keeps
infrastructure. If the forwarder uses its own domain in the the RFC5321.MailFrom, the SPF validation will fail altogether
RFC5321.MailFrom and/or RFC5321.HELO/EHLO, SPF passes but the unless the forwarder is an authorized part of the originator's
alignment with the RFC5322.From header field fails. In either case, email sending infrastructure. On another hand, if the forwarder
SPF cannot produce a DMARC pass, and DKIM will be required to get uses its own domain in the RFC5321.MailFrom, SPF passes but the
DMARC to pass. alignment with the RFC5322.From header field fails.
o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the
forwarder will likely be in different organizational domain of the
RFC5322.From. SPF may pass but the alignment with the
RFC5322.From header field fails.
In either case, SPF cannot produce a DMARC pass, and DKIM will be
required to get DMARC to pass.
2.3. Message Modification 2.3. Message Modification
Modification of email content invalidates most DKIM signatures. For Modification of email content invalidates most DKIM signatures, and
instance while DKIM provides a length flag so that content can be many message forwarding systems modify email content. Mailing list
appended (See Section 8.2 of RFC6376 [RFC6376] for additional processors are the most common example of such systems, but other
security considerations), in practice, particularly with MIME-encoded forwarding systems also make modifications. Although DKIM provides a
[RFC2045] messages, a mailing list processor will do more than append length flag so that content can be appended (See Section 8.2 of
(See Section 5.3 of [RFC5598] for details). Even forwarding systems [RFC6376] for additional security considerations), in practice,
make content modifications. Furthermore, the use of the length flag particularly with MIME-encoded [RFC2045] messages, a mailing list
is by no means universal. processor will do more than append (See Section 5.3 of [RFC5598] for
details). Furthermore, the use of the length flag is seldom found in
emails in part because of its security challenges.
DKIM has two canonicalizations: simple and relaxed. The latter DKIM has two canonicalizations to use for headers and body
allows some modest in transit modifications that do not change the separately: simple and relaxed. The latter allows some modest in
interpretation of the content of the email. The relaxed transit modifications that do not change the interpretation of the
canonicalization used to be computing intensive and may not have been content of the email. The relaxed canonicalization is more computing
preferred in the early deployment of DKIM. intensive and may not have been preferred in the early deployment of
DKIM as this may have been more significant than today.
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
Section 4 of [RFC5598] describes six basic components that make up Section 4 of [RFC5598] describes six basic components that make up
skipping to change at page 6, line 46 skipping to change at page 7, line 11
be capable of sending email that yields Authenticated Identifiers be capable of sending email that yields Authenticated Identifiers
aligned with the domain found in the RFC5322.From header field. aligned with the domain found in the RFC5322.From header field.
Examples of this issue include "forward-to-friend" functionality Examples of this 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 an inherent difficulty in modifying the domain issues are marked by an inherent difficulty in establishing alignment
present in a message's RFC5322.From header field. Examples of this with the domain present in a message's RFC5322.From header field.
issue include: 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 any domains through its infrastructure. to relay any domains through its infrastructure.
o Embedded devices - cable/dsl modems, firewalls, wireless access o Embedded devices - cable/dsl modems, firewalls, wireless access
points that send email using hardcoded domains. points that send email using hardcoded domains.
o Email service providers - ESPs that service customers that are o Email service providers - ESPs that service customers that 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 appears event causing calendaring software to emit an update that appears
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.
3.1.2.1. Message Encoding 3.1.2.1. Message Encoding
An MTA may change the message encoding, for instance by converting An MTA may modify the message encoding, for instance by converting
8-bit mail sections to quoted-printable 7-bit sections. This is 8-bit MIME sections to quoted-printable 7-bit sections. This
outside the scope of DKIM canonicalization and will invalidate DKIM modification is outside the scope of DKIM canonicalization and will
signatures that include message content. invalidate DKIM signatures that include message content.
3.1.2.2. Header Standardization 3.1.2.2. Header Standardization
An MTA may standardize headers, usually in order to make non-RFC An MTA may standardize headers, usually in order to make non-RFC
compliant headers properly compliant. For instance, some common MTAs compliant headers properly compliant. For instance, some common MTAs
will correct comprehensible but non-compliant date formats to will correct comprehensible but non-compliant date formats to
compliant ones. Again, this is outside the scope of DKIM compliant ones. This correction is outside the scope of DKIM
canonicalization and will invalidate DKIM signatures. canonicalization and will invalidate DKIM signatures. This
correction is also outside the scope of this document in providing
solutions for non RFC compliant emails.
3.1.2.3. Email Address Internationalization 3.1.2.3. Email Address Internationalization
A DMARC interoperability issue arises in the context of Email Address A DMARC interoperability issue arises in the context of Email Address
Internationalization [RFC6530]. [RFC6854] allows group syntax in the Internationalization [RFC6530]. [RFC6854] allows group syntax in the
RFC5322.From header field during the transition period to SMTPUTF8. RFC5322.From header field during the transition period to SMTPUTF8.
If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
aware MTA, the EAI/SMTPUTF8-aware system may transform the aware MTA, the EAI/SMTPUTF8-aware system may transform the
RFC5322.From header field of the message to include group syntax to RFC5322.From header field of the message to include group syntax to
allow the non-aware MTA to receive the email. allow the non-aware MTA to receive the email.
This transformation will modify the original content of the message This transformation will modify the original content of the message
and may invalidate any DKIM signatures if the transformation is not and may invalidate any DKIM signatures if the transformation is not
done by the MSA or MUA. In addition, group syntax will remove the done by the MSA or MUA. In addition, group syntax will remove the
ability for the DMARC mechanism to find an Organizational Domain that ability for the DMARC mechanism to find an Organizational Domain that
aligns with any authenticated domain identifier from SPF or DKIM. aligns with any authenticated domain identifier from SPF or DKIM.
In addition, the group syntax will result in an invalid domain in the In addition, the group syntax may result in the impossibility of
RFC5322.From header field. If the receiving MTA pays attention to finding a domain with a DMARC policy associated with it. If the
the validity and reputation of domains, this may present its own set receiving MTA pays attention to the validity and reputation of
of delivery problems. domains, this may present its own set of delivery problems. For
instance an MTA may refuse emails with no valid or emailable domain
in the RFC5322.From as to avoid simple workarounds against DMARC.
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 that modify the body. SIEVE may become an issue when the extensions that modify the body. SIEVE may only become an issue when
email is reintroduced in the transport infrastructure. the email is reintroduced in the transport infrastructure.
3.2. Mediators 3.2. Mediators
See [RFC5598] for a complete definition of Mediators. See [RFC5598] for a complete definition of Mediators.
Mediators forward messages through a re-posting process. Mediators Mediators forward messages through a re-posting process. Mediators
share some functionality with basic MTA relaying, but have greater share some functionality with basic MTA relaying, but have greater
flexibility in both addressing and content modifications. flexibility in both addressing and content modifications.
DMARC interoperability issues are prevalent within the context of DMARC interoperability issues are prevalent within the context of
skipping to change at page 9, line 30 skipping to change at page 10, line 8
storage of emails. storage of 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 final recipient, so administrative relationship to the ADMD of the final recipient, so
solutions to Alias-related DMARC failure should not assume such a solutions to Alias-related DMARC failure should not assume such a
relationship. 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 of the new message. Author of the original message with the Recipient(s) of the new
The new Recipient sees the message as being from the original Author, message. The new Recipient sees the message as being from the
even if the Mediator adds commentary. original Author, even if the Mediator adds commentary.
ReSenders introduce DMARC interoperability issues as content ReSenders introduce DMARC interoperability issues as content
modification invalidates DKIM signatures. SPF's ability to grant modification invalidates DKIM signatures. SPF's ability to grant
authorization via alignment is removed as the new Recipient receives authorization via alignment is removed as the new Recipient receives
the message from the Mediator. the message from the Mediator.
Without an ability to produce Authenticated Identifiers relevant to Without an ability to produce Authenticated Identifiers relevant to
the Author's RFC5322.From header field domain using either DKIM or the Author's RFC5322.From header field domain using either DKIM or
SPF, the new Recipient has almost no chance of successfully applying SPF, the new Recipient has almost no chance of successfully applying
the DMARC mechanism. the DMARC mechanism.
skipping to change at page 10, line 42 skipping to change at page 11, line 19
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 rejection as an o Mailing Lists may interpret DMARC-related email rejection 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 subscribed enforcing DMARC policy. This processing may cause subscribed
members to be suspended or removed from the Mailing List. members to be suspended or removed from the Mailing List.
[RFC3463] specifies Enhanced Mail System Status Codes which help
differentiate between various bounces. DMARC even defines These changes are common for many mailing lists and receivers are
specific codes to be used. used to them. Furthermore MUA expects certain mailing list behavior
in presenting emails to the end users
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 also is permitted to modify content, structure,
address, or attributes as needed to send the message into a messaging address, or attributes as needed to send the message into a messaging
environment that operates under different standards or potentially environment that operates under different standards or potentially
incompatible policies. 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 share also the same DMARC interoperability issues as Gateways may share also the same DMARC interoperability issues as
MTAs (Section 3.1.2). MTAs (Section 3.1.2).
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 to map between if the Gateway is configured to rewrite the message to map between
recipient domains. For example, an acquisition may lead the recipient domains. For example, an acquisition may lead the
acquiring company to decide to decommission the acquired companies acquiring company to decide to decommission the acquired company's
domains by rewriting messages to use the domain of the acquiring domains by rewriting messages to use the domain of the acquiring
company. Since the To: header is usually DKIM-signed, this kind of company. Since the RFC5322.To header field is usually DKIM-signed,
rewriting will also cause DKIM signatures to fail. this kind of rewriting will also cause DKIM signatures to fail.
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 content alter the content to render it safe, such as by removing content
deemed unacceptable. deemed unacceptable.
Boundary Filters share the same DMARC interoperability issues as Boundary Filters share the same DMARC interoperability issues as
ReSenders. ReSenders.
Issues may arise if SPF and DKIM is evaluated after the filter
modifications.
Examples of Boundary Filters include: Examples of Boundary Filters include:
o Anti-spam: To keep its reputation, an MTA that transfers a message o Anti-spam: To keep its reputation, an MTA that transfers a message
may remove harmful content from messages that are likely to be may remove harmful content from messages that are likely to be
unwanted by the next MTA and/or add text in the body to indicate unwanted by the next MTA and/or add text in the body to indicate
the message has been scanned. Any such modifications would the message has been scanned. Any such modifications would
invalidate a DKIM signature. invalidate a DKIM signature.
o Any service that reformulates the RFC5322.body for any other o Any service that reformulates the RFC5322.body for any other
reason, for instance adding an organizational disclaimer. reason, for instance adding an organizational disclaimer.
skipping to change at page 12, line 9 skipping to change at page 12, line 39
The causes of indirect email flows can be combined. For example, a The causes of indirect email flows can be combined. For example, a
university student may subscribe to a mailing list (using his university student may subscribe to a mailing list (using his
university email address) while this university email address is university email address) while this university email address is
configured to forward all emails to a freemail provider where a more configured to forward all emails to a freemail provider where a more
permanent email address for this student exists. permanent email address for this student 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 Solutions to 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 processors, such as proper handling improvements to underlying processors, such as proper handling of
multiple DKIM signatures, to more radical approaches to the messaging multiple DKIM signatures, to more radical approaches to the messaging
architecture. This section describes possible ways to address architecture. This section describes possible ways to address
interoperability issues. interoperability issues.
Mail systems are diverse and widely deployed and are expected to Mail systems are diverse and widely deployed and are expected to
continue to work with old systems. For instance, Qmail is still used continue to work with old systems. For instance, Qmail is still used
and the base code has not been updated since 1998. Ezmlm, a once and the base code has not been updated since 1998. Ezmlm, a once
popular mailing list manager, is still deployed and has not been popular mailing list manager, is still deployed and has not been
updated since 1997, although a new version, Ezmlm-idx exists. In updated since 1997, although a new version, Ezmlm-idx exists. In
this constrained environment, some solutions may be time-consuming this constrained environment, some solutions may be time-consuming
and/or disruptive to implement. and/or disruptive to implement.
DMARC provides for receivers to make decisions about identity DMARC provides for receivers to make decisions about identity
alignment acceptability based on information outside the DMARC alignment acceptability based on information outside DMARC and
headers and communicate those decisions as "overrides" to the sender. communicate those decisions as "overrides" to the sender. This
This facility can be used to ease some interoperability issues, facility can be used to ease some interoperability issues, although
although care is needed to ensure that this does not create loopholes care is needed to ensure that this does not create loopholes that
that abusers can use arbitrarily. abusers can use arbitrarily.
4.1. Identifier Alignment 4.1. Mitigations in Current Use
Currently used work-arounds and fixes to identifier alignment issues: At many places where DMARC is already deployed, mitigations are in
use. These mitigations vary in their effectiveness and side effects,
but have the advantage that they are currently available.
4.1.1. Mitigations for Senders
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 HELO/EHLO o MTAs handling multiple domains may also choose to align
to RFC5322.From, particularly when sending bounce messages. RFC5321.HELO/EHLO to RFC5322.From, particularly when sending
bounce messages. Adjusting dynamically the RFC5321.HELO based on
the RFC5322.From may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces to allow DKIM-based DMARC o MTAs may choose to DKIM sign bounces with an aligned domain to
pass. allow DKIM-based DMARC pass.
o MTAs handling multiple domains may require DMARC-using senders to o MTAs handling multiple domains may require DMARC-using senders to
provide DKIM keys and use DKIM to avoid SPF alignment issues. provide DKIM keys and use DKIM to avoid SPF alignment issues.
Handling DKIM keys with a third party has its security challenges.
o ReSenders may choose to change RFC5322.From to one under the o Senders who are sending on behalf of users in other Administrative
ReSender's control, avoiding alignment issues with the original. Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a
o Receivers should update DKIM handling libraries to ensure that domain controlled by the Sender, or a placeholder address, with
they process all valid DKIM signatures and check them for the original user's address in a RFC5322.Reply-to header field.
alignment. However this may affect what the recipient expects in its MUA.
Proposed and in-progress work-arounds and fixes to identifier
alignment issues:
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
[I-D.kucherawy-dkim-delegate] provide ways to extend identifier
alignment under the control of the domain owner.
4.2. Message Modification
Message modification invalidates DKIM signatures and complicates a
receiver's ability to generate Authenticated Identifiers from a
message. Avoiding message modification wherever possible is
therefore desirable.
Currently used work-arounds and fixes to message modification issues: 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, using relaxed canonicalization and by the header fields they sign, using relaxed canonicalization and by
using length to allow appended signatures. using length to allow appended signatures.
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 Forwarders can choose to add email headers instead of modifying o In order to minimize the chances of transport conversions, Senders
existing headers or bodies. can convert the message to a suitable MIME content-transfer
encoding such as quoted-printable or base64 before signing
o Forwarders can minimize the circumstances in which they choose to ([RFC6376] Section 5.3).
fix messages, preferring preserving non-compliant headers to
creating DKIM failures.
o Forwarders can choose to reject messages with suspect or harmful
content instead of modifying them.
o If message modification is required, the RFC5322.From may be
changed.
Proposed and in-progress work-arounds and fixes to message
modification issues:
o DKIM with constrained transformations,
[I-D.kucherawy-dkim-list-canon]
4.3. Message Forwarding
Forwarding messages without modification is referred to as
"transparent forwarding", and is a way to preserve the validity of
DKIM signatures.
Currently used work-arounds and fixes to message forwarding issues:
o Senders should use DKIM signing to allow transparent forwarding to 4.1.2. Mitigations for Receivers
succeed.
o ReSenders may choose to change RFC5322.From to one under the 4.1.2.1. Identifier Alignment
ReSender's control, avoiding alignment issues with the original.
The Original-From [RFC5703] (or X-Original-From) header is used in o Receivers should update DKIM handling libraries to ensure that
various contexts (X- header fields name are discouraged by they process all valid DKIM signatures and check them for
[RFC6648]). alignment.
Note that Original-From (or X-Original-From) is merely adding 4.1.2.2. Policy Override
complexity to the 'who was the author of this message' assessment,
very possibly creating yet-another security hole.
4.3.1. Original-Authentication-Results o Receivers can amalgamate data from their user base to identify
forwarders and use such list for a DMARC local policy override.
This process may be easier for large receivers, where there is
data and resources to create such lists, than for small receivers.
[I-D.kucherawy-original-authres] has been mentioned in early DMARC 4.1.2.3. Email Address Internationalization
drafts as a way to pass along Original Authentication Results to
"downstream" receivers.
4.4. Message Handling Services o During the transition from email systems that do not allow EAI
(SMTPUTF8) to email systems that allow it, [RFC6854] allows the
MUA or MSA to use the group syntax for the RFC5322.From header
field to avoid a known MTA to reject the message (if RFC5322 is
implemented strictly). While this will alleviate the EAI problem,
it will allow a simple DMARC workaround since the message may no
longer have a single usable domain in the RFC5322.From header
field, making DMARC inapplicable. DMARC implementations that pay
attention to the validity of the domains in the RFC5322.From may
then have to choose between EAI transitioning compliance
(accepting the email without a domain in RFC5322.From) and
security (rejecting RFC-compliant email for lack of a domain in
the RFC5322.From). The real solution is to upgrade MTAs to
support EAI (SMTPUTF8), avoiding the transition issue.
4.4.1. Message Transfer Agents 4.1.3. Mitigations for ReSenders
4.4.1.1. Encoding 4.1.3.1. Changes to the RFC5322.From
There are few reasons to modify the encoding of the message, Many ReSender issues can be avoided by using an RFC5322.From under
compatibility issues between international character sets are few the ReSender's control, instead of the initial RFC5322.From. This
nowadays. More mail systems supports 8bitMIME, therefore the need will correct identifier alignment issues and allow arbitrary message
for transport encoding changes are rarer. By default no modification modification, for instance. When ReSenders change the RFC5322.From,
of the message should be done when simply forwarding the message. it is desirable to preserve the information about the original
initiator of the message. The Original-From [RFC5703] (or X-
Original-From) header field is used for this purpose in various
contexts (X- header fields name are discouraged by [RFC6648]).
4.4.1.2. Filters However, handling of Original-From (or X-Original-From) is not
defined anywhere. It is not currently used consistently or displayed
to the user, but in any situation where it is used, it is a new
unauthenticated identifier available for exploitation.
Filters should not add to or modify the body of the message, but 4.1.3.2. Avoiding Message Modification
either should reject the message or add new email headers (not under
DKIM) to indicate the result of the filter.
4.4.1.3. Email Address Internationalization o Forwarders can choose to add email header fields instead of
modifying existing headers or bodies, for instance to indicate a
message may be spam.
During the transition from email systems that do not allow EAI o Forwarders can minimize the circumstances in which they choose to
(SMTPUTF8) to email system that allows it, [RFC6854] allows using the fix messages, preferring to preserve non-compliant headers to
group syntax for the RFC5322.From header field rather than rejecting creating DKIM failures.
the message (if RFC5322 is implemented strictly). Allowing the group
syntax is at the appreciation of the postmaster, that will always
choose the solution best for its user, but really to avoid DMARC not
finding a single useable domain in the RFC5322.From header field, the
real solution is to upgrade your MTAs, to support EAI (SMTPUTF8). In
that case a sending SMTPUTF8 MTA does not need to require a downgrade
of the message to ASCII identifiers. Encouraging, by rejection or
reputation scoring, the presence of a domain in the RFC5322.From
header field is easier.
4.5. Mediators o Forwarders can choose to reject messages with suspect or harmful
content instead of modifying them.
4.5.1. 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.
Here are some other remediations techniques: Here are some other remediation techniques:
o One common mitigation policy is to configure the Mailing List o One common mitigation policy is to configure the Mailing List
Manager (MLM) to alter the RFC5322.From header field to use the Manager (MLM) to alter the RFC5322.From header field to use the
domain of the MLM. Since most list subscribers prefer to know the domain of the MLM. Since most list subscribers prefer to know the
identity of the author of the original message, typically this identity of the author of the original message, typically this
information may be provided in the display name part of the information may be provided in the display name part of the
RFC5322.From header field. This display name needs to be RFC5322.From header field. This display name needs to be
carefully crafted as to not collide with the original display name carefully crafted as to not collide with the original display name
of the author, nor contain something that looks like an email of the author, nor contain something that looks like an email
address or domain name. These modification may to some extent address or domain name. These modifications may to some extent
defeats 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 author, ensure that users of all email clients can easily reply to the
list, or all using the email client features provided for that author, the list, or all using the email client features provided
purpose. Use of "Reply-To" can alleviate this problem depending for that purpose. Use of RFC5322.Reply-To header field can
if the mailing list is configured to reply-to-list, reply-to- alleviate this problem depending on whether the mailing list is
author or reply-to-fixed-address. configured to reply-to-list, reply-to-author or reply-to-fixed-
address, however it is important to note that this header field
can take multiple email addresses. When altering the RFC5322.From
there are two possibilities, to change it to put the mailing list
email address, or to change it to add a suffix like ".invalid" to
the domain of the email address present there. The later
modification may create issues because it is an invalid domain
name, and some MTAs may take particular attention to the validity
of email addresses in RFC5322.From and the reputation of the
domains present there.
o Another common mitigation policy is to configure the MLM to "wrap" o Another common mitigation policy is to configure the MLM to "wrap"
the message in a MIME message/rfc822 part. This completely the message in a MIME message/rfc822 part and to send as the
bypasses the DMARC policy in clients that allow reading the part Mailing List email address. Many email clients (as of August
as a message. Many email clients (as of August 2014) have 2014) have difficulty reading such messages.
difficulty reading such messages.
o Finally a less common mitigation policy, is to configure the MLM o A, now, less common mitigation policy, is to configure the MLM to
to not modify the message so that the DKIM signature remains not modify the message so that the DKIM signature remains valid.
valid.
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 bounces due bouncing because of DMARC, the MLM needs to not act on bounces due
to Message Authentication issues. Correctly interpreting Extended to Message Authentication issues. [RFC3463] specifies Enhanced
SMTP error messages is useful in this case ([RFC7372]). Mail System Status Codes which help differentiate between various
bounces. Correctly interpreting Extended SMTP error messages is
useful in this case in particular codes defined in [RFC7372] and
in DMARC.
All these techniques may provide some specific challenges in MUAs and All these techniques may provide some specific challenges in 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 alleviated. implications are understood and alleviated.
4.6. Getting More Radical: Requiring New Communication Paths Between 4.2. Proposed and In-Progress Mitigations
MUA and the Message Store
In practice a number of operators are using strict alignement mode in The following mitigations are based on Internet Drafts which have not
yet received broad consensus. They are described here to offer
exploratory path for solutions. These solutions should not be used
in a production environment.
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
[I-D.kucherawy-dkim-delegate] provide ways to extend identifier
alignment under the control of the domain owner.
o DKIM with constrained transformations,
[I-D.kucherawy-dkim-list-canon] is proposed to allow message
modification.
o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform]
is proposed to indicate what limited transformations were done to
the message so that a receiver could reverse them and confirm the
validity of the orignal DKIM signature.
o [I-D.kucherawy-original-authres] is intended as a way to pass
along Original Authentication Results to "downstream" receivers.
It is not widely implemented and relies on a trust relationship
between the forwarder and the other receivers.
o [I-D.levine-dkim-conditional] could be used to have the sender add
a limited DKIM signature, that signs only a very limited set of
header fields and not the body of the message. This DKIM
signature would come with the condition that a subsequent known
domain fully DKIM sign the message. For instance a Mailing List
could transform the message, add its DKIM signature and there
would be a valid DKIM signature aligned with the RFC5322.From that
would satisfy DMARC while limiting the possibilities of replay
attack.
4.2.1. Getting More Radical: Requiring New Communication Paths Between
MUAs
In practice a number of operators are using strict alignment mode in
DMARC in order to avoid receiving new and innovative forms of DMARC in order to avoid receiving new and innovative forms of
unwanted and unauthentic mail 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 third party signatures. 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. However, it introduces no new security issues to Internet Receivers. However, it introduces no new security issues to Internet
messaging. messaging.
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 Dragen 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 mail flows. interoperability issues with DMARC and indirect email flows.
Tim Draegen created the first draft of this document from these Tim Draegen created the first draft of this document from these
contributions and by carefully mapping contributions into the contributions and by hamfistedly mapping contributions into the
language of [RFC5598]. language of [RFC5598].
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, November 1996. Bodies", RFC 2045, November 1996.
skipping to change at page 18, line 28 skipping to change at page 19, line 32
[I-D.kucherawy-dkim-delegate] [I-D.kucherawy-dkim-delegate]
Kucherawy, M. and D. Crocker, "Delegating DKIM Signing Kucherawy, M. and D. Crocker, "Delegating DKIM Signing
Authority", draft-kucherawy-dkim-delegate-01 (work in Authority", draft-kucherawy-dkim-delegate-01 (work in
progress), June 2014. progress), June 2014.
[I-D.kucherawy-dkim-list-canon] [I-D.kucherawy-dkim-list-canon]
Kucherawy, M., "A List-safe Canonicalization for Kucherawy, M., "A List-safe Canonicalization for
DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim-
list-canon-00 (work in progress), June 2014. list-canon-00 (work in progress), June 2014.
[I-D.kucherawy-dkim-transform]
Kucherawy, M., "Recognized Transformations of Messages
Bearing DomainKeys Identified Mail (DKIM) Signatures",
draft-kucherawy-dkim-transform-00 (work in progress),
April 2015.
[I-D.kucherawy-original-authres] [I-D.kucherawy-original-authres]
Chew, M. and M. Kucherawy, "Original-Authentication- Chew, M. and M. Kucherawy, "Original-Authentication-
Results Header Field", draft-kucherawy-original-authres-00 Results Header Field", draft-kucherawy-original-authres-00
(work in progress), February 2012. (work in progress), February 2012.
[I-D.levine-dkim-conditional] [I-D.levine-dkim-conditional]
Levine, J., "DKIM Conditional Signatures", draft-levine- Levine, J., "DKIM Conditional Signatures", draft-levine-
dkim-conditional-00 (work in progress), June 2014. dkim-conditional-00 (work in progress), June 2014.
[I-D.otis-tpa-label] [I-D.otis-tpa-label]
skipping to change at page 19, line 14 skipping to change at page 20, line 28
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)
Eudaemon Eudaemonic Development LLC
NC PO Box 19443
Asheville, NC 28815
USA USA
Email: tim@eudaemon.net Email: tim@eudev.net
Elizabeth Zwicky (editor) Elizabeth Zwicky (editor)
Yahoo Yahoo
Sunnyvale, CA Sunnyvale, CA
USA USA
Email: zwicky@yahoo-inc.com Email: zwicky@yahoo-inc.com
 End of changes. 74 change blocks. 
271 lines changed or deleted 324 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/