Кратко
RSETсделал незавершённое письмо удаляемой транзакцией внутри более долгой SMTP-сессии: отправитель, адресаты и данные очищаются, но соединение не закрывается.- Ответ
250 OKподтверждает сброс, а не доставку. Он не отменяет уже завершённую транзакцию и не стирает TLS, аутентификацию или всю операционную память сессии.
Принятый адресат в конверте, от которого отказались
Клиент отправляет MAIL FROM, затем два RCPT TO. Сервер принимает первого адресата и отклоняет второго. Правило приложения, однако, требует доставки обоим: неполный список делает отправку бессмысленной.
Поздний отказ не аннулирует ранний успех. У сервера всё ещё могут храниться обратный путь и один допустимый получатель. Если передать DATA, продолжится уже ненужная транзакция. Новый MAIL столкнётся с открытым старым конвертом. Разрыв TCP наверняка очистит память, но вместе с ней уничтожит исправное соединение.
RSET выражает более точное намерение: прекратить эту почтовую транзакцию. После положительного ответа обе стороны располагают свидетельством, что следующий конверт не наследует предыдущий.
Умение забывать появилось в SMTP сразу
RFC 821 определил reset ещё в 1982 году. Получатель должен был отбросить сохранённого отправителя, адресатов и данные, очистить буферы и таблицы состояний и вернуть успешный ответ. Там же говорилось, что в одной сессии бывает ноль или несколько почтовых транзакций.
Эти правила нужны друг другу. Повторное использование соединения безопасно лишь тогда, когда одно незаконченное письмо можно уничтожить отдельно. Переподключение после каждой ошибки убирает выгоду постоянной сессии; сохранение испорченного конверта убирает изоляцию.
RFC 821 также не позволял закрывать канал только из-за ошибки предыдущей команды. При преждевременной потере связи отменялась ожидающая транзакция, но уже завершённые оставались завершёнными. Канал, текущая попытка и прошлый результат были разными записями.
Локальная очистка не доказывает удалённую
Клиент способен мгновенно стереть собственную очередь, но не видит буфер сервера. Безопасное продолжение требует ответа другой стороны, связанного именно с reset.
RFC 5321 требует 250 OK на RSET без аргументов и разрешает команду в любой момент. Когда транзакции нет, действие почти пустое. Когда она открыта, удаляются отправитель, адресаты и данные. Сервер не вправе закрыть соединение из-за RSET; закрытие принадлежит QUIT.
Значение 250 определяется командой. После RSET код подтверждает очистку состояния, а не приём прежнего письма. Он не обещает физического уничтожения журналов или следов злоупотребления. Гарантия протокола уже: старый конверт не должен управлять следующей транзакцией.
Память конверта и память сессии
Фраза об очистке буферов и таблиц может показаться полной амнезией. Остальные правила ограничивают её транзакцией.
TCP-соединение остаётся открытым. Сервер не повторяет приветствие. Возможности из EHLO не требуется заново открывать только из-за отменённого письма. TLS продолжает действовать, а аутентифицированная сессия не становится анонимной. Остаться не могут отправитель, адресаты и частичный текст предыдущей транзакции.
Принятый позднее новый EHLO тоже сбрасывает открытый конверт как RSET, отмечает RFC 5321. Но он дополнительно выполняет приветствие и сообщает возможности, поэтому обычно дороже. Формальное совпадение относится к прекращению транзакции, а не ко всей функции команд.
STARTTLS показывает более широкую границу. RFC 3207 требует после успешного TLS-рукопожатия отбросить знания, полученные до него, и снова отправить EHLO. Изменился контекст безопасности, поэтому сессия пересобирает представление о возможностях. Для простой отмены конверта столь широкий сброс не нужен.
Прервать настоящее — не значит переписать прошлое
Почтовая транзакция начинается с MAIL, включает один или несколько RCPT и заканчивается передачей содержимого. RSET действует на ещё открытую единицу. После окончательного успешного приёма данных существует завершённая транзакция. Поздний reset готовит следующую, но не отзывает принятую ответственность.
Долгая SMTP-сессия не является одной транзакцией базы данных для всех писем. У каждого завершённого письма собственный результат. Сохранение соединения не даёт коллективного отката истории.
Поэтому счётчик всех 250 без соответствующих команд создаёт ложное свидетельство. Успех адресата, содержимого и reset говорит о разных объектах.
PIPELINING сблизил границы во времени
RFC 2920 разрешил группировать некоторые команды, не ожидая каждый ответ. RSET, команды отправителя и RCPT TO могут находиться внутри группы. Последний фрагмент одного письма способен разделить TCP-отправку с reset и новым отправителем следующего.
Но результаты не сливаются. Клиент обязан сопоставить ответы по порядку: один относится к старому содержимому, второй подтверждает reset, третий оценивает нового отправителя. Соседний успех не скрывает отказ.
Чем быстрее диалог, тем строже нужен учёт. Опустошённый локальный буфер доказывает готовность клиента, но не переход сервера через ту же границу.
Очистка неопределённого состояния блока
RFC 3030 переносит содержимое блоками BDAT. Блок после BDAT LAST, смешение DATA и BDAT в одной транзакции либо сбой, оставивший состояние неопределённым, требуют RSET перед продолжением почтовых команд.
Reset отбрасывает сегменты текущей попытки. Он не стирает факт соединения, TLS или аудит; он не позволяет частичным байтам стать частью следующего письма.
RFC 4954 охраняет другой масштаб: AUTH запрещён во время открытой почтовой транзакции и должен получить 503. Идентичность сессии нельзя вклинить между отправителем, адресатами и содержимым. Сначала конверт надо завершить или явно отменить.
Восстановление с указанным радиусом
После ошибки можно притвориться, что обе стороны синхронны, либо уничтожить всё соединение. RSET предлагает полезную середину: назвать отбрасываемую единицу, сохранить канал и получить подтверждение перехода.
SMTP не стал протоколом без состояния. Он разделил состояние по областям. Незавершённое письмо можно забыть, не забывая разговор; разговор можно продолжить, не переписывая итоги завершённых писем.
Источники
- RFC 821 — Simple Mail Transfer Protocol
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 2920 — SMTP Service Extension for Command Pipelining
- RFC 3030 — SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- RFC 4954 — SMTP Service Extension for Authentication
- RFC 3207 — SMTP Service Extension for Secure SMTP over TLS
- IANA — Simple Mail Transfer Protocol registries
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
