Since as long as the pct is not zero, any message can have the policy applied, I don't think this is a substantiative compatibility break that warrants a version bump. A version bump effectively translates to 'this is a new protocol with zero deployment', which is not what this group is chartered to do.
If the consensus is that dropping pct requires a version bump, then I think the correct solution is to not bump the version and add pct back to the specification. Scott K On February 23, 2023 7:18:11 PM UTC, Emil Gustafsson <emgu=40google....@dmarc.ietf.org> wrote: >I recognize that the changes in DMARCbis without also changing v=2 are >possible and don't cause a security problem as ignoring "pct" when parsers >are updated should result in the more restricive policy being applied. >I think however there is a practical problem. As a mailbox provider I would >not want to just switch parsers but will need to examine the DMARC record >and actually support both pct and t for backward compatibility just in >order to not change the behavior overnight for our users. > >I also noticed by looking at some recent data in our logs that there is a >significant number of emails received with p=quarantine or p=reject where >the pct value that is neither 0 nor 100 (so not 1:1 compatible with t). > >I think having DMARCbis actually changing the version would simplify and >keep the interpretation of DMARC records consistent. > >What do you think? >/E _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
