Spam Mail

目次

• 0.0.1  異変
• 0.0.2  原因
• 0.0.3  スパム対策
• 0.0.4  顛末
• 0.0.5  スパムフィルター
• 0.0.6  構想

2007/10/18 追加
2007/10/16

異変

研究室に行くと僕の Plan 9 端末が異変を起こしている。

	No physical memoty

のメッセージを出し続けているのだ。勿論何もできない。リブートしてもやはり

	No physical memoty

だ。ブート時のメッセージは 128MB で、これは正しい値だ。メモリーがやられた訳ではない。

原因

この間、システムのアップデートはしていない。何が起こったのだ?! 調べて行くと、Plan 9 端末が立ち上がる時に実行される

	$home/lib/profile

の中の

	upas/fs

が問題を引き起こしている事が判明した。これはメールボックスのメールを全てメモリーに読み取るのだ。僕のメールボックスのサイズを調べると何と 72MB だ。

	alrw--w--w- M 9 arisawa upas 71817426 Oct 16 17:00 mbox

メールボックスの最初のメールが

	Tue Oct  9 13:09:13 JST 2007

で、最後のメールが

	Tue Oct 16 16:15:10 JST 2007

であるから、一週間で 72MB だ。この殆どがスパムメールなのだ。

スパム対策

僕はスパム対策はしていて、スパムの 90% 程がカットされている。その方法は僕のページの「スパム対策」で述べられている。その結果、僕が POP で僕のサーバーから受け取るスパムメールは、大学のサーバーから受け取るスパムメールに比べて遥かに少ないのだ。しかし、それでも僕の貧弱な Plan 9 端末にとっては多過ぎる!

面白いページを見つけた。

• 阻止率99%のスパム対策方式の研究報告
  http://www.gabacho-net.jp/anti-spam/anti-spam-system.html
  

このページでは、 ISP のメールサーバーを経由していないメールをカットすべきだとして、その場合のノウハウが詳しく解説されている。僕の Plan 9 はどうか? Plan 9 ではメールの制御は /mail/lib/smtpd.conf で設定する。smtpd のマニュアルには次のように書かれている。

verifysenderdom [on|off]

When on, smtpd verifies that the first domain of the sender's address exists. The test is cursory; it checks only that there is a DNS delegation for the domain. Setting the option on is equivalent to specifying the –r command line option and is useful for detecting some unreturnable messages as well as messages with randomly generated domain names.

このマニュアルのこの部分は少なくとも 2000 年 10 月以来変更はない。「detecting ... randomly generated domain names」をどのように行っているのかはソースコードを読まない限り分からない。僕のシステムはこれを on にしているが、しかしまだ random domain name のようなものが混ざっている^注1。先の「研究報告」はこの部分にノウハウがあるのかも知れないね。でも阻止率 99% って凄いな。

顛末

2007/10/17

メールボックスのメールを分析してみると、今回のトラブルは 69MB ものファイルを添付したメールを受け取ったことから発生した事が分かった。しかもこれはスパマーからのものではない。馬鹿な奴だ。
Plan 9 の smtpd はこんな大きなメールを受け取れる事が証明されたが、これは僕にとっては幸せな事ではない。メールの最大サイズを指定できれば良いなと思うが、今回改めてマニュアルを見たが、残念ながら無いようだ。

スパムフィルター

2007/10/17

Plan 9 には僕の気に入ったスパムフィルターがない。

スパムフィルターにとって大切な事は、必要なメールは確実に受け取れることだ。例えば僕がメールを送った相手からのメールは無条件に受け取らなくてはならない。

スパムではないが、僕には時々見知らぬ人からのメールが来る。スパムとこうしたメールとの区別が厄介である。しかし、初対面の相手が添付ファイルを送ってくれば拒否して良いであろう^注1。あるいは少なくとも、そのファイルは添付から削除すべきた。(これは 100% ウィルスだ!)

現在の僕のシステムは送信と受信との連係プレーができていない。もちろん大学のシステムもである。連携プレーができれば、スパム対策はもっと効果が上がるのだ。この問題は解決が易しいだろう。やってみよう。

僕の所に来る HTML メールは殆どがスパムである。もっとも iTune や amazon から HTML メールが来る。

構想

2007/10/18

以下はスパムフィルターに関する構想である

インストールの場所は /mail/box/arisawa/pipeto
理由:

• 実験的な色彩が強い
  
• 個人的好みが強い
  

データファイル:

• white
  
• black
  

この置き場所は /mail/box/arisawa/
評価順序 white -> black

判定には正規表現を使う事

以下の方法は過激か? (要吟味)

• メールを送信した相手は自動的に white に登録されるべし
  
• white に無い相手が添付ファイルを付けていれば、添付ファイルを削除する事(名前は残す事)
  
• white に無い相手が HTML メールを送って来たら捨てる事
  
• sender の DNS 情報を利用する事^注1
  
• 判定がグレーなものは受け取る事
  
• メールのサイズに上限を設定し、超えたものは途中で切る事。またその事が分かるようにする事
  

black への自動登録は極めて難しい。例えば otori@ar.aichi-u.ac.jp に来るメールは 100% スパムである。このアドレスは僕が公開ページの中でコメントとして、見えないように埋め込まれた囮のアドレスだからだ。従って、ここに来るメールの発信元の情報は black を作る上で利用できる。しかし、現在はアドレスが DHCP で割り当てられる時代であるから、直ちには black にはできないのである。

black に登録されたアドレスは HP から見えるようにする。

メールを出す相手が個人ではない場合、こちらから出したアドレスと、相手が出すアドレスは同じとは限らない。また個人の場合には複数のアドレスを使っているケースがある。どう扱うべきか?

僕のメールには必ず「HTMLメールは受け取らない」と断り書きを付ける必要がある。

white や black への登録/削除のインターフェース: メールによるインターフェースを持ちたい。でないと面倒で...

実際にフィルターを組み込む前に、適当なユーザ名で実験する事

ところで、昔はネットでソフトを買った場合に、そのソフトをメールに添付して送られて来たが、今は違う。今はメールにはそのソフトのダウンロードアドレスが記載されているだけである。この方が合理的だ。実際にダウンロードされたか否かの管理が可能だからだ。