Чи може електронна адреса містити міжнародні (неанглійські) символи?

Якщо це можливо, чи повинен я приймати такі електронні листи від користувачів і яких проблем очікувати, коли я буду надсилати листи на такі адреси?

Офіційно, згідно з RFC 6532 - Так .

Для швидкого пояснення перегляньте wikipedia на цю тему.

Оновлення 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.

Проблема полягає в тому, що деякі поштові клієнти (серверні інструменти та / або настільні інструменти) цього не підтримують і видають виняток "недійсна електронна пошта", коли ви намагаєтесь надіслати електронну пошту на адресу, яка, наприклад, містить umlauts.

Якщо вам потрібна повна підтримка, ви можете зробити фокус із перетворенням частин адреси електронної пошти на "punycode". Це дозволяє користувачам вводити свої адреси звичайним способом, але ви зберігаєте їх способом підтримуваного рівня.

Приклад: müller.com »xn--mller-kva.com

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

Я припускаю, що так, оскільки низка доменів верхнього рівня вже дозволяють використовувати символи non 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.