Many of the articles we post here assume that you are familiar with the email lingo and components. But what if you're not? Where should you start?
We've put together this crash course for you. In this article I will try to focus on the user facing aspect, and not dive too deep into technical details. I will try to simplify things as much as possible. I've broken this article into two sections: 'Sending Email' and 'Retrieving Email.' Let's start with the latter.

Retrieving Email


I've carefully selected the word 'retrieving' rather than 'receiving.' What I will be talking about in this section has nothing to do with receiving email. Instead, this is about how to retrieve, or fetch, email from your email service provider. The three most common ways to retrieve email are POP3, IMAP and MAPI. Let's call them The Good, the Bad and the Ugly.
Please note that none of these components are used for sending email1.

The Good - IMAP


IMAP is starting to become the standard for retrieving email. It is an open standard, which allows anyone to write both email servers and email clients. Perhaps the best feature in IMAP is that it stores all the emails on the remote server. This enables you to use multiple clients (i.e. webmail, smartphone, computer, etc) and be in sync. If you mark a message as read on your computer, it will also be marked as read on your smartphone.
The flip-side of this is that you are limited to the storage quota set by your email provider. Serious providers offer quite a bit of storage, such as Gmail with ~7GB of free storage, so this is usually not a big problem.
One of the biggest myths when it comes to IMAP is that it is difficult to use. I really don't get it. It's not harder to set up than anything else. The only thing to keep in mind is that if you delete a message on your smartphone, you delete it on the server and it will be gone from your computer at home too.

The Bad - POP3


In the days when internet service providers (ISP) also were people's primary email provider, POP3 was the standard. The reason is simple -- it's cheap. What many people do not understand when it comes to POP3 is that the messages are only temporarily stored on the server2. Once your email client retrieves the emails, they are wiped from the server. Moreover, if you have multiple devices connected to the same account using POP3, you are asking for trouble. You might accidentally download an important message onto your smartphone. It's gone from the server. How are you going to transfer that message back to your computer? I suppose you could forward it, but it's hardly convenient.
Another common misconception when it comes to POP3 is about folders. While there are 'folders' in POP3, they do not work as you would imagine them to. Folders in POP3 are strictly server-side. For the reason outlined above, you cannot 'create' a folder and move messages to it as you can in IMAP. No, a folder in POP3 is just another source to retrieve messages from. While it is not very common, your email service provider could have multiple folders to which different messages are delivered (e.g. based on server-side filters).
I opened the section with saying that POP3 is cheaper for the providers. Since the messages are not permanently stored on the server as they are with IMAP, the email service provider won't have to invest in expensive storage arrays. The end user bears the full cost of long term email storage.
It is also worth mentioning that POP3 is an open standard, just like IMAP.

The Ugly - MAPI


MAPI is Microsoft's proprietary email storage system. If proprietary email system didn't already turn you off, let me elaborate. Unlike POP3 and IMAP, MAPI is not an open standard. Hence, are limited to use Microsoft's email clients (Outlook) and server (Exchange).
To be fair, MAPI is a much more complete solution. It is similar to IMAP in many ways, as it stores the messages on the server. However, unlike IMAP it also supports storage of contacts and calendar information.
The problem with MAPI is that it is completely closed. For instance, you cannot use the email client of your choice (assuming it is not Outlook). If you want to move your messages from an email provider that only supports MAPI, you would need to use Outlook to transfer the messages3.

Sending Email


In this 101 class, there are only two components in "Sending Email." If you don't have your own domain, you can also ignore the "MX-record"-section.

SMTP


SMTP is the key component when it comes to sending email. No matter if you use POP3, IMAP or MAPI to retrieve your email, SMTP is what you will be using for sending email4. It's the open protocol that all email on the internet are sent trough. From an end-user point-of-view, SMTP is pretty simple. You configure your email client to use this server to send emails.
The most common problem people have with SMTP is probably related to ISPs blocking external SMTP servers. In order to prevent users on their network from using their local computers to send spam, some ISPs decided to block all connections to/from SMTP server with the exception of their own SMTP server. It was probably a very efficient measure, but the down-side is that if you are not using the ISPs own email service to send email, you are unable to send email. While I've simplified this issue vastly and left many details out, there is a work-around to this issue that often works: use a an encrypted connection to the SMTP server (port 465 or 587).

MX-record


It is a bit difficult to explain MX-records in layman terms, but I'll do my best.
An MX-record is a DNS-entry that tells the sending SMTP server where to deliver the message. It's probably easiest to explain this with an example. User A ([email protected]) is sending an email to User B ([email protected]).

  • User A composes and sends a message to User B ([email protected])

  • DomainA.com's SMTP server reaches out and asks the DNS server for DomainB.com for the MX-record for DomainB.com

  • The DNS for DomainB.com answers with something like smtp.DomainB.com (it could be anything really)

  • DomainA.com's SMTP server initiates a connection to smtp.DomainB.com and delivers the message to [email protected]


While there is a whole lot more that can be added to the mix (such as SPF etc), this is a very simplified example on how MX-records and SMTP interoperate.

Want to learn more about email and email systems? Learn more in The Email School.

1 It is possible with certain email servers and configurations to send email using IMAP, but it is very rare and few email clients even support it.
2 It is possible to use the option "leave messages on server," but it is highly discouraged as you'll end up with a huge mess.
3 Many service providers who support MAPI also support IMAP.
4 If you use MAPI/Exchange/Outlook, you might not see SMTP in your settings, but it is what the server is sending messages with.