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

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

Официально согласно RFC 6532 - Да .

Для быстрого объяснения загляните в Википедию по этой теме.

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

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

Раздел 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.

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

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

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

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

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

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

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

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

Цитата из H-Online (в том виде, в каком она была):

Инженерная группа Интернета (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 говорит, что он будет уделять внимание символу «ß», также известному как estzett, который до сих пор игнорировался. Немецкий регистратор также говорит, что может немного подождать перед переключением из-за отсутствия обратной совместимости.

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

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

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

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