送信側での準備
送信側で必要なのはSPFレコードの公開である。SPFレコードでは、そのドメインを送信ドメインとするメールが送出されるホストを宣言する。外部へ向けて送信されるメールが自ドメインのどこから送信される可能性があるか、また、どのように扱われるべきかを考えてポリシーを決定する必要がある。
例えば、まったくメールを送信する可能性のないドメインの場合、メールを送信することはないというポリシーをSPFレコードで公開する。IPアドレスベースの認証方式では受信側から見える送信メールサーバのIPアドレスが重要な認証情報になるので、メールを送信する可能性のある場合、どのホストからメールを送信する可能性があるかチェックしておく（図2）。
一般に、メールはゲートウェイMTAと呼ばれる内部ネットワークと外部ネットワークの境界線にあるメールサーバから外部に配送される。それ故、そのメールサーバが外部から見たときにどのようなグローバルIPアドレスで見えるかという点を把握する。また、SPFレコードを便利に記述する方法が提供されているので、それらを使って管理しやすいレコードを考えよう。
図2 サイト構成とSPFレコードの例
ゲートウェイメールサーバMTA1とMTA2は、それぞれ内部ネットワークにおいて192.168.0.11と192.168.0.12を持つ。しかし、ファイアウォールでNATの設定をしており、外部からみるとXXX.XXX.XXX.XXXとYYY.YYY.YYY.YYYというグローバルIPが割り当てられている。このような場合、以下のようなSPFレコードを公開する
v=spf1 +ip4:xxx.xxx.xxx.xxx +ip4:yyy.yyy.yyy.yyy ~all
チェック対象とされる送信ドメイン
SPFレコードを公開した場合、実際に自ドメインから送信したメールのどの部分が検査されるのだろうか。
これは受信者がどのような認証を実施するかに依存する。相手がSPFの認証を利用していると、エンベロープの送信ドメイン（SMTP通信のMAIL FROM:コマンドの引数）をチェック対象にする。
相手がSender IDの認証を実施するとエンベロープの送信ドメインのチェックに加えてPRAのチェックを実施する。この場合対象となるのが次のヘッダである。これらのヘッダ情報は、上から下の順番でチェックされる。
- Resent-sender:
- Resent-from:
- Sender:
- From:
SPFレコードの記述法
SPFレコードの記述法については、次に示すドラフトに規定されている。SPF、Sender IDともExperimental RFCとなっている。
SPFレコードは、
バージョン情報 空白 定義 空白 定義 ……
というように記述する。前述したようにSPFレコードにはSPFとSender IDの2つのバージョンがあるが、この指定をバージョン情報に記述する。
v=spf1
spf2.0
Sender IDではSPFとの互換性のため、「v=spf1」を「spf2.0/mfrom,pra」と解釈する。つまり、Sender IDのチェックを実施している受信側のサイトではSPFレコードをクエリしたときに「v=spf1」というバージョン番号を見つけると、それを「spf2.0/mfrom,pra」と宣言しているものとしてチェックする。
「mfrom,pra」という指定は、受信側への認証のスコープを指定するもので、「mfrom」はエンベロープの送信ドメインを、「pra」はヘッダ上の送信ドメイン（PRA）を認証する範囲として示すことになる。
この原稿を書いている時点（2005年10月）では、「spf2.0」（つまりSender ID）のSPFレコードを公開しているドメインの数に比べると、「v=spf1」（つまりClassic SPF）のレコードを公開しているサイトの数が非常に多い。ライセンスの問題などが議論されていたとき、取りあえず、ライセンスに関係しないSPFから利用していこうという動きがあったためであると思われる。
Copyright © ITmedia, Inc. All Rights Reserved.