日曜日, 9月 30, 2007

ホワイトリスト情報の報告が増えた

 最近、メールやBBSでホワイトリスト情報の連絡をいただくことが多くなったような気がして、公開ホワイトリストファイルを振り返ってみた。コメント行に「(*)」のマークがあるのが協力者から報告された情報であり、日付は報告された日である。
 報告があった月は、2004年には11月、2005年には5月、7月、8月、2006年には1月、3月、12月だった。2007年に入ってからは、9月まで毎月報告をいただいている。件数は、2004年から2006年までの合計が28件だが、2007年には9月までですでにそれを上回る37件になっている。
 ホワイトリスト情報を報告してくださる人にとって、自分に直接得になることはない。中には、Rgeryを使っていてホワイトリスト情報を必要としないにもかかわらず、Rgreyで自動許可されたホストの情報を知らせてくださる方もいる。S25R方式を使う他サイトに役立ててもらおうという無償の善意である。ありがたいことである。そういう善意の人が増えているのは、S25R方式を導入する人の総数が増えているからに違いない。
 ホワイトリスト情報は、実際に役に立っているようである。沼津高専のサイトにある「平成18年度高専情報処理教育研究委員会 承合事項」(PDFファイル)という文書で、全国の高専への迷惑メール対策のアンケートの結果が報告されている。その中に、S25R方式の導入結果の報告として

結果として9割方のスパムを阻止できている。S25Rの導入後に幾分の誤動作があったが、その後発表されたパッチをあてることによりほとんど改善されている。

とある。パッチとはホワイトリスト情報のことだろう。高専ほどの規模のサイトに、私が公表している100件にも満たないホワイトリストで十分だとは思えないが、偽陽性判定の頻発を避けるにはかなり役立っているのだろう。
 S25R方式を導入するサイトが増え、ホワイトリスト情報を報告してくださる人が増える。それで公開ホワイトリストが充実する。これからS25R方式を導入する人は、公開ホワイトリストを組み込むことにより、初めから偽陽性判定の頻発を避けることができる。そのため、S25R方式は使いやすいと評価され、評判が広まってますますS25R方式を導入するサイトが増える。S25R方式の普及は、今、間違いなく好循環に乗っている。

火曜日, 9月 25, 2007

「驚異のスパムフィルタ」とお褒め

 「我的名字叫’佐野’的Blog」さんで「驚異のスパムフィルタ」と題して絶賛をいただいている。会社で社員全員にスパムが送られてくるようになり、S25R方式を採用されたとのこと。

「Postfixの正規表現フィルタにある法則を登録するとあら不思議厄介な発信元をことごとく拒否してくれます。まっとうなメールはちゃんと通過してきます。」
「おどろきました。どんなスパムフィルタよりも簡単で確実にフィルタしてくれます。」
「ホワイトリストで救済するアドレスはうちの会社の場合多くはないのでメンテも簡単に済みそうです。」
「効果をみれば誰もが黙りますね。」

こういう言葉で賞賛していただけるのは本当にうれしい。
 ご利用ありがとうございます。

土曜日, 9月 22, 2007

お気に入りアイコン

 スパム対策技術のページのお気に入りアイコンを作ってみました。こんなの

木曜日, 9月 20, 2007

属性ラベルホワイトリストに落とし穴

 9月14日に属性ラベルホワイトリストのアイデアを紹介したが、地域ドメインの許可条件に落とし穴があることに気付いた。当初、

/\.(pref|metro|city)\.[^.]+\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]+\.jp$/ OK

と書いていたが、これだと、ne.jpは丸ごと信用はしないというポリシーにもかかわらず、metro.ne.jpやcity.ne.jp(いずれも実在する)、それに*.city.EXAMPLE.ne.jpなどのパターンのサイトが丸ごと許可されてしまう。そのため、ne.jpを冠するISPのエンドユーザー回線からスパムやウィルスメールを受けるおそれがある。
 そこで、サイトドメイン名や地域ドメイン名は3文字以上でなければならないというJPNICの規則に基づいて、3文字以上を意味する「{3,}」を指定することにより、jpの直下の階層が2文字の属性ラベルとマッチするのを回避するようにした。
 記事本文を修正したので、9月19日までに許可条件をコピーして取り入れられた方は修正してください。

月曜日, 9月 17, 2007

ルール6を改良

 論文を2004年6月に発表して以来初めて一般規則に手を加えた。ルール6を次のように変更した。

/^(dhcp|dialup|ppp|adsl)[^.]*[0-9]/ 450 S25R check, be patient

