<<< Date Index >>>     <<< Thread Index >>>

Re: mutt webmail



On Sat, Jul 09, 2005 at 11:18:29PM -0500, Dan Nelson wrote:
} In the last episode (Jul 10), R.B. Boyer said:
} > I've been wondering if there are any developmental efforts being done
} > to make the mutt email-parsing library more usable by other programs?
} > 
} > I was trying to write a program that would let me browse my Maildirs
} > in read-only mode for times when I just need to see the mail message
} > in something other than a command line: a local webmail.  If I could
} > interface with portions of mutt's processing code through a 'standard
} > channel' that would be very useful.
[...]
} Or you could take the easy way out and install one of the dozens of
} already-written webmail programs :) I don't know how common Maildir
} support is.

I'd go with this. It seems that it is more common for a webmail system to
support IMAP rather than any on-disk format, which makes a great deal of
sense when you think about it. To this end, I use courier-imap and
squirrelmail. The only on-disk format courier-imap supports is Maildir,
conveniently enough, and squirrelmail interfaces with it nicely. My mail
system includes (note that these are Debian package names):

exim4 for local (Maildir) and smarthost mail delivery
fetchmail for mail retrieval (port 25 is blocked by my ISP anyway)
spamassassin (running as spamd/spamc) for spam filtering
procmail for mail processing and running through spamassassin (spamc)
mutt for local mail reading
courier-imap for local network mail reading (mostly for my wife)
stunnel4 to provide IMAPS for non-local network mail reading (forwarded
        through NAT)
squirrelmail for webmail
apache2 to host squirrelmail
stunnel to provide HTTPS to apache2 (forwarded through NAT, and port
        80 is blocked by my ISP anyway); this is different from the IMAPS
        tunnel in that I am handling both SSH and HTTPS on port 443 using a
        little homegrown traffic discriminator server running from inetd
        (inefficient, but fine given the minimal traffic I deal with)

Yes, I know that I could use courier-imap-ssl to provide IMAPS instead of
stunnel4, and maybe someday I'll bother. For now, stunnel4 is really easy
to configure. Also, while I've been reasonably happy with squirrelmail I'm
sure that other people can recommend other webmail clients they prefer. I
simply don't use webmail very often, so it's sufficient for my purposes.

Note on mailbox cleverness/foolishness: I actually have three accounts
receiving mail for me. They all have the same UID, but different home
directories. One is what all local alert messages (e.g. anything to root)
go to, which require no spam filtering, and its ~/Maildir is a symlink to
my real ~/Maildir/.alerts. Another is for my list mail (many lists, not
just mutt-dev), which actually passes through GMail and is retrieved
over SPOP by fetchmail; its ~/Maildir is a symink to my real ~/Maildir, but
its .procmailrc delivers mail to ~/Maildir/.lists after spam filtering (it
also shares its ~/.spamassassin directory with my real account). Finally,
my real account receives personal mail fetched via SPOP from a mail
provider I actually pay. I'm just as happy to have public list mail pass
through the index-everything hands of GMail, but I prefer a slightly larger
measure of privacy for personal correspondence. All three primary mailboxes
(~/Maildir/.alerts, ~/Maildir, and ~/Maildir/.lists) are listed in the
mailboxes line in my .muttrc, so it's easy to read them all.

Anyhow, just thought I'd share how I solved the problems of what I expect
is a fairly common situation. YMMV.

}       Dan Nelson
--Greg