メールゲートウェイの話
Internet : ↑internet MailGateway ------ : ↓local network MailServer
こういう構成のメールゲートウェイを作る場合にMailGatewayが困ることになるであろう最大のポイントはメールキュー。
近頃のSPAMという奴の中には、特定のドメイン宛にランダムなユーザ名をしこたま送ってくる物がある。数千/数万通も。
- 宛先は自ドメインだからMailGatewayは一旦それを自分のメールキューに登録
- それなりの配送並列度でMailServerへ送るべくSMTPで接続
- MailServerにはそんなユーザはいない
- 550 User unknown を返し、MailServerはそのメールを受け取らない
結果として、メールはMailGatewayのキューに溜まることになる。
メールのバウンス
SMTPのプロトコルとして、配送エラーになったメールはバウンスしなければいけない(MUST)ことになっている(RFC2821)。
近頃のSPAMは初めからバウンスで送り返されることを期待して、本当に送りたいあて先をFrom:に記述し、適当なメールサーバに投げている。バウンスはFrom:に記述されたアドレスに送られるから、言うなればこれはバウンスとは名ばかりのSPAM代行送信。メールサーバは正しく送信すべきメールを出せないほどSPAM送信に励む、なんてことになりかねない。
こういう状況だから当然バウンスすべきでないという話は既に出ていて、↓こんなInternet-Draftもある。
http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-01.txt
乱暴な要約をしてしまうと、「エラーメールはひっそりと消すべき(SHOULD)で、犯人が知れたらISPに教えるのもアリだね(MAY)。」
ちなみに上記は http://moin.qmail.jp/ がネタ元。(筆者の方の主観的な主張が強いので鵜呑みにすると偏ります、というのは俺の主観)
SPAM対策の基本
漠然とした言い方をすれば
- キューに入れない
これに限る。キューに入れないためにはいくつか方法がある。
- 送信元のDNS情報を検査
- RBLを使う
- Tarpitting/Throttling
- ニセのバウンス対策
- ユーザ存在チェックを先に行う
有効な手段はこんなところか。IP逆引きによる云々もあるけど除外。
送信元のDNS情報を検査
送信元のメールアドレスの@以降で
- MXレコードを検索
- Aレコードを検索
どちらもなければ無効なメールアドレスとして排除する方法。ただ、近頃は他人のメールアドレスを書かれる事が多いので性能は疑問。
RBL
RBLには問題もあって、管理する手間も問題ではあるんだけれど(RBLを使わない事による手間もわかるけど)、まずは導入にかかる手間を考えたい。
この話はホント、日ごろの情報収集を怠るとえらい目にあう話なんだと思う。RBLが応答しない時にMTAがどう動くか、という検証もしておいたほうが良いと思うし。(MTAによるんだろうなぁ。未調査。)
tarpitting
1つのSMTPセッションで大量のRCPT TOコマンドを送ってくる事も多い。
ある数以上のRCPT TOコマンドの応答にDelayを入れると、単位時間あたりに受け付けてしまうメールの総数を減らすことが出来る。
結果として、SPAM送信者にとって"使えないMX"となる。このようにわざとゆっくり応答する事を、TarpittingとかThrottlingと言う。
ニセのバウンスメッセージを弾く
バウンスメッセージのenvelope-fromは<>で、これは前述の通り拒否してはいけないことがRFC2505で決まっているから、バウンスを装ったメールも多い。バウンスは送信者に行われるものだから、バウンスメッセージの宛先は必ず一つ。
ニセのバウンスメッセージは複数の宛先を書いてくるからこれを排除する。
