ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Underscore considerations

2006-06-10 21:34:11
At this point I tend to support Doug's position that we "allow" wildcard 
entries on both sides of the "@" to delimit abuse.
hanks,
Bill


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Douglas Otis
Sent: Fri 6/9/2006 4:27 PM
To: Stephen Farrell
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Underscore considerations
 

On Jun 9, 2006, at 7:34 AM, Stephen Farrell wrote:

Your first paragraph below is impossible for me, and I bet, others,  
to understand. If you're not clear you'll be ignored, most likely.  
Sorry to call this out on the list, but this is far from being the  
first time.

I'll try to explain it using examples.


The concern about conveying what is a validated email-address has  
little to do with MX records using a wildcard.

This was answering a question about delimiting wildcards, which was  
understood as delimiting an email-address that, upon delivery,  
references a wildcard MX.


This only relates to why did this become a problem.  Allowing any  
subdomain within the i= parameter is to accommodate a wildcard MX  
technique.

While any domain can sign a message where the key is located by the  
'd=' parameter, some signing domains also, as an option, want an  
email-address contained within the message to be annotated as  
"validated", or to display the "signing address."  As Dave Crocker  
correctly suggested "signing address" is not technically correct.  A  
more accurate term could have been email-address "validation  
template", but that does not sound as official. : (


This is to reduce the burden on the transmitter.

This (meaning the 'i=(_at_)subdomain' feature) is to consolidate the  
number of DNS records within a common location at a higher level  
subdomain.  The transmitter wants their email-addresses annotated as  
"validated" but also doesn't want to bother publishing a key  
referenced from the email-address domain.


By requiring a key be referenced from the email-address domain,  
this provides a means to validate the domain, while also limiting  
the scope of the key.

A requirement that a key be referenced from the email-address domain  
when this email-address is to be "validated" would mean:

        joe(_at_)subdomain(_dot_)domain(_dot_)tld

requires a signature of:

   DKIM-Signature:
     s=select; i=joe; d=subdomain.domain.tld;


By not having this requirement means the scope or the range of  
possible email-address subdomains a key can validate would be unlimited.

        joe(_at_)subdomain(_dot_)domain(_dot_)tld

allows a signature of:

   DKIM-Signature:
     s=select; i=joe(_at_)subdomain(_dot_)tld; d=domain.tld;

where the same key is free to also "validate" an email-address of:

        joe(_at_)any-subdomain(_dot_)domain(_dot_)tld

   DKIM-Signature:
     s=select; i=joe(_at_)any-subdomain(_dot_)tld; d=domain.tld;

or
        joe(_at_)another(_dot_)any-subdomain(_dot_)domain(_dot_)tld

   DKIM-Signature:
     s=select; i=joe(_at_)another(_dot_)any-subdomain(_dot_)tld; d=domain.tld;

where 'another' or 'any-subdomain' is never validated as being real,  
and yet DKIM declares 'joe(_at_)any-subdomain(_dot_)domain(_dot_)tld' and  
'joe(_at_)another(_dot_)any-subdomain(_dot_)domain(_dot_)tld' as "validated."


Of course, this lack of restriction requires that precautions be  
exercised, as a compromised or misused key may affect _all_ subdomains.


-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html