Internationalizing Mail Addresses in Applications

Paul Hoffman / IMC | 5 Feb 2004 01:58

Picon

New draft, new idea


Greetings again. Based on an idea originally proposed here by Keith 
Moore, I have created yet another proposal. See 
<http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least 
until the Internet Drafts directory gets it published.

This proposal starts were Adam and I did with IMAA (be client-only), 
but goes even further in making it unobtrusive. Basically, there is 
an optional map in the headers which tell an MUA how to display 
mailbox names in headers. Mailbox names remain the same: they just 
get displayed differently.

Comments welcome.

--Paul Hoffman, Director
--Internet Mail Consortium

Adam M. Costello | 6 Feb 2004 08:34

Re: New draft, new idea


> <http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>

Like a few others, I have a hard time seeing what this would provide
beyond what we already have with display names.

*************************************************************
In the following examples, ALLCAPS stands for non-ASCII text.
*************************************************************

With the address-map approach, I could send mail to several recipients
with

From: FULLNAME <user <at> DOMAIN>
Address-Map: user <at> DOMAIN,USER

where FULLNAME would be encoded as a MIME encoded-word, DOMAIN would be
encoded as an IDN ACE (in both places), and USER would be encoded using
UTF-8 & base64.

Recipients would see FULLNAME or its raw encoding depending on whether
they have MIME support.  Recipients would see DOMAIN or its ACE
depending on whether they have IDN support.  Recipients would see USER
or user depending on whether they have address-map support.

If I can already see FULLNAME and DOMAIN, how much added benefit do I
get from seeing USER instead of user?

If my MUA allows me to recall address book entries by typing in FULLNAME
(or part of it), how much benefit do I get from also being able to

(Continue reading)

Martin Duerst | 5 Feb 2004 20:45

Picon

Re: New draft, new idea

Hello Paul,

Overall, I'm glad you wrote up this proposal, even if I think
the main thing it does is show what we should not do.

At 16:58 04/02/04 -0800, Paul Hoffman / IMC wrote:

>Greetings again. Based on an idea originally proposed here by Keith Moore, 
>I have created yet another proposal. See 
><http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least 
>until the Internet Drafts directory gets it published.
>
>This proposal starts were Adam and I did with IMAA (be client-only), but 
>goes even further in making it unobtrusive. Basically, there is an 
>optional map in the headers which tell an MUA how to display mailbox names 
>in headers. Mailbox names remain the same: they just get displayed differently.

I have looked at this draft. I currently fail to see any serious functionality
that this is really adding. We already have display names that can be in
any language/script we want. There are user agents that when they find a
display name, they almost completely isolate the user from the actual address
(MS Outlook Express is the one I know). And display names travel much
closer to the actual address, so the chance that the association gets
lost is clearly lower.

With this proposal, people in China or Japan or India,... will still
have to use ASCII addresses on their business cards, letterheads,...
even for language-internal communication. In that sense, the proposal
provides significantly less functionality even than the IMAA draft.

(Continue reading)

Paul Hoffman / IMC | 5 Feb 2004 22:19

Picon

Re: New draft, new idea

At 2:45 PM -0500 2/5/04, Martin Duerst wrote:
>We already have display names that can be in
>any language/script we want.

Display names are *not* mailbox names. Further, there is no 
interoperability between display names unless all MUAs looking at the 
message can display characters from the named character set.

>  There are user agents that when they find a
>display name, they almost completely isolate the user from the actual address
>(MS Outlook Express is the one I know).

And look how well that works.  Seriously, that functionality is 
one of the major causes of mail sent to the wrong people, because 
someone picked out an email "name" from their address book.

>  And display names travel much
>closer to the actual address, so the chance that the association gets
>lost is clearly lower.

That would only be true if the display names were universally 
displayable. They're not. In fact, it is the small minority that are 
encoded with UTF-anything.

>With this proposal, people in China or Japan or India,... will still
>have to use ASCII addresses on their business cards, letterheads,...
>even for language-internal communication. In that sense, the proposal
>provides significantly less functionality even than the IMAA draft.

(Continue reading)

Martin Duerst | 6 Feb 2004 00:04

Picon

Re: New draft, new idea

At 13:19 04/02/05 -0800, Paul Hoffman / IMC wrote:

>At 2:45 PM -0500 2/5/04, Martin Duerst wrote:
>>We already have display names that can be in
>>any language/script we want.
>
>Display names are *not* mailbox names.