/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient

 きっかけは、dsl411.rbh-brktel.pppoe.execulink.comというホストからスパムを受信したことである。そこで、「adsl」のみならず、DSL系のあらゆる名前で始まって数字を含む末端ホスト名をルール6で引っかけるようにした。
 これに伴い、

# xdsl-5790.lubin.dialog.net.pl
/^xdsl.+\.dialog\.net\.pl$/ 450 domain check, be patient

というブラックリスト項目は不要になったので、ブラックリストの実例から削除した。
 ルール6をこのように直したところで、それが役立つことはまれである。すでにS25R方式を運用している皆さんにあえて手直しをお勧めするというほどのことではない。ただ、DSL系の名前として「adsl」以外に「xdsl」に続いて「dsl」も見つかったので、ルール6でDSL系の名前をすべて網羅することでルールを“美しく”したかったのである。

(9月18日追記)
 「役立つことはまれである」と書いてから12時間もしないうちに、改良後のルール6が役立っていた。

Sep 18 05:35:34 reject: RCPT from xdslak126.osnanet.de[85.8.99.126]: 450 4.7.1 <xdslak126.osnanet.de[85.8.99.126]>: Client host rejected: S25R check, be patient; from=<melody.foubert@christianlovelight.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<xdslak126.osnanet.de>

金曜日, 9月 14, 2007

属性ラベルホワイトリストはいかが?

 S25R方式の開発途上のころ、jpドメイン配下の属性ラベル(ac、co、goなど)を許可条件にしてはどうかというアイデアが浮かんだことがある。しかし、そのころはad.jpをエンドユーザー回線に割り当てているISPから不正メールアクセスが来ることがあり、また、ne.jpができる前からor.jpを使っているネットワークサービスサイトから不正メールアクセスが来はしないかとも懸念していた。そうこうするうちに、全世界に普遍的に通用する一般規則ができ上がって、jpドメインでしか通用しない判定条件は必要なくなった。
 このアイデアがまた頭をもたげてきた。最近はne.jp以外の属性型jpドメインからの不正メールアクセスがまったく来ないからである。次の例のような行政区属性ラベル付きの地方公共団体ドメインからも不正メールアクセスが来たことはない。

pref.kanagawa.jp
city.yokohama.jp
city.hachioji.tokyo.jp
vill.ogasawara.tokyo.jp

 そこで、属性ラベルに基づいてサイトを丸ごと信用する許可条件を設けることにより、明らかに信用できる組織のホスト名が一般規則に引っかかって誤ってブロックされるのを避けることができる。したがって、ホワイトリスト登録の手間が少し減る。
 許可条件の書き方は次のとおりである(ne.jpだけは丸ごと信用はしない)。

…(ホワイトリスト)…
…(ブラックリスト)…
/\.(ac|ad|co|ed|go|gr|lg|or)\.jp$/ OK
/\.(pref|metro|city)\.[^.]{3,}\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]{3,}\.jp$/ OK
…(一般規則)…

 ブラックリストの後に置くのは、セキュリティの甘いエンドユーザーPCをインターネットに直結させていてそこから不正メールアクセスを出すサイトや、co.jpを冠する会社があこぎな商売でスパムを送信するのが万一見つかった場合に、ブラックリストの拒否条件を優先させるためである。そのため、論文で推奨している設定ファイル構成では、属性ラベルに基づく許可条件はrejectionsファイルの中に書くことになる。許可条件を含むのにファイル名が「rejections」では気分悪いと思われる方は、「restrictions」に変えるなり、よきにはからってください。
 このアイデアは、このブログでしか書かない。「スパム対策技術」のウェブサイトで発表することは考えていない。そこには全世界に普遍的に役立つコンテンツを日英二ヶ国語で書くという方針をとっており、日本国内および日本との通信が多いサイトにしか役に立たないアイデアをそこで紹介するつもりはないからである。
 S25R方式を導入している国内サイトで、偽陽性判定を減らしたいと思っている方にはお勧めする。ただ、私自身は使っていない。自分のサイトでの偽陽性判定を避けることよりも、一般規則に引っかかるホストを見つけてホワイトリスト情報として公表することを重要視しているからである。

土曜日, 9月 08, 2007

週末の受信失敗はあきらめてもよい

 前回、休日にもログを監視した方がよいと述べた。しかし、別の考え方が浮かんだので、今回はあえて逆説的なことを言う。オンラインショッピングの確認メールが2日でリトライアウトし、週末の間に救済できなかったからといって、それが取り返しのつかないほどの問題だろうか。
 週明けにスタッフがログを確認し、リトライアウトしているアクセスを見つけたらユーザーに知らせる。ユーザーは、どうしても受けたかった確認メールだったならばオンラインショッピング会社に問い合わせればよい。
 メールサーバの運用者は、正当なメールを受信するために最善の努力をすべきであるが、最善の努力としてどこまでできるかはサイトの事情による。スタッフが自発的に休日にもリモートでログを監視してくれればそれに越したことはないが、スタッフの少ない組織サイトでは、週末にレジャーにも行けないような働きをスタッフに命令するわけにはいかない。金曜の夕方にログを確認して、必要なホワイトリスト登録をしてから帰り、月曜(3連休の場合は火曜)の朝にまたログを確認して、必要なホワイトリスト登録をする。これによって、Postfixやsendmailのデフォルト設定で5日間リトライするメールの受信は十分保証できる。そこまでが精一杯であれば、それがそのサイトの最善の努力である。スパムを受信することによるリソース消費のリスクと、リトライ期間の短い正当なメールを受け損なうリスクとのバランスや、スタッフの負担を勘案して、それでよいと判断するなら、それがそのサイトのポリシーである。
 5日よりも長くリトライするメールサーバはまずないと思われるので、長期休暇中に5日間のリトライを放置するようなことはしないでほしいが、2日以下しかリトライしないメールを運悪く週末の間にリトライアウトさせてしまったからといって、送信側に迷惑をかけたと思う必要はないだろう。リトライ期間を短く設定している送信側サイトは、受信側サーバが故障した場合に、復旧までもう少し長く待ってあげるよりも送達失敗の確率が増えるというリスクを当然承知しているはずである。送達失敗のリスクは、どうしても届けたいメールならば送信者が再送するか、受信者が知ったら送信者に再送を依頼するか、あるいは別の連絡手段をとるなどして、人手でカバーすればよいのである。
 リトライ期間の短いメールをリトライアウトさせてしまうリスクをS25R方式の問題点として批判する向きもあるかもしれないが、Postfixのオペレーションがどうにかできるくらいのスタッフしかいない、お金もないというサイトが使えるスパム対策がほかにあれば示してもらいたいものである。増える一方のスパムからネットワークリソースやユーザーの業務を守ることは多くのサイトにとって緊急課題である。応答コード「4xx」を返して送信を待ってもらうこと(言わば、一時的トラブルのふりをすること)は、リソースを守るための自衛権の範囲内である。
 S25R方式を批判することは自由だが、スパムの被害にやむにやまれずS25R方式を採用するサイトのポリシーを批判する権利など誰にもない。そのサイトが、正当なメールを受け入れるために最善の努力をしている限りは。

月曜日, 9月 03, 2007

