Кратко

  • Cancel в Usenet был самостоятельной управляющей статьёй, проходившей по системе распространения новостей и называвшей цель через Message-ID; глобального отзыва всех копий он не обеспечивал.
  • Каждый serving agent применял местные правила авторизации, мог не исполнять запрос и мог сохранить precancel, если управляющая статья пришла раньше оригинала.
  • Cancel-Lock и Cancel-Key позднее добавили криптографическое доказательство, подготовленное при публикации, но не полную целостность статьи, универсальную личность или обязательное стирание.

Отмена шла вслед за публикацией теми же дорогами

В централизованном хранилище отзыв легко представить одной операцией над главным экземпляром. Usenet состоял из самостоятельных площадок. Каждая держала собственный spool, принимала статьи от соседей и передавала их дальше по своим связям. Главного экземпляра, которому подчинялись бы все копии, не существовало.

Поэтому сообщение об отмене само становилось новостью. RFC 850 в 1983 году описал управляющие сообщения как данные, распространяемые тем же механизмом, что и обычные сообщения USENET. Разработчик или администратор мог исполнять их автоматически либо отдавать на ручное рассмотрение.

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

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

Message-ID определял предмет, но не доказывал право

Историческая команда выглядела как cancel <message ID>. Message-ID позволял назвать одну логическую статью, даже если её копии находились в разных каталогах и поступили в разном порядке.

RFC 1036 сохранил эту форму в 1987 году и подчёркивал местный эффект. Система, не способная отменить статью, не должна была пересылать такой запрос соседям. Таким образом, даже дальнейший маршрут управления зависел от возможностей промежуточного участника.

Идентификатор отвечает на вопрос «что отзывают?», но не на вопрос «кто вправе?». Ранние правила допускали автора или локального суперпользователя и сравнивали Sender либо From управляющей и целевой статей. В среде доверительного обмена это помогало отсеять ошибки. С точки зрения безопасности копируемая строка заголовка не подтверждает согласие обозначенного человека.

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

Это важное уточнение границы доказательств. Архитектура перестала выдавать совпадение текста за аутентификацию. Цена честности состояла в том, что разные операторы неизбежно принимали разные решения.

Precancellation хранила память о ещё не пришедшем оригинале

В распределённой доставке нет общего порядка. Cancel может пройти быстрым каналом, пока оригинал задержан в другой очереди. Если сервер посмотрит в текущий spool, ничего не найдёт и забудет запрос, поздняя копия появится после уже состоявшейся попытки отзыва.

RFC 5537 предусматривает precancellation. Сервер запоминает целевой Message-ID и отклоняет оригинал, когда тот приходит позднее. Такая запись хранит не содержание, а отрицательное знание об отсутствующем объекте. Это локальный tombstone, препятствующий воскрешению старого состояния.

Глобальным он не становится. Другой узел может не получить cancel, слишком рано удалить отметку или не поддерживать такую практику. Похожие значения Newsgroups повышают шанс попасть к тем же получателям, что и оригинал, но не гарантируют одинаковое множество. В модерируемых группах действуют ещё и требования поля Approved.

Поле Supersedes не обходит эту модель. RFC 5536 определяет ссылку новой статьи на прежнюю, а RFC 5537 требует применять к эффекту отзыва те же проверки, что и к cancel. Сам факт выхода замены не доказывает власть над всеми прежними копиями.

Средство против злоупотреблений само требовало защиты

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

RFC 2635 упоминает cancelbots среди эксплуатационных ответов на повторные либо массово перекрёстные публикации. Документ фиксирует давление спама и появление автоматики, но не даёт боту всеобщей власти. Каждый запрос по-прежнему встречал местную политику.

RFC 5537 отмечает, что многие площадки игнорировали cancel и Supersedes из-за злоупотреблений и сложности аутентификации. Полный отказ защищал от поддельного удаления, но мешал законному исправлению. Безусловное исполнение давало противоположный набор рисков. Общий формат не мог заменить общее управление.

Замок публиковали заранее, ключ предъявляли потом

RFC 8315 в 2018 году предложил узкое криптографическое решение. Исходная proto-article может нести Cancel-Lock — хеш, выведенный из секретного материала без раскрытия самого секрета. Последующий cancel или статья с Supersedes содержит Cancel-Key. Участвующий агент проверяет соответствие ключа одному из замков, уже находящихся в оригинале.

Решающим является предварительное обязательство. Право подтвердить будущий отзыв готовят при вводе статьи в сеть, а не конструируют после конфликта копированием From. Автор, posting agent, модератор или injecting agent могут иметь отдельные замки. Relays после инъекции не должны их менять. Если замков несколько, знания секрета для одного действительного замка может быть достаточно.

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

Реестр параметров Netnews IANA согласует названия и статусы хеш-алгоритмов. RFC 8315 требует SHA-256; в реестре также присутствуют SHA-512, устаревший MD5 и SHA-1 ограниченного применения. Регистрация не измеряет внедрение и не обещает успешный отзыв.

Доказательство заканчивается там, где заканчивается исполнитель

Между намерением и исчезновением лежит несколько фактов: запрос создан, цель названа, сообщение доставлено, доказательство проверено, политика разрешила действие, локальная копия изменилась. Каждый факт может иметь достоверную квитанцию. Ни одна квитанция не описывает всю цепочку.

Совпадение Cancel-Key означает, что участвующий агент обнаружил одобрение относительно замка. Локальная недоступность означает, что этот агент перестал обслуживать свою копию. Другой peer, gateway, archive или сохранённый читателем экземпляр остаётся за пределами его власти. Поля с пожеланием Archive или Distribution не навязывают правила хранения открытой федерации.

Проверяемая формулировка звучит скромно: «этот сервер принял доказательство и локально сделал данный Message-ID недоступным». Фраза «сеть забыла» соединяет доставку, авторизацию, исполнение и хранение в обещание, для которого ни у кого нет полного контроля. История Usenet учит не путать отзыв запроса с владением всеми репликами.

Источники