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