On 4/11/2019 1:46 PM, Mark Svancarek (CELA) wrote:

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 INYC, 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”.


Indeed !

A./

/marksv

 

From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Asmus Freytag
Sent: Thursday, April 11, 2019 12:15
To: 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 INYC, 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]

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