Практикум по RFC 5321

SMTP: принять письмо, сохранить очередь и повторить передачу

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

Практика → проверка решения150 минут10 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Отличать конверт от заголовков и читать результат каждого RCPT.
  2. Разделять разрешение DATA, итог приёма и последующие доставки.
  3. Учитывать неопределённый исход, дубликаты и разные параметры очереди.
  4. Проверять альтернативные адреса и исключать петлю пересылки при выборе MX.
Модуль 1 из 10

Адреса конверта и заголовков

Практикум разбирает базовый SMTP по полному RFC 5321 от октября 2008 года. Клиент передаёт письмо, сервер принимает этот обмен; relay затем сам становится клиентом. TLS, AUTH, MIME, SMTPUTF8 и настройки конкретного продукта требуют своих источников.

  • Объект SMTP состоит из конверта и содержимого. Адреса MAIL FROM и RCPT TO не обязаны совпадать с адресами заголовков From, To или Cc; промежуточный SMTP-сервер не должен выводить конечный маршрут из заголовков письма.

    Проверить тезис: SMTP: конверт и принятие получателей 01

  • SMTP должен сохранять регистр локальной части адреса: принимающий домен может различать smith и Smith, хотя такое устройство ящиков не рекомендуется. Доменная часть регистронезависима; для специального имени Postmaster действует отдельное регистронезависимое правило.

    Проверить тезис: SMTP: конверт и принятие получателей 06

Модуль 2 из 10

Один MAIL, несколько RCPT и отмена

До DATA сервер хранит ещё незавершённую транзакцию. Ответы отдельных RCPT нужно читать по адресатам, а сброс отличать от команды, которая только проверяет отклик сервера.

  • MAIL начинает новую почтовую транзакцию, очищает буферы прежнего обратного пути, получателей и данных и записывает новый обратный путь. Клиент не должен посылать MAIL, пока предыдущая транзакция ещё открыта.

    Проверить тезис: SMTP: конверт и принятие получателей 02

  • Каждый RCPT TO задаёт одного получателя. Успешный RCPT добавляет его в буфер адресатов; отказ одному адресату сам по себе не отменяет уже принятых других. В примере RFC после одного 550 передача продолжается для двух получателей с ответом 250.

    Проверить тезис: SMTP: конверт и принятие получателей 03

  • RSET отменяет текущую транзакцию: сервер должен удалить сохранённые сведения об отправителе, получателях и данных, ответить 250 и оставить соединение открытым. NOOP лишь запрашивает ответ 250 и не очищает эти буферы.

    Проверить тезис: SMTP: конверт и принятие получателей 05

Модуль 3 из 10

Принятие адресата и обратное уведомление

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

  • Некоторые SMTP-серверы откладывают проверку адресатов до получения содержимого; relay может не иметь доступа к конечной системе. Поэтому положительный ответ RCPT не доказывает окончательную доставку или полную проверку ящика в реальном времени.

    Проверить тезис: SMTP: конверт и принятие получателей 04

  • При обычной ошибке доставки уже принятого письма уведомление направляют на обратный адрес его конверта, а само уведомление отправляют с пустым обратным путём MAIL FROM. Если исходный обратный путь пуст, сообщение о недоставке отправлять запрещено.

    Проверить тезис: SMTP: конверт и принятие получателей 07

  • Клиент SMTP не должен передавать содержимое DATA до ответа 354. Этот ответ промежуточный: он разрешает передачу данных, а итог обработки сервер сообщает после признака конца данных.

    Проверить тезис: SMTP: DATA и ответственность за письмо 01

Модуль 4 из 10

Точка в тексте и граница DATA

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

  • В DATA конец письма обозначается строкой с единственной точкой: CRLF, точка, CRLF. Первый CRLF уже завершает последнюю строку содержимого; лишний CRLF добавлять нельзя. Последовательность LF, точка, LF без CR не является допустимой заменой.

    Проверить тезис: SMTP: DATA и ответственность за письмо 02

  • Перед отправкой строки DATA, начинающейся с точки, клиент добавляет ещё одну точку в начало. Сервер распознаёт одиночную точку как конец DATA, а у иной строки с точкой в начале удаляет первую точку.

    Проверить тезис: SMTP: DATA и ответственность за письмо 03

Модуль 5 из 10

Один итог DATA и последующие доставки

Число в ответе определяет переход протокола. Успех целого SMTP-приёма может предшествовать нескольким дальнейшим доставкам и их отдельным результатам.

  • Положительный итоговый ответ после конца DATA означает, что сервер принял ответственность за доставку или дальнейшую передачу письма. Это не подтверждение чтения адресатом и не требование уже завершить все следующие SMTP-переходы.

    Проверить тезис: SMTP: DATA и ответственность за письмо 04

  • После итогового 4xx или 5xx на конец DATA сервер не должен позднее доставлять эту отклонённую копию. Ответственность остаётся у клиента: временная ошибка допускает возврат или очередь; после постоянной ошибки повтор тому же серверу без разбора пользователем и вмешательства не рекомендуется.

    Проверить тезис: SMTP: DATA и ответственность за письмо 05

  • Если после приёма нескольких адресатов и данных сервер успешно доставил письмо части адресатов, но не всем, итог DATA должен быть положительным. Для неудачных доставок сервер формирует уведомление; один общий отказ DATA не описывает такой частичный результат.

    Проверить тезис: SMTP: DATA и ответственность за письмо 06

  • В общем случае SMTP-клиент выбирает действие по числовому коду ответа, а не по свободному поясняющему тексту. Для неизвестного кода допустимого диапазона он должен интерпретировать первую цифру: 2 — завершение, 3 — промежуточный ответ, 4 — временный отказ, 5 — постоянный.

    Проверить тезис: SMTP: DATA и ответственность за письмо 07

