draft-ietf-dmarc-arc-usage-06.txt | draft-ietf-dmarc-arc-usage-07.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 25, 2019 LinkedIn | Expires: October 25, 2019 LinkedIn | |||
J. Rae-Grant | April 23, 2019 | |||
T. Adams | ||||
Paypal | ||||
October 22, 2018 | ||||
Recommended Usage of the Authenticated Received Chain (ARC) | Recommended Usage of the Authenticated Received Chain (ARC) | |||
draft-ietf-dmarc-arc-usage-06 | draft-ietf-dmarc-arc-usage-07 | |||
Abstract | Abstract | |||
The Authentication Received Chain (ARC) provides an authenticated | The Authentication 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 | |||
skipping to change at page 1, line 42 ¶ | 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 25, 2019. | This Internet-Draft will expire on October 25, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 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. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3 | 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. How does ARC work? . . . . . . . . . . . . . . . . . . . 3 | ||||
2.2. What new headers are introduced by ARC? . . . . . . . . . 5 | ||||
2.3. Does ARC support Internationalized Email (EAI)? . . . . . 5 | ||||
2.4. Does ARC support multiple digital signature algorithms? . 5 | ||||
3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5 | 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5 | |||
3.1. What is the significance of an intact ARC chain? . . . . 5 | 3.1. What is the significance of an intact ARC chain? . . . . 5 | |||
3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 5 | 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 does the absence of an ARC chain in a message mean? 6 | 3.4. What error code(s) should be returned if an invalid ARC | |||
3.5. What reasonable conclusions can you draw based upon | chain is detected during an SMTP transaction? . . . . . . 7 | |||
seeing lots of mail with ARC chains? . . . . . . . . . . 6 | 3.5. What does the absence of an ARC chain in a message mean? 7 | |||
3.6. What if none of the intermediaries have been seen | 3.6. What reasonable conclusions can you draw based upon | |||
previously? . . . . . . . . . . . . . . . . . . . . . . . 7 | seeing lots of mail with ARC chains? . . . . . . . . . . 7 | |||
3.7. What about ARC chains where some intermediaries are known | 3.7. What if none of the intermediaries have been seen | |||
and others are not? . . . . . . . . . . . . . . . . . . . 7 | previously? . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.8. What should message handlers do when they detect | 3.8. What about ARC chains where some intermediaries are known | |||
malicious content in messages where ARC is present? . . . 7 | and others are not? . . . . . . . . . . . . . . . . . . . 8 | |||
3.9. What feedback does a sender or domain owner get about ARC | 3.9. What should message handlers do when they detect | |||
when it is applied to their messages? . . . . . . . . . . 8 | malicious content in messages where ARC is present? . . . 8 | |||
3.10. What prevents a malicious actor from removing the ARC | 3.10. What feedback does a sender or domain owner get about ARC | |||
when it is applied to their messages? . . . . . . . . . . 9 | ||||
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? . . . . . . . . . . . . . . . . . . . . . . . 8 | ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8 | 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 9 | |||
4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8 | 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 9 | |||
4.2. What are the minimum requirements for an ARC | 4.2. What are the minimum requirements for an ARC | |||
Intermediary? . . . . . . . . . . . . . . . . . . . . . . 9 | Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2.1. More specifically a participating ARC intermediary | 4.2.1. More specifically a participating ARC intermediary | |||
must do the following: . . . . . . . . . . . . . . . 9 | must do the following: . . . . . . . . . . . . . . . 10 | |||
4.3. Should every MTA be an ARC participant? . . . . . . . . . 9 | 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? . . . . . . . . . . . . . . . . . 9 | or "broken" ARC chain? . . . . . . . . . . . . . . . . . 10 | |||
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? . . . . . . . . . . . . . . . . . . 10 | present in a message? . . . . . . . . . . . . . . . . . . 11 | |||
4.6. How could ARC affect my reputation as an intermediary? . 10 | 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? . . . . . . . . . . . . . . . . . . . . . . 10 | intermediary? . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10 | ||||
5.1. Where can I find out more information? . . . . . . . . . 10 | 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 11 | |||
5.1. Where can I find out more information? . . . . . . . . . 11 | ||||
5.2. How/where can I test interoperabililty for my | 5.2. How/where can I test interoperabililty for my | |||
implementation? . . . . . . . . . . . . . . . . . . . . . 11 | implementation? . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.3. How can ARC impact my email? . . . . . . . . . . . . . . 11 | 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 12 | |||
5.4. How can ARC impact my reputation as a message sender? . . 11 | 5.4. How can ARC impact my reputation as a message sender? . . 12 | |||
5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11 | 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13 | |||
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 | 6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6.2. Security Considerations . . . . . . . . . . . . . . . . . 12 | 6.2. Security Considerations . . . . . . . . . . . . . . . . . 13 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 12 | 7.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 13 | 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix B. References . . . . . . . . . . . . . . . . . . . . . 16 | Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 16 | Appendix B. References . . . . . . . . . . . . . . . . . . . . . 18 | |||
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 16 | Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
1. Introduction | 1. Introduction | |||
[ARC] is intended to be used by Internet Mail Handlers who forward or | [ARC] is intended to be used by Internet Mail Handlers who forward or | |||
resend messages, with or without alterations, such that they will no | resend messages, with or without alterations, such that they will no | |||
longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] | longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] | |||
mechanisms when evaluated by subsequent message handlers or the final | mechanisms when evaluated by subsequent message handlers or the final | |||
recipient. In such cases ARC may provide useful information about | recipient. In such cases ARC may provide useful information about | |||
the message before the forwarding and/or alterations took place, and | the message before the forwarding and/or alterations took place, and | |||
recipients may choose to use this information to influence delivery | recipients may choose to use this information to influence delivery | |||
decisions. | decisions. | |||
2. How does ARC work? | 2. Overview | |||
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 | |||
DMARC authentication checks on incoming messages. | DMARC authentication checks on incoming messages. | |||
This message is received by the ADMD hosting the Mailing List Manager | This message is received by the ADMD hosting the Mailing List Manager | |||
(MLM) software. Upon receipt from the message author's ADMD, the | (MLM) software. Upon receipt from the message author's ADMD, the | |||
skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 11 ¶ | |||
When the message reaches a list member's ADMD, the SPF and DKIM | When the message reaches a list member's ADMD, the SPF and DKIM | |||
results will still not pass the DMARC check. However if the | results will still not pass the DMARC check. However if the | |||
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? | ||||
The following new headers are defined in [ARC] Section 4.1, "ARC | ||||
Header Fields": | ||||
o ARC-Seal | ||||
o ARC-Message-Signature | ||||
o ARC-Athentication-Results | ||||
Each time a message passes through an ARC Intermediary, an ARC Set | ||||
consisting of these three headers will be attached to the message. | ||||
More information about ARC Sets can be found in [ARC] Section 4.2, | ||||
"ARC Set." The entire collection of ARC Sets in a message is | ||||
commonly referred to as the ARC Chain. | ||||
2.3. Does ARC support Internationalized Email (EAI)? | ||||
Changes to support EAI are inherited from DKIM [RFC6376] as updated | ||||
by [draft-levine-eaiauth], and Authentication-Results as updated in | ||||
[I-D-7601bis]. For more details, please refer to [ARC] | ||||
Section 4.1.4, "Internationalized Email (EAI)." | ||||
2.4. Does ARC support multiple digital signature algorithms? | ||||
Originally ARC only supported a single signing algorithm, but the | ||||
DCRUP working group https://datatracker.ietf.org/wg/dcrup/about [1] | ||||
is expanding the set of supported algorithms available to DKIM | ||||
[RFC6376] and derived protocols. [ARC-MULTI] is adapting this work | ||||
to extend [ARC] to support multiple 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 | |||
determining how to handle the message. | determining how to handle the message. | |||
skipping to change at page 6, line 25 ¶ | skipping to change at page 7, line 11 ¶ | |||
as if there was no ARC chain at all. For example, a message that | as if there was no ARC chain at all. For example, a message that | |||
fails under DMARC and has an invalid ARC chain would be subject to | fails under DMARC and has an invalid ARC chain would be subject to | |||
that DMARC policy, which may cause it to be quarantined or rejected. | that DMARC policy, which may cause it to be quarantined or rejected. | |||
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 does the absence of an ARC chain in a message mean? | 3.4. What error code(s) should be returned if an invalid ARC chain is | |||
detected during an SMTP transaction? | ||||
According to [ARC] Section 5.2.2, a Validator MAY signal the breakage | ||||
during the SMTP transaction by returning the extended SMTP response | ||||
code 5.7.29 "ARC validation failure" and corresponding SMTP basic | ||||
response code. Since ARC failures are likely the be detected due to | ||||
other, underlying authentication failures, Validators may also choose | ||||
to return the more general 5.7.26 "Multiple authentication checks | ||||
failed instead of the ARC-specific code. | ||||
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. | |||
3.5. What reasonable conclusions can you draw based upon seeing lots of | 3.6. What reasonable conclusions can you draw based upon seeing lots of | |||
mail with ARC chains? | mail with ARC chains? | |||
With sufficient history, ARC can be used to augment DMARC | With sufficient history, ARC can be used to augment DMARC | |||
authentication policy (i.e. a message could fail DMARC, but validated | authentication policy (i.e. a message could fail DMARC, but validated | |||
ARC information and therefore could be considered as validly | ARC information and therefore could be considered as validly | |||
authenticated as reported by the first ARC participant). | authenticated as reported by the first ARC participant). | |||
If the validator does content analysis and reputation tracking, the | If the validator does content analysis and reputation tracking, the | |||
ARC participants in a message can be credited or discredited for good | ARC participants in a message can be credited or discredited for good | |||
or bad content. By analyzing different ARC chains involved in "bad" | or bad content. By analyzing different ARC chains involved in "bad" | |||
messages, a validator might identify malicious participating | messages, a validator might identify malicious participating | |||
intermediaries. | intermediaries. | |||
With a valid chain and good reputations for all ARC participants, | With a valid chain and good reputations for all ARC participants, | |||
receivers may choose to apply a "local policy override" to the DMARC | receivers may choose to apply a "local policy override" to the DMARC | |||
policy assertion for the domain authentication evaluation, depending | policy assertion for the domain authentication evaluation, depending | |||
on the ARC-Authentication-Results header field value. Normal content | on the ARC-Authentication-Results header field value. Normal content | |||
analysis should never be skipped. | analysis should never be skipped. | |||
3.6. What if none of the intermediaries have been seen previously? | 3.7. What if none of the intermediaries have been seen previously? | |||
This has no impact on the operation of ARC, as ARC is not a | This has no impact on the operation of ARC, as ARC is not a | |||
reputation system. ARC conveys the results of other authentication | reputation system. ARC conveys the results of other authentication | |||
mechanisms such that the participating message handlers can be | mechanisms such that the participating message handlers can be | |||
positively identified. Final message recipients may or may not | positively identified. Final message recipients may or may not | |||
choose to examine these results when messages fail other | choose to examine these results when messages fail other | |||
authentication checks. They are more likely to override, say, a | authentication checks. They are more likely to override, say, a | |||
failing DMARC result in the presence of an intact ARC chain where the | failing DMARC result in the presence of an intact ARC chain where the | |||
participating ARC message handlers have been observed to not convey | participating ARC message handlers have been observed to not convey | |||
"bad" content in the past, and the initial ARC participant indicates | "bad" content in the past, and the initial ARC participant indicates | |||
the message they received had passed authentication checks. | the message they received had passed authentication checks. | |||
3.7. What about ARC chains where some intermediaries are known and | 3.8. What about ARC chains where some intermediaries are known and | |||
others are not? | others are not? | |||
Validators may choose to build reputation models for ARC message | Validators may choose to build reputation models for ARC message | |||
handlers they have observed. Generally speaking it is more feasible | handlers they have observed. Generally speaking it is more feasible | |||
to accrue positive reputation to intermediaries when they | to accrue positive reputation to intermediaries when they | |||
consistently send messages that are evaluated positively in terms of | consistently send messages that are evaluated positively in terms of | |||
content and ARC chains. When messages are received with ARC chains | content and ARC chains. When messages are received with ARC chains | |||
that are not intact, it is very difficult identify which | that are not intact, it is very difficult identify which | |||
intermediaries may have manipulated the message or injected bad | intermediaries may have manipulated the message or injected bad | |||
content. | content. | |||
3.8. What should message handlers do when they detect malicious content | 3.9. What should message handlers do when they detect malicious content | |||
in messages where ARC is present? | in messages where ARC is present? | |||
Message handlers should do what they normally do when they detect | Message handlers should do what they normally do when they detect | |||
malicious content in a message - hopefully that means quarantining or | malicious content in a message - hopefully that means quarantining or | |||
discarding the message. ARC information should never make malicious | discarding the message. ARC information should never make malicious | |||
content acceptable. | content acceptable. | |||
In such cases it is difficult to determine where the malicious | In such cases it is difficult to determine where the malicious | |||
content may have been injected. What ARC can do in such cases is | content may have been injected. What ARC can do in such cases is | |||
verify that a given intermediary or message handler did in fact | verify that a given intermediary or message handler did in fact | |||
handle the message as indicated in the header fields. In such cases | handle the message as indicated in the header fields. In such cases | |||
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.9. 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 include any mechanism for feedback or reporting. | |||
It does however recommend that message receiving systems that use ARC | It does however recommend that message receiving systems that use ARC | |||
to augment their delivery decisions, who use DMARC and decide to | to augment their delivery decisions, who use DMARC and decide to | |||
deliver a message because of ARC information, should include a | deliver a message because of ARC information, should include a | |||
notation to that effect in their normal DMARC reports. These | notation to that effect in their normal DMARC reports. These | |||
notations would be easily identifiable by report processors, so that | notations would be easily identifiable by report processors, so that | |||
senders and domain owners can see where ARC is being used to augment | senders and domain owners can see where ARC is being used to augment | |||
the deliverability of their messages. | the deliverability of their messages. | |||
3.10. 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 | |||
intact ARC chain, the final message recipient may choose to use the | intact ARC chain, the final message recipient may choose to use the | |||
contents of the ARC-Authentication-Results header field in | contents of the ARC-Authentication-Results header field in | |||
skipping to change at page 9, line 18 ¶ | skipping to change at page 10, line 18 ¶ | |||
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. ([ARC] Section 5.2, | |||
"Validator Actions") | ||||
2. Record the ARC status in an Authentication-Results header | 2. Record the ARC status in an Authentication-Results header | |||
([RFC7601]) | ([RFC7601]) | |||
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. ([ARC] | |||
Section 5.1) | 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 | |||
ARC chain - before sending the message outside of the ADMD. | ARC chain - before sending the message outside of the ADMD. | |||
Some organizations may operate multiple ADMDs, with more or less | Some organizations may operate multiple ADMDs, with more or less | |||
independence between them. While they should make a determination | independence between them. While they should make a determination | |||
based on their specific circumstances, it may be useful and | based on their specific circumstances, it may be useful and | |||
appropriate to have one or both ADMDs be ARC participants. | appropriate to have multiple ADMDs be ARC participants. | |||
4.4. What should an intermediary do in the case of an invalid or | 4.4. What should an intermediary do in the case of an invalid or | |||
"broken" ARC chain? | "broken" ARC chain? | |||
In general terms, a participating ARC intermediary will note that an | In general terms, a participating ARC intermediary will note that an | |||
ARC chain was present and invalid, or broken, when it attaches its | ARC chain was present and invalid, or broken, when it attaches its | |||
own ARC seal and signature. However the fact that the ARC chain was | own ARC seal and signature. However the fact that the ARC chain was | |||
invalid should have no impact on whether and how the message is | invalid should have no impact on whether and how the message is | |||
delivered. | delivered. | |||
skipping to change at page 10, line 49 ¶ | skipping to change at page 11, line 49 ¶ | |||
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. | |||
5. Guidance for Originators | 5. Guidance for Originators | |||
5.1. Where can I find out more information? | 5.1. Where can I find out more information? | |||
Please join the arc-discuss list at arc-discuss@dmarc.org. | Please visit the http://arc-spec.org [2] web site, or join the arc- | |||
discuss mailing list at http://lists.dmarc.org/mailman/listinfo/arc- | ||||
discuss [3]. | ||||
To discuss the IETF spec itself, please join the dmarc working group | To discuss the [ARC] specification itself, please join the DMARC | |||
at [https://datatracker.ietf.org/wg/dmarc]. | working group at https://datatracker.ietf.org/wg/dmarc [4]. | |||
5.2. How/where can I test interoperabililty for my implementation? | 5.2. How/where can I test interoperabililty for my implementation? | |||
The arc-discuss list is the best place to stay in touch with work in | There have been numerous interoperability tests during the | |||
progress. | development of the [ARC] specification. These tests are usually | |||
announced on both the arc-discuss mailing list at | ||||
http://lists.dmarc.org/mailman/listinfo/arc-discuss [5], and the | ||||
DMARC working group at https://datatracker/ietf.org/wg/dmarc [6]. | ||||
Join whichever body is most appropriate for you and/or your | ||||
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. | |||
ARC seeks to provide these so-called "indirect mailflows" with a | ARC seeks to provide these so-called "indirect mailflows" with a | |||
skipping to change at page 12, line 43 ¶ | skipping to change at page 14, line 7 ¶ | |||
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, | Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, | |||
September 2011, <https://www.rfc-editor.org/info/rfc6377>. | September 2011, <https://www.rfc-editor.org/info/rfc6377>. | |||
[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>. | |||
7.2. Informative References | 7.2. Informative References | |||
[ARC] Andersen, K., Long, B., Blank, S., Kucherawy, M., and T. | [ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, | |||
Draegen, "Authenticated Received Chain (ARC) Protocol", | "Authenticated Received Chain (ARC) Protocol", December | |||
October 2018, <https://tools.ietf.org/html/ | 2018, <https://tools.ietf.org/html/ | |||
draft-ietf-dmarc-arc-protocol-18>. | draft-ietf-dmarc-arc-protocol-23>. | |||
[ARC-MULTI] | ||||
Andersen, K., Blank, S., and J. Levine, "Using Multiple | ||||
Signing Algorithms with ARC", June 2018, | ||||
<https://tools.ietf.org/html/ | ||||
draft-ietf-dmarc-arc-multi-02>. | ||||
[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/ | <https://tools.ietf.org/html/ | |||
draft-kucherawy-original-authres-00>. | draft-kucherawy-original-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>. | |||
skipping to change at page 13, line 32 ¶ | skipping to change at page 15, line 12 ¶ | |||
(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>. | |||
Appendix A. GLOSSARY | 7.3. URIs | |||
[1] https://datatracker.ietf.org/wg/dcrup/about | ||||
[2] http://arc-spec.org | ||||
[3] http://lists.dmarc.org/mailman/listinfo/arc-discuss | ||||
[4] https://datatracker.ietf.org/wg/dmarc | ||||
[5] http://lists.dmarc.org/mailman/listinfo/arc-discuss | ||||
[6] https://datatracker/ietf.org/wg/dmarc | ||||
[7] mailto:arc-discuss@dmarc.org | ||||
[8] https://datatracker.ietf.org/wg/dmarc | ||||
[9] https://arc-spec.org | ||||
[10] mailto:arc-discuss@dmarc.org | ||||
[11] http://lists.dmarc.org/mailman/listinfo/arc-discuss | ||||
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. | |||
skipping to change at page 16, line 29 ¶ | skipping to change at page 18, line 31 ¶ | |||
Appendix C. Acknowledgements | Appendix C. Acknowledgements | |||
This draft is based on the work of OAR-Dev Group. | This draft 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, Steve Jones, Terry Zink, Tim Draegen. | |||
This document was influenced by questions posed in the arc- | ||||
discuss@dmarc.org [7] mailing list, and the authors thank all the | ||||
list participants for their input. | ||||
Appendix D. Comments and Feedback | Appendix D. Comments and Feedback | |||
Please address all comments, discussions, and questions to the dmarc | Please address all comments, discussions, and questions about this | |||
working group at [https://datatracker.ietf.org/wg/dmarc]. | document, or about [ARC] itself, to the dmarc working group at | |||
https://datatracker.ietf.org/wg/dmarc [8]. | ||||
Authors' Addresses | Readers looking for general information about ARC may refer to the | |||
website https://arc-spec.org [9], or to the arc-discuss@dmarc.org | ||||
[10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- | ||||
discuss [11]. | ||||
Steven Jones (editor) | Authors' Addresses | |||
Steven M Jones (editor) | ||||
DMARC.org | DMARC.org | |||
2419 McGee Avenue | ||||
Berkeley, California 94703 | ||||
USA | ||||
Email: smj@crash.com | Email: smj@crash.com | |||
Kurt Andersen | Kurt Andersen | |||
2029 Stierlin Ct. | 2029 Stierlin Ct. | |||
Mountain View, California 94043 | Mountain View, California 94043 | |||
USA | USA | |||
Email: kurta@linkedin.com | Email: kurta@linkedin.com | |||
John Rae-Grant | ||||
Email: johnrg@google.com | ||||
J. Trent Adams | ||||
Paypal | ||||
Email: trent.adams@paypal.com | ||||
End of changes. 38 change blocks. | ||||
76 lines changed or deleted | 186 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/ |