SPAM の現状と対策 (草稿)

JANOG Special Session In Interop 98 Tokyo

はじめに

ここ JANOG に集う濃～い方々にいまさら SPAM の概要を説明するまでもないと思っているですが、できれば概要もそしてメイルだけではなく Usenet におけることも話して欲しいということでしたのでこの辺りにもちょっと触れるようにしたいと考えております。ただ時間の制約上かなり端折らざるを得ず説明足らずな点も生じてくるでしょうが URL を示しておきますので詳細に関しましてはそちらを参照して下さいませ。なお JANOG 2 にて Usenet 関連の演題があるとのことだそうです。
なおこの原稿は会場到着前数時間くらいで書き上げたものでありほとんど読み返していないので、内容におかしな点や誤字などがあるかもしれません。http://www.ayamura.org/interop98/ に加筆、修正したものを不定期に置いておきます。

また SPAM 問題は各サイトのポリシーとも密接に関連してくるものであり、技術的な次元だけで解決できる問題ではありません。社会的、法律的な側面からの切り口も必要なのでしょうがここでは触れないで端折ることにします。
SPAM とは

SPAM という語自体を耳にする、目にすることも少なくないと思われるのですが、SPAM の語源は食品の名前で Hormel Foods Corporation 社が「スパム (spam)」を商標として登録しています。興味本位で缶詰を購入された方もいらっしゃるのではないかと。で SPAM とは平たく言うなれば一方的に送り付けられてくる、また Usenet で無差別にクロスポスト、マルチポストされているエロサイトの宣伝、物品販売などを目的としたジャンク記事といったものです。なお最近では電子メイルでの SPAM は Unsolicited Bulk Email (UBE), Unsolicited Commercial Email (UCE) などと表記することが少なくないようですが、ここではことわらない限り一般に広く知られていると思われる SPAM という語で統一させていただきます。

http://spam.ayamura.org/whatisspam.html
http://www.cauce.org/
http://www.imc.org/ube-def.html
http://caramia.g-net.org/spam/

一言 SPAM と言いましても電子メイルベース、Usenet ベースのものなどに大別できます。ここでは電子メイルベースに重点を置いて話させていただきます。
電子メイルでの SPAM とその問題点

電子メイルによる SPAM にはダイレクトメイル (DM) 業者と同様に多くのメイルアドレスを集める必要があります。一般的には Usenet にポストされた記事やウェブペイジなどをソースにして自動的に回収するロボットプログラムを用いることが多いようです。また Mailing List (ML) の購読者リストといったものも恰好の収集対象となるので ML を管理されている場合には安易に購読者リストを得ることができないように設定した方が良いでしょう。
こうしたネットワークにおける DM は郵政省メイルによるものとは異なり、モデムと PC くらいがあれば誰でもほとんどただ当然のコストで行えるので、大きな問題となりつつある現在でも減ることなくむしろ確実に増えてきているといっても過言ではないかもしれません。

以下に SPAM の問題点をいくつかかいつまでん挙げてみます。

(a) 送り付けるメイルの数は数万、数十万通にも及ぶので回線、サーバーのリソースを食い潰します。さらには大規模な ISP では顧客数が多いので受信にあたってもかなりの負担を負わされます (AOL では一日数千万通にもおよぶメイルの 30% 近くが SPAM ではないかという話もあります)。
これは Third-Party Mail Relay (踏台) にも関連してくる点なので後でもう少し深く掘り下げていきます。

(b) 発信元が ISP の顧客からだったりするとその ISP へ苦情が殺到することがあり、それに対応するためには多くの人的資源が必要になります。発信元がヘッダなどを偽造して ISP のユーザーや第三者なりを騙った場合には事態はさらに複雑になり、実際こうした非常に悪質な騙り行為が生じたりしています。
ヘッダ内の From: を騙られた場合もさることながら envelope 内の MAIL FROM: (Return Path: や UNIX From として最終的にはユーザーが目にするもの) が自ドメインのものを騙られたりすると大量のエラーメイルに見舞われることになります。
この辺りに関しましても後で少し触れます。

