web-dev-qa-db-ja.com

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

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

次に例を示します。

--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の存在を「埋め込み意図」の指標として扱うことは合理的な動作です。

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

emailmimerfc
11
Mike B

Content-Dispositionヘッダーフィールドを探していると思います。これにより、ボディパーツ（画像など）の表示スタイルをinlineまたはattachmentに定義できます。

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

--------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
Content-Disposition: inline; filename="test.png"

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

8
james.garriss

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

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

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

8
Thomas Berger