添付ファイル名に使えない文字(長文)

先日会社で使っているEntourageで、日本語ファイル名のファイルを添付して社内の人へメールを送信しようとしたところ、社内のメールサーバが「RFC822規約違反」のエラーで刎ねてしまう、という事象に遭遇しました。添付ファイル名に問題がありそうとわかり、含まれている文字でいろいろテストしてみますと「あ」や「ア」の文字がダメとわかりました。他の文字ではだいたい問題ないようです。Mail.appでやってみても同じでした。しかし、WindowsのOutlook ExpressやThunderbirdでは問題ありません。
さて何が問題なのか、メールソースの添付ファイル名の部分を調べてみると、以下のことがわかりました。
- Entourage、Mail.appともに、添付ファイル名は「Contents-Typeフールドのnameパラメータ」と「Contents-Dispositionフールドのfilenameパラメータ」の両方に書かれている。前者はiso-2022-jpでエンコードされたものが、後者はRFC2231形式で入っている。
- Windowsのメーラでは、両方にiso-2022-jpエンコードを更にMIME-Bでエンコードしたものが入っている。
RFC規約では、添付ファイル名は「Contents-Dispositionフィールドのfilenameパラメータに入れるべきで、ASCII以外の文字の場合はRFC2231に従ってエンコードするのが正しいはずです。つまり、Macのメーラの方が正しいのですが、RFC2231が比較的新しい規約で、これに従ってない多くのWindowsメーラの蔓延で、MIME-Bでエンコードされたものがまかり通っているのが実情のようです。
ところが、今回の問題はContents-Typeのnameフィールドの方をメールサーバがRFC822規約違反と判断したのです。このフィールドは本来添付ファイル名としての意味はないはずなのですが、MIME-Bエンコードされない生のiso-2022-jpでは「あ」は「$"」、「ア」は「%"」でともに「"」が含まれます。これがファイル名全体を囲む「"」とコンフリクトし、正しいヘッダではないと判定されたようです。
ちなみに、他にiso-2022-jpで「"」が含まれる文字は「、」や「帳」などがあり、これらを含む添付ファイル名ではいずれも同じエラーになりました。
RFC822では、メールヘッダで使用出来る文字を限定しており、生のiso-2022-jpは使えないのは確かです。でも、このContents-Typeフィールドがメールヘッダなのかメール本体かといえば、後者と見るのが普通のように思えます。
このエラーを吐くメールサーバはそれほど多くないのかもしれません。このボードでもこのエラーについての書き込みは(以前あったのかもしれませんが)見かけないし、実際自宅で使用しているISPのメールサーバでは問題ありません。会社でもEntourageを4年半使ってきて初めてこのエラーが起こったので、会社のメールサーバが最近変更された可能性が高いと思っています。
皆さんのところではいかがでしょうか?また、どなたかこの問題に詳しい方の意見をお聞かせ願えないでしょうか?

投稿日 2006/06/20 23:00

返信: 8

2006/06/21 00:11 Community User への返信

>皆さんのところではいかがでしょうか?また、どなたかこの問題に詳しい方の意見をお聞かせ願えないでしょうか?
そんなエラーを出すメールサーバー (MTA, MSA) はわたしは知りませんでした。そういうのがあるんですね。
少なくとも、「RFC822 違反」というのは変でしょう。RFC822 (その後継の RFC2822) は添付ファイルに関する規格じゃないですから。
>でも、このContents-Typeフィールドがメールヘッダなのかメール本体かといえば、後者と見るのが普通のように思えます。
つまり、この考えが正しいです。ということで、短絡的な結論としては「メールサーバーの仕様が変だ」ということになります。RFC2045 違反というエラーを出すなら反論できませんが。
>- Windowsのメーラでは、両方にiso-2022-jpエンコードを更にMIME-Bでエンコードしたものが入っている。
全部がそうではなくて、後者 (Contents-Dispositionフールドのfilenameパラメータ) の方に RFC2231 準拠のファイル名を入れるものもあります。Thunderbird も 1.5 からはデフォルトがこの動作のようです。

2006/06/21 00:59 Community User への返信

