.eml添付で不正なContent-Type:が生成され - 秀丸メール情報交換会議室 - スレッド09209, 2002/10/01

.eml添付で不正なContent-Type:が生成され

むーこ さん　02/10/01 14:32

鶴亀メール Version 2.08 を使用し、"forward.eml" という
message/rfc822形式の7bitデータファイルをメールに添付して
送信したところ、不正なContent-Type:フィールドが生成されました。
(foldingの仕方が不正です)

Content-Type: application/octet-stream
; name="forward.eml"
Content-Disposition: attachment; filename="forward.eml"
Content-Transfer-Encoding: BASE64

使用環境は次の通りです。
Windows NT 4.0 SP6
Internet Explorer 6 SP1

RE:09209 .eml添付で不正なContent-Type:

むーこ さん　02/10/01 14:40

追加情報です。

同じ環境でOutlook Express 6 (SP1) を使用して送信すると
次のようになります。

Content-Type: message/rfc822;
name="forward.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="forward.eml"

Outlook Expressが出力したほうは正しくfoldingされています。
さらに、メディアタイプもContent-Transfer-Encodingも
より理想的な形式で出力されています。

RE:09210 .eml添付で不正なContent-Type:

秀まるお2 さん　02/10/01 16:56

　「全般的な設定・基本・詳細」の

　「電子メール添付ファイルをapplication/octet-stream形式で送る」

　がONになっているんじゃないでしょうか？。ここをOFFにすれば（----普通OFF
のはずなんだけど------）message/rfc822形式で送られるはずです。

　ただし、この場合、「name=XXXX」は付きません。name=を付けないのも一応鶴
亀メールとしては仕様のつもりです。

RE:09216 .eml添付で不正なContent-Type:

むーこ さん　02/10/01 18:46

>　「全般的な設定・基本・詳細」の
>
>　「電子メール添付ファイルをapplication/octet-stream形式で送る」
>
>　がONになっているんじゃないでしょうか？。ここをOFFにすれば（----普通OFF
>のはずなんだけど------）message/rfc822形式で送られるはずです。

なるほど。その点は了解しました。

text/*な添付ファイルに対して、鶴亀メールが文字コードの
自動判定を誤った場合、相手に迷惑をかけてしまうため、
どんなデータであろうが常にapplication/octet-streamで
送信できるように設定しようとしていろいろいじったことを
忘れていました。
改めてヘルプを読んだところ、ここでの設定はそういう目的で
使うものではないのですね。
勝手に勘違いしていました。大変失礼しました。

ただ、次の点は鶴亀メールの不具合だと思います。
ご確認いただけますでしょうか。

(1)上記設定がONの場合、Content-Type:の形式が不正になる。
(CRLFの直後にあるべきSPACEやHTABがない)
(2)中国や韓国から送られてくるメールは、しばしば
Content-Transfer-Encoding: 8bit
になっている(日本と違って日常的に8bitが使われる)。
上記設定がOFFの場合、8bitの.emlファイルを添付すると
Base64でエンコードされる。
(message/rfc822をBase64エンコードするのはRFC2046違反)

>　ただし、この場合、「name=XXXX」は付きません。name=を付けないのも一応鶴
>亀メールとしては仕様のつもりです。

その点は、私にとって特に不都合はありません。

RE:09221 .eml添付で不正なContent-Type:

秀まるお2 さん　02/10/01 19:07

>(1)上記設定がONの場合、Content-Type:の形式が不正になる。
> (CRLFの直後にあるべきSPACEやHTABがない)

　今確認したらたしかにバグってました。大変失礼しました。

　さっそく修正させていただきます。

> (message/rfc822をBase64エンコードするのはRFC2046違反)

　RFC違反であることはまったく知りませんでした。んではbase64エンコードし
ないで生で添付する（＆、Content-Transfer-Encodingは必要に応じて7bitにな
ったり8bitになったりする）ように修正させていただきます。

RE:09223 .eml添付で不正なContent-Type:

むーこ さん　02/10/01 20:37

早速、対応いただき、ありがとうございます。

>> (message/rfc822をBase64エンコードするのはRFC2046違反)
>
>　RFC違反であることはまったく知りませんでした。んではbase64エンコードし
>ないで生で添付する（＆、Content-Transfer-Encodingは必要に応じて7bitにな
>ったり8bitになったりする）ように修正させていただきます。

MIMEには1パスで解析可能な構造にする、という設計思想があり、
multipartやmessageなどのコンポジットタイプはエンコード
しない約束になっています。
特にmessage/*に対してはサブタイプごとに細かい制約があり、
http://www.iana.org/assignments/media-types/message/
から関連RFCにリンクが張られています

その他、修正される際に考慮して頂きたい点を書いておきます。

・7bit/8bit/binaryを判別する際、最上位ビット(MSB)だけでなく、
行の長さ、CR/LFの使われ方を調べる必要があります(RFC2045)。
・ボディパートが8bitやBinaryの場合、親のマルチパートに
Content-Transfer-Encoding: [8bit|binary]
と明記される必要があります(RFC2046)。
・8bitメッセージを送信する場合、SMTPサービス拡張の8BITMIME
(RFC1652,RFC2821)を使用します。
・8bitあるいはbinaryのメッセージをmessage/partial形式で
分割して送信することは禁じられています(RFC2046)。

ご参考まで。

RE:09224 .eml添付で不正なContent-Type:

秀まるお2 さん　02/10/02 11:59

　とりあえず別件でバージョンアップを急ぐ必要があったので、細かい内容を把
握することなくバージョンアップしてしまいました。

　現段階で、行の長さやCRLF関係のチェックは入ってないです。ついでに言うと、
「binary」というContent-Transfer-Encodingが存在することすら知らずにメー
ルソフトを作ってます。

　ぼちぼち勉強して、分かる範囲で対応させていただきます。