Генератор MTA-STS

Что нужно сделать помимо записи

1. Поднять поддомен mta-sts.ваш-домен и получить для него сертификат.
2. Выложить файл политики по пути /.well-known/mta-sts.txt с типом text/plain.
3. Опубликовать TXT-запись на имя _mta-sts.
4. Настроить TLS-RPT, чтобы видеть отчёты о неудачных попытках соединения.

Список MX должен совпадать

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

От чего это защищает

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

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

Три режима и порядок внедрения

• none — политики фактически нет. Значение нужно, чтобы корректно отключить ранее опубликованную политику: просто удалить файл нельзя, отправители будут помнить прежнюю до истечения max_age.
• testing — отправитель проверяет политику, но при несовпадении всё равно доставляет письмо и присылает отчёт. Режим, с которого начинают всегда.
• enforce — при несовпадении доставка отменяется.

Разумный порядок: сначала TLS-RPT, затем testing с небольшим max_age — сутки-двое. Неделю смотрите отчёты: в них видно, все ли ваши MX проходят проверку и не забыт ли какой-нибудь резервный сервер. Только когда неделя проходит без сбоев, переключайте на enforce и поднимайте max_age до нескольких недель.

Большой max_age — это палка о двух концах. Он защищает от подмены политики, но и означает, что ошибку отправители будут помнить ровно столько же. Пока конфигурация не устоялась, держите значение небольшим.

Где это ломается

• Файл отдаётся не как text/plain. Сервер добавляет text/html или страницу-обёртку, политика считается нечитаемой. Проверяется одной командой curl -I.
• Сертификат на mta-sts.example.com просрочен. Поддомен с политикой живёт отдельно от основного сайта, и про его автопродление забывают. Политика становится недоступна, а в режиме enforce отправители продолжают требовать TLS по прежней, закешированной.
• Значение id в TXT-записи не изменили. Отправители перечитывают файл, только когда меняется id. Правка политики без обновления идентификатора не даёт эффекта неделями.
• Редирект на www. Политика обязана отдаваться по точному адресу https://mta-sts.example.com/.well-known/mta-sts.txt без перенаправлений.

MTA-STS и DANE

Обе технологии решают одну задачу, но по-разному. DANE публикует отпечаток сертификата в DNS и требует работающего DNSSEC, надёжнее, но DNSSEC поднят далеко не у всех. MTA-STS обходится обычным DNS и https-сертификатом, поэтому внедряется почти везде и почти сразу.

Они не конфликтуют: если настроены обе, отправитель, умеющий DANE, воспользуется им, остальные политикой MTA-STS. Крупные почтовые системы обычно держат обе. Начинать логично с MTA-STS: порог входа ниже, а закрывает он тот же основной сценарий.