送信ドメイン認証で考慮すべき問題点企業責任としてのフィッシング対策(2/2 ページ)

» 2006年03月24日 16時15分 公開
[末政延浩,ITmedia]
前のページへ 1|2       

●電子署名方式は本当に転送に強いか

 Sender IDやSPFなどと比較すると、DomainKeysやIIMは転送に強いといえる。たとえ転送されても、署名の対象になったヘッダとメール本文のデータが変化しなければ、受信側で署名の検査を行えるからだ。

 ただし、ヘッダやメール本文のデータが正規化処理によって回避できないほど変化した場合は、やはり認証に失敗する。また、たとえばメーリングリストサーバなどで題名(「Subject:」ヘッダの値)を書き換えてしまったり、中継メールサーバでMIME(*13)のContent-Encodingが変化したりすると、やはり認証に失敗することになる。送受信側ともに、なるべく多くのメールサーバを経由しないように気を使う必要がある。したがって、電子署名方式の場合も、送受信ともにやはりサイトの最も外側で署名および認証の処理を実施することが望ましい。

モバイルユーザーのサポート

 出張先や自宅から会社のメールアドレスを使ってメールを送信するときに、会社のメールサーバが外部ネットワークからのメール送信をサポートしていないため、代わりにISPの提供するメールサーバを使って送信することができる。これは、前述したSMTPの柔軟性を利用したものだ。つまり社外にいる場合は、会社のメールサーバをいっさい経由することなく、会社のメールアドレスでメールを送信することになる。当然、Sender IDやDomainKeysなどの仕組みを経由しないため、送信ドメイン認証は成功しない(図12)。

図12 図12●モバイルユーザーで認証失敗する例。自宅などからのダイヤルアップでISPのメールサーバを利用して会社のアドレスでメール送信すると、SPFレコードとメールサーバのIPアドレスがマッチせず認証が失敗する

 個人情報保護法施行で企業システムのセキュリティがますます重要になっている現在では、このような方法によるメール送信は残念ながら推奨できない。送信ドメイン認証を導入していても、誤って自宅からISPのメールサーバを使って顧客の個人情報を含むリストを添付したメールを送信するようなことが起きたら、せっかく会社のメールシステムで設定した監査のポリシーやさまざまなセキュリティ対策がまったく無意味なものになってしまうからだ。詳しくはSection 4で説明するが、よりセキュアな方法で、外部ネットワークから会社のメールサーバを利用してメールの送受信ができるような手段を用意する必要がある。

スパマーもSPFレコードを公開する

 SPFレコードの公開は、実はスパム送信者でも可能である。DomainKeysで電子署名することもできる。実際に、相当数のスパム送信者がSPFをすでに公開しているといわれている。ただ、それによりスパム送信者は自分のメールサーバの所在を知らせると同時に、自分のドメインを送信ドメインにしてスパムを送信していることになる。つまり、送信者のドメイン名が詐称できなくなるのだ。そうなると、受信する側としては、スパマーのドメインのブラックリストを作成して受信拒否するだけでよい。

 また、フィッシングなどにおいても送信ドメインを詐称できなくなるので、エンドユーザーに注意を喚起しやすくなる。大手のフリーメールアカウントプロバイダーが送信ドメイン認証を開始(*14)すれば、そこから送られてきたと見なされるメールについて、送信ドメイン認証に失敗したものは、ほぼ詐称メールだと判断できるわけだ。

●reputation/accreditationサービス

 送信ドメイン認証はあくまでも、あるメールに与えられた送信側のドメインが、本当にそのメールを送信したドメインなのかを確かめるための仕組みである。スパム送信者でも送信ドメイン認証を利用できるため、認証されたドメインに対してそのドメインが「よいドメイン」か「悪いドメイン」かを評価するための仕組みについても検討されている。それが「reputation」や「accreditation」といったサービスだ。

 reputationサービスは、DNSブラックホールリストなどと同じく、参加者からのフィードバックでドメインの評価を決定する。accreditationサービスは、送信者がreputationサービスを提供する会社にお金を預けることで、信用できるドメインにリストされ、メールの送信に関して「悪い」振る舞いをすると、その預託金から罰金を取るという仕組みである。

■末政延浩

 センドメール シニアコンサルタント。ISPや企業などの電子メールサイト設計および構築に従事。オープンソースのsendmailはJUNET時代から。6年前から商用版のSendmail製品を扱う。送信者認証技術の早急な確立と適用を強く願う。


*13 MIME Multipurpose Internet Mail Extension。電子メールでASCII文字列以外の言語による文字や音声、動画などのマルチメディアデータを変換(エンコード)するために規格化されたメッセージフォーマット。RFC 2045〜2049で規定されている。

*14 送信ドメイン認証を開始 すでにYahoo!メールやGmailではDomainKeysの署名を実施しており、HotmailではSPFレコードを公開している。

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.