電子メール処理のやり取りは、2つのSMTPサーバ間で行われる。送信側がメッセージ送信の仲介役を果たし、その後、受信サーバがメッセージの配信を処理する。ただし、この場合、送信側が信用できることが前提になる。
そこで、スパムの発信者を識別するさまざまなメカニズムが受信側のSMTPサーバに実装されてきた。ブラックリストやコンテンツフィルタなどだ。残念ながら、これらは複雑化するスパムとの戦いにおいて十分とはいえない。
SPFとSenderIDテクノロジは、スプーフィングを阻止する。スプーフィングは、スパム発信者の間で広く使われている手段で、第三者のドメインから発信したように偽装したメッセージを生成する方法だ。よく知っているアドレスから受信したメールが実はスパムだった、自分のドメインのユーザからどうしてスパムを送ってくるのかと苦情がきた、ということがあるなら、SPFは電子メールインフラストラクチャにとってなによりの恩恵となるだろう。
SPFを展開、それも適切に動作するように展開するには、受信側とドメイン所有者の双方が、それぞれのサーバに変更を加える必要がある。受信側はSMTPサーバでこれを行い、ドメイン側では特殊なDNSコンフィグレーションを介してスプーフィングを防ぐ。この手順を詳しく見ていこう。
SPFのないSMTPサーバに電子メールが到着すると、発信先のドメインが正しいものと見なされる。一方、SPFで動作するように設定されているメールサーバでは、電子メールに含まれるドメインのDNSレコードが照会され、返される応答によって受信側のSMTPは着信メッセージが本物か偽物かを判断できる。
SPF情報はDNSサーバごとに1つのテキストレコードになっており、ゾーンファイル内で以下のような行として示される。
linux.com. IN TXT "v=spf1 a include:myserver.com -all"
|
最初の3つの要素はDNSテキストレコード特有のもので、ドメインのSPFルールを示す情報は引用符で囲まれた部分にある。
v=spf1は、このテキストレコードがSPF情報であることを表し、文字aは、このドメインの公開IPアドレスが電子メールメッセージの発信元として有効であることを示す。
include:myserver.comは、linux.comから送信されたことになっている電子メールが、myserver.comドメインのSMTPサーバからも発信可能であることを示す。
最後に、-allフラグは、前述のドメイン／IPアドレスから発信されたメール以外はいずれも、ドメイン所有者からは有効と認められないことを示す。
以上は、ドメインにSPFポリシーをセットアップする非常に単純な例だ。それでも、スパム発信者がドメイン名をハイジャックして迷惑メールを送信することは確実に阻止できる。さらに精緻なSPFレコードを生成する総合的なツールがここにある。
ポリシーのセットアップは強制時のみ有効で、SPFポリシーの強制はメールサーバの仕事だ。現在、Sendmail社やほかの主要ベンダ によって活発にSPFのテストが行われており、Sendmail用のオープンソースSPFの実装も既にある。コンフィグレーションの詳細はこの記事では紹介できないが、SPFのプロセスとコンフィグレーションはメールサーバのブラックリスト参照と性質が非常に似ている。ただSPFの場合、情報はDNSレコードから取得され、これによってドメインに関する安全で信頼できる情報源が保証される。
SPFを最大限利用するには、ドメイン所有者とメールサーバ管理者の間で密接な協力関係が必要になるが、これは正しい方向への第一歩である。各種団体からの強力な支持を得、SPFはコンテンツフィルタやブラックリストなどのツールと併せてスパムに対抗する重要な武器になりつつある。
Daniel Rubio―Osmosis Latina社の主席コンサルタント。同社はメキシコでエンタープライズソフトウェアの開発、トレーニング、コンサルティングを行っている。