31.5.0

メール受信時に、自動的にそのメールの件名の特定の文字列を変換したり除外したりする
方法　ないし　アドオンはないでしょうか？
したいことは、返信や転送時に着く「Re:」「Fwd:」のコロンを取ることです。
自分はメールをそのままemlファイルとして保存してますが、コロンがあるとそれより前の文字列
がファイル名から消えて不便に感じます。

送信時にコロンを消すことは「Subject Cleaner」というアドオンでできました。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

Re:やFwd:を除去、というようなものはあっても、Re:の「:」だけを取る、なんてなアドオンがあるとは、到底思えない...

まずは、何故、emlファイルに保存した時に、「Re:」がファイル名に入らないか、について。
「:の前だから除去」ではなく、
Re:というのは、メールのSubject: で共通に使われる、一種のデファクトスタンダードな専門用語で、メールのサブジェクトとしてのデータではない、ということと、
Re: xxxに返信してRe: Re: xxx、それに返信してRe: Re: Re: xxx、による Re:の無限の増殖を、簡単に防止するために、
Subject:を解析する時に、先頭のRe:は全部除去した形で、msgDBHdr.subjectのような場所に保存し、msgDBHdr.subjectWithRe=true、というような感じで、Re:があることを保持していて、
返信の時に、常に、Re: + msgDBHdr.subject で済ますようにしてあって、
.emlへの保存の時に、先頭にRe:をつけたものを使う、ということはしていなくて、msgDBHdr.subjectを使っているから、Re:は使われない、です。
Re:の数を保持しているわけではなく、RE:だったのか、rE:だったのか、Re:とRe:の間のスペースはいくつか、とか、そういったものも、一切保持していませんから、
Subject: ヘッダーのデータの折り返しを取って文字列をデコードし直して、Re:を取り除かない、ということをしない限り、Re:も含んだデータを保存する時のファイル名に使うことはできません。

「メール受信時に、自動的に」は、この際一切無視して、自分で行うにはどのような方法があるか、についてです。

お望みのことをしたいのならば、
(A) メッセージヘッダーを解析してmsgDBHdr.subjectに入れる直前のどこかでお望みのデータにする、
(B) 保存されたmsgDBHdr.subjectを書き換えてしまう、
(C) 保存されたmsgDBHdr.subjectからファイル名を作る時に、お望みのようにする、
(D) ただのファイル名なんだから、簡単なスクリプトで好きなようにリネーム
などの方法が考えられます。

(A) では、メッセージのソースのSubject:を手動でもプログラムでも好きなもので書き換えて、Repair Folder。
　　メッセージのソース、それに対するTbの扱い、が気に食わないのなら、好きなように書き換えればいいだけ。
　　サブジェクトに簡単なコメントをつける、といったようなアドオンは、あったはず。
(B) では、自前のツールバーボタンのJavaScriptコードで、 msgDBHdr.subject="好きな文字列"。
　　自前のツールバーボタンは、Custom Buttonsというアドオンで、好きなようにいくつでも作ることができる。
(D) は、極く当たり前の、ファイルのリネームをする自前のツールを、好みのスクリプト言語で書くだけの話。
などがあります。

どれでもお好きなようにどうぞ。

[追記]
これだけではちょっと不親切なので、自前のツールバーボタンで書き換え、の戦略について、簡単に書いておきます。
現在スレッドペインで表示されているメールのmsgDBHdrは、
自前のツールバーボタンから見た、window.gFolderDisplay.selectedMessage で得られます。
だから、原理的には、var msgDBHdr=window.gFolderDisplay.selectedMessage;　の後、
msgDBHdr["サブジェクトを持つオブジェクト名"]["サブジェクトのプロパティ名"]="好きな文字列"; で変えられます。
このステートメント自体は、Tbがサブジェクトを解析したあとにmsgDHdrに書きこむ時のものと、全く同じです。
Tbは、その時には、C++コードでC++オブジェクトに直接アクセス、という違いはありますが。
window.gFolderDisplayも、Tbのコードが、スレッドペインやメッセージペインの表示などのために実際に使用しているものです。

もちろん、その後、スレッドペインの表示の更新とか、.msfファイルへのきちんとした反映とか、既に読み込んで使っているデータの更新とか、一貫性を持った変更をするには、多くのことをする必要があるし、
Repair Folderが入れば、当然のことながら、リセットされますけどね。
[追記おわり]

※質問するときは、「フォーラムの利用に関するご案内」、とりわけ「質問するときは」に目を通し、OS の種類や Thunderbird のバージョンといった使用環境についての最低限の情報を書き添えることをお勧めします。

横から失礼します。

トピックの件名は「メール受信時に自動的に件名を編集すること」についてですが、というのが目的ですよね？

Thunderbird 本体の機能を使ってメッセージを eml ファイルとして保存した場合、メッセージの Subject が保存したファイルの名前に当てられます。しかし、システムの制約からファイル名として使えない文字があり、これが Subject で使われていると期待どおりの結果を得られない、というお話だと思います。以下はその前提で書きます。

Thunderbird 本体からおこなう操作としては、次のような手順があります。
（a）[ファイル] -> [名前を付けて保存] -> [ファイル]
（b）メッセージを選択して [右クリック] -> [メッセージを保存]
（c）メッセージを選択して Thunderbird のウィンドウ外へドラッグ＆ドロップ

このうち、（c）の方法で保存した場合、「Re:」に関しては当方でもおっしゃっているようになります。
例えば、
　Re: 3/3のミーティングの報告です
という Subject のメッセージがあったとして、これを（c）の手順で保存すると、ファイル名は
　3_3のミーティングの報告です.eml
となります。コロン以前が消え、スラッシュがアンダースコアに置き換えられます。

しかし、なぜか「Fwd:」の場合はそうなりません。
例えば、
　Fwd: 3/3のミーティングの報告です
は、
　Fwd 3_3のミーティングの報告です.eml
となり、コロンが除去されただけで、前の文字列は残ります。

一方、（a）（b）の手順で保存すると、
　Re: 3/3のミーティングの報告です
のメッセージも
　Re 3_3のミーティングの報告です.eml
となります。

以上が、当方の環境で経験している結果です。（Windows 8 Pro 64bit + Thunderbird 31.5.0）
（c）の結果になる理由は存じませんが、Thunderbird のバグっぽい気はします。
他にも、Subject にシステムのファイル名で使えない文字が含まれていると、それらは削除されたり置き換えられたりしますが、前後の文字がいっしょに削除されることはないようです。
操作法としては、（c）はメッセージをひとつずつしか扱えませんが、（a）（b）は複数をまとめて選択・保存できるので、こちらのほうが使い勝手がいい場面も多いかと思います。


ご要望の動作を、受信時に自動実行する方法やアドオンは、残念ながら存じません。
特定の文字を検索・置換するスクリプトを自分で書いて、それを FiltaQuilla のようなアドオンと組み合わせれば、あるいは受信メールに対してご希望をかなえられるのかもしれませんが......。

しかし、別の観点から気になることもあります。
完全に個人ベースの電子メールなら、そこまで気を遣うこともないと思いますが、仕事など公用のメールに対してそういう動作が無原則におこなわれると、一歩間違えば「改竄」とみなされてしまうおそれもあるため、技術的なこと以外に是非の判断が必要かもしれません。

「Re:」のコロンを取ったぐらいのこととはいえ、そういうことができる、あるいは実際にやっているということは、他の部分も書き換えられるのでは、といった疑いを生むからです。"李下の冠、瓜田の履" と申しましょうか。

一方、受信したメッセージそのものには手をつけず、保存時のファイル名だけを加工するのは問題ありません。
保存したファイル名が変わるだけで、ファイル内にあるメッセージ本体の Sebject 等への加工・改変がないなら、電子メール自体のオリジナル性は保たれるからです。
しかもこの場合、オリジナルのメッセージは Thunderbird 内に残した上でのことでしょうから、ユーザーが管理しやすい方法で eml ファイルを扱えばいいと思います。

……と、まあ慎重な意見を書きましたが、実際はケース・バイ・ケースなのだろうと思います。
受信済みのメールを効率的に管理したいというニーズも確かにあって、Subject などのヘッダ情報を編集できるアドオンはいくつかあります。ただ、そうした操作を受信メッセージに対して自動実行してくれるものは知りません。書き換える対象や内容、範囲によっては、誤動作を起こしたときのダメージが大きいので、ユーザーの判断でやってね、ということなのかもしれません。

十分認識されていることなら余計なお世話になってしまいますが、せっかくなので書き添えておきます。

以上、さしあたってぼくが知っていることをコメントさせていただきました。役に立たない話になっていたらすみません。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

どうもです。このバグ？さえ直ればそれで満足なんですね。
直るまで我慢することにします・・・

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

(a)/(b)だと、Re: を一個つけていて、つけないのは、(c) のドラッグ＆ドロップだけでしたか。
ファイル名にRe:をつけて欲しい、というバグがあって、全部そうだと思っていたんですけど、(c) だけだったんですね。
知らなかった。

