サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

インバウンドチェックの手法と手順について

ニフティ株式会社
経営戦略室
木村孝
2007年3月

1. インバウンドチェックとは
2. インバウンドチェックとフィルタリング
3. 送信ドメイン認証結果によるインバウンドチェックとフィルタリング
4. 送信ドメイン認証結果を使ったラベンリング
5. インバウンドチェックの場合の法的留意点
6. インバウンドチェックとフィルタリングの提供方法
7. デフォルト・オンの考え方

1.インバウンドチェックとは

インバウンドチェックとは、メール受信側において、受信する(インバウンドの)メールについて迷惑メールかどうかをチェックすることを意味します。これはメール送信側で、送信されるメールが迷惑メールかどうかの判定を行うアウトバウンドチェックと対をなすものです。

アウトバウンドチェックの代表例がOP25B(アウトバウンドポート25番ブロック)ですが、これに対応する受信側のインバウンドチェックはIP25B(インバウンドポート25番ブロック)です。ともにメール送信に使われるプロトコルを意味するTCPポート番号25のパケットについて、発信元や宛先のIPアドレスを見てチェックします。すなわちアウトバウンドチェックの場合は、動的IPアドレスからメール送信者がISPのメールサーバを経由せずに相手に直接メールを送信することを防止するため、宛先がそのISPのメールサーバであるかをチェックします。これはそのやり方が迷惑メール送信によく用いられる手法であるためです。これに対しIP25Bの場合は、メール送信元のIPアドレスが動的IPアドレスかどうかをチェックします。通常のメールサーバのIPアドレスは固定IPアドレスであるのに対し、迷惑メール送信者は動的IPアドレスを使ってメールを送信する事例が多いことに着目したチェック方法です。(注1)

(注1) 動的IPアドレスはISPが主に個人の会員に対してブロードバンド、ナローバンドの接続に際して付与するIPアドレスです。通常一般の利用者はその動的IPアドレスを使うパソコンから、自分が契約するISPなどのメールサーバ経由でメールを送信しますので、動的IPアドレスから直接受信者に対してメールを送信することはありません。

インバウンドチェックはあくまでも、受信側でメールをチェックし迷惑メールかどうかを判定する行為ですので、通常はその後にフィルタリングやラベリングといった処理が付随します。ここでの受信側というのは、メールを受信するメールサーバ単体ではなく、メールを受信するシステム全体を指します。

2. インバウンドチェックとフィルタリング

インバウンドチェックはフィルタリング等の処理の前提として、フィルタリングと一体に行われるのが通常のため、法的にはフィルタリングの一種として捉えられています。現在迷惑メール対策の手法としては、数多くのフィルタリングの技術が使われています。(注2 一覧)しかし、その中でもインバウンドチェックという独立した判定に意味を持たせるのは以下の2つです。

  • IP25B(インバウンドポート25番ブロック) (前述)
  • SPFやSender-ID、DKIMといった送信ドメイン認証

(注2) フィルタリングの例

  • メール送信者のFromアドレスによるフィルタリング
  • 宛先、件名、ヘッダ情報によるフィルタリング
  • 本文に含まれるキーワードによるフィルタリング
  • ブラックリストなど外部データベースを参照してのフィルタリング
  • グレーリストによるフィルタリング
  • 悪意のあるプログラムがダウンロードされるURLが記載されているメールのフィルタリング
  • HTTPメールのフィルタリング
  • 言語別のフィルタリング
  • シグネチャーによるフィルタリング
  • ベイジアン理論によるフィルタリング
  • ヒューリンスティックによるフィルタリング
  • 迷惑メール判定サービスによるフィルタリング
  • ユーザー設定のホワイトリスト、ブラックリストによるフィルタリング

3. 送信ドメイン認証結果によるインバウンドチェックとフィルタリング

迷惑メールを防止するための送信ドメイン認証技術は、先行してメール送信側、すなわちDNSサーバや送信側メールサーバでの実装が普及してきました。2006年末の段階では相当程度普及して来ていると見られています。しかし、メールに送信ドメイン認証の情報が付加されただけでは、迷惑メールを排除するには十分ではありません。メールの受信者が、受信する前に受信側のメールサーバでチェックし、フィルタリングをしなくては実質的に受信する迷惑メールの数を減らすことはできません。そのため、受信側メールサーバでの送信ドメイン認証結果を使ったインバウンドチェックとフィルタリングの仕組みの実装が必要になります。当然、インバウンドチェックのためには、送信側において送信ドメイン認証自体が普及していることが前提になります。

