Кратко

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

В таблице сверки две строки совпали. Для автоматизации это привлекательный момент: можно перестать искать соответствие и продолжить работу. Но если таблица выбросила учётную запись и тип объекта, она могла сохранить как раз недостаточную часть доказательства.

RFC 8620 задаёт область уникальности идентификатора записи JMAP: один тип данных внутри одной учётной записи. Это не глобальное имя, которому можно доверять независимо от места использования. При переходе с IMAP важен не красивый идентификатор сам по себе, а обещание о том, какой объект он обозначает в согласованном контексте.

Такое обещание даёт RFC 9698. Документ опубликован в январе 2025 года и имеет статус Proposed Standard. Расширение JMAPACCESS предназначено для постепенного перехода и использования возможностей JMAP внутри клиента IMAP. Оно позволяет начать новый доступ из уже аутентифицированного соединения, сохраняя полезную связь с прежними объектами.

Полный набор, а не похожий фрагмент

Расширение поддерживает только полную эквивалентность: через оба протокола доступен один и тот же набор сообщений. Совпадение части папок или общего поставщика не заменяет это условие. Для почтового ящика или сообщения с object ID в одном протоколе сервер утверждает доступность того же объекта с тем же ID в другом.

Поэтому необходимо также объявить OBJECTID из RFC 8474. Обычный UID, относящийся к почтовому ящику IMAP, не становится межпротокольным идентификатором по решению клиента. При этом EMAILID связывает неизменяемое содержимое, а экземпляры с одинаковым EMAILID могут иметь разные ключевые слова.

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

Почему успешного входа IMAP недостаточно

После успешного LOGIN или AUTHENTICATE сервер оценивает применённый способ аутентификации. Если из него можно вывести достаточность учётных данных для JMAP, последующие списки возможностей должны содержать JMAPACCESS. В примерах RFC основанием служит общая инфраструктура OAuth либо база паролей.

Другой пример описывает временную асимметрию: старым клиентам IMAP ещё разрешены пароли, а JMAP их уже не принимает. Вход IMAP успешен, но JMAPACCESS отсутствует. Следовательно, отсутствие объявления само по себе не доказывает отсутствие сервиса JMAP. Проверка должна учитывать конкретный путь аутентификации.

За адресом клиент обращается командой GETJMAPACCESS. Если соответствующий сервис известен, ответ без тега JMAPACCESS содержит единственный URL ресурса Session, после чего следует OK с тегом. Если неизвестен, сервер обязан вернуть BAD и не объявлять возможность.

Техническое исправление 8635, подтверждённое 21 ноября 2025 года, заменяет ошибочную команду JMAPACCESS в примере 2 на GETJMAPACCESS. Оно исправляет пример, а не сообщает об эксплуатации уязвимости или новом способе входа.

Получить URL — ещё не выполнить аутентифицированный GET к Session. Именно успешная операция, согласно RFC 8620, возвращает объект с доступными для данных полномочий учётными записями и возможностями. Расширение не выдаёт новые секреты и не отменяет последующую аутентификацию. Вывод сервера о пригодности данных и результат конкретного запроса должны иметь разные записи.

Между наблюдениями продолжает работать система

RFC 9698 прямо допускает удаление сообщения за полсекунды между обращениями IMAP и JMAP. Идентичность не меняет жизненный цикл. Если второй запрос ничего не нашёл, нужны временная последовательность и сведения об удалении, прежде чем объявлять нарушение соответствия.

У полей есть собственные правила. Документ рекомендует по возможности согласовывать flags и другие данные, но сам не требует одинаковых имён ящиков. RFC 8621 отдельно регулирует имена, роли и принадлежность сообщения к ящикам. Email ID сохраняется при смене ящика; модель может допускать несколько принадлежностей. Сверять следует смысл поля, а не ожидать одинаковой картинки от двух клиентов.

Международные адреса показывают ещё одну причину расхождений. В описанных RFC 9698 условиях устаревшего IMAP отсутствие включённого UTF8=ACCEPT может привести к упрощённым полям, тогда как JMAP отдаёт точные. RFC 6855 объясняет ограничения таких заменителей, включая возможные последствия для ответа и проверки подписи. Совпавший ID не делает представления побайтно одинаковыми. Это оговорка о конкретном переходном режиме, а не общее обвинение всех соединений IMAP4rev2.

Обоснование безопасности в RFC 9698 также ограничено. Клиент уже располагает действительными учётными данными, а адрес можно обнаружить существующими средствами JMAP; авторы поэтому считают дополнительную выгоду для атакующего небольшой. Это не аудит производственной конфигурации. Обычные требования защиты транспорта и аутентификации продолжают действовать.

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

Для этой статьи не проводились испытания поставщиков, измерения эффективности или расследования инцидентов. Практический вывод — раздельно фиксировать объявление, адрес, фактическую аутентификацию, соответствие аккаунта и объекта, текущее состояние и результат действия. Это предложенная схема эксплуатации, не дополнительные нормативные требования.