ドメイン認証の問題点と解決案

作成：2005年3月29日
改訂：2006年1月19日
IIJ 山本和彦

ここでは以下のドメイン認証技術に対する問題点をまとめる。

SPF、Sender ID/MFROM
Sender ID/PRA
DKIM

SPF、Sender ID

SPF、Sender ID/MFROM: 「SMTP MAIL FROM のドメイン名に対し DNS を索いて得られた送信サーバの IP アドレス」と「SMTP コネクションから得られた IP アドレス」を比較する
Sender ID/PRA: 「メールヘッダの From: などのドメイン名に対し DNS を索いて得られた送信サーバの IP アドレス」と「SMTP コネクションから得られた IP アドレス」を比較する

DKIM

DKIM: ヘッダに指定してあるドメイン名に対し DNS を索いて得られた公開鍵を用いて、電子署名を検証する

3つのケース

考察すべきケースは、以下の通り。

(1)SMTP レベルの転送: 転送サーバで受信したメールを受信サーバへ転送する
(2)メーリングリスト (ML): ML サーバは、あるメールをコピーし複数の受信サーバへ転送する
(3)第三者投稿サーバの利用: 投稿サーバのドメインは example.com であるが、メールリーダで From: に example.jp を指定して利用する

あらかじめまとめると、次のようになる。

	(1)転送	(2)メーリングリスト	(3)第三者投稿サーバ
SPF、Sender ID/MFROM	SMTP の拡張が必要	問題なし	SMTP の拡張が必要
Sender ID/PRA	Resent-From: を付ければ可能	Resent-From: を付ければ可能	Sender: を付ければ可能
DKIM	問題なし	可能	可能だが署名の意味が変る

(1)SMTP レベルの転送

利用形態：ユーザが、複数のメールアドレスを持っている場合、主となるメールアドレス(bob@example.com)を決め、他のメールアドレス(bob@example.net)へ届いたメールを主のメールアドレスへ集める。

転送サーバでの SMTP レベルの転送は、以下のように実現される。

転送サーバ(example.net)は受信サーバ(example.com)との間に新たな SMTP コネクションを作る
よって、始点の IP アドレスは変る(example.jp:192.0.2.1 → example.net:192.0.2.2)
一方、SMTP MAIL FROM (alice@example.jp)はリレーされる

このような仕組みにより、以下の機能が実現されている。

受信サーバ(example.com)は、エラーメールを送信サーバ(example.jp)へ返すことが可能。なぜならば、SMTP MAIL FROM がリレーされているから。

SPF、Sender ID/MFROM

受信サーバが SMTP MAIL FROM から得られるドメイン名は、送信サーバのもの(example.jp)である。そのドメイン名から得られる IP アドレスは、送信サーバのもの(192.0.2.1)である。一方、SMTP コネクションから得られる IP アドレスは、転送サーバのもの(192.0.2.2)である。これらは一致せず認証に失敗する。

解決案1：これを解決するには、転送サーバのドメイン名も受信サーバに伝える方法があればよい。この目的で、SMTP MAIL FROM に SUBMITTER というパラメータを追加することが検討されていた。

MAIL FROM=<alice@example.jp> SUBMITTER=bob@example.net

解決案2： SMTP MAIL FROM を転送サーバ上のメールアカウント(bob@example.net)に書き換える。この方法では、エラーメールが alice@example.jp に戻らずに、 bob@example.net に返る。このエラーメールが、さらに bob@example.com に転送されるとループが発生するが、これを防ぐ方法が存在する。詳しくは、近日中に加筆する予定である。

Sender ID/PRA

受信サーバが From: から得られるドメイン名は、送信サーバのもの(example.jp)である。そのドメイン名から得られる IP アドレスは、送信サーバのもの(192.0.2.1)である。一方、SMTP コネクションから得られる IP アドレスは、転送サーバのもの(192.0.2.2)である。これらは一致せず認証に失敗する。

これを解決するには、転送サーバのドメイン名も受信サーバに伝える方法があればよい。よって、ヘッダに Resent-From: を追加し、転送サーバ上のメールアカウントを書く。

From: alice@example.jp
Resent-From: bob@example.net

DKIM

IP アドレスから独立した技術であるので、問題は生じない。

(2)メーリングリスト

ML サーバのメーリングリスト・サービスは、以下のように実現される。

ML サーバ(example.net)は、メールを ML のメンバー分コピーし、それぞれの受信サーバに対して以下のように動作する
受信サーバ(example.com)との間に新たな SMTP コネクションを作る
よって、始点の IP アドレスは変る(example.jp:192.0.2.1 → example.net:192.0.2.2)
また SMTP MAIL FROM を ML の管理者(ml-owner@example.net)へ変更する

このような仕組みにより、以下の機能が実現されている。

受信サーバは、エラーメールを ML の管理者へ返すことが可能。投稿者(alice@example.jp)へは戻らない。

SPF、Sender ID/MFROM

受信サーバが受け取る SMTP MAIL FROM には、 ML サーバのドメイン(example.net)が指定されているため問題は生じない。

Sender ID/PRA

