Subject: Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jun 2021 20:45:33 -0700

I don't understand what "demeaning a domain's policy" means.

On Fri, May 28, 2021 at 10:20 AM Alessandro Vesely <[email-masked]> wrote:

> On Fri 28/May/2021 17:43:37 +0200 Todd Herr wrote:
> >
> > Consensus on Ticket #47 <https://trac.ietf.org/trac/dmarc/ticket/47>
> (Removal
> > of "pct" tag) was reached during the May 27 DMARC Interim to keep the
> tag, but
> > to rewrite its definition in whole or in part to make its usage better
> understood.
>
>
> I think the text in RFC 7489 is quite good.  Perhaps a word could be added
> for
> pct=0; for example:
>
> OLD
>     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.  However,
>        this MUST NOT be applied to the DMARC-generated reports, all of
>        which must be sent and received unhindered.  The purpose of the
>        "pct" tag is to allow Domain Owners to enact a slow rollout
>        enforcement of the DMARC mechanism.  The prospect of "all or
>        nothing" is recognized as preventing many organizations from
>        experimenting with strong authentication-based mechanisms.  See
>        Section 6.6.4 for details.  Note that random selection based on
>        this percentage, such as the following pseudocode, is adequate:
>
>         if (random mod 100) < pct then
>           selected = true
>         else
>           selected = false
>
> NEW
>     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.  However,
>        this MUST NOT be applied to any other use, such as skipping DMARC
>        reports or demeaning a domain's policy.  The purpose of the
>        "pct" tag is to allow Domain Owners to enact a slow rollout
>        enforcement of the DMARC mechanism.  Using this tag, organizations
>        can experiment with strong authentication-based mechanisms while
>        lowering or even voiding the risk of non-delivery.  See Section
> 6.6.4
>        for details.  Note that random selection based on this percentage,
>        such as the following pseudocode, is adequate:
>
>         if (random mod 100) < pct then
>           selected = true
>         else
>           selected = false
>
> jm2c
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 3 Jun 2021 13:07:34 +0200

> I don't understand what "demeaning a domain's policy" means.

I meant to say that p=quarantine; pct=0 is to be considered a strict policy to 
all effects.  Saying so should prevent reasoning something like "Oh, they said 
quarantine, but since pct=0 it is somewhat faked, so I'll skip X", where X 
could be rewriting From:, displaying a BIMI image, record aggregate data, or 
any other action that might depend on the policy.  That is to say pct=0 does 
not alter the value of p=, otherwise testing becomes a nightmare.

Perhaps my point would be obvious if the protocol allowed floating point 
values.  Setting pct=1e-37 would have effects equivalent to pct=0, and setting 
a boundary somewhere to distinguish what is valid from what is not would show 
up all of its arbitrariness.

Best
Ale
-- 

>>> (Removal of "pct" tag) was reached during the May 27 DMARC Interim to
>>> keep the tag, but to rewrite its definition in whole or in part to make
>>> its usage better understood. >>
>>
>> for pct=0; for example:

---

From: "John Levine" <[email-masked]>
Date: 3 Jun 2021 18:17:36 -0400

>not alter the value of p=, otherwise testing becomes a nightmare.

If we agree that's what we mean, that's what we should say, e.g., add something
like this:

 Senders may use pct=0 to signal an intention to apply a stricter
 DMARC policy in the future, and to request receivers that do special
 processing based on DMARC policy to do that processing. Examples of
 special processing might include mailing list software rewriting
 addresses in From headers.

---

From: Dotzero <[email-masked]>
Date: Thu, 3 Jun 2021 19:16:26 -0400

>  addresses in From headers.

As long as we get the wording right, I agree with your line of thinking
John. Again, we don't have insight as to the extent that receivers will
honor the request.

Michael Hammer

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 4 Jun 2021 15:59:33 -0400

+1 With Mr Levine's line of thinking.

I also agree with keeping pct= tag.

tim

---

From: Todd Herr <[email-masked]>
Date: Thu, 17 Jun 2021 09:38:02 -0400

I have closed the subject ticket and incorporated relevant text
changes in draft-ietf-dmarc-dmarcbis-02,
which will be published on Datatracker as soon as the chairs have a chance
to do so.

The relevant text changes here include clarification of the meaning of the
pct tag as well as a much longer discussion of message sampling and the
limitations inherent in the application of the pct tag.

The text changes all fall under the umbrella of "proposed text", and I
expect there will be further discussion of the topic.

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*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.