[UA-discuss] Would this be in scope or not?

[Brent London]

>
> Where are conventions/ good practices/best practices for the localname
> part of an e-mail address developed?
> Is this something that the UA group could facilitate during a face to face
> gathering?  If so, should it?


I believe --- someone correct me if I'm mistaken --- that they developed
organically. Since each domain can configure it's local-part rules (mostly)
however it wants, there was/is no technical need for coordination for most
conventions. So as long as everyone's conforming to the internet mail RFCs,
Gmail can decide to ignore dots (.) without negatively affecting outlook.com
.

Could these conventions (etc) be language or script specific?  For example,
> by convention not supporting a dot in a right to left script.  (This way
> you can determine which is the domain and which is the local name part -
> the domain always has a dot.)


I think this is possible, especially if we're anticipating a security/abuse
issue. My sense is that the m3aawg <https://www.maawg.org/> would be the
right forum for coming up with a more detailed proposal. It theoreticallly
could be implemented independently: If major mail providers
together decided to spam-reject all RTL email addresses with a dot in the
local-part, it could help shape this type of convention. But I suspect that
a coordination a decision like that would need to go through an anti-abuse
working group of some sort first.

On Fri, Mar 13, 2015 at 3:08 AM, Don Hollander <don.hollander at icann.org>
wrote:

>  Brent:
>
>  Where are conventions/ good practices/best practices for the localname
> part of an e-mail address developed?
>
>  Is this something that the UA group could facilitate during a face to
> face gathering?  If so, should it?
>
>  Could these conventions (etc) be language or script specific?  For
> example, by convention not supporting a dot in a right to left script.
>  (This way you can determine which is the domain and which is the local
> name part - the domain always has a dot.)
>
>  Don
>
>  On 13/03/2015, at 12:06 pm, Brent London <brentlondon at google.com> wrote:
>
>   The standard for the mailbox name (as in mailbox at domainname) is that the
>> treatment of the mailbox name is up to the domain name.  "Dots" are
>> immaterial to mail operators (which has proven to be a surprise), the "+"
>> might be treated specially, etc. I squirm when I think that there's a
>> desire to think of email names as global and unique.  So, in a way, it
>> seems like the wrong foundation for an ICANN effort.  (Languages have had
>> to adopt '@' already.  Not sure about '+' and other syntactic sugar in
>> mailbox names.
>
>
>  The practices mentioned here --- immaterial dots, treating +substrings
> differently, case insensitivity ---  have evolved outside the context of
> internationalized email addresses. I believe IC! ANN and this group can
> have a real impact at promoting EAI (RFC 6532 et al) adoption while taking
> no stance on subjective local-part practices like these.
>
>  (There might be areas where we choose to weigh in: local-parts are
> technically case-sensitive, but one could imagine that there are security
> implications if an e-commerce site were to allow user at example and
> User at example to be separate accounts. But those problems already exist
> and are not specific to EAI.)
>
> On Thu, Mar 12, 2015 at 2:31 PM, Richard Merdinger <rmerdinger at godaddy.com
> > wrote:
>
>> I'm going to agree with Ram that the most important thing that ICANN do
>> at present is help in the essential Universal *awareness* elements of
>> universal acceptan! ce as well as with facilitation with the coordinating
>> functions. - RSM
>>
>> > It's not clear to me that ICANN could drive a standard handling of
>> mailbox names, I think that would be quixotic.  Then again maybe tackling
>> mailbox names isn't necessary, maybe all we really need to do is get
>> clients to work with an expanded definition of what a mailbox name is.
>> (Lurking in me is the thought of "variants" and how they might cause
>> trouble in mailbox names if there's no canonical form as defined in IDNA
>> 2008 for domain
>>
>> [[Ram]] The goal would not be for ICANN to drive either the standard or
>> adoption. Instead, the goal would be for ICANN to help improve awareness of
>> the problem space, and then provide a coordination function so appropriate
>> parties can determine solution sets for the defined problems.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20150313/71ef10ed/attachment.html>