フィルタリングには、送信ドメイン認証により迷惑メールと判定されたメールの処理について、

  1. サーバ上の通常のメールとは別な領域に保存するもの
  2. メールの受信そのものを拒否するもの

の2種類があります。迷惑メールフォルダなどのサーバ上の別な領域に保存されている場合は、受信者はWebメールでログインすることによって、フィルタリングされたメールを確認することができます。万が一通常のメールが迷惑メールと誤判定されて、迷惑メールフォルダに振り分けられた場合には(これをFaulse Positiveと言います)、それを救い出すことができます。しかし、迷惑メールと判定されたメールをそもそも受信メールサーバで受信拒否している場合には、受信者はそのメールを知るすべがありません。その意味において、同じフィルタリングでも方法により、実装にあたっては異なる手続きや基準があります。すなわち、単なる振分けではなく受信拒否を行う場合には受信者の同意がより積極的に求められるなど、慎重な手続きが必要です。

4. 送信ドメイン認証結果を使ったラベンリング

インバウンドチェックの判定結果の利用法としてはもうひとつ、Webメールで認証結果を表示したり、ヘッダに認証結果を挿入するラベリングというものがあります。ヘッダに認証結果を挿入されると“Authentication-Results:”で始まる行が追加され、ここに送信ドメイン認証の結果がスコアとして「pass(認証成功)」や「fail(認証失敗・送信元メールアドレスは詐称されている)」といった形で記述されます。ラベリングの場合はメールそのものの受信には影響がないため、フィルタリングに比べてより容易な手続きで採用することができます。

すでに一部のISPでは送信ドメイン認証結果を利用したインバウンドチェックを実装し始めています。

● インバウンドチェックを実施しているISPの例(2007年3月現在)

ヤフー  2005年9月13日
Yahoo!メールでDomainKeys*認証結果を表示、検証結果を“Authentication-Results”ヘッダに記述。
(*その後DKIMという規格に吸収されました)

IIJ  2006年3月30日
IIJ4U、IIJmioで送信ドメイン認証フィルタ機能の提供を開始 ユーザーが受信したメールのヘッダに“Authentication-Results:”で始まる行を追加し、ここに送信ドメイン認証の結果がスコアとして「pass(認証成功)」、「fail(認証失敗・送信元メールアドレスは詐称されている)」といった形で記述され、メールの振り分けなどに利用することができます。

KDDI、沖縄セルラー  2007年3月を目処(予定)
送信ドメイン認証技術「SPF/Sender ID」を利用したメールフィルターを導入。

5. インバウンドチェックの場合の法的留意点

ISPなどの電気通信事業者の場合、他人の通信を媒介するものとして、通信の秘密の義務が課せられているため、フィルタリングは利用者の許諾無しには行うことはできません。そのため、インバウンドチェックについても基本的に利用者(受信者)からの委託に基づいて行うことになります。

企業や大学などは電気通信事業者ではありませんので、電気通信事業法に定める通信の秘密の義務や検閲の禁止といった義務は課せられません(ただし、総務省は有線電気通信法に定める通信の秘密の保護は課せられると解釈しています)。企業や大学のメールの場合、受信者は法的には企業や大学といった法人とみなされます。そのため、メールサーバ(及び、その管理者)は、他人の通信を媒介する立場ではなく、自らが受信者であると解釈されます。そのため、受信側メールサーバにおけるインバウンドチェックやフィルタリングについても、個別の利用者である受信者個人の同意を得ることなく行うことができると一般には理解されています。

企業や大学が行うメールサービスなどが電気通信役務に該当するかなどについては、総務省の情報通信政策に関するポータルサイトのマニュアルハンドブック支援メニューにある「電気通信事業参入マニュアル[追補版]― 届出等の要否に関する考え方及び事例 ―(PDF)(総合通信基盤局電気通信事業部)」<http://www.soumu.go.jp/joho_tsusin/manual.html>をご参照ください。

6. インバウンドチェックとフィルタリングの提供方法

先述のように、送信ドメイン認証のインバウンドチェックも広い意味でのフィルタリングに分類されるものですので、電気通信事業者がインバウンドチェックを行うことは通信の秘密に抵触します。したがって、基本的に利用者(ここでは受信者)の個別の同意(サービスの利用申込)が必要となります。その裏として、利用者の同意無しにフィルタリングを行うと違法となります。緊急避難という考え方もありますが、常時適用されるフィルタリングには緊急避難は適用されません。

しかし、申し込んだ人のみにしかフィルタリングを提供してはいけないか、というとそうでもなくて、後述しますように、フィルタリングをデフォルト・オンで提供することも一定の要件を満たせば可能です。また、認証結果を表示するだけのラベリングは、メールを排除していないということで、最低限のことに留まる事から、個別の同意は必ずしも必要とはされていません。

インバウンドチェックによるフィルタリングの適用については以下の方法があります。

  • オプションのサービスの設定者に対してのみ行う
  • 全員にサービスとして提供するが、デフォルトはオフにする
  • 全員にデフォルト・オンで提供するが、利用者が個別に解除もできるようにする
  • 全員に一律に提供し、設定は解除できない

また、フィルタリングの適用にあたっては、その旨を受信者に対し説明し、約款や利用規約などで包括的な合意の形をとる必要もあります。一方、送信者に対しても、ISPのポリシーとして迷惑メールのフィルタリングを行い、その条件を満たしたメールを受信拒否することを宣言することも必要と思われます。

7. デフォルト・オンの考え方

総務省はデフォルト・オンについて以下のような考え方を公表しています。

「電子メールの受信時期については様々な考え方があるため、今後検討を重ねていく必要がある。例えば、 1)受信サーバに到達したという受信と、 2)実際に受信者の端末に到達したという受信の2段階があると考えれば、受信サーバまでは届けるが、実際に受信者の端末に届くかどうかまでは保証しないといった、発信者の通信の自由の制限を2段階にわけた整理も可能と考えられる。

フィルタリングと電気通信事業法との関係を整理する際には、電気通信事業法第4条(通信の秘密)とともに、第3条(検閲の禁止)についても検討が必要であろう。電気通信事業者が、加入者の申込みを受けて行うフィルタリングは、電気通信事業者と加入者との間の回線利用契約に基づく回線利用権の一内容としての、加入者による通信選択権の行使に応じて行われるものと考えられる。

発信者にも、自己の発信した通信について、あて先である受信者まで送信される利益があるので、電子メールのフィルタリングサービスが正当業務行為として正当化されるには、発信者の利益の制約を最小限にする必要がある。具体的には、『受信者が受信したくないと考える範囲』と、『実際に受信されない範囲』ができるだけ同一になるような措置が講じられていなければならないと考えられる。」

平成18年3月17日 電気通信事業分野におけるプライバシー情報に関する懇談会(第19回会合)議事要旨
http://www.soumu.go.jp/joho_tsusin/d_syohi/060317_1.html

また、総務省は電気通信事業者が行う電子メールのフィルタリングと電気通信事業法第4条(通信の秘密の保護)の関係について「初期設定をフィルタリングオンの状態で提供するための条件」を以下のように公表しています。

  • 利用者が、いったんフィルタリングサービスの提供に同意した後も、随時、任意に同意内容を変更できる状態(設定変更できる状態)であること
  • フィルタリングサービス提供に対する同意の有無にかかわらず、その他の提供条件が同一であること
  • フィルタリングサービスの内容等が明確に限定されていること
  • 通常の利用者であれば当該サービスの提供に同意することがアンケート調査結果等の資料によって合理的に推定されること
  • 利用者に対し、フィルタリングサービスの内容等について、事前の十分な説明を実施すること(事業法第26条に規定する重要事項説明に準じた手続により説明すること)

平成18年1月23日電気通信事業分野におけるプライバシー情報に関する懇談会(第18回会合)議事要旨
http://www.soumu.go.jp/joho_tsusin/d_syohi/060123_1.html

また、総務省は「迷惑メール対策技術導入を検討されている事業者の方へ」として、インバウンドチェックの技術導入についていろいろと注意点を公開していますので、参照してください。

http://www.soumu.go.jp/joho_tsusin/d_syohi/jigyosha.html

 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先