Using common Linux mail clients with an Exchange Server
Begin your migration away from Microsoft Exchange by learning how to set up Linux mail clients, Evolution and Thunderbird, to talk to Exchange.
Exchange Server -- and its client, Outlook -- are some of the more entrenched bits of Microsoft technology in most enterprises. It's often a bit of a project to migrate away from them, and the scope of the migration is what makes it difficult. For example, migrating individual Outlook seats is easier than a whole Exchange organization, but even migrating individual Outlook installations can be tricky depending on what you're migrating to.
To that end, some organizations choose to take a gradual approach. Start by migrating the clients, leave the server as-is for the time being and then migrate the server once people are used to the new front-end. This requires some understanding of how to get specific Linux mail clients to talk to Exchange, as each one poses its own particular issues.
 |
||||
|
|
|||
|
||||
Evolution
The Novell Evolution mail client (formerly part of the Ximian suite) has featured support for Exchange since Evolution 2.02. It can connect to Exchange servers via the Evolution Exchange connector, which supports a basic set of Exchange server features and uses MAPI as the main protocol (it's available in Ubuntu, for instance, as the "evolution-mapi" package). It's also possible to configure Evolution to connect to Exchange via Outlook Web Access, although this comes with a serious reduction in functionality.
If you're forced to use OWA, there's two ways it can be used securely, both generally and by Evolution in particular. The first is over an SSL connection, which is how it's typically done by a client with a Web browser (regardless of platform). The second is to use forms-based authentication, which has been available in Evolution since version 1.4.5.
While FBA doesn't require the presence of an SSL certificate, it's also not regarded as being suitable for a production environment. For that reason, you'll probably want to stick to using SSL with a properly-signed (i.e., not self-signed) certificate as the preferred connection method, especially if you have clients that are connecting to the Exchange server from outside the organization's own network. Using a VPN to talk to the server, if you're forced to use FBA, may provide a bit of additional security -- but it's often easier just to set up an SSL connection.
Thunderbird
Mozilla's Thunderbird mail client can talk to Exchange in one of two ways: as an IMAP client, or as a MAPI client. IMAP is the more broadly standard of the two protocols; MAPI is essentially a Microsoft-only protocol designed for its own mail products. It is possible for third-party applications to work with MAPI, but there are some serious drawbacks to doing so, especially as far as Thunderbird is concerned.
The biggest problem with using MAPI is that Thunderbird's implementation of MAPI is incomplete, so many of the features you'd get with a full MAPI client simply don't exist. You can send and receive mail as per a POP3 mailbox, and you can poll the Exchange Global Address List as if it were an LDAP address book, but it's not the best way to work.
The better way to do this is to have Thunderbird talk to Exchange as an IMAP client. This, however, requires that IMAP support be explicitly enabled on Exchange, since it's not on by default. Fortunately, this isn't terribly difficult; it requires little more than adding an IMAP virtual server to Exchange and configuring client support for it. Setting it up and managing is similar in Exchange 2007 (and 2010) as well. Once this is done, most any Linux mail client that speaks IMAP can be configured to talk to Exchange.
Again, note that in most cases, many Exchange-specific features will not be available. Calendaring, for instance, is a topic all its own, and would require a completely separate exploration. But the basics -- reading folders, sending and receiving mail, and using an address book -- should work.
The future
Because Microsoft is changing the way Exchange APIs are exposed and implemented, there's a good chance Thunderbird and other open e-mail clients may implement Exchange connectivity very differently in the near future. The biggest potential difference is how Microsoft will continue to support the ExtendedMAPI interface; developers are encouraged to discontinue using it and move instead to Exchange Web Services. Microsoft themselves have noted EWS will be a platform that encourages third-party products to connect to Exchange, so it's almost certain that connectors for programs like Evolution and Thunderbird will be written to support it.
