メールなりすましを防止する機能の一つ

DKIMってなんじゃろ？と思う人や、名前は聞いたことがあるけどよーわからん・・と言う人いるんじゃないでしょうか。実は私も先日まで名前しか知らなくて、「ああ、DKIMね」とか言ってみるものの、単なる知ったかぶりだったりしていたわけですが、この際キチンと覚えていこうということで、自宅環境に対して取り組んでみました。

図にまとめるとこんな感じのようです。

上図にあるように、所謂「送信ドメインのなりすましを防ぐ」ために、「送信ドメインDNSの所有者であるかどうかを確認する」方法なんだと思います。図の下の方にも書いていますが、実はSPFと言う方式もあり、これもDNSと連携して送信元SMTPサーバの確認を行います。

アプローチとしてはSSL証明書のDV証明に似たところがあるかな？と感じますね。

今回の構成

では、今回の構成ですが、下図のとおりとしています。

セクションとしては2つに分かれます。

• Outlook等から送信する、Office365メールにDKIM署名を加える
• サーバの通知メールに対してDKIM署名を加える

ドメインに関してはいずれもBLUECORE.NETなんですが、送信するSMTPサーバが異なってくるため、やり方としてはそのまま二手に分かれる感じになります。
なお、外部権威DNSサーバは共通してRoute 53を使います。

• Exchange Online上でDKIM実装を行う
• Sophos UTM9上でDKIM実装を行う

それでは、それぞれに対する手順について、説明を行いたいと思います。

Exchange OnlineにおけるDKIM実装

まずはExchange 管理センターへブラウザでアクセスし、そこから画面左側メニューの「保護」をクリックします。

その画面から、「dkim」タブをクリックし、メール配送対象となるドメインを指定して「有効にする」をクリックするとDKIMが有効になります。
しかし、現時点ではセレクタと呼ばれる、DKIM公開鍵との対応付けを行う識別子に紐付くDNSレコードが存在しないため、有効化できません。

そこで、Route 53管理コンソールへアクセスし、必要なDNSレコードを作ることになります。

AWSコンソールからメール配送に関わるドメインゾーンへ入ります。実は、Exchange Onlineで使用する秘密鍵・公開鍵はそれぞれ構築が完了している時点でExchange Onlineに秘密鍵が、Office365ドメイン（*.onmicrosoft.com)のDNSに公開鍵が、すでに実装されています。名称は、先のエラーメッセージに書かれていたものがそのまま適用されており、私の環境では「selector1」と「selector2」になっていました。
そのため、ユーザ側で鍵の作成を行う必要がなく、権威DNSに対して設定するのは、Office365ドメインに対するCNAMEレコードを作るだけで済むのです。とっつきやすいと言えばとっつきやすいですし、予め鍵のセットが2セット構成されているのは可用性の面から見ても便利だなーと思います。

登録するCNAMEの具体的な内容は下図のとおりまとめてみました。

さて、CNAMEレコードが登録されたら、改めてExchange 管理コンソールへアクセスして、DKIMの有効化をリトライします。

DNSレコード設定を誤ってしまった場合、TTLの値によっては手間がかかってしまう可能性があるので、初期登録時は短めのTTL設定にしたほうが良いと思います。で、無事CNAMEとの対応が取れているのであれば、上図のように有効化された形となります。

さて、実際に有効化して動くのでしょうか。試しにExchange OnlineからGmail宛にテストメールを送信してみました。

はい、無事にDKIMが動いていました。これとは別途に入れてたSPFヘッダも記録されてますね。SPFとDKIM各ヘッダの間に、「Authentication-Result」と言うヘッダがあります。これが、SPF/DKIMヘッダを参照した上で、受信メールサーバがそれらの方式に基づいて送信元が正しいと判断したのかどうかが書かれています。

実際の処理をどうするかについては、別途拡張ヘッダの定義が必要になるので、その記述によりけりでメールがドロップしたり、あるいは無事メールボックスに到達できるかするわけですが、このようにして送信元の証明をするんだなーということがわかりますね。

Sophos UTMでのDKIM実装

今度は、通知メールにDKIM署名を付与するための手順について記載していきます。ある意味、これが本来の実装手順と読んで良いのかもしれません。

