[ietf-dkim] Update: otis-dkim-adsp-04

[Douglas Otis]

An update has been submitted, but the automatic tool appears delayed  
or something.

Here are links to the draft which should become available on the IETF  
website soon.

http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-04.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-04.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-04.xml

The difference between the ssp-03 and this draft are indicated here:

http://www.sonic.net/~dougotis/dkim/ssp03-vs-otis-dkim-adsp-04.html

This draft:

Updates  terms related to signing address. This mitigates several  
vulnerabilities created by ssp-03's current definitions.

Expands results to note when no practices are advertised.

Removes defining practices for subdomains, and includes a  
recommendation to confirm that the Author Domain supports SMTP in some  
manner.  It mentions possible use of MX and A records, and cautions  
about AAAA record use.

Uses a door metaphor for advertised practice states, rather than  
misleading words that could appear to recommend receiver-side handling  
instead.

Suggest a need to make exceptions for non-DNS tlds.

Changes location of ADSP records to be below the Author domain rather  
than the _domainkey label.  This facilitates record placement in  
conjunction with many domains containing either address and MX records.

Adds a note about the use of CNAMES.

Removes most IANA Considerations.

Expands the Security Considerations section to note different handling  
for messages having restrictive local-part templates.  This is the  
same as defining the signing address as being the Author Address in  
the case of a restrictive local-part template.  Declaring such  
messages as having a valid signature would create a serious security  
hazard.  This change can also better deal with an ongoing problem now  
affecting major providers related to bot-nets.

Mentions recommending a strategy of automated folder placement to cope  
with look-alike and sub-domain spoofing.

Notes a flooding exploit that might be used when there is dependence  
upon the i= identity in tracking behaviour.

These topics should be split out into separate threads if someone  
wishes to discuss these issues.

-Doug