Порт 25 заблокирован: исходящая почта, 587 против 465 и relay

Порт 25 заблокирован на большинстве домашних подключений и на многих серверах, потому что именно через него доставляется спам, а закрыть его - самый дешёвый для сети способ помешать заражённым машинам и арендованным серверам своих клиентов рассылать спам. Блокировка почти всегда касается исходящих соединений к порту 25 чужих серверов. Она не мешает вашим пользователям отправлять почту через собственный почтовый сервер, потому что для этого используются порты 587 или 465, которые блокируют редко. И она не мешает вам держать почтовый сервер: вы принимаете почту на 25, если он открыт на вход, и отправляете через relay на 587, если он закрыт на выход.

Путаница возникает оттого, что «порт 25» означает три разные вещи в зависимости от того, кто к кому подключается. Эта статья разделяет их, показывает, как понять, на какую блокировку вы наткнулись, и раскладывает варианты.

Три порта, три задачи#

SMTP работает на трёх портах, и они не взаимозаменяемы.

Порт 25 - это место, где почта переходит между организациями. Когда ваш сервер доставляет письмо в Gmail, он подключается к MX Gmail на порту 25. Когда Gmail доставляет письмо вам, он подключается к вашему MX на порту 25. Входа здесь нет: получатель принимает от кого угодно почту, адресованную его доменам, и судит об отправителе по репутации и записям аутентификации. Эта открытость и есть причина злоупотреблений.

Порт 587 определён в RFC 6409 для отправки сообщений (submission): клиент пользователя передаёт письмо своему провайдеру после аутентификации. Сервер перешлёт его дальше, потому что знает, кто вы. Соединение начинается открытым текстом и переходит на шифрование через STARTTLS; правильно настроенный сервер не принимает логин, пока не установлен TLS.

У порта 465 запутанная история. В 1990-х его выделили под SMTP поверх SSL, потом сняли регистрацию, полмира всё равно им пользовалось, а в 2018 году RFC 8314 снова официально закрепил его как «submissions» - отправку поверх неявного TLS. RFC 8314 даже предпочитает его варианту 587 со STARTTLS, потому что здесь нет фазы открытого текста, которую мог бы подделать атакующий. На практике годятся оба; выберите тот, что поддерживают ваш сервер и клиент, и выставьте в клиенте соответствующий режим безопасности.

Некоторые relay-сервисы слушают ещё и порт 2525. Это не стандартный порт, а просто запасной порт для отправки в сетях, где заблокирован и 587. Ведёт он себя как 587.

Почему сети блокируют порт 25#

В 2000-е большую часть спама рассылали домашние компьютеры, заражённые вредоносами, и каждый из них подключался напрямую к почтовым серверам получателей на порту 25. Блокировка исходящего 25 на бытовых подключениях пресекла это у источника, и провайдеры сделали это практически повсеместно. Добросовестных пользователей это не задело, потому что их почтовые клиенты отправляют почту на сервер провайдера через 587.

Теперь та же логика действует и для серверов. Кто угодно может за несколько долларов арендовать виртуальную машину, за полдня разослать с неё миллион спам-писем и уйти, оставив адрес во всех блок-листах, а весь диапазон провайдера - с плохой репутацией. Поэтому облачные и хостинговые провайдеры тоже ограничивают исходящий 25 по умолчанию:

• Google Cloud вообще не разрешает исходящие соединения на порт 25 из Compute Engine и отсылает пользователей к relay-сервисам.
• AWS по умолчанию ограничивает исходящий 25 на EC2 и снимает ограничение по запросу через форму.
• Microsoft Azure блокирует исходящий 25 для большинства типов подписок.
• Многие VPS-провайдеры блокируют его для новых аккаунтов и разблокируют, когда у аккаунта появится история, или по тикету с объяснением, зачем он нужен.

Правила меняются, поэтому сверяйтесь с актуальной документацией своего провайдера, но картина неизменна: исходящий 25 - это привилегия, а не норма.

Входящий 25 - отдельный вопрос. На домашних подключениях его тоже часто блокируют (так что сервер дома не запустишь), а в контейнерном хостинге отдельный сервер не может просто занять порт 25 на общем адресе - сеть должна направить его к вам.

Какое направление заблокировано: проверка#

