SMTP отправка почты: полный разбор формата сообщения

Как работает отправка почты по протоколу

Разобраться в механизме передачи писем проще, чем кажется. smtp отправка почты — это, по сути, процесс диалога между вашим почтовым клиентом и сервером получателя. Сначала ваш компьютер связывается с исходящим сервером, сообщая ему адрес отправителя и получателя. Затем сервер, используя DNS-записи, находит нужный узел и передаёт ему данные. Весь обмен происходит по строго определённым командам, которые подтверждают доставку каждого блока информации.

Принцип передачи письма от клиента к серверу

Когда вы нажимаете «Отправить», почтовый клиент устанавливает соединение с сервером исходящей почты. Обычно это порт 587 с шифрованием STARTTLS или 465 для SSL. Диалог строится на командах: клиент представляется (EHLO), указывает отправителя (MAIL FROM), получателя (RCPT TO), затем передаёт содержимое (DATA). Сервер на каждом шаге отвечает кодом — например, 250 означает успех, 550 — отказ. После завершения сеанса письмо попадает в очередь на дальнейшую доставку.

Роль почтового сервера в доставке

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

Технически процесс выглядит так:

• клиент устанавливает соединение с сервером по протоколу;
• узел аутентифицирует отправителя и проверяет права;
• происходит поиск MX-записи для домена адресата;
• сообщение ставится в очередь и отправляется дальше.

Если на каком-то этапе возникает сбой, сервер повторяет попытки через заданные интервалы. Это повышает надёжность доставки, но иногда приводит к задержкам — особенно когда промежуточные узлы перегружены или внесены в чёрные списки.

Структура и формат сообщения

Разбирая формат smtp сообщения, стоит понимать: это не просто письмо, а строгий набор команд и данных. Протокол диктует, как именно клиент и сервер обмениваются репликами. Каждая строка завершается парой символов CR/LF, а заголовки отделяются от тела пустой строкой.

Ключевые элементы выглядят так:

• Конверт (envelope) — служебная информация для маршрутизации: адреса отправителя и получателей, которые указываются в командах MAIL FROM и RCPT TO.
• Заголовки (headers) — метаданные: From, To, Subject, Date, Message-ID. Они читаемы человеком и используются почтовыми клиентами.
• Тело (body) — непосредственно содержимое. Оно может быть в формате plain text или MIME, если нужно вложить файлы или HTML-разметку.

Важная деталь: длина строки не должна превышать 998 символов, а рекомендуемый предел — 78. Если строка длиннее, её разбивают точками переноса. Это требование RFC 5322, и его нарушение может привести к отказу в доставке.

Заголовки письма: обязательные и опциональные поля

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

• From — адрес отправителя, без него сервер получателя отвергнет корреспонденцию.
• To — основной получатель, хотя допустимо указание скрытых копий.
• Subject — тема, которая видна в списке входящих.
• Date — временная метка формирования.
• Message-ID — уникальный идентификатор для отслеживания диалога.

Опционально добавляют Reply-To, Content-Type и MIME-Version — они управляют кодировкой и вложениями. Отсутствие обязательных атрибутов часто провоцирует попадание в спам.

Тело письма и разделитель заголовков

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

Тело может быть как простым текстом, так и HTML-разметкой. Во втором случае обязательно указывают соответствующий MIME-тип в заголовках, иначе клиент покажет исходный код вместо оформленной вёрстки.

Кодировка и MIME-типы в письме

Чтобы получатель увидел текст без «кракозябр», заголовок письма должен содержать корректный параметр charset. Чаще всего применяется UTF-8, который покрывает кириллицу и спецсимволы. Для вложений и HTML-разметки используются MIME-типы: например, text/plain для простого текста и multipart/alternative, когда в одном сообщении сочетаются обычная и HTML-версии. Неверно указанный тип приводит к тому, что почтовый клиент отображает письмо как пустое или бинарный файл.

Команды протокола для передачи данных

Диалог клиента и сервера строится на коротких текстовых инструкциях. Каждая строка завершается парой символов CRLF. Ответы сервера кодируются трехзначным числом — кодом состояния.

• HELO/EHLO — приветствие и согласование возможностей.
• MAIL FROM — указание отправителя.
• RCPT TO — адрес получателя.
• DATA — начало передачи содержимого письма.
• QUIT — завершение сеанса.

После DATA тело сообщения отделяется от заголовков пустой строкой, а окончание передачи обозначается точкой на отдельной строке. Код 250 подтверждает успех операции, 550 — ошибку.

HELO, MAIL FROM и RCPT TO: начало сессии

