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

Практическое пояснение: строка «250 OK» без соседней команды не объясняет результат. Для приёмки нужно видеть этап обмена, окончание данных и последний код, а доставку в ящик проверять отдельно.

1. 01

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

   Граница применимости: RFC 5321, октябрь 2008 года; §3.3, стр. 20, 21. Базовый DATA без согласованного расширения, меняющего обмен. Отказ на команду DATA не разрешает отправлять тело в надежде на другой итог.

2. 02

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

   Граница применимости: RFC 5321, октябрь 2008 года; §4.1.1.4, стр. 36, 37. Если последняя строка исходного письма не окончена CRLF, исходящий SMTP должен отклонить письмо либо добавить этот CRLF. Это отличается от добавления лишней пустой строки.

3. 03

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

   Граница применимости: RFC 5321, октябрь 2008 года; §4.5.2, стр. 62. Это прозрачность строк базового DATA, а не изменение сохранённого текста письма. Проверка проводится в начале каждой строки.

4. 04

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

   Граница применимости: RFC 5321, октябрь 2008 года; §§2.1, 4.1.1.4, 4.2.5, 6.1, стр. 8, 37, 53, 71. Обычная обработка почты; исключения для атак и враждебных сообщений отдельно описаны в §§6.2, 7.8–7.9. Код относится к концу DATA, а не к MAIL, RCPT или NOOP.

5. 05

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

   Граница применимости: RFC 5321, октябрь 2008 года; §4.2.5, стр. 53, 54. Запрет доставки относится к отвергнутой попытке. Новая исправленная попытка может быть принята отдельно; SHOULD NOT повторов после 5xx не усилено до вечного запрета.

6. 06

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

   Граница применимости: RFC 5321, октябрь 2008 года; §4.4, стр. 59. Обычная доставка с непустым обратным путём. Уведомление перечисляет всех неуспешных адресатов либо отправляется отдельно для каждого; §6.1 запрещает ответ при пустом пути.

7. 07

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

   Граница применимости: RFC 5321, октябрь 2008 года; §§4.2, 4.2.1, стр. 46, 47, 48. RFC выделяет специальные случаи обработки текста 251/551 и при необходимости 220/221/421. Код 1xx или другой выход за диапазон не объявляется обычным SMTP-ответом.

1. Свяжите ответ 354 с командой DATA и не начинайте данные раньше него.
2. Проверьте точную границу CRLF, точка, CRLF без лишней пустой строки.
3. Передайте строки с одной и несколькими точками и сравните восстановленный текст.
4. Запишите итог после конца DATA отдельно от предварительных ответов 250.
5. После итогового отказа проверьте, что отвергнутая копия не доставляется сервером.
6. Разделите общий успех приёма и последующие ошибки конкретных доставок.
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, расширения и реализации не проверялись.

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