表2に挙げるドメインでは実際、すでにSPFレコードを公開している。
Sender IDとSPFでは、メールを送信する可能性のあるホストのリストをDNS上に公開する。これを「SPFレコード」と呼ぶ。SPFレコードは、DNSのResource RecordのSPFとして定義することが推奨されているが、すべてのDNSサーバやクライアントでこのレコードが扱えるわけではないので、TXTリソースレコードでの公開も可能になっている。現在、SPFレコードを公開しているほとんどのサイトが、TXTレコードで公開している。
また、SPFレコードにはバージョンがある。Classic SPFで定義されたものがv1で、現在Sender IDで定義されているものがv2.0である。文法などは基本的に同じだ。
たとえば、あるドメインでは1つのメールサーバからしかメールを公開しない場合、
v=spf1 +ip4:123.123.123.123 -all
という具合に定義する。
●SPFの文法
SPFレコードは、次のように構成する。
バージョン情報 空白 定義 空白 定義....
<(※定義は複数指定することができる)
上記における定義は、ディレクティブかモディファイア(*8)で構成される。ディレクティブにメール送信についてのポリシーを定義し、モディファイアには、たとえば「redirect」などSPFの記述を簡単にする言語機能やポリシーの説明文が入る。ディレクティブにおいては、次のようにポリシーを定義する。
クオリファイァ メカニズム
「メカニズム」にはマッチするホストの条件を記述し、「クオリファイァ」にはメカニズムに該当するホストからのメールをどのように扱うべきかを指定する。クオリファイァは省略可能で、デフォルト値は"+"である。
・クオリファイァ
"+" Pass:認証成功
"-" Fail:認証失敗
"~" SoftFail:導入期などの過渡的な状態で、認証できないメールも存在する
"?" Neutral:認証情報を公開しない
メカニズムとモディファイアをそれぞれ表3に示す。また、ドメインスペックなどにはマクロを利用することが可能だ。送信元のIPアドレスなどをチェック時にダイナミックにポリシーに当てはめ、ポリシーを簡潔に定義できる。利用可能なマクロについては、Classic SPFのドラフトを参考にしてほしい。
●SPFのバージョン情報
Classic SPFでポリシーを定義する場合、レコードの先頭に「v=spf1」を付ける。Sender IDの現在のバージョンの場合は、「spf2.0」である。
Sender IDの書式でポリシーを記述する場合は、バージョン情報に続けて、スコープIDを指定する。これは、認証対象を指定する役目も持っており、「mfrom」と「pra」が与えられる。たとえば、"spf2.0/mfrom,pra"などと指定する。「mfrom」はClassic SPFでの認証対象(つまりエンベロープの送信者)を扱うことを示し、「pra」ではSender IDのPRA(ヘッダ上での送信者)を扱うことを指定できる。両方指定することも可能だ。
Sender IDでは下位互換性を保つため、「v=spf1」のレコードは「spf2.0/mfrom,pra」と同じであるように解釈する。公表する側で、PRAでの認証を行ってほしくない場合は、"v=spf1..."のレコードとともに"spf2.0/mfrom...."というレコードを公開することで、受信側にPRAによる認証を行わないように指定できる。
SPFレコードは、DNSへはドメインに対するTXTレコードとして定義する。ここでは、SPFレコードの例をいくつか紹介しよう。
example.com. IN TXT "v=spf1 +mx -all"
この例では、exmaple.comのmxレコードに登録したサーバのみからメールを送信する可能性があると宣言したことになる。したがって、それ以外のホストから送信されたメールは、受信拒否してもよいという意味になる。
たとえば、仮想ドメインでまったくメールを送信する可能性のない場合は、
example.com. IN TXT "v=spf1 -all"
とすることで、xxxx@example.comというアドレスのメールがけっして送信されないことを示せる。
*8 ディレクティブとモディファイア ディレクティブは、送信ホストにマッチする条件を記述する命令文。モディファイアは、レコードの参照方法などを変更する制御文。
Copyright © ITmedia, Inc. All Rights Reserved.