Logo address

Spam Mail

目次

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 端末にとっては多過ぎる!

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

このページでは、 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% って凄いな。

注1: 僕はこのマニュアルの読み方を間違えていたようだ。このオプションを on にする事によって、送り主の IP を基に、その DNS アドレスが確認されるだけで、(そしてその情報は有用である事が強調されているが)、それに伴うアクションについては述べられていない。この情報の利用は他に任せられていると考えるべきであろう。(2007/10/18)

顛末

2007/10/17

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

スパムフィルター

2007/10/17

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

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

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

注1: 僕は学生からの添付ファイルを受け付けなくてはならないので、添付ファイルを許す相手の集合を定めておく必要がある。

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

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

構想

2007/10/18

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

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

データファイル:

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

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

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

注1: DNS に登録されていないもの、または明らかに sender の IP アドレスから自動生成されたものは捨てる事。他方、IP アドレスをエンコードした場合の最小サイズが存在する。それより小さなものは FQDN だと判断して良いだろうか?。必ずしも 4B の全てがエンコードされて行く訳ではないだろう。ISP が割当可能な IP の範囲は狭い。

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

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

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

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

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

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

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