Subject: [EAI] design and display of non-ascii mailbox name

From: Soobok Lee <[email-masked]>
Date: Tue, 5 Dec 2006 10:13:30 +0900

MSIE 7.0/firefox 2.0 have a feature that displays IDN 
as its punycode form if the IDN is suspicious of 
phishing purpose or has some special characters in labels.

Then, in EAI context, what should MUA implementors do
for NON-ASCII localpart that is thought to be manufactured 
to confuse/fraud recipients?  For example, some localparts 
may contain space-like and @-like symbols or even a-like chars,
   
1)   c(cyrillic a)[email-masked]  
2)   c(cyrillic a)t@hotm(cyrillic a)il.com  
3)   cat@hotm(cyrillic a)il.com  

Do you have any idea about how to warn end users when they
received this From: address or are about to reply to
this sender address?

Soobok

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Soobok Lee <[email-masked]>
Date: Tue, 5 Dec 2006 12:26:25 +0900

> 3)   cat@hotm(cyrillic a)il.com  

one of my self-answers is MUA's  displaying
 cyrillic a in localpart ==> %u0430
 cyrillic a in hostname  ==> entire hostname in punycode form 
 (cyrillic a has U+0430 code number).

any other recommendation ?

Soobok

---

From: Martin Duerst <[email-masked]>
Date: Tue, 05 Dec 2006 13:01:34 +0900

>received this From: address or are about to reply to

It's a user interface issue, so we don't need a standard.
The main point is that users see that something is wrong.
I hope that hotmail and friends keep their act together
and don't allow registration of such local parts anyway.

Regards,     Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Soobok Lee <[email-masked]>
Date: Tue, 5 Dec 2006 15:55:09 +0900

> It's a user interface issue, so we don't need a standard.

Of course, it's a user interface issue. But, past IDNA RFC
also recommended (not required) displaying in puny code form 
when needed, for example,when fonts are not available for IND
labels. So touching some user interface issue may be included
in RFC in special case. 

Even in EAI, if MUA find no available fonts for localparts,
some actions may be needed as in the case of IDNA.
We have no ACE encoding, so, we should instead choose 
a hexadecimal notation or else somethign equivalent one.

%uXXXX is very good common hex notation.
 
> The main point is that users see that something is wrong.

Yes.

> and don't allow registration of such local parts anyway.

I am curious whether  IDN hotm(cyrillic a)il.com  can
be registered  or not *NOW*.

Once we (JET) had released CJK registration guideline
so that less confusible CJK domain names are registerd
in TLD registries. I don't know GTLD registries respect
that guildeline, while eastern asian ccTLDs might have 
done so.

Soobok

---

From: Martin Duerst <[email-masked]>
Date: Tue, 05 Dec 2006 17:26:52 +0900

>%uXXXX is very good common hex notation.

So are many other, similar ones. Some display systems
even have the ability to display four hex digits in
a 2x2 block the same hight as usual characters.
That happens at a much lower level than the application
program, so there is no point in us specifying it.

>be registered  or not *NOW*.

I'd assume that Verisign learned a lot from the
p(cyrillic a)ypal.com incident. Making a mistake
once can happen to everybody; repeating the same
mistake would be really bad.

>that guildeline, while eastern asian ccTLDs might have 

My understanding is that .jp doesn't apply JET guidlines.
I don't know about .com and friends.

Regards,    Martin.

---

From: Soobok Lee <[email-masked]>
Date: Tue, 5 Dec 2006 17:56:25 +0900

> program, so there is no point in us specifying it.

BTW, I know your IRI (in W3C) draft had defined  some %-escaping
conventions for i18ned hostname and path part of i18ned
Resource Indicator in order to be put into <a href="(iri)">. 

Would you tell us about that experience?

Soobok

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Dec 2006 16:12:23 +0100

Soobok Lee wrote:

 [u+1234, IRIs, and other creatures]
> Would you tell us about that experience?

For an IRI you parse it into its parts, scheme, authority,
path, query, etc.  The scheme is supposed to be US-ASCII.

The authority might contain a host name, for that you'd
use IDNA(bis) "punycode", with the xn--what-ever format
for the labels.  For the rest transform local charset to
Unicode, Unicode to UTF-8, and percent-encode it as needed
(keeping most ASCII VCHARs as is).  Put it together again
as parsed, and you've got the corresponding URL.

Not very friendly for human readers if they have to look
at the URL instead of the IRI, because UTF-8 is modulo 64
magic.

In mail you could use a friendlier format for say a local
part, decode UTF-8 to Unicode, display all code points
also available in the local charset excl. "=" as is, and
for the rest use the somewhat familiar =12=34 QP-style,
with =3D for a real "=".

No showstopper.  The most critical EAI point are IMO the
"MIME considerations", when John reported a decisive
"ick" from an expert.

Frank

---

From: Martin Duerst <[email-masked]>
Date: Wed, 06 Dec 2006 18:39:13 +0900

>as parsed, and you've got the corresponding URL.

You can convert to an URI without parsing an IRI, just
by converting Unicode->UTF-8->%-encoded (leaving US-ASCII
as is). The IRI spec also allows using punycode for those
cases where an implementation knows the scheme and knows
that it deals with a domain name.

>at the URL instead of the IRI, because UTF-8 is modulo 64

Modulo anything, even simple hex, is not human-friendly.

>for the rest use the somewhat familiar =12=34 QP-style,

That won't fly. You can't distinguish two == in a row
from U+3D3D (or will have some other problem, depending
on how exactly you define your scheme).

Regards,    Martin.

---

From: Soobok Lee <[email-masked]>
Date: Thu, 7 Dec 2006 00:06:55 +0900

> >also available in the local charset excl. "=" as is, and

If MUA "knows" which local charsets are being used in users'
computing environment, we MAY display in alternative forms
those unfamilar/exotic character for users.

> on how exactly you define your scheme).

As Martin and Frank suggested, there may be good multiple hex 
notations on the table or MUA's own innovative method of 
alternative display of exotic/suspicious localparts.

Unlink that of IDNA, we have no "fallback" ACE encoding.
I welcome any suggestion from your about most desired 
wording for this.

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Thu, 7 Dec 2006 00:11:52 +0900

> Unlink that of IDNA, we have no "fallback" ACE encoding.

I am sorry for this late correction:

  Unlike the case of IDNA, we have no "fallback" ACE encoding
for EAI.

Soobok

---

From: Kari Hurtta <[email-masked]>
Date: 06 Dec 2006 18:15:54 +0200

> for the rest use the somewhat familiar =12=34 QP-style,

Or printing them in from `xxxx  using reverse video for example.

> Frank

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Dec 2006 18:38:20 +0100

> Modulo anything, even simple hex, is not human-friendly.

I like hex. or similar better than UTF-8 or B64, but for a
greater audience it's probably both "some kind of gibberish
different from ROT13".

 [pseudo-QP proposal]
> from U+3D3D

ACK, I forgot the delimiter problem -- embarassing, I read 
CHARMOD, but that was 2005... :-)  A possible choice is the
the &#x1234; notation.

Frank