スパム対策の決め手、「送信ドメイン認証」のこれから（1/3 ページ）

送信ドメイン認証の実装を進めていく中で、意外な注意点も浮かび上がってきた。新たなスパム送信者の手口などとともに紹介していこう。

[和泉研，ITmedia]

　以前の記事でも紹介したが、スパムメールやフィッシング詐欺対策として有望視されている方法が送信ドメイン認証だ。主な技術として、IPアドレス方式の「SPF」や「Sender ID」、電子署名方式の「DomainKeys」「DKIM」などがあり、確実に実装／導入が進んでいる。

　続くこの記事では、実装を進めていく中で浮かび上がってきた注意点や新たなスパム送信者の手口などについて紹介していこう。

SPFを公開する際の注意点

　前回の記事で紹介したとおり、SPFレコードを公開するドメインは確実に増加している。ただそれに伴い、間違ったSPFレコードを公開しているケースもまた多く見られるようになった。

　SPFレコードの文法は簡単だ。だがタイプミスなどが1つでもあると、レコード全体が無効とされ、認証結果は「PermError」（恒常的エラー）となってしまう（認証結果のステータスについては過去の記事参照）。

　PermErrorと判断された場合でも、それだけでメールを受信拒否されることはないはずだ。しかし、そもそもの送信ドメイン認証の意味がまったくなくなってしまう。作成時には、SPFレコードの作成を手伝ってくれるWebサイトなどを利用したい。一例として、OPENSPFやMicrosoftが提供しているものがある。

　さらに、公開前には十分に試験を行い、間違いのないことを確認した上で、公開するようにしよう。

　またSPFレコードには「include」や「redirect」など、記述を集約したり簡単にするステートメントがある。これらを適切に利用し、必要以上に複雑なSPFレコードを作成しないように気をつけよう。

　記述を複雑にすればするほど、タイプミスや文法上のミスなどを起こしてしまう可能性は高まる。また、あちこちにリンクしているようなレコードを記述すると、それだけ受信側でのDNSのクエリの回数が増えるため、なるべくシンプルに記述すべきだ。次のように、IPアドレスのリストが羅列してあるだけというレコードで十分効果的である。

xxxx.com	text = "v=spf1 ip4:xxx.xxx.xxx.xxx ip4:yyy.yyy.yyy.yyy ip4:zzz.zzz.zzz.zzz ~all"

* この例では「xxxx.com」からのメールは、「xxx.xxx.xxx.xxx」と「yyy.yyy.yyy.yyy」「zzz.zzz.zzz.zzz」の3つのIPアドレスから送られた場合に認証に成功する

・エラーメールの扱いには細心の注意を

　こちらから送った覚えのないメールについて、「送信できなかった」ことを示すエラーメールが届いたという不審な経験をした方も多いのではないだろうか。

　自分のドメインがスパムの送信元として詐称され、悪用されるケースは珍しくない。このスパムメールが宛先不明になると、それに対するエラーメールが詐称されたアドレス、すなわち自サイトのメールアドレスに返されることになる。スパムは、送られた側にだけでなく、エラーメールが返信される側にも二次的な被害を及ぼしているのだ。こうした跳ね返り（バウンス）のエラーメールは、1通だけならばともかく、サービスプロバイダーのように大量のメールを配送しているところでは無視できない量になる。

　SPFについても同様の配慮が必要ではないかという議論が生まれてきた。

　つまり、SPFレコードを公開しているサイトについて、そこから送信されたと称するメールが何らかの理由で配送できず、エラーメールを返すような場合があったとしよう。ここでもし、送信ドメイン認証の結果が明らかに失敗していたならば、エラーメールを返さないようにして、SPF公開サイト側の負荷を減らそうという議論が進んでいる。これも、送信ドメイン認証の効果的な利用例の1つだ。

電子署名認証方式の注意点

　次に、電子署名方式のDomainKeysやDKIMを導入する場合の注意点を挙げておこう。

　DomainKeysにしてもDKIMにしても、送信側と受信側の両方での対応が必要だ。したがって前述のIPアドレス方式に比べると、導入の敷居は若干高い。企業でこの電子署名方式を導入する場合、送信側で署名を加えて電子メールを送り出すことにより、自社のメールのセキュリティ（完全性、信憑性）を高めたいという目的によることが多いのではないだろうか。

　この方式では、メールのヘッダや本文のデータを基に電子署名を作成する。配送途中で署名対象のデータを壊さないように、署名は最もインターネット側に配置されたMTA上で実施しよう。

・メーリングリストの扱い

　メーリングリストでは、投稿されたメールの題名に通し番号が追加されたり、本文末尾にメーリングリストの説明が追加されるなど、メールのヘッダや本文に変更が加えられる場合が多い。このような場合、もともとの投稿者が付与した電子署名は無効になってしまう。解決策としては、投稿を受信した時点で投稿者の署名を使って認証を行い、次に参加者に再配布する際、Sender:ヘッダにメーリングリストの制御用アドレスなどを追加した上で、再署名して送信する方法がある。

・DomainKeysと署名対象のヘッダの指定

　DomainKeysを運用した中でわかってきたことだが、メールの配送途中でも、メールに新しいヘッダが追加される場合がある。それも、ヘッダの上部に追加されれば問題ないのだが、DomainKey-Signatureヘッダより下の本文側に追加されると、追加されたヘッダが署名データの中に挿入されてしまう。このため、せっかくの署名が壊れてしまうという問題が頻繁に起こった。

　これを回避するために、DomainKeysでは署名したヘッダを指定するタグがある（図3）。このタグを使ってヘッダを限定しておかないと、認証が成功しない場合が多い。DKIMでは、このタグを用いたヘッダの限定が必須になった。

図3●DomainKeys-Signatureヘッダ

　さらに、どのヘッダを署名の対象にするかという点にも注意が必要である。

　当初、メーリングリストでの題名変更によって生じる問題を回避するために、Subject:ヘッダを署名の対象外にするというアイデアもあった。だが、フィッシング対策の重要性を考えると、Subject:ヘッダを署名から外すのはお勧めできない。

　逆に推奨できるのは、Receivedヘッダなど、転送中に変更される可能性がある項目を、あらかじめ署名対象から外しておくという方法だ。このとき、本文の先頭から何バイトまで署名対象とするかという細かな設定も可能だ。署名作成や照合に関する処理を軽減するため、本文すべてではなく、ある程度現実的なサイズを設定するようにしよう。