A radical idea for compatibility
Question: Is there any reason that clients should *not* punycode *all* addresses when sending messages and convert them back to proper Unicode at display time? Seems like this would unblock a lot of people from using internationalized email addresses. What do people think? Paul
Question: Is there any reason that clients should *not* punycode *all* addresses when sending messages and convert them back to proper Unicode at display time?
Yes. For one thing, it would break mail to the majority of mail users who use ASCII mail clients. For another, the local parts of mail addresses are not always convertible to punycode, or if they are, there is a non-reversible canonicalization step so if you undo the punycode, you'll end up with the wrong local part and it won't be deliverable. R's. John PS: It probably isn't a big surprise that this isn't the first time this suggestion has come up.
12 Dec 2017, в 17:47, John R. Levine <johnl@iecc.com> написал(а):
Question: Is there any reason that clients should *not* punycode *all* addresses when sending messages and convert them back to proper Unicode at display time?
Yes.
For one thing, it would break mail to the majority of mail users who use ASCII mail clients.
Would it break them any worse than keeping the addresses in Unicode? In practice I have only seen places that choke on Unicode but go through fine with punycode, not the opposite.
For another, the local parts of mail addresses are not always convertible to punycode,
Can you elaborate?
or if they are, there is a non-reversible canonicalization step so if you undo the punycode, you'll end up with the wrong local part and it won't be deliverable.
R's. John
PS: It probably isn't a big surprise that this isn't the first time this suggestion has come up.
For one thing, it would break mail to the majority of mail users who use ASCII mail clients.
Would it break them any worse than keeping the addresses in Unicode?
Uh, what? EAI mail is defined by RFCs 6530 through 6533. One of the things they make crystal clear is that the EAI mailstream, with Unicode addreses, is separate from the ASCII mailstream. We tried for a decade to come up with clever ways to downgrade addresses on the fly, all of which failed miserably in practice. It appears that you are suggesting we abandon the IETF standard EAI mail and invent something different. No. Or if you aren't, then I don't understand what you are suggesting. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Because local part can be mix of ascii and unicode, and RFC do not allow conversion of local part while downgrading..With this rule all the email clients are designed to not to expect local part as punycode Thanks On 13 December 2017 05:46:35 GMT+05:30, Paul Borokhov <borokhov@apple.com> wrote:
Question: Is there any reason that clients should *not* punycode *all* addresses when sending messages and convert them back to proper Unicode at display time?
Seems like this would unblock a lot of people from using internationalized email addresses. What do people think?
Paul _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
-- Sent from my Android device with XGenPlus.
Paul Borokhov writes:
Question: Is there any reason that clients should *not* punycode *all* addresses when sending messages and convert them back to proper Unicode at display time?
Even if this were a good idea (I think it's not) it's impractical by now. There are about 70,000 SMTP servers that advertise support for SMTPUTF8 now, and another million-plus that has the necessary code, but disabled in the configuration. Few of them use it, but they are deployed now and at god knows how many different sites. The majority of those are implemented according to the RFCs. None of the RFCs say "MTAs MUST regard punycode and UTF8 as equal for resolving aliases", "MUST regard punycode and UTF8 as equal for looking up local users" etc. Changing the definition of address equality/identity is sure to lead to interop pains. Arnt
participants (4)
-
Arnt Gulbrandsen -
Dr. Ajay Data -
John R. Levine -
Paul Borokhov