Beste Mail-Clients für Entwickler 2026: TUI, skriptbar, ehr…

Der Zyklus 2025-2026 hat sich leise zu einem starken Jahr für Terminal-Mail entwickelt. aerc nahm den Schwung von FOSDEM 2025 mit einer Go-1.23-Basis mit; Himalaya erreichte im Februar 2026 v1.2.0; NeoMutt setzt seine monatliche Kadenz fort, das jüngste Release datiert vom 2026-05-04; und Thunderbird Monthly Release 145 hat nativen Support für Exchange Web Services hinzugefügt — die letzte Lücke für Entwickler in Microsoft-365-Umgebungen ist damit geschlossen. Ergebnis: 2026 kann ein Entwickler unter Linux, Mac oder Windows einen echten tastaturgetriebenen, plain-text-first, skriptbaren Mail-Client haben, ohne einen Cent zu zahlen. Hier sind die sieben, die wir tatsächlich einsetzen würden — mit explizit ausgewiesenen Kompromissen.

Wie wir ausgewählt haben

Wir haben jeden Client gegen einen entwicklertypischen Workflow getestet: ein IMAP-Konto mit einigen tausend archivierten Threads, ein JMAP-Konto bei Fastmail, ein Maildir für private Post und ein Microsoft-365-Postfach für Kundenarbeit. Harte Kriterien: vim- oder vim-artige Tastenbelegung, einsehbare Rohquelle (Header, MIME-Teile), Code-Block- und Patch-Rendering, Protokollzugriff (IMAP/JMAP/Maildir ohne Webmail) und Skriptbarkeit — entweder ex-Command, Plugin-API oder shell-pipebare CLI.

Wir haben jeden Client ausgeschlossen, dessen Architektur E-Mails zwingend über proprietäre Server laufen lässt (Hey, Superhuman). Wir haben Consumer-Clients ausgeschlossen, die Nachrichtenquelle oder MIME-Baum von Anhängen nicht offenlegen (die meisten iOS-first-Apps).

Die Verdiktkriterien, die uns wichtig waren:

Tastenbelegung. Vim/Emacs-Stil oder darauf umbelegbar. Maus-Rückfall im Triage inakzeptabel.
Plain Text zuerst. HTML wird auf Wunsch gerendert, nicht per Default; mit einem Tastendruck in die Quellansicht.
Protokoll-nativ. IMAP, JMAP, Maildir, SMTP — keine vendor-spezifische Abstraktion.
Skriptbar. Lesen/Senden/Suchen aus einem Skript oder einer Shell-Pipeline; keine reinen UI-Workflows.
Git- und patch-freundlich. Inline-Diff-Rendering, Anhang in git am pipebar, oder beides.
Ehrliche Lizenz. Open Source bevorzugt, kommerziell akzeptiert, sofern die Lizenz nicht nutzerfeindlich ist.

1. aerc — TUI für den anspruchsvollen Hacker

Ideal für: Entwickler, die in tmux leben und git-bewusstes Mail wollen.

aerc ist ein Terminal-Mail-Client, geschrieben in Go (92,5 % des Codes) unter MIT-Lizenz. Er bietet vim-artige Tastenbelegung, ein ex-Command-System, ein eingebettetes Terminal zum Verfassen von E-Mails neben anderen Threads oder git-Repos, Inline-Rendering von Diffs und Patches, und unterstützt IMAP-, JMAP-, Maildir-, Notmuch- und Mbox-Backends. Das Projekt beschreibt sich selbst als «perfekt für den anspruchsvollen Hacker» — und nach unseren Tests hält diese Beschreibung. (Quelle: aerc-mail.org, abgerufen am 2026-05-27.)

Die entscheidenden Funktionen für einen Entwickler-Workflow sind konkret:

