ベルギーのドメインの管理者からメールをいただいた。「うちのドメインからドイツの***.deというドメインへ送るメールがことごとく『550 S25R check reject』というメッセージで拒否される」とのこと。「S25R」で検索して私のサイトを見つけて連絡してきたらしい。
宛先のドイツのドメインのオーナーへメールを送った。「拒否コード『550』を返しては絶対にいけません。S25Rはしばしば偽陽性判定を起こします。『450』を返して、再試行するクライアントをホワイトリスト登録するようにしてください。さもなければ自動ホワイトリスティングシステムを導入する必要があります」。
最初、postmaster宛に送ったのだが、エラーリターンしてしまった。必須のエイリアスなのに、最近では設定していない人もいるようである。ドメインに「www.」を付けたURLでウェブサイトにアクセスし、連絡先アドレスを見つけ出してそこへ送り直した。
ベルギーへは、「宛先ドメインの管理者にこのように伝えました。あなたからも苦情を送ってはどうでしょうか。あなたのメールサーバはS25Rに引っかかりません」と伝えた。
3月31日にメールを送って、まだどちらからも返事がない。どうなっているのか…。
月曜日, 4月 04, 2011
火曜日, 3月 29, 2011
チェコから礼状
チェコの人から礼状をいただいた。
以前、S25R方式を使っているという報告は香港からもいただいたことがあり、外国からの礼状はこれで2度目である。私の拙い英語のコンテンツから日本発のアイデアの有用性を読み取っていただけたことは実に嬉しい。
商用サービスには、やはり手動のS25R方式よりも、偽陽性判定を自動救済するtaRgreyの有用性が評価されるようである。開発者の佐藤さんに改めて感謝の意を表したい。
| S25RとtaRgreyを2008年から使っています。 ここチェコ共和国で、ホスティングサーバと、顧客の5台のサーバにインストールしています。内容チェックは、役に立たないのでやめました。 少しのスパムがspamhausでブロックされており、毎日、（taRgreyで）偽陽性が報告されることなく各サーバ8000通ずつ、計40000通のスパムをブロックしています。 偽陰性はありますが、さほど多くありません。 |
以前、S25R方式を使っているという報告は香港からもいただいたことがあり、外国からの礼状はこれで2度目である。私の拙い英語のコンテンツから日本発のアイデアの有用性を読み取っていただけたことは実に嬉しい。
商用サービスには、やはり手動のS25R方式よりも、偽陽性判定を自動救済するtaRgreyの有用性が評価されるようである。開発者の佐藤さんに改めて感謝の意を表したい。
日曜日, 3月 13, 2011
停電による自宅サーバ運休の可能性のお知らせ
東日本大震災のため、東京電力管内では電力が足りなくなり、計画停電を行うとのことです。S25Rホームページを掲載している私の自宅サイトは神奈川県横浜市にあり、東京電力管内なので、停電の影響を受ける可能性があります。UPSはありますが、計画停電の継続時間（3時間程度）はもたないと考えられるので、サーバをシャットダウンする可能性があります。あらかじめご了承くださいますようお願いいたします。
水曜日, 11月 03, 2010
ブラックリスト情報の受付の基準
一般規則のルール1～6をやめる代わりとなるブラックリストの項目追加はなおも終わりそうにない。OCNの固定IPアドレスからのスパムアクセスに続いて、同じくOP25Bを導入していることがわかっているODNからも来た。論文に掲載しているブラックリストの実例にあるmindspring.comからのスパムアクセスは最近ほとんど来なくなっていて、OP25Bを導入したことが推測されるが、そこからも久しぶりに1回来た。10月31日に考察した条件に基づいて、ODNはブラックリストに登録せず、mindspring.comは登録した。
このことから考えると、1回でもスパムアクセスがあったら動的IPアドレスだろうと固定IPアドレスだろうとブラックリストに登録する（どのみち、どちらであるかは通常はわからないのだから）という方法をとっていれば、OP25Bを導入済みかもしれないISPも含めて、逆引きできるすべてのISPドメインに近い数の（OP25B導入済みでホワイトリスト情報があるISPだけを除く）ブラックリスト項目ができることになるかもしれない。これはけっこう大変そうである。
言い換えれば、S25R方式を発表した2004年ころには、逆引きできるホストも6個の正規表現で蹴りまくる方法がいかに正しかったかということである。そうでなければ、導入した人がびっくりして感激するほどのスパム阻止率はとうてい得られなかったのだから。
公開ブラックリストを仮開放したが、こういう状況なので、一般規則のルール1～6をやめても十分にスパムを阻止できると保証することはできない。ルール1～6をやめる方法を今取り入れた人は、公開ブラックリストをすり抜けるスパム送信元ホストを新たに次々と発見することになるだろう。もしかしたら、その情報を提供して公開ブラックリストの充実のために協力しようという人がおられるかもしれない。そこで、ブラックリスト情報を受理する基準を説明しておく。
ブラックリスト情報の提供にあたっては、スパムを送って来た（またはスパムアクセスをして来た）ホストの逆引き名を報告していただく。原則として、以下のいずれかの条件を満たすものを受理する。
●一般規則に引っかかることから、エンドユーザー回線と推定できる。
●十六進番号を含むことから、エンドユーザー回線と推定できる。
●上記いずれの条件も満たさなくても、複数の逆引き名から、エンドユーザー回線の命名規則を推定できる（tpnet.plのようなケース）。
ただし、OP25B導入済みとわかっていて、ホワイトリスト情報があり、かつ私がスパムアクセスをほとんど観測できないドメインについては受理しない（未知の正当なメールサーバからのメールをホワイトリストなしで受信したい人の不利益になりかねないからである）。
上記いずれの条件にも当てはまらないためにメールサーバと推定されるホストのブラックリスト情報は、受理しない。自社の宣伝のためにスパムをまいた前科のある会社だとか、ポルノサイトであるとわかっている場合でも、それはローカルのブラックリストで対処していただく。そのメールサーバをブロックしたいかどうかは、サイトのポリシーによることだからである。そこからのメールを受けたいユーザーのいるサイトの運用に支障を与えることは避けたい。S25R方式において、どのサイトでも共通に使えるスパムブロック方法として提供するのは、あくまでも、エンドユーザーコンピュータと推定されるホストのブロックである。
例外的に、volia.netについては、サイトドメインを丸ごとブロックする条件を公開ブラックリストに登録している。サーバにしか見えない逆引き名のたくさんのホストからスパムアクセスが来るからである。このようなサイトは他に見つかっていない。ブラックリストファイルには、ブラックリスト作成中に見つかったvolia.net内のスパム送信元ホストをすべてコメント行で列挙している（ここまでやる必要はないとは思いつつ）。あきれるばかりである。
# absolving.argument.volia.net
# vehicleness.basin.volia.net
# beachless-vim.volia.net
# designsless.bellows.volia.net
# praise.bend.volia.net
# nodeless.billing.volia.net
# cabinetness-decrease.volia.net
# tusk.calm.volia.net
# devoted-apportioner.volia.net
# earnest-air.volia.net
# efficient-clamourer.volia.net
# feelerly-assault.volia.net
# gadfliless.ideology.volia.net
# inclined-slope.volia.net
# stencilless.management.volia.net
# merging-signature.volia.net
# dressingly.motel.volia.net
# nearer-orchard.volia.net
# pressuring.orthodoxy.volia.net
# pancakely-paint.volia.net
# cardly.pity.volia.net
# revering-excursion.volia.net
# loom.roll.volia.net
# sailly-celebrity.volia.net
# girderless.sheen.volia.net
# ip.77.120.249.47.stat.volia.net
# tangential-design.volia.net
# quiply.taps.volia.net
# vested-ramparts.volia.net
# west-cold.volia.net
/\.volia\.net$/ 450 S25R check
このことから考えると、1回でもスパムアクセスがあったら動的IPアドレスだろうと固定IPアドレスだろうとブラックリストに登録する（どのみち、どちらであるかは通常はわからないのだから）という方法をとっていれば、OP25Bを導入済みかもしれないISPも含めて、逆引きできるすべてのISPドメインに近い数の（OP25B導入済みでホワイトリスト情報があるISPだけを除く）ブラックリスト項目ができることになるかもしれない。これはけっこう大変そうである。
言い換えれば、S25R方式を発表した2004年ころには、逆引きできるホストも6個の正規表現で蹴りまくる方法がいかに正しかったかということである。そうでなければ、導入した人がびっくりして感激するほどのスパム阻止率はとうてい得られなかったのだから。
公開ブラックリストを仮開放したが、こういう状況なので、一般規則のルール1～6をやめても十分にスパムを阻止できると保証することはできない。ルール1～6をやめる方法を今取り入れた人は、公開ブラックリストをすり抜けるスパム送信元ホストを新たに次々と発見することになるだろう。もしかしたら、その情報を提供して公開ブラックリストの充実のために協力しようという人がおられるかもしれない。そこで、ブラックリスト情報を受理する基準を説明しておく。
ブラックリスト情報の提供にあたっては、スパムを送って来た（またはスパムアクセスをして来た）ホストの逆引き名を報告していただく。原則として、以下のいずれかの条件を満たすものを受理する。
●一般規則に引っかかることから、エンドユーザー回線と推定できる。
●十六進番号を含むことから、エンドユーザー回線と推定できる。
●上記いずれの条件も満たさなくても、複数の逆引き名から、エンドユーザー回線の命名規則を推定できる（tpnet.plのようなケース）。
ただし、OP25B導入済みとわかっていて、ホワイトリスト情報があり、かつ私がスパムアクセスをほとんど観測できないドメインについては受理しない（未知の正当なメールサーバからのメールをホワイトリストなしで受信したい人の不利益になりかねないからである）。
上記いずれの条件にも当てはまらないためにメールサーバと推定されるホストのブラックリスト情報は、受理しない。自社の宣伝のためにスパムをまいた前科のある会社だとか、ポルノサイトであるとわかっている場合でも、それはローカルのブラックリストで対処していただく。そのメールサーバをブロックしたいかどうかは、サイトのポリシーによることだからである。そこからのメールを受けたいユーザーのいるサイトの運用に支障を与えることは避けたい。S25R方式において、どのサイトでも共通に使えるスパムブロック方法として提供するのは、あくまでも、エンドユーザーコンピュータと推定されるホストのブロックである。
例外的に、volia.netについては、サイトドメインを丸ごとブロックする条件を公開ブラックリストに登録している。サーバにしか見えない逆引き名のたくさんのホストからスパムアクセスが来るからである。このようなサイトは他に見つかっていない。ブラックリストファイルには、ブラックリスト作成中に見つかったvolia.net内のスパム送信元ホストをすべてコメント行で列挙している（ここまでやる必要はないとは思いつつ）。あきれるばかりである。
# absolving.argument.volia.net
# vehicleness.basin.volia.net
# beachless-vim.volia.net
# designsless.bellows.volia.net
# praise.bend.volia.net
# nodeless.billing.volia.net
# cabinetness-decrease.volia.net
# tusk.calm.volia.net
# devoted-apportioner.volia.net
# earnest-air.volia.net
# efficient-clamourer.volia.net
# feelerly-assault.volia.net
# gadfliless.ideology.volia.net
# inclined-slope.volia.net
# stencilless.management.volia.net
# merging-signature.volia.net
# dressingly.motel.volia.net
# nearer-orchard.volia.net
# pressuring.orthodoxy.volia.net
# pancakely-paint.volia.net
# cardly.pity.volia.net
# revering-excursion.volia.net
# loom.roll.volia.net
# sailly-celebrity.volia.net
# girderless.sheen.volia.net
# ip.77.120.249.47.stat.volia.net
# tangential-design.volia.net
# quiply.taps.volia.net
# vested-ramparts.volia.net
# west-cold.volia.net
/\.volia\.net$/ 450 S25R check
日曜日, 10月 31, 2010
公開ブラックリストの利用法
一般規則のルール1～6をやめるという方法を採るための代わりとなる、スパムアクセスの前科のあるドメインの公開ブラックリストを、この方法を試したい人のために仮開放しようと思う。ファイルは
http://www.gabacho-net.jp/anti-spam/black-list.txt
に仮登録してある。
この方法を使うための推奨設定は次のとおりである。なお、Q&Aのページで説明している、permit_sasl_authenticatedやreject_unlisted_recipientなどの追加指定は省略して示す。
●white-list.txt：公開ホワイトリスト
●white_list：ローカルのホワイトリスト
●black-list.txt：公開ブラックリスト
●rejections：ローカルのブラックリストと一般規則のルール0（ルール1～6はコメントアウトする）
公開ホワイトリストは、ルール1～6が有効であることを前提としたものそのままであり、その中の逆引きできるホストの指定は不要なものである。しかし、あえてそのまま使うことを推奨したい。それまで届いていたメールがブラックリストの更新で突然ブロックされることが、すでに知られたメールサーバについては避けられるからである。逆引きできないホストだけを集めた第二のホワイトリストファイルを作って提供することはしないことにした。
この方法を採れば、S25R一般規則に引っかかる未知のメールサーバであっても、逆引きできて、かつブラックリストに登録されたドメインになければ、ブロックされずに済む。ただし、以下のことに留意していただきたい。
●S25R一般規則でならブロックできたスパムがすり抜けることがありうる。
●逆引きできない未知のメールサーバがブロックされることは変わらない（スパム対策上、逆引きできないホストを一律に許可するわけにはいかないから）。
●ブラックリストの更新によって、それまでブロックされていなかったメールサーバがブロックされるようになる（ホワイトリスト登録が必要になる）ことがありうる。
S25R一般規則に引っかかる未知のメールサーバをブロックしないことを優先したいか、未知のボットネットからのスパムをS25R一般規則でブロックすることを優先したいかは、それぞれのサイトで判断していただきたい。
http://www.gabacho-net.jp/anti-spam/black-list.txt
に仮登録してある。
この方法を使うための推奨設定は次のとおりである。なお、Q&Aのページで説明している、permit_sasl_authenticatedやreject_unlisted_recipientなどの追加指定は省略して示す。
| smtpd_client_restrictions = permit_mynetworks, check_client_access regexp:/etc/postfix/white-list.txt, check_client_access regexp:/etc/postfix/white_list, check_client_access regexp:/etc/postfix/black-list.txt, check_client_access regexp:/etc/postfix/rejections |
●white-list.txt：公開ホワイトリスト
●white_list：ローカルのホワイトリスト
●black-list.txt：公開ブラックリスト
●rejections：ローカルのブラックリストと一般規則のルール0（ルール1～6はコメントアウトする）
公開ホワイトリストは、ルール1～6が有効であることを前提としたものそのままであり、その中の逆引きできるホストの指定は不要なものである。しかし、あえてそのまま使うことを推奨したい。それまで届いていたメールがブラックリストの更新で突然ブロックされることが、すでに知られたメールサーバについては避けられるからである。逆引きできないホストだけを集めた第二のホワイトリストファイルを作って提供することはしないことにした。
この方法を採れば、S25R一般規則に引っかかる未知のメールサーバであっても、逆引きできて、かつブラックリストに登録されたドメインになければ、ブロックされずに済む。ただし、以下のことに留意していただきたい。
●S25R一般規則でならブロックできたスパムがすり抜けることがありうる。
●逆引きできない未知のメールサーバがブロックされることは変わらない（スパム対策上、逆引きできないホストを一律に許可するわけにはいかないから）。
●ブラックリストの更新によって、それまでブロックされていなかったメールサーバがブロックされるようになる（ホワイトリスト登録が必要になる）ことがありうる。
S25R一般規則に引っかかる未知のメールサーバをブロックしないことを優先したいか、未知のボットネットからのスパムをS25R一般規則でブロックすることを優先したいかは、それぞれのサイトで判断していただきたい。
ブラックリストに登録しない条件
一般規則のルール1～6をやめるというアイデアを思い付いた後、うすうす気になっていたことがあった。固定IPアドレスからのスパムアクセスである。2007年8月7日「スタティックIPアドレス」で述べたように、固定IPアドレスからのスパムアクセスは、無視できるほど少なくはなさそうだからである。
このアイデアがいけるかもしれないと思ったのは、OP25Bが国内に普及し、世界にも広まりつつあると見られるからである。OP25Bは、動的IPアドレスのエンドユーザー回線から他ネットワークへのポート25をブロックする。しかし、固定IPアドレスからのポート25はブロックしない（もちろん、そんなことをされては、メールサーバを運用したいユーザーが困る）。固定IPアドレスで接続されたLANにもエンドユーザーコンピュータがつながることはある。それがウィルスに侵されてボット化すれば、そこからスパムアクセスが来る。
それが本当に来た。国内の固定IPアドレスなので、ユーザーが特定されるのを避けるために、逆引きFQDNの数字の部分を伏せ字で示す。
p****-ipbffx**marunouchi.tokyo.ocn.ne.jp
OCNは大手ISPで、もちろんOP25Bを導入している。そのOCNからのスパムアクセスであること、「fx」という綴りが「fixed」の意味と想像されること、協力者から寄せられたホワイトリスト情報に同様の逆引き名があることから、固定IPアドレスであることは間違いない。
私は、一般規則をやめる代わりのブラックリストの作成にあたって、1回でもスパムアクセスがあったドメインは（たとえ「static」の綴りを含んでも）ブラックリストに登録してきた。しかし、OCNをブラックリストに登録するわけにはいかない。OCNのドメイン内のホワイトリスト情報はいくつか寄せられており、ホワイトリストに未登録のメールサーバも潜在していると考えられるからである。
このことから、ブラックリスト登録に手心を加える基準というものをはっきりさせる必要があると考えた。今考えている、ブラックリストに登録しない、あるいは登録解除の要請に応じるための（すべて満たすべき）条件は次のとおりである。
●OP25Bを導入しているISPであること。
●そのISPの固定IPアドレスからのスパムアクセスがめったにないこと。目安として、私のサイトでの調査では、過去1ヶ月以内にスパムアクセスをして来たホストが高々1個しかないこと。
●そのISP内の、S25Rに引っかかる固定IPアドレスのメールサーバが公開ホワイトリストに登録されているか、または新たに報告されること。
ブラックリストに登録しているドメインのほとんどは外国のものなので、国内のサイトでは、ブラックリストによる偽陽性判定は起こりにくいと思う。しかし、その可能性はある。もし「我々のサイトではこのドメインからメールを受信するので、ブラックリストから除いてほしい」という要請があったら、上記の条件に基づいて受理する考えである。
なお、ブラックリストで偽陽性判定されるメールサーバは具体的に報告していただき、通常のホワイトリスト情報の提供と同じ扱いで公開ホワイトリストに掲載する。それはもちろん、一般規則をやめる方法を採用しないS25Rユーザーのためである。
このアイデアがいけるかもしれないと思ったのは、OP25Bが国内に普及し、世界にも広まりつつあると見られるからである。OP25Bは、動的IPアドレスのエンドユーザー回線から他ネットワークへのポート25をブロックする。しかし、固定IPアドレスからのポート25はブロックしない（もちろん、そんなことをされては、メールサーバを運用したいユーザーが困る）。固定IPアドレスで接続されたLANにもエンドユーザーコンピュータがつながることはある。それがウィルスに侵されてボット化すれば、そこからスパムアクセスが来る。
それが本当に来た。国内の固定IPアドレスなので、ユーザーが特定されるのを避けるために、逆引きFQDNの数字の部分を伏せ字で示す。
p****-ipbffx**marunouchi.tokyo.ocn.ne.jp
OCNは大手ISPで、もちろんOP25Bを導入している。そのOCNからのスパムアクセスであること、「fx」という綴りが「fixed」の意味と想像されること、協力者から寄せられたホワイトリスト情報に同様の逆引き名があることから、固定IPアドレスであることは間違いない。
私は、一般規則をやめる代わりのブラックリストの作成にあたって、1回でもスパムアクセスがあったドメインは（たとえ「static」の綴りを含んでも）ブラックリストに登録してきた。しかし、OCNをブラックリストに登録するわけにはいかない。OCNのドメイン内のホワイトリスト情報はいくつか寄せられており、ホワイトリストに未登録のメールサーバも潜在していると考えられるからである。
このことから、ブラックリスト登録に手心を加える基準というものをはっきりさせる必要があると考えた。今考えている、ブラックリストに登録しない、あるいは登録解除の要請に応じるための（すべて満たすべき）条件は次のとおりである。
●OP25Bを導入しているISPであること。
●そのISPの固定IPアドレスからのスパムアクセスがめったにないこと。目安として、私のサイトでの調査では、過去1ヶ月以内にスパムアクセスをして来たホストが高々1個しかないこと。
●そのISP内の、S25Rに引っかかる固定IPアドレスのメールサーバが公開ホワイトリストに登録されているか、または新たに報告されること。
ブラックリストに登録しているドメインのほとんどは外国のものなので、国内のサイトでは、ブラックリストによる偽陽性判定は起こりにくいと思う。しかし、その可能性はある。もし「我々のサイトではこのドメインからメールを受信するので、ブラックリストから除いてほしい」という要請があったら、上記の条件に基づいて受理する考えである。
なお、ブラックリストで偽陽性判定されるメールサーバは具体的に報告していただき、通常のホワイトリスト情報の提供と同じ扱いで公開ホワイトリストに掲載する。それはもちろん、一般規則をやめる方法を採用しないS25Rユーザーのためである。
月曜日, 10月 25, 2010
ブラックリストの作成が終わらない
長いことブログをほったらかしてすみません。
7月8日に、一般規則のルール1～6をやめてはどうかというアイデアを述べた。代わりに、スパムアクセスの前科のあるドメインについてのみ一般規則相当の拒否（すなわち、そのドメイン内のエンドユーザーコンピュータと推定されるホストに対する選択的拒否）を行う条件をブラックリストに登録する。これによるメリットは、まだまだ潜在していると思われる、固定IPアドレス1個割り当てのメールサーバ（ISPが割り当てる連番入りの逆引き名が多い）を引っかけにくくなることである。今は国内にはOP25Bが普及したので、jpドメインからのスパムアクセスは非常に少なくなっている。だから、一般規則をやめる方法もそろそろ可能になってきていると思う。S25R方式を発表した2004年ころは、OP25Bがほとんど行われていなかったので、とてもそうはいかなかった。
この方法は、特に国内からのメールの偽陽性判定を避けたいと思っている人には歓迎されるかもしれない。ただ、S25R方式が広く支持された理由は、何と言っても、一般規則によるスパム阻止率の高さである。一般規則をやめる方法を取り入れることでスパム阻止率が目立って低下しては、がっかりさせてしまうだろう。だから、この方法を提案する前に十分なブラックリストを用意しておく必要がある。そこで、私のサイトへ来るスパムアクセスを観測しながら、3ヶ月にわたってブラックリストの作成を続けている。
私のサイトへのスパムアクセスの宛先は、私の個人アドレス「deo」や公開アドレス「webmaster」ばかりではない。わざとスパマーに拾わせた「otori1」などのおとりアドレス、ISO-2022-JP（通称：JIS）で符号化したウェブページから間違って拾い出された「bwebmaster」のようなアドレス（先行する文字セット切り替えのエスケープシーケンスの末尾が「B」と同じ符号であるため、先頭に「b」が付いている）、それらを改変した「ewotori1」、「sneovbwebmaster」のようなわけのわからないアドレスなど数多い。だから、ほどなくブラックリストはほぼ十分なものになるだろうと思っていた。
しかし、見通しが甘かった。項目の増加はそろそろ頭打ちになるかなと思ってからかなり（2ヶ月ほど？）たつのだが、今なおほぼ毎日1～3件くらいずつ増え続けている。10月24日現在、ブラックリストの登録ドメインは407件である。これでは、一般規則をやめる方法を提案するのは時期尚早である。
もしかしたら、協力者を募ればブラックリストは早く充足するだろうと思う人がおられるかもしれない。しかし、それは難しい。小規模サイトでも大規模サイトでも、毎日たくさんのスパム送信元ホストが見つかるからである。そこからブラックリストに未登録のサイトドメインのものを抽出するのは面倒な作業であり、協力者に要請できるものではない。誤ってブロックされる正当なメールサーバはぽつりぽつりとしか見つからないので、ホワイトリスト情報を提供いただくことは容易だが、ブラックリスト情報はそうはいかないのである。
だから、今のところ私は一人でブラックリストを作成している。それでも、どのサイトでも十分に役立つブラックリストはいずれできると思っている。スパマーはたくさんのボットネットを利用するので、一サイトで受けるスパムに限ってもその送信元ホストは限定されないからである。一方、一サイトに宛てた正当なメールの送信元は限定されるので、どのサイトでも十分に役立つホワイトリストは、多くの人の協力がなければ作れない。そこがブラックリストとホワイトリストの違いである。
なお、作成中のブラックリストは、現在、暫定的に
http://www.gabacho-net.jp/anti-spam/black-list.txt
に置いている。項目の並び順は、上位ドメインのアルファベット順である。
参考までに、jpドメイン内のサイトの登録は以下の5件である。
# 58-147-237-170.ap-w01.canvas.ne.jp
/^[0-9].*\.canvas\.ne\.jp$/ 450 S25R check
# 220-213-107-155.pool.fctv.ne.jp
/^[0-9].*\.fctv\.ne\.jp$/ 450 S25R check
# dynamic-114-69-114-170.vips.gol.ne.jp
/^[^.]*[0-9]-[0-9].*\.gol\.ne\.jp$/ 450 S25R check
# dae62d20.tcat.ne.jp
/^[0-9a-f]{8}\.tcat\.ne\.jp$/ 450 S25R check
# pc74085.ztv.ne.jp
/^[^.]*[0-9]{5}.*\.ztv\.ne\.jp$/ 450 S25R check
7月8日に、一般規則のルール1～6をやめてはどうかというアイデアを述べた。代わりに、スパムアクセスの前科のあるドメインについてのみ一般規則相当の拒否（すなわち、そのドメイン内のエンドユーザーコンピュータと推定されるホストに対する選択的拒否）を行う条件をブラックリストに登録する。これによるメリットは、まだまだ潜在していると思われる、固定IPアドレス1個割り当てのメールサーバ（ISPが割り当てる連番入りの逆引き名が多い）を引っかけにくくなることである。今は国内にはOP25Bが普及したので、jpドメインからのスパムアクセスは非常に少なくなっている。だから、一般規則をやめる方法もそろそろ可能になってきていると思う。S25R方式を発表した2004年ころは、OP25Bがほとんど行われていなかったので、とてもそうはいかなかった。
この方法は、特に国内からのメールの偽陽性判定を避けたいと思っている人には歓迎されるかもしれない。ただ、S25R方式が広く支持された理由は、何と言っても、一般規則によるスパム阻止率の高さである。一般規則をやめる方法を取り入れることでスパム阻止率が目立って低下しては、がっかりさせてしまうだろう。だから、この方法を提案する前に十分なブラックリストを用意しておく必要がある。そこで、私のサイトへ来るスパムアクセスを観測しながら、3ヶ月にわたってブラックリストの作成を続けている。
私のサイトへのスパムアクセスの宛先は、私の個人アドレス「deo」や公開アドレス「webmaster」ばかりではない。わざとスパマーに拾わせた「otori1」などのおとりアドレス、ISO-2022-JP（通称：JIS）で符号化したウェブページから間違って拾い出された「bwebmaster」のようなアドレス（先行する文字セット切り替えのエスケープシーケンスの末尾が「B」と同じ符号であるため、先頭に「b」が付いている）、それらを改変した「ewotori1」、「sneovbwebmaster」のようなわけのわからないアドレスなど数多い。だから、ほどなくブラックリストはほぼ十分なものになるだろうと思っていた。
しかし、見通しが甘かった。項目の増加はそろそろ頭打ちになるかなと思ってからかなり（2ヶ月ほど？）たつのだが、今なおほぼ毎日1～3件くらいずつ増え続けている。10月24日現在、ブラックリストの登録ドメインは407件である。これでは、一般規則をやめる方法を提案するのは時期尚早である。
もしかしたら、協力者を募ればブラックリストは早く充足するだろうと思う人がおられるかもしれない。しかし、それは難しい。小規模サイトでも大規模サイトでも、毎日たくさんのスパム送信元ホストが見つかるからである。そこからブラックリストに未登録のサイトドメインのものを抽出するのは面倒な作業であり、協力者に要請できるものではない。誤ってブロックされる正当なメールサーバはぽつりぽつりとしか見つからないので、ホワイトリスト情報を提供いただくことは容易だが、ブラックリスト情報はそうはいかないのである。
だから、今のところ私は一人でブラックリストを作成している。それでも、どのサイトでも十分に役立つブラックリストはいずれできると思っている。スパマーはたくさんのボットネットを利用するので、一サイトで受けるスパムに限ってもその送信元ホストは限定されないからである。一方、一サイトに宛てた正当なメールの送信元は限定されるので、どのサイトでも十分に役立つホワイトリストは、多くの人の協力がなければ作れない。そこがブラックリストとホワイトリストの違いである。
なお、作成中のブラックリストは、現在、暫定的に
http://www.gabacho-net.jp/anti-spam/black-list.txt
に置いている。項目の並び順は、上位ドメインのアルファベット順である。
参考までに、jpドメイン内のサイトの登録は以下の5件である。
# 58-147-237-170.ap-w01.canvas.ne.jp
/^[0-9].*\.canvas\.ne\.jp$/ 450 S25R check
# 220-213-107-155.pool.fctv.ne.jp
/^[0-9].*\.fctv\.ne\.jp$/ 450 S25R check
# dynamic-114-69-114-170.vips.gol.ne.jp
/^[^.]*[0-9]-[0-9].*\.gol\.ne\.jp$/ 450 S25R check
# dae62d20.tcat.ne.jp
/^[0-9a-f]{8}\.tcat\.ne\.jp$/ 450 S25R check
# pc74085.ztv.ne.jp
/^[^.]*[0-9]{5}.*\.ztv\.ne\.jp$/ 450 S25R check
土曜日, 7月 31, 2010
rejhost.plの改良を反映
7月19日「ツールをいくつか」で紹介したツールのうち、拒否されたホストをメールログから抽出するrejhost.plは、メールログをcatコマンドとパイプでSTDIN（標準入力）に流し込むことを前提とした作りだった。7月23日に、rejhost.plがメールログファイルを直接入力するようにする改良を紹介した。絶対にこの方が便利なので、この改良を7月19日の記事に反映した。7月23日の記事は削除した。
月曜日, 7月 19, 2010
ツールをいくつか
前回、ルール0以外の一般規則をやめることによって偽陽性判定を減らし、スパムアクセスの前科があるドメインのエンドユーザー回線と推定されるホストをブラックリストで阻止する案を述べた。この方法をとる準備のために、現在S25Rやuser unknownなどでブロックされているホストやドメイン名を抽出したりFQDNでソーティングしたりするための補助ツールをいくつか作った。Perl記述で、シェルコマンドのパイプと組み合わせることを前提に機能を単純化している。よろしかったらお使いください。
1. rejhost.pl (Extract rejected hosts)
機能 引数で指定されたPostfixのログファイルから、拒否されたホストのFQDNとIPアドレスを抽出する。引数を省略したら、/var/logディレクトリの下の、過去と最新の全メールログファイルを入力する。ディレクトリを省略したファイル名を指定したら（「/」がないとき）、デフォルトのディレクトリを/var/logとする。
出力例
166-71-95-178.pool.ukrtel.net[178.95.71.166]
使用例
rejhost.pl # /var/logの下のmaillog.4～maillog.1とmaillogから入力
rejhost.pl maillog.1 maillog # /var/logの下のmaillog.1とmaillogから入力
rejhost.pl ~/maillog.save # ~/maillog.saveから入力
プログラムコード
デフォルトのディレクトリとデフォルトのメールログファイルを変更したい場合は、適当に手直ししてください。Perlプログラミングの経験のない人でも直し方はおわかりになると思う。
2. revfqdn.pl (Reverse FQDNs)
機能 sortコマンドを使ってFQDNを上位ドメインの文字コード順にソーティングするために、FQDNのラベルを逆順に並べる。結果をもう一度これに通すと元のFQDNに戻る。
変換例
166-71-95-178.pool.ukrtel.net[178.95.71.166] → net.ukrtel.pool.166-71-95-178[178.95.71.166]
使用例
（拒否されたホストを上位ドメインの文字コード順にソーティングし、重複を削除する。――同じサイトドメイン内のホストは連続して並ぶことになる。）
rejhost.pl | revfqdn.pl | sort -f | uniq | revfqdn.pl
プログラムコード
3. sitedom.pl (Extract site domain names)
機能 FQDNを入力してサイトドメイン名を抽出する。トップレベルドメインが英字2文字（国ドメイン）で、第2レベルがcom、net、org、gov、edu、または英字2文字ならば第2レベルを属性ラベルと推定し（これは確かではないが）、第3レベルをサイトドメインとみなして、上位3階層を抽出する。それ以外の場合は上位2階層を抽出する。2階層以上でない名前（unknownを含む）は出力されない。
変換例
189-68-193-53.dsl.telesp.net.br[189.68.193.53] → telesp.net.br
vc-41-16-75-82.umts.vodacom.co.za[41.16.75.82] → vodacom.co.za
166-71-95-178.pool.ukrtel.net[178.95.71.166] → ukrtel.net
bl17-17-97.dsl.telepac.pt[188.82.17.97] → telepac.pt
使用例
（拒否されたホストのサイトドメインの数を数える。）
rejhost.pl | sitedom.pl | sort | uniq | wc
プログラムコード
1. rejhost.pl (Extract rejected hosts)
機能 引数で指定されたPostfixのログファイルから、拒否されたホストのFQDNとIPアドレスを抽出する。引数を省略したら、/var/logディレクトリの下の、過去と最新の全メールログファイルを入力する。ディレクトリを省略したファイル名を指定したら（「/」がないとき）、デフォルトのディレクトリを/var/logとする。
出力例
166-71-95-178.pool.ukrtel.net[178.95.71.166]
使用例
rejhost.pl # /var/logの下のmaillog.4～maillog.1とmaillogから入力
rejhost.pl maillog.1 maillog # /var/logの下のmaillog.1とmaillogから入力
rejhost.pl ~/maillog.save # ~/maillog.saveから入力
プログラムコード
| #!/usr/local/bin/perl $dir = "/var/log"; if (@ARGV == ()) { @ARGV = ("maillog.4", "maillog.3", "maillog.2", "maillog.1", "maillog"); } foreach $file (@ARGV) { unless ($file =~ /\//) { $file = $dir . "/" . $file; } } while(<>) { if (/reject:.* from ([^]]+\])/) { print "$1\n"; } } |
デフォルトのディレクトリとデフォルトのメールログファイルを変更したい場合は、適当に手直ししてください。Perlプログラミングの経験のない人でも直し方はおわかりになると思う。
2. revfqdn.pl (Reverse FQDNs)
機能 sortコマンドを使ってFQDNを上位ドメインの文字コード順にソーティングするために、FQDNのラベルを逆順に並べる。結果をもう一度これに通すと元のFQDNに戻る。
変換例
166-71-95-178.pool.ukrtel.net[178.95.71.166] → net.ukrtel.pool.166-71-95-178[178.95.71.166]
使用例
（拒否されたホストを上位ドメインの文字コード順にソーティングし、重複を削除する。――同じサイトドメイン内のホストは連続して並ぶことになる。）
rejhost.pl | revfqdn.pl | sort -f | uniq | revfqdn.pl
プログラムコード
| #!/usr/local/bin/perl while (<STDIN>) { chop; $_ =~ /^([a-z0-9._-]+)(.*)$/i; @labels = split(/\./, $1); @labels = reverse(@labels); print join(".", @labels), $2, "\n"; } |
3. sitedom.pl (Extract site domain names)
機能 FQDNを入力してサイトドメイン名を抽出する。トップレベルドメインが英字2文字（国ドメイン）で、第2レベルがcom、net、org、gov、edu、または英字2文字ならば第2レベルを属性ラベルと推定し（これは確かではないが）、第3レベルをサイトドメインとみなして、上位3階層を抽出する。それ以外の場合は上位2階層を抽出する。2階層以上でない名前（unknownを含む）は出力されない。
変換例
189-68-193-53.dsl.telesp.net.br[189.68.193.53] → telesp.net.br
vc-41-16-75-82.umts.vodacom.co.za[41.16.75.82] → vodacom.co.za
166-71-95-178.pool.ukrtel.net[178.95.71.166] → ukrtel.net
bl17-17-97.dsl.telepac.pt[188.82.17.97] → telepac.pt
使用例
（拒否されたホストのサイトドメインの数を数える。）
rejhost.pl | sitedom.pl | sort | uniq | wc
プログラムコード
| #!/usr/local/bin/perl while (<STDIN>) { $_ =~ /^(([a-z0-9_-]+\.)+[a-z0-9_-]+)/i; if ($1 =~ /(^|\.)([a-z0-9_-]+\.(((com|net|org|gov|edu|[a-z]{2})\.)?[a-z]{2}|[a-z0-9_-]+))$/i) { print "$2\n"; } } |
木曜日, 7月 08, 2010
一般規則をやめるというのはどう？
6月27日「常連さんからのスパムが減った」で、論文中のブラックリスト例に掲載したドメインからのスパムアクセスが非常に少なくなったことを述べた。また、6月6日から7月8日までの約1ヶ月のログから抽出した不正メール送信元ホストは2243個で、2006年11月には7245個だったのに比べて減っている。これらのことから、OP25Bが世界で普及しつつあることが推測される。国内では、ご存じのとおりOP25Bが普及したので、jpドメインからの不正メールアクセスは、皆無ではないもののまれにしか来ないようになっている。
このような状況になったからには、ルール0以外の一般規則をやめて、エンドユーザー回線から不正メールを送って来るドメインのブラックリストだけでブロックする方法も運用可能ではないか。そうすれば、IPアドレス1個割り当てのメールサーバや、多数のサーバを持つ事業者の連番入りホスト名など、一般規則で偽陽性判定されるホストは、（ドメインブラックリストにない限り）逆引きできさえすれば偽陽性判定されなくなる。
そう考えて、2243個の不正メール送信元ホストのうち、unknownのホストと、サーバと思われるホストを除いた616個に基づいて、何件のドメインブラックリストが必要になるかを調べてみた。その結果、232件になった。もっと観測すればこれ以外のドメインが発見されるかもしれないが、いつまでも増え続けることはないだろうと思う。公開ホワイトリストの登録数が現在1297件になっていることを思えば、200～300件程度のドメインブラックリストのメンテナンスは大した手間ではないだろう。
一般規則を廃止すれば、ホワイトリストに登録するのは、逆引きできないホストだけで済むようになる。現在、公開ホワイトリストの中で逆引きできないホストの登録は726件。つまり、ホワイトリストは半分強の大きさに減ることになる。そして、逆引きできさえすれば（ドメインブラックリストにない限り）遅延なく受信するので、逆引き名がS25Rに引っかかっていたホストの持ち主が不満を持つこともなくなる。
一般規則をやめるとしても、そのノウハウは、不正メールを送って来るドメインの中のエンドユーザー回線と思われるホストだけを選択的に蹴るようにするために役立つ。いくつか例を挙げる。
# 114-33-77-76.HINET-IP.hinet.net
/^[0-9].*\.hinet\.net$/ 450 S25R check, be patient
# host125-94-static.14-79-b.business.telecomitalia.it
/^[^.]*[0-9]-[0-9].*\.telecomitalia\.it$/ 450 S25R check, be patient
# S010600112f492db3.cg.shawcable.net
/^[^.]*[0-9]{5}.*\.shawcable\.net$/ 450 S25R check, be patient
もっとも、一般規則をやめる設定方法を提案したとしても、乗り換えてくれる人は少ないかもしれない。一般規則は、OP25Bがほとんど導入されていなかった時期から、スパマーとのいたちごっこをいきなり終わらせるほどの効果を持ち、その後大幅な見直しが必要なかった。S25R方式を導入した人たちの間では、この拒否条件がスタンダードになっている。偽陽性判定を起こすとはいえ、公開ホワイトリストが協力者のおかげで充実したため、国内サイトに関する限り、偽陽性判定が起こる頻度は少なくなった。だから、あえて設定を変更する動機付けに欠ける。ただ、これからS25R方式を導入するサイトや外国のサイトでは、一般規則を使わない設定方法を採用する人がいるかもしれない。
# よろしかったらご意見ください。
このような状況になったからには、ルール0以外の一般規則をやめて、エンドユーザー回線から不正メールを送って来るドメインのブラックリストだけでブロックする方法も運用可能ではないか。そうすれば、IPアドレス1個割り当てのメールサーバや、多数のサーバを持つ事業者の連番入りホスト名など、一般規則で偽陽性判定されるホストは、（ドメインブラックリストにない限り）逆引きできさえすれば偽陽性判定されなくなる。
そう考えて、2243個の不正メール送信元ホストのうち、unknownのホストと、サーバと思われるホストを除いた616個に基づいて、何件のドメインブラックリストが必要になるかを調べてみた。その結果、232件になった。もっと観測すればこれ以外のドメインが発見されるかもしれないが、いつまでも増え続けることはないだろうと思う。公開ホワイトリストの登録数が現在1297件になっていることを思えば、200～300件程度のドメインブラックリストのメンテナンスは大した手間ではないだろう。
一般規則を廃止すれば、ホワイトリストに登録するのは、逆引きできないホストだけで済むようになる。現在、公開ホワイトリストの中で逆引きできないホストの登録は726件。つまり、ホワイトリストは半分強の大きさに減ることになる。そして、逆引きできさえすれば（ドメインブラックリストにない限り）遅延なく受信するので、逆引き名がS25Rに引っかかっていたホストの持ち主が不満を持つこともなくなる。
一般規則をやめるとしても、そのノウハウは、不正メールを送って来るドメインの中のエンドユーザー回線と思われるホストだけを選択的に蹴るようにするために役立つ。いくつか例を挙げる。
# 114-33-77-76.HINET-IP.hinet.net
/^[0-9].*\.hinet\.net$/ 450 S25R check, be patient
# host125-94-static.14-79-b.business.telecomitalia.it
/^[^.]*[0-9]-[0-9].*\.telecomitalia\.it$/ 450 S25R check, be patient
# S010600112f492db3.cg.shawcable.net
/^[^.]*[0-9]{5}.*\.shawcable\.net$/ 450 S25R check, be patient
もっとも、一般規則をやめる設定方法を提案したとしても、乗り換えてくれる人は少ないかもしれない。一般規則は、OP25Bがほとんど導入されていなかった時期から、スパマーとのいたちごっこをいきなり終わらせるほどの効果を持ち、その後大幅な見直しが必要なかった。S25R方式を導入した人たちの間では、この拒否条件がスタンダードになっている。偽陽性判定を起こすとはいえ、公開ホワイトリストが協力者のおかげで充実したため、国内サイトに関する限り、偽陽性判定が起こる頻度は少なくなった。だから、あえて設定を変更する動機付けに欠ける。ただ、これからS25R方式を導入するサイトや外国のサイトでは、一般規則を使わない設定方法を採用する人がいるかもしれない。
# よろしかったらご意見ください。
火曜日, 6月 29, 2010
DNSBLとの違いの説明を修正
Q&Aのページで、S25R方式とDNSBLとの違いを次のように説明していた。
前回述べたとおり、Q/A2-6でSpamCopの併用方法を説明したので、A1-6がDNSBLに対する否定的な評価と見えるのは違和感を起こさせると思った。
そこで、A1-6を以下のように書き直した。DNSBLのスパム阻止率がS25R方式ほどでないことを明言するとともに、DNSBLも偽陽性対策をすれば使い物になるとわかるようにした。
| Q1-6. DNSBL（Domain Name System Blackhole List）との違いは何ですか？ A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。あなたのメールサーバがDNSBLに頼り切るとすれば、あなたのメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。時にDNSBLは、間違って、あるいは意図的に正当なメールサーバをリストに載せるので、あなたのメールサーバは正当なメールを失うかもしれません。 S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。偽陽性判定はS25Rシステム管理者によってコントロールすることができるので、注意深い運用のもとではメールサーバは正当なメールを失いません。 |
前回述べたとおり、Q/A2-6でSpamCopの併用方法を説明したので、A1-6がDNSBLに対する否定的な評価と見えるのは違和感を起こさせると思った。
そこで、A1-6を以下のように書き直した。DNSBLのスパム阻止率がS25R方式ほどでないことを明言するとともに、DNSBLも偽陽性対策をすれば使い物になるとわかるようにした。
| A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。DNSBLに頼るメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。そのため、DNSBLのスパム阻止率はS25R方式ほど高くありません。一方、S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。ただし、間違って拒否される正当なメールサーバを許可するためのホワイトリストが必須です。 ところで、DNSBLも、時に間違って、あるいは意図的に正当なメールサーバをリストに載せるので、偽陽性判定を起こすことがあります。正当なメールを失わないためには、DNSBLに引っかかるホストには応答コード「450」（Postfixのデフォルトの「554」ではなく）を返し、送信を再試行するホストをホワイトリスト登録するようにすべきです（ほとんどのスパムアクセスは再試行しません）。 |
日曜日, 6月 27, 2010
Q&AにSpamCopの併用方法を説明
2009年4月にSpamCopの併用を設定してみたところ、かなり役に立つことがわかった。最近でも役に立っており、5月30日から6月27日までの期間にSpamCopのおかげでブロックできたスパム送信元は以下の8個であった。
eth-66.130-homell.natm.ru
dynamic.casa-217-243-12-196.wanamaroc.com
zaxnag.nline.ru
mecanica.ucv.ro
mx1.to-c.biz
shvernik.rinet.ru
krasn23b-slav.skif.com.ua
Msq1.gatchina.ru
これらはいずれも、応答コード「450」に対してリトライしなかった。
ここまで役に立つノウハウをこのブログの読者にしか開示しないのはやはりもったいないと思ったので、Q&AのページにQ/A2-6として掲載した。
eth-66.130-homell.natm.ru
dynamic.casa-217-243-12-196.wanamaroc.com
zaxnag.nline.ru
mecanica.ucv.ro
mx1.to-c.biz
shvernik.rinet.ru
krasn23b-slav.skif.com.ua
Msq1.gatchina.ru
これらはいずれも、応答コード「450」に対してリトライしなかった。
ここまで役に立つノウハウをこのブログの読者にしか開示しないのはやはりもったいないと思ったので、Q&AのページにQ/A2-6として掲載した。
| Q2-6. S25RにDNSBLを併用することは効果がありますか？ A2-6. はい。SpamCopはかなり有用であることがわかっています。私はS25RにSpamCopを併用して99.5%の阻止率を得たことがあり、その時、S25Rだけによる阻止率は99.2%でした。ただし、DNSBLは偽陽性判定を起こすかもしれないので、DNSBLに引っかかったホストには応答コード「450」を返すようにすべきです。/etc/postfix/main.cfファイルに以下の太字の行を追加してください。
拒絶ログソーティングスクリプトを使ってDNSBLによる偽陽性判定を見つけるには、スクリプトの中の
という行を次のように書き換えてください。
|
常連さんからのスパムが減った
論文に記載している設定方法で、ブラックリストとしていくつかのドメインを示している。エンドユーザー回線の逆引き名が一般規則に引っかからない（または引っかからないことがある）ドメインで、論文公開当時やその後に有用だった拒否条件を掲載している。
しかし、これらのドメインからの不正メールアクセスは、最近少なくなっている。5月30日から6月27日10:40までに不正メールを送り込もうとしたホストの数は、各ドメインについて以下のとおりである。
# pr86.internetdsl.tpnet.pl
# fq217.neoplus.adsl.tpnet.pl
# pa148.braniewo.sdi.tpnet.pl
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain check, be patient
2個。
# user-0cetcbr.cable.mindspring.com
# user-vc8fldi.biz.mindspring.com
/^user.+\.mindspring\.com$/ 450 domain check, be patient
なし。
# c9531ecc.virtua.com.br (hexadecimal used)
# c9066a60.static.spo.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.(.+\.)?virtua\.com\.br$/ 450 domain check, be patient
1個。
# catv-5984bdee.catv.broadband.hu (hexadecimal used)
/\.catv\.broadband\.hu$/ 450 domain check, be patient
なし。
# Edc3e.e.pppool.de
# BAA1408.baa.pppool.de
/[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ 450 domain check, be patient
なし。
# pD9EB80CB.dip0.t-ipconnect.de (hexadecimal used)
/\.dip[0-9]+\.t-ipconnect\.de$/ 450 domain check, be patient
なし。
# pD9E799A1.dip.t-dialin.net (hexadecimal used)
/\.dip\.t-dialin\.net$/ 450 domain check, be patient
2個。
# ool-43511bdc.dyn.optonline.net (hexadecimal used)
/\.dyn\.optonline\.net$/ 450 domain check, be patient
なし。
# rt-dkz-1699.adsl.wanadoo.nl
# c3eea5738.cable.wanadoo.nl (hexadecimal used)
/\.(adsl|cable)\.wanadoo\.nl$/ 450 domain check, be patient
なし。
# ACBBD419.ipt.aol.com (hexadecimal used)
/\.ipt\.aol\.com$/ 450 domain check, be patient
なし。
これを見ると、多くのドメインでOP25Bが導入されるようになったと推測される。わずかに不正メールアクセスが来るドメインは、OP25Bの設定が完全には終わっていないか、スタティックIPアドレスなのでOP25Bの対象外かのどちらかだろう。
ここに至っては、不正メールアクセスがまったく来なくなったドメインはブラックリストの実例から除外してもよいだろう。ただ、ブラックリストの実例は、正規表現に慣れていない人が真似る手本として役立っていると思うので、どうするかはもうしばらく考えたい。
一方、エンドユーザー回線の逆引き名が一般規則に引っかかるドメインで、10個以上のホストから不正メールアクセスがあったものは以下のとおりである。1個のホストを代表させて示す。
1-89-112-92.pool.ukrtel.net
60個。
111-240-240-32.dynamic.hinet.net
45個。
host115-93-dynamic.59-82-r.retail.telecomitalia.it
13個。
200-204-159-61.dsl.telesp.net.br
10個。
adsl-104-22-192-81.adsl.iam.net.ma
10個。
ウクライナのvolia.netは、一般規則に引っかからない多くのホストから不正メールアクセスを出している。ホストは10個あった。
beachless-vim.volia.net
coping.linoleum.volia.net
designsless.bellows.volia.net
exampleless-gear.volia.net
inclined-slope.volia.net
loom.roll.volia.net
pat.descender.volia.net
revering-excursion.volia.net
tangential-design.volia.net
vested-ramparts.volia.net
私は、2007年7月からvolia.net全体をブラックリスト入りさせている。これは今なおはずせないようである。
/\.volia\.net$/ 450 domain check, be patient
しかし、これらのドメインからの不正メールアクセスは、最近少なくなっている。5月30日から6月27日10:40までに不正メールを送り込もうとしたホストの数は、各ドメインについて以下のとおりである。
# pr86.internetdsl.tpnet.pl
# fq217.neoplus.adsl.tpnet.pl
# pa148.braniewo.sdi.tpnet.pl
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain check, be patient
2個。
# user-0cetcbr.cable.mindspring.com
# user-vc8fldi.biz.mindspring.com
/^user.+\.mindspring\.com$/ 450 domain check, be patient
なし。
# c9531ecc.virtua.com.br (hexadecimal used)
# c9066a60.static.spo.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.(.+\.)?virtua\.com\.br$/ 450 domain check, be patient
1個。
# catv-5984bdee.catv.broadband.hu (hexadecimal used)
/\.catv\.broadband\.hu$/ 450 domain check, be patient
なし。
# Edc3e.e.pppool.de
# BAA1408.baa.pppool.de
/[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ 450 domain check, be patient
なし。
# pD9EB80CB.dip0.t-ipconnect.de (hexadecimal used)
/\.dip[0-9]+\.t-ipconnect\.de$/ 450 domain check, be patient
なし。
# pD9E799A1.dip.t-dialin.net (hexadecimal used)
/\.dip\.t-dialin\.net$/ 450 domain check, be patient
2個。
# ool-43511bdc.dyn.optonline.net (hexadecimal used)
/\.dyn\.optonline\.net$/ 450 domain check, be patient
なし。
# rt-dkz-1699.adsl.wanadoo.nl
# c3eea5738.cable.wanadoo.nl (hexadecimal used)
/\.(adsl|cable)\.wanadoo\.nl$/ 450 domain check, be patient
なし。
# ACBBD419.ipt.aol.com (hexadecimal used)
/\.ipt\.aol\.com$/ 450 domain check, be patient
なし。
これを見ると、多くのドメインでOP25Bが導入されるようになったと推測される。わずかに不正メールアクセスが来るドメインは、OP25Bの設定が完全には終わっていないか、スタティックIPアドレスなのでOP25Bの対象外かのどちらかだろう。
ここに至っては、不正メールアクセスがまったく来なくなったドメインはブラックリストの実例から除外してもよいだろう。ただ、ブラックリストの実例は、正規表現に慣れていない人が真似る手本として役立っていると思うので、どうするかはもうしばらく考えたい。
一方、エンドユーザー回線の逆引き名が一般規則に引っかかるドメインで、10個以上のホストから不正メールアクセスがあったものは以下のとおりである。1個のホストを代表させて示す。
1-89-112-92.pool.ukrtel.net
60個。
111-240-240-32.dynamic.hinet.net
45個。
host115-93-dynamic.59-82-r.retail.telecomitalia.it
13個。
200-204-159-61.dsl.telesp.net.br
10個。
adsl-104-22-192-81.adsl.iam.net.ma
10個。
ウクライナのvolia.netは、一般規則に引っかからない多くのホストから不正メールアクセスを出している。ホストは10個あった。
beachless-vim.volia.net
coping.linoleum.volia.net
designsless.bellows.volia.net
exampleless-gear.volia.net
inclined-slope.volia.net
loom.roll.volia.net
pat.descender.volia.net
revering-excursion.volia.net
tangential-design.volia.net
vested-ramparts.volia.net
私は、2007年7月からvolia.net全体をブラックリスト入りさせている。これは今なおはずせないようである。
/\.volia\.net$/ 450 domain check, be patient
日曜日, 6月 20, 2010
いたずら
gabacho-net.jpドメインのSPFレコードが設定されているかどうかを調べようとした人へのメッセージをDNSに設定した。
インターネットに直結されたWindows PCでは、コマンドプロンプトを開いて次のように入力すれば見ることができる。
nslookup -q=txt gabacho-net.jp
（この記事へ直接来られた方は、以下の記事もご覧ください。）
送信ドメイン認証はスパムに勝てないだろう
スパマー様御用達・送信ドメイン貸し出しサービスはいかが？
ドメインレピュテーションで何するの？
| $TTL 86400 $ORIGIN gabacho-net.jp. … gabacho-net.jp. IN TXT "v=spf1 +ip4:116.58.188.194 ~all" IN TXT "But don't you know that SPF is useless for fighting spam?" |
インターネットに直結されたWindows PCでは、コマンドプロンプトを開いて次のように入力すれば見ることができる。
nslookup -q=txt gabacho-net.jp
（この記事へ直接来られた方は、以下の記事もご覧ください。）
送信ドメイン認証はスパムに勝てないだろう
スパマー様御用達・送信ドメイン貸し出しサービスはいかが？
ドメインレピュテーションで何するの？
土曜日, 6月 19, 2010
ドメインレピュテーションで何するの？
送信ドメイン認証が普及してもスパム問題は解決しない。なぜなら、スパマーは認証をパスするドメインを使うコストを低減させると考えられるからである。これに対しては、「送信ドメイン認証によってドメインの詐称が不可能になれば、ドメインレピュテーション（信用度評価）が使えるようになるのだ」という反論があるだろう。
ドメインレピュテーションはドメインの信用度をどう評価するか。当然、著名な正当なドメインは信用できると評価し、スパマーのドメインは信用できないと評価するだろう。できたばかりのドメインや、メール送信の実績の少ない無名のサイトは、まだ信用できるとも信用できないともどちらとも言えないという中間の水準として評価するだろう。
スパマーがドメインレピュテーションに対抗するにはどうするか。スパムを最初に送信する時は、スパマーのドメインの信用度は中間水準だろう。スパムをまいたことがばれれば、信用度が急落する。それによってスパムの送達率がある程度下がったところで、そのドメインを捨ててしまい、新しいドメインを使う。それで信用度は中間水準に回復できる。つまり、スパマーは自分のドメインの信用度をほぼいつも中間水準に維持できるということである。
このようなドメインレピュテーションをスパム判定に使うと、無名のドメインからの正当なメールとスパムとで、スパムかもしれない度合は同じくらいと評価されることになる。だから、スパムが無名のドメインからの正当なメールといっしょにスパム判定されずにメールボックスに入るか、無名のドメインからの正当なメールがスパムといっしょに隔離フォルダに入るかのどちらかになる可能性が高い。こんなシステムが役に立つだろうか。
信用度が中間水準以下ならばグレイリスティングにかけるという方法はどうか。これは実用的かもしれないが、「初めてアクセスして来るホストは信用しないが、再送して来たら信用する」という本来のグレイリスティングに比べて何が優れているのだろうか。無名のサイトからのメールを最初に一時拒否することには変わりはない。それに、「アクセス元の逆引き名がエンドユーザーコンピュータっぽいならば最初のアクセスを信用しないが、そうでないかまたは再送して来たら信用する」というS25R方式に比べて何が優れているのかもわからない。S25R方式は、無名のサイトであってもサーバらしい逆引き名のホストは初めから信用するし、一方、送信ドメインが信用できるものかどうかにかかわらず、ボットからの送信はほとんど止めることができる。結局、一時拒否応答を返すグレイリスティングやS25R方式を使うなら、ドメインレピュテーションなど無用の長物なのである。
SPFにしろDKIMにしろ、認証をパスしなかったメールをどう扱うかは決めていない。それがベースとなって利用可能になるとされるドメインレピュテーションにしても、信用度に基づいてメールをどう扱うかは決めていない。ユーザー（すなわちメールシステム管理者）任せになっている。こんなシステムを組み合わせて有効なスパム対策になるのだろうか。Postfixのオペレーションがどうにかできるくらいの人や、稼ぐ仕事の片手間でしかメールサーバのお守りができない人もいるのである。メールシステムの“偉い人”たちはいったい何を考えているのか。私のような“偉くない人”にとって使いやすく、スパムの排除に効果が高いものでなければ使ってもらえるはずがない。大手ISPのIIJがSPF/Sender IDを実装したメールフィルタプログラムをオープンソースとして無償公開しているが、スパムの排除に大して効果のないシステムを無償で提供したところで、普及に弾みが付くとは思えない。
S25R方式は、送信元をエンドユーザーコンピュータと推定するための、あいまいさのない単純な条件を提供し、その条件に引っかかるホストには一時拒否応答を返すと明確に示し、誤判定から救済する方法も示している。これ単独で97～99%のスパムを排除できる完成されたシステムである。Postfixならばサブシステムなしに実装できるので、技術力の高くないメールシステム管理者でも容易に導入できる。運用が簡単なので、運用に必要な人的コストも低い。だから多くのサイトで採用された。使ってもらえるシステムにしようと思ったら、ここまで考えなければいけない。
ドメインレピュテーションはドメインの信用度をどう評価するか。当然、著名な正当なドメインは信用できると評価し、スパマーのドメインは信用できないと評価するだろう。できたばかりのドメインや、メール送信の実績の少ない無名のサイトは、まだ信用できるとも信用できないともどちらとも言えないという中間の水準として評価するだろう。
スパマーがドメインレピュテーションに対抗するにはどうするか。スパムを最初に送信する時は、スパマーのドメインの信用度は中間水準だろう。スパムをまいたことがばれれば、信用度が急落する。それによってスパムの送達率がある程度下がったところで、そのドメインを捨ててしまい、新しいドメインを使う。それで信用度は中間水準に回復できる。つまり、スパマーは自分のドメインの信用度をほぼいつも中間水準に維持できるということである。
このようなドメインレピュテーションをスパム判定に使うと、無名のドメインからの正当なメールとスパムとで、スパムかもしれない度合は同じくらいと評価されることになる。だから、スパムが無名のドメインからの正当なメールといっしょにスパム判定されずにメールボックスに入るか、無名のドメインからの正当なメールがスパムといっしょに隔離フォルダに入るかのどちらかになる可能性が高い。こんなシステムが役に立つだろうか。
信用度が中間水準以下ならばグレイリスティングにかけるという方法はどうか。これは実用的かもしれないが、「初めてアクセスして来るホストは信用しないが、再送して来たら信用する」という本来のグレイリスティングに比べて何が優れているのだろうか。無名のサイトからのメールを最初に一時拒否することには変わりはない。それに、「アクセス元の逆引き名がエンドユーザーコンピュータっぽいならば最初のアクセスを信用しないが、そうでないかまたは再送して来たら信用する」というS25R方式に比べて何が優れているのかもわからない。S25R方式は、無名のサイトであってもサーバらしい逆引き名のホストは初めから信用するし、一方、送信ドメインが信用できるものかどうかにかかわらず、ボットからの送信はほとんど止めることができる。結局、一時拒否応答を返すグレイリスティングやS25R方式を使うなら、ドメインレピュテーションなど無用の長物なのである。
SPFにしろDKIMにしろ、認証をパスしなかったメールをどう扱うかは決めていない。それがベースとなって利用可能になるとされるドメインレピュテーションにしても、信用度に基づいてメールをどう扱うかは決めていない。ユーザー（すなわちメールシステム管理者）任せになっている。こんなシステムを組み合わせて有効なスパム対策になるのだろうか。Postfixのオペレーションがどうにかできるくらいの人や、稼ぐ仕事の片手間でしかメールサーバのお守りができない人もいるのである。メールシステムの“偉い人”たちはいったい何を考えているのか。私のような“偉くない人”にとって使いやすく、スパムの排除に効果が高いものでなければ使ってもらえるはずがない。大手ISPのIIJがSPF/Sender IDを実装したメールフィルタプログラムをオープンソースとして無償公開しているが、スパムの排除に大して効果のないシステムを無償で提供したところで、普及に弾みが付くとは思えない。
S25R方式は、送信元をエンドユーザーコンピュータと推定するための、あいまいさのない単純な条件を提供し、その条件に引っかかるホストには一時拒否応答を返すと明確に示し、誤判定から救済する方法も示している。これ単独で97～99%のスパムを排除できる完成されたシステムである。Postfixならばサブシステムなしに実装できるので、技術力の高くないメールシステム管理者でも容易に導入できる。運用が簡単なので、運用に必要な人的コストも低い。だから多くのサイトで採用された。使ってもらえるシステムにしようと思ったら、ここまで考えなければいけない。
金曜日, 6月 18, 2010
「危険はない」と言うには勇気が要る
前回、LZH書庫ファイルの脆弱性問題が騒ぎになっていることを述べた。作者が「危険だ」と言っているから危険に違いないと思っていっしょになって「危険だ、危険だ」と騒ぎ立てることはたやすい。もし、LZHのヘッダ処理の脆弱性を突くファイルがウィルス対策ソフトの検疫をすり抜けたためにウィルス感染事故が本当に起こったら、「危険だ」と言っていた人の正しさが証明されることになる。一方、ウィルス感染事故が起こらなくても、「危険だ」と言っていたことが誤りだということにはならない。だから、どちらにしても、「危険だ」と言っている人には、後になって誤りを責められるリスクはない。
しかし、私は騒ぎに逆らって「危険はない」と言った。これは勇気の要ることである。もしウィルス感染事故が起こったら、私の誤りが証明されることになる。私は、言ったことの誤りを後で責められるリスクを背負っているのである。
そんなリスクを背負ってまでなぜあえて「危険はない」と公言したか。情報セキュリティに詳しくない人が必要以上に危険を恐れるあまり、LZH書庫という優れた成果によってもたらされる利益を失ってほしくないと思ったからである。みんながスパム問題から解放されてほしいと願ってS25R方式を発表したのと同じ気持ちからの行動である。
「危険はない」と公言したことは、会社で判断を迫られたことの成果である。「危険だから社内ではLZH書庫の利用を禁止する」と決めるのはたやすい。しかし、LZH書庫として提供されている、業務に役立つソフトウェアの入手を禁止することによる不利益をどうするか。それは社の情報セキュリティのために本当に甘受しなければならないことなのか。私は、考えに考えた末、「ウィルスを警戒する通常の注意を守っていればよい」と結論付けて、LZH書庫がもたらす利益を守った。
「危険はない」と言ったことにもし間違いがあれば、このブログでも社内でも批判を受ける可能性がある。しかし、今のところ批判はない。
もう一つ、私が会社で「危険はない」と判断した事例を紹介する。
私の会社では、ウィルス対策ソフトでのフルスキャンを少なくとも週に1回実行するように決めていた。フルスキャンでは、メモリのスキャン、ブートセクタのスキャン、全ファイルのスキャンが行われる。全ファイルのスキャンは何時間もかかり、CPU使用率が上がって仕事にならないことがある。
私は、全ファイルの定期的なスキャンは本当に必須かを考えた。ワクチンが間に合わずにウィルスファイルがディスクに入り込むことはある。しかし、定期的に全ファイルのスキャンをしなくても、リアルタイムの検知を有効にしておけば、ワクチンができた後にウィルスが活動しようとした時には必ず検知される（このことはベンダーに問い合わせて確認した）。ワクチンが間に合わなければ検知されないが、そうであればどのみち全ファイルのスキャンでも検知されない。つまり、全ファイルのスキャンをしなくてもウィルス発病のリスクは上がらないのである。全ファイルのスキャンをしないためにウィルスファイルがディスクに残存し続けるのは危険だと思うのは、感覚的なものにすぎず、論理的な根拠はない（リアルタイムの検知を必ず有効にしている限り）。
このように検討して、「全ファイルのスキャンを行わないように設定してもよい」とルールを改定した。
セキュリティを心配する社員に不安を与えないように、危険はないということを筋道を立てて説明した。この判断も勇気の要ることだった。これにより、社員は、全ファイルのスキャンで仕事にならないという不利益から解放された。
しかし、私は騒ぎに逆らって「危険はない」と言った。これは勇気の要ることである。もしウィルス感染事故が起こったら、私の誤りが証明されることになる。私は、言ったことの誤りを後で責められるリスクを背負っているのである。
そんなリスクを背負ってまでなぜあえて「危険はない」と公言したか。情報セキュリティに詳しくない人が必要以上に危険を恐れるあまり、LZH書庫という優れた成果によってもたらされる利益を失ってほしくないと思ったからである。みんながスパム問題から解放されてほしいと願ってS25R方式を発表したのと同じ気持ちからの行動である。
「危険はない」と公言したことは、会社で判断を迫られたことの成果である。「危険だから社内ではLZH書庫の利用を禁止する」と決めるのはたやすい。しかし、LZH書庫として提供されている、業務に役立つソフトウェアの入手を禁止することによる不利益をどうするか。それは社の情報セキュリティのために本当に甘受しなければならないことなのか。私は、考えに考えた末、「ウィルスを警戒する通常の注意を守っていればよい」と結論付けて、LZH書庫がもたらす利益を守った。
「危険はない」と言ったことにもし間違いがあれば、このブログでも社内でも批判を受ける可能性がある。しかし、今のところ批判はない。
もう一つ、私が会社で「危険はない」と判断した事例を紹介する。
私の会社では、ウィルス対策ソフトでのフルスキャンを少なくとも週に1回実行するように決めていた。フルスキャンでは、メモリのスキャン、ブートセクタのスキャン、全ファイルのスキャンが行われる。全ファイルのスキャンは何時間もかかり、CPU使用率が上がって仕事にならないことがある。
私は、全ファイルの定期的なスキャンは本当に必須かを考えた。ワクチンが間に合わずにウィルスファイルがディスクに入り込むことはある。しかし、定期的に全ファイルのスキャンをしなくても、リアルタイムの検知を有効にしておけば、ワクチンができた後にウィルスが活動しようとした時には必ず検知される（このことはベンダーに問い合わせて確認した）。ワクチンが間に合わなければ検知されないが、そうであればどのみち全ファイルのスキャンでも検知されない。つまり、全ファイルのスキャンをしなくてもウィルス発病のリスクは上がらないのである。全ファイルのスキャンをしないためにウィルスファイルがディスクに残存し続けるのは危険だと思うのは、感覚的なものにすぎず、論理的な根拠はない（リアルタイムの検知を必ず有効にしている限り）。
このように検討して、「全ファイルのスキャンを行わないように設定してもよい」とルールを改定した。
セキュリティを心配する社員に不安を与えないように、危険はないということを筋道を立てて説明した。この判断も勇気の要ることだった。これにより、社員は、全ファイルのスキャンで仕事にならないという不利益から解放された。
土曜日, 6月 12, 2010
LZHの脆弱性問題は騒ぎすぎだと思う
今回はスパム対策ではなくソフトウェアの脆弱性問題の話。
LZH書庫ファイルシステムの作者Miccoさんの「お知らせ」（2010年6月5日公開）、「LZH書庫のヘッダー処理における脆弱性について (2010 年版)」（2010年4月25日公開）、および6月2日の日記が震源地となって、LZHの脆弱性問題についての情報が駆け巡っている。
●圧縮・解凍用DLL「UNLHA32.DLL」が開発中止、作者はLZHの利用中止を呼びかけ（窓の杜）
●「LZH」アーカイバの開発を中止、JVNへ脆弱性報告では「不受理」（ScanNetSecurity）
●「LZH」の開発中止--企業などは使用しないよう作者が注意喚起（ZDNet Japan）
●UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける（スラッシュドット・ジャパン）
以上は企業サイトの情報だけをピックアップしたもの。ほかに、個人のブログでもたくさん取り上げられている。
問題を要約するとこうである。2006年にLZH書庫ファイルのヘッダ処理の脆弱性が発見された。ファイル圧縮・解凍ソフトのほとんどは対処したが、ウィルス対策ソフトの多くは未だにこの脆弱性問題に対応していない。そのため、この脆弱性を突く不正なファイルを検疫できずに見逃してしまう。特に、ゲートウェイ方式によるウィルス対策をとっていてクライアントにウィルス対策ソフトをインストールしていない組織では、ウィルスが容易に侵入してしまう。この問題は4月下旬にJVNに報告したが、不受理。JVNはzip、rar、cab、gzip、7Zip形式の同じ問題についてはJVNVU#545953として公開しているのに、LZH形式についての問題が受理されないのは、「（世界的に見ればマイナーな）LZH書庫なんて知らねえよ」という態度としか考えられない。Miccoさんは、「脆弱性が存在しても放っておかれるような書庫がいつまでも業務目的で利用されるのは嫌ですので」と、UNLHA32.DLL、UNARJ32.DLL、LHMeltの開発中止を決断し、LZH書庫の利用中止を呼びかけた。
しかし、ここで疑問なのだが、アプリケーションの脆弱性を突く不正ファイルを、その検体が捕獲される前からウィルス対策ソフトが一網打尽に検疫することは、そもそも非常に困難なのではないか。LZH書庫ファイルのヘッダ処理の脆弱性を突く不正ファイルなら、ヘッダ部分をLZH書庫の仕様からはずれたビットパターンにしているだろうが、どういうビットパターンかは事前には特定できない。だから、不正ファイルの検体を捕獲する前に不正ファイルを検疫することは、必ずしもできなくて当然である。これは、未知のウィルスを検疫しきれないのと同じである。もちろん、検体が捕獲されたらワクチンを作ることができて、その後は不正ファイルを検疫することができる。
それに、不正な書庫ファイルをウィルス対策ソフトが検疫できなかったとしても、ファイル解凍ソフトが脆弱性問題に対処済みであれば、ヘッダが不正であることを検知して復元をやめるはずだから、危険はない。よしんばそれでウィルスが復元されたとしても、それが既知のウィルスであれば、そのウィルスファイルがアクセスされた時にウィルス対策ソフトが検知するから、危険はない。未知のウィルスであれば危険だが、ワクチンが間に合わなければ検疫できないのは、そもそも仕方のないことである。
結局のところ、Miccoさんの主張は、「LZH書庫のヘッダ処理の脆弱性を突く不正ファイルを、その検体が捕獲されてワクチンが作られる前に検疫できないのは、ウィルス対策ソフトの脆弱性である」というものだと私は受け取った。それに対する私の考えは、「不正ファイルの検体が捕獲される前に必ずしも検疫できないのは、通常のウィルスと同じことであり、これはウィルス対策ソフトの脆弱性ではない」というものである。ゲートウェイ方式のウィルス対策だけを行っている組織では特に危険だと言うが、クライアントにウィルス対策ソフトをインストールしないのがそもそもセキュリティ対策として間違っている。zipなどについては問題がJVNVU#545953として受理されているのにLZHについては受理されないのはおかしいという指摘については、JVNがJVNVU#545953を出したのが間違いだったと思う。
私の会社でも、情報を知った社員から問い合わせがあった。この問題についての社としての対応方針を決めるために私が見解を求められた。私は、
●ウィルス対策ソフトを正しく使う。
●ファイル解凍ソフトは脆弱性に対処済みの版を使う。
●信頼できるサイト以外からファイルをダウンロードしない。
●不審なメールに添付されたファイルを開かない。
という通常の注意を守っていればほぼ危険はないと答申した。これについては、私の会社が属する企業グループのCERT（Computer Emergency Response Team）に相談し、妥当な判断であるとの回答を得ている。
LZH書庫ファイルシステムの作者Miccoさんの「お知らせ」（2010年6月5日公開）、「LZH書庫のヘッダー処理における脆弱性について (2010 年版)」（2010年4月25日公開）、および6月2日の日記が震源地となって、LZHの脆弱性問題についての情報が駆け巡っている。
●圧縮・解凍用DLL「UNLHA32.DLL」が開発中止、作者はLZHの利用中止を呼びかけ（窓の杜）
●「LZH」アーカイバの開発を中止、JVNへ脆弱性報告では「不受理」（ScanNetSecurity）
●「LZH」の開発中止--企業などは使用しないよう作者が注意喚起（ZDNet Japan）
●UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける（スラッシュドット・ジャパン）
以上は企業サイトの情報だけをピックアップしたもの。ほかに、個人のブログでもたくさん取り上げられている。
問題を要約するとこうである。2006年にLZH書庫ファイルのヘッダ処理の脆弱性が発見された。ファイル圧縮・解凍ソフトのほとんどは対処したが、ウィルス対策ソフトの多くは未だにこの脆弱性問題に対応していない。そのため、この脆弱性を突く不正なファイルを検疫できずに見逃してしまう。特に、ゲートウェイ方式によるウィルス対策をとっていてクライアントにウィルス対策ソフトをインストールしていない組織では、ウィルスが容易に侵入してしまう。この問題は4月下旬にJVNに報告したが、不受理。JVNはzip、rar、cab、gzip、7Zip形式の同じ問題についてはJVNVU#545953として公開しているのに、LZH形式についての問題が受理されないのは、「（世界的に見ればマイナーな）LZH書庫なんて知らねえよ」という態度としか考えられない。Miccoさんは、「脆弱性が存在しても放っておかれるような書庫がいつまでも業務目的で利用されるのは嫌ですので」と、UNLHA32.DLL、UNARJ32.DLL、LHMeltの開発中止を決断し、LZH書庫の利用中止を呼びかけた。
しかし、ここで疑問なのだが、アプリケーションの脆弱性を突く不正ファイルを、その検体が捕獲される前からウィルス対策ソフトが一網打尽に検疫することは、そもそも非常に困難なのではないか。LZH書庫ファイルのヘッダ処理の脆弱性を突く不正ファイルなら、ヘッダ部分をLZH書庫の仕様からはずれたビットパターンにしているだろうが、どういうビットパターンかは事前には特定できない。だから、不正ファイルの検体を捕獲する前に不正ファイルを検疫することは、必ずしもできなくて当然である。これは、未知のウィルスを検疫しきれないのと同じである。もちろん、検体が捕獲されたらワクチンを作ることができて、その後は不正ファイルを検疫することができる。
それに、不正な書庫ファイルをウィルス対策ソフトが検疫できなかったとしても、ファイル解凍ソフトが脆弱性問題に対処済みであれば、ヘッダが不正であることを検知して復元をやめるはずだから、危険はない。よしんばそれでウィルスが復元されたとしても、それが既知のウィルスであれば、そのウィルスファイルがアクセスされた時にウィルス対策ソフトが検知するから、危険はない。未知のウィルスであれば危険だが、ワクチンが間に合わなければ検疫できないのは、そもそも仕方のないことである。
結局のところ、Miccoさんの主張は、「LZH書庫のヘッダ処理の脆弱性を突く不正ファイルを、その検体が捕獲されてワクチンが作られる前に検疫できないのは、ウィルス対策ソフトの脆弱性である」というものだと私は受け取った。それに対する私の考えは、「不正ファイルの検体が捕獲される前に必ずしも検疫できないのは、通常のウィルスと同じことであり、これはウィルス対策ソフトの脆弱性ではない」というものである。ゲートウェイ方式のウィルス対策だけを行っている組織では特に危険だと言うが、クライアントにウィルス対策ソフトをインストールしないのがそもそもセキュリティ対策として間違っている。zipなどについては問題がJVNVU#545953として受理されているのにLZHについては受理されないのはおかしいという指摘については、JVNがJVNVU#545953を出したのが間違いだったと思う。
私の会社でも、情報を知った社員から問い合わせがあった。この問題についての社としての対応方針を決めるために私が見解を求められた。私は、
●ウィルス対策ソフトを正しく使う。
●ファイル解凍ソフトは脆弱性に対処済みの版を使う。
●信頼できるサイト以外からファイルをダウンロードしない。
●不審なメールに添付されたファイルを開かない。
という通常の注意を守っていればほぼ危険はないと答申した。これについては、私の会社が属する企業グループのCERT（Computer Emergency Response Team）に相談し、妥当な判断であるとの回答を得ている。
土曜日, 6月 05, 2010
スパマー様御用達・送信ドメイン貸し出しサービスはいかが？
前回、「送信ドメイン認証はスパムに勝てないだろう」と述べた。送信ドメイン認証をちゃんと理解している人には、「送信ドメイン認証はなりすまし対策であって、スパム対策ではないのは当然」とせせら笑われたかもしれない。私は、SPFがスパマーに欺かれることは知っていたが、公開鍵暗号方式を使ったDKIMさえスパマーは欺くことができると最近気付いた。それでようやく、送信ドメイン認証が普及してもスパムに勝つ展望はないとわかったのである。
確かに、他サイトのドメインをかたることはできなくなるが、それならスパマーは、詐称でない自分のドメイン名を使ってスパムをばらまくだけのことである。実際、そのようなスパマーはすでにいる。5月15日「フィッシング詐欺のスパムを送信者アドレスで蹴る」で、以下を送信者アドレスとするスパムが着信したことを述べた。
2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com
数字だけから成るいくつものサイトドメイン名は、真っ当な他サイトのドメインをかたったものではなく、スパム送信のために取得したものに違いない。そして、これらのドメインにはちゃんとDNSのAレコードが対応している。だから、reject_unknown_sender_domain指定でブロックされることもなかったのである。
ドメインを取得してDNSを設定するのにコストがかかることがスパムに対する抑止力になると思う人がいるかもしれない。しかし敵は、スパム用の送信ドメインを用意する仕事を分業化することによって、コストの問題も早晩克服してしまうだろう。スパム用送信ドメイン専門業者は、いくつものドメインを取得して、DNSでMXレコードまたはAレコードを対応させるばかりでなく、SPFとDKIMも設定する。これをスパマーに貸し出すのである。
数字ばかりのサイトドメイン名を信用しないようにしようって？それはもちろん浅はかである。221616.com（株式会社ガリバーインターナショナル）のような真っ当なドメインを疑うという副作用をもたらす。それに、単語を適当に組み合わせたlionspacefoods.comのような、一見して怪しいとわからないドメイン名はいくらでも作れる。mastercardsupport.comのような、著名な会社の関連会社と思わせるようなドメイン名は、高く売れるだろう。
ドメインの詐称ができなくなるのだから、スパマーの送信ドメインをブラックリストに登録すればよいって？もちろんそれも浅はかである。いたちごっこになるのは前回述べたとおり。
スパム用ドメイン専門業者が使うDNSサーバのIPアドレスのブラックリストを作る？そうしたら、敵は、クラウドコンピューティングサービスを使うなどしてDNSサーバを転々とするだろう。
スパム対策のためには送信ドメイン認証の普及が必要だと喧伝されているが、いずれ、送信ドメイン認証は受信側のスパム対策として役に立たないことがわかってみんな失望するだろう。普及前にそのことが広く知れ渡って、結局普及しないのではないかと思う。
「スパムのほとんどは送信者アドレスを詐称しているから、詐称させないようにしよう」という発想で本当にスパマーが手も足も出せなくなるかどうかを検証していないのが間違いなのである。「スパムのほとんどはボットから送信されているから、ボットからの送信を阻止しよう」という発想こそがスパマーの手足をもぐことができる。その発想に基づく送信側対策がOP25Bであり、受信側対策の一つがS25R方式である。OP25Bは国内からのスパム発信を抑え込むのに成功している。そしてS25R方式は、完成以来6年にわたって阻止率97～99%という効果が衰えていないことが実証されている。
私は、SPFレコードの宣言は簡単なので対応している。しかし、DKIMは面倒なので、Postfixのデフォルトインストールで対応できるくらいにならない限り、対応するつもりはない。送信ドメイン認証に対応しなければメールを受け取ってもらえなくなる時が来ると言う人がいるが、そうはならないだろう。正当なメールを受け取り拒否すれば、そのメールを待っていた人が困ることになるからである。そして私は、将来ともスパム判定のために送信ドメイン認証を取り入れるつもりはまったくない。S25R方式のおかげで、スパムにはまったく困っていないからである。
S25R方式を導入した皆さんも、スパム対策のためにこれ以上何もする必要はないと思っておられるだろう。SPFレコードの設定はコストなしにできるからやってもよいが、それ以上のことは、格別関心を持つ人だけが好きにやればよい。送信ドメイン認証だ、いけいけどんどんと笛太鼓が鳴っても踊る必要はない。送信ドメイン認証を勉強して対応する時間とお金があるなら、他の生産的なことに使った方がよい。
続編：ドメインレピュテーションで何するの？
確かに、他サイトのドメインをかたることはできなくなるが、それならスパマーは、詐称でない自分のドメイン名を使ってスパムをばらまくだけのことである。実際、そのようなスパマーはすでにいる。5月15日「フィッシング詐欺のスパムを送信者アドレスで蹴る」で、以下を送信者アドレスとするスパムが着信したことを述べた。
2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com
数字だけから成るいくつものサイトドメイン名は、真っ当な他サイトのドメインをかたったものではなく、スパム送信のために取得したものに違いない。そして、これらのドメインにはちゃんとDNSのAレコードが対応している。だから、reject_unknown_sender_domain指定でブロックされることもなかったのである。
ドメインを取得してDNSを設定するのにコストがかかることがスパムに対する抑止力になると思う人がいるかもしれない。しかし敵は、スパム用の送信ドメインを用意する仕事を分業化することによって、コストの問題も早晩克服してしまうだろう。スパム用送信ドメイン専門業者は、いくつものドメインを取得して、DNSでMXレコードまたはAレコードを対応させるばかりでなく、SPFとDKIMも設定する。これをスパマーに貸し出すのである。
数字ばかりのサイトドメイン名を信用しないようにしようって？それはもちろん浅はかである。221616.com（株式会社ガリバーインターナショナル）のような真っ当なドメインを疑うという副作用をもたらす。それに、単語を適当に組み合わせたlionspacefoods.comのような、一見して怪しいとわからないドメイン名はいくらでも作れる。mastercardsupport.comのような、著名な会社の関連会社と思わせるようなドメイン名は、高く売れるだろう。
ドメインの詐称ができなくなるのだから、スパマーの送信ドメインをブラックリストに登録すればよいって？もちろんそれも浅はかである。いたちごっこになるのは前回述べたとおり。
スパム用ドメイン専門業者が使うDNSサーバのIPアドレスのブラックリストを作る？そうしたら、敵は、クラウドコンピューティングサービスを使うなどしてDNSサーバを転々とするだろう。
スパム対策のためには送信ドメイン認証の普及が必要だと喧伝されているが、いずれ、送信ドメイン認証は受信側のスパム対策として役に立たないことがわかってみんな失望するだろう。普及前にそのことが広く知れ渡って、結局普及しないのではないかと思う。
「スパムのほとんどは送信者アドレスを詐称しているから、詐称させないようにしよう」という発想で本当にスパマーが手も足も出せなくなるかどうかを検証していないのが間違いなのである。「スパムのほとんどはボットから送信されているから、ボットからの送信を阻止しよう」という発想こそがスパマーの手足をもぐことができる。その発想に基づく送信側対策がOP25Bであり、受信側対策の一つがS25R方式である。OP25Bは国内からのスパム発信を抑え込むのに成功している。そしてS25R方式は、完成以来6年にわたって阻止率97～99%という効果が衰えていないことが実証されている。
私は、SPFレコードの宣言は簡単なので対応している。しかし、DKIMは面倒なので、Postfixのデフォルトインストールで対応できるくらいにならない限り、対応するつもりはない。送信ドメイン認証に対応しなければメールを受け取ってもらえなくなる時が来ると言う人がいるが、そうはならないだろう。正当なメールを受け取り拒否すれば、そのメールを待っていた人が困ることになるからである。そして私は、将来ともスパム判定のために送信ドメイン認証を取り入れるつもりはまったくない。S25R方式のおかげで、スパムにはまったく困っていないからである。
S25R方式を導入した皆さんも、スパム対策のためにこれ以上何もする必要はないと思っておられるだろう。SPFレコードの設定はコストなしにできるからやってもよいが、それ以上のことは、格別関心を持つ人だけが好きにやればよい。送信ドメイン認証だ、いけいけどんどんと笛太鼓が鳴っても踊る必要はない。送信ドメイン認証を勉強して対応する時間とお金があるなら、他の生産的なことに使った方がよい。
続編：ドメインレピュテーションで何するの？
日曜日, 5月 30, 2010
送信ドメイン認証はスパムに勝てないだろう
前回述べた、迷惑メール対策について講演した某ISPの人は、送信ドメイン認証にえらくご執心のようだった。送信ドメイン認証のコンセプトは、「確固たるスパム対策のためには、送信者アドレスが簡単に詐称できるという問題を解決し、送信ドメインを信頼できるデータにすることが必要だ」というもの。多くの人がそう思っているだろう。
私もかつては、送信ドメイン認証の普及と他の対策の併用によってS25R方式が不要になる時が来るだろうと思っていた。しかし今では、送信ドメイン認証はスパム問題の解決策にはならないだろうと思っている。スパマーが送信ドメイン認証を欺く方法があるからである。以下に、送信ドメイン認証の代表的な方式について、その原理と欺き方を述べる。
●SPF（Sender Policy Framework）
原理 送信側サイトは、自ドメインからのメールを送信するホストを自ドメインのDNSで宣言する。受信側では、受信したメールの送信ドメインでDNSを検索して、宣言された送信元ホストを知る。実際の送信元がそれと一致すれば、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで不当に広いIPアドレス範囲を送信元として宣言することにより、多数のボットからスパムを送信させてSPFチェックをパスさせることができる。このような手口は、仙石浩明さんが観測しておられる。
●DKIM（DomainKeys Identified Mail）
原理 送信側サイトは、公開鍵を自ドメインのDNSで公開する。そして、私有鍵を使ってメールヘッダとメッセージ本体から作った電子署名をメールヘッダに埋め込んで送信する。電子署名とは、データから生成したハッシュ値を公開鍵暗号方式における私有鍵で暗号化したものであり、私有鍵に対応する公開鍵でのみ復号できる。受信側では、受信したメールの送信ドメインでDNSを検索して公開鍵を入手し、それを使って電子署名を復号する。その結果、復号されたハッシュ値と受信側で生成したハッシュ値とが一致すれば、送信元は公開鍵に対応する私有鍵の所有者に違いない、すなわち、公開鍵を公開しているDNSのドメインの管理主体に違いないということになる。このことから、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで公開鍵を公開する。そして、私有鍵で作った電子署名を埋め込んだスパムを用意する。それを多数のボットから送信させれば、DKIMチェックをパスさせることができる。
仮に送信ドメイン認証が普及したとしたら、スパマーは、送信ドメインを詐称したスパムを受信してもらえなくなるだろうから、詐称でない送信ドメインでスパムを送信しなければならなくなる。受信側では、受信してしまったスパムの送信ドメインは確かにスパマーのものだと判断できるから、それをブラックリストに登録して、以降、同じ送信ドメインのスパムを阻止できる。現状では送信ドメインは容易に詐称できるので、送信ドメインのブラックリストはまったく役に立たないが、その問題が改善され、送信ドメインのブラックリスト作りが意味のある作業になる。それが、送信ドメイン認証を推進している人たちの考えらしい。
しかしスパマーは、送信ドメインを使い捨てることによって、相変わらずボットから大量のスパムを送信し、着信させることができるだろう。極端には、一つの送信ドメインで1種類のスパムを数億通ばらまいたらそのドメインを捨ててしまうというやり方も、ボットを活用できる限りはコスト的にペイするだろう。かくして、送信ドメインのブラックリスト作りのいたちごっこが復活するだけのことである(*)。
メールシステムの“偉い人”たちは、欺かれることが予見される送信ドメイン認証をなぜ一生懸命推進しようとするのだろうか。送信ドメインを詐称不可能なものにしなければならないという固定観念に凝り固まっているのではないかと思えてくる。
仙石さんのブログ記事「迷惑メール送信者とのイタチごっこを終わらせるために (1)」にコメントした人は、書かれているアイデアがS25R方式に似ていることを指摘してS25R方式を批判し、「きちんと管理されたIPアドレスから送信されたメールを確認する提案ならば、SPFやDomainKeysの導入を進める方がよい」と言っているが、これはナンセンス。S25R方式は、スパムのほとんどを占めるボットからの送信に的を絞ることによって、（もちろん完全排除とはいかないものの）スパマーとのいたちごっこをほぼ終わらせた（なおかつ、1000サイト以上と推定される普及にもかかわらず、副作用による不達問題が騒ぎになってはいない）。これからの普及に期待する人が少なくないであろう送信ドメイン認証の方が、実はスパマーとのいたちごっこを終わらせることが期待できないのである。
(*) ブラックリスト作りはいたちごっこになるからホワイトリスト方式にすればよいと言う人がいるかもしれないが、ホワイトリスト登録された送信ドメインのメールのみを受け入れるというやり方は実用にならないだろう。未知の正当なドメインからのメールを受けるのに支障があるからである。ホワイトリスト作りのために送信者自身の手を借りるというのがバウンシングバック認証方式のコンセプトだが、それがいかに使い物にならないシステムであるかは、私がかつてさんざん指摘したとおりである。
続編：スパマー様御用達・送信ドメイン貸し出しサービスはいかが？
私もかつては、送信ドメイン認証の普及と他の対策の併用によってS25R方式が不要になる時が来るだろうと思っていた。しかし今では、送信ドメイン認証はスパム問題の解決策にはならないだろうと思っている。スパマーが送信ドメイン認証を欺く方法があるからである。以下に、送信ドメイン認証の代表的な方式について、その原理と欺き方を述べる。
●SPF（Sender Policy Framework）
原理 送信側サイトは、自ドメインからのメールを送信するホストを自ドメインのDNSで宣言する。受信側では、受信したメールの送信ドメインでDNSを検索して、宣言された送信元ホストを知る。実際の送信元がそれと一致すれば、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで不当に広いIPアドレス範囲を送信元として宣言することにより、多数のボットからスパムを送信させてSPFチェックをパスさせることができる。このような手口は、仙石浩明さんが観測しておられる。
●DKIM（DomainKeys Identified Mail）
原理 送信側サイトは、公開鍵を自ドメインのDNSで公開する。そして、私有鍵を使ってメールヘッダとメッセージ本体から作った電子署名をメールヘッダに埋め込んで送信する。電子署名とは、データから生成したハッシュ値を公開鍵暗号方式における私有鍵で暗号化したものであり、私有鍵に対応する公開鍵でのみ復号できる。受信側では、受信したメールの送信ドメインでDNSを検索して公開鍵を入手し、それを使って電子署名を復号する。その結果、復号されたハッシュ値と受信側で生成したハッシュ値とが一致すれば、送信元は公開鍵に対応する私有鍵の所有者に違いない、すなわち、公開鍵を公開しているDNSのドメインの管理主体に違いないということになる。このことから、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで公開鍵を公開する。そして、私有鍵で作った電子署名を埋め込んだスパムを用意する。それを多数のボットから送信させれば、DKIMチェックをパスさせることができる。
仮に送信ドメイン認証が普及したとしたら、スパマーは、送信ドメインを詐称したスパムを受信してもらえなくなるだろうから、詐称でない送信ドメインでスパムを送信しなければならなくなる。受信側では、受信してしまったスパムの送信ドメインは確かにスパマーのものだと判断できるから、それをブラックリストに登録して、以降、同じ送信ドメインのスパムを阻止できる。現状では送信ドメインは容易に詐称できるので、送信ドメインのブラックリストはまったく役に立たないが、その問題が改善され、送信ドメインのブラックリスト作りが意味のある作業になる。それが、送信ドメイン認証を推進している人たちの考えらしい。
しかしスパマーは、送信ドメインを使い捨てることによって、相変わらずボットから大量のスパムを送信し、着信させることができるだろう。極端には、一つの送信ドメインで1種類のスパムを数億通ばらまいたらそのドメインを捨ててしまうというやり方も、ボットを活用できる限りはコスト的にペイするだろう。かくして、送信ドメインのブラックリスト作りのいたちごっこが復活するだけのことである(*)。
メールシステムの“偉い人”たちは、欺かれることが予見される送信ドメイン認証をなぜ一生懸命推進しようとするのだろうか。送信ドメインを詐称不可能なものにしなければならないという固定観念に凝り固まっているのではないかと思えてくる。
仙石さんのブログ記事「迷惑メール送信者とのイタチごっこを終わらせるために (1)」にコメントした人は、書かれているアイデアがS25R方式に似ていることを指摘してS25R方式を批判し、「きちんと管理されたIPアドレスから送信されたメールを確認する提案ならば、SPFやDomainKeysの導入を進める方がよい」と言っているが、これはナンセンス。S25R方式は、スパムのほとんどを占めるボットからの送信に的を絞ることによって、（もちろん完全排除とはいかないものの）スパマーとのいたちごっこをほぼ終わらせた（なおかつ、1000サイト以上と推定される普及にもかかわらず、副作用による不達問題が騒ぎになってはいない）。これからの普及に期待する人が少なくないであろう送信ドメイン認証の方が、実はスパマーとのいたちごっこを終わらせることが期待できないのである。
(*) ブラックリスト作りはいたちごっこになるからホワイトリスト方式にすればよいと言う人がいるかもしれないが、ホワイトリスト登録された送信ドメインのメールのみを受け入れるというやり方は実用にならないだろう。未知の正当なドメインからのメールを受けるのに支障があるからである。ホワイトリスト作りのために送信者自身の手を借りるというのがバウンシングバック認証方式のコンセプトだが、それがいかに使い物にならないシステムであるかは、私がかつてさんざん指摘したとおりである。
続編：スパマー様御用達・送信ドメイン貸し出しサービスはいかが？
土曜日, 5月 29, 2010
観念論
3ヶ月ほど前のことなのだが、某ISPのセキュリティセミナーを聴きに行った。その中に、迷惑メール対策の演題があった。
プレゼンテーションの中身は、「迷惑メールの動向」として4ページ、「迷惑メール対策」として2ページしかなく、「送信ドメイン認証技術」に12ページも費やしていた。「迷惑メールの現状とその対策」と題しながら、大半が送信ドメイン認証の話で、今どうすればスパムの被害を抑えることができるかという話はなく、そのISPで現状どのようにスパム対策を行っているのかという話もなかった。
「迷惑メール対策」の項では、「安易な対策による弊害」と称して、今使われている対策では問題を起こすから困るのだと言わんばかりの説明。
DNSBL（RBL）については、送信側から苦情が来ないと誤判定がわからないという問題を挙げていた。私だったら、DNSBLに引っかかったホストには応答コード「4xx」を返して、グレイリスティングにかけるか、ツールでリトライを発見することによって、正当な（かもしれない）メールを救済する方法をとるよう訴える。バウンシングバック認証方式のような、克服不可能な副作用のある対策方式とは違うのだから、使えない対策であるかのように批判して終わることはしない。
グレイリスティングについては、「メール配送の遅延を招き、送信側サーバに負担を強いる」と。口頭で「ISPとしては困ることだ」と言っていた。2009年2月14日「「4xx」は迷惑か？」にも述べたとおり、「送信側サーバに負担を強いる」は観念論である。HELO、MAIL FROM、RCPT TOコマンドを再度やらされる処理に使われるCPUリソースやメモリリソースは、スパム1通を丸ごと受信する処理に比べてどれほどのものだと言うのか。相手サーバが受信してくれるまで送信メールがキューに5～30分程度滞留する(*)ことによるディスクリソースの消費は、自サイトのユーザーに届いたたくさんのスパムが（ユーザーがダウンロードするまで）何時間も何日もスプールに滞留するのに比べてどれほどのものだと言うのか。生半可な知識を振りかざすアマチュアやセミプロにこういう観念論を主張する人がいることは知っていたが、ISPのプロまでがこんなことを言うとは驚いた。
また、グレイリスティングの問題点として「迷惑メール送信側も対策することが可能」とも述べていた。それも、現実を見ていないという意味で観念論である。私は何年にもわたって、リトライするスパムアクセスの挙動を観察しており、グレイリスティングの突破率は1%くらい（あるいは時に2.6%）という統計結果を得ている。応答コード「4xx」で一時拒否する方法は、長期にわたってスパムの阻止に高い効果を保っているというのが事実である。
大手ISPで技術を支える重要ポストにいる“偉い人”でもまともなことを言うとは限らないと認識した次第。
(*) 素のS25R方式では送信メールをキューに滞留させる時間は5～30分程度では済まないだろうと突っ込む人がいるかもしれないが、S25R方式はISPのメールサーバからのメールを一時拒否することはほとんどない。ISPのメールサーバの逆引き名がS25Rに引っかかることは少ないし、引っかかるとしても、ISPには送信するユーザーが多いので早期にそのメールサーバが発見され、ホワイトリスト登録されるからである。
続編：送信ドメイン認証はスパムに勝てないだろう
プレゼンテーションの中身は、「迷惑メールの動向」として4ページ、「迷惑メール対策」として2ページしかなく、「送信ドメイン認証技術」に12ページも費やしていた。「迷惑メールの現状とその対策」と題しながら、大半が送信ドメイン認証の話で、今どうすればスパムの被害を抑えることができるかという話はなく、そのISPで現状どのようにスパム対策を行っているのかという話もなかった。
「迷惑メール対策」の項では、「安易な対策による弊害」と称して、今使われている対策では問題を起こすから困るのだと言わんばかりの説明。
DNSBL（RBL）については、送信側から苦情が来ないと誤判定がわからないという問題を挙げていた。私だったら、DNSBLに引っかかったホストには応答コード「4xx」を返して、グレイリスティングにかけるか、ツールでリトライを発見することによって、正当な（かもしれない）メールを救済する方法をとるよう訴える。バウンシングバック認証方式のような、克服不可能な副作用のある対策方式とは違うのだから、使えない対策であるかのように批判して終わることはしない。
グレイリスティングについては、「メール配送の遅延を招き、送信側サーバに負担を強いる」と。口頭で「ISPとしては困ることだ」と言っていた。2009年2月14日「「4xx」は迷惑か？」にも述べたとおり、「送信側サーバに負担を強いる」は観念論である。HELO、MAIL FROM、RCPT TOコマンドを再度やらされる処理に使われるCPUリソースやメモリリソースは、スパム1通を丸ごと受信する処理に比べてどれほどのものだと言うのか。相手サーバが受信してくれるまで送信メールがキューに5～30分程度滞留する(*)ことによるディスクリソースの消費は、自サイトのユーザーに届いたたくさんのスパムが（ユーザーがダウンロードするまで）何時間も何日もスプールに滞留するのに比べてどれほどのものだと言うのか。生半可な知識を振りかざすアマチュアやセミプロにこういう観念論を主張する人がいることは知っていたが、ISPのプロまでがこんなことを言うとは驚いた。
また、グレイリスティングの問題点として「迷惑メール送信側も対策することが可能」とも述べていた。それも、現実を見ていないという意味で観念論である。私は何年にもわたって、リトライするスパムアクセスの挙動を観察しており、グレイリスティングの突破率は1%くらい（あるいは時に2.6%）という統計結果を得ている。応答コード「4xx」で一時拒否する方法は、長期にわたってスパムの阻止に高い効果を保っているというのが事実である。
大手ISPで技術を支える重要ポストにいる“偉い人”でもまともなことを言うとは限らないと認識した次第。
(*) 素のS25R方式では送信メールをキューに滞留させる時間は5～30分程度では済まないだろうと突っ込む人がいるかもしれないが、S25R方式はISPのメールサーバからのメールを一時拒否することはほとんどない。ISPのメールサーバの逆引き名がS25Rに引っかかることは少ないし、引っかかるとしても、ISPには送信するユーザーが多いので早期にそのメールサーバが発見され、ホワイトリスト登録されるからである。
続編：送信ドメイン認証はスパムに勝てないだろう
登録:
投稿 (Atom)
