Network Working Group K. Andersen Internet-Draft LinkedIn Intended status: Standards Track S. Jones, Ed. Expires: November 5, 2017 Trusted Domain Project M. Kucherawy, Ed. B. Long, Ed. Google May 4, 2017 The Authenticated Received Chain (ARC) Protocol draft-kucherawy-dmarc-arc-base Abstract The Authenticated Received Chain protocol creates a mechanism whereby a series of handlers of a message can conduct authentication of a message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 November 5, 2017. Copyright Notice Copyright (c) 2017 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 Andersen, et al. Expires November 5, 2017 [Page 1] Internet-Draft Authenticated Received Chains May 2017 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . . 5 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 5 5.1. ARC-Message-Signature . . . . . . . . . . . . . . . . . . 5 5.2. ARC-Authentication-Results . . . . . . . . . . . . . . . . 6 5.3. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. A New Message . . . . . . . . . . . . . . . . . . . . . . 8 6.2. A Message With An ARC . . . . . . . . . . . . . . . . . . 8 7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 9 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9.1. The ARC-Message-Signature header field . . . . . . . . . . 10 9.2. The ARC-Authentication-Results header field . . . . . . . 10 9.3. The ARC-Seal header field . . . . . . . . . . . . . . . . 11 9.4. The 'arc' Authentication Method . . . . . . . . . . . . . 11 9.5. The 'arc' Authentication Results . . . . . . . . . . . . . 12 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11.1. Message Content Suspicion . . . . . . . . . . . . . . . . 14 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 12.1. GMail . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.2. AOL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.5. Mailman . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.6. Copernica/MailerQ . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 18 Andersen, et al. Expires November 5, 2017 [Page 2] Internet-Draft Authenticated Received Chains May 2017 1. Introduction Modern email authentication techniques such as the Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] have become ubiquitious. However, they are stymied by a small number of common applications, most notably mailing list managers, as these applications have handling properties that prevent these authentication schemes from universal effectiveness. These issues are described in substantial detail in those protocols' defining documents as well as in [RFC6377] In an effort to reduce the success of fraudulent email campaigns, there has been an effort to develop and deploy technologies that use SPF and DKIM to assure legitimate use of the identity of the apparent message author, i.e., the visible "From:" field in a message. To this end, Domain-based Mail Authentication, Reporting and Compliance (DMARC) [RFC7489] has been developed and deployed. However, its deployment in environments where mailing lists are used has had the negative impacts predicted in the documents listed above. What is needed is a mechanism by which legitimate alteration of a message, invalidating SPF and DKIM, does not ultimately result in a rejection of an email message on delivery. An Authenticated Received Chain (ARC), described here, provides a superset of the functionality of DKIM in order to provide to the final message recipient a more complete view into the handling chain of a message and the points in that chain where alterations of the content may have occurred. Equipped with this more compelte information, the final recipient can make a more well-informed handling choice, reducing or eliminating the false negatives inherent in use of DKIM and/or SPF alone. 2. Overview In DKIM, every participating signing agent attaches a signature that is based on the content of the message and local policy, and the domain name of the participating Administrative Management Domain (ADMD). Any verifier can process such a signature; a verified signature means the message content that was "covered" by the signature has not been altered since the signature was applied. The signatures themselves are generally independent of one another. By contrast, this protocol seeks to have each signature be able to convey the following pieces of information: 1. As with DKIM, an assertion that, for a passing signature, the domain name in the signature takes some responsibility for handling of the message and that the message is unchanged since that signature was applied; Andersen, et al. Expires November 5, 2017 [Page 3] Internet-Draft Authenticated Received Chains May 2017 2. A further assertion that, at the time that same ADMD processed the message, the various assertions already attached to the message by other ADMDs were or were not valid; 3. A further assertion that combines and protects the above against alteration by later handlers. This protocol accomplishes each of these by adding a new header field to the message for each of them, as follows: ARC-Message-Signature: virtually identical in syntax to DKIM- Signature, this field contains the assertions about the message header and body as they existed at the time of handling by the ADMD adding it; ARC-Authentication-Results: virtually identical in syntax to an Authentication-Results field [RFC7601], this field records the results of all message authentication checks done by the recording ADMD at the time the message arrived; ARC-Seal: highly similar in structure and format to a DKIM- Signature, this field applies a digital signature that protects the integrity of all three of these new fields when they are added by an ADMD, plus all instances of these fields added by prior ADMDs. A distinguishing feature of all of these is that an ARC participant always adds all of them before relaying a message to the next handling agent en route to its destination. Moreover, as described in Section 5, they each have an "instance" number that increases with each ADMD in the handling chain so that their original order can be preserved and the three of them can be processed as a group. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Readers are encouraged to be familiar with the contents of [RFC5598] and in particular, the potential roles of intermediaries in the delivery of email. Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. A single group of the header fields introduced in Section 2 is called an "ARC Set", and the complete sequence of these groups is called an "Authenticated Received Chain" or merely an "ARC". Although the Andersen, et al. Expires November 5, 2017 [Page 4] Internet-Draft Authenticated Received Chains May 2017 "Received" header field is typically not included in the signed content, the name is based on the notion that this is in essence a cryptographically signed series of header fields that attest to the handling chain of a message much as Received fields always have. 4. Instance ('i=') Tags The header fields comprising a single ARC Set are identified by the presence of a leading string in the value portion of the header field that complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. The tag-name is always the single character "i" and the value is the text representation of a positive integer, indicating the position in the ARC sequence this set occupies, where the first ARC Set is numbered 1. In ABNF terms: instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";" On final delivery, it is an error if any ARC Set is invalid (i.e., does not contain exactly one of the three header fields defined by this protocol). 5. The ARC Header Fields The three header fields that are part of this specification borrow heavily from existing specifications. Rather than repeating all of the formal definitions that are being recycled in ARC, this document instead only describes and specifies changes in syntax and semantics. 5.1. ARC-Message-Signature The ARC-Message-Signature header field is defined. It is syntactically and semantically identical to a DKIM-Signature header field [RFC6376], as is the mechanism by which it is constructed, with the following exceptions: o There is an "i" tag, as described in Section 4. o There is no "v" tag. o ARC-Seal header fields are never included in the content covered by the signature in this header field. It is generally advisable to include in the header fields covered by this signature any DKIM-Signature or Authentication-Results header fields already present on the message. As with a DKIM-Signature, the purpose of this header field is to allow the ADMD generating it to take some responsibility for this Andersen, et al. Expires November 5, 2017 [Page 5] Internet-Draft Authenticated Received Chains May 2017 message as it progresses toward delivery. 5.2. ARC-Authentication-Results The ARC-Authentication-Results header field is defined. It is syntactically and semantically identical to an Authentication-Results header field [RFC7601], as is the mechanism by which it is constructed, with the following exception: o There is an "i" tag, as described in Section 4. An ARC signer generates this field in the same way that a conventional Authentication-Results field would be generated. The purpose of this header field is to incorporate into the record the success or failure of any authentication done on the message upstream of the participating ADMD, so that any changes to these results (e.g., because the message was altered) can be identified as to where in the handling chain they occurred. Of particular importance is the recording of the "i=2" instance of this field, which is the first available opportunity in the handling chain of the message to evaluate its apparent validity since departing its originating ADMD. Although this instance of ARC-Authentication- Results has particular value, this does not preclude any operator from attempting to infer other details about the message handling from other instances. 5.3. ARC-Seal The ARC-Seal header field is defined. It is syntactically and semantically similar to a DKIM-Signature field, with the following exceptions: o There is an "i" tag, as described in Section 4. o The ARC-Seal covers none of the body content of the message. It only covers specific header fields. (See below.) As a result, no body canonicalization is done. Further, only "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is used. o The only supported tags are "a", "b", "d, "i", "s", and "t", and their definitions are copied from Section 3.5 of [RFC6376]. o An additional tag, "cv" is defined. (See below.) The purpose of this field is to assure the integrity of the ARC Set being added by the ADMD generating this header field, and moreover to ensure no tampering with the ARC overall. Andersen, et al. Expires November 5, 2017 [Page 6] Internet-Draft Authenticated Received Chains May 2017 5.3.1. The 'cv' Tag A new tag "cv" is defined, which indicates the state of the ARC as evaluated when it arrived at the ADMD adding this header field. It includes one of three possible values: none: There was no chain on the message when it arrived for validation; typically occurs when the message arrives at a Message Transfer Agent (MTA) from a Message Submission Agent (MSA); invalid: There appeared to be an existing ARC on the message, but it was sufficiently malformed as to be unusable; fail: The message has an ARC whose validation failed; pass: The message has an ARC whose validation succeeded. In ABNF terms: seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "invalid" / "fail" / "pass") 5.3.2. Selected Header Fields The ARC-Seal signature is an encryption of the hash of the concatenation of the canonicalized form of the ARC Sets present on the message, in increasing instance order, starting at 1, including the one being added by the ADMD processing the message. Within a set, the header fields are presented in the following order: 1. ARC-Authentication-Results 2. ARC-Message-Signature 3. ARC-Seal Where the ARC-Seal is the one being generated, it is presented to the hash function in its final form except with an empty "b=" value, in the same manner by which a DKIM-Signature signs itself. 6. Signer Actions This section includes a walk-through of the actions an ARC signing implementation takes when presented with a message. Andersen, et al. Expires November 5, 2017 [Page 7] Internet-Draft Authenticated Received Chains May 2017 6.1. A New Message For a message that has no ARC associated with it, most commonly a message arriving at an MTA from an MSA, the signing agent takes the following steps: 1. Do any DKIM signing or other non-ARC authentication steps that the ADMD normally does. 2. Generate and optionally attach to the message an Authentication- Results header field using the ADMD's authserv-id (see Section 2.5 of [RFC7601]) indicating whatever authentication of the MSA might have been done by the MTA, or possibly indicate that none was done. 3. Generate and attach to the message an ARC-Authentication-Results header field using instance number 1 and the same content from the previous step. 4. Generate and attach to the message an ARC-Message-Signature header field using the general algorithm described in Section 5 of [RFC6376] and as modified in Section 5.1 above, using instance number 1. 5. Generate and attach to the message an ARC-Seal header field using the general algorithm described in Section 5.3 above, using a chain validation status of "none" and instance number 1. 6.2. A Message With An ARC For a message that already has an ARC, the process is largely the same except that there is a verification pass first, and if the ADMD elects to continue processing the message, the ARC Set added by the ADMD outbound reflects the results of that verification. Specifically: 1. Validate the ARC on the message according to Section 7. Note the status thus produced, and the highest instance number of a complete ARC Set in the message. Call this number "N". 2. Conduct whatever other message authentication work is normally done on incoming messages. 3. Generate and optionally attach to the message an Authentication- Results header field using the ADMD's authserv-id (see Section 2.5 of [RFC7601]) indicating whatever authentication of the message was done by the MTA, or possibly indicate that none was done. Andersen, et al. Expires November 5, 2017 [Page 8] Internet-Draft Authenticated Received Chains May 2017 4. Generate and attach to the message an ARC-Authentication-Results header field using instance number N+1 and the same content from the previous step. 5. Generate and attach to the message an ARC-Message-Signature header field using the general algorithm described in Section 5 of [RFC6376] and as modified in Section 5.1 above, using instance number N+1. 6. Generate and attach to the message an ARC-Seal header field using the general algorithm described in Section 5.3 above, using a chain validation status representative of the result of the first step above, and instance number N+1. 7. Verifier Actions The verifier takes the following steps to determine the current state of the ARC on the message: 1. Collect all ARC Sets currently on the message. If there were none, the ARC state is "none" and the algorithm stops here. 2. If any ARC Set is invalid (e.g., does not contain exactly one of each of the three ARC-specific header fields), then the chain state is "invalid" and the algorithm stops here. 3. Conduct verification of the ARC-Message-Signature header field bearing the highest instance number. If this verification fails, then the chain state is "fail" and the algorithm stops here. 4. For each ARC-Seal from the "N"th instance to the first, apply the following logic: A. If the value of the "cv" tag on that seal is "invalid" or "fail", the chain state is the same as that value and the algorithm stops here. B. If the instance number being processed is not 1 and the value of the "cv" tag is "none", the chain state is "fail" and the algorithm stops here. C. Prepare a hash function corresponding to the "a" tag of the ARC-Seal. D. Compute the canonicalized form of the ARC header fields, in the order described in Section 5.3.2, using the "relaxed" header canonicalization defined in (Section 3.4.2 of [RFC6376]). Pass them to the hash function. Andersen, et al. Expires November 5, 2017 [Page 9] Internet-Draft Authenticated Received Chains May 2017 E. Retrieve the final digest from the hash function. F. Retrieve the public key identified by the "s" and "d" tags in the ARC-Seal, as described in Section 8. G. Determine whether the signature portion ("b" tag) of the ARC- Seal and the digest computed above are valid according to the public key. H. If the signature is not valid, the chain state is "fail" and the algorithm stops here. 5. If no seals pass validation, then the chain state is "pass", and the algorithm is complete. 8. Key Management The public keys for ARC header fields follow the same requirements, syntax and semantics as those for DKIM signatures, described in Section 3.6 of [RFC6376]. Operators may use distinct selectors for the ARC header fields at their own discretion. 9. IANA Considerations The following registration actions are requested from IANA. 9.1. The ARC-Message-Signature header field The following registration is to be added to the Permanent Message Header Field Names registry: Header field name: ARC-Message-Signature Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): [this document] Related information: none 9.2. The ARC-Authentication-Results header field The following registration is to be added to the Permanent Message Header Field Names registry: Andersen, et al. Expires November 5, 2017 [Page 10] Internet-Draft Authenticated Received Chains May 2017 Header field name: ARC-Authentication-Results Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): [this document] Related information: none 9.3. The ARC-Seal header field The following registration is to be added to the Permanent Message Header Field Names registry: Header field name: ARC-Seal Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): [this document] Related information: none 9.4. The 'arc' Authentication Method The following registration is to be added to the Email Authentication Methods registry: Method: arc Definition: [this document] ptype: header property: d Value: value of ARC seal "d" tag Status: active Andersen, et al. Expires November 5, 2017 [Page 11] Internet-Draft Authenticated Received Chains May 2017 Version: 1 9.5. The 'arc' Authentication Results The following registrations are to be added to the Email Authentication Result Name registry: Code: none Existing/New Code: existing Defined In: [this document] Auth Method: arc (added) Meaning: No ARC (Authenticated Received Chain) was present on this message. Code: pass Existing/New Code: existing Defined In: [this document] Auth Method: arc (added) Meaning: An ARC (Authenticated Received Chain) was present on this message, and its final validation state was "pass". Code: fail Existing/New Code: existing Defined In: [this document] Auth Method: arc (added) Meaning: An ARC (Authenticated Received Chain) was present on this message, and its final validation state was "fail". Code: temperror Existing/New Code: existing Defined In: [this document] Andersen, et al. Expires November 5, 2017 [Page 12] Internet-Draft Authenticated Received Chains May 2017 Auth Method: arc (added) Meaning: An ARC (Authenticated Received Chain) was present on this message, but its evaluation could not be completed due to some error that is likely transient in nature, such as a temporary Domain Name System issue. A later attempt might produce a final result. Code: permerror Existing/New Code: existing Defined In: [this document] Auth Method: arc (added) Meaning: An ARC (Authenticated Received Chain) was present on this message, but its evaluation could not be completed due to some error that is likely not transient in nature, such as a permanent Domain Name System issue. A later attempt is unlikely to produce a final result. 10. Privacy Considerations An intact ARC provides a verifiable record of the handlers for a message. Anonymous remailers or any other party attempting to conceal its participation in the handling of a message will probably not find this to be aligned with their operating goals. 11. Security Considerations The Security Considerations of [RFC6376] and [RFC7601] apply directly to this specification. Inclusion of ARC Sets in the headers of emails may cause problems for some older or more constrained MTAs if they are unable to accept the greater size of the header. Operators who receive a message bearing N ARC Sets has to complete N+1 DNS queries to evaluate the chain (barring DNS redirection mechanisms, which can increase the lookups for a given target value). This has at least two effects: 1. An attacker can send a message to an ARC partipant with a concocted sequence of ARC Sets bearing the domains of intended victims, and all of them will be queried by the participant until a failure is discovered. Andersen, et al. Expires November 5, 2017 [Page 13] Internet-Draft Authenticated Received Chains May 2017 2. DKIM only does one DNS check per signature, while ARC can do many. Absent caching, slow DNS responses can cause Simple Mail Transfer Protocol (SMTP) [RFC5321] timeouts; this could be exploited as a denial-of-service attack. 11.1. Message Content Suspicion Recipients are cautioned to treat messages bearing ARC Sets with the same suspicion that they apply to all other email messages. This includes appropriate content scanning and other checks for potentially malicious content. The handlers which are identified within the ARC may be used to provide input to local policy engines in cases where the sending system's DKIM-Signature does not validate. 12. Implementation Status [Note to the RFC Editor: Please remove this section before publication.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. This information is known to be correct as of the third interoperability test event which was held on 2016-06-17. 12.1. GMail Organization: Google Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Production -- incoming validation Coverage: full specification Licensing: proprietary -- internal only Implementation notes: * Full functionality was demonstrated during interop testing on 2016-06-17 * In place for reporting usage only as of 2016-11-21 on all GMail flows * Re-checked general incoming validation as of 2017-02-24 interop event Andersen, et al. Expires November 5, 2017 [Page 14] Internet-Draft Authenticated Received Chains May 2017 Contact Info: arc-discuss@dmarc.org 12.2. AOL Organization: AOL Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Beta Coverage: Chain validity status checking is not operation, but all other functions provided Licensing: proprietary -- internal only Implementation notes: * Full functionality except for chain validation was demonstrated during interop testing on 2016-06-17 * Available for production mail via selected account whitelisting for test validation only * Intermittent stability problems discovered at the interop event of 2017-02-24. Remediation in progress. Contact Info: arc-discuss@dmarc.org 12.3. dkimpy Organization: dkimpy developers Description: Python DKIM package with added ARC support Status of Operation: Production Coverage: Chain validation demonstrated to interoperate with AOL and GMail implementations. Licensing: Open/Other (same as dkimpy package) Implementation notes: N/A Contact Info: arc-discuss@dmarc.org Andersen, et al. Expires November 5, 2017 [Page 15] Internet-Draft Authenticated Received Chains May 2017 12.4. OpenARC Organization: The Trusted Domain Project Description: Open source C implementation Status of Operation: In development Coverage: Full specification Licensing: Two-Clause BSD Implementation notes: * Based on the successful OpenDKIM implementation Contact Info: openarc-discuss@trusteddomain.org 12.5. Mailman Organization: Mailman development team Description: Integrated ARC capabilities within the Mailman package Status of Operation: Patch submitted Coverage: Not known Licensing: GPL Contact Info: https://www.gnu.org/software/mailman/contact.html 12.6. Copernica/MailerQ Organization: Copernica Description: Web-based validation of ARC-signed messages Status of Operation: Beta Coverage: full specification Licensing: on-line use only Implementation notes: * Released 2016-10-24 Andersen, et al. Expires November 5, 2017 [Page 16] Internet-Draft Authenticated Received Chains May 2017 * Requires full message content to be pasted into a web form found at [http://arc.mailerq.com]; https is not supported * An additional instance of an ARC signature can be added if one is willing to paste a private key into an unsecured web form. * Appears to interoperate properly. Contact Info: https://www.copernica.com 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [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, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/ RFC7601, August 2015, . 13.2. Informative References [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, . Andersen, et al. Expires November 5, 2017 [Page 17] Internet-Draft Authenticated Received Chains May 2017 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . Appendix A. Acknowledgments TBD Appendix B. Examples [to be copied from draft-ietf-dmarc-arc-protocol] Authors' Addresses Kurt Andersen LinkedIn 100 West Maude Ave. Sunnyvale, CA 94043 United States EMail: kurta@linkedin.com Steven Jones (editor) Trusted Domain Project EMail: smj@crash.com Murray S. Kucherawy (editor) 270 Upland Drive San Francisco, CA 94127 United States EMail: superuser@gmail.com Brandon Long (editor) Google EMail: blong@google.com Andersen, et al. Expires November 5, 2017 [Page 18]