MTA-STS: что это, зачем нужен TLS-RPT и стоит ли включать

MTA-STS (RFC 8461) позволяет домену сказать отправляющим почтовым серверам: «доставляйте мне почту только по TLS, только с действительным сертификатом и только на эти MX-хосты». Без него шифрование между почтовыми серверами остаётся оппортунистическим, и любой, кто находится на пути письма, может его отключить. Механизм состоит из одной TXT-записи, одного небольшого текстового файла, который отдаётся по HTTPS, и в идеале второй TXT-записи (TLS-RPT, RFC 8460), благодаря которой вы будете ежедневно получать отчёты о том, с чем столкнулись отправители. Если почта размещена у крупного провайдера, всё это стоит одного вечера; если по почте вам приходит что-то конфиденциальное, оно того стоит.

Проблема: STARTTLS работает по возможности

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

Понижение. Злоумышленник на пути может удалить строку STARTTLS из ответа сервера. Отправитель решает, что TLS не предлагается, и доставляет письмо открытым текстом.
Отсутствие аутентификации. Отправители, как правило, не проверяют предъявленный сертификат: десятилетиями у множества почтовых серверов стояли самоподписанные или не соответствующие имени сертификаты. Тот, кто способен подменить ответ на ваш MX-запрос или перехватить соединение, может показать какой угодно сертификат.

Три составляющие

1. TXT-запись `_mta-sts`

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260921000000"

id — произвольная строка длиной до 32 букв и цифр. Её единственная задача — меняться при каждом изменении политики, чтобы отправители понимали, что файл нужно скачать заново.

2. Файл политики

Отдаётся по фиксированному URL на фиксированном имени хоста mta-sts:

$ curl https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mx1.mail.example.net
mx: mx2.mail.example.net
max_age: 86400

Поле	Значение
`version`	Всегда `STSv1`
`mode`	`enforce`, `testing` или `none`
`mx`	По одной строке на каждый разрешённый MX-хост. Допускается шаблон вида `*.mail.example.net`, он соответствует ровно одной крайней левой метке
`max_age`	Сколько секунд отправители могут кэшировать политику. Максимум 31557600 (около года)

HTTPS-сервер обязан предъявлять публично доверенный сертификат, действительный для mta-sts.example.com. При получении политики отправители не следуют HTTP-редиректам, поэтому файл должен отдаваться именно по этому URL.

3. MX-хосты, которые проходят проверку

Каждый перечисленный хост должен предлагать STARTTLS с сертификатом, срок действия которого не истёк, который выстраивается в цепочку до доверенного отправителем удостоверяющего центра и совпадает с именем MX-хоста.

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -enddate -ext subjectAltName

Если сертификат на вашем собственном MX уже истёк, сначала исправьте это: продление разобрано в статье истёк SSL-сертификат: что делать.

Как отправитель применяет политику

Перед доставкой на example.com отправитель запрашивает _mta-sts.example.com.
Если у него нет кэшированной политики или id отличается от сохранённого, он скачивает файл политики по HTTPS.
Политика кэшируется на max_age секунд.
Отправитель как обычно разрешает MX-записи, отбрасывает хосты, не совпадающие ни с одной строкой mx:, и требует действительный TLS от оставшихся.

Что происходит при сбое, зависит от режима:

Режим	При ошибке TLS или несовпадении MX
`testing`	Письмо всё равно доставляется, а сбой попадает в отчёт TLS-RPT
`enforce`	Отправитель не доставляет письмо на проблемный хост. Если не проходит ни один хост, письмо ставится в очередь, повторяется и в конце концов возвращается отправителю
`none`	Домен объявляет, что активной политики у него нет. Используется для отзыва

Именно кэш делает MTA-STS сильным. Злоумышленник, который сегодня блокирует запрос TXT-записи или скачивание по HTTPS, не заставит отправителя забыть политику, закэшированную на прошлой неделе. Слабое место — самое первое обращение, пока в кэше ещё ничего нет.

TLS-RPT: узнайте, что видят отправители

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

В rua указывается адрес mailto: или URI https:. Участвующие отправители присылают по одному сводному отчёту в JSON в день: сколько сессий с вашим доменом прошло успешно, сколько завершилось ошибкой и почему (истёкший сертификат, несовпадение имени хоста, STARTTLS не предложен, MX отсутствует в политике). Отчёты охватывают и MTA-STS, и DANE. Без них режим testing ничего не тестирует: результат вам просто никто не сообщает.

Порядок внедрения

Убедитесь, что у каждого MX-хоста есть действительный, совпадающий с именем и публично доверенный сертификат (команда выше).
Сначала опубликуйте запись TLS-RPT и дождитесь первых отчётов.
Разместите файл политики с mode: testing и коротким max_age, например 86400.
Опубликуйте TXT-запись _mta-sts.
Несколько недель читайте отчёты. Ищите сбои у легитимных отправителей и MX-хосты, которых нет в политике.
Переключитесь на mode: enforce, измените id и в первые дни держите max_age коротким.
Когда всё успокоится, поднимите max_age до нескольких недель.
Поставьте сертификат хоста mta-sts и сертификаты MX на мониторинг срока действия.

