May 29, 2017

The mutt email client

I stopped using mutt back in 2011 and switched to Thunderbird, so this information is quite ancient. For many years I received email on my local machine, and used mutt to read it. Mutt had good things and bad. It was a simple interface that I knew well. Single keystrokes did important things (such as deleting worthless messages that I could recognize from the subject line). Mutt was mime compliant in theory, but not in any useful way. It was a major pain to view attachments, in particular images, and html email was impossible (this could be viewed as a virtue).

When our organization switched from receiving email locally to using a gmail server, mutt became awkward at best and that was the end of that. Apparently mutt could be set up to interact with gmail via IMAP, but I never got involved with that.

The big win switching to Thunderbird was that it handled embedded html and mime attachments properly without rocket science level exploits on my part.

Mutt and attachments

More and more, people send me MIME attachments via email. The support that MUTT gives for these is clumsy at best, but this could be viewed as a feature rather than a bug in that when I get html spam email, I am not afflicted by any obnoxious inline graphics. (On the other hand, switching to google mail has entirely eliminated spam, so this is a non-issue these days).

What I do is to use "v" to tell mutt to view attachments (the first is in most cases the "text/plain" element that mutt has already shown me. The "s" key will save an attachment (so if somebody sends me an image, I can save it, then exit mutt and look for it on disk and use display to view it. Better yet is to use the "|" key to pipe it to a command (like display). If I just hit return though, mutt does something stupid and this is what I would like to fix.

Two files seem to govern what goes on. The first, /etc/mime.types is apparently a comprehensive list of every known mime type with an optional suggestion for a file extension to go with it, and does really seem relevant to the current discussion.
The file /etc/mailcap seems to exist for mutt only (though this is not really true). For a given mime type it indicates an application which should be run. What I did was to edit this file and replace the line: 

image/*; /usr/bin/xdg-open %s
with 
image/*; /usr/bin/display %s
(A side note here, if you read section 5.4 of the mutt manual, you will find the following mailcap line suggested. Note that the final "flag" copiousoutput will cause this to display attachments while in the pager and without entering the attachment viewer if used in conjunction with an auto_view line in the muttrc file.) 
image/*;        anytopnm %s | pnmscale -xsize 80 -ysize 50 | ppmtopgm | pgmtopbm | pbmtoascii ; copiousoutput
Anyway, after hacking mailcap, everything works great. So the question is what is wrong with xdg-open? This disfunctional thing is a 469 line shell script that claims to open a file or URL in the "user's preferred application". Whatever that might be!! What it seems to try to do is to divine what desktop (KDE or gnome or whatever) a user is running, and then pass the file or url to some universal handler (like gnome-open) for the desktop in question. It will use mimeopen if it fails to figure out the desktop. My solution of hacking the mailcap file works for me and is fine on my system where I am the only user, so I am not bothering to dive deeper into xdg-open and its cronies.
Feedback? Questions? Drop me a line!

Adventures in computing / tom@mmto.arizona.edu