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