draft-ietf-dmarc-interoperability-02.txt   draft-ietf-dmarc-interoperability-03.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: October 30, 2015 Cisco Systems GmbH Expires: November 23, 2015 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
Eudaemonic Development LLC Eudaemonic Development LLC
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
April 28, 2015 May 22, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-02 draft-ietf-dmarc-interoperability-03
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting. preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 October 30, 2015. This Internet-Draft will expire on November 23, 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
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 . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.3. Message Modification . . . . . . . . . . . . . . . . . . 5 2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.4. Message Modification . . . . . . . . . . . . . . . . . . 6
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6
3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8
3.1.2.2. Header Standardization . . . . . . . . . . . . . 7 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8
3.1.2.3. Email Address Internationalization . . . . . . . 8 3.1.2.3. Email Address Internationalization . . . . . . . 8
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12
4. Possible Mitigations of Interoperability Issues . . . . . . . 12 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13
4.1.1.2. Message Modification . . . . . . . . . . . . . . 13 4.1.1.2. Message Modification . . . . . . . . . . . . . . 14
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14
4.1.2.3. Email Address Internationalization . . . . . . . 14 4.1.2.3. Email Address Internationalization . . . . . . . 15
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 15
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 15
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 16
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 17
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 17 Paths Between MUAs . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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. The DMARC mechanism can encounter several different types reporting. The DMARC mechanism can encounter several different types
of interoperability issues due to third-party message sourcing, of interoperability issues due to third-party message sourcing,
message transformation or rerouting. message transformation or rerouting.
DMARC is, as this writing, an Informational RFC, however it has a
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 recipients are collectively referred to administrative domain to the recipients are collectively referred to
in this document as indirect email flows. Due to existing and in this document as indirect email flows. Due to existing and
increasing adoption of DMARC, the impact of DMARC-based email 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.
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.
skipping to change at page 4, line 8 skipping to change at page 4, line 17
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 an implementation when conformance to the DMARC specification leads an implementation
to apply DMARC based policy to messages that are both compliant with to apply DMARC based policy to messages that are both compliant with
the architecture as specified in [RFC5598] and viewed as legitimate the architecture as specified in [RFC5598] and viewed as legitimate
by the intended recipient. To be clear, this document does not by the intended recipient. To be clear, this document does not
address emails considered legitimate by the intended recipient but address emails considered legitimate by the intended recipient but
which are not conformant to other email specifications. The rest of which are not conformant to other email specifications. The rest of
this section describes several conceptual causes of interoperability this section describes several conceptual causes of interoperability
issues. issues.
2.1. Identifier Alignment 2.1. Originator vs Receiver Perspective
Some Receivers are concerned that wanted email messages are received,
regardless if such email messages are not strictly in conformance to
any standard or protocol.
Some Originators, particularly for high value transactional messages,
want the message discarded if it passes through an intermediary and
is modified in any way resulting in a failure to validate. Examples
of such messages include those related to financial organizations and
medical establishments.
2.2. Identifier Alignment
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
source validation. The DMARC [RFC7489] mechanism refers to source source validation. The DMARC [RFC7489] mechanism refers to source
domains that are validated by DKIM or SPF as Authenticated domains that are validated by DKIM or SPF as Authenticated
Identifiers. DMARC requires an Authenticated Identifier to be Identifiers. DMARC requires an Authenticated Identifier to be
relevant to the domain found in the message's RFC5322.From header relevant to the domain found in the message's RFC5322.From header
field [RFC5322]. This relevancy is referred to as Identifier field [RFC5322]. This relevancy is referred to as Identifier
Alignment. Alignment.
Identifier Alignment can be strict, where the domains exactly match Identifier Alignment can be strict, where the domains exactly match
skipping to change at page 4, line 42 skipping to change at page 5, line 15
In addition, DKIM allows for the possibility of multiple valid In addition, DKIM allows for the possibility of multiple valid
signatures. The DMARC mechanism will process Authenticated signatures. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational Authenticated Identifier is found (if any). However, operational
experience has shown that some implementations have difficulty experience has shown that some implementations have difficulty
processing multiple signatures. The impact on DMARC processing is processing multiple signatures. The impact on DMARC processing is
clear: implementations that cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
may erroneously apply DMARC based policy to otherwise legitimate may erroneously apply DMARC based policy to otherwise legitimate
messages. messages.
SPF can provides two Authenticated Identifiers based on two different SPF can provide two Authenticated Identifiers based on two different
SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM
[RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for [RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for
alignment. The SPF validated domain in RFC7208.MAILFROM must be part alignment. The SPF validated domain in RFC7208.MAILFROM must be part
of the same Organizational Domain as the domain in the RFC5322.From of the same Organizational Domain as the domain in the RFC5322.From
header field to be aligned. It is important to note that even when header field to be aligned. It is important to note that even when
an SPF record exists for the domain in RFC5322.From, SPF will not an SPF record exists for the domain in RFC5322.From, SPF will not
authenticate it unless it is also the domain in RFC7208.MAILFROM, authenticate it unless it is also the domain in RFC7208.MAILFROM,
furthermore, RFC7208.MAILFROM definition is different from furthermore, RFC7208.MAILFROM definition is different from
RFC5321.MailFrom [RFC5321] definition. RFC5321.MailFrom [RFC5321] definition.
2.2. Message Forwarding 2.3. 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 email being retransmitted by a new All of these behaviors involve email being retransmitted by a new
SMTP 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 RFC7208.MAILFROM, must be aligned with that of the domain of the RFC7208.MAILFROM, must be aligned with that of the
RFC5322.From header field: RFC5322.From header field:
skipping to change at page 5, line 31 skipping to change at page 6, line 5
alignment with the RFC5322.From header field fails. alignment with the RFC5322.From header field fails.
o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the
forwarder will likely be in different organizational domain of the forwarder will likely be in different organizational domain of the
RFC5322.From. SPF may pass but the alignment with the RFC5322.From. SPF may pass but the alignment with the
RFC5322.From header field fails. RFC5322.From header field fails.
In either case, SPF cannot produce a DMARC pass, and DKIM will be In either case, SPF cannot produce a DMARC pass, and DKIM will be
required to get DMARC to pass. required to get DMARC to pass.
2.3. Message Modification 2.4. 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 the most common example of such systems, but other processors are the most common example of such systems, but other
forwarding systems also make modifications. Although DKIM provides a forwarding systems also make modifications. Although DKIM provides a
length flag so that content can be appended (See Section 8.2 of length flag so that content can be appended (See Section 8.2 of
[RFC6376] for additional security considerations), in practice, [RFC6376] for additional security considerations), in practice,
particularly with MIME-encoded [RFC2045] messages, a mailing list particularly with MIME-encoded [RFC2045] messages, a mailing list
processor will do more than append (See Section 5.3 of [RFC5598] for 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 details). Furthermore, the use of the length flag is seldom found in
skipping to change at page 8, line 7 skipping to change at page 8, line 28
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. This correction is outside the scope of DKIM compliant ones. This correction is outside the scope of DKIM
canonicalization and will invalidate DKIM signatures. This canonicalization and will invalidate DKIM signatures. This
correction is also outside the scope of this document in providing correction is also outside the scope of this document in providing
solutions for non RFC compliant emails. 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 related issue may arise 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 non aware MTA will reject it. While an MTA will not
RFC5322.From header field of the message to include group syntax to downgrade a message. The MUA or MSA may resend the message using the
allow the non-aware MTA to receive the email. group syntax to allow the non-aware MTA to receive the email.
This transformation will modify the original content of the message In another case, a MDA, may use the group syntax to pass a message to
and may invalidate any DKIM signatures if the transformation is not a non EAI/SMTPUTF8-aware MS (or user email client). This message
done by the MSA or MUA. In addition, group syntax will remove the could then be forwarded to another recipient.
ability for the DMARC mechanism to find an Organizational Domain that
aligns with any authenticated domain identifier from SPF or DKIM.
In addition, the group syntax may result in the impossibility of For an MTA, the group syntax may result in the impossibility of
finding a domain with a DMARC policy associated with it. If the finding a domain with a DMARC policy associated with it. If the
receiving MTA pays attention to the validity and reputation of receiving MTA pays attention to the validity and reputation of
domains, this may present its own set of delivery problems. For domains, this may present its own set of delivery problems. For
instance an MTA may refuse emails with no valid or emailable domain instance an MTA may refuse emails with no valid or emailable domain
in the RFC5322.From as to avoid simple workarounds against DMARC. in the RFC5322.From as to avoid simple workarounds against DMARC.
This case is not an interoperability issue with DMARC, but with other
email policies an MTA may have to support 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
skipping to change at page 10, line 49 skipping to change at page 11, line 18
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 receiver to identify visually the mailing list. the receiver to identify visually the mailing list.
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 the body to the receiver's key. o PGP-encrypting or S/MIME encrypting the body to the receiver's
key.
o enforcing community standards by rewriting banned words. o enforcing community standards by rewriting banned words.
o allowing moderators to add arbitrary commentary to messages. o allowing moderators to add arbitrary commentary to messages.
Any such modifications would invalidate a DKIM signature. Any such modifications would invalidate a DKIM signature.
Mailing Lists may also have the following DMARC interoperability Mailing Lists may also have the following DMARC interoperability
issues: issues:
skipping to change at page 13, line 47 skipping to change at page 14, line 19
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. Handling DKIM keys with a third party has its security challenges.
o Senders who are sending on behalf of users in other Administrative o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with domain controlled by the Sender, or a placeholder address, with
the original user's address in a RFC5322.Reply-to header field. the original user's address in a RFC5322.Reply-to header field.
However this may affect what the recipient expects in its MUA. However this may affect what the recipient expects in its MUA.
o Senders can use different domains with different DMARC policies
for email sent directly and email known to use indirect mail flow.
However for known brands, all active domains are likely to be
targeted equally by abusers.
4.1.1.2. Message Modification 4.1.1.2. Message Modification
o Senders can maximize survivability of DKIM signatures by limiting o Senders can maximize survivability of DKIM signatures by limiting
the header fields they sign, 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 In order to minimize the chances of transport conversions, Senders o In order to minimize the chances of transport conversions, Senders
skipping to change at page 14, line 42 skipping to change at page 15, line 19
MUA or MSA to use the group syntax for the RFC5322.From header 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 field to avoid a known MTA to reject the message (if RFC5322 is
implemented strictly). While this will alleviate the EAI problem, implemented strictly). While this will alleviate the EAI problem,
it will allow a simple DMARC workaround since the message may no it will allow a simple DMARC workaround since the message may no
longer have a single usable domain in the RFC5322.From header longer have a single usable domain in the RFC5322.From header
field, making DMARC inapplicable. DMARC implementations that pay field, making DMARC inapplicable. DMARC implementations that pay
attention to the validity of the domains in the RFC5322.From may attention to the validity of the domains in the RFC5322.From may
then have to choose between EAI transitioning compliance then have to choose between EAI transitioning compliance
(accepting the email without a domain in RFC5322.From) and (accepting the email without a domain in RFC5322.From) and
security (rejecting RFC-compliant email for lack of a domain in security (rejecting RFC-compliant email for lack of a domain in
the RFC5322.From). The real solution is to upgrade MTAs to the RFC5322.From). The practical solution is to upgrade MTAs to
support EAI (SMTPUTF8), avoiding the transition issue. support EAI (SMTPUTF8), avoiding the transition issue.
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 under Many ReSender issues can be avoided by using an RFC5322.From under
the ReSender's control, instead of the initial RFC5322.From. This the ReSender's control, instead of the initial RFC5322.From. This
will correct identifier alignment issues and allow arbitrary message will correct identifier alignment issues and allow arbitrary message
modification, for instance. When ReSenders change the RFC5322.From, modification, for instance. When ReSenders change the RFC5322.From,
skipping to change at page 15, line 30 skipping to change at page 16, line 8
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.
Here are some other remediation techniques: Here are some remediation techniques on using DMARC with Mailing
lists:
o One common mitigation policy is to configure the Mailing List o One mitigation policy, which is now present on several Mailing
Manager (MLM) to alter the RFC5322.From header field to use the List software, is to configure the Mailing List Manager (MLM) to
domain of the MLM. Since most list subscribers prefer to know the alter the RFC5322.From header field to use the domain of the MLM.
identity of the author of the original message, typically this Since most list subscribers prefer to know the identity of the
information may be provided in the display name part of the author of the original message, typically this information may be
RFC5322.From header field. This display name needs to be provided in the display name part of the RFC5322.From header
carefully crafted as to not collide with the original display name field. This display name needs to be carefully crafted as to not
of the author, nor contain something that looks like an email collide with the original display name of the author, nor contain
address or domain name. These modifications may to some extent something that looks like an email address or domain name. These
defeat the purpose of DMARC itself. It may make it difficult to modifications may to some extent defeat the purpose of DMARC
ensure that users of all email clients can easily reply to the itself. It may make it difficult to ensure that users of all
author, the list, or all using the email client features provided email clients can easily reply to the author, the list, or all
for that purpose. Use of RFC5322.Reply-To header field can using the email client features provided for that purpose. Use of
alleviate this problem depending on whether the mailing list is RFC5322.Reply-To header field can alleviate this problem depending
configured to reply-to-list, reply-to-author or reply-to-fixed- on whether the mailing list is configured to reply-to-list, reply-
address, however it is important to note that this header field to-author or reply-to-fixed-address, however it is important to
can take multiple email addresses. When altering the RFC5322.From note that this header field can take multiple email addresses.
there are two possibilities, to change it to put the mailing list When altering the RFC5322.From there are two possibilities, to
email address, or to change it to add a suffix like ".invalid" to change it to put the mailing list email address, or to change it
the domain of the email address present there. The later to add a suffix like ".invalid" to the domain of the email address
modification may create issues because it is an invalid domain present there. The later modification may create issues because
name, and some MTAs may take particular attention to the validity it is an invalid domain name, and some MTAs may take particular
of email addresses in RFC5322.From and the reputation of the attention to the validity of email addresses in RFC5322.From and
domains present there. the reputation of the domains present there.
o Another common mitigation policy is to configure the MLM to "wrap" o Another mitigation policy is to configure the MLM to "wrap" the
the message in a MIME message/rfc822 part and to send as the message in a MIME message/rfc822 part and to send as the Mailing
Mailing List email address. Many email clients (as of August List email address. Many email clients (as of August 2014) have
2014) have difficulty reading such messages. difficulty reading such messages.
o A, now, less common mitigation policy, is to configure the MLM to o Another mitigation policy, is to configure the MLM to not modify
not modify the message so that the DKIM signature remains valid. the message so that the DKIM signature remains valid. Some
Mailing Lists are mainly setup this way and require little
modifications to ensure the DKIM signature is preserved. However
moving to this policy a list that do extensive modification to the
email, may be too much of a change for the members of such list.
o To alleviate unsubscribes to the mailing list due to the messages o Another mitigation policy, is to reject posts from domains with a
DMARC policy other than p=none. However members of such Mailing
Lists may complain of unfair exclusion.
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. [RFC3463] specifies Enhanced to Message Authentication issues. [RFC3463] specifies Enhanced
Mail System Status Codes which help differentiate between various Mail System Status Codes which help differentiate between various
bounces. Correctly interpreting Extended SMTP error messages is bounces. Correctly interpreting Extended SMTP error messages is
useful in this case in particular codes defined in [RFC7372] and useful in this case in particular codes defined in [RFC7372] and
in DMARC. 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
 End of changes. 32 change blocks. 
74 lines changed or deleted 106 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/