Серверные сети · проверено по источникам

SMTP: очередь, таймауты и повторные попытки

Очередь SMTP хранит письмо вместе с конвертом для последующих попыток передачи. Таймаут команды, пауза до повтора и срок отказа от доставки — разные параметры.

Также ищут: SMTP retry queue · SMTP timeout and duplicates

Практический смысл

Почему это важно

Практическое пояснение: слишком ранний обрыв после конца DATA может вызвать дубликат. При настройке очереди важно знать, какая сторона уже приняла ответственность и какой результат действительно получил клиент.

Доказательная часть

Что подтверждено

  1. SMTP-клиент должен иметь отдельные таймауты команд, а не один таймер всей почтовой транзакции. Для передачи данных таймер устанавливают также на каждый передаваемый блок; перенастройка таймаутов без перекомпиляции рекомендуется.

    Граница применимости: RFC 5321, октябрь 2008 года; §4.5.3.2, стр. 65. Блок здесь относится к отправке данных, не к независимому письму. Общая длительность передачи зависит от размера сообщения.

  2. RFC рекомендует минимальные ожидания: 5 минут для начального 220, MAIL и RCPT; 2 минуты для 354 на DATA; 3 минуты для завершения отправки каждого блока; 10 минут для итогового ответа на конец DATA. Серверу рекомендуется ждать следующую команду не менее 5 минут.

    Граница применимости: RFC 5321, октябрь 2008 года; §§4.5.3.2.1–4.5.3.2.7, стр. 65, 66. Это SHOULD для минимальных таймаутов из RFC 5321, а не гарантированное время доставки, единый deadline или неизменяемые значения продукта.

  3. Неподконтрольный клиенту обрыв связи рекомендуется обрабатывать как временную ошибку 451. Если обрыв или преждевременный таймаут произошёл в ожидании итогового ответа на конец DATA, повтор может дать дубликат: сервер мог уже принять письмо.

    Граница применимости: RFC 5321, октябрь 2008 года; §§3.8, 4.5.3.2.6, 6.1, стр. 30, 66, 72. Отсутствие подтверждения у клиента не доказывает ни приём, ни отсутствие приёма на сервере. Это риск повторной доставки, а не обещание exactly-once.

  4. Письмо, которое не удалось передать сразу, отправитель должен поставить в очередь и периодически повторять передачу. Запись очереди включает само письмо и сведения конверта.

    Граница применимости: RFC 5321, октябрь 2008 года; §4.5.4.1, стр. 66. Общий механизм для сообщений, подлежащих повтору. Постоянный отказ не превращается в временный, а заголовки To и From не заменяют утраченный конверт.

  5. После неудачной попытки к той же цели отправитель должен выдержать паузу. Обычно рекомендуется интервал не менее 30 минут; более сложные стратегии допускаются. До отказа от доставки обычно нужно не менее 4–5 дней, а параметры алгоритма повторов должны настраиваться.

    Граница применимости: RFC 5321, октябрь 2008 года; §4.5.4.1, стр. 67. 30 минут — SHOULD общего случая; 4–5 дней — общая рекомендация срока, не SLA. RFC допускает более короткий предел для уведомлений об ошибках.

  6. SMTP-клиент не должен кэшировать ответы 5xx на команду MAIL. Недоступность узла и отрицательный ответ конкретной почтовой транзакции нельзя считать взаимозаменяемыми основаниями для пропуска новых попыток.

    Граница применимости: RFC 5321, октябрь 2008 года; §4.5.4.1, стр. 67. Прямой запрет относится к 5xx на MAIL. Это не запрет очереди или списка недоступных узлов; отрицательные ответы других команд требуют осторожной отдельной обработки.

  7. При преждевременном закрытии соединения SMTP-сервер должен отменить ожидающую транзакцию, но не отменять уже завершённые. QUIT завершает соединение и прерывает ещё незаконченную транзакцию; подтверждённую передачу он не отзывает.

    Граница применимости: RFC 5321, октябрь 2008 года; §4.1.1.10, стр. 40. Успешный конец DATA уже завершил транзакцию. Потеря ответа 221 после него не означает, что ранее принятая копия должна быть отправлена заново.

Перед спецификацией

Что проверить

  1. Разделите таймаут каждой команды и каждого блока передачи данных.
  2. Сверьте ожидания начального 220, 354 и итогового ответа DATA по отдельности.
  3. При обрыве после конца DATA отметьте неопределённость исхода и риск дубликата.
  4. Проверьте, что очередь хранит конверт вместе с содержимым.
  5. Разделите паузу до следующей попытки и срок прекращения повторов.
  6. Проверьте, что 5xx на MAIL не превращается в кэшированный отказ для новой транзакции.
  7. При закрытии сеанса отличайте ожидающую транзакцию от уже подтверждённой.
Открытые основания

Первоисточники

  • Первичная спецификация

    Simple Mail Transfer Protocol

    Internet Engineering Task Force · RFC 5321, October 2008

    Полная локальная копия RFC 5321, октябрь 2008: прочитаны все 95 страниц, включая приложения A–F, 09.09.2026. Сверены конверт, DATA, ответственность, повторы и выбор MX. retrieved_on сохраняет дату офлайн-очереди. Позднейшие errata, расширения и реализации не проверялись.

    Открыть первоисточник

Следующий шаг

Сформулируйте задачу, затем уточните требования перед выбором оборудования.

Подготовить подбор с Делектусом

Откроется черновик вопроса. Отправьте его, когда будете готовы.

Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие