メールに添付したファイルの拡張子が欠ける

日本語もしくは長いファイル名の添付ファイルを送信してませんか。
その場合、WindowsのMicrosoft OutlookやOutlook Expressでは、
RFC2231の規約に対応していない為、ATT00〜と言う名前に変更されたりするみたいです。
添付ファイル名を半角英数字で短めにしたらどうでしょう。

Mail.app側の送信済みメールとWindows側の受信メールのソースを表示し、添付ファイル名の部分がどのようにエンコードされているかを比較してみると、手がかりになるかもしれません。
なお、ファイル名のエンコード部分は、
Content-Transfer-Encoding: base64
Content-Type: xxxx/xxxx;
name==?ISO-2022-JP?B?「英数字の羅列」?=
Content-Disposition: inline;
filename*=ISO-2022-JP'「%を含む英数字の羅列」
のように表示されるはずです。

すみません、タグを書いたのですが表示されないんですね。
全角で書きます。Outlook Expressで本文末に表示されるのは、
＜P＞＜HR＞＜／P＞
でした。
ファイル名は仕事の都合上どうしても日本語で表記しないといけないのですが、
OSX10.3ではこんなことは無かったのです。
OSX10.4にしてから起こるようになった現象です。
どこかに設定があるのでしょうか。

ありがとうございます。
ソースをみてみましたが、自分には難しくて。。
WindowsではThunderbirdを使っています。これは送るファイルすべてを
ATT000〜というファイル名に換えてしまうという仰天のバグがあったのですが、
プラグインだかを組み込むと直りました。
OSXのMailは気に入っているので、乗り換えたくは無いのですが、
MACの他のメーラーではどうなんでしょうか。

メッセージのフォーマットを「標準テキスト」にしても同様に化けるのでしょうか？

ファイルネームのところは確かに変ですね。
この違いは何なのでしょうか？
正しい方↓
filename*=ISO-2022-JP''%1B%24B4%5D0f%3Fe8M%1B%28B%5F%1B%24B%25%28%25s%25H%25i%25s%259%1B%28B.jpg
.jpgのgが欠けた方（駄目な方）↓
filename="=?iso-2022-jp?B?GyRCNF0wZj9lOE0bKEJfGyRCJSglcyVIJWklcyU5GyhCLmpw?="
後でもっとじっくり比べてみます。

そうなんです。
メッセージ作成のフォーマットは標準テキスト にして、
転送や返信の時も標準テキストしか使わないようにしているのですが、、
しかも、常にWindows対応の添付ファイルを送信にチェックを入れているのにぃ〜。

LZH圧縮をして、圧縮ファイル名を半角英数字にされたらどうですか。
http://www.fan.gr.jp/%7Esakai/lha.php

Mail.appは、filenameのほうのエンコードはRFC2231形式（正しい方のエンコード）になるのが正常です。ダメな方はBase64エンコードされていますので、これがまず変です。filenameではなくnameフィールドならわかるのですが。
私はTigerからMail.appを使い始めていますが、送った添付ファイルのfilenameはすべてRFC2231形式になっており、Base64になってしまったものはありません。
ダメなほうのファイル名はデコードすると「丸井水戸_エントランス.jpg」になりますが、試しにこのファイル名の添付ファイルを自分宛に送信してみました。結果は全く問題ありません。
Content-Transfer-Encoding: base64
Content-Type: image/jpeg;
x-unix-mode=0644;
name==?ISO-2022-JP?B?GyRCNF0wZj9lOE0bKEJfGyRCJSglcyVIJWklcyU5GyhCLmpw?=
=?ISO-2022-JP?B?Zw==?=
Content-Disposition: inline;
filename*=ISO-2022-JP''%1B%24B4%5D0f%3Fe8M%1B%28B%5F%1B%24B%25%28%25s%25H%25i%25s%259%1B%28B.jpg
となります。気になるのは、nameフィールドが２行になっていて、masssさんが書かれたfilenameと１行目は一致していることです。Winのメーラは多くがRFC2231形式のfilenameを理解出来ず、nameフィールドの方をファイル名としてしまうのですが、２行になった場合におかしくなるようにも思えます。（nameフィールドがBase64エンコード方式なったのが10.4.7からです。10.4.6まではiso-2022-jpエンコードだけでした。）

検証してくださってありがとうございます。
僕も自分のWindowsに送信して検証していますが、お客さんと同じ症状は出ないので、
相手方のサーバーに問題があったりするのでしょうか。
ぽん太さんのおっしゃるように、圧縮して送れれば良いのですが、
圧縮したファイルだと相手方のOutlookが受け付けてくれなかったりするので、出来るだけ避けているような状態です。
ソースコード、僕には難しくてわからないのですが、この夏休みに解析してみたいと思います〜。

みなさま、
いろいろとありがとうございます。
検証してみましたがソースコードに違いがあるとしても、根本的に解決にはならなそうなので、違うメールソフトを試してみようかと思っています。
試しにOSX版のThunderbirdでやってみました。
結果は、添付ファイルが全部ATT00〜〜というファイル名になり、これに対する
パッチはどうやらWindowsにしかなさそう。。最悪です。
http://www.mozilla-japan.org/kb/solution/3067
GyazMailも試してみました。
こちらはプレーンな状態で送れるようです。
まだまだ検証しないとわかりませんが、（少し使いにくいですが）
よけいなATT〜.txtという0KBのファイルが付かなくなりました。
また報告させていただきます。

最初のトピックにも書きましたが、
Macからの添付ファイルをWindowsで受信した時に、本体とは別なファイルが付く問題を
検証してみました。
みなさん、こんな症状って無いのでしょうか？
すみません、蒸し返しますが、、
　
1）WinのThunderbirdでは、本体とは別にPart 1.3という添付ファイルが付きます。
2）WinのOutlook Expressでは、本体と別の添付が付くことは無いのですが、本文の最後に
＜P＞＜HR＞＜／P＞
というタグらしきものが付いてきます。
3）Microsoft Outlookでも本体とは別にATT000〜.txtという添付ファイルが付きます。
（jpg画像ファイルを添付した場合）
新規メールで送信した場合、これらの添付ファイルは付きません。
人からもらった添付ファイルを返信、または転送した場合に添付されます。
これは英語の添付ファイル名を使っても同じです。
（sitx圧縮ファイルを添付した場合）
こちらも全く同じです。
新規メールで送信した場合、これらの添付ファイルは付きません。
自分自身に送った添付ファイルを返信、または転送した場合に添付されます。
これは英語の添付ファイル名を使っても同じです。
送信サーバーを別なものに変えてみましたが同じでした。
今試している、別なメールソフトでは、
GyazMail：転送するメールにATT000〜やpartのファイルが含まれていると、そのまま添付されます。
　　　　　（GyazMailではこれらの添付が付いているかどうかは見ることが出来ない）
　　　　　MacOSXのmail.appから送られる日本語添付ファイル名の、カタカナの「ク」が表示出来ず、化けてしまいました。
　　　　　ファイル名に「ク」が含まれているとそれ以降の文字と拡張子が全部消えてしまいます。
　　　　　（これはバグかな？）
Thunderbird：Mac版のThunderbirdでは、添付に付いているPart 1.3というファイルを見ることができるので、
　　　　　　　当然削除して送ることが可能だと思います。
　　　　　　　Winのoutlookに送る際に日本語添付ファイル名がATT〜に変わる問題で、
　　　　　　　MacOSXではパッチを当てられないのかな、と思っていましたが、
http://www.mozilla-japan.org/kb/solution/3067
↑このページの下の方をよく読めば解決出来ました。
エディターで編集すると解消されました。
ソースを比べたりしているのですが、Base64エンコードや
添付ファイルの最下部にある
--Apple-Mail-19-354595066
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
--Apple-Mail-19-354595066--
があるかないか、が違うだけみたいです。
OSX10.3.9では無かった問題なので、
やはり10.4.7の仕様なのでしょうか。
今はいろんなメールソフトを使い分けて、混乱気味です。
訳がわからなくなりました。

ソースコードを比べて見ています。
やっとkawabeさんの言っていたことが少しわかるようになりました。
すこし長いですが、、手元のメールソフトを比べてみました。
添付ファイル名は日本語で「広島_window表_修1.jpg」です。
OS10.3.9 Mail.app
--Apple-Mail-3-408736062
Content-Transfer-Encoding: base64
Content-Type: image/jpeg;
x-mac-type=4A504547;
x-unix-mode=0444;
x-mac-creator=3842494D;
name="広島_Window表_修1.jpg"
Content-Disposition: inline;
filename*=ISO-2022-JP''%1B%24B9%2DEg%1B%28B%5FWindow%1B%24BI%3D%1B%28B%5F%1B%24B%3D%24%1B%28B1.jpg
OS10.4.7 Mail.app
--Apple-Mail-1-434797289
Content-Transfer-Encoding: base64
Content-Type: image/jpeg;
x-mac-type=4A504547;
x-unix-mode=0444;
x-mac-creator=3842494D;
name==?ISO-2022-JP?B?GyRCOS1FZxsoQl9XaW5kb3cbJEJJPRsoQl8bJEI9JBsoQjEu?=
=?ISO-2022-JP?B?anBn?=
Content-Disposition: inline;
filename*=ISO-2022-JP''%1B%24B9%2DEg%1B%28B%5FWindow%1B%24BI%3D%1B%28B%5F%1B%24B%3D%24%1B%28B1.jpg
Thunderbird 1.0.5.5
--------------020309020000070108070902
Content-Type: image/jpeg; x-mac-type="0"; x-mac-creator="0";
name="=?ISO-2022-JP?B?GyRCOS1FZxsoQl9XaW5kb3cbJEJJPRsoQl8bJEI9JBsoQjEuanBn?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="=?ISO-2022-JP?B?GyRCOS1FZxsoQl9XaW5kb3cbJEJJPRsoQl8bJEI9JBsoQjEuanBn?="
Gyaz Mail 1.3.8
--Multipart_20060831110045148523
Content-Type: image/jpeg; x-mac-creator=3842494D; x-mac-type=4A504547;
name="=?iso-2022-jp?B?GyRCOS1FZxsoQl9XaW5kb3cbJEJJPRsoQl8bJEI9JBsoQjEuanBn?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=iso-2022-jp''%1B%24B9%2DEg%1B%28B%5FWindo;
filename*1*=w%1B%24BI%3D%1B%28B%5F%1B%24B%3D%24%1B%28B1%2Ejpg
OS10.3.9とOS10.4.7のnameフィールドのところが全然違いますね。
それに、10.4.7のnameフィールドが2行になっています。
また報告致します。

Gyaz Mailのバグかなと思った件、下記回答を頂きました。
＜報告＞
MacOS10.3.9のMailから送られる日本語添付ファイル名の、カタカナの「ク」
が表示出来ず、化けてしまいました。
ファイル名に「ク」が含まれているとそれ以降の文字が全部消えてしまいます。
Windowsから、同様のファイル名のものを送ると、この症状は出ません。
＜回答＞
Apple Mailの添付ファイル名のエンコード処理に問題があります。
今年の6月ぐらいにAppleにバグレポートを送りましたが、しばらく
たっても修正されないようであればGyazMailでの対応を検討しよう
と思います。
とりあえずの回避策ですが、ファイル自体は壊れておりませんので、
一度デスクトップに保存し、ファイル名（拡張子）を正しく付ける
ことで、ファイルを開くことができるようになります。