Take the 2-minute tour ×

I would like to get rid of Google as an email provider, and set up a complete email solution on my dedicated server. The issue: I wish the setup to be as simple as possible, so that it wouldn’t be a pain to set everything up again if there is a problem.


  • Only one user account on the machine.
    • (name’s diti; main e-mail kra@diti.me; other aliases get redirected but an e-mail client can manage the different aliases and react accordingly)
  • Preferably doesn’t use MySQL.
    • (in case of data backup & restore as well as for simplicity’s sake, it’s better if one has not to install & secure MySQL before getting a functional e-mail server)
  • E-mail can be accessed (IMAP and SMTP) from the outside.
  • SSL/TLS encryption for IMAP and SMTP authentication (I’m using CAcert certificates, does it matter?).

I believe that simplicity, IMAP/SMTP access, and secure auth, are the “basic” features that everyone eager to leave Google/whatever else, would want to. If I am mistaken and there is a simpler solution (for instance, an ownCloud-like solution, with everything included), I would be happy to hear.

I think the combination of Postfix and Dovecot would be the way to go. By the way, I am running Debian.

The info I’ve found so far

  • A French article describes in very long details how to set up a complete, secure e-mail solution. It is long, harder to maintain, harder to backup & restore, etc. Besides, is a DNS cache necessary?
  • The Gentoo wiki (Complete_Virtual_Mail_Server/SSL_Certificates page) mentions the use of CAcert certificates, but is neither clear about it (are all those SubjectAltName subdomains necessary?), nor it does use Postfix (I’ve read that Courier is more difficult).
  • Various tutorials about self-hosting, all different, rarely describing what they are doing and why (self-hosted e-mail with remote access seems complicated to set up, so why just providing a list of commands without explanation for “dummies?”).

I hope I have asked the right things, and that they are not too silly.

share|improve this question

closed as not constructive by Canadian Luke, techie007, Olli, Dave M, Brad Patton Jun 12 '13 at 19:32


Any idea how this question could be rephrased and reopened? –  Diti Mar 13 at 20:25
add comment

1 Answer

up vote 10 down vote accepted
  • No, it is not required to set up a DNS cache on the server. The server should use a caching DNS resolver that's somewhere nearby, but most hosting companies already run their own resolvers for the entire datacenter and configure servers to use them by default.

  • By default, both Postfix and Dovecot use local accounts for everything. If you have a Linux account named diti, you can log into Dovecot with it, and you can set up Postfix to validate SMTP logins against Dovecot.

  • If you are fine with making all mail go to the same account, you can set up plain aliases (as in, /etc/aliases) to redirect mail for kra@ or postmaster@ to the diti account.

  • All those subjectAltNames are not necessary. The only ones you need is for domain names you're going to actually use, e.g. mail.diti.me or glaux.diti.me. I'm not sure if you need to include the domain itself (i.e. diti.me).

The following assumes that the domain already has MX records configured to point at this server. I generally try to keep my configuration reasonably clear, since I always end up wondering "what the hell is this for" a few months later.

1. First, install the postfix and dovecot-imapd packages. When prompted about Postfix configuration, select the "Internet Site" option and enter diti.me as the mail name. At this point, you can already send and receive mail as diti@diti.me, and probably even connect to IMAP.

However, it doesn't yet have SSL, nor allow sending mail over SMTP from the outside, nor a sane place to store mail (the default is a mbox file in /var/mail, which is unreliable and gives bad performance, especially with IMAP).

2. If you already have a SSL certificate, put it in /etc/ssl/private/diti.me.pem, and the private key in /etc/ssl/private/diti.me.key. The exact location doesn't actually matter, but /etc/ssl/private is where Debian keeps them.

Make sure both files are owned by and readable by the ssl-cert group, so that Postfix and Dovecot could access them. Also add both daemons' accounts to that group using gpasswd -a.

3. Debian's auto-generated Postfix main.cf is a bit of a mess, too, so I'm going to just post a cleaned-up minimal version:

# Server information
mydomain = diti.me
myorigin = $mydomain
  # Various other parameters use these two variables as default values.

# SMTP service
smtpd_tls_security_level    = may
smtpd_tls_cert_file         = /etc/ssl/private/diti.me-mail.pem
smtpd_tls_key_file          = /etc/ssl/private/diti.me-mail.key
  # This allows STARTTLS to be used on all incoming SMTP connections.
  # Note that `postfix` must be added to the `ssl-cert` group to be able
  # to access files in /etc/ssl/private.

# Policies
mynetworks = [::1]/128,, [::ffff:]/104
  # This lists the IP addresses that are considered "trusted" and can use
  # this server to send mail to the outside (i.e. to other domains). By
  # default, only "localhost" is allowed. From everyone else only mail to
  # domains in $mydestination will be accepted.
mydestination = $mydomain, localhost
  # List of domains to accept mail for, from any IP address.
# Delivery
alias_maps = hash:/etc/aliases
  # This keeps system-wide aliases. It's good to set it explicitly because
  # the default value sometimes includes NIS, which doesn't make sense.
recipient_delimiter = +
  # Tells postfix to split the local part of addresses at the first '+',
  # so-called "plus-addressing": mail sent to diti+foo@ will be delivered
  # to the diti@ mailbox.

For Dovecot, Debian just uses the default example configs, and they are good enough, with each option described.

Whenever you change the configuration, reload daemons with postfix reload and/or doveadm reload.

4. By default, Postfix delivers mail to /var/mail/$USER in the mbox format, which is simple enough (you can easily view it with a text editor) but has many problems, especially with IMAP, since the entire file has to be rewritten whenever you move a message or even mark one as "read" or "unread".

Change both daemons to use Maildir. (There are other formats, but they tend to be specific to the MTA or MDA or IMAP server or whatever; Maildir is widely supported.)

In /etc/postfix/main.cf, add the following to the "Delivery" section:

home_mailbox = Mail/

Configure Dovecot to use the same path, in /etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir:~/Mail

5. At some point, you need to tell Dovecot to use SSL as well. The relevant settings are in /etc/dovecot/conf.d/10-ssl.conf. In fact, the Debian package for Dovecot already uses SSL, although with a self-signed certificate that is mostly useless. Configure it to use your own certificate:

ssl = yes

ssl_cert = </etc/ssl/private/diti.me-mail.pem
ssl_key  = </etc/ssl/private/diti.me-mail.key

6. Now you can send mail to outside and receive it. It's still necessary to configure Postfix to allow you to send from outside by connecting with your mail client over SMTP.

First tell Postfix to use Dovecot to verify logins. The following instructions are mostly taken from Dovecot's wiki.

Dovecot's /etc/dovecot/conf.d/10-master.conf needs to listen on a socket that Postfix could access; the default configuration already has a commented-out example:

service auth {
    unix_listener /var/spool/postfix/private/auth {
        mode = 0660
        user = postfix
        group = postfix

And Postfix needs to use it – /etc/postfix/main.cf again:

# Authentication
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
  # The other possible type is "cyrus", for the Cyrus SASL 'saslauthd'
  # daemon. I choose Dovecot here since it works well as a SASL server, and
  # it is just simpler to let it handle authentication for both daemons.

7. Notice that the above did not set smtpd_sasl_auth_enable anywhere. The current convention is to not enable SMTP auth globally, but to keep tcp/25 purely as a "server-to-server" SMTP port. Meanwhile, new messages from users are accepted over SMTP on tcp/587, the "mail submission" port, which requires authentication. Some ISPs even block tcp/25 because of spam, but keep tcp/587 open since it is usually better-secured.

Enable the "Submission" port in /etc/postfix/master.cf, with SASL auth. The default master.cf already has the necessary lines that just need to be un-commented, although some of them should still be left out.

submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
    # The "Submission" port will require TLS, instead of making it optional
  -o smtpd_sasl_auth_enable=yes
    # ...as well as allow users to log in.
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
    # These four options can be left commented out; if enabled, they would
    # expect you to set custom restriction rules in 'main.cf', but the
    # default ones are just fine.
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
    # The default recipient_restrictions check the IP address and
    # $mydestination. For the "Submission" port, allow everything as long
    # as the user is logged in, but reject all anonymous mail.
  -o milter_macro_daemon_name=ORIGINATING
    # I'm not quite sure what this does.

If you have a mail client that requires an old-style "implicit SSL" port (tcp/465), you can uncomment the smtps lines in master.cf – if you do, keep the settings similar to the submission port ones.

8. Finally set up aliases for your account, by editing /etc/aliases. The postmaster alias is basically required; it's the point of contact if there are problems with your mail server. Pointing root and other similar aliases is good too.

The basic format is documented in aliases(5):

postmaster: root
admin:      root
root:       diti
kra:        diti

Use postalias or newaliases to update the hashed database /etc/aliases.db every time you edit this file.

Now, you still have one account called diti as far as Postfix and Dovecot are concerned, but mail sent to kra@... is also forwarded there. Some mail clients (e.g. Thunderbird) support multiple "identities" or "personas" for a single mail server, so you can select between different "From:" addresses.

That's about it. I might return with instructions for procmail, virtual domains, SPF, and/or DKIM later.

share|improve this answer
This is great! It really is the simplest tutorial about e-mail self-hosting. The part that amazed me the most was to see, at point 1, that I could indeed already send and receive e-mails from/to my server. Anyway, I will edit your message to clarify some points too! However, I cannot manage to setup my e-mail from the outside (I mean Thunderbird). I am using mail.diti.me (= the IP address of my server) for both IMAP and SMTP, my domain already has the MX records. Have I done anything wrong during the setup of my server, or do I just have Thunderbird issues? –  Diti Jun 13 '13 at 1:31
@Diti: Looks like all relevant ports (except for tcp/25) are firewalled at your server. –  grawity Jun 13 '13 at 10:44
What should the output of ps auxw | grep "dovecot" be? I compared against one of my friends’ complex setup, and he has dovecot-auth and imap-login that I don’t have. Could it be possible that the ports are actually open (I do not recall myself using a firewall), but with no daemon set to listen to those ports from the outside, or something? When I run openssl s_client -connect mail.diti.me:993 on the server, it works (and says “Dovecot ready.”), but nothing from the outside. Maybe I should try to install a firewall and explicitly allow those ports? –  Diti Jun 15 '13 at 13:35
@Diti: Dovecot's architecture changed considerably between v1 and v2, so you'll see different processes – in v2, there'll be dovecot, dovecot/anvil, dovecot/log, and others. Also, some processes are only started when someone connects, or only when verifying authentication details. –  grawity Jun 15 '13 at 14:15
@Diti: No, both daemons listen on all interfaces and all addresses by default. But the connections aren't being refused – rather, the server quietly drops all connection attempts (see the nmap scan I linked to), which is a sure sign of a firewall somewhere. Try using iptables -n -v -L to check if there are any rules to drop packets. –  grawity Jun 15 '13 at 14:19
show 1 more comment
