термин · почтовый протокол smtp

Что такое почтовый протокол SMTP и как он влияет на почту приложения?

SMTP (Simple Mail Transfer Protocol) — стандартный протокол, с помощью которого почтовые системы отправляют, ретранслируют и передают друг другу исходящие письма. Приложение обычно передаёт готовое письмо аутентифицированному сервису отправки; затем почтовые серверы с помощью команд SMTP и DNS-маршрутизации продвигают его к каждому получателю. Ответы SMTP показывают, принял или отклонил конкретного получателя соответствующий узел, но приём — это не то же самое, что попадание во «Входящие». Приложению всё равно нужны надёжные очереди, безопасные повторы, идентификаторы писем, аутентификация и обработка отказов (bounce).

SMTP передаёт почту между ответственными системами

SMTP — протокол передачи с промежуточным хранением (store-and-forward). Клиент открывает сессию с сервером, представляется, указывает отправителя конверта, предлагает одного или нескольких получателей в конверте и передаёт содержимое письма после того, как сервер согласится его принять. Сервер может принять одних получателей и отклонить других, поэтому статус относится к получателю и транзакции, а не только к письму в целом. Приняв ответственность, сервер может доставить письмо локально или ретранслировать его в другую систему, выбранную по MX-записям в DNS. Именно из-за такой пошаговой (hop-by-hop) схемы приложению не стоит сводить состояние письма к одному булевому флагу «отправлено». Приложение, сервис отправки, релей, принимающий сервер и система фильтрации почтового ящика знают разные части результата. SMTP перемещает письмо между системами, а записи на уровне продукта и события провайдера делают это перемещение понятным для пользователей и операторов.

Отправка (submission) и ретрансляция (relay) — разные роли в протоколе

RFC 6409 разделяет отправку сообщений (submission) и их ретрансляцию (relay). Отправка — это первая передача письма от авторизованного пользователя или приложения агенту отправки сообщений (Message Submission Agent), обычно через порт 587. Ретрансляция — это передача между агентами передачи сообщений (Message Transfer Agents), и она традиционно использует порт 25. Сервисы отправки могут требовать аутентификацию, проверять или дополнять поля письма и применять политику в отношении отправителя, потому что знают, кто вводит новую почту в систему. Публичные релейные серверы должны взаимодействовать с другими доменами и следуют другим правилам доверия. Поэтому код приложения должен подключаться к документированному эндпоинту отправки провайдера или использовать его HTTP API, а не открывать произвольные соединения на порт 25 серверов назначения. Такое разделение проясняет и вопрос учётных данных: имя пользователя или токен SMTP разрешают отправку в конкретный сервис, но не дают полномочий над доменом назначения. Храните учётные данные для отправки на стороне сервера, ограничивайте их рабочей нагрузкой отправки, если провайдер это поддерживает, и проводите их ротацию, не встраивая их в содержимое писем или клиентское ПО.

SMTP-конверт отличается от видимых заголовков письма

SMTP-транзакция содержит конверт с командой `MAIL FROM` и одной или несколькими командами `RCPT TO`. Передаваемое содержимое отдельно соответствует формату интернет-сообщений (Internet Message Format), определённому в RFC 5322, с такими полями, как From, To, Date, Subject и Message-ID, и телом. Стандарты MIME расширяют это содержимое для HTML, альтернативных частей, вложений и данных не в ASCII. Отправитель конверта — это адрес, используемый для уведомлений о транспортных сбоях, и он может отличаться от видимого автора в From. Получатели в конверте тоже могут отличаться от видимых полей To и Cc, как в случае с Bcc. Не собирайте эти структуры конкатенацией недоверенных строк. Используйте поддерживаемую библиотеку для работы с письмами, проверяйте адреса, блокируйте внедрение переводов строк в поля заголовков и сохраняйте стабильный Message-ID. При диагностике проверяйте оба уровня: корректное видимое поле From не исправит неавторизованный адрес в конверте, а корректный конверт не заставит некорректный MIME отображаться правильно.

Читайте транзакцию как конечный автомат