# 別に詳しいわけではありませんが。。。
> そんなエラーを出すメールサーバー (MTA, MSA) はわたしは知りませんでした。(略)「RFC822 違反」というのは変でしょう。(略)
同意。読んでいて思うのはものすごくWindowsに特化したMail Serverのような気が。。。
> 全部がそうではなくて、後者 (Contents-Dispositionフールドのfilenameパラメータ) の方に RFC2231 準拠のファイル名を入れるものもあります。Thunderbird も 1.5 からはデフォルトがこの動作のようです。
RFC2231準拠にしたがために、Mail.appと同じように「添付ファイルが文字化けしている」「開けない(?)」というような問題も起こっているようです(^^; まぁあれです。WinなMUAにRFC2231を理解できないモノが未だに多いという事でしょう。少なくともMSなMUAではダメみたいです。(Entourageとは違うのね。。。) 個人的にWinのMUAでは一番だろうと思っているBecky!では大丈夫の様です。
ちなみに、私が愛用しているGyazMailでは「Contents-Typeフールドのnameパラメータ」ではMIME-Bで、「Contents-Dispositionフールドのfilenameパラメータ」はRFC2231形式になっており、これはWindows対策(逃げ?)という事なんでしょうねぇ。
ていうか(にしても)、アレです。なんだそのMail Server?! です。
# 解決策)腐ったMail Serverを何とかする。
# 妥協策)Y.KawabeさんがGyazMailに乗り換える。
## いや、半分冗談です。。。

2006/06/21 12:02 Community User への返信

メールのエラーメッセージは以下です。
Reporting-MTA: antivirus@xxxxx.co.jp
Final-Recipient: rfc822;xxxx@xxxxx.co.jp
Action: failed
Status: 5.1.1
Diagnostic-Code: X-Notes; Cannot route mail to user (xxxx@xxxxx.co.jp).
この中にrcf822があるのでてっきりそれが原因かと思ったのですが、サーバ管理者へ聞いてみたら、エラー原因はRFC822ではなくRFC2045-2049とのことです。また、エラーを出しているのはMTA本体ではなく、ウィルス対策フィルターのようですね。
>RFC2045 違反というエラーを出すなら反論できませんが
確かにRFC2045の"5.1 Syntax of the Content-Type Header Field"には、以下のように書かれています。
ーー引用ーー
Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value.
ーーーーーー
つまり、「"」の文字はパラメータの一部ではなく、単なるデリミタだよ、ということですから、iso-2022-jpのエンコード部で最初に現れた「"」以後の部分が解釈不能になるのでしょうね。
それにしても、ちょい厳しすぎるチェックです。今緩めてもらうことが可能か、確認中です。MSやAppleにはバグレポートとして改善要求すべきでしょうかね?

2006/06/30 10:36 Community User への返信

あの後、一応AppleとMSに改善要求を出しておいたのですが、なんと10.4.7のMail.appでは修正されてました!nameパラメータがMIME-Bエンコードされています。リクエストしてからまだ1週間ちょいなので、全然期待してなかっただけに、ちょっとびっくりです。
もっとも職場ではEntourageを使ってますので、肝心なのはMSの方なのです。Officeのアップデートはつい先日出たばかりなので、早急なアップデートは期待薄でしょうけど・・

2006/06/30 10:45 Community User への返信

> 10.4.7のMail.appでは修正されてました!nameパラメータがMIME-Bエンコードされています。リクエストしてからまだ1週間ちょい
をー。MSでは考えられない速さです(^^
# にしてもアレデス。本来エラーを出して遮断している所をどうにかしてもらえるのか一番ですけれど、なかなか難しいのかな。。。

2006/07/01 13:12 Community User への返信

> 関連は如何なる物でしょうか?
別のことです。
ここの話題は添付ファイルのファイル名のエンコーディングのはなし、返送時の話は、返送にすると、メール本文のコードが(多分 utf-8 に)変わる話で関係ないです。
utf-8 に変わるのは必ずしもバグではありません。utf-8 メールを文字化けさせてしまう相手方の使っているメーラが古過ぎるのです。
Windows でも utf-8 メールを正しく扱うメーラはいくらでもあります。

このスレッドはシステム、またはAppleコミュニティチームによってロックされました。 問題解決の参考になる情報であれば、どの投稿にでも投票いただけます。またコミュニティで他の回答を検索することもできます。

添付ファイル名に使えない文字(長文)

Apple サポートコミュニティへようこそ
Apple ユーザ同士でお使いの製品について助け合うフォーラムです。Apple Account を使ってご参加ください。