Wer E-Mails bisher automatisieren wollte, musste sich mit IMAP-Hacks, App-Passwörtern und fragilen Skripten herumschlagen. Himalaya 2.0 räumt damit auf - und bringt Gmail und Microsoft 365 direkt in die Shell.
Photo: Radowan Nakif Rehan / UnsplashWas Himalaya ist - und warum Version 2.0 ein Einschnitt ist
Himalaya ist ein in Rust geschriebener E-Mail-Client für die Kommandozeile. Das Projekt bündelt mehrere Backends - IMAP, SMTP, JMAP, Maildir und m2dir - hinter einer einheitlichen Befehlsschnittstelle. Die Zielgruppe sind Entwickler und Systemadministratoren, die E-Mail-Funktionen aus Skripten, Terminal-Workflows oder eigenen Frontends heraus nutzen wollen.
Bis Version 1.x ließen sich Gmail und Outlook zwar bereits über IMAP und SMTP einbinden. Das war funktional, aber eben auch limitiert: Die proprietären Funktionen der großen Anbieter - Gmail-Labels, Thread-Verwaltung, Graph-spezifische Ordneroperationen - blieben außen vor. Version 2.0 schließt diese Lücke.
Native API-Anbindung: Gmail REST und Microsoft Graph
Himalaya 2.0.0 unterstützt Gmail über die Gmail REST API sowie Outlook- und Microsoft-365-Postfächer über Microsoft Graph. Das ist mehr als ein technisches Detail. Wer bisher IMAP für Gmail nutzte, arbeitete an der eigentlichen Datenstruktur des Dienstes vorbei. Jetzt nicht mehr.
Die Gmail-Integration deckt Profile, Labels, Nachrichten, Anhänge, Entwürfe, Threads, den Nachrichtenverlauf (History) und Einstellungen ab. Der Microsoft-Graph-Backend bietet Zugriff auf Profile, Mail-Ordner, Nachrichten und Anhänge. Beide Backends authentifizieren sich über einen OAuth-2.0-Bearer-Token - kein App-Passwort, kein Workaround.
Für protokoll- oder anbieterspezifische Funktionen stellt Himalaya zusätzliche Subcommands bereit, etwa gmail und msgraph. Die universellen Mail-Befehle bleiben dabei erhalten - wer heute IMAP nutzt und morgen auf die Graph-API wechselt, muss seine Skripte nicht von Grund auf umschreiben.
Breaking Change beachten: In Version 2.0 startet himalaya ohne Subcommand nicht mehr die Nachrichtenübersicht des Standardkontos, sondern den Setup-Wizard. Bestehende Skripte und Aliase sollten vor dem Upgrade geprüft werden.
Der Setup-Wizard: Deutlich smarter als zuvor
Die Entwickler haben den Einrichtungsassistenten grundlegend überarbeitet. Der Wizard erkennt nun automatisch verfügbare Dienste - IMAP/SMTP, JMAP, Gmail und Microsoft Graph - und fragt in einem separaten Schritt nach der passenden Anmeldemethode.
Der Wizard befüllt Postfach-Aliase automatisch vom Server, sodass ein generiertes Konto sofort mit einem funktionierenden Posteingang und bekannten Zielen wie Gesendet, Entwürfe und Papierkorb arbeitet - ohne manuelle Nachbearbeitung der Konfigurationsdatei. JMAP liest die Postfachrollen live über RFC 8621, Gmail und Microsoft Graph mappen ihre festen System-Label-IDs.
Die erzeugte Konfiguration gibt der Wizard als TOML auf der Standardausgabe aus. Wer sie dauerhaft speichern will, leitet sie selbst in die Konfigurationsdatei um - etwa mit himalaya > ~/.config/himalaya/config.toml. Das mag auf den ersten Blick umständlich wirken, ist aber konsequent im Sinne von Composability: Die Ausgabe lässt sich filtern, versionieren oder in ein Deployment-Skript einbetten.
JSON Schema: Typsichere Automatisierung
Das vielleicht unterschätzte Highlight von Version 2.0 ist der neue json-schema-Befehl. Er schreibt für jeden Befehl mit strukturierter Ausgabe eine eigene JSON-Schema-Datei. Andere Programme können damit die JSON-Ausgabe von Himalaya validieren und typisierte Datenmodelle generieren - etwa in Python, Rust oder TypeScript.
Der json-schema-Befehl erzeugt pro strukturiertem Ausgabebefehl eine Datei im Format himalaya-<cmd>-<subcmd>.json; es werden nur die Schemas für kompilierte Backends ausgegeben.
Das ist relevant für alle, die Himalaya als Baustein in größeren Automatisierungspipelines einsetzen: Monitoring-Skripte, die auf eingehende Alerts reagieren; CI/CD-Workflows, die Benachrichtigungen versenden; oder Reporting-Tools, die E-Mail-Daten strukturiert weiterverarbeiten. Mit einem validierten JSON-Schema wird aus einem Kommandozeilentool ein verlässliches Dateninterface.
Vorkompilierte Binaries sind über das offizielle Installationsskript verfügbar: curl -sSL https://raw.githubusercontent.com/pimalaya/himalaya/master/install.sh | sh
Einfach himalaya ohne Argumente aufrufen. Der Wizard erkennt den Provider automatisch und führt durch OAuth-2.0-Einrichtung oder IMAP/SMTP-Konfiguration.
Die TOML-Ausgabe des Wizards in die Konfigurationsdatei umleiten: himalaya > ~/.config/himalaya/config.toml
Mit himalaya json-schema <VERZEICHNIS> Schema-Dateien für alle kompilierten Backends erzeugen – Grundlage für typsichere Automatisierungsskripte.
Jeden Befehl mit --output json aufrufen und die Ausgabe per jq oder direkt in eigene Tools weiterverarbeiten. Kombination mit cron oder CI-Systemen ist problemlos möglich.
IMAP-Hierarchie vereinfacht, MIME standardisiert
Neben den großen API-Neuerungen hat das Team auch die IMAP-Befehlshierarchie überarbeitet. Sie orientiert sich nun stärker an der flachen Befehlsliste des Protokolls: Verben wie select, create, append, store und fetch sind direkt verfügbar, ohne tief verschachtelte Untergruppen.
Für komplexere Nachrichtenentwürfe setzt Himalaya künftig auf externe Programme, die MIME-Nachrichten erzeugen und deren Ausgabe an messages send oder messages add übergeben. Das ist ein klares Bekenntnis zur Unix-Philosophie: Ein Tool, eine Aufgabe - und saubere Schnittstellen nach außen.
Einordnung: Für wen lohnt sich der Umstieg?
Himalaya ist kein Thunderbird-Ersatz. Das Tool richtet sich an Entwickler und DevOps-Teams, die E-Mail programmatisch behandeln wollen - als Datenquelle, als Benachrichtigungskanal oder als Teil automatisierter Workflows. Die native Anbindung an Gmail REST und Microsoft Graph macht es erstmals möglich, die vollen Möglichkeiten dieser Plattformen aus der Shell heraus zu nutzen, ohne auf proprietäre SDKs oder Browser-basierte Interfaces angewiesen zu sein.
Wer heute noch IMAP-Skripte gegen Gmail oder Outlook betreibt und dabei auf Labels, Threads oder Graph-spezifische Ordnerstrukturen verzichtet, sollte Version 2.0 ernsthaft evaluieren. Der Aufwand für die Migration ist überschaubar - der Gewinn an Ausdrucksstärke und Zuverlässigkeit erheblich.
Kann ich Himalaya 2.0 parallel zu meinem bestehenden E-Mail-Client nutzen?
Ja. Himalaya greift über die offiziellen APIs auf die Postfächer zu und verändert keine lokalen Daten, sofern kein Maildir-Backend verwendet wird. IMAP- und Graph-Backends arbeiten auf den Remote-Daten des Servers.
Welche Authentifizierungsmethoden unterstützt Version 2.0?
Beide neuen Backends – Gmail REST und Microsoft Graph – authentifizieren über OAuth 2.0 Bearer Token. Für IMAP und SMTP stehen weiterhin SASL-Mechanismen wie PLAIN und LOGIN zur Verfügung. Credentials werden im System-Keyring gespeichert, nicht im Klartext in der Konfigurationsdatei.
Ist Himalaya für den Einsatz auf Servern ohne Browser geeignet?
Das hängt vom OAuth-2.0-Flow ab. Browser-basierte Redirects funktionieren auf headless Servern nicht direkt. Für solche Szenarien empfiehlt sich die Nutzung eines OAuth-2.0-Proxys oder die Vorab-Generierung von Tokens auf einem Rechner mit Browser.
Wo finde ich das Projekt und die Releases?
Das Projekt liegt auf GitHub unter pimalaya/himalaya. Version 2.0.0 ist bereits in Arch Linux (extra/himalaya) und über Homebrew verfügbar.





