Bug 1670 - Punycode not implemented (internationalized domain name - IDN)
Summary: Punycode not implemented (internationalized domain name - IDN)
Status: REOPENED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Message View (show other bugs)
Version: 4.2.0
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL: http://bugs.debian.org/759283
: 1846 2287 3257 4555 4646 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-07-10 16:21 UTC by Bryan Jacobs
Modified: 2022-10-25 10:18 UTC (History)
7 users (show)

See Also:


Attachments

Description Bryan Jacobs 2008-07-10 16:21:14 UTC
When mail is received from an Internationalized Domain Name, it is displayed in the message view as Punycode.  This affects both the recipient and source addresses.

I'm not sure why claws-mail is linked against libidn if it's not going to get used.  I would expect to see translated UTF-8 characters there instead of ASCII, even though of course only 7-bit is allowed in the original email.
Comment 1 Paul 2008-07-10 17:28:50 UTC
If a message must be only 7-bit, it can't display those characters.

Or did I misunderstand something?
Comment 2 Paul 2008-07-10 17:30:48 UTC
(In reply to comment #1)
> If a message must be only 7-bit, it can't display those characters.

To be more syntactically correct, it can't contain those characters.
Comment 3 Bryan Jacobs 2008-07-10 17:50:52 UTC
Let me explain better:

Let's say my domain is xn--lfa.org (ĺ.org - not a real domain).  When I type "xn--lfa.org" into my browser's address bar, it does a DNS lookup for "xn--lfa.org", and that is the web site it goes to -- but it will display an l with an acute accent.  The purpose of the punycode is only to provide compatibility with applications that only support ASCII.

So, the analogy is like this:  Claws will receive an email that contains only ASCII characters.  To the user, however, it will render them as international characters.  This is the only way non-English languages could be supported without having to upgrade every mail server on the internet.

When I get an email from "foo@xn--lfa.org", I expect to see "foo@&#314;.org" in the "from" field.  When I try to send an email to "bar@&#314;.org", I expect claws-mail to greet the postfix server with "RCPT TO: <bar@xn--lfa.org>".  Currently, the message view shows punycode and sending an email with an IDN recipient results in an SMTP error.
Comment 4 Bryan Jacobs 2008-07-10 17:53:11 UTC
By the way, I think the behavior I'm describing is standard - for instance, if I view the EXACT SAME message through the Zimbra web interface, I see international characters.

And apparently this bugzilla also doesn't do UTF-8 because it represented my "l with acute accent" as "&#314;".  Just imagine the character there :-P.
Comment 5 Colin Leroy 2008-07-10 19:05:14 UTC
can you attach an example email?
Comment 6 Bryan Jacobs 2008-07-10 19:16:36 UTC
(In reply to comment #5)
> can you attach an example email?
> 

Example as requested (this should display an enya in both sender and recipient):

Date: Thu, 10 Jul 2008 14:14:33 -0500
From: Somebody <foo@xn--ida.org>
To: Somebody Else <bar@xn--ida.org>
Subject: IDN test
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This email has an IDN sender and recipient.
Comment 7 Bryan Jacobs 2008-07-10 19:18:46 UTC
By the way, Firefox only displays IDNs for certain (hardcoded) TLDs.  This is to prevent fraud (paypal.com using a cyrillic 'a' is the classic example).  But since email is unauthenticated anyhow, I don't think there's a concern here.  If the message is signed the signature will show up as punycode.  No worries.
Comment 8 Paul 2009-02-12 10:16:27 UTC
*** Bug 1846 has been marked as a duplicate of this bug. ***
Comment 9 Colin Leroy 2010-10-24 09:21:29 UTC
*** Bug 2287 has been marked as a duplicate of this bug. ***
Comment 10 Ricardo Mones 2014-08-25 08:42:09 UTC
*** Bug 3257 has been marked as a duplicate of this bug. ***
Comment 11 Paul 2015-09-20 09:46:40 UTC
*** Bug 3519 has been marked as a duplicate of this bug. ***
Comment 12 Paul 2021-12-10 10:47:01 UTC
*** Bug 4555 has been marked as a duplicate of this bug. ***
Comment 13 Paul 2022-10-25 09:23:50 UTC
*** Bug 4646 has been marked as a duplicate of this bug. ***
Comment 14 Marco Moock 2022-10-25 09:47:02 UTC
Is it intended to change that?
The display of the addresses is one thing, the non-working links another.
Comment 15 Paul 2022-10-25 10:18:53 UTC
They are 2 sides of the same coin.

Note You need to log in before you can comment on or make changes to this bug.