(c) 性別、年齢、職種、趣味などで分類されていることはまずなく無差別に送り付けられるので受信者にとっては興味がない内容のものがほとんどあり、受信するにあたって金銭的、時間的資源を消費することになります。特に最近では電子メイルでのやり取りがビジネスの中に組み込まれ欠かせない存在になってきているので、大事なメイルとこうしたジャンクメイルとが混在してしまうことは仕事の効率などを下げる要因になります。またエロサイトの広告やエロ画像などが添付されたメイルなどを受信することは精神衛生上良くないという側面も見逃せません。
対策にあたっての個人レベル、ISP レベルでのフィルタリングの手法を後でいくつか紹介します。

(d) また MMF (Make Money Fast), Get Rich Quick などと称されるネズミ講、マルチ講の類いが撒き散らされることもあり、これはチェーンメイルに繋がる可能性もあります。これらは Ponzi Scheme とも称することもあり、これは国内法ではどのように扱われるか詳細は知りませんが、現時点では真っ黒と断じることはできない事例が多いかもしれません。法律的な側面に関してはこの場で結論が出せる性質のものではないので割愛させていただきます。

(e) また SPAM とは言わないのかもしれませんが電子メイルを悪用したものとして特定個人へのメイル爆弾 (mail bomb) などもあります。これはウェブでの掲示板などで特定個人への攻撃を扇るような内容が書かれたりすることに起因することが多いようです。

http://spam.ayamura.org/spambad.html
http://www.cauce.org/problem.html
Third-Party Mail Relay (踏台) とその問題点

先ほど回線、サーバーのリソースを食い潰す云々ということを言いましたが、数万、数十万にも及ぶメイルをばらまく手法としては他人の褌で相撲をとる的に他所のメイルホストを介してそこから explode (爆発) させるものが代表的です。
```
 (SENDER) -------+         +------> (RECIPIENT)
                 |         |
            +----+---------+----+ 
            |    |         |    |
            |    V         |    |
            |  +-------------+  |
            |  | MAIL SERVER |  |
            |  +-------------+  |
            |                   |
            |   (LOCAL USER)    |
            +-------------------+
```
上の図を例にして説明すると SENDER という外部の発信元が (SENDER にとっては) 第三者が有する MAIL SERVER というメイルホストを介して RECIPIENT という不特定多数に対してメイルを送り付けるといった行為です。SENDER にとってこうした手法がなぜ有効であるかというと、一通のメイルの宛先 (envelope 内の RCPT TO:) に無数 (実際にはある一定の範囲内) のメイルアドレスを列記することができるので SENDER -> MAIL SERVER 間では一通送るだけで後は MAIL SERVER がそこから数十、数百といったメイルをばらまいてくれるからです。つまり数万もの宛先へジャンクメイルを送るにあたって SENDER が実際に送る (SENDER -> MAIL SERVER) メイルの数は数百程度で済んでしまうのです。QMQP protocol でリレーできれば一通で済むのではなどというちゃちゃはここでは却下いたします :)

以下に踏台の問題点をいくつかかいつまでん挙げてみます。

(a) メイルホストなどの計算機資源を食い潰します。実際一度に数千ものメイルを展開して配送させてみたことがあるのですが load average が怒涛のように上昇します。それに伴い sendmail などはコネクションを受け付けなくなるのでその間は普通のメイルすら受信することができなくなり、これは DoS attack の一つとも言えます。さらに大量のエラーメイルとして舞い戻ってこともしばしばです。

(b) 多くの受信者から抗議、苦情のメイルが押し寄せることがあります。それに伴い対応するためのサポート要員など人的資源をも投入せざるを得なくなるかもしれません。これは料金の上昇などを招き最終的にはユーザーが損害を被ることになりかねません。

(c) インターネットコミュニティー、社会的にも自組織の信用などを失う可能性があります。これは直接は目に見えず数値化すること難しいですが非常に大きな負となるでしょう。

(d) ウェブペイジ上などにあるブラックリストに挙げれたり、その組織からのメイルを拒否するようなサイトが多く生じてくるかもしれません。誰が一番損害を被るかと言えばユーザーであり、善良なユーザーが出したメイルすら受信拒否するサイトが現れてきます。実際 BEKKOAME や地方の無知な新参 ISP などが MPS RBL のブラックリストにリストアップされていたりしました。現在でも例えば geocities.co.jp などがリレーし放題な困った設定になっているようです。

CERT* Summary CS-97.06 の 4. Relaying of Spam Email through Victim Sites でもこうした踏台対策をとることを勧告しています。

