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
