On Sat, Jul 31, 2021 at 4:38 PM John Levine <jo...@taugh.com> 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.




-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to