休日にもログを監視した方がよい

 送信側メールサーバは、受信側メールサーバへのアクセスに対して応答なしの場合(ネットワークの不通や、サーバの故障か停止が考えられる)、コネクション拒否応答が返された場合(MTAデーモンが停止していることが考えられる)、応答コード「4xx」が返された場合(クライアントの逆引きや送信者ドメインのDNS検索に失敗した場合、メールボックスに一時的に書き込みができない場合、グレイリスティングにかけられた場合など)に、適度な時間間隔で送信をリトライする。リトライ期間は、古くから使われているsendmailのデフォルト設定では5日である。Postfixでも同じである。
 リトライ期間のデフォルトがなぜ5日なのか。かなり運悪く長時間にわたってメールサーバのトラブルが続いたというケースを想定してみよう。
 企業や学校などで、金曜の17時にスタッフが帰った後、運悪く18時にハードディスクが故障した。さらに運悪く、月曜は祝日だった。火曜の朝、スタッフが出勤して故障に気付き、サポート業者を呼んだ。午後になってサポート業者が到着。ディスクを交換して、システムを再構築し、バックアップからデータを復元して、動作試験。復旧したのは20時だった。ダウン時間は4日と2時間。送信側メールサーバが5日間リトライするようになっていれば、こういうケースでもメールは届く。
 ゴールデンウィーク、1週間の夏期休暇、または年末年始の期間中にサーバの監視をまったくしなかった場合は、ダウン時間が5日を超えることがありうる。しかし、リトライ期間をあまり長く設定すると、ついにメールが送達しなかった場合に送信者がそれを知るのが遅くなってしまう。5日間のリトライ期間は、デフォルト値としてちょうどよいだろう。
 リトライ期間は、Postfixではmaximal_queue_lifetimeパラメータ(バウンスメールについてはbounce_queue_lifetimeパラメータ)で設定できるが、通常のメールサーバでは、あえてデフォルトから変更している人は少ないだろうと思う。ただ、5日というデフォルト値が決められたのは、インターネットの黎明期。相手サーバは故障しているかもしれないから気長に待ってあげようという心が背景にあったと考えられる。インターネットを使ったビジネスが忙しくなった今は、そこまで悠長に待ってはいられないと考える人がいても不思議はない。
 S25Rのルールに引っかかる、オンラインショッピングの確認メール送信サーバが2日でリトライアウトするケースがあることがわかった。素のS25R方式を使っている組織サイトで、週末にスタッフが不在になる場合、金曜の夜に送信が開始されたメールは日曜の夜にリトライアウトしてしまう。オンラインショッピングの確認メールは、受信者にとって受け損なうと困る大事なメールである。
 私は毎日朝と夜には拒絶ログソーティングスクリプトでリトライアクセスの有無を確認している。旅行中にも(PHSの電波が届かない所へ行かない限りは)毎日モバイルで確認している。だから、1日以上リトライしてくれるメールは受信できる。しかし、素のS25R方式を使う組織サイトにとっては、3連休があることを考えればせめて4日はリトライしてほしいところだろう。
 とはいえ、インターネットの世界では、サイトのポリシーの自由がある。S25R方式を採用するのも自由なら、リトライ期間を2日に設定することも自由である。S25Rに引っかかるすべての他サイトに4日以上のリトライあるいは逆引き名の変更を要求することは非現実的である。自サイトのポリシーに伴う副作用の問題は、他サイトのポリシー変更を要求することによってでなく、自らの努力で解決すべきである。
 私が協力者からの情報も集めて公開しているホワイトリスト情報を利用すればめったなことはないとは思うが、それでも休日にも一日一度はリモートでログを監視した方がよいだろう。
 さもなければ、Rgreyなどでホワイトリスティングを自動化することを考えた方がよい。リトライするスパムがすり抜けてしまうおそれがあるが、私のサイトでの観測によれば、受け入れまでの遅延時間を25分に設定すればほぼ防げることがわかっている。また、正当なメールが25分未満でリトライアウトするケースは見つかっていない。
 なお、正当なメールが1時間ほどでリトライアウトするケース(メールマガジン携帯電話サイトからのエラーリターン)があることがわかっているが、これは素のS25R方式では、あらかじめホワイトリスト情報を取り込んでおくことでしか救済しにくい。素のS25R方式を使う組織サイトでは、こういうリスクがあることをユーザーに説明しておいた方がよい。また、救済できなかったリトライアクセスを見つけたらユーザーに知らせるようにした方がよい。
 もっとも、送信側が1時間ほどでリトライアウトするということは、受信側サーバの故障あるいはメンテナンスにぶつかってもメールを届けたいという意思がないということだから、受け損なっても大して問題のないメールだと考えてよいと思うが。

土曜日, 9月 01, 2007

宛先の正しいスパムが増えた

 2007年8月には、不正メールの送信元ホストは4863個だった。6月には6158個だったのに比べて減っている。一方、宛先の正しい不正メールの送信元は1244個で、6月には575個だったのに比べて2倍以上に増えている。しかし、受けてしまったスパムは増えなくて10通、送信元ホスト数は8個だった。

■全不正メールの送信元(4863個)
●一般規則で4671個(96.1%)。
●ブラックリストを合わせて4777個(98.2%)。
違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
変なReceivedヘッダの検出で3個増加。

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

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で20個増加。

以上の合計で阻止数は4801個(98.7%)。
 反則技以外のフィルタによる阻止率98.3%は、6月の98.4%とほぼ同じである。反則技による阻止を含めた98.7%は、6月のデータと変わっていない。

■宛先の正しい不正メールの送信元(1244個)
●一般規則で1142個(91.8%)。
●ブラックリストを合わせて1221個(98.2%)。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
●変なReceivedヘッダの検出で3個増加。

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

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で11個増加。

以上の合計で阻止数は1236個(99.4%)。
 すべてのサイトにお勧めできるわけではない反則技を使わないとした阻止率は、6月には、全体で98.4%、宛先の正しい不正メールについて95.8%。それ以前も、全体の阻止率よりも宛先の正しい不正メールの阻止率が低かった。ところが8月には、宛先の正しい不正メールの送信元が2倍以上に増えるという変化があり、全体の阻止率は98.3%、宛先の正しい不正メールの阻止率はそれよりもわずかに高い98.5%になった。反則技を含めて99.4%とびっくりする値になり、受信したスパムは増えなかった。宛先の正しい不正メールが激増したとはいっても、ほとんどはエンドユーザーコンピュータからの送信の増加だったために、その阻止率は全体の阻止率に近い値になり、すり抜けは増えなかったと考えられる。