Базовая сессия Extended SMTP начинается с приветствия сервера, затем следует `EHLO`, чтобы сервер мог объявить поддерживаемые расширения. При отправке (submission) клиент может согласовать TLS и аутентификацию. Затем транзакция письма использует `MAIL FROM`, по одной команде `RCPT TO` на каждого адресата, `DATA`, полное письмо, завершённое согласно правилам кадрирования SMTP, и `QUIT`. Не считайте этот пример поводом реализовывать протокол вручную: зрелые SMTP-библиотеки безопаснее обрабатывают окончания строк, прозрачность точки (dot transparency), согласование возможностей, аутентификацию и состояние TLS. Инструментируйте библиотеку на уровне категорий команд и кодов ответа, не логируя учётные данные или полные тела писем. Фиксируйте, какой получатель и на каком этапе завершился ошибкой и принял ли сервер ответственность после передачи данных письма. Эта граница определяет, уместен ли повтор, возможен ли дубль и придёт ли ошибка в последующем уведомлении о статусе доставки, а не в немедленном ответе.

Классифицируйте коды ответа, прежде чем решать о повторе

Классы ответов SMTP указывают на действие. Ответ 2xx означает успешное выполнение команды. Ответ 4xx — временное отрицательное завершение, поэтому отправитель с очередью может повторить попытку после задержки. Ответ 5xx — постоянное отрицательное завершение для данной команды, которое обычно требует исправления, добавления в стоп-лист или разбора человеком, а не повторных попыток. Расширенные коды состояния добавляют структурированную диагностику `X.Y.Z` для условий, связанных с адресом, почтовым ящиком, системой, маршрутизацией, протоколом, содержимым или безопасностью и политикой. Сохраняйте и числовой код, и текст сервера, потому что оба могут быть полезны для диагностики, но не раскрывайте широко исходные ответы, содержащие данные получателей. Применяйте к временным ошибкам экспоненциальную задержку со случайным разбросом (jitter) и максимальное время жизни в очереди. Никогда не повторяйте настолько агрессивно, чтобы временная проблема у получателя превратилась в злоупотребляющий трафик. При постоянной ошибке адреса прекращайте автоматическую отправку на этот адрес и обновляйте стоп-лист. При ошибке политики или аутентификации исправьте адрес отправителя, DNS, учётные данные или содержимое до следующей попытки.

Используйте зашифрованную и аутентифицированную отправку

SMTP появился как транспортный протокол для сетей с разными предположениями о доверии, поэтому безопасная отправка зависит от расширений и политики развёртывания. STARTTLS переводит SMTP-соединение на TLS, после чего клиент должен отбросить возможности, полученные до рукопожатия, и снова отправить `EHLO`. RFC 8314 обновляет рекомендации по отправке: доступ и отправка в открытом виде считаются устаревшими, а для отправки описывается неявный TLS. SMTP AUTH, стандартизированный в RFC 4954, позволяет серверу отправки аутентифицировать клиента с помощью объявленных механизмов. Используйте актуальные имя хоста, порт, режим TLS и инструкции по аутентификации от провайдера, а не подбирайте комбинацию наугад. Проверяйте сертификат сервера и не переключайтесь молча на открытый текст, если нагрузке требуется защищённая отправка. Храните пароли или токены в менеджере секретов, используйте отдельные учётные данные для каждого окружения и отключайте устаревшие механизмы аутентификации. TLS защищает один участок соединения; он не аутентифицирует автора письма перед каждым последующим получателем и не заменяет выравнивание идентичности по SPF, DKIM и DMARC.

Диагностируйте сбой отправки писем приложения по участкам

Начните с надёжной записи об исходящем письме в приложении: было ли продуктовое событие авторизовано и была ли задача в очереди взята в работу только один раз? Затем проверьте отправку: разрешение DNS, TCP-соединение, согласование TLS, проверку сертификата, аутентификацию, авторизацию отправителя конверта, ответы по каждому получателю и итоговый ответ на DATA. Если сервис отправки принял письмо, перестаньте вслепую повторять запрос и отслеживайте его идентификатор письма и поток событий. Отличайте состояние «обработано провайдером» от приёма принимающим сервером. Последующий отказ всё ещё может сообщить о постоянной ошибке после первоначального приёма. Если принимающий сервер принял письмо, исследуйте результаты аутентификации, репутацию, политику получателя, содержимое и классификацию в почтовом ящике, а не называйте это транспортным сбоем SMTP. Проверяйте идентичности и в конверте, и в заголовках и сохраняйте временные метки, коды ответа, счётчик попыток в очереди и идентификаторы провайдера. Для тестов используйте контролируемых получателей. Никогда не вставляйте SMTP-учётные данные из продакшена или полные письма клиентов в тикеты, промпты, историю терминала или публичные диагностические инструменты.

