Кратко

  • RFC 1204 рекомендовал отвечать 250 на синтаксически корректный USER, даже если posting server не узнавал имя. Так клиент не мог перечислять учётные записи; ответ не подтверждал их наличие.
  • Отдельный PASS 250 означал проверку связи пароля с ранее указанным именем. DATA 354 только открывал ввод текста, а 250 после тела фиксировал локальную постановку в очередь.
  • NOOP 250 сообщал лишь об отсутствии внутренней ошибки posting server в текущем сеансе. Без команды, состояния и компонента одинаковый код не называет наблюдаемый факт.

Положительный ответ намеренно ничего не говорил о наличии

RFC 1204 определял экспериментальный Message Posting Protocol между персональным компьютером и почтовым сервисом. На первом шаге клиент передавал имя командой USER. В списке ответов 250 назывался принятием имени.

Следующий абзац запрещал делать из этого вывод о записи. Если строка имела правильный синтаксис, серверу рекомендовалось вернуть 250, даже когда он не распознавал username. Клиент не должен был проверять существование выбранного пользователя и получать лишние сведения о базе.

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

Карточка RFC Editor фиксирует февраль 1991 года и статус Experimental. Нынешняя карточка IETF Datatracker относит документ к Legacy stream, отмечает отсутствие формально записанного источника и говорит, что IETF его не одобряет, а в современной процедуре стандартов он не имеет формального положения. Это граница исторического свидетельства: механизм описан, распространение не доказано.

Посредник получал не всю власть почтового пути

Авторы исходили из того, что операционные системы PC того времени не предоставляли аутентификацию пользователя, а почта нуждалась в защите от подделки отправителя. Message posting server на сервисном хосте должен был проверить пользователя компьютера и от его имени передать сообщение системе доставки вроде Sendmail или MMDF.

Роли были отдельными. Клиент предоставлял данные. Posting server распоряжался локальной проверкой и очередью. Delivery system выполнял дальнейшие попытки. Netix MPP работал поверх TCP на порту 218 и заимствовал модель команд и ответов у SMTP и FTP.

RFC 821 описывал пошаговый SMTP-диалог, числовые replies, DATA и точечный терминатор. RFC 1204 перенёс знакомую грамматику на границу PC—posting agent. Цифры сохранились, но предмет ответа определяли команда и текущее состояние.

PASS превращал следующий 250 в проверку отношения

После USER 250 клиент отправлял PASS. Теперь 250 означал, что пароль принят и проверен как правильно связанный с предыдущим username. Неверное соответствие получало 530; синтаксис, порядок и внутренние сбои имели свои ответы.

Первый успех скрывал распознавание, второй документировал credential check. Без этого разделения сервер либо выдавал бы каталог пользователей, либо не мог бы подтвердить, что секрет вообще проверялся.

Но и PASS 250 оставался локальным утверждением. RFC не удостоверял физического человека за клавиатурой, юридическую личность, авторство текста, правдивость содержания или разрешение писать любому адресату. Компонент говорил о настроенной связи имени и пароля.

Поздняя RFC 4954 оформила SMTP AUTH как переговоры о механизме SASL с отдельными кодами. Она также потребовала конфигурацию, запрещающую plaintext password mechanism без TLS или иной защиты от перехвата. Эти более новые требования нельзя приписывать MPP задним числом; они лишь показывают самостоятельность аутентификации и защиты канала.

Готовность к DATA ещё не была владением сообщением

После успешного пароля клиент мог послать DATA. Ответ 354 переводил parser в режим текста: сервер готов читать следующие байты как message body. Полный объект ещё не пришёл.

Клиент передавал текст и SMTP-подобный терминатор. Только после него очередной 250 означал, что сообщение успешно поставлено в очередь доставки. При внутреннем сбое 451 явно сообщал, что очередь не приняла текст.

Постановка в очередь была реальным локальным custody event, но не доставкой. RFC требовал, чтобы posting server попытался как можно скорее передать принятые сообщения delivery system. Ошибки доставки должен был обрабатывать уже тот компонент, без вмешательства posting server.

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

NOOP проверял ещё более узкую поверхность

NOOP не выполнял действия над сообщением. 250 после него означал только, что в текущем сеансе posting server не столкнулся с внутренней ошибкой. Проверки delivery system не происходило.

Одинаковая последовательность цифр могла относиться к четырём разным записям:

  • имя допустимо по форме, но результат распознавания скрыт;
  • пароль проверен против предыдущего имени;
  • полное тело принято локальной очередью;
  • в posting server нет известной внутренней ошибки текущего сеанса.

Поле success=true уничтожило бы смысл. Полноценная запись сохраняет протокол, соединение, команду, порядок, состояние до и после, отвечающий компонент и объект его решения.

Поздняя архитектура submission назвала границу явно

RFC 6409 позднее закрепил message submission на порту 587. Message Submission Agent принимает сообщения от пользовательского агента и либо доставляет их, либо передаёт Message Transfer Agent. Раздельные сервисы могут применять разные политики и меры безопасности.

Структурное сходство не доказывает прямую родословную и не свидетельствует о сохранении MPP. Оно показывает более узкое: роль отправки полезно отделять от переноса, потому что локальное принятие и конец пути принадлежат разным наблюдателям.

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

Источники