RMAIL をご利用の皆様へ
− MH に乗り換えてください −

by 飯嶋 浩光(g740564

1998 年 4 月 28 日
(6 月 2 日・25 日 加筆訂正)

重要度: ★★☆ (後日でいいので必ず読んでください)


要約

Mule から利用できるメールソフトの一種・RMAIL (Tools→Read Mail)は、特に理由のある場合を除いて使用を避け、 MH などの他のメールソフトに乗り換えることを強くお勧めします。 (MH の使い方は『情報処理入門補遺』に書いてあります。) これは、RMAIL はファイルの肥大化・ 文字化けなどのトラブルを起こしやすく、特に、文字化けを起こした場合にはその前後のメールも読めなくなるおそれがあるからです。

なお、RMAIL から MH への移行方法を下に示しましたので、参考にしてください。


RMAIL が起こす様々なトラブル

RMAIL は、次のようなトラブルを引き起こすことが確認されています。
  1. 改行から改行までの間が長いと、文字化けする

    一般に、電子メールでは、 各行の右端で改行を入力すべきであるとされています。

    ところが、現実には段落末まで改行を入れないメールがあるため、 RMAIL では、メールを受け取ったときに、改行から改行までが 127(= 27-1) 文字を超えると、 127 文字目の直後で強制的に改行を入力してしまいます。

    これは、英文ではそれほど大きな問題はありません。 (単語の途中で改行されるという不都合はありますが…) ところが、RMAIL は漢字圏のことをまったく考慮していないので、 日本語のメールを受け取ったときに問題が生じます。 日本語の文字(いわゆる全角文字)は 1 文字で英文の文字 (いわゆる半角文字)2 文字ぶんとして扱われるので、 *1 ある全角文字が 127 文字目(全角文字換算では 64 文字目の前半)と 128 文字目(同、後半)にまたがっていると、 RMAIL はその中間に改行を入れようとします。そうすると、 二つに割られた全角文字の右半分が次の文字の左半分と結び付いて、 まったく別の全角文字に化けてしまいます。 さらに、その文字の残った右半分がその次の文字の左半分と… というふうに連鎖反応を起こして、 その行は読めなくなってしまいます。

    *1: 厳密には必ずしも正しくないのですが、 ここではとりあえずそういうものだとお考えください。

  2. ある種のメールが送られると、 簡単に文字化けを起こす

    コンピュータ内部での日本語の記録方法には、 主なものとして次の 3 種類があります。

    1. JUNET 方式 …… 俗に JIS 方式ともいう
    2. シフト JIS 方式 …… Windows や Macintosh の標準方式
    3. 日本語 EUC 方式 …… ECC の標準方式

    電子メールの送受信には JUNET 方式を用いることが推奨されていますが、Windows などのメールソフトの一部では、特に設定しない限りメールをシフト JIS 方式で送るようになっていることがあります。 また、ECC 内部でやり取りされているメールは JUNET 方式が主ですが、中には EUC 方式のものもあります。

    では、そういったメールを受け取ったらどうなるでしょうか。 RMAIL ではすべてのメールを一つのファイル(~/RMAIL)に保存しますので、3 種類の方式で記録された文章が一つのファイルに混在することになります。

    この中で、 JUNET 方式と EUC 方式が一つのファイルに混在していることには、ほとんど問題はありません。 JUNET 方式とシフト JIS 方式の混在も、 それほど大きな問題ではありません。

    しかし、EUC 方式とシフト JIS 方式を一つのファイル中で混在させることは、 原則としてできません。 そのため、EUC 方式のメールを既に受け取ったあとでシフト JIS のメールを受け取ると、 その新着メールは文字化けを起こしてしまいます。 場合によっては、Mule がデータ構造の分析を誤り、 今までは読めていた EUC 方式のメールまで読めなくなってしまいます。

  3. 本来必要な量の 2 倍のディスクを占拠する

    RMAIL では、すべてのメールを一つのファイル(~/RMAIL)に保存します。人によっては数百通のメールをためていることもあるので、このファイルは 3〜4 メガバイト(1 メガバイトは日本語で約 52 万字) 以上になることもあります。

    これだけでは特に問題はないのですが、Mule でこのファイルを開いてから C-x C-s で保存すると、もうひとつ、ほぼ同じ大きさのファイル (~/RMAIL~)を作ります。*2 このため、本来必要なディスク容量の 2 倍を占拠してしまいます。

    ECC では、学生ひとりあたりのディスク容量制限は 15 メガバイトとなっているので、RMAIL が原因で容量制限を超え、 ログイン不能になる例がときどきあります。

    *2: このように、ファイル名の末尾に「~」がついたファイルはバックアップファイルと呼ばれ、 Mule でファイルを保存したときに、古いファイルの名前のあとに 「~」をつけて残しておいたものです。 これは、誤って古いデータを消してしまったときに復旧できるようにするためのもので、通常は必要ないものです。


RMAIL から MH への移行方法

RMAIL で保存したメールファイルを MH の形式に変換するには、 以下のようにします。

(危険度 : 少々の危険は伴いますが、 原則としてご自分で行ってください。なお、文字化けやディスク容量制限などの問題を抱えている場合、 また途中でうまく行かなくなった場合は、絶対にご自分で直そうとせず、 相談員に相談してください。

  1. まず、~/RMAIL を、 MH でも読み込める形式のデータに変換します。

    Mule から M-x unrmail を入力し、 「RMAIL ファイル名」には~/RMAIL を、 「メールボックスファイル名」には適当な名前(仮に ~/mailbox.dat としておきましょう) を指定します。そうすると、~/RMAIL に記録されているメールが、この ~/mailbox.dat に書き出されます。

    文字化けの影響で、「Bad format in RMAIL file」 と表示される場合、また、ディスクの容量制限オーバーで ~/mailbox.dat に書き込めない場合は、 下の注を参照してください。

    この他に、kterm から b2m というコマンドを使用する方法もありますが、 このコマンドは「Bad format in RMAIL file」 のエラーが発生すると黙って (エラーメッセージを出さずに)作業を打ち切るので、 使用はあまりお勧めしません。

  2. 先ほど変換したファイルを、MH に読み込ませます。

    Kterm から「inc -file ~/mailbox.dat」 として、~/mailbox.dat を MH に読み込ませます。

    すべてのメールが MH 形式に変換され、正常に読めていることを確認してから、 不要になったファイルを処理します。

    なお、今まで MH と RMAIL を併用していた人の場合、 MH で今まで受け取ったメールの後ろに、 RMAIL から移行したメールが保存されることになります。 それで不便な場合は、Kterm から 「sortm -verbose」と入力すると、 メールを発信時刻順に並べなおすことができます。 詳しくは Kterm から「man sortm」 と入力して調べてください。

(注)うまくいかない場合の対策

(危険度 : 極めて危険です。 下の方法の原理が分からない方・少しでも確証の持てない点のある方は、 絶対に作業しないでください。 失敗した場合でも、著者は責任を負いかねます。
  1. Quota over の場合は、temporary directory を活用するなどの対策をとってください。

  2. 文字化けのせいで、 メールヘッダ中の表示しない部分と表示する部分との区切りである 「*** EOOH ***」という行が正しく読めず、 「Bad format in RMAIL file」と表示される場合は、 途中まで書き出された古い ~/mailbox.dat を削除してから、適当な新規ファイル上で
    (auto-save-mode nil)
    (insert-file "~/RMAIL")
    (query-replace "\^_\^L\n" "\^_\^L\n1,,\n*** EOOH ***\n")
    してそれを ~/RMAIL 以外のファイル名で保存し、 そのファイルに対して M-x unrmail します。

補足説明

  1. MH には「cluster gap 問題」が存在することが知られていますが、 ECC の環境においては心配する必要はありません。
    コンピュータのディスクの中は、cluster と呼ばれる小さな部屋に区切られています。 (さらに小さい sector という単位もありますが、これは 「部屋の中の畳一枚」のようなものだと思って下さい。)

    ひとつのファイルの大きさがこの部屋より大きいときは、 そのファイルを複数の部屋に分けて収納します。 しかし、ファイルの大きさがこの部屋より小さいときでも、 複数のファイルで相部屋ということはしません。 従って、小さなファイルがたくさんあるときには、 ファイルの数だけ部屋が必要になり、本来必要な容量よりたくさんのディスクを消費してしまいます。 これが、cluster gap 問題です。

    MH ではメール 1 通あたりひとつのファイルを使うので、 ひとつひとつの部屋が大きいディスクを使う場合 (たとえば、Windows 上で Mule を動かす場合) にはディスクを浪費することがあります。

    しかし、ECC の環境ではひとつひとつの部屋がじゅうぶん小さいので、特に心配する必要はありません。

  2. 他の資料等では、 メールソフトについて次のような解説をしています。


Send e-mail to wwwadmin@sodan.komaba.ecc.u-tokyo.ac.jp

Copyright © IIJIMA Hiromitsu aka Delmonta, 2016/03/10 15:09 JST
これは「古文書」です。 古くなった情報も原則未修正で保存していますのでご注意ください。

古文書本館トップ | 電脳外道学会