ftp://ftp.cert.org/pub/cert_summaries/CS-97.06
http://maps.vix.com/tsi/
http://www.imc.org/ube-relay.html
Third-Party Mail Relay (踏台) 対策の手法

SPAM および踏台対策は相互に関連しますが、まずは踏台対策にあたっての大枠を上記の図を用いて示しますと
・LOCAL USER つまり自ネットワーク内のクライアントからのメイルはどこへでもリレーしてあげる
・SENDER つまり外部のクライアントからのメイルは LOCAL USERS 宛しか受け取らない、外部 RECIPIENT へは配送しないで拒否する
となります。

最も多く使用されている MTA である sendmail では 8.8.x (8.8.x の最終版は 8.8.8) で導入された check_relay ルーチンを利用することになります。いまだに 8.6.x や 8.7.x を使用しているサイトはパフォーマンス、セキュリティなどの観点からも 8.8.8 もしくは 8.9.0 へバージョンアップして欲しいものです。

現時点では V8/Berkeley フォーマットには対応していませんが国内では CF-3.6W が広く使用されています。CF-3.6W で作成した sendmail-8.8.x 用の sendmail.cf を 8.9.0 でもとりあえず流用することはできます (Warning が出るかもしれませんがとりあえず気にしないで平気です)。

CF_TYPE=R8V7
MAIL_RELAY_RESTRICTION=yes
REJECT_SOURCE_ROUTE_RELAY=yes

LOCAL_HOST_IPADDR=/etc/mail/sendmail.localip
192.168.1
192.168.2.123
自ホストをリレーホストとして利用しても良いホストの IP アドレス/ネットワークを列記する。一般的には自サイト内の IP アドレスを列記しておくことになります。なお 192.168.1 とした場合は 192.168.1.0/24 全てを意味します。

LOCAL_HOST_DOMAIN=/etc/mail/sendmail.localdomain
innerdomain.name
これは LOCAL_HOST_IPADDR と同様なものであり自ホストをリレーホストとして利用しても良い DNS におけるホスト、ドメインネームを列記します。もちろん逆引きできないホストは含まれません。なお innerdomain.name とした場合は *.innerdomain.name をも含むことに注意して下さい。

LOCAL_HOST_IPADDR, LOCAL_HOST_DOMAIN ともに併用することができますし、どちらか一方だけ、または両方とも未設定でも構いませんが LOCAL_HOST_IPADDR を設定しておいた方が何かと便利でしょう。

RELAY_MAP=hash または ndbm
Berkeley DB package (DB-1.8[56]) なりを使用するようにします。hash または ndbm にして map lookup させておけば変更しても sendmail を再起動することがないので RELAY_MAP=null よりは便利です。

RELAY_MAP=/etc/mail/sendmail.relay.map
以下の somedomain.name などは DNS 上のものではなく、あくまでもヘッダではなく envelope 内の {sender,recipient} address でのドメインパートであることに注意して下さい。
# user@somedomain.name, user@*.somedomain.name からは宛先に
# 関係なくどこへでもリレーしてあげる (注意 1)
# ただし LOCAL_HOST_IPADDR, LOCAL_HOST_DOMAIN を設定してある
# 場合にはこの設定は有効にはならない
#
# somedomain.name!. allow
# .somedomain.name!. allow

# ただし user@deny.somedomain.name からのメールはリレーさせない
#
deny.somedomain.name!. deny

# user@somedomain.name, user@*.somedomain.name からでも
# user@remailer.name へはリレーさせない

somedomain.name!.remailer.name deny
.somedomain.name!.remailer.name deny

# somedomain.name, *.somedomain.name 宛を受け取るもしくは
# リレーしてあげる、例えば secondary 以下の MX を担っている
# 場合など (注意 2)
# ただし CHECK_HOST_DENY に含まれているホストからは宛先に
# 関係なく受け付けない
#
.!somedomain.name allow
.!.somedomain.name allow

