> Note: The results from DNS queries that are > intended to validate a domain name unavoidably approximate > the set of Author Domains that can appear in legitimate email. ... > I'd like to suggest that we use a different word than "approximate" in > the above discussion and in the Levine draft. ... > I suppose that "overapproximate" would be OK within the constraints of > 2821. ... > I can definitely live with "approximate". I don't think > "overapproximate" is even a word, or if it is, it may mean something > else so let's avoid that one.
This (over)approximation issue is confusing, and it can be eliminated with a more precise definition of what domains are "in scope for ADSP". After writing the text that evolved into what's in the Levine draft, my thoughts have evolved towards the following: ADSP as defined in [ADSP] is bound to DNS. For this reason, ADSP is applicable only to Author Domains with explicit ADSP DNS records. The handling of Author Domains without explicit ADSP DNS records is outside the scope of [ADSP]. However, attackers may use out-of-scope Author Domains in an attempt to sidestep an organization's explicit ADSP policy statements that some or all email is signed. For this reason receivers MUST handle out-of-scope Author Domains appropriately. The "ADSP scope" algorithm then simplifies into: - Receivers MUST look up the DNS MX record for the Author Domain. If the lookup completes with error code 3 (NXDOMAIN) the Author Domain does not exist in DNS, and therefore it is not possible to publish an ADSP record for the Author Domain. Receivers MUST treat such out-of-scope Author Domains as an error. - Otherwise, the Author Domain exists in DNS, but the organization publishes no ADSP record for the domain. Receivers SHOULD resolve the domain as required by [SMTP]. If the domain does not resolve, receivers SHOULD treat such out-of-scope Author Domains as an error. - Otherwise, receivers MAY treat such out-of-scope Author Domains as if the organization had published an explicit ADSP policy statement of "unknown". So the algorithm simplifies into: MUST do NXDOMAIN test for MX lookup, SHOULD resolve the domain per [SMTP]. Whether it's SHOULD or MAY (or even not at all) depends on a trade-off between the predictability of receiver behavior against typical overhead and the potential for abuse in packet multiplication attacks. Wietse _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html