Wandering Thoughts archives

The three modern formats for email forwarded by people

It's routine for people to forward email around, often with their own comments added. Today, there are three different formats that this is done in, all of which have their own ecological niche, and all of which you may need to care about if you're setting up and configuring a new mail client environment, or if you get sent forwarded email by people (for example, because they're reporting some problem with email, perhaps relayed to them from someone else).

The first format and probably the most common one is what I will call rendered text format. In this format, the email message is 'forwarded' as text inserted into the message in more or less the form the person forwarding it sees in their email client. This means it has a limited selection of message headers and sometimes even they won't be included fully intact. Rendered text format makes a lot of sense for humans to read in ordinary circumstances, and it's generally easy to quote everything (commentary and forwarded message both) when people reply (often with top posting). Obviously this format doesn't really work if the forwarded message has complex content, like embedded images.

(The 'rendered text' and the whole message may be HTML, but I don't think very many mail clients will carefully construct a version that still has the images attached and so on.)

The second format is MIME, with a message/rfc822 content type (normally set to be 'inline' instead of 'attachment'). This forwards the message with everything intact, including both the headers and any complex formatting or embedded additional things (like images or PDF attachments) that it may contain. Pretty much any decent email client can show these MIME message/rfc822 parts inline, rendered as they would show a regular message (so, for example, with only certain headers shown). In theory MIME forwards are what everyone should want and ask for if they want the full literal message; they're certainly what you'd like to get from people if they're reporting spam. Any decent mail client should be able to do things like show you the full headers or extract the entire forwarded message to a file.

Unfortunately life is not always perfect, so we have the third format, which I will call literal plaintext format. Literal plaintext format includes the entire message in raw form, but not in a separate MIME part, just as text, with all of its raw MIME bits dumped out for the reader. You need literal plaintext format because some places want the full message headers in contexts like spam reports, but can't handle MIME message/rfc822 messages. Sometimes they'll tell you this explicitly, and sometimes you'll just get replies telling you that they couldn't handle your '.eml' attachment.

I believe that mail clients often default to the first format and offer the second format as 'forward as an attachment' or 'attach message' (although normally the MIME headers would ask for such messages to be displayed inline). I don't know if it's very common for mail clients to offer an easy way to do the third.

(I wrestled with this recently when I was configuring my MH-E environment to be able to forward messages in all three formats.)

Sidebar: Getting these formats in command line NMH

NMH forwards messages with forw (also), which takes an assortment of options. Forwarding messages as MIME is 'forw -mime', and don't forget to give whatnow (also) a 'mime' command to process the directives that forw will insert (as is necessary when adding MIME attachments).

Forwarding messages as literal plaintext is best done with 'forw -noformat -nodashstuffing'. This is not the proper NMH way to forward messages in non-MIME format, but it's the way that's most likely to be accepted by places that you report spam to that won't accept MIME message/rfc822 format (yes, they exist).

Forwarding messages as rendered text is sufficiently complicated to be well outside the scope of this entry. This is due to NMH limitations, especially with MIME messages; it's 2023, MIME has been around for plural decades, and (N)MH still doesn't have any good way to provide the rendered version of messages for forwarding or replies.

(At least it's possible if you work hard enough, probably including your own program to handle rendering MIME-encoded messages.)