Thunderbird のタグに関して、知っていることを書かせていただきます。
自己レスでお書になっている調査済みの内容と重複もあろうかと思いますが、話の流れとしてまとめますので、ご容赦ください。
【一般的な情報】Thunderbird がタグに関する情報を保存しているところは複数あります。
（a）タグそのものの設定 ・[オプション] -> [表示] -> [タグ] での設定内容
└・メニューの [メッセージ] -> [タグ] 、および右クリックからの [タグ] の表示内容
これらは、prefs.js 内に、mailnews.tags.* という項目として複数存在し、定義されたタグ名や配色の情報が保存されています。
原理的には、移行元の prefs.js にあるこれら一連の設定行を、移行先の prefs.js にコピーすれば、タグ自身の設定内容は移せます。
ただし、この設定はタグの基礎情報のみです。これを移行しただけで各メッセージに自動的に新しい内容のタグが付くわけではありません。
移行先にすでにタグの付いたメッセージがあったとして、それが保持している情報と、持ち込まれたタグの情報が食い違えば、予期しない内容のタグ付けになってしまうかもしれません（関連後述）。
【重要】prefs.js には Thunderbird の中枢情報が集中しています。誤った操作をすれば致命的な障害を発生させてしまう危険があります。
この場合、移行元の prefs.js は、そのコピーを別の場所に作り、それを開いて操作すれば安心です。
移行先では、user.js という名称のファイルを作り、そこに移行したい設定行だけを記述し、その上で Thunderbird を起動させれば、user.js の内容が prefs.js に自動的に書き写されます。ユーザーが独自に施した設定内容も切り分けられるので、後々のメンテナンスを考慮すると、こちらの手段を使ったほうがいいと思います。
（b）メッセージフィルタでおこなうタグ指定 ご存知のように、メッセージフィルタは大きく分けて、（i）条件付け、（ii）それに対する動作 ―― で構成されています。
タグに関するものは（ii）に含まれ、この内容は（a）に依存しています。
メッセージフィルタでのタグ付け条件は、（a）の $label* の内容で定義されていて、それをそのまま適用します。（a）の定義を変更すれば（b）の定義も連動します。
（i）と（ii）を関連付けた形でフィルタ情報を保存しているのは、各アカウントフォルダ内にある msgFilterRules.dat というファイルです。
つまり、アカウントの数だけ、msgFilterRules.dat が存在することになります。
メッセージフィルタにタグ付けの動作しか設定されていない場合、基本的には msgFilterRules.dat のコピーでメッセージフィルタを移行できると思いますが、[移動] や [コピー] などほかの動作が含まれている場合、移行元と移行先のフォルダ構成等に違いがあると、動作しないか、誤った動作がおこなわれる危険があります。
そのほかにも、そのユーザー固有の特殊なフィルタ条件などがあれば、何かしらの影響が現われるかもしれません。このあたりは、どんなフィルタ条件を含むかで変わってくると思われるので、ご自身で慎重に検討してください。
（c）すでにタグを付けたメッセージ （a）（b）の方法、あるいは手動で、送受信したメッセージにタグを付けた場合、２つのファイルにその情報が書き込まれます。
ご存知のように、メッセージは（i）実体ファイル（拡張子のないファイル）と、（ii）要約ファイル（拡張子が msf）の組み合わせで管理されています。
アカウント(X) の [受信トレイ] なら、実体は Inbox 、要約は Inbox.msf であり、プロファイル配下の Mail\accountX または ImapMail\accountX にあります。
ベースとなるタグ付け情報は、（i）内の個々のメッセージヘッダにある X-Mozilla-Keys: という Thunderbird 固有のヘッダに記述されます。選択したメッセージのソースから確認できます。
例：X-Mozilla-Keys: $label1 $label2
重要なのは、（a）でタグ情報を「$label1 - 重要- 赤」から「$label1 - 未定- 青」のように変更したとき、すでに、$label1 が付いているメッセージは、変更後の内容で表示されるということです（関連後述）。メッセージに付与されたタグの定義自体は、除去しない限り固定です。
フォルダを選択したとき一覧が表示される右上のスレッドペインの情報は、（ii）のファイルに保存されています。
カラム（「件名」「差出人」など）には「タグ」の項目もあり、このへんの情報が含まれているのですが、msf ファイルは mork 形式という独特の書式を持っていて、ぼくの能力ではうまく説明できません。（i）が健在なら、仮に（ii）が破損しても、（i）から基本的な情報は再生成されます。
（i）は、含まれるメッセージごとに文字コードなどの条件が様ざまです。厳密に閲覧だけならかまいませんが、テキストエディタなどで開いた実体ファイルを不用意に保存すると、メッセージを破壊することもあります。ご注意ください。
（d）移行先にあるメッセージに、移行元と同じ条件でタグを付ける ユーザー環境に特殊な事情がない標準的な条件の下では、最もシンプルなやり方は次ようになるでしょうか。
（a）が基本になるので、この移行が確実にできていること
（b）はアカウントごとに、それぞれの msgFilterRules.dat に含まれる条件設定が、移行先でも矛盾や期待外の動作を起こさないこと
この２つが確認できたら、アカウント配下のフォルダごとに、[フォルダにフィルタを適用] を実行します。
あるいは、そのアカウントのメッセージフィルタのダイアログを開いて、最下段の [フィルタを適用するフォルダ] を切り替えながら、[今すぐ実行] を押しても同じ結果を得られるはずです。
ただし、事前の運用状況によっては、後述するような課題をクリアしなければならないかもしれません。
以上は、タグに関する一般的な情報です。
【気になる点】ブリッジ さんが書きました:
profile 全体を動かしたり１回きり動かしたりしたいのではなく、元のほうにタグとそれを利用するメッセージフィルタを日常的に追加し、それらを別の PC の Thunderbird でも同様に……という感じです。
つまり、移行元と移行先は、総体として同期関係にあるわけでなく、タグに関連する部分に限って、「日常的に」ミラーリングする関係を築きたいということですか？
このうち、タグそのものの設定（a）は、移行元で生じた差分情報を移行先の user.js に反映させればいいので、処理内容自体は比較的わかりやすいと思います。
ただし、中枢情報を持っているデータに対し、タグ部分だけを「日常的に」ミラーリングする「安全かつ簡便な方法」のアイデアは、にわかには思いつきません。
移行元の pref.js から必要なデータを安全にコピーできるタイミングを図るのが注意点のひとつかと思います。コピーできさえすれば、user.js に書き込むのはそれほど難しくないと思います。
一方、メッセージフィルタ（b）は少々面倒な気がします。
あるアカウントのメッセージフィルタ全体（つまり、msgFilterRules.dat の内容丸ごと）をエクスポート／インポートできるアドオンがあるのは知っていますが、そのメッセージフィルタに設定されているであろう複数のフィルタを個別にエクスポート／インポートできる方法を、ぼくは知りません。
なので、移行元で追加されたタグ関連のフィルタの差分だけを、移行先にインポートする「安全かつ簡便な方法」が思い浮かびません。
力技がないわけではなく、msgFilterRules.dat 自体はテキストファイルなので手動で編集することは可能です。
しかし、複数のアカウント配下にある個々の msgFilterRules.dat を対象に、タグに関連する部分の差分だけを、定期的に A to B でミラーリングするのに、毎回手動編集というのは「安全かつ簡便な方法」とは言えない気がします。
移行元と移行先でアカウントの構成が異なる場合、移行元のどのアカウントの msgFilterRules.dat のタグ関連の差分要素を、移行先のどのアカウントの msgFilterRules.dat に反映させるかなど、事前に検討しておいたほうがいいこともあろうかと思われます。
合わせて、移行元と移行先のメールデータの同期ではないので、送受信するメッセージが異なっていると思われます。そこにタグ関連のメッセージフィルタを移行しただけでは、移行先の受信済みメッセージに自動的に適用されるわけではありません。そのつど、フォルダ単位でフィルタを手動実行してやる必要があるでしょう。
移行先の既存メッセージにすでにタグが付けられていた場合、移行元からコピーした（a）の内容によってはタグ付けに食い違いが生じるかもしれません。
移行先で独自に付けられたタグが、$label3 で名称「重要度２」、色「橙」だったとします。移行元で変更されたタグ情報（a）がコピーされたとき、そこでは $label3 が名称「後回し」、色「灰色」になっていたとすると、移行先のそのメッセージのタグ付けの意味が大きく変わってしまいます。
これは極端な例なので、タグ情報のミラーリングとその反映が順調に進めば、徐々にこうした齟齬は是正されていくと思いますが、移行先のこれまでの運用状況によっては、初期段階でこういう齟齬が大量発生する可能性があることを、念頭に置いておく方が安全だと思います。
他にも、一方のアカウントが IMAP で他方が POP とか、移行元と移行先の環境条件や施されている設定条件、導入しているアドオンの違いなどによっては、さらに考慮したほうがいい要素が出てくるかもしれません。
心配し過ぎかもしれませんが、こういうハードルがいろいろ思い浮かんでしまうので、ご期待にそえる答えにはなっていないと思いますが、情報として使える部分があれば利用してください。
ぼくが知らない、あるいは見落としているだけで、"こんなに簡単な方法がある" とか "便利なアドオンがある" といった情報が寄せられるかもしれませんので、他のユーザーさんからのリプライも待ってみてください。
長くなりましたが以上です。役に立たない話だったらすみません。
ログイン
ユーザー登録
FAQ
検索
