MTA-STSのススメ (TLSレポート編)
MTA-STSとは
詳しくは、こちらを参照ください。
簡単にいうと、メールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのもので、受信側が、送信サーバーに対して
- STARTTLSを必ず使う%
- TLS1.2以上を必ず使う
- 証明書が有効でなければ配送しない
ようにしてもらうことを、お願いする仕組みです。
TLSレポートとは
MTA-STSが成功した、失敗した、という情報をレポート形式で送ってもらう仕組みです。
MTA-STSのmodeがnone以外の時にレポートが作成されます。
MTA-STSが、と書きましたが、DANEでもレポートを送ってくれるそうなのですが、残念ながら、こちらはまだレポートを手に入れられていません。
設定方法
DNSにレポートの送り先を設定します。
メールで送ってもらう場合
example.jpのレポートをhirano@example.comに送る場合、次のように書きます。
_smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=mailto:hirano@example.com"
レポートの送り先は複数書けますが、DMARCレポートと同じように、mailto:をそれぞれに書くのを忘れないようにしてください。
_smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=mailto:hirano@example.com,mailto:admin@example.com"
別ドメインへのレポート送信
DMARCのレポートでは別ドメインへレポートを送信する場合には、レポートを受け取るドメイン側でexample.jp._report._dmarc.example.comのようなDMARCレコードが必要ですが、MTA-STSでは必要ありません。
HTTPSで送りつけてもらう場合
example.jpのレポートをhttps://example.jp/reportにアップロードする例です。
_smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=https://example.jp/report"
実は、まだ試したことがないので、どの程度のプロバイダーが対応しているかは不明です。
レポート内容
レポートはメールの場合、JSON形式を圧縮したファイルを添付として送られます。
レポートは基本的にはUTCの00:00～24:00までの24時間単位で、集計と同時ではなく、集計後4時間以内のランダムなタイミングで送信されます。
問題がない場合
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2020-09-07T00:00:00Z",
"end-datetime": "2020-09-07T23:59:59Z"
},
"contact-info": "smtp-tls-reporting@google.com",
"report-id": "2020-09-07T00:00:00Z_hirano.cc",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"max_age: 86400",
"mx: *.hirano.cc"
],
"policy-domain": "hirano.cc"
},
"summary": {
"total-successful-session-count": 5,
"total-failure-session-count": 0
}
}
]
}
organization-nameはレポートの作成者、date-rangeはレポートがいつからいつまでのものか、contact-infoはレポートに関する連絡先、report-idはレポート毎の固有のIDです。
policiesはリストになっていますが、これは、MTA-STSとDANEのレポートを同時に表現するためで、MTA-STSだけ設定した場合は、policiesのリストには1つの要素しかありません。
policyには、Webで広告したポリシーがそのまま記載されます。
summaryには成功したセッション数と、失敗したセッション数がそれぞれ書かれます。この場合、5セッション成功して、失敗はなかったということになります。
DMARCレポートとは違ってシンプルでわかりやすい構造になっています。
問題がある場合
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2019-10-01T00:00:00Z",
"end-datetime": "2019-10-01T23:59:59Z"
},
"contact-info": "smtp-tls-reporting@google.com",
"report-id": "2019-10-01T00:00:00Z_hirano.cc",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"max_age: 86400",
"mx: *.hirano.cc"
],
"policy-domain": "hirano.cc"
},
"summary": {
"total-successful-session-count": 0,
"total-failure-session-count": 55
},
"failure-details": [
{
"result-type": "validation-failure",
"sending-mta-ip": "209.85.219.198",
"receiving-ip": "210.158.71.76",
"receiving-mx-hostname": "ah.hirano.cc",
"failed-session-count": 2
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.222.201",
"receiving-ip": "210.158.71.76",
"receiving-mx-hostname": "ah.hirano.cc",
"failed-session-count": 1
},
.... 省略 ....
]
}
]
}
失敗した場合は、失敗の情報がfailure-detailsに記載されます。
たくさんあるので、後ろは省略しましたが、上記の場合、validation-failureが2セッション、starttls-not-supportedが1セッションあったことがわかります。
失敗内容には以下のようなものがあります。
- starttls-not-supported
- 受信サーバーがSTARTTLSに対応していない
- certificate-host-mismatch
- 証明書のSANの値とホスト名が一致しない
- certificate-expired
- 証明書の有効期限切れ
- certificate-not-trusted
- 認証局が不正、トラストチェーンがRoot CAまでつながらない、など
- validation-failure
- その他の失敗
おわりに
MTA-STSを設定したら、TLS-RPTもぜひ同時に設定してください。
MTA-STSのmodeをtestingにして、レポートを読むことで、自分のサーバーの設定ミスがわかったりもします。
自信が付いたら、MTA-STSのmodeをenforceにしましょう。
参考資料
RFC8460 SMTP TLS Reporting
MTA-STSのススメ
送信ドメイン認証・暗号化 Deep Dive! (自分の発表資料ですが・・・)