The simplest way to set up a secure, IMAP, email server? [closed]
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.
Prerequisites
- Only one user account on the machine.
- (name’s
diti
; main e-mail[email protected]
; other aliases get redirected but an e-mail client can manage the different aliases and react accordingly)
- (name’s
- 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 thoseSubjectAltName
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.
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 forkra@
orpostmaster@
to thediti
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
orglaux.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 [email protected]
, 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, 127.0.0.0/8, [::ffff:127.0.0.0]/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 # If you later decide to set up a DKIM proxy or such, this will allow # it to distinguish user-submitted mails from received incoming ones. # It's part of the default configuration, therefore included here too.
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.