[ietf-dkim] protecting domains that don't exist

[Douglas Otis]

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  
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