TODO
以下の点で完成度が低いので限定公開です。
- 署名・検証フローの作図
- ARCがどのようにDMARCの評価をひっくり返すロジック
- 署名等の段階でどのようなヘッダーが生成されるのかの説明
- 署名対象となるヘッダーの説明
- 各機能をどういう風に連結していくのか順番の明示
- MTAへの設定ファイルの書き方と担保方法
はじめに
2023年11月、グーグル社より、メール送信認証強化のアナウンス12がありました。本件については色々とニュースになったので、見たことがある人も多いかと思いますが、メールを使ってるユーザーからすると若干ピンとこない話ではあります。
またグーグル社が言ってるだけで、どうしてそう慌てる必要があるのか?など、疑問に尽きない点があるかと思います。
ここではその点を考慮した上で「メール送信認証」3についての概略と、その運用方法について解説していきます。
誰向け?というと、メールサーバー(MTA: メール転送エージェント)を運用する人向けの資料として作成しています。
何かわからないけど、上から設定しろと言われたけど、どんな感じに設定するのか、どう運用するのか、設定順序(優先順位)は?…みたいなことを把握することを目的としています。
ただし、個々の機能の個別の事象については、色々と資料が出回ってるので、そちらを見た方が早いです。そこまで説明しません。
逆に機能の説明は見ても、どういう風に運用するのか今一つピンと来なかったこともあり、その点を中心に解説しています。
MTAの運用をブラックボックス的に扱ってる人向けではない解説となります。
メール送信認証とは?
アナウンスでは「メール認証」というキーワードが出てきます。メール送信認証と違うのでは?と思うところですが、「メール送信認証」のことを意味してます。
単純に「メール認証」と言えば、メール送信時に設定するIDとパスワード、いわゆるSMTP認証(SMTP AUTH)のことを指すのが一般的です。
古のシステムなら POP3 before SMTP といった機能についても言及する人がいるかと思いますが、今では廃止に値する機能となります。そんな設定(サービス)はさっさと切りましょう。
今時SMTP認証に対応していないサービスは色々とおかしいです4。
話を戻して、グーグル社が言うところの「メール送信者」、ここでのテーマである「メール送信認証」というのは何を意味するのでしょうか。
メール送るの自分だよね、という認識があればこそ、自分が何かしないといけない気になるし、具体的に何をするべきかよく分からないと思うのですが、直接的には無関係(間接的に影響ある)となります。
「メール送信者」は、具体的には「メールサービスプロバイダー」(MSP)という人達に向けた話となります。
MSPとは、インターネットサービスプロバイダ(ISP)と契約した時、携帯キャリアと契約した時、学校で、会社で、Gメール/Yahooメールで、自前で、など、メールの送受信サービス5を謳ってるサービスを提供する組織ないしはサービスのことを指しています。それぞれの組織で運用されるメールサービスが従うべきガイドライン(FAQ参照)となります。
ユーザーが間接的に影響受けるというのはこのことで、直接的には無関係となります。
より具体的には、それら組織の中で動いている、いわゆるMTAに対する設定への要求となります。
本設定を行うためにはDNSサーバーへの設定権限と、MTAに対する設定権限6が必要になります。
メール送信認証で要求される設定
メール送信認証で要求される、つまりメールを送信する際に、MTAが満たさなければならない設定は以下の3つです。
4つ目(ARC)については設定はマストではありませんが、かなり性質が異なりますので別立てします。基本は3つです。
- SPF
- MTAが送信する時のIPアドレスをDNSで広告します(DNS側の設定)。
- DKIM
- MTAが送信する内容(ヘッダー)について改ざんされていないことを保証するため、秘密鍵で署名を行います(MTA側の設定)。
- 署名を検証するために、公開鍵をDNSで広告します(DNS側の設定)。
- DMARC
- 上記SPF/DKIMでの成功・失敗した場合のポリシーをDNSにて広告します(DNS側の設定)。
上記の技術を使用して、メール送信者が正当なメールアドレスで送信していることを保証するための仕組みを指して「メール送信認証」と称しています。
これら設定を行う場合、どの程度の難易度でどこに、何を設定すれば良いのか、は下記の表にまとめました。
項目 | MTA設定 | 設定順序 | DNS設定 | 難易度 | DNSの設定単位 | 備考 |
---|---|---|---|---|---|---|
SPF | × | × | ○ | 低 | サブドメイン毎 | |
DKIM | ○ | → | ○ | 高 | サブドメイン毎 | MTAを設定してからDNSを設定します |
DMARC | × | × | ◎ | 低~高 | eTLD+1毎7 | サブドメインについて別途設定8 |
一応DMARC的には SPF と DKIM どちらかを満たせば良い運用が可能です。可能なはずですが、両方満たすように運用した方が、よりメールが安全に受信してくれる効果が期待されます(FAQ参照)。
SPFの設定については難易度は低く、古くから携帯キャリアでの対応が必須だったこともあり、かなりの割合で設定されてるはずです9。
DKIMの設定についてはそれなりにコツはあります。ここでは OpenDKIM
と Yenma
について言及に留めておきます。単純な設定で済むケースもありますので、状況に応じて確認が必要です(FAQ参照)。
いずれにせよ、MTA側で設定を行った後、DNSに設定する、という流れになります。
DMARCの設定は、DNSの設定のみであことから、本質的にSPF並に簡単です。ポリシーの表明だけなので、ほぼテンプレート通りとなります。
その代わり、SPFの設定が正しいか、DKIMの設定が正しいか、自己の管理下にある全てのMTAで問題無いかの確認が必要になります。
その辺りの確認が必要な点が難易度を上げているのと、MTAの増減によりポリシーの適用範囲外になってしまうMTAが無いかのモニタリングが必要な点が、更に運用をめんどくさくしてしまう要素になります。
DMARCのポリシーが主張するとおり、SPFとDKIMの設定をこまめにメンテナンスされることが要求されます。
またそれら設定から外れた分について、レポートする機能があることから、定期的に見守る必要があります。
なお、時間が無い場合はSPF+DMARCのみ設定するのが、一番の早道となります。おいおいDKIMに対応していきましょう。
ARCについて
SPF/DKIMはメーリングリスト、メール転送等のメカニズムと相性が悪い。そのための仕組みがARCで、転送等での再送信時に、SPF/DKIM/DMARCで検証した結果、DKIMで署名した内容を保存することで、メールを受けた側で検証を行う仕組みである。
メール送信時にDKIM/ARCの署名が行われるタイミングとフロー
各種メーラー(MUA)から送られてきたメールをMTAが受け取り、それの宛先を調べて、該当するメールサーバー(MTA)に送るのが基本的なフローとなります。
DKIMとARCは、その途中で処理が行われます。ここではmilterという仕組みを前提にフローを説明します。
- MUAがMTAにSMTPで接続し、メールを送信する
- MTAがヘッダーを受け取った時点で、前処理を行う(ドメイン名補完など)
- 清書されたヘッダー情報からDKIM署名を行い、ヘッダーに追加する
- DKIM署名を含むヘッダー情報をARCで署名する
- 残るボディを受け取るって送る
milterの仕組み上、メールを受け取ったタイミングでDKIM署名およびARC署名が行われます。送信のタイミングで行われない点に注意が必要です。
DKIMに関してはその振る舞いはシンプルであるため、受信時か送信時かのどちらでも同じ振る舞いが期待できますが、ARCはその必要性と署名のタイミングが難しいです。
メール受信時にSPF/DKIM/DMARC/ARCの検証が行われるタイミングとフロー
外部のメールサーバー(MUA)から送られてきたメールをMTAが受け取り、メールの受信・転送といった動作が基本的なフローとなります。
SPF/DKIM/DMARC/ARCの検証は、メールを受け取ってる最中に行われます。ここではmilterという仕組みを前提にフローを説明します。
- 外部のメールサーバーがMTAにSMTPで接続し、メールを送信する
- SMTPコマンドである
MAIL FROM:
が送られた時点(いわゆるエンベロープフロム)で、接続元IPアドレスと合わせてSPFの検証が行われます。 - 引き続きヘッダーを受け取った時点で、DKIM署名の検証が行われます。
- SPF/DKIMの検証が終わったのち、DMARCの評価が行われます。
- さらにARCの検証を行い、場合によってはDMARCの評価を覆す。
- 残るボディを受け取る
よくある質問とその答え
Q.なんでこんなことするの?
A.なりすまし迷惑メール対策の一環です。自分の預かり知らぬ場所から、自分の名前を勝手に名乗って、勝手にメールを送る、そういう不届き者に対する抑制策となります。
ただし完璧な技術というわけでもないので「なりすまし迷惑メール対策」⊇「メール送信認証」という包含関係があります。
これは以下のことが前提となるからです。
- すべてのメール送信者がメール送信認証に対応すること
- メール送信者が正規であること、乗っ取られてメール送信された場合までカバーされていないこと
もちろんメール送信認証したうえで「迷惑メール」を送ることについては本技術はカバーしていません。
この場合、レピュテーションという形で、迷惑メール対策を施すことになります。
Q.従わないと行けないって、設定しなくてもいいのでは?
A.数多のユーザーがいるGメール宛へのメール送信を行わないというのであれば問題ありません。
ただしグーグルだけで無く、この方向性に賛同している他のMSP10も多数いることから、これらMSPの対応が進むにつれて、送れるメール先が無くなることを意味します。
Q.送れなくなるって?
A.設定しなくても送ることはできなくもないですが、そのうち「受信してくれなくなる」ことを指して、「送れなくなる」です。
Q.なんでグーグルが言ったからって対応しないといけないのですか?
A.Gメールという数多のユーザーが利用しているサービスの提供元だからです。
業界的(フィッシング対策協議会)に音頭を取って対応を進めていた話ではありますが、一般に与えるインパクトの度合いは桁外れに違いました。
これら業界からのアナウンスがあっても対応しなかった所が、駆け込みで大騒ぎになりました111213。
なおこの問題は日本だけの問題ではなく、全世界的に進んでいた方向性ではあります。
Q.DKIM対応についてMTAの状況確認とは何ですか?
A.使用するMTA毎により事情が変わるため、です。自前でMTAを運用しているなら、DKIM署名アプリのインストールと設定が必要になります。
外部のMSPサービスを利用している場合は、MSPの案内に沿って対応します。
アンケート等で外部サービスを使用している場合は、外部サービス側の案内にしたがって対応する必要があります。
最後のものが曲者で、MTA管理者の管理外のサーバーを利用している場合がありますので、そこも含めて設定が担保される必要があります。
Q.SPF+DMARCでOKじゃないの?
A.現在、SPF かつ/または DKIMの認証が通ればOKとする運用になっています。その点で言えばYesです。
ただしDMARCポリシー的にはその制御ができません。ある日、SPFかつDKIMとポリシーの解釈が行われる可能性があります。
またメール受信側でSPFとDKIMが必須とする可能性もあります。いずれにせよ、アンコン状態です。
参考文献
- 団体・組織関連
- なりすまし迷惑メール対策
- 参考
-
「送信ドメイン認証」と呼称することもあります。自分としてはより包括的な「メール送信認証」という呼称を使用します。 ↩
-
認証を要求せずに送ることができるケースもあると思いますが、そういう細かい設定については言及しません。 ↩
-
メール配信業者はメール受信しないじゃん、とツッコミたくなりますが、メール送信するだけの業者(=MSP)も今回の対象です。 ↩
-
より具体的にはインストール等の作業が発生しえます。単純な設定だけで済むケースもありますが、MTA毎、仕様するメールサービス毎の仕様によるので、要確認です。 ↩
-
実質的なトップレベルドメイン(eTLD)のサブドメイン。組織や個人がレジストラにお願いして、取得するドメイン名を指します。 ↩
-
サブドメインについても明示することが可能ですが、まとめて一括になります。サブドメイン単位でポリシーを明記することはできません。 ↩
-
Gメール自体は2015年10月頃(公式アナウンスが見つからず、周辺記事から判断)からDMARCを運用しています。唐突に強化を主張したわけではありません。 ↩
-
「メール送信者のガイドライン」自体は2023年11月に発表、その適用を2024年02月から…としてアナウンスしました。 ↩
-
わずか3か月で対応が求められたように見えますが、業界的には10年の歳月をかけています。今までその手のアナウンスを見なかったことが騒ぎを大きくしています。 ↩