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

Question

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

Answer 1

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

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

Answer 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.

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

Еще нет. 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 имеют мягкую посадку, если они выбрасываются до достижения получателя системами, которые не были обновлены. «Старый адрес» - это чисто ASCII-адрес. Но OldAddress не должен использоваться в качестве канала для второй попытки передачи, а скорее для уверен, что обратная связь отправлена ​​домой.

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

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

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

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

Answer 7

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

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