ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Underscore considerations

2006-06-09 07:12:05
On Fri, 2006-06-09 at 08:23 -0400, Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:

You want to ensure that wildcards and i,g tags can delimit subdomains,
is that correct?

The concern about conveying what is a validated email-address has little
to do with MX records using a wildcard.  This only relates to why did
this become a problem.  Allowing any subdomain within the i= parameter
is to accommodate a wildcard MX technique.  This is to reduce the burden
on the transmitter.  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.

Without a means to qualify whether this email-address's subdomains have
been properly synthesized (by an MUA application), less assurance of the
email-address becomes possible.  This increases the burden upon the
receiver.  It also means blocking, when there is a problem, can not
depend upon the validated email-address obtained from DKIM.  Blocking at
the signing-domain may be problematic when this causes extensive
collateral blocking of desired messages.  Ether the recipient adopts
local-part(_at_)[*(_dot_)]domain filters or uses selectors, while prior tools 
could
have otherwise been used.  As a result of the allowance, email-address
validation becomes far less meaningful.

Assume that a recipient expects to see the email-address validation  
annotation.  A bad actor that has obtained or compromised a key at  
this location could then sign messages and recipients could see all  
the email-address using *.com annotated as having been validated.
This validation, as currently defined in DKIM, is to be accepted.

-Doug


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