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.
--
*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email protected]
*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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc