While valid, the SSAC basically concluded we should not be using them: https://features.icann.org/ssac-advisory-use-emoji-domain-name So it would be very hard at the moment to push for any kind of change in spam filters. There is ongoing discussion in terms of acceptable characters and such, but that seems to be going nowhere fast. -- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES On April 11, 2019 8:48:48 AM GMT-03:00, Lars Steffen <lars.steffen@eco.de> wrote:

May I quote from the 2 March 2018:

...what we agreed to is that emojis are not part of the current standard for IDN/DNS. As such it is out of scope for UASG.

Lars

Von: UA-discuss <ua-discuss-bounces@icann.org> im Auftrag von Dr Ajay Data <ajay@data.in> Datum: Donnerstag, 11. April 2019 um 09:10 An: universal access <ua-discuss@icann.org> Betreff: [UA-discuss] interesting to note about emoji in mailbox name.

Some Interesting things to note:

I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in

( ❤ - xn--qei and ♥ - xn--g6h )

When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message.

Probably, we need to discuss this too and have our views around it.

Dr. Ajay Data Founder & CEO

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove: [HID]20190411124031186[-HID] [Das Bild wurde vom Absender entfernt.][Das Bild wurde vom Absender entfernt.]

On 4/11/2019 11:39 AM, Mark Svancarek (CELA) via UA-discuss wrote:

Pedantically, I think Ajay is asking about mailbox names.  UASG and SSAC have historically weighed in against emojis in domain names.  But I think we have neglected to indicate that we oppose them in mailbox names as well. There is no equivalent of IDNA for mailbox names, so we could be more explicit about our opposition.

Mark, I definitely agree. If we run into violent opposition, because many users decide to view that restriction as churlish, there's a possible fallback: E-mail names, unlike domain names, already aren't treated as "exact match"; for example certain punctuation is ignored. A more restricted prohibition might give a better balance: insist that all emoji in an email name are treated as ignorable. That way, people can add them, as long as the remainder of the name contains a string of unique code points. You would be able to have I❤NYC, but not if someone else has INYC. This slightly more relaxed stance may be a useful fallback if we find that we cannot get traction with a full prohibition. A./ PS: this technique doesn't work as well with domain names as it would have to be implemented by registering all these variants, thus lead to combinatorial explosion.

*From:* UA-discuss <ua-discuss-bounces@icann.org> *On Behalf Of *Mark W. Datysgeld *Sent:* Thursday, April 11, 2019 07:09 *To:* ua-discuss@icann.org; Lars Steffen <lars.steffen@eco.de>; Dr Ajay Data <ajay@data.in>; universal access <ua-discuss@icann.org> *Subject:* Re: [UA-discuss] interesting to note about emoji in mailbox name.

While valid, the SSAC basically concluded we should not be using them: https://features.icann.org/ssac-advisory-use-emoji-domain-name <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffeatures.i...>

So it would be very hard at the moment to push for any kind of change in spam filters. There is ongoing discussion in terms of acceptable characters and such, but that seems to be going nowhere fast. -- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES

On April 11, 2019 8:48:48 AM GMT-03:00, Lars Steffen <lars.steffen@eco.de <mailto:lars.steffen@eco.de>> wrote:

May I quote from the 2 March 2018:

...what we agreed to is that emojis are not part of the current standard for IDN/DNS. As such it is out of scope for UASG.

Lars

*Von: *UA-discuss <ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org>> im Auftrag von Dr Ajay Data <ajay@data.in <mailto:ajay@data.in>> *Datum: *Donnerstag, 11. April 2019 um 09:10 *An: *universal access <ua-discuss@icann.org <mailto:ua-discuss@icann.org>> *Betreff: *[UA-discuss] interesting to note about emoji in mailbox name.

Some Interesting things to note:

I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in

( ❤- xn--qei    and ♥- xn--g6h )

When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades.

However If I send email to Gmail / Outlook, they consider this as  Spam.  Not only spam, Gmail displays the following warning. -

*This message seems dangerous*

The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message.

Probably, we need to discuss this too and have our views around it.

*Dr. Ajay Data** *Founder & CEO

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove: [HID]20190411124031186[-HID]

Das Bild wurde vom Absender entfernt.Das Bild wurde vom Absender entfernt.

An interesting side-effect of Asmus’ idea: We know that Google treats mark.svancarek@gmail.com<mailto:mark.svancarek@gmail.com> identically to marksvancarek@live.com<mailto:marksvancarek@live.com>, and our brains are okay with that. But if I point out that they are probably also treated identically to ma.rksvancarek@gmail.com<mailto:ma.rksvancarek@gmail.com> or even m.arksv.ancare.k@gmail.com<mailto:m.arksv.ancare.k@gmail.com>, I think people will have trouble grokking that, because it doesn’t meet our mental model of names. I think people might be upset that INYC, I❤NYC, IN❤YC, INY❤C and INYC❤ all resolve to the same mailbox, even though that confusion is ultimately harmless. From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Mark Svancarek (CELA) via UA-discuss Sent: Thursday, April 11, 2019 13:46 To: Asmus Freytag <asmusf@ix.netcom.com>; ua-discuss@icann.org Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. A more restricted prohibition might give a better balance: insist that all emoji in an email name are treated as ignorable. That way, people can add them, as long as the remainder of the name contains a string of unique code points. You would be able to have I❤NYC, but not if someone else has INYC. Asmus, this is a great idea. I don’t know what role UASG might have in promoting it, but I am personally game to try. Also, more people should use the word “churlish”. /marksv From: UA-discuss <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> On Behalf Of Asmus Freytag Sent: Thursday, April 11, 2019 12:15 To: ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. On 4/11/2019 11:39 AM, Mark Svancarek (CELA) via UA-discuss wrote: Pedantically, I think Ajay is asking about mailbox names. UASG and SSAC have historically weighed in against emojis in domain names. But I think we have neglected to indicate that we oppose them in mailbox names as well. There is no equivalent of IDNA for mailbox names, so we could be more explicit about our opposition. Mark, I definitely agree. If we run into violent opposition, because many users decide to view that restriction as churlish, there's a possible fallback: E-mail names, unlike domain names, already aren't treated as "exact match"; for example certain punctuation is ignored. A more restricted prohibition might give a better balance: insist that all emoji in an email name are treated as ignorable. That way, people can add them, as long as the remainder of the name contains a string of unique code points. You would be able to have I❤NYC, but not if someone else has INYC. This slightly more relaxed stance may be a useful fallback if we find that we cannot get traction with a full prohibition. A./ PS: this technique doesn't work as well with domain names as it would have to be implemented by registering all these variants, thus lead to combinatorial explosion. From: UA-discuss <ua-discuss-bounces@icann.org><mailto:ua-discuss-bounces@icann.org> On Behalf Of Mark W. Datysgeld Sent: Thursday, April 11, 2019 07:09 To: ua-discuss@icann.org<mailto:ua-discuss@icann.org>; Lars Steffen <lars.steffen@eco.de><mailto:lars.steffen@eco.de>; Dr Ajay Data <ajay@data.in><mailto:ajay@data.in>; universal access <ua-discuss@icann.org><mailto:ua-discuss@icann.org> Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. While valid, the SSAC basically concluded we should not be using them: https://features.icann.org/ssac-advisory-use-emoji-domain-name<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffeatures.icann.org%2Fssac-advisory-use-emoji-domain-name&data=02%7C01%7Cmarksv%40microsoft.com%7C858d90e7446e4e8eb83c08d6bebecde7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636906124048858525&sdata=wSOKzeAZEK69rFXrbdD4f8bqeXoAbVVhUv%2Fn%2FNx3rtU%3D&reserved=0> So it would be very hard at the moment to push for any kind of change in spam filters. There is ongoing discussion in terms of acceptable characters and such, but that seems to be going nowhere fast. -- Mark W. Datysgeld from Governance Primer [www.markwd.website<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.markwd....>] Representing businesses in IG together with AR-TARC and ABES On April 11, 2019 8:48:48 AM GMT-03:00, Lars Steffen <lars.steffen@eco.de<mailto:lars.steffen@eco.de>> wrote: May I quote from the 2 March 2018: ...what we agreed to is that emojis are not part of the current standard for IDN/DNS. As such it is out of scope for UASG. Lars Von: UA-discuss <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> im Auftrag von Dr Ajay Data <ajay@data.in<mailto:ajay@data.in>> Datum: Donnerstag, 11. April 2019 um 09:10 An: universal access <ua-discuss@icann.org<mailto:ua-discuss@icann.org>> Betreff: [UA-discuss] interesting to note about emoji in mailbox name. Some Interesting things to note: I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in ( ❤ - xn--qei and ♥ - xn--g6h ) When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message. Probably, we need to discuss this too and have our views around it. Dr. Ajay Data Founder & CEO [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]20190411124031186[-HID] [Das Bild wurde vom Absender entfernt.][Das Bild wurde vom Absender entfernt.]

You're quite mistaken about this. Formally, email address mailboxes are exact-match, but local convention can be anything the administrator wants. It is widely regarded as crazy to do case-sensitive matching, so for practical purposes ajs and AJS are the same mailbox. But they don't have to be. Google has ignored the "." in local-parts forever, but many systems used them as significant for a long time. The + convention is supposed to provide a primitive filtering capability, but many systems didn't implement. There are basically no rules for local parts. But we can rely on the UTC guidance that emojis are unsuitable for identifiers. A -- Andrew Sullivan Please excuse my clumbsy thums. On April 11, 2019 15:15:17 Asmus Freytag <asmusf@ix.netcom.com> wrote:

On 4/11/2019 11:39 AM, Mark Svancarek (CELA) via UA-discuss wrote:

...

Pedantically, I think Ajay is asking about mailbox names. UASG and SSAC have historically weighed in against emojis in domain names. But I think we have neglected to indicate that we oppose them in mailbox names as well. There is no equivalent of IDNA for mailbox names, so we could be more explicit about our opposition. Mark, I definitely agree. If we run into violent opposition, because many users decide to view that restriction as churlish, there's a possible fallback: E-mail names, unlike domain names, already aren't treated as "exact match"; for example certain punctuation is ignored. A more restricted prohibition might give a better balance: insist that all emoji in an email name are treated as ignorable. That way, people can add them, as long as the remainder of the name contains a string of unique code points. You would be able to have I❤NYC, but not if someone else has INYC. This slightly more relaxed stance may be a useful fallback if we find that we cannot get traction with a full prohibition. A./ PS: this technique doesn't work as well with domain names as it would have to be implemented by registering all these variants, thus lead to combinatorial explosion.

...

From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Mark W. Datysgeld Sent: Thursday, April 11, 2019 07:09 To: ua-discuss@icann.org; Lars Steffen <lars.steffen@eco.de>; Dr Ajay Data <ajay@data.in>; universal access <ua-discuss@icann.org> Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name.

While valid, the SSAC basically concluded we should not be using them: https://features.icann.org/ssac-advisory-use-emoji-domain-name

So it would be very hard at the moment to push for any kind of change in spam filters. There is ongoing discussion in terms of acceptable characters and such, but that seems to be going nowhere fast. -- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES On April 11, 2019 8:48:48 AM GMT-03:00, Lars Steffen <lars.steffen@eco.de> wrote: May I quote from the 2 March 2018:

...what we agreed to is that emojis are not part of the current standard for IDN/DNS. As such it is out of scope for UASG. Lars

Von: UA-discuss <ua-discuss-bounces@icann.org> im Auftrag von Dr Ajay Data <ajay@data.in> Datum: Donnerstag, 11. April 2019 um 09:10 An: universal access <ua-discuss@icann.org> Betreff: [UA-discuss] interesting to note about emoji in mailbox name.

Some Interesting things to note:

I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in

( ❤ - xn--qei and ♥ - xn--g6h )

When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message.

Probably, we need to discuss this too and have our views around it.

Dr. Ajay Data Founder & CEO

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove: [HID]20190411124031186[-HID]

Work life without emojis sounds boring to me, but I also understand that there are moments where they are not necessary. Emoji are not required by design, standard, or convention to be visually uniform (one code point displayed the same way in all circumstances) or visually distinguishable (different code points displayed in ways that permit them to be disambiguated regardless of context). As a result, a user will be exposed to problems of confusability and accessibility. Different code points that are rendered the same or one code point that renders differently to different users will lead to inconsistent results depending on the display or rendering technology used. Emoji modifiers and “glue” arrangements allow for a potentially much larger set of composed multi-codepoint symbols with even greater rendering variation and potential for ambiguous interpretation. A fundamental property of the DNS is that it is an exact-match lookup service. For a given query, either there is a single name that matches or there is no match. When two domain names are identical in appearance except for ordinary typographic style variations (which, at present, have no equivalent for emoji), but have different underlying code points, they identify two different DNS domains. It is unrealistic to expect that just because a code point is included in Unicode, it should be used as part of a domain name. We must deject usage of them in any part of domain or email address. Patrick On Thu, Apr 11, 2019 at 7:53 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

The UTC has been pretty clear that emojis are bad for identifiers. Email addresses are most certainly identifiers. QED.

Best regards,

A -- Andrew Sullivan Please excuse my clumbsy thums.

On April 11, 2019 03:11:04 Dr Ajay Data<ajay@data.in> wrote:

...

Some Interesting things to note:

I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in

( ❤ - xn--qei and ♥ - xn--g6h )

When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades.

However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. -

*This message seems dangerous*

The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message.

Probably, we need to discuss this too and have our views around it.

*Dr. Ajay Data*Founder & CEO

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove: [HID]20190411124031186[-HID]

What is missing is writing an actual statement that extracts from the useful statements posted here bye various people a single statement that squarely addresses the issue in the framework of email addresses and that could be the formal position of UASG on why or to what degree emoji fall outside the universal acceptance scope. BTW, the argument made by some people here that they represent an "inferior form" (my term) of communication compared to natural languages is rather weak and I prefer not to rely on it. The reason for avoiding emoji with color variants is that they are easily confusable. The same reasoning applies equally to mailbox names, domain names, and short URLs. By string I mean a sequence of Unicode code points. There are many reasons why two different strings might, when rendered, look identical or be difficult to distinguish (pointer-to-list) A simple measure of confusability for a string is the degree to which the process of attempting to transcribe a rendering of the sequence would result in a different sequence. Transcription involves recognizing the rendering of the string and being able to enter it. Those requesting names or issuing them, whether DNS names or mailbox names, SHOULD avoid names that are significantly confusable by a significant population, including strings that represent multiple scripts, emoji, or are unnormalized. Applications using IDNs such as email servers, web browsers etc. MAY flag e mail or URLs using such names as potentially malicious. Perhaps some kinds of emoji are unambiguous and easily entered by most and the guidance should change. -- https://LarryMasinter.net

If UASG were to recommend prohibiting emoji in mailbox names, are we referring strictly to emoji or more generally graphical characters such as wingdings and line drawing characters, etc.? We need to declare an explicit list of characters that should be avoided. As the argument against allowing emoji is largely based on confusability, I would recommend the prohibition be worded to say they should be avoided for now until such time as a sensible list of allowed emoji can be provided. There is sufficient demand that people will want to use certain emoji and the solution would be to allow a list of useful emoji that are not confusable. For example, a single heart emoji could be allowed so that people (or corporations or other entities) could use I♥NYC without mistaking how to enter or write it or confusing it with other similar looking characters. More generally, there needs to be a list of the characters that are allowed or disallowed in mailbox names, as that list may need to be different from domain names, and there are characters besides emoji that may be confusable or problematic in mailboxes. Tex

On Fri, 12 Apr 2019 20:29:27 +0200, Tex <textexin@xencraft.com> wrote:

If UASG were to recommend prohibiting emoji in mailbox names, are we referring strictly to emoji or more generally graphical characters such as wingdings and line drawing characters, etc.?

We need to declare an explicit list of characters that should be avoided.

A small detail - I think we rather should declare a whitelist of things that are acceptable.

As the argument against allowing emoji is largely based on confusability, I would recommend the prohibition be worded to say they should be avoided for now until such time as a sensible list of allowed emoji can be provided.

+1

There is sufficient demand that people will want to use certain emoji and the solution would be to allow a list of useful emoji that are not confusable.

Indeed.

For example, a single heart emoji could be allowed so that people (or corporations or other entities) could use I♥NYC without mistaking how to enter or write it or confusing it with other similar looking characters.

More generally, there needs to be a list of the characters that are allowed or disallowed in mailbox names, as that list may need to be different from domain names, and there are characters besides emoji that may be confusable or problematic in mailboxes.

Hmm. There is a core difference in assumptions here. For a domain, it is possible in principle for someone to register a different - but confusingly similar - domain. For an email address, the domain owner determines whether this problem can arise, and so the assumption is that they will fix it (unlike the assumption we make about domain registrars, in the parallel cases like Coremail, Yandex Mail, and so on). This needs thinking out, but "emoji are inferior to other characters and should not be used so that's the end of discussion" seems like an argument dangerously at odds with perceived reality. cheers Chaals -- Using Opera's mail client: http://www.opera.com/mail/

On Fri, Apr 12, 2019 at 11:29:27AM -0700, Tex wrote:

We need to declare an explicit list of characters that should be avoided.

No, you most certainly should not do this. You should do it the other way. The PRECIS guidelines are the approach to follow.

As the argument against allowing emoji is largely based on confusability

The argument against allowing emoji is based on the UTC's recommendations for identifiers, not confusability. This entire topic is well-trod ground. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

UASG has not endorsed emojis as part of mailbox names and I doubt that we ever would. But as mentioned below, some mail systems will take a more liberal approach. From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Tariq Soomro Sent: Thursday, April 11, 2019 10:36 To: ua-discuss@icann.org Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. Dear All, Are emoji's allowed to used? Emoji's are not part of International languages. regards, Prof. Tariq R. Soomro, Ph.D. Secretary IEEE Karachi Section, Senior Member IEEE, IEEE Computer Society, IEEE GRSS USA, Member PMI, Life Member Computer Society of Pakistan, Sindh Graduates Associations, Founder President SUCSA. https://scholar.google.com/citations?user=0zP5EYoAAAAJ&hl=en<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscholar.google.com%2Fcitations%3Fuser%3D0zP5EYoAAAAJ%26hl%3Den&data=02%7C01%7Cmarksv%40microsoft.com%7C28ba0bb2ef964222743808d6bea400c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636906008937886514&sdata=AP%2F1jMZdDl4KLAvg7AWkjgVuPUgOkXSeac%2FydEJloXI%3D&reserved=0> On Thu, Apr 11, 2019 at 10:21 PM Asmus Freytag <asmusf@ix.netcom.com<mailto:asmusf@ix.netcom.com>> wrote: On 4/11/2019 12:10 AM, Dr Ajay Data wrote: Some Interesting things to note: I am testing with Two working Valid Email Address with heart shape.. ❤@data.in<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdata.in&dat...> and ♥@data.in<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdata.in&dat...> ( ❤ - xn--qei and ♥ - xn--g6h ) When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous I tend to agree with these mail providers. Emoji have no place is security relevant contexts because their rendering is far from standardized and unless magnified, they can be hard to recognize. Also, users have no good idea whether related shapes might exist or not, so any deviation would be attributed to non-standard rendering and most likely accepted. Finally, many emoji involve sequences that may be displayed by some fall-back means on devices that do not happen to support them. This makes emoji similar to complex scripts, but that danger is underappreciated by many people because emoji have an emotional appeal and appear accessible because the are cute. They are dangerous in identifiers. The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message. Probably, we need to discuss this too and have our views around it. Dr. Ajay Data Founder & CEO [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]20190411124031186[-HID] [https://data.in/XGenPlusMessageID:15549666316034158a-][https://dlr.tbms.in/XET6399:201904.jpg]

Il 13 aprile 2019 alle 12.28 John Levine <john.levine@standcore.com> ha scritto:

One of the glaring holes in the EAI documents is that there is no practical advice on choosing mailbox names. We have developed conventions for ASCII names that LDH are fine, dots and plus signs and maybe apostrophes are OK, upper and lower case ASCII are generally interchagable, and beyond that you take your chances. We need appropriate guidance for mailbox names.

This is what I was thinking while reading this discussion: is it time to restandardize mailbox names in a more restrictive manner, recognizing de facto practices such as the above? Perhaps with a double layer, i.e. mailbox names that are allowed for the future and mailbox names that were allowed in the past but can only be kept in use for backward compatibility? I note that there is a lot of "advice" out there (RFCs included) on how to choose a mailbox name, but since it's just advice, many people are still attracted to shiny new stuff and will say "hey, it does not say MUST NOT!".

The IETF's PRECIS working group has advice on identifiers that would be a good place to continue from. I don't know if the IETF has the energy to do that, or if people here could usefully contribute.

I'd be happy to contribute, though I'm not a real expert in the matter. But I would be happy to contribute the boring stuff, e.g. editorial tasks. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy

On 4/15/2019 5:24 AM, Andre Schappo wrote:

I have frequently thought that one of reasons for the complexity of many standards/guidelines is that they encompass the whole of Unicode and hence there are few constraints and those constraints can be difficult to understand and agree upon.

In some ways, the "all of Unicode" approach looks simple: you don't have to worry about where to make a cutoff, or wrangle long lists of "acceptable" characters. However, where it runs afoul is with the complexity of the many writing systems that Unicode supports. These writing systems do not play well with the basic assumption that underlies identifiers as "random strings of letters and digits" that can be intermixed freely to form (more or less) mnemonic values. For many writing systems arbitrary strings of code points don't work well at all. Both users and rendering engines effectively expect many combinations to "never occur". Some combinations may not have a settled appearance - how to display certain clusters can be up to the font. That's all true for code points that are on people's keyboards or otherwise make up the subset of common, daily use. For ancient, obsolete and special purpose forms that Unicode supports for academic and archival purposes, all bets are off. On top of that, users (unless they are specialists) do not recognize them and cannot reliably distinguish them from similar-looking modern-use characters. They may look like an unexpected font variant, but not like a different character. If you want identifiers that are mnemonic and recognizable (preferably well enough to not just identify them, but also being able to transcribe them) you'll need to sharply limit things to some "modern use" subset.

I posit that with mailbox names, they can be categorised such that each category is more constrained and the constraints are more easily understood.

A mail service provider could impose further constraints.

Categories could be based on writing system/orthography. So one could define Japanese, Korean, Thai ...etc... categories for mailbox names.

The first categorization that follows from the design of Unicode is that you need separate name spaces for each script. Too many scripts have overlapping (visual) repertoires while having distinct code points. Disallowing script mixing keeps the shape inventory to what each set of users expects. If you need to support multiple scripts, you can support them side-by-side with proper rules that disallow names that are whole-script spoofs of each other. While we should not lose sight of the difference between the formal rules for maibox names and domain names, these issues are in fact fundamentally the same. They derive from the intersection of writing systems and Unicode's encoding model, and no so much from the details of your identifier syntax or identifier matching protocol. The statement "A mail service provider could impose further constraints" is the fundamental equivalent to "A registry operator could impose further constraints". The problem with both is the same: neither service providers nor registry operators truly understand the issues with scripts and writing systems other than their own, or how the basic assumptions about text-based identifiers just don't hold up well for complex scripts.

Letʼs take category Japanese: A generalised standard could, for example, include some "Common" characters as well as Han, Hiragana and Katakana unicode.org/Public/UCD/latest/ucd/Scripts.txt <http://unicode.org/Public/UCD/latest/ucd/Scripts.txt>. A mail service provider could, for example, impose a further restriction by not allowing "Common" characters.

I give an example of Korean mailbox names at jsfiddle.net/coas/2uLhcfef <http://jsfiddle.net/coas/2uLhcfef> I only allow a Korean Hangul mailbox names with the provided Korean Hangul domain names.