Посмотреть опубликованную запись _mta-sts и политику домена можно в проверке MTA-STS, а запись отчётности — в проверке TLS-RPT.

Почта у провайдера

Если MX-записи указывают на почтового провайдера, сертификаты — его забота, и у крупных провайдеров они в порядке. Ваша часть работы:

Перечислите MX-имена провайдера в политике ровно так, как они выглядят в ваших MX-записях, либо в виде шаблона, который провайдер описывает в документации.
Файл политики разместите сами на mta-sts.example.com. Достаточно хостинга статических страниц.

Смена почтового провайдера

Как только вы работаете в режиме enforce, порядок действий становится важен. У отправителей в кэше лежит политика, в которой перечислены только старые MX-хосты. Если сначала поменять MX-записи, эти отправители увидят новые хосты, которых политика не разрешает, и откажутся доставлять почту.

Добавьте MX-имена нового провайдера в файл политики (старые оставьте) и измените id.
Дайте отправителям время заметить новый id и скачать политику заново; несколько дней — осторожный запас.
Переключите MX-записи.
Позже уберите старые имена из политики и снова измените id.

По той же причине не стоит рано переходить на годовой max_age.

Отзыв политики

Удалить TXT-запись и файл — не значит отозвать политику. Отправители с закэшированной политикой enforce продолжат её применять, пока кэш не истечёт. Правильный путь: опубликовать mode: none с новым id, оставить и запись, и файл на месте, пока не пройдёт предыдущий max_age целиком, и только потом удалить их.

MTA-STS и DANE

DANE для SMTP (RFC 7672) решает ту же задачу иначе: сертификат или ключ MX-хоста закрепляется в записи TLSA, а этой записи доверяют потому, что зона подписана DNSSEC.

	MTA-STS	DANE для SMTP
Якорь доверия	Web PKI (публичные удостоверяющие центры) плюс HTTPS	Цепочка DNSSEC
Нужен DNSSEC	Нет	Да: TLSA-записи MX-хостов должны находиться в подписанной зоне
Слабость первого контакта	Есть, пока политика не закэширована	Нет

Они могут сосуществовать, и TLS-RPT сообщает об обоих. При почте у провайдера DANE зависит от того, подписывает ли провайдер свою MX-зону; MTA-STS полностью в ваших руках. Подробнее в статье что такое DNSSEC.

Чего MTA-STS не делает

Он защищает только входящую почту вашего домена. Исходящую защищают политики получателей, если ваш отправляющий сервер соблюдает MTA-STS.
Он работает только с теми отправителями, которые его реализовали. Остальные по-прежнему доставляют почту по возможности.
Это шифрование транспорта между соседними узлами, а не сквозное. Письмо читаемо на каждом сервере, через который проходит.
Он ничего не говорит о спаме, подделке отправителя и аутентификации. Это задача SPF, DKIM и DMARC: см. MX, SPF, DKIM и DMARC: как они работают вместе.

Нужен ли он вам

Домен на крупном почтовом хостинге: низкие затраты, низкий риск. Сертификаты провайдер поддерживает сам; вы добавляете две TXT-записи и статический файл.
Домен, на который приходит конфиденциальная почта (договоры, медицина, финансы, сброс паролей): имеет смысл даже с собственным MX, при условии, что вы следите за сертификатами.
Не готовы брать обязательства: режим testing плюс TLS-RPT не создаёт риска для доставки и показывает, навредил бы вам enforce или нет.

Частые ошибки

Сразу включить enforce без TLS-RPT и узнавать о сбоях от людей, чьи письма вернулись.
Отредактировать файл политики и не поменять id. Отправители держатся за старую политику, пока не истечёт max_age.
Написать в строке mx: сам домен (example.com) вместо имён MX-хостов.
Файл политики, доступный только через редирект или под сертификатом, который не покрывает mta-sts.example.com.
Дать истечь сертификату хоста mta-sts: новые отправители больше не смогут получить политику.
Переключить MX-записи раньше, чем обновлена политика, или удалить всё разом, чтобы «выключить».

Проверьте в OrbitProbe

Начните с проверки MX-записей в OrbitProbe: она показывает MX-хосты домена с их приоритетами, а вместе с ними записи SPF и DMARC. Имена хостов в её выдаче — это ровно то, чему должны соответствовать ваши строки mx:, символ в символ, так что запустите её перед написанием политики и ещё раз после любой смены почтового провайдера. DNS-запрос показывает, что опубликовано сейчас; смогли ли отправители на самом деле договориться о TLS, узнаётся из отчётов TLS-RPT, поэтому после перехода на enforce продолжайте их читать.