On Tue, Aug 3, 2021 at 8:22 AM Barry Leiba <[email protected]> wrote:
> The problem I have with leaving pct=0 in as the only (non-default) value
> is that it locks history into the protocol. It makes no sense to have a
> binary situation specified by a tag called “pct” that is either 0 or 100.
>
> If we’re leaving this in as a binary thing, (1) we’re already incompatible
> with deployments that do pct=20 or whatever, so (2) we might better make it
> a y/n or t/f valued tag for that function, deprecate pct entirely, and
> leave text in a backward-compatibility section explaining what happened.
>
> I just think that the pct= 0 or 100 thing won’t wear well and will appear
> tattered quickly.
>
>
I don't disagree with you here, Barry, so let me propose this.
1. Eliminate the 'pct' tag entirely. Section 6.3, General Record Format,
says "unknown tags MUST be ignored." so we're covered on the compatibility
issue, I think.
2. Define a tag named "t", in a fashion somewhat similar to the t= tag
available for DKIM public key records, as follows:
t: DMARC policy test mode (plain-text; OPTIONAL; default is 'n').
For the RFC5322.From domain to which the DMARC record applies, the
"t" 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:
y: 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. The domain owner is currently
testing its specified DMARC assessment policy.
n: The default, a request to apply the policy as specified to any
message that produces a DMARC "fail" result.
3. Include the following as an Appendix:
Appendix C. History of the "pct" Tag
An earlier informational version of the DMARC protocol [RFC7489]
included a "pct" tag and specified all integers from 0 to 100
inclusive as valid values for the 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, unless the value specified was either
"0" or "100" (the default). The default value was easily
implemented, as it required no special processing on the part of the
message receiver, while the value of "0" took on unintended
significance as a value used by some intermediaries and mailbox
providers as an indicator to deviate from standard handling of the
message.
These "custom" actions proved too valuable to the email community to
remove their availability from this version of the protocol, but at
the same time it didn't make sense to support a tag named "pct" that
had only two valid values. This version of the DMARC protocol
therefore introduces the "t" tag as shorthand for "testing", with the
valid values of "y" and "n", which should be analogous to the "pct"
tag values "0" and "100", respectively.
--
*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
