## page was renamed from メール/spam対策/誤解
## page was renamed from spam対策/誤解
## page was renamed from spam対策に対する誤解
## page was renamed from spam 対策に対する誤解
#pragma section-numbers on
<<TableOfContents()>>

== spam対策に対する誤解 ==
一通の詐欺目的のメイルまで spamに含めるのは間違いです。 <<BR>> 多数の宛先に送られるものだけを spamということにしましょう。

spam対策が検閲であるというような ISP はさっさと契約を解除しましょう。

メイルというものを誤解していないでしょうか。 http://www.qmail.jp/email/ email 入門もご覧ください。
 [[emailに対する誤解]]

=== spam対策はいたちごっこである ===
有効な spam対策が提案されても採用されないことはよくあります。

 . このため、spam送信側もすぐに対応することは稀です。 対策の効果は続く方が多いと思います。

spam 送信方法も時間(3 年くらい)とともに変化することは想定すべきであり、

 . 「永久に」特定の spam対策が有効であることを期待するなら、
  . SMTP を使わないか、根本的な変更が必要でしょう。

=== メイルが瞬時に受信されないのはけしからん ===
メイルとチャットとを混同していませんか。

「Greylisting の欠点はメイルが遅延することである」というのは間違いです。

 . インターネットメイルは到達性すら保証されたものではありません。 遅延が許されないような通信をしたいのであれば、電話などの双方向の 通信方式を使うべきでしょう。

=== 再送しないメイルサーバからのメイルが受信できない ===
これは事実ですが、間違っているのは再送しないメイルサーバの方です。
再送しないサーバというのは spamと同じ送り方をするサーバです。
再送しないサーバからのメイルは一度は受信できなくともしかたないでしょう。

インターネットというものは障害が存在することを前提に構築されているものだからです。
　少しの障害も許さないというのであれば、インターネットではない方法を探すしかありません。

=== false positive は避けられない ===
 * 統計的に判定するのであれば、false positive は避けられません。

でも、統計的判定だけではありません。 RFC を守らない送信方法は false positive とは言いません。

=== すべてのメイルは受け取って、利用者に判別させるべきである ===
false positive を恐れるあまりの発言だと思われます。 メイル受信のコストを考慮しましょう。
[[なぜspam対策するのか]]

 * RFC を無視した送信方法で送られてくるメイルまで受けとらなければならないということはありません。
 要は受信ポリシーの問題なのです。

spam対策ポリシーに沿った対策技術を使っていますか。

=== 通した spamが少ないのが優秀な対策である ===
 * spamを通過させたくなければ、すべてのメイルを拒否すればよろしい。

正当なメイルが拒否されることが十分少いことを示す必要があります。

 . 正当なメイルは RFC に従った送信方法をもちいるサーバから送られるものです。

=== helo パラメタで拒否してはいけない ===
helo パラメタがまともでないようなメイルサーバからのメイルを受け取りたいかどうかによります。

これまでの経験では、間違った helo パラメタを送ってくるサーバは spamを送ってきます。

== SMTP 返答についての誤解 ==
MTA で spam対策する人は SMTP (RFC 2821) を勉強しましょう。

 * 4xx 返答は受信拒否である
  . 4xx 返答は一時的に受信できないことを通知するのに使われます。

 * SMTP 5xx 返答は spam拒否返答である
  . 5xx は受信しないこと通知しているだけです。
  spamだと決めつけている訳ではありません。
  4xx で再送信を要求すると相手に配信不能を通知することも遅延させます。
  受け取らないメイルなら、さっさと 5xx 返答をしましょう。

 * DNS blacklist は信用できないから、5xx ではなく、4xx 返答をすべきだ。
  . 信用できない blacklist を使うこと自身を考え直すべきです。
 どうせ受け取らないメイルなら、さっさと 5xx 返答をしましょう。
 4xx で再送信を要求すると相手に配信不能を通知することも遅延させます。

== 逆引きの利用に関しての誤解 ==
 * DNS は枯れた技術なので、逆引きはいくら使っても問題ない。
  . [[DNS/逆引き]]はまともに設定されているとは言えません。
 そもそも DNS に頼るのは危険です。
 [[DNS/キャッシュサーバへの毒盛]]とか、DNS DDoS 攻撃とかいうことは御存知ない？
 それに逆引きだって、DNS 管理者なら勝手な情報を設定できます。
 SMTP と逆引きとの間には直接の関連はありません。

 * 逆引きで受信拒否しても問題ない。
  . 『いまどきの「メールサーバ」で逆引き設定されていないものは少い』は正しいのですが、
　DNS が常に正しく動作することを期待するのは間違いです。
 逆引きできないことなどを理由にするなら、一時保留返答に留めるべきです。

 * 逆引きはコンテンツフィルタリングより軽い。
  . これも間違いではありませんが、比較するべき相手(世界)が違います。
 逆引きは他人の資源を使います。十分重たい動作です。
 コンテンツフィルタリングを使う場合にも逆引きしているかもしれません。
 DNS 逆引きと同種の情報は helo パラメタから得られます。