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/