受信サーバが From: から得られるドメイン名は、送信サーバ(example.jp)のものである。そのドメイン名から得られる IP アドレスは、送信サーバのも(192.0.2.1)のである。一方、SMTP コネクションから得られる IP アドレスは、 ML サーバのもの(192.0.2.2)である。これらは一致せず認証に失敗する。

これを解決するには、ML の管理者も受信サーバに伝える方法があればよい。よって、ヘッダに Resent-From: を追加し、ML の管理者を書く。 (現在、多くの ML が Resent-From: ではなく、 Sender: に ML の管理者を書いて付加している。)

From: alice@example.jp
Resent-From: ml-owner@example.net

DKIM

ML では、よく Subject: が書き換えられ、また Received: が削除される。このため署名の検証に失敗する。

解決案：ML サーバで再署名する。

対症療法：署名の対象から Subject: と Received: を外せば、多くの場合検証は成功する。 DKIM では、これを実現できる。

(3)第三者投稿サーバ

利用形態：家から「会社のメールアドレス(alice@exampl.net)を記述したメール」を出す場合に、個人的に契約している ISP の投稿サーバ(example.jp)を利用する。

注：これを「ローミング」と呼ぶ人もいるが、その呼称は誤解をまねくよくない表現だと考える。

これは以下のように実現される。

投稿サーバ(example.jp)は、メールリーダに認証(POP before SMTP も含む)を要求する。
認証が成功すれば、メールリーダは From: と同じメールアドレス (alice@example.net)を SMTP MAIL FROM に指定する。
送信サーバは、認証が成功しているので、メールリーダが指定した SMTP MAIL FROM をリレーする。

注：ユーザが投稿サーバのメールアカウントを持つことは大前提。メールアカウントなしでこのサービスを提供しているサーバは、オープンリレーと呼ばれ、存在自体が問題視される。

このような仕組みにより、以下の機能が実現されている。

受信サーバは、エラーメールをユーザが希望するメールアドレス(alice@example.net)へ返すことが可能。実際に利用した投稿サーバ/送信サーバ(example.jp)へは戻らない。

SPF、Sender ID/MFROM

受信サーバが SMTP MAIL FROM から得られるドメイン名は、メールリーダが指定した example.net である。そのドメイン名から得られる IP アドレスは、 192.0.2.2 である。一方、SMTP コネクションから得られる IP アドレスは、 example.jp に付けられている 192.0.2.1 である。これらは一致せず認証に失敗する。

解決案1：受信サーバ(example.com)へ送信サーバのドメイン(example.jp)も伝える方法があればよい。この目的で、SMTP MAIL FROM に SUBMITTER というパラメータを追加することが検討されていた。

MAIL FROM=<alice@example.net> SUBMITTER=alice@example.jp

SUBMITTER を実現するには、投稿サーバで SMTP AUTH によりユーザを認証し、投稿サーバ上でのメールアカウントを特定する必要がある。 (POP before SMTP では実現不可能。)

解決案2：SMTP MAIL FROM を送信サーバで書き換える。

MAIL FROM=<alice@example.jp>

このように書き換えても、エラーメールはループしない。

Sender ID/PRA

受信サーバが From: から得られるドメイン名は、メールリーダが指定した example.net である。そのドメイン名から得られる IP アドレスは、 192.0.2.2 である。一方、SMTP コネクションから得られる IP アドレスは、 example.jp に付けられた 192.0.2.1 である。これらは一致せず認証に失敗する。

これを解決するには、受信サーバ(example.com)へ送信サーバのドメイン(example.jp)も伝える方法があればよい。この目的で、ヘッダに Sender: を追加し、投稿サーバのメールアカウントのアドレスを書く。これは、メールリーダで付加しても、投稿サーバで付加してもよい。どちらも SMTP AUTH によりユーザを認証する必要がある。 (POP before SMTP では実現不可能。)

From: alice@example.net
Sender: alice@example.jp

メールリーダで Seneder: 付けた場合は、投稿サーバでそれが正式なアカウントか検査する必要がある。

DKIM

署名情報の中に、From: (alice@example.net)とは独立したドメイン名を記述できるため、投稿サーバ(example.jp)でも署名できる。

メールリーダの作りが悪ければ、 example.jp の署名であるにも関わらず、 example.net の署名に対する検証が成功したという誤解をユーザに与えかねない。これを悪用するフィッシングが現れる可能性がある。

解決案

前提：

Sender ID (のPRA)には特許の問題があるので、受け入れられにくいだろう
SUBMITTER パラメータは、SMTP の拡張を強いるので、普及しにくいだろう
第三者サーバという利用方法は禁止される方向に進むと思われる。常時接続かつブロードバンドの環境が整った現在、使いたいドメインの送信サーバが遠距離にあっても、直接そこを利用すればよい

残る2つのドメイン認証の内、SPF は転送に弱く、ML に強い。一方、DKIM は正反対で、転送に強く、ML に弱い。そこで、解決案として、両者を組み合わせ、一方の認証が成功したらドメインを正当だとみなし、両方失敗したら詐称されているとみなす方法が提案されている。

また、SPF の転送問題を解決する方法も、前述のように存在するので、 SPF を独立して普及させることも可能であると思われる。