I’m Salvatore (GitHub: stalvatero). I use GNOME daily and wanted a mail client that feels like current GNOME and shares the same accounts as Calendar and Contacts — no second account wizard.
Letter is a GTK 4 + libadwaita client built on GNOME Online Accounts and Evolution Data Server / Camel. I’ve been using it as my daily driver for a while; 0.9.0-beta.1 is the first public beta.
What it does (short):
Google, Microsoft 365, and IMAP via Online Accounts
Screenshots are in the README. Happy to hear what feels right or wrong for a GNOME mail workflow — especially if you try Microsoft 365 (Graph) or multi-account setups.
Aside from the genAI aspect, you should be very careful about relying on GNOME Online Accounts: the accounts there are provided to core applications and system components, as per the GOA documentation.
Yes: there are non-core applications that access accounts, like Geary and (optionally) Evolution; those cases are considered legacy. Newly written applications should not rely on GNOME Online Accounts.
Seeing as there is currently no core email client but several options in Online Accounts for connecting to mail servers, what purpose is that functionality intended to serve?
Historical reasons. When Online Accounts were introduced, the idea was to centralise the account management for a GNOME-specific mail user agent—likely in the form of Evolution; that didn’t happen, as Evolution remained committed to its existing design, and it never had sufficient resources for an update. Then Geary appeared, and it seemed to positioned to fill that particular gap; that also didn’t happen. Unlike Evolution, Geary never had the ability to manage additional email accounts without going through GOA, so this particular aspect of Online Accounts remained as a mechanism to maintain email accounts for Geary and Evolution users that created them on earlier GNOME installations.
Ah, okay. So is the risk of tying a mail application to Online Accounts basically that its mail functionality is no longer being maintained/updated? If so, what do you expect it would take for that to change?
Apologies for hijacking the thread. I can create a new topic if that’s more appropriate, but am interested because I have been plodding through my own project that requires an SMTP connection and have been thinking about Online Accounts.
It is unlikely that Mail account capabilities will be removed, at this point.
The reason why third party applications should not rely on GNOME Online Accounts are explained in the link I provided. GNOME Online Accounts is a provider for GNOME, not any random third party applications.
Thanks for the replies, and sorry if the first post sounded a bit “press release” .
I’ll answer both points.
On AI: Letter is my project. I designed it, I decide the architecture, and every change that lands in the repo goes through me. I do use AI sometimes while developing, mostly the way I’d use a search engine: to dig into APIs, Camel/EDS quirks, Flatpak bits, etc., without bouncing across ten tabs. It’s assistance under my control, not “the model wrote the app”.
On GNOME Online Accounts: I read the GOA goals/account policy you linked, Emmanuele — thanks for pointing that out . I understand how GOA is intended.
The choice today is deliberate, though, and for a young app it’s mostly about trust and weight. I don’t want Letter to collect or store account credentials itself while it’s still early. Users already have accounts in Settings → Online Accounts, shared with Calendar and Contacts; reusing that felt safer and lighter than inventing a second login flow and holding secrets inside the client. Same idea for EDS/Camel: lean on what’s already there on the desktop instead of rebuilding the stack.
I’m not claiming Letter is a Core app. If GOA maintainers prefer third-party mail clients to stay clear of GOA, I’m happy to hear what the preferred path is for something like this.
Anyway, I do plan to add proper in-app account setup with its own libraries/stack, decoupled from GOA if the app grows.
Also a quick fact update: there’s a Flatpak bundle on the GitHub releases now (still not on Flathub); I’m iterating on host dependency detection and Microsoft 365 bits from early tester feedback.
if you could not depend on GOA, we could also use your app on KDE which is missing any good email app (I’m using evolution). It would also help to add advanced corporate features like Graph API access to email along with Calendars & Contacts, and Intune conditional access integration (like done in abraunegg onedrive app or Evolution itself)
.
. I understand how GOA is intended.