MIME type to satisfy HTML, email, images and plain text?
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)
- ...
- multipart/alternative
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 <[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--
Answer
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)
- multipart/alternative
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.