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