Yes. But from an end-user's perspective, where exactly is the difference?
(using upper-case for non-ascii)
Currently, I can't tell a user (e.g. in Mexico) to send a mail to
JOSE <at> example.org. With the new proposal, I will still not be able to
tell somebody to send a mail to JOSE <at> example.org. In both cases, I
need to give jose <at> example.org.
Also, currently, I can have jose <at> example.org replaced (for users
with newer MUAs) with something like "JOSE RAMIREZ", or even
most probably "JOSE <at> example.org". (Never tried to put somethnig
that looks like an internationalized email address into a display
name; my guess is that according to standards, this should work,
but it may fail because of sloppy implementations.)

>Further, there is no interoperability between display names unless all 
>MUAs looking at the message can display characters from the named 
>character set.

Are you speaking about the fonts/glyphs needed for display?
Even with the new proposal, there is always the possibility
that your MUA doesn't have glyphs available to display a script
recently added to Unicode.

(Continue reading)

Paul Hoffman / IMC | 6 Feb 2004 01:28

Picon

Re: New draft, new idea


At 6:04 PM -0500 2/5/04, Martin Duerst wrote:
>>Display names are *not* mailbox names.
>
>Yes. But from an end-user's perspective, where exactly is the difference?

The difference exactly is that the display name can be changed or 
omitted when entering an email address and the mail still gets to the 
correct destination. Display names are optional and have nothing to 
do with mail transmission.

>(using upper-case for non-ascii)
>Currently, I can't tell a user (e.g. in Mexico) to send a mail to
>JOSE <at> example.org. With the new proposal, I will still not be able to
>tell somebody to send a mail to JOSE <at> example.org. In both cases, I
>need to give jose <at> example.org.

Huh? In what program? Mailbox names are case-sensitive. Some 
terminating SMTP servers will change case, but that's not part of the 
protocol.

>>Further, there is no interoperability between display names unless 
>>all MUAs looking at the message can display characters from the 
>>named character set.
>
>Are you speaking about the fonts/glyphs needed for display?
>Even with the new proposal, there is always the possibility
>that your MUA doesn't have glyphs available to display a script
>recently added to Unicode. Or are you speaking about the fact that 
>RFC 2047 allows different

(Continue reading)

Martin Duerst | 6 Feb 2004 23:46

Picon

Re: New draft, new idea

Hello Paul,

I think overall, Adam has expressed very well what I tried
to express in my first mail on this subject.

At 16:28 04/02/05 -0800, Paul Hoffman / IMC wrote:

>At 6:04 PM -0500 2/5/04, Martin Duerst wrote:
>>>Display names are *not* mailbox names.
>>
>>Yes. But from an end-user's perspective, where exactly is the difference?
>
>The difference exactly is that the display name can be changed or omitted 
>when entering an email address and the mail still gets to the correct 
>destination. Display names are optional and have nothing to do with mail 
>transmission.

Address-Map: headers and the additional display capabilities they
provide have nothing to do with mail transmission. The email gets
to exactly the same address totally independently of what's in
the Address-Map: header, or if there is one or not.

>>>Further, there is no interoperability between display names unless all 
>>>MUAs looking at the message can display characters from the named 
>>>character set.
>>
>>Are you speaking about the fonts/glyphs needed for display?
>>Even with the new proposal, there is always the possibility
>>that your MUA doesn't have glyphs available to display a script

(Continue reading)

Grant Baillie | 6 Feb 2004 03:39

Picon

Re: New draft, new idea


On 05 Feb 2004, at 4:28 PM, Paul Hoffman / IMC wrote:

> At 6:04 PM -0500 2/5/04, Martin Duerst wrote:
>>> Display names are *not* mailbox names.
>>
>> Yes. But from an end-user's perspective, where exactly is the 
>> difference?
>
> The difference exactly is that the display name can be changed or 
> omitted when entering an email address and the mail still gets to the 
> correct destination. Display names are optional and have nothing to do 
> with mail transmission.
>
>> (using upper-case for non-ascii)
>> Currently, I can't tell a user (e.g. in Mexico) to send a mail to
>> JOSE <at> example.org. With the new proposal, I will still not be able to
>> tell somebody to send a mail to JOSE <at> example.org. In both cases, I
>> need to give jose <at> example.org.
>
> Huh? In what program? Mailbox names are case-sensitive. Some 
> terminating SMTP servers will change case, but that's not part of the 
> protocol.

I think that by "(using upper-case for non-ascii)" Martin meant he was 
using uppercase to represent arbitrary non-ascii characters in the 
email addresses in his example.

--Grant

(Continue reading)

Grant Baillie | 5 Feb 2004 18:23

Picon

