「安心できるメール」配信のためにサービス事業者ができること：企業責任としてのフィッシング対策（2/5 ページ）
フィッシングではエンドユーザー側の対策に注意が集まりがちだが、なりすまされるサービス事業者の側にできることはないだろうか？ まずメールでの対策から考えてみよう。
●SPF/Sender ID
SPFは、送信者側のドメインのネームサーバに、そのドメインからメールを送る可能性のあるメールサーバのIPアドレスなどの情報（SPFレコード）を登録しておき、受信者側のメールサーバがメールの受信時に、送信者側のネームサーバに登録された正規のメールサーバから送信されたものであるかどうかを確認するものだ（図1）。
Sender IDは、SPFとCaller-ID for Emailと呼ばれる技術を統合してできた技術であるが、Sender IDにもSPF部分が含まれるため、従来のSPFを「SPF Classic」と呼ぶこともある（本稿では以下、SPF ClassicとSender IDをまとめて「SPF」と呼ぶ）。
サービス事業者がSPFに対応するには、管理しているネームサーバに自社のメールサーバのIPアドレスなどの情報を追加するだけでよい。この手法を用いる際には、例えばキャンペーンメールなどの送信を外部の事業者に委託する場合、外部事業者のメールサーバもSPFレコードに登録しておく必要があることを注意点として付け加えておく。
●DKIM（DomainKeys）
DKIMは、Yahoo!の提案していた「DomainKeys」と、Cisco Systemsの「IIM (Identified Internet Mail)」が統合されてできた規格である。
DKIMでは、送信者側のメールサーバにおいて、公開鍵暗号技術を用いてメールのヘッダーと本文から電子署名を生成し、付随する情報とともにヘッダー内に格納する。これと同時に、電子署名を生成する際に使用した秘密鍵に対応した公開鍵を送信者側のネームサーバに登録しておく。受信者側のメールサーバでは、送信者のドメインのネームサーバから公開鍵を取得し、電子署名が正しいことを検証することによって、なりすましメールでないことを確認する（図2）。
サービス事業者がDKIMに対応するためには、自社のネームサーバに公開鍵情報を追加すると同時に、メールサーバにて電子署名を生成して付与する必要がある。
●どちらの方式がいいの？
それでは、SPFとDKIMのどちらが、サービス事業者にとってより適切な対策なのだろうか？
これまで見てきたように、SPFでは送信者側の対応としては、単にネームサーバにSPFレコードと呼ばれる情報を追加するだけでよいので、導入は非常に容易である。しかし、受信者側でメールを転送しているような場合、転送元のメールサーバはSPFレコードに登録されていないため、転送先のメールサーバで受信を拒否されてしまう事態が想定される（*1）。
これに対して、DKIMは送信元で電子署名されたことを確認するため、途中でメールが転送されていたとしても支障はない。その半面、サービス事業者側のメールサーバで電子署名の作成・付与を行うように対応する必要があり、SPFに比べて導入の手間がかかる。また、電子署名の生成にはCPUの負荷がかかるため、場合によってはメールサーバの増強も必要になるかもしれない。
さらに、DKIMはメールの転送には対応できるものの、メーリングリストなどで受信者に届く前にヘッダーや本文に変更が加えられた場合には、最終的な受信者側のメールサーバで電子署名の検証に失敗するため、受信を拒否されることが考えられる。
このように、SPFとDKIMはどちらも一長一短なので、送信者としてはどちらか一方だけ対応すればよいというものではなく、両方への対応が必要だといえる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Copyright © ITmedia, Inc. All Rights Reserved.