Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

["John R. Levine" <[e-mail]>]

>>> 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