Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99

[Douglas Foster <[e-mail]>]

Thank you.   I will review it.

On Tue, Jul 13, 2021, 2:10 PM Todd Herr <todd.herr=
[e-mail]> wrote:

> On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster <
> [e-mail]> 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:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>