[UA-discuss] Issue needs discussion and closure

[Andrew Sullivan]

Hi,

I am now even more regretful that I couldn't make yesterday's session,
since it clearly was interesting.  Some comments below.

On Sun, Mar 11, 2018 at 08:19:39AM +0530, Ajay Data wrote:
> 
>  1. Sender ID as xn--anything in local part.
> 
> If email server receives an email FROM  xn--anything at validdomain  , should
> email server at receiving end Do..
> 
>  a. the conversion of xn--anything to UTF8 string.
>  b. Leave it the way it was received i.e xn-anything

I don't know what 1.a means.  As far as I know, there is no protocol
of any kind specified anywhere that that talks about algorithmic
transformations of local-parts from an ASCII-compatible-encoding (ACE)
to UTF-8.  The prefix 'xn--' is not a magic universal transformation
indicator: it works for individual labels in domain names when IDNA is
in use, and that's it.

If we want a reliable protocol mechanism that can do this
transformation, I think it probably needs some protocol engineers to
work on it.  I will observe that the IETF's EAI working group twice
declined to do this kind of mapping, and it might behoove those who
are interested in seeing such a mapping to go and review the prior
discussions about why it was not taken up before.  But I will suggest
that people consider the differences between RFCs 821 and 822, and RFC
952, as a short cut to understanding why "punycode for local-parts"
was not really a good idea.

I think you should expect that a local-part-prefix for this kind of
transformation indicator would be just about anything other than xn--,
since that is in use for domain name labels and overloading this for
email local-parts would be quite a bad idea.  (Please remember that
"xn--" is added to the A-label after the Punycode algorithm is run
over the candidate U-label.)

I'm also pretty nervous about your use of "mail server" there, since
it suggests that intermediate mail servers should be doing
transformations.  This is definitely a bad idea: section 2.3.11 of RFC
5321 prohibits it.

All of that said, of course, it's the Internet: your network, your
rules, and you can do what you want with local-parts in your mail
system.  Just don't expect it to work predictably with others.

>  2. Is Mixing of scripts is allowed in mailbox local part While creating a
>     mailbox like..
> 
>  a. scripta at scriptbdomain -     ajay@ਡਾਟਾਮੇਲਭਾਰਤ
>  b. scripta+scriptc at scriptbdomain ajayअजय@ਡਾਟਾਮੇਲ.ਭਾਰਤ

I don't know what "allowed" means in this context, since practically
anything can go in a local-part.  It has always been possible to mix
scripts in the domain-part, because the DNS is a distributed hierarchy
so there can only be rules zone by zone (which might be label by
label, and might not be), and those rules are set by the zone operator
(ICANN makes rules for the root zone, and through contractual
mechanisms makes them for gTLDs, but that's the extent of ICANN's
control).  I can imagine proposing good pratices for restricting the
scope of scripts to be used in local-part identifiers based in part on
what server-part identifiers are in use.  

>  3. Alias ID on MUA:
> 
> We already agreed that Downgrading of Alias is good practice

I literally don't know what that means, but I will observe that
"downgrade" was a failed experiment in the EAI protocol and was
deprecated.  Moreover,

> and to be followed
> by email servers while communicating with legacy systems

…how do you know when you're communicating with "legacy systems"?
Your only knowledge is of the next mail hop, which might not be the
MTA that does the final delivery.  We do not have a mechanism to
specify the mail path (mercifully, bang addresses went out a long time
ago), and therefore we don't have a mechanism to make sure that the
mail path the whole way through can do ESMTP, never mind EAI.

>, however we have not
> discussed how Alias will be made available on MUA and if there are many Alias,
> than which will be used for downgrading.

I also don't understand what that means.  I'm also not sure what it
would mean to make rules about what MUAs can do.

Best regards,

A


-- 
Andrew Sullivan
ajs at anvilwalrusden.com