Может ли адрес электронной почты содержать международные (неанглийские) символы?

Ответ 1

Официально, за RFC 6532 - Да.

Для быстрого объяснения ознакомьтесь с wikipedia по этому вопросу.

Ответ 2

Обновление 2015: используйте RFC 6532

Экспериментальный 5335 был заменен на: 6532 и
это позже было установлено в "Категория: Стандартная дорожка",
что делает его стандартным.

Раздел 3.2 (Расширения синтаксиса до RFC 5322) обновил большинство текстовых полей на
включают (правильные) UTF-8.

The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
             ; note that this upgrades the body to UTF-8
dtext   =/  UTF8-non-ascii

The preceding changes mean that the following constructs now
allow UTF-8:
   1.  Unstructured text, used in header fields like
       "Subject:" or "Content-description:".
   2.  Any construct that uses atoms, including but not limited
       to the local parts of addresses and Message-IDs. This
       includes addresses in the "for" clauses of "Received:"
       header fields.
   3.  Quoted strings.
   4.  Domains.

Note that header field names are not on this list; these are still
restricted to ASCII.

Обратите внимание на явное включение доменов.
И явное исключение имен заголовков.

Также обратите внимание на NFKC:

The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.

И Раздел 3 начало:

Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.

Ответ 3

Проблема заключается в том, что некоторые почтовые клиенты (серверные инструменты и/или настольные инструменты) не поддерживают его и бросают исключение "недействительного письма" при попытке отправить почту на адрес, который содержит, например, umlauts.

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

Пример: müller.com "xn--mller-kva.com

Оба указывают на одно и то же.

Ответ 4

Я бы предположил, что да, поскольку ряд доменов верхнего уровня уже разрешает не ascii символов для доменов, и поскольку домен является частью адреса электронной почты, это совершенно возможно. Примером такого домена может быть www.öko.de

Ответ 5

Пока нет. IEEE планирует это сделать: Статья H-Online: планирование IEFT интернационализированных адресов электронной почты, здесь RfC: расширение SMTP для международных адресов электронной почты

Цитата из H-Online (по мере ее снижения):

Целевая группа Internet Engineering Task Force (IETF) опубликовала три важных документа для стандартизации заголовков адресов электронной почты которые включают символы вне набора символов ASCII. Это значит, что скоро вы сможете использовать китайские иероглифы, французские акценты и Немецкие умляуты в адресах электронной почты, а также только в теле сообщение. Поэтому, если ваше имя зоо и вы работаете в компании, которая делает фасады, вас может заинтересовать новый адрес электронной почты. Но представители провайдеров уже стонали. Говорят, что должны быть "манией обновления", если стандарт Unicode UTF-8 заменить Американский стандартный код для обмена информацией (ASCII) в настоящее время используется как общий язык электронной почты.

RFC 5335 определяет использование UTF-8 практически во всех почтовых заголовках. Необходимо внести изменения в SMTP-клиенты, SMTP-серверы, почтовый пользователь агенты (MUA), программное обеспечение для списков рассылки, шлюзы на другие носители, и везде, где электронная почта обрабатывается или передается вместе. RFC 5336 расширяет транспортный протокол электронной почты SMTP. На уровне протокол, расширение обозначается UTF8SMTP.

Новое поле заголовка будет добавлено как своего рода "аварийный парашют" для убедитесь, что электронные письма UTF-8 имеют мягкую посадку, если они выбрасываются до достижения получателя системами, которые не были обновлены. "OldAddress" - это чисто ASCII-адрес. Но OldAddress не должен использовать в качестве канала для второй попытки передачи, а скорее сделать убедитесь, что обратная связь отправлена ​​домой.

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

Германия DeNIC, регистратор домена ".de", тем не менее делая это в своем шаге. "Мы действительно мало что можем сделать", пояснил представитель DeNIC Клаус Херциг. DeNIC вместо этого платит больше внимания уделяется обновлению, которое IETF работает для стандарт международных доменов - RFC3490, или IDNA2003, так как это иногда известный. "Мы не очень рады этому, потому что нет обратная совместимость", - пояснил Герциг. Когда приходит обновление, DeNIC говорит, что он будет забрасывать свой вес за символ "ß" - также известный как эцеттт, который до сих пор не учитывался. Немец регистратор также говорит, что он может немного подождать, прежде чем переключать свет отсутствия обратной совместимости. Как только новый стандарт стабильно работающие, а регистраторы и провайдеры приняли его, ß будет добавлено.

Напротив, эксперты считают, что китайские регистраторы в Китае и Тайвань быстро осуществит изменение для интернационализированной электронной почты. Представители CNIC и TWNIC являются авторами стандартов. В настоящее время китайским пользователям приходится писать письма в ASCII слева от @и в китайских иероглифах справа от него для китайцев домены, которые уже были интернационализированы.

(Моника Эрмерт)

Ответ 6

короткий ответ: да

допустимы не только имя пользователя, но и имя домена.

Ответ 7

Ответ - да, но они должны быть специально закодированы.

Посмотрите на это. Прочитайте часть, относящуюся к заголовкам электронной почты и RFC 2047.