Eingebettetes Terminal-Compose. Öffnen Sie einen neuen Tab mit einer Shell und einem git-Repo zur Hand, während Sie eine Antwort schreiben. Kein Alt-Tab-Tanz.
Patch-Handling. Erstklassiger Support für git send-email und git am. Inline-Diff-Hervorhebung in Patches ohne Konfiguration.
HTML auf Anforderung. HTML-Rendering ist via Filter opt-in (w3m oder der eingebaute Terminal-Browser). Default ist Plain Text oder formatierter Plain Text — genau der richtige Default für codelastige Threads.
ex-Commands. Alles, was Sie interaktiv tun, lässt sich skripten — :filter, :pipe, :read greifen mit Shell-Tools ineinander.

Der Kompromiss, den Sie sofort akzeptieren müssen: aerc nimmt Beiträge per Mailingliste entgegen (der GitHub-Mirror ist nur lesbar), die Konfiguration ist TOML-lastig, und es gibt keine GUI-Rückfallschiene. Wenn Sie je Pair-Programming auf Mail-Triage machen, muss Ihr Gegenüber ebenfalls Terminal-Nutzer sein.

Ideal für: Linux/macOS-Power-User, die Mail neben git machen, denen Patch-Workflows nativ anfühlen sollen und die das TUI-Commitment akzeptieren.

Überspringen, wenn: Sie eine GUI für HTML-lastige Newsletter-Triage brauchen oder ein Setup mit Nicht-Terminal-Kollegen teilen.

2. NeoMutt — der Terminal-Klassiker, modernisiert

Ideal für: Mutt-Veteranen, die gepflegte, moderne Patches wollen, ohne ihr Muskelgedächtnis aufzugeben.

NeoMutt ist ein Fork von Mutt, der «viele alte Mutt-Patches» aktualisiert und dokumentiert bündelt — das Sidebar-Patch ist das kanonische Beispiel, das später vom Mutt-Upstream übernommen wurde. Das Projekt erscheint in monatlicher Kadenz; das aktuellste Release datiert vom 2026-05-04. (Quelle: neomutt.org, abgerufen am 2026-05-27.)

Wer schon Mutt-Nutzer ist, hat mit NeoMutt das schmerzlose Upgrade: Ihre .muttrc läuft im Wesentlichen weiter, das Binary ist ein sauberer Drop-in, und die Ergänzungen (Sidebar, notmuch-Integration, Farbverbesserungen) sind genau die Patches, die Sie sonst selbst eingespielt hätten. Wer 2026 frisch in Terminal-Mail einsteigt, fährt mit aerc besser; NeoMutt ist die richtige Wahl, wenn Sie eine bestehende Konfiguration übernehmen oder in einer Umgebung arbeiten, die sich vor Jahren auf Mutt standardisiert hat.

Was NeoMutt besser kann als aerc, konkret: die Flexibilität von Makros und Bindings, notmuch als erstklassiges Backend und ein 25 Jahre alter Community-Korpus (suchen Sie «muttrc github» — tausende Dotfiles sind öffentlich). Was aerc besser kann: die Defaults, das HTML-Rendering, das eingebettete Compose, die ex-Command-Grammatik.

Ideal für: Mutt-Bestandsnutzer, notmuch-Nutzer, Leute, die ihre Config gern feilen, bis alles genau sitzt.

Überspringen, wenn: Sie ohne bestehende muttrc neu anfangen — aerc braucht weniger Anlauf.

3. Himalaya — Rust-CLI, JSON-pipebar

Ideal für: Entwickler, die Mail aus xargs, einem Skript oder einem anderen TUI erreichbar machen wollen.

Himalaya ist ein Kommandozeilen-Mail-Client in Rust (99,2 % Rust laut Repository). Er unterstützt IMAP-, JMAP-, SMTP-, Maildir- und m2dir-Backends, bietet einen JSON-Ausgabemodus und steht unter AGPL-3.0. Das aktuelle stabile Release ist v1.2.0, veröffentlicht am 19. Februar 2026. (Quelle: github.com/soywod/himalaya, abgerufen am 2026-05-27.)