Re: New draft, new idea


On 04 Feb 2004, at 4:58 PM, Paul Hoffman / IMC wrote:

> Greetings again. Based on an idea originally proposed here by Keith 
> Moore, I have created yet another proposal. See 
> <http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least 
> until the Internet Drafts directory gets it published.
>
> This proposal starts were Adam and I did with IMAA (be client-only), 
> but goes even further in making it unobtrusive. Basically, there is an 
> optional map in the headers which tell an MUA how to display mailbox 
> names in headers. Mailbox names remain the same: they just get 
> displayed differently.

I'm new to the discussion, but here are some issues I see:

(1) What's to stop me from sending you a mail from some email address, 
using address-map: to change its display value to 
"support <at> your-bank.com", and asking you to reply with your credit card 
#? It seems that there's a potential for a new kind of social 
engineering attack here, unless MUAs are quite careful about how mapped 
addresses are displayed.

(2) So far as the following goes:

> Clearly, users of enhanced MUAs will expect to be able to enter mailbox
> names in the native scripts. Therefore, MUAs that follow this
> specification SHOULD keep mappings in their address book function.
> Similarly, MUAs that follow this specification MUST be able to add
> Address-map headers to outgoing mail messages.

(Continue reading)

Paul Hoffman / IMC | 5 Feb 2004 18:47

Picon

Re: New draft, new idea


At 9:23 AM -0800 2/5/04, Grant Baillie wrote:
>(1) What's to stop me from sending you a mail from some email 
>address, using address-map: to change its display value to 
>"support <at> your-bank.com", and asking you to reply with your credit 
>card #? It seems that there's a potential for a new kind of social 
>engineering attack here, unless MUAs are quite careful about how 
>mapped addresses are displayed.

The display name is only for the mailbox, so you have to already be 
able to receive mail at the same domain name in order to spoof. In 
your example, the sender has to be able to receive mail at 
your-bank.com in order for this ruse to work.

>I think there's more to it than just maintaining a mapping in the 
>client's local address book: Formats like vcard (and LDAP, I think) 
>would need to have some kind of standardized "display email address" 
>field to remain interoperable.

Why a "display email address" field? Why not just a second email 
address that has internationalized characters in the mailbox part?

>(3) There are implications for IMAP clients that fetch the ENVELOPE 
>message attribute to show message summary information: They wouldn't 
>be able to display addresses properly without issuing an extra 
>header fetch.

Good point.

--Paul Hoffman, Director

(Continue reading)

Grant Baillie | 5 Feb 2004 19:28

Picon

Re: New draft, new idea


On 05 Feb 2004, at 9:47 AM, Paul Hoffman / IMC wrote:

>
> At 9:23 AM -0800 2/5/04, Grant Baillie wrote:
>> (1) What's to stop me from sending you a mail from some email 
>> address, using address-map: to change its display value to 
>> "support <at> your-bank.com", and asking you to reply with your credit 
>> card #? It seems that there's a potential for a new kind of social 
>> engineering attack here, unless MUAs are quite careful about how 
>> mapped addresses are displayed.
>
> The display name is only for the mailbox, so you have to already be 
> able to receive mail at the same domain name in order to spoof. In 
> your example, the sender has to be able to receive mail at 
> your-bank.com in order for this ruse to work.

Oh, right. Still, I think there are possibilities for abuse (eg, 
spoofing upper management inside a company, or other users in large 
domains).

>> I think there's more to it than just maintaining a mapping in the 
>> client's local address book: Formats like vcard (and LDAP, I think) 
>> would need to have some kind of standardized "display email address" 
>> field to remain interoperable.
>
> Why a "display email address" field? Why not just a second email 
> address that has internationalized characters in the mailbox part?

Hmmm.... I guess that would work. MUAs would just have to be careful

(Continue reading)

Steve Hole | 5 Feb 2004 16:22

Re: New draft, new idea

On Wed, 4 Feb 2004 16:58:24 -0800 Paul Hoffman / IMC <phoffman <at> imc.org> 
wrote:

> This proposal starts were Adam and I did with IMAA (be client-only), 
> but goes even further in making it unobtrusive. Basically, there is 
> an optional map in the headers which tell an MUA how to display 
> mailbox names in headers. Mailbox names remain the same: they just 
> get displayed differently.
> 
> Comments welcome.

I like this idea *very* much.   Simple in concept, simple to implement, 
easy to deploy.    The only real downside to is the maintenance of the 
"canonical" ascii-only address which I'm sure that some people will have a
problem with just on principle.

