On 4/15/11 7:25 PM, John R. Levine wrote: >> 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. > > Wow. This change would both be incompatible with 4871, and would put > non-ASCII 8-bit characters into DKIM-Signature: headers, thereby > making them invalid under RFC 5322 and getting them smashed by any > 7bit MTA. A and AAAA records serve as a discovery mechanism for SMTP rather than using MX records to ensure independence from DNS. For both OS X and Windows local name resolution services use UTF-8. Should email be expected to work between two hosts having non-ASCII host names resolved using UTF-8?
When SMTP allows the display of non-ASCII local-parts, the domain portion should also use UTF-8 as well. The DKIM verification process should therefore confirm the proper conversions. No one expects people to visually validate signatures, so why expect them to also validate puny-codes? What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about FQDN. Would http://バスケ指導.meblog.biz/ qualify as a FQDN? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