Модуль 6 из 10

Разные таймеры одного письма

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

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

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

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

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

Модуль 7 из 10

Очередь и неопределённый итог

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

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

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

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

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

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

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

Модуль 8 из 10

Что переносить на следующую попытку

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

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

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

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

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

Модуль 9 из 10

MX, адреса узла и ошибка DNS

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

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

    Проверить тезис: SMTP: следующие адреса MX и петля relay 01

  • Когда выбранное имя SMTP-узла имеет несколько IP-адресов, resolver возвращает упорядоченный список альтернатив. Отправитель SMTP должен пробовать их в предоставленном порядке.

    Проверить тезис: SMTP: следующие адреса MX и петля relay 02

  • При временной ошибке DNS во время выбора почтовой цели сообщение должно остаться в очереди для повторной попытки. Ответ о несуществующем домене должен обрабатываться как ошибка; он не равен пустому успешному списку MX.

    Проверить тезис: SMTP: следующие адреса MX и петля relay 05

  • Если MX домена существуют, SMTP не должен использовать A или AAAA самого домена в обход этих MX. Когда все найденные MX непригодны, требуется сообщить об ошибке; правило неявного MX действует только при отсутствии MX.

    Проверить тезис: SMTP: следующие адреса MX и петля relay 06

Модуль 10 из 10

Сам relay среди MX и следующий обмен

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

  • Relay, пересылающий письмо без изменения адресата, должен найти в списке MX собственные имена или адреса. Обнаружив себя, он исключает все MX с тем же числом предпочтения и с большими числами.

    Проверить тезис: SMTP: следующие адреса MX и петля relay 03

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

    Проверить тезис: SMTP: следующие адреса MX и петля relay 04

  • Приняв задачу дальнейшей передачи, relay сам становится SMTP-клиентом и открывает следующий обмен с выбранным сервером. Успех первого обмена не означает, что следующий уже состоялся: в примере RFC резервный MX принимает письмо и затем отдельно передаёт его основной цели.

    Проверить тезис: SMTP: следующие адреса MX и петля relay 07

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Relay получил готовый конверт с адресатом из отдела продаж. Поле To указывает другой отдел. Как выбрать получателей дальнейшей SMTP-передачи?
02Клиент передаёт адрес Sales@dept.example и ничего не знает о соглашениях получателя. Как обработать регистр обеих частей по базовому правилу RFC 5321?
03Сервер принял MAIL. Для получателей A, B и C ответы RCPT составили 250, 550 и 250. Клиент продолжает эту транзакцию, а DATA сервер затем разрешает. Для кого передаётся её содержимое?
04Клиент ещё не начал DATA и отменяет текущую транзакцию командой RSET. Как сервер должен обработать состояние и соединение?
05Relay ответил 250 на RCPT; команды DATA ещё не было. Как клиенту отметить результат этого обмена?
06Сервер принял обычное письмо с пустым MAIL FROM; позднее доставка провалилась. Заголовок From содержит рабочий адрес. Как обработать уведомление о недоставке?
07После разрешения DATA клиент должен передать строку содержимого, состоящую из единственной точки. Как записать эту строку в канале, сохранив её для адресата?
08Последняя строка письма уже заканчивается CRLF. Клиент должен завершить DATA и сохранить исходный текст. Какие следующие байты он передаёт?
09После признака конца DATA сервер ответил «451 OK». Как распределить ответственность за эту попытку по числу и тексту ответа?
10Обычное письмо с непустым обратным путём доставлено одному из двух принятых адресатов; второму доставить его не удалось. Как сервер отвечает на конец DATA и сообщает об ошибке?
11Разработчик переносит из RFC 5321 рекомендованные минимумы ожидания: сначала разрешения передачи тела, затем итогового ответа на его конец. Какая пара названа в документе для этих этапов?
12Письмо не удалось передать из-за временной неисправности. Что хранить для следующей попытки и как ограничивать ожидание при большой передаче?
13Клиент отправил признак конца DATA, но соединение оборвалось до получения итогового ответа. Как оценить исход и следующую попытку?
14Оператор настраивает повтор после неудачи к той же цели. Как сохранить нормативную силу и смысл общего правила RFC 5321?
15В прежней транзакции MAIL получил 550. Теперь клиент получил другое письмо для той же цели. Как использовать прежний ответ при обработке нового письма?
16Клиент получил итоговый 250 после конца DATA. Затем послал QUIT, но не получил 221 из-за обрыва связи. Как трактовать ранее подтверждённую транзакцию?
17Для выбранного имени MX интерфейс resolver вернул адреса X, затем Y в своём порядке предпочтения. Лимит попыток позволяет проверить оба адреса. Как клиенту использовать этот список?
18У домена есть MX, но все найденные цели непригодны. При этом A самого домена доступна. Как обработать такой результат по обычному алгоритму RFC 5321?
19Relay B видит MX A=10, B=20, C=20 и D=30. Он пересылает письмо без изменения адресата и узнаёт в B себя. Какие записи оставить кандидатами следующего перехода? Знак «+» означает оставить кандидатом, «−» — исключить.
20Резервный MX принял обычное письмо и ответил клиенту итоговым 250. Следующая основная цель временно недоступна. Как распределить дальнейшую работу?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

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

    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, расширения и реализации не проверялись.

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

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

Подтвердите действие