Кратко

  • draft-ietf-mailmaint-smtputf8-syntax-05 опубликован 10 сентября 2026 года. В новой версии перечень разрешённых классов заменён ссылкой на PRECIS IdentifierClass и прямым требованием выполнить применимое контекстное правило.
  • В примерах впервые явно отклонены U+3164 HANGUL FILLER, который может ничего не показывать, и U+0640 ARABIC TATWEEL, удлиняющий предыдущую арабскую букву и создающий множество визуальных написаний.
  • Допуск строки не доказывает существование или контроль почтового ящика, личность владельца, поддержку SMTPUTF8 на всём пути и доставку сообщения.
  • В текущей фразе остаётся буквальное несоответствие между пробелом в кавычках и знаками пунктуации адреса. Это предмет следующего уточнения, а не основание для молчаливого исправления в каждой библиотеке.

Символ исчез, расхождение осталось

Служба поддержки получает жалобу: регистрация прошла, но восстановление учётной записи не находит адрес. На экране значение выглядит обычным. Развёртка по кодовым точкам обнаруживает U+3164 перед разделителем. HANGUL FILLER не занимает видимого места в шрифте, но остаётся частью UTF-8-входа.

Форма может сохранить его, поисковый индекс — удалить, а шлюз — отклонить. Если аудит хранит лишь отрисованный текст, все три события будут выглядеть одинаково. В момент записи исчезнет свидетельство, которое объясняет разные решения.

Версия 05 документа SMTPUTF8 Email Addresses добавляет U+3164 как недопустимый пример. Второй новый случай — U+0640 ARABIC TATWEEL. По общей категории Unicode это буква, но она растягивает предшествующий знак; повторное добавление даёт множество последовательностей с похожим начертанием.

Datatracker указывает, что это активный Internet-Draft рабочей группы Mail Maintenance, претендующий на Proposed Standard. История датирует ревизию 10 сентября. Эти сведения не означают принятия RFC, консенсуса IETF, внедрения или подтверждённого инцидента.

Вместо локального списка — общая процедура

Версия 04 перечисляла категории A, H, K, отдельные элементы F из RFC 8264 и пунктуацию адреса. Версия 05 говорит иначе: разрешены только кодовые точки, которые IdentifierClass считает допустимыми; для контекстных точек соответствующее правило обязано выполниться.

Так ссылка передаёт не таблицу, а процедуру. RFC 8264 различает четыре результата: valid, contextual rule required, disallowed и unassigned. Например, знак управления соединением нельзя решать без соседнего контекста. Проверка только общей категории Unicode обрывает цепочку раньше времени.

IdentifierClass предназначен для строк, обозначающих или адресующих сетевой объект. Безопасность в нём поставлена выше широты выражения. Традиционные буквы и цифры, а также печатный ASCII допускаются по правилам; старые корейские jamo, управляющие и игнорируемые знаки, пробелы, формы совместимости и ряд других классов исключаются.

Но профиль приложения всё равно обязан определить преобразование ширины, дополнительные отображения, регистр, нормализацию и направление письма. Общая база не отменяет локальное решение. Она показывает, где оно начинается.

U+0640 не помещается в ярлык «буква»

RFC 5892 помещает U+0640 в таблицу исключений и назначает DISALLOWED. Без исключения обычный расчёт свойств дал бы PVALID. Поэтому запись «категория Letter» истинна, но не является полным обоснованием допуска.

Публичный набор тестов авторов охватывает также двунаправленные управляющие знаки, полноширинные совместимые буквы, составные старые Hangul Jamo и соответствующий предкомпонованный слог. Тесты воспроизводят предложенную границу, но не удостоверяют работу производственных форм, каталогов, восстановления и SMTP.

Третье правило запрещает более одной не-ASCII письменности в адресе, если ASCII не учитывать при подсчёте. Unicode Standard Annex #24 задаёт свойство Script для такого расчёта. Это предлагаемая граница совместимости идентификатора, а не оценка многоязычного человека.

Пробел в кавычках требует публичного ответа

Текущий текст буквально разрешает кодовые точки, допустимые в IdentifierClass, и пробел в кавычках. Следующие примеры отдельно называют точку, косую черту и знак at. Та же фраза находится в публичном исходнике авторов.

Это может быть опечатка, неявная опора на грамматику mailbox или незавершённая правка. Доступные материалы не выбирают вариант. Поскольку пунктуация делит локальную часть и домен, репертуар символов и синтаксическая продукция должны проверяться отдельно.

Разработчик может временно выбрать толкование, но должен сохранить номер версии, допущение и тест. Тихая правка не создаёт переносимой конформности и способна развести две разумные реализации.

Правильная строка не удостоверяет владельца

RFC 6532 разрешает прямой UTF-8 в заголовках и адресах международной почты. Новый проект ограничивает допустимые строки внутри этого пространства. Ни один слой не аутентифицирует человека.

Синтаксически допустимый ящик может не существовать. Ответ на проверочное письмо показывает контроль в определённый момент, но не юридическую личность. Значение может пройти форму и исказиться при экспорте. Первый SMTPUTF8-совместимый узел не доказывает весь маршрут. Запрещённый знак также не доказывает злой умысел: его могли скопировать, не видя.

Ранее BTW описывал другую историю SMTPUTF8 — сохранение международной локальной части на всём пути без общего механизма понижения. Здесь объектом является более ранний фильтр допуска. Эти проверки независимы.

Квитанция о ходе проверки

Минимальная квитанция связывает исходные UTF-8-байты с упорядоченными кодовыми точками и их местом в грамматике. Для каждого не-ASCII-знака она хранит решение IdentifierClass, контекстное правило и результат, а также расчёт письменности. Отдельно записываются политика отображения, регистра, нормализации и bidi.

Далее нужны версия данных Unicode/PRECIS, сборка валидатора, точка вызова, время, принятое действие и способ исправления. В интерфейсе можно показывать читаемую и экранированную форму рядом; исходник должен оставаться защищённым свидетельством.

Это редакционное предложение Daniel Kade, а не норма IETF. Оно не унифицирует политику ящиков. Оно позволяет выяснить, получили ли разные сервисы один объект и применили ли к нему одну версию правил.

Источники