[UA-EAI] Executive Summary for "Best Practice for Mailbox Name"

[Jim DeLaHunt]

Colleagues:

I have completed a draft Executive Summary for our *Best Practice for 
Mailbox Name* 
<https://docs.google.com/document/d/1WdqJuIqWkSNHEeDequ3JGnHcE9Kl6QMrKlzEnQPQ5Zs/edit?usp=sharing> 
document. I've included it below, for your convenience. Sorry it wasn't 
ready for this morning's meeting.


    Executive Summary

Mailbox names — the part of the email address before the ‘@’ symbol — 
are important to how useful, pleasant, and secure an email system will 
be. Good policy for what mailbox names are allowed is already important 
for email administrators, even when email addresses are limited to 
Latin-script letters and digits. But email technology now allows both 
mailbox name and domain name to be written in almost any language. This 
language flexibility makes policy choices more complex. This document 
guides email administrators in adapting mailbox name policy to cover 
email addresses which go beyond Latin-script letters and digits.


Decide which scripts (writing systems for languages) you will allow in 
mailbox names. The business purpose of the email system, and the 
language needs of your users and of their correspondents, will drive 
this. Make conscious decisions on which combinations of scripts may be 
mixed in a mailbox name. Some mixing is valid, some may open up security 
risks. Length of mailbox names will need limits, but limits might be 
different than before.


Some spellings and character combinations are confusing or deceptive, 
and policy should forbid them — the details depend on the language of 
the name. Right-to-Left (RTL) scripts have unique possibilities for 
confusing name spellings, so if your system allows these scripts there 
are further policy topics. Your users may exchange email with people who 
have difficulty reading the scripts of your email addresses, but you can 
use aliases (alternate addresses for the same user) and display names 
(the personal name displayed) to reduce these difficulties. Signs and 
symbols are now conceivable in mailbox names, but they might be 
confusing, difficult, or unwise. Consider forbidding or limiting them. 
Technical issues about how name spellings which look “the same” to users 
might be different to the email system require special attention. These 
includes Unicode normalization differences, equivalence between 
upper-case and lower-case letters, and similar issues.


Finally, this document includes a list of resources and references which 
provide more detail on several of these policy topics. We also include a 
glossary of terms, some of which may be new with the adoption of 
multiple languages for your mailbox names.


This document is intended for email administrators, systems 
administrators, and IT managers.  Its purpose is to aggregate and 
specify the main operational and policy considerations to be considered 
when creating internationalized email address mailbox names, aliases, 
and display names.

(total: 399 words.) I suggest that we attach suggestions and comments to 
the Google docs, where they are easier to review and apply.

Best regards, —Jim DeLaHunt, Vancouver, Canada

-- 
.   --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant

       355-1027 Davie St, Vancouver BC V6E 4L2, Canada
          Canada mobile +1-604-376-8953

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-eai/attachments/20200714/653648ed/attachment.html>