Mail protocols

This is a copy of an article in C't 08/2021, which I have translated from German to English and make it a little more generic but it entails an overview of issues related to email which is important for more people to understand.

In many companies, office work would hardly be possible without e-mail. If you want to run your own mail server, you have to know exactly how the protocols work and what to watch out for. Otherwise it will be flooded with spam or even become a spam sling itself.

This article is intended to provide administrators who want to operate a mail server the necessary background knowledge so that this can be done safely and, above all, with little spam. But it is also important for users to understand how e-mails work technically, where there are problems and why spamming and fraud are so widespread. If you click carelessly when setting up a mail account in Thunderbird or Outlook, you may be able to email, but you risk unpleasant security problems and in the worst case could send your access data unencrypted every minute through the unsecured hotel WLAN.

The core of the mail infrastructure are mail servers that are on the Internet and communicate with other mail servers. There is no central instance where you have to register as a server operator in order to participate in the global system. The only requirements are a domain and suitable DNS entries for it.

MX: to be found

If you want to operate a mail server that accepts messages, you only need mail server software that listens on port 25 in the Internet and a suitable port release for this port in the firewall. If another mail server wants to deliver a mail to your server, it will first ask the DNS under which address your mail server can be found. For receiving mail servers there are entries of the type MX (for "mail exchange") in the DNS.

An MX record contains an indication of the priority - a natural number. In order to create redundancy in reception, it is quite common to publish several mail servers as MX entries. The sending mail server retrieves them all and first tries the server with the lowest priority value. If this does not answer, he tries the next one, then the next one. An MX record does not contain an IP address but a full name (FQDN), for example mail1.example.org. In order to resolve this name to an IP, another DNS request for the A or AAAA entry for an IPv4 or IPv6 address is necessary. For example, the MX entry for heise.de looks like this when queried with `nslookup -query = MX heise.de`:

heise.de mail exchanger = 10 relay.heise.de.

host greenhost.nl
greenhost.nl mail is handled by 10 mx1.greenhost.nl.
greenhost.nl mail is handled by 10 mx2.greenhost.nl.

If you only operate one server for a domain, on which, for example, the associated website is also located on ports 80 and 443, you can also completely save yourself the MX entry. If a sending mail server does not find an MX entry, it tries to deliver the mail to the A or AAAA entry of the domain, for example directly to example.org.

As soon as you connect a server with port 25 to the network, it can receive mail - and it will almost certainly do so soon. Even if nobody knows the domain. Spammers have nothing else to do than scan the Internet and harass servers with open port 25 with their garbage. That this works so well is due to the structure of the SMTP protocol used.

SMTP

SMTP, the Simple Mail Transfer Protocol, is a real veteran of the Internet, first specified in RFC 821 from August 1982 (later replaced several times by newer versions). Two mail servers among each other use SMTP to deliver mail to the other. The process of such an SMTP session is very simple and you can easily simulate it on the command line with the command telnet (Linux, macOS). Under Windows you have to activate this basic function as a Windows feature (see ct.de/y744). Open the command line of your choice. First of all, you need to find a mail server to test that doesn't immediately identify and reject you as a spammer - Google, for example, allows the experiment almost to the end. Use one of Google's many MX records and start an SMTP session as follows:

telnet gmail-smtp-in.l.google.com 25

To avoid typing errors: The letter before google.com is the consonant L. You handle the following dialog with the server by typing the lines and confirming with Enter. First, you need to introduce yourself as the sender:

EHLO example.org

EHLO is not a typo, it is written into the standard. After the greeting you can announce the delivery of an email:

MAIL FROM: test@example.org

In the next step you pass the recipient of the mail:

RCPT TO: example@gmail.com

The angle brackets must be and a space after the colon would cause a syntax error.

Now initiate the transfer of the content with the following line:

DATA

The subject is part of the content and is first transmitted in one line:

Subject: A test mail

An empty line (Enter key) must now be sent. Only then can the content of the mail follow:

Moin, this is a test.

The transmission ends with another blank line, followed by a line that contains only one point. This means that the server knows that the mail has been completely transmitted:

So you know the complete dialog that two mail servers conduct with one another. The receiving server would now process the mail and put it in the mailbox of the correct user. You probably won't be able to do that with Google - the company has put some effort into removing unwanted mail. For example, the reaction from Google when trying from a home address looks like this:

Our system has detected that this
message is suspicious due to the very
low reputation of the sending IP
address. To protect our users from
spam, mail sent from your IP address
has been temporarily rate limited.
Please visit
https://support.google.com/mail/
answer / 188131 for more information.

So Google's servers have a problem with your IP address and reject you as a spam suspect.

Spam and spoofing

SMTP itself has no protection against spam. It was designed as a means of communication for government institutions and researchers. Anyone who spam got into personal trouble because the annoyed colleague showed up in the office. In the public Internet, of course, things look different and the weaknesses of SMTP quickly became apparent.

In the example dialog you introduced yourself with EHLO example.org, although you do not own this domain. SMTP does not have a mandatory check here. A common mistake is that only the server with the A record for example.org in the DNS is allowed to send. That is not true and would not be desirable, after all, the website and mail server do not have to run on the same server or be connected to the same connection on the Internet. Because SMTP is so generous there, you can also pretend to be the server bundeskanzlerin.de at EHLO and try to send mail from a.merkel@bundeskanzlerin.de to other servers. SMTP doesn't stop you.

Such fakes are known as spoofing. As a receiving server, you have to install filter systems to protect yourself from such attempts as much as possible. The most important information for admins and users: All spam and spoofing protection measures are only approximate solutions and never perfect! They are based on probability estimates and good spam protection from several filter levels. Part of the work of the admin is to adjust these filters from time to time and to give them weightings so that as much spam as possible and as little important as possible is destroyed. A recognition rate of 100 percent and an error rate of 0 percent are utopian.

Private connections

At best, the filtering begins at the SMTP level, i.e. before the sender announces his mail with DATA. If your server cuts the connection to a spammer beforehand, RAM, hard drives and cables are not even loaded with garbage. One of the anti-spam measures that most server operators already use at the SMTP level is a rough check of the IP address. A server can dispose of a lot of spam even before delivery, if it simply does not accept mail that has been sent from a customer connection with dynamic IP. Such spam is mainly caused by malware on PCs or hijacked smart home devices. Attackers remotely like to reprogram systems that have been taken over into spam slingshots.

Almost all recipients first of all check the so-called reverse DNS entry (PTR entry). This is a text entry for an IP address that internet customers cannot change themselves. With a cable connection from Vodafone, for example, it looks like this: ip123456.dynamic.kabel-deutschland.de. The information "dynamic" reveals that this is not a typical server address with a static IP, but one that is dynamically assigned to customers. In that case, a receiving server can actually end the session. If you as a company have booked a line with static IP or rented a server in the data center, you can change the PTR entry with your provider (for rental servers also directly online in the customer center), for example on mail1.example.org The PTR entry must contain exactly the name with which the server introduces itself to an EHLO.

Here, too, there is a common mistake: Contrary to what is said to the contrary, the PTR entry does not necessarily have to correspond to the domain from which you want to send - a server can send from several domains without any problems. The servers of our publishing house send for example from heise.de, ct.de and ix.de, but can only have one PTR entry per IP address - as an admin you have to decide on an entry in the PTR entry and also this name in his server for the EHLO greeting. In addition to the PTR entry, many admins use blacklists such as the “Policy Block List (PBL)” from Spamhaus (spamhaus.org). It contains a regularly updated collection of IP addresses that are marked as end customer connections by the providers themselves. This list rarely contains errors.

If you are toying with the idea of operating a mail server that can send emails, you absolutely need a static IP address. All attempts to operate a sending mail server on a home connection are doomed to failure. But what works well is a small rental server in the data center with static IP.

Send successfully

But how can an ordinary user write a mail to another mail server at all when it is blocking SMTP sessions from ordinary Internet connections? The sender's mail client, for example Outlook or Thunderbird, also uses SMTP for sending, but never communicates directly with the recipient's server. Instead, the client delivers the mail to its own mail server and leaves it to the latter to deliver the mail to the recipient. SMTP is used in two ways: for communication between servers and for delivering e-mails for forwarding by the client.

So that not everyone can use your mail server to send orders, the client must first log in - usually with a user name and password, more rarely with methods such as NTLM. Authentication was not yet provided for in the original idea of SMTP and was only incorporated later. In such authenticated sessions, a properly configured mail server also checks whether the logged-in user is authorized to send messages from the specified sender address. Anyone who has logged in with user@example.org should not necessarily be allowed to send from admin@example.org.

When setting up a mail program like Thunderbird, you should make sure that the login to the SMTP and IMAP server is encrypted.

Send successfully

When setting up a mail program like Thunderbird, you should make sure that the login to the SMTP and IMAP server is encrypted.

