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:
last message for today: the "t" tag instead of "pct".
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.
I never used it, so it doesn't hurt me if it's discouraged. However, I suggest
we take a better survey on the subject, and possibly add to Appendix A7 a
paragraph suggesting how to proceed to those who now have records with pct=x
and 0 < x < 100.
If you're contending that removing 'pct' is a change to 'pct', we can have
that conversation, but I don't know that I'd agree with that contention
either. There are other tags, namely 'rf' and 'ri', for which removal has
been proposed and I've not heard anyone contend that either of those
removals would constitute a change requiring a new version.
Formally, you're right. However, rf= and ri= never had a real effect on the
behavior of DMARC software. For ri, I still think it might be possible for a
report producer to increase the reporting frequency in order to match the
maximum size. However, I never heard about frequencies other than 1/24h.
Given also that we discovered use cases that were not considered during
the hasty discussion that resulted in the decision to change tags, cases
where pct=x with 0 < x < 100 is used as a press, gradually increasing x in
order to urge various departments to comply, exactly as specified in
DMARC1, I appeal to revert that decision. >
We can have this conversation too.
Yes please,
I will promise, however, that if the group decides to keep 'pct', I will
absolutely insist that the first sentence in its definition be changed.
Somehow, RFC 7489 got released with this text: >
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL;
default is 100). Percentage of messages from the Domain Owner's
mail stream to which the DMARC policy is to be applied.
And I will go to my grave stating that DMARC policies cannot be applied to
messages that pass DMARC authentication checks, and the definitions of
'quarantine' and 'reject' explicitly refer to messages that fail DMARC
authentication checks.
The sentence should read something like this:
Percentage of messages using the Domain Owner's domain and failing DMARC
authentication checks to which the DMARC policy is to be applied.
That's fine, it doesn't change the substance. You're right that to make sense
of the former definition one has to consider the somewhat metaphysical concept
of applying a policy to messages that pass DMARC authentication. So your
definition is better. Correspondingly, the example should be changed like so:
if verification fails then
if (random mod 100) < pct then
apply policy
BTW, I plotted a couple of graphs based on binomial calculations like yours:
https://en.wikipedia.org/wiki/Bernoulli_sampling#Example
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
