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:

• Here's an overview (common mail server terms)
• Seneca Client Settings (Seneca Server settings for mail client - Thunderbird)

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

In reality, the terms MTA, MDA, MUA, LDA can actually be considered misleading since some of those services can be combined together to form a single entity (application), while other applications may operate as separate entities. There may be overlap, so if you don't find those acronyms helpful, don't worry too much about them. On the other hand, when referred to in diagrams, they can help to visualize those processes when try to understand how an e-mail system works.

Here's an overview of those terms (from the Dovecot wiki). It is worth viewing this link.

In the diagram displayed above, the elements include:

• 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 (which 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 mail message then travels the rest of the way to the destination MTA unencrypted, so anyone with access to the routers in-between can read all your emails. That 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.
  • Thus, a situation can occur that although you sent your email successfully, it may never make 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 is needed to retrieve the address of the email server responsible for an email for a particular domain. This is done with the MX records we looked at in the DNS labs.

Install Thunderbird Application and Setup a Reference Client

Eventually we're going to set up all those mail services, but to begin with, we will 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.

Switch to your host machine, and install the Thunderbird email application.

When you see the configuration dialog box, configure it in a similar way (using your own information) as shown in the diagram below:

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 obtain your password without any password/encryption cracking tools. In fact, even on a private wired network, it is not uncommon for an employer to use a packet sniffer utility to monitor all the traffic going over their network (Packet Sniffing applications were actually found to be legally acceptable practices if used by the management of organizations).

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

After you create your Thunderbird account, you should be able to read your existing email and send new email within the Thunderbird application.

Take time to view your 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?

The main objective of this section was to learn how to setup your Thunderbird application to read your Seneca email, so in the next section you can use the exact type of setup for your own email server.

INVESTIGATION 1: SETUP MTA FOR SENDING (NO ENCRYPTION)

We be using the Postfix application as the MTA, and we will be setting it up on your vm2 machine. This will act as the email server for your internal network. You will be able to send email out of your network, and receive email from within your network, but you will not receive email from outside of your network due to the following reasons:

1. Individuals outside of your domain will never find the MX records because there are no .org servers pointing to your DNS server (i.e. you haven't paid for it).
2. Even if they the individuals could read your MX records, your local network is using IP addresses on a private subnet, which is not routeable on the Internet, so it cannot be reached from outside of your system.

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 FOR YOUR VIRTUAL NETWORK (vm2, vm3)

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.