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?
Let's check:
$ dig gov soa
; <<>> DiG 9.10.6 <<>> gov soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63612
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gov. IN SOA
;; ANSWER SECTION:
gov. 300 IN SOA a.ns.gov. dns.cloudflare.com.
1711843800 3600 900 604800 300
Yup, it's a domain.
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.
I wouldn't object to taking it out since I agree that it's neither very
accurate nor very helpful.
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.
There aren't any in the PSL. That's where the limit of 5 came from.
We've had people say there are deeper ones; if there are it wouldn't be
hard to bump up the limit from 5 to whatever.
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.
I really don't want to get into speculation about what people might do
wrong and tell them not to do that. Our job is to tell people how to
interoperate -- if you do what the spec says, it'll work.
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.
I'm pretty sure we went through that, and it's a quality of implementation
issue. If you get SERVFAIL, maybe you want to wait and see if it fixes
itself, maybe you figure that if people want to get their mail delivered
they should have working DNS. I don't see how anything we said would make
any real difference to interoperation, and in practice, the DMARC records
tend to be pretty close to the MX records so it's unlikely that one would
be broken and the other wouldn't.
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.
Look at the report drafts and see what you think.
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.
DMARC does one thing, deal with fraud in the domain on the From line. The
list of things it doesn't do is infinitely long, so I don't want to try to
enumerate them.
R's,
John
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
