Порты 25, 465 и 587: какой выбрать для отправки почты

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

Ниже разобрано, за что отвечает каждый номер, как выглядит обмен на 465 и на 587 построчно, чем implicit TLS отличается от STARTTLS на уровне команд, как проверить доступность порта тремя разными командами и что делать, когда соединение отбивается. В конце порты приёма почты и то, как номер записывается в настройках программы.

За что отвечает каждый порт

Мы разбираем три номера в том порядке, в каком они встречаются на пути письма. Все три закреплены за разными участками этого пути. Порт 25 обслуживает перегон между почтовыми серверами: отправляющий сервер находит MX-запись домена получателя и стучится на 25 к тому хосту, который в ней указан. Порты 465 и 587 обслуживают submission, то есть сдачу письма от программы пользователя своему серверу. Разница по смыслу простая: на 25 сервер разговаривает с сервером, на 465 и 587 программа разговаривает со своим сервером и предъявляет логин.

Разделение на submission и перегон между серверами придумано ради того, чтобы сервер мог по номеру порта понять, с кем говорит. На 587 и 465 он ждёт авторизацию и принимает письма только от своих пользователей. На 25 он принимает почту для собственных доменов от кого угодно снаружи, поэтому там действуют совсем другие проверки: обратная зона, SPF, ограничение частоты, серые списки.

Порт 2525 в реестре IANA за почтой не закреплён. Часть сервисов слушает его дополнительно, чтобы клиенты с прикрытым 587 могли отправлять письма без переезда. Обмен на нём идёт по тем же правилам, что и на 587.

Порт 25: передача между почтовыми серверами

Сеанс на 25 начинается открытым текстом. Сервер отвечает баннером 220, клиентская сторона представляется командой EHLO и получает список расширений. Если оба конца поддерживают STARTTLS, обмен переходит в шифрование, и дальше письмо идёт внутри туннеля. Согласие тут добровольное: когда принимающая сторона расширение не объявила, письмо уйдёт открытым текстом.

220 mx.example.net ESMTP Postfix
EHLO relay.example.org
250-mx.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>

Ключевая деталь для практика: команды AUTH в этом сеансе нет. Принимающий сервер берёт письмо потому, что адрес получателя относится к его домену. Попытка отправить через чужой 25 письмо на сторонний домен закончится ответом 554 5.7.1 Relay access denied.

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

Поэтому серверные скрипты и почтовые программы на 25 наружу не ходят. Сдача письма идёт на submission-порт своего сервера, а уже он от своего адреса перегоняет письмо дальше по 25.

Порт 465: соединение сразу в шифровании

На 465 шифрование поднимается до первой почтовой команды. TCP-соединение установилось, и клиент немедленно отправляет TLS ClientHello. Сервер отвечает своим сертификатом, стороны согласуют шифр, и только внутри готового туннеля приходит баннер 220. Такой порядок называют implicit TLS: договариваться о шифровании не нужно, оно подразумевается самим номером порта.

openssl s_client -connect smtp.example.net:465 -servername smtp.example.net -quiet
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
220 smtp.example.net ESMTP ready
EHLO client.example.org
250-smtp.example.net
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250 8BITMIME
AUTH LOGIN
334 VXNlcm5hbWU6

Обратите внимание на строку 250-AUTH: сервер объявляет доступные механизмы авторизации сразу, потому что канал уже защищён. Логин и пароль уходят внутри туннеля, перехватить их по дороге нечем.

У 465 своя история. Номер выделяли под SMTPS, затем отзывали, затем возвращали уже под именем submissions, и в промежутке часть документации называла его устаревшим. Сегодня это полноценный порт сдачи писем, его слушают Postfix через smtps в master.cf, Exim через tls_on_connect_ports, Dovecot, а также крупные почтовые сервисы. При настройке нового клиента 465 удобен именно предсказуемостью: шифрование либо поднялось, либо соединения нет.

Единственное, что нужно проверить перед выбором 465: слушает ли его ваш сервер. Часть площадок оставляет только 587. Одна команда openssl s_client отвечает на этот вопрос за секунду.

