送信ドメイン認証技術は送信者の正当性を確認し、フィッシング詐欺メールに対抗していく手段として有効だが、一方で幾つかの課題が存在するのも事実だ。
N+I NETWORK Guide 2005年7月号よりの転載です
|
送信者の正当性を確認する手段として、詐欺メール対策に有効な送信ドメイン認証技術だが、一方で考慮しなければならない問題もある。導入の解説に入る前に、送信ドメイン認証の持つ問題点について理解しておこう。
●直前のサーバしかチェックできないSender ID/SPF
IPアドレスベースの認証方式では、メール送受信時の相手のIPアドレスによって認証処理を行う。つまり、メールが幾つかMTAを経由して配送されてくる場合、認証処理を行うMTAの直前にあるMTAのみが認証可能な対象となる。しかし、現在のインターネットにおいては、送信者−受信者間で多くのSMTPサーバを経由してメールが配送されるのが一般的だ。そのため、IPアドレスベースの認証処理は、そのドメインの最も外側のMTAで実施する必要がある。
このように、直前のサーバのチェックが基本になるため、当然ながらメールの転送時に問題が起きる(図11)。a@a.comから送信したメールをb@b.comでb@c.com宛に転送するように設定した場合、b@c.comのMTAがそのメールを受け取るときには直前のサーバはB.COMのメールサーバとなる。しかし、A.COMのSPFレコードを取得してもB.COMのメールサーバは含まれておらず、認証に失敗してしまう。この問題を防ぐために、オリジナルのSPFでは「Sender Rewrite Scheme(SRS)」という方式を、Sender IDでは「Purtported Responsible Address(PRA)」の追加という手法をそれぞれ使う。
●Sender Rewriting Scheme(SRS)
SPFではエンベロープの送信者を認証対象にするため、転送時にエンベロープの送信者に転送した(オリジナルの)送信者の情報を追加する。通常、UNIXシステムなどでエイリアス(*12)や.forwardの機能を使ってメールを転送すると、エンベロープの送信者はオリジナルの送信者のままである。だがSRSを行うと、転送するたびにSMTPプロトコルにおいてMAIL FROM:のパラメータを書き換えていくことになる。本来、MAIL FROM:のパラメータはそうした情報を与えられるようには考えられていないため、MTAの改造が必要となる。したがって、現在ではこれを採用することはあまり考えられていない。
●Purported Responsible Address(PRA)
Sender IDでは、前述のとおりヘッダ上の送信者アドレスを認証対象にする。Sender IDにおいて転送が発生した場合は、メール転送時に「Resent-From:」や「Resent-Sender」を追加して対応する。認証処理を実施するMTAでは、Resent-Sender、Resent-From、Sender、Fromの順番でアドレスをチェックする。もちろん、転送を実施するMTAでの改造が必要であるが、SRSに比べてわかりやすい部分が受け入れられている。
だが、マイクロソフトがPRAのチェック技術について特許権を主張したため、これを嫌うオープンソースのグループや一部のISPからSender IDを採用しないことがアナウンスされるなど、一時混乱が起きた(関連記事)。
ただし、このライセンスを必要とするのはごく一部のケースだけであって、Sender IDを利用するだけではマイクロソフトとライセンス契約を交わす必要がないことなどが明らかになってきた。
●両方式の長所・短所
IPアドレスベースの認証方式は、特に送信側ではDNSにSPFレコードを公開するだけなので、簡単に始められるメリットがある。一方電子署名方式は、送信側も受信側もシステムの変更が必要だ。このことから、一般にIPアドレス方式のほうが「導入が簡単で即効性のあるソリューション」と受け止められている。ただ、直前のホストしか検査できないという基本的な制限があるため、長期的に見ると電子署名方式のほうが本質的かつ有効であると考えられる。
ここで気を付けたいのは、両方の方式を同時に利用できるということ。2つの方式の欠点を相互に補い、より送信ドメインに対する情報を増やすことができるのだ。
*12 エイリアス 1つのメールアカウントに対して、別名(エイリアス)のメールアドレスを設定できる機能。メールエイリアスにより、状況や用途に応じてメールアドレスの使い分けができる。
Copyright © ITmedia, Inc. All Rights Reserved.