On May 2, 2008, at 9:32 AM, Arvel Hathcock wrote:
Why is it sufficient for the domain to have no RR relevant to
email, just as long as it has some RR?
An empty node with no resource records will not cause an NXDOMAIN
response.
Because it just seems the path of least resistance. If I were to
suggest that every domain taken from From: needs to have an MX RR
then somebody would point out that this violates SMTP RFC 2821
Section 5 which, in it's wisdom, treated the need for MX RR's as an
optional "we think it's a good idea" type of thing.
While it may be reasonable to check for A records after checking for
MX records, before considering a domain as not supporting SMTP, a
requirement to query A records should not be included within the ADSP
specification. Although SMTP does not require domains to publish MX
records, publish ADSP policy should still be predicated upon the
domain also publishing MX records in conjunction with their ADSP
records. Such a mandate thereby protects all domains not involved
with SMTP from being flooded by policy related DNS transactions
whenever some sub-domain within their domain is spoofed within email
addresses.
With an MX record mandate made by ADSP (that should also be made by
SMTP at some point), the first check should be to discover whether an
MX record exists. When used legitimately, MX records have a fairly
high probability of existing and being cacheable. When an MX record
is not returned, the ADSP mandate allows recipients to assume ADSP
policy is not published at the domain, and thereby forgo attempts to
retrieve SMTP related policies. If ADSP becomes accepted practice,
other policy records will be deployed as well. Limiting the impact
caused by policy records transactions generated by each email received
becomes an extremely important security consideration.
The ADSP draft could recommend the support for SMTP at the From domain
be confirmed before accepting messages, but such a recommendation has
little to do with the application of ADSP policy or DKIM. This would
have more to do with a general issue of not accepting messages
containing spoofed addresses.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html