toddherr
commented
6 months ago John Levine's on-list reply to the above:
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.
2.1 High level goals
PSOs: Define this abbreviation on this first use. Since it’s talking about a public suffix, “the domain” doesn’t seem sufficient, maybe “the domain or suffix”.
Right.
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.
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.
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.
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.
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.
4.5 Flow Diagram
This diagram and accompanying explanation doesn’t help me at all.
“Solid lines”: Dashed lines, maybe?
We should redraw this in SVG with an explanation of what the different kinds of arrows are supposed to mean.
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?
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.
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.
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.
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 or 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.
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.
4.8 Organizational Domain Discovery
Paragraph 2, bullet 2: “DMARC mechanism does not apply”: What if there is a PSO policy? Or is that covered by the tree walk? (I may have gotten lost here)
Yes, it is covered by the tree walk. The PSD stuff is part of the tree walk mechanism.
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.
5.5.3 Setup a Mailbox…, 5.5.5, etc
Does this belong in the reporting documents?
I think most of it does, perhaps replace with a sentence saying that the details of report handling are in the other documents.
6. DMARC Feedback
Again, I don’t think “feedback” is the best term here.
It's a decade too late to change it.
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.
11.5 Denial of DMARC Processing Attacks
Paragraph 3: Regarding multi-valued From, I thought these were out of scope. They are not a “particular challenge” then.
Agreed.
A.3 Sender Header Field
I don’t recall any use of Sender by DomainKeys. Where I do remember it was in Microsoft’s alternative to SPF, SenderID [RFC4406].
Look at RFC 4870. Domain Keys did use the sender if it's there. Sender ID did too, along with a lame patent on the obvious way to pick the header to use.
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.
A.6 Organizational Domain Discovery Issues
It seems much safer to just point to RFC 7489 for a description of the PSL method than to repeat it here, where a non-careful reader might think that this is a recommended method.
Good idea.
??? 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.
R's, John
Full text of message posted to working group list on 30 March 2024 by Jim Fenton:
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.
-Jim
=====
1. Introduction
Paragraph 3 introduces alignment, and goes into relaxed and strict alignment (which seems like a lot of detail this early). But then paragraph 4 doesn’t talk about alignment at all, but rather whether the RFC5322.From domain has been authenticated. This seems like a disconnect from alignment, since it doesn’t say what “authenticated” means.
Paragraph 5 again jumps terms, from “authenticated” to “passes verification”. It seems like this means the same thing, and should use the same term (or at least explain the difference).
Paragraph 5, last sentence: perhaps “should not affect its reputation.”
Paragraph 6, don’t need quotes
Paragraph 7, “identify, not only sources”: Does “identify” mean that it claims to know where they came from? Seems like a different word like “flag existence of mail” might be better.
2.1 High level goals
PSOs: Define this abbreviation on this first use. Since it’s talking about a public suffix, “the domain” doesn’t seem sufficient, maybe “the domain or suffix”.
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.
2.2 Anti-Phishing
“Claims to come from legitimate senders” — should specify in what way this claim is made. “Informed by ongoing efforts” - Can any be cited here? Otherwise this is a throw-away sentence.
2.4 Out of scope
Entities other than domains: Public suffixes aren’t (necessarily) domains, but they aren’t out of scope. I would say authentication at a finer grain than domain is out of scope.
4.1 DMARC Basics
Paragraph 1: “verification” again
Paragraph 2: Awkward wording: aligned supported authentication mechanism
Paragraph 5: “feedback component”: maybe “reporting component”? Feedback seems like an inappropriate term when the reports might go to a third party and not the purported source.
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).
Third bullet: “Many high-profile email sources…”: This doesn’t seem actionable since DMARC does not have a means for the source to assert that it 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.
4.3 Authentication Mechanisms
Bullet 1: “verified DKIM-Signature” vs. bullet 2 “SPF, which can authenticate”.
4.4 Identifier Alignment Explained
Drop the word “Explained” from the section title.
Paragraph 1: “DKIM authenticates” (compare with Sec. 4.3 use of “verified”)
Paragraph 2: This would be a much better place to put the examples of relaxed and strict alignment that appear in later sections. The definitions weren’t sufficient for me.
Paragraph 3: Also site the profile of RFC5322.From (wherever it is) when talking about non-compliant cases.
4.4.1 DKIM-Authenticated Identifiers
Paragraph 1: Authenticity of the Author Domain: “Authenticity” seems more like it has to do with whether it’s a real domain or not. Maybe “association with” or something like that?
Paragraphs 2-4: This would be better back in Sec. 4.4 and reference back to it.
Paragraph 5: “aligned and verified”. “Authenticated and aligned” maybe?
4.4.2 SPF-Authenticated Identifiers
Paragraphs 2-4: Repetitive; also better back in Sec. 4.4. Or is there some subtle difference between SPF and DKIM alignment that I missed?
4.5 Flow Diagram
This diagram and accompanying explanation doesn’t help me at all.
“Solid lines”: Dashed lines, maybe?
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.
What happens if a domain that is not a public suffix publishes psd=y, either accidentally or maliciously?
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.
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”?
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 or gopher://example.org? 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)?
4.8 Organizational Domain Discovery
Paragraph 2, bullet 2: “DMARC mechanism does not apply”: What if there is a PSO policy? Or is that covered by the tree walk? (I may have gotten lost here)
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?
5.3 General Record Format
Finally, a definition of those tags I have been reading about! I think this belongs much earlier.
adkim and aspf: “Domain Owner requires”: should this be Domain Owner or PSO requires?
fo, rua, ruf: Should these be in the reporting documents instead?
sp: “applies only to subdomains”: Does this mean an immediate subdomain or sub-subdomain, etc.?
5.5.3 Setup a Mailbox…, 5.5.5, etc
Does this belong in the reporting documents?
6. DMARC Feedback
Again, I don’t think “feedback” is the best term here.
7. Changes
The changes section usually appears very close to the end.
7.5.1 Tags Added
Probably inappropriate to cite [RFC9091] in this way — it’s being obsoleted, and this looks like a normative reference.
8.6 Interoperability Considerations
Paragraph 1: Alumni forwarders can also break DKIM signatures (although frequently not), and this should be acknowledged.
10.1 Aggregate Report Considerations
Aggregate reporting could reveal sensitive traffic patterns, for example if Company A is in the process of an acquisition of Company B.
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.
Paragraph 3, bullet 2: Since this is easily defeated, why even mention it?
11.5 Denial of DMARC Processing Attacks
Paragraph 3: Regarding multi-valued From, I thought these were out of scope. They are not a “particular challenge” then.
References
RFC7489 and RFC9091 should not be listed as normative references; they are being obsoleted by this document.
A.3 Sender Header Field
I don’t recall any use of Sender by DomainKeys. Where I do remember it was in Microsoft’s alternative to SPF, SenderID [RFC4406].
A.4 Domain Existence Test
This is the sort of thing I was looking for in Sec. 4.7 paragraph 3: this needs normative language saying how nonexistence of the domain is to be established.
A.5 Issues with ADSP in Operation
Maybe include an informative reference to [RFC5617] here.
Item 1: Wildcards cannot be used, as RFC 5617 points out, because it isn’t possible to wildcard anything except the first element. One can’t wildcard _adsp.*.example.com. A tree walk was proposed and extensively discussed for ADSP, but working group consensus was that it was harmful to include (overhead, etc.).
Item 2: NXDOMAINs were considered out of scope for ADSP because ADSP is a policy published by the author domain, and there is no way to publish a policy for a nonexistent domain. The same argument could apply to DMARC as well.
Item 5: DMARC also has no mechanism for a slow rollout now that the pct: tag has been removed.
Item 6: ADSP has an intermediate policy, “all”. ADSP policies are declarative rather than imperative because WG consensus was that the author domain can’t tell the recipient what to do, hence “all” rather than “quarantine” and “discardable” rather than “reject”.
A.6 Organizational Domain Discovery Issues
It seems much safer to just point to RFC 7489 for a description of the PSL method than to repeat it here, where a non-careful reader might think that this is a recommended method.
A.7 Removal of the “pct” tag
Already mentioned in 7.5.2, I don’t think this much description is needed for something that isn’t part of the spec.
??? 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. But I guess that’s in RFC 7960, which is informational, so you can’t reference that normatively. Not sure what to do about that.