[ietf-dkim] protecting domains that don't exist
dotis at mail-abuse.org
Tue Apr 22 11:09:26 PDT 2008
On Apr 22, 2008, at 2:42 AM, Charles Lindsey wrote:
> On Mon, 21 Apr 2008, Douglas Otis <dotis at mail-abuse.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
>> 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
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.
More information about the ietf-dkim