How to: Running and securing your own email system

Email is one of the oldest protocols on the Internet. Despite its advanced age, it continues to be among the most popular, too.

While many individuals and organizations opt to outsource their email to Google, Microsoft (Office 365 / Hotmail / Live.com) and others, this is not an option for everyone. Some industries impose strict regulatory constraints on data ownership and individuals worry about their privacy (justifiably!).

It can also be argued that centralizing a key protocol with a handful of large American tech giants goes against the decentralized spirit of the Internet.

Running an email server

Setting up an email server is not very difficult. Most Unix-like operating systems include sendmail or an alternative out of the box. Some Linux distributions do too.

A more challenging task is keeping a mail server secure and ensuring that other servers will accept the email it sends.

Email in the ‘reputation’ era

Spam is almost as old as email. According to Wikipedia, the earliest documented spam was sent in 1978.

On today’s Internet, as soon as a machine is connected it will start receiving email whether it wants it or not. Since most machines are not going to be interested in receiving email, blocking connections through TCP port 25 (SMTP) is a good default policy.

With spam comprising the vast majority of email on the Internet, even systems that are interested in receiving email will still be configured to drop most of it. Increasingly, mailbox providers will drop email based on the sender’s ‘reputation’ without even looking at its contents.

Real-time blackhole lists

When accepting a connection, most email servers will be configured to consult one or more real-time blackhole lists (RBLs). Some of the most often used lists are operated by the Spamhaus project but many others exist. If a server is listed in one of these blackhole lists, any email it tries to send will likely be rejected.

In addition to real-time blackhole lists, there is also a real-time whitelist: DNSWL.

Staying off the blackhole lists and being on the whitelist are good ways to help ensure email will be accepted. Sending spam will get a server listed on the blacklist. A long history of not sending spam will keep a server listed on the whitelist.

SPF, DKIM and DMARC

In addition to keeping servers off blacklists and on whitelists, there are three DNS-based technologies that can help ensure email will be accepted:

• Sender Policy Framework (SPF) lists the IP addresses a domain considers acceptable for sending email from. If email from a domain arrives from anywhere else, it will be treated with suspicion (or even rejected).
• Domain Keys Identified Mail (DKIM) is a mechanism for cryptographically signing email headers. As part of their arsenal of spam filters, receivers will verify that headers are correctly signed before letting a message through.
• Domain-based Message Authentication, Reporting and Conformance (DMARC) ties together DKIM and SPF. DMARC allows domain owners to indicate to receivers how email that fails DKIM or SPF should be treated. They can also specify a reporting mechanism which helps monitor forged email from their domain.

Each of these works by adding TXT records to a domain in the DNS. With DNSSEC, receivers can have reasonable confidence that the policies were put in place by the (purported) sending domain.

Content filtering

A server’s reputation will determine whether other servers will talk to it at all. At this stage, content filtering kicks in.

Content filters will inspect received messages for malware, unexpected legacies from Nigerian princes and other unwanted content before moving the message to a user’s mailbox. Older content inspection filters will check long lists of regular expressions. Newer technologies use neutral networks trained on large bodies of good and bad messages to evaluate a message’s desirability.

As content filters can never be perfect, a message considered bad by a content filter is more likely to be filed as ‘junk’ rather than rejected outright. Some more advanced content filters (for example Rspamd) will track a message’s score and decide to reject or file as ‘junk’ based on configurable thresholds.

Best practices

Keeping email working in the reputation era may feel like an onerous burden, but with some best practices, it need not be very difficult:

1. Monitor a mail server’s reputation by regularly checking blacklists and whitelists.
2. Scan outbound email for malware and spam. A server’s reputation rapidly deteriorates when it sends any spam — even accidentally.
3. Implement SPF and DKIM policies. If practical, consider implementing a DMARC policy.
4. Block TCP port 25 (SMTP) for systems that don’t send email. Larger receivers increasingly track the reputation of network blocks rather than individual addresses. If a server is in a terrible ‘network neighbourhood’, its messages are unlikely to be treated favourably. Appropriate access control lists will go a long way to keeping legitimate servers in good standing.

Don’t give up!

Inevitably, some email will be rejected or filed as junk — especially when just starting out with a new mail server. With good outbound policies however, a server’s reputation will gradually improve and its email will be accepted and filed in the recipients’ inboxes.

As with any other server connected to the internet, mail servers should be regularly updated. An unpatched server — or a misconfigured one — can quickly do untold damage to a network’s reputation. And rebuilding a bad reputation can take a very long time.

It may be tempting to simply outsource email to one of the giants but there is immense satisfaction in keeping ownership of your data. With a little effort, keeping a mail server running securely can help keep your data firmly under your control.

Philip Paeps is an independent consultant and contractor. He provides research and development on low-level software and operating systems, particularly in an embedded or real-time context.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.