# DavMail: a local gateway that lets any mail client speak to Exchange

> DavMail is a Java gateway that translates POP, IMAP, SMTP, CalDAV, CardDAV and LDAP into a single Exchange or Office 365 account, so a Thunderbird or Apple Mail user can keep their mail client. It is most useful when the server is Exchange and the client is anything else.

**mguessan/davmail** — DavMail POP/IMAP/SMTP/CalDAV/CardDAV/LDAP Exchange and Office 365 Gateway - Synced with main subversion repository at

- Repository: https://github.com/mguessan/davmail
- Website: https://davmail.sourceforge.net
- Stars: 772 · Forks: 118
- Language: Java
- License: GPL-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mguessan-davmail

## The gap DavMail fills is an Exchange account and a client that is not Outlook

DavMail exists for a specific and increasingly common mismatch: the mail server is Exchange or Office 365, and the person reading the mail refuses to use Outlook. The project describes itself as a POP/IMAP/SMTP/CalDAV/CardDAV/LDAP gateway that allows users to use any mail client with Exchange and Office 365, and the first line of the README puts it plainly: ever wanted to get rid of Outlook.

That framing matters because it defines the scope. This is not a mail server, not a relay, and not a filter. It is a translator that sits between one side speaking old, universal protocols and the other side speaking Microsoft's own. The audience is therefore two groups. Individual users and small teams who have an Exchange hosted mailbox but want Thunderbird, Apple Mail or another client. And administrators who need a calendar and address book to sync from the same account through standards based clients, which is what the CalDAV, CardDAV and LDAP fronts are for.

There is a second, less obvious audience: organisations that are moving away from Outlook as a product while keeping Exchange as the backend. For them DavMail is a bridge that postpones the hardest part of that migration, the client, without touching the server.

## Six protocol fronts standing in front of one Exchange account

The mechanism is a locally running gateway that speaks the classic protocols on one side and talks to Exchange on the other. The README links an architecture diagram stored in the repository at src/site/resources/images/davmailArchitecture.png, and the protocol list is the clearest description of the shape: POP, IMAP and SMTP for mail, CalDAV for calendars, CardDAV for contacts, and LDAP for directory lookups.

The point of running it locally is that the mail client needs a server it can reach, and the Exchange account does not present one in a form a standard client accepts. The gateway provides that local server, and the client talks to it in the way it already knows how. A user configuring a mail client therefore points it at a local address and port, and nothing about the client's behaviour changes.

The repository shows how this is built. The primary language is Java, the tree carries src/ and lib/ directories, and both build.xml and pom.xml sit at the top level, so there is an Ant build and a Maven build of the same codebase. davmail-user.conf is a configuration file kept in the repository root, which tells you the gateway is configured locally rather than through a web admin panel. There is no service, no account database and no multi tenant layer in this project.

## Where to get DavMail: SourceForge, RPM, COPR, Flatpak and container images

DavMail is distributed through several channels, and the README is explicit about which one is the main one: the main project site is still on Sourceforge at davmail.sourceforge.net, and the latest release is downloaded from there, currently version 7.1.0.

Linux users are covered by packages built outside the repository, with RPM packages from the OpenSuse build service and an alternative COPR build on Fedora. If the distribution supports Flatpak, the application is published as org.davmail.DavMail on Flathub. Docker images are also available on GitHub Container Registry, with the container documentation in the repository under src/docker.

If you want the newest code rather than the newest release, the trunk builds live on Appveyor, and the README lists a Windows 64 bit setup executable, a Windows standalone package, a platform independent archive, a Debian package and a macOS application bundle. There is a practical note about runtimes attached to those builds. The Windows packages carry an embedded Java Runtime Environment, the Debian package depends on OpenJDK, and Azul JDK is preferred on macOS.

The setup instructions themselves are not in the repository README, which points to the Getting Started page on the project site for that, along with a separate macOS setup guide.

## A Java codebase with an Ant build, a Maven build and a subversion origin

The repository layout tells you how the project is actually maintained, and it is unusual for a GitHub hosted project. The README states that this git repository is synchronized with the subversion repository in order to make contributions easier for GitHub users, and the tree carries an svnant/ directory, a davmail.changes changelog and a releaseguide.txt. The consequence is that the canonical history lives elsewhere and the GitHub copy is a mirror.

Two build files coexist. build.xml is the traditional Ant build, and pom.xml is a Maven descriptor for the Java sources under src/ and the libraries in lib/. Packaging for Windows is handled by an NSIS installer script, davmail-setup64.nsi, along with the nsis/ directory, and the davmail.spec file is the RPM spec. An archive/ directory suggests older material is kept alongside the current tree. Continuous integration is configured through appveyor.yml, and sonar.properties points the build at SonarCloud, which the README shows badges for.

Contributions can arrive as a GitHub pull request, which the README calls the preferred route, or as a patch submitted through the SourceForge tracker, and the open issues list is where the maintainer expects people to look for tasks.

## The gateway has to be running before the mail client is useful

Here is the constraint that shapes every deployment. DavMail is a process on a machine, and the mail client only works while that process is up. A laptop user starts the gateway, opens the client, and has mail. A shared office scenario is different: either every user runs their own gateway with their own copy of the Exchange credentials, or one gateway runs on a server and the clients point at it over the network, in which case the credential handling moves to that server and the account configuration has to be shared and protected.

The runtime requirement is the second constraint. The Windows packages embed a Java Runtime Environment so that route is simple, but the Debian package depends on OpenJDK and macOS users are pointed at Azul JDK, which means a machine without a usable Java installation needs extra work. The Flatpak and Docker distributions reduce that friction by carrying their own runtime assumptions, and the container route is the sensible one for a shared gateway, since it can sit on a small server next to the client configuration rather than on every desk.

A quieter limitation sits in the configuration. davmail-user.conf is the file where the exchange account details live, and the repository README does not document what it contains or how it should be protected, so the operator has to read the Getting Started guide and decide for themselves how the file is stored and who can read it.

## Releases are cut on SourceForge, not on GitHub

DavMail has no GitHub releases at all. The versioned artefacts, the 7.1.0 download and the older files all live on the SourceForge project, and the trunk builds are hosted on Appveyor under a trunk suffix. Reading the version number from the GitHub repository is therefore not a reliable guide to what is in production, and anyone automating a DavMail install has to track the SourceForge file list instead.

What the repository does provide is a written record. RELEASE-NOTES.md is the whats new document, SECURITY.md is present for reporting or policy, and the site at davmail.sourceforge.net carries the Getting Started guide and the macOS setup page. The repository itself is not archived and the last push was on 2026-10-19, so the source is moving even though the published release number is a separate question.

The licence is GNU General Public License v2.0, with the LICENSE file in the repository root. This is the practical constraint for anyone repackaging it. The Windows installer, the Debian package, the Flatpak app and the container image are all redistribution, and GPL-2.0 attaches conditions to redistributed versions, including the same licence and an offer of the corresponding source. Anyone building an internal image of DavMail for a company should look at what that means for their own distribution. The project also asks for donations in dollars or euros to support development.

## When a client that speaks to Exchange directly is the better answer

The alternative is not a better gateway, it is removing the need for a gateway. A client that talks to Exchange natively gives the user their mail, calendar and contacts with no local process to start, no Java runtime to install and no local file holding the account credentials. The trade is that the user is back to the client the exchange platform supports, or to a limited web experience.

A second alternative is a hosted gateway that someone else operates. The difference in approach is where the credentials and the running process live. DavMail puts both on a machine you control, which keeps the data path inside your network and makes the security question your own to answer. A hosted service removes that responsibility and adds a third party between the client and the account, along with a dependency on someone else's availability and pricing.

There is also the option of running the gateway once for a whole team on a server, which is where the Docker images and the shared server deployment start to make sense. What is less defensible is running one DavMail instance per user on every desktop, because that multiplies the number of places a copy of the Exchange account credentials exists without gaining anything.

## Conclusion

Adopt DavMail when a user must keep a non-Outlook client while the account stays on Exchange or Office 365, and you are willing to run a Java gateway on the machine or a small server that holds the account credentials. Do not adopt it where the native client already speaks to the account, or where putting Exchange credentials in a local configuration file is not acceptable. Before deploying, check the release notes for the version you pin, since releases are cut on SourceForge and the GitHub repository carries no releases of its own, and confirm that the davmail-user.conf configuration your users need is documented in the Getting Started guide rather than in the repository README.

## FAQ

### What is DavMail and what does it do?

DavMail is a Java gateway that provides POP, IMAP, SMTP, CalDAV, CardDAV and LDAP fronts to a single Exchange or Office 365 account, so any mail client can be used with it. The project describes itself as a gateway allowing users to use any mail client with Exchange and Office 365.

### How do I install DavMail on my machine?

The latest release, 7.1.0, is downloaded from the SourceForge project page, and RPM packages are available from the OpenSuse build service with an alternative COPR build on Fedora. A Flatpak build is published as org.davmail.DavMail on Flathub, Docker images are on GitHub Container Registry, and the Windows packages include an embedded Java Runtime Environment while the Debian package depends on OpenJDK.

### Does DavMail work with Office 365 as well as Exchange?

Yes. The README describes DavMail as a POP/IMAP/SMTP/CalDAV/CardDAV/LDAP gateway for Exchange and Office 365, and the repository topics include both exchange-server and office365.

### Where are DavMail releases published?

The repository has no GitHub releases. Versioned packages, including the current 7.1.0 download, are hosted on the SourceForge project, and the latest working trunk builds are published on Appveyor for Windows, Linux and macOS.

### Can I contribute to DavMail on GitHub?

Yes. The README says contributions are welcome as a GitHub pull request, which it calls the preferred option, or as a patch through the SourceForge tracker, and it points contributors at the open issues list for tasks.

## Sources

- [Issues](https://github.com/mguessan/davmail/issues)
- [License: GPL-2.0](https://github.com/mguessan/davmail/blob/master/LICENSE)
- [mguessan/davmail on GitHub](https://github.com/mguessan/davmail)
- [Project website](https://davmail.sourceforge.net)
- [README](https://github.com/mguessan/davmail/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mguessan-davmail