Перейти к содержимому
IPeek

Проверка MTA-STS

Принудительная политика TLS для входящей почты

Проверка…

Что такое MTA-STS?

MTA-STS позволяет домену требовать, чтобы входящая почта доставлялась через аутентифицированный TLS, защищая от атак понижения и «человек посередине». IPeek читает TXT-запись _mta-sts и загружает файл политики, опубликованный по адресу mta-sts.your-domain. Он закрывает пробел, оставляемый оппортунистическим STARTTLS, который злоумышленник может незаметно вырезать.

Как MTA-STS публикует и обеспечивает политику

MTA-STS состоит из двух частей. TXT-запись по адресу _mta-sts.your-domain содержит версию и идентификатор политики, которые сообщают отправляющим серверам, что политика существует, и меняются при её обновлении. Сама политика находится в текстовом файле, отдаваемом по HTTPS по адресу https://mta-sts.your-domain/.well-known/mta-sts.txt. Этот файл перечисляет версию, режим, разрешённые имена хостов MX и время жизни кэша max_age. Отправитель, поддерживающий MTA-STS, загружает и кэширует политику, а затем отказывается доставлять любому MX, чей сертификат не проходит проверку по ней.

Как читать результаты MTA-STS

IPeek показывает, существует ли TXT-запись _mta-sts и доступен ли файл политики по HTTPS. Важнее всего значение режима. none означает, что политика не действует, testing — что о сбоях сообщается, но почта всё равно доставляется, а enforce — что отправитель обязан прервать доставку при сбое аутентификации TLS. Проверьте, что записи mx в политике совпадают с вашими реальными MX-записями и что HTTPS-сертификат на хосте политики валиден. Высокий max_age, часто 604800 секунд, улучшает защиту, потому что кэшированные политики устойчивы к подмене в реальном времени.

Частые проблемы MTA-STS и их устранение

Самая частая ошибка — TXT-запись существует, а файл политики возвращает 404 или редирект, что делает политику непригодной. Хост политики обязан отдавать валидный HTTPS, так что просроченный или несоответствующий сертификат на mta-sts.your-domain полностью ломает обеспечение. Записи MX, рассинхронизированные с вашим DNS, вызывают сбои доставки после перехода на enforce. Сначала разверните в режиме testing, отслеживайте отчёты TLS-RPT на предмет сбоев и переходите на enforce только после того, как убедитесь, что каждый MX предъявляет валидный соответствующий сертификат.

Часто задаваемые вопросы

В чём разница между режимами testing и enforce в MTA-STS?

В режиме testing отправители, обнаружившие сбой TLS, всё равно доставляют почту, но сообщают о проблеме, позволяя вам найти неполадки, не блокируя трафик. В режиме enforce отправитель обязан прервать доставку любому MX, чей сертификат не проходит проверку. Начните с testing, следите за отчётами TLS-RPT и переходите на enforce только когда сбоев больше не появляется.

Где находится файл политики MTA-STS?

Файл политики отдаётся по HTTPS по адресу https://mta-sts.your-domain/.well-known/mta-sts.txt, на поддомене с именем mta-sts. DNS-запись TXT по адресу _mta-sts.your-domain лишь объявляет, что политика существует, и несёт идентификатор; сами правила, включая режим и разрешённые хосты MX, находятся в этом HTTPS-файле. Для работы MTA-STS оба должны присутствовать и быть валидными.

Чем MTA-STS отличается от STARTTLS?

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

Требует ли MTA-STS DNSSEC?

Нет. MTA-STS намеренно полагается на HTTPS и веб-PKI для доверия, а не на DNSSEC, что делает его проще в развёртывании, чем DANE. Аутентификацию обеспечивает HTTPS-сертификат файла политики. Если на вашем домене уже есть DNSSEC, можно запускать DANE параллельно с MTA-STS, поскольку эти два механизма дополняют, а не конфликтуют друг с другом.

Как безопасно развернуть MTA-STS?

Сначала опубликуйте TXT-запись и файл политики в режиме testing, затем включите TLS-RPT, чтобы отправляющие серверы присылали вам отчёты о любых сбоях TLS. Убедитесь, что имена хостов MX в политике совпадают с DNS и что каждый MX предъявляет валидный сертификат. Когда отчёты не покажут сбоев за обычный цикл отчётности, смените режим на enforce и обновите идентификатор политики.