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
