IIJ技術陣「spamからメールを守れ（管理者編）」

2005年11月9日
櫻庭秀次
ユーザ編はこちら＞＞

　管理者編第3回で、導入すべきspam対策技術の一つとしてドメイン認証をあげた。時々誤解されることがあるが、ドメイン認証はメールの送信元がどこであるかを認証するための技術で、ドメイン認証技術を導入すればただちにspamがなくなるわけではない。送信元情報を詐称できなくすることにより、送信元ドメインによる振り分けが可能となったり、送るべきエラーメールの送り先は正しいかなど、認証（Authentication）後に承認（Authorization）処理があって初めてspam対策となる。送信ドメイン認証技術の導入は、spam対策の第一歩ととらえるべきである。

　今回は、送信ドメイン認証技術の有力な一つである、「SPF（Sender Policy Framework）」と「Sender ID」の歴史をまとめる。また、今すぐにでも導入できる送信側の宣言について説明する。なお、今回は受信側の認証処理については触れない。

　送信ドメイン認証技術は、spam問題の急激な広がりにより「LMAP（Lightweight Mail Authentication Protocol）」としてIRTFのASRG（Anti-spam Research Group）などを中心としていくつか規格が検討、提出されてきた。いずれもDNSを利用して、ドメインのポリシーを宣言し、受信側がそれを参照することにより、指定されたドメインの利用が妥当かどうかを判断する。SPFは、これらLMAPファミリのうち、RMX（Reverse MX）およびDMP（Designated Mailers Protocol）などの機能を取り込む形でMeng Wong氏によって開発された。

　RMXは送信ドメインのDNS上にRMXという新たなRR（Resource Record）を定義し、そこに送信元のIPアドレス情報を格納する。IPアドレスの定義は、ネットワークアドレスとそのマスク値、あるいはホスト名（FQDN）で指定される。

somedomain.de. IN RMX ipv4:10.0.0.0/8
rmxtest.de. IN RMX host:relay.anyprovider.com

　送信元のドメイン名は、配送上の情報であるエンベロープFromを用いる。DMPも送信ドメインのDNSに送信元IPアドレス情報を格納するが、、格納先は送信ドメインそのものではなく、"_smtp-clinet" サブドメイン以下にアドレスタイプ（"in-addr" や "ip6"）とネットワークアドレスを用いたドメイン名を利用する。すべてのDNSシステムが利用可能なようTXT RRを利用し、そのIPアドレスからメールが送信されるのかどうかを表明する。

_smtp-client.example.com. TXT "dmp="
*._smtp-client.example.com. TXT "dmp=deny"
1.2.0.192.in-addr._smtp-client.example.com. TXT "dmp=allow"

　送信元のドメイン名は、エンベロープFromかHELO/EHLOで指定するドメイン名を利用する。

　SPFはRMXの柔軟なIPアドレス範囲の指定方法や、DMPのTXT RRを使う部分や特定のサブドメインに情報を格納する方式（当初は "_spf" サブドメインを利用していた）などを参考にしたと思われる。

　SPFの当初の名前は「Sender Permitted From」であったが、2003年2月のInternet Draft作成時には「Sender Policy Framework」と略称をそのまま維持する形で改称された。2004年5月にMicrosoft社の「Caller ID for E-mail」と統合することで合意され、6月には最初のInternet Draftが出された。そののち、Sender IDと名称を改め、IETFのMARID（MTA Authorization Records in DNS）ワーキンググループ内で検討が進められてきたが、規格にMicrosoft社の知的所有権が含まれていることから反発を招き、MARIDは2004年9月に解散した。

　そののち、SPFはもとの仕様を「SPF」（Classicまたはversion 1）として再提出し、Sender IDとともにExperimental（実験的）RFCとして承認された。今後はどちらの規格の利用が多く用いられるようになるのか、しばらく様子をみるといった状況が続くと思われる。