Кратко

  • SMTPUTF8 расширил до UTF-8 имена ящиков в конверте и значения заголовков, но только после объявления возможности каждым сервером; такой сервер обязан также поддерживать и объявлять 8BITMIME.
  • Домен можно представить IDNA A-label, однако у не-ASCII local-part нет общего эквивалента. На неспособном пути честными вариантами оставались авторизованное преобразование при submission, другой маршрут, повтор или ошибка — не выдуманный ящик.

Знакомое имя ещё не было адресом

MIME позволял показывать имена и темы вне ASCII. Но RFC 6530 отделяет видимый display name от SMTP-конверта: он не направляет доставку.

IDNA интернационализировал домен справа от @. Local-part оставался именем, которым распоряжается финальная система. У Unicode-домена есть DNS-форма A-label; у ящика нет универсальной транслитерации. Замена может указывать в пустоту или на другого человека.

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

Standards Track отказался от downgrade в пути

RFC 6530 заменил RFC 4952 и признал эксперименты промежуточного понижения ненужными. Ретранслятор в середине не обладал полномочиями создавать ASCII-идентичность.

Документы февраля 2012 года разделили функции. RFC 6531 определил SMTP; RFC 6532 — UTF-8-заголовки; RFC 6533 — уведомления, сохраняющие международного получателя. Это не таблица переводов, а среда, где конверт, сообщение и доказательство ошибки называют один адрес.

SMTPUTF8 был полным обещанием

Сервер помещает SMTPUTF8 в EHLO. Реестр SMTP IANA хранит слово без параметров. RFC 6531 требует полного соответствия, а также поддержки и объявления 8BITMIME.

8BITMIME сохраняет старшие биты тела; SMTPUTF8 расширяет адреса конверта и заголовки идентичности. Второе требует чистой восьмибитной среды, но не заменяет первое.

Клиент может добавить беззначный параметр SMTPUTF8 к MAIL FROM, заявляя, что расширение нужно конверту, сообщению или заголовкам. Разделители SMTP остаются, расширяется набор символов.

Маршрут стал условием достижимости

Без объявления нельзя передавать международный адрес или заголовок RFC 6532, даже внутри вложенного MIME. Один ящик может быть достижим через способный MX и блокироваться другим. Альтернативный MX или повтор ищут верный путь, не переименовывают получателя.

Submission Agent имеет больше свободы на границе пользователя. Если существует действительно назначенный ASCII-алиас, он может построить обычное сообщение. RFC 6531 не определяет эту трансформацию и не разрешает транзитному релею импровизировать.

Без законного преобразования или маршрута следует отказать, уведомить, вернуть в очередь или попробовать другой хост. Ошибка сохраняет разницу между «путь не несёт имя» и «ящика нет».

UTF-8 вошёл в значения, но не в имена полей

RFC 6532 разрешает прямой UTF-8 в Subject, адресах, строках и части конструкций Message-ID. Имена полей остаются ASCII. Жёсткий предел составляет 998 октетов; рекомендация 78 единиц для отображения остаётся в символах.

Нормализация не создаёт идентичность. RFC 6532 рекомендует NFC и предостерегает от NFKC при потере различий в написании. Local-part толкует финальная система.

Уведомление обязано сохранить имя ошибки

RFC 6533 задаёт UTF-8-тип адреса и формы для ORCPT и DSN, включая семибитно-безопасную. Она сохраняет оригинального получателя как доказательство, но не создаёт доставляемый ASCII-ящик.

Сервер, объявляющий SMTPUTF8 и DSN, должен реализовать RFC 6533. Отчёт без имени адресата нельзя связать с исходной отправкой.

Возможность не была собственностью

SMTPUTF8 доказывает способность анализировать и переносить строки, не существование, владение, визуальную эквивалентность или доставку. Владелец домена управляет DNS, финальная система — ящиками, релей переносит или отказывает. Никто не вправе выдумывать замену личности.

Источники и границы

Каркас, транспорт, заголовки и уведомления определяют RFC 6530, RFC 6531, RFC 6532, RFC 6533; текущую запись даёт IANA. Они не измеряют поддержку, доставляемость или владение сегодня.