By Sterling “Chip” Camden
Contributing Writer, [GAS]
Email is one of the greatest innovations in communication of our time, but it can also be a tremendous drain on our time. Wading through all the spam, phishing lures, Facebook invites, and conspiracy theories from distant relatives to find the really important missives can feel like sorting sugar from a sandpile. The last thing you need is a user interface that slows you down even more.
Many geeks ditch the heavy graphical or web-based mail clients for a lean, mean solution: mutt. Mutt’s a character-based Mail User Agent (MUA) that snaps to your every command. It also provides powerful features for customization, organizing large volumes of email (especially from mailing lists), and interfacing to other applications.
But there’s not much about configuring mutt that’s obvious. Precisely because mutt doesn’t impose restrictions or favor one approach over another, it can take some time to figure out how you want to set it up. Once done, though, you’ll fly through your email.
Here are some ways that I’ve customized mutt to serve my needs better.
Using mutt as a feed reader
The same benefits that mutt brings to email can be applied to RSS and ATOM feeds. The obvious solution is to convert the feeds to email and have them delivered to you. You could use an external service for that – but then you’re creating a weak link by relying on that service – witness the demise of SendMeRSS (formerly R|Mail) and RSSFWD. If a particular feed is hosted at FeedBurner, they may provide an email subscription option – but that isn’t a solution you can apply across the board.
You’re better off using a local converter, like rss2email or newspipe. These utilities read the feeds and convert them to email right on your machine. I like newspipe, because it has greater configurability, and because it uses an OPML file for its feed list – which means that converting from FeedDemon was as simple as exporting the feeds and copying the OPML file to my FreeBSD system.
With newspipe, you have the option of sending the feed emails to an email address, or using a “procmail script”. The latter doesn’t have to be procmail, though. It can be anything that accepts complete emails on stdin. Which means that if you are using the mbox mail format, these emails can simply be appended to the mbox file of your choice. Thus, in my newspipe.ini file, I have:
procmail=/bin/cat >> /home/sterling/Mail/feeds
Thus eliminating a round trip to my mail server, as well as avoiding any false positive spam filtering.
I then added an entry to my crontab to run newspipe.py once an hour. All my feeds get loaded into a mailbox named “feeds”, so I can peruse them when I’m good and ready. Of course, your procmail script could be as complex as you want – you could sort feeds into different folders, for instance, by looking for custom header fields that you added in your OPML file. All that’s documented in the newspipe manual, so I’ll leave that as an exercise for the reader.
Working with X
Even though mutt is character-based, you can use some of the graphical capabilities of X-windows to dress it up and make it more readable. When running under X, you’ll need a terminal window for mutt. I like urxvt (rxvt-unicode), because it provides better support for fonts than xterm does. I also built urxvt with 256-color support. It isn’t that I need 256 colors, or even more than 8 – but I like to be able to pick which 8 or 12 or whatever.
For most of mutt’s display, I want the default characteristics of my terminal window, which has a transparent background and SpringGreen text. The default build for mutt, though, uses ncurses – which doesn’t grok that at all. I found that building mutt with slang instead of ncurses (WITH_SLANG=yes in /etc/make.conf) inherits the terminal characteristics beautifully.
To use 256 colors in the .muttrc “color” command, you can use “color0” through “color255” in place of “yellow”, “green”, “default”, etc. To see what color numbers represent what colors, try this Perl script:
print map sprintf(“ \x1b[38;5;%um%4u”, $_, $_), 0 .. 255
That prints each of the numbers 0 through 255 in its corresponding foreground color. It’s also a good test to see whether your terminal really supports 256 colors. To see the colors in the background instead, change “38” to “48”.
But even if that works, you might find that mutt still complains “color not supported by term”. That’s because mutt consults terminfo to figure out how to set the colors, and the entry it found doesn’t support that one. First, check your TERM environment setting. I use “rxvt-256color” — “rxvt” only supports 8 colors. Next, make sure that the entry exists in both terminfo and termcap. On FreeBSD, it existed in terminfo but not in termcap. Even though mutt (or slang) uses terminfo, mutt apparently checks termcap to see if the terminal is defined. I’ve submitted a PR to FreeBSD to get “rxvt-256color” added to the distributed termcap, but in the mean time you can patch it by adding the following lines:
rxvt-256color|rxvt terminal with 256 colors:\
Naturally, you only want to use colors 8 through 256 when you’re running on a terminal that supports them. Since I sometimes use mutt from a virtual console or SSH, I conditionally set up for 256 colors in my shell profile script:
export MUTT_COLORS=.mutt-colors`tput Co`
which sets MUTT_COLORS to either “.mutt-color256” or “.mutt-color8”. Then, in .muttrc:
which includes the file that contains all of my color commands.
But what colors? I use colors as signals rather than for aesthetics. Here are some of the commands in my .mutt-color256 file:
color header red default “^Importance: high”
(flag the header field for high-priority with red text)
color hdrdefault color241 default
color quoted color60 default
color status color30 default
The rest of the header fields are grey, the status information is a light grey-blue, and any quoted text is somewhere in between, so I can easily spot the meat of the message.
color index color227 default “~U”
color index color239 default “~D”
Unread items are colored a very bright yellow (I have a dark background), and deleted items are grey.
Mutt provides at least four ways for you to deal with attachments: you can view them, save them to a file, save them after converting them, or forward them to another address. When I first starting using mutt, I’d often opt for the fourth choice when someone sent me HTML mail or a Word attachment. But you can configure mutt to let you view these and other types of attachments by setting up a .mailcap file. Here’s mine:
text/html; firefox %s & sleep 5; test=RunningX;
image/*; qiv %s; edit=gimp %s; test=RunningX;
text/html; w3m %s; nametemplate=%s.html;
application/pdf; xpdf -q %s; test=RunningX;
application/ms-tnef; tnef -t %s && read ans;
application/msword; openoffice.org-3.2.1 %s; test=RunningX;
application/msword; antiword %s | more;
HTML emails are really “text/html” attachments. If I’m running X, I want to view those in Firefox. Otherwise, I use w3m. RunningX is a little utility that you can download and compile. For Firefox, I have to sleep 5 seconds, because otherwise mutt deletes the temporary file before Firefox can load it. Mutt will wait for w3m, because it uses the same terminal.
For Word attachments (“application/msword”), I use OpenOffice if I’m running under X, otherwise antiword – a nice little utility that renders Word files as text.
The MIME type “application/ms-tnef” is a Microsoft-specific wrapper for attachments. The tnef utility can be used to unpack or list the contents of these files. For viewing the attachment, I just list its contents. The “read ans” is so I have to press return to get back to mutt. That’s another cute mutt trick –- in my .muttrc I use
So mutt doesn’t make me press return after it successfully launches a subprocess – most of the time I want to go right back. But for the odd cases where I need it to wait, I add “&& read ans” to the command. If the command fails, mutt detects that and asks me to press return. If the command succeeds, then read makes me press return.
For extracting files from a tnef attachment, I added the following macro to my .muttrc:
macro attach \Ct “|tnef -–overwrite –C ~/Mail/attach\n” “Unpack TNEF attachment”
which maps Ctrl+T to extract all the files from the attachment into an “attach” subdirectory of my Mail directory, overwriting any existing file of that same name.