Demystifying Email: Why It’s Only As Hard As You Make It

Most of us know that one can set up a private email server. It’s, uh, been in the news. Aside from all that, if you ask most people “Okay, how do I set one up?” They’ll say something along the lines of “Don’t. It’s too complicated.” I’m here to tell you that it’s really not. It’s only as complicated as you make it. And here’s why.

Let’s say you just want to send mail. That’s it, just send mail. Well, Linux has this awesome thing called postfix. postfix, at its core, is a mail transfer agent, meaning it can send mail as well as do some other things. Basically what most people would consider a “mail server.” Setting it up to do send only is incredibly easy. Just install it and fill in the things it asks you to fill in! Then install something like mailutils or s-nail and you can now send mail.

Receiving mail is another thing. SMTP, which is a service you can enable for postfix, sits on port 25 and listens for any incoming mail that resolves to the address your mail server is sitting on. If configured right, which is editing all of two files for postfix, you can then log into your server and read your mail with the mail command. Besides setting up SMTP, you also have to set up an MX record, which is like your standard A or AAAA record (put in a domain, get an IP), except just for mail. Because mail servers can have a domain like mail.whatever.com, but go to bob@whatever.com, you have to configure the MX record to say “Any mail addressed to whatever.com should go to mail.whatever.com.” Your mail server doesn’t need to have a domain of mail.whatever.com, it can just be whatever.com if you’re lazy. You should also configure postfix to be the “final stop” for any mail addressed for your domain, else the person sending you mail will get a message back saying they couldn’t send mail to you. PS: You should also have an SSL cert for your mail.whatever.com domain which is just as easy as using Let’s Encrypt and certbot with the --certonly flag.

Okay, cool, we can now send and receive mail through our server. But what if we don’t want to be logged in to our server? What if we want to use a client? Well, we need to do two things. Er, a thing and a half if you want. This is where some divergence starts happening. There are two ways to configure postfix to accept some mail from a client. You can make SMTP do the job, or use submission, which is basically SMTP but on a different port besides 25. I suggest this, as it’s pretty dang easy to do, just add a couple lines to your postfix config. But now you have to make it so you can read mail. Here’s where things get tricky. There are two, technically three ways you can do this. I’m going to talk about two now, and one later. The first two ways are POP3 and IMAP. POP3 copies mail from the server, then deletes it from the server. You can remember it as “popping” the mail off the server. It’s nice if you only read mail from one place, but most people don’t do that nowadays, they read from their computer and their phone and their tablet and so on. Which is why you’d probably want to use IMAP. IMAP lets you read your mail from the server and keep it on the server (Side note: POP3 can do that in some clients, but because it’s not at the root of the protocol I’ll leave that alone.). But postfix can’t do IMAP. So what do you do? Install another thing! Personally, I use dovecot, Which is… not as easy to configure, but if you find a good guide online it’s pretty easy, there’s some stuff you can avoid. Then tell postfix that dovecot is allowed to read mail. And log in with the same account you use for reading and writing mail on your server.

Which is… what exactly? When we set up postfix, by default it uses system accounts, so the actual Linux accounts one would use to log into the server. That’s no good, if someone has your email password they can get into your mail server and do some naughty things. Well, you can set up virtual mailboxes to use with MySQL. But what about spam? You can set up spam filters like spamassassin and they… work, for the most part. Some clients have a problem with them but other than that they work.

Oh, also, you need to make sure that everyone knows your server mail.whatever.com is the only server that’s allowed to send mail from whatever.com. You need an SPF record for that. And you might want a DMARC record to basically do the same thing. Oh, and don’t forget PTR! And hey, remember how I said there were three ways to read your mail? Well, the third is webmail. What about that? How do you set that up?

As you can see, setting up a mail server can be complicated. But, you don’t have to do every one of these steps. It all depends on what you want. If you just want an address that people can send mail to because you don’t want to give out your private email address, it’s pretty easy. But you can get very easily carried away.

Or, you can do it all automagically. Say hello to Mailcow. Mailcow is basically some stuff and a script that automatically sets up a mail server with all the stuff I’ve mentioned previously, which includes a MySQL based mailbox, web mail, spam filter, a web UI for editing configs, and more. And all you need to do besides the DNS configuration is edit literally a couple lines in a config file. I don’t use Mailcow personally, but I wish I found it before setting up my own mail server. One thing to note about it is you should really use it on something you’re dedicating to being a mail server; You’re not going to use the box for anything besides a mail server. Not only does Mailcow do its own thing with configs, but it also takes up an absurd amount of memory. Yes, it’s technically a bundle of a whole bunch of things, but how those things reach 800mb of suggested RAM is beyond me.

One final note: Email is terrible. There’s a reason a lot of people say not to set up your own mail server. Email is terribly complicated for no good reason. People have been wanting to fix email since the 80s. While we haven’t come up with a drop-in, backwards compatible protocol, we have come up with some great alternatives, such as instant messaging and to some extent texting. But just because mail servers have a lot of working parts doesn’t mean they’re impossible. A lot of the parts are optional, it’s all up to what your definition of “working” is.

One thought on “Demystifying Email: Why It’s Only As Hard As You Make It”

  1. Mailcow’s large footprint is largely caused by it’s use of many bits of what are effectively fluff to make everything work better. It runs lots of different extra stuff, including but not limited to PHP and the fancy (and resource hogging) SoGo Groupware solution if you choose to go down that path. It’s worth noting that Mailcow will use all the RAM it can get, literally. My new mail server is running on Mailcow and I very seldom see much if any RAM freeing up, but it’s also worth noting that Linux does an incredibly good job of managing the resources it has. Mailcow uses a lot of RAM, yes, but that doesn’t mean that it performs poorly when you don’t have a ton. In other words, it will run just fine with a gig of RAM, and be perfectly performant for a small server with two or three active users, but if you give it two or three gigs, it will also certainly use it all. I must agree with you that it’s wise to use a dedicated machine. Weather that’s an additional VPS from your provider of choice, or simply it’s own container on your hypervisor, for security and performance reasons it just makes the most sense to have your mail server separate from everything else.

    (P.S. I didn’t know you set up a weblog here. It’s actually pretty interesting. :P)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.