まずは...
コメントをポストする前には必ず「プレビュー」をしましょう。
巨大な文字になって自分が非常に読みにくければ、余程の例外を除いて、それをそのままポストすることは普通誰でも避けるでしょう。
ペーストで貼り付けられた[ b ]や[ size ]があると読みにくくなりますから、刷毛のようなボタンで余計な装飾の除去などをしてください。
詳しくは、コメント作成画面の「オプション：」の下のBBCode: On/Offのところの「BBCode:」をクリック。
POP3だとすると、質問の意味がわからなくなるので、IMAPだと仮定。
で、IMAPの一つのアカウントを、10台のThunderbirdで共有、と。
(1) タグは、prefs.jsの以下のエントリーで定義されます。
mailnews.tags.abcxyz.tag = タグのラベル名
mailnews.tags.abcxyz.color = #993399
IMAPでは、これは、flag(user defined keyword)としてメールのメタデータとしてメールに付けられ、その時のflagとしては、定義の「abcxyz」部分が使われ、サーバーのMboxに保持されます。
で、各パソコンのメーラーが勝手につけ、各パソコンのメーラーが勝手に読みに行くだけ。
そして、メールに、Thunderbirdに定義してあるflag(=keyword=タグ名)がついていれば、定義に従ってタグのラベル名を表示し、定義で指定された色で表示します。
(2) この「タグ」の定義は、各Thunderbirdのprefs.jsに定義されますから、10台全部のThunderbirdで同じ定義をもっていなければなりません。
(3) Thunderbirdで表示されるものは「タグのラベル名」であって、タグ名=flagの「abcxyz」は、表面にはでてきません。
途中で「タグのラベル名」を変えても、既にflag=タグ名として付加されたものが変わらないように、flag=タグ名である「abcxyz」部分は変更されません。
(2)/(3)の部分に問題があったら、お話になりません
タグのカラムは、表示させていますか？
タグの話なんだから、タグのカラムを表示してどのタグがついているか・いないか、などのチェックは、当然していますよね？
変わらないのは、色だけなんですか？
(2)/(3)の部分には全く問題はなくて、他のThunderbirdでつけたTagXが、自分のThunderbirdでもちゃんと検出されているのに、
色だけが、他のThunderbirdとは異なる、という現象なんですか？
その場合、一つのメールに複数の異なる色のタグを付けた場合ですか？
(4) (2)/(3)の部分には全く問題がない、というケース限定での話。
他のメーラーによるflag(user defined keyword、Tbのタグ)の変更は、IDLEコマンドを使うと、サーバーから自動的に変更の通知が来るのがIMAPの本来の仕様なんですが、
IMAPの仕様が、「何がなんでも絶対に通知しなくてはいけない」(MUST)ではなくて、「通知しないことがあってもよろしい」(SHOULD)、という書き方なので、
サーバーによっては、flagの変更の通知をサボる輩がでてきます。
その最たる例が、Gmail IMAP(^^;
実装が結構面倒なのと、サーバーの負荷の問題もあってか、結構多くのサーバーが、「通知しないことがあってもよろしい」(SHOULD)、を採用し、通知をサボっています。
一方、Thunderbirdは、「何がなんでも絶対に通知しなくてはいけない」(MUST)を信じて、IDLEコマンドを使います。
で、
Bug 693204 の現象になる、と。
> Long delay of emails being flagged as read(or flagged as \Deleted, \Seen is removed, tagged or untagged)
> within Thunderbird when the emails are read from another device/location
> (IDLE does not send unsolicited responses for flag changes)
この場合、ThunderbirdにIDLEコマンドを使わせず、メールボックスオープンの度に全メールのflagをチェックさせることで、回避できるのですが、
Thunderbirdのデフォールトのキャッシュする接続の数が5なので、キャッシュされている接続で使われているメールボックスに対しては、すぐに全メールのflagのチェックをさせられません。
Thunderbirdは、一つ目の接続をInbox専用、二つ目の接続をTrash専用、三つ目以降の接続を他のメールボックス、という使い方をしますから、
キャッシュする接続の数を3に減らせば、Inbox以外のメールボックスについては、
Inbox/Trash以外の他のメールボックスをクリックして目的のメールボックスをクリック、で、バグの問題を回避できます。
しかし、Inboxの場合には、ほとんどの時間一つ目の接続で使われていて、全メールのflagのチェックを強制できません。
従って、キャッシュする接続の数を1にし、Inbox以外のメールボックスをクリックし、もう一度Inboxをクリック、が必要になります。
しかし、大量のメールが届き、それをThunderbirdのフィルターで振り分けていて、しかもInboxにも大量のメールが残り、
数多くのメールボックスがあって、Auto-Sync=On、ほとんど全てのメールボックスがOffline-Use=Onで、
10台のPCのThunderbird全部がそれぞれのPCのローカルファイルに、全メールの全メールデータをダウンロードする、
というような場合には、キャッシュする接続の数を1、は無理があります。
Inboxは、名前のごとく、単なる「受信トレイ」として使い、全てのメールを他のメールボックスに移動し、Inbox自体は常にほぼ空の状態にし、キャッシュする接続の数を3にする、ということになります。
常に最新の状態、が必要ではなくて、作業開始前に一度状態をチェックする、でもいい場合には、
作業開始前に、一度オフライン作業に入り、全ての接続を切らせ、もう一度オンライン作業に入って、
全ての接続において、ログイン、メールボックスのオープン、を再度行わせることで、
全メールのflagのチェックを強制できます。
この場合には、キャッシュする接続の数=5でいいし、IDLEコマンドは、使いたきゃ使えばいいし、使いたくなければ使わなきゃいい。
ログイン
ユーザー登録
FAQ
検索
