Re: [dmarc-ietf] what to document about the tree walk
We can limit the transition period by specifying a date, after which any untagged record is interpreted with strict alignment. On Wed, Jul 13, 2022, 11:10 AM Murray S. Kucherawy wrote: > Once again, participating only: > > On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> [...] >> > >> 2) I believe that the document needs a vigorous explanation of why the >> PSL needs to be replaced. I made a stab at the effort in the text that I >> sent Sunday night. Murray's text here is more comprehensive. But we >> need something. We are asking evaluators to undertake a change which >> requires effort and any change creates multiple risks. >> > > I don't know about "vigorous", but I think some tutorial would be useful > given the wide variability of experience in the ultimate audience. An > appendix would suffice. > > >> 3) The critical question is whether we can treat the PSL as replaced >> without obtaining the markers first. On this issue, John and I have a >> different assessment of the risk. I can accept a solution which lays out >> the assumptions and risks to the evaluator, and lets them decide what to >> do. This is what sections 4.7. and 4.8 in my text from Sunday night >> attempted to do. >> > > My suggestion would be that if we are going to offer a choice, there > should be some eventual path toward convergence rather than an open-ended > period of people doing either. Otherwise, the PSL will be a part of DMARC > for far longer than we'd like. > > -MSK > ___ 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
Re: [dmarc-ietf] what to document about the tree walk
It appears that Murray S. Kucherawy said: >There is indeed more of a burden on sending domains and registry operators >to publish the needed markers in the DNS before this will all work the way >we want it to. ... Not really. If a mail sender has a DMARC record at its org domain, and there are no DMARC records above the org domain, things will work correctly, no psd tag needed. I expect that in practice this will happen 100% of the time, rounding to the closest 0.01%. That's why it is not a problem that popular TLDs like .com, .org, and .net will never publish a DMARC record, with or without psd=y. There are at least 200 million registered domains but less than 1 domains in the PSL. For PSDs, we are talking about one domain in 20,000, or about 0.005% of registered domains. Having surveyed all of the domains in the PSL to see which ones publish DMARC records, I can report that the ones where the lack of a psd tag might plausibly cause problems can be counted on your fingers. Some of those already have np= tags which tells us they're aware of what's going on. (See for example _dmarc.uk.com.) The tree walk works fine. The psd tag is an arcane nit, mostly useful to a handful of TLDs like .bank and .insurance that want to use the aggregate reports to audit their registrants' mail configuration. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
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. Specifically, since "SHOULD" ultimately permits a choice, >we ought to [1] give implementers some guidance about when one might opt >not to do what that "SHOULD" says, or in the alternative, make it a "MAY" >or "MUST" (probably the latter?). > >This might also be true of other MUSTard in the document, but since I was >just reviewing that section, it jumped out at me. Good point. I'll make a pass over the MUSTard using my kewl grep powers. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
Whois vs RDAP isn't the issue. PII about registrants has been restricted by ICANN policy since GDPR. Barry On Wed, Jul 13, 2022 at 11:04 AM Murray S. Kucherawy wrote: > > On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote: >> >> Uh? manuals recommend to look up WHOIS to determine the owner of >> domains reported to suffer lame delegation and contact them... >> Nowadays, contacts for domain names are not available that way. >> >> We could hijack reporting addresses, though. > > > Since WHOIS is obsolete, you could try RDAP. If that doesn't work, use the > email address that's part of the SOA record (which is what it's for, really; > see 3.3.13 of RFC 1035). Still, automation of such notifications runs the > risk of generating a lot of unwanted email, so we would really need to > undertake such an effort carefully. > > -MSK > ___ > 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] what to document about the tree walk
On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" wrote: >Once again, participating only: > >On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> [...] >> > >> 2) I believe that the document needs a vigorous explanation of why the PSL >> needs to be replaced. I made a stab at the effort in the text that I sent >> Sunday night. Murray's text here is more comprehensive. But we need >> something. We are asking evaluators to undertake a change which requires >> effort and any change creates multiple risks. >> > >I don't know about "vigorous", but I think some tutorial would be useful >given the wide variability of experience in the ultimate audience. An >appendix would suffice. > > >> 3) The critical question is whether we can treat the PSL as replaced >> without obtaining the markers first. On this issue, John and I have a >> different assessment of the risk. I can accept a solution which lays out >> the assumptions and risks to the evaluator, and lets them decide what to >> do. This is what sections 4.7. and 4.8 in my text from Sunday night >> attempted to do. >> > >My suggestion would be that if we are going to offer a choice, there should >be some eventual path toward convergence rather than an open-ended period >of people doing either. Otherwise, the PSL will be a part of DMARC for far >longer than we'd like. I think a choice within DMARCbis is a bad idea. Effectively the choice exists. Evaluators will have the choice to stay with an RFC 7489 design or to upgrade to DMARCbis. We can't get rid of the PSL without getting rid of the PSL. There's no way to constrain it within the document. If we have a 'choice', we are essentially signing up the IETF to a future effort to produce an update to actually get rid of it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
Once again, participating only: On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > > 2) I believe that the document needs a vigorous explanation of why the PSL > needs to be replaced. I made a stab at the effort in the text that I sent > Sunday night. Murray's text here is more comprehensive. But we need > something. We are asking evaluators to undertake a change which requires > effort and any change creates multiple risks. > I don't know about "vigorous", but I think some tutorial would be useful given the wide variability of experience in the ultimate audience. An appendix would suffice. > 3) The critical question is whether we can treat the PSL as replaced > without obtaining the markers first. On this issue, John and I have a > different assessment of the risk. I can accept a solution which lays out > the assumptions and risks to the evaluator, and lets them decide what to > do. This is what sections 4.7. and 4.8 in my text from Sunday night > attempted to do. > My suggestion would be that if we are going to offer a choice, there should be some eventual path toward convergence rather than an open-ended period of people doing either. Otherwise, the PSL will be a part of DMARC for far longer than we'd like. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote: > Uh? manuals recommend to look up WHOIS to determine the owner of > domains reported to suffer lame delegation and contact them... > Nowadays, contacts for domain names are not available that way. > > We could hijack reporting addresses, though. > Since WHOIS is obsolete, you could try RDAP. If that doesn't work, use the email address that's part of the SOA record (which is what it's for, really; see 3.3.13 of RFC 1035). Still, automation of such notifications runs the risk of generating a lot of unwanted email, so we would really need to undertake such an effort carefully. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Tue 12/Jul/2022 17:12:40 +0200 John Levine wrote: A.6 seems to be dealing with a different subject. I can still sketch some text to be added there, though. I attach the diff. I realize this is getting repetitive but: -- PSDs are very, very rare, and users will generally never see them That doesn't entail developers can generally skip considering them. -- long discussions of PSDs will just confuse people You keep reiterating this concern, to which I try and conform without fully understanding it. At the same time, the opposite concern, that people acting as PSD won't publish as needed, is neglected. The lack of a full explanation will motivate people to write interpretations and suggestions of their own --the same reaction which is motivating me now. -- I don't even think these examples get the tree walk right. I tried to interpret the current draft. Please correct me where I'm wrong. For convenience, I paste the relevant text below. Hence, this change is not an improvement. I don't plan to argue further unless we see more support for this very bad idea. Even if it's not an improvement, I think some points deserve a bit of discussion. For example, the current draft allows psd.example.com to skip defining any DMARC record at all, which wouldn't work. The text (minor change: s/NODATA// and fix a typo): A.6.2. Tree Walk Example Let's now make a corner case example, where "psd.example.com" operates as a public suffix domain. That is, it delegates subdomains to third parties. "Example.com" itself is a regular domain and has its own DMARC record: _dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-feedb...@example.com; "Psd.example.com" is the kind of domain that the PSL would list as private domains, as opposed to ICANN domains. Most public suffix domains (PSD) don't publish a DMARC record. In this example, "psd.example.com" should publish a record, declaring its role as a PSD: _dmarc.psd.example.com IN TXT "v=DMARC1; psd=y; p=reject" Finally, let's consider a customer "rockabilly.psd.example.com". This is a regular domain, register under a private PSD. It can have a DMARC record too: _dmarc.rockabilly.psd.example.com IN TXT "v=DMARC1; p=none; rua=mailto:el...@rockabilly.psd.example.com; Now, assuming that any other subdomain of "example.com" has no DMARC record,let's consider some message cases: Case 1: Author Domain: example.com SPF-authenticated Identifier: mail.example.com DKIM-authenticated Identifier: example.com To verify alignment, the receiver looks up the records for all three labels, getting NXDOMAIN for "_dmarc.mail.example.com" and for "_dmarc.com". "Example.com" is the organizational domain of all three identifier. Therefore they are all aligned. Case 2: Author Domain: psd.example.com SPF-authenticated Identifier: mail.psd.example.com DKIM-authenticated Identifier: rockabilly.psd.example.com This message won't pass, because it is badly engineered as if "psd.example.com" were an independent organization. It is not. It is a subdomain of "example.com", albeit its being used as a base for independent domains. For the Author Domain, "psd.example.com" is the starting point, so the tree walk doesn't stop even if it finds psd=y. Lookups for the remaining labels bring to the conclusion that the organizational domain is "example.com". For SPF, "mail.psd.example.com" is the organizational domain, as it is the label before the one with psd=y. It is not aligned. Similarly, "rockabilly.psd.example.com" is --correctly-- considered the organizational domain and is not aligned. Case 3: Author Domain: rockabilly.psd.example.com SPF-authenticated Identifier: mail.rockabilly.psd.example.com DKIM-authenticated Identifier: rockabilly.psd.example.com TBD Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
1) I believe that replacing the PSL is a good thing, if it is done with markers present. The domain owner is the best source of information about the organization boundaries. We MUST provide him with a way to communicate that knowledge in DNS, and a compliant implementation MUST find and use that information when it is present. 2) I believe that the document needs a vigorous explanation of why the PSL needs to be replaced. I made a stab at the effort in the text that I sent Sunday night. Murray's text here is more comprehensive. But we need something. We are asking evaluators to undertake a change which requires effort and any change creates multiple risks. 3) The critical question is whether we can treat the PSL as replaced without obtaining the markers first. On this issue, John and I have a different assessment of the risk. I can accept a solution which lays out the assumptions and risks to the evaluator, and lets them decide what to do. This is what sections 4.7. and 4.8 in my text from Sunday night attempted to do. Doug On Wed, Jul 13, 2022 at 1:12 AM Murray S. Kucherawy wrote: > Hatless once again. > > On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> The tree walk solves the problem IF the policy has boundary information >> provided by the domain owner. Without that, aren't we substituting one >> insufficiently reliable solution for another insufficiently reliable one? >> > > Another way to look at it: The PSL was never designed to provide the > information for which DMARC has been using it. Hanging DMARC on it was a > reasonable thing for a proof of concept, which is what RFC 7489 really was; > it happens to give the right answer most of the time, but that's something > of a coincidence. Here we're taking control over the input to the > Organizational Domain and Policy Discovery algorithms, which is a more > defensible way to do things if you're heading for the Standards Track. > > The tree walk also eliminates any concern that two compliant operators are > using different versions of the input data. There is no guarantee that my > copy of the PSL is any more or less up to date than yours is, leading us > both to different determinations about the very same message. But once > we're using the DNS for this, then, other than staleness caused by > short-term caching, we're all talking about the same thing. > > There is indeed more of a burden on sending domains and registry operators > to publish the needed markers in the DNS before this will all work the way > we want it to. My view is that the working group perceives the risk of > continued use of the PSL to be less favorable than taking on that burden. > The tree walk has been a goal for years. > > Changes to nodes in the DNS tree are visible immediately; changes to the > PSL take an unknown amount of time to be published and deployed globally. > > Changes to the DNS are made by the operator in charge of the name(s) being > updated; as far as I'm aware, changes to the PSL are made by a limited > community not involved in (or perhaps even interested in, or cognizant of) > DMARC. > > If we want a migration period, some kind of hybrid model might work: Do > the DNS tree walk, but at each step, if you find you've hit a name that's > present in the PSL, you can stop and pretend you found a marker you're > looking for. When those markers are all (or mostly) actually published, > then stop doing that. For bonus points, find some non-DoS way to notify > those operators that they really should be publishing the missing markers. > (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to > remember that SPF had a not-so-great transition plan, so we need to be > careful how we craft this one. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Wed 13/Jul/2022 07:12:25 +0200 Murray S. Kucherawy wrote: If we want a migration period, some kind of hybrid model might work: Do the DNS tree walk, but at each step, if you find you've hit a name that's present in the PSL, you can stop and pretend you found a marker you're looking for. When those markers are all (or mostly) actually published, then stop doing that. For bonus points, find some non-DoS way to notify those operators that they really should be publishing the missing markers. (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to remember that SPF had a not-so-great transition plan, so we need to be careful how we craft this one. Uh? manuals recommend to look up WHOIS to determine the owner of domains reported to suffer lame delegation and contact them... Nowadays, contacts for domain names are not available that way. We could hijack reporting addresses, though. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed 13/Jul/2022 07:32:37 +0200 Murray S. Kucherawy wrote: Speaking as an AD now, you should expect me to complain about the "SHOULD" in Section 4.7. Specifically, since "SHOULD" ultimately permits a choice, we ought to [1] give implementers some guidance about when one might opt not to do what that "SHOULD" says, or in the alternative, make it a "MAY" or "MUST" (probably the latter?). IMHO the whole paragraph (quoted below) could be omitted, specifying instead, in 5.3. General Record Format, the default value of tag "p" (which is not mandatory in the current draft.) If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" or "np" tag that is not valid, then: * If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing; Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
