Thank you. I will review it. On Tue, Jul 13, 2021, 2:10 PM Todd Herr <todd.herr= [email protected]> wrote:
> On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster < > [email protected]> wrote: > >> I understand that under the current specification, PCT has been useful >> because P=NONE with PCT=100 produces different results than QUARANTINE with >> PCT=0. This is an anomaly that I would hope we can fix, but if not, we >> need to specify that the only valid settings are PCT=0 or PCT=100. The >> specification should force numbers between 1 and 99 to be interpreted as >> either 0 or 100. >> >> The current PCT specification is fatally flawed because the denominator >> is undefined and unstable. Suppose that a domain owner concludes that most >> but not all of his traffic will produce DMARC PASS. Should the percentage >> be based on message volume or Source IP counts? Either way, the volume >> distribution received by any single evaluator will be different than the >> volume distribution sent out. >> >> But the larger problem is that the evaluator is performing a conditional >> probability, because the policy is only applied to messages that produce >> DMARC FAIL. If there is no impersonation, an unauthenticated message has >> a 100% probability of being legitimate. The denominator is determined by >> the volume of impersonation messages, not by the volume of legitimate >> messages. The percentage offered by the sending domain owner is useless. >> >> Next, assume that an accurate probability can be determined, and that 80% >> of unauthenticated messages are legitimate and 20% are impersonations. >> Does it make sense to apply that probability rule to >> message disposition? It will produce these results: >> >> Legitimate and DMARC ignored, message accepted = 80%*80% = 64% of total >> >> Legitimate and DMARC enforced, message blocked = 80%*20% = 16% of total >> >> Impersonation and DMARC ignored, message accepted = 20%*80% = 16% of total >> >> Impersonation and DMARC enforced, message blocked = 20%*20% = 4% of total >> >> Therefore, the correct decision is applied only 68% of the time, and the >> wrong decision is applied 32% of the time. This is unsatisfactory for >> protecting against ransomware, and also unsatisfactory for reliably >> delivering wanted messages. >> >> The actual volume of impersonating messages will be determined by the >> spammer, not by the domain owner, so the whole notion of choosing a >> percentage is flawed. The domain owner does not have the information >> needed to provide a usable percentage. The message evaluator can only >> determine the percentage by carefully examining many messages and >> categorizing the source. Once the source is categorized, guessing is no >> longer necessary and the percentage is irrelevant. >> >> >> > I believe you'll find that your ideas, or at least sentiments quite > similar to them, are captured in draft-ietf-dmarc-dmarcbis-02 > > First, draft-ietf-dmarc-dmarcbis-02 makes a small but substantial change > to the definition of the pct tag from what's currently in RFC 7489. Where > RFC 7489 reads: > > pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; > default is 100). Percentage of messages from the Domain Owner's > mail stream to which the DMARC policy is to be applied. > > > draft-ietf-dmarc-dmarcbis-02 instead starts with this text: > > pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; > > default is 100). For the RFC5322.From domain to which the DMARC > > record applies, the "pct" tag is the percentage of messages > > producing a DMARC result of "fail" to which the Domain Owner > wishes its preferred handling policy be applied. > > Since the concept of applying DMARC policy to messages that produce a > DMARC result of "pass" doesn't exist, it doesn't make sense to claim that > "pct" applies to the entire mailstream. > > Next, draft-ietf-dmarc-dmarcbis-02 contains a substantial rewrite of the > Message Sampling section (now section 6.7.4) that goes to great lengths to > attempt to show that the desired pct value really can't be counted on to be > applied as asked for, and what might actually happen could vary widely from > what's desired. > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > > -- > > *Todd Herr* | Technical Director, Standards and Ecosystem > *e:* [email protected] > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
