Hack and / - Take Mutt for a Walk

 in
Skip ahead on the mutt learning curve with real-life mutt configuration examples.

All of the color options follow the same syntax. First, the word color, then which object should be colorized and finally the foreground and background colors to use. I use default as my background color, so if I have a transparent window, the background is also transparent. You'll notice that the color options for the index (the mutt window that lists all of the messages in a mailbox) has an extra option at the end that lets you control what attributes it should match before it applies that color. For instance, in these two options:

color index	brightyellow default ~N	# New
color index	yellow default ~O	# Old

the ~N and ~O arguments match any new or old messages, respectively. You can use mutt's extensive matching language to match on all sorts of message attributes. In the above file, I provide a commented example for how to colorize a message based on its FROM: header.

Local Mutt Settings

As I mentioned earlier, I like to separate any settings that might differ between machines into a ~/.muttrc.local file. Here's an example of the settings you might want to keep there if you had all of your e-mail stored in a local Maildir folder:

# local mbox settings
set mbox_type=Maildir
set folder=~/Maildir
set spoolfile=+INBOX
set record=+sent-mail
save-hook . "+saved-messages-`date +%Y`"
mailboxes "=INBOX"

Here is an example .muttrc.local for a system that accesses mail remotely via IMAP:

set folder=imaps://mail.example.net/INBOX
set imap_user=username
set imap_pass=password
set spoolfile=+
set record=+.sent-mail
save-hook . "=.saved-messages-`date +%Y`"

Note here that I specify both the IMAP user name and IMAP password. If you want extra security, you will want to leave out the imap_pass option so your password is not in plain text. If no password is specified, mutt will prompt you when it connects to that IMAP server.

Mutt Mailboxes

After you define your main mail folder settings, you also will want to define any other mailboxes you have besides INBOX. I keep these mailboxes defined in ~/.mutt/mailboxes, and I should note that the order does matter here. Whatever mailboxes you define in your configuration files will be checked by mutt for new mail. When you tell mutt to change to a different mailbox, it automatically will fill in the mailbox name with the next mailbox that has new mail. I use this feature a lot, especially at work, as it allows me to make sure I go through all of the high-priority mailboxes with new mail first. Here is a sample mailboxes file. Note that the = sign tells mutt that these folders are off the main folder:

mailboxes "=linuxjournal"
mailboxes "=consulting"
mailboxes "=nblug"
mailboxes "=saved-messages"
mailboxes "=sent-mail"

Hooks

The final configuration file worth mentioning is ~/.mutt/hooks where I store all of my folder hooks and other settings. Hooks are a powerful feature in mutt that allow you to change your mutt settings on the fly based on your current folder, the recipient of an e-mail or contents in an e-mail when you reply to it. Hook syntax can get a bit complicated, so I recommend if you want to know more about a particular option, especially the index_format and folder_format syntax, that you reference the official documentation on mutt.org. Listing 3 shows a few example hooks I use to change how messages are sorted in some folders, tweak what signature to use on certain e-mail messages and even change my TO address when I reply to a message.

So there you have it. If your interest in mutt is piqued, these options should be more than enough to get you started. I also know that these settings won't appeal to everyone. That's the beauty of mutt—you can change the options until they do suit you. I still recommend once you get your base options configured that you spend a little time with the official documentation on mutt.org. There are many great examples and also many more options than I listed here that might solve a particular configuration problem you are having.

Kyle Rankin is a Systems Architect in the San Francisco Bay Area and the author of a number of books, including The Official Ubuntu Server Book, Knoppix Hacks and Ubuntu Hacks. He is currently the president of the North Bay Linux Users' Group.

______________________

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix