メールのMIMEにContent-IDヘッダーが存在するということは、添付ファイルを埋め込む必要があるということですか?


11

私たちが持っている2つの異なるサードパーティのメール製品は、メールのMIMEソースのcontent-idヘッダーの存在に異なる反応を示しています。これにより、解決しようとしているユーザーエクスペリエンスに一貫性がなくなります。

次に例を示します。

--boundary-example
Content-Location: CID:somethingatelse 
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..

1つのメール製品がこれを埋め込み画像として解釈します。もう1つは、これを通常の添付ファイル(埋め込みではない)として解釈します。Content-ID行を完全に削除すると、どちらの製品も添付ファイルが埋め込まれていないと見なします。

どの動作が正しいかを明確に結論付ける特定のRFCはありますか?同僚と私は、冒頭の要約で次のように述べているRFC2392をレビューしました。

電子メール内で[MIME]を使用してWebページとその
関連画像を伝達するには、HTML
がメッセージに含まれる画像やその他のデータを参照できるようにするためのURLスキームが必要です。Content-IDの
Uniform Resource Locator、「cid:」がその目的を果たします。[…]「cid」スキームは、メッセージの特定の本文部分を指します。通常、その使用は、参照している本文部分と同じメッセージ内の他の本文部分への参照に限定されます。「中間」スキームは、コンテンツIDのアドレスを含めることにより、指定されたメッセージ内の特定のボディパーツを指す場合もあります。

したがって、絶対的ではありませんが、すべての埋め込みアイテムはそれらを参照するためにcidを必要とするため、「通常は同じメッセージ内の他のボディパーツに限定されます」、添付ファイルに cid 必要ないと考えます、電子メール製品がcidの存在を「埋め込み意図」の指標として扱うことは合理的な動作です。

これについて確認をもらえますか?


RFCの作成者または関連するIETF WGに質問してください。
sendmoreinfo 2012

回答:


8

Content-ID画像をインライン表示されるべきであることを示すものではありません。このヘッダーは、HTML内の埋め込みデータを参照するために必要です。

メールはテキストメッセージなので、メールがプレーンテキストである限り、埋め込まれた画像を表示する理由はありません。

一部のクライアントは、形式がHTMLかプレーンテキストかに関係なく、データをインラインで表示します。しかし、これは明確な行動ではありません


8

私は、あなたが探していると思うContent-Dispositionあなたがする(画像など)の身体部分のプレゼンテーションのスタイルを定義することができますヘッダフィールド、inlineまたはattachment

以下は、Thunderbirdによって作成されたインラインの例です。

--------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.02080004.04000407@sample.com>
Content-Disposition: inline; filename="test.png"

あなたはもっと読むことができます:


Content-Dispositionヘッダーは常に含まれているとは限りません。質問で提供されたヘッダーに基づいて、パーツがインラインか添付ファイルかを導出する必要がある場合があります。
user2817219
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.