...and... much more controversially one could define a Symbols category for mailbox names. Determining which symbols could/should be included in such a category would require a lot of research and consideration.

If I was a mail service provider I, most likely, would not allow mixing of categories in mailbox names.

All these are examples that are relatively trivial, because (other than the sheer number of characters in East Asian writing systems) the code points can, in fact, be placed without restrictions. Something that would fail in South and Central Asian scripts. However, not allowing a mix of Kana and Hangul, for example (with or without Han thrown in the mix) cuts down on presenting users with labels that they think they understand but that contain something unexpected (from another category) which they will then misidentify as something more familiar. About the only people who benefit from that are users intent on malicious use of identifiers. That's the real danger of understanding UA as "blind acceptance" vs. universal support for well-behaved (if non-native) identifiers. "Well-behaved" almost has to become more narrowly defined than the "anything goes" or "any PVALID goes" from E-maul or domain name standards. A./

André Schappo

...

On 13 Apr 2019, at 11:28, John Levine <john.levine@standcore.com <mailto:john.levine@standcore.com>> wrote:

In article <BYAPR21MB13171918C3D2AC0E8D177983D12F0@BYAPR21MB1317.namprd21.prod.outlook.com <mailto:BYAPR21MB13171918C3D2AC0E8D177983D12F0@BYAPR21MB1317.namprd21.prod.outlook.com>> you write:

...

-=-=-=-=-=- UASG has not endorsed emojis as part of mailbox names and I doubt that we ever would.  But as mentioned below, some mail systems will take a more liberal approach.

First, I have to say that I am dismayed to see that many in the UASG do not know that mailboxes and domain names are different and always have been.  This is an important difference, and it's discussed at some length in UASG 012.  This would probably be a good time for everyone who hasn't read that document to read it now, so at least we agree on the underlying facts.

As several people have pointed out, there are practically no rules for what characters are technically legal in mailbox names, but that doesn't mean that in practice you can put any junk in an address and expect it to work.  For example, this is a valid address:

 "); @,?~]"@m.jl.ly

but that doesn't mean I would hand it out as an address to anyone from whom I wanted mail.

Similarly, you can technically put random combinations of Hindi, Arabic, Japanese, and emojis in a mailbox, but I wouldn't expect many mail systems to deliver it and if they do deliver it I would expect all sorts of warnings.

One of the glaring holes in the EAI documents is that there is no practical advice on choosing mailbox names.  We have developed conventions for ASCII names that LDH are fine, dots and plus signs and maybe apostrophes are OK, upper and lower case ASCII are generally interchagable, and beyond that you take your chances.  We need appropriate guidance for mailbox names.

Before anyone suggests it, the rule for mailboxes can NOT be the same as for IDNs, since a dot is not a separator, mailboxes have always allowed characters not allowed in hostnames, and mail systems have always done fuzzy matching to allow misspellings that wouldn't be possible in domain names.

The IETF's PRECIS working group has advice on identifiers that would be a good place to continue from.  I don't know if the IETF has the energy to do that, or if people here could usefully contribute.

R's, John

🌏 🌍 🌎 André Schappo 小山@电邮.在线?Subject=你好小山😜 <mailto:%E5%B0%8F%E5%B1%B1@%E7%94%B5%E9%82%AE.%E5%9C%A8%E7%BA%BF?Subject=%E4%BD%A0%E5%A5%BD%E5%B0%8F%E5%B1%B1%F0%9F%98%9C> schappo.blogspot.co.uk <https://schappo.blogspot.co.uk> twitter.com/andreschappo <https://twitter.com/andreschappo> weibo.com/andreschappo?is_all=1 <https://weibo.com/andreschappo?is_all=1> groups.google.com/forum/#!forum/computer-science-curriculum-internationalization <https://groups.google.com/forum/#!forum/computer-science-curriculum-internat...>

On 4/15/2019 9:46 AM, John Levine wrote:

In article <09cbecda-324d-eb4d-bd45-fb4e64c71a72@ix.netcom.com> you write:

...

That's the real danger of understanding UA as "blind acceptance" vs. universal support for well-behaved (if non-native) identifiers. "Well-behaved" almost has to become more narrowly defined than the "anything goes" or "any PVALID goes" from E-mail or domain name standards. Quite right. I wish I know where the bad idea came from that you're supposed to accept every technically valid but illegible and misleading IDN or e-mail address. It's never been true with ASCII addresses and it's even less true with IDNs and UTF-8 mailboxes.

How do we make sure that UA doesn't become synonymous with "uncritical acceptance"? A./

