On Mon, Aug 2, 2021 at 3:49 PM Todd Herr <todd.herr= [email protected]> wrote:
> > On Sat, Jul 31, 2021 at 4:38 PM John Levine <[email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
