日曜日, 7月 20, 2008

「@」は効果がある

 ウェブページにメールアドレスを書くと、mailtoアンカーにしていなくてもスパマーにアドレスを拾われてしまう。このことは私の経験からも言える。
 アドレスを拾われにくくするには、HTMLファイル上(あるいはHTML記述が可能なブログ記事上)でメールアドレスの中の「@」を「@」というナンバーエンティティに書き換える方法がある。これにより、メールアドレスを拾い集めるプログラムには「@」という文字が見えなくなる。私のウェブサイトの連絡先のページでも、この方法で「webmaster@gabacho-net.jp」というメールアドレスを表示している。
 あるウェブサイトで、「この方法もすでにスパマーに破られているので、安全ではない」と書かれているのを見たことがある。確かに、メールアドレスを拾うプログラムをPerlなどで書くならば、メールアドレスの構文を定義する正規表現を少し変えれば済むので、ナンバーエンティティによる防御を破るのは簡単だろう。
 しかし、この防御は今なおかなり効果的であるということは、統計が物語っている。6月22日から7月20日22時までのログに基づいて拒絶ログソーティングスクリプトでカウントした推定メッセージ数は、個人アドレス「deo」宛は521通だったのに対して、「webmaster」宛は106通しかなかった。
 「deo」は、私が所有するドメインの管理者のアドレスとして登録しているので、おそらくwhoisデータベースから漏れ続けているものだろう。「webmaster」は私のサイトに掲載し続けている。メールアドレスの情報源としてwhoisデータベースを狙うスパマーよりも、一般のウェブページを狙うスパマーの方がおそらく多い。だから、もし多くのスパマーがナンバーエンティティによる防御を破っているとすれば、「webmaster」宛に押し寄せるスパムは「deo」宛の1/5程度では済まないはずである。かつてはナンバーエンティティを使わず、かつmailtoアンカーにしていたことがあったので、そのころ拾われて今もスパマーのアドレスリストに残っている分もあるだろうということを考えると、ナンバーエンティティで書いた「webmaster」のアドレスはほとんど拾われていない、あるいは拾われているとしても非常に少ないと考えられる。

信じられない阻止率

 2007年9月から、私の息子のアドレス(私のサーバにアカウントを設けている)にスパムが着信し始めた。オンラインショッピング会社から「サーバが侵害されてお客様の個人情報が漏洩しました」という詫び状が郵送されてきたので、息子のアドレスがここからスパマーに漏洩したと思われる。
 着信したスパムの数は、次のように変化してきた。

2007年9月:3通
10月:2通
11月:2通
12月:3通
2008年1月:6通
2月:5通
3月:11通
4月:3通
5月:2通
6月:0通

 3月をピークに減り始め、5月16日を最後に着信が途絶えて、7月20日まで着信していない。着信が減ったのは、S25Rでブロックし続けたために、送達率を重視するスパマーの多くが息子のアドレスへの送信をあきらめたからに違いない。
 しかし、息子のアドレス宛のスパムアクセスが途絶えたわけではない。拒絶ログソーティングスクリプトに手を加えて息子のアドレス宛のアクセスを抽出してカウントした推定メッセージ数は、週50通ほどになっている。なのに9週間にわたって1通も着信していない。推定約450通押し寄せたスパムに対して阻止率なんと100%。「450通につき着信は1通未満」と考えても、阻止率は99.8%以上ということになる。
 おそらく、今も息子のアドレス宛にスパムを送り続けているスパマーのほとんどは送達率に無頓着。そういうスパマーは、サーバを経由させずにボットを使っているから、S25Rが大きく効いているのだろう。S25R方式がいかにボットに強いかを物語るデータだと思う。

エクスパンションアドレスを設定していたら返金なし

 前回の記事「OptPlusの返金はない?」を読み返していてふと気が付いた。
 返金プログラム申請フォームの「利用条件の確認」欄に、チェック条件の一つとして

「利用中のメールアドレスは、他のメールアドレス(エクステンションアドレスを含む)から転送もしくは設定していません」

というのがある。これをまともな日本語に直すと、

「利用中のメールアドレスには、他のメールアドレスから転送しておらず、また、エクステンションアドレスを設定してもいません。」

ということになるだろう。
 これは何を意味するか。エクスパンション(=エクステンション)アドレスを設定していたら、通常のアドレスに宛てられたスパムが着信したとしても返金してもらえないということである。
 おそらく、スパムのメールヘッダを見ても、どのアドレスに宛てられて自分に届いたかがわからないことがあるからだろう(*)。だから、たとえ通常のアドレスに宛てられたスパムだったとしても、エクスパンションアドレスに宛てられたものでなかったと証明できないので、返金には応じられないということになるのだろう。
 なんたることか。バウンシングバック認証方式の弊害を回避するために用意されているエクスパンションアドレスという機能を使わざるを得なくて使ったら、絶対に返金に応じてもらえないのである。そういうからくりを仕組んでおいて、「スパムを1通でも受けたら返金します」と宣伝している。これでは詐欺的である。

(*) Postfixの場合は、SMTPのRCPT TOコマンドで通知された受信者アドレスがReceivedヘッダの中に記録される。私が受信したスパムの例を示す。

Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236])
 by a.reto.jp (Postfix)
 with ESMTP id 204CC1C473 for <webmaster@gabacho-net.jp>;
 Mon,  9 Jun 2008 21:18:07 +0900 (JST)
…(略)…
To: undisclosed-recipients:;

下線部が、RCPT TOコマンドで通知された受信者アドレスを示している。私は複数のアドレスでメールを受信しているが、どのアドレスに宛てられたメールだったかがここからわかる。しかし、MTAの機能あるいは設定によっては「for …」が記録されないこともある。

土曜日, 7月 19, 2008

OptPlusの返金はない?

 Opt Plus ASPは「スパムを1通でも受けたら返金します」と豪語しているが、返金には条件がある。返金プログラム申請フォームの「利用条件の確認」欄に次のように書いてあり、すべての条件に適合することを利用者が誓約しなければならない。

□バウンシングバック機能はONにしていました
□ホワイトリストに登録されていないメールアドレスからのスパム(迷惑)メールを受信しました
□該当のメールはペンディングリストからインポートしたものはありません
□利用中のメールアドレスは、他のメールアドレス(エクステンションアドレスを含む)から転送もしくは設定していません
□同一のメールサーバもしくは同一ドメインからのメールではありません

 受けたスパムの送信者アドレスがホワイトリストに登録されているアドレスだったら、返金の条件からはずれる。このことから、知人のアドレスや、自分が受信しているメールマガジンのアドレスを送信者アドレスにかたったスパム(2007年5月27日「バウンシングバック認証の破り方」参照)を受けても返金してもらえないことがわかる。
 また、バウンシングバック認証にかけないように登録した別アドレスであるエクスパンションアドレス(上記の申請フォームではエクステンションアドレスと書いてあるが、同じ意味だろう)に宛てられたスパムも、返金の条件からはずれる。だから、メーリングリストにエクスパンションアドレスで参加したらアドレスが漏洩してスパムを受けたという場合(6月6日「メーリングリストはOptPlusの鬼門」参照)も返金されない。オンラインショッピングの確認メールをバウンシングバック認証にかけないようにエクスパンションアドレスを登録したら、そのオンラインショッピングのサーバが侵害されてアドレスが盗まれ、スパムを受けたという場合(実際、私の息子はそういう被害を受けている)も同様である。

 では、ホワイトリストに登録されていなかったアドレスからのスパムに対してバウンシングバック認証要求メールが返され、スパマーがまともに認証手続きをした場合、あるいは、送信者アドレスが実在の他人のものであり、アドレスをかたられてバウンシングバック認証要求メールを受けた人が認証手続きをした場合はどうか。これは「ホワイトリストに登録されていないメールアドレスからのスパムメールを受信しました」の条件が満たされ、他のすべての条件も適合するならば、返金の対象になるように思える。
 ところが、6月8日「バウンシングバック認証はタブーの技術」にコメントしてくださったPyTaさんは、この場合も返金の対象にならないのではないかと指摘しておられる。なぜなら、認証手続きが行われた時点でその送信者アドレスはホワイトリスト登録されるので、「ホワイトリストに登録されていないメールアドレスからのスパムメールを受信しました」の条件が満たされなくなるというのである。確かに理屈は通っている。
 PyTaさんいわく、OptPlusはホワイトリスト登録されたアドレスからしかメールを受けないシステム。だから、「ホワイトリスト登録されていないアドレスからスパムを受けた」という条件は成立し得ない。もしその条件が成立するなら、システムの根幹が壊れているということだから、請求すべきは返金でなく解約である――と。
 本当のところはどうなのかは、ベンダーに問い合わせてみなければわからない。しかし、PyTaさんは、ただ質問するだけでも住所や会社名が必須だというのでやめたとのこと。そこまで個人情報を明かさないと質問に応じてもらえないなら、私も問い合わせる気はない。
 Opt Plus ASPのサービスを買いたい人は(このブログを読んでもなおそう思う人はいないことを祈るが)、「スパマー自身またはアドレスをかたられた人が認証手続きをしたためにスパムが受信された時には返金されるのか」をベンダーに確認した方がよいだろう。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

(続編)
エクスパンションアドレスを設定していたら返金なし

日曜日, 7月 13, 2008

外国から礼状をいただいた

 外国の方から、「あなたのスパムフィルタリングの研究に感謝します」というメールをいただいた。外国からも反響があって非常にうれしく思う。
 その人は、フィルタリング条件を少し変更し、「3ヶ月間でスパムは70~80%減少、偽陽性判定は1件だけ」という効果を得たそうである。おそらく、偽陽性判定の確率を減らすためにフィルタリング条件を緩めたのだろう。独自のフィルタリング条件も工夫したかもしれない。それにしても、偽陽性判定が3ヶ月で1件だけとは驚きである。交信相手の中に逆引きを設定していないサイトがほとんどないのだろうと思われる。
 オリジナルのフィルタリング条件では、ブラックリストと併せて阻止率97~99%を達成できるが、阻止率を下げてでも偽陽性判定を避けたいというポリシーも当然あるだろう。そういう工夫はそれぞれのサイトの自由である。いろいろな工夫があってよい。そうした工夫は、私のオリジナルのアイデアがあってこそ生まれる。私はそのことを光栄に思う。

S25Rにもあるリスクだが…

 5月27日「バウンシングバック認証に応じてもらえないケース」を参照したはてなブックマークに、次のようなコメントが書かれていた。

「業者はあなただけじゃない、商機を逃す」って意見がいいねー でもそれS25Rでもありえるリスクでしょ。

 そのとおり。素のS25R方式でも、正当なメールを受け損なうことでビジネスチャンスを失うリスクはある。DNSBLでもベイジアンフィルタでも同様である。偽陽性判定からの救済を自動で行わないスパム対策方式すべてにそのリスクがある。
 ただ、そのリスクのコントロールのしやすさは異なる。
 OptPlusでは、初めてメールを送ってきた人のメールは、送信者がバウンシングバック認証に応じなければ、受信者のメールボックスに入らずにペンディングキューに留め置かれる。つまり、偽陽性と同等の状態になる。そこからの救済は各ユーザーの責任になる。ペンディングキューの内容が時々メールで通知されるので、差出人アドレスとサブジェクトを手がかりに、バウンシングバック未認証の正当なメールを救済する必要がある。
 S25R方式では、偽陽性判定された送信元ホストからはリトライアクセスが来る。それを発見してホワイトリストで救済するのはメールシステム管理者の責任である。もし正当なメールだったかもしれないリトライアクセスの救済が間に合わなかったのを発見したら、受信者に知らせて判断を委ねる必要がある。DNSBLでもベイジアンフィルタでも、拒否応答コードを「4xx」(再送要求)にして偽陽性判定からの救済を図っている場合は同様である。
 ビジネスチャンスになるかもしれないメールを受信し損なうことは、企業にとって損失になりうる。そこで、「偽陽性判定されたメールが受信者のメールボックスに届かない」ことをリスクととらえて、社を挙げてそのリスクの回避を図ろうとする場合、どんな対策が必要になるか(メールボックスに届いたメールをユーザーが見落とすリスクは、スパム対策のいかんにかかわらずありうるので、ここでは考えない)。OptPlusの場合は、「ペンディングキューを必ず確認せよ」というユーザー教育が必要になる。S25R方式の場合は、ログの監視とホワイトリスト登録、および救済に失敗したと思われるときの受信者への通知を作業手順として定め、メールシステム管理スタッフに守らせる必要がある。
 どちらの方がリスクコントロールがしやすいか。OptPlusでは、どんなにユーザー教育を徹底しようとしても、誰か一人でもペンディングキューの確認の作業手順を怠る確率はゼロにはしにくい(腰を落ち着けてメールを読むことができないほど忙しい人のことを考えてみてほしい)。それに対してS25R方式では、作業手順の教育をメールシステム管理スタッフだけに集中できる。少数のスタッフがログの監視とホワイトリスト登録の作業手順を確実に守ることにより、偽陽性判定されたメールが受信者のメールボックスに届かないというリスクを回避できる。もし救済が間に合わなかったとしても、受信者に知らせることにより、受信者から送信者に連絡をとってコミュニケーションをリカバーできる。
 リスク回避の対策の対象は、ユーザー一人一人に分散させるより、メールシステム管理スタッフに集中させた方がよい。その意味でも、OptPlusよりもS25R方式の方が安全なのである。

土曜日, 7月 05, 2008

違法なHELOアドレスが増えている

 6月には、不正メールアクセス元ホストは7329個だった(うち、フィルタをすり抜けて着信させたものは14個、リトライが長時間続いたのでブロックを解除したらスパムだったのが5個)。そのうち、宛先サーバのIPアドレスまたは受信者のドメインを名乗るという違法なHELOアドレスを名乗ったホストは、驚いたことに4163個(56.8%)もあった。2007年6月の統計では、不正メールアクセス元ホスト6158個のうち違法なHELOアドレスを名乗ったものは866個(14.1%)だった。それに比べて極端に増加している。不正メールアクセスをしてくるホストは増えているが、HELOアドレスが違法でなかったホストの数は、2007年6月には6158-866=5292個だったのに比べて、今年6月には7329-4163=3166個とむしろ減っているのである。
 ただ、違法なHELOアドレスを蹴飛ばすという、副作用のまったくない対策だけでスパムの受信を56.8%前後減らせるかというと、そうとは言えないようである。HELOアドレスが違法でなかったホスト3166個のうち宛先が正しかったものは1066個(33.7%)だったのに対して、HELOアドレスが違法だったホスト4163個のうち宛先が正しかったものは174個(4.2%)しかなかった。つまり、宛先の正しいスパムを送り込もうとしたホスト1066+174=1240個のうちHELOアドレスが違法だったものは174個(14.0%)だから、違法なHELOアドレスのチェックだけではスパムの受信を14%くらいしか減らすことができないということになる(ホスト数とスパムメッセージ数はほぼ同じと仮定している)。
 このことから言えることは、違法なHELOアドレスを名乗るボットを使うスパマーの多くは、送達率に無頓着に(2006年9月15日「宛先の正しいスパムの阻止率」参照)でたらめのアドレスへ多くのスパムをばらまいており、そのようなボットが増えているということである。
 それにしても、なぜ違法なHELOアドレスを名乗るボットが増えているのだろうか。これによって何らかのスパムフィルタを突破できるわけではなく、むしろ、確実に不正なメールアクセスだと判断できる手がかりを与えるだけである。こんなアホなボットを使うスパマーの考えていることがさっぱりわからない。

水曜日, 6月 25, 2008

「阻止率97%以上」

 「スパム対策技術」の目次ページに記載しているS25R方式の要点に

効果:
●スパムとウィルスメールの全アクセスに対する阻止率約99%。
●宛先の正しいスパムの阻止率約97%。

と書いていたが、「宛先の正しいスパムの阻止率97%以上」と書き直した。宛先の正しいスパムの阻止率が1ヶ月ほどの統計で97%を下回ったことはほとんどなく、むしろ最近では98%くらいになることが多いので、効果をよりアピールする表現にした。
 でたらめのアドレスに宛てられたものも含む不正メールの全アクセスに対する阻止率は、99%を下回ることがあるかもしれないが、それでも98%くらいにはなっていると思う。S25R方式の効果は衰えていないので、「阻止率99%のスパム対策方式の研究報告」という論文のタイトルを今さら取り下げる気はない。おとりのアドレスを拾わせてわざとスパムアクセスを増やして統計をとった結果、2004年4月に阻止率99.1%になったというのは嘘ではないのだし。

日曜日, 6月 08, 2008

バウンシングバック認証はタブーの技術

 届いたメールに対して「メールを送ったのは本当にあなたですか?」と確認を求めるメールを自動返送するバウンシングバック認証方式は、なにもOptPlusの開発元のヌリビジョン社の発明ではない。昔から使われている工夫である。
 たとえば、自動登録方式のメーリングリストでは、参加希望者が登録要求メールを送ると、登録確認要求メールが自動返送されてくる。そこにはパスワードが書かれていて、それをもう一度送信すると登録される。
 このバウンシングバック認証は、誰かが他人のアドレスをかたってメーリングリストに登録するといういたずらを防ぐためである。アドレスをかたられた被害者には、身に覚えのない登録確認要求メールは迷惑なものには違いない。しかし、これをしないことには、被害者は、望んでもいないメーリングリストの配信メールを多量に受けるという、より大きな迷惑を受けてしまう。被害者を大きな迷惑から守るために、メーリングリストの自動登録のバウンシングバック認証は必要なのである。そこが、スパマーにアドレスをかたられた被害者にとってはただ迷惑なだけのOptPlusのバウンシングバック認証要求とは異なる。
 メーリングリストの自動登録に昔から使われているバウンシングバック認証方式を、自分がスパムを受けないための対策に使えないかというアイデアを思い付いた人は、おそらく何人もいるだろう。しかし、メールシステムを理解している人はすぐにいろんな問題に気付く。

●メールトラフィックを増やすことになる。
●送信者に手間をかけさせるのは失礼ではないか?
●送信者が認証手続きをしてくれなかったら、正当なメールを見逃すおそれがある。
●自分が送信したメールのエラー差し戻しに対して認証要求をかけたら、エラーに気付かない。認証要求をかけないようにしたら、エラー差し戻しを装ったスパムを防御できない。
●スパマーに送信者アドレスをかたられた被害者に届くバウンシングバック認証要求は迷惑メールになる。
●送信側でもバウンシングバック認証方式をとっていたら、バウンシングバック認証要求のメールループが起こるから、その防止策も考えなければならない。
●送信側でもバウンシングバック認証方式をとっていたら、互いに相手からのメールに気付かないデッドロック状態(やぎさんゆうびん問題)に陥る。

これほどいろんな問題が懸念されることに気付いたら、「これじゃ使い物にならない」と思うだろう。
 メーリングリスト登録やその他のサービスの自動受付プログラムならともかく、人に宛てられたメールにバウンシングバック認証方式を適用することは、メールシステムを知る技術者にとってタブーだったのである。だから、スパム対策の研究者の間で議論にもなっていなかったのである。そのタブーを犯したのがOptPlusである。すべての問題を解決してタブーを破ったのなら賞賛もしようが、本質的に避け得ない問題をバウンシングバック認証方式は内在しているのである。
 企業の経営者層の人は、メールシステムをよく知らなくてバウンシングバック認証方式の問題点に気付かず、「OptPlusは画期的なスパム対策製品」という宣伝を鵜呑みにしかねない。バウンシングバック認証方式のタブーに漠然と気付いていながら、それを経営者層にうまく説明できない技術者は、OptPlusの導入を阻止できないかもしれない。そうなると、宛先の不正なバウンシングバック認証要求メールで他人に迷惑をかけ、また、ユーザーは、バウンシングバック未認証を心配してペンディングキューを見なければならないメーリングリストに投稿する時にはFromヘッダのアドレスをエクスパンションアドレスに変えなければならないという不便を強いられるのである。
 バウンシングバック認証方式の問題に漠然と気付くのにとどまらず、緻密に考察して指摘してきたのは、おそらく私だけだろう。メールシステムをよく知らない人たちを、OptPlusを買わないよう説得するため、また、簡単で効果が高くて無料で使えて、すでに多くのサイトで使われている実績のあるS25R方式という対案があることを説明するために、2007年5月14日「バウンシングバック認証という無茶なやり方」に始まる私のバウンシングバック認証方式反対キャンペーンの一連の記事が役立てば幸いである。

金曜日, 6月 06, 2008

メーリングリストはOptPlusの鬼門

 もういいかげんOptPlus批判はやめようかとも思っていたのだが、バウンシングバック認証方式の問題点に次から次へと気付いてしまうので、やはり書いておくことにする。
 バウンシングバック認証方式反対キャンペーンの最初の記事である2007年5月14日「バウンシングバック認証という無茶なやり方」では、
「なぜ無茶か。メーリングリストや、メールマガジンや、オンラインショッピングの確認メールのことをちゃんと考えているとは思えないからである。」
と書いた。しかし、これは誤りだった。バウンシングバック認証にかけないように登録したエクスパンションアドレスという別アドレスで受信する方法が用意されている。
 ただ、メーリングリストが、登録要求メールを送るとそのFromヘッダのアドレスへ登録確認要求メール(「本当にあなたが登録要求を送ったのであれば、確認のためのメールを再度送ってください」と案内するメール)が自動返送されるという仕組みである場合、それをバウンシングバック認証にかけずに受信するために、Fromヘッダのアドレスをエクスパンションアドレスに変えて登録要求メールを送る必要がある。これは面倒なことである。そのことを2007年5月27日「バウンシングバック認証はやはりやっかい」に書いた。
 今回述べるのは、問題はそのような面倒さにとどまらず、「OptPlusユーザーがメーリングリストに参加することでスパムがバウンシングバック認証をすり抜けるリスクがある」ということである。「風が吹けば桶屋が儲かる」みたいな話だが、考えていくとちゃんとそういう結論になる。

 まず、Fromヘッダのアドレスをエクスパンションアドレスに変えて登録要求メールを送ったとする。その理由は、上述のように、自動返送される登録確認要求メールをバウンシングバック認証にかけずに受信するためということにしておく(別の理由もあるのだが、それについては後述する)。
 そして、登録確認要求メールの指示に従って登録手続きが完了したとする。登録されたアドレスは、OptPlusユーザーの通常のアドレスではなく、エクスパンションアドレスである。
 こうなると、メーリングリストに投稿する時には毎回Fromヘッダをエクスパンションアドレスに設定しなければならない。なぜなら、たいていのメーリングリストでは、部外者からの不正な投稿を防ぐために、登録されたアドレスでしか投稿を受け付けないようになっているからである。
 つまり、そのOptPlusユーザーが投稿メールのFromヘッダによってメーリングリストメンバーに公開するアドレスは、通常のアドレスではなく、エクスパンションアドレスになる。
 さて、ここで、そのメーリングリストのメンバーの誰かのPCがウィルス感染して(あるいはスパイウェアによって)、メーリングリストで配信されたメールから拾い出されたメールアドレスがスパマーに漏洩したとしよう。そうなると、スパマーはOptPlusユーザーのエクスパンションアドレスに向けてスパムを送ってくる。そのスパムは、バウンシングバック認証にかからずに通過する。つまり、エクスパンションアドレスでメーリングリストに参加することで、スパムがバウンシングバック認証をすり抜けて着信するということになるのである。
 「スパムを1通でも受けたら返金します」と豪語しているOpt Plus ASPは、このような場合に返金してくれるだろうか。おそらく返金に応じてはくれないだろう。「エクスパンションアドレスを他人に広く公開したユーザーに責任がある」と言うだろう。そうせざるを得ない仕組みであるにもかかわらず。

 では、通常のアドレスでメーリングリストに参加したらどうだろうか。自動返送される登録確認要求メールに対してバウンシングバック認証要求メールが自動返送される。それがメーリングリスト管理者に迷惑になるという問題はさておき、OptPlusユーザーが登録確認要求メールをペンディングキューから救済すれば、登録手続きを完了することができる。
 その後、いろんな人がメーリングリストに投稿したメールが配信されてくる。それがまたバウンシングバック認証にかけられる。
 ここで、メールをペンディングキューから救済した時にホワイトリスト登録されるのが、MAIL FROMコマンドで通知される送信者アドレスなのか、Fromヘッダのアドレスなのかが問題になる。個人がメーラーで送信するメールでは両者は同じである。しかし、メーリングリストで配信されるメールの場合は、Fromヘッダは投稿者のアドレスのままだが、送信者アドレスは、「owner-メーリングリスト名」、「メーリングリスト名-admin」などのような、メーリングリスト管理者のエイリアスに書き換えられる(これはエラーバウンスの返送先になる)。
 ホワイトリスト登録されるのが送信者アドレスであれば、問題はさほど大きくない。バウンシングバック認証要求メールがメーリングリスト管理者へ飛ぶが、いったんペンディングキューから救済すれば、その後は、そのメーリングリストで配信されたメールは、誰が投稿したものであっても受信できるようになる。
 ところが、ホワイトリスト登録されるのがFromヘッダのアドレスだとしたら大変である。すべての投稿者にバウンシングバック認証要求メールが飛ぶことになる。それを受けた投稿者は、「私はメーリングリストに投稿したのであって、あなた個人のことは知らない。メールを疑うなら勝手にしろ」と思ってバウンシングバック認証に応じない可能性が高い。OptPlusユーザーは、いろんな投稿者からの投稿メールをいちいちペンディングキューから救済しなければならない。
 あらかじめメーリングリストのメンバー全員のアドレスをホワイトリスト登録するのは大変である。第一、登録メンバーのアドレスリストは重要な個人情報である。メーリングリスト管理者がおいそれと開示するわけがない(たとえば同窓会のような、メンバーの限定されたメーリングリストならともかく、誰でも参加できるオープンなメーリングリストでは)。
 というわけで、結局のところ、OptPlusがFromヘッダのアドレスをホワイトリスト登録する仕組みであれば、メーリングリストにはエクスパンションアドレスで参加せざるを得ないということになるのである。

 OptPlusユーザーがメーリングリストに参加しようとすると、これほどまでにやっかいで、しかも、エクスパンションアドレスが漏洩してスパムを受けてしまうリスクがあるのである。それでもOptPlusを買いますか?
 S25R方式を知らずにこの記事にたどり着いた人のために説明しておくと、S25R方式とは、送信元IPアドレスの逆引き結果から送信元をエンドユーザーコンピュータと推定した場合に再送要求を返して受信を拒否することにより、ボットからの再送しないスパムアクセスを阻止する(メールサーバを誤判定した場合は再送アクセスが来るので、ホワイトリストで救済する)という単純な方法。Postfixの設定だけで実現でき、97~99%のスパムを阻止できる。メーリングリストへの参加だろうと何だろうと、ユーザーにとってメールの送受信方法は対策前と何も変わらない。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

火曜日, 5月 27, 2008

ペンディングキュー管理機能は使いやすいか?

 OptPlusをヨイショしている「政府研究会の先を行く! スパム完全シャットアウトを実現した革新技術とは」という記事の2ページ目に、ペンディングキューの内容を通知するメールの例が図示されている。前回述べたように、正当なメールがバウンシングバック未認証のままになるリスクはどうしても避けられないから、このようなペンディングキュー管理機能は不可欠である。
 ところが、図を見ると、ペンディングキューにたまったバウンシングバック未認証のメールが正当なメールかスパムかを判定する手がかりは、差出人アドレスとサブジェクトしかない。これでは判定が難しそうである。
 サブジェクトが「裏DVDの激安販売」だったら、明らかにスパムとわかる。しかし、「考えてくれていますか」ではどちらかわからない。もしかしたら、受信者が営業活動で社外の人と名刺交換した時に「その件については考えておきましょう」と発言し、その相手の人が「考えてくれていますか」というサブジェクトでメールを送ってきたのかもしれない。あるいは、スパマーが本文を読ませようとして思わせぶりなサブジェクトを付けたのかもしれない。差出人アドレスからも判別がつかないこともある。名刺交換した相手が、名刺に書かれたアドレスでメールを送ってくるとは限らず、たとえば携帯電話から送ってくることもありうるからである。
 スパムかどうかわからないメールは、本文を見て確認するしかない。本文を確認するには「インポートする」のリンクをクリックするしかないと思われ、そうしたら、スパムの差出人アドレスがホワイトリスト登録されてしまうおそれがある。それを取り消す方法はあるのかもしれないが、どうすればよいのかはわからない。
 こんなことなら、PC上のベイジアンフィルタでスパム判定のマークをサブジェクトまたは他のヘッダに付け、メーラーでごみ箱に自動振り分けする方が、確認が楽ではないだろうか。ごみ箱に振り分けられたメールのうち、サブジェクトで明らかにスパムとわかるものは無視すればよく、スパムかどうかわからないメールは本文を一瞥すればよいからである。
 それに、OptPlusはベイジアンフィルタでスパム判定したメールをブロックするので、偽陽性判定された正当なメールがペンディングキューまで届かないおそれがある(4月12日「OptPlusも失礼な受信拒否をしそうだ」)。ウィルスチェックの偽陽性判定によるバウンスなら、添付ファイルを取り除いたメールを送り直して連絡をとることができるが、ベイジアンフィルタによる偽陽性判定でバウンスされると、送信者はどうすればよいのかわからない。商談を申し込もうとした送信者が怒ってそれっきりメールを送り直さず、ビジネスチャンスが失われるおそれがある。それよりは、偽陽性判定されたメールは「スパムの疑いあり」のマークを付けて受信者に届けた方がましである。
 S25R方式なら、そのようなことに気を病む必要はない。受信者にとって、受信のしかたは対策前とまったく変わらない。ただ、送信元ホストの逆引き結果によって偽陽性判定されたメールは、メールシステム管理者がリトライアクセスを発見してホワイトリスト登録するまで受信が遅延するということを承知していればよい。スパムの阻止率は100%にはならないが、97~99%。一日200通のスパムを受けていた人の場合でも、着信してしまうスパムは一日平均6通以下。手動で捨てるのに苦労はない程度である。リトライ期間が1~2日と短いメールアクセスを週末の間に救済しきれないリスクはあるが、メールシステム管理者が拒絶ログソーティングスクリプトでリトライアクセスを発見して受信者に知らせてあげれば、受信者は送信者に受信失敗を詫びて再送を依頼することで、コミュニケーションをリカバーできる。もちろん、グレイリスティングの併用によって偽陽性判定からの救済を自動化すれば、そのリスクも回避できる。
 OptPlusまたはバウンシングバック認証方式を調査しようとしてこのブログにたどり着いた人は、ぜひS25R方式の導入を検討していただきたい。S25R方式は、スパムの阻止率は100%ではなくても十分に高く(DNSBLよりもベイジアンフィルタよりも)、正当なメールを受信し損なってしかもメールシステム管理者がそれに気付けないというリスクはほとんどなく、しかも無料で導入できるのだから。
 S25R方式や他のスパム対策方式を批判しながら、スパムに困っている人たちを救う具体的な方策を何ら提案しない人もいるが、私は違う。すでに多数の人たちに支持されている実績のあるS25R方式という対案を提示できるからこそ、危険な副作用のリスクがあるバウンシングバック認証方式とOptPlusをこうして強く批判することができるのである。

バウンシングバック認証に応じてもらえないケース

 OptPlusをヨイショしている、マイコミジャーナルの「政府研究会の先を行く! スパム完全シャットアウトを実現した革新技術とは」という記事の2ページ目に、

「認証依頼メールを送信することにより、"不審者を社内に寄せ付けない企業"というクリーンなイメージを持っていただけるケースが多い」

と書かれている。私は、私にメールをくれる善良な送信者に対して認証手続きの手間を要求する気にはとてもなれない。とはいえ、認証手続きの手間を要求されて腹を立てる善良な送信者は私が気兼ねするほどには多くないだろうということは認めよう。
 しかし、それでもなお、OptPlusのユーザーは、正当な送信者なら必ずバウンシングバック認証に応じてくれるとあてにしてはならないということを指摘しておこう。その理由として以下が考えられる。

■事故による不到達
 最近ではめったに起こらないことではあるが、メール配送の事故によってバウンシングバック認証要求メールが送信者に到達しないおそれは皆無ではない。

■見落とし
 送信者がメールを送信した後、受信操作をした時に、バウンシングバック認証要求メールがたくさんのメール(スパムもあるかもしれない)にまぎれてしまい、しかも「先方から返事が来るのは早くても数時間後。即座に来ることはよもやあるまい」という思い込みが重なって、バウンシングバック認証要求メールを見落としてしまうケースが考えられる。

■認証画面が送信者のブラウザに対応できない
 Opt Plus ASPのページに示されているバウンシングバック認証要求メールの文例には、「携帯電話からは認証できません」とある。つまり、認証画面が携帯電話に対応していないため、携帯電話メールの送信者は認証に応じようにもできないということである。
 また、同社のFAQのページによると、管理画面が対応するブラウザはInternet Explorerのバージョン6以降だけだという。認証画面は管理画面とは違うのかもしれないが、Firefox、Operaなどさまざまなブラウザで認証手続きができるのかどうか不安である。

■送信側でもバウンシングバック認証方式をとっている
 このケースでは、受信側サイトから返されるバウンシングバック認証要求メールに対するそのまたバウンシングバック認証要求メールが送信側サイトから送信される。受信側サイトからのバウンシングバック認証要求メールは未認証のまま送信者のペンディングキューに入れられ、送信者はしばらくそれに気付かない。そのため、送信者が認証手続きを行わない。
 双方が同じことをすることによって互いに情報が伝わらなくなるデッドロック状態。私はこれを、白やぎさんと黒やぎさんが共に相手からの手紙を食べてしまったという童謡にちなんで「やぎさんゆうびん問題」と名付けた。このデッドロックから抜け出すには、少なくともどちらかがペンディングキューからメールを救済するしかない。

■「業者はあなただけじゃない」
 送信者が、ある種の製品を買いたいと思って、今まで名刺交換したことのあるたくさんの業者の営業担当者に片っ端から問い合わせのメールを送ったとする。特にどの業者が良さそうかはわかっていなくて、誠実な回答を遅滞なく返してくれた業者と話をしようと思っていた。受信者にとってはビジネスチャンスである。
 ところが一部の業者は、「認証手続きをしてくれなければあなたのメールを受け取ってあげません」と解釈されるバウンシングバック認証要求を自動返送してきた。そんなとき、送信者が「ぜひとも受け取ってくれなくてもいいよ」と思って認証手続きをせずにほったらかしたとしても不思議はない。

 こういうことがありうるから、OptPlusで正当なメールを受信し損なわないためには、ユーザーがペンディングキューを定期的に確認することが不可欠なのである。
 では、ペンディングキューの確認は容易な作業なのだろうか。それについては次の記事で。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

木曜日, 5月 22, 2008

スパムの大量差し戻しの蹴り方

 スパマーに送信者アドレスをかたられて、user unknownになったスパムの差し戻しが大量に殺到しては、大変な迷惑である。5月18日「バウンシングバック認証のもう一つの穴」で、BBSのゲストのkkkさんが677通のスパム差し戻しを受けられたことを書いた。その日はほとんど仕事にならなかったそうである。
 その記事では、「差し戻しはメールサーバから送られてくるから、残念ながらS25Rでは阻止できない」と書いた。しかし、仕事にならなくなる前に防御する方法があることを思い出した。私がS25R方式を考案する前に使っていた内容チェックである。差し戻されてくるスパムの文面が同じならばこの手が使える。
 main.cfファイルには、あらかじめ

body_checks = regexp:/etc/postfix/body_checks

という指定を書き込んでおき、空のbody_checksファイルを用意しておく。スパムの大量差し戻しを受けたら、差し戻しメールに引用されているスパムの文面から特徴的な文字列を抽出し、それをbody_checksファイルに指定して「postfix reload」を実行する。特徴的な文字列としては、スパマーが誘導しようとするサイトのURLがよい。
 私のアドレスを送信者アドレスにかたったスパムが私に差し戻されてきた例を挙げる(この時はこれ1通で済んだ)。

Hi. This is the qmail-send program at gaba-network.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<***@gaba-ca.org>:
This address no longer accepts mail.

--- Below this line is a copy of the message.

Return-Path: <deo@gabacho-net.jp>
Received: (qmail 14545 invoked from network); 17 Feb 2008 13:23:39 -0800
Received: from 82-34-216-89.cable.ubr08.gill.blueyonder.co.uk (HELO flibble) (82.34.216.89)
  by air479.startdedicated.com with SMTP; 17 Feb 2008 13:23:39 -0800
X-Mailer: CME-V6.5.4.3; MSN
Return-Path: ***@cimail15.msn.com
Received: (qmail 37667 by uid 140); Sun, 17 Feb 2008 10:27:30 GMT
Message-Id: <20080217102730.37669.qmail@flibble>
To: <***@gaba-ca.org>
Subject: February 71% OFF
From: <***@gaba-ca.org>
MIME-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr">
…(略)…
<a href="http://track.msadcenter.lyv.com/wwfdtge_ovatpimxtn.html" target="_blank">Click here to get enrolled for your ndnn !</a><br><br>
<img src="http://track.msadcenter.rcy.com/qlooaza-ovatpimxtn.gif" border=0 usemap="#Map">
…(略)…

もし同じ文面のスパムが大量に差し戻されてきたら、<A>タグで指定されたURLを拾って、body_checksファイルには次のように記述する。

/http:\/\/track\.msadcenter\.lyv\.com\/wwfdtge_ovatpimxtn\.html/ REJECT

 これにより、差し戻しの受け取りが拒否される。差し戻そうとしたサイトのポストマスターに差し戻し失敗の通知が行くのは迷惑かもしれないが、やむを得ない。こちらの自己防衛のためである。
 そもそも、MXサーバで受け取った後にuser unknownを検出して送信者アドレスへ向けて差し戻すというシステム構成が良くないのである。外部から最初にメールを受信するMXサーバにサイト内のユーザーリストを持っておいて、サイト内部でuser unknownになることをMXサーバがただちに判定して受け取りを拒否するシステム構成の方がよい。そうすれば、アドレスをかたられた被害者に不正な差し戻しが行くことはなくなるし、でたらめの送信者アドレスをかたったスパムの差し戻しが失敗してポストマスターに通知が殺到することもなくなる。もっとも、qmailでは難しいのかもしれないが。

バウンシングバック文例の問題点

 Opt Plus ASPの「100%スパムメールブロックの仕組み」というページに書かれているバウンシングバック認証要求メールの文例は次のようになっている(メールアドレスの例示は、この記事からスパマーに拾われないように伏せ字にする)。

メールをいただき、ありがとうございます。

株式会社ネオジャパンのinfo@*********.comです。
このメールは自動的に返信されています。

当社では情報セキュリティ強化を目的として、スパム(迷惑)メール防止のための送信元認証システムを導入・採用しています。
お手数をおかけし誠に申し訳ありませんが、まず「認証を行う」ページにて送信元認証をしていただきますよう、お願い申し上げます。

一旦認証されメールが配送された以降は、今後メールを送信いただく際に都度認証していただく必要はございません。

弊社の情報セキュリティ対策に、ご理解・ご協力の程どうぞよろしくお願い申し上げます。

認証を行う

注意:
10日以内に、認証してください。
認証いただけない場合、送信いただいたメールが自動的に破棄されてしまいますのでご注意ください。
携帯電話からは認証できません。受信者側で手動認証いたしますので、本メールは無視してください。

ご協力ありがとうございました。

 この文例は、スパマーに送信者アドレスをかたられた被害者にバウンシングバック認証要求が届きうるということをベンダーがまったく考えていないことを物語っている。これでは、前回述べたように、アドレスをかたられた被害者が意味もわからず、あるいは不要メールを送り付けられた怒りで認証手続きをしてしまう可能性がある。
 アドレスをかたられた被害者にバウンシングバック認証要求メールを殺到させてしまう迷惑を申し訳ないことだと自覚しているなら、せめて次のような文を入れるべきである。

「もし弊社にメールを送信されたお心当たりがないのにこのメールが届いたならば、他人があなた様のメールアドレスを不正に使用して弊社にメールを送信したことが考えられます。その場合はこのメールを無視してください。ご迷惑をおかけしたことをお詫びいたします。」

 もし今後、文例がこのように直されていたら、ベンダーが私のブログを見たということだろう。
 ついでに言うと、「10日以内に認証してください」という依頼は不要である。受信者は、正当な送信者が認証要求に応じてくれなかった場合に備えて、定期的にペンディングキューを確認しなければならない。「10日以内」というのはその猶予である。ペンディングキューを10日間も確認しなかったら、それは受信者の怠慢である。10日という期限を正当な送信者に意識させる必要はない。「認証いただけない場合、送信いただいたメールが自動的に破棄されてしまいます」という警告ももちろん不要である。
 もう一つ言うと、「携帯電話からは認証できません。受信者側で手動認証いたしますので、本メールは無視してください。」と言うくらいなら、バウンシングバック認証要求メールそのものが不要である。受信者がペンディングキューに注意していればよい。このことは2007年6月17日「OptPlusの機能を考える」でも述べた。
 私のブログのバウンシングバック認証方式反対キャンペーンを読んでもなおOptPlusを買おうと思う人がもしいたら、せめてバウンシングバック認証要求メールの送信はオフにして使ってほしい。ペンディングキューを監視していさえすれば、バウンシングバック認証要求メールは必要ないのだから。

日曜日, 5月 18, 2008

バウンシングバック認証のもう一つの穴

 最近、職場の人がスパマーに送信者アドレスをかたられてスパムのエラー差し戻しを大量に受けた。社外からのmailer-daemonまたはpostmaster発のメールをごみ箱に振り分けるようにメーラーBecky!を設定してあげた。自分が社外へ送ったメールのエラー差し戻しもごみ箱に振り分けられてしまうようになるが、緊急策としてやむを得ない。スパムの差し戻しは一日でやんだようである。
 BBSで何度かホワイトリスト情報をお寄せくださっているkkkさんも、アドレスをかたられてスパムの差し戻しを677通受けられたそうである。差し戻しはメールサーバから送られてくるから、残念ながらS25Rでは阻止できない。
 そして、バウンシングバック認証要求メールも4通受けたとのこと。そのうち1通はウェブページへのアクセスを要求するもの、3通は返信メールを要求するものだったそうである。OptPlusはウェブページへのアクセスを要求する方式なので、バウンシングバック認証方式をとるシステムはOptPlusだけではないらしい。
 kkkさんいわく「不愉快ですね」と。そりゃそうだ。スパムのエラー差し戻しが大量に押し寄せ、それに加えて、送ってもいないメールへのバウンシングバック認証要求を送り付けられては、頭にきて当然である。数が少なければよいというものではない。みんながやると大きな被害になることを「自分一人くらい」と思ってやるのがいけないのである。
 さて、アドレスをかたられてバウンシングバック認証要求を受けた被害者が認証要求に応じたらどうなるか。当然、スパムは通過することになる。被害者が認証要求に応じる理由には以下が考えられる。

■報復
 アドレスをかたられた被害者への迷惑を省みないバウンシングバック認証方式を使うサイトに対して、報復のためにスパムを通過させる。

■親切
 OptPlusを使ったASPが「スパムを1通でも受けたら返金します」と豪語していることを知っている人が、ユーザーに返金を受けさせてあげようという親切心でスパムを通過させる。もっとも、豪語するASPに損失を与えようとするものだから、これをやるのもバウンシング認証方式反対派の人であろう。

■天然
 「なんかよくわからないんだけどー、クリックしてくれってメールに書いてあったので、クリックしましたー!」

 OptPlusの開発者やベンダーは、よもやそんなことはあるまいと思っているふしがあるが、よもやあるまいと思うことが起こるのが世の中である。アドレスをかたられた被害者に、ごみメールを増やすという迷惑をかけておきながら、その人が認証手続きをしないことによってスパムの阻止に当然協力してくれるだろうとは、ずいぶん虫のいい考えだと思う。
 ここまで書いてきてふと気が付いた。スパマー自身が認証要求に応じることによってスパムを通過させることも考えられる。送信者アドレスを詐称せずにバウンスをまともに受け、バウンシングバック認証要求メールに書かれたURLに自動アクセスするか、またはそれに自動リプライすることは、技術的に可能であろう。CAPTCHA認証を突破する技術も進みつつあるとの情報もある。
 100%のスパム阻止などあり得ないのである。

土曜日, 4月 12, 2008

OptPlusも失礼な受信拒否をしそうだ

 SYSMATE社の、OptPlusの説明ページにこんな記述がある。

第1次フィルタ : ディクショナリ・アタックチェックエンジン
偽装アカウントからのスパムメールや機械的に送信先を作成して送付してくるディクショナリアタックをサーバの交信のみでブロック。
ブラックリストに登録されているドメイン、IP、E-mailアドレスからのメールをブロック。

第2次フィルタ : ウィルス・パターンチェックエンジン
ウィルスパターンチェックでウィルスメールと判断されるメールをブロック。

第3次フィルタ : スパム・パターンチェックエンジン
スパムパターンチェックでスパムメールと判断されるメールをブロック。
ベイジアン・フィルタにより、スパムメール判定を実施。
メール・ルールに準拠しないメールのブロック。

第4次フィルタ : バウンシング・バック送信元チェックエンジン
送信者入力認証を利用した、最強のフィルタエンジンでメールを確実にブロック。

まず、バウンシング・バックエンジンが機能する前に偽装されたアカウントに対する配信やウィルスメール等は3段階のフィルタエンジンでブロックします。ここで約15%以下に抽出されたメールに対して、スパム判定を行います。
それがバウンシング・バック認証エンジンです。

 ここから読み取れることは、ベイジアンフィルタでスパムパターンに引っかかったメールはブロックされ、バウンシングバック認証待ちのペンディングキューに入らないらしいということである。すなわち、ペンディングキューに入るスパムはベイジアンフィルタをすり抜けた約15%だけと思われる。私は2007年6月17日「OptPlusの機能を考える」で
(3) スパムパターンチェック …(略)… おそらく、ここでスパム判定されたメールは、捨てずにペンディングキューに入れるのだろう。偽陽性判定された正当なメールをユーザーが拾い出せなければ困るから。」
と述べたが、どうもそうではないらしい。
 考えてみたら、ベイジアンフィルタに引っかかったかどうかにかかわらずスパムをすべてペンディングキューに入れたら、ユーザーはその中身を確認するのが大変である。これでは販売戦略的にまずい。ベイジアンフィルタでスパムとわかる約85%のスパムをすべてブロックし、念のために確認しなければならないスパムを15%くらいに減らしてこそ、客に「いいねえ」と言ってもらえる。
 ということはどういうことか。ベイジアンフィルタで偽陽性判定された正当なメールに対して失礼な受信拒否をするということである。私が運用するメーリングリストで配信した会合案内のメールがスパム判定されて失礼にも「5xx」で蹴られた実例を再掲する。前者はインドの会社、後者はアメリカの著名な学会である。

<***@edkal.com> (expanded from <***-outgoing>): host
    mail.edkal.com[202.71.131.52] said: 550 Rejected. Classified as
    ****SPAM**** (in reply to end of DATA command)

<***@computer.org> (expanded from <***-outgoing>): host
    hormel.ieee.org[140.98.193.224] said: 554 5.7.1 Message scored extremely
    high on spam scale.  No incident created. For details, send to
    postmaster@ieee.org. You can also send a plain text message to the
    recipient and request adding your address to his/her UCE whitelist. (in
    reply to end of DATA command)

 おわかりだろうか。OptPlusもおそらく同じことをするのである。スパム判定時に「4xx」(再送要求)を返し、同じメールが再送されてきたら受け入れるという救済措置がもしあれば、偽陽性判定を心配する人にアピールするアドバンテージになるはずであるが、そのことは何も述べられていない。
 念のために言っておくが、ベイジアンフィルタが偽陽性判定を絶対に起こさないなどということはあり得ない。上記のように、理由のわからない偽陽性判定の被害を実際に私は受けている。まして、スパムを引用して「こんな変なメールを受けたんですが、どうしたらいいですか?」と相談するメールや、「スパムによくあるviagra、cialis、xanaxという語は薬物の名前です」などのように書いたまともなメールが偽陽性判定される確率はきわめて高い。
 改めて私は、次の二つの重大な理由により、OptPlusを買わないよう強く訴える。

●詐称された送信者アドレスへバウンシングバック認証要求メールを返すことにより、アドレスをかたられた無実の被害者に迷惑をかける
●ベイジアンフィルタで偽陽性判定された正当なメールを(一時的にでなく完全に)受信拒否することにより、善良な送信者に迷惑をかける。そのメールを受けるはずだった受信者にも迷惑をかける

 いくらスパムを憎んでも善良なインターネットユーザーには決して迷惑をかけまいと思う日本的美徳をわきまえた日本人は、この韓国製の製品を使ってはいけない。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

水曜日, 4月 09, 2008

バウンシングバックはスパム受信を増やすかも

 2007年5月14日にバウンシングバック認証方式反対キャンペーンを始めてから早いもので11ヶ月になる今日このごろ。2007年9月5日掲載のヨイショ記事にとんでもないことが書かれているのを見つけた。OptPlusの輸入ベンダーであるネオジャパンの取締役の言葉として書かれていたもの。

「送信したメールの数だけ認証依頼メールが届くため、スパマーを攻撃することにもつながる」(狩野氏)という。

なんちゅうことおっしゃるの!
 スパムの送信者アドレスに向けて大量のメールを送り付けることによってスパマーに被害を与えることができるくらいなら、みんなやっている。それはやってはならないことだというのは常識である。もちろん、スパマーは送信者アドレスを詐称するからである。スパムの送信者アドレスへメールを返すことは、アドレスをかたられた罪のない被害者を攻撃することになるのである。
 もう一つ、スパムに返信してはならないとされる理由がある。受信者アドレスが有効であることをスパマーに教えてしまうおそれがあるからである。この、やってはならないとされることを自動でやってくれるのがバウンシングバック認証方式である。
 もしスパマーが、罪のない他人のアドレスを送信者アドレスにかたらずに、バウンスが自分に返るように送信者アドレスを設定することがあるとすれば、宛先アドレスの正しさを確認するためだろう。当然、大量のエラーバウンスを受けても平気なように受け口を準備する。そしておそらく、受けたバウンスを自動処理する。mailer-daemonまたはpostmasterを送信者アドレスとするバウンスが入ってきたら、宛先アドレスは無効だったと知ることができる。送信に成功したスパムに対するバウンスが来なければ、宛先アドレスは有効だった可能性が高いと判断できる。そして、スパムに返信する人がいたら、宛先アドレスは有効だったと判断できる。バウンシングバック認証依頼メールを自動送信した場合もそれと同じである。バウンシングバック認証方式は、スパマーに「あなたが送ったスパムの宛先アドレスは正しいものでした」と積極的に教えることになるのである。
 OptPlusのベンダーはこう言うだろう。「有効なアドレスであることをスパマーに知られてスパムが増えても、OptPlusはスパムを100%遮断してくれるのだから平気だ」と。しかし、スパムはペンディングキューに入る。ユーザーは、正当な送信者がバウンシングバック認証に応じてくれなかった場合に備えて、ペンディングキューを定期的に見なければならない。受信するスパムが増えれば、ペンディングキューから正当なメールを探し出す作業はより大変になる。初めのうちは少ししかスパムを受けていなかったユーザーも、スパムに対してバウンシングバック認証依頼メールが送られ続けることによって、だんだん多くのスパムを受けるようになるおそれがある。
 そして、すでに私が指摘しているとおり、バウンシングバック認証方式は破る方法がある。受信者がホワイトリスト登録していそうなアドレスを送信者アドレスにかたればよい。OptPlusのユーザーのメールアドレスを有効なアドレスとして知るスパマーが増えるほどに、いったん破られたら被害は大きくなる。
 そもそも、詐称が容易な信頼できない情報である送信者アドレスを、正当なメールかどうかの判定に使おうというのが間違っているのである。

土曜日, 3月 29, 2008

拒絶ログソーティングスクリプトを改良

 拒絶ログソーティングスクリプトを改良した。変更点は以下のとおりである。

■単独のアクセス記録の表示を抑止するスイッチ
 リトライしなかった単独のアクセスの記録を抑止してリトライシーケンスだけを表示したい場合のために、コードの改造方法を説明していた。しかし、そのように改造すると、最後に表示するアクセス数と推定メッセージ数が、リトライシーケンスのアクセスについてのみのカウントになってしまい、全体のアクセスについてのデータがわからなくなってしまっていた。
 そこで、単独のアクセスの記録を抑止してもアクセス数と推定メッセージ数のカウントが変わらないように改良した。
 その際、単独のアクセス記録の抑止をオン・オフするスイッチの変数を設け、その初期値を書き換えるだけで済むようにした。単独のアクセス記録を抑止するには、最後のプロセスのGAWKスクリプトで

Suppress_single_access_records=0

という行を

Suppress_single_access_records=1

と書き換えればよい。

■sortコマンドで-kオプションを使用
 sortコマンドでソートキーを指定するために、今まで

sort +POS1 -POS2

という形式を使っていたが、もう一つの指定方法である

sort -k POS1,POS2

という形式に変更した。BBSで、システムによっては前者の形式が使えなくなっているという情報をいただいたからである。
 レコードの5、6、7番目のフィールドであるクライアントIPアドレス、送信者アドレス、受信者アドレスをキーとしてソートするには、前者の形式では

sort +4 -7

と書く。「+4」はキーの開始フィールドで、0から数えたフィールド番号である。「-7」は、0から数えたフィールド番号の7よりも前までという意味である。ややこしい。後者の形式では、フィールド番号は1から始まるように数え、

sort -k 5,7

と書く。GAWKでのフィールド番号の数え方と一致していてわかりやすい。

■\nの一時書き換えコードを\034から\036に変更
 処理には影響しない些細な変更である。リトライアクセスが連続して並ぶようにソートした後、日付と時刻でソートし直すために、リトライシーケンスの複数の行を一時的に一行のデータに変換する。その際に、元の\n(改行文字)を\034に置き換えていたが、\036に置き換えるように変更した。
 ISOの機能文字の規格(ASCIIやJISでも同じ)では、情報セパレータとして以下の4個が定められている。

\034 (0x1c): FS (File Separator)
\035 (0x1d): GS (Group Separator)
\036 (0x1e): RS (Record Separator)
\037 (0x1f): US (Unit Separator)

今まで、入力されうる文字と重ならない文字を使えばよいということで、あまり深く考えずに置き換え文字として\034を使っていた。しかし、規格に照らせば、元が一行だった情報単位の区切りを示すにはRSコードを使うのがふさわしいと考えて、\036を置き換え文字として使うことにした。どうでもいいこだわりである。

日曜日, 3月 23, 2008

世界に広まったらどうしよう…

 先日、オーストリアの方から、自分のサイトがS25Rに引っかかるのでホワイトリストに登録してほしいというメールをいただいて、公開ホワイトリストに掲載した。
 「どの国へメールを送った時にS25Rでブロックされましたか?」と尋ねたら、サンフランシスコにある某ブログサイトとのこと。外国でも徐々に使われ始めているようである。S25R方式を採用していると公表している外国の方はまだ少ないようだが、steeeeeveeeさんの記事を見つけた。また、少し前にはオーストラリアの方からホワイトリスト情報をいただいている。
 公開ホワイトリストへの掲載はどなたからの情報も受け入れている。個人サイトや小規模サイトは交信相手が少ないはずだからといって大規模サイトと差別するようなことはしていないし、インターネットはワールドワイドなものだから、外国のホストの情報も掲載している。
 今のところ、公開ホワイトリストに掲載されたホストの大多数は日本国内のものである。だから、国内サイトにはかなり役立つものになっていると思う。しかし、世界のホストが入ってくると、国内サイトにとっては必要以上に重たいホワイトリストになってしまう。一方、外国のサイトにとっては、自国や主要な交信相手国のホストの情報がたくさん入ってくれないと、S25R方式の運用当初から偽陽性判定を少なくできるという利点を享受しにくい。
 ホワイトリストがワールドワイドになってきたら、日本版、東アジア版、西アジア版、オセアニア版、北米版、南米版、西欧版、東欧版、アフリカ版という具合に分けることを考えようかな。願わくは、自国にとって最適なS25Rホワイトリストを提供するボランティアが各国に現れてくれるとうれしいのだが。
 あるいは、いよいよとなったら、テキストファイルによるホワイトリスト情報からDNSホワイトリストへの移行を検討しようか。かつてホスト名とIPアドレスとの対応表がテキストファイルとして一元管理されていたのが、インターネットの拡大につれてDNSへ移行したように。(参考:JPNIC「インターネット10分講座●DNS」)

土曜日, 3月 22, 2008

グレイリスティングの突破率は1%くらい

 3月9日「タールピッティングによる阻止率はあまり高くない」で、「グレイリスティングを突破しそうなスパムメッセージは0.6%ほど」と述べた。これは、2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数とリトライシーケンス数から算出したデータである。
 しかし、2月17日から3月22日10時までのログからカウントしたところ、もう少し高めのデータになった。この期間中、偽陽性判定を除いて、推定メッセージ数は1715、リトライシーケンス数は16。ただ、リトライシーケンスをよく見ると、日付が2月22日、23日、26日のアクセスが1シーケンスとして表示されているものがあり、受けていれば3通だった可能性がある。一方、3月18日と21日の1回ずつのアクセスが、クライアントIPアドレス、送信者アドレス、受信者アドレスとも同じだったためリトライシーケンスとしてカウントされていたが、これはグレイリスティングを抜けられる正常なリトライではない。そこで、推定メッセージ数を1715+2+1=1718、リトライシーケンス数を16+2-1=17と補正すると、グレイリスティングを突破しそうなスパムメッセージの割合は1.0%ということになる。
 長期的に見ると、リトライするスパムの割合が増えつつあるという印象はない。2月10日から3月9日までの期間にはたまたまリトライシーケンスが少なめだったからで、0.6%と1.0%との違いは統計誤差だと思う。「450」で蹴ったスパムアクセスのうちグレイリスティングを突破する割合は1%くらいと思っておけばよいだろう。
 最近では、素のS25R方式による宛先の正しいスパムの阻止率は約98%である。リトライするスパムアクセスのほとんどは10分以上リトライしていることから、遅延時間5分(postgreyのデフォルト値)のグレイリスティングで自動救済した場合、「450」で蹴った約98%のスパムメッセージのうち約1%(全体のうちでもほぼ変わらず1%)がすり抜けることになるので、阻止率は約97%になると推定される。グレイリスティングを併用しても十分な阻止率を保てると言える。

木曜日, 3月 20, 2008

DNSBLって効くの?

 2006年11月24日「DNSBLの利用価値はあるか?」で「DNSBLを使う積極的な理由は見出せない」と書いたが、そもそもDNSBLによるスパム阻止率はどのくらいなのだろうかと思って検索してみた
 ↑クリックしてご覧になればおわかりのとおり、「DNSBL」の代わりに「RBL」でもよい、「阻止率」の代わりに「拒否率」でもよいという検索ワード条件にしたのだが、ヒット件数は424件、表示件数はわずか59件。内容の抜粋に「%」という文字があるものはたいてい、私の論文のタイトルか、メール以外(BBS、コメント、トラックバック)のスパムに関する情報。日本語のページしか探していないが、DNSBLを使うサイトは少なくないはずだから、「スパムの受信を××%減らすことができた」と定量的なデータを公表する人が少しくらいいてもよさそうなもの。いったいどうしたことだろうか。
 かろうじて手がかりになったのは、3位にヒットした「日本語版のRBLサービス」というページ。最後の方にこんな記述があった。

spamcop.net効かせてみました。サーバのログ上、確かに相当な数のものがはじかれてはいるのですが、それでも尚、私のアカウントには毎日80通程度は届きます。以前は150通~200通だった事を思えば、効果はてきめんですが、「選別する手間はあまり変わらないかも・・。」って感じです。

ここから、SPAMCOPを利用した場合の阻止率は50~60%と推測される。たったそんなもんなの?
 RBL.JPBlack list DB checkというCGIで、いくつかのDNSBLにホストが登録されているかどうかを調べることができるので、私のサイトに宛先の正しいスパムを送り込もうとしてS25Rで阻止されたホストを入力してみた。10個のホストを入力したところ、SPAMCOPには8個登録されていたが、それ以外のデータベース(list.dsbl.org、multihop.dsbl.org、VISI.COM、Relay Stop List、dev.null.dk Open Relay List、spamhaus、virus.rbl.jp、short.rbl.jp)には一つも登録されていなかった。
 もちろん、たった10個のスパム送信元ホストのデータだけでDNSBLの効果を定量的に評価することはできない。しかし、宛先の正しいスパムについて阻止率97%以上という定量的なデータが出ているS25R方式に比べれば、DNSBLの効果の低さは推して知るべしである。
 某大学に勤務する私の友人もスパムに悩まされていた。その大学のネットワーク運用を請け負っている会社は、S25R方式を知ってはいたが、ホワイトリスト登録のための監視作業はとてもできないと言って、DNSBLを使うことにしたそうである。DNSBLに頼ればログをこまめに監視しなくてもよい、偽陽性判定の心配はないとでも思っていたのだろうか。ホワイトリスト登録を自動化するにはRgreyか、あるいはグレイリスティングそのものを使えばよいものを。友人は、その後も相変わらずスパムが届いていると言っていた。
 以前、私のBBSに「S25R方式によってスパムの受信が劇的に減ったが、それだけに、すり抜けるスパムが目障り。これも食い止めたい」と書かれた方がいたので、「一日数通程度のすり抜けスパムを手動で捨てるくらい大した手間ではないでしょう」と答えたことがある。スパムの阻止率を100%に近付けようとがんばると、副作用の心配もある。前回、「スパムの受信が業務に支障がないくらい(一人一日数通程度)に減ればそれ以上がんばらないという割り切りも必要だと思う」と述べたのは、このことを念頭に置いたものだった。しかし、S25R方式を知らずに(あるいは、試用して評価してみようともしないで)DNSBLに頼っている人は、満足できる阻止率が得られずに、SpamAssassinなどによるコンテンツフィルタリングにもかなり依存せざるを得ない。だからスパマーとのいたちごっこから抜け出せず、「それ以上がんばらないという割り切り」どころではないんだろうな。

日曜日, 3月 09, 2008

がんばりすぎない

 佐藤さんのブログ記事からリンクされている「最近のspam送信者が進化している件について」という記事では、正当なMTAと区別できない挙動をするスパムアクセスが増えていると書かれている。これを読む人は、スパムの被害は今後もどんどん増えるだろうと悲観的な気持ちになりそうである。しかし、スパムアクセスの総数はどのくらい増えたのか、正当なMTAと区別できないスパムアクセスの割合が増えているのかどうかという定量的な議論は書かれていない。スパム対策を考える上では、現象を統計的にとらえ、何が重大な問題なのかを議論すべきである。さもないと、対策の優先度を考慮せず、実はわずかな割合しかない巧妙なすり抜けスパムを阻止しようと必要以上に躍起になり、労力の割には効果が少ないということにもなりかねない。
 私のサイトで観察する限り、ボットからのリトライしない(あるいは、リトライのたびに送信者アドレスが変わるため、正常なリトライとして検出されない)スパムアクセスが今なおほとんどである。前回の記事で述べたとおり、グレイリスティングを突破しそうなスパムメッセージは0.6%ほどしかない。それも、ログを見て気付いたらすでにアクセスが止まっていたものばかり。グレイリスティングはだませても、素のS25R方式を運用するメールシステム管理者をだませるものはなかった。
 また、S25Rをすり抜けて着信するスパムの割合は相変わらず少ない。私のサイトで2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数(宛先の正しいアクセスのみを抽出したもの)は1571、この期間に受けたスパムは14通だったので、ここから素のS25R方式による阻止率を計算すると、99.1%となる。ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技を使わなかったとしたら着信は20通で、阻止率は98.7%となる。2006年7月の統計では、宛先の正しいスパムの阻止率はホスト数で数えて97.4%だった。ホスト数で数えてもメッセージ数で数えても阻止率にはあまり違いがないことがわかっているので、一昨年よりも良いデータになっていると言える。ボットからのスパムアクセスが増えるにつれて、S25Rによる阻止率は高くなるようである。勤務先でのBecky!によるフィルタリングでも、最近の判別率は98~99%、見逃しは一日平均1通程度で、業務にはまったく支障が生じていない。
 メールサーバを経由するスパムはS25Rをすり抜けるが、メールサーバがメールトラフィックのボトルネックになるので、そのようなスパムはあまり増えないだろう。そんなわけで、私は悲観的な気持ちにはなっていない。
 すり抜けるわずかな割合のスパムに悲観的になり、それをゼロに近付けようとがんばるほどに、対策コスト(メールシステム管理者の頭脳と時間の消費を含む)は急激に増大する。スパムの受信が業務に支障がないくらい(一人一日数通程度)に減ればそれ以上がんばらないという割り切りも必要だと思う。

タールピッティングによる阻止率はあまり高くない

 佐藤さんがブログ記事で「HELOアドレスブラックリストやタールピッティングによる一次フィルタでの阻止率が90%を割るようになった」と書かれている。タールピッティングの遅延時間を125秒に伸ばした時には阻止率がだいぶ高くなったが、最近ではすり抜けるスパムが増えたとのこと。
 佐藤さんの別の記事からリンクされている「Spammers are Less Patient than Legitimate Senders」(スパマーは正当な送信者ほど辛抱強くない)という記事に示されたグラフによると、応答を125秒遅延させても、すり抜けるスパムアクセスは4%ほどある。佐藤さんは、もっと多そうだと言っておられる。素のS25R方式が97~99%の阻止率を保っていることを考えると、タールピッティングによる阻止率はあまり高くないと言える。
 佐藤さんによると、グレイリスティングを突破するスパムアクセスも増えているとのこと。確かに、最近、30~31分リトライするスパムアクセスも時折ある。しかし、全体から見ればまだごく少ない。2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1571(一時的な逆引き失敗による偽陽性判定があったが、それは除いている)、リトライシーケンス数は9である。すなわち、グレイリスティングを突破しそうなスパムメッセージは0.6%ほどしかない。私のサイトでの観察による限りは、グレイリスティングを突破するスパムが増えているのはスパムアクセスの総数が増えているからで、割合から言えばグレイリスティングはまだ十分な効果を保っているように思える。
 タールピッティングの利点は、正当なメールを誤判定しても受信遅延が2分程度ですむことである。佐藤さんのサイトはメールサービスプロバイダなので、スパムの阻止率の高さよりも副作用の少なさを重視する佐藤さんの考えは理解できる。しかし、5~30分程度の受信遅延をユーザーが許容してくれるサイトであれば、私としては、S25Rの誤判定からの自動救済にはグレイリスティングだけを使うことをお勧めしたい。協力者の皆様のおかげでだいぶ充実した公開ホワイトリストを組み込めば、正当なメールの受信遅延が起こる確率は非常に低くできる。

土曜日, 3月 01, 2008

続・失礼な受信拒否

 2007年11月24日「失礼な受信拒否」で、インドのedkal.comがメーリングリストの配信メールをスパム判定して応答コード「550」で蹴ったことを述べた。先日、応答コードが「451」に変わったことがわかった。

<***@edkal.com> (expanded from <***-outgoing>): host
    mail.edkal.com[202.71.131.52] said: 451 Please try again later (in reply to
    end of DATA command)

 2月21日に送信し、私のメールサーバは5日間のリトライの末、26日にギブアップした。
 リトライを放置するくらいなら、なぜ「451」に変えたのだろうか。

CAPTCHA認証破りへの対抗策

 情報源がどこだったか忘れてしまったが、CAPTCHA認証をパターン認識技術で破り、フリーメールアカウントを多数取ってスパム送信に使うという手口が現れたらしい。30%以上の確率でCAPTCHA認証を突破できるくらいになっているそうである。
 よく使われているCAPTCHA認証は、ゆがんだ文字と汚れた背景の画像から文字を読み取らせるものであるが、パターン認識技術が進歩すれば、機械的に読み取れる確率は上がってくる。
 そこで、こんなCAPTCHA認証はどうだろうか。
 画像とその説明の言葉の組をたくさん用意しておく。

「王冠をかぶった女性」
「ネクタイをした男性」
「眠っている猫」
「リボンを付けた猫」
「炎が左になびいているろうそく」
「吹き消されたばかりのろうそく」
「前がつぶれた乗用車」
「横転した乗用車」

といった具合である。そして、数十個の画像を表示し、説明の言葉を数個表示して、該当する画像をチェックボックスで選ばせる。
 この認証を機械的に突破するには、高度な人工知能が必要である。今のパターン認識技術でも、画像を解析して「人の顔」という判断はできるだろう。しかし、「王冠をかぶった」、「ネクタイをした」などの修飾語付きの条件で判別するには、自然言語理解と超高度なパターン認識と膨大な知識データベースが必要である。それができる人工知能の実現はかなり先のことだろう。
 選択肢をでたらめに選んで突破する確率は、かなり低くできる。たとえば25個のうち5個選ばせるとしたら、選ぶ数は5個だという情報が得られていたとしても、突破できる確率は1/53130である。選ぶ数が機械的には知られにくいようにすれば、さらに突破の確率を低くできる。
 しかも、この方法なら、プログラムが難しくなることもない。また、認証手続きに文字入力が不要でマウス操作だけですむので、ユーザーには好まれるかもしれない。

日曜日, 2月 24, 2008

逆引き命名法の標準化の案

 送信元がメールサーバかエンドユーザー回線かを確実に判別できる逆引き命名法を標準化するとすれば、条件ができるだけ簡潔であり、かつ、標準に準拠して逆引き名を直さなければならないサイトがなるべく少なくてすむことが望ましい。そこで、S25Rの一般規則をさらに簡潔にした条件がよいだろう。
 論文の「統計データ」の節に示しているとおり、2004年4月のデータによれば、ルール4、5、6による阻止率増分(これらによってしか引っかけられないホストの割合)は1.2%しかない。したがって、効果の大きいルール1、2、3だけを標準に取り入れるのがよいと思う。さらに、ルール3(逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる)はちょっと煩雑な条件なので、これをもっと簡潔にする。そこで、エンドユーザー回線と判定する条件を次のようにする。

●ルール1:末端ホスト名が、数字以外の文字列で分断された二つ以上の数字列を含む。
●ルール2:末端ホスト名が、5個以上連続する数字を含む。
●簡略化されたルール3:末端ホスト名が数字で始まる。

 これを裏返せば、メールサーバと判定する条件は次のように簡潔なものになる。

「末端ホスト名が、英字で始まり、含む数字は高々一続きで4桁以内である。」

 この標準化ルール案による阻止率は、ここ4週間のログから調査したところ、ルール0(逆引き失敗)と合わせて94.5%になる。逆引きできるホストのうち、この標準化ルール案に合致するものは90.2%。不正メールアクセス元のほとんどがエンドユーザー回線だったとすれば、この標準化ルール案に準拠するために逆引き名を変える必要のあるエンドユーザー回線のホストは約10%ということになる。
 ルール1は議論になると思う。これに引っかかるメールサーバの割合は少ないとはいえ、サーバ事業者では、たくさんのサーバに名前を付けるために、分断された複数の数字列を含む末端ホスト名を付けるケースが少なくないからである。「mc1-s3.bay6.hotmail.com」、「h04-a1.data-hotel.net」、「sd22-01.domainserver.ne.jp」などがその例である。だから、「三つ以上の数字列」という条件にした方がよいと思う人がいるであろう。
 しかし一方、末端ホスト名に数字列を二つだけ含むエンドユーザー回線はかなり多い。ここ4週間のログから、「末端ホスト名が英字で始まり、4桁以下の数字列を二つだけ含む」という条件に合致する不正メールアクセス元を抽出したら、逆引きできるホストのうち9.8%を占めた。実例として、こ~んなにある(同じサイトドメイン内の複数のホストは一つで代表させて示している)。

adsl-211-190.eunet.yu [213.198.211.190]
adsl-dyn-29-154.kosnet.ru [77.234.29.154]
adsl-ull-129-7.50-151.net24.it [151.50.7.129]
adsl1500-112.dyn83.pacific.net.sg [202.42.83.112]
as12-240.qualitynet.net [62.150.153.240]
BAC2ec5.bac.pppool.de [77.130.46.197]
bd21ec9a.virtua.com.br [189.33.236.154]
blfd-4dbebc54.pool.einsundeins.de [77.190.188.84]
brln-4d0572aa.pool.mediaWays.net [77.5.114.170]
CableLink37-252.INTERCABLE.net [207.248.37.252]
cCEF7BF51.dhcp.bluecom.no [81.191.247.206]
cable-117-29.zeelandnet.nl [82.176.117.29]
catv-5062b317.catv.broadband.hu [80.98.179.23]
cliadsl204-232.tdm.co.mz [196.28.232.204]
client158-22.cmk.ru [195.182.158.22]
cmodem-237-253.tricom.net [200.42.237.253]
cust-127-183.on3.ontelecoms.gr [91.132.127.183]
d7-122.rt-bras.wnvl.centurytel.net [69.179.134.122]
dialup-196-074.kpunet.net [206.223.196.74]
dinamic_adsl_114-208.emcali.net.co [190.1.208.114]
host-191-207.adsl.euroweb.sk [212.26.191.207]
host-238-68.an-net.ru [217.212.238.68]
host-5-37.ncrauto.clients.pavlovmedia.com [76.10.5.37]
host-64-160-mdk.igloonet.pl [77.65.160.64]
host100-130-dynamic.17-87-r.retail.telecomitalia.it [87.17.130.100]
host231-238.oskbraniewo.pl [81.15.231.238]
i528C3226.versanet.de [82.140.50.38]
ip-161-189.evhr.net [213.169.161.189]
leased-line-224-240.telecom.by [213.184.224.240]
line-122-7.gprs.westel900.net [212.51.122.7]
lub251-26.wireless.crosswind.net [205.209.251.26]
mh180x127.morehouse.edu [69.87.180.127]
MS-187-108.dyn-ip.SPb.SkyLink.RU [212.129.108.187]
nb10-162.static.cytanet.com.cy [87.228.198.162]
net234-115.ertelecom.ru [212.33.234.115]
node-29-129.adsl.tula.net [212.12.29.129]
OL218-64.fibertel.com.ar [24.232.64.218]
p1029-ipbf2403marunouchi.tokyo.ocn.ne.jp [122.17.215.29]
p5082B4CC.dip.t-dialin.net [80.130.180.204]
p5083BA1A.dip0.t-ipconnect.de [80.131.186.26]
ppp-119-58.21-151.libero.it [151.21.58.119]
ppp-196-11.32-151.iol.it [151.32.11.196]
ppp152-232.tis-dialog.ru [83.219.152.232]
ppp19-85.pppoe.mtu-net.ru [81.195.19.85]
ppp266-114.adsl.forthnet.gr [77.49.45.114]
pppoe079-113.si-chelny.ru [89.248.113.79]
rb5co185.net.upc.cz [89.176.220.185]
suas1-089.ptt.yu [82.208.206.217]
tdev143-219.codetel.net.do [200.88.143.219]
ts2-a47.Voronezh.dial.rol.ru [195.46.185.47]
user-12ldi7i.cable.mindspring.com [69.86.200.242]
user29-213.satfilm.net.pl [77.91.29.213]
vip3-159.sinamail.sina.com.cn [202.108.3.159]
wtc-222-194.wtconnect.com [64.40.222.194]
xdsl-90-ppp231.tts.nov.ru [81.16.90.231]
(以上、55サイト)

標準化に際して、これほど多くのサイトにエンドユーザー回線の逆引き名を変えることを求めるのは難しいだろう。まだしも、サーバの逆引き名を変えてもらう方が容易だと思う。サーバの数が多くて命名が難しければ、「server0012.segment01-02.example.ne.jp」のような、数字をサブドメインに移した名前にすればよい。この標準化案では、S25Rのルール4やルール5に引っかかるパターンはサーバのために明け渡されることになるからである。
 同じやり方で、ルール2に引っかかっていたサーバの名前を変えることも難しくないだろう。
 簡略化されたルール3は、下位から2番目の階層を見ない。このことによって見逃されるようになるエンドユーザー回線は、逆引きできる不正メールアクセス元の2.4%くらいある。実例は次のとおりである(同じサイトドメイン内の複数のホストは一つで代表させて示している)。

adsl-byfly-mgl.86.57.190.228.telecom.mogilev.by [86.57.190.228]
cli-nw.107.169.helios-nw.ru [88.82.169.107]
dslnet.85-22-30.ip226.dokom.de [85.22.30.226]
dyn-85.204.185.222.tm.upcnet.ro [85.204.185.222]
dyn-cable-customer.213.22.138.91.yetnet.ch [91.138.22.213]
h116.43.134.98.ip.windstream.net [98.134.43.116]
h128.196.140.67.ip.alltel.net [67.140.196.128]
h253.119.141.64.cable.gldn.cablerocket.net [64.141.119.253]
host.213.240.207.67.customers.net-surf.net [213.240.207.67]
host125.190-139-22.telecom.net.ar [190.139.22.125]
ip-33.88.126.206.dsl-cust.ca.inter.net [206.126.88.33]
marshallDHCP-171.216-254-243.iw.net [216.254.243.171]
p213.54.201.70.tisdip.tiscali.de [213.54.201.70]
pmsn.129.50.189.90.sable.dsl.krasnet.ru [90.189.50.129]
polcon.806588-194.bih.net.ba [80.65.88.194]
ppp-124.120.114.100.revip2.asianet.co.th [124.120.114.100]
tm.213.143.73.231.lc.telemach.net [213.143.73.231]
ws.20070530152217.clnt.kht.ru [87.225.45.218]
(以上、18サイト)

このようなサイトには、エンドユーザー回線の末端ホスト名の変更を求めざるを得ない。さもないと、逆引き命名法の標準化が簡潔なルールにならない。
 なお、十六進番号を含む末端ホスト名が標準化ルールをすり抜けることがある(例:c9531ecc.virtua.com.br)。この問題を避ける簡単な方法の一つは、末端ホスト名が「0x」で始まるように変更してもらうことである。
 それと、「007.co.jp」(架空の例)のように数字で始まるサイトドメイン名の場合、逆引き名には英字で始まる末端ホスト名を省略してはならないという制約が付くことになる。このことは問題にはならないだろう。
 逆引き命名法を標準化してすべてのサイトがそれに準拠するようになるには、逆引き名の変更の痛みを負うサイトがどうしても出てくる。誰も痛みを負うのはいやだから、逆引き命名法の標準化は容易には合意されないだろう。しかし、もしその標準化を行うとすれば、ここに示した案よりも良いルールはないと思う。これは現実の逆引き名の傾向を踏まえた、しかも非常に簡潔なルールだからである。

逆引き命名法を標準化すれば

 もしメールサーバとエンドユーザー回線をはっきりと区別できる逆引き命名法が標準化されて全サイトがそれを守るようになれば、S25Rによる判定は確実なものになり、ボットからのスパムを完全に遮断できるようになる。
 今のS25R方式では、逆引き名からエンドユーザー回線と推定しても応答コード「5xx」で拒否してはならない。それは、逆引き命名法が標準化されていなくて、判定が不確実だからである。「4xx」を返して、リトライがあれば、メールサーバである可能性が高いから、アクセスを受け入れる必要がある。そのため、リトライするスパムを受け入れてしまうおそれがある。しかし、逆引き命名法が標準化されてすべてのサイトでそれが守られ、逆引き名から確実にエンドユーザー回線だとわかるようになれば、「5xx」で拒否してよいようになる。だから、スパマーは、ボットにリトライさせて受信側のメールシステム管理者あるいはグレイリスティングを欺くという戦略はとれなくなる。
 なお、すべてのサイトで逆引きが設定されるようになっても、逆引きできない時の拒否応答コードは「4xx」でなければならない。逆引きが設定されていても、受信側でDNS検索が一時的に失敗することがあるからである。しかし、何度かリトライを受けるうちに逆引きは成功する。それまでリトライは放置してよい。そして、逆引きが成功したら、送信元がメールサーバかエンドユーザー回線かを確実に判別できることになる。
 つまり、逆引き命名法が標準化されれば、受信側メールサーバは、送信側メールサーバからのSMTPアクセスだけを受け入れ、エンドユーザーコンピュータからのSMTPアクセスを確実に遮断することができる。S25R方式は、メールルートの秩序(送信側MUAから送信側MTAへの投函、送信側MTAから受信側MTAへの転送というルートをとらなければならないこと、また、送信側MUAから受信側MTAへの直接の投函は禁止されること)を強制するゆるぎない手段となる。もはやスパム送信にボットは使えなくなる。
 ところで、ISPが機械的に逆引き名を割り当てるエンドユーザー回線を使ったメールサーバはどうするのかと疑問を持つ人がいるかもしれない。そういうメールサーバには、ISPが、顧客の希望する逆引き名を設定してあげるサービスを提供すればよい。
 このような状況が実現したら、スパマーがスパムを送信するには、ISPのメールサーバを経由させるか、自分でIPアドレスとドメインを取ってスパム送信用のメールサーバを立てるしかなくなる。メールサーバを経由するスパムは、メールサーバでの流量制限、および内容検査による送信保留によって抑制することができる(2月3日「S25Rが不要になる時」参照)。また、スパム送信用サーバは、やがて多くのサイトでブラックリスト登録されるだろうから、スパマーはそれを長く使い続けることができない。逆引き命名法の標準化は、スパム配信ビジネスを破綻させることができるだろう。
 S25R方式の効果を実感している人には、この構想は理解していただけるだろうと思う。しかし、そうでない人にはわかりにくいだろう。すべてのサイトで逆引きを設定し、その逆引き名は、サーバかエンドユーザー回線かを判別できるためのルールに従ったものにする。たったこれだけのことでスパマーを袋小路に追い詰めることができるとは、S25R方式を知らない人には容易には信じてもらえないだろう。
 今、SPFの設定が広まりつつあるが、すでにスパマーはその裏をかいている。大多数のサイトでSPFが設定されたころには、受信側でのスパム対策のためにはSPFはさほど効果的でないことが認識されることになるだろう。そのころになってようやく、送信元の逆引き名を手がかりにする方法が注目され、逆引き命名法の標準化が議論されるようになるのかもしれない。
 次の記事で、逆引き命名法の標準化の案を述べる。

金曜日, 2月 08, 2008

SPFとDKIMの問題点

S25R方式は、送信元の逆引き名がサーバっぽい名前ならばメールサーバと認めてメールを受け入れようというやり方である。メールサーバに対するその推定は87%の確率で当たり(初期の偽陽性判定率は13%と推計されるので)、残りはホワイトリストでカバーする。すなわち、不完全ながら、ドメイン認証によって不正なMUAから受信側MTAへの投函を阻止する方策の代用手段だと言うことができる。
 望ましいドメイン認証方式がインターネットに普及した時、S25R方式は不要になる。ドメイン認証方式としては、SPF(Sender Policy Framework)とDKIM(DomainKeys Identified Mail)が有望とされている。しかし、どちらも理想的なものではないと思うと前回述べた。その理由を説明しよう。

■SPF
 ドメインのDNSで、そのドメインを送信者アドレスとするメールを送信するホストを宣言する方式である。たとえば私は、自サイトのDNSのgabacho-net.jp.ゾーンファイルに

gabacho-net.jp. IN TXT "v=spf1 +ip4:219.163.213.18 ~all"

と記述することによって、送信者アドレスのメールドメインがgabacho-net.jpであるメールはIPアドレス219.163.213.18のホストからのみ送信されることを宣言している。もしgabacho-net.jpドメインを送信者アドレスとするメールが別のホストから送信されたら、受信側ではそれを不正メールと判断できる(ただし、「~all」は、転送によって他ホストから送信されることがないとも限らないから、疑ってもよいが完全な受信拒否はしないでほしいという意味である。他ホストから送信されることは絶対ないという宣言は「-all」と書く)。送信側としての設定は簡単なので、設定は普及しつつある。
 しかし、今のSPFはスパマーが裏をかきやすい仕様である。「"v=spf1 +all"」と書くことによって、すべてのホストが送信元として正当だという宣言ができてしまう。だからスパマーは、スパムの送信者アドレス用にドメインを取ってそのような不正な宣言をすることにより、ボットから送信させたスパムに受信側のSPFチェックをすり抜けさせることができてしまう。
 受信側で「+all」という宣言を信用しないように対処したとしても、まだ抜け道がある。たとえば「+ip4:61.0.0.0/8」のようにネットマスク指定をすることによって、ボットネットを含む広い範囲のIPアドレスブロックを正当な送信元だと宣言することもできてしまう。
 S25R方式は97%以上のスパムを阻止できるが、抜け道のあるSPFで同等以上の阻止率を維持できるとは期待しにくい。

■DKIM
 送信側で電子署名をメールヘッダに埋め込み、受信側で送信元の公開鍵を取得してメールの正当性(確かにそのドメインから送信されたものであること)を検証する方式である。メッセージの正当性を主張する手段としては強靭なセキュリティを持つ。
 しかし、技術的に高度であることが普及の阻害要因になる。MTAのオペレーションがどうにかできるくらいの、スキルの高くないメールシステム管理者も決して少なくないのに、そういう人たちがさらに鍵管理の知識も持たなければならないのである。普及のためには、Postfixの標準インストールでDKIMが組み込まれるくらいに実装が簡単にならなければならないだろう。
 それに、もしDKIMが普及して、正しい電子署名のないメールをことごとく受信拒否しても問題ない世の中になったとしても、パフォーマンスの問題がある。S25R方式は、怪しい送信元に対しては、HELO、MAIL FROM、RCPT TOコマンドまで送信させた段階で、DATAコマンド以降のメッセージ本体を伝送させずに応答コード「450」(再送要求)で蹴飛ばす。次から次へと来るスパムアクセスを軽快に蹴りまくる。DKIMでは、メッセージの正当性を検証するためにメッセージ本体の伝送を受け入れなければならない。蹴飛ばし方はおのずと鈍重になる。回線上のごみトラフィックが減らないことにもなる。

 結局のところ、SPFもDKIMも、受信側としてのスパム対策のために望ましいドメイン認証方式ではないと思う。これらを用いることが世の中の流れになるなら、私は、送信側としてそれらに対応することにやぶさかでない(実際、SPFはもう設定している)。しかし、ほかにもっと良いドメイン認証方式が現れて普及しない限り、私はS25R方式を捨てることはないだろう。

(関連記事)
送信ドメイン認証はスパムに勝てないだろう
送信ドメイン認証は誰にとって有益か

日曜日, 2月 03, 2008

S25Rが不要になる時

 S25R方式は、いずれ不要になる時が来る。それは、メールルートに秩序ができて、スパムの大量配信がきわめて困難になる時である。その将来像を描いてみよう。

■SMTP-AUTHによる投函
 送信者のメーラーから送信側メールサーバへの投函(*)には、サブミッションポート(ポート587)を用いたSMTP-AUTHによるユーザー認証を必要とする。当然、送信者がアカウントを持たない受信側メールサーバに直接投函することはできない。
 メーラーは、パスワードを他プログラムから見破られにくいように作られる。したがって、PCがボットにやられたとしても、ボットが正規の送信者を装ってスパムを投函することは困難になる。

(*) 投函:サブミッションポートによる送信は「投稿」と呼ばれているようであるが、これは、ネットニュースでの言い方「記事(an article)をpostする」の「post」の訳語を継承したものではないかと思われる。私は、電子メールにおいては郵便になぞらえて「post」の訳を「投函」と呼びたい。英和辞典にもそう書かれていることだし。

■送信サーバのドメイン認証
 送信側メールサーバは、メールをポート25のSMTPで受信側メールサーバへ転送する。受信側メールサーバは、SMTPアクセスしてきたホストが正規のメールサーバであるかどうかをドメイン認証でチェックする。ボットにやられたエンドユーザーPCがSMTPで受信側メールサーバへ直接投函しようとしても、ドメイン認証をパスしないので、受信が拒否される。
 ただし、ドメイン認証をパスしないクライアントを安心して拒絶できるためには、すべてのサイトで、メール送信サーバがドメイン認証をパスするように設定していなければならない。その前提として、ドメイン認証方式が標準化されなければならない。それは、スパムの抑止に効果が高く、かつサイト管理者が誰でも容易に実装できるものであることが望まれる。私は、SPF(Sender Policy Framework)もDKIM(DomainKeys Identified Mail)も、インターネット全域で合意されて速やかにあまねく実装されるには理想的なものではないと思っている。道は遠い。

■流量制限
 それでもボットあるいは悪意あるユーザーがスパムを送信するならば、送信側メールサーバで流量制限をかける。一メッセージについての宛先の数を制限するとともに、一クライアントからの常軌を逸した頻度の送信に対しては、応答遅延、または投函の一時拒否によるスロットリングをかける。これにより、大量スパム配信が抑制される。

■内容検査による送信保留
 ボットあるいは悪意あるユーザーによるスパム送信へのもう一つの対抗手段は内容検査である。送信されるスパムのデータを集めながら、送信側メールサーバでベイジアンフィルタによる内容検査を行う。もしスパム判定されたら、次のような内容のバウンシングバックメールを送信者に返して認証を求める。

あなたが送信されたメールは、不正メールの疑いがあると判定されたため、メールサーバで送信が保留されています。判定は誤りかもしれません。送信するためには、以下のURLにアクセスして送信手続きを行ってください。
http://…

 バウンシングバックメールとはいっても、詐称されているかもしれない送信者アドレスに向かって誰彼かまわず投げまくるOptPlusのバウンシングバック認証方式とは異なる。送り先は、そのメールサーバにアカウントを持つユーザーのメールボックスだけである。
 もしボットによるスパムだったならば、ユーザーは身に覚えのないバウンシングバックメールを受けて、アカウントの悪用に気付くことができる。もしユーザーが故意にスパムを送信したならば、送信手続きの手間を強いられるので、スパムの大量送信が非常に困難になる。
 こうして考えてみると、いずれS25R方式が不要になる時が来ても、ベイジアンフィルタの出番はなおも残るわけだな。私は、ベイジアンフィルタを使わずに済む簡単なアンチスパム技術を考案して、「頭のいい人って、なんで難しいことを考えるのだろう」と思っていたが、やっぱ、頭のいい人が作るものは違うわ。

 さて、このような将来像が実現してもなおスパムはペイするでしょうか。私は、スパムを根絶できるとは思わないが、今のような傍若無人な大量スパム配信はできなくなると思う。これでもスパムを今くらいに大量にばらまく抜け道があることに気付かれた方はコメントください。

水曜日, 1月 30, 2008

30分リトライするスパムアクセス

 約5分間隔で30~31分リトライするスパムアクセスが2件見つかった。アクセス元はSMTPに応答しない。だからといってメールサーバでないとは断言できないが、ボットである可能性がある。

Jan 28 05:15:16 unknown [61.6.68.118]
Jan 28 05:20:22 unknown [61.6.68.118]
Jan 28 05:25:29 unknown [61.6.68.118]
Jan 28 05:30:35 unknown [61.6.68.118]
Jan 28 05:35:42 unknown [61.6.68.118]
Jan 28 05:40:48 unknown [61.6.68.118]
Jan 28 05:45:55 unknown [61.6.68.118]

Jan 30 02:06:20 unknown [92.113.198.254]
Jan 30 02:11:30 unknown [92.113.198.254]
Jan 30 02:16:40 unknown [92.113.198.254]
Jan 30 02:21:50 unknown [92.113.198.254]
Jan 30 02:26:58 unknown [92.113.198.254]
Jan 30 02:32:09 unknown [92.113.198.254]
Jan 30 02:37:43 unknown [92.113.198.254]

(1月31日追記)
 リトライパターンが同じ。ボットなのは間違いなさそう。

Jan 31 08:17:43 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:22:51 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:28:00 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:33:07 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:38:18 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:43:31 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:48:42 m85-94-186-66.andorpac.ad [85.94.186.66]

日曜日, 1月 27, 2008

スパム送信サーバが4時間リトライ

 以下のようなリトライアクセスが見つかった。

Jan 25 15:04:30 unknown [219.234.95.15] from=<khfwkbrLeroy@olten.ch> to=<deo@gabacho-net.jp> helo=<hrwl.com.cn>
Jan 25 15:34:36 〃
Jan 25 15:40:38 〃
Jan 25 15:46:37 〃
Jan 25 16:47:38 〃
Jan 25 16:52:44 〃
Jan 25 16:57:50 〃
Jan 25 18:57:55 〃
Jan 25 19:03:57 〃
Jan 25 19:09:57 〃

 送信者アドレスのユーザーIDが無意味な長い文字列を含むのがいかにも怪しい。HELOアドレスが中国の国ドメインなのに送信者アドレスがスイスの国ドメインであることも怪しい。
 リトライは4時間5分で止まった。アクセス元にSMTPアクセスしてみたらMTAが応答し、HELOアドレスと同じホスト名を答えたが、人が送信したメールを中継する正当なメールサーバならもっと長く(少なくとも24時間)リトライするだろう。中国はスパム送信の多い国であることからも、スパム送信を目的としたサーバであることが考えられる。
 経験上、リトライが30分以上続いたら送信元はボットでなくメールサーバだと思ってほぼ間違いない。しかし、メールサーバから送信されるスパムもある。このようなアクセスがグレイリスティングを突破するのはやむを得ないが、素のS25R方式では、正当なメールらしいと判断したらすみやかにホワイトリスト登録し、怪しいとにらんだら数時間放置してみるという処置ができる。
 とはいえ、組織サイトでは、メールシステム管理者の勝手な判断で受信者が不利益をこうむるおそれがある。怪しいとにらんだ時には、受信者に「送信者アドレスに心当たりがありますか?」と問い合わせた上で処置を決めるのがよいだろう。
 受信者からすみやかに回答が得られなかった場合は、とりあえず24時間以内にホワイトリスト登録するのが無難であろう。その際、スパムかもしれないと思ったが通過させた旨を受信者に知らせ、スパムだったら知らせてもらって、ホワイトリスト登録を解除する。
 あるいは、スパムの可能性が非常に高いと判断したら放置して、受信者から回答が来る前にアクセスが止まったらアクセスの記録を知らせるという処置でもよいだろう。もし受けたかったメールだったならば、ホワイトリスト登録を申請してもらって、受信者から送信者に再送を依頼すればよい。

(参考)
 スイスの国ドメインchは、ラテン語国名「Confoederatio Helvetica」に由来する。国名を四つの公用語で併記する代わりに単独で表記する国名として、どの言語話者にも不公平にならないようにラテン語を使っているのである。

月曜日, 1月 21, 2008

日本の美徳

 前回、善良な送信者に迷惑をかけまいという気配りの心が私にあったからS25R方式は実用的なものになったと述べた。気配りの心を自分の美点と自慢するつもりはない。むしろそれは、たいていの日本人が持っている、日本が世界に誇れる美徳だと思う。
 ロシアのmail.ruは、初めてメールを送ってくるホストをことごとく応答コード「550」で受信拒否し、送信者にホワイトリスト登録申請を要求している(2007年1月13日「厳しすぎる防御」)。インドのedkal.comは、正当なメールを誤判定して応答コード「550」で突き返している(2007年11月4日「失礼な受信拒否」)。アメリカのieee.orgもedkal.comと同じことをやっていることがわかった。

<***@computer.org> (expanded from <***-outgoing>): host
    hormel.ieee.org[140.98.193.224] said: 554 5.7.1 Message scored extremely
    high on spam scale.  No incident created. For details, send to
    postmaster@ieee.org. You can also send a plain text message to the
    recipient and request adding your address to his/her UCE whitelist. (in
    reply to end of DATA command)

 スパムを受けないためには正当なメールを間違って、あるいは故意にバウンスさせてもかまわないというやり方は信じられない。私だけでなく、たいていの日本人は同じことを思うのではないだろうか。この荒っぽさが大陸民族の文化というものなのだろうか。
 日本人ならこんなことはしないだろう。正当なメールを必ず受信できる完璧さをユーザーが求めるからということもあるが、メールシステム管理者は、メールを受信できないと困るユーザーに気配りし、善良な送信者に迷惑をかけないようにとも気配りする。「和を以って貴しと為す」という文化の中で育った日本人にとって、それはごく当たり前のことである。日本人の島国根性には「出る杭は打たれる」などの悪い面もあるが、他人への気配りは日本の美徳(*)だと思う。
 韓国製のOptPlusに実装されたバウンシングバック認証方式のコンセプトも、私には理解しがたい。善良な送信者に認証手続きの手間を要求することを失礼だとは思わないのだろうか。スパマーに送信者アドレスをかたられた被害者にバウンシングバック認証要求メールを殺到させることを申し訳ないとは思わないのだろうか。自分がスパムの被害から助かりさえすればよいという観念も大陸文化なのだろうか。
 日本の美徳をわきまえた日本人にはOptPlusは売れないと思う。OptPlusを買っている人は、S25R方式を知らないに違いない。両方を知る人ならきっとS25R方式を選ぶ(なにしろ無料だし)。日本の気配りの文化をわきまえず、OptPlusが日本で売れると思って輸入したベンダーのビジネス感覚が、私には理解できない。
 S25R方式は、注意深く運用すれば、受信者にも善良な送信者にも迷惑をかけない。メール送信サーバにメールを一時滞留させることはあるが、送信者を困らせることはないし、手間をかけさせることもない。正当なメールの受信が遅延することはあるが、ちゃんと届く。私は、ユーザーへの気配りに根ざしたS25R方式を日本発のアイデアとして誇る。そして、開発者の私を育んだ日本の文化を誇る。

(*) ラフカディオ・ハーンの来日後の人生を描いたテレビドラマにこんなシーンがあった。ある女性が、夫の死のことを話しながらほほえんだ。ハーンは、悲しいのになぜ笑うのかといぶかしく思った。後に彼は、それは自分の悲しみを相手に押し付けまいとする気配りで、日本の美徳なのだと理解した。

日曜日, 1月 20, 2008

僕って天才?

 日経BP社・ITproの「記者のつぶやき」に「昨年は「XP上で動くICAサーバー」と「S25R」に感動」という記事がある。1月17日の掲載である。S25R方式に対していただいている賛辞を要約すると、次のとおりである。

S25Rという創意工夫は、言われてみれば当たり前のことだが、普通の人には発想することのできない天才的なひらめきだ。記者がこれを知ったのは2007年も後半になってから。UNIXシステム管理をライフワークとしてきた記者が知らなかったのはまったくの不覚。受信側メールサーバにSMTP接続をしてくるクライアントがメールサーバなのかエンドユーザーコンピュータなのかを知るすべがないという思い込みがあった。逆引き名の文字列で判別しようという発想の転換が、まさにコロンブスの卵のごとき世紀の大発見なのである。

 天才的とまで絶賛されると気恥ずかしい。発想のきっかけは2006年10月21日「無精者の勝利」に書いた。思い付いたのは2003年5月。スパムが急に増え始めたのがきっかけだったが、スパムアクセス数はまだ今の1/10くらいのころだった。postgreyもDNSBLも知らなかった。Postfixが備える機能を利用して効率的にスパムをはじく方法を工夫した。大して高いスキルのない自分でもできる方法を考えたのである。
 個人用メールサーバを運用していたことが幸いした。組織サイトでこんな実験は危なくてできない。個人サイトでありながら、8個ブロックのIPアドレスをもらって逆引き権限の委譲を受けていることも幸いした。ドメイン管理者ならサーバにどのような名前を付けたがるかという思考ができた。S25Rに引っかかるお仕着せの逆引き名がISPから割り当てられる、IPアドレス1個の安い接続サービスを使っていたら、「そのようなサーバを拒否しても、ホワイトリストで救済すればよい」という発想はしにくかったかもしれない。
 「スパムの送信元には逆引きできないものが多いので、それを蹴ってみよう。次に、逆引きできても逆引き名がIPアドレスをそのまま反映したものも多いので、それも蹴ってみよう」――ここまでは、ほかの人でも容易に発想できたと思う。
 私がオリジナリティを誇るとすれば、その後の段階である。逆引き名からアクセス元を高い確度でエンドユーザーコンピュータと推定するための規則をわずか六つの正規表現に類型化した。これは、世界の誰もやっていなかった。数千回に及ぶ不正メールアクセスの逆引き名から単純な法則を見出したのは、私の特異な能力によるものかもしれない。これを「天才的」と褒めていただけるなら、私は喜んでお褒めを拝受しよう。
 これだけでは、S25R方式は使い物にならなかった。私は、誤判定される正当なメールを受信し損なわないために最善を尽くした。その方法も発表した。それは簡単な仕事である。ログの監視とホワイトリスト登録という単純作業を継続する忍耐があればよい。それは天才的な成果ではない。ただ、その背景として、善良な送信者に迷惑をかけまいという、他人への気配りの心が私にあった。だから、S25R方式は多くの人に受け入れられる実用的なものになった。それも私は誇ってよいことだと思う。
 そしてあと一つ、私が誇れるのは、スパムに困っている人々とのコミュニケーションを大切にしていること。質問には必ず答え、問題の解決のために支援する。また、善意の協力者から寄せられるホワイトリスト情報を感謝して受け取り、それをほかの人たちのために公開する。こうした活動を地道に続けている。このことにかけては私は無精者ではないのである。
 “天才的なひらめき”も、それだけで世の中に役立つものになるというものではない。「他人が使えるか」、「他人が困らないか」という、他人を思いやる思考も必要なのである。

土曜日, 1月 19, 2008

属性ラベルホワイトリストの例外

 2007年9月14日に属性ラベルホワイトリストのアイデアを提案した時、最近はne.jp以外の属性型jpドメインからの不正メールアクセスがまったく来ないと述べたが、嘘だった。すみません。前回示したjpドメインからの不正メールアクセスの中に、asahi-net.or.jpからのものがあった。
 エンドユーザーPCをインターネットに直結させているISPで、or.jpを冠しているものがある。そこで、ウェブアクセスログからそれらしいクライアントを拾い出した結果から、一般規則に引っかかるパターンを属性ラベルホワイトリストの例外とする設定方法を考えた。以下にそれを示す。

…(ホワイトリスト)…
…(ブラックリスト)…
/^[^.]*[0-9]{5}.*\.asahi-net\.or\.jp$/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.coara\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.din\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.fitweb\.or\.jp/ 450 S25R check, be patient
/^[0-9].*\.iij4u\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]\.[^.]*[0-9]\.iij4u\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]{5}.*\.janis\.or\.jp$/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.mitene\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.plala\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]\.[^.]*[0-9]\.tokai.or\.jp/ 450 S25R check, be patient
/\.(ac|ad|co|ed|go|gr|lg|or)\.jp$/ OK
/\.(pref|metro|city)\.[^.]{3,}\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]{3,}\.jp$/ OK
…(一般規則)…

 ここまでやるくらいなら、属性ラベルホワイトリストから「or」を削除してもよいかもしれない。
 もっとも、公開ホワイトリストが充実してきたので、属性ラベルホワイトリストを取り入れている人はいないかもしれないが。
 なお、asahi-net.or.jp以外の上記ドメインからの不正メールアクセスは、少なくともここ1ヶ月、観測されていない。

火曜日, 1月 15, 2008

jpドメインからの不正メールアクセス

 国内のISPにはOP25B(Outbound Port 25 Blocking)がかなり広まったらしく、私がS25R方式を開発中だった2003~2004年ころに比べて、国内からの不正メールアクセスがめっきり減った。そこで、国内サイトで偽陽性判定を減らすために、日本のIPアドレスを全部許可する方法を提案しようかと考えていた。しかし、やめた。調べてみたら、国内からの不正メールアクセスはまだ途絶えたとは言えないことがわかったからである。
 以下は、2007年12月16日から2008年1月15日21時までの拒絶ログから、逆引きFQDNがjpドメインのものを拾い出した結果である。日時、逆引き名、拒否応答コードを示している。なお、Q&AのページのQ/A2-5で説明している設定によって、明らかに不正とわかるアクセスと宛先誤りのアクセスをS25Rチェックに優先してはじくようにしている。応答コード「550」のものはuser unknownエラー、「450」のものは宛先が正しくてS25Rチェックではじいたものである。