Прежде чем что-то менять, выясните, что происходит на самом деле. Проверить нужно три вещи, в идеале с самого почтового сервера и с машины за пределами его сети.

# 1. Outbound 25 from the server: can it reach a big receiver?$ nc -vz -w 5 gmail-smtp-in.l.google.com 25# 2. Inbound 25 to the server: run this from a DIFFERENT network$ nc -vz -w 5 mail.example.com 25# 3. Submission: can clients reach your server on 587 and 465?$ nc -vz -w 5 mail.example.com 587$ openssl s_client -connect mail.example.com:465 -quiet

nc пишет succeeded или open, когда TCP-соединение устанавливается, и завершается таймаутом, когда что-то отбрасывает пакеты. Таймаут в проверке 1 - это блокировка исходящих соединений; таймаут в проверке 2 - проблема со входящими (файрвол, непроброшенный порт или сервер, который не слушает). Connection refused - это не то же самое, что таймаут: пакеты дошли, но на этом порту никто не слушает, и это указывает на почтовый сервер, а не на сеть.

Для более «разговорной» проверки openssl s_client -starttls smtp -connect host:25 -crlf подключается, переходит на TLS и позволяет ввести EHLO test.example.com, чтобы увидеть возможности сервера. swaks («швейцарский нож для SMTP») автоматизирует целые тестовые транзакции, и его стоит установить на любую машину, с которой вы отлаживаете почту.

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

Ошибки, похожие на блокировку порта, но ею не являющиеся

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

• `554` или `550` со ссылкой на блок-лист в тексте - соединение состоялось; получатель отказал, потому что ваш IP в списке. Проверьте адрес в списке, названном в сообщении, и пройдите его процедуру удаления.
• `550 5.7.1` с упоминанием reverse DNS или PTR - получатель проверил обратный DNS вашего IP, и тот ему не понравился. Это вопрос настройки для владельца адреса; см. статью обратный DNS и PTR для почтовых серверов.
• `421` «try again later» или отсрочки с упоминанием лимитов - получатель притормаживает незнакомого отправителя. Для нового IP это нормально; очередь повторяет попытки, и доставка обычно проходит в течение нескольких часов.
• `530 5.7.0` must issue STARTTLS first - вы подключились к порту для отправки и попытались войти до перехода на TLS. Это настройка клиента, а не проблема сети.
• `535` authentication failed - неверное имя пользователя или пароль на порту отправки или relay. С сетью всё в порядке.

Только молчаливый таймаут, вообще без SMTP-ответа, означает, что пакеты не дошли. Всё, что с трёхзначным кодом, означает, что вы достучались до почтового сервера и он что-то ответил; прочитайте, что именно.

Что делать, если исходящий 25 заблокирован#

Вариантов четыре, примерно в порядке того, как часто каждый оказывается правильным.

1. Отправляйте через relay. Настройте почтовый сервер так, чтобы вся исходящая почта передавалась smarthost на порт 587 или 465 с аутентификацией по имени пользователя и паролю. Relay доставляет почту от вашего имени с IP-адресов, у которых уже есть репутация и обратный DNS. Ваш сервер по-прежнему принимает почту напрямую и хранит ящики. Это стандартное решение, и оно подробно описано в статье SMTP relay для исходящей почты.
2. Попросите снять блокировку. Некоторые провайдеры соглашаются, если вы объясните, зачем это нужно, подтвердите, что обратный DNS настроен, и покажете рабочий контакт для жалоб (abuse). Тогда вы отправляете почту напрямую - но заодно берёте на себя наращивание репутации IP с нуля, а это занимает недели. Что это означает, читайте в статье почему письма попадают в спам.
3. Отправляйте через почтовый сервис провайдера, а принимайте на собственном сервере. Работоспособно, но такое разделение усложняет SPF и DKIM, и проще relay это бывает редко.
4. Перенесите сервер в сеть, где исходящий 25 разрешён. Разумный выбор, если вы планируете отправлять напрямую значительные объёмы и готовы управлять репутацией; для небольшой организации - перебор.

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

Что не работает#

Некоторые идеи всплывают каждый раз и не помогают.

