Sender ID：受信者側の設定作業：送信ドメイン認証技術解説（1/3 ページ）

　前回は送信側でのSender IDの設定を説明した。Sender IDのようなIPアドレスベースの認証方式においては、送信側はDNSへのSPFレコードの公開だけで運用が開始できるので作業は比較的簡単だといえる。

　一方、受信側での作業は少し手間がかかる。実際にSPFレコードを読み出し、送信元サーバのIPアドレスを検査するプログラムを追加する必要があるのだ。今回は受信側での設定について説明する。

Sender IDの受信側での処理

　Sender IDの受信側では、認証するときに受信する、あるいはしつつある「送信ドメイン」を特定する。送信ドメインとは、Classic SPFであればSMTP通信のMAIL FROM:コマンドの引数に与えられるアドレスのドメイン部分であり、Sender IDではFrom:やSender:、Resent-From:やResent-Senderなどのメールヘッダに指定されているメールアドレスPRA（Purported Responsible Address）のドメイン部分である。

　送信ドメインを特定したら、DNSを使ってその送信ドメインのTXT（SPF）レコードを取得する。送信元のサーバのIPアドレスが取得したSPFレコードに記述されている条件にマッチするかチェックし、マッチしていれば認証成功である。

　送信元のIPアドレスの検査は受信側で行う。つまり、検査するプログラムを送信元サーバのIPアドレスが取得できる場所に配置する必要がある。一般には、ネットワークの外部から送られてくるメールを最初に受信する最も外側のMTAで実施する（図1）。

図1 サイトの構成例

認証結果の種類

　RFCには認証処理の結果として次のものが挙げられている。これはSender IDとClassic SPFで共通である。

●None

　SPFレコードが公開されていないため、認証できなかったことを示す。送信ドメイン認証では送信元についての評価が下せないため、従来どおりスパムフィルタを通すなどしてメールの扱いを決定する。結果がNoneだった場合には、メールを即座に受信拒否すべきではない。

●Neutral

　送信ドメインのSPFレコードが、例えば「v=spf1 ?all」のように定義されている場合、あるいは「v=spf1 +ip4:xxx.xxx.xxx.xxx ?all」のようにレコードの末尾が「?all」と定義されていて、先立つほかの条件にマッチせず「?all」にマッチした場合、Neutralとなる。

　RFCには、NeutralはNoneと同じように扱うべきであるとされている。また、SoftFailよりは正当性が高いものとして扱う可能性があるとも説明されている。結果がNeutralだった場合には、メールを即座に受信拒否すべきではない。

●Pass

　送信元のIPアドレスがSPFレコードにマッチし、認証に成功した場合である。送信ドメインは正当であるので、あとはその送信ドメインの評価に従ってメールを処理する。

●Fail

　SPFレコードが公開されているが、送信元のIPアドレスが「-」クオリファイヤの条件にマッチする場合である。「?all」や「~all」が末尾に設定されているSPFレコードを持つ送信ドメインのメールに対してはこの結果は発生しない。なお、RFCでは「all」の記述が省略されたSPFレコードに対して、どの条件にもマッチしない場合はNeutralになるとされている。

●SoftFail

　SPFレコードが公開されており、送信元のIPアドレスが「~」クオリファイヤの条件にマッチする場合である。RFCではFailとNeutralの中間位の扱いをすべきであるとされている。結果がSoftFailである場合には、メールを即座に受信拒否すべきではない。

●TempError

　一時的な障害で認証処理が失敗した場合である。対応としてはメールを一時エラー（4XX）で受信拒否するか、そのまま受信することになる。受信した場合は、少し厳しく扱うべきである。

●PermError

　SPFレコードは公開されているが、SPFレコードの記述に誤りがある場合などにPermErrorとなる。この結果であっても永続的な受信拒否をすべきではない。