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

[Douglas Foster <[e-mail]>]

Todd, the new language has addressed my concerns about PCT.

As a message evaluator, PCT is an unreasonable request.   If I follow the
requested approach, it pretty much guarantees that I will block wanted
messages and allow unwanted messages.    I don't want to explain to a
C-level executive that a message was mishandled because "the random number
generator told me to do it."

PCT is also a significant data collection effort.   That collection effort
may represent a significant processing load, since every
non-authenticated record requires looking back over all received messages
in a chosen time period.   Obviously, that algorithm can be tuned, but the
tuning process is costly in time, labor, and stability risk.

I suppose that the issue here is that domain owners are concerned about the
message recipients who never send RUA reports.   Once enforcement is turned
on, SMTP reject and non-delivery reports provide feedback from more sources
(any source that does not discard silently).   The domain owner is unlikely
to get non-delivery reports from spam sources, so any notification about
messages that are blocked for DMARC-related reasons will be indications of
legitimate messages that were handled contrary to domain owner
preferences.   I understand the concern, I just don't see it as compatible
with my own security needs.

A partial solution lies in my proposal for an intermediate enforcement
option.   This option should be called "relaxed" mode, for consistency with
other standards.     The domain owner chooses whether
- SPF policy record is required in DNS,
- DKIM public key is required in DNS,
- From "existence" indicator is required in DNS, or
a domain-owner ARC Set is required in the message.
These are independently selectable enforcements; and they provide a domain
owner the opportunity to get reject and NDR information on a limited scale,
based on the feature selected and the weak nature of the test.

Domain owners who want to tolerate mailing list messages will stay in
relaxed mode permanently, and it provides more security than P=NONE.
Domain owners that want to block mailing list messages would eventually
switch to "strict", which is the same as our current P=REJECT.

Doug Foster




On Tue, Jul 13, 2021 at 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
>