Ale, I understand your concern but I don't know that it can be solved. My core objection is the partial-enforcement algorithm. I cannot believe that it would be wise for me, or any other receiver, to implement that algorithm. However, DMARCv1 was written with a presumed requirement for participating recipients to follow that algorithm.
Given my expectations around actual recipient behavior, it seems unreasonable to tell domain owners to expect a different set of behaviors than what will actually occur. I do not want to mislead. During evaluation, my practice will be to treat any value other than 100 as equal to zero, because it means that the sender does not have enough confidence in his situation to be able to provide me with useful information. It does not mean that I will ignore the sender authentication failure. In the face of ambiguity, the only way to get a correct disposition is to collect more data. If I had more time, I would quarantine all unauthenticated mail until I could determine whether the sender should be authenticated by local policy or blacklisted by local policy. In practice, I quarantine some messages and let some messages through, then periodically go back and adjust my policies after reviewing actual message details. Doug Foster On Sat, Jul 31, 2021 at 5:40 AM Alessandro Vesely <ves...@tana.it> wrote: > On Fri 30/Jul/2021 22:06:39 +0200 Todd Herr wrote: > > Following on to the recent discussion about the pct tag, and > specifically the > > disallowing of any values other than 0 and 100, I propose the following > text > > and look forward to your comments: > > > I still dislike this limitation. I previously showed that users seem to > change > pct= with some salt. In addition, how should implementations amend their > code? > What shall a receiver do if it finds intermediate values of pct? > > I'd keep allowing intermediate values. Substitute /Possible values are as > follows:/ with /RECOMMENDED values are as follows:/. > > For case 0: > > YOUR TEXT: > 0: A request that zero percent of messages producing a DMARC > "fail" result have the specified policy applied. While this is > seemingly a non-sensical request, this value has been given > special meaning by some mailbox providers and intermediaries > when combined with "p=" values other than "none". In those > cases, in can result in changes to message handling, and/or > DMARC reporting for the domain publishing such a policy. In > some instances of altered reporting, it is possible that the > altered reports may reveal intermediaries whose handling of the > domain owners' mail could cause it to produce a DMARC result of > "fail" when it reaches its final destination. > > MY PROPOSED ALTERNATIVE: > 0: A request that messages producing a DMARC "fail" result never > have the specified policy applied. The special meaning of > this value is to have mailing lists which discriminate message > handling by author's domain policy apply From: munging > (see [Section X.Y.Z]) while final receivers still apply no > policy. > > > Best > Ale > -- > > > > > > > > > > > > > > > _______________________________________________ > 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
