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