Understanding MIME

Quite a bit of effort has been made to make NeoMutt the premier text-mode MIME MUA. Every effort has been made to provide the functionality that the discerning MIME user requires, and the conformance to the standards wherever possible. When configuring NeoMutt for MIME, there are two extra types of configuration files which NeoMutt uses. One is the mime.types file, which contains the mapping of file extensions to IANA MIME types. The other is the mailcap file, which specifies the external commands to use for handling specific MIME types.

MIME Multipart/Multilingual

NeoMutt includes support for reading and writing multipart/multilingual emails. A multipart/multilingual email is like a multipart/alternative email, except that it comes with parts of different versions of languages instead of appearances. Its format is described by RFC8255.

Reading Multipart/Multilingual Emails

NeoMutt uses the $preferred_languages variable to determine which languages to display when displaying a multipart/multilingual email. You can have several preferred languages, separated by ,:

set preferred_languages="fr,en,de"

NeoMutt will try to match these strings against the multilingual header in the received emails “by prefix”, e.g., en will match both en and en_US.

If $preferred_languages is not set, it defaults to None, and the first part of the received multipart/multilingual email will be displayed.

Composing Multipart/Multilingual Emails

The procedure for composing a multipart/multilingual email is similar to those in Composing Multipart/Alternative. You have to prepare every part manually or using some scripts, and then tag and group them together into a multipart/multilingual bundle before sending it:

1. Prepare parts of the multilingual emails.

2. Attach them as attachments.

3. Tag them with <tag-entry>.

4. Edit the Content-Language header of every attachment with command <edit-language> (default to Ctrl-L). This is important, otherwise the recipient of this email will not know the corresponding languages. You can set arbitrary string as Content-Language, but it is recommended to set it as some common prefixes such as “en”, “zh” and “fr”.

5. Group all the tagged messages together by <group-multilingual> (default to ^).

6. Send the email as usual.

As in Composing Multipart/Alternative, you can also use NeoMutt’s macro and some external scripts to combine this procedure into one.

After grouping, the separate parts will be displayed in a tree structure. Attachments can still be edited separately and reordered within the group, but must be ungrouped using the <ungroup-attachment> (#) binding for more advanced editing before tagging and grouping together again as described above.

📷 Screenshot Needed

Subject: MIME attachment tree in compose menu

Description: The NeoMutt compose screen showing a multipart message with a nested MIME tree structure — e.g. a multipart/mixed containing a multipart/alternative with text/plain and text/html parts, plus a file attachment. The tree indentation and part numbering should be visible.

Highlights: The reader should notice how NeoMutt renders the hierarchical MIME structure as an indented tree with type annotations, showing the parent-child relationship between multipart containers and their leaf parts.

MIME Multipart/Related

NeoMutt doesn’t include any special support for reading multipart/related emails, but it is possible to write a multipart/related email. A multipart/related attachment is intended for compound objects consisting of several inter-related body parts which are linked together using the Content-ID header. Its format is described by RFC2387.

Composing Multipart/Related Emails

The procedure for composing a multipart/related email is similar to that in Composing Multipart/Alternative. You have to prepare every part manually or using some scripts, and then tag and group them together into a multipart/related bundle before sending it:

1. Prepare parts of the related email.

2. Attach them as attachments.

3. Tag them with <tag-entry>.

4. One part can reference another using its Content-ID header. For example, an HTML part that includes an embedded image needs to contain: <img src="cid:content-id"> where an attached image has a Content-ID header of content-id. The Content-ID of an attachment can be set using <edit-content-id> (default key Alt-i). <edit-content-id> sets a random ID which can then be changed if desired. Permitted characters for Content-ID are: -.0-9@A-Z_a-z.

   If the multipart/related group is intended to be inline, members of the group should also have their Content-Disposition header set to inline which can be toggled using <toggle-disposition> (default key Ctrl-D).

   It can also be desirable to give referenced files in the group a filename even when the Content-Disposition is set to be inline. To do this use <rename-attachment> (default key Ctrl-O).

5. Group all the tagged messages together with <group-related> (default key %).

   Top level attachments (excluding multipart ones) in the group are automatically given a random Content-ID if they do not already have one.

6. Send the email as usual.

   Some care needs to be taken with the construction of a multipart/related email to ensure it is correctly displayed by the receiving mail client. A typical email with a multipart/alternative part containing a text/plain part and a text/html part with an embedded image, along with a separate attachment might end up like this:

  I     1 <no description>                                         [multipart/related, 7bit, 0K]
  I     2 ├─><no description>                                  [multipart/alternative, 7bit, 0K]
- I     3 │ ├─>/tmp/neomutt-hostname-XXXX-XXXXXX-XXXXXXXXXX   [text/plain, 7bit, us-ascii, 0.1K]
- I     4 │ └─>/tmp/neomutt-alternative.html                      [text/html, 8bit, utf-8, 0.6K]
  I     5 └─>image.png                                                  [image/png, base64, 19K]
  A     6 attachment.pdf                                         [application/pdf, quoted, 7.1K]

In the above email /tmp/neomutt-alternative.html would reference image.png using <img src="cid:content-id"> and image.png has been given an explicit name of image.png using <rename-attachment> (regardless of its initial filename). <group-related> has set its Content-ID header to a random value.