Everybody uses e-mail. It’s great.

Not everybody understands exactly how e-mail works, and even fewer people have ever tried to set up a mail server. For those of you who have, I can pretty much guarantee you that you’re doing something wrong.

Even if you aren’t setting up your own mail server, you really should understand the limitations of e-mail, especially in terms of security.

So, in this post I’ll try to give a simple and quick intro to e-mail and mail servers

If you are an admin looking for a postfix or exim “quick answer” that you can copy and paste, you must read this more than anyone!

First, let me just say that this article doesn’t include any specifics about how to set up a mail server. For that, you really will need to dig in to the documentation of exim, postfix, or whatever you’re using on your server. The problem is that most often, admins simply Google it, and they take the first thing they find that works.

All set, right?

No, actually.

You see, configuring a mail server is really, really, really not simple. It’s extremely rare for anyone to get it right on the first try. In my own attempts, I noticed that I could never find a simple, down-to-earth explanation of exactly how mail works. If I’d had that, the mail server docs would have made a LOT more sense.

So, that’s what this post is about: the basics.

Let’s begin with a brief history of e-mail

In the olden days, e-mail was extremely basic. You had a mail server (software) running on a physical server (computer) connected to a network. For clarity, we’ll call the mail server software an MTA (mail transfer agent) from now on. The mail client like Thunderbird or Mac Mail that you might be using is known as an MUA (mail user agent).

So, in the old days, MTA’s were rather simple. You could connect to an MTA and send a message – often to anyone else as anyone else. This didn’t last long, because authenticating users is a good idea. You want your MTA to limit who can send mail from your system! Poorly secured MTA’s are also a spammer’s dream, which you often hear talked about as an open relay. That’s bad. It means your MTA is not configured properly, and people can send mail using your system without proper authentication.

The client (MUA) and server (MTA) use the SMTP (Simple Mail Transfer Protocol) to have a “conversation” in order to send or pass on e-mail. It goes something like this:

1. USER: Connect to MTA
2. SERVER: I’m here! Are you?
3. USER: Yes, I’m here!
4. SERVER: Okay, here’s what you can do (gives list)
5. USER: Thanks. I’d like to: send mail (or authenticate, or whatever)
6. SERVER: [Stuff Happens] K, it’s done.
7. USER: Thanks! Bubye.
8. SERVER: Bubye.

In real life, for testing you’d want to use a command like: telnet mail.example.com 25

That would result in something like this:

Trying 11.22.33.44...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian)

Then you’d pretend you’re an MUA or MTA by typing:

ehlo mail.example.com

And your server should respond with something like:

250-mail.example.com
250-PIPELINING
250-SIZE 10000000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

At this point, you can send a message, start TLS (more on that later), quit, etc.

You’ve Got Mail!

So far, we’ve been talking about sending mail, and it usually happens on port 25 or 587. Note that the MTA you set up also serves the function of passing e-mail between servers – it’s not just there so you can send mail out. Other MTA’s need to be able to connect, and pass mail along to your server so you can download it.

These days, usually the exchange of mail between servers happens on port 25, and when a user wants to securely send e-mail out, they use port 587. Note that you need to configure these ports on your MTA, unblock them in your firewall, etc. This part requires an MTA server such as postfix or exim.

And then, you need to be able to download that mail, which is done often insecurely on port 110 for POP3, securely on port 995 for POP3S (SSL), or port 143 for IMAP or 993 for IMAPS. POP3 and IMAP are two different protocols for downloading your mail from the mail server.

Keep in mind that configuration is required… you don’t just “install” POP3S, for example. You will need another bit of software like dovecot, which is a POP3 and IMAP server, in addition to postfix or exim.

You have to set it all up, and verify that it’s working. It’s entirely possible (and even likely) that you will set up POP3S for example, but accidentally fail to disable insecure POP3 connections!

Next up: plain text vs. encryption

Also in the early days, e-mail wasn’t encrypted. In fact, even today, many MTA’s are not configured properly with TLS/SSL, so the entire SMTP (mail protocol) exchange between sender and server is done in plain text. Keep in mind that when you want to connect from Point A to Point B on the net, it’s almost never a direct connection. That means your plain text messages are being bounced through numerous other servers before they reach the MTA – or vice versa if you’re downloading new mail.

Enter SSL, and later, TLS. This is basically encryption. You can set things up in a number of different ways, but the most effective is to encrypt the entire connection between the client (MUA) and the server (MTA). By “the entire connection”, I mean that the user authentication and the sending of mail is all done only after encryption is initiated.

Now, note that we’ve got all these fun port numbers, and each one usually is used in a standard way. But, here’s the catch: It all depends on how you set it up.

You can configure port 587 for your users to send mail, and you can make it nice and secure with TLS. You can even (and you should) configure your MTA so that no user is allowed to authenticate unless they first establish a secure TLS connection. This just makes good sense, but it isn’t necessarily the out-of-the-box default in MTAs like postfix.

