Taking (back) control of my email

The first thing you need to do, is to install the packets. I'm going to assume you're in arch, but replace the commands with your own package manager from your distro:

sudo pacman -Syu dovecot postfix spamassassin pigeonhole

With that done, you can now head to the configuration. I mostly followed the arch wiki for postfix and dovecot. Below are the most important details that might not be exactly the same as in there.

I also used virtual users/domains and followed a very similar scheme as to the one described in the arch wiki for Virtual mail user system (I didn't install roundcube though, I didn't want a web ui on my machine).

I decide to use virtual users, but unlike the wiki docs for arch, my database would be just a regular hash-file with the emails. This is my section to cover that:

virtual_mailbox_domains = /etc/postfix/vhosts.txt
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmaps.txt
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/valias.txt
virtual_transport = dovecot

You will need to create the vhosts.txt, vmaps.txt and valias.txt as specified in the wiki.

I'm using static uid & gid because all email will live under the user & group vmail, that has an id 5000 (created previously). Its home is under an encrypted zfs dataset, and this is where all the mail is created. The last line in that section tells postfix to use dovecot to finally deliver the email. In my case, I'm using LMTP.

In the master.cf file, the only thing I changed from the default, was the addition of the dovecot entry, including spamassassin:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/bin/vendor_perl/spamc -u spamd -e /usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient}

I pretty much followed the instructions in the Arch wiki, however when generating the dhparam, I used openssl with the -dsparam option to avoid waiting forever on my rpi3 (more info about this in this question on SO), like this:

opennssl dhparam -dsaparam -out /etc/dovecot/dh.pem 4096

To create a user password, you would use something like this:

doveadm pw -s crypt -u user@domain.com

And add the result to /etc/dovecot/users in the right format:

user@domain.com:<password-hash>

In order to activate auth-passwd for dovecot, you need to un-comment the right section in 10-auth.conf and then edit auth-passwdfile.conf.ext. Mine looks like this:

passdb {
  driver = passwd-file
  args = scheme=CRYPT username_format=%u /etc/dovecot/users
}

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/home/vmail/%d/%n
}

This file also tells dovecot to use the /etc/dovecot/users file for password authentication, but the user config is "static", in this case all users will have the same uid and gid, as well as home location (you can use Variables in there as you can tell from my config).

At this point, you should be able to reconfig your mx dns settings and point them to your new server. If you send a test email from another server, you should be able to receive it, and it should arrive in /home/vmail/domain.com/user. Dovecot should create the root Maildir in the users' home and you should also be able to connect to your IMAP server using a regular Email client: I tried iOS Mail.app and Wanderlust, but pretty much any client should work.

Something you should do, is to make really sure your SMTP server (postfix) is not an open relay, otherwise it will get abused by spammers. This should be simple: just restrict relay from everyone, except authorized (logged in) users. To achieve this, this is my config (in main.cf):

# only trust our local machine for relay
mynetworks_style = host
myorigin = $mydomain

# SASL through dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

# relay settings
smtpd_sender_restrictions = permit_sasl_authenticated,reject_unauth_destination

With those settings, you should be able to auth to the SMTP server, it should use dovecot (as noted by the smtpd_sasl_type), but there's one thing you need to change in the dovecot config to reflect that, you need to tell the dovecot's auth server to use a local unix socket, in 10-master.conf:

service auth {
  unix_listener auth-userdb {
  }

  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
  }
}

If you restart dovecot and postfix at this point, they should be able to talk to each other. One hint in debugging things, if you're using systemd to orchestrate everything (and you should), you can open the logs for both dovecot and postfix in two separate terminals while debugging your server:

# open logs (and follow) for dovecot
journalctl -f -u dovecot.service
# open logs (and follow) for postfix
journalctl -f -u postfix.service

Having them open and checking while I was trying to login and send test emails helped me a lot.

While you should be able to receive email, with the setup so far, you will not be able to send anything: remember that relay was closed. To fix this, and to make sure that whoever is sending email is a trusted service, I recommend using a third party server that knows how to handle outgoing mail: you can select from many providers, including Gmail if you want. In my case, I opted for AWS Simple Email Service (SES), because I was already using other AWS services from them. The setup should be similar, given that the provider allows sending email through an authenticated smtp server.

In your postfix's main.cf, you should add something like this:

relayhost = [email-smtp.us-east-1.amazonaws.com]:587
smtp_sasl_auth_enable = yes
smtp_tls_security_level = encrypt
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = $smtp_sasl_security_options

What this is doing, is configuring postfix to use SES for relaying, turning on SASL on the smtp protocol, making sure we use TLS, letting postfix know where to find the password for sasl auth when connecting to a smtp server that requests authentication.

The /etc/postfix/sasl_passwd file looks something like this:

[email-smtp.us-east-1.amazonaws.com]:587 username:password

Both username and password are in plain text, so make sure the file is owned by root and chmod 0600. I tried to use dovecot's auth for that as well but I was not successful. Maybe in the future ^_^.

Up to now, you can receive email, it will be scanned by spamassassin (you should check the headers of your email, they should contain something like this: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on alarmpi). But everything will still arrive in your Inbox. In order to take action on that, you can use something like Sieve.

Dovecot supports Sieve through pigeonhole, you should have this already installed from the first part of this post.

You can go super fancy with filters: having global filters that act on all of your users' emails, vacation responders, whitelists, etc. You can also have a per-account filter (just a single file in your virtual user home) and that will be triggered every time you receive email. That's the approach I went for simplicity (I only have one account, my own personal one) and it makes it easy for me to add/remove things as I want.

To enable Sieve support in dovecot, you need to modify the corresponding config, in my case it was 90-sieve.conf:

plugin {
  sieve = file:~/current.sieve
}

This is telling Dovecot that if there is a file named current.sieve in the user's home (virtual user home, in my case /home/vmail/domain.com/user), try to use that as the active sieve filtering script.

My script is basically filtering for spam, and also some sort of white-list: only specific users go directly to Inbox, the rest (if they're not spam), go to Inbox.Other:

require ["fileinto", "reject", "mailbox", "imap4flags"];

if header :contains "X-Spam-Flag" "YES" {
  addflag "\\Seen";
  fileinto :create "Spam";
} elsif not address :is "from" ["m@rolando.cl", "user@domain.com", "user2@domain.com"] {
  fileinto :create "INBOX.Other";
}

Writing Sieve filters can be tricky at first, but they are super helpful. You can find a bunch of examples in the Dovecot documentation.