Contents
SMTP/MTA で spam を撃退する方法
安心して接続制限や受信制限を行なえる方法を提案しています。 一例 お馴染さん方式
- spamの多くを受信しないですませるものです。
- メイル本文を解析して判断する方法は扱いません。
- spamを受信してからフィルターで捨てるのではありません。
spam対策はメイル送信の原理を理解してから： http://www.zvon.org/tmRFC/RFC2821/Output/index.html RFC 2821 SMTP
RFC 2505関連 Anti-Spam Recommendations for SMTP MTAs
SMTP/制限することの長短 -- MTAでspam対策されない理由 -- ISPでやって欲しい対策
spamはどこから送られてくるか -- spamを送信してくる様子
SMTP (RFC 2821 解説)
spam 送信ホストには牛歩戦術と一時エラー返答が有効です
ゆっくり受信する 牛歩戦術 ことで (spam)メイル送信能率を大幅に低下させます。 ただし、受信サーバ側にも資源が必要です。
SMTP/一時エラーを返答するのも有効です。ただし、通常の送信サーバ相手に 対してはできるだけ使わないようにしたいものです。
身元の不確かなホストからの SMTP/接続を判別するのに使います。
あやしい相手にはゆっくりと対応します。 相手があきらめるのを待ちます。spam量を制限することにもなります。
- RFC を守っている MTAを使っているまともな相手には
再接続してくるような返答(SMTP/一時エラー)をします。
制限なしで受信する(ホワイトリスト)ような選択も可能です。
http://www.jca.apc.org/~nezumi/techdoc/Spam-Filtering-for-MX.ja/html/index.html
- Exim を対象に書かれたドキュメントのようですが、とてもよく説明されています。
1. SMTP 接続させない方法
ルータや ipfilter などでの排除/別ホストへの誘導
- DNS での別ホストへの誘導
tcp port 25 の接続拒否 (tcpserver など) tcp 接続を拒否する方法
spamを判別するための情報
IP アドレス： DNS/逆引き情報などのDNS 情報を含む。 インターネットに直接接続されている必要があります。
SMTP/リクエストのパラメタ(helo, mail from, rcpt to など) helo パラメタによる判別は逆引きと同等の効力があります。
2. 制限や拒否の種類
- port 25 への接続拒否 (再接続があるか監視する)
SMTP/恒久的エラー (着信拒否/rblsmtpd, 受信拒否/ smtp daemon など)
SMTP/一時エラー (rblsmtpd, smtp daemon など、再接続があるか監視する)
SMTP/throttling (ゆっくり、あとまわし、別ホストへのリダイレクトなど) SpamCannibal
- 受信後、破棄(ゴミ箱行き)
spamはSMTP/バウンスしてはいけません。
Tagged Message Delivery Agent (TMDA) -- Slowlists
3. 制限や拒否のために別途用意する情報
spam/ホワイトリスト:負担をかけずにメイルを受け取りたい相手の一覧
spam/ブラックリスト:しつこく spamを送ってくる相手の一覧
ISP 送信サーバリスト:複数サーバを使いまわししている相手の一覧
4. メイルを受信してもらうための設定など
メイルを受け取ってもらうたもには送信ホストの逆引きなど DNS をきちんと 設定しておく必要があります。
メイルサーバのためのDNS レコード設定
SPF Sender Policy Framework
5. IP アドレスによる選択
以下の三つの情報で判定して、対応を変えるものです。
(1) ホワイトリストにない相手(IPアドレス)からの接続はいったん断わる お馴染さん方式
(2) 逆引き情報による判定(非通知拒否方式)
ある時期に spamを送信してきたホストの約 70%が逆引き検索できませんでした。 正当なメイルを送信してくるホストについてはひとつだけが不合格でした。 一方で、動的割りあてIPアドレス と推測される名前(PTR レコード)のホストからの接続が増えています。 接続拒否した IP アドレスの 50 % 程度が動的割りあての IP アドレスでした。
DNS 逆引きは時間がかかるという指摘があります。
- 正しく設定されていれば、特に遅くなるということはありません。 問題は設定不良の場合です。代わりに helo 情報を使うのがお勧めです。
(3) ブロックリストを使う方法
http://www.scconsult.com/bill/dnsblhelp.html Blacklists, Blocklists, DNSBL's,and survival
(4) 共用のホワイトリスト
DNS 検索には「毒入れ」や「偽返答」のほか、DDoS への協力という危険があります。
6. IP アドレスと発信者情報の併用
送信元 IP アドレスと mail from を併用する方法 -- SPF Sender Policy Framework
7. SMTP greeting を細工する方法
接続開始時に送るメッセージを複数行に分けて送ると、 混乱して接続を打ちきるホストがあります。
8. SMTP helo/ehlo コマンドパラメタの検査
メイル送信クライアントは FQDN を名乗ることになっています。
spam/helo,ehlo コマンドのパラメタで受信拒否すること(RFC2821 4.1.4 節)
こちらの IP アドレスやドメイン名を名乗るものは spam です。 エラー返答しましょう。切断するのも効果的です。
FQDN でないものや動的割りあて IP アドレスらしきものには一時エラー返答して、 再送してくるか試します。
9. SMTP mail from のドメインを制限する方法
spamの送信者アドレスは実在するドメインを騙る偽アドレスがほとんどです。
- "hotmail.com", "aol.com" などもよく使われています。 これらからメイルが来ることがないのであれば、 これらを名乗るメイルは spamと見なせます。
qmail を使っているなら、 badmailfrom に受け取りたくないドメインを登録して拒否できます。
単独では詐称は見破りにくいので、IP アドレスなど情報を併用すべきです。
発信者ドメインの MX レコードをDNS 検索すること
10. MTA Mark ほか
M. Stumpf and S. Hoehne. "MTA Mark", http://www.space.net/~maex/Drafts/dns-mtamark/draft-stumpf-dns-mtamark-02.html
http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt
G. Feyck, "Designated Mailers Protocol (DMP)", Internet draft draft-fecyk-dmp-01.txt, December 2003.
H. Danisch, "The RMX DNS RR and method for lightweight SMTP sender authorization ", IETF draft draft-danisch-dns-rr-smtp-03.txt, October 2003.
R. S. Brand and L. Sherzer, "Designated Relays Inquiry Protocol (DRIP)," http://www.sherzer.net/draft-brand-drip-02.txt, October 2003,
J. Levine, "Flexible Sender Validation (FSV)", http://www.taugh.com/draft-levine-fsv-00.txt, February 2004.
J. Levine, Selective Sender, http://www.taugh.com/mp/ss.html, January 2004.
11. 送信者の身元証明
メイル送信元に身元証明を要求する方法も存在します。
12. 将来の spam対策
いつになるかは分りませんが、 spamが spammer のドメインから RFC を守って送られてくるようになれば、 dns black list を使うか、ホワイトリストを使うかすることになりそうです。
http://www.w3.org/2003/10/acquaintance-protocol/|Ending Spam with An MTA Acquaintance Protocol
http://slett.net/spam-filtering-for-mx/|Spam Filtering for Mail Exchangers
http://untroubled.org/mailfront/|mailfront Mail server network protocol front-ends