问题是这样的：我使用的第三方电子邮件递送服务不接受名称部分包含非 ASCII 字符的邮件地址，例如 müller@example.com 。
用 Punycode 编码这样的地址：
http://en.wikipedia.org/wiki/Punycode
产生这个地址：
xn--mller-kva@example.com
通过该服务向它发送邮件似乎可行。
但是，我不确定是否有人不能直接注册“xn--mller-kva@example.com”，从而接收到“müller@example.com”的电子邮件。
这有可能发生冲突吗？这个问题还有其他解决方案吗？
更新
感谢您的回答。以下是我们学到的总结：
电子邮件地址的本地部分不允许使用非 ASCII 字符。时期。Punycode 仅适用于域，不适用于电子邮件地址的本地部分。
然而，IETF 很可能采用了一种使国际化本地化部分成为可能的标准。然而，这个标准可能不会基于 punycode。
我很无聊，今晚正在研究这个，显然这现在被编入扩展 SMTP 标准，特别是根据 RFC 6531 的 SMTPUTF8。参见http://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
我使用 emoji 邮箱名称的简短实验在通过 Gmail 发送时返回了以下错误：
信封的本地部分包含 utf8，但远程服务器未提供 SMTPUTF8
无论我使用的是表情符号还是 punycode 版本的地址，这都是一样的。
您可以使用如下格式将邮件标题字段的部分编码为不同的字符编码： =?UTF-8?B?w6HDq8O0?= 这允许您嵌入诸如变音符号之类的东西，但我很确定它不适用于实际地址部分。
您没有理由不能使用这些字符来构成您的地址。RFC5322定义了 3.4 节中地址部分可能出现的字符，你上面使用的所有字符都是有效的。但是，正如另一条评论所补充的那样，如果您发送到的邮件客户端无法解析这种格式，这一切都会徒劳无功。
一些 SMTP 服务器可能“意外”允许变音符号，但由于它们不在支持的字符范围内，我不会冒险。
在电子邮件地址的本地部分发送非 us-ascii 字符的唯一标准方法是通过 rfc6532（国际化电子邮件标头）和 rfc6531（SMTPUTF8 的 SMTP 扩展）。
据我所知，没有标准方法可以在电子邮件地址的本地部分对非 us-ascii 字符进行编码，特别是：
Puny 代码仅适用于域名，不适用于本地部分。但是你可以有一个本地部分，它恰好看起来像某个字符串的微弱编码，但它应该以它的微弱编码形式显示。如果邮件程序决定在对它进行解码后显示它，则它是非标准行为。
答案之一（=?utf-8?Q?foobar?=事物）中提到的编码字编码机制不适用于邮件地址的本地部分，仅适用于邮箱的显示名称（这是不同的东西，但相关，即您的邮件程序可能显示而不是邮件地址）。
最后，这意味着müler@example.com和是两个完全不相关的电子邮件地址，如果它们是域，它们将xn--mler-0ra@example.com具有
相同的含义（但它们不是这样，它们可能会发生冲突）。
从理论上讲，您可以希望到现在（2019 年）所有邮件服务器都支持 SMTPUTF8，所有客户端都支持国际化邮件，但遗憾的是，如果它很重要，我不会指望它。
顺便提一句。碰巧电子邮件地址的本地部分是邮件标准中唯一可能需要非 us-ascii 字符并且无法对其进行编码的内容（据我所知）。所有其他部分要么有编码的单词、puny、percent、base64、quoted-printable 或一些其他形式的编码机制。
做了一些测试.. 本地部分的变音符号似乎在某些设置中起作用。我的 MUA（爪子）、出站中继（exim）和接收 MTA（后缀）都没有抱怨或进行任何 punycode 转换。然而，像 gmail 和 hotmail 这样的提供商根本不允许使用变音符号（经过测试的 webmail 和直接传入和传出的 smtp）。我没有找到任何关于此案例的文档表明对本地部件进行 punycoding.so，因为它没有记录，也没有人这样做，所以没有冲突问题 :-)
结论：您可能首先不应该接受本地部分的变音符号，甚至不尝试向这些地址发送电子邮件。（如果大玩家不这样做并且它没有被 RFC 记录/支持，你为什么要这样做？）