Порт 587: отправка от клиента через STARTTLS

Сеанс на 587 начинается открытым текстом и переходит в шифрование по явной команде. Порядок такой: сервер шлёт баннер 220, клиент представляется EHLO, сервер перечисляет расширения, клиент отправляет STARTTLS, сервер отвечает 220 2.0.0 Ready to start TLS, стороны выполняют рукопожатие. После рукопожатия клиент обязан повторить EHLO, потому что список расширений внутри шифрования другой.

openssl s_client -starttls smtp -connect smtp.example.net:587 -quiet
220 smtp.example.net ESMTP ready
EHLO client.example.org
250-smtp.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
STARTTLS
220 2.0.0 Ready to start TLS

Повторный EHLO часто пропускают при ручной отладке и потом гадают, почему AUTH отсутствует в списке. Механизмы авторизации многие серверы прячут до подъёма шифрования: пока канал открыт, строка 250-AUTH в ответе отсутствует, после рукопожатия она появляется. Postfix делает это директивой smtpd_tls_auth_only = yes.

Второе поведение, о котором полезно знать: сервер на 587 обычно настроен требовать авторизацию для всех отправок. Попытка выполнить MAIL FROM без AUTH возвращает 530 5.7.0 Authentication required. Это нормальный ответ, он говорит о правильно настроенном submission-порту.

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

Implicit TLS и STARTTLS: разница на уровне обмена

Разница видна по первому пакету после установки TCP-соединения. На 465 первым идёт TLS ClientHello от клиента. На 587 первым идёт текстовый баннер от сервера, и до команды STARTTLS весь обмен читается любым наблюдателем на пути.

Из этой таблицы следуют два практических вывода. Первый: на 587 список расширений виден дважды, и содержимое двух списков отличается. Второй: на 587 объявление STARTTLS идёт открытым текстом, поэтому в почтовых программах существует настройка «требовать шифрование». Она заставляет клиента разорвать сеанс, когда расширение в списке отсутствует. На 465 такой настройки не требуется: там нечего подменять, шифрование начинается с первого байта.

Сертификат мы проверяем в обоих случаях одинаково. Имя в сертификате сверяется с тем именем хоста, которое написано в настройках, поэтому openssl s_client полезно запускать с ключом -servername: без него на площадках с несколькими доменами придёт сертификат по умолчанию, и вывод собьёт с толку.

Ещё один момент касается портов приёма. Пара «открытое начало плюс STARTTLS» и «шифрование сразу» повторяется у IMAP и POP3 в точности так же, поэтому, разобравшись один раз на SMTP, вы уже знаете, как устроены 143 и 993.

Как выбрать порт под свой почтовый сервис

Выбор делается по трём вопросам: что слушает ваш почтовый сервер, что умеет ваша программа или библиотека и что пропускает сеть, из которой уходит соединение. Начинать удобно с документации сервиса, там номера портов указаны прямо. Дальше остаётся проверить проходимость.

Отправка через посредника заслуживает отдельного слова. Почтовое соединение это обычный TCP-поток, и посредник переносит его как есть. По HTTP это делается методом CONNECT: клиент просит открыть туннель до пары хост и порт, получает 200 Connection established и дальше гонит по туннелю байты SMTP. Для программ, которые ходят по HTTP-схеме и умеют туннелировать произвольные порты, подойдут прокси HTTP для почтовых программ с доступом по логину либо по привязке своего адреса. Механика самого туннеля разобрана отдельно, если нужны подробности рукопожатия, смотрите материал про туннель CONNECT и работу с шифрованием.

Второй путь, который в почте встречается чаще, это SOCKS5. Он не разбирает содержимое потока и переносит соединение на любой номер порта, поэтому 25, 465, 587, 993 и 995 проходят через него одинаково. Именно поэтому почтовые клиенты в своих настройках сети предлагают SOCKS5 первым: адреса SOCKS5 для произвольных портов закрывают и отправку, и приём одной настройкой. Мы выдаём один и тот же список адресов под оба варианта доступа, меняется только строка подключения в программе.

Проверка доступности порта: telnet, nc и openssl s_client

Проверка идёт снизу вверх: сначала TCP, потом рукопожатие TLS, потом почтовый обмен. Каждому уровню соответствует своя команда, и путать их не стоит, иначе вывод читается неправильно.

Через посредника команды меняются мало. Утилита nc умеет ходить по SOCKS5 сама, curl принимает адрес посредника ключом -x, а для проверки TLS через туннель удобно поднять локальный проброс и уже к нему обращаться openssl s_client.

# доступность порта через SOCKS5
nc -X 5 -x 185.24.87.14:1080 -vz smtp.example.net 587

# полный SMTP-обмен через SOCKS5 с логином и паролем
curl -v --url smtp://smtp.example.net:587 \
     --proxy socks5h://user5521:[email protected]:1080 \
     --mail-from [email protected] --mail-rcpt [email protected] \
     --upload-file letter.txt

# туннель CONNECT до почтового порта через HTTP-посредник
curl -v --proxy http://185.24.87.14:8000 --url smtps://smtp.example.net:465

Отдельно про telnet. Утилита показывает живой текстовый диалог и потому удобна на 25 и 587, где обмен начинается открытым текстом. На 465 она бесполезна: там первым идёт двоичное рукопожатие, и на экране появится молчание либо мусор. Для 465 берём openssl s_client, он делает ровно то, что нужно.

Отказ соединения на порт: что смотреть по шагам

Отказы делятся на два больших класса по одному признаку: скорости ответа. Мгновенный отказ приходит от сетевого стека, значит пакет дошёл и хост ответил сбросом. Долгое молчание до таймаута означает, что пакеты где-то отбрасываются без ответа, и это почти всегда фильтр по пути.

Порядок разбора короткий. Первым делом проверяем TCP командой nc -vz, чтобы отделить сетевую часть от почтовой. Дальше смотрим, поднимается ли TLS: на 465 через прямое подключение, на 587 через ключ -starttls smtp. Если оба уровня прошли, дальнейшие ответы читаются по кодам из таблицы выше, и они уже говорят о настройках почтового сервера.

Когда соединение уходит через посредника, добавляется третий уровень проверки. Сначала убеждаемся, что сам посредник принимает соединение и отдаёт 200 Connection established либо рукопожатие SOCKS5. Только после этого имеет значение ответ почтового сервера. Мы держим приватные серверные адреса на собственном оборудовании и рекомендуем разделять эти два шага при любом разборе: половина запутанных случаев объясняется тем, что обрыв случился на первом уровне, а искали причину на третьем.

Ещё одна частая причина отказа сидит в привязке. Доступ открывается либо по логину с паролем, либо по адресу машины, указанному в кабинете. Когда провайдер сменил адрес рабочей машины, соединение начинает отбрасываться молча, и картина внешне совпадает с закрытым портом. Проверяется это одной командой curl на эхо-сервис.

Порты приёма почты и запись номера в настройках

Отправка это половина работы почтового клиента. Вторая половина, приём, устроена по той же логике портов, поэтому таблица ниже читается как продолжение первой.

Закономерность видна сразу: у каждого почтового протокола есть номер с открытым началом и номер с шифрованием от первого байта. Номера 993 и 995 сегодня стоят по умолчанию почти везде. Устройство самих сеансов приёма и разбор команд FETCH, RETR и DELE вынесены в отдельный материал про приём почты по IMAP и POP3.

Как порт задаётся в строке подключения

В графическом клиенте порт указывается отдельным полем рядом с именем сервера, и рядом же стоит выпадающий список типа шифрования. Соответствие простое: SSL/TLS означает implicit TLS и идёт с 465, 993, 995. Пункт STARTTLS идёт с 587, 143, 110.

В коде и конфигах порт живёт внутри строки подключения, обычно после двоеточия за именем хоста. Схема URI при этом сама подсказывает тип шифрования.

