Кратко

  • Суффиксы .priv и .shared в RFC 5257 определяют, кто видит и меняет устойчивую аннотацию. Они не доказывают, что её написал отправитель, одобрила организация или что значение никогда не менялось.
  • При COPY переносятся подходящие общие аннотации и только личные аннотации текущего пользователя. Байты письма могут сохраниться полностью, а окружающий их контекст — измениться.

Две копии письма дали два разных основания для решения

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

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

Аннотация существует отдельно от исходного сообщения. У неё своё иерархическое имя, атрибуты, область — целое письмо или часть тела — и собственные правила доступа. Совместное отображение на экране не объединяет авторство. Соседство данных не создаёт общего источника.

Личное и общее — это границы видимости

У каждого атрибута неявно есть формы .priv и .shared. При выборке или поиске суффикс можно опустить и затронуть обе формы. Для STORE, APPEND и сортировки по аннотациям клиент обязан выбрать одну. Тем самым при записи определяется личное или коллективное пространство.

Механизм решает практическую задачу: сотрудник оставляет себе напоминание в общем почтовом ящике, а команда ведёт видимый всем статус. Однако .priv не означает сквозное шифрование, юридическую тайну или недоступность любому администратору. .shared не означает проверку, истинность либо официальное одобрение.

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

ACL отвечает «может выполнить», а не «кого представляет»

Без расширения ACL доступ зависит от режима выбранного ящика: только чтение либо чтение и запись. При наличии ACL право r управляет чтением и записью личных аннотаций и чтением общих. Добавленное RFC 5257 право n разрешает создавать и менять общие значения.

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

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

Постоянное хранение не означает неизменяемую историю

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

Команда STORE может создать или заменить значение. Запись NIL удаляет его. Для отсутствующего значения чтение возвращает NIL, а размер — ноль. Без отдельной истории один итоговый вид не позволяет различить «никогда не существовало», «было намеренно удалено» и «не поместилось или не поддерживалось в месте назначения».

Для автономной работы стандарт рекомендует Conditional STORE, чтобы обнаружить изменение после последнего снимка и не затереть его молча. Обнаружение конфликта не решает, какая версия верна, кто обладал деловым мандатом и допустимо ли использовать значение в автоматическом решении. Контроль конкурентности не заменяет содержательную проверку.

Возможность сервера ещё не возможность конкретного ящика

Сервер объявляет ANNOTATE-EXPERIMENT-1, но каждый выбранный ящик сообщает собственные условия. NONE запрещает аннотации, READ-ONLY — их изменение, NOPRIVATE — личные значения. Число задаёт предельный размер, а сервер также может ограничивать количество аннотаций на сообщение.

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

Ошибки размера и количества следует фиксировать как сбой доставки метаданных. Если спрятать их за зелёным статусом копирования письма, запись будет выглядеть полной, хотя часть оснований для её интерпретации осталась в источнике.

COPY намеренно создаёт несимметричный комплект

При COPY на том же сервере реализация с ANNOTATE копирует все общие аннотации и только личные аннотации пользователя, выполняющего операцию. Личные значения других пользователей копировать нельзя. Права назначения, режим только чтения, отсутствие поддержки и лимиты размера могут дополнительно сократить набор.

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

Скопированная общая метка не получает задним числом авторитет отправителя. Её могли добавить позднее, другим аккаунтом, при другой ACL, а затем переносить между папками. COPY сохраняет значение, но не гарантирует сохранность причины, авторства и мандата.

Поиск и сортировка превращают заметку в управляющий сигнал

RFC 5257 позволяет искать значения аннотаций и сортировать сообщения по личным или общим значениям. Боковая заметка может определять очередь, приоритет, срок хранения или автоматическое действие. Чем сильнее влияние, тем важнее проверяемое происхождение.

Значение может быть синтаксически допустимым, читаемым по ACL и корректно скопированным, но всё равно устаревшим или ошибочным. Регистрация стандартного имени или пространства производителя задаёт правила интерпретации; она не подтверждает конкретный экземпляр.

Позднейший RFC 5464 отдельно описывает метаданные сервера и почтового ящика, а не аннотации отдельного сообщения. Это полезная граница: «метаданные» не образуют единую плоскость полномочий. Объект, автор, правило перемещения и потребитель определяют доказательную силу.

Нужна квитанция вокруг аннотации

Для каждого значимого значения сохраняйте ящик и UID, область сообщения или части тела, имя записи, класс .priv/.shared, личность и credential автора, снимок ACL и возможностей, хеши прежнего и нового значения, токен состояния, ответ сервера, событие удаления, решение по размеру или квоте и последующее действие.

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

Формулировка должна соответствовать доказательству. «После этой записи общая аннотация содержала “одобрено”» можно проверить. «Отправитель одобрил» требует его цепочки полномочий. «Архив сохранил весь контекст рецензентов» допустимо только при поатрибутной квитанции копирования.

RFC 5257 дал почтовым системам полезную долговременную память. Задача руководства — использовать её, не позволяя контексту присвоить голос записи, рядом с которой он хранится.

Источники