この特徴を識別すれば spamを簡単に高速で選別できます。

http://im.qmail.jp/im.html メイル配送の仕組 -- DNS/MXレコード

1. MX fallback 判定 (MX 遷移検査)

ドメインに複数のSMTPサーバを置いて、 対応する複数の DNS/MXレコードを設定します。

多くの spamは以下のような動作をします。[60% - 80%]

  1. どれかのサーバ(多くは最優先サーバ)に『一回だけ』接続してきます。
  2. 送信に失敗すると、再度接続は試みません。

この振舞いを逆用して、多くの spam接続を排除できます。

Unlisting と呼ばれる手法とほぼ同じです。 GION 方式も参考にしています。

より単純な方法(Nolisting)もあります。

これだと、判別率が悪くなりますが、ここでの方法の効果をみるには有効です。

通常の送信サーバは以下のようにMX遷移(または MX fallback)を行います。

  1. 最優先のサーバへの接続を試みます。
  2. 最優先のサーバへの接続に失敗すると、 次の優先度の受信サーバに接続を試みます。

この動作により、通常メイルは二番優先度のサーバで受信されます。多くの spamは接続を拒否された段階で送信をあきらめます。

1.1. 実装

1.2. 効果

--- 2007-12-25 追記

2008-01-03

2008-01-29

1.3. 評価

MX 遷移検査による遅延時間は高々 1 分です。

MX 遷移検査には受信側のシステム資源はほとんど必要ありません。

DNS 検索(逆引き)のように第三者の資源を使ったりしません。

throttling (ゆっくり対応する)のように 受信サーバの資源をたくさん占有することもありません。

MX 遷移動作する接続相手(spam)に対してだけ、 以降の MTA での spam対策を併用するのがいいでしょう。

1.4. 課題

MX 遷移しない送信というのはいかに有力なサイトからのものであろうと RFC に従っていないので、受信するかどうかは受信側のポリシー次第です。 spam/RFC ignorant サーバ

primary MX に接続したホストとは別のホストから secondary MX に接続 してくることがあります。

大規模送信サーバプールをもっていて、 SMTP 一時エラー返答に対しては別ホストから再送する運用をしているところ (yahoo, amazon など)でもきちんと MX 遷移するサーバを使っていました。

ただし、Yahoo mail (yahoo.co.jp) は secondary MX を直撃してくることが あります。(接続できたホストのリストを保持しているのかもしれません。)

効率よく発見する方法は研究課題です。

MX 遷移するホストが増えてくると、単純に第二順位の MX に接続してきた ものを受入れる方法に比べての利点が減ります。 簡単な Nolisting 方式でいいかもしれません。

1.5. 難点

導入の前提として、方式の評価が必要になります。

また、グローバル IP アドレスも余分に必要となります。

さらに、サイト毎にログの監視とホワイトリスト作成という仕事も発生します。

つまり、それなりの技術と権限を持つ人材が必要となります。

spamの害と受信した場合の損失などをきちんと評価できていないと、 実装のコストが実際より大きく見えてしまうかもしれません。

spamを捨てたいだけのメイル利用者やメイル管理者には負担が大きいでしょう。

現状では簡単に受入れられそうもない方法かもしれません。:-)

1.6. 発展

pf は OS signature を付けてくれるので、Windows ホストを判別できます。

spamにより、通常メイルが遅延することのないようにしましょう。

2. プロシン 2007


前野年紀

MoinQ: spam/対策/MX fallback 判定 (last edited 2021-05-03 08:43:10 by ToshinoriMaeno)