Welcome to Mail Server on Ubuntu 18.04 Part 1. This is the first part of a series of blog posts. It will use Postfix, dovecot and amavis. Setting up a mail server is a complex project it is one of the most difficult and complex servers to setup. There are many different tools/packages that have to come together before it is working. There are many more packages that can be installed before you have something that is usable in the real world with all the hackers and spammers around.
*Do not follow this blog post on a production server unless you are [crazy|dumb|mad|nutz|stupid] and want to be unemployed!
Why I wrote this.
I wrote this HOWTO, Mail Server on Ubuntu 18.04, as record of what I did to get my own mail server up and running. I can now and in the future follow these steps again and rebuild my own mail server. I hope it is of use to others.
For this HOWTO I am building using the following posts.
my test networking lab, Setup a Test Networking Lab with VirtualBox.
A minimal Ubuntu server running 18.04.
We will run through the setup of this one step at a time, hopefully not making any huge leaps. You will be able to test the parts installed as we go, no huge big bangs. All this as we move gently towards our goal of a Mail Server on Ubuntu 18.04.
There are some holes in the security of this server. e.g No firewall. So not just holes but open doors with neon signs!
Note: You are strongly recommended to take backup copies of your system and all files before you start and as we progress through the blog post.
When I install Ubuntu Linux on test machines I create a default common user called localadmin. I will use localadmin as the default local Linux user for this post. You can use any name you like just remember to change it where necessary.
The Mail Server on Ubuntu 18.04 which this post will be building is called mailserver and will be running Ubuntu Server edition. mailserver will run as a Virtual Box guest which makes backing up simple if nothing else. mailserver will be part of the dragon.lab domain.
mailserver.dragon.lab local IP 10.1.200.7
Services provided on mailserver
The server called mailserver will end up running the following servers and services.
- Postfix mail server.
- Delivering email to one or more local users.
- Email recipients will not have to have a local Linux account.
- Forwarding mail to remote users, from a lookup list only
- Relaying emails to the outside world
- Authentication and encryption TLS/SSL
- Encrypted passwords
- MySQL Database, holds user names, email addresses and alias addresses.
Install Ubuntu Server Edition.
We are starting from a minimal install of Ubuntu Server with no other software installed. During the installation process there will be a menu asking what other servers should be installed. I only install openssh here. ssh will allow you to ssh into your new server mailserver. This will make copy and paste operations easier and you can have more than one terminal open and they will be bigger. The bigger and more numerous terminals makes editing much easier.
After the install is done make sure it is all up to date with the latest patches and security updates.
sudo apt update
sudo apt dist-upgrade
I usually take a snapshot of the virtual machine at this point. When I trash the install I can just roll back the snapshot and try again from a known clean starting point. If at first you don’t succeed, go and have another beer.
Network Config
Network interface. Get this sorted out so mailserver has a static IP address.
sudo nano /etc/netplan/01-netcfg.yaml
It should look something like this
network: version: 2 renderer: networkd ethernets: enp0s3: dhcp4: no addresses: [10.1.200.7/24] gateway4: 10.1.200.1 nameservers: addresses: [10.1.200.1] search: [dragon.lab]
Make sure that the fully qualified domain name is setup and displayed correctly.
hostname --fqdn
The command above should be displaying the following for mailserver.
mailserver.dragon.lab
Fix the hostname
It is does not the problem can be solved by editing the hosts file as follows.
sudo nano /etc/hosts
10.1.200.7 mailserver.dragon.lab mailserver
Note: The system finds the domain from the first FQDN in the /etc/hosts file.
Update mailname
If that is all working update or create the file /etc/mailname with the short name of your server, mailserver.
sudo nano /etc/mailname
mailserver
Save your changes and exit.
This would be a good backup point! You can always restore back to this point if you mess up on the way.
Installing Postfix, Dovecot
We will start off by installing Postfix, Dovecot and a simple mail client. These will be installed with the following command.
sudo apt install mail-stack-delivery mailutils
A lot more packages get pulled in other than the ones listed on the command line due to dependencies. That saves typing 🙂 When the installation of postfix has finished, we will need to reconfigure it.
Reconfigure Postfix
sudo dpkg-reconfigure postfix
This will give us a good starting point to begin with. A number of questions will be asked.
- General type of mail configuration: Internet Site
- System mail name: mailserver.dragon.lab
- Root and postmaster mail recipient: postmaster@dragon.lab
- Other destinations to accept mail for: mailserver.dragon.lab, localhost.dragon.lab, localhost
- Force Synchronous updates on mail queue: No
- Local networks: 127.0.0./8 10.1.200.0/24
- Mailbox size limit: Your choice, depends how many users and how much disk space you have.
- Local address extension character: + leave as default
- Internet Protocols to use: all if you do not know which to choose
If you make a mistake you can reconfigure these setting and a few other basic settings with the following command. Any values already entered before with become the default values.
There should now be a very basic and insecure mailserver running on your test server. It will only accept email for local users. That is, users which have a Linux account on mailserver itself.
Postfix should already be using the Maildir format. It is set with the home_mailbox = Maildir/ parameter in /etc/postfix/main.cf. we can check that with the following command or simply look at the contents of the file.
sudo postconf -f home_mailbox
Since this is a new mailserver and it is unlikely that you are replacing an existing mailserver we can turn off the backwards compatibility mode on Postfix. Although this should already be the default.
sudo postconf -e 'compatibility_level=2'
Update MAIL environment
We also, need to set the MAIL environment variable for our localadmin user while we test this part.
export MAIL=~/Maildir
Viewing the logs
Remember to check the log files for any errors and warnings, there should not be any at all. In another terminal run tail -f on /var/log/syslog and /var/log/mail.log. I tend to use a short wide terminal for this. it helps stop the lines being split onto two or more lines.
tail -f /var/log/syslog /var/log/mail.log
Restart Postfix to take all those changes into use.
sudo systemctl restart postfix.service
This would be a good point to make a backup
Sending Your First Email
Now it’s time to send our first email 🙂 Are you sitting down, this is a momentous occasion after all!
To send our first email, login to mailserver and then we can use this command line
echo 'This is the body of our first email to localadmin.' | mail -s 'Initial email subject' localadmin
If you are running tail on /var/log/mail.log you should see something like this:
Sep 4 12:23:13 mailserver postfix/qmgr[766]: C77F325C9A: from=, size=505, nrcpt=1 (queue active) Sep 4 12:23:14 mailserver dovecot: lda(localadmin): msgid=<20180904112313.C77F325C9A@mailserver.dragon.lab>: saved mail to INBOX Sep 4 12:23:14 mailserver postfix/local[824]: C77F325C9A: to= , orig_to= , relay=local, delay=0.32, delays=0.06/0.02/0/0.25, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}") Sep 4 12:24:58 mailserver postfix/qmgr[766]: E1D1525C9F: removed
Read your first Email
Before we can use mail we need to fix the configuration. If you see an error message Maildir is a directory when you run the mail command we just need to use mail.mailutils and not the bsd-mailx module.
sudo update-alternatives --config mailx
There are 2 choices for the alternative mailx (providing /usr/bin/mailx). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/bsd-mailx 50 auto mode 1 /usr/bin/bsd-mailx 50 manual mode 2 /usr/bin/mail.mailutils 30 manual mode
Enter 2 for mail.mailutils and press return. Your mail command should now work okay.
To read your emails and especially your very first email 🙂 When logged in as localadmin
mail
When your mail command is working you should see something like this.
"/home/localadmin/Maildir": 1 message 1 new >N 1 localadmin 13/581 Initial email subject ?
Reading and deleting Mail
To read the email, at the question mark prompt, type the number at the start of the line, in this case 1 (one).
Return-Path:X-Original-To: localadmin@mailserver.dragon.lab Delivered-To: localadmin@mailserver.dragon.lab Received: by mailserver.dragon.lab (Postfix, from userid 0) id 675E5120534; Sun, 4 Sep 2018 11:21:34 +0000 (GMT) Subject: Initial email subject To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20161120112134.675E5120534@mailserver.dragon.lab> Date: Tue, 3 Sep 2018 11:21:34 +0000 (GMT) From: localadmin@mailserver.dragon.lab (localadmin) This is the body of our first email to localadmin.
I sent this email while logged in as localadmin as you can see from the headers. To delete this email type the email message number, again that would be 1 (one). Type help at the prompt to get a list of all the commands available.
There you go the first step is complete, a very simple mailserver. By the way, that was the easy part. 😉
This would be a good backup point!
Testing with Telnet
For testing out the mailserver you can also use telnet. Using these commands is a little more complex but means you do not need to install the mail utilities. See these blog posts:
Mail Server on Ubuntu 18.04 Part2 of this series will take us through allowing virtual users. That is you the Administrator will not have to create a local Linux user account for all the email users.
* I am amazed at the number of people who have sent in comments saying, They tried this and other posts I have written on a production server and they broke their server.” All I can say is How dumb are these people? Never, ever follow any blog or HOWTO on a production server. Always try new software on test hardware or virtual machines. If your company or boss will not provide the necessary test environment, ask them what would be cheaper a few hundred GBP to buy some new hardware to run virtual machines or the loss of your server until you rebuild it. Just in case you missed the message: Never follow any blog post or HOWTO on a production server.
Hello, thank you for this blog.
I am wondering though what is bad about using this as a guide? This is the most comprehensive and complete guide on the internet that I could find. About 4 years ago I followed this guide https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/ which was fantastic however Ubuntu 18.04 broke things and I did something wrong with my backup and it was broken. I have since been searching for a similar up to date guide and I thought I had found it here until I seen your warnings?
Kind regards
If you mean the warning at the top saying “*Do not follow this blog post on a production server unless you are [crazy|dumb|mad|nutz|stupid] and want to be unemployed!.” About once a month I get people adding comments, that I do not show, that say something similar to “We had a mail server that was working but needed updating. I followed you blog for XYZ and now it is not working, Please help”.
The post is designed to show one way to get a TEST mail server up and running. Follow all the steops, in the order I give them and it should work, it does for me 🙂 Once you have that working. You can play around try out some more settings and see what they do. If it breaks no harm done, You would have learned something. 🙂
Always follow blog posts on a TEST server you can throw away if/when it goes wrong. Do not remove, update or change you live/product server until you have the new one running and tested!
Too many untrained £$%^&&*£ say they are System Admins or Dev Opts when they do not have a clue or even any common sense. Do not test on a live production server. Test first on a test system. e.g. The Sub-standard Bank (TSB), National Westminster Bank ,Royal Bank of Scotland all in the UK should learn that but after 2-3 major failures each so far this year all of the IT Staff are still too dumb to learn from their mistakes.
Great tutorial man, as you said, it is always good to use settings on a test physical or virtual machine if something goes wrong, once when server it is up and running as it should you can use as a production machine, you explained a lot of things I need to know, thanks!