Web Key Directory handling of IDN
m at tthias.eu
Tue Nov 8 09:41:04 CET 2016
El 2016-11-07 20:17:19, Werner Koch escribió:
> Well, if a user decides to use non-ASCII adresses they need to live with
> the strict but impractical rules of RFC5322 which says that case folding
> may or may not happen.
In think that in the case the following rule from RFC6530, section 10.1
For the particular case of mailbox names that contain non-ASCII
characters in the local part, domain part, or both, special attention
MUST be paid to Unicode normalization [Unicode-UAX15], in part
because Unicode strings may be normalized by other processes
independent of what a mail protocol specifies (this is exactly
analogous to what may happen with quoting and dequoting in
traditional addresses). Consequently, the following principles are
offered as advice to those who are selecting names for mailboxes:
o In general, it is wise to support addresses in Normalized form,
using at least Normalization Form NFC. Except in circumstances in
which NFKC would map characters together that the parties
responsible for the destination mail server would prefer to be
kept distinguishable, supporting the NFKC-conformant form would
yield even more predictable behavior for the typical user.
o It will usually be wise to support other forms of the same local-
part string, either as aliases or by normalization of strings
reaching the delivery server: the sender should not be depended
upon to send the strings in normalized form.
o Stated differently and in more specific terms, the rules of the
protocol for local-part strings essentially provide that:
* Unnormalized strings are valid, but sufficiently bad practice
that they may not work reliably on a global basis. Servers
should not depend on clients to send normalized forms but
should be aware that procedures on client machines outside the
control of the MUA may cause normalized strings to be sent
regardless of user intent.
* C0 (and presumably C1) controls (see The Unicode Standard
[Unicode]) are prohibited, the first in RFC 5321 and the second
by an obvious extension from it [RFC5198].
* Other kinds of punctuation, spaces, etc., are risky practice.
Perhaps they will work, and SMTP receiver code is required to
handle them without severe errors (even if such strings are not
accepted in addresses to be delivered on that server), but
creating dependencies on them in mailbox names that are chosen
is usually a bad practice and may lead to interoperability
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: not available
More information about the Gnupg-devel