メールの返信を書くと、本文の途中に半角スペースが挿入されるという問題がおきて困っています。
具体的には、受け取ったメールの返信で「あ」を改行せずに延々と打って送信すると、サーバーのメールボックス上の生のデータが以下のようになって

http://twitpic.com/88q3pe/full

これをThunderbirdで受信して開くと、以下のように、全角68文字毎に半角スペースが挿入されています。

http://twitpic.com/88q6qv/full

文字コードをUTF-8にすると、更に、右端の折り返しも半角スペースとして表示されてしまいます。

http://twitpic.com/88qbb3/full

これはあくまで、返信の時に起きます。新規にメールを作成したときは起きません。
過去の似たような事例のトピを見つけ、既に解決済みとなっているようですが、別の現象、なのでしょうか。
http://forums.mozillazine.jp/viewtopic.php?t=10416

　
＊質問・投稿する前に フォーラムの利用について を読んでその内容を理解した上で
　それに沿って投稿しましょう。
＊ご自分の利用環境として OS の種類、Thunderbird の正確なバージョンぐらいは書
　き添えましょう。
＊質問した後やアドバイスをもらった後には結果や経緯を必ず書くようにしましょう。
　
　
プレーンテキスト形式の返信メッセージを送信した際に起きている現象ですね。
当方では再現しません。
[環境：Windows 7 Professional SP1、Thunderbird 9.0.1 日本語版]

参照された以下のトピックにもありますが、mailnews.wraplength の値はどうなっていますか？
テキストメールの自動改行と、HTMLメールのレイアウト崩れ（不要なスペース挿入）についての報告
　
返信メッセージの送信でのみ起きている現象とのことですが、Thunderbird の送信済みメッセージのコ
ピー保存したものも同じですか？
どんな返信元のメッセージでも返信時は同様ですか？

念のため、Thunderbird のセーフモード起動、新規プロファイルの追加適用や再インストールでも再現
するか確認してみてください。
　

失礼しました。
環境は
Windows XP Home Edition SP3 日本語版
Thunderbird 9.0.1

アカウントの設定は
HTML形式でメッセージを編集する→チェック
返信時は元のメッセージを自動的に引用する→チェック
キャレットの初期状態→引用部の下
返信メッセージに自動的に署名を挿入する→チェック

返信を書くときの設定は
文字エンコーディング：ISO-2022-JP
送信形式：自動判定

mailnews.wraplengthの設定は72
・・・です。

複数の送信者からのメール（ISO-2022-JPのプレーンテキストのメール）に対して試してみましたが、同じ状況です。
受信したメールを表示した状態で「返信」をクリックして、
引用が青い縦線でマークされている状態でHTMLメールのエディタが開き、
メールの先頭に「あ」をひたすら改行せず書き連ね、そのまま送信するとこの現象が発生します。

返信ではなく、「新規作成」で同じように行った場合はこの現象が発生しません。
再インストール及びセーフモードも試してみましたが変化ありませんでした。

ちなみに、
返信するときに文字エンコーディングを「UTF-8」に変更して同じ操作をすると、
先に掲載した３枚目の画像のようになります。

すみません。忘れておりました。
新規プロファイルも試してみましたが変化ありませんでした。

「テキストメールの自動改行と、HTMLメールのレイアウト崩れ（不要なスペース挿入）についての報告」のトピックにあるように、mailnews.wraplength を0に設定してみたところ、自動改行しなくなり、更に半角スペースも挿入されました。
そのときのメールボックス上の生データと、Thunderbird上の表示は以下の通りです。

http://twitpic.com/88t9kr

　

上記の設定で再現しました。
　＃Thunderbird 上の下書き保存と送信済みメッセージのコピー保存および
　　自分宛に送受信にて確認しました。

「HTML 形式でメッセージを編集する」にチェックを入れない場合は、再現しませんでした。

プレーンテキスト形式の受信メッセージに返信する際に
１． HTML 形式で返信本文を編集するとそこに半角スペース（改行コード？）が挿入され、
２．送信時にプレーンテキスト形式に変換される際に、そのまま残る
という現象のように見受けます。

プレーンテキスト形式の返信メッセージを作成・送信することが常用ならば、「HTML 形式で
メッセージを編集する」にチェックを入れないようにしておけば、この問題は回避できること
になるかと思われます。
　

