skip navigation

Valid XHTML 1.0!

Valid CSS!

This page is standards compliant and Section 508 accessible

End of navigation

The Ultimate Email Setup

This is a HOWTO description of my ultimate email setup. Nearly everything I describe here is the "hard, but best" way to do things if you want the features I want.

The features I want in an email system are:

If these features are not important to you, a Gmail account is nice. Not much chance in Gmail going out of business, although if they eventually started charging to use Gmail it wouldn't be the first company to do this. My first free email account started charging after a couple of years.

No one but me should have possession of my email

This is one reason I do everything myself. Another reason is that I just like to know how things work and be able to add features at my whim.

I should never have to change my email address if I don't want to, even if I move or change ISPs

I accomplish this by owning my own domain name. To do this, you have to pay a "registrar" to keep your domain name current in the "root" list. I use 1and1.com, but there are plenty of good registrars out there. 1and1 has a bad reputation as far as customer service goes, but DNS registration doesn't have many things to go wrong, so I haven't switched yet. You should not need to pay more than $15 per year for a domain name. Once you own the domain name, you need to have a computer somewhere on the internet that can tell other computers where to go if they want to send you an email. This is called a DNS server, and you can:

I should not get much spam, even if I use usenet, mailing lists, and post my email address publicly

My main consideration when it comes to spam fighting is that there be no possibility of "silent false positives". A silent false positive is when

