+1 to Scott's suggestion. Michael Hammer
On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba <barryle...@computer.org> wrote: > I’m happy with Scott’s suggestion. > > Barry > > On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman <skl...@kitterman.com> > 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 >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