Andre Can you provide an example of what one such would look like? Don From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Andre Schappo Sent: Tuesday, 16 April 2019 8:54 PM To: Asmus Freytag (c) <asmusf@ix.netcom.com> Cc: John Levine <john.levine@standcore.com>; ua-discuss@icann.org Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. On 15 Apr 2019, at 17:54, Asmus Freytag (c) <asmusf@ix.netcom.com <mailto:asmusf@ix.netcom.com> > wrote: On 4/15/2019 9:46 AM, John Levine wrote: In article <mailto:09cbecda-324d-eb4d-bd45-fb4e64c71a72@ix.netcom.com> <09cbecda-324d-eb4d-bd45-fb4e64c71a72@ix.netcom.com> you write: That's the real danger of understanding UA as "blind acceptance" vs. universal support for well-behaved (if non-native) identifiers. "Well-behaved" almost has to become more narrowly defined than the "anything goes" or "any PVALID goes" from E-mail or domain name standards. Quite right. I wish I know where the bad idea came from that you're supposed to accept every technically valid but illegible and misleading IDN or e-mail address. It's never been true with ASCII addresses and it's even less true with IDNs and UTF-8 mailboxes. How do we make sure that UA doesn't become synonymous with "uncritical acceptance"? A./ I really like your phrase "Uncritical Acceptance". In a previous email you wrote: "Those issues may require a discussion whether "Universal Acceptance" and "Uncritical Acceptance" are the same thing". (Note - I Title cased for better effect) Seeing the two together in a sentence is extremely effective and to me effectively summarises the issues. I consider defining good mailbox naming practices for the whole of Unicode would be a huge undertaking and there would be many overlaps and possibly contradictions with other standards. So, instead, what of defining good mailbox naming practice for just one of the orthography categories? This could serve to illustrate both good practice (Universal Acceptance) and bad practice (Uncritical Acceptance). André Schappo

On Tue, Apr 16, 2019 at 11:46:54AM +0000, Andre Schappo wrote:

The individual letters of Korean are called Jamo eg ㅎ ㅏ ㄴ ㄱ ㅡ ㄹ or ㅂ ㅏ ㄴ ㅏ ㄴ ㅏ

Jamo are formed into squared syllable blocks eg 한글 (Hangeul) or 바나나 (banana)

