Кратко

  • Значения y, n и m в LIST ACTIVE сообщали, как сервер обычно обрабатывает публикации в группе, а не выдавали персональное право клиенту.
  • Клиента можно было отклонить в группе y; клиент с особыми привилегиями мог получить доступ к публикации в группе n.
  • Каталог, аутентификация, локальная авторизация, приём статьи и её доступность читателю оставались разными свидетельствами.

Когда интерфейс неверно определил адресата сигнала

Программа получает список активных групп и видит y. Кнопка подготовки статьи становится доступной. Пользователь заканчивает текст, после чего клиент отправляет POST и получает 440 ещё до передачи тела.

Список мог быть совершенно актуальным. Его строка отвечала на вопрос об обычном порядке работы группы. Ответ 440 относился к этому клиенту, этому соединению и текущему моменту. Ошибка появилась в интерфейсе, который превратил характеристику объекта в обещание субъекту.

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

Предупреждение было уже в RFC 977

RFC 977 в 1986 году определил строки LIST: имя группы, последний и первый известные номера статей, затем флаг y или n. Формат позволял дёшево получить сведения о множестве групп.

В той же секции прямо сказано, что клиенту всё равно может быть запрещена публикация, хотя список показывает разрешающий флаг. Он нужен, в частности, для различения обычных, модерируемых и digest-групп. Это свойство независимо от разрешения, выданного NNTP-сервером клиенту.

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

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

ACTIVE оставался локальным представлением

RFC 3977 назвал вариант LIST ACTIVE. Без фильтра сервер включает группы, которые клиенту разрешено выбирать командой GROUP. Это уже локальный вид конкретного сервера для соединения, а не мировой реестр Usenet.

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

Затем спецификация ограничивает интерпретацию: статус показывает только обычную обработку публикаций и не обязательно настроен для конкретного клиента. Запрет клиента действует и в y; особая привилегия может дать исключение в n.

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

Команда оставляла отдельные доказательства до и после текста

В RFC 3977 POST сначала получает 340 либо 440. После полного тела сервер возвращает 240 либо 441. Ранний отказ не раскрывает черновик серверу; поздняя ошибка происходит уже после передачи содержания.

Даже 240 не означает немедленную видимость. Могут оставаться модерация, обработка и ретрансляция. Доступность нужно проверять отдельно.

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

Успешная аутентификация не давала универсальных прав

RFC 4643 использует 480, когда для команды или ресурса нужна аутентификация и/или авторизация. После AUTHINFO набор возможностей может измениться: соединение представляет уже известного принципала.

Но сервер вправе после успешной аутентификации отклонить некоторые или все ресурсы кодом 502. Установить личность и выдать ей право — разные действия.

Поэтому строка LIST ACTIVE, результат AUTHINFO и ответ конкретной команды не заменяют друг друга. Кэш из имени группы и y/n/m не видит смену пользователя, TLS, сервера или версии политики. После переходов безопасности и идентичности возможности следует запросить заново, а действие — оценить в новом состоянии.

m описывал маршрут, а не удостоверение модератора

Статус m говорит, что публикации направятся модератору. Он не удостоверяет модератора и не обещает одобрение. RFC 5537 разделяет posting-, injecting-, relaying-, serving- и reading agents, а также модератора, поскольку у каждого этапа своя ответственность.

Опубликованная ранее статья об Approved рассматривает власть модератора. Здесь m нужен лишь для подтверждения: список описывает обычный путь. Разрешение отправить не доказывает авторство; приём не гарантирует ретрансляцию; ретрансляция не гарантирует чтение.

Реестр сохранил разные действия разными именами

Реестр параметров NNTP IANA отдельно регистрирует LIST, POST, AUTHINFO и READER. Он не доказывает современное внедрение, но даёт разные совместимые названия обнаружению, отправке, идентичности и чтению.

Каталог полезен именно потому, что обобщает. Опасность начинается, когда обобщение объявляют личным решением. Зелёный сигнал NNTP был настоящим — он относился к обычному режиму группы, а не к вашим правам.

Источники