ここでは以下のドメイン認証技術に対する問題点をまとめる。
考察すべきケースは、以下の通り。
あらかじめまとめると、次のようになる。
(1)転送 | (2)メーリングリスト | (3)第三者投稿サーバ | |
SPF、Sender ID/MFROM | SMTP の拡張が必要 | 問題なし | SMTP の拡張が必要 |
Sender ID/PRA | Resent-From: を付ければ可能 | Resent-From: を付ければ可能 | Sender: を付ければ可能 |
DKIM | 問題なし | 可能 | 可能だが署名の意味が変る |
利用形態:ユーザが、複数のメールアドレスを持っている場合、 主となるメールアドレス(bob@example.com)を決め、 他のメールアドレス(bob@example.net)へ届いたメールを主のメールアドレスへ集める。
転送サーバでの SMTP レベルの転送は、以下のように実現される。
このような仕組みにより、以下の機能が実現されている。
受信サーバが 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 に転送されるとループが発生するが、 これを防ぐ方法が存在する。 詳しくは、近日中に加筆する予定である。
受信サーバが 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
IP アドレスから独立した技術であるので、問題は生じない。
ML サーバのメーリングリスト・サービスは、以下のように実現される。
このような仕組みにより、以下の機能が実現されている。
受信サーバが受け取る SMTP MAIL FROM には、 ML サーバのドメイン(example.net)が指定されているため問題は生じない。
受信サーバが 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
ML では、よく Subject: が書き換えられ、 また Received: が削除される。 このため署名の検証に失敗する。
解決案:ML サーバで再署名する。
対症療法:署名の対象から Subject: と Received: を外せば、 多くの場合検証は成功する。 DKIM では、これを実現できる。
利用形態:家から「会社のメールアドレス(alice@exampl.net)を記述したメール」を出す場合に、 個人的に契約している ISP の投稿サーバ(example.jp)を利用する。
注:これを「ローミング」と呼ぶ人もいるが、 その呼称は誤解をまねくよくない表現だと考える。
これは以下のように実現される。
注:ユーザが投稿サーバのメールアカウントを持つことは大前提。 メールアカウントなしでこのサービスを提供しているサーバは、 オープンリレーと呼ばれ、存在自体が問題視される。
このような仕組みにより、以下の機能が実現されている。
受信サーバが 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>
このように書き換えても、エラーメールはループしない。
受信サーバが 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: 付けた場合は、 投稿サーバでそれが正式なアカウントか検査する必要がある。
署名情報の中に、From: (alice@example.net)とは独立したドメイン名を記述できるため、 投稿サーバ(example.jp)でも署名できる。
メールリーダの作りが悪ければ、 example.jp の署名であるにも関わらず、 example.net の署名に対する検証が成功したという誤解をユーザに与えかねない。 これを悪用するフィッシングが現れる可能性がある。
前提:
残る2つのドメイン認証の内、SPF は転送に弱く、ML に強い。 一方、DKIM は正反対で、転送に強く、ML に弱い。 そこで、解決案として、両者を組み合わせ、 一方の認証が成功したらドメインを正当だとみなし、 両方失敗したら詐称されているとみなす方法が提案されている。
また、SPF の転送問題を解決する方法も、前述のように存在するので、 SPF を独立して普及させることも可能であると思われる。