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@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@scriptbdomain - ajay@ਡਾਟਾਮੇਲਭਾਰਤ b. scripta+scriptc@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@anvilwalrusden.com