Anyone who has managed a mixed-client environment where half the office insists on Thunderbird or Apple Mail while the backend is stubbornly locked to Microsoft Exchange knows the pain. Native Exchange support on Linux mail clients has never been great, and the usual workarounds involve either forcing everyone onto webmail or paying for a commercial connector that costs more per seat than it should. DavMail solves this quietly and for free, acting as a local gateway that translates IMAP, SMTP, CalDAV, and LDAP requests into EWS calls that Exchange or Office 365 actually understands.

With Ubuntu 26.04 LTS “Resolute Raccoon” now the default choice for new server deployments, a fresh look at getting DavMail running on it is overdue. The move to Wayland-only sessions, the kernel 7.0 baseline, and the shift toward sudo-rs in this release change a few small things compared to older guides written for 22.04 or 24.04. None of it breaks DavMail, but there are wrinkles worth knowing about before you start, especially around desktop tray integration and Java runtime selection.

This guide walks through installing DavMail on a clean Ubuntu 26.04 LTS system, whether that’s a headless server acting as a shared gateway for multiple clients or a workstation running it locally for a single user. It covers the .deb package method, the manual tarball approach for when you need a specific version, systemd service configuration for unattended operation, and a troubleshooting section built from the kinds of errors that actually show up in production, not the sanitized ones you find in most tutorials. By the end, you’ll have a working DavMail instance, know how to secure it properly, and understand enough of the internals to fix it yourself when something inevitably goes sideways during an Exchange server maintenance window.

What DavMail Actually Does and Why It Matters

DavMail is a lightweight, open source gateway written in Java. It sits between your mail client and Microsoft Exchange, speaking standard protocols on the client-facing side and EWS (Exchange Web Services) or OWA on the server-facing side. In practical terms, you point Thunderbird, Evolution, or even mutt at localhost for IMAP and SMTP, and DavMail handles the translation layer so Exchange never knows the difference.

The typical use case in a corporate Linux shop looks like this: developers and sysadmins are stuck using Exchange because HR or compliance mandates it, but nobody wants to run Outlook under Wine or live inside a browser tab all day. DavMail lets them keep their preferred native client while still hitting the same mailbox, calendar, and contacts that everyone else on Outlook sees.

It’s also common to deploy DavMail centrally on a small VM or container, configured with davmail.server=true, so multiple users on a LAN can connect to it as a shared IMAP/SMTP relay instead of each running their own instance. That’s the deployment pattern this guide leans toward, since it’s the one most relevant to server administrators rather than desktop users.

System Requirements for Ubuntu 26.04 LTS

Ubuntu 26.04 LTS ships with Linux kernel 7.0 and GNOME 50 by default, and it’s the first LTS release where Wayland is the only supported session type on the desktop variant, Xorg has been dropped entirely from the default install. This matters slightly for the systray icon feature in DavMail’s GUI mode, which we’ll address in the troubleshooting section.

Minimum specs for a comfortable DavMail deployment:

• CPU: Any modern x86_64 or ARM64 core; DavMail is not CPU-intensive under normal load
• RAM: 1 GB minimum for a single-user instance, 2 to 4 GB if serving multiple concurrent connections
• Disk: Under 200 MB for the application itself; actual usage depends on whether you’re caching attachments or logs
• Java runtime: OpenJDK 17 or newer (OpenJDK 21 LTS is preinstalled in the 26.04 repos and is the recommended baseline)
• Network: Outbound HTTPS (443) access to your Exchange or Office 365 endpoint

If you’re running this on a shared VPS that also hosts a Nginx reverse proxy and a couple of WordPress sites, DavMail’s footprint is small enough that it won’t compete meaningfully for resources. Just don’t co-locate it with anything doing heavy disk I/O without checking iostat first, since garbage collection pauses in the JVM can get worse under I/O contention.

Step 1: Update the System and Install Java

Before touching DavMail itself, get the base system current. This is non-negotiable on a fresh 26.04 install, and skipping it is one of the most common reasons people hit obscure TLS handshake errors later when DavMail tries to reach Exchange.

sudo apt update && sudo apt upgrade -y

Ubuntu 26.04 defaults to OpenJDK 21 in the universe repository, which is more than sufficient for DavMail. Install it explicitly rather than relying on whatever happens to be pulled in as a dependency:

sudo apt install openjdk-21-jre-headless -y

Verify the installation:

java -version

You should see output referencing OpenJDK 21.x. If you’re planning to run DavMail with its optional GUI (systray icon and configuration wizard), install the full JRE instead of headless, since the headless package strips out AWT and Swing components the GUI depends on:

sudo apt install openjdk-21-jre -y

For a server-only deployment where DavMail runs as a background service with no GUI, headless is the correct and lighter choice. There’s no reason to drag in font rendering libraries and X11 bindings on a box that will never display a window.

Step 2: Choose Your Installation Method

DavMail isn’t in Ubuntu’s official repositories, which surprises people who expect apt install davmail to just work. You have three realistic paths: the .deb package from SourceForge, the platform-independent tarball, or building from source. Ninety percent of the time, the .deb package is the right call for Ubuntu.

Method A: Installing via the .deb Package (Recommended)

Grab the current release from the DavMail SourceForge project page. Check the version number first since it changes frequently.

cd /tmp
wget https://sourceforge.net/projects/davmail/files/latest/download -O davmail-latest.deb

If the automatic redirect doesn’t resolve cleanly (SourceForge’s download redirects occasionally trip up wget on minimal installs), browse the files list manually and copy the direct link for the current .deb release, then substitute it in the command above.

Install it using apt rather than dpkg directly, since apt will resolve dependency issues on its own:

sudo apt install ./davmail-latest.deb

If you already downloaded it and apt complains about broken dependencies, fall back to:

sudo dpkg -i davmail-latest.deb
sudo apt install -f -y

That second command pulls in anything dpkg couldn’t resolve on its own. This two-step fallback has saved more than one late-night deployment when a mirror had cached an older .deb with mismatched dependency declarations.

Method B: Manual Installation via Tarball

For servers where you want tighter control over the exact version, or where you’re deploying to an air-gapped environment and need to stage the files manually, the platform-independent tarball works everywhere without touching the package manager.

cd /opt
sudo wget https://sourceforge.net/projects/davmail/files/latest/download -O davmail.zip
sudo unzip davmail.zip -d davmail
cd davmail

Confirm the extracted directory contains davmail.sh and the accompanying jar files, then make the launch script executable:

sudo chmod +x davmail.sh

This method is a little more manual to keep updated, since there’s no package manager tracking the version, but it gives you a self-contained directory you can snapshot, back up, or replicate across multiple servers without worrying about repository availability.

Step 3: Create a Dedicated Service User

Running DavMail as root, or even under your own personal account, is a bad habit that tends to bite you later, especially if this instance is meant to run unattended on a shared server. Create a dedicated, unprivileged system user:

sudo useradd -r -s /usr/sbin/nologin -d /opt/davmail davmail
sudo mkdir -p /opt/davmail
sudo chown -R davmail:davmail /opt/davmail

The -r flag creates a system account without a login shell or password, and nologin ensures nobody can actually SSH in as this user. This is standard practice for any service daemon and it limits blast radius if DavMail itself ever has a vulnerability exploited, which, being a Java application handling network protocols, is not an impossible scenario.

Step 4: Configure the davmail.properties File

Configuration lives in a properties file, either at ~/.davmail.properties for the current user or specified explicitly as a startup argument. For a server deployment running under the dedicated davmail user, create it at:

sudo nano /opt/davmail/davmail.properties

A solid baseline configuration for an Office 365 or on-premises Exchange gateway looks like this:

davmail.server=true
davmail.mode=EWS
davmail.url=https://outlook.office365.com/EWS/Exchange.asmx

davmail.allowRemote=false
davmail.bindAddress=127.0.0.1

davmail.imapPort=1143
davmail.smtpPort=1025
davmail.caldavPort=1080
davmail.ldapPort=1389

davmail.ssl.nosecurecheck=false
davmail.smtp.saveInSentFolder=true

davmail.logFilePath=/opt/davmail/davmail.log
davmail.logFileSize=10MB

A few of these fields deserve explanation, because copying them blindly is how misconfigurations happen.

davmail.url points to your EWS endpoint. For Office 365 tenants this is almost always https://outlook.office365.com/EWS/Exchange.asmx. For on-premises Exchange, replace it with your organization’s OWA or EWS URL, something like https://mail.yourcompany.com/EWS/Exchange.asmx.

davmail.mode=EWS is the correct setting for anything running Exchange 2010 SP2 or later, which covers essentially every environment you’ll encounter today. Older modes like WebDAV are deprecated and shouldn’t be used.

davmail.bindAddress=127.0.0.1 restricts DavMail to only accept connections from localhost. If you’re running this as a shared gateway for multiple machines on a LAN, you’ll change this to 0.0.0.0 or a specific internal IP, but that decision needs to come with firewall rules, covered in the security section below.

davmail.allowRemote=false is a second layer of the same restriction. Leave it false unless you have deliberately decided to expose this service beyond localhost and have secured it accordingly.

Set ownership and lock down permissions on this file, since it will eventually contain credentials or at minimum sensitive routing information:

sudo chown davmail:davmail /opt/davmail/davmail.properties
sudo chmod 600 /opt/davmail/davmail.properties

Step 5: Run DavMail as a systemd Service

Manually launching DavMail in a terminal is fine for testing, but production deployments need it managed by systemd so it survives reboots, restarts on crash, and integrates with standard logging.

Create the service unit:

sudo nano /etc/systemd/system/davmail.service

[Unit]
Description=DavMail Exchange Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=davmail
Group=davmail
WorkingDirectory=/opt/davmail
ExecStart=/usr/bin/davmail /opt/davmail/davmail.properties
Restart=on-failure
RestartSec=5
LimitNOFILE=4096

NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/davmail
PrivateTmp=true

[Install]
WantedBy=multi-user.target

If you installed DavMail via the tarball into /opt/davmail rather than the .deb package, adjust ExecStart to point at the shell script directly, for example /opt/davmail/davmail.sh /opt/davmail/davmail.properties.

The hardening directives (NoNewPrivileges, ProtectSystem=strict, PrivateTmp) are worth including even though they’re optional. They cost nothing in performance and meaningfully reduce what a compromised process could touch on the filesystem. This is the kind of detail that separates a quick lab setup from something you’d actually be comfortable running on a production box facing real users.

Reload systemd, enable, and start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now davmail.service

Check status:

sudo systemctl status davmail.service

And tail the logs to confirm it’s actually connecting and listening:

sudo journalctl -u davmail.service -f

You should see log lines indicating the IMAP, SMTP, CalDAV, and LDAP listeners have bound to their configured ports without errors.

Step 6: Configure Your Mail Client

With DavMail running and listening, point your mail client at localhost using the ports defined in the properties file.

For Thunderbird, add a new account manually rather than using the autodiscover wizard, since DavMail won’t respond to autodiscovery the way a real Exchange server does:

• Incoming (IMAP): 127.0.0.1, port 1143, connection security: None (since DavMail handles the TLS layer to Exchange internally)
• Outgoing (SMTP): 127.0.0.1, port 1025, connection security: None
• Username: Your full Exchange email address or domain\username, depending on your organization’s auth setup
• Password: Your Exchange password, or an app password if your tenant enforces MFA

That last point trips people up constantly. If your Office 365 tenant has modern authentication and MFA enforced, DavMail’s basic auth handshake will fail outright unless you generate an app-specific password or configure OAuth2 support, which recent DavMail builds support but requires additional Azure AD app registration steps beyond the scope of a basic install.

Firewall and Network Security

If DavMail is bound only to 127.0.0.1, your local firewall doesn’t need special rules since nothing external can reach it anyway. But the moment you set davmail.bindAddress to a LAN-facing IP to serve multiple clients, treat it like any other network service.

With ufw, restrict access to known internal subnets rather than opening the ports broadly:

sudo ufw allow from 192.168.1.0/24 to any port 1143 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 1025 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 1080 proto tcp
sudo ufw enable

DavMail itself doesn’t encrypt the connection between the client and the gateway unless you explicitly configure SSL on the listener side, which it supports via davmail.ssl.keystoreType and related properties. If this gateway is serving remote users over an untrusted network, either enable TLS on DavMail’s listeners directly or, the more common and simpler approach, tunnel client connections through SSH or a WireGuard VPN rather than exposing DavMail’s plaintext ports to the internet at all. Exposing an unencrypted IMAP/SMTP relay on a public interface is asking for credential interception, full stop.

Performance Tuning Considerations

DavMail’s JVM defaults are conservative and generally fine for single-user setups, but a shared gateway serving a dozen or more concurrent mailboxes benefits from tuning the heap size. Edit the launch parameters (either in the systemd unit’s ExecStart line or the davmail.sh wrapper) to include explicit JVM flags:

ExecStart=/usr/bin/java -Xms256m -Xmx1024m -jar /opt/davmail/davmail.jar /opt/davmail/davmail.properties

Bumping -Xmx prevents garbage collection thrashing under heavier concurrent load, which manifests as intermittent slowness in mail sync that’s easy to misdiagnose as a network issue when it’s actually JVM memory pressure. Monitor with jstat or a simple top filter on the java process if users start complaining about lag during peak morning hours when everyone’s client is syncing simultaneously.

Disk I/O rarely becomes a bottleneck for DavMail itself since it’s mostly proxying network traffic, but if you’ve enabled verbose logging for troubleshooting and forgot to dial it back down, log file growth on a busy gateway can quietly fill a disk over a few weeks. Set davmail.logFileSize and rotate logs through logrotate rather than relying on DavMail’s internal rotation alone:

sudo nano /etc/logrotate.d/davmail

/opt/davmail/davmail.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Troubleshooting Common Errors

“Unable to connect to Exchange server” or connection timeout errors. Nine times out of ten this is either an incorrect davmail.url value or an outbound firewall blocking port 443. Confirm connectivity manually first before touching the config:

curl -v https://outlook.office365.com/EWS/Exchange.asmx

If that hangs or refuses, the problem is network-level, not DavMail. Check outbound rules on the host and any upstream corporate proxy that might need to be configured via davmail.enableProxy settings.

Authentication failures despite correct credentials. This almost always traces back to modern authentication and MFA. DavMail’s default mode uses basic auth against EWS, which many tenants have disabled entirely. Check your Exchange admin center or Azure AD conditional access policies. If basic auth is blocked tenant-wide, you’ll need to configure DavMail’s OAuth2 support, which requires registering an app in Azure AD and supplying a client ID and tenant ID in the properties file.

GUI systray icon doesn’t appear on Ubuntu 26.04. Since Wayland is now the default and only session type on the desktop edition, and GNOME’s default shell doesn’t natively support legacy systray icons, the tray icon may simply not render even if DavMail launched fine. Install the AppIndicator support extension:

sudo apt install gnome-shell-extension-appindicator -y

Then enable it through the Extensions app and restart your GNOME Shell session. For headless server deployments this is a non-issue since you’d be running in server mode without a GUI anyway.

“Too many open files” errors under load. This shows up on gateways serving many simultaneous connections. Increase the file descriptor limit in the systemd unit, which the sample configuration above already addresses with LimitNOFILE=4096. If you’re still hitting the ceiling, bump it further and check the system-wide limit with ulimit -n.

Java version mismatch causing startup failure. If you see UnsupportedClassVersionError in the logs, DavMail was built expecting a newer or older JDK than what’s installed. Verify with java -version and update-alternatives --config java if multiple JDKs are present on the system, since Ubuntu 26.04’s repos can pull in more than one JRE depending on what other packages you’ve installed.