[UA-EAI] UASG014 - Quick Guide to EAI

Wed Jan 17 10:28:54 UTC 2018

Whenever we send an email to group addresses, in headers this gets represented as 

undisclosed-recipients:; 

This is also another way to represent BCC;

So, 

May be put EAI address as display name and

noncompatible-recipient:;. Or
Utf8-email-address:; or
Unsupported-email-address :; or
contact-email-admin :; 
Or something like that in angular brackets.. 

That way, we can deliver and display properly at recipient Server/Client. However technically we have touched the email address we don't own. 

Just for information, if you compose an email on gmail and type your address in BCC and nothing in TO, CC , see how you get headers..

Thanks. 

On 17 January 2018 06:16:02 GMT+05:30, Mark Svancarek via UA-EAI <ua-eai at icann.org> wrote:

[Comments inline]

-----Original Message-----
From: John R. Levine [mailto:johnl at iecc.com] 
Sent: Tuesday, January 16, 2018 4:22 PM
To: Mark Svancarek <marksv at microsoft.com>
Cc: Don Hollander <don.hollander at icann.org>; ua-eai at icann.org
Subject: RE: [UA-EAI] UASG014 - Quick Guide to EAI

     *   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.

[Mark Svancarek] It's not EAI specific, but it feels like something that might be more significant in an EAI setting.  Also, there are other alternatives that I didn't include, such as putting things inside quote marks; I see that from time to time and don't know when or why it was used.

  *   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.

 [Mark Svancarek] Good point.  This only applies to non-compatible clients, and we are asking them to do only one thing - support EAI. Please disregard this example.

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 <http://40microsoft.com> %7C936e38e36e874481fadd08d55bda6
 1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636515915867149370&sd
 ata=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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=02%7C01%7Cmarksv%40microsoft.com%7C5400c036d8b04819f69c08d55d4049da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636517453053962352&sdata=qCzrqdPvuc8qwgnF4wRQc%2BfeYoQM%2BMZL4DDTWXtZpww%3D&reserved=0> &data=02%7C01%7Cmarksv%40microsoft.com%7C5400c036d8b04819f69c08d55d4049da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636517453053962352&sdata=qCzrqdPvuc8qwgnF4wRQc%2BfeYoQM%2BMZL4DDTWXtZpww%3D&reserved=0

  _____  

UA-EAI mailing list
UA-EAI at icann.org
https://mm.icann.org/mailman/listinfo/ua-eai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-eai/attachments/20180117/1e189451/attachment-0001.html>