OPS335 Lab 4b

From CDOT Wiki
Revision as of 23:17, 2 March 2016 by Andrew (talk | contribs) (Sample client setup)
Jump to: navigation, search

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:

Email-servers.png

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:

Seneca-student-thunderbird-email-setup.png