I objected strongly to the RFC 7489 language which provides disposition instructions based on the PCT clause, and still do. A brief review: There are many percentages mixed up together in this issue:
- The percentage of domain message sources which provide proper authentication at origination. - The percentage of domain messages which originate with proper authentication. This is determined by the volume distribution between sources, which is likely to be variable. - The percentage of domain messages which are received with authentication. This will be different for each evaluator, depending on the sources from which those messages originate. This is also affected by transit issues. But none of those percentages actually matter. The one that matters to the evaluator is: - The conditional probability that an unauthenticated message is actually from the domain and not from an impersonator. For this test, the denominator depends on the volume of impersonation messages, which is completely independent of the domain's message volumes. And finally, even if this last percentage could be determined, the advice is wrong. If this percentage is the determining factor for allow or block, the error-minimizing strategy is to either accept all, if the legitimate percentage is high, or block all, if the legitimate percentage is low. The boundary between the two strategies depends on the relative weight given to allow errors and block errors. If the weighting is equal, the breakpoint is 50%. In RFC 7489, we have a domain-provided percentage whose calculation is left undefined. Whatever the calculation, the result has little relevance to the evaluator's risk assessment. It is actually harmful to advise evaluators to disposition using the sender's percentage and a random number generator. The WG observed that some forwarders and some evaluators behave differently between "p=none pct=100" and "p=quarantine pct=0". The "t=" clause was introduced to provide that distinction. I don't object to leaving the PCT clause in place as a historical relic, but we should repudiate the idea that the evaluator obtains valuable guidance from it. Doug Foster On Fri, Sep 8, 2023 at 7:46 AM Alessandro Vesely <ves...@tana.it> wrote: > On Thu 07/Sep/2023 18:28:59 +0200 Wei Chuang wrote: > > > > Regarding the languages in section 8.6 "It is therefore critical that > domains > > that host users who might post messages to mailing lists SHOULD NOT > publish > > p=reject. Domains that choose to publish p=reject SHOULD implement > policies > > that their users not post to Internet mailing lists", we wanted to point > out > > that this is impossible to implement. Many enterprises already have > "p=reject" > > policies. Presumably those domains were subject to some sort of > spoofing which > > is why they went to such a strict policy. It would be unreasonable to > tell > > them to stop posting to mailing lists as many likely already use mailing > list > > services and will want to continue to use them. The one thing that > makes this > > tractable is the SHOULD language as we may choose not to not follow this > aspect > > of the specification. Our suggestion is that there is not a lot of > value in > > including this language in the bis document if the likely outcome is > that it > > will be ignored, and rather more effort should be placed with a > technical > > solution for interop with mailing lists. > > > There is an "until the authentication ecosystem becomes more mature and > deliverability issues are better resolved." Some sites may consider that > the > mailing lists in their particular niche already solved the problem. The > (temporary?) alternative is to use different domains, at the cost of > reviewing > all subscriptions... > > > > We question the benefit versus the implementation effort and confusion > of > > deprecating the DMARC policy "pct" percentage mode and replacing it with > "t" > > test. We do agree that there is benefit in having receivers support a > debug > > mode to enable DMARC deployment and that the test mode supports the most > useful > > use case for testing with indirect mailflow behavior. However "pct" > > represents a sunk cost and implementing test mode seems redundant to the > > already existing "pct" percentage mode. Moreover both modes will likely > need > > to be supported for a while. We do see senders use "pct" ratcheting and > it > > will be confusing to them when at some point they will have to switch. > > > +1, there are sites actually using pct=, however few. I appeal to the WG > to > reconsider this decision. Removing it is a gratuitous incompatibility. > > > 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