This would work and could be made to work quite quickly.    At the very 
least it would be a good intermediate measure that might decide to stay 
for the long run.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:holes <at> ACIWorldwide.com>
Phone: 780-424-4922

(Continue reading)

Arnt Gulbrandsen | 5 Feb 2004 16:44

Picon

Re: New draft, new idea

Steve Hole writes:
> I like this idea *very* much.   Simple in concept, simple to 
> implement,  easy to deploy.    The only real downside to is the 
> maintenance of the "canonical" ascii-only address which I'm sure that 
> some people will have a problem with just on principle.

Business card designers are sure to grrrrumble... but I suppose a simple 
lookup protocol will do. After all, the lookup is only necessary when 
someone is copying a unicode address from a business card or other 
written source and the MUA needs the ascii-only one. I call that 
O(acceptable).

Arnt

John Cowan | 5 Feb 2004 06:05

Re: New draft, new idea


Paul Hoffman / IMC scripsit:

> This proposal starts were Adam and I did with IMAA (be client-only), 
> but goes even further in making it unobtrusive. Basically, there is 
> an optional map in the headers which tell an MUA how to display 
> mailbox names in headers. Mailbox names remain the same: they just 
> get displayed differently.

I think this is the best idea yet.  It will need some enhancement to
specify the legal character set (presumably the same as in IDNA)
in the displayedLHS.

The only downside I see is that users will have to publish two
email addresses in places like business cards (the hard copy kind),
and people who naively enter the wrong one into their down-level
clients will get bounces or other bad results.  In addition, 
if an email-address-assigner screws up and hands out the same displayedLHS
twice, we may have two mailboxes that appear to have the same address
at the MUA level.

--

-- 
John Cowan                              <jcowan <at> reutershealth.com>
http://www.ccil.org/~cowan              http://www.reutershealth.com
Unified Gaelic in Cyrillic script!
        http://groups.yahoo.com/group/Celticonlang

Paul Hoffman / IMC | 5 Feb 2004 18:41

Picon

Re: New draft, new idea

At 12:05 AM -0500 2/5/04, John Cowan wrote:
>In addition,
>if an email-address-assigner screws up and hands out the same displayedLHS
>twice, we may have two mailboxes that appear to have the same address
>at the MUA level.

Not at all. The display name has no connection to the mailbox name 
anywhere other than in the MUA. Therefore, two people at ccil.org 
could say the display name for their two different mailboxes is 
"José". The display is local to the MUA reading the message.

--Paul Hoffman, Director
--Internet Mail Consortium

Martin Duerst | 5 Feb 2004 20:57

Picon

Re: New draft, new idea

At 09:41 04/02/05 -0800, Paul Hoffman / IMC wrote:

>At 12:05 AM -0500 2/5/04, John Cowan wrote:
>>In addition,
>>if an email-address-assigner screws up and hands out the same displayedLHS
>>twice, we may have two mailboxes that appear to have the same address
>>at the MUA level.
>
>Not at all. The display name has no connection to the mailbox name 
>anywhere other than in the MUA. Therefore, two people at ccil.org could 
>say the display name for their two different mailboxes is "Jose'". The 
>display is local to the MUA reading the message.

Well, in theory, this is true. However, as far as I understand, the
Address-map headers and therefore these mappings travel from one
MUA to another. So conflicts would inevitably arise, either by having
the MUA keep two mappings with the same display LHS but different
ascii addresses (which would sooner or later have the wrong thing
sent to the wrong mailbox because the user cannot distinguish
these two), or by the MUA saying "You've got mail. By the way,
there is an Address-map header for =Jose' <at> example.com= different
from the one I already have, should I overwrite the mapping?".

Neither alternative sounds good to me at all.

Regards,    Martin.

jcowan | 5 Feb 2004 18:46

Re: New draft, new idea


Paul Hoffman / IMC scripsit:

> Not at all. The display name has no connection to the mailbox name 
> anywhere other than in the MUA. Therefore, two people at ccil.org 
> could say the display name for their two different mailboxes is 
> "José". The display is local to the MUA reading the message.

Ah, I didn't understand this.  Then why not handle it as a fullname comment,
rather than something masquerading as a mailbox name?  All that would be
required is some escaping convention for RFC 2822 comments.

--

-- 
What is the sound of Perl?  Is it not the       John Cowan
sound of a [Ww]all that people have stopped     jcowan <at> reutershealth.com
banging their head against?  --Larry            http://www.ccil.org/~cowan

Return

Return to gmane.ietf.imaa.

Project Web Page

Internationalizing Mail Addresses in Applications

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane