スパム対策の決め手、「送信ドメイン認証」のいま(3/3 ページ)
3年ほど前から議論されはじめ、2006年以降普及が進んでいる送信ドメイン認証。スパム対策の決め手とされるこの技術の最新動向を紹介する。
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:」ヘッダを利用してメーリングリストの管理用アドレスなどを指定する必要がある。
これ以外にもさまざまな形態が考えられるし、解決方法もいろいろあるが、まずは、自社からインターネットに送信される可能性のあるメールサーバの実際のアドレスを徹底的に調べるところから始めていこう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
【PR】守りと攻めの電子メールセキュリティ ── 安全で効果的な真の「ビジネスツール」実現の鍵とは
ビジネスに不可欠なコミュニケーションツールとなった電子メールだが、一歩使い方を間違えれば企業に大きなリスクをもたらしかねない。メールは企業の活動を示す「証拠」の役割を果たす。コンプライアンス、そして情報漏えい対策の観点から、どのように保存し、管理していくべきだろうか。同時に、依然として増加し続けるスパムやフィッシングからの保護も無視できない課題だ。内と外、2つの課題をどのように乗り越えていくのか、その対策法を探ろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
関連リンク
- 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
関連記事
- スパム対策の決め手、「送信ドメイン認証」のこれから
送信ドメイン認証の実装を進めていく中で、意外な注意点も浮かび上がってきた。新たなスパム送信者の手口などとともに紹介していこう。 - 送信ドメイン認証の基礎知識
- 送信ドメイン認証で考慮すべき問題点
- 送信ドメイン認証システムの導入
- 国内発迷惑メールの大幅減目指す、JEAGが対策「提言書」
- Sender ID:送信者側の設定作業(@IT)
Copyright © ITmedia, Inc. All Rights Reserved.