web-dev-qa-db-fra.com

Type MIME pour satisfaire HTML, e-mail, images et texte brut?

La réponse à Mail multipart/alternative vs multipart/mixed suggère que les pièces jointes devraient être des pairs de multipart/alternative message, comme:

  • multipartie/mixte
    • multipart/alternative
      • texte simple
      • texte/html
    • certains/chose (disposition: pièce jointe)
    • certains/chose (disposition: pièce jointe)
    • ...

Je voudrais envoyer un e-mail avec une partie html avec des images en ligne et une alternative en texte brut. Quelle est la disposition MIME préférée pour les différentes parties? Quelques options apparaissent dans l'exemple de code et dans d'autres questions, mais lesquelles ont le mieux fonctionné dans la pratique? Mon inclination est la suivante:

  • multipart/alternative
    • texte simple
    • multipartite/connexe
      • text/html (référencement des images par cid)
      • image/gif
      • image/gif
      • ...

De cette façon, les images sont clairement destinées à rendre la partie html. Un exemple complet de ceci serait:

From: Rich Example <[email protected]>
To: A Recipient <[email protected]>
Subject: An example of email with images and a plain alternative
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="outer-boundary"

This is a MIME-encoded message. If you are seeing this, your mail
reader is old.
--outer-boundary
Content-Type: text/plain; charset=us-ascii

This message might make you :) or it might make you :(

--outer-boundary
MIME-Version: 1.0
Content-Type: multipart/related;
  type="text/html"; start="<body@here>"; boundary="inner-boundary"

--inner-boundary
Content-Type: text/html; charset=us-ascii
Content-Disposition: inline
Content-ID: <body@here>

<html>
 <body>
  This message might make you
  <img src="cid:smile@here" alt="smile">
  or it might make you
  <img src="cid:frown@here" alt="frown">
 </body>
</html>

--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <smile@here>

R0lGODlhEAAQAKEBAAAAAP//AP//AP//ACH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci6JrasrqkypxJr8S0oNpgqkGLtcY6hoFADs=

--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <frown@here>

R0lGODlhEAAQAKEBAAAAAAD//wD//wD//yH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci75drDzm5uLZyZ1I3Mv8ZB5Krtgg1RoFADs=

--inner-boundary--

--outer-boundary--
emailmime
24
Rob Starling

Tu as raison. Les images en ligne doivent être stockées dans un multipart/related mime-entity (RFC 2387) et offrant plusieurs options de type de contenu peut être fait avec multipart/alternative (RFC 2046).
Pour ajouter des pièces jointes, vous pouvez mettre toute la structure dans un multipart/mixed et ajoutez les pièces jointes.

  • multipartie/mixte
    • multipart/alternative
      • texte simple
      • multipartite/connexe
        • texte/html
        • image/gif
        • image/gif
    • certains/chose (disposition: pièce jointe)
    • certains/chose (disposition: pièce jointe)

Vous pouvez également utiliser l'image en ligne dans des messages texte/simples, mais tous les MUA ne le prennent pas en charge. (N'utilisez aucun ou disposition: en ligne)

  • multipartie/mixte
    • texte/simple (texte au-dessus de l'image)
    • image/gif
    • texte/simple (texte sous l'image)

Et je ne connais pas de moyen propre de combiner cela avec un e-mail HTML en plusieurs parties/alternatif.

10
Hägar