MTA-STS и TLS-RPT для своего почтового сервера: как запретить доставку ваших писем без шифрования

Ваши письма с реквизитами и договорами могут уходить по интернету открытым текстом — и вы об этом даже не узнаете. Пока почта лежит в облаке, вы даже не знаете, шифруется ли переписка с вашими контрагентами по пути — это решает провайдер. На своём сервере это решаете вы, и MTA-STS — главный инструмент: политика, которая говорит отправителям «доставляйте мне почту только по шифрованному каналу с правильным сертификатом». TLS-RPT добавляет отчёты о том, где шифрование ломается. Разбираем, как включить MTA-STS на своём почтовом сервере за час и не потерять входящие письма.

Почему шифрование между серверами — не гарантия

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

MTA-STS закрывает эту дыру: отправитель заранее узнаёт, что ваш домен требует шифрования с действительным сертификатом, и отказывается доставлять иначе.

Открытым текстом через весь интернет

Шифрование между почтовыми серверами по умолчанию — добровольное. Достаточно кому-то по пути вырезать одну строку из ответа сервера, и письмо с платёжными реквизитами уйдёт незашифрованным. Подмена счетов — одна из самых прибыльных схем мошенничества, и начинается она именно здесь.

MTA-STS превращает шифрование из пожелания в требование: ваш домен заявляет миру, что принимает почту только по защищённому каналу с правильным сертификатом. Час настройки — и эта дыра закрыта. В облаке вы бы даже не узнали, есть ли она.

Кому это нужно в первую очередь

Перехват почты в пути — не теоретическая угроза для тех, чья переписка стоит денег. Бухгалтерия, которая отправляет и получает платёжные реквизиты, — классическая цель подмены счетов. Юристы с договорами и доверенностями. Отдел продаж с коммерческими предложениями и ценами. Руководство с переговорами. Для всех них MTA-STS — дешёвая страховка: час настройки и мониторинг сертификата.

Как работает MTA-STS

Стандарт описан в RFC 8461. Владелец домена публикует две вещи: DNS-запись _mta-sts с идентификатором политики и файл политики по HTTPS на поддомене mta-sts. В политике — режим, список ваших MX-серверов и срок, на который отправитель может запомнить политику. Отправитель, поддерживающий MTA-STS, перед доставкой проверяет запись, скачивает политику по HTTPS — где подлинность гарантирует обычный веб-сертификат, — и доставляет почту только на перечисленные MX и только по TLS с проверкой сертификата.

Крупные почтовые сервисы поддерживают MTA-STS при отправке, поэтому политика начинает защищать вашу входящую почту сразу после публикации.

Политика кэшируется отправителем на срок max_age. Это значит, что злоумышленнику мало вмешаться в одно соединение: отправитель уже знает, что ваш домен требует шифрования, и не поверит подмене, пока политика не истечёт.

Что нужно заранее

MTA-STS требует, чтобы сертификат вашего почтового сервера был действительным и выдан на имя, указанное в MX. Самоподписанный сертификат или сертификат на другое имя в строгом режиме приведёт к отказу в доставке. Проверьте это до включения.

• действительный сертификат на имя MX-сервера, например mail.company.ru, с автоматическим продлением
• веб-сервер, который может отдать файл по HTTPS на mta-sts.company.ru
• доступ к DNS-зоне домена
• адрес для отчётов TLS-RPT

Шаг 1. Файл политики

Создайте файл политики и опубликуйте его по адресу https://mta-sts.company.ru/.well-known/mta-sts.txt. Начинайте с режима testing: в нём отправители ничего не блокируют, но присылают отчёты о проблемах.

# https://mta-sts.company.ru/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.company.ru
max_age: 86400

Поле mx перечисляет все ваши MX-серверы, по строке на каждый; допускается шаблон вида *.company.ru. max_age — в секундах: на время тестов ставьте сутки, в рабочем режиме — неделю и больше. Для поддомена mta-sts нужен свой действительный веб-сертификат.

Шаг 2. DNS-записи

Опубликуйте запись _mta-sts с идентификатором политики и запись TLS-RPT для отчётов. Идентификатор — любая строка; меняйте его при каждом изменении файла политики, иначе отправители не узнают, что политика обновилась.

_mta-sts.company.ru.     TXT  "v=STSv1; id=20261011T1800"
_smtp._tls.company.ru.   TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@company.ru"
mta-sts.company.ru.      A    203.0.113.10

Шаг 3. Отчёты TLS-RPT

TLS-RPT описан в RFC 8460. Отправители, поддерживающие его, раз в сутки присылают на указанный адрес отчёт в формате JSON: сколько соединений к вашим серверам прошли с шифрованием успешно, сколько — с ошибкой и какой. Именно отчёты показывают, можно ли переходить в строгий режим: если ошибок нет неделю-две, политика готова.

Отчёты приходят в виде сжатых вложений. Их удобно складывать в отдельный ящик и разбирать скриптом или сервисом анализа отчётов.

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

Как читать отчёт TLS-RPT

Отчёт — JSON-файл, который описывает сутки соединений к вашему домену от одного отправителя. Главное в нём: какая политика применялась — MTA-STS, DANE или никакая; число успешных сессий; число сессий с ошибкой и подробности по каждой причине. Типичные причины ошибок, описанные в стандарте: сертификат истёк, сертификат не прошёл проверку, имя не совпадает, сервер не предложил STARTTLS, политику не удалось скачать.

Если в отчётах есть ошибки истечения или несовпадения имени — исправляйте сертификат до перехода в строгий режим. Ошибки скачивания политики — проверяйте доступность поддомена mta-sts и его сертификат. Если ошибок нет, а успешных сессий много, — политика работает, можно переходить в enforce.

Где разместить файл политики

Файл политики — маленький статический текст, и разместить его можно где угодно, лишь бы по HTTPS с действительным сертификатом на имя mta-sts.company.ru. Варианты: тот же веб-сервер, что отдаёт веб-почту, если на нём можно добавить виртуальный хост; отдельный статический хостинг; веб-сервер сайта компании. Важно, чтобы этот веб-сервер не был единой точкой отказа для почты: если файл политики недоступен, отправители используют закэшированную версию до истечения max_age, поэтому короткая недоступность не страшна.

Несколько доменов

Если у компании несколько почтовых доменов, политика нужна для каждого: своя запись _mta-sts и свой поддомен mta-sts в каждом домене. Чтобы не обслуживать десятки одинаковых файлов, поддомены mta-sts всех доменов можно направить записью CNAME на один веб-сервер, который отдаёт политику для любого имени — сертификат при этом должен покрывать все имена. Отчёты TLS-RPT удобно собирать в один ящик.

Шаг 4. Переход в enforce

Когда отчёты чистые, смените в файле политики mode на enforce, увеличьте max_age и обновите id в DNS-записи. С этого момента отправители, поддерживающие MTA-STS, не доставят ваши письма без шифрования и правильного сертификата. Если ваш сертификат когда-нибудь истечёт, входящая почта от этих отправителей остановится — поэтому мониторинг срока сертификата становится обязательным.

Проверка

Проверьте каждую часть отдельно: запись в DNS, доступность политики по HTTPS, запись TLS-RPT и сертификат почтового сервера при STARTTLS.

dig +short TXT _mta-sts.company.ru
curl -s https://mta-sts.company.ru/.well-known/mta-sts.txt
dig +short TXT _smtp._tls.company.ru
openssl s_client -starttls smtp -connect mail.company.ru:25 -servername mail.company.ru </dev/null | grep -E "subject|issuer|Verify return code"

В выводе openssl должна быть строка с успешной проверкой цепочки сертификата и правильное имя сервера. Отдельно отправьте письмо с внешнего крупного сервиса и посмотрите в заголовках, что соединение было с TLS.

Сертификаты: автоматическое продление и мониторинг

В строгом режиме MTA-STS сертификат почтового сервера становится критической деталью: его истечение останавливает входящую почту от крупных отправителей. Поэтому сертификат должен продлеваться автоматически, а продление — проверяться. Используйте ACME-клиент с автоматическим обновлением, после обновления перезапускайте почтовые службы, чтобы они подхватили новый сертификат, и настройте оповещение, если до истечения осталось меньше двух недель.

Частая ловушка — сертификат обновился на диске, а Postfix и Dovecot продолжают отдавать старый, пока их не перезапустят. Проверяйте не файл, а то, что реально отдаёт сервер, — командой openssl из раздела проверки.

Облако против своего сервера в вопросе шифрования

В облачной почте политика шифрования, сертификаты и отчёты — внутреннее дело провайдера. Вы не видите, сколько писем к вам пришло без шифрования, и не можете потребовать от отправителей большего. На своём сервере это видно в отчётах TLS-RPT и управляется одной строкой в политике. Это хороший пример того, что свой сервер — не только про доступность, но и про контроль над тем, как именно ходит ваша переписка.

Резервный MX и MTA-STS

Если у домена есть резервный MX, он обязан быть в списке mx политики и иметь собственный действительный сертификат на своё имя. Иначе в строгом режиме отправители откажутся доставлять на него письма, и резервный сервер станет бесполезен именно тогда, когда основной недоступен. Проверьте резервный MX той же командой openssl, что и основной, и включите его сертификат в мониторинг. Об устройстве резерва — в статье о резервном MX и второй площадке.

Что увидят отправители

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

MTA-STS в mailcow и других сборках

В mailcow поддержка MTA-STS встроена: политика отдаётся встроенным веб-сервером, нужно опубликовать DNS-записи и проверить, что файл отдаётся. После обновлений стоит перепроверять — мы разбирали случай, когда политика пропала после обновления, в статье «mailcow: MTA-STS пропал после обновления». В iRedMail, Carbonio и голом Postfix файл политики публикуется любым веб-сервером на поддомене mta-sts.

MTA-STS для исходящей почты

MTA-STS защищает входящую почту вашего домена. Чтобы ваш сервер тоже уважал политики получателей при отправке, ему нужна поддержка проверки MTA-STS — в Postfix это делается внешним сервисом политики, который Postfix спрашивает перед доставкой. Это дополнительная настройка, но она закрывает и обратное направление: ваши письма контрагентам не уйдут открытым текстом, если они опубликовали политику.

MTA-STS или DANE

Альтернатива — DANE: отпечаток сертификата публикуется в DNS записью TLSA, а подлинность гарантирует DNSSEC. DANE строже и не требует веб-сервера, но требует DNSSEC для зоны домена, который поддерживают не все регистраторы и DNS-провайдеры. MTA-STS проще внедрить и шире поддерживается крупными сервисами. Можно включить оба: отправители, поддерживающие DANE, используют его, остальные — MTA-STS.

План внедрения по дням

Реалистичный порядок для компании с одним доменом.

• день 1: проверить сертификат почтового сервера и его автопродление, поднять mta-sts с сертификатом
• день 1: опубликовать политику в режиме testing и записи _mta-sts и _smtp._tls
• дни 2–14: собирать и читать отчёты TLS-RPT, исправлять найденное
• день 15: перевести в enforce, увеличить max_age, обновить id
• постоянно: мониторинг срока сертификатов почтового сервера и поддомена mta-sts

Типичные ошибки

Все они приводят либо к отсутствию защиты, либо к потере входящей почты.

• сразу включили enforce без тестового периода — часть писем перестала приходить из-за проблем с сертификатом
• сертификат почтового сервера на другое имя, чем в MX
• поменяли файл политики, но не обновили id — отправители используют старую политику
• нет сертификата на поддомене mta-sts — политика не скачивается
• забыли добавить резервный MX в список mx
• сертификат истёк — в режиме enforce входящая почта встала

Место MTA-STS в защите почты

MTA-STS — часть общего набора, который делает свой почтовый сервер надёжнее облачного: SPF, DKIM и DMARC защищают от подделки отправителя, MTA-STS — от перехвата в пути, защита от перебора и лимиты — от взлома ящиков. Подробнее о доставляемости — в статье о доставляемости почты после переезда, о базовой защите — в статье о безопасности почтового сервера в первый день, о DMARC — в статье о DMARC и BIMI.

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