ここでは以下のドメイン認証技術に対する問題点をまとめる。
考察すべきケースは、以下の通り。
あらかじめまとめると、次のようになる。
| (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 を独立して普及させることも可能であると思われる。