MTA-STS: как защитить email от downgrade-атак

SMTP придумали в 1982 году. Шифрование прикрутили позже через STARTTLS, и это оппортунистическое улучшение любой посредник может по дороге срезать. MTA-STS чинит это, объявляя всему миру: «Мой почтовый сервер требует TLS. Не можете установить шифрованное соединение, не доставляйте письмо вовсе». Ниже разбор протокола, его частей в DNS и в HTTPS, и порядок настройки.

Проблема: STARTTLS не гарантирует шифрование

SMTP изначально передаёт почту открытым текстом. STARTTLS добавляет шифрование, но оппортунистически: если принимающий сервер объявляет поддержку, соединение шифруется, если нет, письмо уходит без шифрования. Атакующий в позиции man-in-the-middle может вырезать строку 250 STARTTLS из ответа сервера. Отправляющая сторона решит, что TLS не поддерживается, и передаст содержимое в открытом виде. Это downgrade-атака.

DANE решает эту задачу через DNSSEC и TLSA-записи. Но DNSSEC подписано менее 5% доменов в зоне .com (данные APNIC на конец 2025). MTA-STS предлагает другой путь: политика TLS публикуется через HTTPS, а подлинность гарантируется сертификатом веб-сервера. Инфраструктура HTTPS есть у всех, отдельная подпись зоны DNS не нужна.

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

MTA-STS описан в RFC 8461. Протокол состоит из двух частей: DNS-запись _mta-sts сигнализирует о наличии политики, а файл на https://mta-sts.домен/.well-known/mta-sts.txt содержит саму политику.

Последовательность при доставке:

1. Отправитель резолвит MX-записи домена получателя.
2. Запрашивает TXT-запись _mta-sts.example.com.
3. Если запись найдена, загружает файл политики по HTTPS.
4. Кеширует политику на время max_age.
5. При каждой последующей доставке проверяет: TLS-соединение установлено, сертификат валиден, имя хоста MX совпадает с паттернами в политике. Если проверка не пройдена и режим enforce письмо не доставляется.

Безопасность строится на том, что подделать TLS-сертификат для поддомена mta-sts.example.com несопоставимо сложнее, чем подменить DNS-ответ.

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

Текстовый файл с четырьмя полями. Размещается по фиксированному пути:

version: STSv1
mode: testing
mx: mail.example.com
mx: backup-mx.example.com
max_age: 86400

Режимы:

• testing означает, что отправители доставляют письмо даже при ошибке TLS, но отправляют TLS-RPT отчёт. Используйте на старте.
• enforce это строгий режим. Нет TLS, нет доставки. Переходите сюда после анализа отчётов.
• none отключает политику. Используется при выводе из эксплуатации.

Значение max_age определяет время кеширования. 86400 секунд (сутки) разумное начальное значение. После перехода в enforce увеличьте до 604800 (неделя) или выше. Чем дольше кеш, тем дольше отправители будут требовать TLS, даже если ваш HTTPS-сервер с политикой временно упадёт.

Шаг 2. Веб-сервер для раздачи политики

Нужен поддомен mta-sts.example.com с валидным TLS-сертификатом. Самоподписанные сертификаты не подходят, отправляющие серверы проверяют цепочку доверия.

Конфигурация Nginx:

server {
    listen 443 ssl;
    server_name mta-sts.example.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        root /var/www/mta-sts;
        default_type text/plain;
    }

    location / {
        return 404;
    }
}

Альтернатива для тех, кто не хочет держать отдельный сервер: разместить файл на GitHub Pages или Cloudflare Pages. Создайте репозиторий, положите файл в .well-known/mta-sts.txt, привяжите кастомный домен mta-sts.example.com. HTTPS обеспечит платформа.

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

Две записи: A/CNAME для поддомена и TXT для сигнала.

# A-запись для веб-сервера с политикой
mta-sts.example.com.  IN  A  203.0.113.10

# TXT-запись — сигнал отправителям
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260427001"

Поле id меняется при каждом обновлении политики. Отправитель сравнивает id из DNS с кешированным значением. Если не совпадает, перезагружает файл политики. Формат произвольный; дата с порядковым номером удобная практика.

Шаг 4. TLS-RPT: отчёты о проблемах

Без TLS-RPT (RFC 8460) вы не узнаете, блокируется ли легитимная почта из-за ошибок TLS. Добавьте запись:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Google, Microsoft, Yahoo и другие крупные отправители поддерживают TLS-RPT и будут присылать ежедневные отчёты в формате JSON. Отчёт содержит количество успешных и неуспешных TLS-сессий, типы ошибок и IP-адреса отправителей.

Отдельный ящик для отчётов хорошая практика. Объём невелик (десятки писем в день для домена со средним трафиком), но смешивать с рабочей почтой неудобно. Для автоматического парсинга можно использовать tlsrpt-processor или написать скрипт, который распаковывает .gz и собирает метрики.

Скрипт проверки MTA-STS

Bash-скрипт, который проверяет все компоненты MTA-STS за один запуск:

#!/bin/bash
DOMAIN=${1:?"Usage: $0 domain.com"}

echo "=== MTA-STS check for $DOMAIN ==="
echo ""

# DNS TXT record
echo "[1] _mta-sts.$DOMAIN TXT record:"
dig TXT "_mta-sts.$DOMAIN" +short
echo ""

# Policy file
POLICY_URL="https://mta-sts.$DOMAIN/.well-known/mta-sts.txt"
echo "[2] Policy file ($POLICY_URL):"
HTTP_CODE=$(curl -sS -o /tmp/mta-sts-policy.txt -w "%{http_code}" "$POLICY_URL")
if [ "$HTTP_CODE" = "200" ]; then
    cat /tmp/mta-sts-policy.txt
else
    echo "FAIL: HTTP $HTTP_CODE"
fi
echo ""

# TLS on MX hosts
echo "[3] MX records and TLS check:"
MX_HOSTS=$(dig MX "$DOMAIN" +short | awk '{print $2}' | sed 's/\.$//')
for MX in $MX_HOSTS; do
    CERT_CN=$(openssl s_client -connect "$MX:25" -starttls smtp \
        -servername "$MX" < /dev/null 2>/dev/null | \
        openssl x509 -noout -subject 2>/dev/null)
    if [ -n "$CERT_CN" ]; then
        echo "  $MX — TLS OK ($CERT_CN)"
    else
        echo "  $MX — TLS FAIL"
    fi
done
echo ""

# TLS-RPT
echo "[4] _smtp._tls.$DOMAIN TXT record:"
dig TXT "_smtp._tls.$DOMAIN" +short

Запуск:

chmod +x check-mta-sts.sh
./check-mta-sts.sh example.com

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

• MX-хост не совпадает с паттерном в политике. MX-запись указывает на mx1.mailprovider.com, а в политике прописан *.example.com. Сертификат MX-хоста тоже не содержит example.com. Результат: в режиме enforce почта не доставляется. Решение: в поле mx укажите хостнеймы из MX-записей, а не свой домен.
• Просроченный сертификат на mta-sts поддомене. Let’s Encrypt-сертификат не продлился автоматически. Отправители не могут загрузить политику. Пока кеш не истёк, используется старая политика. После истечения max_age защита пропадает. Настройте мониторинг сертификата.
• Забыли обновить id в DNS. Изменили файл политики, но не изменили id в TXT-записи. Отправители не знают, что политика обновилась, и продолжают использовать кеш.
• Режим enforce без тестирования. Включили enforce сразу, не проанализировав TLS-RPT отчёты. Выяснилось, что один из MX-серверов возвращает сертификат без нужного SAN. Часть почты заблокирована. Всегда начинайте с mode: testing.
• CNAME вместо A-записи для mta-sts поддомена, указывающий на домен без HTTPS. CNAME на example.github.io допустим. CNAME на IP-адрес нет (CNAME не может указывать на IP). Убедитесь, что целевой хост отдаёт сертификат для mta-sts.example.com.

MTA-STS на стороне отправителя: Postfix

MTA-STS защищает входящую почту. Но если вы управляете собственным почтовым сервером, стоит также включить проверку MTA-STS при отправке. Postfix не поддерживает MTA-STS из коробки, но есть плагин postfix-mta-sts-resolver (пакет в PyPI).

# Установка
pip install postfix-mta-sts-resolver

# Конфигурация /etc/mta-sts-daemon.yml
host: 127.0.0.1
port: 8461
cache:
  type: sqlite
  options:
    filename: /var/cache/mta-sts/cache.db

# Добавить в /etc/postfix/main.cf
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix

# Перезапуск
systemctl restart mta-sts-daemon
systemctl reload postfix

После этого Postfix будет запрашивать MTA-STS-политику для каждого домена-получателя и применять её при доставке. Если принимающий домен опубликовал mode: enforce, Postfix откажется отправлять без TLS.

MTA-STS в связке с SPF, DKIM, DMARC

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

Полный стек email-безопасности выглядит так: SPF + DKIM + DMARC (аутентификация) + MTA-STS (шифрование транспорта) + BIMI (визуальная идентификация). Каждый слой закрывает свой вектор атаки. MTA-STS единственный из них, который защищает от прослушивания трафика между серверами.

Подробнее о настройке аутентификации расскажет пошаговая инструкция по SPF, DKIM и DMARC. О визуальном слое есть руководство по BIMI.

Кому и когда внедрять MTA-STS

Если ваш домен принимает почту, MTA-STS полезен. Он защищает входящие письма от перехвата. Настройка занимает 20-40 минут: файл, DNS-запись, веб-сервер. Поддерживать почти нечего, разве что продление сертификата, которое автоматизируется через certbot.

Для компаний в финансовом секторе, здравоохранении и других регулируемых отраслях MTA-STS не опция, а требование. PCI DSS 4.0 прямо указывает на необходимость шифрования email-трафика при передаче конфиденциальных данных.

Google Workspace и Microsoft 365 уже публикуют MTA-STS для клиентских доменов (при включении в админ-панели). Если вы используете одну из этих платформ, проверьте настройки, возможно, осталось только создать DNS-записи.