2002-11-10
spams, headers, and @nifty
related stories:
- [2003-10-01] BIGLOBEとspamポリシー
- [2002-12-13] spams, headers, and @nifty - a little step forward
- spam021208
- spam021204
- [2002-11-10] spams, headers, and @nifty
- spam021104
- [2002-11-07] fuck spammers!
spammer's watchを始め、最近受け取ったspamをHTML化しながらwebで資料を集めいていたところ、電子メール広告社からのspamが迷惑メール(spam)撲滅私的調査会（恐ろしく見にくい、もしくは醜いトップページなのは残念、なんかspamが持ついやらしさをこのレイアウトに感じてしまうのは皮肉か）というanti spamサイトなどで叩かれているのを知った。anti spamの世界ではロリムトーという名で有名だったのだ。
しかしながら、そのロリムトーのspamよりも気になったのは、迷惑メール(spam)撲滅私的調査会 専用掲示版にあった「ヘッダのIPアドレスが隠れているspam」というスレッドにあるように、@niftyのメールサーバが故意に送信したときの接続先IPアドレスをヘッダから削除しているという話題だった。この問題についてはspam021108にも書いたが、RFC-2505 日本語訳 niftyのMTA（SMTPサーバ）がIPアドレスを記録しない問題 （人生ままならず）や@nifty受信サーバの問題性（迷惑メール(spam)撲滅私的調査会）に詳しい。
******
彼らが@niftyを批難する根拠はまず[RFC 2505] Anti-Spam Recommendations for SMTP MTAsの文書にある2.2. Received: lines以降の勧告である。
2.2.1. Direct MTA-to-MTA connections
Internet mail was designed such that the sending host connects directly to the recipient as described by MX records (there may be several MX hosts on a priority list). To assure traceability back to the sending host (which may be a firewall/gateway, as described later) each MTA along the path, including the final MTA, MUST prepend a "Received:" line. For such a "Received:" line we have:
It MUST contain:
- The IP address of the caller.
- The 'date-time' as described in RFC822, [2], pp 18.
It SHOULD contain:
- The FQDN corresponding to the callers IP address.
- The argument given in the "HELO" statement.
- Authentication information, if an authenticated connection was used for the transmission / submission
簡単に説明すれば、メールを配送するプログラムであるMTA（sendmailなど）がメールを転送する際、MTAを通過するときはヘッダにReceived:フィールドを付加すること、そしてMTAが転送先ドメインのDNSサーバにMXレコード（メールサーバのホスト名を定義するレコード）を問い合わせるときには必ずcaller、つまり呼び出した側のIPアドレスを必ず含めなければならないとあるのだ（そう、ここでは"MUST"となっている）。
それが@niftyのサーバの経由ではなくなることがある、これが問題の核心であり、最も問題となっている点である。それがわからなければ、spamの苦情先を特定できないのだ。
確かに最近ロリムトーから届いた5通のspamのうち、1通(spam021104)を除いて送信時の接続先IPアドレスがない。しかし、ロリムト−スパム 資料室やspam mail "child porn sales spammer"にある受信リストを見る限りは僕が受け取ったspamと同じものは見つけることはできなかったものの、どれもきちんとメールヘッダにIPアドレスが表示されていた。
当初は送信側で小細工したのかと思っていた。また、MUAでもIPアドレスの受け渡し方がそれぞれで変わってくるので、てっきりIPアドレスが表示されないのかと考えていたのだ。しかし、それは間違いだったようだ。かなりの勘違いだったようだ。やはり、メールサーバにspamが吸い込まれる瞬間 (Point of Injection)、接続先のIPアドレスが表示されないのはおかしい。
******
掲示板のhttp://antispam.blfan.org/exhibit/mutou.htm報告を読むと、@niftyは[RFC 822] Standard for ARPA Internet Text Messages (obsolete)のあとを受けてInternet MailのIETF STD（インターネット標準）となった[RFC 2822] Internet Message Formatでは必須項目となっていない、結局、callerのIPアドレスのヘッダへの表記は先のRFC 2505でBest Current Practiceになっているに過ぎないのだから、それに従う必要は現在のところないといった強弁を行っているように見える。
Best Current Practice (BCPs)は[RFC 1818] Best Current Practicesにあるように
The BCP process is similar to that for proposed standards ... once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the IETF, but it is not, and cannot become an official Internet Standard.
BCPはSTDとなる最初の段階であるproposed standards 標準への提唱 の過程段階と同じだが、最終的に文書化されれば、IETFより技術勧告を受けたものとされるとある。しかしながら、正式なインターネット標準、つまりSTDにはなりえない。となると、@niftyの言い訳もあながち外れているわけではないが、標準化過程をまとめた[RFC 2026] The Internet Standards Process -- Revision 3の5. BEST CURRENT PRACTICE (BCP) RFCsの項では
Historically Internet standards have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from protocol standards, their establishment needs a similar process for consensus building.
と、インターネット標準が歴史的に一般的な技術問題に向けられていたのに対し、複雑化するネットワークのポリシーやオペレーションに共通のガイドラインを提供する役割としてBCPが生まれた背景を説明している。このことからも、@niftyの言う「推奨レベル」に過ぎないRFC 2505を適用しないのは言葉通りでは確かに必須ではないわけだが、会員数500万を超える日本最大のISPとして、また、Nifty Serveというパソコン通信を生み出した会社として誇りを持って"common guideline"に従い、率先してspamに対して強い姿勢で臨むべきではないかと思うのだ。
******
先の RFC-2505 日本語訳 niftyのMTA（SMTPサーバ）がIPアドレスを記録しない問題 のwebページでは@niftyを辛辣に批判、@nifty/個人情報保護ポリシーにある
5。当社は、お客様に有益と思われる当社のサービス、又は提携先の商品、サービス等の情報を電子メールでお客様に送信させていただく場合がございます。お客様は、当社にお申し出いただければ、このような電子メールの送信を中止させることができます。
から、@niftyがDMの送信に対してopt-outを宣言しているのにもかかわらず、DM（ダイレクトメール）への対応では
このような迷惑メールが来た時は、すみやかにメールボックスから削除することをお勧めします。メールの中に、「今後受け取りたくない時は、メール不要の連絡をして欲しい」と書いてあることもありますが、迷惑メールに対して返信してはいけません。なぜなら、あなたのメールアドレスが確かに存在していることが、スパムメールの送信元に知られてしまうからです。
と書いており、これは先のopt-outとはまったく矛盾した説明ではないかと皮肉っている。しかし、これは作者の誤解だろう。先の個人情報保護ポリシーではニフティ株式会社とその提携先企業からのDMが送信されることを明確に会員に告げ、しかし、それを必要としない、快く思わない人はopt-outできますよと説明しているわけだ。
ISPだけに限った話をしても、So-netでもrimnetでもIIJ4Uでも自社のサービスのお知らせについて会員にメールを定期的に送信している。そして、どのISPでも、そのメールを拒否したい者は配信停止の手続きを取るようにとメールの最後に記載されている。opt-outである。» 電子商取引におけるOpt-out / Opt-in
この正当な−これを正当と取るかどうかはまたその人の見解によって違ってくるのだろうが−商取引とspamを同じ視線で見るのはどうかと思う。経済産業省の迷惑メール防止のための特定商取引法改正によりopt-outの表示が義務化されたspamに対して返事を送ることとはつまり、まったく知らない、こちらから会員になったわけでもない業者に対して返事を送ることとなる。そのことと、自らの意志で@niftyの会員となった者が@niftyという会社に対してopt-outの意思を表示することは行為こそ同じであれ、意味合いはまったく変わってくる。@niftyがDM（ダイレクトメール）への対応のなかで、spammerに対して返事を書くなと勧めているのは正しい対応ではないか？
勿論、「すみやかにメールボックスから削除することをお勧めします。」をISPとして後ろ向きの対処と言われてもそれは反論できないだろう。着信拒否といったサービスでspamを撃退するのではなく、目に触れないように削除するといった方法となんら変わることなく、それはとても勧められたものではない。しかし、「@niftyでのスパムメールへの取り組み方」としてスパムメールブロックを紹介している一方、
なお、@nifty会員からスパムメールが送られてきた場合は、弊社までご連絡ください。会員規約上、問題があると判断した場合は、適切な措置を取らせていただきます。
と、spamの報告を一応求めているのである。
******
僕が@niftyで問題とするのは、opt-inではなくopt-outを採用していること、ほかのISPと比べても@niftyからのお知らせがあまりに多いことだ（それもDM系多し）。まず前者に関しては、オンラインサインアップで入会するときに、最後にお知らせやDMの配信を希望するかどうか訊ねるべきだと思う。つまりopt-inへの方針変換である。
後者については僕もほとほと呆れており、例えば、今年になって@niftyからのメールは実に107通、これは週あたり2.4通のメールが@niftyから届いている計算となる。一方、So-netに限って言えば、これまでのところ今年は48通である。平均1通/週ということとなる。rimnetについては31通、IIJ4Uは28通である。しかし、IIJ4Uはアクセスポイントのメンテナンスのお知らせが大半である。これを見る限りでは@niftyの異常さがわかることだろう。
@niftyを始め、各ISPは接続料金だけではやっていけず、コンテンツに活路を見出すほかなくなっている。これは去年、Yahoo! BBがADSL料金の価格破壊を呼び起こし、価格競争せざるを得なくなったISPはさらにコンテンツに収益の柱を移す傾向が顕著となった（それで利益が上がったという話は聞かないが）。それゆえ、DM系のお知らせが増えるのは予想される。
穿った見方を思いっ切りすれば、@niftyは自分たちもいっぱいDMを会員宛に送信しているから、同じDM系のspamに対して弱腰になってしまう、なんてことはないと思う（思いたい）。しかし、RFC 2505に対する@niftyの見方を知ると少し不安になるのもまた事実だ。
spamは受け取った者を不快にさせるだけではなく、Internet communityに対して悪影響を与えていることは公然の事実だ。Internetにあるリソースを勝手に食い散らかし、自由と自主的なcommunityとして発展してきたInternetの精神を愚弄するような行為、それがspamなのだ。» [RFC 2635] DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam)
先日、iTSCOM（旧東急ケーブルテレビジョン）の246.ne.jpドメイン宛のメールがそのドメインになりすましたspamによって発生した大量のReturned mailが原因で遅延が発生、その30万通に及ぶメールを削除することでなんとか復旧はしたが、まさにspamの危険性を僕らの前にまざまざと見せつけてくれた。
» iTSCOM 246、SPAMが原因で長時間にわたりメールの送受信に遅延が発生 (ZDNet JAPAN)
» サブドメイン無しのメールアドレスをご利用のお客様のメール遅延とその後の経過について (iTSCOM)
新種のサイバーテロと表現した者もいたが、安定したネットワークを維持するためにはやはりこういったネットワークに対する脅威に対し、毅然とした対応を取らなければならない。@niftyはさっさとRFC 2505: Anti-Spam Recommendations for SMTP MTAsに準じたサーバ仕様に変更し、僕たちとともにspammerを追い詰めるべきだ。