OPS335 Lab 4b

Email Servers

You may not be aware of it as an user, but email is a very complex system to administer. In fact, the more modern e-mail systems (eg. web-based mail applications, etc) are more technically involved than the other archaic, hard-to-configure, and sometimes inter-operable mail systems.

We are going to spread the remaining email labs over a few weeks, so that by the end of this topic, you will have a sufficient understanding of what services are involved in sending, filtering, and reading email. You will also have the skills to configure a basic mail setup using the default services provided for your Centos7 Linux distribution.

LAB RESOURCES

Online References:

OVERVIEW & PREPARATION

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

In fact, the above diagram does not include reading mail messages, but this acts as a starting point in order to run a basic email server. Although will be learning to administer the mail services in the diagram above, we will not required you to go into tremendous depth (just the minimum requirements). For example, we will not go over every aspect of the Postfix MTA service, but you should know what it represents and what is its main purpose, as opposed to the following: complex diagram 1 , complex diagram 2.

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.

Reference 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.

INVESTIGATION 1: SETUP MTA FOR SENDING (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.

Verify Postfix Service Status

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.

Listening on all interfaces

The first change to the Postfix configuration will be to make it listen for incoming connections on the extrnal intercace, that's eth0 from the VMs point of view.

The configuration file is /etc/postfix/main.cf Edit it and change inet_interfaces to all.

At this point we should also set the string that will end up in the From: header in messages sent by this server. Change mydomain to your domain name and and myorigin to $mydomain.

Restart postfix, confirm (with netstat) that it's now listening on all interfaces, not just loopback, and test connecting to it from the host.

DNS Server used by the host

So far you're probably not using vm1 as the DNS server for your host. We'll need to change that for email to work correctly. Normally you don't need an entire DNS server for running an email server, you just add an MX record in your registrar's web interface, but we haven't paid for our domains so we don't have a registrar with a web interface.

Modify your /etc/resolv.conf to use vm1 as the name server. This will not be a permanent change but that's ok, we only need it for the email labs. You'll have to remember to do this every time you reboot your host.

If you regular (internet) DNS lookups slow down significantly - try to update the DNS server configuration on vm1 to forward requests to the Google nameserver (8.8.8.8) instead of your host.

INVESTIGATION 2: SETUP THUNDERBIRD MUA

We are far from having a working email server but at this point we have enough to be able to test it with Thunderbird.

The process is a little challenging because Thunderbird tries really hard to prevent you from connecting to a server that doesn't work (and ours mostly doesn't work at this point). Set it up to connect to your vm2 for SMTP and vm3 for IMAP. Use no encryption, and normal password authentication for IMAP (we don't have an IMAP server running yet, but that's ok).

Thunderbird won't let you proceed with the "Done" button because you will fail to connect to IMAP. Use the "Advanced config" button to bypass that check.

Now use Thunderbird to send an email to your myseneca address. If you've done everything right - it will send the message successfully but it will fail to save it in the Sent folder, because that's done with IMAP and you don't have an IMAP server yet.

Still - verify that your message has been sent. Check your myseneca email and look at /var/log/maillog on vm2 (your email server).

COMPLETING THE LAB

Students should be prepared with all required commands (system information) displayed in a terminal (or multiple terminals) prior to calling the instructor for signoff.

Arrange evidence (command output) for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:

✓Status and configuration of your Postfix service on vm2.

✓Proof that you can connect to that service from the host.

✓Your Thunderbird configuration.

✓The email you sent to your myseneca account.