【余談】
このフォーラムでは投稿本文内にスクリーンショットを貼り付けることができます。
リンクアドレスを書くよりは、この方法を用いるほうがリンクを開く手間が省けて見やすいか
と思いますので、今後は以下のガイドを参照して利用してみてください。
　[参照] MozillaZine.jp : BBCode ガイド - 投稿文中に画像を表示する

　　[サンプル]
　　
　

ありがとうございます。
写真貼り付けて説明文を書いて送ったりする用にHTMLメールを時々使うのですが、この問題が解決するまではプレーンテキスト＋添付ファイルにした方がよさそうですね。

画像の件、失礼しました。
どこにアップロードするのかわからず、とりあえずリンクにしてしまっていました。
今後気をつけます。

この問題にだいぶ長い間悩まされている者です。。
現在の環境は、Thunderbird9.0/Windows 7 Professionalです。



HTML形式メッセージをデフォルトで利用しております。最近ですと、むしろ仕事上でのやり取りではHTMLメールを使う人の方が多いため、引用返信で相手のメールを崩してしまわないよう自分もHTMLで書いています。

個人的には適宜改行を入れるよりも、段落以外では改行を入れずに、相手のウィンドウサイズに合わせて改行されるように書きたいと思ってます（これは個人的な嗜好です）。なので、この半角スペース問題が非常に悩みのタネです。

何かHTML形式でうまい解決策を講じられている方はいませんでしょうか？

私も同じ問題で悩み，ここ2日ほどネットで調べたところ，解決策に近いものが見つかりましたので，報告します：

http://dayinthelife.at.webry.info/200706/article_1.html

にありました．Thunderbird で，HTMLメールを作成する際，本文ではなく，整形済み〈pre〉として記入します．これで，
改行による空白が表示されることがなくなります．

ただし，995バイト目，或いは，987バイト目には必ず改行が挿入されて文字化けが生じます．これがまだ解決していません．
不完全な知識ですみませんが，私の認識はここまでです．メーラーのせいか，メールサーバーのせいかは判りません．

ここに書き込むのは初めてなので，何か間違っていたらすみません．

_________________
Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0

これだけきちんと提示してもらえると、いいですね。

HTMLモードでのメールの作成で、
新規作成だと、多分「自動判定」でうまいことtext/htmlあるいはmultipart/alternative{text/plain+text/html}で送られ、見る側が、text/htmlパートを見るので、text/plainパートにおけBug 653342の現象が隠されるが、
テキストメールへの返信だと、「自動判定」によるtext/htmlからtext/plainへのダウングレードによって、text/plainのメールとして送られるので、Bug 653342の現象が常に見えることになり、
また、text/plainメールあるいはパートにおいて、
iso-2022-jpの場合には、Tbではformat=flowedは内部的に使わないようにしてあるので、format=flowedで送られることはないが、
utf-8の場合には、format=flowedを使用するか否かのprefs.jsの設定(デフォールトは有効)によって、format=flowedで送られ、メール作成時のformat=flowed,DelSp=Yesはまだサポートしていないので、format=flowedによって挿入されたスペースも、表にでてくる、
ということでしょう。
<pre>で回避できた、というのは、
<pre>だと、HTMLにおける、Tbによる80文字弱ごとの改行の挿入が起こらず、
<pre>内の各行の長さが、mailnews.wraplengthを超えない場合、かつ、メールの行長制限の1000バイトを越えない場合には、テキストコンバージョン後のtext/plainパートにおける途中の改行が発生しない、ということだと思います。

ユーザーが意図的に改行なしの極端に長いテキストをメールの作成画面にペーストした時に起こる様々な現象・問題の多くは、Bug 653342の中で触れられ、関連する多くのバグがポイントされています。
HTMLソースの整形のため、あるいは、Tbの内部的なHTMLの一行の長さ制限(80文字弱)のために、HTMLタグの中の属性値の間に改行を入れてしまう、という問題も、ちゃんと含まれています。
Bug 653342 は、問題を引き起こす「HTMLメールの中での改行の挿入」を止め、メールの行長制限に引っかかる場合にはBase64で送る、ということで問題を解決しようとしています。
HTML部分における改行の挿入がなければ、HTML⇒テキスト変換時の、HTMLの「改行==
空白」の適用もなくなり、text/plainパートの余分な挿入された空白もおこらないことになります。
テキストモードのメール作成における「改行の挿入」に関連する問題は、このバグの守備範囲外ですから、混同しないでください。

明白なTbのバグであり、あのバグでは実に数多くのバグの現象を見られるのですが、
テキストメールで済むのにわざわざHTMLで作成し、遭遇しなくても済むはずの「自動判定」の問題をわざわざ経験し、
元々が、テキストを80文字以内で改行して送る、という電子メールであることや、メールの送信であって単なるテキストファイルではなくて、行長には制限がある、というようなことを無視して、
mailnews.wraplength=0を設定し、改行無しの長～いテキストを貼り付けて、あのバグの問題をわざわざ経験する、
という人にも問題あり、
という問題...
(mailnews.wraplength=0は、メールの改行には自分が責任を持つ、という宣言...、だと私は思う)

HTMLで作成したものがtext/htmlで送られさえすれば、大きな問題になりにくいと思うのですが...

シグネチャーを使っているのならば、HTMLシグネチャーに<B></B>を入れ、「後で送信」を行い、「ローカルフォルダ」の「Outbox(未送信メール、かな?)」に作られたメールのソースを見ると、text/htmlメールか、text/htmlパートが作られているはずです。
これをThunderbirdで表示した時に、余計な改行・空白、といった現象が表にでてきますか？
他のメーラーだと、HTMLでの改行==空白、あるいは、HTMLでの連続するスペース==一つの空白、がきちんと適用されて、余計な空白は見えてしまうかもしれません。

なお、シグネチャーを使っていない場合に「HTMLシグネチャーに<B></B>」をやると、余計な"-- "がでてくるので、その場合には、アドレス帳で、各コンタクトに「HTMLメール」を設定し、初めて送る場合でもアドレス帳に入れてから、というような対策が必要になってきます。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

HTMLモードで作成した時の、text/htmlからテキストコンバーターによって作りだされるtext/plainの場合、あるいは、HTMLモードで作成画面を開きFormat=Plain Textに変えた時の、内部的にはtext/htmlからテキストコンバーターによって作りだされるはずのtext/plainの場合には、追加された「HTMLの改行=空白、による空白」のせいもあってか、SMTPの行長制限の1000バイトのところでの分割で、ちゃんとiso-2022-jpのエスケープシーケンスを含んだ分割がなされ、エスケープシーケンスを含む3バイトコードの途中での分割は、Bug　653342のテストの中では、見られなかったのだが...

1バイトコードや2バイトコードが混じると、運が悪いとエスケープシーケンスの所で分割が起こる？
3バイトのエスケープシーケンスではなく、3バイト文字の中での分割で文字化け？
utf-8だと、3バイトコードの分割は避けられない? (でも、これだと、そう頻繁には引き起こせない...)

最初からテキストモードでのメール作成、
iso-2022-jpやutf-8などの、3バイト以上の文字コードやエスケープシーケンスがあるcharset、
mailnews.wraplength=0かSMTPによるメールの行長制限の1000よりもかなり大きい値、
SMTPによるメールの行長制限=1000バイトを無視した、極端に長い改行なしのテキストのペースト、
の合わせ技によるものではないですか？

HTMLモードでのメールの作成の場合、text/htmlパートでの話ですか？ text/plainパートでの話ですか?

HTMLモードでのメール作成、
iso-2022-jp(3バイトのエスケープシーケンスがあるcharset)、
mailnews.wraplength=0かSMTPによるメールの行長制限の1000よりもかなり大きい値、
SMTPによるメールの行長制限=1000バイトを無視した、極端に長い改行なしのテキストのペースト、
<pre> で、HTMLにおける「80文字弱での改行(+整形のためのスペース)の挿入」を抑制
の時には、テキストモードと同じく、エスケープシーケンスや文字コードの長さに関わらず、1000バイトのところに改行が入ってしまう、ということかな？

だとすると、折角、HTMLモードでの作成で、エスケープシーケンスの途中での行分割のバグを避けられたのに、わざわざ<pre>でそのバグを復活させた...、
HTMLを全部<pre>で書いていて、しかも、「自動検出」のせいで、HTMLで書いたのにtext/plainで送られる、というHTML、ならば、端からテキストモード、となんら変わらない...
どうせバグに遭遇するのならば、余計なことを何もしないで遭遇するほうが、まだマシ...

iso-2022-jpだと、3バイトのエスケープシーケンスが数多く出現し、そこで分割される確率がかなり高くなります。
utf-8でも、「後で送信」で作られたメールのソースで、3バイト文字のところでの分割が、数多くみられますか？
日本語だと3バイトコードが多くて、iso-2022-jp程ではないにしろ、結構な高確率で起こるかな？
「自動検出」ではなく「Format=Rich Text(HTML) and Plain Textを明示的に指定」すると、multipart/alternative{text/plain+text/html}で作成されます。
text/plainパートでもtext/htmlパートでも、1000バイト弱のところの、3バイトコードの途中での分割が見られます？

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

これを阻害するものは、HTMLのメール作成において、現在、大まかに、3つあります。
(1) <P>の中のテキストで改行すると、HTMLメールのエディターはWYSIWYGだ、と言って、<BR>を挿入してしまう。
そして「Soft-Line-Break」はサポートしてくれない。
(2) それで、改行なして<P>に長いテキストを入れると、
(2-1) HTMLソースの整形(インデント)のために、行頭に複数の空白を挿入、
(2-2) Unicodeの80文字弱、の、HTMLソースの一行あたりの文字数のハードコードされた内部的な制限、による、改行の挿入、
(注：mailnews.wraplengthが指定している(デフォールト=72「バイト」)、元来の伝統的なメールの行幅の制限、の、80「バイト」、ではない)
を行ってしまう。
(3) 「Format=自動検出」によって、運が良ければtext/htmlで送られるが、シンプルなHTMLメールだと(imgの挿入程度ではダメ)、大抵は、text/htmlのデータをテキスト変換したデータの、text/plainメールとして送られてしまう。

改行を含んだ長いテキストを貼り付けた時に、<BR>にするか改行のままにするかは、ちょっと不明です。

(3)で、text/htmlで送られさえすれば、(2)があったとしても、<pre>などの特殊なことをしなければ、<HTMLの仕様上、<P>の中の「改行+連続する空白」は「一つの空白と同等」なので、空白が一つ入るだけであり、「CJK文字とCJK文字の間の改行は、空白でなく除去」という実装のメーラーやブラウザーもありますから、(2)が大きな問題になるケースは減るかもしれません。
Thunderbirdでは、うまいこと、なんらかのバグで余計に挿入された行末か行頭の空白を除去するロジック、が働くのか、改行なしの連続する長いひらがな、であっても、text/htmlの場合には、連続して表示されているように見えます。
改行の挿入も、空白だけでなく句読点や区切り記号のところに入れる、連続する数字の間にはいれない、英字の長い文字列ではは英単語の最長の40文字程度には改行を入れない、などの、一種の禁則処理も、十分とはいえないまでも、働きます。
「、」や「。」の後ろの空白、ならば、目立つことはないし何の支障もないはずですから、貼り付ける長いテキストの「、」や「。」の後ろに空白か改行を入れておく、あたりで、改善されるかもしれません。

そして、(3)のバイパスには、シグネチャーを使っている場合には「HTMLシグネチャーに<B></B>を入れる」という至極単純明快なものが存在しますし、そうでなくても、HTMLメール作成時の文字色の設定を#FFFFFEにするとか背景色を#000001にするとか、実害が全くない範囲で、簡単に、「自動検出」が自動的にtext/plainにしてしまうのを邪魔する、というものが存在します。
HTMLで作成したのにtext/plainで送られる、ということが、問題に大きく関わっているのならば、まず、(3)が起こらないようにして、試してみてください。

なお、HTMLエディターの問題なので、UTF-8で作り、Format=Rich Text(HTML)でtext/htmlだけにし、「後で送信」でOutbox(未送信メール)にそのメールだけを入れ、Outboxのファイル(Unsent Messages)を、UTF-8サポートし、勝手にUTF-8用のBOMを書かないテキストエディターで編集し、HTMLソース部分を書き換え、OutboxのRepair Folder(索引の再構築 or フォルダの修復)を行った後、「未送信メッセージを送信」、という手段は、いつでも使えます。
文だと長いですが、要は、Tbが作り出すHTMLソースを手で書き換えてしまう、です。
端からHTML本文部分はTbでは書かず、使いやすいHTMLエディターなどでテキストファイルにHTMLを作り、テキストエディターでTbのメールデータにHTMLを貼り付け、の方が楽かもしれないですね。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

text/htmlパートでの、HTMLソース上の、整形のための行頭の空白によるインデント＋80文字弱の文字数制限による「改行＋複数の空白の挿入)」＝＝「一つの空白の挿入と同等」　⇒　日本語文字間に挿入された空白、は、Thunderbird 17でも、ちゃんと見られますね。
プロポーショナルフォントで、「あ」と「い」と「う」とかで文字幅が結構違い、ウィンドウ幅で折り返される位置が異なり、また、スペースの幅が狭いフォントなので、挿入された空白が、認識しづらかった(^^;
text/plainパートだと、等幅フォントで表示されて、挿入された空白が綺麗に斜めに並ぶので、すぐにわかるんですけどね。

Bug 653342に提出されているパッチで、一行がSMTPの行長制限(1000バイト)を越える時には、確実に、改行の挿入などは行わず、Base64で送るようになるのですが、
HTMLエディターの一行の文字数制限の80文字弱(76文字+CR+LFあたり)を超えただけでも、改行の挿入なし＋Base64で送信、だったっけ？

もしそうでないと、UTF-8の3バイト文字 x 300文字程度の長さの改行無しのテキストの時に、3～4箇所で、HTMLソース上で挿入された改行による空白、は、避けられないことになる...
でも、HTMLソース上で挿入された改行による日本語文字間の空白、を常に避けるには、一行たかだか100文字程度であっても、Base64で送らないといけなくなる...
それだったら、空白が単語の区切りのヨーロッパ諸国の言語しか考慮していない、HTMLエディターの、カストマイズできない、80文字での強制改行とか、整形(インデント)のための行頭への空白の強制挿入とかを止めるのが先であるべき...
あるいは、text/htmlでのformat=flowed,DelSp=YesをきちんとRFCで定義しformat=flowed,DelSp=YesでHTMLメールを作成し、HTMLに挿入された「改行(+連続する空白)」とかを除去」を、多くのメーラーで実装しないといけない...

Bug 653342のパッチの仕様をチェックしておかないといけないですね。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

iso-2022-jpのHTMLメールの作成で、<pre>に、SMTPの行長制限の1000バイトを超える、改行無しの日本語文字列をペーストすると、
テキストモードでのメールの作成の時と同様に、texp/htmlパートであっても、3バイトのエスケープシーケンスの間に改行が挿入されてデータが壊される、という現象を確認できました。
このケースは、HTMLのソース上の改行の挿入を一切止めてBase64で送る、というパッチで解決するはずです。
パッチが適用されれば、テキストモードのメール作成での、SMTPの行長制限の1000バイトを越えた時にエスケープシーケンスの間に改行が挿入されてデータが壊される、という問題は、HTMLモードでメールを作成して<pre>を使用する、という方法でバイパスできることになりますね。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

HTMLメールの作成で、<pre>に、SMTPの行長制限の1000バイトを超える改行無しの日本語文字列をペースト、でメールを送ると、<pre>だから、無茶苦茶長い行になって、読めた代物じゃなくて、送られた方はいい迷惑...
と思っていたが、3バイト文字を含まないShift_JISで作成し、text/plainとtext/htmlの両方を送らせ、ついでにquoted-printableで送らせようとmail.strictly_mime=trueで送り、View/Message Body As/Plain Textでも見てみて、納得。


「自動判定」でtext/plainメールとして送られる問題を利用していたんですね。


Tb 17(en-US、on Win-XP)で、全部「あ」でのテストですが、text/htmlパートは、先に、SMTPの行長制限の1000バイトのところで改行が挿入され、3バイト文字がないのでデータ破壊はおこらず、mail.strictly_mime=trueによってquoted-printableで送られ、
表示では、<pre>の中だから、挿入された改行のところは、<pre>の中の改行であると「きちんと」認識される、という状況になります。

一方、text/plainパートは、どういうわけかCRとLFが混在する状態になったのか、テキストのコピー＆ペーストで、文字列の最後の改行をコピーし忘れて、改行で終わらないメールデータになったのか、うまいことBase64で送られ、テキストコンバージョンは、SMTPの行長制限の1000バイトのところでの改行が挿入される前の、<pre>一行の長い改行無しテキスト</pre>に対して行われるので、運良く「一行の長い改行無しテキスト」がBase64で送られる、というような結果になりました。

でも、HTMLでShift_JISで<pre>で「自動判定」でtext/plainメールとして送られる問題を利用、ならば、テキストモードで作成し、mailnews.wraplength=0にし、SMTPの行長制限の1000バイトのところでの3バイトコードの中への改行の挿入の問題を、3バイトコードが無いShift_JISで逃げ、Base64で送らせるために最後の改行なしとかCRとLFを混在させるとかし、念のためにmail.strictly_mime=trueを指定しておくのと、なんら変わらない...

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36