OPS335 Lab 4b

Email Servers

You may not be aware of it as a user but email is a very complex system to administer, in fact it's a very complex system of other archaic, hard-to-configure, sometimes-interoperable complex systems.

We're going to spend three weeks working on it so that by the end of the course you will have a general understanding of what services are involved in sending, filtering, and reading email. You will also have the skills to configure a basic setup using the default services on CentOS 7.

Overview

This is a simple (yeah, really) diagram of how you can send an email to someone else:

The diagram above doesn't even include reading email, but it's as simple as it gets (if you want to run an email server). You will need to learn to administer basics of all the systems in the diagram. We won't go in too much depth, only the minimum you need. But we will not (for example) go over every detail of Postfix, which on its own has a rather complex diagram.

Services involved in email delivery

The terms MTA, MDA, MUA, LDA are not 100% well defined, because few of the related services are simple and do exactly one thing. There is overlap, so if you don't find the acronyms helpful - don't worry about them. But they can help organize your thoughts when trying to keep all this in your head.

Here's an overview of from the Dovecot wiki, it's worth reading.

In our diagram we have:

• A user. That's the person who wants to send an email.
• An MUA (email client). This is the application the user uses to send an email. It can be a native application or a web application. We'll set up both types.
• Two MTAs. These are the servers responsible for getting your emails to the destination server.
  • They are similar to routers (whcih route packets) but work on the application layer rather than the network layer.
  • In our example there are only two MTAs - but there can be several.
  • You connect to your MTA over a secure connection, so your emails can't be read by the operators of the network you're connected to.
  • The rest of the way to the destination MTA the emails travel completely unencrypted, so anyone with access to the routers in between can read all your emails. This is why many organizations will refuse to send you confidential information over email.
• The LDA/MDA will receive the email from the MTA, and will store it on disk in some format. MailDir and MBOX are the most popular mailbox formats.
• When sending an email you send it to the destination using your MTA, but you also want to save it in your "Sent" folder for yourself. This is accomplished by a separate connection to your IMAP or POP3 server.
  • This is why it can happen that you sent your email successfully but it never makes it to your "Sent" folder - the second connection to your IMAP server is quite unrelated to the first connection to the SMTP server.
• Note that a DNS server is also involved - it's needed to retrieve the address of the email server responsible for email for a particular domain. This is done with the MX records we looked at in the DNS labs.

Sample client setup

Eventually we're going to set up all those services, but to begin with we'll set up an email client to connect to a (hopefully) working server - the Seneca email server. This will be a good exercise with an email client.

Install Thunderbird on your host, and configure it like this, obviously using your own information:

Notice that there are unencrypted options available to connect to your SMTP/IMAP servers but those are rarely used these days. The potential for abuse is too great. On a free wifi network the operator would be able to not only read your email - but also get your password, without any password/encryption cracking tools. And even on a private network - it is not uncommon for an employer to sniff all the traffic going over their network (that was found in court to be a legally acceptable practice).

The specific security settings depend on how your servers were configured. The settings for the seneca servers are published here.

After you create your account - you should be able to read your existing email and send new email in Thunderbird.

Look through the Account Settings and Preferences to get a feel for what settings exist. For example:

• How often will Thunderbird check for new messages?
• Will the messages you write be in HTML or plain text?
• How do you change your SMTP server settings? Why are they in a different section?

If everything is working - that's good, now you know what you'll try to build in the email labs. The goal is to have the exact same setup using your servers instead of Seneca servers.

MTA for Sending with no encryption

We'll use Postfix as the MTA, and we'll set it up on vm2. This will be the email server for your internal network. You'll be able to send email out of your network, and receive email from within your network, but not receive from outside your network because:

1. Outsiders will never find the MX recors for your domain, because there are no .org servers pointing to your DNS server (you haven't paid for it).
2. Even if they did - your local network is using IP addresses on a private subnet, which is not routeable on the internet, so it cannot be reached from the outside.

Postfix should be installed by default. If it isn't - go ahead and install it. Install also the netstat application (use yum search to find the package name) and the telnet command.

Postfix will work with the default configuration, so enable it, start it, and check that it's running. Also look for it in the list of listening ports:

netstat -atnp

Which one is it? Find the port used by SMTP, and look for connctions with the state LISTEN (i.e. currently listening).

Testing the connection to Postfix

Connect from your server to your server using telnet:

telnet localhost 25

Note that it will tell you once your connect that Escape character is '^], which means your can hold control and press the square bracket key to end the session (and then exit the telnet app).

If this worked - that means the service is running and listening and responding to connections. Let's see if it works from other machines. Telnet to vm2 from the host (connect to the SMTP port) and see if it works. If your firewall is set up properly - it shouldn't, you'll need to allow incomming connections to TCP port 25.

Once you open the port in the firewall - try the telnet command. You should get a different error this time. This time the problem is that your service isn't listening on the outside interface, it's currently configured to listen only on the loopback (lo) interface.