On Oct 20, 2008, at 1:57 AM, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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