送信ドメイン認証の基礎知識：企業責任としてのフィッシング対策（1/4 ページ）

現在の送信ドメイン認証技術には大きく分けて、IPアドレスベースのものと電子署名ベースのものの2つが存在する。その詳しい仕組みを紹介しよう。

N+I NETWORK Guide 2005年7月号よりの転載です

送信ドメイン認証を実現する2つの方式

　前回で説明したように、SMTPプロトコルでは送信者の詐称が可能であるため、スパムや詐欺メールを防ぐことが難しくなっている。送信ドメイン認証とは、そのメールが、送信者と名乗っているアドレスに示されるドメイン（送信ドメイン）から本当に送られているかどうかを確認するための仕組みだ。たとえば「user1@example.com」という送信者からメールが送られてきたとすると、本当にそのメールがexample.comというドメインから送られてきたものかどうかをチェックできるようになる。

　現在、送信ドメイン認証技術には大きく分けて、IPアドレスベースのものと電子署名ベースのものの2つが存在する。IPアドレスベースの認証方式には「Sender ID」や「SPF（Sender Policy Frameworks）」が含まれる。また、電子署名ベースのものには「DomainKeys by Yahoo!」と「Identified Internet Mail」がある。

　送信ドメイン認証は、メールの送信者のドメインを確認する技術だが、電子メールにおける「送信者」には次のものが考えられる。

・エンベロープの送信者：
　-SMTPプロトコルにおいて、MAIL FROM:の引数として与えられるアドレス

・メールヘッダ上の送信者：
　-RFC2822で規定される電子メールのフォーマットにおいて、メールヘッダに記録される送信者
　-From:、Sender:、Resent-From:、Resent-Senderなどのヘッダの値として表される

　つまり、送信者のメールアドレスの@以降が送信ドメインということになる。

IPアドレスベースの認証方式

　IPアドレス認証方式では、メールを送受信する際、SMTPプロトコルにおいてクライアント側のホストIPアドレスが重要な情報となる。

　図7にあるように、メールを送信する側では、DNSのTXT（SPF）レコードに自分のドメインからメールを送信する可能性のあるホストのリストを公開する。そして、メールを受信する側では、メールの受信中にメールの送信者のドメイン部分を取り出し、そのドメインのDNSからTXT（SPF）レコードを読み出して、メールを送信しているホストIPアドレスがそのリストに含まれているかをチェックする。もし含まれている場合は、送信ドメインと実際にメールを送信したサーバが合致するということで認証が成功する。含まれていない場合は、認証失敗である。

図7●IPアドレスベースの送信ドメイン認証

Sender IDとSPF

　Sender IDは、マイクロソフトが提案していた「Caller ID for Email」という規格と、poboxのMeng Wongという技術者が提唱したSPFを統一してできた規格である。Caller IDにはDNSにメールの扱いについてのポリシーをXML形式で定義できるようにするなどの仕様が存在したが、Sender IDではその部分にSPFレコード（後述）を使用する。

　Sender IDは当初、メールヘッダ上の送信者のみを扱うように規定していたが、SPFとの互換性を考慮して、エンベロープの送信者も扱うようになっている。またSender IDでは、SRS（Sender Rewriting Scheme）は含んでいない。Sender IDのドラフトが提出された後も、もともとのSPFの規格（Classic SPFと呼ぶ）をまとめたものとしてSPFのドラフト（*6）が発表されている。

●ヘッダ上のメールアドレスをチェックするSender ID

　IPアドレスベースの認証方式としてのSender IDとSPFとでは、送信者の扱いが異なる。Sender IDではヘッダとエンベロープの両方を、Classic SPFではエンベロープの送信者のみを扱う。Sender IDでは、このメールヘッダ上の送信者をPurported Responsible Address（PRA）と呼ぶ。

　エンベロープの送信者情報は、普通のユーザーがMUA（*7）を使ってメールを読んでいるときに目にするようなものではない。これに対して、メールヘッダ上の送信者、特にFrom:行は、どのユーザーでも「このメールを送信した人」と認識する情報である。この点から考えると、エンベロープの送信者をチェックしても詐欺メールへの対策としては一見無意味なように思える。だが、送信者アドレスを信頼できる情報として扱えるため、その情報を基にブラックリストやホワイトリストを適用できるスパム対策としては有効なのである。

　ドラフトでは、送信ドメインの認証結果に対するアクションとして、表1に示すものが規定されている。

表1●Sender ID/SPFでのアクション

●送信側はSPFレコードの公開だけ

　IPベース認証方式の場合、送信側はSPFレコードを公開するだけで開始できる。すでにSPFレコードを公開しているドメインからのメールを優先的に受信するようなISPなども出てきているので、SPFレコードを公開するだけでもメリットはある。BINDなどメジャーなDNSサーバではプログラムの変更なしにTXTレコードを扱えるので、システムに手を加えずにSPFレコードを公開できる。