Могут ли адреса электронной почты, закодированные с помощью Punycode, совпадать с «реальными» адресами?

Question

Проблема заключается в следующем: я использую стороннюю службу доставки электронной почты, которая не принимает почтовые адреса с не-ASCII-символами в имени, например, müller@example.com.

Кодировкатакой адрес с Punycode:

http://en.wikipedia.org/wiki/Punycode

http://idnaconv.phlymail.de/index.php?decoded=m%C3%BCller%40example.com&idn_version=2008&encode=Encode+%3E%3E&lang=de

дает этот адрес:

xn--mller-kva@example.com

И отправка почты на него через службу, похоже, работает.

Однако я не уверен, что кто-то не может зарегистрировать "xn--mller-kva@example.com" напрямую, таким образом получая электронные письма, предназначенные для "müller@example.com".

Возможно ли это столкновение?Есть ли другие решения для этой проблемы?

ОБНОВЛЕНИЕ

Спасибо за ответы.Вот краткое изложение того, что мы узнали:

• Работает точная кодировка локальной части адреса электронной почты, и вы можете отправлять и получать с такого закодированного адреса (конечно)
• Однако,нет никаких гарантий, что провайдеры или почтовые клиенты поймут кодировку или сделают это автоматически.Поэтому возможны столкновения, и сама идея не очень хорошая:)
• Нужно просто делать то, что делают все остальные, то есть не разрешать или принимать части имен, отличные от ASCII, согласно спецификации
• И, наконец, выясняется, что сторонний сервис запрещает подобные махинации.

Answer 1

Не-ASCII символы не допускаются в локальной части адресов электронной почты.Период.Punycode предназначен ТОЛЬКО ДЛЯ ДОМЕНОВ, а не для локальных частей адресов электронной почты.

Однако весьма вероятно, что IETF примет стандарт, который делает возможной интернационализацию локальных частей.Этот стандарт, однако, вероятно, не будет основан на punycode.

Answer 2

Мне стало скучно, и я исследовал это сегодня вечером, и, по-видимому, теперь это кодифицировано в расширенном стандарте SMTP, в частности, SMTPUTF8 согласно RFC 6531. См. http://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8

Мой краткий эксперимент с использованием имен почтовых ящиков emoji вернул следующую ошибку при отправке через Gmail:

локальная часть конверта содержит utf8, но удаленный сервер не предлагал SMTPUTF8

Это то же самое, независимо от того, использовал ли я адрес Emoji или Punycode.

Answer 3

Вы можете кодировать разделы полей заголовка письма в различные кодировки символов, используя следующий формат: =? UTF-8? B? W6HDq8O0? = Это позволяет вам встраивать такие вещи, как умляуты, но я уверен, что это не такне работает для фактической части адреса.

Нет причин, по которым вы не можете использовать эти символы для формирования своего адреса. RFC5322 определяет символы, которые могут появиться в части адреса в разделе 3.4, и все символы, которые вы используете выше, действительны.Однако, как добавил другой комментарий, все это немного бесполезно, если почтовые клиенты, на которые вы отправляете сообщения, не могут проанализировать этот формат.

Некоторые SMTP-серверы могут «случайно» разрешить умлауты, но так как они не входят в поддерживаемый символдиапазоны я бы не стал рисковать.

Answer 4

сделал несколько тестов. Умлауты в локальной части, кажется, работают в определенных установках. ни мой MUA (когти), ни исходящий ретранслятор (exim), ни принимающий MTA (postfix) не жаловались и не выполняли какое-либо преобразование с помощью punycode. провайдеры, такие как gmail и hotmail, однако, не разрешают использование умлаутов вообще (проверенная веб-почта и прямой входящий и исходящий smtp). Я не нашел никакой документации по этому делу, которая бы предлагала точную кодировку локальных parts.so, так как она не задокументирована, и никто не делает этого, нет проблем с конфликтами: -)

вывод: вы, вероятно, не должны сначала принимать умлауты в локальной части и даже не пытаться отправить электронное письмо на эти адреса. (если крупные игроки не делают этого, и это не задокументировано / не поддерживается RFC, почему вы должны?)

Answer 5

Единственный стандартный способ отправки символов, отличных от us-ascii, в локальную часть адреса электронной почты - через rfc6532 (интернационализированные заголовки электронной почты) и rfc6531 (расширение SMTP для SMTPUTF8).

Насколько я знаю, не существует стандартного способа кодирования символов non-ascii в локальной части адреса электронной почты, а именно:

• Код Puny предназначен только для доменных имен, но неместная часть.Но у вас может быть локальная часть, которая выглядит как ничтожное кодирование какой-либо строки, но она должна отображаться в ее маленьком зашифрованном виде.Если почтовая программа решает отобразить ее после незначительного декодирования, это нестандартное поведение.

• Механизм кодирования кодированных слов, упомянутый в одном из ответов (вещь =?utf-8?Q?foobar?=), равен * 1016.* не применимо к локальной части почтового адреса, только к отображаемому имени почтового ящика (что-то другое, но связанное, т.е. то, что может отображать ваша почтовая программа вместо почтового адреса).

В конце концов это означает, что müler@example.com и xn--mler-0ra@example.com - это два совершенно не связанных друг с другом адреса электронной почты, которые имели бы одно и то же значение, если бы они были бы доменами (но ониони не могут конфликтовать).

Теоретически можно надеяться, что к 2019 году все почтовые серверы поддерживают SMTPUTF8, а все клиенты поддерживают интернационализированную почту, но, к сожалению, я бы не стал рассчитывать на это, если это важно.

Btw.бывает, что локальная часть адреса электронной почты является единственной вещью в стандарте (ах) почты, где вы, возможно, захотите использовать символы, отличные от us-ascii, и нет способа кодировать ее (насколько я знаю).Все остальные части имеют закодированное слово, маленькое число, процент, base64, цитируемый для печати или какой-либо другой вид механизма кодирования.