## page was renamed from spam/MX fallback 判定 ## page was renamed from MX fallback 判定 <> [[spam/bots]] は『送り放し(fire-and-forget)』とよばれる SMTP(RFC2821)に反したメイル送信方法を使っています。 この特徴を識別すれば spamを簡単に高速で選別できます。 http://im.qmail.jp/im.html メイル配送の仕組 -- [[DNS/MXレコード]] == MX fallback 判定 (MX 遷移検査) == ドメインに[[複数のSMTPサーバ]]を置いて、 対応する複数の [[DNS/MXレコード]]を設定します。 多くの spamは以下のような動作をします。[60% - 80%] 1. どれかのサーバ(多くは最優先サーバ)に『一回だけ』接続してきます。 1. 送信に失敗すると、再度接続は試みません。 この振舞いを逆用して、多くの spam接続を排除できます。 * 最優先の受信サーバは SMTP 接続を受けつけません。 ただし、接続があったことを記録しておきます。 ([[packet filter]] log 利用；ホワイトリストを併用する方がよい。) * 二番優先度の受信サーバでは、最優先サーバへの接続記録があるホスト からの接続を一定時間だけ許し、受信処理をします。 '''[[http://unlisting.org|Unlisting]]''' と呼ばれる手法とほぼ同じです。 [[http://www.reflection.co.jp/spam/|GION]] 方式も参考にしています。 より単純な方法('''[[http://nolisting.org/|Nolisting]]''')もあります。 . 二番優先度のサーバへの接続を無条件に認めます。 これだと、判別率が悪くなりますが、ここでの方法の効果をみるには有効です。 通常の送信サーバは以下のように[[MX遷移]](または MX fallback)を行います。 1. 最優先のサーバへの接続を試みます。 1. 最優先のサーバへの接続に失敗すると、 次の優先度の受信サーバに接続を試みます。 この動作により、通常メイルは二番優先度のサーバで受信されます。多くの spamは接続を拒否された段階で送信をあきらめます。 === 実装 === * それぞれの MX レコードは異なるドメイン名を指します。 これらのドメイン名は異なる IP アドレスをもちますが、 実装を簡単にするために実際には同一のマシンに割りあてます。 (ip alias などを使って、同一のネットワークインターフェースでも構わない) * SMTP port への接続は packet filter (pf)で監視します。 * pf のログ(tcpdump相当)をリアルタイムで観察して、 primary MX への接続を記録するプログラム(python, lua)を動かしておきます。 . pf.conf, tcpdump, recent.lua (recent.py) 接続記録は別のプログラム(tcpserver)から参照しやすいように、 ファイルシステム上にファイル名として作成します。 * tcpserver は接続記録を調べて、fallback であることを確認できたら、 SMTP セッションを開始します。 * primary MX に接続してから、1 分以内に secondary MX に接続してくるものを MX 遷移と判断しました。 * 接続記録は cron を使って適宜抹消します。 === 効果 === * MX 遷移する spamホスト数は接続してきたホスト数の '''10%''' 程度でした。 一次フィルタとしては十分の効果です。 * MX fallback してこない非 spamホストはあったとしても SMTP RFC に従っていないので、受信しない(ポリシー)こととします。 (必要なら、ホワイトリストを使って対応してください。) --- 2007-12-25 追記 * MX 遷移する spamホストの比率が上ってきています。 この一か月の平均で「約25%」となりました。 * MX2 への接続ホスト数は全体の約 40 %です。 . 遷移検査も多少は効果があることが分ります。 2008-01-03 * ある別のドメインでは MX 遷移するホストの比率は 35% でした。 MX2 への接続ホスト数は全体の約 50 %です。 (spamしかこないドメインで、MX は 3 こ設定されています。) 2008-01-29 * MX 遷移する比率が 55% になりました。 MX2 への接続ホスト数は全体の約 80 %です。 === 評価 === MX 遷移検査による遅延時間は高々 1 分です。 . SMTP 一時保留返答の遅延(15 分以上)よりは短かいため、 通常の利用者が気づくようなものではなく、受入れられ易いでしょう。 メイルが遅延なく届くと思っている利用者が多くても、 導入の障害にはならないでしょう。 MX 遷移検査には受信側のシステム資源はほとんど必要ありません。 . 送信側で接続を繰返す資源が必要になります。 DNS 検索(逆引き)のように第三者の資源を使ったりしません。 . DNS 返答待ちの遅延もなく、ネットワークの負担になりません。 throttling ([[ゆっくり対応する]])のように 受信サーバの資源をたくさん占有することもありません。 MX 遷移動作する接続相手(spam)に対してだけ、 以降の MTA での spam対策を併用するのがいいでしょう。 . [[helo情報の検査]]、SMTP throttling ([[ゆっくり対応する]]) そして[[DNS/逆引き検査]]などがお勧めです。 === 課題 === MX 遷移しない送信というのはいかに有力なサイトからのものであろうと RFC に従っていないので、受信するかどうかは受信側のポリシー次第です。 [[spam/RFC ignorant サーバ]] * primary MX だけに接続しているホストの再接続状況を調べました。 * 約半年間の接続記録には MX 遷移しない通常送信ホストは 見あたりませんでした。(white list にあるものは除外) primary MX に接続したホストとは別のホストから secondary MX に接続 してくることがあります。 * こういう動作は RFC で禁止されているわけではありませんが、 稀な運用だと考えています。 * gmail.com, dartmail.net, apple.com などの大規模ドメインが使っています。 * 各種ホワイトリストで対応できます。 * 共有情報として公開していきましょう。 大規模送信サーバプールをもっていて、 SMTP 一時エラー返答に対しては別ホストから再送する運用をしているところ (yahoo, amazon など)でもきちんと MX 遷移するサーバを使っていました。 ただし、Yahoo mail (yahoo.co.jp) は secondary MX を直撃してくることが あります。(接続できたホストのリストを保持しているのかもしれません。) 効率よく発見する方法は研究課題です。 . secondary MX 直撃に対しては一時保留返答をすることにして、 再接続を待つというのが、安全な対応になりそうです。 MX 遷移するホストが増えてくると、単純に第二順位の MX に接続してきた ものを受入れる方法に比べての利点が減ります。 簡単な Nolisting 方式でいいかもしれません。 === 難点 === 導入の前提として、方式の評価が必要になります。 . 方式の評価には SMTP の原理の十分な理解と DNS を設定するだけの知識、 そして packet filter 設定のための知識が必要になります。 また、グローバル IP アドレスも余分に必要となります。 さらに、サイト毎にログの監視とホワイトリスト作成という仕事も発生します。 つまり、それなりの技術と権限を持つ人材が必要となります。 spamの害と受信した場合の損失などをきちんと評価できていないと、 実装のコストが実際より大きく見えてしまうかもしれません。 spamを捨てたいだけのメイル利用者やメイル管理者には負担が大きいでしょう。 現状では簡単に受入れられそうもない方法かもしれません。:-) === 発展 === pf は OS signature を付けてくれるので、Windows ホストを判別できます。 * Windows ホストは bots の可能性が高いので、 これらの接続を分離して対応することも考えられます。 spamにより、通常メイルが遅延することのないようにしましょう。 == プロシン 2007 == * [[環境にやさしいspam対策]] スライド * [[ps07/概要]] ------ 前野年紀