Subject: [ietf-dkim] Meta-comment re: subdomain strawpoll

From: Jim Fenton <[email-masked]>
Date: Wed, 07 May 2008 13:37:58 -0700

There seems to be a little confusion in questions I have gotten about 
the "Try Parent Domain" step and the title of this straw poll.  In 
particular, whether the parent domain check is intended to apply to 
subdomains at all.

The confusion is whether a hostname, like www.example.com, is a 
subdomain or not:

(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.  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).

Using definition (2), the parent domain check is beneficial only for 
hostnames, but not for subdomains.  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.  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.

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 7 May 2008 17:00:38 -0700

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.
>
> 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.

> 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