月曜日, 7月 30, 2007

設定ファイルと拒否メッセージの変更のお知らせ

 この記事は、S25R方式の目次ページのお知らせ欄のリンクから来られた方のための説明記事です。
 論文の2007年7月27日以降の版では、従来とは異なる設定ファイル構成と、拒否メッセージの変更を推奨しています。
 従来の版で説明していた設定をしておられる方は、次のように変更するようお勧めします。
  1. main.cfファイルに追加するsmtpd_client_restrictionsパラメータは、従来は次のとおりでした。

    smtpd_client_restrictions =
      permit_mynetworks,
      check_client_access regexp:/etc/postfix/client_restrictions,
      reject_unknown_client

    これを次のように変更します。

    smtpd_client_restrictions =
      permit_mynetworks,
      check_client_access regexp:/etc/postfix/white_list,
      check_client_access regexp:/etc/postfix/rejections

  2. 従来のclient_restrictionsファイルからホワイトリスト部分を切り取ってwhite_listファイルにコピーします。

  3. 従来のclient_restrictionsファイルからブラックリストおよび一般規則の部分を切り取ってrejectionsファイルにコピーします。

  4. rejectionsファイルの中の、ルール1の直前に次の行を挿入します。

    # [rule 0]
    /^unknown$/ 450 reverse lookup failure, be patient

  5. rejectionsファイルの中の、ブラックリストの従来の拒否メッセージ「450 domain UCE-blacklisted」を「450 domain check, be patient」に置き換えます。

  6. rejectionsファイルの中の、一般規則の従来の拒否メッセージ「450 may not be mail exchanger」を「450 S25R check, be patient」に置き換えます。

  7. 「postfix reload」を実行して完了です。
 この変更により、次のメリットがあります。

●送信を再試行する正当なメールサーバをホワイトリストで救済する作業が数時間以上遅れた時、送信者は送信側のメールサーバから遅延警告メッセージを受け取ることがあります。その中に、設定ファイルで指定した拒否メッセージが表示されます。拒否メッセージは、逆引きできない場合も含め、「be patient」(お待ちください)という語句を含むものに変更しました。これにより、善良な送信者に不安を与えるのを避けることができます。

●従来の設定方法では、逆引きできて逆引き名が一般規則かブラックリストに引っかかるメールサーバの許可条件はFQDNで指定する必要があり、IPアドレスの十進表記で指定しても許可されませんでした。これは、Postfixが条件をサーチする順序に原因があります(こちらの記事の中に説明があります)。変更後の設定では、ホワイトリストを単独のファイルとして分離したことにより、許可条件をFQDNでもIPアドレスの十進表記でもどちらで書いても許可されるようになりました。

●設定ファイルをホワイトリストと拒否条件に分けたため、ファイルの役割分担がわかりやすくなり、メンテナンスがやりやすくなります。

金曜日, 7月 27, 2007

クライアント制限設定ファイルを分割

 7月21日「逆引き失敗時の拒否メッセージを変更する方法」の記事に対して、「(拒否メッセージの設定を)別ファイルに分ける必要があるのでしょうか」とのコメントをいただいた。ホワイトリストと拒否条件を一つのファイルに書いているので、逆引き名が「/^unknown$/」にマッチするときの条件は別ファイルにしないと、逆引きできないホストをIPアドレスの十進表記で許可することができないというのが回答になる。7月21日「ルール3に関する説明を訂正」で説明した、Postfixが条件をサーチする順序が原因である。
 しかし、そこではたと気付いた。ホワイトリストファイルと拒否条件のファイルを別々にするという方法がある。そうすれば、ホワイトリストが単独のファイルになるので、逆引き名が一般規則かブラックリストに引っかかるホストの許可条件をIPアドレスの十進表記で指定しても許可されないという問題が解消される。そして、逆引き名が「/^unknown$/」にマッチするときの条件をS25Rのルール1~6といっしょに拒否条件のファイルに組み込むことができる。それに、許可条件と拒否条件とでファイルを分けることにより、ファイルの役割分担がわかりやすくなり、ファイルのメンテナンスがやりやすくなる。
 以前にも、ホワイトリストファイルを別にした方がよいだろうかと考えたことはあったのだが、わざわざ設定方法を変更するほどのメリットはないと思っていた。こんなに大きなメリットを生むとは今まで気付かなかった。
 さっそく検証し、論文の付録A.を書き直した。また、「逆引きできるホストのホワイトリスト登録は、IPアドレスの十進表記でなく逆引き名で指定した方がよい」という注意点は不要になったので、その説明文を削除した。
 なお、逆引きできないという条件は「ルール0」と名付け、ルール1~6の直前に指定するようにした。
 また、ファイル名の例示は、役割をわかりやすく表すものに変更した。main.cfファイルに追加するsmtpd_client_restrictionsパラメータは次のようになる。

spmtd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections

水曜日, 7月 25, 2007

変なReceivedヘッダを蹴る

 受信したスパムのReceivedヘッダである。なお、a.reto.jpは私のサーバのFQDNである。

Received: from ns2.digis.net (ns2.digis.net [208.186.134.102])
 by a.reto.jp (Postfix)
 with ESMTP id D43261C473 for <deo@gabacho-net.jp>;
 Wed, 4 Jul 2007 17:46:20 +0900 (JST)
Received: from 66.235.192.212 (HELO mail.synet.biz)
 by gabacho-net.jp
 with esmtp (Q*=<G/58F 9A=X) id AW2GCD-Q7,,,6-// for deo@gabacho-net.jp;
 Wed, 4 Jul 2007 09:08:15 +0800

 私のサーバが受信する前のReceivedヘッダに「by gabacho-net.jp」という記録がある。gabacho-net.jpは私の(つまり宛先の)メールドメイン名であり、かつgabacho-net.jpというFQDNを持つサーバはこの世に存在しない。どうせボットの仕業だろうが、どういう仕組みでこうなるのか、敵がどういう考えでこんな記録をReceivedヘッダに残すようにしたのかはわからない。2007年に入ってから受信したスパムのうち半数近くにこのような変なReceivedヘッダが付いていた。
 Receivedヘッダに「by gabacho-net.jp」とあれば間違いなくスパムなので、ヘッダチェックで蹴飛ばすようにした。
 main.cfファイルに次の行を設定する。

header_checks = regexp:/etc/postfix/header_checks

 header_checksファイルには次の行を書く。

/^Received:.* by gabacho-net\.jp/ REJECT Fake Received header

 HELOアドレスチェックもS25Rのクライアントアドレスチェックも送信者ドメインの実在チェックもすり抜けた、スパムに違いないアクセスが見事に蹴飛ばされていた(論文に掲載している拒絶記録抽出スクリプトによって、ログの行から日付および「reject:」以降を抽出して表示している。下線部分はヘッダに書かれていた文字列)。

Jul 25 17:05:25 reject: header Received: from 72.22.69.27 (HELO mail.ammgroup.org)?     by gabacho-net.jp with esmtp (N8VRXWO*RO0' 4./62)?     id @9G5FR-A(FQG4-34?     for deo@gabacho-net.jp; Wed, 25 Jul 2007 08:05:35 -0300 from wdc-gw.obninsk.org[83.166.112.151]; from=<lehammgroupcah@ammgroup.org> to=<deo@gabacho-net.jp> proto=ESMTP helo=<wdc-gw.obninsk.org>: 5.7.1 Fake Received header

 このテクニックは、自サイトのユーザーのメールドメイン名(「@」の右」)と同じFQDNを持つサーバが存在しない場合にのみ使える。たとえば、自サイトのメールサーバのFQDNがhost.example.jpで、ユーザーのメールアドレスがuser@example.jpの形である場合は使える。Receivedヘッダに「by example.jp」と記録するサーバは存在しないのだから、不正メールと判定できる。
 しかし、メールサーバのFQDNがそのままメールドメイン名になっている場合(すなわち、ユーザーのメールアドレスがuser@host.example.jpの形である場合)は使ってはならない。自サイトのサーバがReceivedヘッダに「by host.example.jp」と記録するし、そのメールが外から自サイトへ戻ってくることがあるからである。自サイトのユーザーが外部のメーリングリストに投稿したメールが自サイトに配信されてきた場合などである。

逆引きできないホストへのメッセージを変更

 7月21日「逆引き失敗時の拒否メッセージを変更する方法」で説明した設定方法を論文に反映した。Postfix組み込みの「cannot find your hostname」というつっけんどんなメッセージよりも、「reverse lookup failure, be patient」というメッセージをS25R標準として推奨した方がよいと考えたからである。

日曜日, 7月 22, 2007

逆引きできないサーバが減りつつある

 ホワイトリスト情報を昨日(7月21日)更新したが、項目の追加ではない。かつて逆引きできなかったが今では逆引きできることが確認されたサーバの許可条件をいくつか削除した。
 たとえば、今年2月にエスプリラインという会社でオンラインショッピングをした時には、確認メールを送ってきたwww.espritline.co.jp、および発送通知メールを送ってきたmail.esprit.ne.jpはともに逆引きできなかったが、今ではそれぞれのIPアドレスはda.esprit.ne.jp、mail.esprit.ne.jpという名前で逆引きできるようになっている。ほかにも、すでに逆引きできるようになっていたサーバがいくつかあった。
 逆引き設定があまり行われていないと言われる中国などの国は別として、日本に関する限り、逆引き設定は浸透しつつあるようである。スパムのあまりの増大にやむにやまれず、逆引きできないホストを蹴る設定をするサイトやS25R方式を採用するサイトが増えたために、確実な送信のためには逆引きをちゃんと設定した方が無難だということが知れ渡ってきているのかもしれない。
 もちろん、国内のメール通信でも、逆引きできない正当なメールサーバを蹴ってしまうリスクはなおもある。しかし、逆引きできないメールサーバをホワイトリスト登録する手間は少なくなってきているのではないかと思う。reject_unknown_clientは使うべきでないという主張はそろそろ時代遅れになるだろう。
 素のS25R方式を長くお使いの方は、逆引きできないホストのホワイトリスト登録の棚卸しをされてはいかがだろうか。1年以上前にホワイトリスト登録したIPアドレスの逆引きが今もできないかどうかを調べてみる(逆引きできたら、逆引き名の順引き検証もお忘れなく)。あるいは、1年以上前にホワイトリスト登録したホストで、ログの保存期間内(1ヶ月程度)にそこからの受信がなかったものは削除してみて、もしまた引っかかったら再登録することにする。棚卸しをすれば、案外ホワイトリストが軽くなるかもしれない。また、ホワイトリスト登録したホストのIPアドレスが変わり、元のIPアドレスがエンドユーザーコンピュータに再利用されていてそこからスパムを受けてしまうというリスクを低減できる。

# 今日(7月22日)でS25R雑情報の開設1周年。ご愛読ありがとうございます。

土曜日, 7月 21, 2007

ルール3に関する説明を訂正

 S25Rの一般規則のルール3の正規表現は次のとおりである。

/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/

これについて、論文に次のような説明を書いていた。

 正規表現の末尾にある「\.[a-z]」は、トップレベルドメイン名の先頭にマッチする。これは、逆引きが失敗した時にIPアドレスのドット付き十進表記を引っかけないために必要である。逆引き名を持たないクライアントをこの規則で引っかけるよりも、Postfixが「cannot find your hostname(ホスト名が見つからない)」というメッセージをメールログに残すのに任せた方がよい。

これは正確な説明でなかった。次のように修正した。

 正規表現の末尾にある「\.[a-z]」は、トップレベルドメイン名の先頭にマッチする。これは、あらゆるIPアドレスのドット付き十進表記を引っかけないために必須である。これがないと、デフォルトで許可されるべきあらゆるクライアントを引っかけてしまう。

 どういうことかというと、以下のとおりである。
 Postfixは、check_client_access指定によってクライアントアドレスを正規表現のファイルと照合する時、まず逆引きFQDN(逆引きが失敗したら「unknown」)で上から順にサーチし、どれともマッチしなければ次にIPアドレスのドット付き十進表記で上から順にサーチする。
 もしルール3の正規表現に「\.[a-z]」がないと、あらゆるIPアドレスのドット付き十進表記がマッチしてしまう。だから、逆引きできてFQDNがS25Rの一般規則にもブラックリストにもマッチしない(すなわちデフォルトで許可されるべき)ホストは、IPアドレスのドット付き十進表記でサーチした時にここで引っかかって蹴られてしまうのである。「『\.[a-z]』を抜いても、逆引きできないホストがここで引っかかるだけで、支障はない」のではなく、「抜いてはならない」のである。
 上述のようなサーチ順序を知ったのは、ドキュメントからではない。逆引きFQDNが一般規則に引っかかるホストの許可条件をIPアドレスの十進表記で記述しても許可されないことがわかったからである。まず逆引きFQDNでクライアント制限設定ファイルを上から順にサーチするので、IPアドレスの十進表記が許可条件にマッチする前にFQDNが拒否条件にマッチしてしまうのだと気付いた。
 このことは、論文を発表した時点では知らなかった。発表後にわかったのである。それに基づいて論文の記述は修正していたのだが、前述の不正確な説明がまだ残っていたことに今日まで気付かなかった。

逆引き失敗時の拒否メッセージを変更する方法

 Postfixのreject_unknown_client指定によって、逆引きできないクライアントを蹴る時にクライアントに返す拒否メッセージ(ログに残るメッセージでもある)は

450 4.7.1 Client host rejected: cannot find your hostname, [88.245.28.215]

のような形である。送信側のメールサーバのMTAがsendmailである場合、送信が4時間遅延すると送信者に遅延警告メッセージが送られることがある。その時、遅延警告メッセージの中に上記の形のメッセージが表示される。
 Postfixに組み込まれた「cannot find your hostname」というメッセージはつっけんどんである。「あなたのホスト名が見つかりません。あなたがDNS逆引きでホスト名を公開していないからじゃないんですか?あなたのホスト名がわからない限り、私は受け取りませんよ」というニュアンスが感じられる。
 6月2日「拒否メッセージを変更」で、ブラックリストと一般規則で拒否する時のメッセージを、「be patient」(お待ちください)という語句を含むものに変えたことを説明した。「ドメイン検査/S25R検査に引っかかりました。そのままお待ちください。調査の上で受信します」というニュアンスを込めれば、遅延警告メッセージを受けた送信者に不安を与えずにすむだろうと考えてのことである。
 その記事では、初め、逆引きできない時の拒否メッセージを変更するにはsrc/smtpd/smtpd_check.cというソースファイルを編集してリコンパイルする方法があるが、あえて変更するまでもないだろうと述べた。なお、クライアント制限設定ファイル(論文で記載しているファイル名はclient_restrictions)の最後に1行付け加える方法もあると書いたが、バグだと気付いてあわてて消した。
 しかし、逆引きできない時の拒否メッセージも変更したくなった。ソースファイルを編集する方法では、Postfixのバージョンアップのたびに編集を繰り返さなければならないし、ミスをすればトラブルを引き起こす。そこで、設定だけでメッセージを変更する方法を考案した。

 main.cfファイルでのsmtpd_client_restrictionsパラメータの指定を次のようにする。

smtpd_client_restrictions =
  permit_my_networks,
  …(必要ならばここに各種指定)
  check_client_access regexp:/etc/postfix/client_restrictions,
  check_client_access regexp:/etc/postfix/unknown_client_restriction

つまり、reject_unknown_clientをやめて、代わりにもう一つのクライアント制限設定ファイルunknown_client_restrictionを指定する(client_restrictionsファイルとは別のファイルとして設ける必要がある)。unknown_client_restrictionファイルには次の1行を記述する。

/^unknown$/ 450 reverse lookup failure, be patient

 これで、拒否メッセージは次の例のようになる。

450 4.7.1 <unknown[213.91.187.67]>: Client host rejected: reverse lookup failure, be patient

 「逆引きに失敗しました(あなたが逆引きを設定していないせいだとは言っていませんよ。私が逆引き検索をしようとして失敗したと言っているだけです)。そのままお待ちください。調査の上で受信します」というニュアンスを込めることができていると思う。

(7月30日追記)
 この記事にいただいたコメントのおかげで、もっとうまい方法を思い付きました。

金曜日, 7月 20, 2007

エラーリターンを受け損ねた

 私が運用しているメーリングリストのメンバーの誰かがソフトバンクの携帯電話へメールを自動転送して、そこで何かのエラーになったらしい。エラーリターンの送信アクセスがあった。
 softbank.ne.jpのサーバがルール1に引っかかるということは協力者から報告されていて、ホワイトリスト情報に掲載しているのだが、自分のホワイトリストに登録し忘れていた。

Jul 20 10:50:50 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:10:42 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:50:41 mmrts020p01c.softbank.ne.jp [210.228.189.186]

 1時間、3回のトライで止まってしまい、ホワイトリスト登録が間に合わなかった。「4xx」の応答に対してエラーリターンの送信を長時間リトライしないのは、携帯電話メールサービスではメールトラフィックが多いので、リソース負荷の増大を避けるためだろう。もっとも、メーリングリストの一時的なエラーリターンと推測できたので、受け損なったところで大した損失ではなかった。むしろ、こういうケースがあると知ったことは怪我の功名だった。
 Rgreyならば受け損なわずに済んだだろうが、素のS25R方式だと、リトライするスパムに強い代わりに、こういう時に受け損なう。メールマガジンのリトライが1時間余りで止まったケースもあった。素のS25R方式を使っている人がこういう受信失敗を避けるためには、なるべく私の公開ホワイトリスト情報を利用するのがよいだろう。
 組織サイトのメールシステム管理者は、再送が短時間で止まってしまった拒絶ログを見つけた時には、受信者に照会をかけるのがよいだろう。受信者は、心当たりがあればそれで何らかの判断ができるだろう。
 S25R方式にはこういうリスクがある。しかし一方、スパム対策をしなければ、安いサーバを使っていてユーザー数の割にディスク容量が大きくない場合、突発的に大量のスパムが押し寄せた時にスプールあふれを起こすリスクがある。受けてからフィルタリングするSpamAssassinなどのスパム対策方式でも、偽陽性判定に備えてスパムを全部ディスクに蓄積しておかなければならないので、やはり同じである。そのリスクを低減するためには、サーバのリソースの増強にコストがかかる。S25R方式を使えば、ディスクに蓄積されるスパムは少なく抑えられるので、サーバにかけるコストを増やさずにすむ。受け損なってもさほど損失が大きくないメールを受け損なうリスクに比べて、利益の方が大きいと思う。
 S25R方式を正しく運用して効果を喜んでいる人たちは、正当なメールの救済が間に合わないリスクをゼロにできないとわかっても、S25R方式を放棄しようなどとは思わないだろう。

火曜日, 7月 17, 2007

またもやリトライするスパム

 2006年7月ころには、約5分間隔で5回トライするスパムアクセスがけっこうあった(2006年7月31日「手動ホワイトリスティングの利点」)。最初のアクセスから最後のアクセスまではたいてい23分未満なので、Rgreyではpostgreyの起動オプションを「--delay=1500」と指定することによって、25分未満のリトライを阻止できるだろうと述べた(2006年8月28日「リトライするスパムをRgreyで蹴る」)。しかし、2006年12月にはそのようなスパムは見かけなくなった(2006年12月4日「リトライするスパムが減った」)。
 ところが、今日(7月17日)、新たなパターンのリトライするスパムアクセスが見つかった。

Jul 17 11:15:41 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]
Jul 17 11:25:48 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]
Jul 17 11:35:58 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]

Jul 17 12:15:58 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]
Jul 17 12:26:06 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]
Jul 17 12:36:13 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]

 約10分間隔で3回トライしている。この2組のリトライは同じパターンである。新たなボットかもしれない。
 なお、ここでは表示を省略しているが、HELOアドレスはクライアントの逆引き名と同じである。
 このようなリトライするスパムアクセスが今後増えるかどうかはわからない。今のところ、最初のアクセスから最後のアクセスまでは21分未満である。もしこのようなのが増えたら、また「--delay=1500」を設定した方がよいかもしれない。
 私がホワイトリスティングの自動化をしていないのは、めんどくさがり屋なのと、メールトラフィックが少ない個人サイトなのであまり必要を感じないからだが、このようなスパムアクセスを見つけて皆さんに報告できるというメリットもある。

注意点を追記

 「スパム対策技術」の目次ページにS25R方式の要点を掲示している。そこに注意点として

●初期の偽陽性判定率約13%。ホワイトリストの保守(自動化可能)が必須です。

と書いていたが、さらに2点書き足した。

●メールログの監視ができない人は使わないでください。

 「メールログの監視ができない」とは、スキルがなくてできないのか、時間がなくてできないのか、どちらの意味かというと、両方の意味だと解釈してくださってよい。ログの監視はメールシステム管理の基本である。まして、スパム対策とは、受けたいメールと受けたくないメールを選別しようとするものである。それを受信者の願いどおりに機械が完璧にやってくれるわけがない。特に偽陽性判定の監視は絶対にやらなければならない。
 S25R方式をベースとしてメンテナンスフリー化を狙った、佐藤さんのtaRgreyを使っても、まったくログを見ずに放置できるわけではないはずである。
 ログを見ないなら、S25R方式なんか使ってくれるな。いや、むしろ、スパム対策なんかせずにメールは全部受けてくれた方がよい。そういう意味を込めている。

●メールの受信の遅延がいやだと思う人は使わないでください。

 S25R方式で偽陽性判定が起これば、救済までメールの受信が遅延する。その副作用を明記した。
 佐藤さんのStarpitを使えば、S25Rで偽陽性判定されたメールサーバからのメールは1~2分のタールピッティング(応答遅延)の後に受信されるので、遅延はあまり問題にならない。しかし、正当なメールサーバがタールピッティングを抜けないケースも皆無ではないので、手動救済に時間がかかることはありうる。taRgreyはそういうメールサーバをグレイリスティングで救済できるが、やはり受信遅延は起こる。
 受信の遅延がいやなら、S25R方式は使うべきでない。SpamAssassinなどでスパム判定のマークを付けて受信者へ即刻配信する方式の方がよい。そういう意味を込めている。

 S25R方式を発表した当初、私は、スパムの阻止率が高いというメリットを強調しがちだった。実際、そのメリットが、S25R方式を先駆的に導入してくれた人たちに歓迎された。しかし、S25R方式が有名になり、多くの人の目を惹くようになった今、副作用のこともはっきりと認識してもらう配慮がより重要になってきていると思う。

S25R方式を批判するための戦略

 「reject_unknown_clientは迷惑メール対策としておすすめではない」というブログ記事において、S25R方式を批判する上で把握していると認められる情報は、論文のタイトルと「reject_unknown_client」の2行だけである。これでは、S25R方式の支持者のみならず、S25R方式をちゃんと理解した上で批判している人からも、「なんだ、こいつ」と思われかねない。浅薄な人だと思われたら、せっかくほかのコンテンツでいいことを書いていても、それがゆがんだ目で見られることにもなりかねない。これでは批判者ご本人にとって損である。
 前回述べたように、私は批判には感謝している。批判によって「ごもっとも。S25R方式は有用ではないのだ」と思ったことも、S25R方式を抜本的に考え直す必要があると思ったこともないが、S25R方式を正しく、より容易に理解してもらうためにコンテンツを工夫するきっかけにはなっているからである。そこで、批判者へのお礼として、S25R方式を上手に批判するための戦略をアドバイスしよう。重要なポイントは、“敵”の情報を収集することである。
 論文を見つけたら、読む前でもよいから、アラートに従って「目次」をクリックして目次ページを見る。そこにはS25R方式の要点を簡潔に書いてあるから、まずそれを把握する。偽陽性判定があるから運用に注意が必要だということがわかるだろう。
 目次欄には、ホワイトリスト情報へのリンクがある。そこを見れば、具体的にどのようなホストが偽陽性判定されるのかがわかる。「無茶なスパム判定だ」とネガティブにとらえるか、「この情報を利用すれば偽陽性判定をかなり避けることができるんだな」とポジティブにとらえるかはご自由に。偽陽性判定を容易に発見するためのスクリプトが提供されていることにも注目してほしい。
 「導入者の皆様の声」というページもある。個人サイトから18,000人規模のメールサービスプロバイダまで利用実績があることがわかるだろう。ただし、ホワイトリスト登録の自動化によって導入に成功したという事例もある。ホワイトリスト登録の自動化は、佐藤潔さん、あるいはサイト管理者ご自身の功績である。
 Q&Aもある。論文を熟読してS25R方式を理解する前に読んでもかまわない。どんな疑問が持たれがちな方式なのかはわかるだろう。
 「スパムやウィルスを99%阻止するメールサーバの運用技術」という取材記事は、IT企業の経営者クラスの人がS25R方式の概要を理解できるように書かれている。これを読んでから論文を読めば、より理解しやすいかもしれない。
 目次ページのリンク欄では、ボランティアによる、S25R方式をベースとしたさまざまな工夫を紹介している。特に佐藤さんのRgreyStarpittaRgreyに注目してほしい。S25R方式による偽陽性判定を自動的に救済するシステムである。
 さらに、目次ページの上端か下端の「ホーム」をクリックしてGabacho-Netのホームページを見てみる。私がスパム対策技術以外にどんなコンテンツを提供しているかを一望できる。きまぐれノートだの日本語脚韻だのフランス語詩だのという酔狂なコンテンツは見る必要はないが、“敵”の関心事を把握することは、批判の戦略に役立つかもしれない。
 それはともかく、掲示板は見てみてほしい(著者の連絡先のページからもたどれる)。私がS25R方式についてゲストたちとどのようなコミュニケーションをしているかがわかる。S25R方式への賞賛を表明してくれる人や、ホワイトリスト情報を提供してくれる人がいることがわかるだろう。
 ここまで周辺情報を把握してから論文を熟読すれば、内容がよくわかると思う。
 そして、このブログも読んでほしい。書き始めてから1年近くで、この記事が90件目になる。全部を熟読しなくても、批判の戦略のために重要だと思ったものだけ拾い読みすればよいだろう。S25R方式が良いことずくめではないことも書いている。リトライを短時間でやめるサーバからのメールを受け損なうとか、リトライのたびに送信元のIPアドレスが変わるサイトが困るといったことである。過去の記事から順に読むには、2006年7月のページから、ページ下部の左端にある翌月のページへのリンクをクリックしながら一ヶ月分ずつ順に見ていくのがよいと思う。
 さらに、S25R方式やそれをベースとしたRgreyなどについて検索してみる。導入して役立てているという報告が多数見つかるが、批判もある。支持する理由の論理に欠陥はないか、ほかの批判者の意見が参考にならないかを見てみよう。
 はい、ご苦労さま。ここまで情報を収集した上で批判の戦略を立ててください。
 私は、スパマーの立場に立ってS25R方式を破る方法を考えたり、自分の理論を自分で批判したりする思考ができる。それでも、S25R方式の支持派と批判派に分かれてディベートゲームをするとすれば、批判派が圧倒的に不利だと思う(それは持論への執着によるものではない)。突っ込まれる問題点はすでに把握しているつもりだし、それに対する回答もすでに持っている。それでも私を愕然とさせることができる批判があれば、ぜひ表明してください。私は大歓迎する。どうせ批判するなら、S25R方式に関心を持った人の過半数を批判派に取り込もうとするくらいの意気込みを持ってほしい。私は、バウンシングバック認証方式反対キャンペーンにそのくらいの意気込みを持っているのである。もっとも、私のように時機を逃さず戦いを挑むことが重要で、発表から3年たって多数の利用実績ができてからじゃ遅いと思うけど。
 なお、S25R方式を導入した人たちから批判として表明されたことはないが、私が最も痛烈な批判と受け止めたのは、大規模サイトでは約1000項目ものホワイトリスト登録が必要になるという報告だった。私の個人サイトで開発した時には、偽陽性判定がそこまで多いとは気付かなかったのである。しかし、それへの回答は、ホワイトリスト作りの苦労を乗り越えた人たちがすでに持っている。偽陽性判定が際限なく頻発し続けることはなく、2週間から1ヶ月ほどでホワイトリストは安定する。怪しいホストの判定条件を緩めることは得策でない。また、私は、ホワイトリスト登録が間に合わなければS25Rを一時的に解除するという方法も提案できる。もちろん、Rgreyなどでホワイトリスティングを自動化するという方法も回答の一つになる。

日曜日, 7月 15, 2007

びっくりページ

 「スパム対策技術」の目次ページよりも論文の方が注目度が高いので、検索サイトから論文へ直接来る人が多い。それで、論文を熟読せずに「逆引きできないメールサーバを排除するのはけしからん」、「ダイナミックIPアドレスの個人メールサーバを排除するのはけしからん」などと批判する人がいる。そこで、論文のページの上端と下端に「このページへ直接来られた方は、目次ページもご覧ください。」と書いている。目次ページを見れば、ホワイトリストを使うことや、ホワイトリスト登録すべきメールサーバを発見しやすくするためのスクリプトを提供していることや、すでにS25R方式を導入している人がいることは一目でわかるはずである。
 しかしそれでも、目次ページを見ないどころか論文さえまともに読んでいないとしか思えない批判が現れた。「reject_unknown_clientは迷惑メール対策としておすすめではない」というブログ記事である。そのオーナーさんから、私の論文をリンクしたという通知をメールでいただいたのは7月1日。その人が使用を反対しているreject_unknown_clientをS25R方式が使っているということしか引用していない。逆引きできないホストを蹴るばかりか、逆引きできてさえ、ホワイトリストなしにはmc1-s3.bay6.hotmail.comは蹴るわ、web35509.mail.mud.yahoo.comは蹴るわという乱暴なやり方であることにはお気付きでないらしい。また、ホワイトリストを作る前の偽陽性判定率が約13%であることは2006年12月から目次ページの先頭に書いているし、今年5月3日に論文にも付記したのだが、それにもお気付きでないようである。気付いていたら、
「「阻止率99%」と題してはいるものの、その数字は、受け取れるべき正常なメールをスパムと誤判定した確率は何%ですか?という話とはまた別である点が、この論文のそもそものトリックなのである。」
などと書くよりも、批判の観点をもっと工夫するだろう。すぐに返事を出して、2006年12月13日「逆引き論争」(そのブログ記事とそれへの反論の両方を論評している)と、2006年7月24日「Unknown hosts」(逆引きできない正当なメールサーバを蹴りっぱなしにしてはならないと言っている)のURLをお知らせしたが、その後も批判の文章は変更されていない。
 これをきっかけとして工夫し、論文のページに閲覧者をびっくりさせる仕掛けを入れた。目次ページを見ることを促すアラートがポップアップするようにしたのである。
 ただし、目次ページから論文へたどる人にも毎回アラートを出すのは失礼である。そこで、内容が同じでアラートを出さない第二の論文ページを作り、目次ページからはそこへリンクした。この第二の論文ページにはロボットよけを仕掛けている。当然ながら、アラートを出さない第二の論文ページへ検索サイトから直接来られては、以前と同じことになってしまうからである。なお、目次ページには、以前からの論文ページへのリンクも保持している。リンク切れに見えては、せっかく上位にヒットしている論文が検索順位で不利になりかねないと思ったからである。
 たとえ的外れな批判であっても、批判者には感謝しなければならない。S25R方式への支持を表明してくれている数十人の人の裏には声なき支持者が数千人いると期待してよいとすれば、批判を表明している数人の人の裏には声なき批判者が数百人いると思うべきだろう。批判を表明してくれる人のおかげで、私はS25R方式を正しく、より容易に理解してもらおうと工夫する。目次ページの先頭にS25R方式の要点を掲示したことや、Q&Aを作ったことや、目次ページを見るよう促すアラートなどがそうした工夫である。このような努力によって、私のコンテンツはより説得力のあるものに成長していく。そして、理解不足による声なき批判者は減っていくであろう。
 なお、皆様には、論文へのリンクはこれまでどおり
http://www.gabacho-net.jp/anti-spam/anti-spam-system.html
としてくださるよう、目次ページからたどれる、アラートを出さない論文ページにはリンクしないよう、ご協力をお願いします。

(2010年5月18日追記)
 論文ページをはじめすべてのページに他ページへのインデックスを設け、アラートはやめました。

公表ブラックリストからzaq.ne.jpを削除

 論文の付録A.に掲載しているクライアント制限設定ファイルのブラックリスト項目から

# zaq3d7d6ded.zaq.ne.jp (hexadecimal used)
/^zaq.+\.zaq\.ne\.jp$/ 450 domain check, be patient

を削除した。論文を発表したころにはzaq.ne.jpから不正メールアクセスがけっこう来ていたのだが、最近まったく来ないからである。
 それと、ホスト名に十六進番号を含むホストは一般規則に引っかからないことがあるのでブラックリストの例として掲載していたのだが、よく考えてみると、ZAQのIPアドレスの上位12ビットの十六進表記は「3d7」だから、一般規則のルール1に引っかかる。だからブラックリスト登録は必要ないのである(別のIPアドレスブロックを持っているなら別だが)。
 最近不正メールアクセスが来ないのはOP25Bを導入しているからかと思って、OP25B連絡会のページを見てみたら、実施ISPとしてZAQもちゃんと掲載されていた。
 これで、論文に掲載しているブラックリスト項目の実例は11個。日本のISPは一つもなくなった。

 ところが、公表していないけれども私が設定しているブラックリストに、最近so-net.ne.jpが引っかかったことがある。6月2日「拒否メッセージを変更」で、拒絶ログの一例として書いた。So-netもOP25Bの実施ISPに入っているのになぜか?もしかしたら、外行き25番ポートを完全に遮断しているのではなくて、他ISPのメールサーバへの低頻度のアクセスなら許可するようにしているので、それでブロックをすり抜けたのかもしれない。それ以降、so-net.ne.jpからの不正メールアクセスは観測されていない。

木曜日, 7月 12, 2007

ルール3はこれでよかったんだっけ…?

 6月のスパム阻止率の統計のために、拒否されたホストから一般規則に引っかかるものを抽出しようと、一般規則と等価な正規表現でegrepをかけた時のこと。「214.ultraflex.com」というホストが抽出されなかったことに気付いた。末端ホスト名は、IPアドレスの第4オクテットを反映したものである。ドジなおいらは、「末端ホスト名が数字で始まるのに、なぜ見逃されるんだ?」と考え込んでしまった。
 一般規則のルール3は「逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる」という条件。最下位の名前が数字で始まっても、全体で3階層だけなら見逃されてしまうのである。当たり前のことだった。
 ルール3を作った理由は、「398pkj.cm.chello.no」のように最下位の名前が数字で始まるものや、「host.101.169.23.62.rev.coltfrance.com」のように、最下位の名前は英字で始まっても下位から2番目の名前が数字で始まるエンドユーザー回線がたくさん見つかったことだった。
 ところが、「246.ne.jp」のように、数字だけから成るサイトドメイン名がある。そこで、「smtp.246.ne.jp」のような名前のメールサーバを引っかけないように、上位3階層を検査から除外することにしたのである。
 そうすると、「214.ultraflex.com」のような、上位から2階層目がサイトドメイン名で末端ホスト名が数字で始まる3階層のFQDNを見逃してしまう。私は、考えに考え抜いて、それでもかまわないと結論付けたはずである。なぜだったんだっけ…。
 思い出した。「007.co.jp」(架空の例)のように、上位から3階層目が数字だけから成るサイトドメイン名で、しかも末端ホスト名を省略した逆引き名がありうると予想したからである。サイトのサーバが1台しかなくて、ことさらDNSで末端ホスト名をアナウンスする必要はないと思ったドメイン管理者は、末端ホスト名を省略した逆引き名を設定するかもしれない。もちろん、そのような設定は可能である。
 「007.co.jp」に類するメールサーバの逆引き名を発見したことはない。あるとしてもまれだろう。しかし、「214.ultraflex.com」のようなエンドユーザーコンピュータの逆引き名もまれである。このようなFQDNを持つサイトが収容するエンドユーザーコンピュータは少ないから(ultraflex.comに割り当てられているIPアドレスは64個ブロックだとわかった)、そこのエンドユーザーコンピュータがボットに感染してスパムを送ってくる確率は低い。もしたくさんのエンドユーザーコンピュータを収容しているなら、末端ホスト名は、分断された複数の数字列を含むか、数字列がもっと長いだろう。そういうものならルール1かルール2で引っかけることができる。
 「007.co.jp」のようなケースの偽陽性判定を避けるように決めたルールを見直して、「214.ultraflex.com」のようなケースの偽陰性判定を避けるようにした方がよいか?いや、そんな必要はないだろう。ただでさえS25Rの一般規則による偽陽性判定率は低くない。ごくごくわずかとはいえ、これ以上偽陽性判定の確率を増やすようなルール改訂を提案することはないだろう。もしultraflex.comのエンドユーザーコンピュータからのスパムを阻止したいなら、ブラックリストに

/^[0-9]+\.ultraflex\.com$/ 450 domain check, be patient

と書き加えればよい。
 というわけで、ルール3の見直しは必要ないと、改めて結論付けたのでありました。

# 健忘症かな?

日曜日, 7月 08, 2007

論文中の設定ファイル内容を更新

 論文に記載しているクライアント制限設定ファイルにホワイトリスト項目の実例をいくつか記載した。ホワイトリスト情報で公開しているものを全部記載しては長くなってしまうので、ISPや携帯電話会社など、それによって救済されるメールが多いと思われるものをピックアップした。それと、有名どころとしてverisign.netも記載しておいた。もちろんこれで偽陽性判定を十分に減らせるわけではないが、論文をよく読まずに設定ファイルを一瞥した人もホワイトリスト作りが重要だとわかるためには十分だろうと思う。
 また、ブラックリスト項目の実例も、最近役立っているものを追加した。たまに一般規則をすり抜けてスパムを送り込んでくるドメインはあるだろうが、しょっちゅうスパムを送り込んでくるドメインをはじくためなら、今のところ、設定ファイルにブラックリスト項目をさらに追加する必要はあまりないだろうと思う。

スパム受信数の推移

 私有のメールアドレスに受けたスパムとウィルスメールは、研究材料としてすべて保管している(もちろん、ウィルスメールは検疫済みである)。6月までで、その数は409通になった。いつからかというと、8年前から。1999年5月に自宅サイトを開設する前、OCNのメールサービスを使っていたころからである。409通なんて、勤務先では今は10日くらいでたまってしまうくらいの数である。
 受信数の推移は以下のとおりである。

1999年:7
2000年:11
2001年:42(10月、URLフィルタリング)
2002年:37
2003年:99(5月、S25R方式の開発開始)
2004年:50
2005年:18
2006年:85
2007年6月まで:60(5月、反則技を設定)

 2000年までは、スパムは少なかった。まともな会社が、スパムが嫌われる行為だと知らずに、悪気のない未承諾広告メールを送ってくるケースもあった。
 2001年にスパムが増え始めた。本文中に書かれたURLを引っかけてエラーリターンさせるURLフィルタリングを設定した。2002年までは、これでスパム受信数の増加を抑え込むことができていた。
 2003年になってまた増え始めた。5月にS25R方式の着想を得て開発を始めた。これでスパム受信数を減らすことができた。2005年には受信数が非常に少なくなった。
 2006年、また急激に増え始めたが、スパムアクセスの総数が増えたからで、S25R方式の効果が衰えているわけではないとわかった。
 2007年に入ると、1月には4通、2月には5通とまだ少なかったのだが、3月に15通、4月に11通、5月に15通とまた増え始めた。ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技をかけた。6月には、反則技がなければ24通受けていたところ、10通の受信に抑え込んだ。
 しかし、反則技で阻止できたものを除いた受信数をさかのぼってみると、3月には12通、4月には6通、5月には3通だったが、6月にまた10通に増えたわけである。このあとどうなるかはわからない。なお、7月に入ってからのスパム受信数は、8日までで2通である。
 S25R方式による防御は、このへんが限界である。物量作戦で来られては、すり抜けが増えるのはやむを得ない。今後さらにスパム受信は増えるかもしれない。
 とはいえ、もし防御していなかったら、今ごろスパムの受信数は大変なものになっていたはずである。勤務先で受けるスパムは、今年に入ってから月平均1400通ほど。勤務先のドメイン管理者の連絡先アドレスとしてwhoisデータベースに露出していたことはあるものの、2003年以降露出していないアドレスに対してさえこれだけである。自宅サイトのアドレス「deo」は今もwhoisデータベースに露出しているし、「webmaster」はウェブサイトに連絡先アドレスとして掲載している。二つのアドレスを合わせれば、月4000通ほど、年5万通ほどになっていたかもしれない。それがまだ年100通を超えたことがないのである。もちろん、年5万通押し寄せているスパムのうちすり抜けが100通以下だということではない。年4000通も押し寄せていないのである(2006年までは)。それは、スパム対策を始めてからずっと拒否応答を返し続けてきたことによって、かなりのスパマーに私へのスパム送信をあきらめさせたからに違いない。
 スパム5万通の送り込みに成功すれば、1人くらいはカモが引っかかって、スパマーは儲かるかもしれない。しかし、スパムをはじき続けることと、それによってスパマーにあきらめさせることによって、1/500の100通くらいしか送り込みに成功しなくなれば、スパムは割に合わなくなるのではないか。
 最良の防衛とは、攻撃が割に合わないものだと敵に思い知らせることである。そのためには、受けてから捨てるよりも、スパムの送信を高い確率で失敗させる方法をとるべきである。その方法として今すぐ使える実用的なツールは、グレイリスティングとタールピッティングとS25R方式くらいしかないと思う(DNSBLがどうかについてはこちらを参照)。

金曜日, 7月 06, 2007

2007年6月の統計(Becky!編)

 勤務先ではスパムをBecky!でフィルタリングしている。その2007年6月の統計を報告する。
 受信したスパムは1512通。見逃しは29通。つまり判別率は98.1%であった。偽陽性判定は、5月に1件あったが、6月にはなかった。
 簡易一般規則以外のReceivedヘッダ用フィルタは以下のとおりである(受信メールサーバの名前は仮にmail.example.jpとしている)。

from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp
from .*\(user.*\.mindspring\.com .* by mail\.example\.jp
from .*\(.+\.[a-z]\.pppool\.de .* by mail\.example\.jp
from .*\([^.]*[0-9]+\.[^.]*[0-9]+\.maxonline\.com\.sg .* by mail\.example\.jp
from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp
from .*\(.+\.[^.]*[0-9]+-[0-9]+-[0-9]+\.noos\.fr .* by mail\.example\.jp
from .*\(.+\.dip[0-9]+\.t-ipconnect\.de .* by mail\.example\.jp
from .*\(.+\.dip\.t-dialin\.net .* by mail\.example\.jp
from .*\(.+\.rev\.numericable\.fr .* by mail\.example\.jp
from .*\(.+\.(pl|ru|cz) .* by mail\.example\.jp

 1月13日「Becky!用ブラックリストを追加」で紹介した6個のブラックリストにさらに3個追加している。最後の行が、ポーランド、ロシア、チェコの国ドメインからのメールを全部ごみ箱行きにする反則技フィルタである。
 反則技フィルタだけに引っかかったメールは17通だった。したがって、もし反則技フィルタがなければ見逃しは46通。つまり判別率は97.0%。これは、2006年9月23日「Becky!でのフィルタリング」で報告した、2006年8月23日から9月22日までの1ヶ月間のデータと変わらない。反則技フィルタのおかげで、判別率は98.1%と高い値になった。これは、自宅サイトに宛先の正しいスパムを送ろうとしたホストの阻止率98.3%とほぼ同じである。
 反則技フィルタのおかげでごみ箱行きにできたスパム17通の送信元は以下のとおりである。

router.finemedia.pl
trzemeszno2.serv-net.pl
pear.derbynet.waw.pl
nat-mia.aster.pl
static146.debica231.tnp.pl
gw-h3.erkor.cz
host218.net2.ttkdv.ru
mail.prospekt-omsk.ru
bytom-16.streamcn.pl
pear.derbynet.waw.pl
apache.org.ru
pear.derbynet.waw.pl
f0.gate2.naukanet.ru
tls1.tlstar.ru
pear.derbynet.waw.pl
a211.ext-net9.gazsvyaz.ru
ftp1.rlan.ru

 apache.org.ruというホストにはびっくりしたが、www.apache.org.ruにアクセスすると、写真が1枚だけで文章もリンクもまったくない、わけのわからないページしか現れない。おそらく、まぎらわしいドメイン名を取っているだけで、Apache Software Foundationとは無関係なのだろう。

 ところで、見逃されたスパムには、sendmailが記録するReceivedヘッダの逆引き名の欄が次のようになっているものがあった。

GrTB0T@[61.251.16.20]
GrTB0T@68-184-58-113.dhcp.mtgm.al.charter.com
Owner47@[58.79.217.64]
BASSMASTER7126@68-189-79-2.dhcp.wscr.ca.charter.com

逆引き名(逆引きできなかった場合はIPアドレス)の直前に「@」を挟んで記されているIDが何なのかは知らない。ご存じの方は教えてください。これがなければ簡易一般規則でフィルタリングできていたのである。これがあったら「@」まで読み飛ばすように正規表現を書くと、なぜかBecky!ではフィルタリングがうまくできなくなってしまうので、あきらめている。

2007年6月の統計(自宅サーバ編)

 6月には、受けたスパムは10通だった。偽陽性判定はなかった。不正メール(スパムやウィルス)の送信元ホストは全部で6158個。2006年7月には4423個だったのに比べてさらに増えている。論文で発表している2004年4月の統計では567個だったので、3年で10倍以上に増えたことになる。以下に統計を示す。

■全不正メールの送信元(6158個)
●一般規則で5950個(96.4%)。
●ブラックリスト(後述の反則技は含まない)を合わせて6059個(98.4%)。
違法なHELOアドレスの検査で1個増加。なお、違法なHELOアドレスで引っかかった総数は866個(14.1%)。
●送信者ドメインの実在の検査で1個増加。

ここまでの合計は6061個(98.4%)。それと、

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で28個(0.5%)増加。なお、これら3国の国ドメインのものの総数は208個(3.4%)。

以上の合計で阻止数は6079個(98.7%)。
 反則技以外のフィルタによる阻止率98.4%は、2004年4月にも2006年7月にも99.1%だったのを下回っている。反則技による阻止を含めてもなお、98.7%と、わずかに及ばなかった。

■宛先の正しい不正メールの送信元(575個)
●一般規則で494個(85.9%)。
●ブラックリストを合わせて550個(95.7%)。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。

ここまでの合計は551個(95.8%)。それと、

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で14個(2.4%)増加。なお、これらのこれら3国の国ドメインのものの総数は106個(18.8%)。

以上の合計で阻止数は565個(98.3%)。
 宛先の正しい不正メールについての、反則技以外による阻止率95.8%は、2006年7月には97.4%だったのに比べてやや悪いデータになっている。一般規則による阻止率85.9%は、2006年7月には92.1%だったのに比べてかなり悪い。しかし、反則技のおかげで合計の阻止率は2006年7月のデータを上回った。
 受けたスパムは10通、反則技で14個のホストを蹴飛ばしたのだから、もし反則技を使っていなかったら24通のスパムを受けていたところだった。
 ほかのフィルタにかからずに反則技にかかったホストは28個で、そのうち14個は宛先が正しかった。全体では、不正メールを送ろうとしたホスト6158個のうち、宛先が正しかったのは575個と9%しかない。つまり、東欧3国のエンドユーザーコンピュータっぽくない名前のホストからは宛先の正しいスパムが送信される割合が非常に高いということである。ロシアのまともな会社のメールサーバがボットにやられたらしいということがあったのも考えると、送達率を重視する高スキルのスパマーが東欧3国のホストを相当悪用していると思われる。
 反則技に引っかかった28個のホストは以下のとおりである。なお、「nat」で始まるホスト名を引っかけるフィルタもかけているが、これにマッチするものはすべて東欧3国の国ドメインに属していた。このフィルタの効果は、前記の一般規則による阻止率のデータには含めていない。

OpolR012-controlex.dsl.opol.bdi.inetia.pl
bbservice144.mmpnet251.tnp.pl
brana.mecom.cz
cgr-netcom.freebone.cz
czarneckiego.jota.za.digi.pl
debica-nat.mtnet.com.pl
fasolowa.spray.net.pl
gw-aagnethkrasejovka.cust.termsnet.cz
gw-o4.erkor.cz
gw.mykey.cz
host057.tfn.x-systems.ru
host246.eimg.pl
ipe065.customer.medialine.cz
mail.kamlit.ru
mail.lirp.ru
mnepu.sura.ru
nat-06.kgts.ru
nat-be3.aster.pl
nat-goc.aster.pl
nat.4net.ru
pear.derbynet.waw.pl
piasty-125.tp.unicity.pl
router.finemedia.pl
s143.star.net.pl
totel.satis-tl.ru
*o*o*a-tsusho-machinery.ru
turkot.zs1.edu.pl
xt276e.stansat.pl

(日本企業のロシア支社とモロわかりの名前は一部伏せ字にしている。)

 スパムを着信させたホスト10個は以下のとおりである。

mail.tamoil.es
cv01mail.cablevision.net.mx
flasmtp.t-mobile.sk
agrado.tea.bg
risky.tract.volia.net
disgusting.depresser.volia.net
del3.sitek.net
gw-ma.kabelnetz.at
PanelNet4.MadNet.sk
refinerily-lane.volia.net

 volia.netのホストが3個あったので、このドメインを丸ごとブラックリスト入りさせてみた。

/\.volia\.net$/ 450 domain check, be patient