On 4/13/11 12:23 PM, Dave CROCKER wrote: > On 4/13/2011 12:21 PM, John R. Levine wrote: >>> i'm also tempted to suggest using months in a different language, >>> with enero or >>> Januari... >> >> If you're going to change it, change it to 一月 or يناير > > not after i just got done trying to avoid unicode issues... DKIM has not properly considered the security ramifications related to IDN usage.
See http://tools.ietf.org/html/rfc6055#section-4 ,--- Instead, conversion to A-label form, or any other special encoding required by a particular name-lookup protocol, should be done only by an entity that knows which protocol will be used (e.g., the DNS resolver, or getaddrinfo() upon deciding to pass the name to DNS), rather than by general applications that call protocol-independent name resolution APIs. (Of course, applications that store strings internally in a different format than that required by those APIs, need to convert strings from their own internal format to the format required by the API.) Similarly, even if an application can know that DNS is to be used, the conversion to A-labels should be done only by an entity that knows which part of the DNS namespace will be used. '--- See http://tools.ietf.org/html/rfc4952#section-4.2 ,--- There are many places in MUAs or in a user presentation in which email addresses or domain names appear. Examples include the conventional From, To, or Cc header fields; Message-ID and In-Reply-To header fields that normally contain domain names (but that may be a special case); and in message bodies. Each of these must be examined from an internationalization perspective. The user will expect to see mailbox and domain names in local characters, and to see them consistently. If non-obvious encodings, such as protocol-specific ASCII-Compatible Encoding (ACE) variants, are used, the user will inevitably, if only occasionally, see them rather than "native" characters and will find that discomfiting or astonishing. Similarly, if different codings are used for mail transport and message bodies, the user is particularly likely to be surprised, if only as a consequence of the long-established "things leak" principle. The only practical way to avoid these sources of discomfort, in both the medium and the longer term, is to have the encodings used in transport be as similar to the encodings used in message headers and message bodies as possible. '--- The presumption of A-Label use within a domain name is likely wrong from a security or standardization perspective. It would be incorrect to expect email applications using standard resolving APIs will only accept A-Labels. Email should not depend upon an older view of a DNS limitation that does not exist. Although the definition for a domain made in section 2.3.5 of RFC5321 limits domains to ldh characters, this clearly represents an archaic definition in conflict with rfc6055 and rfc4952. Users that see punycode versions for the signing domain, in conjunction with the UTF-8 versions within email addresses are not afforded added comfort nor reliable assurances which resource had been selected when making the verification. http://tools.ietf.org/html/rfc5321#section-2.3.5 Clearly, this issue requires at minimum a section added that reviews the issue and consensus established in how this information is to be encoded. Clearly, the requirement to use A-labels binds DKIM to now an obsolete limitation. Remove the requirement to use A-labels since SMTP and resolvers can not be expected to enforce this type of restriction. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
