Stephen Farrell wrote: > http://tools.ietf.org/wg/dkim/draft-ietf-dkim-ssp/
----------------------------------------------------------------- - matches the ABNF for a "tag-list" and includes a valid "dkim" tag. + matches the ABNF for a "tag-list" and starts with a "dkim" tag. ----------------------------------------------------------------- - background in Section 3.1 the checker MUST decide which degree of + background in Section 3.1 the checker decides which degree of Already reported earlier, IIRC. ----------------------------------------------------------------- - query to fetch the Named ADSP Record. If the result of this query + query to fetch the named ADSP Record. If the result of this query Another occurence later, maybe s/Named/named/g (?) ----------------------------------------------------------------- - If a query results in a "SERVFAIL" error response, the algorithm + Otherwise the agorithm Already reported earlier: NXDOMAIN at this point is not different from SERVFAIL. If that's supposed to be a subtle hint at TEMPERROR processing for SERVFAIL maybe add an "Otherwise" covering NXDOMAIN after the SERVFAIL blurb. ----------------------------------------------------------------- - cases, new values are assigned only for values that have been - documented in a published RFC that has IETF Consensus [RFC5226]. + cases, new values are assigned only for values after IETF review + as specified in [RFC5226]. RFC 5226 intentionally *renamed* IETF consensus to IETF review, this covers publication as RFC among other things. ----------------------------------------------------------------- - Domains that intend to make active use of ADSP by publishing a - practice other than Unknown are advised to avoid the use of - wildcards elsewhere in their hierarchy. Strike that, wildcards elsewhere can never overlap, or can they ? ----------------------------------------------------------------- - Hence a domain MUST NOT publish wildcard ADSP records. + Hence a domain SHOULD NOT publish wildcard ADSP records. The whole point of the "must start with dkim" discussions was to make wildcards possible for publishers inisting on this "feature". ----------------------------------------------------------------- All occurences of "discardable" should be replaced by a better term, e.g., "suspicious" in old drafts was better. "Discard" could cause losses of legit resent mails. The issue itself - independent of its name - should be mentioned in the security considerations. ----------------------------------------------------------------- The terms SERVFAIL, NXDOMAIN, and NOERROR should be explained where they are first used, e.g., NXDOMAIN (rcode=3, [RFC1035]). Please add a normative reference to RFC 1035 for this purpose, already reported several times. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
