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

[John Levine <[e-mail]>]

I mostly agree but here's a few comments.

It appears that Seth Blank  <[e-mail]> said:
>Section 4:2: Use of RFC5322.From:
>
>Is it also worth it to call out that time and operational impact have
>proven this to be the right choice?

Since we never tried anything else, we don't know. I suppose we might
note that DMARC remains surprisingly effective even though most MUAs no
longer show the domain name it uses.

>Section 4.4.1 and 4.4.2:
>
>Naive question: Both sections call out requiring the aligned identifier to
>be an FQDN. Is this sufficient with the extension of DMARC to PSDs? Would
>this mean that .google can never be a source of authenticated mail? Is that
>desirable?

You're conflating two things here. Back in ye olden days it used to be
common for people to put partial domain names in their mail, e.g.
joe@sales, and it added a default like [e-mail]. That
ended fairly quickly when Czechoslovakia got its own domain and comp
sci departments around the world found that mail to joe@cs was now
getting lost somewhere near Prague.

An FQDN can have one component so GOOGLE is a FQDN.  However, a decade
ago in RFC 7085 we found that a fair number of TLDs had MX records, and
none of them worked.  I checked again more recently, same thing.  So
the update to RFC 5321 is going to say that you shouldn't try to send
mail to addresses with single label FQDNs.

>Do we want to remove the reference to FQDN and say that an aligned
>identifier must be at or below a valid Organizational Domain?

The FQDN reference is fine, and I don't think we need to try and
duplicate advice about whether or not single label names work.

>Section 4.6: DNS Tree Walk:

>I *strongly* believe that N needs to be 8 to meet operational use cases
>we see today, and may still fall short in the future as this use case is
>unlocked by the tree walk.

OK with me.

>Section 5.3: General Record Format:
>
>Shouldn't the RUF options be defined in the RUF document, as opposed to the
>primary bis document?

I'd rather leave all the syntax in the main document so people know how to
construct or parse a DMARC record, but put the usage into the other docs.
I don't feed strongly about where we say that the only URLs that work
are mailto:.

>Section 11.4: Display Name Attacks:
>
>This feels out of place. Even though it's mentioned as a different problem,
>this is a lot of content irrelevant to the spec itself. Do we need it at
>all outside the second paragraph?

I'm with you -- I don't think it makes sense to talk about what we don't do
since the list of potential topics is infinite.

R's,
John