Some of our customers have decided to use MACs to access either Microsoft Exchange 2003 or Microsoft Exchange 2007.

This is a brief outline of the steps necessary to configure the MAC Mail client application, also known as Mail.App, to access Microsoft Exchange.

What you will need:

1. The FQDN (Fully Qualified Domain Name) or IP Address of the Microsoft Exchange server. In Exchange 2007, this must be information for an Exchange Server that has the Client Access role configured on it.

   eg. mail.contoso.com or 10.10.10.40

2. Assurance from your IT team that IMAP is configured to support access to Microsoft Exchange. Check out other blog entries on this site regarding IMAP and iPhone configuration for more detail on how an IT department would go about configuring IMAP access.
3. The port number that is used to access your Exchange Server via IMAP. Typically this defaults to port 993 (secured communication) or port 143 (insecure communication!).

Steps to Configure the Mail.App application

1. Start the Application, and Click Mail/Preferences (select the Mail pulldown, and then select Preferences).
2. Click on the @ (at) icon that reads Accounts
3. On the bottom right hand corner of the Accounts page you'll see a plus (+) and a minus (-) symbol. Click on the plus (+) symbol to add an account.
4. NOTE: You are allowed to have only ONE Exchange account configured. Select Account Type and then select Exchange.
5. Fill the information in like shown in the below two screenshots:
   

Currently we have customers asking how to setup IMAP in an Exchange 2003 clustered environment for iPhone use. Exchange 2003 by default disables IMAP4 which is what the iPhone supports. I want to stress that IMAP4 should never be enabled without using SSL! Sending information in clear text is not recommended. I will be referencing the IMAP4 port 993 later in this article. I will step through the different actions taken for Exchange 2003 clusters.
Enabling IMAP:
On the Exchange 2003 Cluster nodes you will need to go to each and enable the “Microsoft Exchange IMAP4” service. Typically if you are using a clusterd back-end you have a front-end server that will need to have IMAP enabled also.

The iPhone has arrived and the corporate world is now starting to configure their existing messaging infrastructure allowing employees to sync up their iPhone’s.
I want to stress that IMAP4 should not be enabled without using SSL! Sending information in clear text is not recommended. I will be referencing the IMAP4 port 993 later in this article. I will step through the different actions taken for a non-clustered Exchange 2003 system.
Enabling IMAP:
By default, IMAP4 is disabled on Exchange 2003. If your organization has one or many Exchange 2003 servers(front-end and back-end) you will need to go to each one and enable the “Microsoft Exchange IMAP4” service.

The release of a little known device called the “iPhone” caused quite a bit of talk about how it fits into an enterprise-class messaging environment. There is little argument over the popularity of the iPhone and its inevitable arrival into the corporate network whether well received by IT administrators or not. To support a device that does not support Exchange ActiveSync such as the iPhone, administrators may have to turn on IMAP functionality.

Exchange 2007 brings about a lot of changes for IMAP4 from prior versions of Exchange. IMAP is no longer provided to exchange by IIS but is now fully incorporated into Exchange on the Client Access Server role. Unlike in Exchange 2003, IMAP cannot be administered via a GUI like Exchange System Manager. All configuration is done from the Exchange management command shell. In this first article, I will step through a straightforward configuration of IMAP for an Exchange 2007 system. In the second, upcoming part I will walk through the steps needed to enable IMAP for the entire organization.

Accessing Messages from an IMAP-enabled Device

The first thing we need to do is enable the IMAP service on our Client Access Server role. The following commands will enable and set the service to startup automatically:

• Start-service -identity MSExchangeIMAP4
• Set-service –identity MSExchangeIMAP4 –startuptype Automatic

Exchange 2007 was designed with security as a priority and thus all features are set secure by default. IMAP4 is no different.

By default, IMAP requires TLS and uses port 993. We can change this if we choose to do so however, most devices and applications support secure IMAP. By changing the loginType attribute from SecureLogin to either PlainTextLogin or PlainTextAuthentication, we open up the standard port TCP 143. NOTE: Again, for security reasons, avoid this configuration unless you absolutely MUST open up port 143.

Because we are using SSL/TLS to encrypt the communication between the device and Microsoft Exchange we need to make sure are certificates in are in good order. If you choose to use a FQDN (eg. imap.company.com) that differs from the Certificate, or if you use a self signed certificate, the user will be prompted that the certificate is invalid each time a connection is made, which can be annoying.

Some devices will fail without the option of trusting the invalid certificate. For example, if you wanted to use imap.company.com you would need to create a certificate with an internal/external Certificate Authority or it could be part of a Unified Communications certificate in the Subject Alternative Names. Assuming that the proper certificate is in the local computer personal store, we can apply the certificate to the IMAP service using the following shell command.

• Enable-exchangeCertificate –Thumbprint [thumbprint] -Services IMAP

After the above steps, IMAP should now be fully functional on our Client Access Server role. However, at this stage IMAP has only provided a device such as the iPhone a means of receiving messages from Exchange. We still can not send messages from the device.

Configuring SMTP Services to enable sending Messages from an IMAP-enabled Device

The next step is to provide a means to submit outgoing messages from a device such as the iPhone. Outgoing messages will use the SMTP protocol to send the message.

Unfortunately we cannot submit our messages to any SMTP server that we choose, as most SMTP servers are configured to not trust, or relay content from an unknown client. We must use a mail server that allows us to authenticate so the server can trust the client. Many companies may have a mail server provided to them by their ISP that automatically trusts any client on their network but it is often best to provide the means to relay mail for your users.

Many organizations have an Exchange Edge server that is exposed to the internet and is easily reached. Unfortunately, the Edge role cannot authenticate a sender because it cannot contact Active Directory. There are a myriad number of ways you can provide SMTP relay but for most Exchange 2007 organizations the best method is to provide access to an Exchange 2007 Hub Transport role.

All Hub Transport roles have a pre-configured receive connector called Clients for users to relay mail. This connector is set to listen on the standard client SMTP port of 587 and not 25. This connector also requires TLS. By default for security purposes, many Exchange 2007 options, including this one, are not enabled.

In this case, the Clients connector does not allow messages from an address that is in the authoritative domain so we must grant the Authenticated Users session the permission to bypass this restriction. Run this command within the command shell on the hub transport servers:

• get-receiveconnector Client | add-adpermission -user AU -extendedrights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

This is a cross posting from Microsoft Technet forums.

We too at Azaleos are having this same issue at a customer site undergoing an upgrade from Exchange 2003 to Exchange 2007.

In this customer, MAC clients using MAIL 2.1.1 worked just fine with Exchange 2003.

However, when we performed the upgrade, the same MAC client could download mail message headers from Exchange 2007, but on accessing body content 90% of the time the client would just hang and time out with the message: