Dave's solution for disconnected mail handling

2006 Update: Moved to Mail.app

Goal

• Fast, easy local email reading - I run, or can login to, my own mail spool, or at least mount it via NFS and run unprivileged programs there. I want to be able to have life be fast while I'm connected. I like having my email client poll for new mail every 5 seconds. You get the idea.
• Secure Convenience - I don't want to type my password every 5 minutes, and I _certainly_ don't want my cleartext password stored in a textfile somewhere. I'd love a solution that interoperates with ssh-agent, since I already use that.
• Disconnected support for remote email reading. I want to be able to read my MIT email at home. If my network connection goes down, as it frequently does, or I take my laptop on an airplane, I should be able to still compose, reply to, delete, or re-file email. When I hook back up to my mail server, these changes should be properly synchronized with my spool(s), where new mail may have arrived, or I've even deleted mail there.
• Amazing re-synchronization efficiency not a priority. I'm not too freaked out about having to spend a few minutes now and then while my mail refiles, or whatever. Most of my life is spent with 128Kbps+ connectivity.
• Good search capabilities, while online or disconnected.

Solution

• Doesn't run an accessible IMAP server (happy for security reasons)
• Accessing mail via a local machine IMAP server is nearly as fast as accessing the files.
• Doesn't require a duplicated authentication step (convenient)
• Allows full offline reading and dealing with mail (the big goal).

The tools:

• Mutt, a very nice email reader. Use version 1.3 or later; IMAP support is vastly improved.
• UW IMAP - the code looks like crap, but it has the right set of features. More on this later.
• Isync.
• Mairix is the best mail searching program I've found. It's incredibly useful if you have large quantities of mail.

Step 1: Install UW-IMAP, carefully

If you already have uw-imap installed, note the location of your imapd binary (/usr/local/libexec/imapd on FreeBSD), and skip this step.

UW-IMAP is the de-facto reference IMAP server. It's had more remote security exploits than I'm comfortable with, and the code is almost impossible to read -- thus making it extremely difficult to audit, or trust.

Install uw-imap-2001a or later. Do not put an entry for it in inetd.conf or in any other way make it accessible on the network. Just note the location of the installed imapd.

You'll use the rsh mode of imapd to access it instead of the network.

Install mutt version 1.3 or later

Mutt configuration: Spool machine

set tunnel="/usr/local/libexec/imapd"
set spoolfile=imap://localhost/INBOX
set folder=imap://localhost/Mail
set timeout=5

Set the tunnel to the location of your imapd server. Instead of connecting over the network, you'll just run it locally. Fast and happy. Set the spool and the default mail save folders to use the IMAP space instead of the local dirs. Setting timeout to 5 is, perhaps, excessive - it causes mutt to check every 5 seconds to see if the current mailbox has been updated. Pick whatever value makes you happy.

Why use IMAP locally? If you refile messages between mail folders directly using Mutt, you'll store invalid X-UID headers into the wrong mail folders. When you then check your mail with IMAP, the IMAP server will decide that you've goofed up your mailbox, and renumber it for you, and change the IMAP uidvalidity identifier. Isync will then barf. You could accomplish this by having Mutt strip out the X-UID header on a refile, but this way is much more clean.

On your remote hosts

set maildir_trash

folder-hook ~A bind index $ <sync-mailbox>

folder-hook +INBOX 'macro index $ "<sync-mailbox>!isync -e INBOX\n"'

Install isync

Configure your .isyncrc:

Tunnel "ssh -C -q your.mail.server /usr/local/libexec/imapd"
MailDir Mail
Mailbox INBOX
Box INBOX
Mailbox mailbox1
Box Mail/mailbox1
Mailbox mailbox2
Box Mail/mailbox2
...

#!/bin/csh
set IS="~/.isyncrc"
set LIMIT=500
echo 'Tunnel "ssh -C -q eep.lcs.mit.edu /usr/local/libexec/imapd"' >> $IS
echo "MailDir Mail" >> $IS
echo "Mailbox INBOX" >> $IS
echo "Box INBOX" >> $IS

foreach i (ls -t ~/Mail/ | grep -v \.gz$' | head -${LIMIT})
  echo "Mailbox $i" >> $IS
  echo "Box Mail/$i" >> $IS
end

Run isync -L -a to populate your mail spool. When you want to synchronize, run isync -C -a -e -d, or synchronize a particular folder (MUCH FASTER) with isync -C -e -d foldername.

Install Mairix

.muttrc contains:
set record=+sent_mail

.procmailrc contains:
:0 c
$MD/received_mail

base=/home/dga/Mail
mfolder=search
database=/home/dga/.mairix_database
mbox=received_mail:sent_mail:received_mail.*

alias mm 'mairix \!* && mutt -f ~/Mail/search'

17,37,57 * * * * /usr/local/bin/mairix > /dev/null 2>/dev/null

Some related sites

• The Mutt website
• Mutt and IMAP
• Isync website

• I used to plug pobox.com for spam filtering, but these days, I'm much more in favor of having a good local spamassassin installation. The bayesian filtering will do a much better job than pobox does. Gmail's spam filtering is still in beta. I'd be willing to bet that Google can do a pretty incredible job at it once they put their minds to it. Pobox is better than nothing if you can't use SA locally, though, and it's still a very nice way to have a portable address. :)
• Spamassassin. Yum. Catches most of the rest of my spam.

Appendix 2: Thoughts about other mailreaders

elm

Just switch to mutt. I did extremely recently, and haven't looked back. The transition is trivial, and painless. Elm development is at a glacial pace, and the elm IMAP patches are questionable at best, with no disconnected support. Mutt has a vibrant user and developer community, and is constantly getting better.

VM

No offline IMAP (but I might be wrong; i was wrong on the previous IMAP support). VM is a beautiful mail reader, and I used it for years, but switched because I didn't think it supported offline IMAP. It does now, (and maybe did then), but I'm now pretty entrenched in Mutt.

Pine

Kick-ass IMAP support... unless you want disconnected operation. Would make a great way to read your mail remotely while the Internet is functional, though. Except that, well, it's pine, and I just kind of dislike pine. No real reason. If you're a pine fan, don't complain, just accept that I'm weird. Support for disconnected operation in pine has been "planned" for many years now. I'm not holding my breath.

Mulberry

Reportedly the best IMAP client out there. Coredumped on me, very frustrating to configure, no emacs/vi, huge GUI, doesn't seem to like my 301 mailfolders. May need more experimentation, but I'm not a fan thus far.

Ximian Evolution

Requires more extra installed packages than I have hard disk space for right now. Reportedly supports disconnected operation, though one of my colleagues reported that it coredumped on him after (correctly) resynchronizing after a disconnection. May try some day.