draft-ietf-dmarc-arc-usage-08.txt   draft-ietf-dmarc-arc-usage-09.txt 
DMARC Working Group S. Jones, Ed. DMARC Working Group S. Jones, Ed.
Internet-Draft DMARC.org Internet-Draft DMARC.org
Intended status: Informational K. Andersen Intended status: Informational K. Andersen
Expires: April 24, 2020 LinkedIn Expires: November 7, 2020 LinkedIn
October 22, 2019 May 06, 2020
Recommended Usage of the Authenticated Received Chain (ARC) Recommended Usage of the Authenticated Received Chain (ARC)
draft-ietf-dmarc-arc-usage-08 draft-ietf-dmarc-arc-usage-09
Abstract Abstract
The Authentication Received Chain (ARC) provides an authenticated The Authenticated Received Chain (ARC) provides an authenticated
"chain of custody" for a message, allowing each entity that handles "chain of custody" for a message, allowing each entity that handles
the message to see what entities handled it before, and to see what the message to see what entities handled it before, and to see what
the message's authentication assessment was at each step in the the message's authentication assessment was at each step in the
handling. But the specification does not indicate how the entities handling. But the specification does not indicate how the entities
handling these messages should interpret or utilize ARC results in handling these messages should interpret or utilize ARC results in
making decisions about message disposition. This document will making decisions about message disposition. This document will
provide guidance in these areas. provide guidance in these areas.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 24, 2020. This Internet-Draft will expire on November 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. How does ARC work? . . . . . . . . . . . . . . . . . . . 3 2.1. How does ARC work? . . . . . . . . . . . . . . . . . . . 3
2.2. What new headers are introduced by ARC? . . . . . . . . . 5 2.2. What new headers are introduced by ARC? . . . . . . . . . 5
2.3. Does ARC support Internationalized Email (EAI)? . . . . . 5 2.3. Does ARC support Internationalized Email (EAI)? . . . . . 5
2.4. Does ARC support multiple digital signature algorithms? . 5 2.4. Does ARC support multiple digital signature algorithms? . 5
3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 6
3.1. What is the significance of an intact ARC chain? . . . . 5 3.1. What is the significance of an intact ARC chain? . . . . 6
3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6
3.3. What is the significance of an invalid ("broken") ARC 3.3. What is the significance of an invalid ("broken") ARC
chain? . . . . . . . . . . . . . . . . . . . . . . . . . 6 chain? . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. What error code(s) should be returned if an invalid ARC 3.4. What error code(s) should be returned if an invalid ARC
chain is detected during an SMTP transaction? . . . . . . 7 chain is detected during an SMTP transaction? . . . . . . 7
3.5. What does the absence of an ARC chain in a message mean? 7 3.5. What does the absence of an ARC chain in a message mean? 7
3.6. What reasonable conclusions can you draw based upon 3.6. What reasonable conclusions can you draw based upon
seeing lots of mail with ARC chains? . . . . . . . . . . 7 seeing lots of mail with ARC chains? . . . . . . . . . . 7
3.7. What if none of the intermediaries have been seen 3.7. What if none of the intermediaries have been seen
previously? . . . . . . . . . . . . . . . . . . . . . . . 8 previously? . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. What about ARC chains where some intermediaries are known 3.8. What about ARC chains where some intermediaries are known
and others are not? . . . . . . . . . . . . . . . . . . . 8 and others are not? . . . . . . . . . . . . . . . . . . . 8
3.9. What should message handlers do when they detect 3.9. What should message handlers do when they detect
malicious content in messages where ARC is present? . . . 8 malicious content in messages where ARC is present? . . . 8
3.10. What feedback does a sender or domain owner get about ARC 3.10. What feedback does a sender or domain owner get about ARC
when it is applied to their messages? . . . . . . . . . . 9 when it is applied to their messages? . . . . . . . . . . 9
3.11. What prevents a malicious actor from removing the ARC 3.11. What prevents a malicious actor from removing the ARC
header fields, altering the content, and creating a new header fields, altering the content, and creating a new
ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9 ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9
4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 9 3.12. What should an ARC Receiver/Validator do when multiple
4.1. What is an Intermediary under ARC? . . . . . . . . . . . 9 digital signature algorithms are used in an ARC chain? . 10
4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 10
4.1. What is an Intermediary under ARC? . . . . . . . . . . . 10
4.2. What are the minimum requirements for an ARC 4.2. What are the minimum requirements for an ARC
Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. More specifically a participating ARC intermediary 4.2.1. More specifically a participating ARC intermediary
must do the following: . . . . . . . . . . . . . . . 10 must do the following: . . . . . . . . . . . . . . . 10
4.3. Should every MTA be an ARC participant? . . . . . . . . . 10 4.3. Should every MTA be an ARC participant? . . . . . . . . . 10
4.4. What should an intermediary do in the case of an invalid 4.4. What should an intermediary do in the case of an invalid
or "broken" ARC chain? . . . . . . . . . . . . . . . . . 10 or "broken" ARC chain? . . . . . . . . . . . . . . . . . 11
4.5. What should I do in the case where there is no ARC chain 4.5. What should I do in the case where there is no ARC chain
present in a message? . . . . . . . . . . . . . . . . . . 11 present in a message? . . . . . . . . . . . . . . . . . . 11
4.6. How could ARC affect my reputation as an intermediary? . 11 4.6. How could ARC affect my reputation as an intermediary? . 11
4.7. What can I do to influence my reputation as an 4.7. What can I do to influence my reputation as an
intermediary? . . . . . . . . . . . . . . . . . . . . . . 11 intermediary? . . . . . . . . . . . . . . . . . . . . . . 11
4.8. How can an ARC Intermediary adopt a new digital signature
5. Guidance for Originators . . . . . . . . . . . . . . . . . . 11 algorithm that other Intermediaries and Validators may
5.1. Where can I find out more information? . . . . . . . . . 11 not support? . . . . . . . . . . . . . . . . . . . . . . 12
5. Guidance for Originators . . . . . . . . . . . . . . . . . . 12
5.1. Where can I find more information? . . . . . . . . . . . 12
5.2. How/where can I test interoperabililty for my 5.2. How/where can I test interoperabililty for my
implementation? . . . . . . . . . . . . . . . . . . . . . 12 implementation? . . . . . . . . . . . . . . . . . . . . . 12
5.3. How can ARC impact my email? . . . . . . . . . . . . . . 12 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 12
5.4. How can ARC impact my reputation as a message sender? . . 12 5.4. How can ARC impact my reputation as a message sender? . . 13
5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
6.2. Security Considerations . . . . . . . . . . . . . . . . . 13 6.2. Security Considerations . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. References . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. References . . . . . . . . . . . . . . . . . . . . . 19
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 18 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[ARC] is intended to be used by Internet Mail Handlers who forward or The Authenticated Received Chain (ARC) [RFC8617] is intended to be
resend messages, with or without alterations, such that they will no used by Internet Mail Handlers who forward or resend messages, with
longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] or without alterations, such that they will no longer pass the SPF
mechanisms when evaluated by subsequent message handlers or the final [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] mechanisms when
recipient. In such cases ARC may provide useful information about evaluated by subsequent message handlers or the final recipient. In
the message before the forwarding and/or alterations took place, and such cases ARC may provide useful information about the message
recipients may choose to use this information to influence delivery before the forwarding and/or alterations took place, and recipients
decisions. may choose to use this information to influence delivery decisions.
2. Overview 2. Overview
2.1. How does ARC work? 2.1. How does ARC work?
Consider a message sent to a mailing list. Assume that the message Consider a message sent to a mailing list. Assume that the message
author's domain publishes an SPF record, signs messages with a DKIM author's domain publishes an SPF record, signs messages with a DKIM
signature that includes the RFC5322.Subject header and the message signature that includes the RFC5322.Subject header and the message
body, and publishes a DMARC policy of "p=reject". Finally, assume body, and publishes a DMARC policy of "p=reject". Finally, assume
that the final recipient(s) of the message implement SPF, DKIM and that the final recipient(s) of the message implement SPF, DKIM and
skipping to change at page 5, line 13 skipping to change at page 5, line 19
receiving ADMD implements ARC, it can check for and validate the ARC receiving ADMD implements ARC, it can check for and validate the ARC
chain in the message, and verify that the contents of the ARC- chain in the message, and verify that the contents of the ARC-
Authentication-Results header were conveyed intact from the MLM's Authentication-Results header were conveyed intact from the MLM's
ADMD. At that point the final recipient's ADMD might choose to use ADMD. At that point the final recipient's ADMD might choose to use
those authentication results in the decision whether or not to those authentication results in the decision whether or not to
deliver the message, even though it failed to pass conventional SPF, deliver the message, even though it failed to pass conventional SPF,
DKIM, and DMARC checks. DKIM, and DMARC checks.
2.2. What new headers are introduced by ARC? 2.2. What new headers are introduced by ARC?
The following new headers are defined in [ARC] Section 4.1, "ARC The following new headers are defined in [RFC8617] Section 4.1, "ARC
Header Fields": Header Fields":
o ARC-Seal o ARC-Seal
o ARC-Message-Signature o ARC-Message-Signature
o ARC-Athentication-Results o ARC-Athentication-Results
Each time a message passes through an ARC Intermediary, an ARC Set Each time a message passes through an ARC Intermediary, an ARC Set
consisting of these three headers will be attached to the message. consisting of these three headers will be attached to the message.
More information about ARC Sets can be found in [ARC] Section 4.2, More information about ARC Sets can be found in [RFC8617]
"ARC Set." The entire collection of ARC Sets in a message is Section 4.2, "ARC Set." The entire collection of ARC Sets in a
commonly referred to as the ARC Chain. message is commonly referred to as the ARC Chain.
2.3. Does ARC support Internationalized Email (EAI)? 2.3. Does ARC support Internationalized Email (EAI)?
Changes to support EAI are inherited from DKIM [RFC6376] as updated Changes to support EAI are inherited from DKIM [RFC6376] as updated
by [draft-levine-eaiauth], and Authentication-Results as updated in by [RFC8616], and Authentication-Results as updated in [RFC8601].
[I-D-7601bis]. For more details, please refer to [ARC] For more details, please refer to [RFC8617] Section 4.1.4,
Section 4.1.4, "Internationalized Email (EAI)." "Internationalized Email (EAI)."
2.4. Does ARC support multiple digital signature algorithms? 2.4. Does ARC support multiple digital signature algorithms?
Originally ARC only supported a single signing algorithm, but the Originally ARC only supported a single signing algorithm, but the
DCRUP working group https://datatracker.ietf.org/wg/dcrup/about [1] DCRUP working group https://datatracker.ietf.org/wg/dcrup/about [1]
is expanding the set of supported algorithms available to DKIM expanded the set of supported algorithms available to DKIM [RFC6376]
[RFC6376] and derived protocols. [ARC-MULTI] is adapting this work and derived protocols. [RFC8463] is a standards track document that
to extend [ARC] to support multiple algorithms. adds the Edd25519-SHA256 signing algorithm to DKIM, and [ARC-MULTI]
is adapting this work to allow ARC to support multiple signing
algorithms.
3. Guidance for Receivers/Validators 3. Guidance for Receivers/Validators
3.1. What is the significance of an intact ARC chain? 3.1. What is the significance of an intact ARC chain?
An intact ARC chain conveys authentication results like SPF and DKIM An intact ARC chain conveys authentication results like SPF and DKIM
as observed by the first ARC participant. In cases where the message as observed by the first ARC participant. In cases where the message
no longer produces passing results for DKIM, SPF, or DMARC but an no longer produces passing results for DKIM, SPF, or DMARC but an
intact ARC chain is present, the message receiver may choose to use intact ARC chain is present, the message receiver may choose to use
the contents of the first ARC-Authentication-Results header field in the contents of the first ARC-Authentication-Results header field in
skipping to change at page 7, line 14 skipping to change at page 7, line 21
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.
3.4. What error code(s) should be returned if an invalid ARC chain is 3.4. What error code(s) should be returned if an invalid ARC chain is
detected during an SMTP transaction? detected during an SMTP transaction?
According to [ARC] Section 5.2.2, a Validator MAY signal the breakage According to [RFC8617] Section 5.2.2, a Validator MAY signal the
during the SMTP transaction by returning the extended SMTP response breakage during the SMTP transaction by returning the extended SMTP
code 5.7.29 "ARC validation failure" and corresponding SMTP basic response code 5.7.29 "ARC validation failure" and corresponding SMTP
response code. Since ARC failures are likely the be detected due to basic response code. Since ARC failures are likely the be detected
other, underlying authentication failures, Validators may also choose due to other, underlying authentication failures, Validators may also
to return the more general 5.7.26 "Multiple authentication checks choose to return the more general 5.7.26 "Multiple authentication
failed instead of the ARC-specific code. checks failed instead of the ARC-specific code.
3.5. What does the absence of an ARC chain in a message mean? 3.5. What does the absence of an ARC chain in a message mean?
The absence of an ARC chain means nothing. ARC is intended to allow The absence of an ARC chain means nothing. ARC is intended to allow
a participating message handler to preserve certain authentication a participating message handler to preserve certain authentication
results when a message is being forwarded and/or modified such that results when a message is being forwarded and/or modified such that
the final recipient can evaluate this information. If they are the final recipient can evaluate this information. If they are
absent, there is nothing extra that ARC requires the final recipient absent, there is nothing extra that ARC requires the final recipient
to do. to do.
skipping to change at page 9, line 8 skipping to change at page 9, line 10
a message recipient who maintains a reputation system about email a message recipient who maintains a reputation system about email
senders may wish to incorporate this information as an additional senders may wish to incorporate this information as an additional
factor in the score for the intermediaries and sender in question. factor in the score for the intermediaries and sender in question.
However reputation systems are very complex, and usually unique to However reputation systems are very complex, and usually unique to
those organizations operating them, and therefore beyond the scope of those organizations operating them, and therefore beyond the scope of
this document. this document.
3.10. What feedback does a sender or domain owner get about ARC when it 3.10. What feedback does a sender or domain owner get about ARC when it
is applied to their messages? is applied to their messages?
ARC itself does not include any mechanism for feedback or reporting. ARC itself does not currently include any mechanism for feedback or
It does however recommend that message receiving systems that use ARC reporting. It does however recommend that message receiving systems
to augment their delivery decisions, who use DMARC and decide to that use ARC to augment their delivery decisions, who use DMARC and
deliver a message because of ARC information, should include a decide to deliver a message because of ARC information, should
notation to that effect in their normal DMARC reports. These include a notation to that effect in their normal DMARC reports.
notations would be easily identifiable by report processors, so that These notations would be easily identifiable by report processors, so
senders and domain owners can see where ARC is being used to augment that senders and domain owners can see where ARC is being used to
the deliverability of their messages. augment the deliverability of their messages.
3.11. What prevents a malicious actor from removing the ARC header 3.11. What prevents a malicious actor from removing the ARC header
fields, altering the content, and creating a new ARC chain? fields, altering the content, and creating a new ARC chain?
ARC does not prevent a malicious actor from doing this. Nor does it ARC does not prevent a malicious actor from doing this. Nor does it
prevent a malicious actor from removing all but the first ADMD's ARC prevent a malicious actor from removing all but the first ADMD's ARC
header fields and altering the message, eliminating intervening header fields and altering the message, eliminating intervening
participants from the ARC chain. Or similar variations. participants from the ARC chain. Or similar variations.
A valid ARC chain does not provide any automatic benefit. With an A valid ARC chain does not provide any automatic benefit. With an
skipping to change at page 9, line 45 skipping to change at page 10, line 5
already able to do without ARC involved, but now a signature linked already able to do without ARC involved, but now a signature linked
to the domain responsible for the manipulation is present. to the domain responsible for the manipulation is present.
Additionally in the second case it is possible some negative Additionally in the second case it is possible some negative
reputational impact might accrue to the first ARC participant left in reputational impact might accrue to the first ARC participant left in
place until more messages reveal the pattern of activity by the bad place until more messages reveal the pattern of activity by the bad
actor. But again, a bad actor can similarly manipulate a sequence of actor. But again, a bad actor can similarly manipulate a sequence of
RFC5322.Received header fields today without ARC, but with ARC that RFC5322.Received header fields today without ARC, but with ARC that
bad actor has verifiably identified themselves. bad actor has verifiably identified themselves.
3.12. What should an ARC Receiver/Validator do when multiple digital
signature algorithms are used in an ARC chain?
[ARC-MULTI] is adapting the output of the DCRUP working group
https://datatracker.ietf.org/wg/dcrup/about [2] for use in ARC. It
specifically covers how to create and validate ARC header sets and
chains that include mutliple signature algorithms.
4. Guidance for Intermediaries 4. Guidance for Intermediaries
4.1. What is an Intermediary under ARC? 4.1. What is an Intermediary under ARC?
In the context of ARC, an Intermediary is typically an Administrative In the context of ARC, an Intermediary is typically an Administrative
Management Domain [RFC5598] that is receiving a message, potentially Management Domain [RFC5598] that is receiving a message, potentially
manipulating or altering it, and then passing it on to another ADMD manipulating or altering it, and then passing it on to another ADMD
for delivery. Common examples of Intermediaries are mailing lists, for delivery. Common examples of Intermediaries are mailing lists,
alumni or professional email address providers that forward messages alumni or professional email address providers that forward messages
such as universities or professional organizations, et cetera. such as universities or professional organizations, et cetera.
skipping to change at page 10, line 18 skipping to change at page 10, line 35
A participating ARC intermediary must validate the ARC chain on a A participating ARC intermediary must validate the ARC chain on a
message it receives, if one is present. It then attaches its own ARC message it receives, if one is present. It then attaches its own ARC
seal and signature, including an indication if the chain failed to seal and signature, including an indication if the chain failed to
validate upon receipt. validate upon receipt.
4.2.1. More specifically a participating ARC intermediary must do the 4.2.1. More specifically a participating ARC intermediary must do the
following: following:
1. Validate that the ARC chain, if one is already present in the 1. Validate that the ARC chain, if one is already present in the
message, is intact and well-formed. ([ARC] Section 5.2, message, is intact and well-formed. ([RFC8617] Section 5.2,
"Validator Actions") "Validator Actions")
2. Record the ARC status in an Authentication-Results header 2. Record the ARC status in an Authentication-Results header
([RFC7601]) ([RFC8601])
3. Generate a new ARC set and add it to the message. ([ARC] 3. Generate a new ARC set and add it to the message. ([RFC8617]
Section 5.1, "Sealer Actions") Section 5.1, "Sealer Actions")
4.3. Should every MTA be an ARC participant? 4.3. Should every MTA be an ARC participant?
Generally speaking, ARC is designed to operate at the ADMD level. Generally speaking, ARC is designed to operate at the ADMD level.
When a message is first received by an ADMD, the traditional When a message is first received by an ADMD, the traditional
authentication results should be captured and preserved - this could authentication results should be captured and preserved - this could
be the common case of creating an Authentication-Results header be the common case of creating an Authentication-Results header
field. But when it is determined that the message is being sent on field. But when it is determined that the message is being sent on
outside of that ADMD, that is when the ADMD should add itself to the outside of that ADMD, that is when the ADMD should add itself to the
skipping to change at page 11, line 39 skipping to change at page 12, line 4
is beyond the scope of this document. is beyond the scope of this document.
4.7. What can I do to influence my reputation as an intermediary? 4.7. What can I do to influence my reputation as an intermediary?
Today it is extremely simple for a malicious actor to construct a Today it is extremely simple for a malicious actor to construct a
message that includes your identity as an intermediary, even though message that includes your identity as an intermediary, even though
you never handled the message. It is possible that an intermediary you never handled the message. It is possible that an intermediary
implementing ARC on all traffic it handles might receive some implementing ARC on all traffic it handles might receive some
reputational benefit by making it easier to detect when their reputational benefit by making it easier to detect when their
involvement in conveying bad traffic has been "forged." involvement in conveying bad traffic has been "forged."
As mentioned previously reputation systems are very complex and As mentioned previously reputation systems are very complex and
usually specific to a given message receiver, and a meaningful usually specific to a given message receiver, and a meaningful
discussion of such a broad topic is beyond the scope of this discussion of such a broad topic is beyond the scope of this
document. document.
4.8. How can an ARC Intermediary adopt a new digital signature
algorithm that other Intermediaries and Validators may not
support?
[ARC-MULTI] is adapting the output of the DCRUP working group
https://datatracker.ietf.org/wg/dcrup/about [3] for use in ARC. It
specifically covers how to create and validate ARC header sets and
chains that include mutliple signature algorithms.
5. Guidance for Originators 5. Guidance for Originators
5.1. Where can I find out more information? 5.1. Where can I find more information?
Please visit the http://arc-spec.org [2] web site, or join the arc- Please visit the http://arc-spec.org [4] web site, or join the arc-
discuss mailing list at http://lists.dmarc.org/mailman/listinfo/arc- discuss mailing list at http://lists.dmarc.org/mailman/listinfo/arc-
discuss [3]. discuss [5].
To discuss the [ARC] specification itself, please join the DMARC To discuss details of the [RFC8617] specification itself, especially
working group at https://datatracker.ietf.org/wg/dmarc [4]. errata, please join the DMARC working group at
https://datatracker.ietf.org/wg/dmarc [6].
5.2. How/where can I test interoperabililty for my implementation? 5.2. How/where can I test interoperabililty for my implementation?
There have been numerous interoperability tests during the There have been numerous interoperability tests during the
development of the [ARC] specification. These tests are usually development of the ARC [RFC8617] specification. These tests are
announced on both the arc-discuss mailing list at usually announced on both the arc-discuss mailing list at
http://lists.dmarc.org/mailman/listinfo/arc-discuss [5], and the http://lists.dmarc.org/mailman/listinfo/arc-discuss [7], and the
DMARC working group at https://datatracker/ietf.org/wg/dmarc [6]. DMARC working group at https://datatracker/ietf.org/wg/dmarc [8].
Join whichever body is most appropriate for you and/or your Join whichever body is most appropriate for you and/or your
organization to receive future announcements. organization to receive future announcements.
5.3. How can ARC impact my email? 5.3. How can ARC impact my email?
Prior to ARC, certain DMARC policies on a domain would cause messages Prior to ARC, certain DMARC policies on a domain would cause messages
using those domains in the RFC5322.From field, and which pass through using those domains in the RFC5322.From field, and which pass through
certain kinds of intermediaries (mailing lists, forwarding services), certain kinds of intermediaries (mailing lists, forwarding services),
to fail authentication checks at the message receiver. As a result to fail authentication checks at the message receiver. As a result
these messages might not be delivered to the intended recipient. these messages might not be delivered to the intended recipient.
skipping to change at page 13, line 41 skipping to change at page 14, line 13
<https://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,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[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,
<https://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC8601] Kucherawy, M., "Message Header Field for Indicating
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Message Authentication Status", RFC 8601,
September 2011, <https://www.rfc-editor.org/info/rfc6377>. DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Message Authentication Status", RFC 7601, Kucherawy, Ed., "The Authenticated Received Chain (ARC)
DOI 10.17487/RFC7601, August 2015, Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc7601>. <https://www.rfc-editor.org/info/rfc8617>.
7.2. Informative References 7.2. Informative References
[ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy,
"Authenticated Received Chain (ARC) Protocol", December
2018, <https://tools.ietf.org/html/draft-ietf-dmarc-arc-
protocol-23>.
[ARC-MULTI] [ARC-MULTI]
Andersen, K., Blank, S., and J. Levine, "Using Multiple Andersen, K., Blank, S., and J. Levine, "Using Multiple
Signing Algorithms with ARC", June 2018, Signing Algorithms with ARC", March 2019,
<https://tools.ietf.org/html/draft-ietf-dmarc-arc-multi- <https://tools.ietf.org/html/draft-ietf-dmarc-arc-multi-
02>. 03>.
[draft-levine-eaiauth]
Levine, J., "E-mail Authentication for Internationalized
Mail", August 2018, <https://tools.ietf.org/html/draft-
levine-appsarea-eaiauth-03>.
[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>.
[I-D-7601bis]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/draft-ietf-dmarc-
rfc7601bis/>.
[OAR] Chew, M. and M. Kucherawy, "Original-Authentication- [OAR] Chew, M. and M. Kucherawy, "Original-Authentication-
Results Header Field", February 2012, Results Header Field", February 2012,
<https://tools.ietf.org/html/draft-kucherawy-original- <https://tools.ietf.org/html/draft-kucherawy-original-
authres-00>. authres-00>.
[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,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[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>.
[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,
<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>.
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage
Update to DomainKeys Identified Mail (DKIM)", RFC 8301,
DOI 10.17487/RFC8301, January 2018,
<https://www.rfc-editor.org/info/rfc8301>.
[RFC8463] Levine, J., "A New Cryptographic Signature Method for
DomainKeys Identified Mail (DKIM)", RFC 8463,
DOI 10.17487/RFC8463, September 2018,
<https://www.rfc-editor.org/info/rfc8463>.
[RFC8616] Levine, J., "Email Authentication for Internationalized
Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
<https://www.rfc-editor.org/info/rfc8616>.
7.3. URIs 7.3. URIs
[1] https://datatracker.ietf.org/wg/dcrup/about [1] https://datatracker.ietf.org/wg/dcrup/about
[2] http://arc-spec.org [2] https://datatracker.ietf.org/wg/dcrup/about
[3] http://lists.dmarc.org/mailman/listinfo/arc-discuss [3] https://datatracker.ietf.org/wg/dcrup/about
[4] https://datatracker.ietf.org/wg/dmarc [4] http://arc-spec.org
[5] http://lists.dmarc.org/mailman/listinfo/arc-discuss [5] http://lists.dmarc.org/mailman/listinfo/arc-discuss
[6] https://datatracker/ietf.org/wg/dmarc [6] https://datatracker.ietf.org/wg/dmarc
[7] mailto:arc-discuss@dmarc.org [7] http://lists.dmarc.org/mailman/listinfo/arc-discuss
[8] https://datatracker.ietf.org/wg/dmarc [8] https://datatracker/ietf.org/wg/dmarc
[9] https://arc-spec.org [9] mailto:arc-discuss@dmarc.org
[10] mailto:arc-discuss@dmarc.org [10] https://datatracker.ietf.org/wg/dmarc
[11] http://lists.dmarc.org/mailman/listinfo/arc-discuss [11] https://arc-spec.org
[12] mailto:arc-discuss@dmarc.org
[13] http://lists.dmarc.org/mailman/listinfo/arc-discuss
Appendix A. Glossary Appendix A. Glossary
ADMD Administrative Management Domain as used in [RFC5598] and ADMD Administrative Management Domain as used in [RFC5598] and
similar references refers to a single entity operating one or more similar references refers to a single entity operating one or more
computers within one or more domain names under said entity's computers within one or more domain names under said entity's
control. One example might be a small company with a single control. One example might be a small company with a single
server, handling email for that company's domain. Another example server, handling email for that company's domain. Another example
might be a large university, operating many servers that fulfill might be a large university, operating many servers that fulfill
different roles, all handling email for several different domains different roles, all handling email for several different domains
representing parts of the university. representing parts of the university.
ARC ARC is an acronym: Authentication Results Chain - see also [ARC] ARC ARC is an acronym: Authenticated Received Chain - see [RFC8617]
ARC-Seal An [RFC5322] message header field formed in compliance with ARC-Seal An [RFC5322] message header field formed in compliance with
the ARC specification. It includes certain content from all prior the ARC specification. It includes certain content from all prior
ARC participants, if there are any. ARC participants, if there are any.
ARC-Message-Signature (also abbreviated as "AMS") An [RFC5322] ARC-Message-Signature (also abbreviated as "AMS") An [RFC5322]
message header field formed in compliance with the [ARC] message header field formed in compliance with the [RFC8617]
specification. It includes certain content about the message as specification. It includes certain content about the message as
it was received and manipulated by the intermediary who inserted it was received and manipulated by the intermediary who inserted
it. it.
ARC-Authentication-Results (also abbreviated as "AAR") An [RFC5322] ARC-Authentication-Results (also abbreviated as "AAR") An [RFC5322]
message header field formed in compliance with the [ARC] message header field formed in compliance with the [RFC8617]
specification. It includes certain content about the message as specification. It includes certain content about the message as
it was received by the intermediary. it was received by the intermediary.
Authentication Results Chain (ARC) A system that allows a Message Authenticated Received Chain (ARC) A system that allows a Message
Receiver to identify Intermediaries or Message Handlers who have Receiver to identify Intermediaries or Message Handlers who have
conveyed a particular message. For more information see the conveyed a particular message. For more information see the
Abstract of this document, or refer to [ARC]. Abstract of this document, or refer to [RFC8617].
Domain Naming System Block List (DNSBL) This is a system widely used Domain Naming System Block List (DNSBL) This is a system widely used
in email filtering services whereby information about the past in email filtering services whereby information about the past
activity of a set of hosts or domains indicates that messages activity of a set of hosts or domains indicates that messages
should not be accepted from them, or at least should be subject to should not be accepted from them, or at least should be subject to
greater scrutiny before being accepted. Common examples would be greater scrutiny before being accepted. Common examples would be
SpamCop, Spamhaus.org, SORBS, etc. SpamCop, Spamhaus.org, SORBS, etc.
Email Service Provider (ESP) An Email Service Provider is typically Email Service Provider (ESP) An Email Service Provider is typically
a vendor or partner firm that sends mail on behalf of another a vendor or partner firm that sends mail on behalf of another
company. They may use email addresses in Internet domains company. They may use email addresses in Internet domains
belonging to the client or partner firm in various [RFC5321] belonging to the client or partner firm in various [RFC5321]
fields or [RFC5322] message header fields of the messages they fields or [RFC5322] message header fields of the messages they
send on their behalf. send on their behalf.
Intermediary In the context of [ARC], an Intermediary is typically Intermediary In the context of [RFC8617], an Intermediary is
an Administrative Management Domain (per [RFC5598]) that is typically an Administrative Management Domain (per [RFC5598]) that
receiving a message, potentially manipulating or altering it, and is receiving a message, potentially manipulating or altering it,
then passing it on to another ADMD for delivery. Also see and then passing it on to another ADMD for delivery. Also see
[RFC7960] for more information and discussion. Common examples of [RFC7960] for more information and discussion. Common examples of
Intermediaries are mailing lists, alumni or professional email Intermediaries are mailing lists, alumni or professional email
address providers like universities or professional organizations, address providers like universities or professional organizations,
et cetera. et cetera.
Mail/Message Transfer Agent (MTA) This refers to software that sends Mail/Message Transfer Agent (MTA) This refers to software that sends
and receives email messsages across a network with other MTAs. and receives email messsages across a network with other MTAs.
Often run on dedicated servers, common examples are Exim, Often run on dedicated servers, common examples are Exim,
Microsoft Exchange, Postfix, and Sendmail. Microsoft Exchange, Postfix, and Sendmail.
skipping to change at page 18, line 23 skipping to change at page 19, line 9
within the message and various types of content within the message within the message and various types of content within the message
body. Link: [RFC5322] body. Link: [RFC5322]
Validator A Message Receiver that attempts to validate the ARC chain Validator A Message Receiver that attempts to validate the ARC chain
in a message. in a message.
Appendix B. References Appendix B. References
Appendix C. Acknowledgements Appendix C. Acknowledgements
This draft is based on the work of OAR-Dev Group. This document is based on the work of OAR-Dev Group.
The authors thank the entire OAR-Dev group for the ongoing help, The authors thank the entire OAR-Dev group for the ongoing help,
innumerable diagrams and discussions from all the participants, innumerable diagrams and discussions from all the participants,
especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth
Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant,
Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Mike Hammer, Mike Jones, Terry Zink, Tim Draegen.
This document was influenced by questions posed in the arc- This document was influenced by questions posed in the arc-
discuss@dmarc.org [7] mailing list, and the authors thank all the discuss@dmarc.org [9] mailing list, and the authors thank all the
list participants for their input. list participants for their input.
Appendix D. Comments and Feedback Appendix D. Comments and Feedback
Please address all comments, discussions, and questions about this Please address all comments, discussions, and questions about this
document, or about [ARC] itself, to the dmarc working group at document, or about [RFC8617] itself, to the DMARC Working Group at
https://datatracker.ietf.org/wg/dmarc [8]. https://datatracker.ietf.org/wg/dmarc [10].
Readers looking for general information about ARC may refer to the Readers looking for general information about ARC may refer to the
website https://arc-spec.org [9], or to the arc-discuss@dmarc.org website https://arc-spec.org [11], or to the arc-discuss@dmarc.org
[10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- [12] mailing list at http://lists.dmarc.org/mailman/listinfo/arc-
discuss [11]. discuss [13].
Authors' Addresses Authors' Addresses
Steven M Jones (editor) Steven M Jones (editor)
DMARC.org DMARC.org
2419 McGee Avenue 2419 McGee Avenue
Berkeley, California 94703 Berkeley, California 94703
USA USA
Email: smj@dmarc.org Email: smj@dmarc.org
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
 End of changes. 58 change blocks. 
117 lines changed or deleted 148 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/