## page was renamed from spam/と対策についての非常識
## page was renamed from spamと対策についての非常識
## page was renamed from spam と 対策についての非常識
#pragma section-numbers on
<<TableOfContents()>> 

== spamについての非常識 ==

 . spam と 対策についての民間伝承といつわりの宣伝

対比：[[spam/対策の常識]]

http://www.eff.org/wp/?f=SpamCollateralDamage.html

=== 2006 年には spam はなくなっているだろう ===
みんなが協調すれば、spam 退治は可能です。 問題は協調できるかです。

=== spam は永遠になくならない ===
あきらめがよすぎませんか。 これが正しければ、インターネットとともに滅ぶでしょう。

spam は大量のメイルを安価に配送することで成立しています。 spam メイル配送のコストを上げてやれば、滅びます。 技術的には解決可能なことは明かです。

問題は社会的な部分にあります。

=== 法による規制 ===
 . { 現状は有効とは言いがたい状態です。特に opt-out を勧める法律が、...}

=== spam は削除キーを押せばいい ===
[http://www.cloudmark.com/products/authority/roi/ Spam Cost Calculator]] あなたの大事な人に spam メイルが送られてきてもそう言いつづけられますか。 それとも代わりにあなたがメイルを受け取りますか。

=== spam はフィルターを通せばいい ===
spam フィルターを問題なく設定できる人ばかりではありません。 末端で設定/処理するための手間はどうするのですか。

=== spam 対策サイトの記事 ===
 * メイルアドレスの変更は敗北だ。{一番効果がある。 :-) }
 * opt-out (受信者による受信拒否手続き）は効果がある。{ 到達するアドレスだと確認できる。}
 * xx ISP はいい対応だった。{ 文句を言う客にだけかも }

[http://www.spamhaus.org/mailinglists.html opt-out (SPAMHAUS)]]

=== 広告業者 (spam?) ===
 * まっとうな宣伝であるから、受け取らなければならない。
 * opt-outで spam 問題は解決する。
 * spam は(最終)受信者の責任で捨てるべきである。spam を捨てるのに時間はかからない。
 * False Positives Can Cost Companies Billions
 * smtp 接続の拒否はまずい。まっとうなメイルが受信できなくなる。

=== spam 対策業者の宣伝 ===
 * チャレンジレスポンス方式で spam は拒絶できる。
 * チャレンジレスポンス方式は有効ではない。初めての人に失礼だ。
 * その他の filter 業者の宣伝多数 (filter で 99% 排除など)
 * 継続した契約をさせるための囲いこみ文句
  . ルールは日々の更新が必要、客は手間をかけたがらない。
 * spam に課金すれば解決する。{方法は ?}

=== ウィルス対策業者の宣伝 ===
 * 多くの客はウィルス対策ソフトで spam 対策することを願っている。

=== spam 送信ホストについて ===
 * spam を送ってくるのは open relay である。
 * spam を送ってくるのは open proxy である。

{第三者メイルの中継を禁止すれば対策済というような記述は時代遅れです。}

=== メイルサーバ管理者ができる spam 対策についてのうそ ===
spam 対策しないことの言い訳

 * 『MTA で spam 排除すると検閲になる。』 『通信の秘密保持違反』
 * IP ブロックで拒否するのはまずい。(不当な差別)
 * dnsbl は役にたたない。害がある。
 * 一時エラー方式は小規模サイトでしか使えない。大規模サーバには迷惑だ。
 * ホワイトリスト方式は小規模でしか使えない。
 * 協調型 フィルターにはプライバシー問題がある。

問題の残る spam 対策
 * SMTP mail from で存在しないドメインからのメイルの拒否が有効だ。
 * 逆引きチェックで受信拒否してよい。

=== virus (spam) メイルの警告を詐称アドレスに送ること ===
=== 宛先不明メイルをバウンスすること ===
 * 宛先不明なのだから、バウンスして当然だ。 {無関係の第三者に spam を送りつける結果になります。} [[バウンスメイル]]

=== ブラックリストは使えるのか ===
 * dns ブラックリストは信頼できない。(自分のサイトが載せられたから)
 * ブラックリストを使うと誤爆(false-positive)する。
 * ブラックリストはいくつ指定してもよい。 {ブラックリストがメイルを拒否する訳ではありません。
  . どう使うか、使う側の問題なのです。使いすぎるのも dnsbl 提供への負荷になります。}

=== ホワイトリストの維持はたいへんだ。 ===
 . { ホワイトリストなしでブラックリストを使うのはブラックリスト提供サイトに
  . 過大な負荷をおわせていることになります。}
 { ホワイトリストの管理が面倒な人はメイル管理者にむいていないのです。} {spam 対策ベンダーの宣伝文句にひきづられていませんか。}

=== メイリングリストでの spam 排除 ===
 * メイリングリストで spam 排除すると検閲になる。
 * 投稿者を制限すると投稿が減る。{spam はどうなんですか}

=== プロバイダでの spam 規制 ===
 * 検閲になるからやってはいけない。
 * 通信の秘密を侵すことになる。
 * 契約違反だ。
 * 制約があると客が逃げる。{spam はどうなんですか}

発信メイル数の規制がないプロバイダは spammer の天国です。 spam 支援業者だと分類すべきです。

制約のないプロバイダからは客が逃げるという状況にしましょう。

----
[http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html The Spam Problem: Moving Beyond RBLs]] [http://phil.ipal.org/rbl-bad-reply/rbl-bad-reply-1.html A reply to The Spam Problem: Moving Beyond RBLs]]

リンク： [http://spam.h1r.org/ サーバ管理者のスパム対策]]

[http://www.zvon.org/tmRFC/RFC2505/Output/index.html Anti-Spam Requirements on an SMTP MTA (RFC 2505)]]