As with all protocols from the early days of the Internet, encryption is not mandatory for SMTP either - not even for authentication with user name and password. If you don't do anything else, the client would always send this sensitive access data unencrypted over the network, which is a massive problem with public WLANs at the latest. There are two options for encryption: STARTTLS is widely used, a procedure that allows both encrypted and unencrypted communication on one port (see page 149). The decision for STARTTLS is based on the assumption that there are still good reasons for an unencrypted connection when delivering mails. With the RFC 8314 of the IETF, which appeared in 2018, the rethinking in the scene was put on paper: It bears the promising title "Cleartext Considered Obsolete" - there are no plausible reasons for unencrypted deliveries. Instead, it is recommended to use implicit TLS, i.e. to encrypt every session immediately. STARTTLS is not more insecure per se, but it is completely unnecessary if it is called for every connection anyway. Then it is sufficient to set up TLS immediately on a separate port.There is some confusion around these two encryption options and there are two ports. In the IETF standard, port 587 was initially provided for the delivery of e-mails. Contrary to custom, the Internet Assigned Numbers Authority (IANA), which is responsible for reserving standard ports, also kept port 465 free for SMTPS (i.e. SMTP with encryption), this was withdrawn and the port explicitly planned for the authenticated submission of mails via SMTP later. Which port the operator provides is his decision - he just has to inform his users. The RFC currently recommends offering both STARTTLS on port 587 and implicit TLS on 465 in the next few years. In the long term, STARTTLS should then give way. Important for all server operators: So that no user accidentally logs in unencrypted, you should set up your server software so that STARTTLS is forced on port 587. End users who are unsure whether they have configured their mail client correctly should check the account settings of their software to see whether SSL / TLS or STARTTLS is checked. Encrypted transmission is now being enforced by the major providers. Unfortunately, unencrypted transmission is often still possible with small hosters.

As always with SSL / TLS, the server operator also has to take care of a certificate for a mail server that the clients accept. The certificate must therefore be signed by a certification authority with a trustworthy root certificate. The same rules apply here as for a web server that is published via HTTPS. At Let's Encrypt, admins can obtain a certificate free of charge that all common clients accept.

Incidentally, STARTTLS is not only used between client and server when delivering. More and more server operators have learned something new in terms of security and have also activated transport encryption with STARTTLS for the server-server connection on port 25. This means that a mail is not end-to-end encrypted, but it is still on most of the connection. Some recipients, for example the Lower Saxony tax authorities, even refuse to accept emails without STARTTLS.

Open Relays and Reputation

When SMTP was invented, the recipient was sometimes unavailable. It was therefore absolutely desirable that every server in the network should work as an open relay - whoever was currently active and available accepted every mail and then tried to forward it to the actual destination. For example, friendly server operators could set each other as MX entries and thus increase the likelihood that emails would arrive. This was a useful idea for a network of friends, in today's internet with professional spammers, open relays are one of the biggest problems. If you run a mail server yourself, you must make sure that it does not inadvertently work as an open relay and accept unauthenticated mails for others on port 25 and forward them.

If you run a server and take a look at its logs, you'll quickly see that spammers are regularly checking you for open relay configuration. If you are identified as such, the storm begins: the spammers dump their garbage messages on your server and let it do the dirty work of delivering the spam to the recipients' servers. After a few hours as an open relay, your server either collapses under the load or suddenly ends up on all relevant spam blacklists. In the case of rental servers, the data center operator also intervenes quickly.

To prevent all of this, it is a mail admin's top priority to start an Open Relay test immediately after setting up the server - for example with a suitable online tool (see ct.de/y744). A correctly configured server only accepts mails that are intended for itself without registration.

The hunt for spam is primarily about the reputation of the sender, i.e. an estimate of how trustworthy a sending IP address is. In addition to the Spamhaus organization, there are other operators of lists that provide information about the reputation of a connection to support admins. Anyone who attracts negative attention, for example as an open relay, ends up with their IP - or even worse, the domain - on such lists. It is therefore important to configure the server properly from the first minute. Getting an address removed from all blacklists is not easy. Sometimes you just have to fill out forms, and elsewhere you even have to pay money. If you take over a new connection with static IP or a rental server with IP, you should use online tools (see ct.de/y744) to check whether the IP address has already been burned because the previous owner is a spam-thrower was active. If the address is on more than two lists, you'd better contact the provider and have them give you a different IP. If an entire IP segment is blacklisted, you have a serious problem. If nothing helps, you can only change the provider or ask them to contact the operators of the lists.

Another important remedy against unpleasant entries on blacklists is a limit for mails per user in a period of time. Especially if you have a lot of users on the system, you should take this measure. Imagine if a user has a very simple password that they also use elsewhere. If it is leaked somewhere, spammers can use it to log into your server and spam others on behalf of your user. Sooner or later your server will end up on blacklists and you as the admin will have the work. Almost all mail servers have an option to limit the number of mails per user per hour. An ordinary employee does not usually have to send more than 50 e-mails in 60 minutes.

Mailbox access with POP3 and IMAP

E-mail users have the most contact with POP3 and IMAP. After all, they want to read their emails too. Both come from the core of the 80s and solve the problem quite differently. POP3 has the more manageable range of functions:

A client logs on via POP3 with the USER and PASS commands, can then use STAT to check the number of mails and the size of the incoming mail and call up an overview with LIST. He downloads a single mail with RETR and deletes it on the server with DEL. Everything else happens offline for the user. If, for example, he creates sub-folders and sorts his mail there, the server will not find out about it. In addition, the server with POP3 does not know whether you have already read a mail. At the latest when you use several clients (for example on the PC and the mobile phone), POP3 is no longer fun. Today POP3 is a protocol for nostalgic lovers and special applications. For example, if a script is to automatically retrieve all messages from an old mailbox and put them in a new mailbox, POP3 will do just fine.

Because POP3 is not particularly flexible, IMAP has become the standard protocol. A few pages of text would be required to describe its range of functions with all options. IMAP is responsible for everything that you know and appreciate as a user of a modern mail program: The IMAP server manages mailboxes and their nesting and all clients map this synchronously. E-mails can be moved to folders via IMAP, marked as read, given flags or thrown in the trash. The changes appear very quickly on all devices that speak to the server via IMAP. When you send a mail from an IMAP client, two things happen one after the other: First the mail is delivered to the server via SMTP, then a copy is sent via IMAP to your sent folder.

One of the biggest annoyances is that the standard is not strict enough: the names of the Sent, Trash and Drafts folders are not standardized. For example, one client application can name the folder “Sent”, another “Sent” or “Sent items”. However, this can almost always be adjusted by hand. If you are wondering that e-mails are missing in these folders on some devices Search deep in the settings of your software for the appropriate option and change the names.

Of course, POP3 and IMAP are also initially unencrypted (because they have grown over time). POP3 works in plain text on port 110 - optionally with STARTTLS after the greeting. Because passwords are transmitted, unencrypted transmission is also prohibited here. STARTTLS has to be made mandatory as an admin. It is even more consistent to close port 110 directly and only allow implicit TLS on port 995. In many environments you can save yourself POP3 completely, because almost all users only want to use IMAP.

The same applies to encryption for IMAP. Unencrypted IMAP on port 143 is obsolete, mandatory STARTTLS is the minimum. Because there are no alternatives to encryption anyway, IMAP with mandatory TLS on port 993 is also sufficient.

Even with IMAP and POP3, it is worth taking a look at your client's settings as a user. Because some providers still allow unencrypted connections, it is possible that you have inadvertently sent your access data unencrypted over the network for years. The checkmark for SSL / TLS or STARTTLS is mandatory!

In addition to IMAP and POP3, there are also proprietary protocols, mainly from Microsoft. Over the years, the developers have come up with various protocols for the corporate mail server Exchange - above all MAPI and ActiveSync. SMTP, IMAP and POP3 speak Exchange servers nevertheless, so that users can also work with clients like Thunderbird.

Fine tune

If you as the operator of a mail server have avoided the worst mistakes and did not immediately attract negative attention as a spammer, over time you have to make optimizations in two areas: First, you should ensure that as much spam as possible is filtered. In addition to further filter measures that take effect at the SMTP level and prevent transmission, there are also downstream content filters that look at the mail and, for example, react to keywords ("Casino", "Viagra") or suspicious linked URLs. Such spam is usually moved to a separate mailbox, where the user can still find it in an emergency - while the users never find out about spam that has already failed at the SMTP level.

You also have to make sure that your emails reach others reliably. You will find out in one of the next issues how you can set up filters yourself and use trust-building measures such as SPF and DKIM to ensure that others do not filter you.

You do not have to worry about running your own mail server if you already have administrative experience with other servers - even if this introduction may seem daunting at first. Small optimizations have to be made to spam protection and delivery to other servers from time to time (because spam also adapts itself again and again). But this is not a full-time job and your own mail server can also be a worthwhile project for small companies or organizations: You have full control over the data and do not have to rely on the quick reaction of an external company in the event of delivery problems. (jam@ct.de)

IETF standards: ct.de/y744