Кратко

  • Каждый агент Netnews добавлял свою path identity слева, поэтому самый свежий шаг оказывался первым, а след рос против направления чтения.
  • Перед передачей сервер мог исключить соседа, уже указанного в Path. Отдельная локальная история по Message-ID по-прежнему отклоняла дубликаты, пришедшие иным путём.
  • !! заявляло о проверке соседней идентичности, одиночный ! — нет; POSTED, MISMATCH, SEEN и хвост not-for-mail имели разные границы смысла.

Когда дубликат отброшен, передача уже оплачена

Пусть A передаёт статью серверу B. При рассылке по принципу flood-fill B предлагает принятую статью нескольким заинтересованным соседям. Если среди них снова окажется A, тот сверит Message-ID с историей и немедленно отвергнет копию. Цикл прекратится, однако соединение перенесло объект, который заведомо не мог стать новой статьёй.

Поэтому системе понадобились две памяти. История внутри сервера отвечала: «видел ли я эту логическую статью?» Поле Path позволяло до отправки спросить: «есть ли будущий получатель в уже пройденной цепочке?» Первая обеспечивала сходимость, вторая убирала очевидную лишнюю работу на конкретном ребре.

RFC 1036 проводит это разделение явно. Учёта Message-ID достаточно, чтобы остановить петлю. Path служит дополнительной оптимизацией и, в частности, не даёт B сразу вернуть A полученную от A статью. Поэтому тема не повторяет существующую историю глобального имени сообщения: здесь важен выбор соседа до передачи дубликата.

Новейший шаг появлялся слева

Получив A!X!Y!Z, сервер B превращал строку в B!A!X!Y!Z. Текущий обработчик стоял слева, более ранние — уходили вправо. Поле менялось при распространении, не создавая новую логическую статью.

Уже RFC 850 1983 года описывал добавление имени слева. Он допускал разные разделители и сохранял внешность старых UUCP-маршрутов с восклицательными знаками. Именно поэтому спецификация сделала оговорку: Path не предназначался для ответа и не должен считаться почтовым адресом.

Маршрут новости мог не совпадать с маршрутом почты. Короткое имя, согласованное двумя news-релеями, могло быть неизвестно почтовой программе. Эпизодическая работоспособность в старой реализации не превращала сходство в обязательство протокола.

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

Там же объяснена цена ошибки. История Message-ID отвергнет вернувшуюся копию, но путаница имён способна заставить каждую статью дважды пройти один feed. Итоговый набор статей останется правильным, а эксплуатационные расходы вырастут.

Хвост не был последним посещённым сервером

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

RFC 5536 формально разводит path-list и tail-entry. Хвост может содержать not-for-mail. Это не ошибка и не имя машины, а явный отказ от старой идеи, будто похожее на адрес место годится для доставки почты.

Значит, важна синтаксическая роль. Identity внутри списка может участвовать в решении «не отправлять». Источник после POSTED и финальный tail такой силы не имеют, даже если текст совпадает.

NNTP переносил статью, но не превращал Path в перечень соединений

RFC 977 в 1986 году стандартизовал распространение, чтение и публикацию news по надёжному потоку вроде TCP. В 2006 году его сменил RFC 3977. Оба описывают команды и ответы между программами, но не объявляют Path историей TCP-сессий.

Архитектура RFC 5537 прямо отделена от нижележащего транспорта. Статья переживает закрытие соединения, проходит между компонентами injection, relay и serving, а иногда пересекает gateway в другую среду. Path именует прикладные news-агенты, а не IP-маршрутизаторы.

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

Пунктуация сохраняла степень уверенности

Стандарты 2009 года требуют, чтобы обрабатывающие компоненты добавляли path identity. Предпочтителен полный доменный адрес; допускается другое имя, уникальность которого обеспечена в соответствующем круге peers. Соседи должны одинаково понимать основное имя и aliases, иначе сравнение бессмысленно.

!! означает, что агент слева проверил, по удовлетворяющим его критериям, identity непосредственно справа. Один ! такой проверки не заявляет. Нормализация, которая считает формы равными, изобретает отсутствующее свидетельство.

POSTED отмечает injection. MISMATCH фиксирует несовпадение между identity, ожидаемой из контекста соединения, и ведущей identity статьи. SEEN сохраняет наблюдавшийся источник, когда приёмник не желает или не может подтвердить его как заявленную Path-идентичность. Ожидание может опираться на аутентификацию peer или исходный IP.

Каждая метка — заявление одного наблюдателя о соседнем звене. MISMATCH может указывать на подмену, но также на устаревший alias, миграцию, proxy или регистр букв. Даже последовательность !! не становится сквозной подписью: каждая проверка локальна и криптографически не связывает всю предысторию.

RFC 5537 дополнительно советует принимать статьи лишь от доверенных агентов, чтобы ограничить подделку Path и Injection-Info. Доверие поставляет рабочее отношение, а не сама строка.

Отсутствие в списке не давало права на пересылку

Статью не следует направлять получателю, чья identity или известный alias уже есть в корректном path list. Tail и отдельные диагностические позиции исключаются. Но из отсутствия имени не следует обязанность отправить статью.

Совпадение Newsgroups и Distribution, валидность, ёмкость, доверие и локальная политика остаются самостоятельными воротами. История Message-ID нужна для копий с других направлений. Gateways требуют дополнительных мер, поскольку преобразование среды может потерять след и идентичность, а затем повторно ввести содержание в Netnews.

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

RFC подтверждают эти семантические границы, а не современное внедрение. По ним нельзя узнать, какие сервисы используют диагностику, верно ли конкретное имя и дошла ли статья до читателя. Для этого нужны журналы соединений, передачи, истории и хранения.