前回は、メール感染型ワームやspam、フィッシングなどのメールを悪用した問題について紹介した。今回は、これらの問題を解決するために有効なメール送信者認証のための手段として、送信ドメイン認証技術について紹介する。
メール感染型ワーム/spam/フィッシングにはメール送信者認証が有効
前回説明したように、メール感染型ワームやspamメール、フィッシングメールは送信者を偽装して送られることが多い。このため、メールの送信元が偽装されていないかどうかを確認し、偽装されている場合には、メールの受信を拒否することでこれらの行為による被害の多くを防ぐことが可能となる。
メールの送信者を認証するための仕組みとしてまず思いつくのが、PGPやS/MIMEなどの電子署名を使ったユーザ間での認証方式であろう（図1）。しかし、これらの仕組みは、メールの送信者と受信者の両方がこれらの方式に対応していないといけないという大きな問題がある。
このため、メールを受信したメールサーバが、「メールを送信してきたメールサーバは、そのメールの送信元ドメイン（送信元メールアドレスの@以降のドメイン名）の正規のメールサーバであるかどうか」を認証する「送信ドメイン認証」が注目されている。この送信元ドメイン認証を行うことで、メールを受信したメールサーバが、送信元メールアドレスのドメイン名部分の偽造をチェックすることができるのである。
もちろん、メールアドレスのドメイン名部分は偽らずに、ユーザ名部分だけを偽ることも可能であるが、多くの組織やISPでは、SMTP AUTHやPOP before SMTPなどのユーザ認証の仕組みを導入しており、これらを組み合わせることで解決することができる（図2）。
そこで、今回は、この送信ドメイン認証の仕組みとして提案されている、SPF、Sender-ID、DomainKeysについてそれぞれ紹介する。
SPFの仕組み
SPFは、現在、もっとも多く利用されている送信ドメイン認証の仕組みである。SPFでは、SMTPの「MAIL FROM」コマンドで指定された送信元メールアドレスのドメイン名部分の偽造をチェックする。具体的には、DNSで、そのドメイン名に対するSPFレコードを検索し、実際にメールを送信してきたメールサーバがSPFレコード中に記述されていなければ、送信元メールアドレスが偽造されていると判断する。
DNSのSPFレコードは、以下のように記述されている。
| xxx.ne.jp. IN TXT "v=spf1 +mx +a:mail.xxx.ne.jp -all" |
「v=spf1」はSPFのバージョンを指定するためのものである。その後は、このドメインのメールアドレスを送信元とするメールが送信される正規のメールサーバが指定されている。「+mx」は、このドメイン名に対するMXレコードを検索して得られたメールサーバを示し、「+a:mail.xxx.ne.jp」は、ホスト名が「mail.xxx.ne.jp」のメールサーバを示している（これらの「+」は記述しなくても構わない）。最後の「-all」はこれらのメールサーバ以外からは送信されないことを示している。
Sender-IDの仕組み
Sender-IDは、先に紹介したSPFと、マイクロソフトが提案していたCaller-IDという仕組みを統合した仕組みである。Sender-IDでは、SPFで提供されていた、SMTPの「MAIL FROM」コマンドで指定された送信元メールアドレスの認証（MFROM認証と呼ばれる）に加えて、メールの「From」ヘッダなどに記述されている送信元メールアドレスの認証（PRA認証と呼ばれる）も行う。
Sender-IDでは、SPFと同様のSPFレコードを使用する。Sender-IDで使用するSPFレコードは、以下のようになっている。
| xxx.ne.jp. IN TXT " spf2.0/mfrom,pra +mx +a:mail.xxx.ne.jp -all" |
基本的には、SPFと同様であるが、最初のバージョン番号を示す箇所が、SPFでは「v=spf1.0」となっていたのに対し、Sender-IDでは「spf2.0」となっているところが異なる。また、「spf2.0/」の後に、このレコードがMFROM認証とPRA認証のどちらに対応しているのかを指定する。両方に対応している場合は上記のように「spf2.0/mfrom,pra」と記述する。
Sender-IDはSPFと互換性があり、「v=spf1」から始まるSPFレコードが存在した場合は、それを「spf2.0/mfrom,pra」と読み替えて処理を行う。
DomainKeysの仕組み
DomainKeysは、Yahoo!が提案している送信ドメイン認証の仕組みであり、メールに送信元ドメインの電子署名を添付し、それを受信側メールサーバで検証することでドメインの偽造を検出する。
DomainKeysでは、送信元メールサーバは、メールのヘッダに、以下のような「DomainKey-Signature」というフィールドを追加し、そこに署名を格納する。
| DomainKey-Signature: a=rsa-sha1 s=abc; d=xxx.ne.jp; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+ yuU4zGeeruD00lszZVoG4ZHRNiYzR; |
また、検証用の公開鍵をDNSにあらかじめ以下のように登録しておく。
| abc._domainkey.xxx.ne.jp. IN TXT "g=; k=rsa; p=MHww ... IDAQAB" |
受信側のメールサーバは、「DomainKey-Signature」フィールドの内容から対応する公開鍵をDNSから取得し、その署名を検証する。検証に成功すれば、そのドメインの正規のメールサーバからメールが送信されたことが確認できたことになる。
以上、今回は、SPF、Sender-ID、DomainKeysといった、代表的な送信ドメイン認証技術について紹介した。しかし、これらの技術は普及してこそ効果が出てくるものである。特にSPFやSender-IDは、SPFレコードをDNSに登録するだけで、自ドメインを偽ったメールの被害を抑えることが可能となるので、ぜひ、導入を検討して欲しい。
