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.

Perform the following steps:

1. Switch to your host machine, and install the Thunderbird email application.
2. 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.

3. After you create your Thunderbird account, you should be able to read your existing email and send new email within the Thunderbird application.
4. 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 MAIL TRANSFER AGENT (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:

• 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).
• 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 the Postfix Service Status

Perform the following steps:

1. The postfix application should be installed by default. If it isn't, install it.
2. Install also the netstat application (tip: use yum search to find the package name) and also install the telnet command.
3. Postfix will work with the default configuration, so start and enable this service, and verify that the postfix service is running.
4. Look for the running postfix service in the list of listening ports by issuing the following command:
   

   netstat -atnp

5. Which service is postfix running? Locate the port used by SMTP, and look for connctions with the state LISTEN (i.e. currently listening).
6. Write your observations in your lab logbook.

Testing the connection to the Postfix Service

We will be demonstrating the use of the telnet application to test that the postfix service is running.

Perform the following steps:

1. Connect from your server to your server using telnet by issuing the following command:
   

   telnet localhost 25

2. Note that it should indicated that you are connected by displaying the the text:Escape character is '^], which indicates that in order to end the telnet session, you can hold control and press the square bracket key. Perform that key-combination to end the telnet session.
3. Enter the command exit to close the telnet application.

NOTE: If it worked, this indicates that the postfix service is running and listening and responding to connections.

4. 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, the telnet command should not permit a connection.
5. Issue an iptables rule to allow incoming connections to TCP port 25.
6. Once you open the port in the firewall, retry 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

Our first editing change to the Postfix configuration will be to make the service "listen" for incoming connections on the external interface (i.e eth0 from the VMs point of view).

Perform the following steps:

1. Launch in editing session for the postfix configuration file called: /etc/postfix/main.cf
2. Change the value of the following parameter to what is displayed below:

inet_interfaces = all

3. 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 myorigin to $mydomain.
4. Restart the postfix service and confirm (using netstat) that the service is now listening on all interfaces (not just loopback)
5. Test by connecting to it (using telnet) from your host machine.

DNS Server used by the host

So far, you are not using vm1 as the DNS server for your host machine. We will need to change the DNS configuration in order for the email server to operate correctly. Normally you don't need an entire DNS server for running an email server, you can simply add an MX record in your registrar's web interface, but we haven't paid for our domains; therefore, we don't have a registrar with a web interface.

Perform the following steps:

1. Modify your /etc/resolv.conf on your host machine to use your vm1 machine as the name server. This will not be a permanent change, since it will only be required for our email labs.
2. We will have to remember to do this every time you reboot your host.

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

Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book

INVESTIGATION 2: SETUP THUNDERBIRD MAIL USER AGENT (MUA) FOR YOUR VIRTUAL NETWORK (vm2, vm3)

Although We are far from having a working email server, at this point we still have configured enough to be able to test the running mail service (postfix) with the Thunderbird application. This process is a little challenging, since 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).

Perform the following steps:

1. On your host machine, return to the Mail Account Setup dialog box (eg. near top of lab).
2. Set up the account settings to connect to your vm2 for SMTP and vm3 for IMAP. Use no encryption, and use normal password authentication for IMAP (we don't have an IMAP server running yet, but that's ok). Refer to the diagram below for reference:

NOTE: Thunderbird won't let you proceed with the "Done" button because you will fail to connect to IMAP.

3. Use the "Advanced config" button to bypass that check.
4. Use the Thunderbird application 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 since that's done with IMAP and you don't have an IMAP server yet.
5. Verify that your message has been sent. Check your myseneca email and look at /var/log/maillog on vm2 (your email server).

Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book

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.