メール送信者認証技術 SPF/Sender ID についてお勉強

お勉強の背景に関しては　「迷惑メール対策 OP25B（Outbound Port25 Blocking）についてお勉強」　に書いたとおりですが、迷惑メール対策としての SPF/Sender ID についてもいろいろ勉強したのでそのまとめです。（DomainKeys については思いのほかエントリが長くなったのでまた別の機会で・・・）まずは参考になったサイトの紹介から。

• Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
• Sender ID: Authenticating E-Mail
• DNS関連技術の最新動向 - SPF/DomainKeysとは
• Sendmail 社 - 送信者認証技術の導入におけるレコメンデーション
• メール送信者認証の仕組みを探る(2/2):スペシャル - ZDNet Japan
• DNS逆引きチェックによるスパム対策は百害あって一利無し
• メール交換機でのスパム排除 - 送信者認証方式
• Sender ID：送信者側の設定作業 − ＠IT
• MTA/AntiSPAM/Sender ID を導入してみる - Pocketstudio.jp Linux Wiki

さてここから SPF/Sender ID についてのまとめです。ほとんどが上記サイトの内容を自分なりに理解したものをまとめただけですけど。。。これが丸一日作業だったりするのは・・・orz

SPF / Sender ID / DomainKeys とは何か？

共にスパム対策のための技術です。
現在の主要な認証方式はすべて、メールの送信元のドメインを認証する方法で策定されています。認証のために一般のエンドユーザが何らかの作業を行う必要はなく全てサーバ側で完結します。認証方式には大きく２種類あり、

• IP ベース認証方式（メールを送信しているホストのアドレスを検査するもの）　→　SPF / Sender ID 方式
• 暗号化ベースの認証方式（メール上に設定してある電子署名を検査するもの）　→　DomainKeys 方式

があります。両者ともに送信者のドメインの DNS レコードに情報を公開し、その公開された情報をメールの受信サーバ側で検査することで成り立っています。暗号化ベースの認証方式では送信者は送信するメールのすべてに電子署名する必要があります。RMX++ 方式なんてのもあるようですが気にしなくても良いでしょう。さてそれぞれの認証方式についてもう少し詳細にまとめていきます。

SPF(Sender Policy Framework) 方式 / Sender ID 方式

SPF は現在もっとも多く利用されている送信ドメイン認証の仕組み。SMTP 通信のなかでやり取りされるエンベロープのバウンスアドレス（MAIL FROM コマンドの引数にあたるアドレス）を検査します。メール受信サーバは受信中のメールの MAIL FROM の送信ドメインをを元に DNS からドメイン名情報を取得して SPF レコードの内容とメールの送信元 IP アドレスを照合する。照合の結果 IP アドレスが SPF レコードの内容にマッチすれば認証成立となる。

一方、Sender ID 方式はマイクロソフト社が提唱したもので SPF との互換性を持っています。認証としては SPF 方式のエンベロープの送信ドメインのチェックに加えてヘッダ情報（Purported Responsible Address＝PRA）での認証も行います。PRA の認証順序以下の順序で判定されます。

Resent-sender:　→　Resent-from:　→　Sender:　→　From:

より詳しい情報は rfc4408 / rfc4406 の原文をみるとよいでしょう。

• SPFに関しては rfc4408 として策定されています。
• Sender ID に関しては rfc4406 として策定されています。

さて話をより実務的な方向へ。現状よく使われている SPF レコードの標準的なフォーマットは以下のようなものになります。

最初の　v=spf1　は SPF のバージョンを指定するためのものです。その後にこのドメインのメールアドレスを送信元とするメールが送信される ip アドレスやそのアドレス範囲を指定します。最後の　-all　は必ず付与するべき設定で、それ以外は認証ＮＧにして下さいという意味です。

それ以外の設定項目として A レコード、MX レコード、PTR レコードによる設定が可能ですが現状使っている大手サイトは少ないようです。SPF レコードの調査方法は nslookup で取得可能です。例えば yahoo! ならこんな感じ。

[drk@srv01 ~]$ nslookup -q=txt yahoo.co.jp
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
yahoo.co.jp     text = "v=spf1 include:spf01.yahoo.co.jp include:spf02.yahoo.co.jp ~all"

Authoritative answers can be found from:
yahoo.co.jp     nameserver = dnsg01.yahoo.co.jp.
yahoo.co.jp     nameserver = ns10.yahoo.co.jp.

上記のように include 設定になっていたらその実体を見に行けば詳細がわかる。

[drk@srv01 ~]$ nslookup -q=txt spf01.yahoo.co.jp 
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
spf01.yahoo.co.jp       text = "v=spf1 ip4:124.83.147.0/24 ip4:124.83.153.0/24 ip4:124.83.155.0/24 ip4:124.83.165.0/24 ip4:124.83.168.0/24 ip4:124.83.170.0/24 ip4:124.83.178.0/23 ip4:124.83.181.0/24 ip4:124.83.195.0/24 " "ip4:124.83.200.0/24 ip4:202.93.80.0/23 ip4:202.93.83.0/24 ip4:202.93.84.0/23 ip4:202.93.86.0/24 ip4:202.93.88.0/24 ip4:202.93.90.0/24 ip4:203.141.34.0/24 ip4:210.80.241.0/24 ip4:211.14.15.0/24 ip4:211.14.23.0/24 ~all"

Authoritative answers can be found from:
yahoo.co.jp     nameserver = dnsg01.yahoo.co.jp.
yahoo.co.jp     nameserver = ns10.yahoo.co.jp.
dnsg01.yahoo.co.jp      internet address = 211.14.12.10

さて次に実際に SPF レコードをどうやって作るかですが ip4 だけ使って記述するなら簡単ですね。その他の項目も使っていろいろ書きたい場合は、ウィザード形式で生成することができる便利な web サービスがあります。SPF 方式の方が普及率が高いので SPF Wizard を使って SPF レコードを生成しておけば良いと思います。

それぞれの項目の意味を知るには　Sender ID：送信者側の設定作業 − ＠IT　が参考になります。

さて、自宅サーバの場合の実作業まで話を落とし込むと、BIND 使っている場合は SPF レコードを ZONE 情報ファイルの MX レコードの下あたりに TXT レコードとして追加すればＯＫです。

$ cat /var/named/****.jp.zone
$TTL 86400
$ORIGIN ****.jp.
@       IN      SOA      ns.****.jp. (
        2002012301      ; Serial No.
        3600            ; refresh 1hr
        900             ; retry 15min
        604800          ; expire 1w
        86400           ; min 24hr
        )
        IN     NS              ns.***.jp.
        IN     MX      10      ns.***.jp.
        IN     TXT     "v=spf1 ip4:***.***.***.*** -all"
・・・・

もしも Sender ID 形式で記述しないならば、

・・・・
        IN     TXT     "v=spf2.0/mfrom,pra ip4:***.***.***.*** -all"
・・・・

と記述しておけば良いかと思います。ちなみに Sender ID では SPF との互換性のため、「v=spf1」は「spf2.0/mfrom,pra」と解釈されます。「mfrom,pra」という指定は受信側への認証のスコープを指定するもので、「mfrom」はエンベロープの送信ドメインを、「pra」はヘッダ上の送信ドメイン（PRA）を認証する範囲として示すことになります。

さて設定をしたら BIND を再起動して自分自身を nslookup -q=txt してテストしてみましょう。正しく TXT レコードが弾ければ旨く設定できていることが確かめられます。実際にウチのサーバの場合のテストです。

ちなみに DNS として VALUE DOMAIN を使っているのですが、ちゃんと設定することが可能でした。説明もいつの間にか追加されていました。契約時に見たときには無かったと思うのですが・・・。

さて、書くのも随分と疲れてきました。読むのも随分と疲れてきているころかと思います。最後の話題です。

SPF/Sender ID によるメール送信者認証の問題点

最後に問題点についても説明をしておかなければなりません。詳細は　DNS逆引きチェックによるスパム対策は百害あって一利無し　が結構詳しいのですが、

DNS の仕様上１つの IP アドレスに設定可能なドメイン名は基本１つだけ。

↓　言い換えると・・・

１つのサーバで複数のドメインを運用する（レンタルサーバで独自ドメインやるケース）の場合は認証 NG になってしまう。

__修正__
はてブのコメントで以下のような指摘を頂きました。僕の理解がまだ足りていないようです。
SPF は DNS に取りに行くので同一 IP 上のメールサーバを複数のドメインで利用出来ますよ(別々のドメインの SPF が同一のメールサーバを指定する事はアリ。)

となると本来スパムでないメールであっても上記のような理由で SPF/Sender ID にパスできない場合はスパムとしてメールが届かないことになります。従って表向きはSPFレコードの確認にパスしない場合は破棄するとかエラーとして返すとか謳っているところもいくつかあったりするのですが実際はそのまま正常に送信できる場合も多いようです。

例えば Docomo の特定接続サービスを本業で契約しているのですが、SPF レコードを定義して下さいと半年ほど前に通達が来た記憶があります。もちろん現在は SPF レコードを追加済みなわけですが、ついていないときも問題なく送信できていた記憶があります。特定接続を契約していない通常のメール送信では明らかに SPF 認証によるメール破棄はなされてませんね。もし SPF 認証でメールが破棄されていたら大変な問題になると思います。ちなみに KDDI も SPF 認証エラーは破棄すると書いてありますね。どちらも大量配信時にのみ発動するものなのかもしれませんが実体は不明です。

• 送信ドメイン認証（Sender ID／SPF）について | サービス・機能 | NTTドコモ
• KDDI au: EZwebへメール送信する際の注意事項 > 送信ドメイン認証SPFレコードについて

さて、話は一番初めに戻りまして Yahoo! メールの対応についてです。そもそもその検証を行うための勉強だったので。

まずは SPF レコードを何も設定していないサーバから送信してみた結果。受信箱で正しく受信できました。

次に SPF レコードが設定されたサーバから送信してみた結果。受信箱で正しく受信できました。

次にどう見てもスパムメールであるもので受信箱で受信されてしまっていたもの。SPF 認証は fail ステータスですがメールは破棄されないことが確認できました。

ちなみに SPF 認証が error ステータスでも受信箱に入っているのもありました。

というわけで、どうやら Yahoo! メールの場合は SPF 認証は行っているもののフィルターアルゴリズムとしては組み込まれてなさそうだという予想が立ちました。

おしまい。