_ おお、気がつけばもう10月もだいぶ過ぎたな。間の空いたこの10日ほど何をしていたかというと、何もしてなかったよーんほえほえ。いや、仕事はしてたけど。
_ ディスク障害な自宅サーバその後。外に出しているマシンを切り替えて引退させた後、再度電源を入れて様子を見てたけど、なかなか死なない。切り替える直前は uptime が1日もたなかったが、今度は何事もなく数日ほど動き続けている。……が、週末の cron でディスクを総なめしたタイミングで落ちた。仕事してないからディスクアクセスもなく、それで秘孔を突かなかっただけらしい。
_ 送信元をチェックする仕組みを入れやがれ。
_ Twitter でイチイチ follow するのが面倒くさいちうことで、届いたメールにスクリプトで自動で follow するスクリプトだそうな。でも、これ、どこから届いたメールなのかまったくチェックしてないよね。赤の他人であっても、このスクリプトが起動されるメールアドレスがわかれば twitter から送信されたメールに装って（というか偽装する必要すらなく URL を本文に入れるだけで）自動的に follow させることが可能になってしまう。
_ 今ごろ目についたからケチをつけてみたけど、別にこれにかぎったことじゃない。今年の春ごろ、携帯メールから twitter を update するスクリプトを書いたよー、というネタをいろんな人が書いてたけど、ほとんどのものは送信元をチェックする仕組みがなかった。スクリプトを設置したアドレスがバレると赤の他人が自分を装って更新できてしまうというお粗末なモノばかり。twitter の状況はほとんどおっかけてないからわからんけど、twitter spam というのがもしあるとすれば、こういう甘いスクリプトは踏台になってしまう。
_ このことはもちろん twitter にかぎらず、特定のアドレスからのメールだけを処理すること念頭に置いたスクリプト全般に言える。不特定に使われちゃ困るものはちゃんと制限かけておけよ、と。
_ つづく。
_ わしの ~/.mailfilter （maildrop の設定ファイル）からてきとーに改変抜粋。
ちうわけで、スクリプトの中身では一切判定せず、スクリプトを呼ぶ側で判断させてる。この場合は SPF で判定させてるけど、SPF が信用できない場合には if 文をif ( /^Authentication-Results: mx\.maya\.st from=ケータイのメールアドレス;.*spf=pass/:h ) { to "| /path/to/script" }のように書き換えれば、スクリプトの方は一切いじらなくても、X-Hoge というヘッダにパスワードが含まれていた場合だけスクリプトを起動する、というように発動条件を変更することがカンタンにできる。なお、これはあくまで一例であって、ほかにもいろいろ方法はある。こうじゃなきゃダメとかこれが最上の方法だとかいう主張ではなく、わしはこうしてるというだけ。if ( /^X-Hoge: ぱすわーどみたいなの/:h )_ なお、「SPF が信用できない場合」というのがどういう場合かというと、ほとんどすべての場合。SPF は送信ドメイン認証であって送信者認証ではない。hoge@example.ne.jp が fuga@example.ne.jp と詐称しても、SPF では example.ne.jp が正しいかどうかの判定だけで、hoge か fuga かのチェックはしないから詐称を見破れない。例外的に、携帯電話からのメール送信で from を詐称できる穴が存在するという話は聞いたことがない（ないよね？）ので、携帯からのメールが SPF に pass すれば、ローカルパートも正しいと判定しちゃって問題ないと思う。あるいは、SMTP AUTH 必須かつユーザと From が一致しないメールを拒否するような厳しい運用をしているようなところならば、これも SPF を信用してもいいだろう。ただし、そういう運用をしているかどうかを外部から知る一般的な方法はないので、不特定のアドレスに適用することはできない。
_ SPF についてもうひとつ補足。Authentication-Results: や Received-SPF: などのヘッダも簡単に偽装できる（ 実際に偽装された例）。つまり、このヘッダ自体も無条件に信じてはいけない。外から届いていたときにすでにあった Authentication-Results: と、自分のサイトで判定した結果付加された Authentication-Results: をはっきり区別して、前者は偽装ヘッダとして確実に捨てる必要がある。どうやって区別するかの方法は実装によるので一概には言えない。たとえば postfix + sid-milter の場合は、header_checks に
と書いておけばよい (*1)。milter が付加するヘッダは header_checks にひっかからないので、このヘッダがついた状態で外から届いたものだけを捨てられる。postfix を使っていても、milter ではなく policy daemon や smtpd_proxy_filter を使うフィルタはこの方法では区別できないはずなのでので注意（未確認だけど）。content_filter なら同じ方法でできるはず（やっぱり未確認）。どこが違うのかは、postfix の処理の流れでフィルタと header_checks のどっちが先に実行されるかを考えればわかるはず。/^Authentication-Results: (自分とこのホスト名)/i IGNORE
(*1): IGNORE では該当ヘッダを消すだけだが、場合によっては DISCARD でメールごと消したり REJECT で拒否してもいいと思う。