Linux.com

Home Learn Linux Linux Tutorials Escaping Microsoft Exchange via Davmail + Fetchmail + Postfix + Courier IMAP

Escaping Microsoft Exchange via Davmail + Fetchmail + Postfix + Courier IMAP

Many enterprises use Microsoft Exchange for corporate e-mail, and there is frequently no avoiding its use regardless of where you might sit in the organization or the freedom afforded to you in terms of desktop configuration. Whilst Exchange has the capability to provide an IMAP and/or POP service these are frequently disabled, leaving Outlook Web Access (OWA) as the only remaining hope for users of non-Microsoft mail user agents (MUAs). This tutorial explains how to use a recipe of Davmail + Fetchmail + Postfix + Courier IMAP to interface standards-based e-mail clients with Exchange’s OWA, and to integrate corporate and non-corporate e-mail accounts into a single inbox and one that is not buried inside the store of the MUA.

Before You Start

This particular configuration is perhaps best suited to a more advanced desktop configuration, else as the basis for a server-based resource where you may have multiple desktops and want to synchronize mail across devices.

If you want the quickest and simplest route to getting mail from OWA into your MUA of choice, and are fine with it being pulled down into the local folders of a MUA, you might be better off using Davmail in its desktop configuration and without the complexity of Postfix + Fetchmail + Courier IMAP.

This tutorial assumes that:

  • You have the OWA service configured on your Exchange server, e.g. https://mail.acme.com/exchange/
  • You have a Gmail account with POP enabled (this tutorial could be easily adapted to other service providers)
  • You are running Ubuntu GNU/Linux. However, there should be few differences if you are running Debian, and it should be easy enough to adapt this configuration to accommodate RPM-based distributions
  • You are capable of appropriately securing services, e.g. managing firewall configuration

Meat & Potatoes

Note: this tutorial uses acme.com as the example corporate mail domain (OWA) and Gmail as the non-corporate mail service. You could just as easily have multiple Exchange accounts and/or standards-based e-mail accounts.

Install Packages

Fetchmail, Postfix and Courier IMAP and dependencies can all be installed via the package management system:

$sudo apt-get install postfix fetchmail courier-imap sun-java6-jdk tomcat6 tomcat6-admin ant

Configure Certificates

To be sure that we are actually connecting to Gmail and to encrypt e-mail to and from the service we need to set up a few certificates.

Create a local certificate store:

$mkdir -p /etc/ssl/local/certs/

Install the Thawte root CA certificate (required for Gmail SMTPS):

  • Go to Thawte and download their root CA certificates
  • Unzip the ZIP archive and locate the file: Thawte Premium Server CA.cer
  • Convert the CA certificate to PEM format and install:
$sudo openssl x509 -inform der -in 'Thawte Premium Server CA.cer' -out /etc/ssl/local/certs/thawte.pem

Install the Equifax root CA certificate (required for Gmail POP3S):

$sudo wget -O /etc/ssl/local/certs/equifax.pem https://www.geotrust.com/resources/root_certificates/certificates/ Equifax_Secure_Certificate_Authority.cer

Install the Gmail POP3S certificate:

$openssl s_client -connect pop.gmail.com:995 -showcerts

From the output of the command select the pop.gmail.com certificate (the first block to appear between and including lines “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–”) and copy and paste this into a new file:

/etc/ssl/local/certs/googlepop.pem

Hash the certificates:

$sudo c_rehash /etc/ssl/local/certs

Build and Configure Davmail

Grab the latest Davmail code from SVN. For checkout details see the Sourceforge page. Then to build:

$cd davmail/trunk $ant

If the build is successful proceed to configure the web application archive (WAR file) version of Davmail:

$cd dist $jar xvf davmail-N.N.N-NNN.war

(replacing ‘N.N.N-NNN’ with the version number)

Edit the file WEB-INF/classes/davmail.properties as appropriate, for example:

davmail.url=https\://mail.acme.com/exchange/ davmail.popPort=1110 davmail.smtpPort=1025 davmail.ldapPort=1389 davmail.caldavPort=1080 davmail.keepDelay=60 davmail.sentKeepDelay=180 davmail.caldavPastDelay=60  davmail.enableProxy=false davmail.proxyHost= davmail.proxyPort= davmail.proxyUser= davmail.proxyPassword=  davmail.allowRemote=true davmail.bindAddress= davmail.server=true davmail.disableUpdateCheck=false  log4j.logger.davmail=DEBUG log4j.rootLogger=WARN log4j.logger.httpclient.wire=WARN log4j.logger.org.apache.commons.httpclient=WARN

