Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Sat 04/Dec/2021 22:30:30 +0100 Murray S. Kucherawy wrote: On Fri, Dec 3, 2021 at 10:38 AM Todd Herr 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. I'd be happy with either of these two definitions: (a) All messages are subjected to DMARC checking, and "pct" identifies the percentage of messages failing the check that should be subjected to the policy; (b) "pct" identifies the percentage of messages subjected to the DMARC check, irrespective of the outcome. I implemented (a), and don't understand how (b) can make sense given: However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. In order to compile DMARC result into the report one must first evaluate it. Besides, after checking SPF and DKIM, the cost of evaluating DMARC boils down to compare two strings for alignment. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Sat 04/Dec/2021 22:01:50 +0100 Tim Wicinski wrote: On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely wrote: On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
Argh: On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy wrote: > > I'd be happy with either of these two definitions: > > (a) All messages are subjected to DMARC checking, and "pct" identifies the > percentage of messages failing the check that should be subjected to the > policy; > > (b) "pct" identifies the percentage of messages subjected to the DMARC > check, irrespective of the outcome. > > So the dice-roll happens either before you start DMARC, or after you find > a "fail". They're not the same thing, and (again if "pct" stays) we need > to be clear about which one people are expected to implement. > > The original intent, as I recall, was (a). We preferred that because if > you choose early on to exclude the message you're handling, you avoid all > that processing cost. > The clown who said this hit "Send" without proofreading. The original intent was (b), for the reason given. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Fri, Dec 3, 2021 at 10:38 AM Todd Herr wrote: > We can have this conversation too. 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. > > I'd be happy with either of these two definitions: (a) All messages are subjected to DMARC checking, and "pct" identifies the percentage of messages failing the check that should be subjected to the policy; (b) "pct" identifies the percentage of messages subjected to the DMARC check, irrespective of the outcome. So the dice-roll happens either before you start DMARC, or after you find a "fail". They're not the same thing, and (again if "pct" stays) we need to be clear about which one people are expected to implement. The original intent, as I recall, was (a). We preferred that because if you choose early on to exclude the message you're handling, you avoid all that processing cost. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely wrote: > On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: > > On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely > 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. > Ale, While RFC7489 will be obsoleted, it did document several tags which are no longer considered valid. 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. tim > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
It appears that Alessandro Vesely said: >Hi, > >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. Todd is right. We're deprecating the pct tag and adding a new t tag. No new version needed. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely wrote: > Hi, > > 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. I contend that introducing 't' to replace 'pct' is not a change to an existing tag but rather an addition of a new tag. 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. > 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. 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. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
Hi, 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. 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. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
