フォールバック検出による spam 対策システムの実装 Implementation of

フォールバック検出による spam 対策システムの実装
Implementation of Anti-spam System via MX Fallback Detection
北川　直哉†　鈴木　常彦‡
Naoya Kitagawa　Tsunehiko Suzuki
世界中で広く利用され，我々の生活に深く定着した電子メールだが，昨今でも依然として
spam による被害は留まるところを知らず，深刻な問題を抱えている．本研究は，正常な送信
者と spam 送信者によるメール配送時の振舞いの違いを解析した結果， spam は RFC5321 で
定められた MX fallback を行わないことを確認した．この特徴を利用して，フォールバック
の検出による spam 対策システムの実装を行った．本手法は，
Three-way Handshake によ
る TCP コネクションの確立までに MX fallback の検出を行い，配送失敗によるメールの再送
を用いることなく判定を行うため， spam 対策による受信の遅延を抑えることができる．
1. はじめに
電子メールは長年にわたって重要な情報通信手段
として広く利用されており，我々の社会活動に必要
不可欠な存在となっている．しかしながら，不特定
多数の利用者に向けて日々大量に送信されるスパム
メールによる被害は留まるところを知らず，深刻な
問題を抱えている．電子メール利用者が日々受信と
削除を繰り返すのが煩わしいという被害は氷山の一
角に過ぎず，さらに深刻な問題は，大量に送信され
るスパムメールによる膨大な量のトラフィックが，
ネットワークやメールサーバに大きな負荷をかけて
おり，インターネットを麻痺させかねない脅威とな
っている点である．Messagelabs 社による調査[1] に
よると，2010 年全体における全ての電子メールのう
ち，スパムメールの割合は 89.1%を占め，2009 年の
87.7%からさらに増加している．世界中で通信され
ている電子メールのほぼすべてがスパムメールであ
ることから，メールサーバでは如何にして効率的か
つ正確に大量のスパムメールの中から正常なメール
を救い出すことができるかが重要な課題である．
本研究は，正常なメール送信者の利用する Mail
Transfer Agent（以降 MTA）と spam 送信者の利用
するメール送信プログラムによるメール配送時の再
送戦略について詳細に調査し，それらが分別可能で
あるか評価を行った．この結果，spam 送信者によ
†名古屋大学大学院情報科学研究科
Graduate School of Information Science,
Nagoya University
‡中京大学情報理工学部
School of Information Science and Technology,
Chukyo University
るメール配送では MX fallback を行わないという特
性が確認され，その特徴を利用した spam 判別シス
テムの開発を行った．
2. MX fallback
SMTP に関する取り決めである RFC5321[2]によ
り，メール送信者は配送先ドメインの MX レコード
のリストに従い，その優先度順に配送をリトライで
きなければならないと定められている．例えばアク
セスの集中によるサーバのダウン等，何らかの障害
により Primary MX に対して配送が成功しなかった
場合に，次に優先度の高い Secondary MX に対して
再送を行う動作が MX fallback である．信頼あるメ
ール配送を行うために， MX fallback はメール送信
者にとって必須の動作であると言える．
本研究では，メール送信ホストが MX fallback を
行う機能を有しているかを調べるため，図 1 のよう
に 3 台のメールサーバを使用した．メール送信者は
はじめに，最も優先度の高い Primary MX に対して
配送を試みるが，Primary MX では固定的に Threeway Handshake の SYN に対して RST を応答するこ
とにより接続に失敗させ，Secondary MX に対して
配送を行うもののみを受信する環境で行った．した
がって，優先度順に正しく再送を行えば最も優先度
の低い Tertiary MX に対して接続を試みることはな
いはずであるが，送信ホストの異常な振舞いを調査
するために Tertiary MX も設置し，Primary MX と
同様に SYN に対して RST を応答する．
このようなメールサーバの仕様は特殊なものであ
るが，Primary MX への SYN に対して RST を応答し
た場合と沈黙した場合，さらに tcpserver で
deny（Three-way Handshake 後の FIN）を行った
場合を比較した結果，SYN に対して RST を応答する
場合が最も効率的に Secondary MX に再送（ MX
fallback）を行わせることができることが先行研究
[3]で確認されている．
多くのドメインからのメール配送を実験環境で受信
し，解析を行うことが望ましい．本調査では大学，
携帯電話各社，国内外ウェブメール各社，プロバイ
ダ等，計 22 ドメインのメールアカウントを利用して
調査環境宛てにメールを送信し，フォールバック検
査を行った．
Sender's SMTP server
3.3 調査結果
上記調査対象に対する再送動作の調査結果は表 1
のようになった．本調査の範囲において，最初に
Primary MX 以外に対して配送を行う動作や，フォ
ールバックを行わない送信ホストは見られず，規定通
りに正しく振舞うことを確認した．また，いくつか
のドメインで Primary MX への送信時とは異なる IP
アドレスから Secondary MX に再送を行う動作が見
られたが，表 1 および表 2 では区別なく表記した．
(1)SYN
(3)SYN
(4)pass
×
(2)RST
Primary MX
Secondary MX
Tertiary MX
図 1：実験サーバの構成
Primary=>Secondary
20
91.0%
Primary=>Primary=>Secondary
1
4.5%
Primary=>Primary=>Primary=>Secondary
1
4.5%
Total
3. 正常な送信ホストの MX fallback 調査
3.1 調査の目的
本研究は，spam 送信ホストによるメール配送では
MX fallback を行わないという仮説[3][4]に注目し，
正常な送信ホストと spam 送信ホストを，それぞれ
のセッション時の振舞いの違いによって分別を行え
るか調査を行った．はじめに，正常な送信ホストは
正しくフォールバックを行う機能を有しているか，
もしくは行わないことがあるのか調査を行い，さら
に彼らは Primary MX への接続に失敗してからフォ
ールバックして Secondary MX に再送を行うまでに，
どのような動作で，またどの程度の時間以内に再送
を行うのか等，再送戦略の特徴を得るためのデータ
を収集した．
また，これらのデータから独自に「フォールバッ
クを行ったと見なす条件」を定義し，その条件と
spam 送信ホストによる振舞いを照らし合わせること
により，本研究の仮説通りに spam 送信ホストによ
るメール配送では MX fallback を行わないか調査を
行った．なお，これらの調査には前章で論じた図 1
の実験環境を使用した．
3.2 調査の対象
正常な送信ホストが利用している MTA によるメー
ル配送時の再送戦略の解析を行う方法として，主要
な MTA を自前のサーバで動作させ，実験環境に向け
てメールを送信する方法が考えられるが，実際のメ
ールサーバ運用において，各 MTA のデフォルト設定
のまま利用しているのではなく，様々な独自の設定
がなされている場合が考えられる．したがって，現
在実際に利用されているメールサーバの MTA による
振舞いを正確に調査するには，現在利用されている
22 100.0%
表 1：再送動作の調査結果
次に，最初の Primary MX に対する SYN の送信か
ら Secondary MX への再送までに要した時間は表 2
のように，非常に高速に行われることを確認した．
1 秒未満
20
91.0%
1 秒（2 秒未満）
2
9.0%
Total
22 100.0%
表 2：再送までに要した時間
3.4 MX fallback と見なす条件
3.3 項で論じたように，再送動作の振舞いに若干
の違いが観測されたものの，すべての送信ホストが
フォールバックを行う機能を有することを確認した
この結果から，MX fallback を行ったと見なす条件
を次のように定める．
(1) 最初の送信は Primary MX
(2) Primary MX へのリトライは 3 回以内
(3) Secondary MX への送信は試行開始から 2 秒以内
最初に Primary MX に送信を行わない場合，すな
わち優先度順に送信を行わない送信ホストは RFC に
よる規約に反するものであり，正しい配送を行って
いるとは言えない．また本調査の結果，TCP 接続を
許可しない Primary MX への再試行回数（SYN の再
送回数）は最大で 3 回であったことや，Primary MX
への接続失敗後に Secondary MX への送信を行うま
でに要する時間は非常に短いという特徴があること
を踏まえ，上記のように 3 つの条件を定めた．
これらの条件は，本調査の範囲においては全ての
送信ホストが満たす条件であることから，正常な送
信者による再送戦略の基準として妥当なものである
と言える．
4. spam 送信ホストの MX fallback 調査
前章で述べた調査環境と同様の環境の spam 収集
サーバを用いて，spam 送信者によるメール配送の特
徴を詳細に調査した．この調査では， 3.4 項で定め
たフォールバックと見なす条件を spam 送信者によ
るメール配送ではどの程度満たすかを調べることで，
正常な送信ホストと比較して分別可能か判断を行う．
spam 送信ホストの MX fallback 調査は，筆者が
過去に調査を行った[5]が，Primary MX への接続失
敗後に異なる IP アドレスから再送が行われた場合に
対応していなかったため，本論文ではこれに対応さ
せ，新たに調査を行った．異なる IP アドレスからの
再送の判断には DNS 逆引き検索を行い，権威サーバ
が一致していれば同一サイトからの配送であると見
なした．
対象は，2010 年 4 月から 2011 年 3 月までの 12
ヶ月間に調査環境に送信された spam とし，各月毎
の検査結果を表 3-A〜C にまとめた．
本検査に利用したプログラムでは，配送動作を次
の 10 項目に分類した．
(1) Primary=>Secondary かつ 2 秒未満で再送
(2) Primary*2=>Secondary かつ 2 秒未満で再送
(3) Primary*3=>Secondary かつ 2 秒未満で再送
(4) (3),(4),(5)の動作で，異なる IP アドレスから再送
(5) 1 度目の送信で Secondary MX に送信
(6) 1 度目の送信で Tertiary MX に送信
(7) Primary=>Secondary かつ 2 秒以上で再送
(8) Primary*2=>Secondary かつ 2 秒以上で再送
(9) Primary*3=>Secondary かつ 2 秒以上で再送
(10) Primary へ送信後，正しく MX fallback しない
上記の項目のうち，1〜4 までがフォールバックを
行ったと判定されたものであり，前章で述べた全て
の正常な送信ホストはこのいずれかに含まれる．こ
れらの合計に基いた MX fallback を行った送信ホス
トの割合を，表 3 中において”Fallback ratio(%)”と
併せて示した．
また上記の項目のうち，(10)の条件には例えば次
のような動作が含まれる．
A. Primary のみに対して何度も再送
B. 1 度のみ Primary に送信し，再送が行われない
C. Primary に送信後，Tertiary に再送
D. Primary に 4 回以上再送後，Secondary に再送
（Primary MX への再送回数の条件に不合格）
なお，項目中の”*2”などの表記は再送回数を示し，
例えば ” Primary*2=>Secondary” という表記は
Primary(RST)=>Primary(RST)=>Secondary という
送信順序だったことを意味する．また，同様の内容
を表すものとして表 3 中において”P*2=>S”のように
記したが， ” P” は Primary MX ， ” S” は Secondary
MX を意味する．
2010
Apr
May
Jun
Jul
Aug
(1) Fallback (P => S)
46
31
18
21
31
(2) Fallback (P*2 => S)
12
4
8
4
5
(3) Fallback (P*3 => S)
1
6
0
2
1
(4) Fallback (other IP)
31
27
26
39
16
(5) Secondary Direct
2345
1514
1889
1934
1498
(6) Tertiary Direct
1039
330
402
364
445
(7) Time over (P => S)
4
3
0
2
8
(8) Time over (P*2 => S)
8
4
0
10
10
(9) Time over (P*3 => S)
59
38
6
10
21
(10)Not Fallback (P=> ?)
2861
1359
1380
1697
1752
Total Senders
6406
3316
3729
4083
3787
Fallback ratio (%)
1.40
2.05
1.39
1.62
1.40
Dec
Jan
表 3-A：配送動作の検査結果
2010 / 2011
(1) Fallback (P => S)
Sep
Oct
Nov
13
8
49
18
20
(2) Fallback (P*2 => S)
0
0
11
6
1
(3) Fallback (P*3 => S)
1
0
1
0
1
(4) Fallback (otherIP )
0
0
146
0
2
1357
3142
3890
1257
125
267
213
231
142
79
4
2
1
0
1
(8) Time over (P*2 => S)
6
11
8
1
1
(9) Time over (P*3 => S)
26
11
32
24
20
(10)Not Fallback (P=> ?)
1303
1120
1031
812
1062
Total Senders
2977
4507
5400
2260
1312
Fallback ratio (%)
0.47 0.18 3.83
表 3-B：配送動作の検査結果
1.06
1.83
(5) Secondary Direct
(6) Tertiary Direct
(7) Time over (P => S)
2011
(1) Fallback (P => S)
Feb
Mar
Total / (%)
18
11
284 / (0.72%)
(2) Fallback (P*2 => S)
0
1
52 / (0.13%)
(3) Fallback (P*3 => S)
0
0
13 / (0.03%)
(4) Fallback (other IP)
5
3
295 / (0.75%)
(5) Secondary Direct
270
126
19,347 / (48.94%)
(6) Tertiary Direct
255
71
3,838 / (9.71%)
(7) Time over (P => S)
7
0
32 / (0.08%)
(8) Time over (P*2 => S)
0
1
60 / (0.15%)
(9) Time over (P*3 => S)
20
11
278 / (0.70%)
(10)Not Fallback (P=> ?)
636
318
15,331 / (38.78%)
Total Senders
1211
542
39,530 / (100.00%)
Fallback ratio (%)
1.90 2.77
表 3-C：配送動作の検査結果
1.63%
次に，フォールバックを行ったもの（表 3：(1)(2)
(3)(4) ），最初に Secondary MX に送信（表 3 ：
(5)）及び Tertiary MX に送信（表 3：(6)）したもの，
時間切れのもの（表 3：(7)(8)(9)），フォールバック
しないもの（表 3：(10)）の割合の推移を図 2 で示し
た．
図 2：配送動作の割合の推移
spam 送信ホストのうち，MX fallback を行うもの
の割合は調査全期間において約 1.63%と非常に少な
く，前章で述べた正常な送信ホストと比較して明ら
かな振舞いの違いを確認できた．また，図 2 から読
み取れるように，spam の配送動作は時期によって大
きな変化が見られ，例えば 2011 年に入ってからは
Secondary MX 直撃の配送が激減している．
しかしながら，全ての期間において MX fallback
を行う spam は安定して非常に少ない状態で推移し
ているため，この特徴を利用した spam 対策は有効
であると言える．
5. Firewall を用いた MX fallback 検出システム
5.1 従来の spam 対策との違い
本システムと類似した手法で，現在広く利用され
ている”Greylisting”[6]や，”お馴染みさん方式”[7]な
ど，初めてメールを受信する相手に対して， SMTP
サーバから一時エラーの応答を行うことで spam の
判別を行う方法がある．これらの手法の問題点は，
数十分から一時間程度経過後に再送信されたメール
を受信するため，受信までに非常に長い時間が必要
となる点である．これに対し本手法では，前章まで
に論じた正常な送信ホストと spam 送信ホストの再
送動作の違いを利用することで，メールの受信まで
に生じる遅延を数秒程度に抑制することができる．
5.2 実装方法の検討
前章までの調査に用いた環境では， Secondary
MX は常に TCP 接続を許可しているため，この方法
のみでは Primary MX への接続失敗後の再送である
という判定を行うことができず，最初に Secondary
MX に対して送信を行う spam（表 3：(5)）を受信し
てしまうことになる．このような環境でフォールバ
ック判定を行うためには，Secondary MX において
Primary MX の Handshake のログを参照し，事前に
SYN が送られているか確認を行わなければならない．
本研究では，参照を行わずにフォールバック後の
Secondary MX への再送であることを検出するシス
テムを，ファイアウォールを利用して実装する．
フォールバックを行ったもののみを Secondary
MX で受信したい場合， Primary MX ，Secondary
MX のいずれのサーバも接続を許可しない状態で待
機しておき，Primary MX で SYN を受信した瞬間に
Secondary MX の接続を許可するようにファイアウ
ォールの対応を変化させることでフォールバックを
検出することができると考えられるが，表 2 に記し
たように，多くの場合 Primary MX への接続失敗後
の Secondary MX への再送は非常に高速に行われる
ため，Secondary MX への再送までにファイアウォ
ールの書き換えが間に合わず，送信ホストが正しく
フォールバックを行っても受信できない場合が多く
なるため，この方法は得策ではない．
5.3 応答遅延による MX fallback 検出
前項の問題を解決するために本研究で開発したシ
ステムでは，Primary MX で SYN を受信すると遅延
を開始させ，それと同時に該当する送信ホストの IP
アドレスを一時ホワイトリストに登録する．応答の
遅延には FreeBSD 独自の機能である dummynet を
利用して実装した．また，Secondary MX，Tertiary
MX ともに接続を許可しない．
一時ホワイトリストに登録された送信ホストに対
して，Primary MX は SYN に対して RST を応答し，
Secondary MX は接続を許可するように対応が変化
する．このとき送信ホストが再送を行うことで，フ
ォールバックを行ったメールのみを Secondary MX
で受信することができる．なお，本システムにおい
て一時ホワイトリストは，送信ホストと本受信サー
バが TCP 接続を確立し，SMTP セッションを開始す
るまで生存していれば良いため，登録後 10 秒後に削
除する．また，一部の MTA は同一メールの配送で異
なる IP アドレスから再送を行うため，暫定的な対応
であるが，該当する IP アドレスのクラス C に属する
IP アドレスを一時ホワイトリストに追加を行った．
5.4 システムの実装
本システムは，図 3 のようにファイアウォール
（FreeBSD の ipfw）を利用して制御を行った．
140
145
150
170
180
190
reset log tcp from table(1) to Primary 25 setup
reset log tcp from table(1) to Primary 25 established
pipe 1 log tcp from any to Primary 25 setup
allow log tcp from table(1) to Secondary 25 setup
reset log tcp from any to Secondary 25 setup
reset log tcp from any to Tertiary 25 setup
図 3：ipfw の設定例
本環境に対してメールが送信されると， ipfw のル
ール番号が小さい順に参照され，はじめにルール番
号 150 により，Primary MX への最初の SYN を受信
すると応答の遅延が発生する． ” pipe 1” は
dummynet の設定であり，5 秒間応答を遅延させて
いる．また，これと同時に出力されるログを常時監
視し，一時ホワイトリスト（図 3：”table(1)”）への
追加され，10 秒間維持する．この後，送信ホストの
振舞いは次のような動作が想定される．
(1) 遅延終了後の SYN+ACK に対して ACK を送信
(2) 遅延終了前に Primary MX に SYN を再送
(3) 遅延終了前に Secondary MX に SYN を再送
(1)は，5 秒後に Primary MX から SYN+ACK を応
答し，それに対して送信ホストが ACK を送信する場
合であり，図 3 のルール番号 150，145，170 の順に
参照され，配送が開始されることが予想される．
(2)及び(3)は，送信ホストが遅延終了まで待たずに
SYN を再送する場合であり，(2)は図 3 のルール番号
150，140，170 の順，(3)は 150，170 の順に参照さ
れ，配送が開始されることが予想される．
5.5 配送テスト
前項のシステム環境宛てに，3 章の調査で利用し
た正常な送信ホストである 22 ドメインからメールを
送信し，想定通りの動作で正しくメールの受信が行
えるか配送テストを行った．
図 4：Three-way Handshake の流れ
配送テストの結果，送信ホストによって振舞いに
若干の違いがあるものの，全ての送信ホストが前項
で示した動作予想の(2)を行い，正しく受信すること
ができた．
送信ホストと Secondary MX が TCP 接続を確立
するまでの流れを図 4 に示した．図 4 では，縦軸を
時間軸とし，上から順に動作が進行するものとする．
また，[ ]内の数字は送信ホストからの何度目の SYN
かを表し，どの SYN がどの RST や ACK と対応して
いるかを示した．さらに，( )内の数字は経過時間を
秒単位で表しており，数字に範囲があるものは送信
ホストにより経過時間が異なることを示す．
図 4 のように，送信ホストはまず Primary MX に
対して SYN を送信する．このとき，この送信ホスト
の IP アドレスが一時ホワイトリストに登録され，同
時に応答遅延を開始する．この後，全ての送信ホス
トが 3 秒後に Primary MX に対して SYN を再送した．
これに対し，既に該当する送信ホストは一時ホワイ
トリストに含まれているため，Primary MX は RST
を応答する．すると，送信ホストは即座にフォール
バックを行い，Secondary MX に対して SYN を送信
する．ここでも一時ホワイトリストに含まれている
ため，これに対して SYN+ACK を応答すると，送信
ホストから ACK が返り，Three-way Handshake が
完了し，SMTP セッションが開始される．この後，
Primary MX への最初の SYN に対する応答遅延が 5
秒後に終了し，送信ホストに対して SYN+ACK を応
答するが，既に Secondary MX との間で TCP コネ
クションが確立されているため，送信ホストはこれ
に無視，あるいは RST を応答することが確認され，
いずれの場合にもメール配送に問題は生じなかった．
この結果から，本システムは MX fallback を行う機
能を有する送信ホストによるメール配送はもれなく
受信することが確認した．
また，配送テストで利用した全ての送信ホストが，
最初の Primary MX への SYN 送信の 3 秒後に再度
SYN を送信したため，Primary MX では 1 度目の
SYN に対して応答の遅延ではなく沈黙させても同様
の動作を行い，受信することができた．しかしなが
ら，SYN の再送に長時間を要する送信ホストが存在
した場合に Primary MX が 5 秒後に応答することに
より，メール配送に要する時間を短縮することがで
きる．加えて，Primary MX から応答がない場合に
再送を行わない送信ホストが存在した場合に，SYN
に対して沈黙すると正しく配送が行えないが，遅延
後に応答することで配送を可能にすることができる
と考えられる．
Primary MX への SYN の再送を行わない送信ホス
トを救うために応答を 5 秒間遅延させたが，これを
3 秒未満の遅延とすると，SYN の再送が行われない
ため正しく配送が行われない．したがって遅延時間
は 3 秒以上でなければならず，本システムでは 5 秒間
としたが，さらに長時間としても問題は生じない．
また，一時ホワイトリストの生存時間を 10 秒とし
たが，配送テストでは配送開始から 3〜4 秒後に送信
ホストと Secondary MX の間で SMTP セッションが
開始されたことから，10 秒程度の保持が適切である
と考えられる．
5.6 恒久ホワイトリストの併用
これまでに述べた MX fallback 検出システムは，
初めての通信相手であれば spam を判別するために
有効な手段であるが，何度も正しくフォールバック
を行い，メールを受信した相手に対して配送の度に
再送を行わせることは好ましくない．そのため，過
去 3 回以上正しくフォールバックを行った実績のあ
る送信ホストは恒久ホワイトリストに加える．恒久
ホワイトリストに含まれる送信者からの配送の場合，
Primary MX と Secondary MX のどちらとも，即座
に接続を許可する．Secondary MX でも接続を許可
するのは，これまでの配送で Primary MX に接続で
きず，毎回 Secondary MX に対して配送を行ったた
めに，その情報をキャッシュした送信ホストが存在
した場合にも対応するためである．
また正常な送信ホストのうち，RFC による規定を
守らず，MX fallback を行わないホストからのメール
を受信したい場合には恒久ホワイトリストに登録す
ることにより受信可能である．
恒久ホワイトリストを実装するため，図 3 で示し
た ipfw のルールに加え，図 4 のように設定した．
130
140
145
150
160
170
180
190
allow log tcp from table(2) to Primary 25 setup
reset log tcp from table(1) to Primary 25 setup
reset log tcp from table(1) to Primary 25 established
pipe 1 log tcp from any to Primary 25 setup
allow log tcp from table(2) to Secondary 25 setup
allow log tcp from table(1) to Secondary 25 setup
reset log tcp from any to Secondary 25 setup
reset log tcp from any to Tertiary 25 setup
図 4：ipfw の設定例
する．このスクリプトは，/etc/fallback/に送信ホス
トの IP アドレス名のファイルを生成する．同一の IP
アドレスを引数として実行される度に，そのファイ
ルに 1 行ずつ IP アドレスを出力する．したがって，
3 回正しくフォールバックを行った送信ホストは，該
当するファイルに 3 行出力された状態となっており，
この状態になると該当する IP アドレスを恒久ホワイ
トリスト（table(2)）に加える．
また，本サーバを再起動した場合や ipfw を reset
した場合に恒久ホワイトリストのデータが失われる
ことを防ぐため，バックアップファイルとして，
/etc/fallback/permanent.dat に保存する．サーバの
再起動時にこのファイルから恒久ホワイトリストを
読み込み，ipfw の table(2)にリストを反映させるた
めに，/usr/local/etc/rc.d/に図 6 のようなシェルス
クリプトを置く．
#!/bin/sh
while read line; do
ìpfw table 2 add $line`
done < /etc/fallback/permanent.dat
図 6：起動時に実行されるスクリプト
再起動時には図 6 のスクリプトが自動的に実行さ
れ，恒久ホワイトリストが ipfw に反映されるが，
ipfw を reset する場合はこのスクリプトを手動で実
行すればよい．
5.7 動作
本章で論じたシステムの動作を図 7 にまとめた．
図 4 では，table(2)が恒久ホワイトリストを表して
いる．恒久ホワイトリストに含まれる送信ホストか
らの配送は，ルール番号 130 と 160 が適用される．
ルール番号 130 では，Primary MX に対して送信が
行われた場合，フォールバック検査を行わずに即座
に受信することを表している．また，ルール番号
160 が適用される場合は，130 が適用されなかった
ことを意味する．すなわち，送信ホストがキャッシ
ュデータを持っており，最初に Secondary MX に対
して送信された場合にも即座に受信する．
恒久ホワイトリストへの登録は，正しくフォール
バックを行い，Secondary MX に再送を行った場合
に適用される図 4 のルール番号 170 をで出力される
ログを監視して送信ホストの IP アドレスを抜き出し，
それを引数として，図 5 のシェルスクリプトを実行
#!/bin/sh
f=/etc/fallback/$1
echo $1 >> $f
cnt=`grep -c $1 $f`
if test $cnt -ge 3; then
ìpfw table 2 add $1`
ècho $1 >> /etc/fallback/permanent.dat`
`rm -r /etc/fallback/$1`
f
図 5：恒久ホワイトリストへの登録
図 7：システムの動作
6. まとめ
6.1 評価
正常な送信ホストと spam 送信ホストによるメー
ル配送の特徴を詳細に調査し，比較した結果，両者
の間には大きな違いが見られ，TCP コネクションが
確立するまでの間に spam 検査を行うことが可能で
あることを確認し，その特徴を利用した spam 判別
システムの開発を行った．
本システムは，Secondary MX において Primary
MX の Handshake のログを参照せずに MX fallback
の検出を行うことが可能であり，メールサーバの負
荷を軽減できる．
配送テストの結果，本システムを利用して spam 判
別を行って受信するまでに要した時間は，spam 対策
なしでの受信に要する時間と比較して，わずか 3〜5
秒程度の遅延で受信可能であり，非常に高速に
spam の削減を行える．また，本システムは TCP 接
続の確立までに spam 判別を行うため，MTA に寄せ
られる spam の総量が劇的に減少する．MTA におけ
る様々な手法と組み合わせて運用を行う上で，本手
法は一次検査として大きな効果があると言える．
6.2 問題点と課題
本システムに対して，同一ホストから並列接続を
試行された場合に正しくフォールバック検査を行え
ない可能性があり，何らかの制御が必要である．
Secondary MX では，一時ホワイトリストに含ま
れている送信ホストのみ接続を許可しているため，
複数ホストからの並列送信に対しては問題なくフォ
ールバック検査を行うことができる．
しかしながら，同一ホストからの並列送信では，
一時ホワイトリストに含まれている限り Secondary
MX は常に受信可能な状態となるため，フォールバ
ック検査を行えない場合が生じる恐れがある．
同一ホストから並列送信を行う spam の振舞いは
次の 2 通りが考えられる．
(1) Primary MX のみ，または Secondary MX のみ
に対して大量の SYN を送信
(2) Primary MX と Secondary MX の両方に対して
大量の SYN を送信
(1)の場合は，Primary MX では一時ホワイトリス
トに該当ホストが加えられている間，大量の SYN に
対して常に RST を応答するため問題は生じない．ま
た，Secondary MX のみに対して大量の SYN が送信
されても，該当ホストは一時ホワイトリストに追加
されていないため，同様に RST を応答し続ける．し
たがって，(1)の場合は問題は生じず，正しく spam
判別を行うことができる．
しかしながら(2)のように，Primary MX と
Secondary MX の両方に対して並列送信が行われた
場合，想定通りにフォールバック検査が行えない．
すなわち，フォールバックを行った配送のみではな
く，無作為に送信され，偶然 Primary MX への接続
失敗後に Secondary MX へ送信を行った場合，false
negative が発生する恐れがあるが，この場合，spam
送信ホストは”無作為に”送信を行うという特徴があ
る可能性が高い．すなわち，送信回数が極端に多く
なることが予想されるため，それを検出し，SMTP
セッション中に強制的に接続を断ち切る方法が考え
られる．
また，無作為に送信を行う spam 送信ホストは，最
初の試行で Secondary MX や Tertiary MX に送信を
行う場合も多いと予想される．このような送信を行
った場合には一時ブラックリストの利用が効果的で
あると考えられる．一時ブラックリストでは，一定
時間すべてのサーバへの接続を拒否する．
6.3 今後の展望
本システムはファイアウォール（ipfw）のログを
監視することにより実装しているが，非常に高負荷
な状態になった場合等に，ログの書き込みやログ監
視プログラムの処理が遅延する可能性が考えられ，
如何にして負荷に耐えられるようシステムを構築す
るか検討する必要がある．
そのためには，ファイアウォールのログを，ファ
イルに書き込まれたものを読み込む方法ではなく，
ipfw から直接読み取る方法を検討しなければならな
い．実装を行うためには，ipfw のコードの書き換え
を行うか，ipfw からパケットを迂回させ，そのパケ
ットを受けるデーモンと ipfw を連携させて処理を行
う必要がある．
謝辞
本研究を行うにあたり，実験環境の提供や助言を
いただいた，中京大学情報理工学部の長谷川明生教
授と，愛知県立大学情報科学部の山口榮作講師に感
謝の意を表する．
参考文献
[1] MessageLabs Intelligence：2010 Annual
Security Report 3 SPAM: TOP THREATS OF 2010
http://www.messagelabs.com/mlireport/MessageL
absIntelligence_2010_Annual_Report_FINAL.pdf
[2] RFC5321：Simple Mail Transfer Protocol
http://tools.ietf.org/html/rfc5321
[3] 山口榮作，鈴木常彦: “Handshake を利用した
spam 対策システム”, 国公立大学センター情報システ
ム研究会, 大学情報環境研究 Vol.8 pp.60-67, 2005
[4] 前野年紀，鈴木常彦: “spam 送信ホストの見分け
かた”, 情報処理学会, DSM シンポジウム 2004 年度
論文集, pp.25-29, 2004
[5] 北川直哉，鈴木常彦：“再送戦略ポリシーの違い
を利用した spam 判別”，情報科学技術フォーラム
2010 特集号：講演論文集第 4 分冊， pp.231234，2010
[6] Evan Harris：Graylisting
http://projects.puremagic.com/greylisting/
[7] qmail.jp：お馴染さん方式
https://moin.qmail.jp/お馴染さん方式

Download Report