On Oct 20, 2008, at 1:57 AM, [EMAIL PROTECTED] wrote: There is an alternative to the use of DNS existence that will allow use of wildcards and will not necessitate DNS existence tests. The alternative would be to define ADSP as applying to RFC5321.
> - Section 3.3, 1st bullet would be clearer if it said "...no ADSP > record is found" This would be incorrect. As currently defined, the ADSP draft requires any From header field domain to exist within DNS. Existence checks apply to all email, and are not limited to domains publishing ADSP records! > - Section 3.3, 4th bullet: this would be easier to understand it > said "because it does not exist in DNS", "this is the case if the > domain does not exist in DNS", or something When the From header field does not exist within DNS, the domain is "out-of-scope". For this to control abuse, "out-of-scope" will need to be interpreted as having the same state as 3rd bullet! Again, defining ADSP as applying to RFC5321 eliminates a need for the dubious "out-of-scope" state, since ADSP would only be valid for domains that support RFC5321. > - Section 3.3, should mention the 5th possibility of the procedure > in 4.3: algorithm terminates without producing a result, indicating > a temporary failure. A temporary failure would be a mistake. The lack of DNS records for a From header field domain is unlikely to change at a later time. > - Section 4.2.1: Since the signing practice list is extensible, the > text should say how an unknown value should be treated -- probably > same as "unknown"? While this list might be considered extensible, an "unknown" status is unlikely a desired default. Extensions are likely to require the use of a different tag. > - Section 4.3, "Check Domain Scope" step: it'd be useful to > explicitly say something "NODATA" (rcode=0 with ANCOUNT=0), as if I > recall right, even some WG members were confused at some point... It seems odd that ADSP fails to mention the use of RFC5321, but then goes into describing the DNS protocol API and what is meant by NXDOMAIN? A valid domain is already defined by RFC5321 section 2.3.5 Domain Names, and 5.1 Locating the Target Host! There is no current requirement that From header field domains resolve servers using DNS. This field may resolve servers that do not depend upon DNS, such as Microsoft Exchange. ADSP failing to define what "out-of-scope" processing means obscures the conflict created for all email, and not just email from domains publishing ADSP records. > - Section 4.3, "Fetch Named ADSP Record" step: it'd be useful to > say here that if the result is NXDOMAIN, or NOERROR with zero > records, or NOERROR with records that aren't valid ADSP records, > the result is "unknown" (is that right, BTW?) Per section 4.3 4.3 ADSP Lookup Procedure, an NXDOMAIN result is defined as being the "out-of-scope" state. In essence, some sort of message processing based upon whether the From header field resolves resource records in DNS. > - Section 4.3, "does not exist for mail" would benefit from > rephrasing somehow (perhaps "is not a valid email domain for > [2821]", or something?) Agreed. The changes being recommended by http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-03.txt removes a need to impose domain requirements for the From header field. These changes allow the positive evidence of RFC5321 support to remove the confusion created by the lack of defined resource records. > - Section 4.3: would this be easier to read if you included a > concrete example (e.g. email message with a From line, and all the > DNS lookups done)? Or perhaps couple of examples? > > - Section 6.1, last paragraph: to me it seems the amount of DNS > traffic would be less than amount of SMTP traffic, so this wouldn't > be a very good traffic multiplication attack? (with multiplier < 1) > If that's the case, perhaps would be useful to mention? Wrong. Due to wildcard related issues and the lack of defined specific DNS resource records that pertains specifically to ADSP processing, a fair amount of DNS traffic might be generated when recipients attempt to mitigate issues created by wildcards. There are no limits as to the number of signatures that might be applied to a message, and there can be a number of parent domains where a wildcard might be published. ADSP even requires multiple signatures where one previously could have been sufficient whenever an "on-behalf-of" conflicts with ADSP's Author Signature definition. A minor change to the Author Signature definition safely eliminates a need for an additional signature. The general goal of ADSP should be to ensure that the signing domain controls the From header field. MTAs and MUAs must interpret which message elements relate to DKIM signature's "on-behalf-of" and domain before applying annotations or weighing acceptance. ADSP should only require that a DKIM signature by an authoritative domain be present. Whether the From header field is able to resolve an RFC5321 server is a separate, and essentially new requirement, that does not belong in ADSP draft at all. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