Разделяйте приём, доставку и попадание во «Входящие»

Точность в терминах протокола важна для интерфейсов продукта. Приём приложением означает, что локальная система зафиксировала запрос. Приём сервисом отправки означает, что первый почтовый сервис принял ответственность за обработку. Доставка на принимающий сервер означает, что SMTP-сервер назначения вернул успешный ответ при передаче. Попадание во «Входящие» — более позднее решение политики и классификации внутри принимающей среды. Письмо может пройти одно состояние и не пройти следующее или быть классифицировано иначе. SMTP даёт прямые данные о текущей транзакции и может породить последующие уведомления о статусе доставки, но не раскрывает итоговую папку получателя. Храните эти состояния независимо, а не помечайте каждый ответ 250 как доставку во «Входящие». Событие провайдера, содержащее успешный SMTP-ответ сервера назначения, может подтверждать состояние «доставлено на сервер». Отказ служит основанием для обработки ошибки или добавления в стоп-лист. Ни то, ни другое не даёт оснований обещать видимость, прочтение или вовлечённость. Такая модель сохраняет правдивость статусов и предотвращает небезопасные повторы после того, как ответственность уже передана.

Используйте документированный API SendHQ

Приложение может работать с SMTP через библиотеку провайдера или вызывать HTTP email API, провайдер которого обеспечивает транспортировку интернет-почты под этим интерфейсом. SendHQ предоставляет email API в рамках рабочего пространства с проверками подтверждённого домена, ресурсами исходящих и входящих писем, событиями, стоп-листами, почтовыми ящиками и границами ресурсов рабочего пространства. Его HTTP API может предоставлять структурированные запросы, идентификаторы и события наряду с прямой SMTP-отправкой. Он не меняет поведение сервера назначения и не устанавливает принятие SMTP, попадание во «Входящие» или взаимодействие получателя.

Частые вопросы

Как расшифровывается SMTP?

SMTP — это Simple Mail Transfer Protocol (простой протокол передачи почты). Он определяет, как почтовые клиенты и серверы отправляют и передают исходящие письма с помощью команд, ответов, конвертов, данных письма и расширений для таких возможностей, как аутентификация и TLS.

Используется ли SMTP для чтения писем из почтового ящика?

Нет. SMTP предназначен в первую очередь для отправки и передачи исходящей почты. Для доступа к почтовому ящику используются другие интерфейсы, например IMAP, POP, API почтового ящика конкретного провайдера или email API приложения, которое предоставляет доступ к сохранённым входящим письмам.

Чем отличаются порты 25, 587 и 465?

Порт 25 традиционно используется для ретрансляции между серверами. Порт 587 — стандартный порт сервиса отправки сообщений (submission), на нём обычно согласуется TLS. Порт 465 зарегистрирован для отправки через неявный TLS. Используйте документированный эндпоинт и режим безопасности провайдера, а не меняйте порты экспериментально.

Доказывает ли успешный ответ SMTP, что письмо попало во «Входящие»?

Нет. Успешный ответ доказывает лишь то, что отвечающий SMTP-сервер принял соответствующую команду или ответственность за письмо. Принимающая система всё ещё может применить последующую политику, сгенерировать отложенную ошибку или поместить принятое письмо не в основную папку «Входящие».

Должно ли приложение повторять отправку при каждом SMTP-ответе 4xx?

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

Заменяет ли HTTP email API протокол SMTP?

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

Источники

Что почитать дальше

Руководство по внедрению email API для продуктовых командСпроектируйте безопасную интеграцию email API: подтверждённые домены, отправка через очередь, стабильные идентификаторы, контролируемые повторы, события доставки, стоп-лист и изоляция тенантов.