Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
+1, but the concern of not informing suspicious parties about local policies should then be risen in aggregate-reporting, Security Considerations (currently blank), shouldn't it? The current wording makes an attempt to distinguish overrides due to authentication failures, such as mailing list, from reject or quarantine decisions made /after/ dmarc=pass, such as obvious spam. The latter are not to be reported, and the action disposition left to none in those cases. Indeed, that is what a DMARC filter actually knows. Best Ale On Sun 28/Aug/2022 15:08:51 +0200 Dotzero wrote: +1 to Scott's suggestion. Michael Hammer On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba wrote: I’m happy with Scott’s suggestion. Barry On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman wrote: On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote: On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: I think “SHOULD do what the domain owner says” is too strong, and propose to change it. By making it that strong we vary from the policy that recipients use all the input they have to make their handling decision, and we tell them that using this input alone is normatively required for interoperability/security. I think that’s wrong. I suggest this alternative text: NEW A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy when a message fails the DMARC test, and uses it as an important factor in deciding how to handle the message. I agree that blindly following the remote policy is a hazard. (Personally, I enable that on a restricted set of domains only.) However, the above text is too generic and slightly inexact. You actually get the policy /before/ concluding the evaluation. DMARC result is an important factor also if it is a pass or a none. The above snippet can be skipped. The above snippet is just a slight change to what was already there, and I think it's useful to keep it... but I think I did change the sense of it when I rephrased it. In the original, "when a message fails the DMARC test" was attached to the action that the receiver should take. In mine, that attachment is lost. Maybe this rewording works better?: NEW-2 A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy and uses it as an important factor in deciding how to handle the message. When a message fails the DMARC test, Mail Receivers should make a best-effort attempt to comply with the published policy, but email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.) and Mail Receivers may have other information that can inform their decisions. When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [DMARC-Aggregate-Reporting]. END I think that retains the connection that I lost in the first attempt. In this part of the document, I think the phrase "best-effort" is a problem. A "best-effort" to comply with the policy is pretty trivial to do: if it fails and the policy is reject, then reject. That's not actually what we want. This section is a non-normative paraphrase of part of Section 5.8. I think it would be better to shorten it and reference Section 5.8. Also, this says SHOULD use PolicyOverride. Section 5.8 currently discourages it. We ought to decide if we want to discourage or encourage reporting of policy overrides. I think encourage is the right answer. Based on that approach, I'd suggest the following changes: In place of the above: NEW-3 A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy and uses it as an important factor in deciding how to handle the message. Mail handling considerations based on DMARC policy enforcement are discussed below in [section-5.8]. END And this additional change in Section 5.8: Replace: Mail Receivers should only report reject or quarantine policy actions in aggregate feedback reports that are due to published DMARC Domain Owner Assessment Policy. They need not report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns. with: When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
+1 to Scott's suggestion. Michael Hammer On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba wrote: > I’m happy with Scott’s suggestion. > > Barry > > On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman > wrote: > >> On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote: >> > > On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: >> > > > I think “SHOULD do what the domain owner says” is too strong, and >> > > > propose to change it. By making it that strong we vary from the >> > > > policy that recipients use all the input they have to make their >> > > > handling decision, and we tell them that using this input alone is >> > > > normatively required for interoperability/security. I think that’s >> > > > wrong. >> > > > >> > > > I suggest this alternative text: >> > > > >> > > > NEW >> > > > >> > > > A Mail Receiver implementing the DMARC mechanism gets the Domain >> > > > Owner’s or PSO's published DMARC Domain Owner Assessment Policy >> > > > when a message fails the DMARC test, and uses it as an important >> > > > factor in deciding how to handle the message. >> > > >> > > I agree that blindly following the remote policy is a hazard. >> > > (Personally, >> > > I enable that on a restricted set of domains only.) However, the >> above >> > > text is too generic and slightly inexact. You actually get the policy >> > > /before/ concluding the evaluation. DMARC result is an important >> factor >> > > also if it is a pass or a none. >> > > >> > > The above snippet can be skipped. >> > >> > The above snippet is just a slight change to what was already there, >> > and I think it's useful to keep it... but I think I did change the >> > sense of it when I rephrased it. In the original, "when a message >> > fails the DMARC test" was attached to the action that the receiver >> > should take. In mine, that attachment is lost. >> > >> > Maybe this rewording works better?: >> > >> > NEW-2 >> >A Mail Receiver implementing the DMARC mechanism gets the >> >Domain Owner’s or PSO's published DMARC Domain Owner Assessment >> >Policy and uses it as an important factor in deciding how to >> >handle the message. When a message fails the DMARC test, Mail >> >Receivers should make a best-effort attempt to comply with the >> >published policy, but email streams can be complicated (due to >> >forwarding, existing RFC5322.From domain-spoofing services, >> >etc.) and Mail Receivers may have other information that can >> >inform their decisions. >> > >> >When Mail Receivers deviate from a published Domain Owner >> >Assessment Policy during message processing they SHOULD make >> >available the fact of and reason for the deviation to the Domain >> >Owner via feedback reporting, specifically using the >> >"PolicyOverride" feature of the aggregate report defined in >> >[DMARC-Aggregate-Reporting]. >> > END >> > >> > I think that retains the connection that I lost in the first attempt. >> >> In this part of the document, I think the phrase "best-effort" is a >> problem. >> A "best-effort" to comply with the policy is pretty trivial to do: if it >> fails >> and the policy is reject, then reject. That's not actually what we >> want. >> This section is a non-normative paraphrase of part of Section 5.8. I >> think it >> would be better to shorten it and reference Section 5.8. Also, this says >> SHOULD use PolicyOverride. Section 5.8 currently discourages it. >> >> We ought to decide if we want to discourage or encourage reporting of >> policy >> overrides. I think encourage is the right answer. Based on that >> approach, >> I'd suggest the following changes: >> >> In place of the above: >> >> > NEW-3 >> >A Mail Receiver implementing the DMARC mechanism gets the >> >Domain Owner’s or PSO's published DMARC Domain Owner Assessment >> >Policy and uses it as an important factor in deciding how to >> >handle the message. Mail handling considerations based on DMARC >> >policy enforcement are discussed below in [section-5.8]. >> >> > END >> >> And this additional change in Section 5.8: >> >> Replace: >> >> >Mail Receivers should only report reject or quarantine policy actions >> >in aggregate feedback reports that are due to published DMARC Domain >> >Owner Assessment Policy. They need not report reject or quarantine >> >actions that are the result of local policy. If local policy >> >information is exposed, abusers can gain insight into the >> >effectiveness and delivery rates of spam campaigns. >> >> with: >> >> >When Mail Receivers deviate from a published Domain Owner >> >Assessment Policy during message processing they SHOULD make >> >available the fact of and reason for the deviation to the Domain >> >Owner via feedback reporting, specifically using the >> >"PolicyOverride" feature of the aggregate report defined in >> >[DMARC-Aggregate-Reporting]. >> >> I think this reduces
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
I’m happy with Scott’s suggestion. Barry On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman wrote: > On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote: > > > On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: > > > > I think “SHOULD do what the domain owner says” is too strong, and > > > > propose to change it. By making it that strong we vary from the > > > > policy that recipients use all the input they have to make their > > > > handling decision, and we tell them that using this input alone is > > > > normatively required for interoperability/security. I think that’s > > > > wrong. > > > > > > > > I suggest this alternative text: > > > > > > > > NEW > > > > > > > > A Mail Receiver implementing the DMARC mechanism gets the Domain > > > > Owner’s or PSO's published DMARC Domain Owner Assessment Policy > > > > when a message fails the DMARC test, and uses it as an important > > > > factor in deciding how to handle the message. > > > > > > I agree that blindly following the remote policy is a hazard. > > > (Personally, > > > I enable that on a restricted set of domains only.) However, the above > > > text is too generic and slightly inexact. You actually get the policy > > > /before/ concluding the evaluation. DMARC result is an important > factor > > > also if it is a pass or a none. > > > > > > The above snippet can be skipped. > > > > The above snippet is just a slight change to what was already there, > > and I think it's useful to keep it... but I think I did change the > > sense of it when I rephrased it. In the original, "when a message > > fails the DMARC test" was attached to the action that the receiver > > should take. In mine, that attachment is lost. > > > > Maybe this rewording works better?: > > > > NEW-2 > >A Mail Receiver implementing the DMARC mechanism gets the > >Domain Owner’s or PSO's published DMARC Domain Owner Assessment > >Policy and uses it as an important factor in deciding how to > >handle the message. When a message fails the DMARC test, Mail > >Receivers should make a best-effort attempt to comply with the > >published policy, but email streams can be complicated (due to > >forwarding, existing RFC5322.From domain-spoofing services, > >etc.) and Mail Receivers may have other information that can > >inform their decisions. > > > >When Mail Receivers deviate from a published Domain Owner > >Assessment Policy during message processing they SHOULD make > >available the fact of and reason for the deviation to the Domain > >Owner via feedback reporting, specifically using the > >"PolicyOverride" feature of the aggregate report defined in > >[DMARC-Aggregate-Reporting]. > > END > > > > I think that retains the connection that I lost in the first attempt. > > In this part of the document, I think the phrase "best-effort" is a > problem. > A "best-effort" to comply with the policy is pretty trivial to do: if it > fails > and the policy is reject, then reject. That's not actually what we want. > This section is a non-normative paraphrase of part of Section 5.8. I > think it > would be better to shorten it and reference Section 5.8. Also, this says > SHOULD use PolicyOverride. Section 5.8 currently discourages it. > > We ought to decide if we want to discourage or encourage reporting of > policy > overrides. I think encourage is the right answer. Based on that > approach, > I'd suggest the following changes: > > In place of the above: > > > NEW-3 > >A Mail Receiver implementing the DMARC mechanism gets the > >Domain Owner’s or PSO's published DMARC Domain Owner Assessment > >Policy and uses it as an important factor in deciding how to > >handle the message. Mail handling considerations based on DMARC > >policy enforcement are discussed below in [section-5.8]. > > > END > > And this additional change in Section 5.8: > > Replace: > > >Mail Receivers should only report reject or quarantine policy actions > >in aggregate feedback reports that are due to published DMARC Domain > >Owner Assessment Policy. They need not report reject or quarantine > >actions that are the result of local policy. If local policy > >information is exposed, abusers can gain insight into the > >effectiveness and delivery rates of spam campaigns. > > with: > > >When Mail Receivers deviate from a published Domain Owner > >Assessment Policy during message processing they SHOULD make > >available the fact of and reason for the deviation to the Domain > >Owner via feedback reporting, specifically using the > >"PolicyOverride" feature of the aggregate report defined in > >[DMARC-Aggregate-Reporting]. > > I think this reduces duplication and inconsistency without losing > anything. > the proposed new text in 5.8 is a direct move of the proposed Section 5 > text > on including feedback based on local policy overrides. > > Scott K > > >
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote: > > On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: > > > I think “SHOULD do what the domain owner says” is too strong, and > > > propose to change it. By making it that strong we vary from the > > > policy that recipients use all the input they have to make their > > > handling decision, and we tell them that using this input alone is > > > normatively required for interoperability/security. I think that’s > > > wrong. > > > > > > I suggest this alternative text: > > > > > > NEW > > > > > > A Mail Receiver implementing the DMARC mechanism gets the Domain > > > Owner’s or PSO's published DMARC Domain Owner Assessment Policy > > > when a message fails the DMARC test, and uses it as an important > > > factor in deciding how to handle the message. > > > > I agree that blindly following the remote policy is a hazard. > > (Personally, > > I enable that on a restricted set of domains only.) However, the above > > text is too generic and slightly inexact. You actually get the policy > > /before/ concluding the evaluation. DMARC result is an important factor > > also if it is a pass or a none. > > > > The above snippet can be skipped. > > The above snippet is just a slight change to what was already there, > and I think it's useful to keep it... but I think I did change the > sense of it when I rephrased it. In the original, "when a message > fails the DMARC test" was attached to the action that the receiver > should take. In mine, that attachment is lost. > > Maybe this rewording works better?: > > NEW-2 >A Mail Receiver implementing the DMARC mechanism gets the >Domain Owner’s or PSO's published DMARC Domain Owner Assessment >Policy and uses it as an important factor in deciding how to >handle the message. When a message fails the DMARC test, Mail >Receivers should make a best-effort attempt to comply with the >published policy, but email streams can be complicated (due to >forwarding, existing RFC5322.From domain-spoofing services, >etc.) and Mail Receivers may have other information that can >inform their decisions. > >When Mail Receivers deviate from a published Domain Owner >Assessment Policy during message processing they SHOULD make >available the fact of and reason for the deviation to the Domain >Owner via feedback reporting, specifically using the >"PolicyOverride" feature of the aggregate report defined in >[DMARC-Aggregate-Reporting]. > END > > I think that retains the connection that I lost in the first attempt. In this part of the document, I think the phrase "best-effort" is a problem. A "best-effort" to comply with the policy is pretty trivial to do: if it fails and the policy is reject, then reject. That's not actually what we want. This section is a non-normative paraphrase of part of Section 5.8. I think it would be better to shorten it and reference Section 5.8. Also, this says SHOULD use PolicyOverride. Section 5.8 currently discourages it. We ought to decide if we want to discourage or encourage reporting of policy overrides. I think encourage is the right answer. Based on that approach, I'd suggest the following changes: In place of the above: > NEW-3 >A Mail Receiver implementing the DMARC mechanism gets the >Domain Owner’s or PSO's published DMARC Domain Owner Assessment >Policy and uses it as an important factor in deciding how to >handle the message. Mail handling considerations based on DMARC >policy enforcement are discussed below in [section-5.8]. > END And this additional change in Section 5.8: Replace: >Mail Receivers should only report reject or quarantine policy actions >in aggregate feedback reports that are due to published DMARC Domain >Owner Assessment Policy. They need not report reject or quarantine >actions that are the result of local policy. If local policy >information is exposed, abusers can gain insight into the >effectiveness and delivery rates of spam campaigns. with: >When Mail Receivers deviate from a published Domain Owner >Assessment Policy during message processing they SHOULD make >available the fact of and reason for the deviation to the Domain >Owner via feedback reporting, specifically using the >"PolicyOverride" feature of the aggregate report defined in >[DMARC-Aggregate-Reporting]. I think this reduces duplication and inconsistency without losing anything. the proposed new text in 5.8 is a direct move of the proposed Section 5 text on including feedback based on local policy overrides. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
On Thu 25/Aug/2022 19:43:49 +0200 Barry Leiba wrote: Maybe this rewording works better?: Yes, it does! NEW-2 A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy and uses it as an important factor in deciding how to handle the message. When a message fails the DMARC test, Mail Receivers should make a best-effort attempt to comply with the published policy, but email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.) and Mail Receivers may have other information that can inform their decisions. When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [DMARC-Aggregate-Reporting]. END I think that retains the connection that I lost in the first attempt. Yup. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
> On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: > > > > I think “SHOULD do what the domain owner says” is too strong, and > > propose to change it. By making it that strong we vary from the > > policy that recipients use all the input they have to make their > > handling decision, and we tell them that using this input alone is > > normatively required for interoperability/security. I think that’s > > wrong. > > > > I suggest this alternative text: > > > > NEW > > A Mail Receiver implementing the DMARC mechanism gets the Domain > > Owner’s or PSO's published DMARC Domain Owner Assessment Policy > > when a message fails the DMARC test, and uses it as an important > > factor in deciding how to handle the message. > > > I agree that blindly following the remote policy is a hazard. (Personally, > I enable that on a restricted set of domains only.) However, the above > text is too generic and slightly inexact. You actually get the policy > /before/ concluding the evaluation. DMARC result is an important factor > also if it is a pass or a none. > > The above snippet can be skipped. The above snippet is just a slight change to what was already there, and I think it's useful to keep it... but I think I did change the sense of it when I rephrased it. In the original, "when a message fails the DMARC test" was attached to the action that the receiver should take. In mine, that attachment is lost. Maybe this rewording works better?: NEW-2 A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy and uses it as an important factor in deciding how to handle the message. When a message fails the DMARC test, Mail Receivers should make a best-effort attempt to comply with the published policy, but email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.) and Mail Receivers may have other information that can inform their decisions. When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [DMARC-Aggregate-Reporting]. END I think that retains the connection that I lost in the first attempt. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5
On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote: I think “SHOULD do what the domain owner says” is too strong, and propose to change it. By making it that strong we vary from the policy that recipients use all the input they have to make their handling decision, and we tell them that using this input alone is normatively required for interoperability/security. I think that’s wrong. I suggest this alternative text: NEW A Mail Receiver implementing the DMARC mechanism gets the Domain Owner’s or PSO's published DMARC Domain Owner Assessment Policy when a message fails the DMARC test, and uses it as an important factor in deciding how to handle the message. I agree that blindly following the remote policy is a hazard. (Personally, I enable that on a restricted set of domains only.) However, the above text is too generic and slightly inexact. You actually get the policy /before/ concluding the evaluation. DMARC result is an important factor also if it is a pass or a none. The above snippet can be skipped. Mail Receivers should make a best-effort attempt to comply with the published policy, but email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.) and Mail Receivers may have other information that can inform their decisions. Agree to non-2119 expression. When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [DMARC-Aggregate-Reporting]. END Fine. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