Subject: RE: rE: Re: ABCDE
とやると、もう少し現象が見えてきます。

スレッドペイン = Re: ABCDE
メッセージペインのヘッダー = Subject: RE: rE: Re: ABCDE
(a)/(b) = Re: ABCDE
(c) ＝ ABCDE

これは、(1) Subjet: ヘッダーそのまま、 (2) SubjectにRe有り=true ＋ Re:を除去したSubject、 (3) Re:を除去したSubjectだけ、の、どれを使うかの違いで、
メッセージペインのヘッダー = (1)、
スレッドペイン/(a)/(b) = (2) で、SubjectにRe有り=true だと、"Re: "　を一個先頭につける、
(c) ＝ (3)、
ということになります。
あと、ファイル名だから、Winでファイル名に使えないコロンの除去、が、当然入ります。

これは、(a)、(b)、(c)、で、通るパス(処理するモジュール)が、全然異なることに起因しています。
実は、(a)と(b)、添付ファイルだと、Openから保存、と、Save As、は、最終的に同じことをするにも関わらず、
全然異なるパスを通っていて、選択される「最後に保存したディレクトリー」が、パスによって異なる、というような問題があり、
統一したパスを通すように変えるべきだ、というバグが開かれています。
メールの保存も同様であり、保存する時のファイル名に関しては、たまたま、運良く同じルーチンを使っていた、というだけの話でしょう。
いつでもどこでも同じ名前で統一感を醸し出す、なんてなことをするはずもない(^^)

(c) の場合は、ドラッグ＆ドロップですから、保存される時のファイル名を作り出すところが、(a)/(b)とは全然違います。
OSのデスクトップへのドラッグでは、ドロップの処理を行うのはThunderbirdではなく、
ドロップの時に処理を行う、WinだとWindows Explorerに、Thunderbirdが、保存に使われる、ユニークなファイル名を引き渡す義務があります。
で、この、ユニークなファイル名の生成は、ドラッグのondragstartというような、ドラッグ開始のイベントハンドラーの中で行われます。
これは、(a)/(b)のコンポーネントとは別物です。
この中で使っている、ユニークなファイル名を生成するルーチンが、(a)/(b)と(c)で異なっているのでしょう。

Subjectヘッダーから全部持って来直し、ではなく、SubjectにRe有り=true だと"Re: "を一個先頭につける、を加えるだけであって、パフォーマンスの問題を引き起こす可能性はゼロだし、
(c)だけ異なる件は、ユニークなファイル名を生成するルーチンを、(a)/(b)と共通にすればいい話だと思います。
統一したルーチンを使いさえすれば、長すぎて短縮するロジックなども共通になるし。
ファイル名にRe:をつけて欲しい、というバグは、この件かな？

ドラッグ開始のイベントハンドラーはJavaScriptだし、その中でユニークなファイル名を生成するルーチンを呼ぶのもJavaScriptだったような気が...
そうならば、ドラッグドロップのイベントハンドラーを自分のもので置き換えてしまうコードは、ドラッグドロップのイベントのデータをとる時に作ったのがそのまま使えるし、
あとは、Thunderbirdのハンドラーをコピーして、(a)/(b)と同じものを呼ぶように書き換えてしまったものを作るだけ。
これで、「Tbがファイル名を作りだすところで変えてしまう」という戦略も可能であることが判明。

複数のメールのデスクトップなどへのドラッグ＆ドロップでの保存は、少なくともWinでは動かなくてサポートされていなくて、
全部のメールのユニークなファイル名を生成してもムダなので、先頭の一つしかユニークなファイル名を生成していないから、
パフォーマンスの問題は、どう転んでも起きようがないし(^^)

なお、Re: と Fwd: の違いは、業界公認の接頭詞か、Thunderbirdローカルの接頭詞か、によります。
「Re:は一個だけ」という、意味からもマナーからも要請されることを実現するために、Re:は特別に扱われています。
Re: の無限の増殖は、Thunderbirdを通過すると一個のRe:だけになるから、Thunderbirdの所で防止できます。
Fwd:の場合は、Thunderbird は、Subject: Fwd: Fwd: ,,, Fwd: と増やしますが、他のメーラーは増やさないから、少々増えても問題なし。
[訂正]
http://en.wikipedia.org/wiki/List_of_email_subject_abbreviations#Standard_prefixes
Fwd: も、Standard Prefixのようです。FW:の記述で「Also written as "FWD: ", "Fwd: " or "Fw: ".」とありました。
Re:とは異なり、意味的に、複数あることは正常、ということかな。
[/訂正おわり]

