No.65 2000/09/17
メーリングリストの工夫あれこれ（その2）
　私は、Gabacho-Netのサーバでいくつかのメーリングリストを提供しています。そのうちのほとんどのメーリングリストでは、メンバーはネチケット（ネットワークのエチケット）をよく心得ています。たとえば といったことです。私の経験では、若い人たちはたいてい、私がネチケットを一度説明すればちゃんと守ってくれます。

　しかし、なかなかそうはいかないメーリングリストもあります。ソフトウェア工学関係の研究会のために提供しているもので、メンバーが200人近くで、年配の人もかなりいるメーリングリストです。
　初期のころ、私は、「無駄な全文引用（第60回参照）は極力避けてください」と何度も何度も説明していました。メンバーには、メールボックスの容量の制限が厳しいプロバイダを使っている人もいるからです。実際、メールボックスあふれでメーリングリスト管理者の私に差し戻されることがよくありました（今でもあります）。しかし、インターネットが普及するにつれて、全文引用は定着してしまいました。リソース（システムの資源；コンピュータの処理能力や記憶容量、ネットワークの伝送能力などの総称）がリッチなイントラネット（企業内ネットワーク）では、全文引用のメールがばんばん流れても困らないので、おそらく、その癖が外部のメーリングリストでも出てしまうのでしょう。
　私は、言うのをやめてしまいました。いちいち注意することで「うるさい奴」と思われるのがいやだったからです。
　添付ファイルが流れることも時たまありました。何度も説明しているのに、研究会専用のウェブページにも注意事項を掲載しているのに、また、私にファイルをメールで送ってもらえばウェブサーバに登録して、ほしい人にダウンロードしてもらうという代替手段も提供しているのにです。
　添付ファイルで1メガバイト近くになったメールが流れた時、メールボックス容量の制限が厳しいプロバイダで受信不能が発生して、私に差し戻しが殺到しました。「事故が発生しました。添付ファイルはおやめください」とアナウンスしました。その1ヶ月後、また流れました。

　私は考えました。無償で提供しているメーリングリストとはいえ、私は「サービス提供者」であり、メンバーは私にとって「お客様」です。注意を一度聞いて守ることができない人であっても、「お客様」であることには違いありません。お客様の「最大多数の最大幸福」を守ること（具体的には、配送事故を防ぐことなど）がサービス提供者の責務です。その責務を、うるさく注意することによって達成できないのなら、システムで防御することによって達成しよう。

　自作のGAWKスクリプトに手を加えました。
　まず、全文引用ぶら下げの抑止対策。たいていのメーラーは、引用文の行頭に「>」を付けるので、その行をカウントする。30行を超えたら、以降の連続する引用行を削除。代わりに「-- automatically snipped --」（自動カットしました）という行を一つ入れる。30行という数は、通常の大きさのウィンドウを埋め尽くす程度の行数で、それを超えて連続する引用行には私が読んでいていらいらするということ、それに、話の流れをわかりやすくする引用行の一続きはせいぜい20行くらいまでだという経験則から決めました。
　次に、添付ファイル拒絶対策。添付ファイルはマルチパートメッセージという形式で送られ、そのことはメールヘッダでわかるので、それを検出。指定されたバウンダリー（各パートの区切りになる文字列）を手がかりに、第1パート（本文のテキスト）だけを残し、第2パート以降を捨て去る。これで、Microsoft Outlook Expressがデフォルト設定のときに送りつけるHTMLメールのHTMLパートも削除できる。代わりに第2パートとして「添付ファイルまたはHTMLパートを削除しました」という意味の英語のメッセージをプレーンテキストで入れる。
　これで、私が注意喚起メールを出す必要はなくなりました。私はひっじょーに気が楽になりました。
　本格的なメーリングリストプログラムには、添付ファイルを削除する設定ができるものもあるのですが、結局、スクリプトの改造で実現しました。メーリングリストプログラムを新たに導入して、引用行の制限もできるか、今までの仕様との互換を保てるかということを調査するよりも、スクリプトを改造する方が楽だったからです。
　その後、全文引用ぶら下げ抑止機能と添付ファイル拒絶機能を独立させたスクリプトを作りました。

　さて、この対策は別の弊害をもたらします。メンバーがほかから得た情報をメーリングリストに流す時、元がすでに引用文（行頭が「>」）の形になっていると、30行まででカットされてしまうことです。それを回避するには、送信者がスクリプトをだますように編集してくれる必要があります。行頭の「>」を別の文字に置き換えるとか、30行以内ごとに適当に空白行を入れるとかです。長く連続する引用行を意図的に入れたい人には手間をかけさせますが、やむを得ません。100行だろうが200行だろうが、何も考えずに全文引用をそのままにした返信を投げつけるケースの方が圧倒的に多いのですから。
　もう一つの弊害は、真に必要な緊急時に添付ファイルを流すことができなくなったことです。この研究会の設立に功績のあった人が亡くなった時、私は、葬儀会場の地図が添付ファイルで流れたのを黙認しました。今後は、どんな事態であろうと添付ファイルは容赦なく自動削除されます。「地図なら、私に送ってくれれば極力その日のうちに研究会ホームページに貼り付けてあげます」と表明しているものの、緊急時に情報が伝わるのが遅くなるリスクは避けられません。しかし、やむを得ません。配送事故が頻発するのは困りますから。

　「できること」と「やってよいこと」とは違うのです。添付ファイルを流すことが可能であるからといって、やってよいとは限らないのです。やるべきでないことを誰もが守っていれば、そのルールに優先すべき緊急時にあえて超法規的にルールを破る余地が残されます。「できるのに、なぜやってはいけないのか」と言うユーザーがいれば、サービス提供者は、融通のきかないコンピュータシステムに防御を委ねざるを得なくなります。だから皆さん、サービス提供者が要請することはちゃんと守った方がいいですよ。
　もちろん、私は、この防御策をほかのメーリングリストには適用していません。

　ほかの人だったら、ボランティアでサービスを提供していてこういうことがあれば、うんざりしてしまうかもしれません。でも、私は楽しいですよ。こういう工夫をすることが。また、ネットワークを通して人間のさまざまな行動を観察することが。
目次 ホーム