マルチパート/代替サブタイプ（クライアントが使用する場合）？

Question

multipart/alternativeサブタイプ（HTMLで作ったとき）以外のものは、text/htmlパーツが入ったMIMEとしてHTMLを送るのに対し、GmailのようなwebmailsはMIMEメッセージを送る理由は何ですか？

Answer 1

multipart/alternativeは、各部分が同じ（または類似の）内容の「代替」バージョンであり、それぞれが「Content-Type」ヘッダーで示される異なる形式であることを示します。フォーマットは、それらがオリジナルにどれくらい忠実であるか、最も忠実でないものから最も忠実なものまで、順序付けられます。

Gmailのようなメールエージェントは、自分が何をしているのかを知り、text/htmlをtext/plainに変換して両方のメールボックスにメールを入れて、受信側で使用する代替方法を決定させます。

HTMLコンテンツからテキストのみのバージョンを抽出する方法を知らないメールエージェントもあります。なぜなら、開発者はそれを実装するのを邪魔しなかったからです。したがって、text/htmlに代替を送信するだけです。

そして時々 - 私はそれらを狂ったものと呼んでいます - multipart/alternativeを送信しますが、実際には代わりにtext/htmlを入れます。それは本当に素晴らしいわけではありませんが、いかなる仕様にも違反していません。

Answer 2

RFC 2046のsection 5.1.4は、送信者が同じメッセージの異なる、交換可能な表現を提供し、その能力のために最も適切なプレゼンテーションの形式を選択したために受信機にそれを残すことができるようにmultipart/alternative MIMEタイプを定義します。ユーザに対する各表現の一般的な意味は保持されるべきであるが、ある表現から他の表現への情報の損失は通常ある（例えばtext/htmlに関するtext/plainのフォーマット情報が欠けている）。代替案は、一般的に最も明瞭なものから最も豊富なものに順序付けられるべきである。すなわち、代替が再びtext/htmlおよびtext/plainである場合、text/plainが最初に来るべきである。これは、最も解釈しやすい部分が最初に現れる非MIME準拠の視聴者のユーザを助ける。一般的に、MIME準拠のビューアは、それが最も望ましいので、それが見ることができる最後の表現を表示する必要があります。

このコンテンツタイプは、多くの場合、異なる番号のリソースが1つのメッセージに結合されているmultipart/mixedと対比されます。

一部のメールサービスがメッセージを提供する主な理由は、受信側でさまざまなタイプの表示アプリケーションをサポートすることです。multipart/alternative例えば、HTMLをレンダリングする能力がない視聴者もいれば、メッセージをすべて読むことができるようにtext/plain表現を必要とする視聴者もいます。同時に、他の視聴者はHTMLをレンダリングする能力を持ち、メッセージがtext/htmlとして配信されたときのユーザーエクスペリエンスをはるかに向上させることができます。 multipart/alternativeメッセージで囲まれた両方の表現を配信することによって、幅広い視聴者をサポートすることと、より能力の高い視聴者のためのユーザエクスペリエンスを向上させることとの間のトレードオフに対する最も柔軟な解決策が得られる。

詳細はRFC 2046を参照してください。