On Apr 22, 2008, at 2:42 AM, Charles Lindsey wrote:
On Mon, 21 Apr 2008, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
The current ADSP algorithm establishes DKIM signing compliance by
qualifying From header email-address domains. This qualification
process ensures NXDOMAIN are not returned in response some DNS
transaction at the domain.
A) With a negative result, an NXDOMAIN response MUST return an
error (likely resulting in the rejection of the message).
But I thought we had already agreed that MUST was a mistake, and
needs to be relaxed (since it is outwith our remit). For sure there
is no consensus to retain it.
Using MUST or SHOULD is not significant, since protection would not be
obtained when a From email-address domain is not SMTP deliverable, and
not just whether a domain exists within DNS.
B) With a positive result, not finding an NXDOMAIN implies a valid
domain without policy when policy records are not found below this
or the parent's domain at "_adsp._domainkey."
That's OK. Once you have established that the domain exists in the
DNS, then you are free to look for an associated ADSP policy.
Synthesized records might exist, but these records might not be
indicative of intent to publicly send or receive ADSP covered messages.
But all that is true regardless of whether the transport is SMTP or
something else.
SMTP defines specific records that MUST exist for SMTP service
discovery. Not all records implies a service that _might_ be covered
by ADSP. In addition, it is absurd to suggest ADSP ALL policy covers
_any_ transport. It would be reasonable to expect SMTP exchanged
messages are covered by an ADSP ALL assertion. It is _extremely_
important to define the scope of the ADSP ALL policy, or this might
disrupt other public exchange protocols not currently employing DKIM!
The overwhelming majority of messages carried by SMTP both abuse
recipients and those spoofed as message sources. In general, DKIM
is not the only SMTP extension adding a separate policy.
DKIM is NOT an "SMTP extension". It is an RFC2822 extension, and
arguably a DNS extension.
DKIM may used in conjunction with SMTP. Like it or not, ADSP _is_ an
SMTP extension. Otherwise, ADSP MUST list _all_ public exchange
protocols that MUST incorporate DKIM before asserting an ADSP ALL
policy.
How does ADSP recognize distinctly different TLDs and unknown
protocols? Why not extend this logic to SMTP as well? Such as:
If some TLDs are known not to be accessible via the DNS (which case
does not arise today), then that is a future problem which the
Internet will have to worry about.
Domains used in the From email-addresses may involve local name
resolution, for example. This is not only an issue for the future.
It is way above the level that this WG should be worried about. It
may well turn out to be a matter verifiers will need to consider
when faced with a From header containing an NXDOMAIN, but as I said
above that case is outwith our remit too (though it might merit a
non-normative mention, just to show that its omission was not an
accident).
Determining whether the From email-address is SMTP deliverable offers
much greater security. In addition, a convention to terminate policy
searches when MX records are absent offers SMTP receivers and spoofed
domains greater protection from undesired traffic. These significant
benefits are lost by suggesting ADSP is independent of SMTP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html