Exchange Onlineの場合、それら環境を構築する時点で、DKIMが使えるようになっているため、予め決まったCNAMEレコードを登録すればよかったわけですが、今回は鍵セットから作成が必要となります。
また、スマートホスト経由やドメイン内配送では基本的にDKIMは動かないようで、MX配送時に動作していることを今回の実装では確認しました。逆に言うと、スマートホスト経由での配送であれば、そもそもDKIMはいらない・・ということでいいのかな？うーん。

では、まずCLIで鍵のペアを作ります。SSHでまず、loginuserにてログインし、続いてsuコマンドでrootに昇格しました。

■秘密鍵の作成
meiji:/home/login # openssl genrsa -out meiji.private 1024
Generating RSA private key, 1024 bit long modulus
...................++++++
.....++++++
e is 65537 (0x10001)

■公開鍵の作成
meiji:/home/login # openssl rsa -in meiji.private -out meiji.public -pubout -outform PEM
writing RSA key

■鍵の確認
meiji:/home/login # ls
meiji.private  meiji.public

■公開鍵の出力（コピペなどする形で手元に控えておこう）
meiji:/home/login # cat meiji.public
-----BEGIN PUBLIC KEY-----
******************************************
******************************************
****
-----END PUBLIC KEY-----

■秘密鍵の出力（コピペなどする形で手元に控えておこう）
meiji:/home/login # cat meiji.private
-----BEGIN RSA PRIVATE KEY-----
*********************************************
*********************************************
     ........

*********************************************
*************************
-----END RSA PRIVATE KEY-----

■ログアウト
meiji:/home/login # exit

次に、Route53でTXTレコードを作成します。Exchange Onlineではセレクタ名は事前に決まっていましたが、今回のケースではセレクタ名は何にしても大丈夫です。

メールを送信元SMTPが発信する時点で、付与情報にセレクタ名が欠かれています。受信メールサーバはそのセレクタ名を権威DNSへ確認することで、その証明の妥当性を確認できるということみたいです。

ここでは必要最低限の記載しかしていませんが、ざっくりこんな感じです。
「DKIM TXT」を検索対象として、Google先生にお伺いを立てれば、もっと細かい情報が拾えると思います。

さて、UTM9側では以下の通り設定します。

WebGUIを開き、DKIMに必要な情報を登録します。悲しいかな、わざわざopensslコマンドを叩いて鍵を出力させ、それをcatで出してここに貼り付ける・・・というのが。

秘密鍵はヘッダとフッタも加えた形でコピペしましょう（公開鍵は外す必要があったけど）。省略しちゃうと秘密鍵処理でエラーを起こしてました。

そして、同様に今度は通知メールの配送ヘッダを参照し、DKIMの動作を確認します。

はい、ちゃんと動いてました。ヘッダの内容としてはExchange Onlineとさほど変わりません。DKIM署名が正常に追加され、Authentication-Resultsでもpassと書かれているので、配送元は証明されたということになりますね。

さて、受信側はどうしたら良いだろうか

Gmailは比較的このあたり寛容で、ひとまずはSPFレコードをちゃんと設定しておけば、迷惑メール扱いされずに済みます。DKIMは・・・？果たしてどーしたら良いでしょうか。

実はDKIM署名は注意すべきポイントが有り、その署名の妥当性を判断する箇所がDKIMヘッダしかない点です。 あくまで、DKIM-Signatureというヘッダに指定されているドメイン名や送信アドレスを対象に認証するだけで、そこから外にあるFromアドレスとは値が異なる場合がある・・というのがなんとも悩ましいところです。

そこで、この問題を補うのがDKIM-ADSPというもので、実は認証通過した要素の組み合わせによって、どうさばいてほしいかというのが、送信元ドメインの権威DNS上のレコードで定めることができます。
元々DKIM自体が「ドメイン所有の証明」であることを示すので、ドメイン所有者そのものである権威DNSでキチンと定義してりゃ、まぁちゃんとその実効性も高まってくれるよねという話なんだと思います。

DKIM-ADSPの他にもDMARCというものもあります。同様に、権威DNSに対応方針をレコードとして登録し、受信メールサーバにポリシーを指示するもので、よりこうした送信者ドメイン認証の実効性を高めてくれるものになります。

今回、実はここの実装はできていないので、追々実装の上、まとめられそうであればまとめたいなーと思います。