>The terms "Valid Signature from an Author Domain" and "Author >Signature" are very easily confused.
I think we're all confused at this point. If the From: address were [email protected] and the signature had [email protected], that sure looks like a valid signature from an author domain, but I don't think anyone expects them to match. Personally, I have never understood the assumption that the i= value is in the same namespace as From: addresses, since it's demonstrably false, but I've been consistently overruled so I'll have to let someone who does understand this model try to fix it. >2) Protecting subdomains > >However, I think we need an additional paragraph explaining the >implications of this choice for domains that would like to protect >their subdomains We deliberately left this out because it's just a subset of the impossible problem of defending against lookalike domains. For the subdomains you actually use, it's easy enough to publish records for them so that's not at issue. We had a long and heated discussion about protecting all of a domain's non-existent subdomains, but it was never clear why if you're example.com, it's more important to protect against foo.example.com than examp1e.com, since we all agree that the latter isn't possible. >If all the RRs (including "_foomtp._tcp.eng.example.com") are in the >"example.com" zone (no zone cuts under it), and no RRs with owner >"eng.example.com" exist, does a DNS query for "eng.example.com" return >NXDOMAIN or NODATA? It returns NODATA. >4) Minor clarifications/nits I think I got the FWS/WSP and DNS Considerations in -08. Re your second message, we didn't say anything about Sender: for roughly the same reason we didn't say anything about subdomains -- the number of identities that ADSP doesn't address is unlimited, and it seems counterproductive to try to enumerate all of the addresses to which someone might wrongly hope that ADSP applies. Note that any valid DKIM signature means that an organization takes responsibility for the mail it signed. ADSP doesn't and can't affect that, so again, there seems little point in listing yet more things ADSP doesn't do. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
