On 30 Mar 2024, at 11:42, John R. Levine wrote: >> Below is a number of “minor issues and editorial comments” on dmarcbis-30. I >> have a larger issue regarding the draft as a whole that I have yet to write >> up and will post separately. > > Thanks for the review even though I disagree with a fair amount of it.
You’re welcome. It’s fine if we disagree. >> Side note: I’m very dubious about the allowances for DMARC records to be >> published by public suffixes since the PSO is much less likely to know the >> usage of the domains under it, and whether a policy like Reject is >> appropriate. But I suspect the WG decided to include the public suffix >> policies so this would be a relitigation. > > PSDs were originally invented for .BANK and .INSURANCE which know exactly > what their registrants' policy should be because it's in the contract. And also .gov where DHS seems to be setting policy for state and local registrants, probably without that knowledge. > Beyond that, since we're not using the static PSL any more, the PSD flag > fixes some uncommon cases where the tree walk would otherwise get a wrong > answer. We debated this at extreme length and it ain't gonna change now. Not really expecting that it will. >> 2.4 Out of scope >> ---------------- >> >> Entities other than domains: Public suffixes aren’t (necessarily) domains, > > Of course they're domains. What else could they be? The things that are out > of scope are IP addresses, ASNs, magic tokens in the messages, stuff like > that. I’m probably being pedantic here: is “gov” a domain? >> 4.2 Use of RFC5322.From >> ----------------------- >> >> Second bullet: “most MUAs display some or all of the contents of that >> field”. I find this becoming less and less true. Many MUAs that I use, >> including Apple Mail (iOS) and Outlook, display only the Display Name, which >> is not authenticated at all as pointed out much later (11.4). > > Perhaps it should say "can display". I agree you're more likely to see the > comment in the From header than the domain these days. I’m not sure how helpful “can display” is if you have to figure out how to display message source or something. Of course, there is also the argument that users’ behavior won’t be any different even if it is displayed. >> authenticates the individual sender. So the recipient would just be guessing. >> >> Last paragraph: I don’t see a profile of RFC5322.From in section 5.7. > > It's in 5.7.1, From with more or less than one domain is out of scope. Yes, the reference needs to be corrected. It’s not worded as a profile would be, and I even searched for the word “profile” and didn’t find it. >> 4.6 DNS Tree Walk >> ----------------- >> >> Step 2 starts talking about the psd flag without telling what it is. It >> would be much better if this discussion came after the flags and their >> meanings was introduced. >> >> I’m concerned that some (admittedly rare) public suffixes with multiple >> components are not well served by this algorithm, such as pvt.k12.ma.us. > > I happen to run the registry for seneca.ny.us, watkins-glen.ny.us and other > local places and it seems fine to me. Can you give some examples? Mine wasn’t a good example. There are a few public suffixes that have more than 5 labels. Presumably that means there are registered domains that are 6 levels down, and my reading of the tree walk is that a policy published there would never be seen. But who knows if they’re actually sending email. >> What happens if a domain that is not a public suffix publishes psd=y, either >> accidentally or maliciously? > > Its subdomains might get the wrong organizational domain. This seems to me a > self-inflicted wound. OK >> Side note: I got well into this document before I realized that DMARC is >> publishing an assertion of being a public suffix. Some mention of that >> belongs back in the introduction. > > A what? It's only using PSDs as a way to figure out the org domain. We > certainly don't expect other users of the PSL to switch. Maybe there should be an admonition to say that other applications MUST NOT use a psd=y record for anything. >> 4.7 DMARC policy discovery >> -------------------------- >> >> Paragraph 3: “domain does not exist”: How is that determined, NXDOMAIN, >> NODATA? What happens with SERVFAIL (e.g., DNSSEC problem) or no response? >> And if a domain really doesn’t exist, isn’t that a reason to reject “with >> prejudice”? > > As it says later, error handling is up to you. IMO the specification is incomplete if it doesn’t say how nonexistence is determined. >> Paragraph 4 bullet 1: “syntactically valid”: It seems like there are a lot >> of URIs with valid syntax that would not make sense here. What if someone >> publishes [sip://example.org](sip://example.org) or >> [gopher://example.org](gopher://example.org)? > > Another self-inflicted wound, so we don't care. I believe the report > documents now say that only mailto: actually works. I proposed an https > method similar to what MTA-STS has but nobody was interested. Considering > how few people use https MTA-STS reports, it's hard to disagree. Maybe it should be limited to mailto: URIs unless someone publishes an extension to another URI scheme. >> Also, don’t a lot of these things that have to do with reporting belong in >> one or both of those drafts (which I haven’t read yet)? > > This is just what goes in the DMARC record. The other stuff is indeed in the > other drafts. I had expected there would be a DMARG tag registry and the other specifications would add things like ruf to it. >> 5\. Policy >> ---------- >> >> Paragraph 2: “A Domain Owner…may choose not to participate...by not >> publishing an appropriate DNS TXT record”. But what if the PSO did? If they >> disagree with that record, they do need to publish a TXT record of their >> own, don’t they? > > They do, but I don't think it's our job to referee arguments between > registries and their customers. Not asking for it to be refereed, just to point out that the domain owner may indeed have a DMARC policy even if they didn’t publish one themselves. >> 11.4 Display Name Attacks >> ------------------------- >> >> This goes to one of the overarching concerns I have about DMARC. I am >> getting lots of spam and phishing with plausible display names but obvious >> throwaway addresses controlled by attackers. “Further exploration…needs to >> be undertaken” is not a sufficient response IMO. > > I think we should take this section out. There have been a lot of > discussions at M3 about what to do about display name attacks and nobody has > any idea beyond normal spam filtering. Strongly disagree. The Security Considerations section is specifically for describing relevant threats. The fact that nobody has any idea what to do about display name attacks is a specific reason why it should be included. > A.5 Issues with ADSP in Operation >> --------------------------------- >> >> Maybe include an informative reference to \[RFC5617\] here. > > As an author of the ADSP RFC, I would strongly suggest completely removing > everything about it. It was a bad idea and time has not improved it. As an author of the ADSP RFC, I have a somewhat different opinion about it. But I was rather surprised to see the amount of attention being paid to it here. >> ??? Not Found >> ------------- >> >> I expected to find some text at least recommending a rewriting strategy for >> From addresses to be used by mailing lists and the like. > > That would be extremely out of scope, not to mention something likely to get > the IESG to kick it back to us. The WG charter lists as the phase 1 work item for this WG, “Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them.” This was published as RFC 7950 (informational). On the contrary, I would expect IESG to kick it back for not even informatively referencing that work here. -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
