AmberChest 2.0: neuer Name, reparierte macOS-App und Mails, die draußen bleiben

Mit Version 2.0.0 heißt Mail Archiver jetzt AmberChest. Der Name kollidierte mit einem älteren Projekt, die Suche nach dem einen fand das andere. Dazu kam eine macOS-App, die sich auf Apple-Silicon-Macs gar nicht öffnen ließ, und eine neue Funktion, mit der man Mails dauerhaft aus dem Archiv werfen kann. Vorab das Wichtigste für alle, die schon eine Installation haben.

Warum der neue Name

Die Begründung: Der alte Name kollidierte mit s1t5/mail-archiver, das sechzehn Monate älter ist, rund zweitausend Sterne hat und denselben Repository-Namen für dieselbe Aufgabe trägt. Wer nach einem suchte, fand das andere, und dieses Projekt wirkte wie eine Nachahmung. Besser, das früh zu ändern als bei tausend Nutzern. Die beiden Werkzeuge sind verschieden: Das andere speichert Mails in einer PostgreSQL-Datenbank und zielt auf Unternehmen mit Mehrbenutzerzugang, OIDC und Audit-Log. AmberChest schreibt eine .eml je Nachricht in einen Ordnerbaum, den man auch ohne das Programm lesen kann, und zielt auf den eigenen Rechner.

Update von Mail Archiver

Beim ersten Start nach dem Update passieren zwei Dinge von selbst:

• Konfiguration und Index ziehen mit: Das Verzeichnis wird umbenannt (MailArchiver zu AmberChest unter macOS und Windows, mail-archiver zu amberchest unter Linux), aber nur, wenn das neue noch nicht existiert. Das Archiv bleibt dort, wo es ist; der Pfad steht in der Konfiguration. Nur eine Neuinstallation bekommt den neuen Standard ~/AmberChest Archive.
• Alte Umgebungsvariablen funktionieren weiter: Ein Container mit MAIL_ARCHIVER_* startet, die Werte werden nach AMBERCHEST_* übernommen, und das Protokoll sagt, welche. Die alten Namen sollen in einer künftigen Version aufhören zu funktionieren.

Von Hand zu ändern ist Folgendes:

Docker-Image        ghcr.io/sphings79/mail-archiver  ->  ghcr.io/sphings79/amberchest
macOS-App           Mail Archiver.app                ->  AmberChest.app
MQTT-Basis-Topic    mailarchiver                     ->  amberchest (neue Entitäten, alte löschen)
HA-Integration      Domain mail_archiver             ->  amberchest, neu installieren
HA-Add-on           Slug mail_archiver               ->  amberchest, neu installieren

Die alten Repository-Adressen leiten weiter, bestehende Links und Klone funktionieren also.

Die macOS-App ließ sich nicht öffnen

Davor, in 1.2.1, war die macOS-App ein eigenes Thema: „Mail Archiver is damaged and cannot be opened“. Jedes macOS-Build bis dahin wurde von einem Apple-Silicon-Mac abgelehnt, ohne Möglichkeit, die Warnung wegzuklicken. Das Packaging war mit identity: null konfiguriert, was in electron-builder nicht „ad-hoc signieren“ bedeutet, sondern „nicht signieren“. Die App behielt die Signatur, die Electron selbst mitbringt, während das Packaging die ausführbare Datei umbenannte und die Ressourcen des Bundles austauschte. Heraus kam ein Bundle, dessen Signatur nicht mehr zu seinem Inhalt passte, was macOS als Beschädigung liest. Seitdem wird das fertige Bundle ad-hoc signiert; die Hardened Runtime ist aus, weil Ad-hoc-Signatur plus Library Validation die vorkompilierte Binärdatei von better-sqlite3 abgelehnt hätte. Beglaubigt ist die App weiterhin nicht, dafür fehlt ein bezahltes Apple-Konto.

Wer ein 1.2.0 installiert hat, kann es reparieren, ohne neu zu laden:

xattr -dr com.apple.quarantine "/Applications/Mail Archiver.app"
codesign --force --deep --sign - "/Applications/Mail Archiver.app"

Das erste Öffnen muss weiterhin erlaubt werden: einmal versuchen, scheitern lassen und dann unter „Systemeinstellungen → Datenschutz & Sicherheit“ auf „Dennoch öffnen“ klicken. Seit macOS 15 funktioniert der alte Rechtsklick-Weg nicht mehr; die Installationshinweise hatten etwas anderes behauptet und wurden korrigiert. Windows und Linux waren nie betroffen. Außerdem gibt es seit 1.2.1 eine bebilderte Anleitung, wie man das Add-on von außerhalb Home Assistants erreicht – nötig, wenn man ein Archiv aus der Desktop-App ins Add-on umziehen will – und eine Tabelle, was Desktop-App und Container jeweils können.

