Кратко

  • RFC 9979 закрепляет общие имена полезных состояний IMAP и JMAP, но намеренно ограничивает их смысл: $istrusted остаётся утверждением сервера, $unsubscribed — записью о попытке, $new — сигналом внимания, а Scheduled — именем места хранения.
  • Для доказуемого решения необходимо отдельно фиксировать, кто поставил метку, по какому правилу и свидетельствам, когда и в какой области, как её показали клиенты, какое действие последовало и какой независимый документ подтвердил итог.

В строке реестра IANA всё выглядело официально: имя ключевого слова, область применения, назначение и ссылка на спецификацию. В отчёте о проверке эта строка незаметно превратилась в более сильное утверждение: раз $istrusted зарегистрировано, значит конкретное письмо заслуживало доверия; раз $unsubscribed стандартизировано, значит подписка была прекращена.

Первое утверждение верно только о словаре. Второе и третье требуют фактов, которых в реестре нет.

Это составной пример, а не сообщение о провайдере, почтовом ящике или происшествии. Различия опираются на RFC 9979, информационный документ IETF, опубликованный в мае 2026 года. Он стандартизирует 17 ключевых слов сообщений и три атрибута имён почтовых ящиков, уже применявшихся в разных реализациях. Общая орфография и согласованный смысл уменьшают коллизии и позволяют клиентам распознавать одно состояние. Они не заверяют правильность состояния конкретного сообщения.

Реестр ключевых слов IMAP и JMAP фиксирует имя, тип, назначение, область и определяющую спецификацию. Реестр атрибутов имён почтовых ящиков делает то же для Memos, Scheduled и Snoozed. IANA координирует пространство имён. Она не запускает классификатор, не наблюдает нажатие кнопки отказа от рассылки и не получает ответ транспортного сервера.

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

У RFC 9979 зрелая основа. RFC 5788 создал реестр ключевых слов. RFC 8457 ранее задал общую модель важности. RFC 9051 определяет IMAP4rev2, а RFC 8621 — JMAP Mail. Согласованное состояние улучшает совместимость этих поверхностей. Локальная политика, породившая состояние, от этого не становится общей или доказанной.

Самый наглядный пример — вложения. $hasattachment и $hasnoattachment взаимно исключают друг друга. Вторая метка не лишняя: RFC 9979 прямо указывает, что отсутствие $hasattachment ничего не решает, поскольку анализ мог вообще не выполняться. Поэтому существуют как минимум три рабочих состояния: обнаружено, явно не обнаружено и неизвестно. Интерфейс с одной скрепкой и пустым местом легко скрывает это различие. Пустота не равна отрицательному результату.

Свойство JMAP hasAttachment должно отражать ту же информацию. Совпадение между протоколами является свидетельством согласованности проекций. Оно не доказывает, что анализатор выбрал правильное MIME-дерево, был актуальной версии, отработал в нужный момент или не утратил силу после изменения сообщения.

Пара $memo и $hasmemo показывает проблему перехода. Первая метка относится к сообщению-заметке, вторая — к сообщению, которое этой заметкой аннотировано. При создании или удалении заметки клиент обязан согласованно изменить обе стороны. RFC 8474 даёт устойчивые идентификаторы объектов и цепочек для связанного поведения IMAP. Но если клиент завершится между двумя записями, оставшаяся метка будет синтаксически допустимой и при этом устаревшим свидетельством отношения. Текущее состояние не восстанавливает прерванную транзакцию.

Особенно важна метка доверия. RFC 9979 определяет $istrusted как рекомендательное утверждение сервера: имя отправителя и адрес электронной почты проверены с высокой степенью уверенности. Документ предупреждает, что ошибочная метка способна склонить пользователя довериться мошенническому письму. И прямо запрещает присваивать её лишь потому, что прошли SPF, DKIM или DMARC.

Это не критика механизмов аутентификации. RFC 7208 проверяет право хоста использовать идентичность конверта. RFC 6376 связывает доменную подпись с выбранными частями сообщения. RFC 9989 оценивает выравнивание с видимым доменом автора и задаёт политику получателя. Это полезные, но ограниченные доказательства. Они не удостоверяют автоматически отображаемое имя, конкретного человека, деловые полномочия, безопасность ссылок или истинность текста.

Универсального алгоритма или числового порога для «высокой степени уверенности» RFC 9979 не задаёт. Такая локальная свобода оправданна, однако именно поэтому происхождение решения необходимо хранить отдельно. Рядом с меткой доверия нужен защищённый журнал: какой сервер её поставил, какая версия правила действовала, какие классы свидетельств учитывались, какова уверенность, когда решение принято, когда истекает и как отзывается. Интерфейс должен описывать область утверждения соразмерно доказательству. Яркий знак без метода превращает локальный классификатор в заёмный авторитет.

Раздел безопасности формулирует принцип прямо: толкование ключевых слов зависит от доверия клиента и пользователя к серверу IMAP. Скомпрометированный или злонамеренный сервер может поставить или изменить метки так, чтобы ввести человека в заблуждение. Идеальная синхронизация не исправляет ложное исходное утверждение. Она лишь безошибочно переносит его на следующий экран.

Состояние подписки содержит иную категориальную ошибку. $canunsubscribe означает, что сообщение предлагает совместимый механизм List-Unsubscribe и прошло достаточные для реализации проверки репутации. RFC 8058 определяет сигнал отказа одним нажатием. Возможность предложить действие ещё не означает его выполнение.

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

Метки внимания принадлежат ещё одной оси. $new может вернуть старое отложенное сообщение на заметное место после пробуждения. Это не дата создания и не время доставки. $notify просит совместимый клиент показать уведомление с учётом пользовательских настроек. Метка не доказывает, что уведомление отрисовано, замечено или привело к действию. Запрос, показ, просмотр и реакция — четыре разных свидетельства.

Атрибуты почтовых ящиков столь же скромны. Snoozed определяет место временного хранения отложенных сообщений; RFC 9979 намеренно не задаёт механизм и интерфейс откладывания. Scheduled указывает на ящик с сообщениями, предназначенными для будущей отправки. Наличие письма в нём не является доказательством передачи, приёма ретранслятором или доставки. Для этого нужны запись расписания, факт запуска, транспортный ответ и конечное состояние.

Пара $followed и $muted показывает, зачем детерминированной семантике всё равно нужна история. Метки взаимно исключаются, а при противоречии приоритет получает followed. Это разумное правило совместимости: клиенты сходятся в поведении, а не гадают. Но правило не говорит, возникло ли противоречие из-за старого клиента, гонки, злоумышленника или процедуры восстановления. RFC 9979 предупреждает, что захвативший учётную запись человек может заглушить цепочки и скрыть ответы; при восстановлении следует проверить действия mute.

Так удобное состояние превращается в средство управления вниманием. Та же метка, которая уменьшает шум, способна спрятать переписку о смене платёжных реквизитов, сбросе пароля или инциденте безопасности. Сбросить пароль и принять синхронизированное mute-состояние как истину — значит восстановить доступ, не восстановив целостность внимания.

Карточка RFC Editor и поиск опечаток RFC 9979 ограничивают документальную базу. Они не устанавливают, какие провайдеры внедрили метки, как работают их классификаторы и верно ли обработано хоть одно письмо. Принадлежность авторов документа к организациям также не является свидетельством развёртывания.

В модели Heng Lu Reality Layers реестровое значение, локальное правило, утверждение сервера, синхронизированное состояние, экран клиента, убеждение человека, автоматическое действие и внешний итог принадлежат разным слоям. Running-Code Primacy ставит исполненный классификатор и фактический эффект выше элегантности токена. Minimum Initial Specification объясняет преимущество малого общего слоя: согласовать имена и разрешение конфликтов, сохранив локальные суждения видимыми и подотчётными.

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

RFC 9979 делает компактные состояния переносимыми. Ответственное управление не позволяет этой переносимости превратить метку в утверждение об аутентичности, успехе, времени или доставке, которых никто не наблюдал.

Источники