draft-ietf-dmarc-arc-protocol-20.txt		draft-ietf-dmarc-arc-protocol-21.txt
	DMARC Working Group K. Andersen		DMARC Working Group K. Andersen
	Internet-Draft LinkedIn		Internet-Draft LinkedIn
	Intended status: Experimental B. Long, Ed.		Intended status: Experimental B. Long, Ed.
	Expires: May 10, 2019 Google		Expires: May 11, 2019 Google
	S. Blank, Ed.		S. Blank, Ed.
	Valimail		Valimail
	M. Kucherawy, Ed.		M. Kucherawy, Ed.
	TDP		TDP
	November 6, 2018		November 7, 2018
	Authenticated Received Chain (ARC) Protocol		Authenticated Received Chain (ARC) Protocol
	draft-ietf-dmarc-arc-protocol-20		draft-ietf-dmarc-arc-protocol-21
	Abstract		Abstract
	The Authenticated Received Chain (ARC) protocol provides an		The Authenticated Received Chain (ARC) protocol provides an
	authenticated "chain of custody" for a message, allowing each entity		authenticated "chain of custody" for a message, allowing each entity
	that handles the message to see what entities handled it before, and		that handles the message to see what entities handled it before, and
	to see what the message's authentication assessment was at each step		to see what the message's authentication assessment was at each step
	in the handling.		in the handling.
	ARC allows Internet Mail Handlers to attach assertions of message		ARC allows Internet Mail Handlers to attach assertions of message
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 May 10, 2019.		This Internet-Draft will expire on May 11, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 31		12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 31
	12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32		12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32
	12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32		12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32
	12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32		12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32		12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32
	12.15. IIJ . . . . . . . . . . . . . . . . . . . . . . . . . . 33		12.15. IIJ . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	13.1. Normative References . . . . . . . . . . . . . . . . . . 33		13.1. Normative References . . . . . . . . . . . . . . . . . . 33
	13.2. Informative References . . . . . . . . . . . . . . . . . 34		13.2. Informative References . . . . . . . . . . . . . . . . . 34
	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35		13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix A. Appendix A - Design Requirements . . . . . . . . . . 36		Appendix A. Design Requirements . . . . . . . . . . . . . . . . 36
	A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36		A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36
	A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36		A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 36		Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 36
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 38		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 38
	Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 38		Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	The utility of widely deployed email authentication technologies such		The utility of widely deployed email authentication technologies such
	as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified		as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
	Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail		Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
	by intermediate handlers. This impact is thoroughly documented in		by intermediate handlers. This impact is thoroughly documented in
	skipping to change at page 18, line 30 ¶		skipping to change at page 18, line 30 ¶
	failures, become unrecoverable and are considered permanent.		failures, become unrecoverable and are considered permanent.
	Any error validating an Authenticated Received Chain results in a		Any error validating an Authenticated Received Chain results in a
	Chain Validation Status of "fail". For further discussion of this		Chain Validation Status of "fail". For further discussion of this
	topic and the design restriction which prevents chain continuation or		topic and the design restriction which prevents chain continuation or
	re-establishment, see [ARC-USAGE].		re-establishment, see [ARC-USAGE].
	5.2.2. Responding to ARC Validation Failures During the SMTP		5.2.2. Responding to ARC Validation Failures During the SMTP
	Transaction		Transaction
	If an ARC Validator determines that the incoming message fails		If an ARC Validator determines that the incoming message fails ARC
	authentication checks (potentially including ARC validation), the		validation, the Validator MAY signal the breakage through the
	Validator MAY signal the breakage through the extended SMTP response		extended SMTP response code 5.7.29 "ARC validation failure" and
	code 5.7.29 "ARC validation failure" and corresponding SMTP basic		corresponding SMTP basic response code. Because ARC failures are
	response code. Validators MAY use the more general 5.7.28 "Multiple		likely only to be detected in the context of other underlying
	authentication checks failed" instead.		authentication mechanism failures, validators MAY use the more
			general 5.7.26 "Multiple authentication checks failed" instead of the
			ARC-specific code.
	6. Communication of Validation Results		6. Communication of Validation Results
	Chain Validation Status (described in Section 4.4) is communicated		Chain Validation Status (described in Section 4.4) is communicated
	via Authentication-Results (and AAR) header fields using the auth		via Authentication-Results (and AAR) header fields using the auth
	method "arc". This auth method is described in Section 10.1.		method "arc". This auth method is described in Section 10.1.
	If necessary data is available, the ptypes and properties defined in		If necessary data is available, the ptypes and properties defined in
	Section 10.2 SHOULD be recorded in an Authentication-Results header		Section 10.2 SHOULD be recorded in an Authentication-Results header
	field:		field:
	skipping to change at page 25, line 31 ¶		skipping to change at page 25, line 31 ¶
	10.4. New Enhanced Status Code - ARC Validation		10.4. New Enhanced Status Code - ARC Validation
	The following value should be added to the [ENHANCED-STATUS]		The following value should be added to the [ENHANCED-STATUS]
	registry, as follows:		registry, as follows:
	o Code: X.7.29		o Code: X.7.29
	Sample Text: ARC validation failure		Sample Text: ARC validation failure
	Associated basic status code: 550		Associated basic status code: 550
	Description: This status code may be returned when a message fails		Description: This status code may be returned when a message fails
	multiple authentication checks, including ARC validation		ARC validation
	Reference: this document		Reference: this document
	Submitter: K. Andersen		Submitter: K. Andersen
	Change controller: IESG		Change controller: IESG
	11. Experimental Considerations		11. Experimental Considerations
	The ARC protocol is designed to address common interoperability		The ARC protocol is designed to address common interoperability
	issues introduced by intermediate message handlers. Interoperability		issues introduced by intermediate message handlers. Interoperability
	issues are described in [RFC6377] and [RFC7960].		issues are described in [RFC6377] and [RFC7960].
	skipping to change at page 36, line 19 ¶		skipping to change at page 36, line 19 ¶
	[5] mailto:openarc-users@openarc.org		[5] mailto:openarc-users@openarc.org
	[6] mailto:dmarc@ietf.org		[6] mailto:dmarc@ietf.org
	[7] mailto:arc-discuss@dmarc.org		[7] mailto:arc-discuss@dmarc.org
	[8] mailto:arc-interop@dmarc.org		[8] mailto:arc-interop@dmarc.org
	[9] https://arc-spec.org		[9] https://arc-spec.org
	Appendix A. Appendix A - Design Requirements		Appendix A. Design Requirements
	The specification of the ARC framework is driven by the following		The specification of the ARC framework is driven by the following
	high-level goals, security considerations, and practical operational		high-level goals, security considerations, and practical operational
	requirements.		requirements.
	A.1. Primary Design Criteria		A.1. Primary Design Criteria
	o Provide a verifiable "chain of custody" for email messages;		o Provide a verifiable "chain of custody" for email messages;
	o Not require changes for originators of email;		o Not require changes for originators of email;
	skipping to change at page 36, line 45 ¶		skipping to change at page 36, line 45 ¶
	o Provide a trustable mechanism for the communication of		o Provide a trustable mechanism for the communication of
	Authentication-Results across trust boundaries.		Authentication-Results across trust boundaries.
	A.2. Out of Scope		A.2. Out of Scope
	ARC is not a trust framework. Users of the ARC header fields are		ARC is not a trust framework. Users of the ARC header fields are
	cautioned against making unsubstantiated conclusions when		cautioned against making unsubstantiated conclusions when
	encountering a "broken" ARC sequence.		encountering a "broken" ARC sequence.
	Appendix B. Appendix B - Example Usage		Appendix B. Example Usage
	The following message is an example of one which has passed through		The following message is an example of one which has passed through
	several intermediary handlers, some of which have modified the		several intermediary handlers, some of which have modified the
	message and others which have not:		message and others which have not:
	Return-Path: <jqd@d1.example>		Return-Path: <jqd@d1.example>
	Received: from example.org (example.org [208.69.40.157])		Received: from example.org (example.org [208.69.40.157])
	by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207		by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
	for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)		for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
	Received: from segv.d1.example (segv.d1.example [72.52.75.15])		Received: from segv.d1.example (segv.d1.example [72.52.75.15])
End of changes. 10 change blocks.
	15 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/