ietf-dkim
[Top] [All Lists]

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

2008-04-22 02:48:29
On Mon, 21 Apr 2008 18:45:53 +0100, Douglas Otis 
<dotis(_at_)mail-abuse(_dot_)org>
wrote:

On Apr 19, 2008, at 11:36 AM, Charles Lindsey wrote:

DNS yes, but why SMTP? SMTP is not the problem. It is DNS that is
(possibly) a problem. DKIM already relies on DNS, so I see no reason
why ADSP should differ.

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.

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.

But all that is true regardless of whether the transport is SMTP or
something else.

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.

It would be utterly stupid if someone invented a naming space with
the same syntax as domain names but using something other than DNS,
and then let those names wander around freely on the internet. At
the very least, any such scheme MUST use some TLD(s) distinct from
any that is approved for DNS usage by ICANN.

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 nternet will
ahve to worry about. 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).



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>