普段 Webmail を利用していますのでメーラーはめっきり使う機会がなくなっているのですが（ガッチガチにセキュリティを固めた XP では相変わらず Outlook Express を愛用していますが）、2.14a で実装した全ての送受信メールを特定のアカウントに集約する機能の最終テストをするべく、めっちゃ久しぶりに Thunderbird を起動してみました。

17.x.x と古かったのでまずは更新してみたところ、24.0.1 になっていました。なんか凄いバージョンです。

と、その前にテスト用のメールを作らなければならないのでローカルに構築してある 2.14a にストレステスト用のソフトを少し改造して、ランダムにフォルダ内にあるファイルをくっつけて、でたらめに送信させます。

1,000 通くらい送ってから、Thunderbird を起動してみますと、実装した機能は正常に動作しているようです。

で、ふと画像が添付されているメールを開いてみたのですが・・・画像が壊れてる(^-^;

また受信時にサイズに 2M と表示されているサイズが 104K と減っています。

なんだこれ？IMAP4に未知のバグ？不具合？

と急遽ログを精査してみます。
（以下のログは非常に大きくなるので通常の PMail Server2 では出力されません。デバッグ用出力です）

[IMAP4] (略) [000-6L7POm] 11 UID fetch 235082:235401 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To)])

IMAP4 のコマンドは少々判り難いですが、慣れればスラスラと読めます。

上のコマンドは、UID fetch ってコマンドで 235082番から235401番のメールの、ユニークIDとサイズとフラグとヘッダの中の From To Cc Bcc Subject Date Message-ID (以下略）を教えてねってコマンドです。

これ書いてて気が付いたのですが、Bcc を教えろってなんだそれ（笑）ヘッダ中に Bcc なんてあるわけないだろ。

まぁ、それはいいとして

[IMAP4] (略) [000-6L7POm] * 20 FETCH (UID 235235 RFC822.SIZE 2064655 FLAGS (\SEEN NONJUNK) BODY[HEADER.FIELDS ("FROM" "TO" "CC" "BCC" "SUBJECT" "DATE" "MESSAGE-ID" "PRIORITY" "X-PRIORITY" "REFERENCES" "NEWSGROUPS" "IN-REPLY-TO" "CONTENT-TYPE" "REPLY-TO")] {344}
ここは実際の内容なので省略。
)

ここは、応答の 20番目です。UID は 235235 です。

メールのサイズは 2064655バイトです←重要！

後は色々とヘッダの内容などがつらつらと出てきます。
ここもＯＫですが、メールのサイズ応答を覚えていて下さい。

[IMAP4] (略) [000-6L7POm] 14 UID fetch 235235 (BODYSTRUCTURE)

UID fetch コマンドで 235235番のメールの、メール構造体（BODYSTRUCTURE)を教えてね。ってコマンドです。
メール構造体の説明は非常に面倒臭いので省略！

[IMAP4] (略) [000-6L7POm] * 20 FETCH (UID 235235 BODYSTRUCTURE ((("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 0 0 NIL NIL NIL) ("text" "html" ("charset" "iso-2022-jp") NIL NIL "7bit" 133 1 NIL NIL NIL) "ALTERNATIVE" ("boundary" "0......

特定の書式に従って上記のような構造体を解析して「文字コードはなにかなー」とか「添付ファイルはどんなのがどんだけあるのかなー」とか出てくる訳です。

ここまでもＯＫです。

さて問題は次の行です。

[IMAP4] (略) [000-6L7POm] 15 UID fetch 235235 (UID RFC822.SIZE BODY[]<0.106496>)

UID fetch コマンドで 235235 の UID とメールサイズと「メール本文の最初から 106496バイトまで送ってね」です。

えぇ？？106496 ってどっから出てきたの？
なんか 1024で割ると 104KByte になるのでまずは 104KByte だけ受信して残りは後で受信するのかな？
と思った訳です。

ちなみに、BODY[]<106497.212992>とかすると、続きから受信ができるのが IMAP4 です。

これに対する応答が下です。

[IMAP4] (略) [000-6L7POm] * 20 FETCH (UID 235235 RFC822.SIZE 2064655 BODY[] {106496}
ここはメール本文なんで省略
)

UID は（略）メールサイズは 2064655 です。指示された通り 106496byte 送りマース。

応答は間違っていません。省略した箇所もきちんとサイズを数えましたが、きっちり 106496byte です。

その後、Thunderbird から 235235番にアクセスすることはありませんでした・・・っておい！ダメじゃん！！（笑）

メール本文をＷクリで開ければ残りをダウンロードするのかと思ったのですが、アクセスしない。
念の為、アカウントごと削除してプロファイルも削除して新規にアカウント設定しても同じ症状。

そもそも、106496byte の根拠がどこにも無い（近似値も探しましたが無い）

ネットワークがいかんのかな？とローカルに完全に同期させてみるもアウト。

この症状全てのファイルに発生する訳ではなく、特定のメールでのみ発生し、重要なのは「他の IMAP4 クライアントでは発生しない」事です。
一応ですね、Thunderbird 以外として、Outlook / Sylpheed / Becky! / iPod touch / iPad / Android K9 / i4Portable(宣伝) で確認しています。公平にね。

世界的にも利用者が多く検索しても「これはすんばらすぃメーラーだ」と絶賛されている Thunderbird です。
色々と掲示板とかを見ても「アンチウィルスが原因じゃねーの？」とか「プロファイルが壊れているんだよ」ってのが大半ですので、まさか不具合があるとは思えません。

サーバーのログから客観的に見ても、Thunderbird 側が 104Kbyte だけ送れって指示しているのが原因と思われますが、きっとうちの Thunderbird が壊れているんでしょう。

それか、一応 IMAP4 サーバーを開発して 3.5年くらいやっていますが、まだ見知らぬプロトコルの仕様があるのかもしれませんので、Thunderbird だけが悪いとは言えないですけどねー