On May 7, 2008, at 1:37 PM, Jim Fenton wrote:
(1) When used in an email address, www.example.com is called a
domain, and since it's below example.com, it could be called a
subdomain of example.com.
(2) In some other contexts, a hostname may not be considered to be a
subdomain, since it has nothing below it.
Disagree. A hostname can represent both a domain AND a subdomain of a
parent domain.
The domain "example.com" can support an SMTP server with a hostname of
"example.com". Often MX records offer multiple hostnames, which might
be "mx01.example.com" and "mx02.example.com" where address records for
these hosts would be within subdomains of example.com. There is no
requirement that a subdomain also have subdomains as definition 2
seems to imply. This seems to confuse subdomains with resource
records at a domain.
If there's a www.eng.example.com, then eng.example.com would be a
subdomain (regardless of whether it has its own SOA record, or a
direct record for www.eng exists within the example.com zone).
Disagree. "eng.example.com" would be a subdomain of "example.com"
whether or not the subdomain "www.eng.example.com" exists.
Using definition (2), the parent domain check is beneficial only for
hostnames, but not for subdomains.
By striking the paragraph, policy only covers a _single_ domain level,
and _not_ automatically subdomains of a domain.
Since any hostname can receive mail via its A or AAAA record, in
order to achieve complete coverage for ADSP within a given domain,
every hostname needs its own ADSP record, absent a reference to the
ADSP record at the next higher level.
Removing parent domain checks eliminates transactions at parent
domains for each email received. Publishers and not receivers of each
email (a quadrillion fold), must make the added effort.
The parent domain check does not attempt to cover subdomains, but
since they are much less numerous than hostnames, the overhead of
publishing ADSP records (manually, if necessary) for subdomains is
much less than for hostnames.
It is not always possible to publish records within parent domains.
For example, "example.com" is unable to publish records within its
parent domain. It seems this is attempting to defined semantics
related to domains containing addresses specifically for hostnames
versus domains used in email-addresses. Unless or until SMTP mandates
publishing MX resource records, it remains impossible to differentiate
which domains support SMTP. Only those without A, AAAA, or MX records
clearly do not support SMTP.
ADSP should be cautious and mandate MX records always be published in
conjunction with ADSP records. A check for MX records thereby
eliminates checks for policy records. This mandate protects domains
not supporting SMTP from being inundated with policy discovery
transactions and connection attempts whenever their domain is spoofed
as an email-address.
The MX mandate may depend upon J.D. or others championing the cause.
Without the MX mandate for SMTP as well, there can not be a practical
solution for comprehensive SMTP policy coverage. SMTP MUST depend
upon opt-in strategies. Opting out through the use of "MX ." or
"v=spf1 -all" or "DKIM=DISCARDABLE" published at every domain
containing address records to fending off a deluge undesired SMTP
transactions, connections, spoofed messages is unfair and
unreasonable. Stop the nonsense. The few supporting SMTP that have
yet to publish MX records should step-up to ensure safer public SMTP
exchanges.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html