After my previous article, the general consensus of those who commented on it was that running an email server would be too hard on a Startup. Now, I tend to disagree. While running an email server is not as easy as, say, taking care of your laptop and keeping it up to date, it is nowhere as difficult as some people are making it out to be.
I will be the first to say I am no expert. I however, have run and maintained several email servers ever since I set up a Postfix, Dovecot and fetchmail setup configuration back in Intrepid Ibex and that should count for something.
I have thus decided to provide my own email server recipe in a “I show you mine and you show me yours” gesture with the hope that it will help others out there including myself.
No one has managed to break into any of my email servers, of all these only one was blacklisted in CBL and even then it wasn’t really my fault. My email servers send a couple of thousand emails a day mostly newsletters send via MailPoet and a couple of personal emails.
I only check into my server once a week, unless there is some sort of problem which there is almost never is. During my check ups I look at the mail.log and the mail.err log files and the auth.log files.
I also perform updates and do a spam test on one of my newsletters using Mail-tester.com (I have been getting 10/10 for the past couple of months by the way). On average I spent about 30 minutes once a week on the email server and considering I would have to spent about $50/ month for the personal email accounts and $20 on an SMTP service like MailChimp or Amazon SES I consider it totally worth of my time.
A couple of problems were outlined in these comments to support the case that running your own email server is difficult including: downtime, spammers breaking into your server or using your domain name and your email being marked as Spam. I believe today’s article, as shown below, and the ones that will come in the series will solve all these problems.
My email server recipe
- The first thing that you need to do is to find a reliable server provider. Given things like ZESA issues and price I tend to favour foreign data centers as they are cheaper and have good uptime. I usually use: Amazon AWS, Dreamhost, SDAPP, Digitalocean and Oneprovider. These providers also provide DDOS protection (usually for free) which might come in handy once in a while when your server comes under a DDOS attack.
- Choose a distro you are most familiar with. I have always used Ubuntu and if this is your first time or if you are unsure you should too. To be fair configuring an Ubuntu server is no easier than configuring say a Debian, Redhat, Centos or Fedora server but Ubuntu is very popular and chances are whatever problem you have someone out there has already encountered and solved it. You should always choose the latest LTS version of Ubuntu which is currently 14.04.2. In all the steps below we will assume you have chosen Ubuntu.
- Once you have successfully installed your VPS, disable remote create a user with sudo privileges and disable remote root login. Follow the guide here.
- Switch from password login to certificate login using this guide.
- For a long time my auth.log log file was filled with ssh bots trying to break in. Changing your default sshd port as shown in this guide might help but the relentless crackers out there might do a port scan until they find the port and continue with their siege. I have come up with a custom solution of my own.
- My main email server is hosted by Dreamhost and like a lot other cloud providers they provide a panel where you can restrict the IP address or range that can access a certain port under security policies. Like most people I do not have a fixed IP address that I use to connect to the internet. My service provider has a NAT setup which means my IP addresses is constantly changing even if I keep my equipment on all the time. To get around this problem I went to ip-details.com and discovered my IP address which is was described as “ZOL 16E CUSTOMERS ON ALVARION PLATFORM”.
- I then did a search using the tcpiputils.com website to discover the entire CIDR block. Which I discovered is 220.127.116.11/18. I then restricted ssh access to this block. I have also restrict access to the IMAP port to this block since I only ever access my email using this same IP block. This wiped out all the attempts to the ssh port and reduced them to zero. If you are not sure you can just add all the Zimbabwean IP blocks. It is highly unlikely that there are some Zimbos out there looking to break into your email server.
- To further reinforce and guard against brute force attacks I installed fail2ban and configured it to ban repeat offenders for a year. So any attempts to break in via ssh or Postfix will be automatically thwarted. Remember to add you main IP block to the exception list.
- Before I cooked up the above solutions, I simply uninstalled sshd from my server! I instead used the provided browser based Qemu installation that my server provider provides.
- Once I have secured my server I install and configure Postfix. In my opinion, it is the easiest MTA server out there and the default installation would work for most. I usually use this guide. I prefer it to the default one here because it does not use “PAM” authentication thus precluding the need to create actual physical accounts on the machine and risk a break in, in the event that some user has a weak password.
- Setup Postfix to reject mail from invalid domains and domains that fail reverse lookups. Using the directive:
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname, reject_unknown_hostname
- Reject mail from known spammers:
- Configure TLS using the guide I provided here.
- Have my service provider set up a reverse pointer record that matches my domain e.g. mail.myserver.co.zw.
- Setup a SPF record. We will look at how you can do this later on in the series.
- Setup DKIM signing and a DKIM record. We will also look at how you can do this later on in the series.
- Setup a DMARC record that expressly tells other smtp servers out there to reject all unsigned mail and all mail that does not come from your authorised mail server.
- Set up an alert at mailtoolbox.com for your domain to monitor possible blacklists on your IP and deal with them as soon as they occur.
- Have your users use a service like lastpass.com’s vault to generate and maintain strong passwords and change them regularly.
- Apply to the dnswl.org and tell them that you have done all the above and get on their whitelist.
- Set up an account at uptimerobot.com to monitor your server in and set up email alerts to your email account. Obviously this email cannot be on using the same domain name as the server so you can use your good old fashioned Gmail/Yahoo account.
- Check the Ubuntu CVE website here. Be sure to select the correct version of your Operating system. If there is nothing new it means there are no urgent updates on your server so you can update according to your preferred schedule.
- Check in at least once a week, read the server’s log files. I recommend using Atom.
NB One of the users made a remark about how Hotmail kept rejecting their email. This is probably because they have not set up the SPF,DKIM and DMARC records yet.
If you have and your email keeps getting rejected when you send it from Zimbabwe it is probably because you have not properly configured your email client. Usually this means your email client is sending mail directly and not via the MTA you have set up.
In fact if you have set up the three records above properly attempting to directly send email through your client should see it rejected by Gmail, Hotmail and most reputable servers because they would be following your directives not to accept such emails!
Another user cites possible misconfigurations and downtime as a reason for startups to avoid setting up their own email server. Well, if you choose reliable Data Centers such as the ones I have named above, downtime is something that will rarely happen if at all.
In any case most reputable MTA’s such as Postfix will defer sending email and attempt again thus largely negating any effects resulting from outages. As for misconfiguration causing problems, there are no really good reasons why one should mess with the above configuration once it’s set up.
If there is a reason for such changes they should be tested on another machine before being deployed into a productive environment and that is standard practice really.
I hope people find this useful and as always please feel free to comment and add to the article in the comment section.