термин · порт smtp

Какой порт SMTP использовать приложению для отправки писем?

Большинству приложений следует использовать эндпоинт отправки (submission) и порт, документированные их почтовым провайдером. Порт 587 — стандартный порт отправки сообщений и обычно начинается с обычного SMTP до обновления STARTTLS. Порт 465 — отправка сообщений с неявным TLS, поэтому TLS-рукопожатие начинается сразу. Порт 25 предназначен прежде всего для SMTP-релея между серверами, а не для обычной аутентифицированной отправки приложением. Рабочая конфигурация должна одновременно соответствовать четырём параметрам: имени хоста, порту, режиму TLS и способу аутентификации.

Порт SMTP определяет роль протокола и режим подключения

Номер порта — это не просто одна из взаимозаменяемых дверей в один и тот же сервис. Он помогает понять, какую роль SMTP предлагает сервер и как начинается соединение. Отправка сообщений (submission) — это первая передача письма от приложения или почтового клиента сервису отправки. Релей — это передача почты между почтовыми серверами. Стандарты разделяют эти задачи, потому что при отправке могут требоваться аутентификация, авторизация отправителя и проверки политики, которые к публичному релею применяются иначе. Порт также может указывать, начинает ли клиент с SMTP-команд и затем переходит на TLS через STARTTLS или сразу начинает с TLS-рукопожатия. Считайте имя хоста, порт, режим TLS и инструкции по аутентификации от провайдера единым набором настроек. Если скопировать порт у постороннего провайдера или после ошибки поменять только порт, сетевая проблема может превратиться в ошибку TLS или аутентификации, а исходная причина так и останется неустранённой.

Порт 25 — в основном для релея между почтовыми серверами

Порт 25 — традиционный порт SMTP-релея, используемый, когда один агент передачи сообщений (MTA) передаёт почту другому. RFC 6409 оставляет релей на порту 25, а отправку новых сообщений выносит на порт 587. Поэтому приложению не стоит считать прямое подключение к почтовым серверам получателей на порт 25 обычным способом отправки писем продукта. Прямой релей требует очередей, DNS-маршрутизации, обработки отказов, защиты от злоупотреблений, управления репутацией и поведения повторов, соответствующего стандартам. Сети и хостинг-провайдеры также могут ограничивать исходящий трафик на порт 25. Например, AWS документирует, что по умолчанию ограничивает почтовый трафик Amazon EC2 на порту 25. Порт 25 всё ещё может быть задокументированным вариантом у провайдера или внутри контролируемой инфраструктуры, но его доступность не делает его предпочтительным для отправки. Используйте его, только если ответственный сервис явно документирует этот эндпоинт, режим безопасности и модель эксплуатации.

Порт 587 — стандартный порт для отправки сообщений

RFC 6409 резервирует порт 587 для отправки сообщений и описывает сервис отправки, который может отклонять неавторизованную почту, требовать аутентификации и применять политику до приёма нового письма. Типичная сессия на порту 587 начинается как SMTP, после `EHLO` объявляет расширение STARTTLS, переводит соединение на TLS, повторяет `EHLO`, проходит аутентификацию и затем отправляет письмо. Слово «типичная» здесь важно: точные механизмы и требования аутентификации определяются актуальной документацией провайдера и возможностями сервера. Безопасный клиент должен требовать ожидаемого перехода на TLS и проверять сертификат сервера, а не продолжать в открытом виде после неудачного согласования. Не путайте начальное нешифрованное приветствие протокола с незащищённой аутентифицированной сессией: STARTTLS предназначен для того, чтобы защитить соединение до передачи учётных данных и данных письма. Порт 587 обозначает сервис отправки, а успешное принудительное применение TLS зависит от правильной политики клиента.

Порт 465 использует неявный TLS для отправки

Порт 465 зарегистрирован для отправки сообщений через неявный TLS. При неявном TLS клиент выполняет TLS-рукопожатие сразу после открытия TCP-соединения и отправляет SMTP-команды только внутри защищённого канала. В этом отличие от порта 587 со STARTTLS, где клиент сначала получает SMTP-приветствие, а затем запрашивает переход на TLS. RFC 8314 рекомендует неявный TLS для отправки и одновременно описывает переходный период, в течение которого провайдеры и клиенты могут поддерживать и порт 465 с неявным TLS, и порт 587 со STARTTLS. RFC отмечает, что при обязательном TLS корректно реализованные клиенты и серверы обеспечивают по существу равноценную безопасность в любом из режимов. Практическое правило — не объявлять какой-то один порт универсально правильным. Используйте в точности тот эндпоинт и режим, которые поддерживает провайдер. Настройка STARTTLS для слушателя с неявным TLS или неявного TLS для слушателя со STARTTLS обычно завершается ошибкой ещё до аутентификации.

Альтернативные порты провайдеров — это явные договорённости

Некоторые провайдеры предлагают альтернативные порты для обхода сетевых ограничений, но эти номера не являются универсальными стандартами SMTP для всех сервисов. Amazon SES сейчас документирует STARTTLS на портах 25, 587 и 2587 и TLS Wrapper — так он называет неявный TLS — на портах 465 и 2465. SES требует зашифрованных соединений и публикует SMTP-эндпоинты для каждого региона. Это показывает, почему порт нужно брать из документации выбранного провайдера, а не из общего списка. Порт 2587 не означает STARTTLS везде, а порт 2465 не обозначает сервис с неявным TLS на произвольных хостах. Альтернативные порты также не позволяют обойти подтверждение отправителя, область действия учётных данных, квоты или политику провайдера. Храните URL источника и дату проверки вместе с конфигурацией продакшена, чтобы оператор мог отличить осознанную настройку провайдера от необъяснимого «магического числа», скопированного в переменную окружения много лет назад.

