There are a huge number of different
email clients that can connect to Exchange Server. This is due to
Exchange providing support for standards-based email protocols, such as
Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP), in addition to Microsoft's proprietary Messaging Application Programming Interface (MAPI).
There are also several open source implementations of MAPI, such as
OpenMapi, MAPI4Linux, and libmapi, which allow open source email
clients to connect to Exchange Servers directly via MAPI.
Because of the number of client types, most design teams group them together based on their protocols.
Messaging Application Programming Interface (MAPI/RPC)
MAPI has been around in one
form or another since 1991. Initially, it was used as the protocol for
the MS PC Mail product. It was later developed into extended MAPI and
used within Exchange Server.
OUTLOOK DOES NOT ONLY USE MAPI
From a client perspective, Outlook is the most
common MAPI client used with Exchange Server. Nevertheless, just
because Outlook is in use does not guarantee that it is connecting via
MAPI, especially in open environments such as universities. Remember
that Outlook supports other protocols that can be used to connect to
Exchange Server, including IMAP and POP3, and with Outlook 2013, even
Exchange Active Sync is supported, which allows it to connect to Outlook.com.
Although Outlook does not necessarily imply a MAPI connection, a MAPI
connection usually implies Outlook since it is the only MAPI client
that is supported by Microsoft for connecting to Exchange Server.
It is worth defining MAPI at this point
and how it has changed in Exchange Server 2013. At its core, the
Messaging Application Programming Interface is a Remote Procedure Call
(RPC) protocol that provides a very rich interface to your Exchange
mailbox. One of the main differences between MAPI and Internet
standards-based protocols, such as POP3 and IMAP, is that MAPI requires
high-speed network connectivity and multiple TCP ports in order to
connect. This is in contrast to POP3 and IMAP, which were designed to
operate over unreliable Internet connections and through firewalls.
MAPI is still used in Exchange 2013. However, it has been encapsulated within an HTTPS tunnel. HTTPS
is a secure version of the World Wide Web protocol (HTTP), which is
encrypted with a certificate. Encapsulating MAPI within HTTPS was done
to simplify the authentication and connectivity model within Exchange
2013. It is important to remember that MAPI is still alive and well,
and that it is merely hidden within an HTTPS connection.
This type of MAPI connection is known as Outlook Anywhere
in Exchange terminology. Outlook Anywhere was available in previous
versions of Exchange, where it was mainly used to allow Outlook clients
to connect over the Internet to Exchange Servers via MAPI encapsulated
within an HTTPS tunnel.
Exchange Web Services
Exchange Web Services (EWS) has been the
recommended application programming interface (API) for Exchange Server
since Exchange Server 2007. EWS is a web-based protocol that
communicates over HTTPS with Exchange Server. The most common
user-based EWS clients are on Apple OS X. Apple OS X 10.6+ includes a
native mail client, called Mail, which supports EWS
connections, and Microsoft Office 2011 for Mac includes Outlook 2011,
which also uses EWS to connect to Exchange. Prior to Outlook 2011 for
Mac, Microsoft provided Entourage 2008 Web Services Edition, which also
supported EWS.
From a client
perspective, EWS provides a very similar set of features to MAPI. It is
not as efficient as MAPI over the network, however, and so it can often
appear to take longer to send or receive email on an EWS client than
for Outlook connected via MAPI.
EWS is not restricted to end-user client
use, though, and it is also frequently used by applications that
require mailbox access. The move to EWS for application integration
with Exchange has increased dramatically since Microsoft made Office
365, which runs Exchange in the cloud, available. This is because the
recommended API into this service for applications is EWS. Some
applications also use POP3 and IMAP4 for application integration. This
has prompted developers to rewrite many applications that had
previously used the Common Data Objects (CDO) API to use EWS instead.
POP/IMAP
The Post Office Protocol was first defined in
1984, and it became ubiquitous as the standard email protocol in the
early days of the Internet. Virtually every email client supported POP,
largely since it was extremely simple, lightweight, and very reliable.
The current implementation of POP is known as POP3, which was defined
via RFC 1081 in 1988. POP3 is still in use today, and Exchange 2013
supports it.
The Internet Message Access Protocol was
first defined in 1986 as the Interim Mail Access Protocol, before
eventually being renamed to Internet Message Access Protocol Version 4
in 1990. IMAP4 was an attempt to improve on POP3 and provide a richer
client experience, including the following features:
- Ability to leave messages on the server
- Multicomputer access
- Power to synchronize multiple folders (including sent items)
- Ability to work offline
- Improved error handling
Since POP3 and IMAP4 are totally unrelated
protocols, why do we often group the clients together? The answer here
relates more to client commonality than to the individual protocol
used. For instance, most clients that support POP3 also support IMAP4.
These clients are typically not Active Directory domain-joined and also
typically connect over the Internet.
Another use of both POP3 and IMAP4 is for
application integration with Exchange Server. POP3 and IMAP4 are
extremely simple protocols to use, and so many developers use them when
they need to read or write data to an Exchange mailbox.
By far the biggest problem with both POP3
and IMAP4 is the tendency for clients and application developers to
send credentials in clear text over an unencrypted connection. Both of
these protocols can be secured via the use of encryption certificates.
The credentials will still be sent in clear text over an encrypted
tunnel, but they are protected by the tunnel encryption. Be mindful,
though, that not all clients support the secure version of each
protocol, and many applications that were developed to use POP3 or
IMAP4 are old and may require an upgrade to function securely. In
Office 365, only encrypted POP3 and IMAP4 are supported.
ENABLING POP3 AND IMAP4 IN EXCHANGE SERVER 2013
By default, both POP3 and IMAP4 are disabled in
Exchange Server 2013. To enable POP3 and IMAP4, you must start the
appropriate services on your Exchange 2013 servers. One change from
previous versions of Exchange Server is that there are now two services
for each protocol.
To enable POP3, run the following PowerShell cmdlets as an administrator:
Set-service msExchangePOP3 -startuptype automatic
Set-service msExchangePOP3BE -startuptype automatic
Start-service msExchangePOP3
Start-service msExchangePOP3BE
To enable IMAP4, run the following PowerShell cmdlets as an administrator:
Set-service msExchangeIMAP4 -startuptype automatic
Set-service msExchangeIMAP4BE -startuptype automatic
Start-service msExchangeIMAP4
Start-service msExchangeIMAP4BE
Note that the Backend service (POP3BE/IMAP4BE)
will exist on Mailbox roles and the normal protocol service will exist
on Client Access Servers. If you have installed both Mailbox and Client
Access on the same server, both services will be present.
