[mew-dist 24713] IMAP: FETCH with untagged responses not terminated

[ash2 at example.com]

現在 Mew-4.0.63 を使っていまが、以前のversionから IMAPでメールを取
得しようとして終了しないサイトがありました。
(mew-summary-retrieve-message,mew-summary-retrieve)

POPもあるのでごまかしていたのですが、ちょっと見てみました。
RFCも .el も正確には読んでないので勘違いしているかもしれませんし、
あるいはすでに議論済みのお話かもしれませんが、その時は申し訳ありま
せん。

|<GREETING>
|* OK myrealbox.com NetMail IMAP4 Agent server ready <1595d.1078867059 at example.com>

|<=SEND=>
|mcab7249 UID FETCH 2827028 RFC822
|
|<FETCH>
|* 2 FETCH (UID 2827028 RFC822 {744}

|Content-Transfer-Encoding: 7bit
|
|TEST
|)
|mcab7249 OK UID FETCH completed
|* 2 FETCH (FLAGS (\Seen))
|
|
|<IMAP SENTINEL>
|killed by the user

読み取ったバッファ中の最終行が "TAG OK ..." ではなく "* 2 FETCH" 
の untagged responses(タグなし応答) のため、現在の mew-imap-filter 
の処理の流れでは、サーバからの completion result response(完了応答?) 
を見つけられず、データ待ちの状態になっているようです。

サーバ側がこの2つの応答の順番を間違えているのかとも思いましたが、
RFC2060,3501 の 2.2.2 を斜め読みした限りでは、タグなし応答は、命令
の結果としてだけではなく、サーバが一方的に送りつけてよいようなので、
規約上問題はないような気がします。これは勘違いでしょうか?

もし規約上問題なければ、バッファ終端から前方にタグを探す、という処
理は、無理でないにしても少し苦しくなるように思えます。

単純に考えると、望ましくは素直に、前方から順に行ごとの処理を行うの
がよさそうに思えるのですが、下記などを見ると、効率だけでなく、
literal のカウント数の問題なども出てきそうです。

[mew-dist 21326] Re: IMAP: bottom of Message 
http://www.mew.org/ml/mew-dist-2.0/msg03096.html

CRLF をどの時点で変換しているのか追っていないのですが、やはり、
literal 中の行数を数えるなど、この方向での修正は困難でしょうか?

よろしくご教示をお願いいたします。

---
Takamasa Hasei