What’s that mean, authenticate?

Authentication means that you have your MTA configured in such a way that it will refuse to send mail from your server unless an MUA with a valid username and password is connecting. Otherwise, if your MTA is on a server for yourdomain.com, anybody could connect and say, “Hey, I want to send an e-mail from [email protected] to the President. It should say that he smells like a goat. Thanks!”

Obviously, that’s not good – unless you don’t like the president. Well, you get the idea.

Also, remember how I said that usually, the MTA will exchange mail with other MTA’s on port 25, but port 587 is usually used for when valid users want to send out mail? Right, well, this introduces another problem. You must configure both ports properly.

If you configure port 587 to be nice and tight, with TLS, and you set it so that users can only authenticate over a TLS connection, and you make it so that only authenticated users can send mail, that’s good. But, if you don’t set some restrictions on port 25, anyone can still connect and send mail, and your mail server may still be an open relay. This is why people say that they’ve configged their mail server, and then they’re totally perplexed as to why their IP and/or domain has been blacklisted as a spammer. The reason is because evil people ARE using their insecure MTA to send spam!

In postfix, for example, the /etc/postfix/main.cf file should have certain restrictions enabled in the helo, sender, and recipient restriction reject rules, such as:

• reject_non_fqdn_helo_hostname
• reject_invalid_helo_hostname
• reject_non_fqdn_sender
• reject_unknown_sender_domain
• reject_unauth_pipelining
• reject_non_fqdn_recipient
• reject_unknown_recipient_domain
• reject_unauth_destination

I’m not going to tell you which goes where (and there are more), or where permit_mynetworks and permit_sasl_authenticated go, because I cannot emphasize enough that you really NEED to read the docs and understand everything yourself! It’s the only way. Note that each config parameter above is hyperlinked for your convenience…

The point is that just because “it works” doesn’t mean that it works securely, correctly, or even the way you want it to.

And yes, it’s painful. But it’s better to suffer a bit and learn some new tricks than to deal with spammers, blacklists, and a wide open (or even partially open) mail server!

Google it, and read. Google, read. Google, read. Repeat ad nauseum.

Spam Egg Spam Spam

You can also HUGELY reduce the amount of spam your users receive by simply configuring your mail server properly. Keep in mind that your MTA is for yourdomain.com, and anybody (including spammers) can connect to it and claim to have mail for [email protected]. If you don’t have a basic security configuration in place, your MTA will take every single spam mail it receives, and plop it in your users’ inboxes. Tools like SpamAssassin and blacklist lookups alone are NOT enough…

Been there, done that, got the t-shirt, set it on fire, and then danced around it!

You’ll probably also want to set up some other nifty tricks, like spam filtering, DKIM headers + DNS records, SPF DNS records, and an rDNS entry. The last three (DKIM, SPF, and rDNS) are tricks that we use to help ensure that when our MTA sends mail, remote MTA’s can validate that the mail really DID come from yourdomain.com, and that it isn’t spoofed.

Now, let’s say you manage to configure everything air-tight. You’re happy with yourself. You rock!

E-mail still isn’t safe

One reason is that while MTA’s prefer these days to connect to each other via encrypted connections, that’s not always the case. Like I said, many MTA’s are not configured properly. So, when your mail is being bounced around between servers on the net, it’s entirely possible (and even probable) that at some point, it will be exchanged in plain text.

IOW, just because you did your job well, doesn’t mean that other system administrators did their job well.

Unless you are actually encrypting the Subject and Body of your e-mails with something like PGP or whatever, you must assume that your mail can and will be read by somebody who’s not supposed to be reading it. Period, end of story. You know what I’m talkin’bout, Willis!

Also note that when testing your TLS setup with a command such as:

openssl s_client -connect mail.example.com:25 -starttls smtp

or when setting TLS logging to a higher level so you can see if/how remote MTAs are connecting to your server over TLS,  you may notice that some mail servers will connect to yours via TLS 1.1, some via TLS 1.2, etc. Just because your server is up to date and relatively safe, that doesn’t mean everyone else’s MTA is also.

The fact of the matter is that not only is mail server configuration a big PITA, but it’s also quite variable. For example, it’s generally not recommended to heavily restrict your TLS/SSL connections to only certain ciphers and that kind of thing, because if you do, you’ll probably prevent other old/crappy MTA’s from passing mail on to you. Everyone is NOT on the same page when it comes to e-mail and mail servers… It’s a jungle out there. That’s another reason why you need to understand what you’re doing.

Finally, passwords…

Sweet Mother of Jesus, people are dumb. No matter how good you are as an admin, if your users are choosing passwords like “password” or “pass1234”, or their love’s birthday in the form “14/02/76”, you’re screwed. So, tell your users to read my fabulous (!) and highly useful post, Making Strong Passwords – and Keeping them Safe

Oh, and don’t forget to have fun! 😉