Кратко

  • RFC 9755 разделяет объявление сервера и явное включение функции аутентифицированным клиентом; ни одно не подтверждает всю цепь учётной записи, хранилища, индекса и интерфейса.
  • Приёмка заканчивается контрольным письмом, которое адресат способен увидеть в списке, найти, получить, понять и использовать.

Тест может успешно завершиться не на той границе. Сервер отвечает OK на APPEND сообщения с интернационализированными заголовками, однако получатель не находит его по отправителю, не открывает вложенное письмо или вовсе не видит его в поддерживаемом клиенте. Ответ был верен. Слишком широким оказался вывод.

RFC 9755 опубликован в марте 2025 года как Standards Track и заменяет RFC 6855 для IMAP4rev1; IMAP4rev2 уже содержит примерно те же возможности. UTF8=ACCEPT означает поддержку международных сообщений и имён ящиков UTF-8. UTF8=ONLY включает её и отказывается от modified UTF-7.

Объявление не меняет состояние сессии

Клиент сначала аутентифицируется, затем отправляет ENABLE UTF8=ACCEPT. Это верно и для UTF8=ONLY; команды ENABLE UTF8=ONLY нет. По RFC 5161 ответ ENABLED показывает реально включённые расширения. CAPABILITY не меняется и не является квитанцией сессии.

Нужны версия и режим сервера, а также команда и ответ каждого настоящего клиента. Скриншот настройки вне проверенного соединения ничего из этого не подтверждает.

Допустимая строка не создаёт пользователя

LOGIN не расширен для имени или пароля UTF-8; требуется AUTHENTICATE. Но RFC прямо говорит: законный синтаксический перенос не гарантирует, что система провижининга разрешает такую учётную запись. Отдельно подтверждаются запись в авторитетном источнике, производственная аутентификация, привязка к правильному ящику и права во всех каналах.

APPEND лишь начинает доказательство хранения

После ENABLE сервер должен принять заголовки UTF-8 в APPEND, а до него — отклонить 8-битные заголовки. Положительная и отрицательная проверки полезны, но не доказывают индексацию и отображение.

Новая редакция удаляет старый элемент APPEND UTF8 и отмечает, что IMAP4rev1, IMAP4rev2 и JMAP не дают надёжного индикатора его использования для отдельного сообщения. Поэтому сохраняют исходник и хеш, ответ, UID при наличии и последующее получение того же объекта.

Именам ящиков нужны собственные векторы. RFC 9755 требует Net-Unicode и исключает заданные управляющие символы. RFC 5198 объясняет NFC; RFC 6532 рекомендует NFC для заголовков и не рекомендует NFKC при потере написания. Одинаковый вид, байты и поиск — разные обещания.

Документация Dovecot показывает практический шов: хранение имён ящиков в UTF-8 — отдельная настройка, изменение которой может сломать существующие не-ASCII имена. Это пример реализации, не обзор рынка. Протокольное обновление не выполняет миграцию хранилища само.

У корректного BODYSTRUCTURE возможны две формы

Программа без поддержки message/global может показать неизвестное вложение. Для включённого IMAP4rev1 RFC 9755 допускает две формы BODYSTRUCTURE и требует принимать обе; IMAP4rev2 следует RFC 9051. Erratum 8697 исправляет термин на message/rfc822.

Набор проверок охватывает обе формы rev1, форму rev2, вложенные международные заголовки и сырой MIME-фрагмент. Значок вложения ещё не доказывает правильного разбора.

Получить — не значит найти

После ENABLE команда SEARCH не содержит charset; SORT и THREAD должны использовать UTF-8. Старый клиент способен успешно выполнять LIST и FETCH, но неверно искать. Фиксируйте запрос и возвращённые UID для составных и разложенных форм, заголовков, имён ящиков и тела.

Одно хранилище обслуживает IMAP, POP, webmail и разные клиенты. Отказ, уведомление, сокрытие или стандартный surrogate — разные политики, не доказательство равенства. Уже опубликованная тема хранения оригинала surrogate здесь не повторяется; вопрос в заявленном и наблюдаемом результате каждого поддерживаемого пути.

Последняя квитанция принадлежит пользователю: он видит ящик, находит письмо, узнаёт стороны, открывает части и отвечает там, где это разрешено? Источники подтверждают семантику стандартов и один шов реализации, а не качество поставщика. В различии Heng Lu между символическим представлением и исполнимой реальностью capability — представление, доступное письмо — реальность. Цепочка стандартов также включает интернационализацию SMTP, преобразование для понижения, соответствующее упрощённое поведение POP и основу IMAP4rev2. Они ограничивают выводы о совместимости, но не превращают успех одного пути во всеобщую видимость.