• Запустить SMTP на другом порту. Другие почтовые серверы доставляют почту только на порт 25. Нельзя сказать Gmail доставлять на ваш порт 2525 - для этого нет DNS-записи. В MX-записях нет поля для порта. Нестандартные порты работают только для отправки, где клиент под вашим контролем.
• Пустить исходящий 25 через VPN. Это переносит проблему на адреса VPN, которые обычно уже в блок-листах и не имеют обратного DNS для вашего домена. Почта уходит прямо в спам или отклоняется.
• Отправлять через собственный `sendmail` веб-сервера. На хосте, где 25 заблокирован, локальная почтовая программа ставит письмо в очередь и молча терпит неудачу. Приложения должны отправлять почту на настоящий почтовый сервер или relay через 587 с учётными данными. Подробности для кода приложений - в статье транзакционная почта из вашего приложения.
• Открыть порт 25 в собственном файрволе. Если блокировка стоит выше, у провайдера, ваши правила файрвола ничего не меняют. Где находятся разные уровни, объясняет статья правила файрвола, которые имеют значение.

Как порт 25 работает на RE:NODE Mail Server#

Два направления - два ответа.

Входящий: тариф Mail Server запускает Stalwart в контейнере, а контейнер не может сам открыть порт 25 на публичном адресе. Откройте тикет, и поддержка пробросит порт 25 на адресе вашего сервера к вашему серверу. Поскольку принимать почту на порту 25 конкретного адреса может только один сервер, на один адрес приходится один почтовый сервер. Пока это не сделано, другие почтовые серверы не могут доставить вам почту - они поставят её в очередь и будут повторять попытки, так что почта, отправленная за это время, обычно приходит, как только проброс настроен, если он уложился в окно повторов отправителей длиной в несколько дней.

Исходящий: если какая-то сеть на пути не пропускает ваш исходящий порт 25, отправляйте почту через relay, настроенный в веб-админке Stalwart; он подключается наружу на 587 или 465 с учётными данными relay. Ваших пользователей и приложения это в любом случае не касается: они отправляют почту на ваш сервер Stalwart через его порт для отправки, используя номер порта, который панель показывает для вашего сервера, а Stalwart сам решает, как письмо уйдёт дальше. В тарифах пять портов - для отправки, IMAP, HTTPS и всего остального, что вы решите открыть наружу. Остальное описано в статье настройка почтового сервера Stalwart, а о том, подходит ли вам вообще собственный сервер, - в статье руководство по собственному почтовому серверу.

Разбор на примере: застрявшая очередь#

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

Клиенты правы: они отправили письмо на 587, прошли аутентификацию, и сервер его принял. Проблема на следующем шаге. Очередь сервера показывает, что все внешние письма ждут, и последняя ошибка у каждого звучит примерно как «connection timed out» при подключении к MX-хостам получателей.

1. С консоли сервера nc -vz -w 5 gmail-smtp-in.l.google.com 25 завершается таймаутом. Исходящий 25 заблокирован.
2. nc -vz -w 5 smtp.relayprovider.example 587 проходит. Отправка на relay открыта.
3. Они заводят аккаунт у relay-сервиса, добавляют его include: в SPF-запись домена, настраивают relay в почтовом сервере с выданными учётными данными и направляют через него внешнюю почту.
4. Они повторяют отправку очереди. Письма уходят в течение минуты. Authentication-Results у получателя показывает spf=pass через include relay, dkim=pass с собственным селектором компании и dmarc=pass.

Всего около получаса. Пользователи так и не узнали, что их письма всё утро провели в ожидании.

FAQ#

Должен ли мой почтовый клиент использовать порт 25?

Нет. Клиенты отправляют почту на 587 со STARTTLS или на 465 с неявным TLS после входа. Порт 25 предназначен для доставки между серверами и к тому же заблокирован в большинстве бытовых сетей.

Порт 465 устарел?

Уже нет. Несколько лет он был снят с регистрации, но в 2018 году RFC 8314 снова закрепил его за отправкой поверх неявного TLS и рекомендует его. И 465, и 587 актуальны, и пользоваться можно обоими.

Можно ли принимать почту на порту, отличном от 25?

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

Не будет ли из-за relay казаться, что почта приходит от кого-то другого?

Нет, если всё настроено правильно. Ваш сервер подписывает письма вашим собственным DKIM-ключом до передачи, а relay вы добавляете в свою SPF-запись, так что DMARC проходит для вашего домена. Получатели видят ваш домен, а не домен relay.

Провайдер снял блокировку. Нужен ли мне ещё relay?

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