Кратко

  • RFC 1211 приводит ошибки для ящиков, которых не было отдельными строками в основном списке IETF. Там хранился exploder-алиас, а конечный адрес находился в подсписке под управлением другого узла.
  • Строки Received, похожие имена хостов и SMTP-команды EXPN или VRFY помогали определить направление поиска, но часто не давали ответа. След маршрута не доказывал членство.
  • Центральный оператор мог переслать просьбу зарегистрированному владельцу или postmaster. Только удалённый владелец мог проверить и исправить скрытый список; отправленная просьба не была свидетельством исполнения.

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

Расследование в RFC 1211 начинается с поиска адреса в основном файле. Система сообщает о неизвестном пользователе или хосте, но в списке такой строки иногда нет.

Большой список мог включать другой список как один почтовый ящик. Алиас-exploder принимал сообщение на удалённом узле и разворачивал его в местную группу. Внешний реестр знал алиас; внутренний — людей за ним. Поэтому почтовая система могла верно назвать неудавшийся внутренний адрес, которого центральный оператор никогда не хранил.

У этих фактов были разные хранители. Центр подтверждал включение алиаса. Местный администратор проверял его участников. MTA наблюдал попытку доставки. Ни одна запись не становилась полной копией двух других.

Карточка RFC Editor датирует Informational-документ мартом 1991 года. IETF Datatracker относит его к Legacy stream. Это ограниченный отчёт об эксплуатации, а не обязательный стандарт и не оценка всего Интернета.

Масштаб сделал свободный текст ежедневным управляющим сигналом

Ann Westine и Jon Postel писали, что ISI обслуживал около 25 списков исследовательских групп, IETF и других сообществ. Ежемесячно поступало примерно 400 заявок на добавление или удаление и около 300 сообщений об ошибках; после дублей примерно десять случаев в день требовали разбирательства. Эти числа относятся к конкретному месту и времени.

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

До изменения списка человек должен был классифицировать событие. Одна задержка не означала удаление. Повторение в течение дней могло открыть расследование. Даже «неизвестный пользователь» требовал дополнительной проверки, если адрес связывали с активным участником. Отчёт был основанием для дела, не командой записи.

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

Маршрут говорил, у кого спросить

Когда адрес отсутствовал в основном файле, оператор читал строки Received и искал хост, похожий на известный exploder. Переходы через UUCP, BITNET или шлюзы ещё сильнее отделяли видимый путь от административной связи.

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

Современная тому времени RFC 821 отводила reverse path для возврата ошибок и разрешала специальный ящик обработки, отличный от автора письма. VRFY проверял пользователя, EXPN раскрывал список. Но обе команды не входили в обязательный минимум и не должны были работать сквозь ретрансляторы.

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

Владелец связывал право изменения с правильным файлом

При включении подсписка ISI записывал заявителя и считал его владельцем. RFC 1211 просил назначать каждому exploder местного ответственного, направлять ему ошибки его участников и поручать ему местные добавления и удаления.

Центральный оператор мог убрать весь алиас, но вместе с ним потерял бы всех скрытых участников. Исправление одного адреса принадлежало стороне, которая могла видеть и редактировать удалённый файл.

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

Надёжная цепочка различает первоначального заявителя, нынешнего владельца, получение запроса, подтверждение, решение, запись и последующую проверку. Контакт — маршрут к решению, а не само решение.

Центральный request-ящик не управлял всей вложенной структурой

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

Пересылка исправляла административное направление, но данные ещё не менялись. Удалённая сторона должна была найти запись, сопоставить заявителя, решить, записать и сохранить. Похожий хост мог привести не туда; прежний владелец мог не ответить.

Видимый центр казался управляющим всей схемой. RFC 1211 показывает различие: координация не создаёт права записи во всех вложенных реестрах.

Позднейший SMTP оставил место неизвестности

RFC 5321 разрешила отключать VRFY и EXPN по соображениям безопасности и отделила реальную проверку от кажущейся допустимости без проверки в реальном времени. Отказ раскрывать список не доказывает отсутствия.

RFC 3464 структурировала уведомления и назвала expanded нетерминальным действием: позднее возможны задержка или отказ. Это объясняет границу развёртывания, но не превращает старые тексты RFC 1211 в современные DSN и не даёт сообщающему MTA права менять чужой список.

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

Источники