今頃になってですが、どぉもIE9Betaを入れてからWindowsメールの冒頭に?マークが付くので、おかしいなと思い
調べたところ、どぉやらエンコードの問題のようですね＾＾；
Windows Vista の Windows メールや Windows Vista (Windows 7 も含む)の Windows Live メールで
メールを送信するとメール本文の頭に「?」が勝手に入るので＾＾；
でも、私。待ってられない（笑 
そこでメールで何度かテストした結果
・１行目だけ？が付く
・２行目からは問題ない
・ブラウザーメールには影響がない
・エンコードをUnicode(UTF-8)なら問題ない。ただしUnicode(UTF-8)をサポートしていないメーラーが受け取ったら化け文字になる。
ならば（・・？
手っ取り早く逃げるなら、２行目以降は付かないので１行目だけ可愛く絵文字で逃げる（ぇ

?*・゜゜・*:.。..。.:*・*:゜・*:.。. .。.:*・゜゜・**・゜゜・*:.。..。.:*・*:゜・*:.。. .。.:*・゜゜・**・゜゜・*:.。..。.:*?　←１行目
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←２行目
　　こんにちは＾＾　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←３行目

↑こんなのか

??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??←１行目
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←２行目
　　こんにちは＾＾　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←３行目

↑こんなので逃げる（ぇ
例：??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??*:;;;:*??
ピンクの部分が勝手に追加されるわけですから＾＾；ごまかすようにね（笑
この後に文字を書けば問題クリア！…そんなんでいいのか！？

この問題を本質的にクリアするならIE9Betaをアンインストールするしかないですね＾＾；

それか、条件付きでWindowsメールの[ツール]の[オプション]から[送信]のエンコードの設定を変えればいいんじゃないの？って思いましてね＾＾；

この場合、メールを受け取る相手もUnicode(UTF-8)に対応してなければいけません＾＾；
まぁこれも手段の一つでしょうか＾＾；

この問題はMicrosoft様の開発チームがIE9をリリースするまでは直らない問題ですので＾＾；
これらの問題解決にConnect の IE9 Public Feeback Program に参加して「○人のユーザーがこのバグを再現できます」の「私もです」の部分をクリックすると、この現象を大勢の人が再現されて、困っていることが Microsoft へ伝わるとより早く修正してくれる場合があります。




?*・゜゜・*:.。..。.:*・*:゜・*:.。. .。.:*・゜゜・**・゜゜・*:.。..。.:*・*:゜・*:.。. .。.:*・゜゜・**・゜゜・*:.。..。.:*?

ここから下は自己責任において参考までに＾＾


ただし、これも相手やメールサーバーが対応しているかで…

選択としましてはBase64とQuoted-printableがありますよね？
標準だと「なし」になっています。


7bitがおすすめですが、日本語なのであえて8bit設定。（笑
メールサーバーが8bit対応してなければ7bitにしてね＾＾

少し説明しますと＾＾；
メールのSMTPプロトコルで、8bitのデータ（バイナリデータや日本語のテキスト等）の送信は保証されないことがあるんです。
（データが欠落することがある）
ですので、7bitのデータ（半角の英数記号のASCII。16進数で0x00～0x7Fの範囲）に変換して送ります。
その昔。メールに予想外の日本語が無かった時代に、ASCIIの送信しか想定されていなかったためです。

最近は8bitでそのままエンコードされることも多いようですが、万一にもエンコードされない場合に日本語だと化け文字の嵐で意味不明になるので、7bitへのエンコードの必要性はまだまだ無くなりませんね。

ちなみに…Base64とQuoted-printableの違いについて

Base64：
主に添付ファイルを変換します。Winでは最も一般的です。
元のデータの6bitを0～63の数字としてA～Za～z0～9+/の64文字で置き換えます。
元のデータが8bitと6bitの最小公倍数である24bitで割り切れない場合、6bitに足りないbitには0を代入して変換し、変換後の文字列の最後には「=」を１つないし２つ付け足して割り切れるbit数にします。
変換前よりデータサイズが一律33%大きくなります。
ですから8bit送信のFTPやHTTPの方が効率はよいわけです。

Quoted-printable：
Base64とともにMIMEで規定されたエンコードです。
「=」以外のASCII文字とスペース、タブ、改行。その他は8bitごとに「=nn」(nnは16進数の文字コードの大文字で表記）という変換をします。
たとえば「=」は =3D になります。
１行が76文字を超える場合は「=」を行末に入れて改行されます。
特殊文字（ウムラウト、逆さ？、アクセント付き文字等）は8bitデータなので、ときどき現れるその文字だけ変換するのに効率がよく、
アルファベット部分はデコードしなくても読めるのが利点です。
8bit部分はデータサイズが２倍位～３倍？になるので、8bitばかりのバイナリデータや日本語等のエンコードには全然向きません。