How to set up a secure Raspberry Pi web server, mail server and Owncloud installation

@Pestmeester
February 13th 2017: MAJOR UPDATE!
Version 1.1.0 | view changelog
donate bitcoin: 12Y4kzB6ZRzQkSVBv2sBCQsB4BqKU5KKfX

Introduction

As soon as I posted a picture of my routers, switch, USB Drive and most important of all my Raspberry Pi 2 B, people asked if I wanted to write it all down in a guide. Of course I didn't do this by myself. I made use of several guides myself. I combined bits and pieces until I got what I was looking for. This guide is a step-by-step compilation of all those parts I used. This is how I made my secure Raspberry Pi Webserver, TLS/SSL email server and https secured Owncloud hosting in one. This very website you're viewing is actually served from the Raspberry Pi this guide is all about.

A fair warning

Over the past 2 years a lot has changed in this guide. Make sure to check the changelog. As of February 13th 2017 really big parts of this guide have been rewritten. Some things became a lot easier!

Also please understand that I am no server expert. I just like to tinfoil about cloud based personal data and experiment with creating self-hosted stuff in my spare time. I am sure there are people who can do this a lot better than I. But hey, it works! And security test results look great.

And my mail server security looks pretty decent too!

Enjoy!

Initial configuration

For the next part I used a guide Setting up a (reasonably) secure home web-server with Raspberry Pi written by Matt Wilcox.

I made the same setup. A Nginx, PHP, MySql web-server. In addition to that a Postfix, Dovecot email server.

Set up Raspberry Pi

The first part of his guide we already did above. One of the things I want to do now is getting rid of the television. I want to control my Raspberry from a terminal on my Mac (or Putty in Windows). That step is described at the bottom of Matt's guide. We're gonna start with it.

Creating a new user

As Matt describes it's a good idea to change the user Pi. We're gonna make a new user. Type in bash:

groups

You will see a list output similar to the one below - yours may be different to mine (this article will become old and out of date) so pay attention to your list and not mine!

pi adm dialout cdrom sudo audio video plugdev games users netdev input

Now we can create a new user. Type the following into the command prompt but remember to use your list of groups (minus the first 'pi' item) and replace USERNAME with the username you want to create. Make sure you type it all on one line (if you're seeing the line wrap here that's just to make things readable for you).

sudo useradd -m -G adm,dialout,cdrom,sudo,audio,video,plugdev,games,users,netdev,input USERNAME

Next we set a password for the new user:

sudo passwd USERNAME

Complete the prompts as they appear.

The latest Raspbian Jessie changed the automatic login of the Pi. We have to tell Raspbian to no longer automatically login with user Pi. We're gonna make a little change in a file called: /etc/systemd/system/getty.target.wants/getty@tty1.service

Type:

sudo nano /etc/systemd/system/getty.target.wants/getty@tty1.service

The system will ask you for a password. At this point you're still logged in as user Pi. Use the password you made for this user during the raspi-config configuration in the previous chapter.

Look for the line that says:

ExecStart=-/sbin/agetty --autologin pi --noclear %I $TERM

Change the word pi to your username, like this:

ExecStart=-/sbin/agetty --autologin username --noclear %I $TERM

Save and exit the file by pressing: CTRL-X. Choose Yes, and Enter.

Now shutdown the Pi:

sudo shutdown -h now

