[ietf-dkim] Underscore considerations

[Bill.Oxley at cox.com]

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.org on behalf of Douglas Otis
Sent: Fri 6/9/2006 4:27 PM
To: Stephen Farrell
Cc: ietf-dkim at mipassoc.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=@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.domain.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.domain.tld

allows a signature of:

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

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

	joe at any-subdomain.domain.tld

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

or
	joe at another.any-subdomain.domain.tld

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

where 'another' or 'any-subdomain' is never validated as being real,  
and yet DKIM declares 'joe at any-subdomain.domain.tld' and  
'joe at another.any-subdomain.domain.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