| 前 | 2005年 5月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
「ErrorProtector / DriveCleaner / ErrorSafe / SystemDoctor / WinFixer / WinAntivirusって何?」と思う方はこちらへ。
「ErrorProtector / DriveCleaner / ErrorSafe / SystemDoctor / WinFixer / WinAntivirus をどうしよう?」と思う方はこちらへ。
今月7日から、拙作 SpamAssassin 用 user_prefs に、個々の環境に依存するルールを加えました。
これまで、誰もが簡単に SpamAssassin を導入し利用できるようにするため、個々のメイル受信環境に依存しないルールを心がけて書いていました。
しかし、現状の日本語 spam の大多数は、プロバイダの動的 IP から受信 MTA に対して直接送信されるタイプの spam ばかりであり、 DNSBL (RBL) の効果が期待し難いものばかりです。
動的 IP ですので、プロバイダの動的 IP を全て弾くこともできません。
この問題に関して、以前から悩んでいましたが、今般、この動的 IP から直接送信される spam を捕捉する為のルールを追加することにしました。
これは私のメイル受信環境に大きく依存するので、大部分の他の方には使えない、汎用性のないルールになってしまっています。
したがいまして、このルールを利用する際には、利用者自身のメイル受信環境に合わせて書き換える必要が生じます。
簡単ではありますが、以下にルールの概要と書き換えの留意点を記します。
なお、以下の文章では便宜的に「動的 IP から受信 MTA へ直接送信される spam」を「ダイレクト spam」と、仮に称します。(ぐぐってもこれに相当する略称が見つからなかったので、やむを得ず造語してしまいました。ご容赦を。)
ダイレクト spam を検出するルールの例を以下に記します:
header DIRECTOCNDYN Received =~ /from .+(p[0-9]+-[a-z0-9-]+\.[a-z]+\.ocn\.ne\.jp|219\.16[0-5](\.([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){2,2}).+by (mail\.flcl\.org|ums5[0-9][0-9]\.nifty\.ne\.jp|(mbox53|m(x|ail)5[0-9][0-9])\.nifty\.com|(alt|dns|mta|ybbmta)[0-9][0-9]\.mail\.(bbt\.|mci\.){0,1}yahoo\.co\.jp)/
describe DIRECTOCNDYN directly received spam from OCN
score DIRECTOCNDYN 8.0
上記ルールは、例えば以下のようなヘッダの捕捉を目的としています:
Received: from BSD (p5038-ipad07kamokounan.kagoshima.ocn.ne.jp [60.38.245.38])
by mail.flcl.org (Postfix) with SMTP id 7005683BE5
for <yoh@flcl.org>; Tue, 10 May 2005 15:50:30 +0900 (JST)
はっきり言って、やっていることは非常に地味です。
ダイレクト spam の Received: 行の特徴をそのまま検出しよう、ということです。
この例では、鹿児島の OCN ダイヤルアップらしき IP から mail.flcl.org へ直接送信されています。
ルールは、上記ヘッダを大きく二つに分けて見ています。
一つは、送信側 FQDN 或は IP アドレス。
もう一つは、 "by" 以降に記されている、受信側 MTA の FQDN 。
この二つを正規表現で記述することで、実現しています。
上記 Received: 行は受信側 MTA が記す内容ですので、偽装されるものではありません。
したがいまして、 "by" 以降の受信側 MTA の FQDN を検索キーワードとして grep すれば、Received: 行に記される動的 IP が分類できることでしょう。
/from .+(p[0-9]+-[a-z0-9-]+\.[a-z]+\.ocn\.ne\.jp|219\.16[0-5](\.([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){2,2}).+by (mail\.flcl\.org|ums5[0-9][0-9]\.nifty\.ne\.jp|(mbox53|m(x|ail)5[0-9][0-9])\.nifty\.com|(alt|dns|mta|ybbmta)[0-9][0-9]\.mail\.(bbt\.|mci\.){0,1}yahoo\.co\.jp)/
↓
from .+(p[0-9]+-[a-z0-9-]+\.[a-z]+\.ocn\.ne\.jp|219\.16[0-5](\.([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){2,2})
.+by (mail\.flcl\.org|ums5[0-9][0-9]\.nifty\.ne\.jp|(mbox53|m(x|ail)5[0-9][0-9])\.nifty\.com|(alt|dns|mta|ybbmta)[0-9][0-9]\.mail\.(bbt\.|mci\.){0,1}yahoo\.co\.jp)
送信側 FQDN 或は IP アドレスについては、プロバイダ毎にきっちり調べて記述します。
途方もない位大変な作業かと思われるかも知れませんが、案外そうではありません。
何故なら、日本語 spammer が利用するプロバイダは限られているからです。
1〜2年分の日本語 spam の Received: 行を grep でご覧になってみて下さい。
無尽蔵ではない筈です。
なお、これまで私が受信した日本語 spam において利用されていたプロバイダの大体半分位は、既に user_prefs に記述を済ませています。*1
受信側 MTA の FQDN についても、利用するプロバイダ毎にきっちり調べて記述します。
利用するプロバイダの数が多ければ多い程大変になるかも知れませんが、過去に受信したダイレクト spam の Received: 行を grep すれば、おおよその見当が付きます。
この、受信側 MTA の FQDN の部分が、利用者毎に書き換える必要のある部分となります。
なお、書き換えの際は、 Pop Before SMTP 等、プロバイダの MTA の認証を経て送信している Received: 行にはマッチングさせないように心がけて下さい。
例え spam であろうとも、正規のルートでメイル送信を行っている限り、これをルールで引っかけてはいけません。
例えば、 yahoo.co.jp ですと、 FQDN が "smtp" で始まるメイルサーバは認証を行っているものと判断されますので、これを by 以降に含めてしまいますと、認証を行ったメイル迄も弾く結果となってしまいます。
下記は実際の spam のうち、認証を経ているものの抜粋です。
Received: from smtp21.mail.bbt.yahoo.co.jp (smtp21.mail.bbt.yahoo.co.jp [202.93.85.136])by mx504.nifty.com with SMTP id j3Q4C8gj018535
for <********@nifty.com>; Tue, 26 Apr 2005 13:12:09 +0900
Message-Id: <200504260412.j3Q4C8gj018535@mx504.nifty.com>
Received: from unknown (HELO SourceNextCom1175031502) (ko?zack?057@61.203.167.177 with login)
by smtp21.mail.bbt.yahoo.co.jp with SMTP; 26 Apr 2005 04:12:08 -0000
X-Apparently-From: <ko_zack_057@yahoo.co.jp>
以上のようにして作成したルールは、実質的に利用者自身のメイル受信環境でしか使えないルールとなってしまいますが、極めて効率良く spam の検出確率を向上させることができます。
このルールとベイジアンのスコアや DNSBL / URIBL 等を meta ルールで論理積させてスコアを加算させれば、更に spam の検出確率を向上させることができるでしょう。
「 spam はダイレクト spam に限られない、固定 IP を経由して来るものもある」と思われる方。
確かにそうですが、そのような固定 IP は、第三者中継 MTA か、 spammer が契約して確保した踏台 MTA でしょうから、殆どが DNSBL (RBL) に登録されていることでしょう。
また、「中国や韓国から直接来るダイレクト spam の記述がないじゃないか」と思われる方。
中国・韓国方面からの spam で誤検出された事例は、私の手元にはありません。
全て高得点で spam と判断されます。
*1 まー、 FreeBit と OCN と Infosphere 辺りを抑えておけば、7割はカバーできると思います。(笑)
「なお、書き換えの際は、 Pop Before SMTP 等、プロバイダの MTA の認証を経て送信している Received: 行にはマッチングさせないように心がけて下さい。」とありますが、yahoo.co.jpのように認証を行っているメールサーバー別に<br>なっていない場合はどうしたらよいのでしょうか?<br><br>SMTP-AUTH認証を経て送信された Received: 行にマッチ<br>してしまいました。<br>---<br>Received: from yasumi (p3139-ipad87marunouchi.tokyo.ocn.ne.jp [221.188.38.139]) (authenticated) by mail530.nifty.com with ESMTP id j5CDwY5R018555; Sun, 12 Jun 2005 22:48:35 +0900
ご報告有難うございます。<br>"DIRECT*" の正規表現の記述の、<br><br>.*by (mail\.flcl\.org|<br><br>の箇所を、<br><br>.{0,3}by (mail\.flcl\.org|<br><br>と書き換えて下さい。<br>更新した user_prefs は明日に tlec web に上がると思います。
早速、tlec web に上がったもの試して見ましたが、やはりマッチするようです。
おっしゃる通り、修正を失敗していました。<br>以下を試してみて頂けませんか。<br>http://www.flcl.org/~yoh/problem/user_prefs.050616171041
どたばたしていて返事が遅くなりました。<br>こちらは大丈夫でした。<br>#(authenticated)があればマッチせず、なければマッチしました。<br><br>ちなみに、MTAによってはSMTP-AUTHしてもこのような文字列は付かないようですが、しょうがないですよねー。
一つ言い忘れましたが、「や」さんご自身が nifty のメイルアカウントを使っていない場合、拙作ルールを書き換える必要が生じます。<br>私はたまたま<br><br>- flcl.org<br>- nifty<br>- yahoo.co.jp<br>- freemail.ne.jp<br><br>を利用しているので、<br><br>[^(a-z]{0,3}by (mail\.flcl\.org|[a-z0-9]+\.nifty\.((ne|co|ad)\.jp|com)|(alt|dns|mta|ybbmta)[0-9][0-9]\.mail\.(bbt\.|mci\.){0,1}yahoo\.co\.jp|fm[1-6]\.freemail\.ne\.jp)<br><br>というルールを書いていますが、もしも nifty を使っていない場合は、<br><br>[^(a-z]{0,3}by ((alt|dns|mta|ybbmta)[0-9][0-9]\.mail\.(bbt\.|mci\.){0,1}yahoo\.co\.jp|fm[1-6]\.freemail\.ne\.jp)<br><br>こんな風に nifty の MTA にマッチする正規表現を削除して、ご自身のメイルアカウントの受信 MTA にマッチする正規表現を追加する必要があります。