Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[Dotzero <[e-mail]>]

On Mon, Aug 2, 2021 at 3:49 PM Todd Herr <todd.herr=
[e-mail]> wrote:

>
> On Sat, Jul 31, 2021 at 4:38 PM John Levine <[e-mail]> wrote:
>
>> I'd make it a lot simpler:
>>
>>    pct:  (plain-text integer; OPTIONAL; default is 100).  For the
>>       RFC5322.From domain to which the DMARC record applies, the "pct"
>>       tag describes what receivers are requested to to do with unaligned
>> messages.
>>       This parameter does not affect the generation of DMARC reports.
>> Possible values are as follows:
>>
>>       0:  A request to not apply the policy, but for message forwarders
>>           to do whatever message rewriting they do that is intended to
>> avoid
>>           sending DMARC unaligned mail.
>>
>>       100:  The default, a request to apply the policy as specified.
>>
>>       Any other value: results are undefined.
>>
>>
>> I like simple, but I also like the idea of a separate section that
> discusses the history of the pct tag and why the old values won't work any
> longer.
>
> So, how about this:
>
>    pct:  (plain-text integer; OPTIONAL; default is 100).  For the
>
>       RFC5322.From domain to which the DMARC record applies, the "pct"
>
>       tag serves as a signal to the actor performing DMARC validation
>
>       checks as to whether or not the domain owner wishes the assessment
>
>       policy declared in the "p=" tag to actually be applied.  This
>
>       parameter does not affect the generation of DMARC reports.
>
>       Possible values are as follows:
>
>
>       0:  A request that the actor performing the DMARC validation check
>
>          not apply the policy, but instead apply any special handling
>
>          rules it might have in place.  See Section 6.7.4 for further
>
>          details.
>
>
>       100:  The default, a request to apply the policy as specified to
>
>          any message that produces a DMARC "fail" result.
>
>
> And this:
>
>
> 6.7.4.  History of the "pct" Tag
>
>
>    An earlier experimental version of the DMARC protocol [RFC7489]
>
>    specified all integers from 0 to 100 inclusive as valid values for
>
>    the pct tag.  The intent of the tag was to provide domain owners with
>
>    a method to gradually change their preferred assessment policy (the
>
>    p= tag) from 'none' to 'quarantine' or from 'quarantine' to 'reject'
>
>    by requesting the stricter treatment for just a percentage of
>
>    messages that produced DMARC results of "fail".
>
>
>    Operational experience showed that the pct tag did not function as
>
>    intended due to many factors, and so this version of the DMARC
>
>    protocol has eliminated all possible values save for "100", which
>
>    remains the default, and "0".  The value of "0" took on unintended
>
>    significance during the experimental stage as a value used by some
>
>    intermediaries and mailbox providers as an indicator to either
>
>    deviate from standard handling of the message and/or to alter the
>
>    substance of reports generated, and these "custom" actions proved too
>
>    valuable to the email community to remove from this version of the
>
>    protocol.
>

"6.7.4.  History of the "pct" Tag


   An earlier experimental version of the DMARC protocol [RFC7489]..."


RFC7489 is Informational, not experimental. In IETF nomenclature,
experimental status has a specific meaning.


Michael Hammer