メーリングリストで無駄な全文引用がばらまかれるのを抑止するための工夫を
第65回でご紹介しました。行頭が「>」である行を引用行と判断し、それが連続したら31行目以降をカットするという仕掛けです。
ところが、さっそくこの方式の問題が見つかりました。次のような全文引用のパターンがあったのです。
> インターネットが大衆化する前の研究段階のころは、話の流れをわかりやすく
> するための引用文だけを残し、無駄な情報を極力削ることが強く推奨されて
> いました。今よりもコンピュータの動作が遅く、ディスク容量が小さく、通信回線
の
> 速度も低かったからです。また、Windowsのような便利なウィンドウシステムが
> 一般的でなかったころには、ディスプレイ画面を埋め尽くす行数の引用文を送り返
し
> て
> 受信者に延々とスクロールを強いるのはひんしゅくものとされていました。
|
|
（もちろん、実際に流れた文面ではなく、私が例として作ったものです。）
|
つまり、長い引用行の後ろの方が次の行へ折り返され、折り返しの行頭に「>」がないというパターンです。メーリングリスト処理スクリプトは、折り返しを新規行（送信者が新たに書き込んだ行）とみなしたため、長い全文引用がほとんど抑止されなかったのです。
私を困らせてくれたメーラーは、またしても
Microsoft Outlook Expressでした。残念ながら、Windowsにただで付いてくるこの問題だらけのメーラーを使っている人はたくさんいます。これでは、無駄な情報を抑制するという目的を果たせません。
そこで、いったん引用行の抑止が始まれば折り返しの後も抑止が継続する（ただし、次に空白行が来るまで）ようにプログラムを変更してみました。連続する引用行数の制限は30行にしていますから、前記の例において、それ以前に引用行が29行連続していたとすると、次のような表示になります。
> インターネットが大衆化する前の研究段階のころは、話の流れをわかりやすく
-- automatically snipped --
の
-- automatically snipped --
し
-- automatically snipped --
|
行頭に「>」がない折り返しは形の上では新規行と区別できないので、削除するわけにはいかないだろうと思っていたのですが…。
社内で流れたメールを見ていて、次のようなパターンもありうるということに気付きました。
> インターネットが大衆化する前の研究段階のころは、話の流れをわかりやすくす
る
> ための引用文だけを残し、無駄な情報を極力削ることが強く推奨されていました。
今
> よりもコンピュータの動作が遅く、ディスク容量が小さく、通信回線の速度も低か
っ
> たからです。また、Windowsのような便利なウィンドウシステムが一般的でなかっ
た
> ころには、ディスプレイ画面を埋め尽くす行数の引用文を送り返して受信者に延々
と
> スクロールを強いるのはひんしゅくものとされていました。
|
これは次のようになってしまいます。
> インターネットが大衆化する前の研究段階のころは、話の流れをわかりやすくす
る
-- automatically snipped --
今
-- automatically snipped --
っ
-- automatically snipped --
た
-- automatically snipped --
と
-- automatically snipped --
|
こりゃだめだ。行数はちっとも減りません。
引用行カウンターをリセットするタイミングを、行頭が「>」でない行すべてでなく、空白行だけにするという発想は、すでに得ていました。次の発想は、「引用行カウンターが30を超えたら、
次の空白行の直前までことごとく消してしまう」というものでした。そうすれば折り返しも消えます。しかし、新規行も消えてしまうことがありえます。そこで、それでユーザーを困らせないかどうかの検証です。
過去のメールから、引用行の後に新規行が書き込まれるパターンを調べました。
> ところが、昨今では、引用文をまったく編集せずに、先頭に文章を書き加えて
> そのまま送信する人が多くなりました。
ほんとにそうですね。私がプロバイダにトラブルの問い合わせをした時、回答
に私の数百行のメール文がそっくりぶら下げられていたことがありましたよ。
> しかし、高速のLANを使っている企業内でならともかく、そうではない受信者
> のことも考えてほしいものです。低速のダイヤルアップ回線でインターネット接
|
引用行の後に新規行を書き込む人のほとんどは、↑このように、新規行の前後に空白行を挟んでいます。これなら、たとえ引用行が連続30行を超えてカットされることがあっても、新規行が消されることはありません。空白行の所で引用行カウンターがリセットされるからです。
> ところが、昨今では、引用文をまったく編集せずに、先頭に文章を書き加えて
> そのまま送信する人が多くなりました。
ほんとにそうですね。私がプロバイダにトラブルの問い合わせをした時、回答
に私の数百行のメール文がそっくりぶら下げられていたことがありましたよ。
> しかし、高速のLANを使っている企業内でならともかく、そうではない受信者
> のことも考えてほしいものです。低速のダイヤルアップ回線でインターネット接
|
まれに、↑このように新規行の直前に空白行を挟まない人がいました。この場合、連続30行を超えた引用行の後の新規行は消えてしまいます。しかし、引用行の後に新規行を書き込む人は、引用行を適度に短く区切っていますから、問題ありません（新規行の後の方に空白行を入れてくれさえすれば）。
> ところが、昨今では、引用文をまったく編集せずに、先頭に文章を書き加えて
> そのまま送信する人が多くなりました。
ほんとにそうですね。私がプロバイダにトラブルの問い合わせをした時、回答
に私の数百行のメール文がそっくりぶら下げられていたことがありましたよ。
> しかし、高速のLANを使っている企業内でならともかく、そうではない受信者
> のことも考えてほしいものです。低速のダイヤルアップ回線でインターネット接
|
もし、空白行をまったく挟まない↑このようなパターンだと、引用行が累積カウントされ、31行目の引用行以降がことごとく消えてしまいます。しかし、このような書き方をする人はいませんでした。読みにくくなることがわかっているからでしょう。
ということで、この仕様で問題なしと判断し、メーリングリストに説明を流しました。
次に起こるトラブルは、元々が引用文の形になっている新規情報がカットされて流れることでしょうかね。「30行以内ごとに空白行を挿入してください」と説明してはあるのですが、忘れる人はいるでしょう。
ここまで工夫したあと、さらにひらめきを得ました。添付ファイルを除去する機能と引用行数を制限する機能を別々のスクリプトに分離することです。そうすれば、Majordomoやfmlなどの既存のメーリングリストプログラムと組み合わせることもできますし、必要な機能だけを選択して利用することもできます。
こちらでご紹介しています。
ただし、興味本位でこれを利用してシステムで制限をかけることはお奨めできません。ネチケットを説明して守ってもらう努力をするのが先ですよ。
（2000/10/26追記）
元々が引用文の形になっている新規情報がカットされて流れるというトラブルは、その後、本当に起こりました。そこでまたまた新しいアイデアを得ました。メーリングリスト名と連番から成る見出しを本文の先頭に自動的に記入しているので、その引用があれば、すでに流れているメール文の引用と判断してカットする、そうでなければカットしないという方法です。
こちらにそのアイデアを追記しました。