You’ve been using email forever, but do you know what all that email jargon means? Keep reading to find out more about the differences between the various ways you can receive email.
Whether you use company email, a web service like Gmail or Outlook.com, or your own email server, there’s more to receiving email than it might seem like on the surface. If you’ve set up an email client, you’ve no doubt come across the options like POP3, IMAP, and Exchange. We’re going to take a look at the difference between email clients and web mail, and at the different protocols used.
Email Clients vs Webmail
Before we explain the different protocols used to download emails, let’s take a few minutes to understand the simpler stuff—the difference between email clients and webmail. If you’ve ever started a Gmail, Outlook.com, or other online email account, you’ve used webmail. If you use an app like Microsoft Outlook, Windows Live Mail, or Mozilla Thunderbird to manage your emails, you’re using an email client.
Both webmail and email clients send and receive email, and they use similar methods for doing so. Webmail is an app that’s written to be operated over the internet through a browser—usually with no downloaded applications or additional software necessary. All of the work, so to speak, is done by remote computers (i.e. servers and machines you connect to through the Internet).
Email clients are apps you install on local devices (i.e. your personal or work PC, a tablet, or smartphone). The client apps interact with remote email servers to download and send email to whomever you might care to. Some of the back end work of sending email and all of the front end work of creating a user interface (what you look at to receive your email) is done on your device with the installed app, rather than by your browser with instructions from the remote server. However, many webmail providers also allow users to use email clients with their service—and here’s where it may start to get confusing. Let’s run through a quick example to explain the difference.
Say you sign up for a new email address with Google’s Gmail. You begin sending and receiving email through the webmail service by connecting to it in your browser. Google is providing two things for you. The first is a web front end where you can read, organize, and compose messages. The second is a mail server back end where all the message storage and routing goes on.
Now, say you decide you don’t like Google’s Gmail interface, so you decide to switch to an email client that supports Gmail—whether that’s the official Gmail interface or something like the built-in mail app on your device. Now, instead of using your web based client (Gmail’s web interface) to interact with Google’s Gmail servers, the app you’re using interacts with the mail servers directly, sidestepping webmail altogether.
All the webmail providers offer the ability to use their website to conduct your business or to connect a client to their servers and do things that way.
If you’re using an email client, whether it’s to connect to a webmail provider’s server, your own mail server’s, or your company’s servers, that client will connect using one of various email protocols like POP3, IMAP, or Exchange. So, let’s take a closer look at those.
Post Office Protocol (POP) offers a way of interacting with mail servers that dates back to a very different Internet than we use today. Computers tended to not have permanent Internet access. Instead, you connected to the Internet, did what you needed to do, and then disconnected. Those connections were also pretty low bandwidth compared to what we have access to today.
Engineers created POP as a dead simple way to download copies of emails for offline reading. The first version of POP was created in 1984, with the POP2 revision created in early 1985. POP3 is the current version of this particular style of email protocol, and still remains one of the most popular email protocols. POP4 has been proposed, and may be developed one day, although there’s not been much progress in several years.
POP3 works something like this. Your app connects to an email server, downloads all messages to your PC that have not been previously downloaded, and then deletes the original emails from the server. Alternatively, you can configure your app and server to not delete emails for a specific amount of time, or even to not delete emails from the server at all—even if they’ve been downloaded by your client.
Assuming the emails do get deleted from the server, then the only copies of those messages are in your client. You can’t log on from another device or client and see those emails.
Even if you set your server up to not delete messages after they’re downloaded, things still get pretty complicated when you’re checking email from multiple devices. Here are a few examples:
- When you send an email, the sent email is stored in the client from which you sent it. You won’t be able to see your sent messages on other devices.
- When you delete an email in a client, it’s only deleted in that client. It’s not deleted from other clients that have downloaded the message.
- Each client downloads all messages from the server. You’ll end up with multiple copies of messages on different devices, with no good way of sorting out what you’ve read and when. At least, not without doing a lot of email forwarding or porting around mailbox files.
While those limitations are substantial, POP3 is still a fast, robust protocol that is particularly useful if you only check email from one device. For example, if you only ever check mail from your PC using Windows Live Mail, then there’s no reason not to use POP3.
The Internet Messaging Access Protocol (IMAP) was created in 1986, but suits the modern day world of omnipresent, always-on Internet connectivity quite well. The idea behind IMAP was keep users from having to be tied to a single email client, giving them the ability to read their emails as if they were “in the cloud.”
Unlike POP3, IMAP stores all messages on the server. When you connect to an IMAP server, the client app lets you read those emails (and even downloads copies for reading offline), but all the real business happens on the server. When you delete a message in a client, that message is deleted on the server, so you don’t see it if you connect to the server from other devices. Send messages are also stored on the server, as is information about which messages have been read.
In the end, IMAP is a much better protocol to use if you’re connecting to your mail server from multiple devices. And in a world where people have become accustomed to checking mail from their PCs, phones, and tablets, that’s a vital distinction.
IMAP isn’t without its problems, though.
Because IMAP stores emails on a remote mail server, you typically have a limited mailbox size (though that depends on the settings provided by the email service). If you have huge numbers of emails you want to keep, you could run into problems sending and receiving mail when your box is full. Some users sidestep this problem by making local archived copies of emails using their email client, and then deleting them from the remote server.
Microsoft Exchange, MAPI, and Exchange ActiveSync
Microsoft began developing the Messaging API (MAPI) not long after IMAP and POP were first developed. And it’s actually designed for more than just email. Thoroughly comparing IMAP and POP to MAPI is pretty technical, and out of scope for this article.
But put simply, MAPI provides a way for email clients and other apps to communicate with Microsoft Exchange servers. MAPI is capable of IMAP-style syncing of emails, contacts, calendars, and other features, all of which is tied into local email clients or apps. If you’ve ever used Microsoft Outlook at work, you’ve used MAPI. In fact, all of the stuff Outlook does—emails, calendar syncing, looking up free/busy information, syncing contacts with the company, and so on—works over MAPI.
This syncing function is branded by Microsoft as “Exchange ActiveSync.” Depending on what device, phone, or client you use, this same technology might be called any of the three Microsoft protocols—Microsoft Exchange, MAPI, or Exchange ActiveSync—but offers a very similar server-based email syncing as that provided by IMAP.
Because Exchange and MAPI are Microsoft products, you’ll likely only run into this protocol if you’re using email provided by a company that uses Exchange mail servers. Many email clients, including the default Android and iPhone mail apps, are Exchange ActiveSync capable.
Other Email Protocols
Yes, there are other protocols for sending, receiving, and using email, but the vast majority of people use one of the three major protocols—POP3, IMAP, or Exchange. Since these three technologies likely cover the needs of nearly all our readers, we’re not going to go into detail about the other protocols. However, if you have any experience using email protocols not listed here, we’re interested to hear about it—feel free to discuss them in the comments.
RELATED: How to Send Large Files Over Email
In Short: Which Do I Use to Set Up My Email?
Depending on your personal style of communicating your email provider, you can pretty quickly narrow down how you should use your email.
- If you use check your email from a lot of devices, phones, or computers, use a webmail service or set up your email clients to use IMAP.
- If you use mostly webmail and want your phone or iPad to sync with your webmail, use IMAP, as well.
- If you’re using one email client on one dedicated machine (say, in your office), you might be fine with POP3, but we’d still recommend IMAP.
- If you have a huge history of email and you’re using an old mail provider without a lot of drive space, you may want to use POP3 to keep from running out of space on the remote email server.
- If you use company email, and your company uses an Exchange server, you’ll have to use Exchange.
For our geekier readers who already know this stuff, feel free to join in on the discussion! Let us know how you explain to relatives and tech-challenged coworkers the difference in common email setups. Better yet, keep this guide handy and save yourself the trouble of explaining it!