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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html