Pythonのドキュメントにこういうのが書いてあったとは．．．

いろいろMUA（PGPやGnuPGとか途中で符号化するツールも含めて）によって行頭の「From 」以降のフォーマットや扱いが違うんですが、ほとんどのMUAの都合で「>」を付加すると思っていても良いのでしょう。
「>」を取り除いて元に戻すのはやらないという「決め」みたいです。（元がどうだか判断出来ないから、らしい）


似たような話題が6年も前に有ったのを見つけました。これは移行時のメールの区切りに失敗したという話題のときのオフトピですね。
http://forums.mozillazine.jp/viewtopic.php?t=579&start=0&postdays=0&postorder=asc&highlight=&sid=b5f64807b5c226af6c29829ae9cb82b5

「From 」の場合は目で見えるから話題になりますが、改行コードの変換のような「正規化」という処理が送信時にも受信時にも入ります。

おそらく誰も反論はしません、ご自由にどうぞ。

MS Outlook系や他のMUAでmbox形式で保存していない（例えば1通1ファイルとか）MUAではこういう問題は発生しないはずです。

kiyo4_k さん、meeyar さん、ご教示ありがとうございます。

ぼくにとっても、たいへん勉強になりました。
（参考）
・メールのデータ保存フォーマット mbox MH Maildir

古くから使われてきた代表的なメールデータ保存フォーマットである mbox 形式に関わっていたことだったのですね。
Thunderbird の保存フォーマットは、mbox 形式をベースにした改良型 mbox 形式とでもいうべきフォーマットを採用しているためこの影響を受けるし、mbox 形式（とそのアレンジ版）を採用している他のメールクライアントもおおむね同様であると......。

逆にいえば、mbox 形式ではない保存フォーマットを採用しているメールクライアントや Web メールなどでは、この現象は起こらないということなんでしょうね。
例えば、Microsoft 社の独自形式を採用している Outlook Express 、MH 形式を採用している Sylpheed などのメールクライアントでは「>From」問題は起こらないし、それぞれ独自フォーマットを使う Web メールなどでも同様ってことでしょうか。
（各形式には一長一短あるので、一概にどれがベストとはいえませんが...。）

個人的には、「>From」問題は、Thunderbird が採用しているメールデータ保存フォーマットの mbox 形式に由来する "仕様" 的な制限事項、というふうに理解しました。

バグ登録しました。英語、疲れます。
「全部が署名のメッセージを保存後、Ctrl + a のあとにコピペすると改行がスペースに変換されます」
https://bugzilla.mozilla.org/show_bug.cgi?id=789387

mbox 形式と仕様と不具合について

これは「mbox 形式と仕様と不具合について」の話です。興味のない人は無視してください。

あるところに ふたりの男性が いました。ふたりとも普段は温厚な せいかくです。しかし、ラーメン屋でラーメンを食べていたとき、男性のうち ひとりが急に怒り出しました。もうひとりの男性は、普段温厚な人が急に おこっていたので驚きました。実は、その おこっていた男性の職業はラーメン屋だったのです。だから、同業他社のラーメンが非常に手抜きで、「客をばかにしたような味」だったため、どうしても許せなかったのです。その男性にとって、ラーメンは「おこる価値のあるもの」であり、その人の人生そのものでもあったのです。

さて、本題に入ります。私は既に説明したとおり、とあるメーカーの開発者です。普段は温厚です。しかし、部下や同僚、場合によっては上司にさえ、おこらなければいけないときがあります。それは「客をばかにしたような仕様」だったときです。

mbox 形式の仕様は客をばかにしています。既に説明されている通り、mbox 形式の「メール区切り記号」は行頭の「From 」です。これは人間が偶然に記述する可能性のある文字列のため、絶対に「メール区切り記号」として使用しては いけません。仮に、何らかのメール区切り記号を用意したいのであれば、それは「<@k-s_j\fo^e~w@>」のような、「人間が絶対に入力しない文字列」にしなければいけません。

100歩譲って、世の中に「客をばかにしたような仕様」が存在したとします。しかし、開発者は その仕様を極力 回避するべきです。自分で新しい仕様を用意するなり、不具合のある仕様を自分で改良して新しい仕様を策定するなり、何らかの回避策を講じるべきです。不具合が発生して、客が困っているにもかかわらず、「仕様です」で言い逃れすることは、開発者として禁止されています。なぜなら、要求定義の最優先事項は「客にとって妥当であること」だからです。

もちろん、例外は存在します。予算の都合上、製品の品質を落とさなければいけない場合も存在します。しかし、それは「商品の価格を下げるため」、すなわち「客の支払いコストを下げるため」でもあるのです。顧客の存在を放置した状態での「仕様優位主義」など、絶対に許されるべきではありません。

開発の世界では、バグをいくつかの種類に区別しています。1つは「仕様どおりに製品が動いていないこと」を示す「コード不具合」です。もう1つは、仕様が間違っていたために発生した「仕様不具合」です。どちらもバグとして計上します。「仕様です」が言い訳になることは、現場では ありえません。仕様が「顧客を満足させ、製品として妥当であること」を満たさない限り、バグと指摘されます。なぜなら、顧客こそが第一義の優先事項であり、それより優先すべきことは存在しないからです。

Thunderbird というメーラーは、mbox 形式という仕様に執着しました。その結果、不具合「From に > が付与される」を発生させてしまいました。これは仕様ですか? いいえ、これは「仕様不具合」です。なぜなら、Thunderbird は mbox 形式以外の手段を提供することができたからです。実際、同業他社のメーラーは mbox 形式で提供していません。そして、不具合も回避できています。mbox 形式が理想的な仕様でないことを示す客観的証拠です。

私は今回の「仕様不具合」を Thunderbird 開発者に報告しません。修正される可能性が極めて低いからです。しかし、RFC も mbox 形式も、本来は守る必要のない仕様です。人間は過去の間違った仕様を修正して、改良して、情報技術を進化させる能力を持っています。これを読んでいる人には、どうか そのことを忘れないでほしいのです。

zz54547tzさんの個人的な意見、役目柄無視せず読ませていただきました。
（ここは自分の意見の垂れ流しをする場所では無いので「興味のない人は無視してください」と断り書きを冒頭に置くような記事は投稿しないでください　<-- ここだけadminとしての注意です）

ここでは1メール1ファイルの形式とmbox形式の相違点やそれぞれの利点を話し合う気は無いですが、
MUAに大事なことは互換性と接続性だと考えています。守る必要の無いRFCを守らなくても問題が無いのはマイクロソフト製のMUAだけかもしれません。Windowsユーザだけの間で接続性が確保されれば良いという考えも有ったようですが、元々は無知からの間違った実装だったものが数で押し切ってしまった（押し切ることが出来た）というのが現状のようです。

ジャンケンの後出しはルール違反だと叫んでも、この場合は数が多ければ勝てるんですよ。興味も知識も無い人にはこれが標準になってしまいます。
また、間違ったものでも勝手に修正してしまうと互換性や接続性が失われますからMUAの場合はこれが致命的です。これはRFCについても同じですが、ThunderbirdもRFCを無視しているところは有ります。
MUAのデータ（保存メール）の方は移行など他のMUAとの間でやりとりを考えなければ、どうでも良い話しですし、一般のユーザーにはあまり関係ない話しですけどね。

メールの区切りに「From 」を使用すると決めたときも、おそらく本文中に極東の島国の引用の書き方などは想定していなかったんでしょう。しかも、その頃は日本ではインターネット自体が一般に普及していませんでした。今も極東の島国だけの事情はなかなか反映どころか理解もしてくれません。
今回の問題となっている先頭に「-- 」が書かれていたメールも、言ってみれば利用者の無知かミスが起因していることであり、「-- 」の性質を知っている人や海外ではそういう書き方や長い署名を付けませんからバグを発見出来なかったんでしょうね。そういう意味では製品テストは甘いと感じます。

ユーザ自身の不勉強、製品の選択のミス、無知、思い込み等から間違ったものや異種のものを基準にして、違うからと言ってケチを付けるのは誰も同じですし、MUAに限った話しでも無いですし、このフォーラムでもそういう人は多いです。

でも、文章では「ラーメン屋」と「客」という言葉を使って考え方を表現していますが、商品に対して対価を支払うということで生じる考え方は、当てはまるかどうかは疑問です。
対価を支払うユーザはいません。Mozilla製品を作るのはユーザだという考え方が基本なのかもしれません。

※Bugzillaへの投稿と、質問とは少し離れた投稿が有ったということで解決済みクローズを考えていますが、しばらく時間を置いてクローズします。