Приёмник объявляет требование шифрования на своём сайте

MTA-STS
Политика приёмника, забранная по HTTPS

Механизм в двух шагах: узел спрашивает у DNS идентификатор политики, затем забирает саму политику по HTTPS с mta-sts.<домен>/.well-known/mta-sts.txt.

Если политика в режиме принуждения, письмо уйдёт только при трёх условиях сразу: адрес приёмника совпал хотя бы с одним образцом MX из политики; соединение зашифровано; узел проверил и цепочку сертификата, и имя сервера в нём.

Режим testing ничего не запрещает — узел доставит письмо и при несовпадении MX. Это важно при разборе: политика есть, а поведение обычное, потому что приёмник ещё не включил принуждение.

Сертификаты проверяются по списку из поставки — Mozilla CA, — и его можно заменить своим через smtp-tls-ca-file. Отзыв сертификатов узел не проверяет, а отчёты TLS (RFC 8460) не поддерживает вовсе.

Политика кэшируется на срок из неё самой и обновляется раз в сутки. То есть изменения у приёмника доходят до нас не мгновенно.

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

Главная ловушка — принять политику приёмника за работающую защиту, не посмотрев её режим. mode: testing встречается часто: домен публикует политику, чтобы посмотреть на отчёты, и ничего не требует. Включённая у нас строка на таком приёмнике ничего не меняет — и это нормально, а не поломка.
Что делает Хаб. Пишет yes во всех пятнадцати блоках шаблона политик, включая общий; у крупных приёмников — рядом с require-starttls, в общем блоке — без неё: там шифрование обязательно только для тех, кто объявил это политикой MTA-STS. Выбор осмысленный: MTA-STS, в отличие от DANE, ничего не требует от нашей инфраструктуры — ни DNSSEC, ни особого резолвера, — а проверку выполняет более строгую, чем просто обязательное шифрование: сверяются и цепочка, и имя в сертификате.
Рекомендуемые значения

Собственных значений у механизма нет: его включает use-mta-sts. Что стоит знать про поведение:

Режим политики приёмника Что делает узел
enforce доставит только при совпадении MX, шифровании и проверенном сертификате
testing доставит в любом случае — политика ничего не требует
политики нет доставит как обычно

Чего механизм не делает: не проверяет отзыв сертификатов и не шлёт отчёты TLS. На это опираться нельзя.

Три условия доставки, режимы политики, кэширование и правило про объединение очередей — из руководства (§ 10.6). Сравнение с DANE по требованиям к инфраструктуре — наше.
Пример в конфигурации
# у крупного приёмника — обязательное шифрование и проверка по политике
<domain hotmail.com>
    use-starttls yes
    require-starttls yes
    use-mta-sts yes</domain>
Строки дополняют друг друга: require-starttls требует шифрования всегда, MTA-STS добавляет проверку MX и сертификата — но только если приёмник опубликовал политику в режиме принуждения.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Считают включённую строку работающей проверкой

§ 10.6

Чем чреватоПроверка целиком зависит от политики приёмника. Нет политики или она в режиме testing — поведение обычное, и никакой дополнительной защиты нет.
Как заметитьНастройка включена, а в учёте ничего не изменилось.
Как правильноСмотреть политику приёмника командой из справки. Свою обязательность шифрования обеспечивает require-starttls, а не эта строка.

Забывают про взаимодействие с объединением очередей

§ 10.6

Чем чреватоПри принуждающей политике очереди объединяются, только если все объединяемые MX разрешены. Одно несовпадение — и объединения не будет вовсе, а расчёт нагрузки строился на нём.
Как заметитьОжидаемая объединённая очередь не появляется, письма идут отдельными очередями по доменам.
Как правильноСверять образцы MX из политики приёмника со списком объединения. Это не ошибка настройки, а описанное поведение.

Рассчитывают на проверку отзыва сертификата

§ 10.6

Чем чреватоУзел проверяет цепочку и имя, но не проверяет отзыв. Отозванный, но ещё не истёкший сертификат проверку пройдёт.
Как заметитьОбнаруживается при разборе требований, а не в работе.
Как правильноНе считать MTA-STS полной проверкой подлинности приёмника. Отзыв узел не смотрит, и отчётов TLS не шлёт.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у самого механизма нет — наследуется директива, которой он включается: use-mta-sts живёт в <domain> и сливается по обычному правилу блоков получателей, побеждает самое точное совпадение. Кэш политики при этом общий для узла и от блоков не зависит.
Как проверить на узле
Проверять начинают с политики самого приёмника — есть ли она и в каком режиме:
curl -s https://mta-sts.gmail.com/.well-known/mta-sts.txt
Строка mode: enforce означает, что проверка действительно работает; testing — что приёмник ничего не требует, и включённая у нас настройка ничего не изменит. Отсутствие ответа — политики нет.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Настроить темп под провайдера · Шифрование соединений