EarlgreyTea です。
kuromaku さんとの齟齬の解消に時間がかかってしまいましたが、ようやく中身の話ができます。
でもその前に念のため。
kuromaku さんが書きました:
これでiMapの問題ではないということが分かりました。
iMacとは違いますし、マップとも関係ありません。
正しく「IMAP」と表記しましょう。正確には「IMAP4（Internet Mail Access Protocol version 4）」というプロトコルになります。
EarlgreyTea さんが書きました:
これはIMAPサーバー上のフォルダー限定の問題でしょう。
という発言はもちろん「IMAPプロトコル」の問題という意味ではありません。
「IMAPサーバー上のフォルダー対象の場合のThunderbirdの処理」について言っています。
それでは本題に入ります。
■■ 「どういうことが起きていたと考えられるか」編 ■■
件のメッセージフィルターはこういう構成でした。
コード:
新着メール（件名「ほげぴよ1」、件名「ほげぴよ2」…）
├フィルタ1（条件：件名に「ほげ」を含む）
│ ├1.メールを既読にする
│ └2.メールを「受信トレイ」→「フォルダA」にコピーする
│
└フィルタ2（条件：件名に「ぴよ」を含む）
├1.メールを既読にする
└2.メールを「受信トレイ」→「フォルダB」に移動する
フィルターアクションの順番はこれでいいのですが、アクションの対象はローカルのメールではなく、IMAPサーバーにコマンドを送信して処理をしてもらう必要があります。
状況から見て、Thunderbirdのメッセージフィルターのアクションで、サーバーからの処理完了を適切に待っていない疑いがあります。
関連すると思われるバグチケットを2件見つけましたが、どちらも解決されずに放置されています。
- Bug 892424 Incomplete messages when copying then moving with a filter (When "Copy to Local folder, Move to IMAP folder" is executed on multiple mails, "uid MOVE(copy+store \Deleted) uid1:uidN IMAP" is issued just after "uid fetch uid1 body.peek[]" for first mail)
- Bug 1221671 Filter sequence copy message to another inbox and then move original to another folder is not reliable (IMAP)
もし、メールのコピー処理が完了する前に移動をしてしまった場合、コピー元の受信トレイのメールが消失してしまい、コピーが失敗してしまうことになります。
「基本IMAP仕様」にしか対応していないサーバーの場合、メールの移動は「COPY / STORE / EXPUNGE」と3ステップが必要でしたが、MOVE拡張仕様に対応したサーバーでは MOVEコマンドの1ステップで可能です。
しかもサーバーによっては実際のデータ移動をせずに移動が可能のため、コピーより高速である可能性があります。
したがってメール移動のタイミングを遅らせてやらないと事故ることになります。
本来は Thunderbird のメッセージフィルターアクションで対策が入ることが望ましいですが、現状では厳しそうです。
次の投稿は「回避策について」編となります。
しばしお持ちください。
ログイン
ユーザー登録
FAQ
検索