You should really only need to update davmail.url with the URL of your OWA service, but you may also choose to adjust the davmail.*Delay settings which control things such as for how many days messages that have been retrieved should be left on the Exchange server. However, note that the Postfix and Fetchmail configuration that follows assumes that you have set the POP3 and SMTP port numbers as detailed above.

Re-package the web application archive:

$jar cvf davmail.war WEB-INF META-INF

Configure Tomcat and deploy Davmail

Grant all Java security permissions to Davmail by editing the file /etc/tomcat6/policy.d/50local.policy and adding to the bottom:

// Davmail //grant codeBase "file:${catalina.base}/webapps/davmail/-" { //        permission java.security.AllPermission; //};

Create a user for the Tomcat admin application by editing the file /etc/tomcat6/tomcat-users.xml and adding to the bottom:

<tomcat-users> <role rolename="tomcat"/> <role rolename="manager"/> <user username="yourusername" password="yourpassword" roles="manager"/> </tomcat-users>

Substitute “yourusername” and “yourpassword” for the username and password you want to use for administering Tomcat.

Restart Tomcat:

$sudo /etc/init.d/tomcat6 restart

Deploy Davmail:

  • Log in to the Tomcat admin application at http://yoursystem:8080/manager/html
  • From the WAR file to deploy section browse to the davmail.war archive we created earlier, and then select Deploy.
  • Davmail should now be listed in the Applications section. If Davmail is not showing as running select Start from the Commands column.

Configure Postfix

For security reasons it makes sense to keep mail on-system whenever possible. Or to put it another way: if I send mail from my Acme Inc account to another Acme Inc user why route it via a 3rd party mail system? So, we’ll be explicit when it comes to mail routing.

Edit the file /etc/postfix/main.cf and set the following options:

home_mailbox = Maildir/  smtp_tls_loglevel = 1 smtp_tls_per_site = hash:/etc/postfix/tls_per_site smtp_tls_CAfile = /etc/ssl/local/certs/thawte.pem smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache smtp_use_tls = yes  smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous  relayhost = [smtp.gmail.com]:587  disable_dns_lookups = yes  smtp_generic_maps = hash:/etc/postfix/generic  sender_dependent_relayhost_maps = hash:/etc/postfix/bysender

Configure Postfix to route mail sent from the corporate account(s) to OWA via Davmail, by editing the file /etc/postfix/bysender and adding:

@acme.com         [localhost]:1025

Map any local users to routable mail addresses by editing the file /etc/postfix/generic and adding:

ausername@yoursystem		
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 

Note: ‘yoursystem’ is the system we are configuring, ‘ausername’ is a Linux account on this system and the right hand address could be an Exchange or Google account. This configuration is optional and is only used where a MUA defaults to setting the originator address of a message to $LOGNAME@$HOSTNAME.

Store the authentication credentials for remote SMTP (and sending via OWA) by editing the file /etc/postfix/sasl_passwd and adding:

[smtp.gmail.com]:587    
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 :gmailpassword [localhost]:1025        DOMAIN\USER:domainpassword

Note: the 2nd line is specifying credentials that will be passed to OWA via Davmail, therefore “DOMAIN\USER” is the username half of Windows domain credentials. Ensure that this file is mode 640 and ownership root:postfix.

For security reasons force connections to Google’s SMTP service to use TLS by editing the file /etc/postfix/tls_per_site and adding:

smtp.gmail.com         MUST

Create the Postfix lookup tables:

$cd /etc/postfix $sudo postmap bysender $sudo postmap generic $sudo postmap sasl_passwd $sudo postmap tls_per_site

Restart Postfix:

$sudo /etc/init.d/postfix restart

Note: If you plan to use this configuration on a server you will likely want to configure Postfix to accept SMTP connections from remote MUAs over SSL. However, this is out of the scope of this tutorial.

Configuring Courier IMAP

Edit the file /etc/courier/imapd and ensure that the following variables are set (they should be found toward the bottom of the file):

IMAPDSTART=YES  MAILDIRPATH=Maildir

Edit the file /etc/courier/authdaemonrc and ensure that the following variable is set:

authmodulelist="authpam"

Note: If you plan to use this configuration on a server you will likely want to configure the Courier IMAP service to work over SSL. However, this is out of the scope of this tutorial.

Configure the Local User Environment

Create an initial maildir format mailbox:

$maildirmake ~/Maildir

Create a new file ~/.fetchmailrc to hold the Fetchmail configuration:

# # ~/.fetchmailrc # # Check mail every 120 seconds # set daemon 120 set postmaster ausername # # Gmail # poll pop.gmail.com with proto POP3 and options no dns         user '
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 ' with pass "gmailpassword" is 'ausername'         here options ssl sslcertck sslcertpath '/etc/ssl/local/certs/'         smtphost localhost # # ACME Inc # poll localhost with proto POP3 and options port 1110 no dns         user "someuser@ACME" with pass "domainpassword" is 'ausername' here         smtphost localhost #

Note: “ausername” is the local Linux account. SSL is not needed when retrieving mail from Exchange as the fetchmail -> Davmail connection will be over localhost, and Davmail -> OWA over https (unless your Exchange administrators have configured the OWA service to run over http).

Manually start Fetchmail in verbose mode and check for errors:

$fetchmail -v

Fetchmail can be configured to automatically start via a number of different mechanisms. For example, with Gnome desktop you could create a new ‘Startup Application’ from System -> Preferences, and have ‘/usr/bin/fetchmail’ be executed on login. Or you could add fetchmail to your personal crontab, e.g.:

*/2 * * * * /usr/bin/fetchmail -s

When using cron you would remove the line starting set daemon from file .fetchmailrc.

Finishing Up

Mail Client Settings

If you are running a local MUA that supports the maildir mailbox format there should be nothing to configure other than the sending identities and application preferences. If you are using a local MUA that does not support maildir you should use IMAP and enter localhost for the server and use your Linux account credentials for authentication. If you are using this configuration on a server: for the MUA on the client you would use the server FQDN for the IMAP server and your Linux account credentials for authentication, and SMTP settings would depend on how you had configured SMTP authentication (incoming to the server).

Davmail also provides proxies for LDAP and CalDAV to OWA:

  • LDAP: server: localhost:1389; bind dn: USER@DOMAIN; password: domainpassword; search base: ou=people; search field: sn
  • CalDAV: URL: http://localhost:1080/users/ This e-mail address is being protected from spambots. You need JavaScript enabled to view it /calendar/; password: domainpassword

USER@DOMAIN and domainpassword are the credentials associated with your Windows domain account.

Note: Whenever your Windows domain password or Gmail password changes you will need to update this in ~/.fetchmailrc and /etc/postfix/sasl_passwd, and execute $sudo postmap /etc/postfix/sasl_passwd.

Conclusion

The configuration detailed here is rather more complicated than ought to be and has wrinkles such as having to store user credentials in both Fetchmail and Postfix configuration. As such its appeal is likely limited to use with more complex mail requirements involving OWA and where there are few, if any, alternative options. Davmail could be used on its own for simple OWA access; however, the addition of Fetchmail and Postfix also means that e-mail is always stored in a standard format, maildir, and that where possible outbound e-mail is always kept on-system. The addition of Courier IMAP allows a greater number of local MUAs to be used (i.e. those that do not support maildir), and the configuration could be deployed to a server and the unified inbox synchronised across multiple desktops.

Finally, there is much room for improvement, and it would be great to see this configuration further developed such that user credentials were better handled and a practical, secure multi-user proxy server could be easily set up, thereby providing a shared service for Exchange OWA <—> standards-based (IMAP, SMTP, LDAP and CalDAV) MUA integration.

Andrew Back
Andrew Back joined BT in June 2005 and has been working with Free Software since 1995. He currently holds the position of Open Source Strategist with BT's open source innovation unit, Osmosoft. During his tenure at BT he has been responsible for driving strategy for the effective adoption of open source technology and principles across all lines of business, the development of open source governance practice and the creation of BT Design's Open Source Focus Group. He represents BT at the Linux Foundation FOSSBazaar work group, is a Fellow of the Royal Society for the encouragement of the Arts, Manufactures and Commerce, and is a Chartered Member of the British Computer Society.


Article Source Wazi

 

December 15, 2009, 12:32 pm 

 

 

 

Comments

Subscribe to Comments Feed

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board