🚀 go-pugleaf

こんにちは山岡です。

XEmacs 20.3 と付属の Gnus を使える環境に居ないので想像で書いてしまいま
すが...。

>>>>> In <6mktfp$di1$1@ns1.hamamatsu-pc.ac.jp> 
>>>>>	mori@mori.c.hamamatsu-pc.ac.jp (MORI Mitsuhiko) wrote:

森さん> 岐阜職短の森です.

森さん> xemacs-20.3のgnusをメイルの読み書きに使い始めてみたのですが,メ
森さん> イルの取り込みがうまく行かないことがあり,困っています.

森さん> メイル・サーバ(POP3サーバ)側のスプールディレクトリと見比べてみ
森さん> ると, サーバ側では10通くらいのメイルがあったはずなのに,
森さん> xemacs+gnus側でメイルを取り込むと,6～8通ほどしか取り込めないこ
森さん> とがあります.

森さん> また,逆にサーバ側では複数の別個のメイルとして存在しているに,
森さん> xemacs+gnusに取り込むとつながって1つのメイルとして扱われてしま
森さん> うケースもありました.

movomail が作る crash box file の中身は babyl format で複数のメールが
区切られています。2通だとこんな感じになります。

^L
(1通目)
^_^L
(2通目)
^_

これを処理する場合に問題が発生する場合として二つのことが考えられます。

1. メールの本文中に改ページ記号 "^L" や texi ファイルの "^_" が含まれ
   ていた場合に、メールとメールの区切り記号であると誤判定される。

2. ヘッダに Content-Length フィールドがあって、そこに書いてあった数値
   が正しい値より大きかった場合に、区切り記号 "^_^L" が飛ばされてしま
   う。

いずれも古い nnmail.el を見て想像で書いていますが、2. については確実に
事故が起こせるように思えます。と言うのも生の Gnus は crash box file を
バッファに読み込むときに coding-system を規制していないために自動変換
が行なわれるとすれば、iso-2022-jp などだったときの Content-Length より
も小さいサイズのメールになってしまうからです。

では movemail コマンドの代わりに pop3.el の関数を使えば良いかというと、
世に野放しになっているものはやはり問題がありますので :-p、ここはやはり
Semi-gnus に乗り換えて、付属の pop3.el を使うようにするのがもっとも簡
単なのではないかと思います。
-- 
Katsumi Yamaoka <yamaoka@ga.sony.co.jp>