前のコメントのような、しょうもないことを知っているのは、次のバグのおかげ。
https://bugzilla.mozilla.org/show_bug.cgi?id=778907
https://bugzilla.mozilla.org/show_bug.cgi?id=812923
メールをたくさん選択しただけでBug 778907が起こり、その後ドラッグをしようものなら、Bug 812923が起こって、悲惨な目に遭う。
それで、Bug 812923で、将来のためにと全部のメールのファイル名を生成するのは止めて、一個だけに戻した。
で、そのBug 812923の修正が触っているのが、メールのファイル名を生成するモジュールを呼ぶところで、
そのパッチのソースをみたら、一回しか呼ばない、は、呼ぶところの前でif(n>0)continu;、で行っていた。

let uniqueFileName = suggestUniqueFileName(subject.substr(0, 124), ".eml", fileNames);
で呼んでいるものが、(a)/(b)と異なるか、(a)/(b)だと、以下のようなことをしている。
var Re; if(SubjectにRe有り==true) Re="Re "; else Re="";
var SBJ = Re + subject.substr(0, 124-Re.length);
let uniqueFileName = suggestUniqueFileName(SBJ , ".eml", fileNames);

[追記]
全然違うコードで、
Dragは、SubjectにRe有りの真偽に関係なく、Re:をとったものを使って、 suggestUniqueFileNameを呼ぶが、
SaveAsは、SubjectにRe有り==trueだとRe:をくっつけて、 GenerateValidFilenameを呼ぶ、になっています。
ここまでくると、(a) Open⇒Save系も、(b) SaveAs系も、同じところを通るので、(a)も(b)も同じファイル名になるのでしょう。

結局は、全く同じことをしていて入り口が違うだけなのに、それぞれが、それぞれ用の、似たようなコードを独自に持っていてそれを使う、という、構造に原因がある問題。

SaveAs http://mxr.mozilla.org/comm-central/source/mail/base/content/mailCommands.js#342

Drag http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1415

ここまでわかったから、「Bug 1140323 ThreadPaneOnDragStart() should use same logic or code as SaveAsFile() for ".eml" file name generation」を開いておきました。
[/追記おわり]

原因は、msgMail3PaneWindow.jsのThreadPaneOnDragStart() で、
msgHdr.flagsのHasReのフラッグがオンの時に、頭にRe:をつけていないことだから
と同じことを、ThreadPaneOnDragStart()ですればOK。

omni.jar(omni.ja?)を.zipにリネームして解凍し、ThreadPaneOnDragStart()を書き換え、全部をomni.zipに圧縮し、omni.jarにリネーム、で、おしまい。

Re: だけのSubject:だと、上のコードの入れ方だと同じにならないし、長い時のカットのしかたも違いそうだし、気になるなら、好きなように書き換えればいい。

WADA さん、詳しい背景説明、ありがとうございます。

以前どこだったかで、Firefox から画像をドラッグ＆ドロップで保存するのと、右クリックから [名前を付けて画像を保存] で保存するのとで挙動に違いがある、といった話題がありましたが、Thunderbird でも似たような事情があるのですね。

【オフトピ】
Windows 環境で、Subject を
\/:*?"<>|
としたメッセージをつくり、eml ファイルとして保存すると、
（a）（b）（c）ともにファイル名は、
_ '()_.eml
となります。

Subject を
file:///C:\hoge
としたものは、
file _C _hoge.eml
となります。

ファイル名としての使用がシステムに制限された文字に対する処置には、他の文字に置き換えられるものと、単純に削除されるものの、２種類があるんですよね。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

そうなんですか。知りませんでした。
Dragの時に呼ばれる、suggestUniqueFileName()と、SaveAsの時に呼ばれる、GenerateValidFilename() の違いによって、削除するか置き換えかが異なる可能性も大。
長い時のカットのしかたも、Dragの方は三点リーダーみたいだけど、SaveAsは別のような感じがします。
同じルーチンを使えばいいものを...

偶然的通行人さんが、(c)だけ、と教えてくれなかったら、こんなに簡単にわからなかった。
SavesやOpenから辿る方は知らなかったから、モジュールを探し出すだけでも一苦労。
たまたま、ドラッグスタートの時のことは、パッチを見ていて、どのソースのどこのコードでどういう風にやっているか、知っていたんですよね。
で、そこだけ、と、わかりさえすれば、コード自体は複雑ではないから、もうこっちのもの(^^)、