Кратко

  • RFC 2047 Кита Мура задаёт ограниченную ASCII-форму для не-ASCII-текста в разрешённых позициях почтовых заголовков; она не переписывает синтаксис адреса и не удостоверяет отправителя.
  • Надёжная проверка хранит отдельно сырой заголовок, разобранную структуру, charset и декодирование, отображаемое имя, addr-spec, подписанные DKIM-поля и домен SDID.

Почтовая программа показывает знакомое имя и рядом сообщает, что подпись действительна. Оба сообщения интерфейса могут быть корректны. Ошибка возникает в уме наблюдателя: два факта складываются в вывод «этот человек проверен», хотя первый относится к отображению текста, а второй — к криптографической проверке определённых данных от имени домена.

В 1996 году Кит Мур опубликовал RFC 2047. Документ описал encoded-word — последовательность из ASCII-символов, которая указывает набор символов, способ Q или B и закодированный текст. Это позволило переносить имена, темы и другой разрешённый текст вне ASCII через инфраструктуру, созданную для более узкого набора символов. Но RFC не была единоличным изобретением всего MIME и не создавала систему доверия к отправителю. Она решала задачу представления.

Размер одного кодированного слова ограничен 75 символами, а документ работает с пределом строки заголовка в 76 символов. Поэтому одна видимая фраза может быть разбита на несколько единиц. Линейный пробел между соседними encoded-words при показе разрешено игнорировать, однако каждая единица должна декодироваться самостоятельно. Скрыто переносить состояние кодировки между ними нельзя.

Граница применимости важнее внешнего рисунка. RFC 2047 допускает такую форму в тексте некоторых полей, в комментариях и как слова внутри phrase. Она запрещена внутри addr-spec, внутри строки в кавычках, в полях Received, в параметрах MIME и в прочих структурированных местах без явного разрешения. Совпадение с характерным шаблоном ещё не делает последовательность допустимым кодированным словом.

Правильный порядок таков: сначала анализируется структура поля, затем в разрешённых позициях распознаются encoded-words, после чего содержимое декодируется для отображения. Если результат содержит @, двоеточие, кавычку или скобку, эти знаки не отправляются обратно в синтаксический анализатор. Их положение уже установлено. Они остаются символами отображаемого текста, а не становятся новым адресом, новым полем или комментарием.

Это позволяет описать проверяемую цепочку преобразований. Сначала идут исходные байты заголовка; затем токены и границы грамматики; далее объявленный charset и способ декодирования; потом полученные байты, кодовые точки Unicode и нормализация; наконец шрифт, направление и компоновка интерфейса. Сбой или изменение на любом шаге может поменять экран, не меняя исходное сообщение.

Неизвестный charset, неверная последовательность или незаконное положение дают неодинаковые результаты в разных клиентах. Один покажет сырой шаблон, второй заменит символы, третий применит осторожное восстановление, четвёртый откажется декодировать. Поэтому современный снимок экрана не доказывает, как все исторические программы показывали письмо. Для повторяемости нужны исходный заголовок, версия клиента, политика обработки ошибок и фактический результат рендеринга.

RFC 5322 отделяет удобочитаемый display-name от addr-spec, где синтаксически определены почтовый ящик и домен. Имя может помогать человеку узнавать корреспондента, но оно не становится адресом. Поля From и Sender также имеют разные формальные роли в формате сообщения. Эти роли описывают авторство и передачу на уровне документа, а не являются самостоятельной криптографической проверкой человека или владения ящиком.

RFC 6532 позже разрешила прямой UTF-8 в заголовках международной почты и рекомендовала NFC-нормализацию. Это даёт иной путь представления, но не отменяет разделение. Визуально похожие символы могут иметь разные кодовые точки, а эквивалентный текст — разные последовательности до нормализации. Нормализация улучшает сопоставление; она не выдаёт удостоверение личности.

DKIM отвечает ещё на один отдельный вопрос. По RFC 6376 подпись охватывает канонизированное тело и перечисленные поля заголовка. Signing Domain Identifier, SDID, указывает домен, принимающий ответственность за проверяемую подпись. Успешная проверка не превращает показанное имя в проверенного человека, не означает, что подписано всё видимое, и не обязана связывать домен из адреса From с доменом подписи.

Следовательно, запись «DKIM: pass» без перечня охваченных полей слишком широка для серьёзного вывода. Нужно сохранить сырой заголовок, результат структурного разбора, местоположение encoded-word, charset и метод, декодированные байты, кодовые точки и нормализацию, отдельные значения имени и addr-spec, перечень подписанных полей, криптографический результат, SDID и преобразование интерфейса. Тогда каждое утверждение можно проверить в его собственных границах.

Долговечность решения Мура определяется не только тем, что оно сделало международные заголовки читаемыми. RFC также оставила ясный предел: представление текста не должно незаметно становиться синтаксисом или полномочием. Кодированное слово меняет то, что видит читатель. Само по себе оно не меняет владельца ящика, подписавший домен или доказанную личность.

Источники