On Sat 04/Dec/2021 22:01:50 +0100 Tim Wicinski wrote:
On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely <[email protected]> wrote:
On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote:
On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely <[email protected]> wrote:
That's the only part which breaks existing records. According to the last
paragraph of this section, doing so requires v=DMARC2.
I'm not sure I agree with your assertion here. I'm assuming you're
referring to this paragraph:
Note that given the rules of the previous paragraph, addition of a
new tag into the registered list of tags does not itself require a
new version of DMARC to be generated (with a corresponding change to
the "v" tag's value), but a change to any existing tags does require
a new version of DMARC.
Exactly.
I contend that introducing 't' to replace 'pct' is not a change to an
existing tag but rather an addition of a new tag.
In that case, the definition of pct= must still appear in the spec. As
rfc7489 is obsoleted, referencing it makes little sense.
While RFC7489 will be obsoleted, it did document several tags which are no
longer considered valid.
Are they invalid in the sense that Domain Owners should not publish them or
that receivers should ignore them? Invalid and deprecated are different
states. If we deprecate a tag and explain why, we are compatible with the
existing base and may keep the same version.
If the concern is that we will be forcing readers of the new RFC to chase
through old documents to understand what 'pct' tag was defined, Appendix
A.7 explains the pct tag, and its removal. I think that is the right place
to place this info.
The problem is not what pct= means, but how to treat it. I guess there are
only a small number of domains who rely on the effect of pct=, but they exist.
The following was written in August 2021 by a German admin:
we're on the way to more then p=none and
startet with "p=quarantine; pct=10 " more then year ago
March 2021 we set pct=25 and June 2021 pct=50
We review the reports once per month and inverstigate findings
Depending on the current situation we plan to increase pct=
After the last year we got a signifiant amount of attention.
Simply because we identified setups that break our plan.
We offer alternatives, give time for implementation and get positive
feedback.
I'm optimistic to step forward up to pct=99 and finally p=reject.
but not this year
The usual way to deprecate features is to still support them for a good while,
possibly issuing warnings. Instead, the current draft seems to be eliminating
pct= abruptly. That would be a change.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
