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 a(_at_)example(_dot_)com and the signature had i=b(_at_)example(_dot_)com,
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