I look after a few email servers and after implementing much stricter encryption settings at the start of the year, I noticed some emails were never making it to accounts - being rejected at the negotiation stage (where the remote server sending the email agrees an encryption protocol and cipher with the local server).
I was puzzled by this. TLS is hardly new, yet these servers were only ever attempting to use SSLv3 and then failing to 'upgrade' to TLS - not even TLS1.0. Poor show.
This isn't unique either - I periodically run a script which reports the spread of protocols and ciphers of incoming email connections; here's a sample from one server for the last hour...
...The stats don't make for pretty reading:
Today I needed to use - and install - DiG (Domain Information Groper!) on a Windows 10 box. Of course, Windows is useless when it comes to CLI tools - nslookup is past its prime and not even Windows 10 includes much by way of useful tools for DNS queries. It's shipped as part of the BIND9 DNS software from ISC.
So, let's see about DiG... Good news, everyone! - BIND9 is available for Windows, but I don't want to install the whole thing, ain't nobody got time for that. So, let's see about excerpting just the DiG executable and getting it so you can use it without specifying its full path every time, which will require setting its location in the PATH variable.
There's quite a few guides and tutorials to installing DiG on Windows. The simplest one I found was from Websistent, who recommended downloading their own zip of DiG and its necessary DLL dependencies, dropping those into windows\system32 (urk?) and using as normal.
We can do better than that:
Click to see how simple it is!
Fail2ban's official compile for CentOS6 has never advanced beyond 0.9.6-1.el6.1. While 0.9.6 works, it's old and has a few major inconveniences:
- No IPv6 support 🙁
- A tendency for the daemon to die when parsing many logs or a high volume of activity
- Quite slow to parse logs when restarting after a config change
So, what can we do? Well, compile from source and upgrade with the supplied python script! It's easier than I anticipated, but there's still a few things you need to watch out for.
Postfix is great, and widely used, but freshly installed it's like a newborn child. Nowadays there's a lot of work required to get it to an acceptable level to face the wild west of the Internet.
NB: This is a living document and will probably change over time as I revise my own methods for managing my servers.
Running an MTA to an 'acceptable' standard now requires lots of additional config and tuning, but it's satisfying once done. Be prepared to learn lots about DNS, TLS, certificate structure, mail filtering (miltering), regular expression and monitoring - crucial once your system is operational.
Once you've had your fill of the RFCs (https://www.fastmail.com/help/technical/standards.html), there's plenty other stuff to learn. http://www.emailarchivestaskforce.org/documents/guide-to-email-standards/ is worth a read, and are you sure you know how to validate an email address? https://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/
For newcomers, important areas to cover are:
- understanding quirks of different email clients, some of the odd scenarios with specific email services
- familiarising oneself with the certificate process
- how TLS is employed with email
- Hands-on experience is crucial!
- Doing dry runs with a dev system is invaluable - you must be able to make and break things without taking down customers' email 🙂
I administer shared Postfix servers for numerous clients. Some are newest releases of Postfix, and some, due to legacy requirements, are older. Nothing necessarily wrong with that, but some configuration options aren't always available.
If I was setting up a new Postfix server today, I'd go through these steps:
Continue reading "Setting up a secure Postfix server in 2019 - what to consider?"