Colorizing messages in mutt index

I’d heard a long time that if I’m a self-respecting Linux or UNIX geek I should use a terminal-based email client. My options are Alpine and mutt, and it seemed that while mutt was the hardest to get up and running, it was also the most flexible and powerful. I have drunk the Google Kool-Aid, so I had been loath to switch from Gmail, my workflow habits (in both personal and work Gmail) depending on certain features.

The first feature of Gmail (available in the “Labs” section) that I used very heavily was the multi-colored stars feature. At home, I use six different stars (green-check, yellow-bang, red-star, blue-info, purple-question, and green-star, in this order). At work I use eight (these and yellow-star, and blue-star). One thing I always hated about Gmail, is that I had to repeatedly click on the empty star icon in Gmail to cycle to the star I wanted. For seldom-used stars, this meant that I might not remember where it is in the list, so I’d accidentally cycle past it, sometimes multiple times until I got the star I wanted. Another problem with these stars is that they don’t translate to any other mail client. It would be really nice if Google would add something like “X-Gmail-red-star” or something to the email headers, but that isn’t what happens now (not sure if that would violate an RFC).

The other feature I use is the priority inbox, which separates the inbox into “Important and Unread,” “Starred,” and “Everything else.” I use this especially at work to help me triage email. I get a lot of stuff which isn’t junk, but that isn’t addressed (To: or Cc:) to me, so I don’t read it. All messages To or Cc’d to me get an automatic star (Gmail only has the capability to add yellow-star to messages automatically, something I hope to rectify with mutt. One day….).

The only thing I’ve figured out how to do in mutt thus far is at least a first stab at achieving the multi-colored stars feature. This time, it’s all tied to key macros, so no having to cycle through until I find the color I want. The way it works is through mutt’s scoring feature. At least for now, each score range (100-199, 200-299, 300-399, etc.) gets set to whatever color that score range gets. Whenever I run the macro to color a message, I pipe it (<pipe-entry>) into a bash script I wrote which greps for the Message-ID, filters out the Message-ID’s angle brackets (‘<' or '>‘), adds the relevant score, and then writes a score configuration command to a separate rc file (~/.mutt/stars). Then, I have mutt reload it’s configuration (thankfully score isn’t something that requires a complete restart).

First, the section of .muttrc I have for stars:

# Star scoring 
source ~/.mutt/stars

set my_red_star = 1000
set my_magenta_question = 800
set my_yellow_bang = 600
#set my_green_star = 400
set my_green_check = 200
set my_blue_info = 100
set my_del_star = 0

macro index,pager sr "<pipe-entry>~/bin/stars $my_red_star<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with RED"
macro index,pager sm "<pipe-entry>~/bin/stars $my_magenta_question<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with MAGENTA"
macro index,pager sy "<pipe-entry>~/bin/stars $my_yellow_bang<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with YELLOW"
macro index,pager sc "<pipe-entry>~/bin/stars $my_green_check<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with GREEN"
macro index,pager si "<pipe-entry>~/bin/stars $my_blue_info<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with BLUE"
macro index,pager sd "<pipe-entry>~/bin/stars $my_del_star<enter><enter-command>source ~/.muttrc<enter>\
<enter-command>source ~/.muttrc<enter>" "Remove color marking from the current message"

color index default brightred '~n 1000-1100'  # Mark the message with red!
color index magenta default '~n 800-999'  # Mark the message with magenta!
color index black brightyellow '~n 600-799'  # Mark the message with yellow!
#color index default green '~n 400-599'  # Mark the message with green!
color index green default '~n 200-399'  # Mark the message with green (check)!
color index brightblue default '~n 100-199'  # Mark the message with blue!

And my stars script:

msgid=$(grep -m 1 '^Message-I[Dd]' | awk '{print $2}' 
                                   | sed 's/[<>]//g')                                                                                                                                                                                        
echo "score \"~i $msgid\" $1" >> ~/.mutt/stars       

My delete stars (del_stars) script (which doesn’t work all the time, but I haven’t been able to investigate why):


msgid=$(grep -m 1 '^Message-I[Dd]' | awk '{print $2}' | sed 's/[<>]//g')
sed -i "/$msgid/d" ~/.mutt/stars

Now the stars script doesn’t always work, either. I think I’ve tracked it down to Message-IDs which use nonalphanumeric symbols in them (like pipe ‘|’ and dollar-sign ‘$’). I might not be quoting the “~i $msgid” correctly (single-quotes, maybe?). Not terrible for a first stab at this. I wonder if any old mutt hands will have a fit if they see this, but I’m too tired to investigate further. It works well enough for my purposes right now. Also, I don’t know the performance ramifications of an ever growing ~/.mutt/stars file. We’ll have to see how that goes.

Setting up exim4 for Google Apps SMTP in Debian Wheezy

Whenever I install a new system, I always have to look up how to set my servers and workstations to use Google’s SMTP server for sending outbound mail. At Digium I just used the Zimbra server, and it was simple. For my VPSes, workstations, and laptops, it’s more complicated. Nonetheless, it’s still straightforward to set up Google Apps’/GMail’s SMTP as my smarthost.

  1. exim4 should already be installed. To set it up to use Google’s SMTP server, run the following command:
    dpkg-reconfigure exim4-config
    1. The first choice is the “General type of mail configuration.” Since this server (and all of my workstations/laptops) don’t process any local mail, I chose “mail sent by smarthost; no local mail”.
    2. I used my system’s hostname as the system mail name (in this case, it was “betachunk”).
    3. For the IP address or hostname of the outgoing smarthost, I used “”
    4. I chose not to keep the DNS queries minimal, since most of my systems have an “always-on” connection.
    5. I decided not to split the configuration file into small files, to keep the system robust (small files can introduce breakage).
    6. I set the root and postmaster mail recipient to be my email address,
  2. Now that exim4 has its basic configuration, I can add my credentials.
    1. First I edited /etc/exim4/exim4.conf.template, and added the following after the line “.ifdef DCconfig_smarthost DCconfig_satellite”:
      send_via_gmail: driver = manualroute domains = ! +local_domains transport = gmail_smtp route_list = *

      …before the very next “.endif”.

    2. I then searched for this comment, and added the gmail_smtp section below it:
      ### transport/30_exim4-config_remote_smtp_smarthost ################################# ###### # GMail smtp gmail_smtp: driver = smtp port = 587 hosts_require_auth = $host_address hosts_require_tls = $host_address
    3. Next, I searched for “begin authenticators”, and added a section for gmail_login:
      begin authenticators ######### # GMail SMTP gmail_login: driver = plaintext public_name = LOGIN client_send = : :

      If you don’t use GMail’s two-factor authentication, you can substitute your actual GMail password there. Note that I use a dummy GMail account for all of my SMTP services, I don’t use my primary Google Account.

    4. Finally, I had to comment out the “login:” section at the end of the file since it conflicts with the gmail_login section (“public_name = LOGIN” can only appear once in the file).

    And that’s it for exim4.conf.template.

  3. I didn’t add anything to /etc/exim4/passwd.client.
  4. Finally, I could run the following commands to load the configuration:
    update-exim4.conf service exim4 restart # a reload may be sufficient

That’s it for the configuration. To test, I used the “mail” command from the shell:

mail Subject: Test Alpha Alpha Test .

That should send the message to my primary email address. If all goes well, I should receive a message with subject “Test Alpha” and body “Alpha Test”. When I was writing these instructions, I was configuring betachunk so I could document it as I went. It almost never happens, but this time the first test message got sent correctly, with no further configuration or troubleshooting necessary.

A note on my SMTP service testing: I use the Greek alphabet to label the test messages. I always start with alpha. I also start a running tail “tail -f /var/log/exim4/mainlog”, so I can verify that the system tried to send the message. Once I see the message has been sent successfully, I refresh my GMail inbox until the message arrives, completing the circuit. In this case I checked the email headers (“show original” in Gmail) to ensure it came from betachunk.

Should mainlog show an error, I investigate the problem, making the requisite changes. Then I send the next message, with the next Greek letter. Unfortunately my recollection of the Greek alphabet is rather spotty, so after the first five or six letters I just pick them at random.

And there you have it! Hopefully I won’t have to do this again for a while.