SPFとDKIMの問題点

S25R方式は、送信元の逆引き名がサーバっぽい名前ならばメールサーバと認めてメールを受け入れようというやり方である。メールサーバに対するその推定は87%の確率で当たり（初期の偽陽性判定率は13%と推計されるので）、残りはホワイトリストでカバーする。すなわち、不完全ながら、ドメイン認証によって不正なMUAから受信側MTAへの投函を阻止する方策の代用手段だと言うことができる。
　望ましいドメイン認証方式がインターネットに普及した時、S25R方式は不要になる。ドメイン認証方式としては、SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）が有望とされている。しかし、どちらも理想的なものではないと思うと前回述べた。その理由を説明しよう。

■SPF
　ドメインのDNSで、そのドメインを送信者アドレスとするメールを送信するホストを宣言する方式である。たとえば私は、自サイトのDNSのgabacho-net.jp.ゾーンファイルに

gabacho-net.jp. IN TXT "v=spf1 +ip4:219.163.213.18 ~all"

と記述することによって、送信者アドレスのメールドメインがgabacho-net.jpであるメールはIPアドレス219.163.213.18のホストからのみ送信されることを宣言している。もしgabacho-net.jpドメインを送信者アドレスとするメールが別のホストから送信されたら、受信側ではそれを不正メールと判断できる（ただし、「~all」は、転送によって他ホストから送信されることがないとも限らないから、疑ってもよいが完全な受信拒否はしないでほしいという意味である。他ホストから送信されることは絶対ないという宣言は「-all」と書く）。送信側としての設定は簡単なので、設定は普及しつつある。
　しかし、今のSPFはスパマーが裏をかきやすい仕様である。「"v=spf1 +all"」と書くことによって、すべてのホストが送信元として正当だという宣言ができてしまう。だからスパマーは、スパムの送信者アドレス用にドメインを取ってそのような不正な宣言をすることにより、ボットから送信させたスパムに受信側のSPFチェックをすり抜けさせることができてしまう。
　受信側で「+all」という宣言を信用しないように対処したとしても、まだ抜け道がある。たとえば「+ip4:61.0.0.0/8」のようにネットマスク指定をすることによって、ボットネットを含む広い範囲のIPアドレスブロックを正当な送信元だと宣言することもできてしまう。
　S25R方式は97%以上のスパムを阻止できるが、抜け道のあるSPFで同等以上の阻止率を維持できるとは期待しにくい。

■DKIM
　送信側で電子署名をメールヘッダに埋め込み、受信側で送信元の公開鍵を取得してメールの正当性（確かにそのドメインから送信されたものであること）を検証する方式である。メッセージの正当性を主張する手段としては強靭なセキュリティを持つ。
　しかし、技術的に高度であることが普及の阻害要因になる。MTAのオペレーションがどうにかできるくらいの、スキルの高くないメールシステム管理者も決して少なくないのに、そういう人たちがさらに鍵管理の知識も持たなければならないのである。普及のためには、Postfixの標準インストールでDKIMが組み込まれるくらいに実装が簡単にならなければならないだろう。
　それに、もしDKIMが普及して、正しい電子署名のないメールをことごとく受信拒否しても問題ない世の中になったとしても、パフォーマンスの問題がある。S25R方式は、怪しい送信元に対しては、HELO、MAIL FROM、RCPT TOコマンドまで送信させた段階で、DATAコマンド以降のメッセージ本体を伝送させずに応答コード「450」（再送要求）で蹴飛ばす。次から次へと来るスパムアクセスを軽快に蹴りまくる。DKIMでは、メッセージの正当性を検証するためにメッセージ本体の伝送を受け入れなければならない。蹴飛ばし方はおのずと鈍重になる。回線上のごみトラフィックが減らないことにもなる。

　結局のところ、SPFもDKIMも、受信側としてのスパム対策のために望ましいドメイン認証方式ではないと思う。これらを用いることが世の中の流れになるなら、私は、送信側としてそれらに対応することにやぶさかでない（実際、SPFはもう設定している）。しかし、ほかにもっと良いドメイン認証方式が現れて普及しない限り、私はS25R方式を捨てることはないだろう。

（関連記事）
送信ドメイン認証はスパムに勝てないだろう
送信ドメイン認証は誰にとって有益か