There’s a number of howto’s on the web about how to configure an open-source email server. What I struggled to find is something that told me WHAT it was I was trying to configure, as opposed to HOW I should configure it.
If you have something working, and you break it – it’s easy to undo your change, work out what part of the change broke it, and then decide what you need to do to fix it. However what if I’ve never had something working in the first place? Have I misconfigured the software? Or is the software configured correctly but I’m expecting the software to do something it isn’t supposed to do? Both end up with it not working, but the solutions are drastically different.
In my view it’s important to understand not only the nuts and bolts of how to configure something, but be clear about what you are configuring it to do. That makes the whole process a lot easier
Assumptions here are that you have your own server, on the public internet, and you’re trying to set it up so you can send and receive email from it. I’m also assuming you own and manage your own DNS records. My server is running Ubuntu Linux, so I’ll refer to their instructions. If you’ve chosen something else then there’s actually an awful lot of configuration guides out there. This article is to try and help you work out what you’re trying to configure, not how to do it.
To start with then, here’s a baffling diagram illustrating how the different components interact:
The 10,000 mile high view:
Email comes in to the server via SMTP (Postfix) and stored on a filesystem. That email can be accessed by the user with a client talking to the IMAP server (Dovecot) which looks in the folders Postfix is delivering emails to. At a really high level that’s how it works.
Before delving into more detail, lets take a look at what the system needs to do
What before how
Lost of other places will show you the configuration options to setup the software components I’m going to talk about here. But before I talk about HOW to do something (and even then I’m only going to talk at a high level and leave configuration for the other HOWTO’s out there) – I want to talk about the WHAT. What was it I wanted to create? What would I have at the end of the exercise?
I wanted to replicate (well replace actually) my Gmail experience. To do that I needed to:
- Have a domain name people can email me at,
- Install Email Server Software that can receive email,
- Install Email Server Software that can receive email,
- Install Web Server Software that can show me my email through a web interface,,
- Configure the system so I can only see my email and not email for other users
- Configure the system so I can have pretend users (that’s kind of complicated and confused me for a while. Take it as read for the minute and I’ll explain it later),
- Make the system secure. I wanted the system to use encryption where possible so my information can’t be easily be read over a network connection. I also wanted the system locked down so it can only be used for the purpose it was designed and not as a SPAM relay.
Some of that requirement is iterative. Specifically point 6 wasn’t something I realised I wanted until I started learning about how to set the system up. I did however get completely bogged down in the configuration of the point 2 and point 3 – mainly because I hadn’t properly thought out what I was trying to setup. The errors in the logs didn’t make sense. I just dived straight into a “how to configure Dovecot / Postfix / SASL” HOWTO without thinking about what the end thing was going to look like.
Your requirements may differ (well probably will differ tbh). If some of this helps someone then great. The biggest thing I think will help is reminding people to have a plan before they start configuring.
SMTP – Sending Email
1. Have a domain name people can email me at
Email is delivered using the SMTP protocol. First off you need your DNS configuring. Every domain name has a number of attributes;
- A Records – the names of real servers
- CNAME’s – aliases to A Records
- NS Records – the DNS server that has the details about your domain
- MX records – Mail eXchanger. This is the email server for your domain
MX is what we are interested here. For PressedonTech a DNS search will tell you the MX record for pressedontech.com is mail.pressedontech.com.
2. Install Email Server Software that can receive email
I selected Postfix for this tool (partly because it was already installed, partly because there was a lot of related documentation, partly because I hate SendMail).
Postfix is a Mail Transfer Agent (MTA) and it’s doing two jobs.
- Inbound email;
- Postfix listens on TCP Port 25, using the SMTP protocol, to receive email ,
- Postfix is checking it’s the right server for the email it’s being asked to process (i.e. it is configured to process email for pressedontech.com)
- Postfix is checking it is configured to send the email to the place it’s being asked to? For pressedontech.com it’s storing email on the server filesystem. Other configurations will tell Postfix to pass on the email to someone else. If that’s not what you want then make sure you aren’t telling Postfix to do that. Potentially you’re allowing your server to be a spam relay.
- After it’s passed these checks it puts the email where it’s told to (or errors if the checks fail 🙂 )
These things are important because spam is an issue on the internet. Postfix is making sure the SMTP client isn’t trying to use my installation to send email pressedontech.com isn’t authorised to .
2. Outbound email
- Postfix is sending email on your behalf to MTA’s running on other computers using SMTP.
- Postfix is looking for outbox messages, for your user, (on the unix filesystem in my case) and then trying to deliver them
To recap – Postfix is the Mail Transfer Agent that controls the delivering of email in and out of my server. The next step is something that can show that email to a user. Read on to find out more…..
IMAP – Reading Email
3. Install Email Server Software that can receive email
Email has been delivered to you server using SMTP. How do you read it?
IMAP is the Internet Message Access Protocol. IMAP client software talk to IMAP server software to access messages in mailboxes on the server.
You can use the POP3 – the Post Office Protocol if you like. For a massive oversimplification – IMAP is better for accessing email on a server. POP3 is better for downloading email to a computer. For my use case I can imagine multiple IMAP clients talking to my server so it makes more sense for me to use IMAP and not POP3.
From the search I did, there were two options for a Linux / Open Source based IMAP Server. Cyrus or Dovecot. Cyrus is a much older and more mature project. However Dovecot seemed to have much more recent documentation available, and more howto’s and forum threads that seemed related to what I was trying to do. So I picked Dovecot.
Next is second part of reading email, the web interface….
IMAP – Reading Email – part 2
4. Install Web Server Software that can show me my email through a web interface
For my use case, I expected to want to read email on my phone, and read email in a web browser interface from my PC. I could have just set up another desktop IMAP client but webmail seemed to be the way to go (I suspect this is Gmail brainwashing but it was something else to learn so I went with it. For this I selected Roundcube.
Roundcube is a PHP application. In your web browser you log in to the Roundube application. Roundcube then talks to Dovecot and shows you your emails. Roundcube stores it’s own configuration in MySQL (hence the database requirement).
But how does Dovecot know how to show Roundcube just my email and no-one elses? Follow through to the next page to find out…..
Each User has their own email
5. Configure the system so I can only see my email and not email for other users
Dovecot is acting as the authentication process for everything.
- When Postfix receives an email to process it asks Dovecot “does user@pressedontech.com” exist? If it has a valid user it lets Postfix know. It took me ages to get this bit right. If enough people want it I can post my final config but there’s plenty of technical documentation to help you sort this out.
- When a user on their smartphone connects through the mail app, it’s providing a username and password. Dovecot checks and provides access to the appropriate mailbox, assuming that exists
If you look at the various DoveCot / Postfix forum posts, it’s the integration between these two software components (specifically getting Postfix to authenticate users using Dovecot’s authentication process) that seems to be the one thing that gives people the most headache. First off I setup Dovecot to authenticate against real users
Dovecot can check against real system users (i.e. a UNIX user who can ssh onto a server, a separate file with email only users or data in a database such as MySQL). This is where I came unstuck as well because many of the HOWTO’s talk about virtual users – description which makes sense in hindsight but I didn’t properly wrap my head around when trying to troubleshoot why Dovecot wasn’t talking to Postfix properly. By configuring Dovecot against real users first, I got the basic system working before trying to do something clever.
A virtual email user means that I don’t need a real UNIX user to send email to someone. Why is that important? If I want a secure system, I don’t want the username’s and passwords of users that can log in via ssh spread across the internet. By configuring virtual users I can send email to tom@pressedontech.com, dick@pressedontech.com or harry@pressedontech.com without needing those real users on the system. This can be implemented using encrypted flat files, or with a database backend. I chose to use MySQL and the final configuration looked like this:
Next we learn about making the system secure
Security Security Security
7. Make the system secure.
There’s a few best practises to consider here.
The first is to expose as few services to the internet as possible. Therefore
- I don’t run a POP3 Server because I don’t see an immediate need to use POP3. This is a key principle of only configuring the minimum set of services required. If you configure a service then you’d better make sure it’s configured properly. If you aren’t going to use a service, then why waste time configuring it when you could just disable it and focus your efforts on doing a better job with the services you are going to use
- I do use a firewall. Belt and braces here. I think I’ve disabled services I don’t need. With a firewall configured then I’m making extra sure that I’m only exposing the services to the internet that I intend to.
- As many of my services as possible are routed through the localhost / loopback / 127.0.0.1 IP address. I’m not providing database services to the internet so why would my MySQL server need to be contacted by an internet IP address? By using either local UNIX ports or non-routable IP Addresses you are limiting the amount of traffic you are sharing outside of the service and reducing the attack vectors for your server
- Encrypt as much as possible. For the services I do expose to the internet, then these are configured using TLS. At the minute I’m self signed, mainly because it’s just me using it. But it gives me the confidence that I’m not passing my username and password details around in plaintext for all to see.
My secondary concern was around not turning my system into an open spam relay. I don’t want other people using my SMTP server to send emails pretending to be from my domain because
a) because that’s not cool.
b) because that will get my domain and IP blacklisted so my own email won’t work
c) I’ll probably get moaned at and potentially switched off by my ISP. and I don’t want that either
As part of configuring the system I spent a fair amount of time on this topic, making sure I understood how to lock the system down, how to prevent unauthorised users and how to only relay for my domain.
External checking
There were a number of tools I used once I had my system up and running. The first was a portscan to check I was only exposing the services I thought I was exposing. Secondly I used a number of different websites to check my server wasn’t acting as an open spam relay. Notice here I said I used more than one service. I did this for both the port scanning and the SMTP relay check. Using more than one tool gives you the extra confidence in your results. It’s one thing to think you’ve done it correctly. It’s another to have someone else check your homework. This was one of the key points in making sure I was happy with what I’d setup.
It took me several days of trial and error to get my system up and running. During this period I made a point of switching things off whilst I wasn’t configuring them. I would make some progress, hit a roadblock and leave the system to come back another day and try and make more progress. It would be silly to leave a half configured or misconfigured service live on the internet so when I wasn’t configuring, the services were disabled.
Finally make sure you’re patched and up to date. If you’re using a Linux system with a package manager, it’s a 5 second job.
I don’t think any of these make my server hack proof. Nothing is invulnerable. However by taking these options your making it less vulnerable and reducing any options potentially hackers may have.
In Summary
Hopefully that gives a good overview of how an internet email service can be setup.
There are lots of other websites out there giving instructions on how to configure the email software, which options to pick, how to generate self signed certificates, etc. What I wanted to do here was give a high level view of what you were trying to configure and not duplicate the other places that tell you how to configure it.
As per usual, any feedback or clarification on what I’ve written here is always welcome. I hope some of that info is useful to people