How IMAP and POP work in an Exchange (2007/2010/2013) Coexistence environment

Understanding how IMAP and POP works in an Exchange 2007, 2010, 2013 coexistence environment is helpful for exchange troubleshooting.

We need to know how Exchange 2013 forwards the Imp, pop request to an older version of Exchange, and that the exchange's CAS is still receiving IMAP, POP requests through a proxy (proxy) to the destination server. Typically, Exchange ClientAccess server receives a client's IMAP, POPs requests with two actions: 1), authenticates the request (acceptance of the user name and password). 2), perform IMAP, POP service discovery. (Find IMAP, POP service location).

There are two scenarios in which Exchange clientaccess server performs IMAP, POP service discovery:

1. When the requested mailbox is located on an Exchange 2010 database, Exchange ClientAccess Server enumerates the POP, IMAP attribute value Internalconnectionsettings in this site, This value is in the FQDN of the Exchange Client Access server. (So note that the Internalconnectionsettings attribute value of POP and IMAP is best not to be modified to a load-balanced FQDN)

650) this.width=650; "title=" image "style=" border-top:0px; border-right:0px; Background-image:none; border-bottom:0px; padding-top:0px; padding-left:0px; border-left:0px; padding-right:0px "border=" 0 "alt=" image "src=" http://s3.51cto.com/wyfs02/M01/7F/A6/ Wkiol1codjkzwftnaaerdgbia4m092.png "" 831 "height=" 315 "/>

2. When the requested mailbox is on an Exchange 2007 database, Exchange ClientAccess Server enumerates the FQDN of each Exchange-Client Access server in this site.

Learn how Exchange 2013 discovers how pop and IMAP services work, and next we need to understand how the Exchange-CAS proxy will look when it finds the target server.

There are usually two cases:

1), when the client sends an IMAP, the pop inbound request is encrypted (for example: Pop 995, IMAP 993), Exchange CAS receives the request first with the SSL proxy proxy to the target server, if the failure will take the TLS Proxy proxies to the target server and finally to the target server using plaintext (non-encrypted) mode.

2), when the client sends an IMAP, the POP inbound request is clear (non-encrypted) mode, the Exchange to receive the request when the CAS first use clear text proxy to the target server, if the failure will use SSL proxy, and finally use TLS proxy.

The coexistence environment described above is how Exchange CAS will proxy IMAP, POP requests to older versions. For IMAP, POP services We also need to note:

1. On Exchange CAs, before the agent IMAP, POP request, Exchange 2013 does not check the target service's IMAP, the POP service is available, so in the wrong way, we need to first confirm that the target server IMAP, POP service is started. (Other types of proxies (EWS, OAB, OWA, Microsoft-server-activesync, ECP), Exchange 2013 periodically sends service status monitoring to older versions of Exchange, For example: httpproxy.clientaccessserver2010ping, except IMAP, POP does not have this kind of state monitoring)

How IMAP and POP work in an Exchange (2007/2010/2013) Coexistence environment