Let multipart/alternative filter provide multiple MIME parts
At time of writing, send_multipart_alternative_filter
uses a very simple line-based protocol to read data back into mutt: First, a line specifying the part's MIME type (e.g. text/html
), two newlines, and then the payload. From that, mutt creates a new MIME part to provide as alternative to the text/plain
part that was provided to the script as input.
This works fine for simple text, but the protocol cannot cater for related entities, such as images. A hack is to provide the images with inline data, e.g.:
<img alt="" src="data:image/jpeg;base64,/9j/4AAQSkZJ … " … />
but most clients seem to filter out the src
attribute containing such data, e.g. rendering an img
tag without a src
attribute.
The "correct" way to inline images into rich-text parts is to reference them by "Content-ID", e.g.
<img src="cid:part1.DF4C10CB.2185C5B7@example.org" … />
and then provide a multipart/related
part like this:
I 1 <no description> [multipa/alternativ, 7bit, 14K]
I 2 ├─><no description> [text/plain, 7bit, utf-8, 0,1K]
I 3 └─><no description> [multipa/related, 7bit, 13K]
I 4 ├─><no description> [text/html, 7bit, utf-8, 0,3K]
I 5 └─>image.jpg [image/jpeg, base64, 13K]
which declares the same Content-ID:
--------------D0ACD2D48969C37E2267EFFE
Content-Type: image/jpeg; name="image.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.DF4C10CB.2185C5B7@example.org>
Content-Disposition: inline; filename="image.jpg"
/9j/4AAQSkZJRg …
At the moment, the multipart_alternative_filter
protocol does not allow for the creation of multipart/related
MIME hierarchies, but I see little reason why it couldn't, for instance if the first line matches /^Content-Type:/
, simply treat the entire output as a valid MIME hierarchy and attach it in place.
Ideally, Mutt would even unpack a multipart/related
hierarchy, because arguably, the attachments therein are also related to the plain-text alternative, and the resulting hierarchy should actually be:
I 1 <no description> [multipa/related, 7bit, 14K]
I 2 ├─><no description> [multipa/alternativ, 7bit, 0,4K]
I 3 │ ├─><no description> [text/plain, 7bit, utf-8, 0,1K]
I 4 │ └─><no description> [text/html, 7bit, utf-8, 0,3K]
I 5 └─>image.jpg [image/jpeg, base64, 13K]
I am not sure whether "modern" mailers will be able to handle this though.