John Levine wrote:
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.
Maybe, but that expectation is not based on the definition of "Valid
Signature" in RFC 4871 -- so this document needs to be clear about it.
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.
Since the WG apparently reached rough consensus on this, at this
point I'm not asking anyone to fix it, but just make the explanation
clearer so that readers who didn't see the WG discussions will
understand the implications.
(The main implication being that just signing all your outgoing email
may not allow you to advertise "dkim=all", if you e.g. use the "i="
tag to identify a mailing list manager -- the only example of its use
given in RFC 4871.)
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.
Right -- this is not something we can (or need to) solve in this
document; I was asking for a sentence or two explaining the "it's easy
enough to publish records for [the subdomains you actually use]" part.
Something like this, perhaps? (added after 2nd para in Section 3.1)
Note: If an organization wants to publish Author Domain Signing
Practices for all its subdomains, too, it needs to create ADSP
records for every _adsp._domainkey_.<subdomain>.domain.example.
Note that wildcards cannot be used (see Section 6.3); however,
creating the ADSP records could be automated with suitable DNS
management tools.
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.
Thanks! I think we can leave this sentence as-is, then.
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.
I think clearly explaining when an organization that signs all
its outgoing email can actually publish a "dkim=all" policy is pretty
important -- although ADSP doesn't (and shouldn't) do everything,
we need to be clear about what it does.
Best regards,
Pasi
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html