メールで作成した文章のソースコードが文字化けします。

文字化けというよりは仕様では？

ソースですからそのまま表示、というポリシーではないかと思います。

本文の上の方に、

Content-Transfer-Encoding: 7bit

となっているときは、文字コードそのまま表示（文字コードそのままなので、人には文字としては認識出来ない）。

Content-Transfer-Encoding: base64

のときは、base64 でエンコードされたものをそのまま表示。

Content-Transfer-Encoding: quoted-printable

のとき（ところどころ半角文字が混じったテキスト）は、ブロックごとに文字コードそのまま表示

となってませんか？

いずれにしろ文字コードをそのまま16進数で表示しているだけですので、見ても普通のテキストには見えません。文字化けといえば文字化けですが、意図せざる（バグ）によるものではなくて、仕様でこうしているのではないかと思います。指定された通りになっているかを見るにはこの方が正確です。

テキストをテキストとしてみたいなら、何もソースで見ることはありません。

Tiger-the-cat による書き込み:

当方、不定期でメルマガの仕事をしており、先方（ウインドウズ）からは、通常の送信と別に

ソースコードを送るようにと言われております。

どちらかが（両方？）がソースコードの意味を取り違えているのでは？

単に、「本文のテキスト」という意味じゃないでしょうかね。

厳密にはメールのソースそのものを見てみないと判別はできませんが、恐らく純正のメールアプリは標準テキストで作成し、ThunderbirdはHTML形式で作成する設定になっているのだと思います。（これらは環境設定で切り換えることができます。）

純正メールは、標準テキストですからE-mailの標準であるJISコードでメール（＝ソース）を作成します。したがって、UTF-8コードがデフォルトであるMacOSの中で何も細工をせずにJISコードのテキストを表示させようとすれば文字化けしているように見えます。

一方、ThunderbirdのHTML形式のメールは、ヘッダー部分に文字コードを明示しておけばそれ以降はJISコードとは異なるコードで記述しても問題ありませんので、ThunderbirdのデフォルトであるUTF-8コードのメールを作成します。純正メールと同様にメールソースを表示させた場合、最初からUTF-8コードであればOS内で普通に表示できるので文字化けのような現象は発生しないのでしょう。

以上のような理由から現在の状況は確かに仕様通りなのですが、お仕事でメルマガを作成しているなら「気にしない」では済まされない面があります。

それというのも、HTML形式の場合は普通にメールを表示させた際に目に見えるテキストの他に色々なコードを埋め込むことができるので、場合によっては悪意を持って不正なコードを混入させる事件があったりします。したがって、メール本文がHTML形式であるか否かは重要な問題で、メルマガによってはHTML形式のメールを拒否して標準テキスト形式のメールで送るような設定が読者側で選択できるようになっている場合もあります。つまり、メール本文をHTML形式とするか否かはメール作成業務を発注する側が指定する可能性がありますので、その点には注意が必要です。