(注意 1)
RELAY_MAP での somedomain.name などは DNS 上のものでもヘッダ内のものでもなく envelope 内の {sender,recipient} address ですので、騙られた場合には不本意に踏台にされてしまう可能性があります。ゆえにポリシーにも依りますが LOCAL_HOST_IPADDR などでリレーを許可する IP address などを予め明示的に指定しておいた方が無難でしょう。上記の設定を例にすると
# somedomain.name!. allow
# .somedomain.name!. allow
が有効になっていると外部からでも MAIL FROM: を騙ることによって誰もが踏台として利用できることになり、これはバックドア的な設定とも言え sendmail-8.9.0 での FEATURE(relay_local_from) と同様な穴空け行為となるのであまりお薦めできません。fj.mail, fj.net.providers でも話題になっていましたがいくつかの ISP ではこのような設定になっているようです。

(注意 2)
当該ホストが別ホストの secondary 以下の MX を担っている場合には、その別ホスト宛のものをもリレーしてあげるように設定しておかないと、別ホストが落ちている間などに一時的に配送されてきた別ホスト宛へのメールを全て reject してしまいます。実際踏台対策をとってても bt モードなりでちゃんと動作チェックを行わないまま運用してしまう例も少なくないようです。こうなると Postmaster 宛へのメイルすら受け取ることができなくなるので、長期間改善されない場合には電話などの手段で連絡せざるを得なくなります。なお sendmail-8.9.0 では FEATURE(relay_based_on_MX) を用いてこれを回避できるようになっていますが正しく設定しておけばあらためて設定する必要はないでしょう。

次に最近リリースされた sendmail-8.9.0 でありますがこれは SPAM, RELAY 対策への強い要請を受けてか従来とは異なりデフォルトでは踏台にされないように変更されており、SPAM 対策に関しても今まで 8.8.x 用に各所で公開されてきた各種ルールセットを盛り込んだものになっています。これに伴い sendmail.cf のフォーマットも V8/Berkeley に変更されていますが、ルールセットもさらに複雑怪奇なスパゲッティ構造となっています…。設定するにあたって cf/README が参考になります。

