送信ドメイン認証の導入後に想定される問題点とその対策

| | Comments (0) | TrackBacks (0)
迷惑メールのほとんどは、送信元情報を詐称して送られています。このような状況を踏まえて、2007年10月号のHDEコラム - 迷惑メール撲滅への第一歩を踏み出そう!では、送信ドメイン認証で送信元を認証することが、迷惑メール対策に非常に有効であるとご紹介しました。

また、弊社の小椋のブログ、テクノロジー解放日記 - SPF対応企業が11月に急増でも書かいているように、NTTドコモが2007年11月1日からSPFによるなりすましメールの拒否機能を無料提供しています。NTTドコモのなりすましメールの拒否機能は、SPFを登録しておらず、正当なメールサーバーから送信されたことが判別できないメールもなりすましメールと扱われるため、送信ドメイン認証の導入は必須となったと言えるかもしれません。

今回は、送信ドメイン認証を導入後、営業の方などが、社外から会社のメールアドレスを使用して、メールを送信する場合に想定される問題点とその対策をご紹介します。

営業の方などが、社外(ISP業者のネットワーク)から会社のメールアドレスを使用してメールを送信する場合に、ISP業者のメールサーバーを使用すると、送信ドメイン認証において送信元情報詐称と判断されたり、会社のメールサーバーで全てのメールをアーカイブすると決められていても、会社のメールサーバーを経由しないため、アーカイブの対象にならないということが発生します。

このような問題点は、会社のメールサーバーを使用することで解決できます。

しかし、近年、ISP業者では迷惑メール対策の一環として、ISPが提供するメールサーバー以外のメール受付ポート(25番ポート)との通信を禁止するOP25B(Outbound Port 25 Blocking)を採用しているため、会社のメールサーバーのメール受付ポートにはアクセスできません。

このため、VPN環境を用意するか、会社のメールサーバー側で、メール受付ポートとは別のポート(Submission)でメールを受け付けるようにした上で、SMTP AUTHで正規ユーザーのメールだけを受けるという対応が必要になります。
また、SubmissionポートでのSMTP AUTH時に、ユーザーIDやパスワードが通信データとして流れるため、SSLによる通信データの暗号化を行い、経路上での盗聴を防ぐことも忘れずに行う必要があります。

メールクライアント側では、Submissionポート、SMTP AUTH、SSLを使用するように設定しておけば、使用しているネットワークが社内ネットワークであるか、ISP業者のネットワークであるかということを意識することなく、常に会社のメールサーバーを使用してメール送信できます。

HDE Anti-Spam 2 for Gatewayでは、Submissionポートでのメール受付SMTP AUTH、SSLによる通信データの暗号化といった環境を、非常に簡単に構築できます。
評価版もございますので、是非お試し頂ければと思います。

0 TrackBacks

Listed below are links to blogs that reference this entry: 送信ドメイン認証の導入後に想定される問題点とその対策.

TrackBack URL for this entry: http://lab.hde.co.jp/blog/mt-tb.cgi/32

Leave a comment

About this Entry

This page contains a single entry by published on April 8, 2008 10:55 AM.

ERRORログをメールで通知する ~tailコマンド編~ was the previous entry in this blog.

Google App EngineでHello World!! + ローカルLinux環境 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.