On Tue, 05 Aug 2008 21:52:47 +0100, John Levine <johnl(_at_)iecc(_dot_)com>
wrote:
We think that this version addresses all of the concerns brought up at
the
IETF 72 meeting, so I sure hope it's done.
OK, after a careful read through, a few typos and one item needing
clarification.
3. Operation Overview
independently on each address. This standard does not address the
^^^^^^^^
document
3.3. ADSP Results
An ADSP lookup for an Author Address produces one of four possible
results:
o Messages from this domain might or might not have an author
signature. This is the default if the domain exists in the DNS
but no record is found.
o All messages from this domain are signed.
o All messages from this domain are signed and discardable.
o The domain is not a valid mail domain.
^^^
This
However, this whole section promises four possible results, whereas 4.2.1
on the next page only provides three possible tags
(unknown/all/discardable). Not enough information for four results, and
the explanation is not given until Appendix A6. If we are not going to
have a tag "none", then I think the last two bullets in 3.3 ought to be
combined something like this:
o All messages from this domain are signed and discardable (this also
covers the case of a domain that neve sends email at all, and hence
never signs anything and presumably does not even publish a key).
And s/four possible/three possible/ of course.
4.3. ADSP Lookup Procedure
Check Domain Scope: An ADSP checker implementation MUST determine
whether a given Author Domain is within scope for ADSP. Given the
background in Section 3.1 the checker MUST decide which degree of
approximation is acceptable. The checker MUST return an
appropriate error result for Author Domains that are outside the
scope of ADSP.
I don't see how a standard can prescribe that you MUST do X when there is
no clear definition of exactly what X means nor of how it could be done.
Also, the whole section 4.3 ends rather abruptly. Perhaps there needs to
be some mention that, having fetched (or failed to fetch) and ADSP record
(a process which is described in some detail), it is then up to the
discretion of the checker what action to take as regards further handling
of the message in the light of that ADSP record, and that such actions are
not prescribed by this document.
6.1. ADSP Threat Model
Email abuse often seeks to exploit a legitimate email author's name-
recognition among recipients, by using the author's domain name in
^^^
that
the From: header field. ...
ADSP checkers may perform multiple DNS lookups per Alleged Author
Domain. Since these lookups are driven by domain names in email
message headers of possibly fraudulent email, legitimate ADSP
checkers can become participants in traffic multiplication attacks.
I am not at all clear just how such an attack would work. Perhaps someone
who knows could suggest a better wording.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html