I mostly agree but here's a few comments. It appears that Seth Blank <[email protected]> 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 [email protected]. 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
