draft-ietf-dmarc-arc-protocol-08.txt		draft-ietf-dmarc-arc-protocol-09.txt
	DMARC Working Group K. Andersen		DMARC Working Group K. Andersen
	Internet-Draft LinkedIn		Internet-Draft LinkedIn
	Intended status: Standards Track B. Long, Ed.		Intended status: Standards Track B. Long, Ed.
	Expires: January 22, 2018 Google		Expires: March 10, 2018 Google
	S. Jones, Ed.		S. Jones, Ed.
	M. Kucherawy, Ed.		M. Kucherawy, Ed.
	TDP		TDP
	July 21, 2017		September 06, 2017
	Authenticated Received Chain (ARC) Protocol		Authenticated Received Chain (ARC) Protocol
	draft-ietf-dmarc-arc-protocol-08		draft-ietf-dmarc-arc-protocol-09
	Abstract		Abstract
	The Authenticated Received Chain (ARC) protocol creates a mechanism		The Authenticated Received Chain (ARC) protocol creates a mechanism
	whereby a series of handlers of a message can conduct authentication		whereby a series of handlers of an email message can conduct
	of a message as it passes among them on the way to its destination,		authentication of the email message as it passes among them on the
	and record the status of that authentication at each step along the		way to its destination, and record the status of that authentication
	handling path, for use by the final recipient in making choices about		at each step along the handling path, for use by the final recipient
	the disposition of the message.		in making choices about the disposition of the message. Changes in
			the message that might break DKIM or DMARC can be identified through
			the ARC set of header fields.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 January 22, 2018.		This Internet-Draft will expire on March 10, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(https://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
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions and Terminology . . . . . . . . . . . . . . . . . 5
	4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5		3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
	4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6		4. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . . . 6
	5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6		4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 7
	5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6		5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 7
			5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 7
	5.1.1. Additional Information for the AAR Header . . . . . . 7		5.1.1. Additional Information for the AAR Header . . . . . . 7
	5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7		5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 8
	5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8		5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8
	5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9		5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9
	5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9		5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9
	6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9		6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 10
	7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11		7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12		8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12
	9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12		9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12
	9.1. Relationship between DKIM-Signature and AMS signing		9.1. Relationship between DKIM-Signature and AMS signing
	scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12		scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12		9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12
	9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 12		9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 13
	9.4. Handling DNS Problems While Validating ARC . . . . . . . 13		9.4. Handling DNS Problems While Validating ARC . . . . . . . 13
	9.5. Responding to ARC Validity Violations . . . . . . . . . . 13		9.5. Responding to ARC Validity Violations . . . . . . . . . . 13
	9.6. Recording the Results of ARC Evaluation . . . . . . . . . 13		10. Recording and Reporting the Results of ARC Evaluation . . . . 13
	9.6.1. Output Information from an ARC Evaluation . . . . . . 13		10.1. Information from an ARC Evaluation . . . . . . . . . . . 13
	9.6.2. Reporting ARC Effects for DMARC Local Policy -		10.2. Recording (local) ARC Evaluation Results . . . . . . . . 14
	Interim . . . . . . . . . . . . . . . . . . . . . . . 14		10.3. DMARC Reporting of ARC Findings - Interim . . . . . . . 14
	10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 14		11. Supporting Alternate Signing Algorithms . . . . . . . . . . . 15
	10.1. Introductory Period . . . . . . . . . . . . . . . . . . 15		11.1. Introductory Period . . . . . . . . . . . . . . . . . . 15
	10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15		11.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15
	10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15		11.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15
	10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15		11.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15		12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	12.1. Authentication-Results Method Registry Update . . . . . 15		13.1. Authentication-Results Method Registry Update . . . . . 16
	12.2. Definitions of the ARC header fields . . . . . . . . . . 16		13.2. Definitions of the ARC header fields . . . . . . . . . . 16
	13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17		14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	13.1. GMail test reflector and incoming validation . . . . . . 17		14.1. Message Content Suspicion . . . . . . . . . . . . . . . 17
	13.2. AOL test reflector and internal tagging . . . . . . . . 18
	13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 18		15. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
	13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 18		15.1. GMail test reflector and incoming validation . . . . . . 18
	13.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 19		15.2. AOL test reflector and internal tagging . . . . . . . . 19
	13.6. Copernica/MailerQ web-based validation . . . . . . . . . 20		15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19
	13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 20		15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 20
	13.8. PERL Mail::Milter::Authentication module . . . . . . . . 21		15.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 20
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 21		15.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
	14.1. Message Content Suspicion . . . . . . . . . . . . . . . 22		15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 21
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		15.8. PERL Mail::Milter::Authentication module . . . . . . . . 22
	15.1. Normative References . . . . . . . . . . . . . . . . . . 22		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	15.2. Informative References . . . . . . . . . . . . . . . . . 24		16.1. Normative References . . . . . . . . . . . . . . . . . . 22
	15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25		16.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Appendix A - Example Usage (Obsolete but retained		16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	for illustrative purposes) . . . . . . . . . . . . . 25		Appendix A. Appendix A - Design Requirements . . . . . . . . . . 25
	A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25		A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 25
	A.1.1. Here's the message as it exits the Origin: . . . . . 25		A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 26
	A.1.2. Message is then received at example.org . . . . . . . 26		Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 26
	A.1.3. Example 1: Message received by Recipient . . . . . . 28		B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 26
	A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29		B.1.1. Here's the message as it exits the Origin: . . . . . 26
	A.2.1. Here's the message as it exits the Origin: . . . . . 29		B.1.2. Message is then received at example.org . . . . . . . 27
	A.2.2. Message is then received at example.org . . . . . . . 30		B.1.3. Example 1: Message received by Recipient . . . . . . 29
	A.2.3. Example 2: Message received by Recipient . . . . . . 34		B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 30
	A.3. Example 3: Mailing list to forwarded mailbox with source 36		B.2.1. Here's the message as it exits the Origin: . . . . . 30
	A.3.1. Here's the message as it exits the Origin: . . . . . 36		B.2.2. Message is then received at example.org . . . . . . . 31
	A.3.2. Message is then received at example.org . . . . . . . 37		B.2.3. Example 2: Message received by Recipient . . . . . . 35
	A.3.3. Example 3: Message received by Recipient . . . . . . 42		B.3. Example 3: Mailing list to forwarded mailbox with source 37
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44		B.3.1. Here's the message as it exits the Origin: . . . . . 37
	Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45		B.3.2. Message is then received at example.org . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		B.3.3. Example 3: Message received by Recipient . . . . . . 43
			Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 45
			Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 46
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	Modern email authentication techniques such as the Sender Policy		Modern email authentication techniques such as the Sender Policy
	Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)		Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
	[RFC6376] have become ubiquitious. However, they are stymied by a		[RFC6376] have become common.
	small number of common applications, most notably mailing list		However, their end-to-end utility is limited by the effects of
	managers, as these applications have handling properties that prevent		intermediaries along the transmission path, which either are not
	these authentication schemes from universal effectiveness. These		listed (for SPF) or which break digital signatures (for DKIM). These
	issues are described in substantial detail in those protocols'		issues are described in substantial detail in those protocols'
	defining documents as well as in [RFC6377] and [RFC7960].		defining documents as well as in [RFC6377] and [RFC7960].
	In an effort to reduce the success of fraudulent email campaigns,		Technologies that build upon the use of SPF and DKIM can reduce the
	there has been an effort to develop and deploy technologies that use		success of fraudulent email campaigns. To this end, Domain-based
	SPF and DKIM to assure legitimate use of the identity of the apparent		Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
	message author, i.e., the visible "From:" field in a message. To		validates the domain of the RFC5322.From author header field.
	this end, Domain-based Mail Authentication, Reporting and Compliance
	(DMARC) [RFC7489] has been developed and deployed. However, its		However its use along email transmission paths that have independent
	deployment in environments where mailing lists are used has had the		intermediaries, such as some forwarders and essentially all mailing
	negative impacts predicted in the documents listed above.		list services, produces false positive rejections that are
			problematic, both for the message authors, the intermediary
			service(s), and for those they are interacting with.
	What is needed is a mechanism by which legitimate alteration of a		What is needed is a mechanism by which legitimate alteration of a
	message, invalidating SPF and DKIM, does not ultimately result in a		message, which invalidates associated SPF and DKIM information, does
	rejection of an email message on delivery. An Authenticated Received		not ultimately result in a rejection of an email message on delivery.
	Chain (ARC), described here, provides a superset of the functionality		Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
	of DKIM in order to provide to the message recipient system(s) a more		provide a sequence of signatures that are more survivable than DKIM's
	complete view into the handling chain of a message and the points in		and that provide a view of the handling sequence for a message,
	that chain where alterations of the content may have occurred.		especially the points where alterations of the content might have
	Equipped with this more complete information, the recipient system(s)		occurred. Equipped with this more complete information, the
	can make a more informed handling choice, reducing or eliminating the		recipient system(s) can make a more informed handling choice,
	false postives inherent in use of DKIM and/or SPF themselves.		reducing or eliminating the false negatives inherent in use of DKIM
			and/or SPF themselves.
	2. Overview		2. Overview
	In DKIM, every participating signing agent attaches a signature that		In DKIM, every participating signing agent attaches a signature that
	is based on the content of the message, local policy, and the domain		is based on the some of the content of the message, local policy, and
	name of the participating Administrative Management Domain (ADMD).		the domain name of the participating Administrative Management Domain
	Any verifier can process such a signature; a verified signature means		(ADMD). Any verifier can process such a signature; a verified
	the message content that was "covered" by the signature has not been		signature means that the domain referenced in the DKIM-Signture's
	altered since the signature was applied. The signatures themselves		"d=" parameter has some responsibility for handling the message. An
	are generally independent of one another.		artifact of using digital signature technology for this means that
			verification also ensures that 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		By contrast, an ARC signature conveys the following pieces of
	convey the following pieces of information:		information:
	1. An assertion that, at the time that the intermediary ADMD		1. An assertion that, at the time that the intermediary ADMD
	processed the message, the various assertions already attached to		processed the message, the various assertions (DKIM-Signature(s)
	the message by other ADMDs were or were not valid;		and/or ARC sets) already attached to the message by other ADMDs
			were or were not valid;
	2. As with DKIM, an assertion that, for a passing signature, the		2. As with DKIM, an assertion that, for a validated signature, the
	domain name in the signature takes some responsibility for		domain name in the signature takes some responsibility for
	handling of the message and that the message is unchanged since		handling of the message and that the message is unchanged since
	that signature was applied;		that signature was applied;
	3. A further assertion that combines and protects the above against		3. A further assertion that binds the ARC evaluation results into
	alteration by later handlers.		the ARC chain sequence.
	This protocol accomplishes each of these by adding a new header field		This protocol accomplishes each of these by adding a new header field
	to the message for each of them, as follows:		to the message for each of these pieces of information, as follows:
	o ARC-Authentication-Results (referred to below as "AAR"): virtually		o ARC-Authentication-Results (referred to below as "AAR"): virtually
	identical in syntax to an Authentication-Results field [RFC7601],		identical in syntax to an Authentication-Results field [RFC7601],
	this field records the results of all message authentication		this field records the results of all message authentication
	checks done by the recording ADMD at the time the message arrived.		checks done by the recording ADMD at the time the message arrived.
	Additional information is added to this field compared to a		Additional information is placed in this field compared to a
	standard Authentication-Results field in order to support a more		standard Authentication-Results field in order to support a more
	complete DMARC report (see Section 5.1);		complete DMARC report (see Section 5.1);
	o ARC-Message-Signature (referred to below as "AMS"): virtually		o ARC-Message-Signature (referred to below as "AMS"): virtually
	identical in syntax to DKIM-Signature, this field contains the		identical in syntax to DKIM-Signature, this field contains the
	assertions about the message header and body as they existed at		signature about the message header and body as they existed at the
	the time of handling by the ADMD adding it; and		time of handling by the ADMD adding it; and
	o ARC-Seal (referred to below as "AS"): highly similar in structure		o ARC-Seal (referred to below as "AS"): highly similar in structure
	and format to a DKIM-Signature, this field applies a digital		and format to a DKIM-Signature, this field applies a digital
	signature that protects the integrity of all three of these new		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 when they are added by an ADMD, plus all instances of these
	fields added by prior ADMDs.		fields added by prior ADMDs.
	A distinguishing feature of all of these is that an ARC participant		A distinguishing feature of all of these is that an ARC participant
	always adds all of them before relaying a message to the next		always adds all of them before relaying a message to the next
	handling agent en route to its destination. Moreover, as described		handling agent en route to its destination. Moreover, as described
	in Section 4, they each have an "instance" number that increases with		in Section 4, they each have an "instance" number that increases with
	each ADMD in the handling chain so that their original order can be		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.		preserved and the three related header fields can be processed as a
			group.
	3. Terminology		3. Definitions and Terminology
	This section defines terms used in the rest of the document.		This section defines terms used in the rest of the document.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Readers are encouraged to be familiar with the contents of [RFC5598],		Because many of the core concepts and definitions are found in
	and in particular, the potential roles of intermediaries in the		[RFC5598], readers SHOULD to be familiar with the contents of
	delivery of email.		[RFC5598], and in particular, the potential roles of intermediaries
			in the delivery of email.
	Syntax descriptions use Augmented BNF (ABNF) [RFC5234].		Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
	A single group of the header fields introduced in Section 2 is called		o "ARC set" - A single group of the header fields introduced in
	an "ARC set", and the complete sequence of these groups is called an		Section 2 is called an "ARC set".
	"Authenticated Received Chain" or merely an "ARC chain". Although
	the "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		o "ARC chain" - The complete sequence of these groups (ARC sets) is
			called an "Authenticated Received Chain" or merely an "ARC chain".
			Although the "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.
			3.1. Referenced Definitions
			The following terms are defined in other RFCs. Those definitions can
			be found as follows:
			o ADMD - [RFC5598], Section 2.3
			o MTA - [RFC5598], Section 4.3.2
			o MSA - [RFC5598], Section 4.3.1
			o MDA - [RFC5598], Section 4.3.3
			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 reused in ARC, this document
			only describes and specifies changes in syntax and semantics.
			Language, syntax, and other details are imported from DKIM [RFC6376].
			Specific references can be found below.
			4. Instance ('i=') Tag
	The header fields comprising a single ARC set are identified by the		The header fields comprising a single ARC set are identified by the
	presence of a string in the value portion of the header field that		presence of a string in the value portion of the header field that
	complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].		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		The tag-name is "i" and the value is the text representation of a
	text representation of a positive integer, indicating the position in		positive integer, indicating the position in the ARC sequence this
	the ARC sequence this set occupies, where the first ARC set is		set occupies, where the first ARC set is numbered 1. In ABNF terms:
	numbered 1. In ABNF terms:
	instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"		instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
			position = 1*DIGIT
	At any delivery stage, it is an error if any ARC set is invalid		Valid ARC sets must have exactly one instance of each header field
	(i.e., does not contain exactly one of the three header fields		for a given position value. (Note that when multiple algorithms are
	defined by this protocol). (Note that when multiple algorithms are		supported, there is some nuance to this statement - see Section 11.)
	supported, there is some nuance to this statement - see Section 10.)
	Note that because the AMS and AS header field values are made up of		Because the AMS and AS header field values are made up of tag-spec
	tag-spec constructs, the i= tag may be found anywhere within the		constructs, the i= tag may be found anywhere within the header field
	header field value, but is represented throughout this spec in the		value, but is represented throughout this spec in the initial
	initial position for convenience. Implementers SHOULD seek to start		position for convenience. Implementers are encouraged to place the
	with the i= tag to facilitate human inspection of the headers.		i= tag at the beginning of the field value to facilitate human
			inspection of the headers.
	4.1. Valid Range for Instance Tags		4.1. Valid Range for Instance Tags
	The 'i' tag value can range from 1-1024 (inclusive).		The 'i' tag value can range from 1-1024 (inclusive).
	ARC implementations MUST support at least ten (10) intermediary		ARC implementations MUST support at least ten (10) ARC sets.
	steps.
	More than fifty (50) intermediaries is considered extremely unlikely		An effective operational maximum will have to be developed through
	so ARC chains with more than fifty intermediaries may be marked with		deployment experience in the field and will be documented within
	"cv=fail".		[ARC-USAGE] once determined.
	5. The ARC Header Fields		ARC chains with more than the defined operational maximum count MAY
			be marked with "cv=fail".
	The three header fields that are part of this specification borrow		5. The ARC Header Fields
	heavily from existing specifications. Rather than repeating all of
	the formal definitions that are being reused in ARC, this document
	only describes and specifies changes in syntax and semantics.
	5.1. ARC-Authentication-Results (AAR)		5.1. ARC-Authentication-Results (AAR)
	The ARC-Authentication-Results header field is defined. It is		The ARC-Authentication-Results header field is syntactically and
	syntactically and semantically identical to an Authentication-Results		semantically identical to an Authentication-Results header field
	header field [RFC7601] (A-R), as is the mechanism by which it is		(defined in Section 2.2 of [RFC7601] (A-R)), except for one mandatory
	constructed, with the following exception:		addition and several optional data fields. These deviations are:
	o There is an "i" tag, as described in Section 4; and		o There is an "i" tag, as described in Section 4; and
	o Two (or more) additional pieces of information MAY be added (see		o Two (or more) additional pieces of information MAY be added (see
	Section 5.1.1).		Section 5.1.1).
	The instance identifier MUST be separated from the rest of the		The instance identifier MUST be separated from the rest of the
	Authentication-Results value contents with a semi-colon (';', 0x3b).		Authentication-Results value contents with a semi-colon (';', 0x3b).
	The purpose of this header field is to incorporate into the record		The purpose of this header field is to incorporate into the record
	the success or failure of any authentication done on the message		the success or failure of any authentication done on the message
	upstream of the participating ADMD, to validate and continue the		upstream of the participating ADMD that is validating and continuing
	authentication chain.		the authentication chain.
	In processing, some architectures will generate multiple A-R records		The AAR MUST contain all A-R results from within the participating
	for the same authserv-id. In such cases, the resinfo value from each		ADMD, regardless of how many A-R headers are on the message.
	of the A-R records should be concatenated into a single record just
	as they would have been if they were generated in a single A-R
	record.
	5.1.1. Additional Information for the AAR Header		5.1.1. Additional Information for the AAR Header
	An ARC signer generates this field in the same way that a		An ARC signer generates this field in the same way that a
	conventional A-R field would be generated. Because the AAR is		conventional A-R field would be generated. Because the AAR is
	designed for machine-based consumption over the course of a message's		designed for machine-based consumption over the course of a message's
	transit through a series of mediators and to facilitate		transit through a series of mediators and to facilitate
	troubleshooting of problematic sources by sending organizations,		troubleshooting of problematic sources by sending organizations,
	three additional fields of data SHOULD be added to the normal A-R		three additional fields of data SHOULD be added to the normal A-R
	content, dependent on the presence of DKIM-Signature and/or ARC		content, dependent on the presence of DKIM-Signature and/or ARC
	set(s) and if available to the ADMD which is recording the A-R:		set(s) and if available to the ADMD which is recording the A-R:
	o source.ip - The connecting client IP address from which the		o smtp.client_id - The connecting client IP address from which the
	message is received; and		message was received;
	o header.s - The selector value associated with each dkim signature
	(added to the dkim data sections of the A-R/AAR record)
	o ARC-related data (added to the arc data sections of the A-R/AAR
	record):
	* ams[N].d - The domain value associated with the 'N'th ARC set's
	AMS header
	* ams[N].s - The selector associated with the 'N'th ARC set's AMS
	header
	* as[N].d - The domain value associated with the 'N'th ARC set's		o header.ds - The domain/selector pair for each dkim signature on
	AS header		the message (header.ds=example.com,selector)
	* as[N].s - The selector associated with the 'N'th ARC set's AS		o arc.closest_fail - The hop number of the most recent AMS that
	header		fails to validate, or 0 if all hops pass.
	5.2. ARC-Message-Signature (AMS)		5.2. ARC-Message-Signature (AMS)
	The ARC-Message-Signature header field is defined. It is		The ARC-Message-Signature header field is syntactically and
	syntactically and semantically identical to a DKIM-Signature header		semantically identical to a DKIM-Signature header field [RFC6376],
	field [RFC6376], as is the mechanism by which it is constructed, with		with the following exceptions:
	the following exceptions:
	o There is an "i" tag, as described in Section 4.		o There is an "i" tag, as described in Section 4.
	o There is no "v" tag.		o There is no "v" tag.
	ARC-Seal header fields MUST never be included in the content covered		ARC-Seal header fields MUST NOT be included in the content covered by
	by the signature in this header field.		the signature in this header field.
	The AMS SHOULD include any DKIM-Signature header fields already		The AMS SHOULD include any DKIM-Signature header fields already
	present on the message in the header fields covered by this		present on the message in the header fields covered by this
	signature.		signature.
	The AMS header field MAY inclue (sign) the AAR header field(s).		The AMS header field MAY include (sign) the AAR header field(s).
	Authentication-Results header fields SHOULD NOT be included since		Authentication-Results header fields SHOULD NOT be included since
	they are likely to be deleted by downstream ADMDs (per Section XXX of		they are likely to be deleted by downstream ADMDs (per Section XXX of
	[RFC7601]), thereby breaking the AMS signature.		[RFC7601]), thereby breaking the AMS signature.
	As with a DKIM-Signature, the purpose of this header field is to		As with a DKIM-Signature, the purpose of this header field is to
	allow the ADMD generating it to take some responsibility for handling		allow the ADMD generating it to take some responsibility for handling
	this message as it progresses toward delivery.		this message as it progresses toward delivery.
	5.3. ARC-Seal (AS)		5.3. ARC-Seal (AS)
	The ARC-Seal header field is defined. It is syntactically and		The ARC-Seal header field is syntactically and semantically similar
	semantically similar to a DKIM-Signature field, with the following		to a DKIM-Signature field, with the following exceptions:
	exceptions:
	o There is an "i" tag, as described in Section 4.		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		o The ARC-Seal covers none of the body content of the message. It
	only covers specific header fields. (See below: Section 5.3.2.)		only covers specific header fields. (See below: Section 5.3.2.)
	As a result, no body canonicalization is done. Further, only		As a result, no body canonicalization is done. Further, only
	"relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is		"relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
	used.		used.
	o The only supported tags are "i" (Section 4 supercedes the		o The only supported tags are "i" (Section 4 supercedes the
	[RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5		[RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
	tag definitions are copied from Section 3.5 of [RFC6376].		tag definitions are copied from Section 3.5 of [RFC6376].
	o An additional tag, "cv" is defined. (See below: Section 5.3.1)		o An additional tag, "cv" is defined. (See below: Section 5.3.1)
	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.
	5.3.1. The 'cv' Tag		5.3.1. The 'cv' Tag
	A new tag "cv" (chain validation) is defined, which indicates the		A new tag "cv" (chain validation) indicates the the outcome of
	state of the ARC chain as evaluated when it arrived at the ADMD		evaluating the existing ARC chain upon arrival at the ADMD that is
	adding this header field. It accepts one of three possible values:		adding this header field. It accepts one of three possible values:
	o none: There was no chain on the message when it arrived for		o none: There was no chain on the message when it arrived for
	validation; typically occurs when the message arrives at a Message		validation; typically occurs when the message arrives at a Message
	Transfer Agent (MTA) from a Message Submission Agent (MSA) or when		Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
	any upstream MTAs may not be participating in ARC handling;		any upstream MTAs may not be participating in ARC handling;
	o fail: The message has a chain whose validation failed;		o fail: The message has a chain whose validation failed;
	o pass: The message has a chain whose validation succeeded.		o pass: The message has a chain whose validation succeeded.
	In ABNF terms:		In ABNF terms:
	seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")		seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
	5.3.2. Selected Header Fields		5.3.2. Selected Header Fields
	The ARC-Seal signature is an encryption of the hash of the		[[ Note: reword sentence 1 per Dave's comments ]]
			The ARC-Seal signature is a signature of the hash of the
	concatenation of the canonicalized form of the ARC sets present on		concatenation of the canonicalized form of the ARC sets present on
	the message at the time of sealing, in increasing instance order,		the message at the time of sealing, in increasing instance order,
	starting at 1, including the one being added at the time of sealing		starting at 1, including the one being added at the time of sealing
	the message.		the message.
	Within a set, the header fields are presented in the following order:		Within a set, the header fields are listed in the following order:
	1. ARC-Authentication-Results		1. ARC-Authentication-Results
	2. ARC-Message-Signature		2. ARC-Message-Signature
	3. ARC-Seal		3. ARC-Seal
			Where the ARC-Seal is the one being generated, it is input to the
	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		hash function in its final form except with an empty "b=" value, in
	the same manner by which a DKIM-Signature signs itself.		the same manner by which a DKIM-Signature signs itself.
	Note that the signing scope for the ARC-Seal is modified in the		Note that the signing scope for the ARC-Seal is modified in the
	situation where a chain has failed validation (see Section 9.3).		situation where a chain has failed validation (see Section 9.3).
	6. Verifier Actions		6. Verifier Actions
	The verifier takes the following steps to determine the current state		The verifier takes the following steps to determine the current state
	of the ARC on the message:		of the ARC chain on the message. Canonicalization, hash functions,
			and signature validation methods are imported from Section 5 of
			[RFC6376].
			[[ Note: need markdown flag to have subordinate numbering distinction
			]]
	1. Collect all ARC sets currently on the message. If there were		1. Collect all ARC sets currently on the message. If there were
	none, the ARC state is "none" and the algorithm stops here.		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		2. If the form of any ARC set is invalid (e.g., does not contain
	each of the three ARC-specific header fields), then the chain		exactly one of each of the three ARC-specific header fields),
	state is "fail" and the algorithm stops here.		then the chain state is "fail" and the algorithm stops here.
	1. To bypass all cryto and DNS operations, the cv value for all		1. To avoid the overhead of unnecessary computation and delay
	ARC-Seal(s) MAY be checked at this point. If any of the		from crypto and DNS operations, the cv value for all ARC-
	values are "fail", then the overall state of the chain is		Seal(s) MAY be checked at this point. If any of the values
	"fail" and the algorithm stops here.		are "fail", then the overall state of the chain is "fail" and
			the algorithm stops here.
	3. Conduct verification of the ARC-Message-Signature header field		3. Conduct verification of the ARC-Message-Signature header field
	bearing the highest instance number. If this verification fails,		bearing the highest instance number. If this verification fails,
	then the chain state is "fail" and the algorithm stops here.		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		4. For each ARC-Seal from the "N"th instance to the first, apply the
	following logic:		following logic:
	1. If the value of the "cv" tag on that seal is "fail", the		1. If the value of the "cv" tag on that seal is "fail", the
	chain state is "fail" and the algorithm stops here. (note		chain state is "fail" and the algorithm stops here. (This
	that this duplicates step 2.1)		step SHOULD be skipped if the earlier step (2.1) was
			performed)
	2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv		2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
	== "none" && i != 1)) then the chain state is "fail" and the		== "none" && i != 1)) then the chain state is "fail" and the
	algorithm stops here.		algorithm stops here (note that the ordering of the logic is
			structured for short-circuit evaluation).
	3. Prepare a hash function corresponding to the "a" tag of the		3. Initialize a hash function corresponding to the "a" tag of
	ARC-Seal.		the ARC-Seal.
	4. Compute the canonicalized form of the ARC header fields, in		4. Compute the canonicalized form of the ARC header fields, in
	the order described in Section 5.3.2, using the "relaxed"		the order described in Section 5.3.2, using the "relaxed"
	header canonicalization defined in Section 3.4.2 of		header canonicalization defined in Section 3.4.2 of
	[RFC6376]. Pass them to the hash function.		[RFC6376]. Pass the canonicalized result to the hash
			function.
	5. Retrieve the final digest from the hash function.		5. Retrieve the final digest from the hash function.
	6. Retrieve the public key identified by the "s" and "d" tags in		6. Retrieve the public key identified by the "s" and "d" tags in
	the ARC-Seal, as described in Section 8.		the ARC-Seal, as described in Section 8.
	7. Determine whether the signature portion ("b" tag) of the ARC-		7. Determine whether the signature portion ("b" tag) of the ARC-
	Seal and the digest computed above are valid according to the		Seal and the digest computed above are valid according to the
	public key.		public key. (See also Section Section 9.4 for failure case
			handling)
	8. If the signature is not valid, the chain state is "fail" and		8. If the signature is not valid, the chain state is "fail" and
	the algorithm stops here.		the algorithm stops here.
	5. If all seals pass validation, then the chain state is "pass", and		5. If all seals pass validation, then the chain state is "pass", and
	the algorithm is complete.		the algorithm is complete.
	The verifier should record the cv state for subsequent use by any		[[ Note from Dave: possibly delete the following paragraph as it is
			more usage/procedural than specification guidance. KA: It was added
			to clarify the separation of the verification and signing steps as
			some of the initial implementations failed to realize that they were
			not necessarily done in one fell swoop. ]]
			The verifier should save the cv state for subsequent use by any
	sealing which may be done later (potentially after message		sealing which may be done later (potentially after message
	modification) within the same trust boundary. The cv state may be		modification) within the same trust boundary. The cv state may be
	recorded by sealing at the time of verification in an initial ARC set		recorded by sealing at the time of verification in an initial ARC set
	(for the ADMD) or may be recorded out of band depending on the		(for the ADMD) or may be recorded out of band depending on the
	architecture of the ADMD.		architecture of the ADMD.
	7. Signer Actions		7. Signer Actions
	This section includes a walk-through of the actions an ARC signing		[[ Note from Dave: This seems more like implementation guidance than
	implementation takes when presented with a message.		specification detail. KA: see explanation just above referring to
			the previous note. ]]
	The signing agent should undertake the following steps:
	1. Do any authentication steps that the ADMD normally does:
	1. If a message is traveling within the same trust boundary,
	this would include any internal trust conveyed with the
	message;
	2. If a message is coming from outside the same trust boundary,		This section includes a specification of the actions an ARC signer
	this would include any SPF / DKIM / DMARC / other		takes when presented with a message.
	authentication evaluation steps.
	2. Do any DKIM signing or authentication assertion steps that the		The signer MUST undertake the following steps:
	ADMD normally does.
	3. Generate and optionally attach to the message an Authentication-		1. Before creating an ARC signature, perform any other, normal
	Results header field using the ADMD's authserv-id (see		authentication and/or signing, so that the ARC signature can
	Section 2.5 of [RFC7601]) indicating whatever authentication		cover those results.
	might have been done by the MTA, or possibly indicate that none
	was done.
	4. Build and attach the new ARC set:		2. Build and attach the new ARC set:
	1. If an ARC chain exists on the message, then set "N" equal to		1. If an ARC chain exists on the message, then set "N" equal to
	the highest instance number found on the chain (i=);		the highest instance number found on the chain (i=);
	otherwise set "N" equal to zero for the following steps.		otherwise set "N" equal to zero for the following steps.
	2. Generate and attach to the message an ARC-Authentication-		2. Generate and attach to the message an ARC-Authentication-
	Results header field using instance number N+1 and the same		Results header field using instance number N+1 and the same
	content from the previous step.		content from the previous step.
	3. Generate and attach to the message an ARC-Message-Signature		3. Generate and attach to the message an ARC-Message-Signature
	header field using the general algorithm described in		header field as defined in Section 5.2 above, using instance
	Section 5 of [RFC6376] and as modified in Section 5.1 above,		number N+1.
	using instance number N+1.
	4. Generate and attach to the message an ARC-Seal header field		4. Generate and attach to the message an ARC-Seal header field
	using the general algorithm described in Section 5.3 above,		using the general algorithm described in Section 5.3 above,
	the chain validation status as determined in Section 6, and		the chain validation status as determined in Section 6, and
	instance number N+1.		instance number N+1.
	8. Key Management		8. Key Management
	The public keys for ARC header fields follow the same requirements,		The public keys for ARC header fields follow the same requirements,
	syntax and semantics as those for DKIM signatures, described in		syntax and semantics as those for DKIM signatures, described in
	Section 3.6 of [RFC6376]. Operators may use distinct selectors and/		Section 3.6 of [RFC6376]. For operational convenience, signers MAY
	or domains for the ARC header fields at their own discretion.		choose to use selectors and/or domains for the ARC header field
			signatures that are distinct from those used in DKIM signing.
	9. Usage of ARC and Chain Validity		9. Usage of ARC and Chain Validity
	9.1. Relationship between DKIM-Signature and AMS signing scopes		9.1. Relationship between DKIM-Signature and AMS signing scopes
	DKIM-Signatures SHOULD never sign any ARC header fields.		DKIM-Signatures SHOULD never sign any ARC header fields.
			[[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers
			DKIM, which comes first? The chicken or the egg? I'm open to
			alternate ways to phrase this without opening the "modifying the DKIM
			spec" can of worms. ]]
	9.2. Assessing Chain Validity Violations		9.2. Assessing Chain Validity Violations
	There are a wide variety of ways in which the ARC set of header		Email transit can produce broken signatures for a wide variety of
	fields can be broken. Receivers need to be wary of ascribing motive		benign reasons. This includes possibly breaking one or more ARC
			signatures. Therefore, receivers need to be wary of ascribing motive
	to such breakage although patterns of common behaviour may provide		to such breakage although patterns of common behaviour may provide
	some basis for adjusting local policy decisions.		some basis for adjusting local policy decisions.
	This specification is exclusively focused on well-behaved,		ARC does not attempt to protect an entire message. There are various
	participating intermediaries that result in a valid chain of ARC-		ways that a message can still be problematic, in spite of having a
	related header fields. The value of such a well-formed, valid chain		valid ARC chain. Consequently, all normal, content-based analysis
	needs to be interpreted with care since malicious content can be		SHOULD still be performed on any message having a valid chain of ARC
	easily introduced by otherwise well-intended senders through machine
	or account compromises. All normal content-based analysis still
	needs to be performed on any messages bearing a valid chain of ARC
	header sets.		header sets.
	9.3. Marking and Sealing "cv=fail" (Invalid) Chains		9.3. Marking and Sealing "cv=fail" (Invalid) Chains
	The header fields signed by the AS header field b= value in the case		The header fields signed by the AS header field b= value in the case
	of a chain failure MUST be only the matching 'i=' instance headers		of a chain failure MUST be only the matching 'i=' instance headers
	created by the MTA which detected the malformed chain, as if this		created by the MTA which detected the malformed chain, as if this
	newest ARC set was the only set present.		newest ARC set was the only set present.
	9.4. Handling DNS Problems While Validating ARC		9.4. Handling DNS Problems While Validating ARC
	DNS failures to resolve or return data which is needed for ARC
	validation SHOULD result in a 421 tempfail during the SMTP
	conversation with the sending system. Temporary or intermittent DNS
	problems will generally not be sufficiently transitory to allow a
	mediator to obtain a different result during the ordinary transit
	duration so it is better to have the source system queue the
	problematic message(s) than to generate (potential) backscatter.
	Operators of systems which mediate mail should be aware that broken
	DNS records (or malfunctioning name servers) will result in
	undeliverable mail to any downstream ARC-verifying ADMDs.
	DNS-based failures to verify a chain are treated no differently than		DNS-based failures to verify a chain are treated no differently than
	any other ARC violation. They result in a "cv=fail" verdict.		any other ARC violation. They result in a "cv=fail" verdict.
	9.5. Responding to ARC Validity Violations		9.5. Responding to ARC Validity Violations
	If a receiver determines that the ARC chain has failed, the receiver		If a receiver determines that the ARC chain has failed, the receiver
	MAY signal the breakage through the extended SMTP response code 5.7.7		MAY signal the breakage through the extended SMTP response code 5.7.7
	[RFC3463] "message integrity failure" [ENHANCED-STATUS] and		[RFC3463] "message integrity failure" [ENHANCED-STATUS] and
	corresponding SMTP response code.		corresponding SMTP response code.
	9.6. Recording the Results of ARC Evaluation		10. Recording and Reporting the Results of ARC Evaluation
	Receivers MAY add an "arc=[pass|fail|policy]" method annotation into		The evaluation of an ARC chain provides information which will be
	a locally-affixed Authentication-Results [RFC7601] header field along		useful to both the receiver (or intermediary) and to the initial
	with any salient comment(s).		sender of the message. This information should be preserved and
			reported as follows.
	9.6.1. Output Information from an ARC Evaluation		10.1. Information from an ARC Evaluation
	The evaluation of a series of ARC sets results in the following data		The evaluation of an ARC chain produces a list of domain names for
	which MAY be used to inform local-policy decisions:		participating intermediaries which handled the message, to wit:
	o A list of the "d=" domains found in the validated ARC-Seal header		o A list of the "d=" domains found in the validated ARC-Seal header
	fields;		fields
	o The "d=" domain found in the most recent (highest instance number)		o The "d=" domain found in the most recent (highest instance number)
	AMS header field (since that is the only one necessarily		AMS header field (since that is the only one necessarily
	validated)		validated)
	In the case of a failed chain, only the terminal ARC set is covered		In the case of a failed chain, only the terminal ARC set is covered
	by the ARC-Seal so the reporting is limited to the findings in that		by the ARC-Seal so the reporting is limited to the findings in that
	terminal ARC set.		terminal ARC set.
	9.6.2. Reporting ARC Effects for DMARC Local Policy - Interim		10.2. Recording (local) ARC Evaluation Results
			Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
			a locally-affixed Authentication-Results [RFC7601] header field along
			with any salient comment(s).
			Details of the ARC chain which was evaluated should be included in
			the Authentication-Results and AAR headers per Section Section 5.1.1.
			10.3. DMARC Reporting of ARC Findings - Interim
	[[ Note: Discussion on the IETF DMARC-WG list has indicated some		[[ Note: Discussion on the IETF DMARC-WG list has indicated some
	interest in more substantial reporting for analytic purposes. To		interest in more substantial reporting for analytic purposes. To
	support that effort, the following guidance is provided only as an		support that effort, the following guidance is provided only as an
	interim, minimal data set. A more complete reporting construct will		interim, minimal data set. A more complete reporting construct will
	be specified in a related spec - TBD. (see the additional fields		be specified in a related spec - TBD. (see the additional fields
	specified in Section 5.1.1) ]]		specified in Section 5.1.1) ]]
	Receivers SHOULD indicate situations in which ARC evaluation		Receivers SHOULD indicate situations in which ARC evaluation
	influenced the results of their local policy determination. DMARC		influenced the results of their local policy determination. DMARC
	reporting of ARC-informed decisions is augmented by adding a		reporting of ARC-informed decisions can be accomplished by adding a
	local_policy comment explanation containing the list of data		local_policy comment explanation containing the list of data
	discovered in the ARC evaluation (Section 9.6.1 and Section 5.1.1):		discovered in the ARC evaluation (Section 10.1 and Section 5.1.1):
	<policy_evaluated>		<policy_evaluated>
	<disposition>delivered</disposition>		<disposition>delivered</disposition>
	<dkim>fail</dkim>		<dkim>fail</dkim>
	<spf>fail <comment>source.ip=10.0.0.1</comment></spf>		<spf>fail <comment>source.ip=10.0.0.1</comment></spf>
	<reason>		<reason>
	<type>local_policy</type>		<type>local_policy</type>
	<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example		<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
	as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>		as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>
	</reason>		</reason>
	skipping to change at page 14, line 40 ¶		skipping to change at page 15, line 5 ¶
	In the suggested sample, d2.example is the sealing domain for ARC[2]		In the suggested sample, d2.example is the sealing domain for ARC[2]
	and d1.example is the sealing domain for ARC[1].		and d1.example is the sealing domain for ARC[1].
	Mediators SHOULD generate DMARC reports on messages which transit		Mediators SHOULD generate DMARC reports on messages which transit
	their system just like any other message which they receive. This		their system just like any other message which they receive. This
	will result in multiple reports for each mediated message as they		will result in multiple reports for each mediated message as they
	transit the series of handlers. DMARC report consumers should be		transit the series of handlers. DMARC report consumers should be
	aware of this behaviour and make the necessary accommodations.		aware of this behaviour and make the necessary accommodations.
	10. Supporting Alternate Signing Algorithms		11. Supporting Alternate Signing Algorithms
	[[ Note: Some additional development of this section is needed. ]]		[[ Note: Some additional development of this section is needed. ]]
	In the following branch diagrams, each algorithm is represented by an		In the following branch diagrams, each algorithm is represented by an
	'A' or 'B' at each hop to depict the ARC chain that develops over a		'A' or 'B' at each hop to depict the ARC chain that develops over a
	five hop scenario. 'x' represents a hop that does not support that		five hop scenario. 'x' represents a hop that does not support that
	algorithm.		algorithm.
	Note that during a transitional period where multiple algorithms are		Note that during a transitional period where multiple algorithms are
	allowed, all of the statements in this spec which refer to "exactly		allowed, all of the statements in this spec which refer to "exactly
	one set of ARC headers per instance" need to be understood as "at		one set of ARC headers per instance" need to be understood as "at
	least one set per instance and no more than one instance-set per		least one set per instance and no more than one instance-set per
	algorithm".		algorithm".
	10.1. Introductory Period		11.1. Introductory Period
	Intermediaries MUST be able to validate ARC chains build with either		Intermediaries MUST be able to validate ARC chains built with either
	algorithm but MAY create ARC sets with either (or both) algorithm.		algorithm but MAY create ARC sets with either (or both) algorithm.
	The introductory period should be at least six (6) months.		The introductory period should be at least six (6) months.
	10.2. Co-Existence Period		11.2. Co-Existence Period
	Intermediaries MUST be able to validate ARC chains build with either		Intermediaries MUST be able to validate ARC chains build with either
	algorithm and MUST create ARC sets with both algorithms. Chains		algorithm and MUST create ARC sets with both algorithms. Chains
	ending with either algorithm may be used for the result.		ending with either algorithm may be used for the result.
	10.3. Deprecation Period		11.3. Deprecation Period
	ARC sets built with algorithms that are being deprecated MAY be		ARC sets built with algorithms that are being deprecated MAY be
	considered valid within an ARC chain, however, intermediaries MUST		considered valid within an ARC chain, however, intermediaries MUST
	NOT create additional sets with the deprecated algorithm.		NOT create additional sets with the deprecated algorithm.
	The deprecation period should be at least two (2) years.		The deprecation period should be at least two (2) years.
	10.4. Obsolescence Period		11.4. Obsolescence Period
	ARC sets built with algorithms that are obsolete MUST NOT be		ARC sets built with algorithms that are obsolete MUST NOT be
	considered valid within an ARC chain. Intermediaries MUST NOT create		considered valid within an ARC chain. Intermediaries MUST NOT create
	any sets with any obsoleted algorithm.		any sets with any obsoleted algorithm.
	11. Privacy Considerations		12. Privacy Considerations
	The ARC chain provides a verifiable record of the handlers for a		The ARC chain provides a verifiable record of the handlers for a
	message. Anonymous remailers will probably not find this to match		message. Anonymous remailers will probably not find this compatible
	their operating goals.		with their operating goals.
	12. IANA Considerations		13. IANA Considerations
	This specification adds three new header fields as defined below.		This specification adds three new header fields as defined below.
	12.1. Authentication-Results Method Registry Update		13.1. Authentication-Results Method Registry Update
	This draft adds one item to the IANA "Email Authentication Methods"		This draft adds one item to the IANA "Email Authentication Methods"
	registry:		registry:
	o Method : arc		o Method : arc
	Defined: [I-D.ARC]		Defined: [I-D.ARC]
	ptype: header		ptype: header
	Property: chain evaluation result		Property: chain evaluation result
	Value: chain evaluation result status (see Section 5.3)		Value: chain evaluation result status (see Section 5.3)
	Status: active		Status: active
	Version: 1		Version: 1
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 28 ¶
	ptype: header		ptype: header
	Property: chain evaluation result		Property: chain evaluation result
	Value: chain evaluation result status (see Section 5.3)		Value: chain evaluation result status (see Section 5.3)
	Status: active		Status: active
	Version: 1		Version: 1
	12.2. Definitions of the ARC header fields		13.2. Definitions of the ARC header fields
	This specification adds three new header fields to the "Permanent		This specification adds three new header fields to the "Permanent
	Message Header Field Registry", as follows:		Message Header Field Registry", as follows:
	o Header field name: ARC-Seal		o Header field name: ARC-Seal
	Applicable protocol: mail		Applicable protocol: mail
	Status: draft		Status: draft
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 17 ¶
	o Header field name: ARC-Authentication-Results		o Header field name: ARC-Authentication-Results
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/Change controller: IETF		Author/Change controller: IETF
	Specification document(s): [I-D.ARC]		Specification document(s): [I-D.ARC]
	Related information: [RFC7601]		Related information: [RFC7601]
	13. Implementation Status		14. Security Considerations
			The Security Considerations of [RFC6376] and [RFC7601] apply directly
			to this specification.
			Inclusion of ARC sets in the header 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 have to complete
			up to 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. The difficulty of forging the signature
			values should limit the extent of this load to domains under
			control of the attacker.
			2. DKIM only does one DNS check per signature, while this one can do
			many (per chain). Absent caching, slow DNS responses can cause
			SMTP timeouts; and backlogged delivery queues on mediating
			systems. This could be exploited as a DoS attack.
			14.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 chain may be used to provide input to local policy
			engines in cases where DMARC validation fails (due to mediation
			impacting SPF attribution, DKIM validity or alignment).
			15. Implementation Status
			[[ Note: For minimizing section number references when the RFC editor
			removes this section, it has been moved to be the last section of the
			document before the Appendicies. ]]
	[[ Note to the RFC Editor: Please remove this section before		[[ Note to the RFC Editor: Please remove this section before
	publication along with the reference to [RFC6982]. ]]		publication along with the reference to [RFC6982]. ]]
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC6982].		Internet-Draft, and is based on a proposal described in [RFC6982].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	skipping to change at page 17, line 28 ¶		skipping to change at page 18, line 34 ¶
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their		be construed to be, a catalog of available implementations or their
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	This information is known to be correct as of the seventh		This information is known to be correct as of the seventh
	interoperability test event which was held on 2017-07-15 & 16 at		interoperability test event which was held on 2017-07-15 & 16 at
	IETF99.		IETF99.
	13.1. GMail test reflector and incoming validation		15.1. GMail test reflector and incoming validation
	Organization: Google		Organization: Google
	Description: Internal production implementation with both debug		Description: Internal production implementation with both debug
	analysis and validating + sealing pass-through function		analysis and validating + sealing pass-through function
	Status of Operation: Production - Incoming Validation		Status of Operation: Production - Incoming Validation
	Coverage: Full spec implemented as of [ARC-DRAFT-06]		Coverage: Full spec implemented as of [ARC-DRAFT-06]
	Licensing: Proprietary - Internal only		Licensing: Proprietary - Internal only
	Implementation Notes:		Implementation Notes:
	o Full functionality was demonstrated during the interop testing on		o Full functionality was demonstrated during the interop testing on
	2017-07-15.		2017-07-15.
	Contact Info: arc-discuss@dmarc.org [1]		Contact Info: arc-discuss@dmarc.org [1]
	13.2. AOL test reflector and internal tagging		15.2. AOL test reflector and internal tagging
	Organization: AOL		Organization: AOL
	Description: Internal prototype implementation with both debug		Description: Internal prototype implementation with both debug
	analysis and validating + sealing pass-through function		analysis and validating + sealing pass-through function
	Status of Operation: Beta		Status of Operation: Beta
	Coverage: ARC chain validity status checking is operational, but only		Coverage: ARC chain validity status checking is operational, but only
	applied to email addresses enrolled in the test program. This system		applied to email addresses enrolled in the test program. This system
	skipping to change at page 18, line 27 ¶		skipping to change at page 19, line 29 ¶
	Licensing: Proprietary - Internal only		Licensing: Proprietary - Internal only
	Implementation Notes:		Implementation Notes:
	o 2017-07-15: Full functionality verified during the interop		o 2017-07-15: Full functionality verified during the interop
	testing.		testing.
	Contact Info: arc-discuss@dmarc.org [2]		Contact Info: arc-discuss@dmarc.org [2]
	13.3. dkimpy		15.3. dkimpy
	Organization: dkimpy developers/Scott Kitterman		Organization: dkimpy developers/Scott Kitterman
	Description: Python DKIM package		Description: Python DKIM package
	Status of Operation: Production		Status of Operation: Production
	Coverage:		Coverage:
	o 2017-07-15: The internal test suite is incomplete, but the command		o 2017-07-15: The internal test suite is incomplete, but the command
	line developmental version of validator was demonstrated to		line developmental version of validator was demonstrated to
	interoperate with the Google and AOL implementations during the		interoperate with the Google and AOL implementations during the
	interop on 2017-07-15 and the released version passes the tests in		interop on 2017-07-15 and the released version passes the tests in
	[ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both		[ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
	python and python3.		python and python3.
	Licensing: Open/Other (same as dkimpy package = BCD version 2)		Licensing: Open/Other (same as dkimpy package = BCD version 2)
	Contact Info: https://launchpad.net/dkimpy		Contact Info: https://launchpad.net/dkimpy
	13.4. OpenARC		15.4. OpenARC
	Organization: TDP/Murray Kucherawy		Organization: TDP/Murray Kucherawy
	Description: Implemention of milter functionality related to the		Description: Implemention of milter functionality related to the
	OpenDKIM and OpenDMARC packages		OpenDKIM and OpenDMARC packages
	Status of Operation: Beta		Status of Operation: Beta
	Coverage: Built to support [ARC-DRAFT-06]		Coverage: Built to support [ARC-DRAFT-06]
	Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)		Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
	Implementation Notes:		Implementation Notes:
	skipping to change at page 19, line 32 ¶		skipping to change at page 20, line 37 ¶
	o Some issues still exist when deploying in a chained milter		o Some issues still exist when deploying in a chained milter
	arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)		arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
	with coordination between the stages. When deployed in a		with coordination between the stages. When deployed in a
	"sandwich" configuration around an MLM, there is no effective		"sandwich" configuration around an MLM, there is no effective
	mechanism to convey trust from the ingress (validator) to egress		mechanism to convey trust from the ingress (validator) to egress
	(signer) instances.		(signer) instances.
	Contact Info: arc-discuss@dmarc.org [3]		Contact Info: arc-discuss@dmarc.org [3]
	13.5. Mailman 3.1+ patch		15.5. Mailman 3.1+ patch
	Organization: Mailman development team		Organization: Mailman development team
	Description: Integrated ARC capabilities within the Mailman 3.1+		Description: Integrated ARC capabilities within the Mailman 3.1+
	package		package
	Status of Operation: Patch submitted		Status of Operation: Patch submitted
	Coverage: Unknown		Coverage: Unknown
	Licensing: Same as mailman package - GPL		Licensing: Same as mailman package - GPL
	Implementation Notes:		Implementation Notes:
	o Appears to work properly in at least one beta deployment, but		o Appears to work properly in at least one beta deployment, but
	waiting on acceptance of the pull request into the mainline of		waiting on acceptance of the pull request into the mainline of
	mailman development		mailman development
	Contact Info: https://www.gnu.org/software/mailman/contact.html		Contact Info: https://www.gnu.org/software/mailman/contact.html
	13.6. Copernica/MailerQ web-based validation		15.6. Copernica/MailerQ web-based validation
	Organization: Copernica		Organization: Copernica
	Description: Web-based validation of ARC-signed messages		Description: Web-based validation of ARC-signed messages
	Status of Operation: Beta		Status of Operation: Beta
	Coverage: Built to support [ARC-DRAFT-05]		Coverage: Built to support [ARC-DRAFT-05]
	Licensing: On-line usage only		Licensing: On-line usage only
	skipping to change at page 20, line 32 ¶		skipping to change at page 21, line 38 ¶
	at http://arc.mailerq.com/ (warning - https is not supported).		at http://arc.mailerq.com/ (warning - https is not supported).
	o An additional instance of an ARC signature can be added if one is		o An additional instance of an ARC signature can be added if one is
	willing to paste a private key into an unsecured web form.		willing to paste a private key into an unsecured web form.
	o 2017-07-15: Testing shows that results match the other		o 2017-07-15: Testing shows that results match the other
	implementations listed in this section.		implementations listed in this section.
	Contact Info: https://www.copernica.com/		Contact Info: https://www.copernica.com/
	13.7. Rspamd		15.7. Rspamd
	Organization: Rspamd community		Organization: Rspamd community
	Description: ARC signing and verification module		Description: ARC signing and verification module
	Status of Operation: Production, though deployment usage is unknown		Status of Operation: Production, though deployment usage is unknown
	Coverage: Built to support [ARC-DRAFT-06]		Coverage: Built to support [ARC-DRAFT-06]
	Licensing: Open source		Licensing: Open source
	skipping to change at page 20, line 47 ¶		skipping to change at page 22, line 4 ¶
	Status of Operation: Production, though deployment usage is unknown		Status of Operation: Production, though deployment usage is unknown
	Coverage: Built to support [ARC-DRAFT-06]		Coverage: Built to support [ARC-DRAFT-06]
	Licensing: Open source		Licensing: Open source
	Implementation Notes:		Implementation Notes:
	o 2017-06-12: Released with version 1.6.0		o 2017-06-12: Released with version 1.6.0
	o 2017-07-15: Testing during the interop showed that the validation		o 2017-07-15: Testing during the interop showed that the validation
	functionality interoperated with the Google, AOL, dkimpy and		functionality interoperated with the Google, AOL, dkimpy and
	MailerQ implementations		MailerQ implementations
	Contact Info: https://rspamd.com/doc/modules/arc.html and		Contact Info: https://rspamd.com/doc/modules/arc.html and
	https://github.com/vstakhov/rspamd		https://github.com/vstakhov/rspamd
	13.8. PERL Mail::Milter::Authentication module		15.8. PERL Mail::Milter::Authentication module
	Organization: FastMail		Organization: FastMail
	Description: Email domain authentication milter, previously included		Description: Email domain authentication milter, previously included
	SPF / DKIM / DMARC, now has ARC added		SPF / DKIM / DMARC, now has ARC added
	Status of Operation: Intial validation completed during IETF99		Status of Operation: Intial validation completed during IETF99
	hackathon with some follow-on work during the week		hackathon with some follow-on work during the week
	Coverage: Built to support [I-D.ARC]		Coverage: Built to support [I-D.ARC]
	skipping to change at page 21, line 33 ¶		skipping to change at page 22, line 36 ¶
	o 2017-07-15: Validation functionality which interoperates with		o 2017-07-15: Validation functionality which interoperates with
	Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,		Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
	the signing functionality was reported to be working		the signing functionality was reported to be working
	o 2017-07-20: ARC functionality has not yet been pushed back to the		o 2017-07-20: ARC functionality has not yet been pushed back to the
	github repo but should be showing up soon		github repo but should be showing up soon
	Contact Info: https://github.com/fastmail/authentication_milter		Contact Info: https://github.com/fastmail/authentication_milter
	14. Security Considerations		16. References
	The Security Considerations of [RFC6376] and [RFC7601] apply directly
	to this specification.
	Inclusion of ARC sets in the header 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 have to complete
	up to 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. The difficulty of forging the signature
	values should limit the extent of this load to domains under
	control of the attacker.
	2. DKIM only does one DNS check per signature, while this one can do
	many (per chain). Absent caching, slow DNS responses can cause
	SMTP timeouts; and backlogged delivery queues on mediating
	systems. This could be exploited as a DoS attack.
	14.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 chain may be used to provide input to local policy
	engines in cases where DMARC validation fails (due to mediation
	impacting SPF attribution, DKIM validity or alignment).
	15. References
	15.1. Normative References		16.1. Normative References
	[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",		[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
	RFC 1345, DOI 10.17487/RFC1345, June 1992,		RFC 1345, DOI 10.17487/RFC1345, June 1992,
	<http://www.rfc-editor.org/info/rfc1345>.		<https://www.rfc-editor.org/info/rfc1345>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and		[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
	Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,		Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
	<http://www.rfc-editor.org/info/rfc2142>.		<https://www.rfc-editor.org/info/rfc2142>.
	[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS		[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
	Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,		Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
	<http://www.rfc-editor.org/info/rfc2606>.		<https://www.rfc-editor.org/info/rfc2606>.
	[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",		[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
	RFC 3463, DOI 10.17487/RFC3463, January 2003,		RFC 3463, DOI 10.17487/RFC3463, January 2003,
	<http://www.rfc-editor.org/info/rfc3463>.		<https://www.rfc-editor.org/info/rfc3463>.
	[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys		[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
	Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,		Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
	September 2006, <http://www.rfc-editor.org/info/rfc4686>.		September 2006, <https://www.rfc-editor.org/info/rfc4686>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,		IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<https://www.rfc-editor.org/info/rfc5226>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<https://www.rfc-editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<http://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys		[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
	Identified Mail (DKIM) Service Overview", RFC 5585,		Identified Mail (DKIM) Service Overview", RFC 5585,
	DOI 10.17487/RFC5585, July 2009,		DOI 10.17487/RFC5585, July 2009,
	<http://www.rfc-editor.org/info/rfc5585>.		<https://www.rfc-editor.org/info/rfc5585>.
	[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,		[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
	DOI 10.17487/RFC5598, July 2009,		DOI 10.17487/RFC5598, July 2009,
	<http://www.rfc-editor.org/info/rfc5598>.		<https://www.rfc-editor.org/info/rfc5598>.
	[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,		[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
	"DomainKeys Identified Mail (DKIM) Development,		"DomainKeys Identified Mail (DKIM) Development,
	Deployment, and Operations", RFC 5863,		Deployment, and Operations", RFC 5863,
	DOI 10.17487/RFC5863, May 2010,		DOI 10.17487/RFC5863, May 2010,
	<http://www.rfc-editor.org/info/rfc5863>.		<https://www.rfc-editor.org/info/rfc5863>.
	[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,		[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", STD 76,		"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
	RFC 6376, DOI 10.17487/RFC6376, September 2011,		RFC 6376, DOI 10.17487/RFC6376, September 2011,
	<http://www.rfc-editor.org/info/rfc6376>.		<https://www.rfc-editor.org/info/rfc6376>.
	[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and		[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
	Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,		Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
	September 2011, <http://www.rfc-editor.org/info/rfc6377>.		September 2011, <https://www.rfc-editor.org/info/rfc6377>.
	[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail		[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
	(DKIM) for Failure Reporting", RFC 6651,		(DKIM) for Failure Reporting", RFC 6651,
	DOI 10.17487/RFC6651, June 2012,		DOI 10.17487/RFC6651, June 2012,
	<http://www.rfc-editor.org/info/rfc6651>.		<https://www.rfc-editor.org/info/rfc6651>.
	[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for		[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
	Authorizing Use of Domains in Email, Version 1", RFC 7208,		Authorizing Use of Domains in Email, Version 1", RFC 7208,
	DOI 10.17487/RFC7208, April 2014,		DOI 10.17487/RFC7208, April 2014,
	<http://www.rfc-editor.org/info/rfc7208>.		<https://www.rfc-editor.org/info/rfc7208>.
	[RFC7601] Kucherawy, M., "Message Header Field for Indicating		[RFC7601] Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status", RFC 7601,		Message Authentication Status", RFC 7601,
	DOI 10.17487/RFC7601, August 2015,		DOI 10.17487/RFC7601, August 2015,
	<http://www.rfc-editor.org/info/rfc7601>.		<https://www.rfc-editor.org/info/rfc7601>.
	15.2. Informative References		16.2. Informative References
	[ARC-DRAFT-05]		[ARC-DRAFT-05]
	Andersen, K., Long, B., and S. Jones, "Authenticated		Andersen, K., Long, B., and S. Jones, "Authenticated
	Received Chain (ARC) Protocol (I-D-06)", n.d.,		Received Chain (ARC) Protocol (I-D-06)", n.d.,
	<https://tools.ietf.org/html/draft-ietf-dmarc-arc-		<https://tools.ietf.org/html/
	protocol-06>.		draft-ietf-dmarc-arc-protocol-06>.
	[ARC-DRAFT-06]		[ARC-DRAFT-06]
	Andersen, K., Long, B., and S. Jones, "Authenticated		Andersen, K., Long, B., and S. Jones, "Authenticated
	Received Chain (ARC) Protocol (I-D-05)", n.d.,		Received Chain (ARC) Protocol (I-D-05)", n.d.,
	<https://tools.ietf.org/html/draft-ietf-dmarc-arc-		<https://tools.ietf.org/html/
	protocol-05>.		draft-ietf-dmarc-arc-protocol-05>.
	[ARC-TEST]		[ARC-TEST]
	Blank, S., "ARC Test Suite", January 2017,		Blank, S., "ARC Test Suite", January 2017,
	<https://github.com/ValiMail/arc_test_suite>.		<https://github.com/ValiMail/arc_test_suite>.
	[ARC-USAGE]		[ARC-USAGE]
	Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,		Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
	"Recommended Usage of the ARC Headers", December 2017,		"Recommended Usage of the ARC Headers", December 2017,
	<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-		<https://tools.ietf.org/html/
	01>.		draft-ietf-dmarc-arc-usage-01>.
	[ENHANCED-STATUS]		[ENHANCED-STATUS]
	"IANA SMTP Enhanced Status Codes", n.d.,		"IANA SMTP Enhanced Status Codes", n.d.,
	<http://www.iana.org/assignments/smtp-enhanced-status-		<http://www.iana.org/assignments/smtp-enhanced-status-
	codes/smtp-enhanced-status-codes.xhtml>.		codes/smtp-enhanced-status-codes.xhtml>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982,		Code: The Implementation Status Section", RFC 6982,
	DOI 10.17487/RFC6982, July 2013,		DOI 10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.		<https://www.rfc-editor.org/info/rfc6982>.
	[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based		[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
	Message Authentication, Reporting, and Conformance		Message Authentication, Reporting, and Conformance
	(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,		(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
	<http://www.rfc-editor.org/info/rfc7489>.		<https://www.rfc-editor.org/info/rfc7489>.
	[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,		[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
	E., Ed., and K. Andersen, Ed., "Interoperability Issues		E., Ed., and K. Andersen, Ed., "Interoperability Issues
	between Domain-based Message Authentication, Reporting,		between Domain-based Message Authentication, Reporting,
	and Conformance (DMARC) and Indirect Email Flows",		and Conformance (DMARC) and Indirect Email Flows",
	RFC 7960, DOI 10.17487/RFC7960, September 2016,		RFC 7960, DOI 10.17487/RFC7960, September 2016,
	<http://www.rfc-editor.org/info/rfc7960>.		<https://www.rfc-editor.org/info/rfc7960>.
	15.3. URIs		16.3. URIs
	[1] mailto:arc-discuss@dmarc.org		[1] mailto:arc-discuss@dmarc.org
	[2] mailto:arc-discuss@dmarc.org		[2] mailto:arc-discuss@dmarc.org
	[3] mailto:arc-discuss@dmarc.org		[3] mailto:arc-discuss@dmarc.org
	[4] mailto:dmarc@ietf.org		[4] mailto:dmarc@ietf.org
	[5] mailto:arc-discuss@dmarc.org		[5] mailto:arc-discuss@dmarc.org
	Appendix A. Appendix A - Example Usage (Obsolete but retained for		Appendix A. Appendix A - Design Requirements
	illustrative purposes)
			(This section is re-inserted for background information from
			[ARC-DRAFT-06] and earlier versions.)
			The specification of the ARC framework is driven by the following
			high-level goals, security considerations, and practical operational
			requirements.
			A.1. Primary Design Criteria
			o Provide a verifiable "chain of custody" for email messages;
			o Not require changes for originators of email;
			o Support the verification of the ARC header field set by each hop
			in the handling chain;
			o Work at Internet scale; and
			o Provide a trustable mechanism for the communication of
			Authentication-Results across trust boundaries.
			A.2. Out of Scope
			ARC is not a trust framework. Users of the ARC header fields are
			cautioned against making unsubstantiated conclusions when
			encountering a "broken" ARC sequence.
			Appendix B. Appendix B - Example Usage
	[[ Note: The following examples were mocked up early in the		[[ Note: The following examples were mocked up early in the
	definition process for the spec. They no longer reflect the current		definition process for the spec. They no longer reflect the current
	definition and need various updates which will be included in the		definition and need various updates which will be included in a
	next draft. ]]		future draft. ]]
	A.1. Example 1: Simple mailing list		(Obsolete but retained for illustrative purposes)
	A.1.1. Here's the message as it exits the Origin:		B.1. Example 1: Simple mailing list
			B.1.1. Here's the message as it exits the Origin:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])		Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
	(authenticated bits=0)		(authenticated bits=0)
	by segv.d1.example with ESMTP id t0FN4a8O084569;		by segv.d1.example with ESMTP id t0FN4a8O084569;
	Thu, 14 Jan 2015 15:00:01 -0800 (PST)		Thu, 14 Jan 2015 15:00:01 -0800 (PST)
	(envelope-from jqd@d1.example)		(envelope-from jqd@d1.example)
	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;		DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
	s=20130426; t=1421363082;		s=20130426; t=1421363082;
	bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;		bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
	skipping to change at page 26, line 29 ¶		skipping to change at page 27, line 29 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@dmarc.org		To: arc@dmarc.org
	Subject: Example 1		Subject: Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.1.2. Message is then received at example.org		B.1.2. Message is then received at example.org
	A.1.2.1. Example 1, Step A: Message forwarded to list members		B.1.2.1. Example 1, Step A: Message forwarded to list members
	Processing at example.org:		Processing at example.org:
	o example.org performs authentication checks		o example.org performs authentication checks
	o No previous Auth-Results or ARC-Seal headers are present		o No previous Authentication-Results or ARC-Seal headers are present
	o example.org adds ARC-Auth-Results header		o example.org adds ARC-Authentication-Results header
	o example.org adds Received: header		o example.org adds Received: header
	o example.org adds a ARC-Seal header		o example.org adds a ARC-Seal header
	Here's the message as it exits example.org:		Here's the message as it exits example.org:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	ARC-Seal: i=1; a=rsa-sha256; t=1421363107;		ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
	s=seal2015; d=example.org; cv=none;		s=seal2015; d=example.org; cv=none;
	skipping to change at page 28, line 5 ¶		skipping to change at page 29, line 5 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.1.3. Example 1: Message received by Recipient		B.1.3. Example 1: Message received by Recipient
	Let's say that the Recipient is example.com		Let's say that the Recipient is example.com
	Processing at example.com:		Processing at example.com:
	o example.com performs usual authentication checks		o example.com performs usual authentication checks
	o example.com adds Auth-Results: header, Received header		o example.com adds Authentication-Results: header, Received header
	o Determines that message fails DMARC		o Determines that message fails DMARC
	o Checks for ARC-Seal: header; finds one		o Checks for ARC-Seal: header; finds one
	o Validates the signature in the ARC-Seal: header, which covers the		o Validates the signature in the ARC-Seal: header, which covers the
	ARC-Authentication-Results: header		ARC-Authentication-Results: header
	o example.com can use the ARC-Authentication-Results values or		o example.com can use the ARC-Authentication-Results values or
	verify the DKIM-Signature from lists.example.org		verify the DKIM-Signature from lists.example.org
	skipping to change at page 29, line 30 ¶		skipping to change at page 30, line 30 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.2. Example 2: Mailing list to forwarded mailbox		B.2. Example 2: Mailing list to forwarded mailbox
	A.2.1. Here's the message as it exits the Origin:		B.2.1. Here's the message as it exits the Origin:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])		Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
	(authenticated bits=0)		(authenticated bits=0)
	by segv.d1.example with ESMTP id t0FN4a8O084569;		by segv.d1.example with ESMTP id t0FN4a8O084569;
	Thu, 14 Jan 2015 15:00:01 -0800 (PST)		Thu, 14 Jan 2015 15:00:01 -0800 (PST)
	(envelope-from jqd@d1.example)		(envelope-from jqd@d1.example)
	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;		DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
	s=20130426; t=1421363082;		s=20130426; t=1421363082;
	bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;		bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
	skipping to change at page 30, line 29 ¶		skipping to change at page 31, line 29 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: Example 1		Subject: Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.2.2. Message is then received at example.org		B.2.2. Message is then received at example.org
	A.2.2.1. Example 2, Step A: Message forwarded to list members		B.2.2.1. Example 2, Step A: Message forwarded to list members
	Processing at example.org:		Processing at example.org:
	o example.org performs authentication checks		o example.org performs authentication checks
	o example.org applies standard DKIM signature		o example.org applies standard DKIM signature
	o No previous Auth-Results or ARC-Seal headers are present		o No previous Authentication-Results or ARC-Seal headers are present
	o example.org adds ARC-Auth-Results header		o example.org adds ARC-Authentication-Results header
	o example.org adds usual Received: header		o example.org adds usual Received: header
	o example.org adds a ARC-Seal header		o example.org adds a ARC-Seal header
	Here's the message as it exits Step A:		Here's the message as it exits Step A:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	ARC-Seal: i=1; a=rsa-sha256; t=1421363107;		ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
	s=seal2015; d=example.org; cv=none;		s=seal2015; d=example.org; cv=none;
	skipping to change at page 32, line 5 ¶		skipping to change at page 33, line 5 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.2.2.2. Example 2, Step B: Message from list forwarded		B.2.2.2. Example 2, Step B: Message from list forwarded
	The message is delivered to a mailbox at gmail.com		The message is delivered to a mailbox at gmail.com
	Processing at gmail.com:		Processing at gmail.com:
	o gmail.com performs usual authentication checks		o gmail.com performs usual authentication checks
	o gmail.com adds Auth-Results: and Received: header		o gmail.com adds Authentication-Results: and Received: header
	o Determines that message fails DMARC		o Determines that message fails DMARC
	o Checks for ARC-Seal: header; finds one		o Checks for ARC-Seal: header; finds one
	o Validates the signature in the ARC-Seal: header, which covers the		o Validates the signature in the ARC-Seal: header, which covers the
	ARC-Authentication-Results: header		ARC-Authentication-Results: header
	o Uses the ARC-Auth-Results: values, but:		o Uses the ARC-Authentication-Results: values, but:
	o Instead of delivering message, prepares to forward message per		o Instead of delivering message, prepares to forward message per
	user settings		user settings
	o Applies usual DKIM signature		o Applies usual DKIM signature
	o gmail.com adds it's own ARC-Seal: header, contents of which are		o gmail.com adds it's own ARC-Seal: header, contents of which are
	* version		* version
	skipping to change at page 34, line 23 ¶		skipping to change at page 35, line 23 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.2.3. Example 2: Message received by Recipient		B.2.3. Example 2: Message received by Recipient
	Let's say that the Recipient is example.com		Let's say that the Recipient is example.com
	Processing at example.com:		Processing at example.com:
	o example.com performs usual authentication checks		o example.com performs usual authentication checks
	o example.com adds Auth-Results: header, Received header		o example.com adds Authentication-Results: header, Received header
	o Determines that message fails DMARC		o Determines that message fails DMARC
	o Checks for ARC-Seal: header; finds two		o Checks for ARC-Seal: header; finds two
	o Validates the signature in the highest numbered ("i=2") ARC-Seal:		o Validates the signature in the highest numbered ("i=2") ARC-Seal:
	header, which covers all previous ARC-Seal: and ARC-		header, which covers all previous ARC-Seal: and ARC-
	Authentication-Results: headers		Authentication-Results: headers
	o Validates the other ARC-Seal header ("i=1"), which covers the ARC-		o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
	skipping to change at page 36, line 26 ¶		skipping to change at page 37, line 26 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.3. Example 3: Mailing list to forwarded mailbox with source		B.3. Example 3: Mailing list to forwarded mailbox with source
	A.3.1. Here's the message as it exits the Origin:		B.3.1. Here's the message as it exits the Origin:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])		Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
	(authenticated bits=0)		(authenticated bits=0)
	by segv.d1.example with ESMTP id t0FN4a8O084569;		by segv.d1.example with ESMTP id t0FN4a8O084569;
	Thu, 14 Jan 2015 15:00:01 -0800 (PST)		Thu, 14 Jan 2015 15:00:01 -0800 (PST)
	(envelope-from jqd@d1.example)		(envelope-from jqd@d1.example)
	ARC-Seal: i=1; a=rsa-sha256; t=1421363107;		ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
	s=origin2015; d=d1.example; cv=none;		s=origin2015; d=d1.example; cv=none;
	b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T		b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
	skipping to change at page 37, line 33 ¶		skipping to change at page 38, line 33 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: Example 1		Subject: Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.3.2. Message is then received at example.org		B.3.2. Message is then received at example.org
	A.3.2.1. Example 3, Step A: Message forwarded to list members with		B.3.2.1. Example 3, Step A: Message forwarded to list members with
	source		source
	Processing at example.org:		Processing at example.org:
	o example.org performs authentication checks		o example.org performs authentication checks
	o example.org applies standard DKIM signature		o example.org applies standard DKIM signature
	o Checks for ARC-Seal: header; finds one (i=1)		o Checks for ARC-Seal: header; finds one (i=1)
	o Validates the signature in the ARC-Seal (i=1): header, which		o Validates the signature in the ARC-Seal (i=1): header, which
	covers the d1.example ARC-Message-Signature: header		covers the d1.example ARC-Message-Signature: header
	o example.org adds ARC-Auth-Results header		o example.org adds ARC-Authentication-Results header
	o example.org adds usual Received: header		o example.org adds usual Received: header
	o example.org adds a DKIM-Signature		o example.org adds a DKIM-Signature
	o example.org adds a ARC-Seal header, contents of which are		o example.org adds a ARC-Seal header, contents of which are
	* sequence number ("i=2")		* sequence number ("i=2")
	* hash algorithm (SHA256 as example)		* hash algorithm (SHA256 as example)
	skipping to change at page 40, line 5 ¶		skipping to change at page 41, line 5 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.3.2.2. Example 3, Step B: Message from list forwarded with source		B.3.2.2. Example 3, Step B: Message from list forwarded with source
	The message is delivered to a mailbox at gmail.com		The message is delivered to a mailbox at gmail.com
	Processing at gmail.com:		Processing at gmail.com:
	o gmail.com performs usual authentication checks		o gmail.com performs usual authentication checks
	o gmail.com adds Auth-Results: and Received: header		o gmail.com adds Authentication-Results: and Received: header
	o Determines that message fails DMARC		o Determines that message fails DMARC
	o Checks for ARC-Seal: header; finds two		o Checks for ARC-Seal: header; finds two
	o Validates the signature in the ARC-Seal (i=2): header, which		o Validates the signature in the ARC-Seal (i=2): header, which
	covers the ARC-Authentication-Results: header		covers the ARC-Authentication-Results: header
	o Validates the signature in the ARC-Seal (i=1): header, which		o Validates the signature in the ARC-Seal (i=1): header, which
	covers the d1.example ARC-Message-Signature: header		covers the d1.example ARC-Message-Signature: header
	o Uses the ARC-Auth-Results: values, but:		o Uses the ARC-Authentication-Results: values, but:
	o Instead of delivering message, prepares to forward message per		o Instead of delivering message, prepares to forward message per
	user settings		user settings
	o Applies usual DKIM signature		o Applies usual DKIM signature
	o gmail.com adds it's own ARC-Seal: header, contents of which are		o gmail.com adds it's own ARC-Seal: header, contents of which are
	* version		* version
	skipping to change at page 42, line 27 ¶		skipping to change at page 43, line 27 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	A.3.3. Example 3: Message received by Recipient		B.3.3. Example 3: Message received by Recipient
	Let's say that the Recipient is example.com		Let's say that the Recipient is example.com
	Processing at example.com:		Processing at example.com:
	o example.com performs usual authentication checks		o example.com performs usual authentication checks
	o example.com adds Auth-Results: header, Received header		o example.com adds Authentication-Results: header, Received header
	o Determines that message fails DMARC		o Determines that message fails DMARC
	o Checks for ARC-Seal: header; finds three		o Checks for ARC-Seal: header; finds three
	o Validates the signature in the highest numbered ("i=2") ARC-Seal:		o Validates the signature in the highest numbered ("i=2") ARC-Seal:
	header, which covers all previous ARC-Seal: and ARC-		header, which covers all previous ARC-Seal: and ARC-
	Authentication-Results: headers		Authentication-Results: headers
	o Validates the other ARC-Seal header ("i=2"), which covers the ARC-		o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
	skipping to change at page 44, line 37 ¶		skipping to change at page 45, line 37 ¶
	Message-ID: <54B84785.1060301@d1.example>		Message-ID: <54B84785.1060301@d1.example>
	Date: Thu, 14 Jan 2015 15:00:01 -0800		Date: Thu, 14 Jan 2015 15:00:01 -0800
	From: John Q Doe <jqd@d1.example>		From: John Q Doe <jqd@d1.example>
	To: arc@example.org		To: arc@example.org
	Subject: [Lists] Example 1		Subject: [Lists] Example 1
	Hey gang,		Hey gang,
	This is a test message.		This is a test message.
	--J.		--J.
	Appendix B. Acknowledgements		Appendix C. Acknowledgements
	This draft is the work of OAR-Dev Group.		This draft is the work of OAR-Dev Group.
	The authors thank all of the OAR-Dev group for the ongoing help and		The authors thank all of the OAR-Dev group for the ongoing help and
	though-provoking discussions from all the participants, especially:		though-provoking discussions from all the participants, especially:
	Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck		Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
	Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,		Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
	Mike Jones, Steve Jones, Terry Zink, Tim Draegen.		Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
	Grateful appreciation is extended to the people who provided feedback		Grateful appreciation is extended to the people who provided feedback
	through the discuss mailing list.		through the discuss mailing list.
	Appendix C. Comments and Feedback		Appendix D. Comments and Feedback
	Please address all comments, discussions, and questions to		Please address all comments, discussions, and questions to
	dmarc@ietf.org [4]. Earlier discussions can be found at arc-		dmarc@ietf.org [4]. Earlier discussions can be found at arc-
	discuss@dmarc.org [5].		discuss@dmarc.org [5].
	Authors' Addresses		Authors' Addresses
	Kurt Andersen		Kurt Andersen
	LinkedIn		LinkedIn
	1000 West Maude Ave		1000 West Maude Ave
End of changes. 164 change blocks.
	386 lines changed or deleted		444 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/