[UA-EAI] UASG014 - Quick Guide to EAI

[John R. Levine]

>     *   Suppose a system replaces an address with a punycode equivalent or MIME equivalent.

When you get mail from xn--ls8ha at outlook.com (a real address, try it) that 
may look like punycode, but it's not.  There is no way to tell whether 
some address in a header was mangled by a previous step or if so, how to 
unmangle it.  The reasonable approach is to do what the MUA normally does, 
show some combination of the display name and the unmodified actual 
address since that's most likely to be right.

>        *   (They shouldn't do that, but we are robust and can accept it.... it's just ascii, after all.)
>        *   If the message includes a friendly-from string, we can display as
>           *   Friendly Name <randomasciicrap at moreasciicrap>
>        *   … or, as just
>           *   Friendly Name
>        *   … or something else.
>        *   The former seems better to me.  What is the UASG preferred practice?

I don't see how this is EAI specific.  Personally I always prefer to see 
both the comment and the real address, but a lot of mail programs written 
in the Redmond WA area only show the comment, unrelated to whether it's an 
EAI address.

>  *   Example 2:
>     *   When UTF8 is received on a non-EAI-compatible client or via a
>       non-EAI-compatible service on the CC line, it will usually show
>       the right characters (fonts are often managed by the OS, not the
>       app), but Reply and Reply All will fail.

It does not seem like a good idea to encourage people to spend any time 
applying band-aids to their non-EAI clients.  If they want to handle EAI, 
they should fix their software to handle EAI, a position we came to in the 
IETF EAI group after everything else turned out to be unworkable.

I agree since a lot of MTAs are mostly 8-bit clean in some cases the UTF-8 
headers may arrive intact, but I wouldn't want to count on it.

>        *   I think John mentioned that ":;" is used in this case, sorry if I captured that wrong.

Yup, that's an empty address group.  There are two RFCs about POP/IMAP 
servers downgrading mail so that non-EAI mail clients can at least see 
their mail.  One tries to be very clever with reversible transformations, 
which I think is the wrong place to put effort, the other just smashes 
headers down to something legit without worrying too much about the 
semantics.  Putting the real addrss in the display name is reasonable. 
The :; tells the MUA that there's no addresses there so if you try to 
reply, there's nothing to reply to.


>        *   Is this the best way to convey to the user that Reply is unavailable?
>
>
>
> -----Original Message-----
> From: UA-EAI [mailto:ua-eai-bounces at icann.org] On Behalf Of John R. Levine
> Sent: Sunday, January 14, 2018 9:39 PM
> To: Don Hollander <don.hollander at icann.org>
> Cc: ua-eai at icann.org
> Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI
>
>
>
> On Sat, 13 Jan 2018, Don Hollander wrote:
>
>
>
>> 2) I’ve added a section identifying which fields need to be considered
>
>>    when doing EAI retrofitting.  Can someone provide such a list?  Are
>
>>    there also tasks/functions that we need to apply?
>
>
>
> For sending, all you have to do is to handle UTF-8 text in addresses in From:, To:, Cc:, Sender:, Reply-To:, and Resent-*:.  But RFC 6532 also says that you can use UTF-8 nearly everywhere that used to require ASCII, so the display names, Subject: line, and message body can also be UTF-8, so you better be prepared to handle that on incoming mail even if you don't send it.  Also, when doing attachments, if your mail program can attach one message to another, e.g., forward as an attachment, it needs to check if the message being forwarded is EAI and if so attach is as message/global rather than message/rfc822.
>
>
>
> It's probably also worth mentioning a few things not to change.  Don't change the Date: header, since it's in a rigid format intended to be parsed and redisplayed by MUAs.  (Mine displays dates in the local timezone, adjusting appropriately.)  Don't change Message-IDs, they're for computers, not people.
>
>
>
>> 3) Should we identify UASG Good Practices where they are not addressed
>
>>    one way or another within the RFCs?  Eg Aliasing vs ‘downgrading’ on
>
>>    the fly.
>
>
>
> Aliasing is the only thing that comes to mind.
>
>
>
> Regards,
>
> John Levine, johnl at iecc.com<mailto:johnl at iecc.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=02%7C01%7Cmarksv%40microsoft.com%7C936e38e36e874481fadd08d55bda61bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636515915867149370&sdata=scv26qwi2VaZBitByBFyU%2FrOTaIGvdWosG5uo0%2BzbyI%3D&reserved=0
>

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly