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