Himalaya ist kein TUI im aerc/NeoMutt-Sinn — es ist ein Kommando. Sie rufen himalaya envelope list auf, pipen das JSON in jq, hängen das Ergebnis in eine Shell-Funktion oder ein Neovim-Plugin. Die Authentifizierungsfläche ist ungewöhnlich breit: anonymous, login, plain, OAuth bearer, XOAUTH2, SCRAM-SHA-256, plus HTTP-basic und -bearer für JMAP. Die TOML-Konfiguration unterstützt mehrere Konten in einer Datei, und die Discovery-Mechanismen (PACC, Thunderbird-Autokonfiguration, RFC-6186-SRV) sorgen dafür, dass die Ersteinrichtung selten manuell ausfallen muss.

Ehrliche Einordnung: Himalaya ist fast immer eine Ergänzung, kein Einzel-Client. Die meisten Entwickler paaren es mit aerc oder NeoMutt fürs Lesen und nutzen Himalaya für die skript-getriebenen Teile — Bulk-Versand, programmatische Suche, CI/CD-Benachrichtigungen. Als «lies die Tagesneuigkeiten in 30 Sekunden»-Werkzeug schlägt die JSON-Pipeline das Öffnen einer GUI.

Brauchen Sie einen Auffrischer zu Inbox-Triage, bevor das alles wirkt? Mehrere E-Mail-Konten verwalten deckt die Grundlagen ab.

Ideal für: Shell-lastige Workflows, skriptbare Automatisierung, Neovim-Nutzer, die Mail-Primitive in ihrem Editor wollen.

Überspringen, wenn: Sie zum Lesen, Schreiben und Suchen in einer App leben wollen.

4. Thunderbird — die quelloffene GUI-Rückfallschiene, die endlich aufgeholt hat

Ideal für: Entwickler, die eine GUI brauchen, Open Source wollen und ein Microsoft-365-Postfach im Stack haben.

Thunderbird wird von der MZLA Technologies Corporation (einer Mozilla-Tochter) unter MPL 2.0 gepflegt. Es läuft unter Windows, macOS und Linux und liefert in zwei Kanälen: dem 128 ESR (das aktuell stabile Extended-Support-Release) und dem Monthly Release. Monthly Release 145 hat Ende 2025 nativen Support für Exchange Web Services ergänzt. JMAP-Support gibt es seit Thunderbird 115 (2023). (Quelle: Thunderbird-Blog, Community Office Hours Dezember 2025.)

Für Entwickler, die TUI-Clients ausprobiert und wieder abgesprungen sind, ist Thunderbird 2026 der richtige Einstiegspunkt. Die Extension-API ist real (Thunderbird-Erweiterungen auf MozillaAddons suchen — aktives Ökosystem), die Quellansicht einer Nachricht ist einen Tastendruck entfernt (Ctrl+U), und die Protokollabdeckung ist nun wirklich vollständig: IMAP, POP3, JMAP und EWS (Exchange) in einer Binary.

Zwei spezifisch entwicklerrelevante Vorteile:

Filter sind in einem nützlichen Maße skriptbar. Kombiniert mit der Quellansicht bauen Sie ein Triage-System, das die Gmail-Filter-UI in reiner Lokalkonfiguration annähert.
Exchange-Support ohne Outlook. Wenn Ihr Tagesgeschäft auf Microsoft 365 läuft, ist Thunderbird 145 Monthly die erste glaubwürdige Nicht-Outlook-GUI-Option, die Exchange nativ handhabt (statt mit fragiler IMAP-Brücke).

Der Kompromiss: Thunderbird ist kein TUI. Es ist eine Desktop-GUI mit entwicklerfreundlichen Knochen, kein entwicklerorientierter Client. Der Start ist langsamer als bei aerc, das Tastenbelegungssystem ist umbelegbar, aber die Defaults sind GUI-geprägt, und der Suchindex kann bei Multi-Konto-Setups jenseits 50 GB nachhinken.

Ideal für: GUI-Anforderung, Microsoft-365-Umgebungen, Open-Source-Präferenz, plattformübergreifende Teams.

Überspringen, wenn: Sie unter 100 ms Startzeit und einen reinen Tastatur-Workflow wollen — dann lieber aerc oder NeoMutt.

5. Mailspring — Electron, native Sync-Engine, MIT-lizenziert

Ideal für: Entwickler, die eine polierte GUI ohne Thunderbird-Startverzögerung wollen und mit Electron leben können.

Mailspring ist ein Desktop-Mail-Client mit einer nativen C++-Sync-Engine und einer Electron-UI. Er läuft unter macOS, Windows und Linux, unterstützt Gmail, iCloud, Office 365, Fastmail, Outlook.com, Yahoo und generisches IMAP/SMTP und ist vollständig quelloffen unter MIT-Lizenz. Der Pro-Tarif kostet 8 $/Monat und ergänzt Lesebestätigungen, Link-Tracking, geplanten Versand, Vorlagen und Kontaktanreicherung. (Quelle: getmailspring.com, abgerufen am 2026-05-27.)

Mailspring sitzt in einer kuriosen Nische: zu poliert für die Terminal-Fraktion, zu schlicht für Nutzer, die Sparks Kollaborationsschicht wollen. Für Entwickler, die eine kostenlose, aktiv gepflegte GUI suchen, die im Free-Tier keine Funktionen hinter Paywalls verbirgt, ist es eine vernünftige Wahl. Die native C++-Sync-Engine ist schneller als die JavaScript-Backends, die die meisten Electron-Clients mitbringen.

Die ehrlichen Grenzen: Es gibt keine öffentliche Plugin-API, die so dokumentiert wäre wie die von Thunderbird. Der Code ist hackbar (MIT, forken Sie ihn), aber Sie sind nicht die Zielgruppe der bestehenden Erweiterbarkeitsstory. Wenn «skriptbar» wichtiger ist als «polierte GUI», lassen Sie Mailspring aus.

Ideal für: Plattformübergreifende Entwickler, die eine kostenlose GUI mit Unified Inbox wollen und kein Scripting brauchen.

Überspringen, wenn: Sie eine dokumentierte Plugin-API wollen oder lieber für Mimestreams Gmail-nativen Schliff auf dem Mac bezahlen.

6. Apple Mail — mit AppleScript und Shortcuts

Ideal für: Mac-only-Entwickler, die lieber den Standard-Client automatisieren als eine weitere App installieren.

Apple Mail unter macOS Sequoia 15.4 (März 2025) hat Apple-Intelligence-Posteingangskategorien und On-Device-Zusammenfassungen erhalten. Für Entwicklungszwecke ist die relevantere Funktion die langjährig vorhandene AppleScript- und Shortcuts-Fläche: Mail.app stellt ein Scripting-Dictionary bereit, mit dem Sie Inbox-Automatisierungen, Anhang-Exporteure und Ablageregeln in shell-aufrufbarem AppleScript bauen — ohne Drittanbieter-Tools.

Apple Mail ist kein entwicklerorientierter Client. Es ist ein Standard-Client mit einer Automatisierungsfläche, die die meisten Leute vergessen. Das AppleScript-Dictionary deckt Nachrichten, Konten, Postfächer, Signaturen und Regeln ab. Shortcuts unter macOS (seit Monterey) legt eine klick-und-bau-Oberfläche auf dieselben Aktionen.

Wofür das nützlich ist: routinierte Inbox-Automatisierungen, die kein eigenes Tool rechtfertigen. Automatisches Speichern von Anhängen bekannter Absender in einen Projektordner, Archivierung von Threads nach Ende eines Kalendertermins, Sortierung von Nachrichten einer bestimmten Domain in einen getaggten Ordner. Nichts Bahnbrechendes, aber es liegt dem OS bei und kostet nichts.

Wofür es nicht nützlich ist: jedes plattformübergreifende Team, alles, was auf einem Server laufen muss, alles, was patch-freundliches Verfassen braucht. Die Quellansicht von Apple Mail existiert (Cmd+Option+U), ist aber umständlich, und das HTML-Rendering ist meinungsstark.

Ideal für: Mac-only-Entwickler, leichte Automatisierung, «ich will keine weitere App»-Haltung.

Überspringen, wenn: Sie zwischen Plattformen wechseln oder echtes Tastatur-Triage in voller Geschwindigkeit brauchen.

7. Spark — Team-Triage-Layer, kein Entwickler-Client

Ideal für: Kleine Teams, bei denen ein oder zwei Mitglieder zufällig Entwickler sind und der Rest nicht.

Spark ist ein polierter plattformübergreifender Mail-Client (Mac, Windows, iOS, Android) mit geteilten Postfächern, Thread-Kommentaren und KI-gestützten Antwortentwürfen. Es ist kein entwicklerorientierter Client. Wir nehmen ihn auf, weil bei team-geformten Workflows — wo der Entwickler eine Rolle neben Support, Vertrieb und Operations ist — Sparks Kollaborationsschicht der richtige Kompromiss ist.

Der Kompromiss, den Spark erzwingt, ist die serverseitige Verarbeitung: Ihre Mails laufen durch Readdles Infrastruktur, um die intelligenten Funktionen zu speisen. Für die meisten Entwickler ist das als Hauptclient inakzeptabel; für Teams, bei denen die Alternative ein fragmentierter Slack-plus-Gmail-Eintopf ist, ist es eine vertretbare Wahl.

Wir nehmen Spark in die Liste streng dafür, dass ein Entwickler, der «worauf soll mein Team sich standardisieren» evaluiert, die Option abgedeckt findet. Als persönlicher Entwickler-Client sprechen die fehlende Plain-Text-Quellansicht, das Fehlen von Scripting-Hooks und das Server-Routing alle dagegen.

Müde vom Newsletter-Lärm in einem dieser Clients? Leave Me Alone kümmert sich providerübergreifend sauber um das Massen-Abmelden — siehe unseren Vergleich von Abmelde-Tools.

Ideal für: Kleine, fachlich gemischte Teams; Gründer, die Ops neben Engineering führen.

Überspringen, wenn: Sie einen entwicklerorientierten Client wollen oder Mail nicht über Drittanbieter-Server laufen lassen dürfen.

Vergleich auf einen Blick

Die sieben Clients tauschen auf drei Achsen: GUI vs TUI, Tiefe der Skriptbarkeit und Protokollbreite. aerc und Himalaya sind am skriptbarsten; Thunderbird und Mailspring sind die vollständigsten GUIs; NeoMutt ist am konfigurierbarsten; Apple Mail und Spark sitzen am «Automatisierung als Nachgedanke»-Ende. Lizenzseitig sind sechs der sieben quelloffen — Spark ist die Ausnahme.

Client	Typ	Lizenz	Protokolle	Stärkstes Signal
aerc	TUI (Go)	MIT	IMAP, JMAP, Maildir, Notmuch, Mbox	Eingebettetes Compose, Patch-Rendering
NeoMutt	TUI (C)	GPL-2.0+	IMAP, POP, SMTP, Maildir, Notmuch	Mutt-kompatibel, tiefe Konfig
Himalaya	CLI (Rust)	AGPL-3.0	IMAP, JMAP, SMTP, Maildir	JSON-pipebar, skriptbar
Thunderbird	GUI (XUL/Rust)	MPL 2.0	IMAP, POP, JMAP, EWS	GUI + Extension-API + EWS
Mailspring	GUI (Electron + C++)	MIT	IMAP, SMTP (Gmail/O365/Fastmail/…)	Schnelle Sync, gefüllter Free-Tier
Apple Mail	GUI (Cocoa)	proprietär (kostenlos mit macOS)	IMAP, POP, Exchange, iCloud	AppleScript + Shortcuts
Spark	GUI (proprietär)	proprietär	IMAP, OAuth (Gmail, O365)	Team-Triage, geteilter Posteingang

Wenn Sie sich nicht auf einen einzigen Client festlegen wollen, ist Mailbird die polierte plattformübergreifende Option für alle, die eine GUI ohne entwicklerorientierte Komplexität wollen — er ist für Windows-Wissensarbeiter gebaut, nicht für Entwickler. Gut zu wissen, dass er existiert; nicht zur Empfehlung als primärer Entwicklerclient geeignet.

Warum nicht Hey, Superhuman oder Mailbird

Hey von Basecamp leitet alles über seine eigene Infrastruktur, ohne IMAP-Notausgang. Superhuman ist ein 30-$-im-Monat-Gmail-Frontend ohne Scripting, ohne Quellansicht, ohne IDE-Integration. Mailbird ist eine Windows-first-GUI für Wissensarbeiter, nicht für Entwickler — kein Plain-Text-Quellumschalter, keine Plugin-API, kein Terminalmodus. Alle drei sind sinnvolle Wahl für Nicht-Entwickler; keiner erfüllt das Entwickler-Basismaß.

Hey von Basecamp. Hey verschließt IMAP und SMTP bewusst — die Architektur lautet «Ihre Mail lebt in Hey, Punkt.» Für Basecamps Publikum ist das ein Feature. Für einen Entwickler, der Bulk-Export skripten, mit einem git-Workflow integrieren oder schlicht ohne Reimport den Client wechseln will, ist das ein No-Go. Hey hat das 2026 nicht geändert.

Superhuman. 30 $/Monat für einen schnellen Gmail-Wrapper sind eine völlig vertretbare Wahl, wenn Ihre einzige Metrik die Geschwindigkeit-zu-null in einem Gmail-Konto ist. Das Produkt hat keine Scripting-Ebene, kein Plugin-System, keine Quellansicht und keine entwicklerrelevante Integration. Es als «Mail-Client für Entwickler» zu bezeichnen, verlangt kreative Definitionen von «Entwickler».

Mailbird. Mailbird ist ein starker Windows-Mail-Client für Wissensarbeiter — Unified Inbox, App-Panel mit angedocktem Slack und WhatsApp, polierte Tastenkürzel. Es ist explizit kein Entwicklerclient: keine Plain-Text-Quellansicht per Default, keine Plugin-API für eigene Logik, kein Terminal/TUI-Modus. Wir empfehlen Mailbird in unserem Windows-Überblick und Mac-Überblick für den allgemeinen Einsatz; in einer entwicklerorientierten Liste gehört es nicht.

Wenn keiner dieser Clients passt

Wenn Ihr Workflow primär serverseitige Automatisierung ist (CI/CD-Mail, Alert-Routing, transaktionaler Versand), überspringen Sie Clients ganz und greifen zur Bibliothek: imaplib + email in Python, lettre in Rust, nodemailer in Node, net/mail in Go. Wenn iOS Ihr Primärgerät ist, funktioniert keine der entwicklerfreundlichen Optionen — fallen Sie auf Apple Mail zurück und verlagern Sie Scripting auf Ihren Mac oder einen Server.

Serverseitige Use Cases. Lesen von eingehenden Webhook-Bestätigungen in CI, Alert-Deduplizierung, transaktionaler Versand — keiner braucht einen Client. Nutzen Sie eine Bibliothek, schreiben Sie einen kleinen Daemon, loggen Sie in Ihren bestehenden Observability-Stack.

iOS-first-Entwickler. TUI-Clients existieren unter iOS nicht. Realistische Optionen sind Apple Mail (mit Shortcuts auf dem Gerät), Spark (serverseitig, akzeptieren Sie den Kompromiss) oder Gmail Web. Das entwicklerorientierte Tooling fehlt.

Sie wollen polierte GUI UND TUI in einer App. Existiert 2026 nicht. Am nächsten kommt das parallele Betreiben von Thunderbird + aerc auf dasselbe IMAP-Konto — sie kollidieren nicht, sie lesen denselben serverseitigen Zustand.

Müssen Sie drei oder vier Konten gleichzeitig handhaben, ohne den Kontext zu verlieren? Unser Leitfaden zum Verwalten mehrerer Mail-Konten führt durch die Unified-Inbox-Muster.

Verwandte Lektüre:

Alexis Dollé

Gründer & Chefredakteur

Alexis Dollé, seit 10+ Jahren E-Mail-Experte und langjähriger Terminal-Nutzer. Gründer von Email Tools. Ich teste jeden Client an einem echten Entwickler-Workflow — IMAP + JMAP + Maildir, git send-email und ein Microsoft-365-Postfach für Kundenarbeit — und schreibe darüber so, wie ich es einem Kollegen erklären würde. Kein Marketing-Geschwurbel, keine gesponserten Rankings, jede Aussage belegt.

Häufige Fragen

Was ist 2026 der beste Mail-Client für Entwickler?: aerc

aerc, wenn Sie im Terminal leben. Vim-Tastenbelegung, eingebettetes Terminal zum Verfassen neben git, erstklassiges Rendering von Patches und Diffs, JMAP-Support. Als GUI-Rückfallschiene, die den Entwicklerinstinkt respektiert, ist Thunderbird mit seiner Extension-API die sicherste zweite Wahl.

Ist mutt noch relevant, oder sollte ich auf aerc umsteigen?: NeoMutt ist aktuell

NeoMutt wird weiterhin aktiv gepflegt — das Release vom 2026-05-04 ist aktuell — und bleibt die richtige Wahl, wenn Ihr Muskelgedächtnis schon in mutt sitzt. aerc ist 2026 die bessere Wahl, wenn Sie bei null anfangen: bessere Defaults für HTML-Rendering, eingebettete Terminal-Komposition und eine sauberere ex-Command-Grammatik.

Kann ich Himalaya als einzigen Mail-Client nutzen?: meist als Ergänzung

Wenn Ihr Workflow ein reines CLI verträgt, ja. Himalaya v1.2.0 (veröffentlicht am 19. Februar 2026) ist für den täglichen Einsatz mit IMAP, JMAP, SMTP und Maildir stabil. Es passt gut mit notmuch oder aerc als Lese-Layer. Für die meisten Entwickler ist es eine Ergänzung, kein Ersatz.

Unterstützt Thunderbird inzwischen JMAP?: ja, seit 115

Ja — JMAP wurde in Thunderbird 115 (2023) eingeführt und ist im 128 ESR sowie im Monthly-Release-Kanal weiterhin verfügbar. Thunderbird 145 Monthly hat natives Exchange Web Services hinzugefügt. Als kostenloser, quelloffener Client, der IMAP, JMAP und jetzt EWS abdeckt, ist Thunderbird die vollständigste GUI-Option.

Warum nicht Hey, Superhuman oder Spark für Entwickler?: die Basics fehlen

Hey von Basecamp ist geschlossen und meinungsstark; alles läuft durch Hey-eigene Infrastruktur, ohne IMAP-Notausgang. Superhuman ist ein Gmail-Frontend ohne IDE- oder git-Integration. Spark ist für Team-Triage in Ordnung, bietet aber keine Plain-Text-Quellansicht, keine skriptbaren Hooks und leitet Mails über Readdles Server. Entwickler-relevante Funktionen sind bei allen dreien minimal.

Ist Mailspring skriptbar?: keine dokumentierte Plugin-API

Mailspring ist quelloffen unter MIT-Lizenz und nutzt eine native C++-Sync-Engine mit einer Electron-UI. Der Code ist hackbar, aber es gibt keine dokumentierte öffentliche Plugin-API, wie Thunderbird sie bietet. Für «skriptbar» sind aerc, Himalaya oder NeoMutt besser geeignet — jedes ist um Konfiguration als Code herum gebaut.

Quellen