smtp://smtp.example.net:587     обычное начало, дальше STARTTLS
smtps://smtp.example.net:465    шифрование сразу после соединения
imap://mail.example.net:143     обычное начало, дальше STARTTLS
imaps://mail.example.net:993    шифрование сразу после соединения
pop3s://mail.example.net:995    шифрование сразу после соединения

import smtplib

# порт 587: открываем соединение, поднимаем шифрование командой
s = smtplib.SMTP('smtp.example.net', 587, timeout=20)
s.ehlo()
s.starttls()
s.ehlo()
s.login('[email protected]', 'secret')

# порт 465: шифрование поднимается вместе с соединением
s = smtplib.SMTP_SSL('smtp.example.net', 465, timeout=20)
s.login('[email protected]', 'secret')

Строка подключения посредника устроена похоже и живёт рядом. Список выдаётся в форматах IP:PORT и IP:PORT:LOGIN:PASS, забрать его можно ссылкой или файлом, обновляется он в режиме реального времени. В настройках почтовой программы адрес и порт посредника указываются в разделе сети, отдельно от адреса и порта почтового сервера. Путать два порта в одном окне легко, поэтому мы советуем выписать обе пары рядом на лист перед настройкой. Разбор полей строки собран в материале про строку подключения по полям, а состав пакета с потоками и привязками описан там, где оформляется пакет с доступом по протоколу HTTP.

Отдельного внимания просит число одновременных сеансов. Почтовые серверы ограничивают частоту подключений с одного адреса, и при массовой работе счётчик упирается в потолок быстро. На стандартных пакетах доступно до 1000 потоков, на корпоративном до 3000, а при двух привязанных адресах общая цифра делится пополам. Пул держится в районе 12 000 активных адресов, ротация внутри него идёт автоматически. Полный состав доступа описан на странице, где можно оформить доступ к пулу адресов IPv4.

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

Почему письма не уходят через порт 25 с моего сервера?

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

Что выбрать при равной доступности 465 и 587?

Оба порта рабочие. Порт 587 удобен универсальностью: его слушают все распространённые почтовые сервисы, и библиотеки поддерживают STARTTLS из коробки. Порт 465 удобен предсказуемостью: шифрование поднимается вместе с соединением, подменить объявление расширения по дороге нечем. При настройке нового клиента мы обычно ставим 587, а 465 берём для библиотек, где STARTTLS настраивается тяжело.

Подойдут ли ваши прокси под мою почтовую задачу?

Заранее предугадать поведение каждого почтового сервиса и каждой программы нельзя, поэтому перед покупкой доступен бесплатный тест длительностью до 2 часов под ваш запрос. Тест проходит на вашем софте, с вашими портами и вашим сервером, и его результат отвечает на вопрос точнее любого описания. Порядок запуска: выбрать тип прокси под свой софт, зарегистрироваться в кабинете, отправить запрос теста из меню, указать свой адрес в настройках, активировать доступ и написать оператору логин и тип прокси.

Сколько времени занимает включение пакета после оплаты?

Пакет включается примерно за 5 минут после подтверждения списания с баланса. После этого раздел выдачи начинает отдавать список адресов в двух форматах, IP:PORT и IP:PORT:LOGIN:PASS, ссылкой либо файлом. Доступ открывается по привязке своего адреса в настройках кабинета либо по паре логина и пароля, в пакет входит две одновременные привязки со свободной сменой.

Порты это одна деталь почтового обмена, вокруг неё есть смежные разборы. Как устроен сам протокол и из чего складывается путь письма, описано в материале про устройство протокола SMTP. Настройка отправки через посредника, с командами и разбором ответов сервера, собрана в заметке про отправку почты через прокси. Разница между HTTP, HTTPS, SOCKS4 и SOCKS5 при выборе типа доступа разобрана в сравнении четырёх протоколов посредника. А если почтовая программа уже настроена и остаётся подключить её к пулу, начните с материала про подключение в программах и на сервере.