送信ドメイン認証システムの導入：企業責任としてのフィッシング対策（2/2 ページ）

[末政延浩，ITmedia]

　また最近は、自社でメールサーバを持たず、ISPなどが提供する法人向けASPサービスなどを利用している企業も多い。このような場合は、そのサービスで送信ドメイン認証をサポートしているかどうかを事前に確認しておく。IIJや＠niftyといった大手のISPが送信ドメイン認証に対応するプランを公表しており、事業者間でも追随する動きを見せている。

目的別の注意点

●SPFレコードの公開

　送信認証が失敗したときに受信者に受信拒否されてしまわないよう、SPFレコードで宣言しておく（方法については後述）。プレスリリース用のメールや販促のキャンペーンのメール送信などを外部の業者に依頼している場合は、それらのメールの送信に利用するサブドメインを作成し、その業者が利用できるようにする。

●メーリングリスト

　自社でメーリングリストを運用している場合、まずメーリングリストに投稿されたメールの送信ドメイン認証を実施して、投稿者の確認をする。そして、その投稿メールをメンバーに再配布する際に、SPF/Sender IDであれば、エンベロープをメーリングリストにするか、またはPRAの書き換えを実施する。

　DomainKeysであれば、そのメーリングリストのドメインで再署名を実施する。こうすれば、メーリングリストのメンバーはそのメーリングリストからのメールであることを確認することができる。

モバイルユーザーの認証対策

　モバイルユーザーのサポートは、特に送信側において重要だ。出張先や自宅からいずれかのISPを使ってインターネットに接続してメールを送信する場合、前節でも説明したように自社のメールサーバを利用させる必要がある。そうしないと、送信ドメイン認証の仕組みが利用できないからだ。ただし現在、各ISPはOutbound Port 25番ブロックによる対策を実施する動きにあり（図14）、ISPに接続してそこからISP以外のメールサーバを使ってメールを送信しようとすると、一般に利用されている25番ポートが使えない可能性がある。

図14●Outbound Port 25番ブロックの仕組み。動的IPアドレス領域から直接25番ポートへSMTP送信を行う処理をブロックする

　よって、25番ポート以外に本来のメールサブミッション用のポートである587番を利用するか、SMTP over SSLのポートを利用する。また、587番のポートをモバイルユーザーにオープンにする場合は、SMTP AUTHによる認証を必須とし、許可された送信者しかそのポートを利用できないようにしておく。同時に、STARTTTLSをサポートして通信路を暗号化し、SMTP認証時のパスワードの漏えいを防いでおく。

導入後の対策

　実際に運用し始めると、送信ドメイン認証が失敗する場合のチェックが必要となる。実際には認証が成功するはずなのに失敗しているようなケースでは、何が原因なのか調査する。

　原因としては、先に説明した転送やモバイルユーザーの問題などが考えられる。それ以外に、サイト内部でも認証情報を壊してしまう原因がないかチェックし、認証成功するように電子メールの経路を改善していこう。

　また、認証に成功するがスパム率の高いメールを送信してくるドメインは、ブラックリストに入れて次回からは受信を拒否するとよい。

■末政延浩

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