スパム対策の決め手、「送信ドメイン認証」のいま (3/3)

[和泉研，ITmedia]

SPFレコードの公開

　ここまでで、送信ドメイン認証がかなり普及していることを説明してきた。この流れに沿い、一般企業などでも自社サイトでSPFレコードを公開する場合、どのように進めていくべきだろうか。

　もちろん、企業でのメールシステム運用形態はさまざまで、一概に「こうだ」と言うことはできない。そこで、以下のような代表的な例を考え、それぞれに応じた導入方法を見てみよう。

1）ASPなどが提供するサービスを利用し、メールシステム全体を運用している

2）自社でメールシステムを所有し、運用している。しかし業務連絡以外の用途には利用していない

3）自社でメールシステムを所有しているが、広告／営業用のメールの送信は外部の業者に委託している

4）自社でメールシステムを所有しており、かつパブリックなメーリングリストを運用している

1）メールシステム全体をASPなどが提供するサービスで運用している場合

　SPFレコードはDNSを利用して公開する。このケースではたいていの場合、ASP側がDNSを管理しているため、利用しているASPにSPFレコードを公開可能かどうか確認し、可能であれば依頼する必要がある。

2）自社でメールシステムを持っている。業務での連絡以外の用途には利用していない場合

　DNSも自社で管理している場合、そのDNSサーバにおいて、適切なSPFレコードをTXTレコードとして公開すればいい。SPFレコードとしては、自社のメールサーバの中でも、メールがインターネットに送出される最前部にあるゲートウェイMTAのIPアドレスのリストを定義することになるだろう。DNSの管理をISPなどに委託している場合は、TXTレコードの公開が可能かどうか確認する必要があるだろう。

3）自社でメールシステムを持っているが、広告メールや営業用のメールの送信を外部の業者に委託している場合

　自社のメールシステムから送信するメールについては、前節に説明したとおりだ。だが、外部の業者に委託してメールを送信している場合は、その業者への送信用のMTAのIPアドレスを問い合わせる必要があるだろう。自社のメールシステムと区別するために、それらのメールの送信用にサブドメインを利用し、そのサブドメイン用のSPFを公開するのも良い。SPFレコードは業者のメール送信用のMTAのIPアドレスのリストを含むことになる。

4）自社でメールシステムを持っている。パブリックなメーリングリストを運用している

　この場合は、メーリングリストに投稿されたメールがメーリングリストの参加者に再配布される場合が問題になる。メーリングリストのシステムを変更し、再配布する際のエンベロープ送信者をそのメーリングリストのシステムのアカウントに変更するとともに、Sender IDでの認証を可能にするために、「Resent-sender:」や「Sender:」ヘッダを利用してメーリングリストの管理用アドレスなどを指定する必要がある。

　これ以外にもさまざまな形態が考えられるし、解決方法もいろいろあるが、まずは、自社からインターネットに送信される可能性のあるメールサーバの実際のアドレスを徹底的に調べるところから始めていこう。

【PR】守りと攻めの電子メールセキュリティ ── 安全で効果的な真の「ビジネスツール」実現の鍵とは

ビジネスに不可欠なコミュニケーションツールとなった電子メールだが、一歩使い方を間違えれば企業に大きなリスクをもたらしかねない。メールは企業の活動を示す「証拠」の役割を果たす。コンプライアンス、そして情報漏えい対策の観点から、どのように保存し、管理していくべきだろうか。同時に、依然として増加し続けるスパムやフィッシングからの保護も無視できない課題だ。内と外、2つの課題をどのように乗り越えていくのか、その対策法を探ろう。

関連リンク

• 4406 Sender IDM: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT=40428 bytes) (Status: EXPERIMENTAL)
• 4407 Purported Responsible Address in E-Mail Messages. J. Lyon. April 2006. (Format: TXT=14387 bytes) (Status: EXPERIMENTAL)
• 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. M. Wong, W. Schlitt. April 2006. (Format:TXT=105009 bytes) (Status: EXPERIMENTAL)
• 4409 Message Submission for Mail. R. Gellens, J. Klensin. April 2006. (Format: TXT=34911 bytes) (Obsoletes RFC2476) (Status: DRAFT STANDARD)
• DomainKeys draft：http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-06.txt
• DKIM BASE draft：http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-08.txt
• DKIM SSP draft：http://www.ietf.org/internet-drafts/draft-allman-dkim-ssp-02.txt
• Japan E-mail Anti-Abuse Group：http://jeag.jp/
• 送信ドメイン認証についてのJEAGレコメンデーション：http://jeag.jp/news/pdf/SenderAuthRecommendation.pdf
• Outbound Port25 BlockingについてのJEAGレコメンデーション：http://jeag.jp/news/pdf/op25b20060223.pdf
• 総務省「フィッシングの現状及びISPによるフィッシング対策の方向性」の公表：http://www.soumu.go.jp/s-news/2005/050810_4.html

共有する

プリント／アラート

オンラインムック Special

- PR -

Special

- PR -