Старт диалога с почтовым сервером начинается с приветствия. Клиент отправляет команду HELO (или EHLO для расширенного набора возможностей), представляясь именем хоста. Далее указывается обратный адрес через MAIL FROM, а получатели перечисляются по одному с помощью RCPT TO. Сервер отвечает кодами 250 или 550, подтверждая или отклоняя каждый шаг.

Команда DATA и завершение передачи

Когда клиент отправляет команду DATA, сервер отвечает кодом 354 и ожидает тело письма. Завершается передача строкой с единственной точкой. После этого SMTP-сервер возвращает код 250, подтверждая успешный приём сообщения. Если в процессе возникла ошибка, придёт код 4xx или 5xx — тогда письмо не будет доставлено, и клиенту стоит повторить попытку позже.

Ошибки и коды ответов сервера

При передаче корреспонденции сервер обменивается с клиентом цифровыми квитанциями. Код 250 означает успешное завершение операции, а 550 — отказ из-за недоступности ящика получателя. Временные неполадки обозначаются ответами 421 и 450, когда стоит повторить попытку позже. Постоянные сбои, например 551, требуют проверки адреса. Расшифровка статусов помогает быстро диагностировать проблему доставки.

Коды 2xx, 4xx и 5xx: что они означают

Ответы сервера при передаче письма делятся на три группы. Диапазон 2xx — успех: сообщение принято и доставлено. Класс 4xx сигнализирует о временной проблеме (например, переполненный ящик получателя) — стоит повторить попытку позже. Коды 5xx указывают на постоянную ошибку: адрес не существует или доступ запрещён, поэтому повторная отправка бессмысленна.

Для наглядности:

• 250 — запрос выполнен, письмо ушло;
• 421 — сервис недоступен, попробуйте снова;
• 550 — получатель не найден, проверьте адрес.

Типичные сбои при отправке и их причины

Когда письмо не доходит, чаще всего виноваты три вещи: неверные учётные данные, блокировка провайдером или проблемы с DNS. Ошибка аутентификации (535) обычно означает опечатку в пароле. Код 550 сигнализирует о том, что сервер получателя отклонил запрос — возможно, из-за спам-фильтров. Таймауты соединения возникают при блокировке 25-го порта.

Полезно проверить очередь сообщений и логи. Если письма уходят, но не доставляются, проверьте SPF и DKIM записи. Нередко причина кроется в устаревших настройках TLS.

Практические примеры сессии

Разберём диалог с почтовым сервером на порту 587. Клиент отправляет команды, сервер отвечает кодами. Строки начинаются с C: (клиент) и S: (сервер).

1. C: EHLO client.example.com — приветствие и запрос возможностей.
2. S: 250-mail.example.com — сервер представляется и перечисляет поддерживаемые расширения.
3. C: AUTH LOGIN — начало аутентификации.
4. S: 334 VXNlcm5hbWU6 — запрос логина в base64.
5. C: dXNlcg== — передача логина.
6. S: 334 UGFzc3dvcmQ6 — запрос пароля.
7. C: cGFzcw== — передача пароля.
8. S: 235 Authentication successful — успешный вход.
9. C: MAIL FROM:<user@example.com> — обратный адрес.
10. S: 250 OK — принято.
11. C: RCPT TO:<recipient@example.org> — получатель.
12. S: 250 Accepted — получатель найден.
13. C: DATA — начало передачи тела письма.
14. S: 354 End data with <CR><LF>.<CR><LF> — сервер готов.
15. C: Subject: Test и далее заголовки, пустая строка, текст, завершающая точка.
16. S: 250 OK: queued as 12345 — письмо принято в очередь.
17. C: QUIT — завершение сессии.
18. S: 221 Bye — соединение закрыто.

Обратите внимание: коды 250, 235, 354 — положительные ответы. Ошибки начинаются с 4xx (временные) или 5xx (постоянные).

Пошаговый разбор обмена командами

Сеанс начинается с приветствия сервера (код 220). Клиент представляется командой EHLO, получая список возможностей. Затем указывает отправителя через MAIL FROM и получателя — RCPT TO. После подтверждения адресатов передаётся содержимое письма: DATA, тело сообщения, завершающая точка. Финал — QUIT, сервер отвечает 221. Каждый шаг сопровождается трёхзначным кодом ответа, по которому легко отследить успешность операции.

Пример письма с вложением

Собрать сообщение с файлом несложно. Достаточно добавить к заголовку Content-Type: multipart/mixed и разделить части границей-разделителем. Текстовая часть идёт первой, затем бинарные данные, закодированные в Base64. Такой подход универсален для любого клиента.