The Pi will turn itself off. Un-plug the power, plug in the network cable, then plug the power back in. The Pi will boot up and immediately log you in as the new user. If it didn't, log-in with your newly created user's details (i.e., don't log in as 'pi'). Now it is safe to delete the user 'pi'.

Deleting the default 'pi' user

Type:

sudo deluser --remove-all-files pi

This will take a little while and spit out a lot of lines of text - eventually it will say 'Done'. The 'pi' user and its associated files are now removed from the system.

Set up a fixed IP address for your Pi

Make sure your Pi gets a fixed IP address assigned by your router.

Find the MAC address of the Pi

Set the router to always assign the same IP to any device with that MAC address

To find your Pi's MAC address type:

ifconfig

Going headless

At this point I shut down my Pi. Removed the Pi from the television and moved it to the room with my routers and external harddisks. Connect the ethernet cable, the external harddisk and power up the Pi.

Your Pi should get its fixed IP-address assigned by your router.

Start a terminal session on your Mac and login to your Pi with ssh by typing:

ssh USERNAME@IPADDRESS

For example: ssh pestmeester@192.168.178.39

Enter your password (we're gonna change this to SSH Key Pair Autentication later) and you're logged into your Pi.

Updating the operating system and software

Lets perfrom an update on our operating system now. We're gonna start the real stuff any moment now. To update the system type:

sudo apt-get update

Wait for this to complete; it's just got a list of all the potential updates and new bits of software you could install. To upgrade all of the currently installed software type:

sudo apt-get upgrade

Wait for that to complete, answer any prompts with 'y' + Enter. Your system is now up-to-date.

Securing your Pi

I did the optional step describedd in Matt's guide. Matt refers to an excellent guide by Linode. I used that as well and will write down all the steps I took.

The first part of the guide we already performed earlier. I scrolled directly to the paragraph Using SSH Key Pair Authentication.

You've used password authentication to connect to your Pi via SSH, but there's a more secure method available: key pair authentication. In this section, you'll generate a public and private key pair using your desktop computer and then upload the public key to your Pi. SSH connections will be authenticated by matching the public key with the private key stored on your desktop computer - you won't need to type your account password. When combined with the steps outlined later in this guide that disable password authentication entirely, key pair authentication can protect against brute-force password cracking attacks.

Generate the SSH keys on a desktop computer running Linux or Mac OS X by entering the following command in a terminal window on your desktop computer. (A new MAC terminal. Not your session in Pi.) PuTTY users can generate the SSH keys by following the windows specific instructions in the Use Public Key Authentication with SSH Guide. Type in:

ssh-keygen

The SSH keygen utility appears. Follow the on-screen instructions to create the SSH keys on your desktop computer. To use key pair authentication without a passphrase, press Enter when prompted for a passphrase.

Two files will be created in your \~/.ssh directory: id_rsa and id_rsa.pub. The public key is id_rsa.pub - this file will be uploaded to your Pi. The other file is your private key. Do not share this file with anyone!

Upload the public key to your Pi with the secure copy command (scp) by entering the following command in a terminal window on your desktop computer. Replace USERNAME with your username, and 192.168.178.39 with your Pi's IP address. If you have a Windows desktop, you can use a third-party client like WinSCP to upload the file to your home directory.

scp ~/.ssh/id_rsa.pub USERNAME@192.168.178.39:

Go back to your Pi terminal session and create a directory for the public key in your home directory (/home/USERNAME) by entering the following command on your Pi:

sudo mkdir .ssh

Move the public key in to the directory you just created by entering the following command on your Pi:

sudo mv id_rsa.pub .ssh/authorized_keys

Modify the permissions on the public key by entering the following commands, one by one, on your Pi. Replace example_user with your username.

sudo chown -R example_user:example_user .ssh

sudo chmod 700 .ssh

sudo chmod 600 .ssh/authorized_keys

The SSH keys have been generated, and the public key has been installed on your Pi. You're ready to use SSH key pair authentication! To try it, log out of your terminal session and then log back in. The new session will be authenticated with the SSH keys and you won't have to enter your account password. (You'll still need to enter the passphrase for the key, if you specified one.)

Disabling SSH Password Authentication and Root Login

You just strengthened the security of your Pi by adding a new user and generating SSH keys. Now it's time to make some changes to the default SSH configuration. First, you'll disable password authentication to require all users connecting via SSH to use key authentication. Next, you'll disable root login to prevent the root user from logging in via SSH. These steps are optional, but are strongly recommended.

Here's how to disable SSH password authentication and root login:

Open the SSH configuration file for editing by entering the following command:

sudo nano /etc/ssh/sshd_config

Change the PasswordAuthentication setting to no as shown below. Verify that the line is uncommented by removing the # in front of the line, if there is one.:

PasswordAuthentication no

Change the PermitRootLogin setting to no as shown below:

PermitRootLogin no

Save the changes to the SSH configuration file by pressing Control-X, and then Y.

Restart the SSH service to load the new configuration. Enter the following command:

sudo service ssh restart

Creating a Firewall

Now it's time to set up a firewall to limit and block unwanted inbound traffic to your Pi. This step is optional, but we strongly recommend that you use the example below to block traffic to ports that are not commonly used. It's a good way to deter would-be intruders! You can always modify the rules or disable the firewall later.

Here's how to create a firewall on your Pi:

Check your Pi's default firewall rules by entering the following command:

sudo iptables -L

Examine the output. If you haven't implemented any firewall rules yet, you should see an empty ruleset, as shown below:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Create a file to hold your firewall rules by entering the following command:

sudo nano /etc/iptables.firewall.rules

Now it's time to create some firewall rules. We've created some basic rules to get you started. Copy and paste the rules shown below in to the iptables.firewall.rules file you just created.

*filter

#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allows SMTP access
-A INPUT -p tcp --dport 25 -j ACCEPT
-A INPUT -p tcp --dport 465 -j ACCEPT
-A INPUT -p tcp --dport 587 -j ACCEPT

# Allows pop and pops connections
# -A INPUT -p tcp --dport 110 -j ACCEPT
# -A INPUT -p tcp --dport 995 -j ACCEPT

# Allows imap and imaps connections
-A INPUT -p tcp --dport 143 -j ACCEPT
-A INPUT -p tcp --dport 993 -j ACCEPT

#  Allow SSH connections
#  The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

Edit the rules as necessary. By default, the rules will allow traffic to the following services and ports: HTTP (80), HTTPS (443), SSH (22), and ping. I also added SMTP, Pop and IMAP as we need those later. All other ports will be blocked.

We'll add a few more rules later, when we get that email server running.

Save the changes to the firewall rules file by pressing Control-X, and then Y.

Activate the firewall rules by entering the following command:

sudo iptables-restore < /etc/iptables.firewall.rules

Recheck your Pi's firewall rules by entering the following command:

sudo iptables -L

Examine the output. The new ruleset should look like the one shown below:

Chain INPUT (policy ACCEPT)
target     prot opt source     destination
ACCEPT     all  --  anywhere   anywhere            
REJECT     all  --  anywhere   loopback/8  reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere   anywhere    state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:http
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:https
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:smtp
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:ssmtp
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:submission
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:imap2
ACCEPT     tcp  --  anywhere   anywhere    tcp dpt:imaps
ACCEPT     tcp  --  anywhere   anywhere    state NEW tcp dpt:ssh
ACCEPT     icmp --  anywhere   anywhere    icmp echo-request
LOG        all  --  anywhere   anywhere    limit: avg 5/min burst 5 LOG level debug prefix "iptables denied:"
DROP       all  --  anywhere   anywhere 

Chain FORWARD (policy ACCEPT)
target     prot opt source     destination
DROP       all  --  anywhere   anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source     destination
ACCEPT     all  --  anywhere   anywhere

Now you need to ensure that the firewall rules are activated every time you restart your Pi.

Start by creating a new script with the following command:

sudo nano /etc/network/if-pre-up.d/firewall

Copy and paste the following lines in to the file you just created:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules

Press Control-X and then press Y to save the script. Set the script's permissions by entering the following command:

sudo chmod +x /etc/network/if-pre-up.d/firewall

That's it! Your firewall rules are in place and protecting your Pi. Remember, you'll need to edit the firewall rules later if you install other software or services.

Installing and Configuring Fail2Ban

Fail2Ban is an application that prevents dictionary attacks on your server. When Fail2Ban detects multiple failed login attempts from the same IP address, it creates temporary firewall rules that block traffic from the attacker's IP address. Attempted logins can be monitored on a variety of protocols, including SSH, HTTP, and SMTP. By default, Fail2Ban monitors SSH only.

Here's how to install and configure Fail2Ban. Install Fail2Ban by entering the following command:

sudo apt-get install fail2ban

Fail2Ban is now installed and running on your Pi. It will monitor your log files for failed login attempts. After an IP address has exceeded the maximum number of authentication attempts, it will be blocked at the network level and the event will be logged in /var/log/fail2ban.log.

Setting up your first website

You can host as many websites as you like on one Pi/nginx install, but with the Pi being fairly lightweight, and with your uploads from it all going over your home internet connection it's a good idea to not have too many. Let's say we're going to create a website called "mysite"; we will want to be able to access it on the internal network from http://mysite.com.local and we'll want to access it from the internet at http://mysite.com.local

Setting up the mysite.com.local address

Being able to use http://mysite.com.local means your network traffic stays in your home network and doesn't go out to the internet - which will make it a lot faster while you're at home. Then you can use the http://mysite.com url to access it when you're not at home. The easiest way to get mysite.com.local working for you is to edit your computer's hosts file (i.e., the computer you'll access the Pi from, not the Pi's hosts file). If you're on OSX or Linux just open a new Terminal and type:

sudo nano /etc/hosts

If you're stuck on Windows, Google how to edit your hosts file.

In your hosts file add the following line: YOUR-PI'S-IP-ADDRESS mysite.com.local So, for example;

192.168.178.39 mysite.com.local

Save the file with Ctrl+X, save your changes. Now, whenever you type "http://mysite.com.local" into a browser on your computer, it will go straight to the Pi over your home network. If you were on OSX/Linux close the Terminal and return to the one that's SSH'd to the Pi.

Create the directory for your website's files

Lets make our first simple website. I'm hosting all mine on the external USB drive I mounted earlier. In the directory /data. Type:

sudo mkdir -p /data/mysite.com/www

sudo mkdir -p /data/mysite.com/logs

All your PHP/HTML/CSS etc will live in /data/mysite.com/www, and all of the access and error logs related to that site will go into /data/mysite.com/logs. Just so we can test the site is working later, lets create a minimalist HTML file in /data/mysite.com/www:

sudo nano /data/mysite.com/www/index.html

Write a short message or bit of HTML. Quit and save changes. Now we want to secure the /data/mysite.com files and directories a little bit - they're currently owned by root, and in order for nginx to have access they need to be owned by a special user and group called 'www-data'.

sudo chown -R www-data:www-data /data/mysite.com

This changes the mysite directory and all of its contents to have the www-data owner and group.

Configure nginx to serve the website

We'll start by making a copy of the default website config that ships with nginx, then customising it. "Available" sites are all stored as individual configuration files inside the directory /etc/nginx/sites-available - we need to create a new one for 'mysite.com'

cd /etc/nginx/sites-available

sudo cp default mysite.com

That's made a site available (to nginx) but it is not yet enabled (i.e., it's not yet used by nginx); to enable it we create a 'symbolic link' inside /etc/nginx/sites-enabled to the file we just created:

sudo ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/mysite.com

If we ever want to disable a website all we need to do is delete the symbolic link from the sites-enabled directory (which leaves the file in sites-available where it is). We'll remove the default website while we're here:

sudo rm /etc/nginx/sites-enabled/default

And:

sudo rm /etc/nginx/sites-available/default

Now lets reload nginx so our changes all take effect:

sudo /etc/init.d/nginx reload

With those reloaded lets get the settings for 'mysite' correct:

sudo nano /etc/nginx/sites-available/mysite.com

Let's just change everything in this file, so the site is ready to receive validation for SSL certificates later on and is able to run PHP.

Copy and paste the following into your file, replacing everything that is in it:

server {
listen 80 default_server;
listen [::]:80 default_server;
    server_name mysite.com www.mysite.com;

    root /data/mysite.com/www;
    index index.php index.html index.htm;

    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /data/mysite.com/www;
    }

    # Error & Access logs
    error_log /data/mysite.com/logs/error.log error;
    access_log /data/mysite.com/logs/access.log;

    location / {
        index index.html index.php;
    }

    location ~ /.well-known {
                allow all;
    }

    location ~ [^/].php(/|$) {
        fastcgi_split_path_info ^(.+?.php)(/.*)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

}

Save your edits and quit by pressing Ctrl + X, Y, Enter. Now we can reload the configuration files so nginx uses the new values:

sudo /etc/init.d/nginx reload

Once that completes open a new browser window on your computer and try to access http://mysite.com.local - you should see the HTML file you created earlier. If so, congratulations, you've got a basic server working on your Pi!

Testing your PHP configuration

sudo nano /data/mysite/www/index.php

Then write:

<?php phpinfo(); ?>

Save and close. Now go visit http://mysite.local.com/index.php in your browser; you should see a pile of information about your PHP configuration - which means it's working. It would be a good idea to remove that index.php file before you allow the site to be visible to the world, as it obviously contains a lot of information a hacker might find useful.

Accessing your site via a real domain

This bit is pretty easy as far as the Pi is concerned - remember how you included two domain names in the nginx configuration file for 'mysite'; mysite.local and mysite.com? That's literally all there is to it as far as the Pi is concerned. There are just two other things you need to do:

Setting up your domains A-record

You need to log into your Domain Registra's account and set the A-record for your domain (mysite.com) to point to your router's public IP address. This process varies between registra's so consult their documentation on how to do this. To find your public IP address just type "what is my IP" into Google, it will tell you right at the top of the page. That's the address you need to point your domain to. This is also why you must have a fixed IP address from your ISP - otherwise when you reboot your home connection your router's IP will change and your domain name will be pointing at the old IP address… so it won't work.

Setting up your Router

This is the final step: getting your Domain Name to point to your public IP is half the battle, but now you need to set your router up so that it can forward incoming requests for your website to your Raspberry Pi - otherwise requests for http://mysite.com will get as far as your router and stop there. You'll need to consult your router's documentation again, but you're looking for how to set up "port forwarding". You want to set the http port (and https port if you're instested in using https later…) to go to your Pi's internal IP address. Likewise, you want to make sure your router will allow out-bound network traffic on those ports too.

Setting up Email with Postfix, Dovecot, and MySQL

If you're not interested in running your own mail server you can skip this entire section.

For this I used another guide by Linode.

First, make sure you open up the following ports on your router: 143, 993,465, 25 and 587. This in addition to the ports that already should be open: 80, 443 and 22.

Configuring DNS

Add a MX record to your domain provides DNS Manager. For example:

mail.mysite.com    MX      10      YOUREXTERNALIPADDRESS

Installing Packages

We'll start by installing all of the necessary packages. Go into your Pi terminal and type:

sudo apt-get install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-mysql mysql-server

When prompted, type a new secure password for the root MySQL user. Type the password again. Make sure you remember what it is - you'll need it later.

You'll be prompted to select a Postfix configuration. Select Internet Site.

You'll be prompted to enter a System mail name, as shown below. You can use your FQDN or any domain name that resolves to the server. This will become your server's default domain for mail when none is specified. I just chose 'mysite.com'.

You just installed packages to support three applications: MySQL, Postfix, and Dovecot. Now it's time to configure the individual applications to work together as a mail server.

MySQL

First, you'll create a dedicated database in MySQL for your mail server. It will have three tables: one with domains, one with email addresses and encrypted passwords, and one with email aliases. You'll also create a dedicated MySQL user for Postfix and Dovecot.

Creating the Database

Here's how to create the necessary database and tables in MySQL:

Create a new database by entering the following command. We'll call the database mailserver in this example.

sudo mysqladmin -p create mailserver

Enter the MySQL root password.

Log in to MySQL by entering the following command:

sudo mysql -p mailserver

Enter the root MySQL password. You should see a command line prompt that looks like this:

mysql>

Create a new MySQL user (mailuser) by entering the following command. You'll grant the user local, read-level access on the mailserver database, and you'll also set the user's password, which is mailuserpass in the example below. Change this and make a note of the password for future use.

GRANT SELECT ON mailserver.* TO `mailuser`@`127.0.0.1` IDENTIFIED BY `mailuserpass`;

Reload MySQL's privileges to make sure the user has been added successfully:

FLUSH PRIVILEGES;

Enter the following command to create a table for the domains that will receive mail on your Pi. You can copy and paste the whole block of code at once. This will create a table called virtual_domains and give it two fields, an id field, and a name field for the domains.

CREATE TABLE `virtual_domains` (`id` int(11) NOT NULL auto_increment, `name` varchar(50) NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Enter the following command to create a table for all of the email addresses and passwords. This command will create a table called virtual_users. It has a domain_id field to associate each entry with a domain, a password field to hold an encrypted version of each user's password, and an email field to hold each user's email address.

CREATE TABLE `virtual_users` (`id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `password` varchar(106) NOT NULL, `email` varchar(100) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Enter the following command to create a table for your email aliases. This lets you forward mail from one email address to another. This command will create a table called virtual_aliases. It has an id field, a domain_id field which will associate each entry with a domain, a source field for the original email address, and a destination field for the target email address.

CREATE TABLE `virtual_aliases` (`id` int(11) NOT NULL auto_increment,`domain_id` int(11) NOT NULL,`source` varchar(100) NOT NULL,`destination` varchar(100) NOT NULL,PRIMARY KEY (`id`),FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Congratulations! You have successfully created the database and necessary tables in MySQL.

Adding Data to the Database

Now that you've created the database and tables, let's add some data to MySQL. Here's how:

Add your domains to the virtual_domains table. You can add as many domains as you want in the VALUES section of the command below, but in this mysite you'll add just the primary domain (mysite.com), your hostname (hostname), your FQDN (srv01.mysite.com), and localhost.mysite.com. (You'll add localhost in a different file later). Be sure to replace mysite.com and hostname with your own domain name and hostname. You'll need an id value and a name value for each entry. Separate each entry with a comma (,), and close the last one with a semicolon (;).

INSERT INTO mailserver.virtual_domains (id ,name) VALUES ('1', 'mysite.com'), ('2', 'srv01.mysite.com'), ('3', 'mail.mysite.com'), ('4', 'localhost.mysite.com');

Make a note of which id goes with which domain - you'll need for the next two steps.

Add email addresses to the virtual_users table. In this example, you'll add two new email addresses, email1@mysite.com and email2@mysite.com, with the passwords CHOOSEPASSWORD1 and CHOOSEPASSWORD2, respectively. Be sure to replace the examples with your own information, but leave the password encryption functions intact. For each entry you'll need to supply an id value, a domain_id, which should be the id number for the domain from Step 1 (in this case we're choosing 1 for mysite.com), a password which will be in plain text in this command but which will get encrypted in the database, and an email, which is the full email address. Entries should be separated by a comma, and the final entry should be closed with a semicolon.

INSERT INTO mailserver.virtual_users (id, domain_id, password , email) VALUES ('1', '1', ENCRYPT('CHOOSEPASSWORD1', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email1@mysite.com'), ('2', '1', ENCRYPT('CHOOSEPASSWORD2', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email2@mysite.com');

I skipped this step, but if you want to set up an email alias, add it to the virtual_aliases table. Just like in the previous step, we'll need an id value, and a domain_id value chosen from the virtual_domains list in Step 1. The source should be the email address you want to redirect. The destination should be the target email address, and can be any valid email address on your server or anywhere else.

INSERT INTO mailserver.virtual_aliases (id, domain_id, source, destination) VALUES ('1', '1', 'alias@mysite.com', 'email1@mysite.com');

That's it! Now you're ready to verify that the data was successfully added to MySQL. Enter the following command to exit MySQL:

exit

Now you're ready to set up Postfix so your server can accept incoming messages for your domains.

Postfix

Here's how to configure Postfix:

Before doing anything else, enter the following command to make a copy of the default Postfix configuration file. This will come in handy if you mess up and need to revert to the default configuration.

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.orig

Open the configuration file for editing by entering the following command:

sudo nano /etc/postfix/main.cf

This is how my files looks. I followed all steps in Linode's guide and changed myhostname, mydestination, my certificate lines and the line at the bottom to support only IPV4, otherwise you'll see ugly errors when restarting postfix, as I don't have IPV6 support yet:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Raspbian)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mysite.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.mysite.com/privkey.pem
smtpd_use_tls=yes
smtpd_tls_auth_only = yes

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

smtpd_recipient_restrictions =
          permit_sasl_authenticated,
          permit_mynetworks,
          reject_unauth_destination

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = mail.mysite.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

#Handing off local delivery to Dovecot's LMTP, and telling it where to store mail
virtual_transport = lmtp:unix:private/dovecot-lmtp

#Virtual domains, users, and aliases
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

inet_protocols = ipv4

Save the changes you've made to the /etc/postfix/main.cf file.

Create the three files you specified earlier. These files will tell Postfix how to connect to MySQL to read the lists of domains, email addresses, and aliases. Create the file for virtual domains by entering the following command:

sudo nano /etc/postfix/mysql-virtual-mailbox-domains.cf

Enter the following values. At a minimum, you'll need to change the password entry to the one you created for mailuser. If you used a different user, database name, or table name, customize those settings as well.

user = mailuser
password = mailuserpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s'

Save the changes you've made to the /etc/postfix/mysql-virtual-mailbox-domains.cf file.

Restart Postfix by entering the following command:

sudo service postfix restart

Enter the following command to ensure that Postfix can find your first domain. Be sure to replace mysite.com with your first virtual domain. The command should return 1 if it is successful; if nothing is returned, you have an issue.

postmap -q mysite.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Create the connection file for your email addresses by entering the following command:

sudo nano /etc/postfix/mysql-virtual-mailbox-maps.cf

Enter the following values. Make sure you use your own password, and make any other changes as needed.

user = mailuser
password = mailuserpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_users WHERE email='%s'

Save the changes you've made to the /etc/postfix/mysql-virtual-mailbox-maps.cf file.

Restart Postfix by entering the following command:

sudo service postfix restart

Test Postfix to verify that it can find the first email address in your MySQL table. Enter the following command, replacing email1@mysite.com with the first email address in your MySQL table. You should again receive 1 as the output:

postmap -q email1@mysite.com mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

Create the file that will allow Postfix to access the aliases in MySQL by entering the following command:

sudo nano /etc/postfix/mysql-virtual-alias-maps.cf

Enter the following values. Again, make sure you use your own password, and make any other changes as necessary.

user = mailuser
password = mailuserpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT destination FROM virtual_aliases WHERE source='%s'

Save the changes you've made to the /etc/postfix/mysql-virtual-alias-maps.cf file.

Restart Postfix by entering the following command:

sudo service postfix restart

Test Postfix to verify that it can find your aliases by entering the following command. Be sure to replace alias@mysite.com with the actual alias you entered:

postmap -q alias@mysite.com mysql:/etc/postfix/mysql-virtual-alias-maps.cf

This should return the email address to which the alias forwards, which is email1@mysite.com in this example.

Make a copy of the /etc/postfix/master.cf file:

sudo cp /etc/postfix/master.cf /etc/postfix/master.cf.orig

Open the configuration file for editing by entering the following command:

sudo nano /etc/postfix/master.cf

Locate and uncomment the two lines starting with submission and smtps. This will allow you to send mail securely on ports 587 and 465, in addition to port 25 (which is also secure with our SSL setup). The first section of your /etc/postfix/master.cf file should resemble the following:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       -       -       -       smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

The other text we leave as it is.

Save the changes you've made to the /etc/postfix/master.cf file.

Restart Postfix by entering the following command:

sudo service postfix restart

Congratulations! You have successfully configured Postfix.

Dovecot

Here's how to configure Dovecot:

Copy all of the configuration files so that you can easily revert back to them if needed. Enter the following commands, one by one:

sudo cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.orig
sudo cp /etc/dovecot/conf.d/10-mail.conf /etc/dovecot/conf.d/10-mail.conf.orig
sudo cp /etc/dovecot/conf.d/10-auth.conf /etc/dovecot/conf.d/10-auth.conf.orig
sudo cp /etc/dovecot/dovecot-sql.conf.ext /etc/dovecot/dovecot-sql.conf.ext.orig
sudo cp /etc/dovecot/conf.d/10-master.conf /etc/dovecot/conf.d/10-master.conf.orig
sudo cp /etc/dovecot/conf.d/10-ssl.conf /etc/dovecot/conf.d/10-ssl.conf.orig

Enter the following command to open the main configuration file for editing:

sudo nano /etc/dovecot/dovecot.conf

Verify that dovecot.conf is including all of the other configuration files. This option should be enabled by default:

## Dovecot configuration file

# If you're in a hurry, see http://wiki2.dovecot.org/QuickConfiguration

# "doveconf -n" command gives a clean output of the changed settings. Use it
# instead of copy&pasting files when posting to the Dovecot mailing list.

# '#' character and everything after it is treated as comments. Extra spaces
# and tabs are ignored. If you want to use either of these explicitly, put the
# value inside quotes, eg.: key = "# char and trailing whitespace  "

# Default values are shown for each setting, it's not required to uncomment
# those. These are exceptions to this though: No sections (e.g. namespace {})
# or plugin settings are added by default, they're listed only as examples.
# Paths are also just examples with the real defaults being based on configure
# options. The paths listed here are for configure --prefix=/usr
# --sysconfdir=/etc --localstatedir=/var

# Enable installed protocols
!include_try /usr/share/dovecot/protocols.d/*.protocol
protocols = imap lmtp

# A comma separated list of IPs or hosts where to listen in for connections.
# "*" listens in all IPv4 interfaces, "::" listens in all IPv6 interfaces.
# If you want to specify non-default ports or anything more complex,
# edit conf.d/master.conf.
listen = *

# Base directory where to store runtime data.
#base_dir = /var/run/dovecot/

# Name of this instance. Used to prefix all Dovecot processes in ps output.
#instance_name = dovecot

# Greeting message for clients.
#login_greeting = Dovecot ready.

# Space separated list of trusted network ranges. Connections from these
# IPs are allowed to override their IP addresses and ports (for logging and
# for authentication checks). disable_plaintext_auth is also ignored for
# these networks. Typically you'd specify your IMAP proxy servers here.
#login_trusted_networks =

# Sepace separated list of login access check sockets (e.g. tcpwrap)
#login_access_sockets =

# Show more verbose process titles (in ps). Currently shows user name and
# IP address. Useful for seeing who are actually using the IMAP processes
# (eg. shared mailboxes or if same uid is used for multiple accounts).
#verbose_proctitle = no

# Should all processes be killed when Dovecot master process shuts down.
# Setting this to "no" means that Dovecot can be upgraded without
# forcing existing client connections to close (although that could also be
# a problem if the upgrade is e.g. because of a security fix).
#shutdown_clients = yes

# If non-zero, run mail commands via this many connections to doveadm server,
# instead of running them directly in the same process.
#doveadm_worker_count = 0
# UNIX socket or host:port used for connecting to doveadm server
#doveadm_socket_path = doveadm-server

# Space separated list of environment variables that are preserved on Dovecot
# startup and passed down to all of its child processes. You can also give
# key=value pairs to always set specific settings.
#import_environment = TZ

##
## Dictionary server settings
##

# Dictionary can be used to store key=value lists. This is used by several
# plugins. The dictionary can be accessed either directly or though a
# dictionary server. The following dict block maps dictionary names to URIs
# when the server is used. These can then be referenced using URIs in format
# "proxy::".

dict {
  #quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
  #expire = sqlite:/etc/dovecot/dovecot-dict-sql.conf.ext
}

# Most of the actual configuration gets included below. The filenames are
# first sorted by their ASCII value and parsed in that order. The 00-prefixes
# in filenames are intended to make it easier to understand the ordering.
!include conf.d/*.conf

# A config file can also tried to be included without giving an error if
# it's not found:
!include_try local.conf

Save your changes to the /etc/dovecot/dovecot.conf file.

Open the /etc/dovecot/conf.d/10-mail.conf file for editing by entering the following command. This file allows us to control how Dovecot interacts with the server's file system to store and retrieve messages.

sudo nano /etc/dovecot/conf.d/10-mail.conf

Find the mail_location variable, uncomment it, and then set it to the following value. This tells Dovecot where to look for mail. In this case, the mail will be stored on the external USB drive in /data/mail/vhosts/mysite.com/user/, where mysite.com and user are variables that get pulled from the connecting email address. For example, if someone logs in to the server with the email address email1@mysite.com, Dovecot will use mysite.com for %d, and email1 for %n. You can change this path if you want, but you'll have to change it everywhere else the mail storage path is referenced in this tutorial. It's useful to keep this location in mind if you ever need to manually download the raw mail files from the server.

This is my entire 10-mail.conf file, beware it's a very big file:

##
## Mailbox locations and namespaces
##

# Location for users' mailboxes. The default is empty, which means that Dovecot
# tries to find the mailboxes automatically. This won't work if the user
# doesn't yet have any mail, so you should explicitly tell Dovecot the full
# location.
#
# If you're using mbox, giving a path to the INBOX file (eg. /var/mail/%u)
# isn't enough. You'll also need to tell Dovecot where the other mailboxes are
# kept. This is called the "root mail directory", and it must be the first
# path given in the mail_location setting.
#
# There are a few special variables you can use, eg.:
#
#   %u - username
#   %n - user part in user@domain, same as %u if there's no domain
#   %d - domain part in user@domain, empty if there's no domain
#   %h - home directory
#
# See doc/wiki/Variables.txt for full list. Some examples:
#
#   mail_location = maildir:~/Maildir
#   mail_location = mbox:~/mail:INBOX=/var/mail/%u
#   mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
#
# 
#
mail_location = maildir:/data/mail/vhosts/%d/%n

# If you need to set multiple mailbox locations or want to change default
# namespace settings, you can do it by defining namespace sections.
#
# You can have private, shared and public namespaces. Private namespaces
# are for user's personal mails. Shared namespaces are for accessing other
# users' mailboxes that have been shared. Public namespaces are for shared
# mailboxes that are managed by sysadmin. If you create any shared or public
# namespaces you'll typically want to enable ACL plugin also, otherwise all
# users can access all the shared mailboxes, assuming they have permissions
# on filesystem level to do so.
#
# REMEMBER: If you add any namespaces, the default namespace must be added
# explicitly, ie. mail_location does nothing unless you have a namespace
# without a location setting. Default namespace is simply done by having a
# namespace with empty prefix.
namespace index {
# Namespace type: private, shared or public
#type = private

# Hierarchy separator to use. You should use the same separator for all
# namespaces or some clients get confused. '/' is usually a good one.
# The default however depends on the underlying mail storage format.
#separator =

# Prefix required to access this namespace. This needs to be different for
# all namespaces. For example "Public/".
#prefix =

# Physical location of the mailbox. This is in same format as
# mail_location, which is also the default for it.
#location =

# There can be only one INBOX, and this setting defines which namespace
# has it.
inbox = yes

# If namespace is hidden, it's not advertised to clients via NAMESPACE
# extension. You'll most likely also want to set list=no. This is mostly
# useful when converting from another server with different namespaces which
# you want to deprecate but still keep working. For example you can create
# hidden namespaces with prefixes "~/mail/", "~%u/mail/" and "mail/".
#hidden = no

# Show the mailboxes under this namespace with LIST command. This makes the
# namespace visible for clients that don't support NAMESPACE extension.
# "children" value lists child mailboxes, but hides the namespace prefix.
#list = yes

# Namespace handles its own subscriptions. If set to "no", the parent
# namespace handles them (empty prefix should always have this as "yes")
#subscriptions = yes
}

# Example shared namespace configuration
#namespace {
#type = shared
#separator = /

# Mailboxes are visible under "shared/user@domain/"
# %%n, %%d and %%u are expanded to the destination user.
#prefix = shared/%%u/

# Mail location for other users' mailboxes. Note that %variables and ~/
# expands to the logged in user's data. %%n, %%d, %%u and %%h expand to the
# destination user's data.
#location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u

# Use the default namespace for saving subscriptions.
#subscriptions = no

# List the shared/ namespace only if there are visible shared mailboxes.
#list = children
#}

# System user and group used to access mails. If you use multiple, userdb
# can override these by returning uid or gid fields. You can use either numbers
# or names. 
#mail_uid =
#mail_gid =

# Group to enable temporarily for privileged operations. Currently this is
# used only with INBOX when either its initial creation or dotlocking fails.
# Typically this is set to "mail" to give access to /var/mail.
mail_privileged_group = mail

# Grant access to these supplementary groups for mail processes. Typically
# these are used to set up access to shared mailboxes. Note that it may be
# dangerous to set these if users can create symlinks (e.g. if "mail" group is
# set here, ln -s /var/mail ~/mail/var could allow a user to delete others'
# mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it).
#mail_access_groups =

# Allow full filesystem access to clients. There's no access checks other than
# what the operating system does for the active UID/GID. It works with both
# maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/
# or ~user/.
#mail_full_filesystem_access = no

##
## Mail processes
##

# Don't use mmap() at all. This is required if you store indexes to shared
# filesystems (NFS or clustered filesystem).
#mmap_disable = no

# Rely on O_EXCL to work when creating dotlock files. NFS supports O_EXCL
# since version 3, so this should be safe to use nowadays by default.
#dotlock_use_excl = yes

# When to use fsync() or fdatasync() calls:
#   optimized (default): Whenever necessary to avoid losing important data
#   always: Useful with e.g. NFS when write()s are delayed
#   never: Never use it (best performance, but crashes can lose data)
#mail_fsync = optimized

# Mail storage exists in NFS. Set this to yes to make Dovecot flush NFS caches
# whenever needed. If you're using only a single mail server this isn't needed.
#mail_nfs_storage = no
# Mail index files also exist in NFS. Setting this to yes requires
# mmap_disable=yes and fsync_disable=no.
#mail_nfs_index = no

# Locking method for index files. Alternatives are fcntl, flock and dotlock.
# Dotlocking uses some tricks which may create more disk I/O than other locking
# methods. NFS users: flock doesn't work, remember to change mmap_disable.
#lock_method = fcntl

# Directory in which LDA/LMTP temporarily stores incoming mails >128 kB.
#mail_temp_dir = /tmp

# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
#first_valid_uid = 500
#last_valid_uid = 0

# Valid GID range for users, defaults to non-root/wheel. Users having
# non-valid GID as primary group ID aren't allowed to log in. If user
# belongs to supplementary groups with non-valid GIDs, those groups are
# not set.
#first_valid_gid = 1
#last_valid_gid = 0

# Maximum allowed length for mail keyword name. It's only forced when trying
# to create new keywords.
#mail_max_keyword_length = 50

# ':' separated list of directories under which chrooting is allowed for mail
# processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too).
# This setting doesn't affect login_chroot, mail_chroot or auth chroot
# settings. If this setting is empty, "/./" in home dirs are ignored.
# WARNING: Never add directories here which local users can modify, that
# may lead to root exploit. Usually this should be done only if you don't
# allow shell access for users. 
#valid_chroot_dirs =

# Default chroot directory for mail processes. This can be overridden for
# specific users in user database by giving /./ in user's home directory
# (eg. /home/./user chroots into /home). Note that usually there is no real
# need to do chrooting, Dovecot doesn't allow users to access files outside
# their mail directory anyway. If your home directories are prefixed with
# the chroot directory, append "/." to mail_chroot. 
#mail_chroot =

# UNIX socket path to master authentication server to find users.
# This is used by imap (for shared users) and lda.
#auth_socket_path = /var/run/dovecot/auth-userdb

# Directory where to look up mail plugins.
#mail_plugin_dir = /usr/lib/dovecot/modules

# Space separated list of plugins to load for all services. Plugins specific to
# IMAP, LDA, etc. are added to this list in their own .conf files.
#mail_plugins =

##
## Mailbox handling optimizations
##

# The minimum number of mails in a mailbox before updates are done to cache
# file. This allows optimizing Dovecot's behavior to do less disk writes at
# the cost of more disk reads.
#mail_cache_min_mail_count = 0

# When IDLE command is running, mailbox is checked once in a while to see if
# there are any new mails or other changes. This setting defines the minimum
# time to wait between those checks. Dovecot can also use dnotify, inotify and
# kqueue to find out immediately when changes occur.
#mailbox_idle_check_interval = 30 secs

# Save mails with CR+LF instead of plain LF. This makes sending those mails
# take less CPU, especially with sendfile() syscall with Linux and FreeBSD.
# But it also creates a bit more disk I/O which may just make it slower.
# Also note that if other software reads the mboxes/maildirs, they may handle
# the extra CRs wrong and cause problems.
#mail_save_crlf = no

##
## Maildir-specific settings
##

# By default LIST command returns all entries in maildir beginning with a dot.
# Enabling this option makes Dovecot return only entries which are directories.
# This is done by stat()ing each entry, so it causes more disk I/O.
# (For systems setting struct dirent->d_type, this check is free and it's
# done always regardless of this setting)
#maildir_stat_dirs = no

# When copying a message, do it with hard links whenever possible. This makes
# the performance much better, and it's unlikely to have any side effects.
#maildir_copy_with_hardlinks = yes

# Assume Dovecot is the only MUA accessing Maildir: Scan cur/ directory only
# when its mtime changes unexpectedly or when we can't find the mail otherwise.
#maildir_very_dirty_syncs = no

##
## mbox-specific settings
##

# Which locking methods to use for locking mbox. There are four available:
#  dotlock: Create .lock file. This is the oldest and most NFS-safe
#           solution. If you want to use /var/mail/ like directory, the users
#           will need write access to that directory.
#  dotlock_try: Same as dotlock, but if it fails because of permissions or
#               because there isn't enough disk space, just skip it.
#  fcntl  : Use this if possible. Works with NFS too if lockd is used.
#  flock  : May not exist in all systems. Doesn't work with NFS.
#  lockf  : May not exist in all systems. Doesn't work with NFS.
#
# You can use multiple locking methods; if you do the order they're declared
# in is important to avoid deadlocks if other MTAs/MUAs are using multiple
# locking methods as well. Some operating systems don't allow using some of
# them simultaneously.
#mbox_read_locks = fcntl
#mbox_write_locks = dotlock fcntl

# Maximum time to wait for lock (all of them) before aborting.
#mbox_lock_timeout = 5 mins

# If dotlock exists but the mailbox isn't modified in any way, override the
# lock file after this much time.
#mbox_dotlock_change_timeout = 2 mins

# When mbox changes unexpectedly we have to fully read it to find out what
# changed. If the mbox is large this can take a long time. Since the change
# is usually just a newly appended mail, it'd be faster to simply read the
# new mails. If this setting is enabled, Dovecot does this but still safely
# fallbacks to re-reading the whole mbox file whenever something in mbox isn't
# how it's expected to be. The only real downside to this setting is that if
# some other MUA changes message flags, Dovecot doesn't notice it immediately.
# Note that a full sync is done with SELECT, EXAMINE, EXPUNGE and CHECK
# commands.
#mbox_dirty_syncs = yes

# Like mbox_dirty_syncs, but don't do full syncs even with SELECT, EXAMINE,
# EXPUNGE or CHECK commands. If this is set, mbox_dirty_syncs is ignored.
#mbox_very_dirty_syncs = no

# Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK
# commands and when closing the mailbox). This is especially useful for POP3
# where clients often delete all mails. The downside is that our changes
# aren't immediately visible to other MUAs.
#mbox_lazy_writes = yes

# If mbox size is smaller than this (e.g. 100k), don't write index files.
# If an index file already exists it's still read, just not updated.
#mbox_min_index_size = 0

##
## mdbox-specific settings
##

# Maximum dbox file size until it's rotated.
#mdbox_rotate_size = 2M

# Maximum dbox file age until it's rotated. Typically in days. Day begins
# from midnight, so 1d = today, 2d = yesterday, etc. 0 = check disabled.
#mdbox_rotate_interval = 0

# When creating new mdbox files, immediately preallocate their size to
# mdbox_rotate_size. This setting currently works only in Linux with some
# filesystems (ext4, xfs).
#mdbox_preallocate_space = no

##
## Mail attachments
##

# sdbox and mdbox support saving mail attachments to external files, which
# also allows single instance storage for them. Other backends don't support
# this for now.

# WARNING: This feature hasn't been tested much yet. Use at your own risk.

# Directory root where to store mail attachments. Disabled, if empty.
#mail_attachment_dir =

# Attachments smaller than this aren't saved externally. It's also possible to
# write a plugin to disable saving specific attachments externally.
#mail_attachment_min_size = 128k

# Filesystem backend to use for saving attachments:
#  posix : No SiS done by Dovecot (but this might help FS's own deduplication)
#  sis posix : SiS with immediate byte-by-byte comparison during saving
#  sis-queue posix : SiS with delayed comparison and deduplication
#mail_attachment_fs = sis posix

# Hash format to use in attachment filenames. You can add any text and
# variables: %{md4}, %{md5}, %{sha1}, %{sha256}, %{sha512}, %{size}.
# Variables can be truncated, e.g. %{sha256:80} returns only first 80 bits
#mail_attachment_hash = %{sha1}

Save your changes to the /etc/dovecot/conf.d/10-mail.conf file.

Create the mail folder in the /data directory:

sudo mkdir /data/mail

Enter the following command to verify the permissions for /data/mail:

ls -ld /data/mail

Verify that the permissions for /data/mail are as follows:

drwxrwsr-x 2 root mail 4096 Mar  6 15:08 /data/mail

Create the /data/mail/vhosts/ folder and the folder(s) for each of your domains by entering the following command:

mkdir -p /data/mail/vhosts/mysite.com

Create the vmail user with a user and group id of 5000 by entering the following commands, one by one. This user will be in charge of reading mail from the server.

groupadd -g 5000 vmail
	useradd -g vmail -u 5000 vmail -d /data/mail

Change the owner of the /data/mail/ folder and its contents to belong to vmail by entering the following command:

chown -R vmail:vmail /data/mail

Open the user authentication file for editing by entering the command below. You need to set up authentication so only authenticated users can read mail on the server. You also need to configure an authentication socket for outgoing mail, since we told Postfix that Dovecot was going to handle that. There are a few different files related to authentication that get included in each other.

nano /etc/dovecot/conf.d/10-auth.conf

Here is a copy of my 10-auth.conf:

##
## Authentication processes
##

# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you're connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
disable_plaintext_auth = yes

# Authentication cache size (e.g. 10M). 0 means it's disabled. Note that
# bsdauth, PAM and vpopmail require cache_key to be set for caching to be used.
#auth_cache_size = 0
# Time to live for cached data. After TTL expires the cached record is no
# longer used, *except* if the main database lookup returns internal failure.
# We also try to handle password changes automatically: If user's previous
# authentication was successful, but this one wasn't, the cache isn't used.
# For now this works only with plaintext authentication.
#auth_cache_ttl = 1 hour
# TTL for negative hits (user not found, password mismatch).
# 0 disables caching them completely.
#auth_cache_negative_ttl = 1 hour

# Space separated list of realms for SASL authentication mechanisms that need
# them. You can leave it empty if you don't want to support multiple realms.
# Many clients simply use the first one listed here, so keep the default realm
# first.
#auth_realms =

# Default realm/domain to use if none was specified. This is used for both
# SASL realms and appending @domain to username in plaintext logins.
#auth_default_realm =

# List of allowed characters in username. If the user-given username contains
# a character not listed in here, the login automatically fails. This is just
# an extra check to make sure user can't exploit any potential quote escaping
# vulnerabilities with SQL/LDAP databases. If you want to allow all characters,
# set this value to empty.
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

# Username character translations before it's looked up from databases. The
# value contains series of from -> to characters. For example "#@/@" means
# that '#' and '/' characters are translated to '@'.
#auth_username_translation =

# Username formatting before it's looked up from databases. You can use
# the standard variables here, eg. %Lu would lowercase the username, %n would
# drop away the domain if it was given, or "%n-AT-%d" would change the '@' into
# "-AT-". This translation is done after auth_username_translation changes.
#auth_username_format = %Lu

# If you want to allow master users to log in by specifying the master
# username within the normal username string (ie. not using SASL mechanism's
# support for it), you can specify the separator character here. The format
# is then . UW-IMAP uses "*" as the
# separator, so that could be a good choice.
#auth_master_user_separator =

# Username to use for users logging in with ANONYMOUS SASL mechanism
#auth_anonymous_username = anonymous

# Maximum number of dovecot-auth worker processes. They're used to execute
# blocking passdb and userdb queries (eg. MySQL and PAM). They're
# automatically created and destroyed as needed.
#auth_worker_max_count = 30

# Host name to use in GSSAPI principal names. The default is to use the
# name returned by gethostname(). Use "$ALL" (with quotes) to allow all keytab
# entries.
#auth_gssapi_hostname =

# Kerberos keytab to use for the GSSAPI mechanism. Will use the system
# default (usually /etc/krb5.keytab) if not specified. You may need to change
# the auth service to run as root to be able to read this file.
#auth_krb5_keytab =

# Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon and
# ntlm_auth helper. 
#auth_use_winbind = no

# Path for Samba's ntlm_auth helper binary.
#auth_winbind_helper_path = /usr/bin/ntlm_auth

# Time to delay before replying to failed authentications.
#auth_failure_delay = 2 secs

# Require a valid SSL client certificate or the authentication fails.
#auth_ssl_require_client_cert = no

# Take the username from client's SSL certificate, using
# X509_NAME_get_text_by_NID() which returns the subject's DN's
# CommonName.
#auth_ssl_username_from_cert = no

# Space separated list of wanted authentication mechanisms:
#   plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi otp skey
#   gss-spnego
# NOTE: See also disable_plaintext_auth setting.
auth_mechanisms = plain login

##
## Password and user databases
##

#
# Password database is used to verify user's password (and nothing more).
# You can have multiple passdbs and userdbs. This is useful if you want to
# allow both system users (/etc/passwd) and virtual users to login without
# duplicating the system users into virtual database.
#
# 
#
# User database specifies where mails are located and what user/group IDs
# own them. For single-UID configuration use "static" userdb.
#
# 

#!include auth-deny.conf.ext
#!include auth-master.conf.ext

#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

These are three most important lines. I didn't touch the rest of the default file:

disable_plaintext_auth = yes
auth_mechanisms = plain login
#!include auth-system.conf.ext
!include auth-sql.conf.ext

Save your changes to the /etc/dovecot/conf.d/10-auth.conf file.

Now you need to create the /etc/dovecot/conf.d/auth-sql.conf.ext file with your authentication information. Enter the following command to create the new file:

nano /etc/dovecot/conf.d/auth-sql.conf.ext

Paste the following lines into in the new file:

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/data/mail/vhosts/%d/%n
}

Save your changes to the /etc/dovecot/conf.d/auth-sql.conf.ext file.

Update the /etc/dovecot/dovecot-sql.conf.ext file with our custom MySQL connection information. Open the file for editing by entering the following command:

nano /etc/dovecot/dovecot-sql.conf.ext

This is my entire file:

# This file is opened as root, so it should be owned by root and mode 0600.
#
# http://wiki2.dovecot.org/AuthDatabase/SQL
#
# For the sql passdb module, you'll need a database with a table that
# contains fields for at least the username and password. If you want to
# use the user@domain syntax, you might want to have a separate domain
# field as well.
#
# If your users all have the same uig/gid, and have predictable home
# directories, you can use the static userdb module to generate the home
# dir based on the username and domain. In this case, you won't need fields
# for home, uid, or gid in the database.
#
# If you prefer to use the sql userdb module, you'll want to add fields
# for home, uid, and gid. Here is an example table:
#
# CREATE TABLE users (
#     username VARCHAR(128) NOT NULL,
#     domain VARCHAR(128) NOT NULL,
#     password VARCHAR(64) NOT NULL,
#     home VARCHAR(255) NOT NULL,
#     uid INTEGER NOT NULL,
#     gid INTEGER NOT NULL,
#     active CHAR(1) DEFAULT 'Y' NOT NULL
# );

# Database driver: mysql, pgsql, sqlite
driver = mysql

# Database connection string. This is driver-specific setting.
#
# HA / round-robin load-balancing is supported by giving multiple host
# settings, like: host=sql1.host.org host=sql2.host.org
#
# pgsql:
#   For available options, see the PostgreSQL documention for the
#   PQconnectdb function of libpq.
#   Use maxconns=n (default 5) to change how many connections Dovecot can
#   create to pgsql.
#
# mysql:
#   Basic options emulate PostgreSQL option names:
#     host, port, user, password, dbname
#
#   But also adds some new settings:
#     client_flags        - See MySQL manual
#     ssl_ca, ssl_ca_path - Set either one or both to enable SSL
#     ssl_cert, ssl_key   - For sending client-side certificates to server
#     ssl_cipher          - Set minimum allowed cipher security (default: HIGH)
#     option_file         - Read options from the given file instead of
#                           the default my.cnf location
#     option_group        - Read options from the given group (default: client)
#
#   You can connect to UNIX sockets by using host: host=/var/run/mysql.sock
#   Note that currently you can't use spaces in parameters.
#
# sqlite:
#   The path to the database file.
#
# Examples:
#   connect = host=192.168.1.1 dbname=users
#   connect = host=sql.mysite.com dbname=virtual user=virtual password=blarg
#   connect = /etc/dovecot/authdb.sqlite
#
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuserpass

# Default password scheme.
#
# List of supported schemes is in
# http://wiki2.dovecot.org/Authentication/PasswordSchemes
#
default_pass_scheme = SHA512-CRYPT

# passdb query to retrieve the password. It can return fields:
#   password - The user's password. This field must be returned.
#   user - user@domain from the database. Needed with case-insensitive lookups.
#   username and domain - An alternative way to represent the "user" field.
#
# The "user" field is often necessary with case-insensitive lookups to avoid
# e.g. "name" and "nAme" logins creating two different mail directories. If
# your user and domain names are in separate fields, you can return "username"
# and "domain" fields instead of "user".
#
# The query can also return other fields which have a special meaning, see
# http://wiki2.dovecot.org/PasswordDatabase/ExtraFields
#
# Commonly used available substitutions (see http://wiki2.dovecot.org/Variables
# for full list):
#   %u = entire user@domain
#   %n = user part of user@domain
#   %d = domain part of user@domain
#
# Note that these can be used only as input to SQL query. If the query outputs
# any of these substitutions, they're not touched. Otherwise it would be
# difficult to have eg. usernames containing '%' characters.
#
# Example:
#   password_query = SELECT userid AS user, pw AS password \
#     FROM users WHERE userid = '%u' AND active = 'Y'
#
#password_query = \
#  SELECT username, domain, password \
#  FROM users WHERE username = '%n' AND domain = '%d'
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u'

# userdb query to retrieve the user information. It can return fields:
#   uid - System UID (overrides mail_uid setting)
#   gid - System GID (overrides mail_gid setting)
#   home - Home directory
#   mail - Mail location (overrides mail_location setting)
#
# None of these are strictly required. If you use a single UID and GID, and
# home or mail directory fits to a template string, you could use userdb static
# instead. For a list of all fields that can be returned, see
# http://wiki2.dovecot.org/UserDatabase/ExtraFields
#
# Examples:
#   user_query = SELECT home, uid, gid FROM users WHERE userid = '%u'
#   user_query = SELECT dir AS home, user AS uid, group AS gid FROM users where userid = '%u'
#   user_query = SELECT home, 501 AS uid, 501 AS gid FROM users WHERE userid = '%u'
#
#user_query = \
#  SELECT home, uid, gid \
#  FROM users WHERE username = '%n' AND domain = '%d'

# If you wish to avoid two SQL lookups (passdb + userdb), you can use
# userdb prefetch instead of userdb sql in dovecot.conf. In that case you'll
# also have to return userdb fields in password_query prefixed with "userdb_"
# string. For example:
#password_query = \
#  SELECT userid AS user, password, \
#    home AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \
#  FROM users WHERE userid = '%u'

# Query to get a list of all usernames.
#iterate_query = SELECT username AS user FROM users

These are the important lines:

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuserpass

Make sure to change mailuser and mailuserpass to your own MySQL information

default_pass_scheme = SHA512-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

Save your changes to the /etc/dovecot/dovecot-sql.conf.ext file.

Change the owner and group of the /etc/dovecot/ directory to vmail and dovecot by entering the following command:

chown -R vmail:dovecot /etc/dovecot

Change the permissions on the /etc/dovecot/ directory by entering the following command:

chmod -R o-rwx /etc/dovecot

Open the sockets configuration file by entering the following command. You'll change the settings in this file to set up the LMTP socket for local mail delivery, and the auth socket for authentication. Postfix uses these sockets to connect to Dovecot's services.

sudo nano /etc/dovecot/conf.d/10-master.conf

This is my entire file:

#default_process_limit = 100
#default_client_limit = 1000

# Default VSZ (virtual memory size) limit for service processes. This is mainly
# intended to catch and kill processes that leak memory before they eat up
# everything.
#default_vsz_limit = 256M

# Login user is internally used by login processes. This is the most untrusted
# user in Dovecot system. It shouldn't have access to anything at all.
#default_login_user = dovenull

# Internal user is used by unprivileged processes. It should be separate from
# login user, so that login processes can't disturb other processes.
#default_internal_user = dovecot

service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    #port = 993
    #ssl = yes
  }

  # Number of connections to handle before starting a new process. Typically
  # the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
  # is faster. 
  #service_count = 1

  # Number of processes to always keep waiting for more connections.
  #process_min_avail = 0

  # If you set service_count=0, you probably need to grow this.
  #vsz_limit = 64M
}

service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    #port = 995
    #ssl = yes
  }
}
service lmtp {
 unix_listener /var/spool/postfix/private/dovecot-lmtp {
   mode = 0600
   user = postfix
   group = postfix
  }
  # Create inet listener only if you can't use the above UNIX socket
  #inet_listener lmtp {
    # Avoid making LMTP visible for the entire internet
    #address =
    #port =
  #}
}

service imap {
  # Most of the memory goes to mmap()ing files. You may need to increase this
  # limit if you have huge mailboxes.
  #vsz_limit = 256M

  # Max. number of IMAP processes (connections)
  #process_limit = 1024
}

service pop3 {
  # Max. number of POP3 processes (connections)
  #process_limit = 1024
}
service auth {
  # auth_socket_path points to this userdb socket by default. It's typically
  # used by dovecot-lda, doveadm, possibly imap process, etc. Its default
  # permissions make it readable only by root, but you may need to relax these
  # permissions. Users that have access to this socket are able to get a list
  # of all usernames and get results of everyone's userdb lookups.
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }

  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    #group = vmail
  }

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

  # Auth process is run as this user.
  user = dovecot
}

service auth-worker {
  # Auth worker process is run as root by default, so that it can access
  # /etc/shadow. If this isn't necessary, the user should be changed to
  # $default_internal_user.
  user = vmail
}

service dict {
  # If dict proxy is used, mail processes should have access to its socket.
  # For example: mode=0660, group=vmail and global mail_access_groups=vmail
  unix_listener dict {
    #mode = 0600
    #user =
    #group =
  }
}

Most important is that we have disabled unencrypted IMAP and POP3 by setting the protocols' ports to 0. This will force your users to use secure IMAP or secure POP on 993 or 995 when they configure their mail clients. Make sure you leave the secure versions alone - imaps and pop3s - so their ports still work. The default settings for imaps and pop3s are fine. You can leave the port lines commented out, as the default ports are the standard 993 and 995. I made a few other changes suggested by Linode's guide in sections: service auth-worker, service auth, service lmtp.

Save your changes to the /etc/dovecot/conf.d/10-master.conf file.

Open the SSL configuration file for editing by entering the following command. This is where we tell Dovecot where to find our SSL certificate and key, and any other SSL-related parameters.

sudo nano /etc/dovecot/conf.d/10-ssl.conf

This is my entire file:

	##
## SSL settings
##

# SSL/TLS support: yes, no, required. 
ssl = required

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
	ssl_cert = </etc/letsencrypt/live/mail.mysite.com/fullchain.pem
	ssl_key = </etc/letsencrypt/live/mail.mysite.com/privkey.pem

# If key file is password protected, give the password here. Alternatively
# give it when starting dovecot with -p parameter. Since this file is often
# world-readable, you may want to place this setting instead to a different
# root owned 0600 file by using ssl_key_password = <path.
#ssl_key_password =

# PEM encoded trusted certificate authority. Set this only if you intend to use
# ssl_verify_client_cert=yes. The file should contain the CA certificate(s)
# followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem)
#ssl_ca =

# Require that CRL check succeeds for client certificates.
#ssl_require_crl = yes

# Request client to send a certificate. If you also want to require it, set
# auth_ssl_require_client_cert=yes in auth section.
#ssl_verify_client_cert = no

# Which field from certificate to use for username. commonName and
# x500UniqueIdentifier are the usual choices. You'll also need to set
# auth_ssl_username_from_cert=yes.
#ssl_cert_username_field = commonName

# How often to regenerate the SSL parameters file. Generation is quite CPU
# intensive operation. The value is in hours, 0 disables regeneration
# entirely.
#ssl_parameters_regenerate = 168

# SSL protocols to use
ssl_protocols = !SSLv2 !SSLv3

# SSL ciphers to use
#ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

# SSL crypto device to use, for valid values run "openssl engine"
#ssl_crypto_device = 

Most important here is the line ssl = required and the paths to our certificates. But another very important difference in my file is the line for ssl_protocols. Make sure it looks like mine. That's protection against the POODLE attack. More on that at the end of this guide. But we might as well activate this protection now we're in this file.

Save your changes to the /etc/dovecot/conf.d/10-ssl.conf file.

Open the file 15-lda.conf for one last setting.

sudo nano /etc/dovecot/conf.d/15-lda.conf

Uncomment the line postmaster_address and fill in a mailaddress. I just used %d as stated in the file comments:

postmaster_address = %d

Save your changes to the /etc/dovecot/conf.d/15-lda.conf file. Dovecot has been configured!

Restart Dovecot by entering the following command:

sudo service dovecot restart

Set up a test account in an email client to make sure everything is working. You'll need to use the following parameters:

• Your full email address, including the @mysite.com part, is your username.
• Your password should be the one you added to the MySQL table for this email address.
• The incoming and outgoing server names must be a domain that resolves to your Pi.
• Both the incoming and outgoing servers require authentication and SSL encryption.
• You should use Port 993 for secure IMAP, Port 995 for secure POP3, and Port 25 with SSL for SMTP.

Monitor your mail log with the following command in your Pi:

sudo tail -f /var/log/mail.log

Send and email to this account and see if everything goes fine. If not? Backtrack a little. I had some issues with connecting to MySQL at first. It appeared I had the login credentials wrong in one file.

If you want to add more e-mailusers and domains, please read the last paragraph in Linode's guide. It is beyond the scope of my step-by-step-combining-several-guides-from-great-people-to-get-my-Pi-working.

Source material

• Raspberry Pi Foundation (2014), NOOBS SETUP. raspberrypi.org. Retrieved 14 Februari 2015.
• Wilcox, Matt (2013). Setting up a (reasonably) secure home web-server with Raspberry Pi. mattwilcox.net. Retrieved 14 Februari 2015.
• Grubb, Mel (2014). Raspberry Pi Home Server: Part 6, Adding a hard drive. Retrieved 14 Februari 2015.
• Russel, Dave (2014). Securing Your Server. linode.com. Retrieved 14 Februari 2015.
• Namecheap (2014). Generating CSR on Apache + OpenSSL/ModSSL/Nginx. namecheap.com. Retrieved 14 Februari 2015.
• Stewart, James (2014). Email with Postfix, Dovecot, and MySQL. linode.com. Retrieved 14 Februari 2015.

© 2015-2017 @Pestmeester | donate bitcoin: 12Y4kzB6ZRzQkSVBv2sBCQsB4BqKU5KKfX | geocities retro link: link 1 & link 2