Aerion: a lightweight mail client that keeps its accounts to itself

The pitch is independence from the desktop account service

The readme starts with a survey of what Linux has to offer, and it is a pointed one. Thunderbird is described as clunky and carrying too much legacy structure, Geary as crippled by GNOME Online Accounts with unreliable search, Mailspring as an Electron application, and Evolution as something from 1999. The point of the list is not that those clients are bad, it is that the category has not been served well.

Aerion is described as a standalone lightweight e-mail client inspired by Geary, with five stated goals. Resource efficiency, meaning minimal CPU, RAM and battery consumption. A modern interface with dark mode support. Keyboard and mouse friendliness, with full keyboard navigation and vim-style shortcuts. Independence, with no dependency on GNOME Online Accounts or other system services. And search that works, which the readme phrases as basic search that actually finds your emails.

The independence goal is the one with teeth. A client that uses a desktop account service inherits that service's OAuth flows, its token storage, its permission model and its release cycle, and it inherits the bugs too. A client that holds its own IMAP and SMTP credentials can be configured once and then behave the same on every desktop, which is a real advantage for anyone who moves between Linux, macOS and Windows, all three of which are supported.

The keyboard emphasis is also a genuine differentiator in the category. The readme links a keyboard shortcuts document, and the topic list includes a term for people who live in their keyboard shortcuts, which tells you what kind of user the author is designing for.

Wails and Svelte in front, Go behind

The tech stack is stated plainly: the application was built with Wails plus Svelte. Wails is the framework that lets a Go program own the window and drive a web frontend through a Go binding layer, and that choice is what delivers the resource profile the project claims, since there is no bundled browser engine the way there is with Electron.

The repository layout matches. There is a main.go and a preflight.go at the root, a cmd directory, an internal directory holding the Go packages, an app directory, a frontend directory with the Svelte source and its assets, an extensions directory for the first-party extension packages, a build directory, a docs directory, and a wails.json file describing the Wails application configuration.

Two files at the root are worth a closer look because they tell you about the platforms involved. There is a webkit_preinit_linux.go and a webkit_preinit_other.go, which is the usual pattern for a WebKit based desktop app that needs to do something different on Linux, where the WebKit runtime is a system package with a different lifecycle from the one macOS and Windows provide. A preflight step, with its own bindings file, suggests the application runs a check before starting.

The go.mod declares the module as github.com/hkdb/aerion and requires Go 1.25.0. The build is driven by a Makefile whose targets are documented in its own header, and the targets are the standard set for a desktop project with several platforms:

make build
make dev
make help

The same target list in the Makefile shows that the project ships install and uninstall targets for Linux and macOS, plus a Windows installer target and Flatpak targets, so it is packaged for several desktop formats rather than being a source-only affair.

The Go dependency list shows what the client really does

The dependency list is unusually informative, because a mail client has to touch a lot of protocol surface and the libraries chosen name that surface exactly.

The IMAP stack is the emersion family: go-imap in its second version, still marked as a beta in the pinned release, go-message for parsing and serialising mail, go-sasl for authentication negotiation, go-ical for calendars, go-vcard for contacts and go-webdav for the CardDAV and CalDAV side. Reading those six together tells you the client is not limited to fetching mail, it speaks the whole CalDAV and CardDAV world too.

Around them sit the pieces a real client needs. The ProtonMail go-crypto library and go.mozilla.org/pkcs7 handle the signing and encryption side for PGP and S/MIME, with the software sslmate pkcs12 library for the certificate formats that come with S/MIME identity certificates, and the zalando keyring library for storing secrets in the platform credential store. The microcosm bluemonday library is an HTML sanitiser, which is the standard way to strip dangerous markup out of message bodies, and the teamwork tnef library handles the winmail.dat attachments that older Windows mail clients produce. The modernc SQLite driver is a pure Go one, so there is no cgo dependency for local storage.

The rest is desktop plumbing: the wails framework itself, the godbus dbus library for Linux notifications, a toast library for desktop notifications, a UUID library, the zerolog logger, a digest library for HTTP authentication, and the x/crypto, x/net, x/text and x/sys modules from the standard extended library.

The tracking element removal feature in the readme is worth connecting to this list. Basic removal of tracking elements in mail content is a sanitisation feature, and bluemonday is the library that makes it possible to do that safely rather than with regular expressions over HTML.

Provider support, including the parts that are not tested

The provider list is long, and it carries a marker that deserves attention. Some providers are followed by a laboratory symbol that the readme defines as not yet tested, and the affected entries are Fastmail, Zoho Mail, AOL Mail and Mail.com.

The rest are listed without that caveat: generic IMAP and SMTP, GMail, Microsoft 365 and Outlook, Yahoo, Proton Mail via Proton Bridge, iCloud Mail, Mailfence, Murena, GMX Mail and Mailbox.org.

The marker is a small piece of honesty that tells you how to read the list. A provider listed without it has been worked against, and one listed with it is configured in the interface but has not been exercised, which is a meaningful difference when a provider has a non-standard authentication flow or an unusual IMAP dialect.

Proton Mail is worth singling out because it does not speak IMAP directly. It is supported through Proton Bridge, which means the user has to run that bridge alongside the client, and the interaction between two local processes and one account is a different failure surface from talking to a server.

The account model itself is worth noting. Multiple accounts are supported, with a unified inbox that colour codes accounts, and conversation threads, so the client is a multi-account client rather than a single mailbox with extra steps.

The extension system, and the credentials it needs

The most recent and least settled part of the project is its extension system.

A first-party extension system ships with two extensions, a calendar and a contacts panel, and both are labelled alpha and disabled by default. That is the correct way to ship something unfinished, and it also means the default Aerion install is a mail client, nothing more.

The environment example shows what the extensions cost in practice, and it is more than a single client id. There is a Google client id and secret for the mail side, a Microsoft client id for the Outlook side, and then a separate Google testing client id and secret for the first-party extensions. The comment explains the reason: the extensions need broader scopes than the mail application's verified client carries, such as contacts read and write and full calendar access, so a single unverified test project backs both extensions, and the picker surfaces it as a testing option so users understand they may see the unverified application warning during the consent screen.

The Microsoft comment says something similar, that the Graph scopes for contacts and calendar are not gated behind verification, so the same registration can serve mail, contacts and calendar. The verified Google client covers the mail scopes and backs extensions for any scope their manifest declares, which today is contacts read only.

So the practical setup for the extensions is a build of your own with your own credentials:

GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com

The Makefile injects these at compile time rather than reading them at run time, and it loads them from an environment file, with a local file taking precedence, and the file is not committed. That is a reasonable arrangement, and it is also a lot of moving parts before you can sync a calendar.

Certification, sponsors and a recurring bill

The news section of the readme is where the project's real priorities show through, because the entries are about third-party verification rather than features.

Google verification is dated 2025-04-25, Microsoft verified on 2026-03-11, and CASA Tier 2 certification on 2026-04-16. The certification comes from Google's preferred authorised assessor, TAC Security, and the readme states the tier and the assessor. CASA Tier 2 is a security assessment for consumer applications that use Google OAuth, and it is what allows a mail client to hold a verified Google application, which in turn is what keeps the unverified application warning off the consent screen.

The consequence is described with unusual candour. Apps like Aerion have to recertify for CASA Tier 2 every year, which cost 540 US dollars this year, and that cost was sponsored one time by 3DF. From the next year the project will have to depend on community or corporate sponsorship, and the readme asks people who want to fund the certification specifically to say so on the donation page. The sponsorship arrangement is stated as well: 3DF sponsors the project by dedicating cloud infrastructure resources and the team's time to work on it, and there is otherwise currently no sponsorship.

For an evaluator this is the most important operational fact in the repository. The project is a small team's work with a recurring compliance cost, and the certification that makes Google sign-in pleasant for users depends on money that is not yet committed. A readme that tells you this is doing you a favour.

The product itself is honest in other ways too. The readme states a transparency disclaimer that the project leveraged Claude models heavily to implement, which is worth knowing before you judge the code's provenance.

Where it stands, and what to check first

The current state is a pre-1.0 application with a community behind it. The release history is short and recent, with v0.3.4 on 2026-09-18, a test build and then v0.3.5 on 2026-09-21, and the last push on 2026-10-06. The licence is Apache-2.0, the default branch is main, and the project is not archived.

The feature set covers the things that matter in a mail client: a WYSIWYG detachable composer and WYSIWYG signatures, both built on the TipTap editor, contact sync for auto-complete over CardDAV and the Google and Microsoft variants, basic local and IMAP search, a notification that brings focus to the email when clicked, automatic sync when the system wakes from suspend, multiple colour themes, PGP and S/MIME support, and basic removal of tracking elements from message content. Keyboard shortcuts have their own document. There is a security policy file, a contributing guide and a changelog.

The road map lists post quantum ready encryption as a confirmed future feature, along with account templates for Mailfence and Startmail in the add account flow, and lists customisable shortcut keys, advanced search and AI assisted composition using Ollama as potential features. A local model for composition is an interesting choice for a mail client, since it keeps the text of a message on the machine.

Before you install, the sensible order is to read the official installation guide, which is the only installation reference the project offers, then register your own OAuth clients if you want the provider integrations to work, and then try it against a secondary account with a couple of providers, one from the tested list and one from the untested list, so you find out which category your own provider falls into.

Editorial conclusion

Aerion suits a Linux desktop user who wants a mail client that is not an Electron app, does not depend on a desktop account service, and can be extended with first-party modules. It is a poor fit if you need a client with years of battle testing behind it, if your provider needs the OAuth setups the readme leaves undocumented, or if you need the calendar and contacts extensions, which are alpha and disabled by default. Before you commit, try it with a secondary account, read the OAuth section of the environment example so you know what credentials you will be asked to register, and check the installation guide for the packaging format your distribution expects.

Frequently asked questions

Official sources

1. hkdb/aerion on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases