もういいかげん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とバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。）
金曜日, 6月 06, 2008
火曜日, 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をこうして強く批判することができるのである。
ところが、図を見ると、ペンディングキューにたまったバウンシングバック未認証のメールが正当なメールかスパムかを判定する手がかりは、差出人アドレスとサブジェクトしかない。これでは判定が難しそうである。
サブジェクトが「裏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とバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。）
「認証依頼メールを送信することにより、"不審者を社内に寄せ付けない企業"というクリーンなイメージを持っていただけるケースが多い」
と書かれている。私は、私にメールをくれる善良な送信者に対して認証手続きの手間を要求する気にはとてもなれない。とはいえ、認証手続きの手間を要求されて腹を立てる善良な送信者は私が気兼ねするほどには多くないだろうということは認めよう。
しかし、それでもなお、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通で済んだ）。
もし同じ文面のスパムが大量に差し戻されてきたら、<A>タグで指定されたURLを拾って、body_checksファイルには次のように記述する。
/http:\/\/track\.msadcenter\.lyv\.com\/wwfdtge_ovatpimxtn\.html/ REJECT
これにより、差し戻しの受け取りが拒否される。差し戻そうとしたサイトのポストマスターに差し戻し失敗の通知が行くのは迷惑かもしれないが、やむを得ない。こちらの自己防衛のためである。
そもそも、MXサーバで受け取った後にuser unknownを検出して送信者アドレスへ向けて差し戻すというシステム構成が良くないのである。外部から最初にメールを受信するMXサーバにサイト内のユーザーリストを持っておいて、サイト内部でuser unknownになることをMXサーバがただちに判定して受け取りを拒否するシステム構成の方がよい。そうすれば、アドレスをかたられた被害者に不正な差し戻しが行くことはなくなるし、でたらめの送信者アドレスをかたったスパムの差し戻しが失敗してポストマスターに通知が殺到することもなくなる。もっとも、qmailでは難しいのかもしれないが。
その記事では、「差し戻しはメールサーバから送られてくるから、残念ながら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%スパムメールブロックの仕組み」というページに書かれているバウンシングバック認証要求メールの文例は次のようになっている（メールアドレスの例示は、この記事からスパマーに拾われないように伏せ字にする）。
この文例は、スパマーに送信者アドレスをかたられた被害者にバウンシングバック認証要求が届きうるということをベンダーがまったく考えていないことを物語っている。これでは、前回述べたように、アドレスをかたられた被害者が意味もわからず、あるいは不要メールを送り付けられた怒りで認証手続きをしてしまう可能性がある。
アドレスをかたられた被害者にバウンシングバック認証要求メールを殺到させてしまう迷惑を申し訳ないことだと自覚しているなら、せめて次のような文を入れるべきである。
「もし弊社にメールを送信されたお心当たりがないのにこのメールが届いたならば、他人があなた様のメールアドレスを不正に使用して弊社にメールを送信したことが考えられます。その場合はこのメールを無視してください。ご迷惑をおかけしたことをお詫びいたします。」
もし今後、文例がこのように直されていたら、ベンダーが私のブログを見たということだろう。
ついでに言うと、「10日以内に認証してください」という依頼は不要である。受信者は、正当な送信者が認証要求に応じてくれなかった場合に備えて、定期的にペンディングキューを確認しなければならない。「10日以内」というのはその猶予である。ペンディングキューを10日間も確認しなかったら、それは受信者の怠慢である。10日という期限を正当な送信者に意識させる必要はない。「認証いただけない場合、送信いただいたメールが自動的に破棄されてしまいます」という警告ももちろん不要である。
もう一つ言うと、「携帯電話からは認証できません。受信者側で手動認証いたしますので、本メールは無視してください。」と言うくらいなら、バウンシングバック認証要求メールそのものが不要である。受信者がペンディングキューに注意していればよい。このことは2007年6月17日「OptPlusの機能を考える」でも述べた。
私のブログのバウンシングバック認証方式反対キャンペーンを読んでもなおOptPlusを買おうと思う人がもしいたら、せめてバウンシングバック認証要求メールの送信はオフにして使ってほしい。ペンディングキューを監視していさえすれば、バウンシングバック認証要求メールは必要ないのだから。
| メールをいただき、ありがとうございます。 株式会社ネオジャパンの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%のスパム阻止などあり得ないのである。
BBSで何度かホワイトリスト情報をお寄せくださっているkkkさんも、アドレスをかたられてスパムの差し戻しを677通受けられたそうである。差し戻しはメールサーバから送られてくるから、残念ながらS25Rでは阻止できない。
そして、バウンシングバック認証要求メールも4通受けたとのこと。そのうち1通はウェブページへのアクセスを要求するもの、3通は返信メールを要求するものだったそうである。OptPlusはウェブページへのアクセスを要求する方式なので、バウンシングバック認証方式をとるシステムはOptPlusだけではないらしい。
kkkさんいわく「不愉快ですね」と。そりゃそうだ。スパムのエラー差し戻しが大量に押し寄せ、それに加えて、送ってもいないメールへのバウンシングバック認証要求を送り付けられては、頭にきて当然である。数が少なければよいというものではない。みんながやると大きな被害になることを「自分一人くらい」と思ってやるのがいけないのである。
さて、アドレスをかたられてバウンシングバック認証要求を受けた被害者が認証要求に応じたらどうなるか。当然、スパムは通過することになる。被害者が認証要求に応じる理由には以下が考えられる。
■報復
アドレスをかたられた被害者への迷惑を省みないバウンシングバック認証方式を使うサイトに対して、報復のためにスパムを通過させる。
■親切
OptPlusを使ったASPが「スパムを1通でも受けたら返金します」と豪語していることを知っている人が、ユーザーに返金を受けさせてあげようという親切心でスパムを通過させる。もっとも、豪語するASPに損失を与えようとするものだから、これをやるのもバウンシング認証方式反対派の人であろう。
■天然
「なんかよくわからないんだけどー、クリックしてくれってメールに書いてあったので、クリックしましたー！」
OptPlusの開発者やベンダーは、よもやそんなことはあるまいと思っているふしがあるが、よもやあるまいと思うことが起こるのが世の中である。アドレスをかたられた被害者に、ごみメールを増やすという迷惑をかけておきながら、その人が認証手続きをしないことによってスパムの阻止に当然協力してくれるだろうとは、ずいぶん虫のいい考えだと思う。
ここまで書いてきてふと気が付いた。スパマー自身が認証要求に応じることによってスパムを通過させることも考えられる。送信者アドレスを詐称せずにバウンスをまともに受け、バウンシングバック認証要求メールに書かれたURLに自動アクセスするか、またはそれに自動リプライすることは、技術的に可能であろう。CAPTCHA認証を突破する技術も進みつつあるとの情報もある。
100%のスパム阻止などあり得ないのである。
土曜日, 4月 12, 2008
OptPlusも失礼な受信拒否をしそうだ
SYSMATE社の、OptPlusの説明ページにこんな記述がある。
ここから読み取れることは、ベイジアンフィルタでスパムパターンに引っかかったメールはブロックされ、バウンシングバック認証待ちのペンディングキューに入らないらしいということである。すなわち、ペンディングキューに入るスパムはベイジアンフィルタをすり抜けた約15%だけと思われる。私は2007年6月17日「OptPlusの機能を考える」で
「(3) スパムパターンチェック …（略）… おそらく、ここでスパム判定されたメールは、捨てずにペンディングキューに入れるのだろう。偽陽性判定された正当なメールをユーザーが拾い出せなければ困るから。」
と述べたが、どうもそうではないらしい。
考えてみたら、ベイジアンフィルタに引っかかったかどうかにかかわらずスパムをすべてペンディングキューに入れたら、ユーザーはその中身を確認するのが大変である。これでは販売戦略的にまずい。ベイジアンフィルタでスパムとわかる約85%のスパムをすべてブロックし、念のために確認しなければならないスパムを15%くらいに減らしてこそ、客に「いいねえ」と言ってもらえる。
ということはどういうことか。ベイジアンフィルタで偽陽性判定された正当なメールに対して失礼な受信拒否をするということである。私が運用するメーリングリストで配信した会合案内のメールがスパム判定されて失礼にも「5xx」で蹴られた実例を再掲する。前者はインドの会社、後者はアメリカの著名な学会である。
おわかりだろうか。OptPlusもおそらく同じことをするのである。スパム判定時に「4xx」（再送要求）を返し、同じメールが再送されてきたら受け入れるという救済措置がもしあれば、偽陽性判定を心配する人にアピールするアドバンテージになるはずであるが、そのことは何も述べられていない。
念のために言っておくが、ベイジアンフィルタが偽陽性判定を絶対に起こさないなどということはあり得ない。上記のように、理由のわからない偽陽性判定の被害を実際に私は受けている。まして、スパムを引用して「こんな変なメールを受けたんですが、どうしたらいいですか？」と相談するメールや、「スパムによくあるviagra、cialis、xanaxという語は薬物の名前です」などのように書いたまともなメールが偽陽性判定される確率はきわめて高い。
改めて私は、次の二つの重大な理由により、OptPlusを買わないよう強く訴える。
●詐称された送信者アドレスへバウンシングバック認証要求メールを返すことにより、アドレスをかたられた無実の被害者に迷惑をかける。
●ベイジアンフィルタで偽陽性判定された正当なメールを（一時的にでなく完全に）受信拒否することにより、善良な送信者に迷惑をかける。そのメールを受けるはずだった受信者にも迷惑をかける。
いくらスパムを憎んでも善良なインターネットユーザーには決して迷惑をかけまいと思う日本的美徳をわきまえた日本人は、この韓国製の製品を使ってはいけない。
（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のユーザーのメールアドレスを有効なアドレスとして知るスパマーが増えるほどに、いったん破られたら被害は大きくなる。
そもそも、詐称が容易な信頼できない情報である送信者アドレスを、正当なメールかどうかの判定に使おうというのが間違っているのである。
| 「送信したメールの数だけ認証依頼メールが届くため、スパマーを攻撃することにもつながる」(狩野氏)という。 |
なんちゅうことおっしゃるの！
スパムの送信者アドレスに向けて大量のメールを送り付けることによってスパマーに被害を与えることができるくらいなら、みんなやっている。それはやってはならないことだというのは常識である。もちろん、スパマーは送信者アドレスを詐称するからである。スパムの送信者アドレスへメールを返すことは、アドレスをかたられた罪のない被害者を攻撃することになるのである。
もう一つ、スパムに返信してはならないとされる理由がある。受信者アドレスが有効であることをスパマーに教えてしまうおそれがあるからである。この、やってはならないとされることを自動でやってくれるのがバウンシングバック認証方式である。
もしスパマーが、罪のない他人のアドレスを送信者アドレスにかたらずに、バウンスが自分に返るように送信者アドレスを設定することがあるとすれば、宛先アドレスの正しさを確認するためだろう。当然、大量のエラーバウンスを受けても平気なように受け口を準備する。そしておそらく、受けたバウンスを自動処理する。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を置き換え文字として使うことにした。どうでもいいこだわりである。
■単独のアクセス記録の表示を抑止するスイッチ
リトライしなかった単独のアクセスの記録を抑止してリトライシーケンスだけを表示したい場合のために、コードの改造方法を説明していた。しかし、そのように改造すると、最後に表示するアクセス数と推定メッセージ数が、リトライシーケンスのアクセスについてのみのカウントになってしまい、全体のアクセスについてのデータがわからなくなってしまっていた。
そこで、単独のアクセスの記録を抑止してもアクセス数と推定メッセージ数のカウントが変わらないように改良した。
その際、単独のアクセス記録の抑止をオン・オフするスイッチの変数を設け、その初期値を書き換えるだけで済むようにした。単独のアクセス記録を抑止するには、最後のプロセスの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」）
「どの国へメールを送った時に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%になると推定される。グレイリスティングを併用しても十分な阻止率を保てると言える。
しかし、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を利用した場合の阻止率は50～60%と推測される。たったそんなもんなの？
RBL.JPのBlack 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などによるコンテンツフィルタリングにもかなり依存せざるを得ない。だからスパマーとのいたちごっこから抜け出せず、「それ以上がんばらないという割り切り」どころではないんだろうな。
↑クリックしてご覧になればおわかりのとおり、「DNSBL」の代わりに「RBL」でもよい、「阻止率」の代わりに「拒否率」でもよいという検索ワード条件にしたのだが、ヒット件数は424件、表示件数はわずか59件。内容の抜粋に「%」という文字があるものはたいてい、私の論文のタイトルか、メール以外（BBS、コメント、トラックバック）のスパムに関する情報。日本語のページしか探していないが、DNSBLを使うサイトは少なくないはずだから、「スパムの受信を××%減らすことができた」と定量的なデータを公表する人が少しくらいいてもよさそうなもの。いったいどうしたことだろうか。
かろうじて手がかりになったのは、3位にヒットした「日本語版のRBLサービス」というページ。最後の方にこんな記述があった。
| spamcop.net効かせてみました。サーバのログ上、確かに相当な数のものがはじかれてはいるのですが、それでも尚、私のアカウントには毎日80通程度は届きます。以前は150通～200通だった事を思えば、効果はてきめんですが、「選別する手間はあまり変わらないかも・・。」って感じです。 |
ここから、SPAMCOPを利用した場合の阻止率は50～60%と推測される。たったそんなもんなの？
RBL.JPのBlack 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をすり抜けるが、メールサーバがメールトラフィックのボトルネックになるので、そのようなスパムはあまり増えないだろう。そんなわけで、私は悲観的な気持ちにはなっていない。
すり抜けるわずかな割合のスパムに悲観的になり、それをゼロに近付けようとがんばるほどに、対策コスト（メールシステム管理者の頭脳と時間の消費を含む）は急激に増大する。スパムの受信が業務に支障がないくらい（一人一日数通程度）に減ればそれ以上がんばらないという割り切りも必要だと思う。
私のサイトで観察する限り、ボットからのリトライしない（あるいは、リトライのたびに送信者アドレスが変わるため、正常なリトライとして検出されない）スパムアクセスが今なおほとんどである。前回の記事で述べたとおり、グレイリスティングを突破しそうなスパムメッセージは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の誤判定からの自動救済にはグレイリスティングだけを使うことをお勧めしたい。協力者の皆様のおかげでだいぶ充実した公開ホワイトリストを組み込めば、正当なメールの受信遅延が起こる確率は非常に低くできる。
佐藤さんの別の記事からリンクされている「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」に変わったことがわかった。
2月21日に送信し、私のメールサーバは5日間のリトライの末、26日にギブアップした。
リトライを放置するくらいなら、なぜ「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である。選ぶ数が機械的には知られにくいようにすれば、さらに突破の確率を低くできる。
しかも、この方法なら、プログラムが難しくなることもない。また、認証手続きに文字入力が不要でマウス操作だけですむので、ユーザーには好まれるかもしれない。
よく使われている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」（架空の例）のように数字で始まるサイトドメイン名の場合、逆引き名には英字で始まる末端ホスト名を省略してはならないという制約が付くことになる。このことは問題にはならないだろう。
逆引き命名法を標準化してすべてのサイトがそれに準拠するようになるには、逆引き名の変更の痛みを負うサイトがどうしても出てくる。誰も痛みを負うのはいやだから、逆引き命名法の標準化は容易には合意されないだろう。しかし、もしその標準化を行うとすれば、ここに示した案よりも良いルールはないと思う。これは現実の逆引き名の傾向を踏まえた、しかも非常に簡潔なルールだからである。
論文の「統計データ」の節に示しているとおり、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はさほど効果的でないことが認識されることになるだろう。そのころになってようやく、送信元の逆引き名を手がかりにする方法が注目され、逆引き命名法の標準化が議論されるようになるのかもしれない。
次の記事で、逆引き命名法の標準化の案を述べる。
今の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方式を捨てることはないだろう。
（関連記事）
送信ドメイン認証はスパムに勝てないだろう
送信ドメイン認証は誰にとって有益か
望ましいドメイン認証方式がインターネットに普及した時、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）も、インターネット全域で合意されて速やかにあまねく実装されるには理想的なものではないと思っている。道は遠い。
■流量制限
それでもボットあるいは悪意あるユーザーがスパムを送信するならば、送信側メールサーバで流量制限をかける。一メッセージについての宛先の数を制限するとともに、一クライアントからの常軌を逸した頻度の送信に対しては、応答遅延、または投函の一時拒否によるスロットリングをかける。これにより、大量スパム配信が抑制される。
■内容検査による送信保留
ボットあるいは悪意あるユーザーによるスパム送信へのもう一つの対抗手段は内容検査である。送信されるスパムのデータを集めながら、送信側メールサーバでベイジアンフィルタによる内容検査を行う。もしスパム判定されたら、次のような内容のバウンシングバックメールを送信者に返して認証を求める。
バウンシングバックメールとはいっても、詐称されているかもしれない送信者アドレスに向かって誰彼かまわず投げまくるOptPlusのバウンシングバック認証方式とは異なる。送り先は、そのメールサーバにアカウントを持つユーザーのメールボックスだけである。
もしボットによるスパムだったならば、ユーザーは身に覚えのないバウンシングバックメールを受けて、アカウントの悪用に気付くことができる。もしユーザーが故意にスパムを送信したならば、送信手続きの手間を強いられるので、スパムの大量送信が非常に困難になる。
こうして考えてみると、いずれ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方式が不要になる時が来ても、ベイジアンフィルタの出番はなおも残るわけだな。私は、ベイジアンフィルタを使わずに済む簡単なアンチスパム技術を考案して、「頭のいい人って、なんで難しいことを考えるのだろう」と思っていたが、やっぱ、頭のいい人が作るものは違うわ。
さて、このような将来像が実現してもなおスパムはペイするでしょうか。私は、スパムを根絶できるとは思わないが、今のような傍若無人な大量スパム配信はできなくなると思う。これでもスパムを今くらいに大量にばらまく抜け道があることに気付かれた方はコメントください。
登録:
投稿 (Atom)