Кратко

  • RFC 1036 требовал строку Approved: для публикаций в модерируемых группах и указывал, что модератор должен добавить свой почтовый адрес.
  • Это был сигнал допуска и маршрутизации, а не криптографическое удостоверение: поздний исторический текст прямо говорил, что заявленное одобрение нельзя проверить.

Решение должно было путешествовать вместе с публикацией

Usenet не была центральным сервером, который принимал каждую публикацию и утверждал окончательную копию от имени всей сети. Статьи переходили между узлами, обменивались выбранные группы новостей, а местные системы хранили собственные копии. Чтобы правило модерации действовало на всём пути, публикация должна была нести понятную программе отметку: можно ли передать её дальше обычным порядком или сначала требуется проверка?

Опубликованная в декабре 1987 года RFC 1036, стандарт обмена сообщениями Usenet, дала такой отметке короткое имя — Approved. В общем перечне заголовков поле считалось необязательным, но для публикации в модерируемой группе оно было обязательным. Модератору предписывалось добавить свой почтовый адрес. Адрес давал практический контакт и позволял программам распознать заявленное состояние. Однако спецификация не вводила цифровую подпись, ключ или доверенный каталог, по которому принимающий узел мог бы удостовериться, что адрес принадлежит признанному модератору.

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

То же поле сопровождало команды управления группами

Пример RFC 1036 показывает, как выглядела эта отметка. Отчёт о читательской аудитории от 1 октября 1986 года распространяется в news.lists и news.groups и содержит поле Approved с адресом модератора. Поле Xref также указывает локальные номера статей на узле seismo. Пример показывает адрес в обычной статье, циркулирующей по сети; он не сообщает, насколько часто использовалось поле и как его проверял каждый узел.

Отметка появлялась и в более значимых ситуациях. RFC описывает управляющее сообщение newgroup, запрашивающее создание группы с возможностью объявить её модерируемой. Узлы должны были игнорировать сообщение без Approved. Аналогичное требование действовало для rmgroup, запрашивавшего удаление группы со всех хостов. Документ призывал к осторожности, поскольку удаление имело сетевой охват. Поле помогало программе отличить обычную команду от команды с заявлением об одобрении, но не удостоверяло источник полномочий.

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

Поздний проект прямо назвал пробел доверия

Хронологию «Son of 1036» важно описывать точно. RFC 1849 опубликована в марте 2010 года как исторический документ, сохраняющий проект, который, по словам автора, широко распространялся в начале 1990-х и стал фактическим ориентиром для разработчиков новостного ПО. Сам документ говорит, что это исторический контекст, а не современное руководство по реализации.

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

Исторический документ прямо указывает на ограничение: не было способа проверить подлинность Approved и убедиться, что заявленное одобрение действительно дано; не существовало и поддерживаемого актуального списка легитимных согласующих. Криптографическая проверка упоминалась как желательное расширение, но документ отмечал, что многие новостные системы не имели доступа к серверам ключей в реальном времени. Это свидетельство ограничения дизайна, но не доказательство конкретного подлога или всеобщего принятия поддельных заголовков.

Позднее RFC 5537 формализовала путь ввода: агент передачи направляет неутверждённую статью модератору первой модерируемой группы в списке Newsgroups, обычно по электронной почте. Одобрение и ввод в сеть отделены от обычной ретрансляции. Эта более поздняя спецификация проясняет разделение ролей, но её нельзя автоматически переносить на каждую установку 1980-х годов.

Что отметка делала — и чего не решала

Approved: не была бесполезной из-за отсутствия криптографического доказательства. Она давала разным новостным программам общее условие обработки статьи и практический адрес модерации. Редакционное решение могло перемещаться вместе с распределённой издательской системой. Но переносимость заканчивалась там, где начинались отношения доверия вокруг заголовка.

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

Источники