ScottLog

August 2, 2008

Managing Your Own Mail: Part 1 of Many

Filed under: Uncategorized — numist @ 12:00 am

Fitting that Brad recently posted a useful tip about how to use email properly, since in the last week or two I’ve decided to venture into the weird world of email and see what could be done.

The problem: I have a lot of accounts, I don’t want Google indexing all my mail and it would be nice to have some fine-grained control over it all. The solution where you just point your local mail client at all these accounts works well to a point, but what if you want to be able to access your mail from multiple locations, and the accounts don’t all support IMAP?

This post tries not to bite off more than people can attention-span: setting up mail delivery to your local host. Later posts build on this with things like message filtering and sending mail through your various accounts’ SMTP servers, resulting in a complete mail system you can actually use.

Starting off:

First off, install dovecot, fetchmail, postfix, and procmail. The default settings are fine for now.

  • dovecot: a mail server that knows many protocols and can do many things.
  • fetchmail: “why do they call it fetchmail?” “…because it fetches mail, Avi.”
  • postfix: handles mail delivery and routing for you.
  • procmail: handles mail when it’s on it’s way to being sent or delivered

Getting mail to your server:

fetchmail is a really handy tool that polls all of your accounts for mail and brings it locally. It supports POP and IMAP (including the IDLE state on IMAP), and aims to have a human-readable configuration. Here’s roughly what mine looks like, with only GMail configured:


# ~/.fetchmailrc
set postmaster "numist"
set no bouncemail
set no spambounce
set properties ""
set daemon 300
set logfile /home/numist/log/fetchmail.log
#set syslog

defaults proto pop3 options mda "/usr/bin/procmail -d numist"

poll pop.gmail.com
    user "numist@gmail.com" pass "psasword" is "numist" here
    options ssl sslcertck flush;

All the options in there are pretty well documented, and eminently findable with a simple web search, so we’ll move quickly through this. The main option to note is the mda option is set to `/usr/bin/procmail -d numist`, which just means “instead of delivering normally” (whatever normal may be) “pass the mail to procmail and it will handle delivery”. The mda option is defined in a defaults block, which means that unless otherwise specified, the options in that block will apply to all accounts in the fetchmailrc.

Which brings us to procmail:

procmail is a handy tool for manipulating mail as it goes from one place to another. A later post (or few) will take a much closer look at how to use it, but as a fairly simple example, this is way more than you need in your ~/.procmailrc file to make mail delivery work:


# .procmailrc
# mail recipes for processing incoming mail

# new to procmail?  you should check out:
# procmailrc(5)
# formail(1)
# procmail(1)
# procmailex(5)
# procmailsc(5)
# http://partmaps.org/era/procmail/links.html
# http://partmaps.org/era/procmail/mini-faq.html
# http://pm-doc.sourceforge.net/pm-tips.html
# http://www.ii.com/internet/robots/procmail/qs/

RC=$HOME/.procmail
SHELL=/bin/bash
MAILDIR=$HOME/Maildir
DEFAULT=$HOME/Maildir/

# set up vars
INCLUDERC=$RC/vars.rc

# set up logging
INCLUDERC=$RC/log.rc

LOG="Processing incoming mail from ${FROM}:
"

# Make an archival copy of every single message that comes in.
# XXX: a job in cron creates this directory for us every day at midnight.
:0 c
$HOME/mail-archive/`date +%Y`/`date +%m`/`date +%d`/

:0:
$DEFAULT

procmail is fairly simple. Things to note:

  • Anything starting with :0 is what’s known as a recipe.
  • The characters after :0 are flags, which have different meanings (which are well documented in procmailrc(5)).
  • Both of the recipes in this file are delivering recipes. the first operates on a copy, denoted by the c flag, and the second operates on the message itself, causing the script to terminate.
  • Syntax is somewhat like shell, but certain variables have special meanings; assigning a string to LOG causes it to be logged, and assigning a filename to INCLUDERC causes the file to be sourced.

There are a lot of gotchas to procmail, so reading lots of docs will help you (really, go read docs and find example recipes), but one thing you should know in the context of this file (and in the context of this post) is that when you deliver a message, you need to end the path with a /, which denotes that the directory uses the MAILDIR format. Read this through a couple times and make sure that you’ve got it. For completeness, here’s the two files that get included:


# vars.rc
# vim:set syntax=procmail:
# set up vars

# Subject: tabs to spaces, remove leading and trailing
SUBJECT=`formail -xSubject: | sed -e 's/[;\`\\]/ /g' \
        | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`
FROM=`formail -rt -xTo: | sed -e 's/[;\`\\]/ /g' \
        | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`

# These vars should really be split off into a conf of some sort...
NAME="Scott Perry"


# log.rc
# vim:set syntax=procmail:
# Set up logging

LOGFILE=$HOME/log/procmail.log

VERBOSE=off

LOG="
"

Note that LOG does not automatically add a newline. You have to do it yourself.

Getting mail to your client:

Now that you’ve got your mail on your server, you want to be able to get it to your local client. Enter dovecot. To get running quickly and easily, go to /etc/dovecot/dovecot.conf and make sure that protocols = imaps. You may need to scroll down to the ssl configuration section and make sure that ssl_cert_file = /etc/ssl/certs/dovecot.pem exists and is uncommented, as well as ssl_key_file = /etc/ssl/private/dovecot.pem. If you’re on Debian, those files have already been created for you. Beyond that, chances are good that dovecot is set up perfectly fine for your needs. Their documentation is really good, so head on over there if you have any issues. Customizing dovecot is outside the scope of this document.

What, that’s it?

Chances are you want to do more than just get your mail to your server (which is why you’re here), so stay tuned for future sections (coming soon?) which will include:

  • Sending mail through your server
  • Filtering spam
  • Filtering virii
  • Organizing your solicited bulk mail (mailing lists)
  • Filtering mail using a whitelist (and why that’s not the same as a greenlist)
Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: