Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Saturday, July 16, 2022 7:16:12 AM EDT Alessandro Vesely wrote: > On Fri 15/Jul/2022 18:03:36 +0200 John Levine wrote: > > On Fri, 15 Jul 2022, Alessandro Vesely wrote: > >> Organizational Domains are defined as PSD+1, and can have DMARC records > > > > I think this would be a good time to review the way relaxed alignment > > works in sections 4.5 through 4.8 of the draft. > > I think this statement in 4.8 is inexact: > > OLD: > If this process does not determine the Organizational Domain, then > the initial target domain is the Organizational Domain. > > NEW: > If this process does not determine the Organizational Domain, then > the initial target domain is the Organizational Domain, unless it > is a PSD. > > > Indeed, since we said an org domain is PSD+1, a PSD cannot be an org > domain. OTOH, you can happen to start the process with a PSD. > > Perhaps we should take a position of treating a domain as if it were > an org domain albeit it isn't, for uk.com and similar? I think the proposed change is incorrect. To pick a real example, gov.uk is a PSD with a DMARC record. It's one that I expect will add psd=y once the tag is assigned. There is no benefit from preventing gov.uk from sending mail and having it pass DMARC. We have discussed this concept before. With the draft as it stands, even if gov.uk had psd=y in its DMARC record, if the 5322.From, 5321.MailFrom, and DKIM d= were all gov.uk, uk.gov would be the organizational domain. With your change there would be no organizational domain determined and so nothing would align. Why would we want to do that? > > Perhaps 0.01% of the time, a tree walk will find a record with a psd > > tag. The other 99.99% of the time it's the shortest name with a DMARC > > record, and PSDs are completely irrelevant. > > Yes, you seem to be repeating this argument and I'm unable to grasp > its implication. The Internet itself wouldn't exist if there were no > PSDs, however rare. Programmers have to know what to do when they > find one. It's true that without PSDs there would be no Internet as we know it, but that's not relevant to DMARC. The only PSDs relevant to DMARC are those with DMARC records, so I don't think that's a relevant point. I think we have adequately specified what programmers should do. In the other thread I've suggested adding a PSD example to make the concept clear. I think that's enough. If there is something that's not adequately specified, please suggest changes to the document. While I disagree with your suggestion above, the fact that you proposed specific alternate text made it very easy to understand what you were proposing and I appreciate that. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
This is about Ale's question about handling the situation where the tree walk starts on a PSD=y entry: When the tree walk starts at a PSD=Y record, the appropriate response is to treat it as a self-contained organization (PSD=N) and force alignment to STRICT for both SPF and DKIM. This rule applies naturally to PSDs, and to the private registries which are implemented as a single label. The question becomes: Are there private registry organizations which: - have a multi-label structure so that relaxed alignment is feasible, and - have a need to send email from a leaf domain name with PSD=Y, and - have a need to authenticate those messages using a different domain and relaxed alignment? This combination is certainly possible, but I suspect it is rare. More importantly, I think it is necessary to inconvenience private registries which have that special case, simply for the technical convenience of using a single token and the security benefit of knowing that other PSD=Y entries are handled safely. Does this work for everyone? I actually thought that some version of this had been agreed previously. Doug On Sat, Jul 16, 2022 at 7:16 AM Alessandro Vesely wrote: > On Fri 15/Jul/2022 18:03:36 +0200 John Levine wrote: > > > On Fri, 15 Jul 2022, Alessandro Vesely wrote: > >> Organizational Domains are defined as PSD+1, and can have DMARC records > > > > I think this would be a good time to review the way relaxed alignment > > works in sections 4.5 through 4.8 of the draft. > > > I think this statement in 4.8 is inexact: > > OLD: > If this process does not determine the Organizational Domain, then > the initial target domain is the Organizational Domain. > > NEW: > If this process does not determine the Organizational Domain, then > the initial target domain is the Organizational Domain, unless it > is a PSD. > > > Indeed, since we said an org domain is PSD+1, a PSD cannot be an org > domain. OTOH, you can happen to start the process with a PSD. > > Perhaps we should take a position of treating a domain as if it were > an org domain albeit it isn't, for uk.com and similar? > > > > Perhaps 0.01% of the time, a tree walk will find a record with a psd > > tag. The other 99.99% of the time it's the shortest name with a DMARC > > record, and PSDs are completely irrelevant. > > > Yes, you seem to be repeating this argument and I'm unable to grasp > its implication. The Internet itself wouldn't exist if there were no > PSDs, however rare. Programmers have to know what to do when they > find one. > > > Best > Ale > -- > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Fri 15/Jul/2022 18:03:36 +0200 John Levine wrote: On Fri, 15 Jul 2022, Alessandro Vesely wrote: Organizational Domains are defined as PSD+1, and can have DMARC records I think this would be a good time to review the way relaxed alignment works in sections 4.5 through 4.8 of the draft. I think this statement in 4.8 is inexact: OLD: If this process does not determine the Organizational Domain, then the initial target domain is the Organizational Domain. NEW: If this process does not determine the Organizational Domain, then the initial target domain is the Organizational Domain, unless it is a PSD. Indeed, since we said an org domain is PSD+1, a PSD cannot be an org domain. OTOH, you can happen to start the process with a PSD. Perhaps we should take a position of treating a domain as if it were an org domain albeit it isn't, for uk.com and similar? Perhaps 0.01% of the time, a tree walk will find a record with a psd tag. The other 99.99% of the time it's the shortest name with a DMARC record, and PSDs are completely irrelevant. Yes, you seem to be repeating this argument and I'm unable to grasp its implication. The Internet itself wouldn't exist if there were no PSDs, however rare. Programmers have to know what to do when they find one. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Fri 15/Jul/2022 13:23:20 +0200 Laura Atkins wrote: On 15 Jul 2022, at 12:02, Alessandro Vesely wrote: On Wed 13/Jul/2022 23:51:31 +0200 John Levine wrote: I went through and looked at all of the "must" and "should", in both upper and lower case. A lot of the lower case "must" was saying that one thing is the same as another using tortured syntax so I rewrote most of them to be shorter and clearer. This change is wrong: However, a DKIM signature bearing a value of "d=com" would never allow - an "in alignment" result, as "com" should be identified as a PSD How is a valid DKIM signature of d=com going to happen? I found several d=;, which also shouldn't happen. I discovered them because my filter choked on NULL domain. (Had I interpreted d=; as the root, ".", perhaps I'd never have noticed it.) The next version I'll try and log the "kind" of identifiers. I'd guess some (faked) signing PSDs will appear. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Thursday, July 14, 2022 11:26:05 AM EDT Todd Herr wrote: > On Wed, Jul 13, 2022 at 7:44 PM Scott Kitterman > > wrote: > > On July 13, 2022 9:51:31 PM UTC, John R Levine wrote: > > >On Wed, 13 Jul 2022, John Levine wrote: > > >> It appears that Murray S. Kucherawy said: > > >>> Speaking as an AD now, you should expect me to complain about the > > > > "SHOULD" > > > > >>> in Section 4.7. > > > > > >I went through and looked at all of the "must" and "should", in both > > > > upper and lower case. > > > > [snip] > > > > >You can see the text diffs here: > > > > > >https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html > > > > > >There's a github pull request with the changes. > > > > These all look like reasonable changes to me. > > I've merged John's pull request and created rev-13 in github, but due to > the blackout for the upcoming meeting we can't publish this rev until after > July 23. Since we have some time DMARCbis should also obsolete RFC 9091 as it's functionality is inherent in the DMARCbis design. This should also be mentioned in Section 7. My thought is that a sentence at the end of 7.3 should be sufficient. Perhaps, "The DNS Tree Walk also incorporates PSD policy discovery, which was introduced in RFC 9091." Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Fri, 15 Jul 2022, Alessandro Vesely wrote: Organizational Domains are defined as PSD+1, and can have DMARC records I think this would be a good time to review the way relaxed alignment works in sections 4.5 through 4.8 of the draft. Perhaps 0.01% of the time, a tree walk will find a record with a psd tag. The other 99.99% of the time it's the shortest name with a DMARC record, and PSDs are completely irrelevant. (although com currently hasn't). As we have repeatedly discussed, .com and other large gTLDs do not have DMARC records and never will, and that is not a problem. I have to say I am dismayed that we seem to be repeating argunebts about misconceptions that we had already resolved in recent weeks. That doesn't seem like a good use of anyone's time. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
> On 15 Jul 2022, at 12:02, Alessandro Vesely wrote: > > > On Wed 13/Jul/2022 23:51:31 +0200 John Levine wrote: > >> I went through and looked at all of the "must" and "should", in both upper >> and lower case. >> A lot of the lower case "must" was saying that one thing is the same as >> another using tortured syntax so I rewrote most of them to be shorter and >> clearer. > > > This change is wrong: > > However, a DKIM signature bearing a value of "d=com" would never allow > - an "in alignment" result, as "com" should be identified as a PSD How is a valid DKIM signature of d=com going to happen? laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed 13/Jul/2022 23:51:31 +0200 John Levine wrote: I went through and looked at all of the "must" and "should", in both upper and lower case. A lot of the lower case "must" was saying that one thing is the same as another using tortured syntax so I rewrote most of them to be shorter and clearer. This change is wrong: However, a DKIM signature bearing a value of "d=com" would never allow - an "in alignment" result, as "com" should be identified as a PSD and + an "in alignment" result, as "com" does not have a DMARC record therefore cannot be an Organizational Domain. Organizational Domains are defined as PSD+1, and can have DMARC records (although com currently hasn't). Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed, Jul 13, 2022 at 7:44 PM Scott Kitterman wrote: > On July 13, 2022 9:51:31 PM UTC, John R Levine wrote: > >On Wed, 13 Jul 2022, John Levine wrote: > >> It appears that Murray S. Kucherawy said: > >>> Speaking as an AD now, you should expect me to complain about the > "SHOULD" > >>> in Section 4.7. > > > >I went through and looked at all of the "must" and "should", in both > upper and lower case. > > > [snip] > > > >You can see the text diffs here: > > > >https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html > > > >There's a github pull request with the changes. > > These all look like reasonable changes to me. > > I've merged John's pull request and created rev-13 in github, but due to the blackout for the upcoming meeting we can't publish this rev until after July 23. -- *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
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On July 13, 2022 9:51:31 PM UTC, John R Levine wrote: >On Wed, 13 Jul 2022, John Levine wrote: >> It appears that Murray S. Kucherawy said: >>> Speaking as an AD now, you should expect me to complain about the "SHOULD" >>> in Section 4.7. > >I went through and looked at all of the "must" and "should", in both upper and >lower case. > >A lot of the lower case "must" was saying that one thing is the same as >another using tortured syntax so I rewrote most of them to be shorter and >clearer. > >The SHOULD in 4.7 is now a MUST, and I trimmed some excess words. Also fixed >a similar SHOULD in 5.3. You have to ignore crud in the DMARC record, which I >believe is what most if not all DMARC libraries do. > >In 4.4.1 it said that d=com cannot be an organizational domain because it's a >PSD, which I fixed to say because it has no DMARC record. You can't tell it's >a PSD because it has no DMARC record and never will but as previously >discussed, that doesn't matter. > >In 5.8 took out a MUST turn an IDN in an A-R header into an A-label, since you >don't have to do that. > >You can see the text diffs here: > >https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html > >There's a github pull request with the changes. These all look like reasonable changes to me. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] mustard, was I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed, 13 Jul 2022, John Levine wrote: It appears that Murray S. Kucherawy said: Speaking as an AD now, you should expect me to complain about the "SHOULD" in Section 4.7. I went through and looked at all of the "must" and "should", in both upper and lower case. A lot of the lower case "must" was saying that one thing is the same as another using tortured syntax so I rewrote most of them to be shorter and clearer. The SHOULD in 4.7 is now a MUST, and I trimmed some excess words. Also fixed a similar SHOULD in 5.3. You have to ignore crud in the DMARC record, which I believe is what most if not all DMARC libraries do. In 4.4.1 it said that d=com cannot be an organizational domain because it's a PSD, which I fixed to say because it has no DMARC record. You can't tell it's a PSD because it has no DMARC record and never will but as previously discussed, that doesn't matter. In 5.8 took out a MUST turn an IDN in an A-R header into an A-label, since you don't have to do that. You can see the text diffs here: https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html There's a github pull request with the changes. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
