26

The answer to Mail multipart/alternative vs multipart/mixed suggests that attachments should be peers of the multipart/alternative message, like:

  • multipart/mixed
    • multipart/alternative
      • text/plain
      • text/html
    • some/thing (disposition: attachment)
    • some/thing (disposition: attachment)
    • ...

I'd like to send email with an html part with some inline images and a plain text alternative. What is the preferred MIME layout for the various parts? A couple of options appear in example code and in other questions, but which have worked best in practice? My inclination is this:

  • multipart/alternative
    • text/plain
    • multipart/related
      • text/html (referencing the images by cid)
      • image/gif
      • image/gif
      • ...

That way, the images are clearly for the purpose of rendering the html part. A full example of this would be:

From: Rich Example <rich-example@example.org>
To: A Recipient <recipient@example.org>
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--
Community
  • 1
  • 1
Rob Starling
  • 3,868
  • 3
  • 23
  • 40
  • 1
    Appears to be an exact dupe of the question it refs: http://stackoverflow.com/questions/3902455/smtp-multipart-alternative-vs-multipart-mixed – james.garriss Mar 29 '13 at 18:29
  • 3
    A slight difference in intent (whether i clearly conveyed it or not) might have to do with the purpose of the attachments. If they are _for_ the rich rendering (e.g. logos, wingdings, etc.), should they be "in" the rich alternative? The ref'd question also makes no mention of `related`. – Rob Starling Mar 31 '13 at 20:52

1 Answers1

10

You are right. Inline images should be stored in a multipart/related mime-entity (RFC 2387) and offering multiple content-type options can be done with multipart/alternative (RFC 2046).
For adding attachments you may put the whole structure into a multipart/mixed and add the attachments.

  • multipart/mixed
    • multipart/alternative
      • text/plain
      • multipart/related
        • text/html
        • image/gif
        • image/gif
    • some/thing (disposition: attachment)
    • some/thing (disposition: attachment)

You can also use inline image in text/plain messages, but not all MUA support this. (Use none or disposition: inline)

  • multipart/mixed
    • text/plain (text above image)
    • image/gif
    • text/plain (text below image)

And I dont't know a clean way to combine this with a multipart/alternative HTML-email.

Hägar
  • 131
  • 1
  • 3
  • Sorry, I don't think this correct. Inside multipart/alternative there are only two items: text and html. The alternative is inside a multipart/related. See: http://stackoverflow.com/a/40420648/633961 – guettli Nov 04 '16 at 10:50
  • @guettli - not true. Per [RFC1341](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) you can have as many alternatives as you like - you can include a PDF version, a video version, etc.. – dsz Mar 15 '23 at 11:06