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](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.
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
