Lacking Natural Simplicity

I composed a carefully constructed MIME message using Mew, which has a nice way to build MIME messages, but Gmail doesn’t know that if you have a multipart MIME message that has a text part, then an image, then a text part, then an image, then a text part then what you want is for the image parts to be displayed inline. In messages like that composed in Gmail, it uses the content type of multipart/related, which then encloses a multipart/alternative, which has a plain text version of the message and an HTML version, which refers to the images with an img tag that has an id that refers to the id in a Content-ID MIME header in following parts of the multipart-related MIME part that is the main body of the email.

I don’t know why Gmail doesn’t display the simpler multipart/mixed messages correctly.

It is very annoying. I don’t mind them using the multipart/related (which I didn’t even know about before looking at one of their messages using wl-summary-reedit in Wanderlust, which pulls it up in the mime-edit-mode MIME composition mode [1], which revealed all the details), but I wish they’d get the simpler multipart/mixed version right. Instead, they don’t display the inline attachments (regardless of whether they are images or text) and put them all at the end of the display as attachments, and display the other text parts smushed together.

Interestingly, if a text part it has a Content-Type: Text/Plain MIME header field it is displayed inline in Gmail, unless it has a

Content-Disposition: inline; filename="JRandomFilename.txt"

MIME header field, and then it doesn’t display it inline, unlike all the other mail readers I tried: Wanderlust, Mew, Alpine, Thunderbird (had to have a pure GUI client for comparison), and mutt.

Interestingly, Wanderlust displays Gmail’s multipart/related messages correctly, which impressed me.

I originally I thought that Mew did not display the multipart/related message correctly, punting to just displaying original MIME-encoded text instead, and not displaying the image parts.

I was wrong about that; I was just confused by its presentation. First it displays the text version of the enclosed multipart/alternative, which is what made me think it didn’t display the image parts; it just hasn't yet! Then if I hit space, it displays the first of the images, and then if I hit space it displays the second of the images.

And you can make Mew display the HTML part, but it doesn’t know how the <img id=“foo”> elements work, so it doesn’t display the images.

I was pleased to see that the Wanderlust (WGH) and Mew (MGH) github repositories both have recent commits.

And Wanderlust and Mew are both in MELPA these days, although Mew’s MELPA package doesn’t include the command line program, incm, that is used to pull emails from /var/mail into MH style files under ~/Mail. Wanderlust and Mew both use MH style files under ~/Mail as their local message store. MH puts subdirectories there for folders, and in each folder the messages are named with integers that correspond to the order in which they were incorporated from whatever mail source you were using (historically /var/mail). MH used command line programs to incorporate mail, list mail messages, display mail messages, and file it into folders. I rather liked it. I used nmh (the New MH, a new implementation of the original Rand MH commands, which ran on newer Unixes) and GNU mailutils (which provided MH-compatible command line programs, if not configured out), sometimes during the same period of time, for a considerable time. At one time, when I was getting mail at a server I had online, I was using nmh, GNU mailutils, Emacs’s built-in interface to MH (MH-E), Wanderlust, and Mew. (Before that I used ViewMail, and before that I used RMAIL) They each had features the other lacked.

I tried using Unison to sync that mail between my server online and my computer at home, but that did not work well, since MH commands change the names of files when they move them from one folder to another (remember, each message in a folder gets a name that is an integer based on the order in which it was incorporated in that folder, and its folder command provided an option, -pack, that renamed all the messages in a folder sequentially, used after you’d deleted messages) so you couldn’t keep track if the message named 32 in one folder on one machine was a new one or just renamed from 976 when you ran folder -pack last. Syncing with Unison just did not work at all. Hmm. I could have changed the Path option in my .mh-profile` file on each machine, so that instead of all the MH mail being under ~/Mail on both machines, on my home machine it could have been under ~/Mail-home and on tkb.mpl.com it could have been under ~/Mail-onlineserver, and then I could have used rsync to copy those from one machine to the other appropriately so I’d have a backup. Huh. Wish I’d figured that out back in the day. Of course, to read email in ~/Mail-home on my online server I’d have had to changed the Path option in my ~/.mh_profile on that machine, and then changed it back when I wanted to use ~/Mail-onlineserver. It would have worked, however.

Completion made me go look at the MIME messages I was testing in MH-E. In the multipart/mixed message MH-E does not show the PNG files inline, though emacs has the capability to do that now. It does have keybindings to open an external viewer for you. If you specify the macOS command open it will open it in whatever app is the default for macOS; in the case of PNGs that is Preview.

I do most of my email reading and sending in Gmail these days, alas. I still use Wanderlust and Mew occasionally, since they support IMAP very well. Now if only Google didn't make it harder to use them: Gmail declares IMAP-over-SSL is a “less secure” application, and turns IMAP access off if you don't use it regularly.