Шифровать там, где приёмник этого требует
Задача. Письма клиента не должны молча уходить открытым текстом, когда приёмник ждал шифрования. Поведение по умолчанию — зашифровать, если предложат, иначе отправить как есть и никому не сказать.
Из чего складывается:
- dane — принуждение для приёмников, публикующих подписанные записи с отпечатком сертификата;
- mta-sts — принуждение для приёмников, публикующих политику по HTTPS;
- require-starttls — грубый вариант: не понижать до открытого текста никогда.
Области у составляющих разные. Все три включаются на получателя. Для DANE нужен резолвер с поддержкой DNSSEC — это условие узла, и без него записям DANE доверять нельзя.
Как они взаимодействуют. Три части выстроены по тому, сколько требуют от приёмника. Отказ от понижения не требует ничего и не доставит почту никому, кто шифрования не предлагает. DANE и MTA-STS действуют только у тех, кто сам опубликовал требования, и при невыполненных условиях не отправляют письмо открытым текстом. Доверяют они разному — подписанному DNS и политике по HTTPS, — поэтому вместе покрывают больше приёмников. Чего схема не даёт — числа писем, ушедших открытым текстом туда, где ничего не требовали.
Три способа и что им нужно:
| Способ | Строка | Что требуется от приёмника | Условие на узле |
|---|---|---|---|
| DANE | use-dane | подписанные записи с отпечатком | резолвер с DNSSEC |
| MTA-STS | use-mta-sts | политика по HTTPS | — |
| без понижения | require-starttls | ничего | — |
<domain *> use-mta-sts yes use-dane yes</domain> <domain bank.example> require-starttls yes </domain>
pmta show settings gmail.com/vmta1 | grep -E '^(use-dane|use-mta-sts|require-starttls) '