Настраивайте имя хоста, порт, TLS и аутентификацию вместе

Надёжная конфигурация SMTP — это набор: имя хоста провайдера, порт, режим защиты транспорта, политика проверки сертификата, механизм аутентификации, имя пользователя, секрет, тайм-аут подключения и адрес отправителя. Имя хоста важно, потому что по нему проверяется TLS-сертификат и потому что провайдеры могут предоставлять разные региональные эндпоинты. Порт и режим TLS должны соответствовать друг другу. Аутентификация должна выполняться только после установления нужного защищённого канала, а секреты должны храниться в менеджере секретов, а не в исходном коде, браузерных бандлах, журналах или диагностическом выводе. Разделяйте учётные данные и конфигурацию по окружениям, чтобы локальный тест не мог случайно отправить письмо через продакшен. Задавайте конечные тайм-ауты подключения и команд, но повторами писем пусть управляет надёжная очередь приложения. Параметр библиотеки с названием `secure` в одном SDK может означать неявный TLS, а в другом — лишь требование STARTTLS, поэтому проверяйте определение в библиотеке и тестируйте фактически согласованное поведение, а не полагайтесь на название параметра.

Тестируйте соединение послойно, не раскрывая секретов

Начните с разрешения DNS и доступности по TCP из той же сети среды выполнения, что и приложение. Тайм-аут до установления соединения указывает на маршрутизацию, файрвол, политику исходящего трафика провайдера, неверное имя хоста или закрытый порт. Затем проверьте ожидаемый режим TLS. При неявном TLS TLS-клиент должен получить сертификат, а затем SMTP-приветствие. При STARTTLS клиент с поддержкой SMTP должен получить приветствие, отправить `EHLO`, увидеть объявленный STARTTLS, запросить переход, проверить сертификат и после TLS снова отправить `EHLO`. RFC 3207 требует, чтобы клиент и сервер отбросили сведения, полученные до рукопожатия, — поэтому второй `EHLO` важен. Только после этого проверяйте аутентификацию на контролируемом аккаунте. Прежде чем делиться журналами, скройте имена пользователей, токены, адреса получателей, полные расшифровки сессий с сервером и содержимое писем. Для проверки связности не нужны ни отправка в продакшене, ни реальный адрес клиента.

Классифицируйте сбои по этапу, на котором они действительно произошли

Отказ в соединении (connection refused) означает, что TCP-адресат активно отклонил подключение; тайм-аут означает, что пригодный ответ не пришёл в пределах лимита. Ошибка TLS-рукопожатия указывает на несоответствие режимов, проблему с сертификатом, несовместимость протоколов, перехват трафика или неверный эндпоинт. Ошибка аутентификации возникает позже, и её нужно расследовать как проблему учётных данных, механизма, аккаунта или настройки авторизации, а не исправлять случайной сменой порта. Коды ответа SMTP на `MAIL FROM`, `RCPT TO` или `DATA` описывают ещё более поздние решения о политике и письме. Сохраняйте этап, время, эндпоинт, число попыток, числовой код ответа и ответ, очищенный от персональных данных. Ответ SMTP 4xx обычно временный, а 5xx обычно постоянный для данной команды, но повторы должны быть ограниченными и учитывать получателей. Если провайдер принял данные письма, не отправляйте вслепую дубликат только потому, что более поздний запрос приложения завершился тайм-аутом; сверяйтесь по идентификатору провайдера и истории событий.

Успешное подключение к порту — это не доставка и не попадание во «Входящие»

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

Осознанно выбирайте между отправкой через SMTP и email API

Используйте SMTP-отправку (submission), когда система уже имеет зрелый SMTP-клиент, нужная платформа поддерживает SMTP как вариант интеграции или особенно необходимы средства управления на уровне протокола. HTTPS email API может быть лучшей границей приложения, когда структурированные запросы, токены с ограниченными правами, идемпотентность, пакетные ресурсы и машиночитаемые записи событий подходят рабочей нагрузке. Провайдер всё равно может использовать SMTP далее по цепочке для доставки в почтовые системы получателей, поэтому API не отменяет транспортировку почты. Он переносит ответственность за порт, TLS, аутентификацию и повторы для передачи провайдеру из SMTP-конфигурации приложения.

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

Какой порт SMTP использовать приложению — 587 или 465?

Используйте порт и режим TLS, задокументированные провайдером. Порт 587 обычно использует STARTTLS, а порт 465 — неявный TLS. Оба могут защищать отправку при корректной реализации и обязательном TLS; конфигурация клиента должна соответствовать слушателю на сервере.

Почему порт SMTP 25 заблокирован или соединение уходит в тайм-аут?

Хостинг-платформа, интернет-провайдер, файрвол или политика получателя могут ограничивать порт 25, потому что он используется для релея между почтовыми серверами и часто становится объектом злоупотреблений. Уточните сетевую политику и используйте задокументированный провайдером эндпоинт для отправки, а не обходите ограничение произвольным портом.

Можно ли переключиться с порта 587 на 465, ничего больше не меняя?

Как правило, нет. Сессия на порту 587 обычно начинается с SMTP и переходит на TLS через STARTTLS, а на порту 465 сразу начинается TLS-рукопожатие. Меняйте порт и режим TLS клиента одновременно, следуя документации провайдера и библиотеки.

Шифруется ли порт 587 по умолчанию?

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

Что означает ошибка SMTP connection refused?

Она означает, что TCP-адресат отклонил подключение ещё до согласования SMTP. Частые причины: неверный хост или порт, сервис не слушает порт, отказ файрвола или эндпоинт провайдера недоступен из этой сети.

Доказывает ли успешная проверка порта SMTP доставку писем?

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