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