This is not _quite_ the way it works, because there are also precomposed forms. IDNA, for instance, uses only the precomposed forms and treats the Jamo forms as INVALID. The invalidity of them is actually contrary to the principles used in setting out the IDNA2008 work, but there seemed to be very strong agreement about this. (IIRC, but I haven't gone back and checked, this had something to do with the rather tricky normalization rules.)

Universal Acceptance = Hangul Syllables U+AC00➔D7AF Uncritical Acceptance = Hangul Syllables U+AC00➔D7AF + Hangul Jamo U+1100➔11FF + Hangul Jamo Extended-A U+A960➔A97F + Hangul Jamo Extended-B U+D7B0➔D7FF + Hangul Compatibility Jamo U+3130➔318F + ...

I most definitely am not an expert on Korean so those that are please check my reasoning

This was what IDNA baked into the protocol for Korean, so you could do something similar for conventions in local-parts and get a long way. I think there remains, for Korean, a problem with Han, but that is not related to this issue. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

On 4/16/2019 8:24 AM, John Levine wrote:

...

So, instead, what of defining good mailbox naming practice for just one of the orthography categories? This could serve to illustrate both good practice (Universal Acceptance) and bad practice (Uncritical Acceptance).

Sorry, what do you mean by "orthography categories"?  There's plenty of advice about scripts and character classes and confusables that we can build on.

I think this is intended to cover what I would call "modern, everyday general use", or the letters that people learn in school, as opposed to arcane, outdated, specialized code points for the same languages and scripts that are also in Unicode for use by scholars and other specialized and expert users. The proposal is apparently to pick an example for didactic purposes. A./

Dear all, I'd like to shift this discussion to the UA-EAI mailing list with a goal of producing a Good Practice Guide for mailbox administrators. Existing subscribers would have just received a message asking for the start of a discussion of a Good Practice Guide. If you'd like to participate and are not a subscriber to the UA-EAI mailing list, do please let me know direct (off list) and I'll add you. Thanks. Don Hollander Secretary General UASG -----Original Message----- From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of John Levine Sent: Wednesday, 17 April 2019 7:59 AM To: ua-discuss@icann.org Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. In article <c36e2135-bdc7-7610-0fc2-9071ac8495f1@ix.netcom.com> you write:

I think this is intended to cover what I would call "modern, everyday general use", or the letters that people learn in school, as opposed to arcane, outdated, specialized code points for the same languages and scripts that are also in Unicode for use by scholars and other specialized and expert users.

Seems reasonable. I was hoping we could do something like recommend that mailbox names follow the UTS39 Highly Restrictive profile, with the additional advice that since these are mailboxes and not domain names, if the identifier contains confusable characters that the MTA's mailbox fuzzy match accept all of the confusables as aliases for the name. This would imply that you can't have two mailboxes that differ only in confusables. I don't know if there's "almost confusables" like various accented versions of letters, which I would treat as confusables here and accept as aliases.

I am a bit puzzled by this discussion. I wonder whether we should apply a simple consideration: while universally accepting different scripts is something that is needed by parts of the internet user population to effectively and fully benefit of the Internet, this is not really the case for supporting emoji. In simple words, while this can be a fascinating technical problem, its solution does not address a primary need of the average internet user but just some vanity need (at best) of some internet users. I am not saying that we should not study it, but I would argue that it has a far lower priority. Just my 2c R On 11.04.2019, at 19:20, Asmus Freytag <asmusf@ix.netcom.com<mailto:asmusf@ix.netcom.com>> wrote: On 4/11/2019 12:10 AM, Dr Ajay Data wrote: Some Interesting things to note: I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in ( ❤ - xn--qei and ♥ - xn--g6h ) When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous I tend to agree with these mail providers. Emoji have no place is security relevant contexts because their rendering is far from standardized and unless magnified, they can be hard to recognize. Also, users have no good idea whether related shapes might exist or not, so any deviation would be attributed to non-standard rendering and most likely accepted. Finally, many emoji involve sequences that may be displayed by some fall-back means on devices that do not happen to support them. This makes emoji similar to complex scripts, but that danger is underappreciated by many people because emoji have an emotional appeal and appear accessible because the are cute. They are dangerous in identifiers. The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message. Probably, we need to discuss this too and have our views around it. Dr. Ajay Data Founder & CEO [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]20190411124031186[-HID]

I am sorry for being perpetually distracted by shiny objects. Consider the emoji discussion dropped from my side. From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Lars Steffen Sent: Friday, April 12, 2019 12:28 AM To: Roberto Gaetano <roberto_gaetano@hotmail.com>; Asmus Freytag <asmusf@ix.netcom.com>; Universal Acceptance <ua-discuss@icann.org> Subject: Re: [UA-discuss] interesting to note about emoji in mailbox name. Thank you Roberto. We had the last extensive discussion about emojis on this mailing list exactly one year ago. I consider emojis as a very small part of the Universal Acceptance complex – if at all. The UASG is currently working on an update of its strategic plan and strategic objectives. Emojis are not included. Neither in the plan, nor in the objectives. I´d highly appreciate if the UASG leadership would keep this in mind when starting new discussion threads. The UASG will keep struggeling to achieve its goals if we repeatedly allocate time and resources on niche phenomena that are not even in scope. Thank you Lars Von: UA-discuss <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> im Auftrag von Roberto Gaetano <roberto_gaetano@hotmail.com<mailto:roberto_gaetano@hotmail.com>> Datum: Freitag, 12. April 2019 um 02:38 An: Asmus Freytag <asmusf@ix.netcom.com<mailto:asmusf@ix.netcom.com>> Cc: Universal Acceptance <ua-discuss@icann.org<mailto:ua-discuss@icann.org>> Betreff: Re: [UA-discuss] interesting to note about emoji in mailbox name. I am a bit puzzled by this discussion. I wonder whether we should apply a simple consideration: while universally accepting different scripts is something that is needed by parts of the internet user population to effectively and fully benefit of the Internet, this is not really the case for supporting emoji. In simple words, while this can be a fascinating technical problem, its solution does not address a primary need of the average internet user but just some vanity need (at best) of some internet users. I am not saying that we should not study it, but I would argue that it has a far lower priority. Just my 2c R On 11.04.2019, at 19:20, Asmus Freytag <asmusf@ix.netcom.com<mailto:asmusf@ix.netcom.com>> wrote: On 4/11/2019 12:10 AM, Dr Ajay Data wrote: Some Interesting things to note: I am testing with Two working Valid Email Address with heart shape.. ❤@data.in and ♥@data.in ( ❤ - xn--qei and ♥ - xn--g6h ) When I receive email from the above ID`s, In mobile devices these above hearts are shown in different red shades. However If I send email to Gmail / Outlook, they consider this as Spam. Not only spam, Gmail displays the following warning. - This message seems dangerous I tend to agree with these mail providers. Emoji have no place is security relevant contexts because their rendering is far from standardized and unless magnified, they can be hard to recognize. Also, users have no good idea whether related shapes might exist or not, so any deviation would be attributed to non-standard rendering and most likely accepted. Finally, many emoji involve sequences that may be displayed by some fall-back means on devices that do not happen to support them. This makes emoji similar to complex scripts, but that danger is underappreciated by many people because emoji have an emotional appeal and appear accessible because the are cute. They are dangerous in identifiers. The sender’s email address uses abnormal characters, which might be used to spoof real addresses. Avoid clicking links, downloading attachments, or replying to this message. Probably, we need to discuss this too and have our views around it. Dr. Ajay Data Founder & CEO [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]20190411124031186[-HID] [Das Bild wurde vom Absender entfernt.][Das Bild wurde vom Absender entfernt.]