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

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

> 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