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

[Todd Herr <[e-mail]>]

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.