## page was renamed from spam/MTAでspamを撃退する方法
## page was renamed from MTAでspamを撃退する方法
## page was renamed from MTA で spamを撃退する方法
#pragma section-numbers on
<<TableOfContents()>>
{{{
SMTP/MTA で spam を撃退する方法
}}}
安心して接続制限や受信制限を行なえる方法を提案しています。
一例 [[お馴染さん方式]]
 * spamの多くを受信しないですませるものです。
 * メイル本文を解析して判断する方法は扱いません。
 * spamを受信してからフィルターで捨てるのではありません。

spam対策はメイル送信の原理を理解してから：
[[http://www.zvon.org/tmRFC/RFC2821/Output/index.html RFC 2821 SMTP]]
<<BR>>
[[RFC 2505関連]] Anti-Spam Recommendations for SMTP MTAs

[[SMTP/制限することの長短]] --
[[MTAでspam対策されない理由]] --
[[ISPでやって欲しい対策]] 

[[spamはどこから送られてくるか]] -- [[spamを送信してくる様子]]

[[http://im.qmail.jp/smtp.html|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 を対象に書かれたドキュメントのようですが、とてもよく説明されています。
 
=== SMTP 接続させない方法 ===
 * ルータや ipfilter などでの排除/[[別ホストへの誘導]]
 * DNS での別ホストへの誘導
 * tcp port 25 の接続拒否 (tcpserver など) [[tcp 接続を拒否する方法]]

spamを判別するための情報
 * IP アドレス： [[DNS/逆引き情報]]などのDNS 情報を含む。
 インターネットに直接接続されている必要があります。
 * [[SMTP/リクエスト]]のパラメタ(helo, mail from, rcpt to など)
 helo パラメタによる判別は逆引きと同等の効力があります。

=== 制限や拒否の種類 ===
 * port 25 への接続拒否 (再接続があるか監視する)
 * [[SMTP/恒久的エラー]] (着信拒否/rblsmtpd, 受信拒否/ smtp daemon など)
 * [[SMTP/一時エラー]] (rblsmtpd, smtp daemon など、再接続があるか監視する)
 * [[SMTP/throttling]] (ゆっくり、あとまわし、別ホストへのリダイレクトなど)
 [[http://www.spamcannibal.org/cannibal.cgi|SpamCannibal]]
 * 受信後、破棄(ゴミ箱行き) 
 
 spamは[[SMTP/バウンス]]してはいけません。

[[http://tmda.net/|Tagged Message Delivery Agent (TMDA)]] --
[[http://www.slowlists.org/|Slowlists]]

=== 制限や拒否のために別途用意する情報 ===
 * [[spam/ホワイトリスト]]:負担をかけずにメイルを受け取りたい相手の一覧
 * [[spam/ブラックリスト]]:しつこく spamを送ってくる相手の一覧
 * [[ISP 送信サーバリスト]]:複数サーバを使いまわししている相手の一覧
 
=== メイルを受信してもらうための設定など ===
メイルを受け取ってもらうたもには送信ホストの逆引きなど DNS をきちんと
設定しておく必要があります。
<<BR>>
[[DNS/mailserver|メイルサーバのためのDNS レコード設定]]

[[SPF]] Sender Policy Framework

=== IP アドレスによる選択 ===
以下の三つの情報で判定して、対応を変えるものです。

(1) ホワイトリストにない相手(IPアドレス)からの接続はいったん断わる
[[お馴染さん方式]]

(2) 逆引き情報による判定([[非通知拒否方式]])
<<BR>>
ある時期に spamを送信してきたホストの約 70%が逆引き検索できませんでした。
正当なメイルを送信してくるホストについてはひとつだけが不合格でした。
一方で、[[動的割りあてIPアドレス]]
と推測される名前(PTR レコード)のホストからの接続が増えています。
接続拒否した IP アドレスの 50 % 程度が動的割りあての IP アドレスでした。

DNS 逆引きは時間がかかるという指摘があります。
  正しく設定されていれば、特に遅くなるということはありません。
  問題は設定不良の場合です。代わりに helo 情報を使うのがお勧めです。
  
(3) ブロックリストを使う方法
<<BR>>
http://www.scconsult.com/bill/dnsblhelp.html Blacklists, Blocklists, DNSBL's,and survival

(4) [[http://www.dnswl.org/|共用のホワイトリスト]]

{{{
DNS 検索には「毒入れ」や「偽返答」のほか、DDoS への協力という危険があります。
}}}
=== IP アドレスと発信者情報の併用 ===
送信元 IP アドレスと mail from を併用する方法 --
[[SPF]] Sender Policy Framework

=== SMTP greeting を細工する方法 ===
接続開始時に送るメッセージを複数行に分けて送ると、
混乱して接続を打ちきるホストがあります。

=== SMTP helo/ehlo コマンドパラメタの検査 ===
メイル送信クライアントは FQDN を名乗ることになっています。
 * [[spam/helo,ehlo コマンドのパラメタで受信拒否すること]](RFC2821 4.1.4 節)
{{{ 
こちらの IP アドレスやドメイン名を名乗るものは spam です。
エラー返答しましょう。切断するのも効果的です。
}}}

FQDN でないものや動的割りあて IP アドレスらしきものには一時エラー返答して、
再送してくるか試します。

=== SMTP mail from のドメインを制限する方法 ===
spamの送信者アドレスは実在するドメインを騙る[[偽アドレス]]がほとんどです。
  "hotmail.com", "aol.com" などもよく使われています。
  これらからメイルが来ることがないのであれば、
  これらを名乗るメイルは spamと見なせます。

qmail を使っているなら、
[[http://man.qmail.jp/jman8/qmail-smtpd.html#badmail|badmailfrom]]
に受け取りたくないドメインを登録して拒否できます。

単独では詐称は見破りにくいので、IP アドレスなど情報を併用すべきです。
 * [[発信者ドメインの MX レコード]]をDNS 検索すること

=== 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. 


=== 送信者の身元証明 ===
メイル送信元に[[身元証明を要求する]]方法も存在します。
 
===  将来の 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