draft-ietf-dmarc-arc-protocol-10.txt		draft-ietf-dmarc-arc-protocol-11.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: Experimental B. Long, Ed.
	Expires: June 22, 2018 Google		Expires: July 26, 2018 Google
	S. Jones, Ed.		S. Jones, Ed.
	TDP		TDP
	S. Blank, Ed.		S. Blank, Ed.
	ValiMail		ValiMail
	December 19, 2017		M. Kucherawy, Ed.
			TDP
			January 22, 2018
	Authenticated Received Chain (ARC) Protocol		Authenticated Received Chain (ARC) Protocol
	draft-ietf-dmarc-arc-protocol-10		draft-ietf-dmarc-arc-protocol-11
	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 an email message can conduct		whereby a series of handlers of an email message can conduct
	authentication of the email message as it passes among them on the		authentication of the email message as it passes among them on the
	way to its destination, and record the status of that authentication		way to its destination, and record the status of that authentication
	at each step along the handling path, for use by the final recipient		at each step along the handling path, for use by the final recipient
	in making choices about the disposition of the message. Changes in		in making choices about the disposition of the message. Changes in
	the message that might break DKIM or DMARC can be identified through		the message that might break DKIM or DMARC can be identified through
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 44 ¶
	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 https://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 June 22, 2018.		This Internet-Draft will expire on July 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6		3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
	3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6		3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
	4. Protocol Elements and Features . . . . . . . . . . . . . . . 7		4. Protocol Elements and Features . . . . . . . . . . . . . . . 7
	4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 7		4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8
	4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 7		4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 8
	4.1.2. Optional Participation . . . . . . . . . . . . . . . 8		4.1.2. Optional Participation . . . . . . . . . . . . . . . 8
	4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 8		4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9
	4.1.4. All Failures are Permanent . . . . . . . . . . . . . 8		4.1.4. All Failures are Permanent . . . . . . . . . . . . . 9
	4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9		4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9
	4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9		4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9
	4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 9		4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 10
	5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9		4.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 10
	5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 9		4.1.9. Chain Validation Status . . . . . . . . . . . . . . . 10
			5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 10
			5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 10
	5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10		5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10
	5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 10		5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 11
	5.2.1. ptypes and properties for arc-info . . . . . . . . . 11		5.2.1. ptypes and properties for arc-info . . . . . . . . . 11
	5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 11		5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
	5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12		5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12
	5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 12		5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13
	5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13		5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13
	6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 13		6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
	7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 15		6.1. Handling DNS Problems While Validating ARC . . . . . . . 15
			6.2. Responding to ARC Validity Violations During the SMTP
			Transaction . . . . . . . . . . . . . . . . . . . . . . . 15
			7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
			7.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
	8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16		8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16
	8.1. Relationship between DKIM-Signature and AMS signing		8.1. Relationship between DKIM-Signature and AMS signing
	scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16		scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Assessing Chain Validity Violations . . . . . . . . . . . 16		8.2. Assessing Chain Validity Violations . . . . . . . . . . . 17
	8.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
	8.4. Handling DNS Problems While Validating ARC . . . . . . . 16
	8.5. Responding to ARC Validity Violations . . . . . . . . . . 16
	9. Recording and Reporting the Results of ARC Evaluation . . . . 17		9. Recording and Reporting the Results of ARC Evaluation . . . . 17
	9.1. Information from an ARC Evaluation . . . . . . . . . . . 17		9.1. Information from an ARC Evaluation . . . . . . . . . . . 17
	9.2. Recording (local) ARC Evaluation Results . . . . . . . . 17		9.2. Recording (local) ARC Evaluation Results . . . . . . . . 18
	9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 17		9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
	10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 18		10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
	10.1. Introductory Period . . . . . . . . . . . . . . . . . . 18
	10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 18
	10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 19
	10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 19
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19		11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	12.1. Authentication-Results Method Registry Update . . . . . 19		12.1. Authentication-Results Method Registry Update . . . . . 19
	12.2. Definitions of the ARC header fields . . . . . . . . . . 19		12.2. Definitions of the ARC header fields . . . . . . . . . . 20
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 20		13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 20		13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 21
	13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21		13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
	13.3. Message Content Suspicion . . . . . . . . . . . . . . . 21		13.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
	14. Implementation Status . . . . . . . . . . . . . . . . . . . . 21		14. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 22
	14.1. GMail test reflector and incoming validation . . . . . . 22		14.1. Success Consideration . . . . . . . . . . . . . . . . . 23
	14.2. AOL test reflector and internal tagging . . . . . . . . 22		14.2. Failure Considerations . . . . . . . . . . . . . . . . . 23
	14.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 23		14.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23
	14.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 23		14.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 23
	14.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 24		14.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 23
	14.6. Copernica/MailerQ web-based validation . . . . . . . . . 24		14.3.3. Distinguishing Valuable from Worthless Trace
	14.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 25		Information . . . . . . . . . . . . . . . . . . . . 24
	14.8. PERL Mail::Milter::Authentication module . . . . . . . . 25		15. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		15.1. GMail test reflector and incoming validation . . . . . . 25
	15.1. Normative References . . . . . . . . . . . . . . . . . . 26		15.2. AOL test reflector and internal tagging . . . . . . . . 25
	15.2. Informative References . . . . . . . . . . . . . . . . . 27		15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
	15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29		15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26
	Appendix A. Appendix A - Design Requirements . . . . . . . . . . 29		15.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
	A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 29		15.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
	A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 29		15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
	Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 29		15.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28
	B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 30		15.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
	B.1.1. Here's the message as it exits the Origin: . . . . . 30		15.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
	B.1.2. Message is then received at example.org . . . . . . . 30		15.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
	B.1.3. Example 1: Message received by Recipient . . . . . . 32		15.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30
	B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 33		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	B.2.1. Here's the message as it exits the Origin: . . . . . 33		16.1. Normative References . . . . . . . . . . . . . . . . . . 30
	B.2.2. Message is then received at example.org . . . . . . . 34		16.2. Informative References . . . . . . . . . . . . . . . . . 32
	B.2.3. Example 2: Message received by Recipient . . . . . . 38		16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	B.3. Example 3: Mailing list to forwarded mailbox with source 40		Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
	B.3.1. Here's the message as it exits the Origin: . . . . . 40		A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
	B.3.2. Message is then received at example.org . . . . . . . 41		A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
	B.3.3. Example 3: Message received by Recipient . . . . . . 46		Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 48		B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 34
	Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 49		B.1.1. Here's the message as it exits the Origin: . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		B.1.2. Message is then received at example.org . . . . . . . 35
			B.1.3. Example 1: Message received by Recipient . . . . . . 37
			B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38
			B.2.1. Here's the message as it exits the Origin: . . . . . 38
			B.2.2. Message is then received at example.org . . . . . . . 39
			B.2.3. Example 2: Message received by Recipient . . . . . . 43
			B.3. Example 3: Mailing list to forwarded mailbox with source 45
			B.3.1. Here's the message as it exits the Origin: . . . . . 45
			B.3.2. Message is then received at example.org . . . . . . . 46
			B.3.3. Example 3: Message received by Recipient . . . . . . 51
			Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 53
			Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 54
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
	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 common.		[RFC6376] have become common.
	However, their end-to-end utility is limited by the effects of		However, their end-to-end utility is limited by the effects of
	intermediaries along the transmission path, which either are not		intermediaries along the transmission path, which either are not
	listed (for SPF) or which break digital signatures (for DKIM). 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'
	skipping to change at page 8, line 39 ¶		skipping to change at page 9, line 7 ¶
	4.1.2. Optional Participation		4.1.2. Optional Participation
	Validating an existing chain and then adding your own ARC set to a		Validating an existing chain and then adding your own ARC set to a
	message allows you to claim responsibility for hanndling the message		message allows you to claim responsibility for hanndling the message
	and modifications, if any, done by your ADMD to benefit message		and modifications, if any, done by your ADMD to benefit message
	delivery downstream. However, no ADMD is obligated to perform these		delivery downstream. However, no ADMD is obligated to perform these
	actions.		actions.
	4.1.3. Only one ARC Chain (One Chain to Rule Them All)		4.1.3. Only one ARC Chain (One Chain to Rule Them All)
	A message can have only one ARC chain on it at a time. Once broken,		A message can have only one ARC chain on it at a time (see
	the chain cannot be restarted, as the chain of custody is no longer		Section 5.1). Once broken, the chain cannot be restarted, as the
	valid and responsibility for the message has been lost.		chain of custody is no longer valid and responsibility for the
			message has been lost.
	4.1.4. All Failures are Permanent		4.1.4. All Failures are Permanent
	Because ARC chains are transmitted across multiple intermediaries,		Because ARC chains are transmitted across multiple intermediaries,
	all errors, even temporary ones, become unrecoverable and are		all errors, even temporary ones, become unrecoverable and are
	considered permanent.		considered permanent.
	Any error validating or sealing a chain, for whatever reason, MUST		Any error validating or sealing a chain, for whatever reason, MUST
	result in a "cv=fail" verdict.		result in a "cv=fail" verdict.
	skipping to change at page 9, line 45 ¶		skipping to change at page 10, line 12 ¶
	Section 3.6 of [RFC6376]. ARC places no requirements on the		Section 3.6 of [RFC6376]. ARC places no requirements on the
	selectors and/or domains used for the ARC header field signatures.		selectors and/or domains used for the ARC header field signatures.
	4.1.7. Trace Information		4.1.7. Trace Information
	ARC includes trace information encoded in the AAR. While section		ARC includes trace information encoded in the AAR. While section
	Section 5.2 defines what information must be provided, sealing ADMDs		Section 5.2 defines what information must be provided, sealing ADMDs
	may provide additional information, and validating receivers may use		may provide additional information, and validating receivers may use
	or ignore this trace information as they wish.		or ignore this trace information as they wish.
			4.1.8. Instance Tags
			See section Section 5.1
			4.1.9. Chain Validation Status
			See section Section 5.4.1
	5. The ARC Header Fields		5. The ARC Header Fields
	5.1. Instance ('i=') Tag		5.1. 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 "i" and the value is the text representation of a		The tag-name is "i" and the value is the text representation of a
	positive integer, indicating the position in the ARC sequence this		positive integer, indicating the position in the ARC sequence this
	set occupies, where the first ARC set is numbered 1. In ABNF terms:		set occupies, where the first ARC set is numbered 1. In ABNF terms:
	instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"		instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
	position = 1*2DIGIT ; 1 - 50		position = 1*2DIGIT ; 1 - 50
	Valid ARC sets must have exactly one instance of each header field		Valid ARC sets must have exactly one instance of each header field
	for a given position value. (Note that when multiple algorithms are		for a given position value and signing algorithm. (Initial
	supported, there is some nuance to this statement - see Section 10.)		development of ARC is only being done with a single allowed signing
			algorithm, but parallel work in the DCRUP working group
			(https://datatracker.ietf.org/wg/dcrup/about/) is expanding that.
			For handling multiple signing algorithms, see [ARC-MULTI].)
	Because the AMS and AS header field values are made up of tag-spec		Because the AMS and AS header field values are made up of tag-spec
	constructs, the i= tag may be found anywhere within the header field		constructs, the i= tag may be found anywhere within the header field
	value, but is represented throughout this spec in the initial		value, but is represented throughout this spec in the initial
	position for convenience. Implementers are encouraged to place the		position for convenience. Implementers are encouraged to place the
	i= tag at the beginning of the field value to facilitate human		i= tag at the beginning of the field value to facilitate human
	inspection of the headers.		inspection of the headers.
	5.1.1. Valid Range for Instance Tags		5.1.1. Valid Range for Instance Tags
	skipping to change at page 11, line 30 ¶		skipping to change at page 12, line 8 ¶
	The AAR, through these ptype-properties stamped in arc-info, provide		The AAR, through these ptype-properties stamped in arc-info, provide
	a mechanism for this information to survive transit.		a mechanism for this information to survive transit.
	The ptypes and properties defined in this section SHOULD be stamped		The ptypes and properties defined in this section SHOULD be stamped
	in the AAR:		in the AAR:
	o smtp.client-ip - The connecting client IP address from which the		o smtp.client-ip - The connecting client IP address from which the
	message is received;		message is received;
	o header.ds - The domain/selector pair for each DKIM signature on		o header.s - Defined in [RFC6376] section 7.2
	the message (header.ds=example.com,selector). Note that this is a
	concatenation of the header.d and header.s field values from [[
	TODO: reference DKIM A-R method spec ]] separated by the comma
	character (0x2c). These values are joined into a single arc-info
	field value in order to avoid indexing and correlation ambiguity
	between the possible multiple DKIM signatures which may be found
	on any given message;
	o arc.closest-fail - The hop number of the most recent AS that fails		o arc.oldest-pass - The instance number of the oldest AMS that still
	to validate, or 0 if all hops pass.		validates, or 0 if all pass.
	5.3. ARC-Message-Signature (AMS)		5.3. ARC-Message-Signature (AMS)
	The ARC-Message-Signature header field is syntactically and		The ARC-Message-Signature header field is syntactically and
	semantically identical to a DKIM-Signature header field [RFC6376],		semantically identical to a DKIM-Signature header field [RFC6376],
	with the following exceptions:		with the following exceptions:
	o There is an "i" tag, as described in Section 5.1.		o There is an "i" tag, as described in Section 5.1.
	o There is no "v" tag.		o There is no "v" tag.
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 50 ¶
	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 input 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 8.3).		situation where a chain has failed validation (see Section 7.1).
	6. Verifier Actions		6. Verifier Actions
	The verifier takes the following steps to determine the current state		A verifier takes the following steps to determine the state of the
	of the ARC chain on the message. Canonicalization, hash functions,		ARC chain on a message (cv value). Canonicalization, hash functions,
	and signature validation methods are imported from Section 5 of		and signature validation methods are imported from Section 5 of
	[RFC6376].		[RFC6376].
	[[ Note: need markdown flag to have subordinate numbering distinction		[[ 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 the form of any ARC set is invalid (e.g., does not contain		2. If the form of any ARC set is invalid (e.g., does not contain
	skipping to change at page 14, line 40 ¶		skipping to change at page 15, line 12 ¶
	[RFC6376]. Pass the canonicalized result to the hash		[RFC6376]. Pass the canonicalized result to the hash
	function.		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 4.1.6.		the ARC-Seal, as described in Section 4.1.6.
	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. (See also Section Section 8.4 for failure case		public key. (See also Section Section 6.1 for failure case
	handling)		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.
	[[ Note from Dave: possibly delete the following paragraph as it is		[[ Note from Dave: possibly delete the following paragraph as it is
	more usage/procedural than specification guidance.		more usage/procedural than specification guidance.
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 39 ¶
	the WG think that this can be reasonably removed from this location?		the WG think that this can be reasonably removed from this location?
	]]		]]
	The verifier should save the cv state for subsequent use by any		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.
			6.1. Handling DNS Problems While Validating ARC
			DNS-based failures to verify a chain are treated no differently than
			any other ARC violation. They result in a "cv=fail" verdict.
			6.2. Responding to ARC Validity Violations During the SMTP Transaction
			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
			[RFC3463] "message integrity failure" [ENHANCED-STATUS] and
			corresponding SMTP response code.
	7. Signer Actions		7. Signer Actions
	[[ Note from Dave: This seems more like implementation guidance than		[[ Note from Dave: This seems more like implementation guidance than
	specification detail. KA: see explanation just above referring to		specification detail. KA: see explanation just above referring to
	the previous note. ]]		the previous note. ]]
	This section includes a specification of the actions an ARC signer		This section includes a specification of the actions an ARC signer
	takes when presented with a message.		takes when presented with a message.
	The signer MUST undertake the following steps:		The signer MUST undertake the following steps:
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 39 ¶
	3. Generate and attach to the message an ARC-Message-Signature		3. Generate and attach to the message an ARC-Message-Signature
	header field as defined in Section 5.3 above, using instance		header field as defined in Section 5.3 above, using instance
	number N+1.		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.4 above,		using the general algorithm described in Section 5.4 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.
			7.1. Marking and Sealing "cv=fail" (Invalid) Chains
			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
			created by the MTA which detected the malformed chain, as if this
			newest ARC set was the only set present.
	8. Usage of ARC and Chain Validity		8. Usage of ARC and Chain Validity
	8.1. Relationship between DKIM-Signature and AMS signing scopes		8.1. Relationship between DKIM-Signature and AMS signing scopes
			[[ SB-11: replace with "ARC MUST be the last signer of the message;
			otherwise it cannot be validated on receipt." in the signer actions
			section. KA: Concern that this still does not address the risk of
			DKIM-Signatures covering ARC chains. This does not seem like it fits
			in this section but it needs to go somewhere. ]]
	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		[[ 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		DKIM, which comes first? The chicken or the egg? I'm open to
	alternate ways to phrase this without opening the "modifying the DKIM		alternate ways to phrase this without opening the "modifying the DKIM
	spec" can of worms. ]]		spec" can of worms. ]]
	8.2. Assessing Chain Validity Violations		8.2. Assessing Chain Validity Violations
			[[ SB-11: move to protocol elements
			KA: This seems a bit banal. I suspect that what receivers want is a
			section on using ARC to override DMARC failures. Would that be to
			brazen to insert here instead? Or do we relegate that to the
			[ARC-USAGE] doc? ]]
	Email transit can produce broken signatures for a wide variety of		Email transit can produce broken signatures for a wide variety of
	benign reasons. This includes possibly breaking one or more ARC		benign reasons. This includes possibly breaking one or more ARC
	signatures. Therefore, receivers need to be wary of ascribing motive		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.
	ARC does not attempt to protect an entire message. There are various		ARC does not attempt to protect an entire message. There are various
	ways that a message can still be problematic, in spite of having a		ways that a message can still be problematic, in spite of having a
	valid ARC chain. Consequently, all normal, content-based analysis		valid ARC chain. Consequently, all normal, content-based analysis
	SHOULD still be performed on any message having a valid chain of ARC		SHOULD still be performed on any message having a valid chain of ARC
	header sets.		header sets.
	8.3. Marking and Sealing "cv=fail" (Invalid) Chains
	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
	created by the MTA which detected the malformed chain, as if this
	newest ARC set was the only set present.
	8.4. Handling DNS Problems While Validating ARC
	DNS-based failures to verify a chain are treated no differently than
	any other ARC violation. They result in a "cv=fail" verdict.
	8.5. Responding to ARC Validity Violations
	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
	[RFC3463] "message integrity failure" [ENHANCED-STATUS] and
	corresponding SMTP response code.
	9. Recording and Reporting the Results of ARC Evaluation		9. Recording and Reporting the Results of ARC Evaluation
	The evaluation of an ARC chain provides information which will be		The evaluation of an ARC chain provides information which will be
	useful to both the receiver (or intermediary) and to the initial		useful to both the receiver (or intermediary) and to the initial
	sender of the message. This information should be preserved and		sender of the message. This information should be preserved and
	reported as follows.		reported as follows.
	9.1. Information from an ARC Evaluation		9.1. Information from an ARC Evaluation
	The evaluation of an ARC chain produces a list of domain names for		The evaluation of an ARC chain produces a list of domain names for
	skipping to change at page 18, line 27 ¶		skipping to change at page 19, line 10 ¶
	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		10. Supporting Alternate Signing Algorithms
	[[ Note: Some additional development of this section is needed. ]]		This section has been moved to [ARC-MULTI]
	In the following branch diagrams, each algorithm is represented by an		11. Privacy Considerations
	'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
	algorithm.
	Note that during a transitional period where multiple algorithms are		The ARC chain provides a verifiable record of the handlers for a
	allowed, all of the statements in this spec which refer to "exactly		message. Anonymous remailers will probably not find this compatible
	one set of ARC headers per instance" need to be understood as "at		with their operating goals.
	least one set per instance and no more than one instance-set per
	algorithm".
	10.1. Introductory Period		12. IANA Considerations
	Intermediaries MUST be able to validate ARC chains built with either		This specification adds three new header fields as defined below.
	algorithm but MAY create ARC sets with either (or both) algorithm.
	The introductory period should be at least six (6) months.		12.1. Authentication-Results Method Registry Update
	10.2. Co-Existence Period		This draft adds one item to the IANA "Email Authentication Methods"
			registry:
	Intermediaries MUST be able to validate ARC chains build with either		o Method : arc
	algorithm and MUST create ARC sets with both algorithms. Chains
	ending with either algorithm may be used for the result.
	10.3. Deprecation Period		Defined: [I-D.ARC]
	ARC sets built with algorithms that are being deprecated MAY be		ptype: header
	considered valid within an ARC chain, however, intermediaries MUST
	NOT create additional sets with the deprecated algorithm.
	The deprecation period should be at least two (2) years.		Property: chain evaluation result
	10.4. Obsolescence Period		Value: chain evaluation result status (see Section 5.4)
	ARC sets built with algorithms that are obsolete MUST NOT be		Status: active
	considered valid within an ARC chain. Intermediaries MUST NOT create
	any sets with any obsoleted algorithm.
	11. Privacy Considerations		Version: 1
	The ARC chain provides a verifiable record of the handlers for a		o Method : dkim
	message. Anonymous remailers will probably not find this compatible
	with their operating goals.
	12. IANA Considerations		Defined: [I-D.ARC]
	This specification adds three new header fields as defined below.		ptype: header
	12.1. Authentication-Results Method Registry Update		Property: selector
	This draft adds one item to the IANA "Email Authentication Methods"		Value: value of signature "s" tag (see [RFC6376])
	registry:
			Status: active
			Version: 1
			o Method : spf
			Defined: [I-D.ARC]
			ptype: smtp
			Property: client-ip
			Value: the connecting client IP address from which the message is
			received
			Status: active
			Version: 1
	o Method : arc		o Method : arc
	Defined: [I-D.ARC]		Defined: [I-D.ARC]
	ptype: header		ptype: header
	Property: chain evaluation result		Property: oldest-pass
	Value: chain evaluation result status (see Section 5.4)		Value: the oldest instance with a still validating AMS signature
	Status: active		Status: active
	Version: 1		Version: 1
	12.2. Definitions of the ARC header fields		12.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:
	skipping to change at page 21, line 34 ¶		skipping to change at page 22, line 20 ¶
	13.3. Message Content Suspicion		13.3. Message Content Suspicion
	Recipients are cautioned to treat messages bearing ARC sets with the		Recipients are cautioned to treat messages bearing ARC sets with the
	same suspicion that they apply to all other email messages. This		same suspicion that they apply to all other email messages. This
	includes appropriate content scanning and other checks for		includes appropriate content scanning and other checks for
	potentially malicious content. The handlers which are identified		potentially malicious content. The handlers which are identified
	within the ARC chain may be used to provide input to local policy		within the ARC chain may be used to provide input to local policy
	engines in cases where DMARC validation fails (due to mediation		engines in cases where DMARC validation fails (due to mediation
	impacting SPF attribution, DKIM validity or alignment).		impacting SPF attribution, DKIM validity or alignment).
	14. Implementation Status		Note that a passing ARC chain may not adequately mean that the
			message is safe because:
			1. You have to trust all signatories; and
			2. Even trusted systems may have become compromised or may not
			properly authenticate messages, so even with a chain of trusted
			participants, the message might still never have authenticated in
			the first place (which is why you have the AAR to inspect) or
			could have been subject to unintended modifications.
			14. Evaluating the Efficacy of the ARC Protocol
			The ARC protocol is designed to mitigate some of the most common
			failure conditions for email which transits intermediary handlers en
			route to the final recipient. Some of these problems have happened
			due to the adoption of the DMARC protocol [RFC7489] and are listed in
			[RFC6377] and [RFC7960].
			As the ARC protocol becomes standardized and implemented amongst
			intermediary handlers, the following aspects should be evaluated in
			order to determine the success of the protocol in accomplishing the
			intended benefits.
			NOTE: Terminology within this section does NOT follow [RFC2119]
			interpretation. This section represents the current thoughts of the
			working group regarding unanswered questions related to the protocol.
			Wider deployment will inform these topics and probably expand them.
			14.1. Success Consideration
			Currently, many receivers have heuristically determined overrides in
			order to rescue mail from intermediary-caused failures. Many of
			those overrides rely on inferrence rather than direct evidence.
			ARC will be a success if, for ARC sealed messages, receivers are able
			to implment ARC-based algorithmic decisions based on the direct
			evidence found within the ARC chain. This is especially relevant for
			DMARC processing when the DKIM d= value is aligned with the
			rfc5322.From author domain.
			14.2. Failure Considerations
			The intent of ARC is to be at most value-add and at worst benign. If
			ARC opens up significant new vectors for abuse (see Section 13) then
			this protocol will be a failure. Note that weaknesses inherent in
			the mail protocols ARC is built upon (such as DKIM replay attacks and
			other known issues) are not new vectors which can be attributed to
			this specification.
			14.3. Open Questions
			The following open questions are academic and have no clear answer at
			the time of the development of the protocol. However, wide-spread
			deployment should be able to gather the necessary data to answer some
			or all of them.
			14.3.1. Value of the ARC-Seal (AS) Header
			Data should be collected to show if the ARC-Seal (AS) provides value
			beyond the ARC Message Signature (AMS) for either making delivery
			decisions or catching malicious actors trying to craft or replay
			malicious chains.
			14.3.2. DNS Overhead
			Longer ARC chains will require more queries to retrieve the keys for
			validating the chain. While this is not believed to be a security
			issue (see Section 13.2), it is unclear how much overhead will truly
			be added. This is similar to some of the initial processing and
			query load concerns which were debated at the time of the DKIM
			specification development.
			Data should be collected to better understand usable length and
			distribution of lengths found in valid ARC chains along with the the
			DNS impact of processing ARC chains.
			14.3.3. Distinguishing Valuable from Worthless Trace Information
			There are several edge cases where the information in the AAR can
			make the difference between message delivery or rejection. For
			example, if there is a well known mailing list that ARC seals but
			doesn't do its own initial DMARC enforcement, a Final Receiver with
			this knowledge could make a delivery decision based upon the
			authentication information it sees in the corresponding AAR header.
			Certain trace information in the AAR is useful/necessary in the
			construction of DMARC reports. It would be beneficial to identify
			the value-add of having intermediary-handled mail flow information
			added into the DMARC reports going back to senders.
			Certain receivers believe the entire set of trace information would
			be valuable to feed into machine learning systems to identify fraud
			and/or provide other signals related to message delivery.
			It is unclear what trace information will be valuable for all
			receivers, regardless of size.
			Data should be collected on what trace information receivers are
			using that provides useful signals that affect deliverability, and
			what portions of the trace data are left untouched or provide no
			useful information.
			Since many such systems are intentionly proprietary or confidential
			to prevent gaming by abusers, it may not be viable to reliably answer
			this particular question. The evolving nature of attacks can also
			shift the landscape of "useful" information over time.
			15. Implementation Status
	[[ Note: For minimizing section number references when the RFC editor		[[ Note: For minimizing section number references when the RFC editor
	removes this section, it has been moved to be the last section of the		removes this section, it has been moved to be the last section of the
	document before the Appendicies. ]]		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
	skipping to change at page 22, line 11 ¶		skipping to change at page 25, line 13 ¶
	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.
	14.1. GMail test reflector and incoming validation		For a few of the implementations, later status information was
			available as of December 2017.
			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]
	14.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 23, line 5 ¶		skipping to change at page 26, line 10 ¶
	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]
	14.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
	14.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-10]
	Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)		Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
	Implementation Notes:		Implementation Notes:
	o The build is FreeBSD oriented but some packages have been built		o The build is FreeBSD oriented but some packages have been built
	for easier deployment on RedHat-based Linux platforms.		for easier deployment on RedHat-based Linux platforms.
	o 2017-07-15: Testing showed problems with the hash calculation for
	the AMS header b= field. Several other bugs were discovered and
	were either fixed during the following week of IETF meetings or
	are under active repair.
	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. (_NOTE_: this is expected to resolved with a
			new release of OpenDMARC expected in January 2018.)
	Contact Info: arc-discuss@dmarc.org [3]		Contact Info: arc-discuss@dmarc.org [3]
	14.5. Mailman 3.1+ patch		15.5. Mailman 3.2 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.2
	package		package
	Status of Operation: Patch submitted		Status of Operation: Patch submitted
	Coverage: Unknown		Coverage: Based on OpenARC
	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
	14.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 25, line 10 ¶		skipping to change at page 28, line 10 ¶
	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/
	14.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 25, line 33 ¶		skipping to change at page 28, line 33 ¶
	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
	14.8. PERL Mail::Milter::Authentication module		15.8. PERL MAIL::DKIM module
	Organization: FastMail		Organization: FastMail
	Description: Email domain authentication milter, previously included		Description: Email domain authentication (sign and/or verify) module,
	SPF / DKIM / DMARC, now has ARC added		previously included SPF / DKIM / DMARC, now has ARC added
			Status of Operation: Production, deployment usage unknown
			Coverage: Built to support [ARC-DRAFT-10]
			Licensing: Open Source
			Implementation Notes:
			o 2017-12-15: v0.50 released with full test set passing for ARC
			Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
			15.9. PERL Mail::Milter::Authentication module
			Organization: FastMail
			Description: Email domain authentication milter, uses MAIL::DKIM (see
			above)
	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]
	Licensing: Open Source		Licensing: Open Source
	Implementation Notes:		Implementation Notes:
	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
	15. References		15.10. Sympa List Manager
	15.1. Normative References		Organization: Sympa Dev Community
			Description: Work in progress
			Status of Operation: Work in progress
			Coverage: unknown
			Licensing: open source
			Implementation Notes:
			o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
			issues/153
			Contact Info: https://github.com/sympa-community
			15.11. Oracle Messaging Server
			Organization: Oracle
			Description:
			Status of Operation: Intial development work during IETF99 hackathon.
			Status since then unknown.
			Coverage: Built to support [ARC-DRAFT-06]
			Licensing: Unknown
			Implementation Notes:
			o Status since the work done in July 2017 is unknown.
			Contact Info:
			15.12. MessageSystems Momentum
			Organization: MessageSystems/SparkPost
			Description: OpenARC integration into the LUA-enabled Momentum
			processing space
			Status of Operation: Beta
			Coverage: Built to support [ARC-DRAFT-10]
			Licensing: Unknown
			Implementation Notes:
			o Initial deployments for validation expected in early 2018.
			Contact Info:
			16. 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,
	<https://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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 27, line 48 ¶		skipping to change at page 32, line 35 ¶
	[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,
	<https://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,
	<https://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., "Authenticated Received Chain (ARC) Protocol
	Received Chain (ARC) Protocol (I-D-06)", n.d.,		(I-D-05)", n.d., <https://tools.ietf.org/html/
	<https://tools.ietf.org/html/		draft-ietf-dmarc-arc-protocol-05>.
	draft-ietf-dmarc-arc-protocol-06>.
	[ARC-DRAFT-06]		[ARC-DRAFT-06]
	Andersen, K., Long, B., and S. Jones, "Authenticated		Andersen, K., "Authenticated Received Chain (ARC) Protocol
	Received Chain (ARC) Protocol (I-D-05)", n.d.,		(I-D-06)", n.d., <https://tools.ietf.org/html/
	<https://tools.ietf.org/html/		draft-ietf-dmarc-arc-protocol-06>.
	draft-ietf-dmarc-arc-protocol-05>.
			[ARC-DRAFT-10]
			Andersen, K., "Authenticated Received Chain (ARC) Protocol
			(I-D-10)", n.d., <https://tools.ietf.org/html/
			draft-ietf-dmarc-arc-protocol-10>.
			[ARC-MULTI]
			Andersen, K., "Using Multiple Signing Algorithms with
			ARC", January 2018, <https://tools.ietf.org/html/
			draft-ietf-dmarc-arc-multi-01>.
	[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/		<https://tools.ietf.org/html/
	draft-ietf-dmarc-arc-usage-01>.		draft-ietf-dmarc-arc-usage-01>.
	skipping to change at page 29, line 5 ¶		skipping to change at page 33, line 42 ¶
	(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,		(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
	<https://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,
	<https://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
	skipping to change at line 2235 ¶		skipping to change at page 54, line 35 ¶
	Steven Jones (editor)		Steven Jones (editor)
	TDP		TDP
	Email: smj@crash.com		Email: smj@crash.com
	Seth Blank (editor)		Seth Blank (editor)
	ValiMail		ValiMail
	Email: seth@valimail.com		Email: seth@valimail.com
			Murray Kucherawy (editor)
			TDP
			Email: superuser@gmail.com
End of changes. 73 change blocks.
	174 lines changed or deleted		400 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/