Dec 16 21:26:18 p3242-ipbfp1401osakakita.osaka.ocn.ne.jp 450
Dec 18 20:33:48 t01.combzmail.jp 550
Dec 19 03:25:30 203.141.132.142.static.zoot.jp 550
Dec 19 04:01:37 p1024-ipbf09takakise.saga.ocn.ne.jp 550
Dec 19 10:24:36 61.206.118.155.static.zoot.jp 550
Dec 19 22:37:14 203.141.132.142.static.zoot.jp 550
Dec 20 12:39:03 203.141.132.142.static.zoot.jp 550
Dec 21 14:53:23 opt-125-215-101-221.client.pikara.ne.jp 550
Dec 21 16:15:32 u004425.ueda.ne.jp 450
Dec 22 15:18:21 202-71-93-92.ap-w01.bb-west.ne.jp 450
Dec 23 04:33:46 203.141.132.142.static.zoot.jp 550
Dec 25 06:52:21 p2057-ipbf04motosinmat.mie.ocn.ne.jp 450
Dec 25 19:37:54 p6230-ipbf201sapodori.hokkaido.ocn.ne.jp 550
Dec 28 00:40:13 122x212x213x69.ap122.ftth.ucom.ne.jp 450
Dec 28 16:45:00 61.206.118.99.static.zoot.jp 550
Dec 29 01:55:10 61.206.118.99.static.zoot.jp 550
Dec 31 22:58:05 214.net059086069.t-com.ne.jp 550
Jan  2 07:19:05 p2225-ipbfp405yosemiya.okinawa.ocn.ne.jp 450
Jan  2 11:07:47 p1198-ipad12matuyama.ehime.ocn.ne.jp 450
Jan  3 01:10:56 p670c8e.tkyoea09.ap.so-net.ne.jp 550
Jan  3 21:14:23 p6083-ipad13fukuokachu.fukuoka.ocn.ne.jp 550
Jan  6 07:34:28 catv303135.tac-net.ne.jp 550
Jan  8 14:57:46 p1121-ipbf1102hodogaya.kanagawa.ocn.ne.jp 550
Jan 10 22:39:21 eatkyo050162.adsl.ppp.infoweb.ne.jp 450
Jan 12 17:08:53 w147078.ppp.asahi-net.or.jp 550
Jan 12 23:16:13 AI-203-132-116-124.kyo.access-internet.ne.jp 550
Jan 12 23:16:26 AI-203-132-116-124.kyo.access-internet.ne.jp 550

 以上、27回。トータルで4477回(偽陽性判定を除く)なので、jpドメインからのものは0.6%。かなり少ないとは言える。しかし、応答コードが「450」、すなわち宛先が正しかったものは9回。jpドメインをすべて許可していたとしたら、これらを受けてしまっていた。国内のIPアドレスを全部許可していたとしたら、国内にあって逆引きできないホストやjp以外のドメインのホストも加わって、受けるスパムはもっと多かったかもしれない。この期間に受けたスパムは16通なので、国内のIPアドレスを許可することによってスパムの受信は1.5倍以上に増えることになる。これでは、OP25Bの普及を当てにして国内のIPアドレスを全部許可するなんてことはとてもできない。
 OP25Bを実施しているISPに名を連ねているOCNからの不正メールアクセスが目立つ。考えられる理由の一つは、OP25Bの対象にならないスタティックIPアドレスのホストがボットにやられているということである。*.static.zoot.jpというホストから不正メールアクセスが来ていることからも、そういうことは考えられる。もう一つ考えられることは、これらのアクセス元はダイヤルアップ回線だということである。ダイヤルアップ接続は、接続時間が短いため比較的スパムの発信源になりにくいことと、モバイルの利用でOP25Bをやられては非常に不便だということから、OP25Bの対象になっていないことが考えられる。実際、私がモバイルに使っているbモバイルは、携帯電話会社向けのポート25を規制しているだけであり、私は自宅のサーバを経由してPOP-before-SMTPでメールを送信することができている。
 なお、私の自宅サイトはOCNを利用しているが、ダイナミックIPアドレスから同じOCNの他顧客のネットワークへのポート25ブロッキングをしていないなんてことはまさかないだろうと思う。
 t01.combzmail.jpは、SMTPに応答するまともなメールサーバである。ここからのアクセスは、かつてわざとスパマーに拾わせたおとりのアドレスに宛てたものだった。combzmail.jpはメール配信ASPサービスである。顧客がスパムをばらまこうとしたか、顧客のPCがボットにやられたのかもしれない。
 もう一つ気付いたことは、OP25Bを実施しているISPに名を連ねていないISPもけっこうあるということだった。
 結局のところ、OP25Bの推進は不正メールアクセスの減少に功を奏してはいるが、スタティックIPアドレスやダイヤルアップ接続のホストもスパムの発信源になっていると思われる状況である。送信側の自主規制策としてのOP25Bがいくら普及しても、S25Rによる受信側の自衛策が不要になる時代は当分来そうにない。

水曜日, 1月 09, 2008

また激賞された

 国島丈生さんのブログ記事「某学会メールサーバのSPAM対策」で激賞をいただいている。
 国島さんが管理するメールサーバでは、spam throttling(DATAコマンドに対する応答を遅らせることによってメールの流量を制限するものらしい)を施してもなお、学会の連絡用メーリングリスト宛に一日数百通のスパムが押し寄せていたとのこと。
 普通に考えると、実装の簡単な素のS25Rを導入してから、ホワイトリスト登録を省力化するために選択的グレイリスティングへのステップアップを考える人が多そうなもの。しかし、国島さんは逆のやり方をされた。正当なメールの受信失敗を避けるためにまず佐藤さんのQgreyを導入。偽陽性判定がほとんど起こらないことを確認した上で、廣島さんのqmail用S25R対応パッチに手直しを加えて素のS25R方式の運用に切り替えられた。
 Qgreyを使っている間、すり抜けがそこそこあったそうである。グレイリスティングがそんなにすり抜けられるものなのかと思って調べてみたところ、Qgreyの母体のqgreylistは、クライアントIPアドレスだけでグレイリスティングを行うらしい。だから、送信者アドレスを変えながら繰り返すスパムアクセスや、同じ送信元から複数の受信者へのスパムアクセスを受け入れてしまうようである。Postfixの場合は、設定項目にsmtpd_delay_rejectパラメータというものがあって、そのデフォルト値は「yes」である。これにより、クライアントにHELO、MAIL FROM、RCPT TOコマンドを送らせてから、次のDATAコマンドを受け入れるかそこで拒絶するかを決めることができる。グレイリスティング用ポリシーサーバのpostgreyは、クライアントIPアドレス、送信者アドレス、受信者アドレスを知って、それらがともに同じであるアクセスのみを正常なリトライと判定することができる。スパムウェアがpostgreyをだますには、まともなMTAと同じリトライをしなければならない。
 そういうわけで、qmailではPostfixに比べて、グレイリスティングを適用したときのスパムの阻止率の低下がやや大きいと考えられる。qmailでは、可能ならば素のS25R方式を用いた方が、スパムに対する防御力の観点では得策であろう。
 で、国島さんが素のS25R方式に切り替えた結果…

結果はというと…まさに驚異的の一語に尽きる。受け取るSPAMは1日10通程度にまで激減した。ログを解析すると、昨晩23:00から今日の12:00までにS25Rで一時拒否したSMTP接続数は2048。実に99%以上のSPAMを、受け取ることなく排除していることになる。この間、誤って拒否したメールは1通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。

 私は論文を「阻止率99%のスパム対策方式の研究報告」と題しているが、99%とは、user unknownになるおとりのアドレスやでたらめのアドレスに宛てられたものも含めた不正メールアクセス全体についての統計である。宛先の正しいスパムの阻止率は99%に至ることは少なく、月によって97~99%といったところである。しかし、メールアドレスをウェブで公開していて、今までスパムを受け放題だった人の場合は、高い阻止率を記録しやすいかもしれない。
 そして最後に…

こんなすごい方法を編み出した浅見秀雄さんに大感謝である。

喜んでいただけて幸いです。ご利用ありがとうございます。

 ところで、国島さんは直後の記事で、逆引き名を「localhost」と不正に設定したホストからのスパムがすり抜けたことを書いておられる。qmailはパラノイド検査(逆引き名の順引き検証)をしないからだろう。Postfixはパラノイド検査をするので、このような嘘にだまされるおそれはない。「localhost」の順引き結果が元のクライアントIPアドレスに一致することは絶対にないので、検証後の逆引き結果は逆引き名がないときと同じく「unknown」となり、応答コード「450」で蹴ることができる。

日曜日, 1月 06, 2008

選択的グレイリスティングの代名詞?

 JOMONインターネットが「S25R方式によるスパム対策を2007年10月27日から運用開始した」と告知している。もちろん、ISPで素のS25R方式を運用するのは無理がある。よく読むと、やっていることはRgreyと同じ選択的グレイリスティングである。しかし、RgreyではなくS25R方式の名を掲げている。S25R方式で誤判定からの救済のためにやることはグレイリスティングで自動化できると最初に気付いてRgreyを作られたのは佐藤さんだが、JOMONインターネットの人もS25R方式を調査した際にすぐに同じ発想を得たから、ベース技術であるS25R方式の名を掲げているのかもしれない。
 グレイリスティングという技術は、私がS25R方式を考案するよりも前からあった。しかし、当たり前のものとして広まってはいない。少なくとも国内では、採用するサイトの数において素のS25R方式が追い抜いているはずである。純粋なグレイリスティングは、初めてメールを送ってくるホストに無差別に応答コード「4xx」を返して受信を遅延させる。だから、知っていても採用に二の足を踏む人は少なくなかったのかもしれない。それがS25R方式との組み合わせで、逆引きできないか逆引き名がエンドユーザーコンピュータっぽいホストにのみグレイリスティングを適用する選択的グレイリスティングのアイデアになった時、「これなら使える」と思われたのだろう。つまり、後から現れたS25R方式がグレイリスティング技術に光を当てた。
 JOMONインターネットが、S25R方式をベースとした選択的グレイリスティングも「S25R方式」と呼んでいるのは、それはそれでうれしいことではある。ソニーの商標「ウォークマン」がヘッドホンステレオの、また、ヤマハの商標「エレクトーン」が電子オルガンの代名詞になっているようなもの。それだけ「S25R」の名前が有名になったということだろう。
 ところで、冒頭のJOMONインターネットのページでは、S25R方式の原典として私のサイトを紹介してくれてはいない。しかし、そのことに不平を言うつもりはない。JOMONインターネットの人は、原典を紹介しておこうとは思い至らないくらい、S25R方式の存在を常識だと思っているのかもしれないから。

多数派の圧力

 素のS25R方式を使っている受信側サイトにとって、リトライを短時間でやめる送信サーバやリトライしない送信サーバは困った存在である(前回の記事)。このような送信サーバがある以上、受信失敗の際のリカバリーを考えておくという危機管理で対処せざるを得ない。
 このような受信失敗をなるべくしないためには、S25R方式の導入者が相互協力することが望ましい。ホワイトリスト情報をに知らせていただき、私が公表する公開ホワイトリストを共有するのである。ただ、ホワイトリスト情報を寄せてくださるのはあくまでもボランティアの行動であり、S25R方式の導入者みんながそうしてくださるわけではないので、限界がある。
 もっとも、S25R方式で受信に失敗するような送信サーバは今後減っていくことが期待できる。S25R方式が広まれば、多くの人がS25R方式を知るようになる。送信サーバを立てる人は、S25R方式を採用するサイトにもちゃんと受信してもらうことを考慮せざるを得なくなる。すなわち、S25Rの拒否条件に引っかからない逆引き名を付けるか、受信側サイトのメールシステム管理者が気付いてホワイトリスト登録してくれるまでリトライすることである(逆引きを設定しても、受信側でDNS検索に一時的に失敗することがあるので、どのみちリトライは必要であるが)。さもないと、受信に失敗したサイトから問い合わせや再送依頼を頻繁に受けることになりかねない。
 私は、S25R方式を提案するにあたって、S25R方式によるスパム対策の都合のために送信側で逆引きを設定してほしいとは言っていない。送信側はまともなMTAを使っていてくれさえすればよいという前提で、正当なメールを誤判定から救済する努力は受信側だけで行うことをS25R方式のコンセプトとしている。実際のところ、受信側の努力で正当なメールを救済できないケースもまれにある。しかし、S25R方式を採用するサイトが多数派になれば、それは送信サーバにも送達のための相応の努力を求める無言の圧力になるだろう。

金曜日, 1月 04, 2008

送達の努力をしない送信サーバには…

 DNSBLの情報を信用して正当なメールサーバを応答コード「5xx」で蹴るサイトがある内容チェックの誤判定で正当なメールを「5xx」で蹴るサイトもある。偽陽性のおそれがある判定でメールを(保留させるのでも印を付けて届けるのでもなく)バウンスさせることには反対である。私は、S25R方式を導入される方々に対して、正当なメールを受け入れるために最善の努力をするよう訴えている。つまり、絶対に不正メールだと確信できる場合(HELOアドレスが違法である、ポルノサイトであるなど)以外の受信拒否時には必ず「450」で再送要求し、ログを監視して、リトライアクセスを発見したらホワイトリスト登録する。
 ただ、受信側のこの努力によって正当なメールを受け入れるのは、応答コード「450」による拒否に対して送信側がある程度の期間リトライを続けてくれること、すなわち、送信サーバもメールの送達のためにある程度努力してくれることを前提としている。Postfixやsendmailのデフォルト設定で5日間リトライしてくれれば、週末や3連休を挟んでも救済できる。しかし、リトライ期間が2日以下だと、週末にスタッフが休む組織サイトではメールを受け損なうおそれがある。1時間くらいしかリトライしてくれないと(私が発見しているのは、メールマガジン携帯電話会社からのエラーリターンのケース)、手動で救済することは非常に困難である。1時間くらいでリトライをやめるのは、受信側が何らかのトラブルに陥った時に1時間以内に復旧するのは期待しにくいということを考慮していない、つまり、メールを送達させる努力をする意思がないと考えざるを得ない。
 Rgreyを使えば、リトライ期間が短くても受信できる。しかし、Rgreyの導入に二の足を踏む人は少なくないだろう。S25R方式が多くの人たちに受け入れられた最も大きな理由は、スパムの阻止率もさることながら、Postfixの設定だけで実現できるという簡便さに違いない。メールシステム管理者の中には、Postfixのオペレーションがどうにかできるくらいのスキルレベルの人はおそらく少なくない。スキルの高い人は、ホワイトリスト登録という手間のかかる作業はなんとか自動化したいと考えるだろう。しかし、スキルの高くない人にとっては、単純作業の継続はさして苦にならず、むしろ、新たな付加ソフトウェアを導入するための勉強に頭脳と時間を費やすことはかなりの負担なのである。
 ところで、大規模サイトでRgreyを使っている人から聞いた話によると、Rgreyでも救えないメールがあるらしい。ウェブへの入力に応答してメールを送信するシステムなどで、リトライしないものがあるとのこと。このような送信サーバは、タールピッティングに耐えさえすればStarpitで救済できる。ところが、佐藤さんによれば、タールピッティングに耐えないメールサーバもあるらしい。そこで、タールピッティングに耐えるかリトライするかいずれかを満たせば救済できるようにしようと佐藤さんが開発されたのがtaRgreyである。しかし、これも付加ソフトウェアを要するから、スキルの高くない人にとっては、導入にはかなりの負担になる。
 正当なメールを受け入れるための最善の努力といっても限界がある。送達のための努力をしてくれないメールサーバを救済する努力は困難である。Postfixのオペレーションがどうにかできるくらいの人にとっては、RgreyやtaRgreyの導入は“最善”を超えた努力である。
 では、スキルの高くないメールシステム管理者がこの問題に対処するにはどうすればよいか。受信失敗がありうることを認識し、そのリカバリーのために最善を尽くすことである。その要点を次に示す。

●ある程度の期間(毎日ログを監視する場合は1日以上、スタッフが最大3日監視を休むとすれば4日以上)リトライしないメールを受信できないことがありうるということをユーザーに断っておく。

拒絶ログソーティングスクリプトでログを監視し、おおむね30分以上リトライしていて救済が間に合わなかったと思われるアクセスが見つかったらユーザーに知らせてあげる。

●ユーザーが、来るはずのメールが来ないと思った時には、申し出てもらって、ログを調べてあげる。

●受信失敗とわかった時には、ホワイトリスト登録した上で、人からのメールだったならば送信者に再送を依頼するよう、また、オンラインショッピングの確認メールなどの場合は送信サイトに問い合わせるようユーザーに助言する。ユーザーが問い合わせ方法がわからない場合は、方法を調べてあげる。

 ここまでやれば、たとえ受信失敗が起こっても、ユーザーのために最善の努力をしていると言える。
 メールサービスでユーザーからお金をもらっているわけではない、企業や学校などの組織のメールシステム管理者は、ともすると「メールサービスを提供してやっている」、「スパムの被害から守ってやっている」という恩着せがましい意識に陥りがちであるが、ゆめゆめそんなことは思わないように。「ユーザーはお客様」という意識で最善を尽くしていただきたい。