🚀 go-pugleaf

>
> ァイルが出来ています。はっきりとは言えませんが RMAIL ファイルと
> .newmail-ユーザファイルの合計の容量が８ＭＢを越えると処理出来ないようです。
> それで質問ですが、この制限を変更する方法は無いでしょうか？
> 　mule のインストールは他の人が行いましたので詳しくは分かりませんが、標準
> 的な（？）パラメータしか指定していないと思います。
>

上限があるということを変更することは
基本的にはできないと思います。
(パッチをあてることでバッファサイズを多少大きくすることは
できたかと思いましたが。)

ということで、RMAIL をつかうときには

- ある程度大きくなってきたら、mv RMAIL RMAIL.year.mm.dd
    みたいにしてファイルを適宜作り替えていく。
  (古いメイルファイルは
   M-x rmail-input RMAIL.year.mm.dd
  でrmailモードで読めます。)

 - ファックスの tiff ファイルみたいな巨大なファイルとして送ってくる
    相手がいないことを祈る。(Denial of Service 攻撃と変わらない。)

みたいな運用をするしかないと思います。

2番目の対処にはSMTP の処理系(たとえば sendmail)で
メイルのサイズの大きさに制限をつけることが
できる場合が多いと思います。

MHモードとかでも、emacsバッファ内部にサイズ制限をこえた
大きなメイル本体を表示しようとしたら失敗するでしょう。
(ただし、MHのときにはディレクトリにメイル記事そのものは
問題なくコピーしてくれると思いますが、詳細不明。)

個人的には8MBどころか、1.44MB floppy fileの内容を
エンコードしたときにできるファイルのサイズ程度よりも大きい
ファイルはメイルとして送って来てほしくないというのが
管理者を含めての希望ではないかと思っています。
それより大きいのは  ftp 経由で交換しましょうというのが
もし ftpアカウントを使ってもらえるのであればいいかなと思います。

もちろん ファイルを split して、encode して小さくしてメイルと
しておくってもらって、それを個別に受取り元に戻すなんていうのが
UNIXの上では簡単にできます。(gnusharとか。)

が、上で述べた RMAILのときには、困ったことに小さいメイルが
複数あつまったときにまとめて読もうとしてしまって
やはりバッファが大きくなりすぎて問題になります。
そのときには mail をコマンドラインから呼び出して、一個一個見ては
セーブしてみたいな緊急処理がいりますから (経験者)、
RMAILをつかい続けるとして、巨大なファイルの交換が必要としたら、
やっぱり ftp が好ましいですね。

なお、一度mbox 形式でセーブしたメイルfファイル(バッファよりも小さい)を
RMAILモードで読み込ので自動的に Babylon 形式にできます。

石川