A silent false positive will invariably turn out to be a job offer, or a long lost friend trying to get in touch. One silent false positive is too many. There are two good spam-fighting techniques which have no possibility of silent false positives, but they both require that you run your own mail server:

  1. The anti-spam technique called greylisting is about 60-80% effective, and has no false positives if the sender retries correctly (and any sender that doesn't retry is going to lose a lot of mail anyway). It works like this: when an email server somewhere else on the internet contacts your mail server to send you a mail, your mail server says "hold up a while, I need to rest or something". Your server than blocks contact with that other server for a while. After that, your server allows the foreign server to deliver the mail like normal. The reason this works is that most spammers are extremely impatient; they set up their servers to try only once. Some people have told me they had problems with greylisting, and they believe that legitimate email was being lost. There are only two ways this can happen: if the greylist program has a bug or if the sending mail server is broken. Whether this is an acceptable risk is up to you.
  2. If you do you spam identification while the SMTP transaction is in progress (before the SMTP transaction is complete) you can reject emails identified as spam without accepting the email. This means the sending server is still responsible for the email, and what will happen is that the sending server will send the message back to the sender in a bounce, with your rejection message added. I put my voicemail number in the rejection message so that someone who gets falsely rejected will have another way to contact me (even though this is a very unlikely scenario given my rejection threshold). To accomplish this, I use a combination of Postfix, Amavis-new, and Spamassassin (with the DCC and Razor plugins). I used this very long tutorial as a guide, although I didn't have to do 95% of the things in the tutorial because Debian did a very good job of packaging those three programs.

To keep web spiders from collecting my email address off my web site I wrote a bot trap.

I should be able to have as many email addresses as I want without extra cost

I should have no limits on attachment size

I should have no limits on the number of emails I can save

I accomplish the previous three by running my own email server. I like Postfix, but other people like Sendmail, Exim, or others. Postfix is definitely the most recommended mail server at my local Linux Users' Group.

My mail should be stored in a simple text format

I use the Maildir format. It works well with the other utilities I use. Each email is a text file with a unique name, and you don't have to worry about locking or other problems that the traditional mbox mail format has. You can use any backup utilities and it is resistant to corruption, unlike database or compressed mail formats.

I should be able to filter incoming email into folders automatically

The procmail program is a very powerful but very cryptic program for filtering incoming email. However, the formula to filter to a folder is easy enough to copy. For example, if you want to send all emails that have "mutt-users@mutt.org" in the headers to a Maildir folder "lists/mutt", use this in your ~/.procmailrc file:

:0:
* ^.*mutt-users@mutt.org
/home/user/Maildir/lists/mutt/

My mail reader should be very fast, text-based, and keyboard-based

Mutt is without doubt the best mail reader out there if you think email should be text. It is very fast, very flexible, and completely stable. It is text and keyboard based, so you can go through a lot of email very quickly. It takes a while to configure and learn, but if you have a good starting point it's a lot easier. Here is my .muttrc configuration file.

Some extra options I have added to mutt to make it more powerful:

I should be able to read my email from any web browser in the world

If I'm traveling and can't get a console to use Mutt, I like the web-based mail reader IlohaMail.

You need to be running your own web server to do this. Like most people, I use the Apache web server, and it's awesome. Here is the configuration snippet in the Apache configuration so that http://mail.danielwebb.us accesses my email from any web browser using a secure SSL connection:

# Redirect mail.danielwebb.us to SSL version
<VirtualHost *>
  ServerName mail.danielwebb.us
  Redirect permanent / https://mail.danielwebb.us/
</VirtualHost>

<VirtualHost _default_:443>
  ServerName mail.danielwebb.us
  # Only serve webmail over SSL
  Include /etc/IlohaMail/apache.conf
  DocumentRoot /usr/share/IlohaMail/source/

  SSLEngine on
  SSLCertificateFile /etc/apache/ssl.crt/server.crt
  SSLCertificateKeyFile /etc/apache/ssl.key/server.key
</VirtualHost>

You also need to have an IMAP mail server running for IlohaMail to work. I use Dovecot, and I'm very happy with it after being disappointed with problems I had with the IMAP server most people use, UW-IMAP. The only thing I don't like about Dovecot is that it forces you to use its naming scheme for your Maildir folders. As far as I can tell, there's nothing in the Maildir specification that says the folders should be named a certain way, but several Maildir clients seem to think that's true. For example, for the Maildir folder ~/Maildir/lists/mutt, Dovecot thinks it should be ~/Maildir/.lists.mutt. dovecot-links is a script I wrote to create symbolic links to my folders in the way Dovecot likes. You'll need to edit it to fit your system, but the basic idea will be the same. Do not run this script without reading and understanding it!

I should be able to search all my email by keyword in a few seconds

Mairix is a terrific email search engine that can search through tens of thousands of emails in seconds. The ~/.mairixrc configuration file is very straightforward. My muttrc file contains a link to mairix-search, an interface script I wrote that calls mairix. Mairix searches all the folders at the same time, which is great. However, sometimes I want to know which folder a resulting email came from, and so mairix-search adds a header with the folder each email is in. This slows the search down proportional to how many results are found, so you can edit the settings in the mairix-search script to not do this for searches with more than a certain number of results.

Email older than a certain number of days should be automatically moved to an archive

archive_mail is a script I wrote that moves any mails older than a certain number of days into my mail archive. It is still searched by mairix and easy to open in Mutt, I just do this so that mailboxes with new mail open very fast in Mutt. You'll need to edit it to fit your system.

I should get RSS news headlines in my email

I use rss2email to send RSS headlines to my email. Each email contains the article headline as the subject, and the body contains the short summary and a link to the actual article. This allows me to scan 200 or so headlines each day for the few I'm interested in in about 5 minutes. I use procmail to deliver headlines from rss2email to their own folder. Rss2email is very easy to set up and just keeps working.

I should be able to receive faxes in my email

I use k7.net to receive faxes (and voicemails) in my email. They are free and have been around since 1999, and you get your own direct-dial number. See my recommendations page for more info on k7.net.

I should be able to send faxes through email

There are many commercial providers of this service, here is a good list of commercial fax providers.

I evaluated all the providers in the list above and chose FaxItNice. They have a minumum initial credit of $20 and charge $0.18 per page, with no setup fee or monthly fees. Two other options that looked good to me were FaxAway ($1 per month + $0.11 per minute) and GreenFax ($10 setup fee + $0.07 per minute).

A free provider of outgoing email to fax is TPC Remote Printing Service. This is a network of volunteers in most parts of the United States and much of the world who allow you to use their outgoing fax line in their area. To send scanned images through TPC, you need to get a client that can send to TPC. On Linux you can try FaxMail. Unfortunately, I never got TPC to work so I went with a commercial provider.