Кратко
- RFC 9661 разделяет загрузку содержимого, проверку, сохранение объекта
SieveScriptи активацию единственного скрипта для учётной записи. - Успешный
SieveScript/setиisActive=trueподтверждают переход состояния объекта, но не загрузку blob всеми обработчиками доставки и не результат для отдельного письма. - Надёжное подтверждение связывает хеш blob, возможности, условное состояние, ответ активации, повторное чтение через интерфейсы, поколение обработчика, трассу письма и итог.
Искушение очевидно: если сервер вернул isActive=true, назвать это фактом исполнения. Но через минуту тестовое письмо может оказаться в папке, которую задавал прежний скрипт. Тогда спор о том, «какой журнал прав», скрывает главное: журналы описывают разные границы.
RFC 9661 вводит модель управления Sieve через JMAP. У объекта есть серверный id, уникальное имя, blobId и серверный признак isActive; одновременно активен не более чем один скрипт. Стандарт делает логическое состояние наблюдаемым, но не определяет внутреннюю доставку этого состояния до всех процессов финальной обработки почты.
Четыре события нельзя сводить к одному
Загрузка blob означает приём байтов. SieveScript/validate проверяет содержимое, не сохраняя его как скрипт. Проверка охватывает синтаксис и требуемые расширения, однако RFC 5228 различает ошибки до запуска и ошибки времени исполнения. Корректный текст ещё не гарантирует успешную работу на реальном письме.
Изменение объекта следует общим правилам RFC 8620. ifInState позволяет отклонить запись, если коллекция изменилась после чтения клиентом. Это защищает от гонки и перезаписи более нового изменения. Непрозрачная строка состояния не является аттестацией кода в памяти почтового worker.
Активация добавляет атомарность: onSuccessActivateScript переключает активный объект, только если запрошенные операции успешны. В ответе должны быть видны включённый и выключенный скрипты. Граница этой гарантии — транзакция JMAP. За ней остаются задержка реплики, очередь инвалидирования, скомпилированный кэш и поэтапное обновление процессов.
Одинаковые интерфейсы ещё не означают одинаковое исполнение
RFC 9661 рассчитан на согласованный доступ к одним скриптам через JMAP и ManageSieve. После переключения следует прочитать активное имя и содержимое обоими способами. Расхождение прямо указывает на проблему хранения или представления.
Совпадение всё же может означать лишь общий источник данных. Часть обработчиков обновляется по таймеру, часть — по событию, часть читает запаздывающую реплику, часть хранит скомпилированное правило в памяти. Поэтому доказательный объект должен включать учётную запись, id скрипта, хеш blob, активное поколение, worker, идентификатор письма и принятое действие.
Отсутствие письма не доказывает discard. До финальной доставки возможны отказ, задержка, антиспам, ошибка маршрута или хранилища. Надёжный тест проходит по реальному входному пути, использует уникальный идентификатор, сохраняет подтверждение приёма и связывает письмо с worker, поколением и наблюдаемым действием.
VacationResponse показывает границу авторства
RFC 8621 определяет VacationResponse. Если сервер реализует его как Sieve-скрипт, RFC 9661 разрешает читать и активировать объект через JMAP Sieve, но запрещает менять содержимое или удалять его через SieveScript/set. Авторство принадлежит VacationResponse/set.
Тем самым видимость и право записи разделены. Рядом с хешем нужна история происхождения: редактор Sieve, генератор ответа об отсутствии, восстановление, ManageSieve или автоматика. Верный объект, изменённый по неверному каналу полномочий, остаётся нарушением контроля.
RFC 9404 расширяет управление blob, RFC 9425 показывает квоты, а реестр JMAP IANA закрепляет названия и ошибки. Эти механизмы задают границы, но не наблюдают исполнение отдельного письма.
Строить цепочку от результата назад
Сначала задаётся ожидаемое действие тестового письма. Затем фиксируются обработавший его worker и загруженное поколение. Поколение разрешается в активный id и точный хеш blob. После этого сохраняются ответ активации, старое и новое состояние, условие ifInState, результат проверки и снимок возможностей. Содержимое перечитывается через JMAP и ManageSieve.
Нужны и отрицательные испытания: несуществующий id не меняет текущий активный скрипт; удаление активного объекта возвращает sieveIsActive; синтаксически корректный тест с контролируемой ошибкой исполнения даёт понятную классификацию; скрипт VacationResponse отвергает запись из чужого интерфейса; давление квоты и перезапуск worker не скрывают состояние.
Идея Heng Lu о минимальной начальной спецификации задаёт верный масштаб: общий договор должен быть небольшим и проверяемым, а локальная архитектура — отвечать доказательствами. Слои реальности не позволяют слову «активен» присвоить смысл «исполнен». Приоритет работающего кода возвращает решающее наблюдение в точку финальной доставки.
RFC 9661 упорядочивает управляющее состояние. Оператор должен отдельно доказать, что оно стало действующим.
Источники
- RFC 9661 — HTML
- RFC 9661 — канонический текст
- RFC 9661 — исходный XML
- RFC Editor — сведения о RFC 9661
- Поиск исправлений RFC 9661
- IETF Datatracker — история RFC 9661
- RFC 8620 — ядро JMAP
- RFC 5228 — Sieve
- RFC 5804 — ManageSieve
- RFC 8621 — JMAP для почты
- RFC 9404 — управление blob в JMAP
- RFC 9425 — квоты JMAP
- IANA — реестры JMAP
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

