水曜日, 12月 13, 2006

逆引き論争

 reject_unknown_clientはスパム対策として有害だという主張がある。そのとおり。ログも確認せず、逆引きできない送信元ホストを蹴りっぱなしにする運用は有害である。しかし、ログを見て、逆引きできないホストからのリトライアクセスを見つけてホワイトリストで救済するならば、reject_unknown_clientは有害ではない。
 対して仙石さんは、「(送信元の)素性を調べる手段としてDNS逆引きは、ある程度の合理性を持つ」と主張しておられる。まったく同感である。ただ…
 「逆に言うと、弊害をきちんと理解していれば、DNS逆引きの結果を迷惑メール判定に用いることは受信側の判断だろう。DNS逆引きができないホストからメールを送らざるを得ないサイトにとっては釈然としないところもあるとは思うが、受け取らない権利があるのもインターネットである。」――いや、受信側は、正当なメールを受信するために最善の努力をすべきである(「逆引きできないホストからの正当なメールを受け取らないのも受信側のポリシーとして認められる」という解釈は仙石さんの本意ではないと信じるが)。
 「「まともに管理されているホストに逆引きがないというのもふつうに存在する」のは事実だと思うが、「まともに管理している」ということを通信相手に伝える努力はすべきではないだろうか?通信はお互いの協力があって初めて成り立つものであるから、spammerと区別してもらうための努力もせずに、spammerと一緒にするなと叫んでいるだけでは解決にならない。もちろん、spammerと区別してもらう方法がDNS逆引きの設定だけであると主張するつもりはない。」――確かに、まともに管理していることを送信側が逆引きによって伝えてくれれば、スパム対策をする受信側としてはうれしい。しかし、努力というほどのことを受信側が送信側に求める必要はない。送信側はただ、まともなMTAを使っていてくれればよい。それで、逆引きできなくてもリトライの検出によって、まともなメールサーバであることがわかるから。
 S25R方式のコンセプトは、逆引きできない正当なメールサーバがあるという現実を認めている。逆引き名からアクセス元をエンドユーザー回線と推定するルールを定めているが、それに引っかかる正当なメールサーバがあることも承知している。正当なメールサーバを蹴るリスクがあるから、蹴る時に返す応答コードは「450」である。送信をある程度遅延させることは送信側に受忍していただくが、リトライを検出して正当なメールを救済するのは受信側の努力で行う。
 送信側に対して「逆引きを設定してくれ」などとは要求しない。まして「S25Rの拒否条件に引っかからない逆引き名にしてくれ」などという傲慢なことは言わない。そんなことを他人に要求して対処を待つよりも、自分が選んだ対策方法に伴う副作用の問題はさっさと自分の手で解決する方が早い。その覚悟があれば、すぐにも非常に効果的にスパムを排除できるのである。
 S25R方式は、逆引き検査によるスパム対策は是か非かという論争をとっくにアウフヘーベンしてしまっていると思うんだけどなあ。

(関連記事)
DNS逆引きチェックは有効なスパム(迷惑メール)対策

月曜日, 12月 11, 2006

taRgrey

 佐藤さんtaRgreyを公開された。
 S25Rの拒否条件に引っかかる送信元にまず65秒程度のtarpitting(応答遅延)をかける。ほとんどのスパムウェアは、応答を待ちきれずに勝手に切断する。正当なメールサーバはちゃんと応答を待つので、グレイリスティングによるよりもはるかに短い遅延でメールを受信できる。tarpittingを抜けられないごく少数の正当なメールサーバは、再送してきた時にグレイリスティングで救済する。これによって、自動的に偽陽性をほぼなくすことができる。スパムの阻止率を多少犠牲にしてでも正当なメールを確実に受信すべきISPには適した方式だと思う。
 ところが、いざ発表してみると、佐藤さんの元々の狙いに反して、スパムの阻止率を上げるためにtarpittingとグレイリスティングの両方をかけるという需要の方が多かったのだそうである。そこで、taRgreyでは救済重視の「taRgreyモード」と阻止率重視の「tarpit & greylistモード」が提供されている。
 tarpit & greylistモードでは、S25Rの拒否条件に引っかかる送信元に対してtarpittingとグレイリスティングの両方の試練を与える。この需要が多いということは、よほどスパムを憎む人が多いのだろうか。S25Rの偽陽性率はホワイトリストなしでは約13%もある(11月29日「偽陽性率」)と知ってもなお、正当なメールサーバの13%にそこまでの試練を与えたいだろうか。私は「そこまでやる?」と思ってしまう。
 S25Rの拒否条件に引っかかるホストからのメールはグレイリスティングで30分ほど遅延してもかまわない、再送のたびにIPアドレスが変わるケース(9月1日「グレイリスティングを抜けられないサイト」)は手動のホワイトリスト登録で救済すればよいという考え方なら、Rgreyを使えばよいのではないかと思うのだが。うーん、どんなものでしょうねえ。
 なお、ついでに言うと、「tarpitting」は英語の辞書にないが、「tar pit」(タールの穴)が語源らしい。

(12月12日追記)
 佐藤さんのブログ記事に書かれていることを見落としていた。佐世保高専の中原さんの測定によると、スパムの阻止率はtaRgreyモードで約96.5%、Rgreyで約97.0%、tarpit & greylistモードで約98.5%だそうである。やっぱりtarpit & greylistモードの阻止率は高いらしい。

金曜日, 12月 08, 2006

偶発的な逆引き失敗

 12月1日「スパムは増える」で、勤務先に届くスパムをBecky!でフィルタリングして偽陽性判定は10月以来ゼロだと書いたが、嘘だった。すみません。(_"_) 逆引きできる送信元の逆引きまたはパラノイド検査が一時的に失敗してごみ箱に振り分けられたことがあったのを思い出した。
 送信元ドメインのプライマリDNSサーバもセカンダリDNSサーバもあるのに、一定時間内にDNSクエリーが解決しないことがまれにある。いつも届いている相手からのメールはごみ箱に入らないものと思い込んでいてはいけない。ごみ箱に振り分けられたメールの一覧は毎日チェックする必要がある。
 そういえば、自宅サイトでも同じことがあった。逆引きできて、いつもはちゃんと受け取っている送信元サーバをunknownで2回蹴って、3回目に1時間の遅延でようやく受信していた。
 まあ、こういうこともある。受信できるから問題ない。遅延がいやだと思う人は、S25R方式なんか使わない方がよい。

月曜日, 12月 04, 2006

リトライするスパムが減った

 8月28日「リトライするスパムをRgreyで蹴る」で、約5分間隔で5回トライするスパムアクセスがけっこうあることを述べた。ところが、この1ヶ月、私のサイトではそのようなスパムアクセスをまったく見かけなくなった。
 11月5日以降のログでは、リトライしたスパムアクセスは次の1件だけで、2回のトライで終わっていた。

Dec  1 05:59:01 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]
Dec  1 06:06:32 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]

 もしかしたら、5回トライするスパムアクセスは特定のウィルスによるもので、その駆除が進んだからかもしれない。
 前述の記事では、postgreyの--delayオプションに指定する遅延時間を1500秒(25分)に設定することを勧めたが、600秒(10分)程度に緩めてもよいかもしれない。

日曜日, 12月 03, 2006

注意点も公表

 「スパム対策技術」の目次ページの先頭にS25R方式の要点を掲示しているが、これを少し書き換えた。全不正メールアクセスに対する阻止率は99%だが、宛先の正しいスパムの阻止率はやや低くて97%であること。それに、注意点として、初期の偽陽性判定率が13%と高いことも書いた。13%という値は、わずか142個のホストから算出したものなので(11月29日「偽陽性率」)精度が粗いと思うが、おそらく大規模サイトでの統計からさほどかけ離れてはいないだろう。
 また、10月から、論文のページの先頭に「このページへ直接来られた方は、目次ページもご覧ください。」と書き加えている。論文だけでなく、ホワイトリスト情報、導入者の皆様の声、このブログ、ボランティアの方々による工夫などの情報を総合的に見てほしいからである。
 論文の上っ面だけを読んで批判されるのも不本意だが、副作用のリスクをちゃんと理解せずに導入されるのも困る。Googleで「スパム 対策」で検索すると論文が1位にヒットするが、そこから目次ページへ誘導すれば、S25R方式をより正しく理解してくれる人が増えるだろうと期待している。

土曜日, 12月 02, 2006

スパムの総数が増えれば

 BBSで相談を受けた。S25R方式を導入して最初のうちは効果があったのだが、すり抜けるスパムが増えてきたので、何か良い方法はないかということだった。
 一日に受けたスパムが6通とのこと。送信元のFQDNを見ると、8月7日「ホスト名「nat」」で述べた方法で阻止できるものが2通、一般規則のルール1を緩めていたためにすり抜けたものが1通、残りはどうにもならないものだった。一般規則をすり抜けるホストからスパムが繰り返し来るならブラックリストに登録すればよいが、そういうことはあまりない。
 すり抜けが増えたのは、単にスパムの総数が増えたからに違いない。宛先の正しいスパムの阻止率は約97%だから、100通のスパムが押し寄せれば3通、200通が押し寄せれば6通ほどがすり抜けるのはやむを得ない。8月25日「今なお阻止率99%」で述べたように、S25R方式の効果が衰えているわけではないのである。
 私の自宅サイトは、S25R方式の開発期間を含めて3年以上にわたって固い防御を保っている。それで、前回述べたように、スパムの総数は増える一方なのに、着信するスパムは減少傾向にある。拒否応答を返し続けていれば、そのうち敵はだんだんあきらめるようになるだろう。

金曜日, 12月 01, 2006

スパムは増える

 勤務先のアドレスに届いたスパムは、9月には510通、10月には847通、11月には1570通だった。なんと、2ヶ月で3倍になっている。この増加ぶりには、もう笑っちゃうしかない。
 とはいえ、Becky!でのフィルタリングがうまくいっているので、ストレスは感じない。11月の見逃し数は37通(2.4%)。つまり判別率は97.6%。8月23日から9月22日までの1ヶ月間で計った判別率97.0%(9月23日「Becky!でのフィルタリング」)からほとんど変わっておらず、むしろわずかに上がっている。見逃しは一日にせいぜい数通。まったくない日もある。除外条件(ホワイトリスト)の登録は6件で、偽陽性判定は10月以来ゼロである。S25R方式を応用したフィルタリングがスパムを正確にごみ箱に放り込んでくれるのを見るのは、むしろ快感である。フィルタリングの条件の指定に正規表現を使えるBecky!のおかげである。Becky!万歳!
 さて、自宅サイトの方はどうかというと、11月に不正メールを送り込もうとしたホストは7245個(うち3個からスパムが着信した)。7月には4423個だった(8月25日「今なお阻止率99%」)のに比べて、やはり増えている。
 ところが、奇妙なことに、宛先の正しい不正メールの送信元ホストが7月には305個だったのが、11月には192個に減っていた。着信したスパムは、7月には8通、8月には10通だったが、9月には6通、10月には4通、11月には3通と減ってきている。勤務先での受信数の急激な増加とは対照的である。やはり、9月28日「拒絶の効果?」で述べたように、送達率を重視するスパマーが私の自宅サイトへの送信をだんだんあきらめてきているとしか思えない。S25R方式万歳!

水曜日, 11月 29, 2006

偽陽性率

 S25R方式の偽陽性率をどう評価しようかと考えた末に、正当な受信メールの送信元ホストを拾い上げてみた。2006年1月以降、11月28日までに受信したメールの送信元は142個。そのうち、S25Rの一般規則に引っかかるホストは19個だった。ここから計算した、ホワイトリストがないものと仮定した偽陽性率は13.4%である。意外な高さに今さらながら驚いた。
 とはいえ、偽陽性率の高さに手を焼いているわけではまったくない。1サイトのメールマガジンを受信し損ねたことがある(8月30日「リトライを短時間でやめるサーバ」)のを除いて、以前から登録してあったホワイトリスト、新たに登録したホワイトリスト、および協力者から報告されたホワイトリストのおかげで、苦もなく受信に成功している(もちろん、メールトラフィックが少ない個人サイトだから苦労がないのだが)。正規表現によるホワイトリスト登録1件で複数のホストを救済するケースもあり、19個のホストを救済したホワイトリスト項目は14件であった。
 一方、9月15日「宛先の正しいスパムの阻止率」で報告したとおり、2006年7月の統計では、宛先の正しいスパムの阻止率はトータルで97.4%であった。すなわち、偽陰性率(見逃し率)は2.6%である。
 スパム判定においては、偽陰性判定よりも偽陽性判定の方が有害である。スパムの阻止に失敗するよりも、正当なメールを受けられないことの方が困る。では、偽陰性率よりも偽陽性率の方が高いS25R方式は有害な方式か。決してそんなことはない。
 S25R方式では、偽陽性判定は致命的なものではなく、リトライアクセスを発見してホワイトリスト登録すればメールを受信することができる。そして、そのホストからのメールを阻止することは二度となくなる。ホワイトリスト登録が進むにつれて、偽陽性率はゼロに近付いていく。
 偽陰性率は初めから十分に低い。メールの90%以上はスパムだと言われる現在、偽陰性率の低さはやはり重要である。そして、偽陽性率は、ホワイトリスト登録によって(素のS25R方式ではそのために労力はかかるものの)どんどん下がっていく。偽陽性を減らすために偽陰性率の低さを犠牲にする必要がない。つまり、スパム対策方式としての実用性が高いのである。このことこそ、S25R方式が多くの人々に支持されている理由に違いない。

