Выбор порта и метода шифрования при настройке почты зависит от роли пользователя, требований безопасности и конфигурации сервера, где порт 587 со STARTTLS является стандартом для клиентов, а порт 25 зарезервирован для взаимодействия между серверами
Настройка почтового клиента часто превращается в упражнение по угадыванию. В окне конфигурации выпадающий список предлагает три варианта шифрования и три числа для порта. Раньше перебор комбинаций продолжался до исчезновения ошибки соединения. Потом пришлось разобраться в протоколах, чтобы понимать причину ошибок, а не просто устранять следствие.
Стандартная панель настройки показывает опции: без шифрования, SMTPS, STARTTLS. Порты предлагаются следующие: 25, 465, 587. Для обычного пользователя это выглядит как избыточность. Для администратора это разделение задач внутри инфраструктуры передачи сообщений. Разница между вариантами не только в цифрах, но и в этапе установки защищенного соединения.
Какой порт выбрать для настройки почты 25 465 или 587
Когда вы отправляете письмо из почтового клиента, оно попадает не напрямую в систему межсерверной пересылки, а сначала в MSA. Этот компонент проверяет учётные данные пользователя, валидирует формат сообщения, применяет политики домена и только после этого передаёт письмо в MTA (Mail Transfer Agent) для дальнейшей маршрутизации. Разделение MSA и MTA появилось по нескольким причинам.
[√] Авторизация — MSA требует логин и пароль, MTA работает без проверки пользователя
[√] Валидация — MSA отклоняет письма с ошибками формата до отправки в сеть
[√] Политики — MSA применяет правила домена, квоты, ограничения на вложения
[√] Логирование — MSA фиксирует кто и когда отправил письмо для аудита
Message Submission Agent, компонент почтовой инфраструктуры который принимает письма от авторизованных клиентов и передаёт их дальше для доставки. Большинство почтовых сервисов рекомендуют использовать порт 587 с обязательным шифрованием STARTTLS. Это текущий стандарт для submission агентов. Если провайдер или хостинг не поддерживает этот вариант, допускается использование порта 465 с протоколом SMTPS. Порт 25 следует оставлять для серверного взаимодействия, если не администрируется собственная инфраструктура доставки.
Провайдеры интернет-услуг часто блокируют исходящие подключения к порту 25 для абонентов физических лиц. Это мера против распространения спама. Злоумышленники используют зараженные компьютеры для рассылки сообщений напрямую через открытые релеи. Блокировка порта на стороне провайдера предотвращает такую активность.
[√] Порт 587 + STARTTLS — стандарт для почтовых клиентов с обязательной авторизацией
[√] Порт 465 + SMTPS — валидный вариант с шифрованием сразу при подключении
[ ] Порт 25 — только для серверного взаимодействия, часто блокируется провайдерами
Разделение портов возникло не из-за технических ограничений протокола, а из-за необходимости разграничить потоки трафика. Сообщения от пользователей требуют проверки учетных данных. Сообщения между серверами проверяются другими методами, например через SPF и DKIM записи домена. Смешивание этих потоков на одном порту усложняет фильтрацию и мониторинг. SPF, DKIM и DMARC три механизма аутентификации почты которые работают на уровне домена и позволяют серверам проверять подлинность отправителя.
SPF (Sender Policy Framework) запись в DNS которая содержит список IP-адресов почтовых серверов уполномоченных отправлять почту от имени домена. Когда сервер получает письмо он смотрит SPF-запись домена отправителя и сверяет адрес подключившегося сервера со списком. Если адреса нет в списке — письмо может быть помечено как подозрительное.
[√] Запись публикуется в зоне домена в формате TXT
[ ] Указывает разрешённые сервера по IP или механизму включения
[ ] Проверка происходит на этапе SMTP-сессии до передачи тела письма
DKIM (DomainKeys Identified Mail) цифровая подпись которая добавляется к заголовкам письма. Сервер отправителя вычисляет хеш от содержимого письма и подписывает его приватным ключом. Получатель берёт публичный ключ из DNS домена отправителя и проверяет подпись. Если подпись не совпадает — письмо было изменено в пути или отправлено неавторизованным сервером.
Технически DKIM использует алгоритмы вроде RSA или EdDSA для подписи. Подпись покрывает выбранные заголовки и тело письма. Это гарантирует что содержимое не менялось после отправки.
DMARC (Domain-based Message Authentication, Reporting and Conformance) политика которая объединяет результаты проверок SPF и DKIM и указывает получателю как поступать с письмами которые не прошли аутентификацию. Политика публикуется в DNS и содержит три ключевых параметра:
- p=none — не предпринимать действий, только собирать отчёты
- p=quarantine — помещать непроверенные письма в спам
- p=reject — отклонять письма которые не прошли проверку
Также DMARC позволяет домену получать отчёты от крупных почтовых провайдеров о том кто и как отправляет почту от его имени. Это помогает выявлять попытки подделки домена.
Проверить настройки домена можно через онлайн-инструменты вроде MXToolbox или командой dig TXT пример.домена в терминале. Записи начинаются с v=spf1, v=DKIM1 или v=DMARC1
Проверка настройки на трех разных хостингах показала: два рекомендовали 587 порт, один предлагал 465. Оба варианта работали одинаково надежно. Разница заметна только при анализе трафика.
Чем ESMTP отличается от обычного SMTP
Когда в документации встречается аббревиатура SMTP, чаще всего подразумевается расширенная версия протокола ESMTP. Базовый спецификация RFC 821 1982 года не предусматривала механизмов аутентификации. Любой сервер мог принять сообщение от любого клиента без проверки прав. Это позволяло отправлять письма от имени любого адреса.
ESMTP вводит команду EHLO вместо базовой HELO. Сервер отвечает списком поддерживаемых расширений. Клиент анализирует этот список и активирует нужные функции. Среди расширений встречаются AUTH для ввода логина и пароля, STARTTLS для шифрования канала, SIZE для ограничения размера вложения.
Проверка поддержки расширений через терминал показывает ответ на команду EHLO. Если в списке отсутствует STARTTLS, установить защищенное соединение не получится. Если нет AUTH, сервер не примет сообщение от клиента без дополнительной настройки IP-адресов.
Интересный момент заключается в том, что список возможностей передается в открытом виде. Даже если последующая сессия будет зашифрована, факт поддержки конкретных функций виден любому участнику сети. Это не является уязвимостью, но позволяет собирать информацию о конфигурации сервера.
Не все сервера отвечают одинаково. Некоторые скрывают часть расширений до авторизации. Это дополнительная мера безопасности, которая усложняет разведку злоумышленникам.
Почему порт 465 до сих пор работает если его убрали из стандартов
В середине 1990-х годов возникла задача добавить шифрование к существующим сервисам. Для HTTP выделили порт 443. Для почты выделили порт 465. Протокол SMTPS предполагал установку SSL-соединения сразу после TCP-рукопожатия. Команды SMTP передавались только после завершения криптографического handshake.
Позже инженеры пришли к выводу, что выделение отдельных портов для каждого сервиса с шифрованием не масштабируется. Количество портов ограничено. Для SMTP разработали расширение STARTTLS. Оно позволяет начать общение в открытом виде, а затем переключиться на шифрованный канал командой протокола. Порт 465 официально отозвали из стандартов.
Стандарты отозвали, но инфраструктура не изменилась мгновенно. Множество серверов продолжали слушать 465 порт. Клиенты продолжали поддерживать этот вариант. В 2018 году IETF официально вернула порт 465 в оборот для использования с implicit TLS через RFC 8314. Сейчас он работает параллельно с 587.
Некоторые провайдеры предпочитают 465 порт. Шифрование начинается сразу, без этапа переговоров в открытом виде. Это исключает возможность перехвата данных до момента установки защиты. Для пользователя разница незаметна, но для безопасности канала это имеет значение.
Тестирование обоих вариантов через анализатор трафика показало: на 465 порту весь обмен зашифрован с первого пакета. На 587 порту первые команды видны в открытом виде до команды STARTTLS.
Современные рекомендации RFC 8314 предлагают использовать implicit TLS там, где это возможно. Это снижает риск атак на этапе переговоров. Но STARTTLS остается широко поддерживаемым стандартом.
Как работает STARTTLS и можно ли его обмануть
Команда STARTTLS инициирует переход на защищенное соединение внутри существующего TCP-канала. Клиент отправляет команду, сервер подтверждает готовность. Начинается обмен криптографическими ключами. После завершения handshake все последующие данные передаются в зашифрованном виде.
Проблема заключается в этапе переговоров. Команда STARTTLS и ответ сервера передаются до включения шифрования. Злоумышленник в сети может перехватить ответ сервера и удалить из него поддержку TLS. Клиент получит список расширений без STARTTLS. Протокол предпишет отправить письмо в открытом виде.
Такая атака называется downgrade attack. Клиент не знает, что сервер поддерживает шифрование, потому что ему сказали обратное. Защита возможна только при строгой политике безопасности. Администратор сервера может запретить прием почты без шифрования. Клиент может быть настроен на разрыв соединения при отсутствии TLS.
[√] Настройте почтовый сервер на обязательное шифрование для исходящей почты
[ ] Включите в клиенте предупреждение если сервер не поддерживает STARTTLS
[ ] Используйте сертификат от доверенного центра а не самоподписанный
[ ] Регулярно обновляйте список поддерживаемых шифров убирая устаревшие
Тестирование поведения через openssl s_client показывает поддержку STARTTLS в ответе на EHLO при подключении к порту 587. Отправка команды запускает handshake TLS 1.3. Если на этапе переговоров подменить пакет с ответом сервера, клиент действительно может отправить данные в открытом виде. Зависит от настроек политики безопасности в клиенте.
Современные механизмы MTA-STS и DANE помогают решить эту проблему. MTA-STS позволяет домену опубликовать политику обязательного использования TLS. DANE использует DNS записи для проверки сертификатов сервера. Оба механизма требуют настройки на стороне домена.
Не все почтовые провайдеры поддерживают MTA-STS. Проверить поддержку можно через онлайн инструменты. Но для обычной отправки почты клиентом это не критично.
Зачем нужен порт 587 если есть порт 25
Оба порта используют один протокол передачи сообщений. Задачи у них разные. Порт 25 предназначен для общения между почтовыми серверами MTA. Порт 587 предназначен для отправки почты клиентами MSA. Разделение закреплено в стандартах RFC 4409 и RFC 6409.
Разделение появилось из-за проблемы спама. Раньше любой мог подключиться к серверу на порт 25 и отправить письмо. Злоумышленники находили неправильно настроенные сервера. Такие сервера принимали почту от кого угодно и пересылали дальше. Их называли open relay.
Чтобы ограничить спам, провайдеры начали блокировать исходящие подключения к порту 25 для обычных пользователей. Для легитимной отправки почты выделили порт 587 с обязательной авторизацией. Message Submission Agent на этом порту проверяет учетные данные. Затем сообщение передается дальше через MTA на порту 25.
Еще одно отличие касается обработки ошибок. MSA на порту 587 лучше обрабатывает ошибки клиента. Если в письме нет адреса получателя или нарушен формат, сервер сразу вернет сообщение об ошибке. Сервер на порту 25 может молча отклонить письмо или переслать его с ошибкой. Получатель увидит проблему только потом.
Отправка тестовых писем с ошибками через оба порта показала: на 587 ошибка возвращалась мгновенно. На 25 письмо принималось, но потом возвращалось bounce сообщение через несколько минут.
Порт 465 работает аналогично 587 с точки зрения задач. Разница только в методе установки шифрования. Оба предназначены для клиентской отправки с авторизацией.
Как выглядит зашифрованная сессия отправки почты на практике
Запуск анализатора трафика позволяет наблюдать за процессом. Почтовый клиент настроен на подключение к серверу через порт 587 с STARTTLS. Процесс начинается с установления TCP-соединения. Клиент отправляет SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK.
Затем начинается SMTP-сессия. Сервер присылает баннер с приветствием и кодом состояния 220. Клиент отвечает командой EHLO с указанием своего домена. Сервер перечисляет расширения. Среди них обязательно есть STARTTLS и методы авторизации AUTH PLAIN LOGIN.
Клиент отправляет команду STARTTLS. Сервер отвечает 220 Ready to start TLS. Начинается рукопожатие TLS. Обмен версиями протокола, выбор шифра, проверка сертификата сервера. После сообщения Finished с обеих сторон канал считается защищенным.
Дальше весь трафик идет в зашифрованном виде. Клиент авторизуется командой AUTH. Передает адрес отправителя MAIL FROM. Передает адрес получателя RCPT TO. Передает тело письма командой DATA. Перехватчик трафика видит только зашифрованные пакеты без возможности расшифровки содержимого.
Попробуйте повторить наблюдение. Установите анализатор трафика. Настройте фильтр по порту 587. Отправьте тестовое письмо. Вы увидите открытые команды до STARTTLS и зашифрованный трафик после. Если используете порт 465, весь трафик будет зашифрован с самого начала соединения.
Небольшая деталь, которая требует внимания. В процессе рукопожатия TLS клиент и сервер обмениваются списками поддерживаемых шифров. Порядок в этом списке может влиять на выбор алгоритма. Иногда сервер предпочитает более старые но совместимые шифры. Стоит проверить настройки безопасности сервера.
Версия TLS 1.3 сейчас является рекомендуемой. Она убирает устаревшие шифры и ускоряет handshake. Но не все сервера поддерживают эту версию.
Что проверить перед настройкой почтового клиента
Перед вводом настроек в клиенте уточните у провайдера или хостинга поддерживаемые параметры. Не все сервера одинаковы. Конфигурация зависит от версии программного обеспечения и политики безопасности администратора.
[√] Поддерживает ли сервер STARTTLS на порту 587
[ ] Требуется ли авторизация и какой метод PLAIN LOGIN OAuth
[ ] Используется ли самоподписанный сертификат или от доверенного центра
[ ] Блокирует ли провайдер исходящие подключения к порту 25
Если сервер использует самоподписанный сертификат, клиент может выдавать предупреждение о безопасности. Это нормально для внутренних систем. Для публичных сервисов лучше сертификат от известного центра. Игнорирование предупреждения снижает уровень защиты соединения.
Еще момент касается порта по умолчанию. Некоторые клиенты пробуют порт 25 автоматически. Если провайдер его блокирует, отправка не пройдет. Лучше сразу указать 587 или 465 в настройках аккаунта. Это сэкономит время на диагностику проблем с доставкой.
Проверка работоспособности шифрования доступна через командную строку. Команда telnet или openssl позволяет подключиться к серверу вручную. Ответ сервера покажет доступные методы защиты. Это надежнее чем доверять настройкам клиента по умолчанию.
Использование openssl для быстрой проверки работает так: команда openssl s_client -connect сервер:587 -starttls smtp покажет сертификат и поддержку шифрования. На 465 порту starttls не нужен, шифрование начинается сразу.
Рекомендации по безопасности
Стандарты безопасности продолжают развиваться. RFC 8314 рекомендует использовать implicit TLS где это возможно. Это означает порт 465 для отправки почты клиентами. Но STARTTLS на 587 остается полностью валидным вариантом.
MTA-STS становится распространенным механизмом для сервер-сервер доставки. Он публикует политику обязательного использования TLS для домена. Клиенты могут проверять эту политику перед отправкой.
DANE использует DNS записи для проверки сертификатов. Это добавляет дополнительный уровень доверия. Но требует настройки DNS записей и поддержки со стороны сервера.
Для обычного пользователя достаточно использовать 587 или 465 с шифрованием. Дополнительные механизмы работают на уровне серверов и доменов.
[√] Используйте шифрование для всех подключений
[ ] Требуйте TLS в настройках клиента
[ ] Проверяйте сертификат сервера
[ ] Обновляйте почтовый клиент регулярно
Некоторые клиенты позволяют настроить минимальную версию TLS. Установка TLS 1.2 или выше отсекает устаревшие небезопасные соединения. Но может вызвать проблемы со старыми серверами.
Проверка настроек в трех популярных клиентах показала: Thunderbird позволяет явно указать минимальную версию TLS. Outlook скрывает эти настройки по умолчанию. В мобильных клиентах варианты ограничены. Правильный выбор зависит от конфигурации провайдера. Начните с рекомендаций почтового сервиса. Если явных указаний нет, используйте порт 587 с STARTTLS. Это самый совместимый вариант.
Если 587 не работает или провайдер рекомендует 465, переключайтесь на implicit TLS. Оба варианта обеспечивают надежное шифрование при правильной настройке.
Порт 25 оставьте для серверного взаимодействия. Для клиентской отправки он практически бесполезен из-за блокировок провайдеров.
Главное требование — шифрование плюс авторизация. Без этих двух компонентов письмо может быть перехвачено или отправлено от вашего имени без разрешения.
Использование 587 порта для основных аккаунтов и 465 с самоподписанными сертификатами для внутренних систем работает стабильно больше года.
Проверьте свои настройки сейчас. Откройте конфигурацию почтового клиента. Убедитесь что выбран порт 587 или 465. Проверьте что шифрование включено. Это займет две минуты но защитит вашу переписку.
#интернетбезопасность #инфобез #киберзащита #технологии #программирование #разработка #безопасностьданных