define(`confCR_FILE', `/etc/mail/relay-domains')
192.168.1
192.168.2.123
innerdomain.name
自ホストをリレーホストとして利用することができる DNS 上でのドメインネームもしくは IP アドレスを列記します。逆引きできないホストの場合は IP アドレスで指定します。192.168.1 とした場合は 192.168.1/24 を意味します。FEATURE(relay_hosts_only) を設定していない場合は *.innerdomain.name をも含み、ここでの設定内容が class 'R' ($=R) となります。

FEATURE(access_db, hash -o /etc/mail/access)
192.168.1 RELAY
192.168.2.123 RELAY
somedomain.name RELAY
右辺 (RHS) には "OK", "RELAY", "REJECT", "DISCARD", "### any text" (### は RFC 821 compliant error code) を設定でき、"RELAY" とした場合は左辺 (LHS) にある DNS 上でのドメインネームもしくは IP アドレスのホストは自ホストをリレーホストとして利用することができるとともに、自ホストを介したそのホスト宛へのメイルを許可します。FEATURE(relay_hosts_only) を設定していない場合は *.somedomain.name をもみます。なお makemap を用いると変更がすぐに有効になり sendmail そのものに SIGHUP を送るなどして再起動する必要がありません。

さらにいくつかのオプショナルな設定があります。

FEATURE(promiscuous_relay)
どこからどこへでもメイルをリレーするようにします。これは踏台行為を許容してしまう結果になるので使用しないようにするべきです。

FEATURE(relay_local_from)
envelope sender address でのドメインパートが class 'w' ($=w) (通常は /etc/mail/sendmail.cw) などのローカルと認識するものと完全一致した場合どこへでもメイルをリレーします。envelope sender address は容易に詐称できるものなのでこの設定は大きな抜け道を作ってしまうことになりお薦めできません。 POP での認証を利用したリレー許可などといった方法を採るなどした方が良いでしょう。

FEATURE(relay_based_on_MX)
DNS を索いて RCPT TO: にある宛先の MX レコードに自ホストが含まれているかを調べ、含まれている場合に限りその宛先へリレーするようにする。ただし関係のないドメインが DNS の MX レコードに自ホストを勝手に登録していたりする可能性があるかもしれないのであまりお薦めできません。

FEATURE(relay_entire_domain)
access db の RHS が "RELAY" になっているものだけではなく、class 'm' ($=m) で定義されているドメイン (通常は自ドメイン名) に属するホストは自ホストをリレーホストとして利用することができるとともに、自ホストを介したそのドメイン宛へのメイルを許可します。例えば Dm mydomain.name と定義されている場合 mydomain.name および *.mydomain.name からのメイルをリレーするとともに、mydomain.name および *.mydomain.name 宛のメイルをもリレーしてあげます。

FEATURE(relay_hosts_only)
通常 access db の RHS が "RELAY" になっているものおよび class 'R' ($=R) で定義されているドメインは、それだけではなくそれよりも下位のドメインも有効になっています。この FEATURE(relay_hosts_only) を設定した場合は下位のドメインは有効にはなりません。上記の例で言うと *.innerdomain.name が含まれないようになります。

FEATURE(loose_relay_check)
source routing 表記のメイルアドレスに対するチェックを甘くする。詳細は http://www.informatik.uni-kiel.de/%7Eca/email/norelay.html などを参照して下さい。

最近はより安全かつ高速だと言われている qmail を使用するサイトも増えてきているようですが踏台対策をたてるのは非常に簡単です。

RCPT TO: に現れてよい宛先 (ある宛先の下位の MX を担っている場合はその宛先もお忘れなく) を control/rcpthosts に列記しておけば、その他の宛先へのメイルをリレーしないようになります。control/rcpthosts が存在しない場合にはどこへでもリレーしてしまうので設定するようにします。ただし環境変数 RELAYCLIENT がセットされているときには qmail-smtpd は control/rcpthosts が存在しないものとしてすべてのメイルを受け取り RELAYCLIENTの値を各受信アドレスの後に付け加えます。

ある特定のクライアントからのメイルに限り control/rcpthosts での設定に関係なくどこへでもリレーしてあげるように設定するにはいくつかの方法がありますが、もっとも便利なものとしては ucspi-tcp を併用する方法です。実際 qmail を使用しているホストではこの ucspi-tcp を併用していることがほとんどでしょう。/etc/tcp.smtp などに
127.0.0.1:allow,RELAYCLIENT=""
friend@192.168.2.123-126:allow,RELAYCLIENT=""
192.168.1.:allow,RELAYCLIENT=""
などと設定したローカルホストの他に 192.168.2.12[3-6] 上の friend というユーザー (ただし IDENT/TAP によってリモートホストから環境変数 TCPREMOTEINFO を取得できた場合のみ有効) と 192.168.2.12[3-6] からのメイルを control/rcpthosts での設定に関係なくどこへでもリレーしてあげるようになります。sendmail での makemap と同様に設定を変更した場合 tcprules コマンドを用いればプロセスそのものを再起動することなく直前までの変更が有効になります。

qmail での日本語による情報は東京工業大学の前野年紀先生が管理されている
http://www.jp.qmail.org/
にまとめられており qmail に興味がない方でも非常に参考になるリソースです。

その他 exim や Windows 環境での設定などに関しましては以下の URL などを参照して下さいませ。なお他の方からの伝聞ですが Windows NT + IMS というサイトが結構あるようなのですが IMS は開発が終了しているらしく、しかもそのままでは踏台にされてしまうらしいのですが http://www1.sica.com/ims/ から踏台防止のためのプラグインなどを入手できるようです。私は Windows を使用していないので詳細は未確認です。
SPAM 対策の手法

これは各サイトのポリシーなどにも関わってくるところでありますが、手法だけを簡単に紹介してみます。

WIDE CF-3.6W では上記の踏台対策に加えて

SPAM_LIST=/etc/mail/sendmail.junklist
SPAM_LIST_TYPE=hash/ndbm/null (デフォルトは null)
CHECK_HOST_DENY=/etc/mail/sendmail.deny
USE_SENDER_DNS_CHECK=yes/no (デフォルトは no)

などといった設定を用います。

SPAM_LIST には
spammer@junk.domain SPAMMER
10.111.222.222 JUNKIP
192.168.111 JUNKNETWORK
# 以下の場合 *.junk.domain も含む
junk.domain JUNKDOMAIN
というように envelope sender address, envelope sender address のドメインパート、SMTP 接続してくるドメイン、ホスト、IP address を左辺に列記できます。重複しないかぎりいくつでも設定でき、DB フォーマットの形式上右辺には自分で決めた適当な単語を書いておきます。SPAM_LIST_TYPE=hash/ndbm であれば変更しても sendmail を再起動させたりする必要がないのでデータベース管理も楽です。
また USE_SENDER_DNS_CHECK=yes とした場合は envelope sender address のドメインパートが DNS 的に resolve できないものを 4xx な SMTP reply codes を返すようになっていて受け取りを延長するようになっています。ただこの場合何度も接続を繰り返してくることがあるので 5xx を返すように変更するなりもしくは使用しないようにした方が良いかもしれません。

sendmail-8.9.0 では access_db というものが SPAM、踏台対策の心臓部であり
EATURE(access_db, hash -o /etc/mail/access)
FEATURE(blacklist_recipients)
などと設定しておくと access_db には
```
spammer@aol.com		REJECT
206.117.147		REJECT
cyberspammer.com	550 We don't accept mail from spammers
okay.cyberspammer.com	OK
sendmail.org		OK
128.32			RELAY
badlocaluser		550 Mailbox disabled for this username
host.mydomain.com	550 That host does not accept mail
user@otherhost.mydomain.com	550 Mailbox disabled for this recipient
```
というように SPAM, 踏台対策を統合して管理することができます。さらに RCPT TO: をも評価して適当な SMTP reply codes を伴ったメッセージを返して受信を拒否することができます。右辺は以下の書式が使用できます。
```
OK		accept mail even if other rules in the
		running ruleset would reject it.
RELAY		Allow domain to relay through your SMTP
		server.  RELAY also serves an implicit
		OK for the other checks.
REJECT		reject the sender/recipient with a general
		purpose message.
DISCARD		discard the message completely using
		the $#discard mailer
### any text	where ### is an RFC 821 compliant error code
		and "any text" is a message to return for
		the command.
```
qmail では qmail-smtpd から参照されている control/badmailfrom には
spammer@aol.com
cyberspammer.com
などと envelope sender address , envelope senders のドメインパートを列記しておくことができます。さらに qmail-1.02 からは control/databytes で受信するメイルサイズの上限を設定できるようになっています。上でも挙げた ucspi-tcp を用いれば /etc/tcp.smtp で
206.117.147.:deny
などと設定しておけば上記の class C block からの SMTP 接続そのものを拒否することができます。
おまけ (MAPS RBL)

あと御存知の方も多いかと思われますが MAPS (the Mail Abuse Protection System) RBL (Realtime Blackhole List) を DNS 経由で使用するという方法もあります。これは SMTP 接続してくるホストがこのブラックリストに載っているか否かを DNS 経由で問い合わせ、載っている場合には受信を拒否するようになります。他人任せな側面もありますが自前でデータベース管理をする手間を減らすことができるので便利かもしれません。sendmail, qmail, exim, smail, smtpd, smap などからも簡単に利用でき
WIDE CF (ただし CF-3.6W ではおかしな点があるようなので使用しない方が良いかも) では USE_MAPS_RBL=yes
cf では FEATURE(rbl)
と設定し ucspi-tcp では ucspi-tcp-0.80-rbl.diffs というパッチをあてておくだけです。
なお tcp_wrappers-7.6 を MAPS RBL 対応にするパッチもあります。
対策にあたっての問題点、ポリシー問題など

技術的にはこのようにそれなりの対策をとることができますが色々な問題点をもはらんでいます。

特に SPAM 対策に関してはある特定のドメイン、メイルアドレスなどからのメイルを一律に拒否してしまうと、一部のユーザー、顧客からメイルを受け取ることができないの困るなどと苦情を言われることがあるでしょう。procmail や rblcheck などといったツールを用いてユーザーが各自のポリシーでフィルタできるようなシステム構築をするというのも一つの手かもしれません (設定次第ではメイルのループ、ロストに繋がるという危険性も孕んでいますが)。check_local での _SPAM_FRIENDS_, _SPAM_HATERS_ を用いるというのもお薦めです。いづれにせよ各サイトのポリシー次第ですし顧客との契約条件などにも依るのでこれといった基準はありません。

また自ネットワーク内からのメイルに関しては制限をかけていない場合がほとんどでしょうが、内部のユーザーから SPAM がばらまかれた場合、多くの苦情などが押し寄せてくることも当然あります。苦情に対してどのように対処していくのか、また該当ユーザーを突き止めることができた場合どのような対応をとるのかなどといったガイドラインを決めておく必要があります。
ところでこうした net-abuse な行為に関する苦情を受け付けるメイルアドレスを用意しておくべきではないかということで
RFC2142 Mailbox Names for Common Services, Roles and Functions. D.Crocker.
May 1997. (Format: TXT=12195 bytes) (Status: PROPOSED STANDARD)
では
```
MAILBOX        AREA                USAGE
-----------    ----------------    ---------------------------
ABUSE          Customer Relations  Inappropriate public behaviour
```
というように苦情の対応窓口として abuse@ というメイルアドレスを用意することが提唱されており、実際海外では用意している ISP が多いようです。国内では極一部の ISP でしか存在しないようであり大多数では用意されていないようです。
全ての苦情に対応することはできないでしょうが筋が通った苦情に対してはちゃんと対応するようにする必要があるかと思いますし、対応次第でその ISP の評価をすることができるのではないかとも思います。実際踏台にされているという忠告、他人のメイルアドレスを騙った記事をばらまく輩がいるので何とかしてくれ的な苦情などを出してもなしのつぶてで全く音沙汰なしという例には事欠きません。できれば窓口を用意して対応できるような体制を整えておいて欲しいものです。

あと踏台対策を施した場合、別の ISP にダイアルアップ PPP 接続していたりするときに POP 経由でメールを受信することはできても、送信しようとした場合にそのドメイン宛ではないメールが拒否されてしまうことになります。そのためメールを送信する場合には Eudora などユーザー側が使用している MUA での SMTP サーバの設定などを現在接続している ISP のものに変更しなければいけないことが多いわけです。本来ユーザー側で接続先を変更した場合にはその都度 MUA での設定を変更するべきなのですが、ユーザー側に便宜を図るという方向でこの問題を解決する手段の一つとしては POP での認証を用いて動的にリレー許可を行うというものがあります。どのようなものかと言いますと外部からのアクセスであっても POP で認証が済んだクライアントからのメイルはどこへでもリレーしてあげるというものです。POP で認証済みのユーザーがアクセスしてきている IP address を内部アドレスとして定義されているデータベースに加えてやるのです。追加したままだと危険なのである一定時間後はその�(! ! ! ! B�(! ! ! B 賓痲糅纉s をデータベースから削除するようにします。実際にこうした手法を採用している ISP もあるとかないとか。問題点もいくつかありますが以下の URL などが参考になります。

http://spam.ayamura.org/tools/smPbS.html
http://www.iecc.com/pop-before-smtp.html
http://www.tech-net.net/technical/unix/popauth.html
http://www.informatik.uni-kiel.de/%7Eca/email/chk-rcpt5.html
ftp://ftp.navya.com/pub/sendmail-spam-v2.tar.gz
http://www.qmail.org/open-smtp.tar.gz
まとめ

・全域に渡って踏台対策を施しておく。
・SPAM はゴミ同然のものであり計算機、ネットワーク資源を浪費する。
・SPAM を受け取ることは受信者側にとって金銭的、時間的、精神衛生的なマイナスとなる
・Mailing List の購読者リストなどを安易に取得させないようにする。また WEB でのロボット対策などをも考えておく。
・SPAM 対策にあたってどのようなフィルタをかけるのか、内部からの SPAM に対してどのように対処するのかなどガイドラインを予め決めておく。
・混乱を招かないようにユーザーへの事前アナウンスなどを徹底しておく。
・net-abuse な行為に対する苦情の受け皿 (例えば abuse@) を用意しておく。

しかしながら
・ユーザーサイドでの教育も含めて Email というものが国内ではまだ実用になっていない
・SPAM 云々以前の問題としてちゃんと管理できる人材が少なすぎる
という意見も少なくないようです。私自身がちゃんとしているわけではないので大きなことを言えないのですが、プログラミング的能力と管理能力というものは異なる次元であり、プログラミングができても実運用に関してはいまいちという例は少なくありません。できる管理者が絶対的に不足しており、身近な環境でも一番危惧している問題はある程度の管理スキルを有した人材がほとんど皆無に近いことです。

話が逸れてしまいましたが SPAM 行為による宣伝広告効果はほとんどなく、むしろ送り手に対して負の評価を与えるだけであるということが社会的にも広く認識されていく必要があり、マスコミなどをも含めて社会的な啓蒙が必要であります。

Ayamura Kikuchi <ayamura@ayamura.org>