Кратко

  • RFC 1036 требовала наличия статьи с указанным Message-ID на локальном сервере; если отменить ее не удавалось, запрос не следовало передавать соседним системам.
  • Сообщение управления распространялось через обычный механизм групп Usenet, однако отправителем должен был быть автор статьи или локальный администратор новостей, а поля заголовка проверялись по заданному правилу.
  • Это ограниченная по хосту норма, а не доказательство того, что публикация исчезла со всех серверов, архивов и копий у читателей.

Запрос распространялся, но власть оставалась у локального узла

В Usenet не было единственного экземпляра статьи, которым распоряжался один сервер. Публикации переходили между системами разных операторов, и у каждой оставалось собственное локальное состояние. Поэтому RFC 1036 начинала обработку cancel с проверки: есть ли у этого хоста статья с указанным Message-ID?

Документ вышел в декабре 1987 года и описал cancel как сообщение управления для программы новостей. Если статья присутствовала на локальной системе, ее можно было отменить там. Если система не могла выполнить запрос, RFC предписывала не пересылать его соседним системам. Точка остановки совпадала с границей локального действия: хост не должен был отправлять дальше команду, на которую сам не мог отреагировать.

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

Команда использовала общий поток новостей

В RFC 1036 статья с полем Control считалась сообщением управления для машин Usenet, а не материалом для обычного чтения. Такие сообщения распространялись тем же механизмом групп новостей, что и статьи. Разработчики и администраторы могли выбрать автоматическую обработку или очередь; сообщения, обрабатываемые вручную, следовало рассматривать оперативно. Ошибочные сообщения управления направлялись в локальную учетную запись usenet, а не автору запроса.

Путь сообщения и результат команды оставались разными событиями. Получив cancel, хост должен был найти Message-ID в собственном хранилище и проверить отправителя. Сам факт доставки не означал, что локальная копия была отменена. Тем более он не создавал общего журнала, в котором каждый сосед отмечал бы результат.

Проверка отправителя опиралась на заголовок

Отправителем cancel мог быть автор статьи или локальный администратор новостей. Проверенным отправителем считалось значение Sender; если поля не было — использовалось From. Оно должно было совпасть с Sender или From исходной статьи. RFC также разрешала проверенному отправителю cancel совпасть с исходным From, который не был проверен.

RFC 822 объясняет, зачем нужен Sender, если сообщение отправляет агент, отличный от автора. RFC 1036 использует эти поля для проверки cancel. Однако сравнение заголовков не является цифровой подписью и не доказывает контроль над учетной записью в современном смысле. Текст задает, какие поля сравнивать, но не показывает, что их невозможно подделать или что каждый сервер выполнял эту проверку.

Что изменилось относительно RFC 850

RFC 1036 обновила и заменила RFC 850 для версии B2.11 программы News. В документе 1983 года уже разрешалось отменить статью, если она есть на локальном сервере; отправителем мог быть автор или локальный суперпользователь. Версия 1987 года назвала эту роль локальным администратором новостей и прямо добавила запрет на пересылку, если локальный сервер не смог выполнить отмену.

Это разница в опубликованных спецификациях, а не даты обновления всех машин Usenet. RFC 1036 говорит, что не определяет интернет-стандарт; она оставляет хостам свободу выбирать транспортное оборудование и программы, а также объединять новости в пакеты. Источник доказывает формулировку правила, но не его повсеместное принятие.

Локальная отмена не равна исчезновению копий

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

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

Источники и пределы

Основные источники — RFC 1036, прежде всего разделы Control и Cancel; предшествующий документ RFC 850; и RFC 822 о поле Sender. Они подтверждают текст спецификаций, но не распространенность внедрения, поведение отдельных хостов, фактическую задержку, криптографическую аутентификацию или удаление во всей сети.