さくらインターネットで迷惑メール対策のためにmaildrop（mailfilter）を手動で書き換えてみた
さくらインターネットで迷惑メール対策のために
maildrop（mailfilter）の手動修正してみて、
ひっかかったこと、エラーをおこしたときの挙動、
ほか知っておくべきだと思ったことをつらつらと書いてみました。
maildropは、メールの配信プログラムです。
様々なレンタルサーバーで利用されているらしく、
ぼくが長年使っている、さくらインターネットでも利用されています。
このmaildropを手動で書き換えることで
迷惑メール対策のレベルが大幅に向上します。
ただ、勝手にプログラムを書き換える技なので
自己責任ですし、書き換えについても
自分の受信状況ややりたいことなどによって、
色々と試行錯誤が必要になってきます。
本記事では色々やってみて苦労したので、
あれこれ試したなかで、つまづいたことや知っておいたほうがよいなと
思ったことを、メモとして書き残すものです。
また実際のプログラム記述にはほとんど触れていないので
あらかじめご理解ください。
理由は、書く気力がもたなかったので。
別の機会に書きたいとは思ってます。
はじめてにひとこと。
実際のプログラムの書き換えをやってみると分かるのですが、
ひとつひとつの設定だけをみると出来ないことも
無いように思えると思います。
が、長期的なメールの運用を考えると
maildropの手動運用は結構大変だということも分かってきます。
レンタルサーバーを借りている時点で
ある程度ウェブに精通している人も多いかと思いますが、
決してパパっと出来るものではないので
やるなら少し腰を据えたほうがよいと思います。
ここから、本題です。
■■maildropの書き方でつまづいたことなど認識しておくことまとめ
■if文の開始タグの位置
一般的なプログラムの書き方の注意点と
ちょっと違う約束があるので注意です。
if文の開始 { はifと同じ行の末尾に置くとエラーになります。
【×間違った書き方】
if ( /^X-Spam-Flag:.*YES/ ){
to “maildir/.spam/"
}
【〇正しい書き方】
if ( /^X-Spam-Flag:.*YES/ )
{
to “maildir/.spam/"
}
■プログラムにエラーがある場合のメール配信について知っておく。
エラーがあると、メールは配信されずに溜まります。
たぶん、消えはしません。
エラーを解消すると、溜まっていたメールがまとめて配信されます。
■【重要】ウェブ上からの書き換え対策が必要！
今回、maildropプログラムを手動で書き換えていますが、
ウェブメール上から設定変更をすると、
プログラムの記述が自動的に書き換わる仕組みになっています。
なので、苦労してプログラムを手動で書き換えても、
ウェブメール上で設定変更を保存すると、
プログラムの記述が勝手に書き換わります!※
※————————————–
ウェブメールを全く利用しないなら
書き換えを気にしなくていいかもしれませんが、
ウェブメールを利用している場合は、
誤って設定変更してしまって手動で書き換わらないような
工夫などが必要になります。
調べたところでは「if文の条件の末尾に書き換えを回避できる条件を入れる」
というのがポピュラーなようでしたが
若干面倒に思ったため、ぼくはそれは行いませんでした。
このあたりは別の機会で。
————————————–
また、手動でプログラムを書き換えた場合でも、
ウェブ上から設定変更した場合でも、
メール配信プログラムを同じ設定状態にすることが可能ですが、
プログラムコード自体は、違うものになることも多いです。
ウェブメール上で確認できる設定状態は、
ウェブ上から設定保存したときに
自動的に書き換えられる構文の状態で無いと、
その状態をウェブに反映しません。
なので、手動でプログラムを書き換えた場合、
ウェブメールの設定上からみたとき、
設定が反映されていないように見えてしまいます。
設定が反映されてないと思ってウェブ上から変更してしまうと、
機械的なコードの書き換えが発生して、
手動で書き換えたコード全体に影響が出てしまう、
という落とし穴にひっかかってしまいます。
ぼくはこれを回避するために、
手動書き換えの前に、ウェブメール上の設定から
迷惑メールフィルタの状態や受信拒否リストの状態、
それぞれ要点としては、迷惑メールを受信した時の動作と、
受信拒否リストにマッチした場合の動作、ですが、
それを設定してから、
プログラムファイル（.mailfilter）を開いて、
自動的に記述された設定ファイルの構文には一切ふれずに、
そのほかの部分に記述をしていくことにしました。
機械的に自動挿入で記述されたコードは
いじらずそのままにしておくことで、
プログラムコード上の命令と、ウェブ上の設定で見た状態が一致する状態となり、
混乱を招きません。
構文が一致していれば、ウェブ上での設定の見た目の状態も一致します。
言い換えれば、構文以外には変更があっても、ウェブ上と一致します。
たとえば、迷惑メールを受信した時にどこに移動するのか、の
移動先のファイルパスを手動で書き換えても、
ウェブ上で見てもその状態となり、コードとウェブでの見た目が一致します。
また、構文まるごと別の行に移動するのも問題ありません。
ですが、ifを別のifに入れたりするとダメです。
また if文の途中で半角スペースをひとつ追加するだけでもダメでした。
ウェブ上で確認できる設定状態と、プログラムコード上の命令が一致することで、
混乱を招かず、ウェブから設定変更しようという気もおこりにくくなると思います。
とはいえ、それでもウェブ上から設定変更して保存してしまえば
自動書き換えが発生してしまいます。
なので手動書き換えする場合は、バックアップをとっておくのは必須です。
書き換えが発生した場合、どんなふうに書き換えされるのか？
以下で、判明した範囲を書いておきます。
・ウェブ上の設定変更によるプログラムコードは、
設定ファイル（.mailfilter）の先頭に挿入される。
既存の記述はそのあとに続く感じになる。
⇒プログラムの順序も処理に影響するので、厄介です。
・空白行はなくなります。
・コメントはすべて削除されます。
⇒分かりやすいようにいれていたコメントも全て削除されます。
・変数が以下のようなかんじになり、
⇒エラーで動かなくなりました。厄介です。
NORMSUB = $MATCH1
UTF8SUB = `echo $NORMSUB | nkf -mw`
↓
NORMSUB “= $MATCH1"
UTF8SUB “= `echo $NORMSUB | nkf -mw`"
…このように、自動的な書き換えの影響は大きいので
手動書き換えで運用するなら、
極力ウェブからのメールの設定変更は避けるべきです。
疲れたのでここらへんにしておきます。
どんな処理に変更したのか、実際のプログラムコードにも
ふれたかったのですが…冒頭にも書きましたが、
今回では余力がなかったので、別の機会にします。
●参考
メール < Wiki | さくらのレンタルサーバ非公式FAQ http://faq.sakuratan.com/wiki/wiki.cgi?%A5%E1%A1%BC%A5%EB#i22