Кратко

  • RFC 1425 сделал EHLO общей точкой обнаружения расширений SMTP. Успешный ответ относился к одному сеансу, и клиенту запрещалось переносить его через кэш в следующий.
  • Старый сервер должен был отвергнуть EHLO, сохранив канал и состояние для HELO. RFC 1651 позже зафиксировал реализации, которые разрывали соединение или не принимали второе приветствие.
  • Регистрация расширения, объявление возможности, исполнимый откат, принятая команда, завершённая почтовая транзакция и доставка — разные доказательства.

Электронной почте требовались новые возможности, но не всемирный день обязательного обновления.

SMTP распространился благодаря короткому диалогу: соединение, приветствие, HELO, конверт и содержимое. К 1993 году расширений становилось больше. Если бы каждое принесло собственные правила обнаружения, общий протокол распался бы на частные диалекты.

RFC 1425 создал тонкий общий слой. Расширенный клиент начинал с EHLO; сервер перечислял зарегистрированные ключевые слова и параметры; поведение отдельной функции определял её RFC. Общей стала точка обнаружения, а не обязанность внедрения.

Возможность жила столько же, сколько сеанс

Если клиенту нужны были сведения о расширениях, он обязан был отправлять EHLO в начале каждого сеанса SMTP. Информацию успешного ответа нельзя было кэшировать.

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

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

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

RFC 1426 показывает последовательность: сначала увидеть 8BITMIME в ответе EHLO, затем запросить BODY=8BITMIME в MAIL FROM, после принятия перейти к DATA. Механика восьмибитного тела — другая тема. Здесь важна граница между объявлением и использованием.

Нарисованный откат зависел от живого состояния

Новый клиент должен был общаться и с сервером уровня RFC 821. По RFC 1425 такой сервер не узнавал EHLO, возвращал ошибку, но оставлял канал открытым. Клиент мог выполнить сброс или перейти к HELO и продолжить старый SMTP.

Отказ не становился нарушением и не требовал немедленной модернизации. Стороны выбирали меньший общий набор правил.

Но стрелка схемы предполагала исполнимые условия. Сервер не должен был закрывать соединение. Неизвестная команда не должна была портить внутреннее состояние. Следующий RSET или HELO должен был попасть в состояние, которое его принимает.

Спецификация определяла правильный переход, но не могла доказать его наличие в установленной программе.

RFC 1651 вернул в текст эксплуатационные факты

В июле 1994 года RFC 1651 заменил RFC 1425 и добавил раздел о неправильно реализованных серверах.

Некоторые известные серверы закрывали канал SMTP при получении EHLO: до ответа или после него. Это противоречило RFC 821, где нормальное закрытие следовало за QUIT, однако ссылка на норму не сохраняла сокет.

Клиенту пришлось наблюдать сам канал. После разрыва он решал, можно ли завершить задачу без расширений. Если да, открывал новое соединение и использовал HELO. Это была не продолженная сессия, а новая попытка со своей временной границей и результатом.

Другие серверы оставались на линии, но после отказа EHLO не принимали HELO. Иногда помогал промежуточный RSET. При этом многие реализации отвечали на него 503 Bad sequence of commands; RFC 1651 разрешал игнорировать такой код именно в узком сценарии восстановления.

RFC 1869 сохранил это предупреждение в 1995 году. Отклонение работающего кода стало частью памяти стандарта.

Это не довод против спецификаций. Пересмотр отделил нормативное состояние от развёрнутого и позволил эксплуатационным данным уточнить карту совместимости.

«Откат сработал» может скрывать два соединения

За этой фразой могут стоять открытие канала, 220, отправка EHLO, ответ или разрыв, RSET, HELO, приём конверта, DATA, ответственность ретранслятора и доставка.

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

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

Тонкий слой перенёс стоимость совместимости

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

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

Реестр давал слову общий смысл, но не запускал код. Сервер локально выбирал расширения, клиент — совместимый путь, объявленный сейчас. Принятие было добровольным; совместимость должна была исполниться на линии.

Схема начинает проверку. Только трасса сеанса подтверждает, что стрелка существовала.