メール送信者認証の仕組みを探る(2/2)

高崎達哉 2005年09月22日 10時00分

  • このエントリーをはてなブックマークに追加

前回は、メール感染型ワームやspam、フィッシングなどのメールを悪用した問題について紹介した。今回は、これらの問題を解決するために有効なメール送信者認証のための手段として、送信ドメイン認証技術について紹介する。

メール感染型ワーム/spam/フィッシングにはメール送信者認証が有効

 前回説明したように、メール感染型ワームやspamメール、フィッシングメールは送信者を偽装して送られることが多い。このため、メールの送信元が偽装されていないかどうかを確認し、偽装されている場合には、メールの受信を拒否することでこれらの行為による被害の多くを防ぐことが可能となる。

 メールの送信者を認証するための仕組みとしてまず思いつくのが、PGPやS/MIMEなどの電子署名を使ったユーザ間での認証方式であろう(図1)。しかし、これらの仕組みは、メールの送信者と受信者の両方がこれらの方式に対応していないといけないという大きな問題がある。

図1 PGPおよびS/MIMEによるメール送信者認証の仕組み

 このため、メールを受信したメールサーバが、「メールを送信してきたメールサーバは、そのメールの送信元ドメイン(送信元メールアドレスの@以降のドメイン名)の正規のメールサーバであるかどうか」を認証する「送信ドメイン認証」が注目されている。この送信元ドメイン認証を行うことで、メールを受信したメールサーバが、送信元メールアドレスのドメイン名部分の偽造をチェックすることができるのである。

 もちろん、メールアドレスのドメイン名部分は偽らずに、ユーザ名部分だけを偽ることも可能であるが、多くの組織やISPでは、SMTP AUTHやPOP before SMTPなどのユーザ認証の仕組みを導入しており、これらを組み合わせることで解決することができる(図2)。

図2 SMTP AUTH / POP before SMTP+送信ドメイン認証によるメール送信者認証の仕組み

 そこで、今回は、この送信ドメイン認証の仕組みとして提案されている、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に登録するだけで、自ドメインを偽ったメールの被害を抑えることが可能となるので、ぜひ、導入を検討して欲しい。

  • このエントリーをはてなブックマークに追加
関連キーワード
セキュリティ

関連ホワイトペーパー

SpecialPR

連載

CIO
藤本恭史「もっと気楽にFinTech」
Fintechの正体
内山悟志「IT部門はどこに向かうのか」
情報通信技術の新しい使い方
米ZDNet編集長Larryの独り言
谷川耕一「エンプラITならこれは知っとけ」
田中克己「2020年のIT企業」
大木豊成「Apple法人ユースの取説」
デジタル未来からの手紙
モノのインターネットの衝撃
松岡功「一言もの申す」
三国大洋のスクラップブック
大河原克行のエンプラ徒然
今週の明言
アナリストの視点
コミュニケーション
情報系システム最適化
モバイル
通信のゆくえを追う
スマートデバイス戦略
セキュリティ
ネットワークセキュリティ
セキュリティの論点
スペシャル
de:code
Sapphire Now
VMworld
HPE Discover
Oracle OpenWorld
Dell World
AWS re:Invent
PTC LiveWorx
デプロイ王子のテクノロジ解説!
古賀政純「Dockerがもたらすビジネス変革」
誰もが開発者になる時代 ~業務システム開発の現場を行く~
さとうなおきの「週刊Azureなう」
より賢く活用するためのOSS最新動向
「Windows 10」法人導入の手引き
北川裕康「データアナリティクスの勘所」
Windows Server 2003サポート終了へ秒読み
米株式動向
Windows Server 2003サポート終了
実践ビッグデータ
中国ビジネス四方山話
日本株展望
ベトナムでビジネス
アジアのIT
10の事情
エンタープライズトレンド
クラウドと仮想化