日曜日, 11月 26, 2006

DNSWLはいかが?

 S25R方式は、スパムの阻止率が高い代わりに、組織サイトでは初めのうち偽陽性判定が多い。500~1000件のホワイトリスト登録が必要だと聞く。それなら、ホワイトリストデータベースを共有するようにすれば運用が楽になるのではないかという発想が出てくる。
 そこで、DNSBLならぬDNSWL(DNS White List)というものが世の中にあるかどうかと思って、何気なく検索してみた。すると、そのものずばりのサイトがあった。dnswl.orgである。そのホームページにはこう説明されている(誤訳があったらご指摘ください)。

dnswl.orgとは?
 dnswl.orgは、善良とわかっている送信元のIPアドレスのリストを提供します。このデータは、これらの送信元からのメールがスパムフィルタに偶然つかまったり、偶発的あるいは誤った阻止リスト登録によって阻止されたりしないことを保証するために使うことができます。
 このリストは、メール管理者やスパムフィルタ管理者がホワイトリストを手動で保守する労力を最小化するのに役立ちます。dnswl.orgは共同作業です。つまり、善良な送信元を識別するのに皆さんの援助が必要です。また、リストにある送信元の一つが善良でないとわかったら、知らせてください。
 データは複数のカテゴリー(財団やその他の大企業、インターネット/メールサービスプロバイダなど)について入手でき、各項目は「低」、「中」、「高」に点数付けされています。各管理者は、これらの点数をどう適用するかについて自分自身のルールを選ぶことができます。
 このリストは、DNSによって、また、いくつかのダウンロードフォーマット(プレーンテキスト、rbldnsdフォーマットテキスト、コメント付きテキスト)で提供されます。

 DNSBLよりも役に立つかもしれない。
 ただし、おそらく、S25R方式の導入サイトがすぐに使えるものではない。S25R方式特有のルールによって阻止されるホストがかなりあるからである。S25R方式の導入サイト(それも、かなりの規模の組織サイト)の誰かがボランティアでデータを提供する必要がある。
 また、これが広く使われるようになると、スパマーがスパム送信コンピュータをホワイトリスト登録するおそれがある。悪意ある者によってデータが汚されるのは、ブラックリストにせよホワイトリストにせよ、不特定の人々の共同作業で作るデータベースではどうしても生じるリスクである。

金曜日, 11月 24, 2006

DNSBLの利用価値はあるか?

 「IPアドレスを手がかりにしてスパム判定するなら、すでにDNSBLがあるではないか」と言う人がいる。しかし私は、S25R方式の方が使いやすいと思う。
 DNSBLは、スパム送信の前科のあるIPアドレスをブラックリストに登録する。しかし、前科がなくても、悪意のないインターネットユーザーのPCがウィルス感染でゾンビ化してスパムの送信元になるおそれがある。ゾンビPCが次から次へと生まれれば、ブラックリスト登録は後追いになる。S25R方式なら、前科の有無にかかわらず、エンドユーザー回線からと推定されるSMTPアクセスに対して一時的拒否応答を返すので、かなりの確度でスパムやウィルスメールを阻止することができる。
 また、DNSBLでは、正当なメールサーバがスパム送信元の巻き添えを食らってブラックリストに登録されてしまうことがある。そのため、今まで届いていたメールが突然拒否されるようになるおそれがある。ブラックリストのデータが古いままで、あるいはデータベースのトラブルでデータが過去に巻き戻ってしまって、無実のメールサーバを拒絶することもあると聞く。S25R方式ではそのような心配はない。拒否や許可のルールはローカルな設定で決めるからである。初めてメールを送ってくる正当なメールサーバを誤って蹴ってしまうことはあるが、再送アクセスが来ている間にホワイトリスト登録した後は、二度と蹴ることはなくなる。
 S25R方式にDNSBLを併用するという方法はどうだろうか。併用の方法には、阻止率を上げる(偽陰性を減らす)ためと、偽陽性を減らすための二通りの方法が考えられる。
 阻止率を上げるためにDNSBLを併用するには、S25Rの阻止条件に引っかからなかったホストをDNSBL検査にかけることになる。しかし、これはあまり効果がないと思う。S25Rをすり抜けるスパムには、ISPのメールサーバを経由したものや、一時的に乗っ取られたサーバから送信されたと思われるものが多い。私のサイトでの観測では、サーバっぽい逆引き名の同じホストから繰り返しスパムが来たことはほとんどない。DNSBLに頼っても、阻止率は、S25Rによる阻止率(全不正メールアクセスについて99%、宛先の正しいスパムについて97%)よりもさらに大きく向上することはないだろう。むしろ、ISPのメールサーバや、乗っ取られた後に対処されたサーバがDNSBLに残り、偽陽性が増えるおそれがある。
 偽陽性を減らすためにDNSBLを併用するには、S25Rの阻止条件に引っかかったホストをDNSBL検査にかけて、それに引っかからなかったホストを許可することになる。この方法では、ゾンビ化したばかりのPCからのスパムを受けてしまうおそれがある。定量的評価はしていないが、阻止率はかなり下がってしまうのではないかと思う。
 結局のところ、DNSBLを使う積極的な理由は見出せない。「S25R+グレイリスティングという対策をとっていれば、今さらDNSBLを使う必要は感じない」と言う人もいる。私もそう思う。

木曜日, 11月 23, 2006

訳語

 「false positive」に「偽陽性」、「false negative」に「偽陰性」という訳語があることを知った。元々は医学用語で、病気がないのに病気の反応が出るのが偽陽性、病気なのに反応が出ないのが偽陰性である。医療では偽陰性の方が危ないが、スパム判定では偽陽性の方が危ない。
 せっかく訳語があるのだから、使うことにしよう。
 ついでに言うと、この場合の「positive」「negative」は可算名詞であり、英作文では単数なら不定冠詞「a」、複数なら語尾「s」を付ける必要がある。

土曜日, 11月 18, 2006

Debian whitelister

 佐藤さんからの情報。DNSBLに引っかかったホストをグレイリスティングに回すのは、Debianのwhitelisterというパッケージでできるそうである。

木曜日, 11月 09, 2006

maps_rbl_reject_code

 Postfixのsample-smtpd.cfファイルに次のような記述を見つけた。

# The maps_rbl_reject_code parameter specifies the SMTP server response
# when an SMTP client request is blocked by a reject_rbl or reject_rhsbl
# restriction.
#
# Do not change this unless you have a complete understanding of RFC 821.
#
maps_rbl_reject_code = 550

デフォルトの応答コードは「550」だと読み取れるが、実際のデフォルト値をpostconfコマンドで調べてみたら…

$ postconf | grep maps_rbl_reject_code
maps_rbl_reject_code = 554

 前回の記事「「5xx」で蹴るなんて」で、DNSBLを全面的に信頼して「5xx」で蹴ることが信じられないと書いたが、なんとその元凶はPostfixのデフォルト値だった。
 PostfixでDNSBLを利用している人は、ぜひmain.cfファイルに

maps_rbl_reject_code = 450

を追記してほしい。sample-smtpd.cfファイルには「RFC 821を完全に理解していない限り変えるな」と書いてあるが、びびることはない。
 もちろん、まめにログを監視して、正当なメールサーバからのリトライアクセスを発見したらホワイトリスト登録するように運用すべきである。リトライアクセスを発見しやすくするためには、私の拒絶ログソーティングスクリプトが使える。あるいは、グレイリスティングに回してもよいが、どうやればよいのかは知らない。

火曜日, 11月 07, 2006

「5xx」で蹴るなんて

 S25R方式でメールを蹴られて困っている人がいるという情報(10月29日「大手ISPに導入されたらしいが…」)を佐藤さんから聞いたきっかけは、佐藤さんが運用するサイトがSpamhausのDNSBLに登録されてしまったという事件だった。もちろん佐藤さんのサイトがスパムを発信するわけはないのだが、近隣のIPアドレスからスパムが発信されたため、巻き添えをくらってネットマスク22ビット(1024個ブロック)で登録されてしまったらしい。そのため、佐藤さんのサイトからのメールが、Spamhausを利用しているサイトで受信拒否されてしまったのである。
 何の応答コードで蹴られたかと質問したら、「5xx」だったと聞いてびっくりした。なぜそこまで他人のデータベースを信用できるのだろうか。今回のSpamhausのように、多数のIPアドレスからスパムが発信されたら、それらを含むIPアドレスブロックをまとめてリストに登録してしまうケースもある。ましてDNSBLは、登録されたIPアドレスからスパムしか発信されないと保証しているわけではない。DNSBLに登録されたIPアドレスから正当なメールが送信されることもありうるということを考慮すべきである。
 DNSBLの情報に基づいてアクセスを蹴るなら、「4xx」を返して様子を見るべきである。さもないと、他サイトの善良な送信者を困らせるし、そのメールを受信するはずだった自サイトの受信者にも不利益をこうむらせることになる。
 S25R方式のコンセプトで重要なことは、送信元のIPアドレスの逆引き結果に基づいて不正メールアクセスの疑いを推定するが、あくまでも推定であって、決して確信しないということである。だから、誤って阻止される正当なメールを救済する余地を残すために、応答コード「450」を返すのである(企業や学校でポルノサイトからのスパムを阻止するような場合はこの限りではないが)。
 S25R方式に対して、個人サイトを排除するやり方だという批判がいまだにあるが、S25R方式のコンセプトは決してそのようなものではない。私は、ダイナミックIPアドレスの個人サーバから直接送信するのはやめてほしい、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えてほしいと主張してはいる(論文および7月29日「個人サーバ」)。しかし、ダイナミックIPアドレスのサーバだからといって「5xx」を返すことを勧めてなどいない。実際私は、ダイナミックIPアドレスのサーバからのメールもホワイトリスト登録して受信している。
 S25R方式は正当なメールを排除するという批判は誤りである。批判されるべきは、スパムの受信が減ったことで満足してしまって、正当なメールを拒絶する副作用のリスクを省みないという、間違った運用である。それは、S25R方式を使うにせよDNSBLを使うにせよ、同じことである。

水曜日, 11月 01, 2006

Starpitが採用される

 佐藤さんのStarpitTCNWEBのメールサービスに採用された。すばらしい!

日曜日, 10月 29, 2006

大手ISPに導入されたらしいが…

 佐藤さんから聞いた話。IPアドレスの割り当て1個の接続サービスを利用している会社から某大手ISPにメールを送ろうとしたら、リトライアウトでエラーリターンしたとのこと。先月(9月)のことである。そこに示されたエラーメッセージは、「may not be mail exchanger」という、私が作ったものだった。応答コードは「450」だった。
 このメッセージ文で検索すると、困っている人の情報が得られると佐藤さんに言われて、検索してみた。そのISPへのメールのエラーリターンに「550」の応答コードが示されているのがさらされていた(日付はやはり9月だった)。これには驚いた。
 裏を取ろうと、ダイヤルアップ接続で手動のSMTPアクセスをかけてみた。RCPT TOコマンドに対する応答コードは「250」。拒否していない。私がダイヤルアップ接続に使っているISPのダイヤルアップ用IPアドレスの逆引き名はルール5(逆引きFQDNが5階層以上で、下位2階層の名前がともに数字で終わる)に引っかかるが、もしかしたらルール5を入れていないのかもしれない。私は8個ブロックのIPアドレスをもらっていて逆引き権限の委譲を受けているので、予備サーバのIPアドレスの逆引き名を「219-163-213-19.rev.reto.jp」とS25Rに思い切り引っかかるものに変えて、予備サーバからアクセスしてみた。「450」で蹴られた。「550」を返していたという裏は取れなかった。
 それにしても、正当なメールをリトライアウトさせてしまったとはどういうことだろう。通常のMTA(くだんの会社ではqmailを使っているとのこと)なら数日間リトライする。その間ずっと、ログを確認せずに放置していたのだろうか。
 私は、善良な送信者や受信者をハッピーにするためにS25R方式を発表したのである。善良なユーザーを困らせてはいけない。正当なメールを「450」で蹴ってしまうというリスクをちゃんとコントロールしてくれなければ困る。正当なメールを救済することには真剣勝負の覚悟で取り組んでほしい。リトライのログを確認しやすくするために、私は拒絶ログソーティングスクリプトを提供している。まめにログを確認することができないなら、Rgreyなどでリトライアクセスの救済を自動化することを考えてほしい。それさえしないなら、S25R方式は使わないでほしい。
 大手ISPでもS25R方式が導入されたとは光栄なことではあるが、正しく運用してくれているのだろうか。導入初期に失敗はあったけれども今はうまくやっていると信じたいが。
 そのISPはS25R方式の導入を公表していないので、私がここで社名を公表するのは差し控える。もっとも、私が作ったメッセージ文で検索すればわかってしまうけれども。

土曜日, 10月 21, 2006

無精者の勝利

 2001年3月、sendmailから、設定の楽なPostfixに乗り換えた。
 2001年8月、悪気のない未承諾広告メールを2度送ってきた業者に対して拒絶の意思を伝えようと考え、header_checksパラメータでFromヘッダをチェックしてエラーリターンさせるようにした(今にして思えば、smtpd_sender_restrictionsパラメータを使ってもよかったのだが)。これが私のスパム対策の始まりである。
 2001年10月、同じ文面でFromアドレスを変えたスパムが2通来た。body_checksパラメータで、スパマーが宣伝しようとするウェブサイトのURLを引っかけてエラーリターンさせることを思い付いた。
 その後1年あまり、この方法はうまくいっていた。着信するスパムがあまりに少なくなって、スパム防御策を研究しにくくなって面白くなくなった。そこで、2003年3月、見えないmailtoアンカーにおとりのアドレス(User unknownになる)を書いてホームページに仕掛けた。さっそく引っかかった奴が現れたので楽しかった。
 2003年5月、着信するスパムが急に増え始めた。次々に来るスパムに防御が追い付かなくなった。また、URLに十六進文字符号を混ぜたり、本文全体をBASE64符号化したりするスパムもあった。内容チェックによる防御策に見切りを付けた。
 内容チェックを高度化したベイジアンフィルタという技術があることは知らなかった(そのころすでに一般化していたのかどうか、今も知らない)。根が無精だから、世の中にどんなスパム対策技術があるのかをつぶさに調査することもしなかった。もっとも、もしベイジアンフィルタを知っていても、使いはしなかっただろう。受けてからフィルタリングする方法では、拒絶の意思をスパマーに思い知らせることができない。拒否応答を返さなければ気がすまない。悪人に対してはサディスティックなのである。
 多くのスパムに共通することは何かと観察して、送信元のIPアドレスに着目した。ほとんどのスパムはエンドユーザー回線から直接送信されており、その多くは逆引きできないことがわかった。smtpd_client_restrictionsパラメータを使うことを覚え、「reject_unknown_client」を指定したら効果てきめんだった。また、逆引きできるエンドユーザー回線には逆引き名にIPアドレスを反映したものがかなりあることに気付いた。そこで、ハイフンかドットで区切られた4個の数字列が逆引き名に含まれていたら蹴るように正規表現を書いた。リトライする正当なメールサーバを救済する方法もマスターした。S25R方式の開発はここから始まった。個人サーバだから、思い切った試行錯誤ができた。
 根が無精だから、楽をするためには労苦を惜しまない。たくさんの不正メールアクセスを観察しながら、なるべく多くのエンドユーザー回線を引っかけることができて(つまり、ブラックリスト作成の手間が少ない)、メールサーバを引っかけることがなるべく少ない(つまり、ホワイトリスト作成の手間が少ない)正規表現を作り上げた。この方式でよいと判断したのは、10ヶ月後の2004年3月だった。スパムだけでなくウィルスメールもほとんど阻止できる方式ができ上がった。
 スパマーの立場に立って、S25R方式を破る方法も考えた。少量のスパムなら、ISPのメールサーバを経由するなどして送り込むことができるが、S25R方式の防御を破って大量のスパムを届かせることは、スパム送信コンピュータのリソース負荷が大きくなってきわめて難しいと結論付けた。簡単に破れる方式でも、大量スパムの90%以上を阻止し続けることができれば、それは勝利である。
 私のような無精者が考え付くことはすでに世界の誰かが作っているのではないかと思ったが、不思議なことに、あちこち情報を検索しても見つからなかった。
 もし私がベイジアンフィルタの発明者だったら…。もし私がもっと頭が良くて勤勉で、高度な数学を駆使することができて、内容チェックを高度化する道を突き進んでいたら…。宣伝文を画像化するというあまりにも簡単な方法で破られることに気付かされた時、「ああ、私の今までの努力は何だったのか」と嘆き悲しみ、絶望のあまりに憤死していたに違いない。
 無精者だからできる発明もある。

火曜日, 10月 17, 2006

パラノイド検査

 S25R方式を導入された方から、「送信元ホストが逆引きできるのにPostfixで『unknown』になることがあるのはなぜ?」という質問を受けた。
 私はすぐにパラノイド検査の結果を疑った。案の定、逆引き名を順引きしたらIPアドレスが検索されなかった。
 Postfixは、逆引き名を順引きした結果が元のIPアドレスに一致するかどうかまで見る。これをパラノイド(猜疑的)検査という。逆引き名を偽造することは簡単にできるので、パラノイド検査をパスしないと逆引き名を信用しないようになっているのである。パラノイド検査をパスしなかった場合は、逆引きできなかった場合と同じく「unknown」として扱われる。sendmailもやはりパラノイド検査を行っており、逆引きできたら逆引き名はReceivedヘッダに記録するが、パラノイド検査をパスしなかったら「(may be forged)」(偽造かもしれない)と付記する。
 以前、BBSで、「スパム対策のためにはパラノイド検査は不要だ」という意見を書かれた方がいる。ISPで逆引きが管理されている場合はユーザーが逆引き名を偽造することはできないし、スパマーが逆引き権限を持って逆引き名を偽造してスパムを送信した場合はIPアドレスに基づいてブロックすればよいからだという。パラノイド検査をやめた方が、世界のDNSサーバにかかる負荷を減らすことができる。確かにもっともだとは思うが、それを言ったところで、MTAのユーザーである我々としては、MTAの仕様を受け入れるしかない。
 それに、もしPostfixにパラノイド検査をやめるオプションが設けられたとしても、私はそれを使わないだろう。もしかしたら、悪者が逆引き権限を持って逆引き名をたとえば「mail.microsoft.com」と偽造し、マイクロソフトからの案内であるかのように偽ってウィルスをばらまくかもしれない。Receivedヘッダに逆引き名がそのまま記載されたら、受信者には、本当にマイクロソフトから送信されたメールであるかのように見えてしまう。このやり方は詐欺メールにも使える。「unknown」と記載されるか、「(may be forged)」と付記された方が、受信者がだまされないためには安全である。
 DNSサーバの負荷の問題は、さほど心配する必要はないと思う。負荷が問題になったらDNSサーバを増強すればよい。最も負荷がかかると思われるルートサーバの数も増えている。ルートサーバの名前はa.root-servers.netからm.root-servers.netまでの13個であり、これはUDPパケットの長さの制限のために増やせないのであるが、実はルートサーバの台数はもっと多い。anycast(相手任意の通信)という通信技術によって、同じ名前、同じIPアドレスのサーバを数台ずつ世界に分散配置することが可能になっているのである。

火曜日, 10月 10, 2006

SQLgrey

 佐藤さんのブログ記事で、SQLgreyというものがあることを知った。postgreyから派生したグレイリスティングサーバで、動的IPアドレスっぽいFQDNパターンと、メールサーバっぽいFQDNパターンを検査する正規表現が用意されていて、動的IPアドレスっぽいパターンにマッチしてメールサーバっぽいパターンにマッチしなければグレイリスティングをかけるという方式だそうである。コンセプトは佐藤さんのRgreyと同じである。

動的IPアドレスっぽいパターン:
(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9]{12}|c:alnum:?{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106:alnum:?{12,}\.[a-z]{2})[0-9.x_-]

メールサーバっぽいパターン:
^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firewall|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|postfix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|pool|out|server)?[0-9]*[._-]

すげえな…
 S25Rの一般規則を一つの正規表現にまとめたものと比較してみようか。