Die Integration zieht um

Die Home-Assistant-Integration folgt in Version 2.0.0. Die Domain wechselt von mail_archiver zu amberchest. Sie steckt in jeder Entitäts-ID, jeder Unique-ID und im Namen der Karte, deshalb gibt es keinen Migrationspfad – und es ist keiner nötig, weil 1.0.0 nie in HACS gelistet war. Wer von 1.0.0 kommt, entfernt die alte Integration, installiert die neue und fügt die Instanz wieder hinzu. Ein Dashboard mit custom:mail-archiver-card wird zu custom:amberchest-card. Voraussetzung ist AmberChest 2.0.0 oder neuer.

2.1.0: verwerfen und wieder holen

Eine einzelne Nachricht aus dem Archiv zu löschen war bisher sinnlos: Die Mail liegt ja noch auf dem Server, und die nächste Sicherung fand sie nicht im Index und holte sie sofort zurück. Das Archiv merkt sich die Entscheidung jetzt. Die Datei verschwindet, die Zeile bleibt als Grabstein, und die nächste Sicherung erkennt die Nachricht und lässt sie in Ruhe. Weil ein Fehlklick sonst endgültig wäre, zeigt „Verworfen“ in der Seitenleiste alles, was verworfen wurde, gefiltert nach Konto, Ordner und Text, mit einem Weg zurück für eine Nachricht, einen Ordner oder das ganze Konto; zurückgeholt wird sie beim nächsten Lauf. Die Entscheidung steht auch im Journal des Ordners, damit ein aus den Dateien neu aufgebauter Index zum selben Ergebnis kommt. Sonst würde die erste Sicherung nach einer Übernahme oder einem Umzug alles Verworfene wiederherstellen.

Dazu kommen Rechtsklickmenüs. Im Ordnerbaum lassen sich die Anhänge des Ordners exportieren, der Ordner selbst exportieren oder die lokale Kopie löschen. Das Löschen fragt vorher, weil der Server nicht gefragt wird und es nichts gibt, woraus man wiederherstellen könnte. Eine Mail, die in zwei Ordnern liegt, wird einmal gespeichert und vom zweiten verlinkt; die Datei geht an den anderen Ordner, statt mit dem Verzeichnis zu verschwinden. Und weil der Ordner mit der nächsten Sicherung wiederkäme, bietet der Dialog an, ihn aus der Auswahl zu nehmen (voreingestellt). Auf einer Nachricht: .eml speichern, als PDF speichern, nach dem Absender suchen, im Mailprogramm öffnen oder aus dem Archiv werfen.

Das Postfach hat jetzt dieselben Filter wie die Suche: Absender, Empfänger, Feld, Zeitraum, Größe, ungelesen, markiert und „an mich selbst gesendet“. Das Letzte findet Notizen, zwischen Rechnern verschobene Dateien und Erinnerungen; beide Enden müssen eigene Adressen sein, die Kontoadresse zählt immer, Aliase stehen in einer Liste daneben. Die Statistik zeigte zuvor zehn große Nachrichten, ohne dass man sah, wo sie liegen. Jetzt gibt es getrennt „größte Nachricht“ und „größte Anhänge“ (ein langer Thread ist groß, ohne dass etwas angehängt ist), mit Ordner in jeder Zeile, Klick zum Öffnen und Blättern. Der Anhang-Export lässt sich auf einen Zeitraum eingrenzen.

Ein Sicherheitsfehler in den MCP-Werkzeugen

Mit 2.1.0 kommt auch ein Fehler zur Sprache. get_settings gab das Einstellungsobjekt unverändert zurück, und darin stehen der MCP-Token, das MQTT-Passwort, der Benachrichtigungs-Header und die OAuth-Client-Secrets. Die Berechtigung read gilt, sobald MCP überhaupt eingeschaltet ist; ein Client mit reinem Lesezugriff bekam also den Token, der alle anderen eingeschalteten Berechtigungen freigibt. Wer MCP nutzt, sollte den Token nach dem Update erneuern. Außerdem schickte die Oberfläche Geheimnisse an den Browser, die sie nie anzeigt: Broker-Passwort, Header und Client-Secrets, auch über das Netz, wenn die Desktop-App einen Container bedient. Die bleiben jetzt auf dem Server. Der MCP-Token steht in einem maskierten Feld mit Anzeigeknopf.

Die Installer und Images stehen auf der Releases-Seite; das Image heißt ghcr.io/sphings79/amberchest.