拒絶ログソーティングスクリプトを改良した。変更点は以下のとおりである。
■単独のアクセス記録の表示を抑止するスイッチ
リトライしなかった単独のアクセスの記録を抑止してリトライシーケンスだけを表示したい場合のために、コードの改造方法を説明していた。しかし、そのように改造すると、最後に表示するアクセス数と推定メッセージ数が、リトライシーケンスのアクセスについてのみのカウントになってしまい、全体のアクセスについてのデータがわからなくなってしまっていた。
そこで、単独のアクセスの記録を抑止してもアクセス数と推定メッセージ数のカウントが変わらないように改良した。
その際、単独のアクセス記録の抑止をオン・オフするスイッチの変数を設け、その初期値を書き換えるだけで済むようにした。単独のアクセス記録を抑止するには、最後のプロセスの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月 29, 2008
日曜日, 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方式が不要になる時が来ても、ベイジアンフィルタの出番はなおも残るわけだな。私は、ベイジアンフィルタを使わずに済む簡単なアンチスパム技術を考案して、「頭のいい人って、なんで難しいことを考えるのだろう」と思っていたが、やっぱ、頭のいい人が作るものは違うわ。
さて、このような将来像が実現してもなおスパムはペイするでしょうか。私は、スパムを根絶できるとは思わないが、今のような傍若無人な大量スパム配信はできなくなると思う。これでもスパムを今くらいに大量にばらまく抜け道があることに気付かれた方はコメントください。
水曜日, 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]
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」に由来する。国名を四つの公用語で併記する代わりに単独で表記する国名として、どの言語話者にも不公平にならないようにラテン語を使っているのである。
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と同じことをやっていることがわかった。
スパムを受けないためには正当なメールを間違って、あるいは故意にバウンスさせてもかまわないというやり方は信じられない。私だけでなく、たいていの日本人は同じことを思うのではないだろうか。この荒っぽさが大陸民族の文化というものなのだろうか。
日本人ならこんなことはしないだろう。正当なメールを必ず受信できる完璧さをユーザーが求めるからということもあるが、メールシステム管理者は、メールを受信できないと困るユーザーに気配りし、善良な送信者に迷惑をかけないようにとも気配りする。「和を以って貴しと為す」という文化の中で育った日本人にとって、それはごく当たり前のことである。日本人の島国根性には「出る杭は打たれる」などの悪い面もあるが、他人への気配りは日本の美徳(*)だと思う。
韓国製のOptPlusに実装されたバウンシングバック認証方式のコンセプトも、私には理解しがたい。善良な送信者に認証手続きの手間を要求することを失礼だとは思わないのだろうか。スパマーに送信者アドレスをかたられた被害者にバウンシングバック認証要求メールを殺到させることを申し訳ないとは思わないのだろうか。自分がスパムの被害から助かりさえすればよいという観念も大陸文化なのだろうか。
日本の美徳をわきまえた日本人にはOptPlusは売れないと思う。OptPlusを買っている人は、S25R方式を知らないに違いない。両方を知る人ならきっとS25R方式を選ぶ（なにしろ無料だし）。日本の気配りの文化をわきまえず、OptPlusが日本で売れると思って輸入したベンダーのビジネス感覚が、私には理解できない。
S25R方式は、注意深く運用すれば、受信者にも善良な送信者にも迷惑をかけない。メール送信サーバにメールを一時滞留させることはあるが、送信者を困らせることはないし、手間をかけさせることもない。正当なメールの受信が遅延することはあるが、ちゃんと届く。私は、ユーザーへの気配りに根ざした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方式に対していただいている賛辞を要約すると、次のとおりである。
天才的とまで絶賛されると気恥ずかしい。発想のきっかけは2006年10月21日「無精者の勝利」に書いた。思い付いたのは2003年5月。スパムが急に増え始めたのがきっかけだったが、スパムアクセス数はまだ今の1/10くらいのころだった。postgreyもDNSBLも知らなかった。Postfixが備える機能を利用して効率的にスパムをはじく方法を工夫した。大して高いスキルのない自分でもできる方法を考えたのである。
個人用メールサーバを運用していたことが幸いした。組織サイトでこんな実験は危なくてできない。個人サイトでありながら、8個ブロックのIPアドレスをもらって逆引き権限の委譲を受けていることも幸いした。ドメイン管理者ならサーバにどのような名前を付けたがるかという思考ができた。S25Rに引っかかるお仕着せの逆引き名がISPから割り当てられる、IPアドレス1個の安い接続サービスを使っていたら、「そのようなサーバを拒否しても、ホワイトリストで救済すればよい」という発想はしにくかったかもしれない。
「スパムの送信元には逆引きできないものが多いので、それを蹴ってみよう。次に、逆引きできても逆引き名がIPアドレスをそのまま反映したものも多いので、それも蹴ってみよう」――ここまでは、ほかの人でも容易に発想できたと思う。
私がオリジナリティを誇るとすれば、その後の段階である。逆引き名からアクセス元を高い確度でエンドユーザーコンピュータと推定するための規則をわずか六つの正規表現に類型化した。これは、世界の誰もやっていなかった。数千回に及ぶ不正メールアクセスの逆引き名から単純な法則を見出したのは、私の特異な能力によるものかもしれない。これを「天才的」と褒めていただけるなら、私は喜んでお褒めを拝受しよう。
これだけでは、S25R方式は使い物にならなかった。私は、誤判定される正当なメールを受信し損なわないために最善を尽くした。その方法も発表した。それは簡単な仕事である。ログの監視とホワイトリスト登録という単純作業を継続する忍耐があればよい。それは天才的な成果ではない。ただ、その背景として、善良な送信者に迷惑をかけまいという、他人への気配りの心が私にあった。だから、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ヶ月、観測されていない。
エンドユーザー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による受信側の自衛策が不要になる時代は当分来そうにない。
以下は、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方式に切り替えた結果…
私は論文を「阻止率99%のスパム対策方式の研究報告」と題しているが、99%とは、user unknownになるおとりのアドレスやでたらめのアドレスに宛てられたものも含めた不正メールアクセス全体についての統計である。宛先の正しいスパムの阻止率は99%に至ることは少なく、月によって97～99%といったところである。しかし、メールアドレスをウェブで公開していて、今までスパムを受け放題だった人の場合は、高い阻止率を記録しやすいかもしれない。
そして最後に…
喜んでいただけて幸いです。ご利用ありがとうございます。
ところで、国島さんは直後の記事で、逆引き名を「localhost」と不正に設定したホストからのスパムがすり抜けたことを書いておられる。qmailはパラノイド検査（逆引き名の順引き検証）をしないからだろう。Postfixはパラノイド検査をするので、このような嘘にだまされるおそれはない。「localhost」の順引き結果が元のクライアントIPアドレスに一致することは絶対にないので、検証後の逆引き結果は逆引き名がないときと同じく「unknown」となり、応答コード「450」で蹴ることができる。
国島さんが管理するメールサーバでは、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を、受け取ることなく排除していることになる。この間、誤って拒否したメールは１通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。 |
私は論文を「阻止率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方式が追い抜いているはずである。純粋なグレイリスティングは、初めてメールを送ってくるホストに無差別に応答コード「4xx」を返して受信を遅延させる。だから、知っていても採用に二の足を踏む人は少なくなかったのかもしれない。それがS25R方式との組み合わせで、逆引きできないか逆引き名がエンドユーザーコンピュータっぽいホストにのみグレイリスティングを適用する選択的グレイリスティングのアイデアになった時、「これなら使える」と思われたのだろう。つまり、後から現れたS25R方式がグレイリスティング技術に光を当てた。
JOMONインターネットが、S25R方式をベースとした選択的グレイリスティングも「S25R方式」と呼んでいるのは、それはそれでうれしいことではある。ソニーの商標「ウォークマン」がヘッドホンステレオの、また、ヤマハの商標「エレクトーン」が電子オルガンの代名詞になっているようなもの。それだけ「S25R」の名前が有名になったということだろう。
ところで、冒頭のJOMONインターネットのページでは、S25R方式の原典として私のサイトを紹介してくれてはいない。しかし、そのことに不平を言うつもりはない。JOMONインターネットの人は、原典を紹介しておこうとは思い至らないくらい、S25R方式の存在を常識だと思っているのかもしれないから。
登録:
投稿 (Atom)