^(unknown|[^.]*[0-9][^0-9.]+[0-9]|[^.]*[0-9]{5}|([^\.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]|[^.]*[0-9]\.[^.]*[0-9]-[0-9]|[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\.|(dhcp|dialup|ppp|adsl)[^.]*[0-9])

こっちの方がずっと短い。
 ついでに、9月23日の記事「Becky!でのフィルタリング」で紹介した簡易一般規則をPostfix向けに手直しすると…

^(unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9])

もちろん、さらにシンプルである。これは、Postfixではさらに短く

^(unknown|[0-9]|[^.]*([0-9]{5}|[0-9]([^0-9.]+|\.)[0-9]))

とも書ける(Becky!では通用しないが)。
 で、2006年7月に私のサイトへ不正メールを送り込もうとしたホスト4423個をどれだけ引っかけることができるかを比較してみた。その際、SQLgreyでの動的IPアドレスっぽいパターンの正規表現は、egrepコマンドにかかるようにするため、および「unknown」も引っかけるために、以下のように書き換えた。「:alnum:?」という書き方は謎だったが、不正メール送信の常連さんのFQDNからよきに推察して「[0-9a-f]」と書き換えた。

(unknown|(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]|c[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+(\.[a-z][a-z][a-z])?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]\.ipt|pcp[0-9][0-9][0-9][0-9][0-9][0-9]+pcs|S0106[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+\.[a-z][a-z])[0-9.x_-])

 その結果…

SQLgrey:3781個(85.5%)
簡易一般規則:4331個(97.9%)
S25R一般規則:4344個(98.2%)

なんてこったい。SQLgreyは、ものすごい正規表現の割に、S25Rの一般規則に比べて8倍もの不正メール送信元ホストを見逃しているではないか。しかも、catv.ne.jpやadsl.ne.jpやhome.ne.jp(いずれも実在する)をドメインごと引っかけてしまう。こんなものを使うよりも、S25Rのルールを取り入れたRgreyを選ぶべきである。
 自慢じゃないけど(自慢だけど)、私が作ったルールの方がはるかに簡潔でしかも効果的である。

日曜日, 10月 08, 2006

S25Rが敗北する時は来るか?

 スパマーがS25R方式の防御を突破する方法はいくつかある。
 第一に、ISPのメールサーバを経由することである。防御側では、ISPのサーバをブラックリスト登録するわけにはいかない。しかし、スパムの量は抑えられる。サーバのパフォーマンスがボトルネックになるからである。それに、スパマーがサーバを過負荷にしたら、ISPも黙ってはいないだろう。
 第二に、逆引きできてサーバっぽい逆引き名を持つサーバを侵害してそこからスパムをばらまくことである。私のサイトに着信するスパムには、この方法で送信されたと思われるものが多い。日本の企業や大学のサーバが乗っ取られてそこから来たスパムもあった。この場合も、おいそれとブラックリスト登録はできない。しかし、やはりスパムの量は抑えられる。乗っ取ることができるサーバは、ゾンビ化できるエンドユーザーPCに比べて非常に少ないからである。それに、乗っ取られたサーバの管理者はすぐに守りを固めるだろうから、同じサーバを長く利用し続けることはできない。
 第三に、ドメインを取得してサーバっぽい逆引き名を使うことである。しかし、コストがかかるので、この方法をとれるスパマーは少ないだろう。しかも、そのホストからスパムばかりが来ることがわかれば、ブラックリスト登録によって防御できる。
 第四に、まともなMTAを使うか、あるいはゾンビPCにまともなMTAと同じ動作をさせることである。つまり、「450」の拒否応答に対して何時間もリトライを続け、tarpitting(応答遅延)に対しても5分間辛抱強く待つ。スパム送信コンピュータにかかるリソース負荷が大きくなるが、技術的に不可能ではない(今の大半のスパマーがそうしていないのは、そうしなくてもスパムの送達に成功することが多いからである)。もし多くのスパム送信がそういうものになったら、S25R方式の運用は困難を極めることになるだろう。アクセス元が正当なメールサーバかスパム送信コンピュータかの区別ができなくなるからである。
 しかし、そうなってもまだS25R方式は負けてはいない。受けてからフィルタリングする方法が残っている。SpamAssasinのようなフィルタリングプログラムで、送信元の逆引き名を検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」のマークを付けて配信すればよい。そうすれば、受信者は容易にスパムをごみ箱行きにできる(間違ってごみ箱行きになった正当なメールはごみ箱から回収すればよい)。
 結局のところ、S25R方式は半永久的にスパムに敗北しないと私は考える。
 もっとも、当分は、S25R方式で拒否応答を返す方法が無力化する心配はない。大多数のサイトがスパムに対して無防備な状況では、スパマーは、防御の固い少数のサイトを攻撃するためにわざわざスパム送信コンピュータに大きなリソース負荷をかけたりはしないだろう。逆説的な言い方だが、S25R方式が世界中でこぞって採用される時が来るまでは、S25R方式は安泰である。

日曜日, 10月 01, 2006

1時間近くリトライするスパム

 次のようなスパムアクセスを見つけた。

Sep 29 05:13:36 unknown [74.130.145.173]
Sep 29 05:18:43 unknown [74.130.145.173]
Sep 29 05:23:50 unknown [74.130.145.173]
Sep 29 05:57:26 unknown [74.130.145.173]
Sep 29 06:03:12 unknown [74.130.145.173]

 5分余りの間隔で3回トライし、その後33分余りたってから、また5分余りの間隔で2回トライしている。8月28日の記事「リトライするスパムをRgreyで蹴る」で、最初のアクセスからアクセスを受け入れるまでの遅延時間を25分にすれば、リトライするスパムをほとんど阻止できると書いた。しかし、そのようにしても上記のアクセスはすり抜けてしまう。かといって、遅延時間をあまり長く設定するわけにもいかないだろう。
 考えてみると、スパマーにとって、スパム送信コンピュータにあまりリソース負荷をかけずにRgreyを突破するのは、さほど困難ではないと思われる。「450」の拒否応答が返された宛先をアドレスリスト上でマークしておき、30分~1時間後に、送信者アドレスを変えずに再送信すればよい。
 そのような手口にどう対抗するかというと、佐藤さんのStarpit(S25R+tarpitting)が有効だろう。たくさんの宛先サーバからtarpitting(応答遅延)を食らうと、プロセスが増加しすぎてリソース負荷に耐えきれなくなるので、送信を早々にあきらめてしまうと考えられるからである。
 ところが、それでも安心してはいられない。佐藤さんのブログ記事によると、STRATIONウィルスは65秒のtarpittingを抜けるそうである。このことから考えると、スパマーは、たくさんのゾンビPCを操ることによって、リソース負荷の問題も克服してしまうかもしれない。
 RgreyもStarpitもすり抜けるスパムが増えたらどうするか。そうなったら、通過したメールをSpamAssasinのようなフィルタリングプログラムにかけて、送信元の逆引き結果を再度検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」とマーキングして配信するのがよいと思う。正当なメールがマーキングされることはあっても、取りこぼす心配はない。
 もっとも、上記のようなアクセスは今のところレアケースである。当分は、S25R方式やそれを応用した方式によって90%以上のスパムを排除し続けることができるだろう。それというのも、まだ大半のサイトがスパムに無防備だからである。だからスパマーは、軽いリソース負荷で、いい気になってスパムを大量配信することができるのである。強力な防御策が多くのサイトに普及した時には、スパマーは、さらにそれを破る手を打ってくるだろう。

木曜日, 9月 28, 2006

拒絶の効果?

 勤務先では31日間に535通のスパムを受けた(9月23日「Becky!でのフィルタリング」)。一方、自宅サイトでもし対策をしていなければ受けてしまったであろうスパムは、35日間で370通と推計された(8月26日「通数で計った阻止率」)。31日間あたりに換算すると328通で、勤務先でのスパムの受信数の61%しかない。自宅サイトでスパムに狙われているアドレスは「deo」(個人アドレス)と「webmaster」の二つである。これらを合算しても、自宅サイトでスパム対策を解除したら受けるであろうスパムの量は、勤務先で一つのアドレスに届いているスパムより少ないのである。
 勤務先のアドレスがスパマーに知られたのは、whoisデータベースからと考えられる。勤務先のドメインの管理者を務めていたことがあるからである。今は仕事が変わったので、whoisデータベースに私のアドレスはない。このこと以外に、勤務先のアドレスを自らインターネットに露出させたことはない。一方、自宅のアドレス「deo」は、私が持つドメインの管理者のアドレスとして今もwhoisデータベースに露出している。また、「webmaster」は、私のウェブサイトに連絡先として掲載している。かつてはmailtoアンカーで掲載していたので、スパマーやウィルスに拾われやすかった(今はmailtoアンカーをやめているが)。
 他人のPCのウィルス感染によって私のアドレスがスパマーに漏洩したという推理もできるが、そうだとしても、自宅のアドレスの方が漏洩のリスクが高いと思われる。私は会員200人ほどのメーリングリストを運用しており、会員のPCがウィルス感染したことは何度かあったからである。
 どう考えても、自宅のアドレスの方が露出度が高い。それにもかかわらず、勤務先で受けるスパムよりも、自宅サイトの正しいアドレスに押し寄せるスパムの方が少ないのである。
 理由は一つしか考えられない。勤務先ではスパム対策をしていなくて、自宅サイトではスパムをはね返していることである。やはりスパマーは、送達率に無頓着にスパムを投げまくる連中ばかりではないのだろう。おそらく一部のスパマーは、私のサイトにはどうにもスパムを送り込めないことを知って、私のアドレスをリストから削除しているのだろう。
 私のサイトに押し寄せる、宛先の正しいスパムが少ないのは、拒否応答を返し続けていることの効果なのだと思う。受けてからフィルタリングする方法では、こうはいかない。送達には成功しているので、スパマーはいい気になってスパムを送り込み続けるに違いない。
 拒否応答を返す方法には、時として正当なメールを遅延させるという副作用が伴うが、やむを得ない。悪人をシャットアウトするためには善人も検問を受けなければならないようなものである。

月曜日, 9月 25, 2006

簡易一般規則

 前回(9月23日)紹介したBecky!用の簡易一般規則は、S25Rの6個の正規表現による一般規則に比べて効力がさほど劣らない振り分け条件を一つの正規表現として書いたものである。
 なぜ一つの正規表現にしたのかというと、正当なメールをごみ箱行きから除外するための条件を追加しやすくするためである。たとえば、一般規則に引っかかる正当なメールのFromヘッダのドメイン名が「example1.co.jp」および「example2.ne.jp」である場合、Becky!では、一般規則の条件の下に「かつFromヘッダにexample1.co.jpがないとき、かつFromヘッダにexample2.ne.jpがないとき(…に、ごみ箱に振り分ける)」という具合に、除外条件を絞り込み条件として追加していく必要がある。一般規則を複数の正規表現で指定すると、除外条件をどの条件の下に追加すればよいのかがわかりにくかったり、複数の条件の下に同じ除外条件を追加しなければならなかったりすることがある。それを避けるために一つの正規表現にしたわけである。
 簡易一般規則を作るにあたっては、S25R方式の一般規則のすべてのルールを盛り込もうとは欲張らず、ほどほど複雑すぎない正規表現で、ほどほど高い効果が得られるように工夫した。もしかしたら、Becky!での利用以外にも、フィルタリングスクリプトを組むのに役立つかもしれないと思ったので、参考のために解説を補足する。

from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp

 この正規表現の各部分を以下に説明する。

.*\(
 「Received: from 」に続くHELOアドレスから、それに続く「(」までを読み飛ばす。Postfixとsendmailが記録するReceivedヘッダでは、「(」の次から逆引き名が始まる。
 「Received: from 」の直後に逆引き名が位置するフォーマットの場合(qmailの場合)は、この4文字を削除してください(ブラックリストの指定でも同様である)。

unknown
 Postfixおよびqmailで、逆引きできなかった場合を引っかける。
 sendmailの場合は不要である(削除しなくても支障はない)。

\[
 sendmailでは、逆引きできなかった場合、「(」の直後の逆引き名が空になり、IPアドレスを囲む「[」が直後にいきなり位置する。その場合を引っかける。
 Postfixおよびqmailの場合は不要である(削除しなくても支障はない)。

[0-9]
 逆引きホスト名が数字で始まる場合を引っかける。すなわち、ルール3(逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる)の条件のサブセットである。

[^.]*[0-9][0-9][0-9][0-9][0-9]
 逆引きホスト名に、5個以上連続する数字が含まれる場合を引っかける。すなわち、ルール2の条件である。

[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]
 下線で示した部分は、随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介した時には「([a-z]|-)+」だけであった。ホスト名に、英字やハイフン1個以上で分断された数字列が2個以上含まれる場合を引っかける。すなわち、ルール1の条件である。
 ところが、「h146.27.40.69.ip.alltel.net」のようなケースがけっこうすり抜けることがわかったので、数字列を分断するのは最初のドット1個でもよいという条件を付け加えた。ややトリッキーな書き方である。これで、ルール3で引っかかるものの一部がさらに引っかかるようになる。
 ただし、これによって、「mx01.246.ne.jp」(実在するMXだが、メールを送信するかどうかはわからない)のようなケースが引っかかってしまう。S25Rのルール3は、このようなケースを引っかけないように上位3階層を検査から除外しているのだが、同じようにしようとすると正規表現が複雑化するので、やめた。レアケースだと思うので、かんべんしてください。

.*\(may be forged\)
 sendmailで、逆引きのパラノイド検査が不適合になって、逆引き名とIPアドレスの次に「(may be forged)」と付記された場合を引っかける。
 Postfixの場合は、パラノイド検査が不適合になった場合も逆引き失敗の場合と同じく「unknown」と表示されるので、不要である(削除しなくても支障はない)。qmailの場合は確かめていないが、多分不要だと思う。

土曜日, 9月 23, 2006

Becky!でのフィルタリング

 私は、勤務先ではメーラーBecky!のフィルタリング機能を利用してスパムを捨てている。その方法は、随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介している。以前は、メールサーバが送信元の逆引き名をReceivedヘッダに記録してくれなかったので、S25R方式を応用した正規表現フィルタでHELOアドレスを検査して約60%、HTMLメールを捨てるフィルタを加えて約80%、さらに、怪しい単語(「viagra」など)を引っかけるフィルタを加えて約90%をごみ箱行きにしていた。
 最近になって、逆引き名がReceivedヘッダに記録されるようになったので、フィルタを変更した。
 まず、随筆記事で紹介している正規表現フィルタに若干工夫を加えた。「ヘッダ」欄に「Received」と入力し、「正規表現」のチェックをオンにして、「文字列」欄に次のように入力する。

from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp

ここで、「mail\.example\.jp」は自サイトのメールサーバ名に置き換える。MTAがsendmailの場合は、「unknown|」はなくてもよい。Postfixの場合は、「\[|」と「|.*\(may be forged\)」はなくてもよい。
 これは、S25Rの一般規則を簡略化したもの(簡易一般規則と呼ぶことにする)である。逆引き失敗、およびルール1、2、3を合わせた条件とおおむね等価である。また、sendmailによるパラノイド検査(逆引き名の順引き結果が元のIPアドレスに一致するかどうかの検査)で不適合になって逆引き名に「(may be forged)」(偽造かもしれない)と付記されている場合も引っかけるようにしている。正当なメールをごみ箱行きから除外するには、この条件の下に絞り込み条件として除外条件を追加する。
 また、次のブラックリストも設定した。

from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp
from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp
from .*\(user.*\.mindspring\.com .* by mail\.example\.jp

 2006年8月23日から9月22日までの1ヶ月間に受信したスパムは535通。そのうち519通(97.0%)がスパム判定された。簡易一般規則に引っかかったものは494通(92.3%)であった。いずれも、9月15日の記事「宛先の正しいスパムの阻止率」で報告した阻止率(トータルで97.4%、一般規則で92.1%)に近い値である。
 S25Rの一般規則には引っかかるが簡易一般規則をすり抜けたものは4通(0.7%)であった。このことから、簡易一般規則の効力はS25Rの一般規則に比べてさほど劣らないと言える。
 これで、HTMLメールを捨てるフィルタと、怪しい単語を引っかけるフィルタは不要になった。これらのフィルタを設定してもスパム判定率はほとんど上がらない。
 一方、誤ってごみ箱行きになった正当なメールは4通(送信元は3個)であった。人によってはもっと多くなるだろう。多くの外部サイトからのメールを受けないと、false positive率は計算しにくい。
 以前、ウイルスバスターの迷惑メール対策機能を使っていた時には、判定レベルを「高」にしても、スパム判定率は85%くらいであった。それに比べて、わずか4個の、負荷の軽いフィルタで97%のスパムをごみ箱行きにできるのだから、S25R方式を応用したフィルタリングの効果は高い。一日に100通のスパムを受ける人の場合も、受信箱に残るスパムは平均3通ですむのだから、メーラーによるスパム対策としてはこれで十分だと思う。
 Becky!以外への応用の参考のために、前記の4個のフィルタ設定を、Receivedヘッダ全体を検査する正規表現に直して示しておく。

/^Received: from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp/
/^Received: from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp/
/^Received: from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp/
/^Received: from .*\(user.*\.mindspring\.com .* by mail\.example\.jp/

月曜日, 9月 18, 2006

ベイジアンフィルタを欺くスパム

 最近、宣伝文を画像化したスパムが多い。私が受けたスパムのうちでは、2006年7月には8通のうち6通、8月には10通のうち6通が画像ファイル付きだった。本文を解析するベイジアンフィルタを欺くことを狙っているのだろう。
 今のところ、そのようなスパムはHTML形式であって、ベイジアンフィルタでもHTMLタグを解析してスパム判定することは可能だと思われる。また、ほとんどはメールヘッダに

Content-Type: multipart/related

が入っているので、これを条件としてごみ箱行きにするようメーラーでのフィルタリングを設定するという方法もある(Outlook Expressをデフォルト設定のままで使っている人から送信されるHTMLメールのヘッダは「Content-Type: multipart/alternative」になっているので、上記のフィルタリングでごみ箱行きになることはない)。
 しかし、スパムメールの中身がプレーンテキストと画像ファイルだけになって、しかもプレーンテキストの内容がまっとうに見える文章になっていたら、ベイジアンフィルタでは歯が立たなくなるのではないだろうか。あるいは、判定条件がかき乱されて、正当なメールをスパム判定することが多くなるのではないだろうか。S25R方式の恩恵を受けていないユーザーにとって、ベイジアンフィルタや、それを応用したメーラーの迷惑メール対策機能は重宝な技術である。それが無力化しては気の毒である。
 S25R方式をメーラーでのフィルタリングに応用する方法もある。メーラーBecky!なら、フィルタリング条件に正規表現を使えるので簡単に設定でき、私はそれを随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介している。また、本庄さんは「Becky! S25R spamフィルタ」というBecky!用のプラグインを開発されている。
 ほかのメーラーのメーカーも、S25R方式を応用した迷惑メール対策機能を付けてくれないものだろうか。Receivedヘッダに記録された、送信元の逆引き名を解析すればよいので、技術的には簡単である(ただし、自サイトのメールサーバが送信元の逆引き名をReceivedヘッダに記録してくれなければならないが)。
 もっとも、S25R方式があまりにも単純すぎることが、かえって採用の阻害要因になるかもしれない。スパム対策には世界中の人々が大変な苦労をしているのに、こんな簡単な方式で、受信するスパムのうち97%(9月15日の記事「宛先の正しいスパムの阻止率」参照)もスパム判定できるとは、おそらく多くの人には信じられないことだろう。開発者本人でさえ、もし私が他人だったら耳を疑うだろうと思うくらいだから。

土曜日, 9月 16, 2006

ブラックリスト

 前回(9月15日)の記事で述べたように、2006年7月には、宛先の正しい不正メールの送信元で阻止されたのは297個であった。そのうち1個は送信者ドメインの実在の検査に引っかかり、一般規則に引っかかったものは281個であった。残りの15個はブラックリストで阻止されたもので、次のとおりである。

abcm136.neoplus.adsl.tpnet.pl [83.6.228.136]
abem128.neoplus.adsl.tpnet.pl [83.7.24.128]
abmf241.neoplus.adsl.tpnet.pl [83.7.225.241]
abty159.neoplus.adsl.tpnet.pl [83.8.170.159]
aeb234.internetdsl.tpnet.pl [83.16.105.234]
aiz151.neoplus.adsl.tpnet.pl [83.25.233.151]
boo89.neoplus.adsl.tpnet.pl [83.29.30.89]
dao137.neoplus.adsl.tpnet.pl [83.23.14.137]
dtf110.neoplus.adsl.tpnet.pl [83.24.243.110]
dtm234.neoplus.adsl.tpnet.pl [83.24.250.234]
dvn234.internetdsl.tpnet.pl [83.19.251.234]
edw31.neoplus.adsl.tpnet.pl [83.21.8.31]
xdsl-334.jgora.dialog.net.pl [81.168.149.78]
xdsl-5141.lodz.dialog.net.pl [87.105.80.21]
xdsl-9532.wroclaw.dialog.net.pl [84.40.234.60]

 ご覧のように、ドメインは二つだけである。一般規則だけによる阻止率は92.1%だったが、たった二つのブラックリスト項目が阻止率を97.0%にまで引き上げていたのである(あと0.4%は送信者ドメインの実在の検査による)。
 マークしておくべきドメインはもう一つある。

user-0cetsi8.cable.mindspring.com [24.238.242.72]

このドメインからの不正メールアクセスのうち、宛先が正しかったのはこの1件だけで、一般規則のルール1に引っかかっていた。しかし、「user-」の後の7個の英数字は番号を符号化したものと思われ、一続きで4桁以下の数字列しか含まれなくて一般規則をすり抜けることが時々ある。おそらく、一般規則をすり抜ける割合は、8桁の十六進番号よりも高い。しかも、このドメインは不正メール発信の常連である。
 そういうわけで、ブラックリストに次の3件は最低限登録しておくことをお奨めする。

/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain UCE-blacklisted
/^xdsl.+\.dialog\.net\.pl$/ 450 domain UCE-blacklisted
/^user.+\.mindspring\.com$/ 450 domain UCE-blacklisted

 これらのうち、tpnet.plとmindspring.comは論文に示した設定ファイルの内容に含まれているが、dialog.net.plは最近見つけたもので、含まれていない。
 なお、dialog.net.plを引っかけるには、一般規則のルール6を

/^(dhcp|dialup|ppp|adsl|xdsl)[^.]*[0-9]/ 450 may not be mail exchanger

と直してもよい。

金曜日, 9月 15, 2006

宛先の正しいスパムの阻止率

 私のサイトへの不正メールアクセスの大半は、宛先誤りのものである。スパムやウィルスメールをおびき寄せてデータを取るためにおとりアドレスを仕掛けたのが理由の一つである。また、ISO-2022-JP(通称:JIS)で符号化したウェブページから拾い出された「bwebmaster」などの間違いアドレスもある。先頭の「b」は、文字セット切り替えのエスケープシーケンス(「B」と同じ符号を含む)から誤って抽出されたものである。ほかに、「sneovbwebmaster」だの「qujwtbwebmaster」だのというでたらめのアドレスもある。アドレスリストにごみデータを混ぜて水増しして売り飛ばす奴がいるのだろうか。
 このような不正メールアクセスから統計を取り、2004年4月にも2006年7月にも、ホスト数で計って阻止率99.1%という結果を得た(8月25日「今なお阻止率99%」)。しかし、対策をしていなければ受けてしまったであろうスパムの推計数と実際に受けてしまった通数から計算した阻止率は、97.8%という、やや低い値になった(8月26日「通数で計った阻止率」)。これはなぜだろうかと考えて、推計値でない厳密な統計値を出すことを思い付いた。宛先の正しい不正メールを送り込もうとしたホストだけを抽出して、そのホスト数で阻止率を計るという方法である。
 2006年7月には、受けてしまったスパムの送信元は8個(ISPのメールサーバを含む)、阻止されたホストは297個、そのうち一般規則に引っかかったものは281個であった。このことから、トータルの阻止率は97.4%、一般規則だけによる阻止率は92.1%という結果になった。トータルの阻止率は、通数で計った推計阻止率に近い。
 私は論文で「阻止率99%」と標榜しており、それは不正メールアクセスすべてから統計を取った結果であって嘘ではないのだが、受信するスパムの減少率は97%くらいと思っていただいた方がよいかもしれない。それでも、無料でできるスパム対策としては十分に高い値だと思う。
 この結果は何を意味するかというと、宛先の正しいスパムはS25R方式の防御を突破する率がやや高いということである。その理由を私はこう推測する。スパマーには、効率無視のスパマーと効率重視のスパマーがいる。効率無視のスパマーは、ごみデータだらけのアドレスリストを使い、たくさんのエンドユーザーPCをゾンビ化させて、送達率など気にせずにスパムをばらまく。これらのほとんどはS25R方式で阻止できる。一方、効率重視のスパマーは、送達率の高い良質なアドレスリストを使い、ISPのメールサーバを経由するか、あるいはセキュリティの弱いサーバを乗っ取ってそこからスパムをばらまく。それらの送信元が逆引きできて、しかもサーバっぽい逆引き名であれば、S25R方式では阻止できない。つまり、効率重視のスパマーが、宛先の正しいスパムの突破率を押し上げているのだろう。

月曜日, 9月 11, 2006

ホワイトリスト情報

 ルール1に引っかかるメールサーバがまた見つかって、ホワイトリスト情報に掲載した。

# Sep 11, 2006: adm2-bge0.cc.uec.ac.jp
/\.cc\.uec\.ac\.jp$/ OK

 こういうことがあると、「ルール1の条件を緩めた方がよいだろうか」とつい思ってしまう。しかしそれは、強固な防衛力によってサイトの平和が保たれていることをつい忘れてしまうからだろう。
 前回(9月3日)の記事に書いたように、2006年7月の統計によれば、ルール1の条件を「3個以上の数字列」に緩めたら阻止率は1.3%低下する。わずかなもののように思えるかもしれないが、不正メールの送信元のホスト4423個のうち、見逃されるものが57個増えるのである。大規模サイトでは、一日の不正メールアクセスが数千件になる所はざらであろう。数千件のうちの数十件の不正メールアクセスを毎日見逃すか、たまにホワイトリスト登録を強いられるか、どちらを選びますか?それを考えれば、「数字列が2個以上なら阻止」という一見厳しすぎる条件を提案したことは間違っていなかったと思っている。
 一方、ルール2をぎりぎりですり抜けたスパム(すなわち、ホスト名に4桁の数字を含むホストからのもの)をたまに受けると、ルール2を厳しくしたいという衝動にかられてしまう。
 実は、ルール2を「数字が5桁以上なら阻止」という条件に決めたのは、多分に恣意的な理由によるものである。第一に、S25R方式の開発中にいろいろなドメインのMXレコードを調べたところ、見つかったホスト名の中では数字4桁が最長だったこと。第二に、4桁までの数字なら覚えやすいので(自動車のナンバーが4桁だし、電話番号も多くの場合、最大4桁ずつ区切って覚えるから)、4桁の数字を含むホスト名をメールサーバに付ける人はいるだろうと思ったこと。第三に、S25R方式で阻止されないホスト名を決めようとする人の立場で考えた時、「数字は一続きで3桁まで」という条件は窮屈すぎると思われたからである。
 実際のところ、ルール2をぎりぎりですり抜ける不正メールの送信元は少しあるが(4423個中9個)、ブラックリストで阻止するのに苦労はない程度。一方、ホスト名に数字5桁を含む正当なメールサーバもたまに見つかるが、ホワイトリストで許可するのに苦労はない程度である。「数字が5桁以上なら阻止」という条件は、ほどほどバランスがとれていると思う。

日曜日, 9月 03, 2006

一般規則を緩めたら

 ルール1(逆引きFQDNの最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む)やルール2(逆引きFQDNの最下位の名前が、5個以上連続する数字を含む)に引っかかるメールサーバがある。そのため、これらの条件を緩めた方が安全ではないかと考える方もおられるであろう。
 8月25日の記事「今なお阻止率99%」に書いたように、2006年7月には、一般規則による阻止率は98.2%であった。これが、ルール1またはルール2の条件を緩めたらどのくらいに下がるのかを計算してみた(それぞれ、ほかのルールは変えないという前提で計算している)。
 ルール1を「3個以上の数字列」という条件にしたら96.9%(1.3%減)。「4個以上の数字列」では95.7%(2.5%減)。
 ルール2を「6個以上連続する数字」という条件にしたら98.0%(0.2%減)。「7個以上連続する数字」では97.6%(0.6%減)。ついでに、「4個以上連続する数字」と厳しくしたら98.4%(0.2%増)になった。
 これらの結果をどう考えるかは皆さんにお任せする。「阻止率の低下がそのくらい少ないなら、正当なメールサーバを阻止するリスクを減らすために条件を緩めよう」と考える人もいるかもしれない。
 しかし私は、条件を緩めてもホワイトリストの作成の手間が大きく減ることはないだろうと思う。どのみち、逆引きできないメールサーバや、エンドユーザー回線を使っているメールサーバ(小規模サイトやメールマガジン配信業者などのもの)はホワイトリスト登録しなければならず、それらに比べれば、一般規則を緩めることで引っかからなくなるメールサーバは少ないと考えられるからである。

金曜日, 9月 01, 2006

グレイリスティングを抜けられないサイト

 ホワイトリスト情報で公開しているサイトに以下のものがある。

# Nov 25, 2004: mta12.m2.home.ne.jp, etc.
/\.m2\.home\.ne\.jp$/ OK

# Jan 10, 2006: n2.59-106-41-68.mixi.jp, etc. (*)
/\.mixi\.jp$/ OK

これらは、リトライのたびに送信元のIPアドレスが変わるという困った動作をするサイトである。前者は私が見つけた。後者は、協力者から報告されたものだが、これも困ったサイトだということは後で佐藤さんのブログ記事で知った。
 S25Rの拒否条件に引っかかる上に、グレイリスティングも抜けられない。だから、S25R方式の導入サイトだけでなく、グレイリスティングの導入サイトでもホワイトリスト登録しておかなければならない。
 S25R方式では拒否されなくてもグレイリスティングを抜けられないサイトがほかにあるかもしれないので、グレイリスティングの導入サイトでは要注意である(注意しようにもどうしようもないかもしれないが)。
 こんなスパムもどきの動作はしてほしくないのだが。

水曜日, 8月 30, 2006

リトライを短時間でやめるサーバ

 NTT東日本のメールマガジン送信サーバをルール2(逆引きFQDNの最下位の名前が、5個以上連続する数字を含む)で蹴飛ばしてしまった時のログである。

Jul  4 13:28:35 cms01011.mids.flets.com [202.229.5.151]
Jul  4 13:42:18 cms01011.mids.flets.com [202.229.5.151]
Jul  4 14:09:38 cms01011.mids.flets.com [202.229.5.151]
Jul  4 14:50:19 cms01011.mids.flets.com [202.229.5.151]

 これでリトライが止まってしまい、受信し損ねた。わずか1時間21分のリトライでは、手動で救済する暇はない。多数の受信者にメールを配信するサーバのリソース負荷の増大を避けるために、不到達がしばらく続いたら早々に送信をあきらめてしまうようにしているのかもしれない。
 素のS25R方式をお使いの方はお気を付けください。「一部のメールマガジンを救済しきれないことがありえます」とユーザーに断っておいた方がよいかもしれない。その際、「ぜひとも受信者に送り届けたいという熱意のないメールマガジンの場合」とただし書きを付けるかどうかは、皆さんの自由である。

月曜日, 8月 28, 2006

リトライするスパムをRgreyで蹴る

 リトライするスパムはグレイリスティングでは防げないものと思い込んでいたが、浅はかだった。最初のアクセスからリトライを受け入れるまでの遅延時間は、postgreyのデフォルトでは5分だが、これを長く設定すればよい。
 素のS25R方式を使っていると、リトライするスパムアクセスの挙動をよく観察できる。ほとんどのスパムアクセスは、さほど長時間はリトライしていないのである。
 2006年7月30日から8月28日までのログを拒絶ログソーティングスクリプトで解析したところ、リトライするスパムアクセスは15件見つかった。そのうち14件は、次の例のように、最初のアクセスから最後のアクセスまでの時間間隔が23分未満であった。

Aug 24 14:26:15 unknown [83.68.35.41]
Aug 24 14:32:12 unknown [83.68.35.41]
Aug 24 14:37:25 unknown [83.68.35.41]
Aug 24 14:43:29 unknown [83.68.35.41]
Aug 24 14:49:10 unknown [83.68.35.41]

例外は、次の1件(40分50秒)だけであった。

Aug 25 04:34:34 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:39:42 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:44:50 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:50:02 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 05:15:24 82-135-208-206.ip.zebra.lt [82.135.208.206]

 このことから、Rgrey(すなわち、パッチしたpostgrey)の起動オプションとして「--delay=1500」を指定すれば、最初のアクセスから25分に達しないうちはリトライアクセスを「450」で蹴り続けるので、リトライするスパムのほとんどを阻止できるはずである。
 S25Rの拒否条件に引っかかるメールサーバからの最初のメールの受信は25分以上遅延することになる。しかし、素のS25R方式ではホワイトリスト登録まで数時間あるいは一晩(場合によっては休日を挟む2~3日)遅延しうることを思えば、大したことはないだろう。
 この方法は、素のグレイリスティングを使っているサイトにはお奨めしない。初めてメールを送ってくるホストからのメールがことごとく25分以上遅延し、けっこう大騒ぎになりかねないからである。Rgreyなら、S25Rの拒否条件に引っかからない大多数のまともなメールサーバからのメールを遅延なしに通過させるので、ほとんど問題にならないだろう。
 どなたかやってみませんか?

日曜日, 8月 27, 2006

Illegal HELO address

 HELOアドレスが宛先サーバのIPアドレスまたは受信者のドメイン名になっているというアホな不正メールアクセスが増えている。2004年4月の統計では不正メールの送信元ホスト567個中9.3%だったが、2006年7月の統計では4423個中22.6%にもなっていた。
 なぜこんなアホな動作をするのだろうか。論文では「このような不正な動作をするSMTPエンジンを作る奴は、SMTPの決まりを知らないのだろう」と書いた。しかし、もしかすると、Receivedヘッダを読んだ時に、その不正メールが自サイトで発生したかのように錯覚させることを狙ったのかもしれない。見る人が見れば、偽のHELOアドレスだとすぐにわかるのだが。
 このようなアホなSMTPエンジンは、防御側にとっては幸いである。HELOアドレスが自サイトのIPアドレスまたはドメイン名だったら蹴飛ばすようにすればよく、副作用がまったくないからである。
 S25R方式の導入に躊躇している方も、Postfixをお使いなら、このチェックはぜひ入れるようお奨めする。これだけでスパムやウィルスの受信を約2割は減らせるだろうから。

土曜日, 8月 26, 2006

通数で計った阻止率

 私が「阻止率99%」と標榜しているのは、不正メール(スパムやウィルス)を送り込もうとするホストのうちの99%に対して選択的拒絶が成功しているという意味である。不正メールの通数でなくホスト数で計っているので、必ずしも、月に1000通のスパムを受けていた人が10通しか受けなくてすむようになるということではない。
 しかし、皆さんの関心事はやはり、スパム対策をしていない場合に比べて、S25R方式を導入したらスパムの受信数をどのくらい減らせるのかということだろう。そこで、推計してみた。
 スパム対策をしていなければ受けてしまったであろう不正メールの通数は、ログからは正確にはわからない。拒絶したらリトライしてくるアクセスがあるからである。そこで、私の拒絶ログソーティングスクリプトでカウントされるメッセージ数が、対策をしていなければ受けてしまったであろう通数であると仮定する(7月27日の記事「reject_unlisted_recipient」に書いたように、宛先誤りのアクセスはクライアントアドレスチェックの前にはねているので、抽出されるのはすべて宛先の正しいアクセスである)。メッセージ数とは、リトライアクセスがあればその1シーケンスを1通と数えたものである。
 2006年7月23日から8月26日(18時)までの5週間のログをスクリプトに入力したら、メッセージ数は327であった。このほかに、宛先は正しかったが不正なHELOアドレスではねたために抽出されなかったアクセスが35件。この期間中に受けてしまったスパムは8通であった。したがって、対策をしていなければ受けてしまったであろう不正メールの数の推計値は、合計370通ということになる。
 このことから、通数で計った阻止率は97.8%という結果になった。99%には届かなかった。でも、けっこう高いでしょ?

金曜日, 8月 25, 2006

今なお阻止率99%

 2006年7月の統計をとってみた。
 論文に示している、2004年4月の統計期間には、不正メールの送信元ホストは567個だったが、今回は4423個と7.8倍に増えていた。それに比例して、受けてしまったスパムは1通から8通に増えた。
 4423個のうち、一般規則にマッチしたのは4344個で98.2%。2004年4月から変わっていない。ブラックリストにマッチしたのを合わせると4383個で99.1%。不正なHELOコマンド(宛先サーバのIPアドレスまたは受信者のドメイン名を通知している)を送ってきたものは998個あったが、これらはすべて一般規則に引っかかっていた。結局、トータルの阻止率(User unknownになったために受けずにすんだものは、阻止されたことにしない)は99.1%で、これまた2004年4月から変わっていなかった。
 「阻止率99%のスパム対策方式」というセンセーショナルなタイトルが“看板に偽りあり”になったらどうしようかと心配していたが、2年たってもS25R方式の効果は衰えていなかった。自慢しちゃおう。えっへん!

木曜日, 8月 24, 2006

Non-FQDN HELO address

 スパムアクセスの中には、HELOアドレスがFQDNの形になっていないもの(「localhost」など)がけっこう目に付く。そこで、smtpd_helo_restrictionsパラメータに「reject_non_fqdn_hostname」を指定していたことがある。
 しかし、これはやめた方がよい。あるオンラインショッピングの確認メール送信サーバを「554」で蹴飛ばしてしまった。HELOアドレスもまともに設定してくれよと言いたいところだが、受信できなくて困るのはこちらなので、それ以来、この指定はやめている。「reject_unknown_hostname」(HELOアドレスのAレコードもMXレコードも検索できなければ蹴る)というのも指定できるが、正当だけれどもHELOアドレスの設定が不備なメールサーバが存在する以上、これはますます危険である。
 これらの指定を使わなくても、逆引き検査によって十分にスパムを阻止できているので、阻止率はほとんど変わらない…と思う。

水曜日, 8月 23, 2006

「450」だけ書いてもだめ

 ある企業ネットワークのメールシステム管理者から質問を受けたことがある。ポルノサイトからのスパムを阻止しようと、クライアント制限の設定ファイルのブラックリスト欄に

/^host\.example\.com$/ 450

の形で設定したのだが、阻止されないとのこと。
 これではだめである。

/^host\.example\.com$/ 450 UCE-blacklisted

のように、応答コードの後に何らかのテキストを指定しなければならない。なぜPostfixがこういう仕様になっているのかは知らない(ご存じの方は教えてください)。
 それと、送信元がポルノサイトだとわかっているのなら、「450」でリトライを促す必要はないだろう。企業ネットワークは仕事のための設備なのだから、社員のためにポルノの宣伝を受信してあげることはない。敵が逆引きホスト名を変えてもスパムを送り込めないように、ドメインごと「554」で蹴飛ばしてやろう。

/\.example\.com$/ REJECT

の形で設定すればよい。
 もっとも、「450」を返すことによって、敵がむなしくリトライを続けるのを見て楽しむなら、それはそれでよいけれども。

日曜日, 8月 20, 2006

Starpit

 佐藤さんが開発されたStarpitは、S25Rの拒否条件に引っかかる送信元に対してtarpitting(応答遅延)をかけることによってスパムを排除するという方式である。RFC2821では、RCPT TOコマンドに対する応答待ちは5分と推奨されていて、正当なメールサーバの大多数はこれを守っているが、スパム送信プログラムやウィルスの多くは、大量のメールを送信したいがために、応答がないと短時間で送信を打ち切ってしまう。このことを利用して、RCPT TOコマンドに対して65秒ほどの応答遅延をかけることによって、正当なメールは受信しながら、スパムやウィルスのほとんどを排除できるというものである。すでに大規模ネットワークサービスでの運用実績もあるとのことである。
 利点は、Postfixの2.3以降であれば設定だけで実現できるので、付加ソフトウェアなしでホワイトリスト作成の手間をほとんどなくすことができることである。また、リトライによってグレイリスティングを突き抜けることを狙ったスパムも、待ち時間が短いならば排除できる。
 ただ、問題点もいくつか報告されている。
 第一に、応答遅延をかける分だけsmtpdプロセスが長時間持続するので、リソース負荷が増えることである。これを軽減するために、佐藤さんは、送信元が接続を切ったらプロセスを終了させるためのパッチを作成されている。
 第二に、S25Rの拒否条件に引っかかる正当なメールサーバが送信を早々にあきらめることがまれにあることである。これはホワイトリスト登録で救済できるが、佐藤さんは、グレイリスティングとの組み合わせでこれも自動的に救済する方法を研究中とのことである。
 第三の問題は、受信者が複数でRCPT TOコマンドが複数回送られてくると、そのたびに応答遅延がかかってしまうことである。たとえば、応答遅延を65秒と設定していると、10人の受信者に宛てられたメールは受信まで650秒(10分50秒)遅延してしまう。これは、多人数でメールを交換する時にはけっこう切実な問題になる。2回目以降のRCPT TOコマンドに対しては応答遅延をかけないようにPostfixを改造できればよいのだが、可能だろうか。
 Starpitが、Postfixのパッチも付加ソフトウェアもなしに手軽に使えるものになるためには、tarpittingの手法にPostfixがもっと適応してくれる必要があるのではないかと思う。そんなわけで私は、ホワイトリスト作成を省力化できてかつ安定運用を重視するというニーズに対しては、今のところはまだRgreyを推奨したいと考えている。グレイリスティングは、すでに長く使われていて安定した技術だからである。また、リトライしてグレイリスティングを突き抜けるスパムが増えてきているようではあるが、全体の中での割合はまだ少なく、グレイリスティングは今なお効果的だからでもある。

# 佐藤さん、ごめんね。

火曜日, 8月 08, 2006

リソース負荷

 「スパム対策のためだからといって、正当な送信側メールサーバにリソース負荷をかけるのは好ましくない」という考え方がある。「450」を返して受信を拒否すると、送信側メールサーバにメールを滞留させる、つまりディスクというリソースに負荷をかけることになるからだという。この考え方に照らすと、メールを受信してからメーラーやSpamAssassinなどでフィルタリングするのはよいが、S25R方式やグレイリスティングは好ましくないということになる。そうだろうか。
 私は、送信側の立場に立つならばこう考える。時には宛先サイトのメールサーバがダウンしていることもある。「4xx」を返されることもある(それは、グレイリスティングによるものかもしれないし、何らかのトラブルによるものかもしれない)。それで自サーバにメールが滞留することがある。それはあって当然のことである。滞留したメールのためにディスク領域が使われたところで何の実害もない。
 よしんば実害があったとしても、それは、自サイトのユーザーが大量のメールを送信してそれが滞留し、スプールあふれを起こした時だろう。それはこちら側の責任である。自サイトのメールトラフィックに耐えられるサーバを用意していなかったのがいけないか、あるいは、ユーザーが自サイトのサーバのパフォーマンスを考えずに大量のメールを送信したのがいけない。「宛先サイトがただちに受信してくれなかったのが悪い」などと言うのはお門違いというものである。
 だから私は、逆に受信側の立場に立つならば、送信側が正当なメールサーバであるかどうかを判断できるまで「450」を返して送信を多少待ってもらうことは罪悪でもモラル違反でもないと考える。
 ところで、インターネットの中継回線にかかるリソース負荷という観点で考えてみよう。今、インターネットのメールトラフィックの大半をスパムが占めている。中継回線がごみトラフィックであふれれば、善良なユーザーの通信に影響をきたす。また、ISPや中継ネットワーク事業者がごみトラフィックのせいで回線を増強しなければならなくなる。これは切実な実害である。
 受信してからフィルタリングする方法では、中継回線上のごみトラフィックは減らない。それに対してS25R方式やグレイリスティングでは、正当なメールサーバであろうと推定できない送信元に対して「450」を返すことによって、多くのスパムのメッセージ本体の伝送を食い止めることができる。つまり、中継回線上のごみトラフィックを減らすことができるのである。時には正当な送信側メールサーバに対して、実害のないリソース負荷を多少かけることがあろうとも、この方がよほどインターネットの公益のためになる。

月曜日, 8月 07, 2006

ホスト名「nat」

 2006年5月から7月にかけて、以下のホストからスパムを受けた。

nat.praganet.pl
nat.sychrovnet.cz
nat.a10.qwerty.ru
nat5.mnc.pl
nat.trzechwieszczy133.trustnet.pl

また、7月のログから以下のホストも見つかった(User unknownになったので、受信はしなかった)。

nat.csm.pl
nat.rtcol.com
nat11.piotrkow.net.pl
nat_net172.14.phonewave.net

 「nat」はNAT(Network Address Translator)の意味に違いない。こんな名前のメールサーバはまずないだろう。癪なので、こやつらのたぐいを全部蹴飛ばしてあげることにした。
 一般規則に以下の設定を追加した。もちろん、「natalie」とか「national」のような名前は引っかからない。

/^nat[^a-z]/ 450 may not be mail exchanger

 不正メールの送信元全体から見れば、このようなホスト名はごく一部で数は少ない。このフィルタを設定した後にこれで阻止されたスパムはまだない。しかし、副作用のおそれがまずないので、一般規則に追加する価値はあると思う。よろしかったら真似してみてください。

日曜日, 8月 06, 2006

十六進番号

 IPアドレスの十六進表記(8桁)を逆引きホスト名に含むエンドユーザー回線がけっこう多い。その中には、一般規則をすり抜けるものがある。論文に書いているように、「ACBBD419.ipt.aol.com」がその実例である。8桁の十六進番号の96%はルール1(最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む)またはルール2(最下位の名前が、5個以上連続する数字を含む)に引っかかり、残りの4%の中にもほかのルールに引っかかるものがありうるので、すり抜ける割合は少ない。
 とはいえ、メールの流量が多いサイトでは、十六進番号が一般規則をすり抜けることでスパムを阻止し損なうことが多いかもしれない。エンドユーザー回線のホスト名に十六進番号を使っているドメインをブラックリストに登録すればよいのだが、数が多いとそれも大変だろう。
 実は、8桁の十六進番号をすべて引っかけるルールを一般規則に含めようかと考えたこともあった。

/^[^.]*[0-9a-f]{8}/ 450 may not be mail exchanger

という設定を加えればよい。
 しかし、あえてそうしなかった。「a」~「f」の文字を含む語がマッチするおそれがあるからである。たとえば「speedfeed1」は引っかかってしまう。この名前を見れば、誰でも「2個の英単語と1個の数字から成る」と思うだろう。「『sp』の後に十六進番号8桁が続く」とすぐに見ることができる人は、よほどマニアックである。「なぜこの名前が引っかかったのだろう」と戸惑わせるルールは万人向けではないと考えたのである。だから、論文では「こういう方法もある」と示唆するにとどめている。
 十六進番号が一般規則をすり抜けることが多いサイトでは、「speedfeed1」のようなケースで戸惑わない自信があるなら、あるいはRgreyを使っているなら、上記のルールを追加していただいてもよいと思う。「speedfeed1」のような名前はレアケースであり、おそらく副作用は少ないだろう。

土曜日, 8月 05, 2006

False positive

 判定誤りにはfalse positiveとfalse negativeがある。スパム判定においては、正当なメールをスパムと誤認するのがfalse positive、スパムを見逃すのがfalse negativeである。false positiveが多いのは大変困る。まだしもfalse negativeの方がましである。
 しかるに、S25R方式はどうか。false negativeは非常に少なく、「予想以上の効果に驚いた」という声が聞かれるほどである。一方、false positiveは、組織サイトでは500~1000件のホワイトリスト登録に追われるほど多い。なにしろ、逆引きできなければ蹴るわ、ホスト名が「mail1-2」とか「server00102」とかだったら蹴るわで、やることが乱暴である。
 ところが、false positiveの多さにねを上げてS25R方式の運用を断念したという声は聞かれない。もちろん、ホワイトリスト作りの手間をなくしたいならRgreyを使えばよいということもあるが、かなりの人がホワイトリスト作りの苦労を乗り越えて素のS25R方式を使い続けている。これはなぜだろうか。
 まず、S25R方式においてはfalse positiveは致命的なものではない。送信元がリトライしているうちにホワイトリスト登録することによってメールは受信できるからである。その作業は、件数が多いと労力はかかるが、簡単である。しかも、ホワイトリスト登録が進むほどにfalse positiveは減っていく。
 心理的な理由も考えられる。スパムフィルタでfalse negativeを減らす作業は、スパムを受けるたびに「またか、コンチクショー」という怒りを伴うので、精神的ストレスが高い。それに対してS25R方式では、導入したとたんにスパムとのいたちごっこはほとんど終わってしまう。あとはホワイトリスト登録に追われることになるが、正当なメールを救済する作業には怒りを伴わないので、精神的ストレスが低くてすむ。しかも、正当なメールをユーザーに届けてあげるという義務感から、一生懸命になれる。また、スパムから解放された快感を維持するためなら、ホワイトリスト登録作業の繰り返しも苦にならない。
 このような心理は、佐世保高専の中原さんのレポートからも読み取れる。中原さんは、SpamAssassinに判断基準を教え込んでいた作業と比べて、S25R方式でのホワイトリスト登録を「それは遥かに実のある作業といえました」と書いておられる。中原さんにとってホワイトリスト登録作業は、不快感を伴わず、喜びを伴うものだったに違いない。
 もっとも私は、人間のこういう心理まで考慮してS25R方式を開発したわけではない。なにしろ、組織サイトではfalse positiveが多いということは、導入者の方々からの報告を聞くまでわからなかったのだから。

水曜日, 8月 02, 2006

ユーザーに判断を委ねる方法

 東京都精神医学総合研究所の中山さん(「導入者の皆様の声」の9番)は、受信者ごとのグレイリスト(リトライアクセスのログ)をスクリプトによってウェブで掲示してユーザーにチェックしてもらい、ユーザーからの要求でホワイトリストを作成するという方法をとっておられる。これはうまい方法だと思う。
 リトライアクセスが怪しいか怪しくないか、運用者だけでは判断しにくいことがあるであろう。ユーザー自身にチェックしてもらえば、送信者アドレスに心当たりがあるかどうかで判断できることがある。知らない人からメールが来るはずがないと思っている人は、送信者アドレスに心当たりがないグレイリストを見つけても放っておけばよい。それでもし正当なメールを受信し損ねたとしても、そこはユーザー責任ということで納得してもらえる。
 ユーザーには、グレイリストを毎日チェックするという負担がかかる。しかし、スパムに困っているサイトなら、スパムをはじくためということで理解が得られるだろう。
 気がかりなのは、スパムがほとんど入らなくなってホワイトリストも安定すると、ユーザーがグレイリストをチェックするのを忘れるようになるのではないかということである。運用者が気を付けていて、「あなた宛のグレイリストがあります。受信したいなら知らせてください」と連絡してあげることが必要になるかもしれない。
 なお、この方法をとる場合でも、最初のうちは運用者の判断でホワイトリストを作成し、ホワイトリスト登録の頻度が少なくなってからにした方がよいと思う。最初からユーザーに判断を委ねると、ホワイトリスト登録要求が殺到して作業が追い付かなくなり、「ホワイトリスト登録を頼んだのに受信できないぞ」と苦情が来るおそれがある。かといって、S25Rを一時的に解除すると、「スパム対策を開始したと言ったのにまだスパムが来るぞ」と苦情を受けることになりかねない。

火曜日, 8月 01, 2006

手動ホワイトリスティングのこつ

 ホワイトリストのメンテナンスの手間がほとんどないRgreyを皆さんこぞって採用するかと思いきや、素のS25R方式もけっこう人気があるように見受けられる。実装の簡単なS25R方式をまず導入して、Rgreyへのステップアップは後で検討すればよいと考える人が多いのかもしれない。
 私の個人サイトでは経験のないことなのだが、ユーザーの多いサイトでS25R方式を導入すると、ホワイトリストで救済すべきリトライアクセスが次から次へと検出されて往生するかもしれない。もしそうなったら、あわてずにS25Rを解除してしまおう。スパムやウィルスを阻止することよりも、正当なメールを通過させることの方が大事だからである。そして、ホワイトリストの作成が一段落したらまたS25Rを設定する。これを繰り返せば、正当なメールの受信に失敗することなく、ホワイトリストを徐々に整備していけるだろう。
 以前にも書いたとおり、導入者の方々からの報告によると、ユーザーの多いサイトではホワイトリストの登録数は500~1000件くらいになるが、2週間から1ヶ月もたてば登録の頻度は少なくなるとのことである。毎日膨大な件数を登録する作業が際限なく続くのではないかと心配する必要はない。
 ところで、ホワイトリスト登録作業に手間がかかるからといって、作業者を増やせばよいかというと、そうはいかない。これは分担しにくい作業である。ただ、2人でなら分担できるだろう。一人がログを見てホワイトリストに登録すべきホストを抽出し、もう一人がそれを受けて登録作業を行うのである。ログを見る作業は、怪しいリトライアクセスを見分けることができるくらいのベテランの人が担当するのがよいだろう。登録作業は、手順さえ覚えればオペレーションの初心者でもできる。

月曜日, 7月 31, 2006

手動ホワイトリスティングの利点

 手動でホワイトリストを作るのは面倒ではあるが、利点もある。スパムに対する防御力が強いことである。
 以下は、私のサイトで観測されたアクセスである。

Jul  3 11:43:03 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul  3 11:48:14 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul  3 11:53:20 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul  3 11:58:26 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul  3 12:03:34 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …

 約5分の間隔で“行儀よく”リトライしており、このようなアクセスはグレイリスティングを突き抜ける。しかし、人の目はだませない。送信者アドレスのユーザーIDがいかにも怪しいし、5回のトライで止まっていることから、スパムかウィルスに違いないと判断できる。このようなアクセスはけっこう見られる。
 佐世保高専の中原さんのレポートによると、2006年に入ってからグレイリスティングを突き抜けるスパムが増えてきたので、素のS25R方式に戻したとのことである。正当なメールを受け損なわないためには相当神経を遣う必要があるが、手動のホワイトリスティングの方がスパムには強い。「怪しい」と見抜くことにかけては人間の判断力に勝るものはない。
 単純なグレイリスティングに頼らずに、人間の知識と経験を活かしてホワイトリストの作成を自動化するというアプローチもある。東京外国語大学の芝野先生(「導入者の皆様の声」の7番)は、リトライ回数に加えてHELOアドレスと送信者アドレスとの整合性もチェックしてホワイトリストを自動作成するスクリプトを開発されている。

日曜日, 7月 30, 2006

Rgrey

 佐藤さんは、S25R方式にグレイリスティングを組み合わせたRgreyを作られた(qmail版のQgreyもある)。S25R方式の拒否条件に引っかかるホストに対して「450」を返し、リトライがあれば自動的に受け入れるというものである。postgreyにパッチを当てることによって実現している。
 これにより、ホワイトリスト作成の手間がほとんどなくなる。大規模サイトには良いシステムである。リトライするスパムは通過できてしまうので、素のS25R方式(手動ホワイトリスティング)よりはスパムの阻止率は下がるが、約95%は阻止できると聞いている。
 すでにグレイリスティングによってスパムの受信を十分に減らしているサイトでも、Rgrey(あるいはQgrey)の導入にはメリットがある。
 素のグレイリスティングでは、初めてSMTPアクセスをかけてくるホストに対して無差別に「450」を返し、リトライしてきたホストをデータベースに登録する。したがって、膨大な数のまともなメールサーバがデータベースに登録されることになる。
 それに対してRgreyは、S25Rの拒否条件に引っかかるホストに対してだけ「450」を返す。まともなメールサーバの大多数はS25Rの拒否条件に引っかからないので、グレイリスティングの対象にならずに通過できる。したがって、リトライさせられることによる送達遅れがなくてすむ。また、データベースが小さくてすむので、グレイリスティングサーバの負荷が軽くなるのである。
 一方、スパムの阻止率は、素のグレイリスティングに比べてあまり下がらない。不正メールの送信元の約98%はS25Rの一般規則に引っかかるからである(2004年4月の統計による。論文参照)。

土曜日, 7月 29, 2006

個人サーバ

 S25R方式に対して「ダイナミックIPアドレスの個人サーバをまるっきり無視している」という批判がある。まるっきり無視しているわけではないが、ダイナミックIPアドレスのサーバはスパム対策にはやっかいなのである。
 S25R方式を導入した受信側サイトでは、ダイナミックIPアドレスのサーバからのリトライアクセスを発見したら、そのIPアドレスをホワイトリストに登録するだろう。ところが、送信側サーバがIPアドレスを変えたら、それもまた登録しなければならない。こうして1台のサーバのためにいくつものIPアドレスをホワイトリストに登録していけば、それらのIPアドレスのうちいずれかが、スパマーのコンピュータやウィルス感染したPCやゾンビPCに割り当てられて、そこからスパムやウィルスを受信してしまうおそれがある。
 事情は、グレイリスティングを採用しているサイトでも同様である。グレイリスティングでは、初めてメールを送ってくるホストを一度「450」で蹴るが、二度目には受信して、その後は同じホストからの送信をすぐに受け入れる。したがって、ダイナミックIPアドレスのサーバによっていくつものIPアドレスに対して穴が開けられ、不正メールの受信のリスクが増えるのである。
 今、OP25B(Outbound Port 25 Blocking)を導入するISPが増えつつある。ダイナミックIPアドレスのサーバから外へメールを直接送信することができなくなる。どのみち、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えるか、いずれかの策が必要になる。そうしてもらえれば、S25R方式を導入しているサイトにとっても助かる。受信にまったく問題なくなるか、あるいは1サーバにつき1件のホワイトリスト登録ですむからである。

金曜日, 7月 28, 2006

一般規則

 私が作った一般規則は、なるべく多くのエンドユーザー回線を引っかけることができて、メールサーバを引っかけることがなるべく少ないように工夫したものである。作り上げるのに約10ヶ月かけた。逆引き名が一般規則に引っかかるメールサーバもあるが、少しくらいかまわないという考え方をとっている。送信をリトライしているうちにホワイトリストで救済すればよいからである。
 しかし、Kさんの会社(「導入者の皆様の声」の4番)では、逆引き名の一般規則のうちルール6(逆引きFQDNの最下位の名前が「dhcp」、「dialup」、「ppp」、または「adsl」で始まり、かつ数字を含む)しか使っていないそうである。逆引きできるメールサーバを蹴るのを避けるためである。逆引きできないメールサーバはホワイトリストで救済し、逆引きできるエンドユーザー回線はブラックリストで拒否するという考え方である。
 エンドユーザー回線からスパムやウィルスを送ってくる世界中のドメインをブラックリストに登録すると、ブラックリストは相当な大きさになると思う。しかし、マシンは高性能だし、運用のマンパワーにも不自由していないので、うまくいっているのだろう。
 いろいろな考え方があってよいと思う。逆引き検査に基づいてSMTPを選択的に拒絶するのだから、S25R方式であることに変わりはない。

ご厚意

 「導入者の皆様の声」の4番で紹介しているKさんの会社では、社長命令で謝礼としてシャンパンを贈ってくださった。せっかくのご厚意なので、ありがたくいただいた。おいしかった。
 社長がこんなに立派なお心の持ち主であればさぞかし良い会社だろうと思った。Kさんにお願いして会社を訪問し、お話を聞かせていただいた。社長自ら技術者からの提案を聞き、S25R方式の価値を認め、導入を判断されたそうである。出迎えてくれた人たちは皆、社長を信頼して生き生きと働いている様子であった。セキュリティ対策についての守秘を頼まれているので社名は明かせないが、本当に良い会社である。
 Kさんほか皆様、その節はありがとうございました。

木曜日, 7月 27, 2006

reject_unlisted_recipient

 BBSで質問を受けた。退職したユーザー宛にメールマガジンを送ってくるサーバがS25Rの条件に引っかかってリトライを繰り返している。リトライのログを見ているのもわずらわしいが、User unknownを返すためにホワイトリスト登録するのもわずらわしい。そこで、クライアントアドレスチェックの前にUser unknownではねる方法はないだろうかということだった。
 私は方法を知らなかったのだが、その人があとで自分で解決して教えてくださった。次のように設定すればよい。

smtpd_client_restrictions =
  permit_mynetworks,
  reject_unlisted_recipient,
  check_client_access regexp:/etc/postfix/client_restrictions,
  reject_unknown_client

 私は、HELOアドレスが不正なアクセスと不正中継を要求するアクセスもついでに「554」ではねてしまおうと考えた。前回説明した、DRACによるPOP認証のデータベースの指定と併せると、次のような設定になる。

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  check_helo_access regexp:/etc/postfix/helo_restrictions,
  reject_unauth_destination,
  reject_unlisted_recipient,
  check_client_access regexp:/etc/postfix/client_restrictions,
  reject_unknown_client

 これで、私の拒絶ログソーティングスクリプトで表示されるのは、宛先アドレスが正しいアクセスだけになる。ホワイトリストに登録すべきホストを見つけるための監視がずいぶん楽になった。

水曜日, 7月 26, 2006

POP-before-SMTP

 POP-before-SMTPをサービスしているメールサーバにS25R方式を実装すると、ISPのエンドユーザー回線に接続された正当なクライアント(モバイルPCなど)からのSMTPアクセスがS25Rの拒否条件によって蹴られてしまう。これを解決するには、POP認証されたクライアントのデータベースをsmtpd_client_restrictionsパラメータとsmtpd_recipient_restrictionsパラメータの両方で参照すればよい。
 たとえば、私が使っているDRACの場合は、以下のように設定する。ここで「dracd」が、POP認証されたクライアントのデータベースファイルである(実際のファイル名は「dracd.db」だが、「.db」を付けずに指定する)。

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  check_client_access regexp:/etc/postfix/client_restrictions,
  reject_unknown_client

smtpd_recipient_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  reject_unauth_destination

火曜日, 7月 25, 2006

Rule 1 trap

 一般規則のルール1(逆引きFQDNの最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む)に引っかかるメールサーバを持つ外国のサイトから苦情のメールが来たことがある。そこからのリトライアクセスを発見して、素早くホワイトリストに登録して受信した。
 そのサイトから日本の某サイト(ドメイン名は伏せ字になっていたが、「.ne.jp」が付いていた)へ送ろうとしたメールに対する遅延警告メッセージが引用されていた。そこには「may not be mail exchanger」という見覚えのある文。これを作った張本人をネット検索で突き止めたのだろう。苦情は「分断された2個の数字をホスト名に含む正当なメールサーバがあることを考慮してくれ」というものだった。
 私は、分断された2個の数字列をホスト名に含むエンドユーザー回線が多いことと、S25R方式をとるサイトでは拒否条件に引っかかるメールサーバをホワイトリスト登録しなければならないことを説明し、「貴サイトのホストを拒否しているサイトを教えてください。ホワイトリスト登録するよう私から言いましょう」と申し出た。
 しかし、それっきり返事は来なかった。宛先サイトでもちゃんとホワイトリスト登録して、送達に困らなくなったんでしょ、きっと。
 こういうこともあるので、ルール1は厳しすぎると思う人がいるであろう。実際、「3個以上の数字列」と条件を緩めて運用している人もいるようである。もちろん、人それぞれいろいろな工夫をしてくださってよい。
 しかし私は、ルール1の条件の提案を変えるつもりはない。数あるメールサーバの中でルール1に引っかかるものは少ないが、「2個の数字列」という条件でスパムやウィルスメールが食い止められる頻度はかなり高いからである。

月曜日, 7月 24, 2006

Unknown hosts

 S25R方式を発表して間もないころ、「逆引きできないホストに対する受信拒否は百害あって一利なしだ」という主張を引き合いにして「考え直したらどうだ」とメールで書いてきた人がいた。ホワイトリストの説明をちゃんと読んでくれていなかったようである。
 逆引きできない正当なメールサーバがあることくらい先刻承知である。しかし、逆引きできないホストのうち、ほとんどはエンドユーザー回線でスパムやウィルスの発信源になっており、正当なメールサーバはごく一部である。そこで、S25R方式では、逆引き名から素性を推定できないという理由により、応答コード「450」で蹴ってみるのである。それに対する規則的なリトライが検出されたら、正当なメールサーバであろうと推定できる。そこで、ホワイトリストで救済するのである。
 正当なメールを受信しないことは、受信者にとっても損失になる。逆引きできないという理由で、規則的なリトライを蹴りっぱなしにしたり、「5xx」を返してエラーリターンさせたりすることなど、どうしてできようか。
 ついでに言えば、私は、メールサーバは逆引きを設定してくれた方がよいとは思っているが、逆引きできないメールサーバをいまいましいと思ったことはない。逆引きできないメールサーバからの正当なメールは、黙ってホワイトリストで救済している。それで、以後の受信には支障がなくなる。送信元のサイトに逆引き設定を要求したことなど一度もない。
 ところで、hi-hoでは、逆引きできないホストからのメールを蹴るようにしたことがあるが、1ヶ月ほどでやめたそうである。正当なメールの救済策をとらなければ、ユーザーから苦情が殺到するのは当然である。スパムやウィルスを阻止するためなら、少しくらい正当なメールを巻き添えにしてエラーリターンさせてもしかたがないとでも思っていたのだろうか。グレイリスティングという救済策もあっただろうに。

日曜日, 7月 23, 2006

福音

 S25R方式について私が最もメリットを強調したいことは、スパムの阻止率よりも、実装の容易さである。Postfixの設定だけで実現できるので、Postfixのオペレーションがどうにかできるというくらいのスキルレベルの人でも導入できる。このことは、中小企業には福音になるであろう。
 中小企業では、自社のネットワークの運用のために高スキルのIT技術者を雇う余裕がないのが普通であろう。あるいは、高スキルのIT技術者は、稼ぐ仕事に回されて、自社のネットワークのめんどうをみる余裕がない。そのようなサイトでも、S25R方式は容易に導入できるのである。
 問題となるのは、ホワイトリストの作成である。私の個人サイトではホワイトリストはごく小さくてすんでいるのだが、ユーザーが多いサイトでは登録数は500~1000件くらいになると聞いている。初めのうちは、ホワイトリストの作成に手間がかかるであろう。とはいえ、手間がかかるだけで、手順は簡単である。ログを見て、正当なメールサーバからと思われるリトライアクセスを見つけ出し、そのIPアドレスまたは逆引きFQDNを設定ファイルに書き加えて、Postfixをreloadするだけである。高スキルを要する仕事ではない。私の拒絶ログソーティングスクリプトを利用すれば、リトライアクセスを見つけ出す作業はいっそう容易になる。
 導入者の方々からの報告によると、ホワイトリストは際限なく増え続けることはないようである。2週間から1ヶ月もたてば、ホワイトリスト登録の頻度は少なくなるとのことである。
 1000人以上の規模のサイトになると、手動でホワイトリストを作るのは現実的でなくなるかもしれない。そのくらい大規模な組織では、佐藤さんのRgrey(S25R+postgrey)を導入するとよいだろう。必要なスキルレベルは、素のS25R方式よりも少しだけ高くなるが、大規模組織ならそのくらいのスキルを持つ人を確保するのは容易であろう。

「25」とは?

 「Selective SMTP Rejection」を略して「S25R」。「25」とは何かというと、SMTPのポート番号である。私の論文の対象読者であるメールシステム管理者には当たり前の知識なので、なぜ略称で「SMTP」が「25」に置き換わっているのかなどという説明は書かなかった。
 常識的な略し方なら「SSR」とでもなるところだろうが、元々略称である「SMTP」(Simple Mail Transfer Protocol)をさらに「S」と略すのは好きでなかった。だから、「SMTP」を短くするためにポート番号に置き換えたわけである。
 スパム対策についての知識がある方ならピンとくるであろう。スパム対策の一つである「OP25B」(Outbound Port 25 Blocking)を意識したネーミングである。ご存じない方のために説明すると、OP25Bとは、ISPが自社網のダイナミックIPアドレスのエンドユーザー用回線から外へ宛先ポート番号25(つまりSMTP)のパケットが出るのを禁止するという策である。

土曜日, 7月 22, 2006

広まりつつあるS25R

 S25Rスパム対策方式を発表してから2年たった。今ではかなり広く注目されているらしい。批判もあるが、支持者の方が圧倒的に多そうなことが、検索から見てとれる。「予想以上の効果に驚いた」という証言がウェブページやBBSで見つかる。「導入者の皆様の声」への掲載を承諾してくださった方だけで現在11人。ほかに、メールやBBSで質問やホワイトリスト情報を寄せてくださった導入者の方々が数人いる。私には知らせてもらっていないが、導入していると公表しているサイトが見つかる。このことから推測すると、導入しているサイトは100を優に超えるのではないかと思う。うれしいことである。
 S25R方式の広まりは、もちろん私だけによる成果ではない。qmailに実装した廣島さん、sendmailに適用可能にした伊藤さん、Postfixとqmailでグレイリスティングとの組み合わせを実現した佐藤さんらのボランティアのおかげである。大規模サイトでの導入について貴重な情報をくださった方々もいる。これらの方々に心から感謝したい。
 このブログでは、S25R方式に関する雑多な情報をつれづれなるままに報告しようと思う。関心を持ってくださっている方々の参考になれば幸いである。
 さて、いつまでネタが続くことやら…