Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
3
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

Organization

MTA-STSのススメ (TLSレポート編)

MTA-STSのススメ (TLSレポート編)

MTA-STSとは

詳しくは、こちらを参照ください。

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! (自分の発表資料ですが・・・)

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
3
Help us understand the problem. What are the problem?