Posts by StephanR

    So in den letzten Wochen habt Ihr mir viele Dinge gezeigt und auch Fehler aufgedeckt. Für die Zukunft werde ich nur dann eine neue Version raus bringen, wenn tatsächlich Fehler auftauchen. Alle anderen Dinge die kommen werden gesammelt und dann gibt es einmal im Monat ein Update. Wenn es denn notwendig ist!

    Dann kommt auch etwas Ruhe in die Sache und Ihr könnt MailBurg in ruhe nutzen & testen. Aber natürlich stehe ich hier weiter für Fragen und Wünsche zur Verfügung!

    GitHub - Stephan-Lefty/MailBurg: Plattformübergreifendes Archiv für E-Mail. Beliebig viele Postfächer, Archivort frei wählbar, Volltextsuche auch in Anhängen. Linux, Windows, macOS.
    Plattformübergreifendes Archiv für E-Mail. Beliebig viele Postfächer, Archivort frei wählbar, Volltextsuche auch in Anhängen. Linux, Windows, macOS. -…
    github.com

    Hallo zusammen, ein kurzer Wochenrückblick!
    Eine Bitte, die zwei Minuten kostet und die ich mir selbst hätte früher stellen sollen.

    Diese Woche sind mir gleich mehrere Wege untergekommen, auf denen der Abruf stehenbleibt, ohne dass irgendwo etwas rot wird: ein Passwort, das der Anbieter nicht mehr nimmt; ein Server, der seine internen Nummern neu vergeben hat; ein Systempaket, das beim Aufräumen mitgegangen ist. In allen Fällen sieht das Archiv gesund aus, die Prüfung sagt das auch - es kommt nur nichts Neues mehr an.

    Wer den Abruf im Hintergrund laufen lässt, merkt das besonders spät: Ein geplanter Abruf hat kein Fenster, in dem er sich beschweren könnte.

    Der schnellste Test

    Öffnet MailBurg und schaut unten rechts in die Statuszeile. Dort steht, wann zuletzt abgerufen wurde. Ist das länger her, als es sein sollte,
    stimmt etwas nicht.

    Der gründlichere

    Post -> Ist alles im Archiv?

    Das fragt eure Postfächer, was dort älter als ein Stichtag ist, und vergleicht es mit dem Archiv. Nur wenn dort überall "vollständig" steht, ist wirklich alles drin.

    Bei mir hat dieser Vergleich zwei Postfächer gefunden, in denen seit Monaten nichts mehr ankam - was in meinem Fall gewollt war, aber ich
    wusste es schlicht nicht mehr.

    Was in der neuen Fassung steckt

    1.7.5 räumt zwei dieser Fallen weg. Wenn der Schlüsselbund fehlt, sagt MailBurg das jetzt, statt "kein Passwort hinterlegt" zu melden - das
    hat eine Anwenderin fast dazu gebracht, alle Passwörter neu einzutippen, in einen Speicher, den es nicht mehr gab. Und das
    Debian-Paket bringt den Schlüsselbund jetzt zwingend mit, damit ihn kein "apt autoremove" wegräumen kann.

    Ich wünsche Euch ein tolles Wochenende!

    Ein GUI-Nutzer wird die Suchausdrücke in der Regel mit der "Ausführlich Suchen" Maske erstellen. Dann sollte die Konvertierung Felder -> Ausdruck -> Felder und Ausdruck -> Felder -> Ausdruck immer funktionieren. Ich dachte zum Beispiel vor diesem Beitrag gar nicht daran, einen Suchausdruck in der GUI manuell einzugeben. Ein Power-User, der eigene Suchausdrücke mit dem Texteditor erstellt, kann dann auch auf die Maske verzichten. Ich würde also im Dialog "Suchordner ändern" den Button "Ausführlich.." nur anbieten, wenn der aktuelle Suchausdruck in eine Feld-Werte Liste konvertiert werden kann, sonst ausgrauen oder verstecken.

    Ich plane nicht, vorzeitig auf Fedora 45 umzustellen. Wenn ich Mailburg unter NixOS zum Laufen bringe, könnte ich dort das Zusammenspiel mit oo7 testen und dann rückmelden.

    Hallo joka63,

    Dein Vorschlag ist besser als den ich gehen wollte, und ich habe ihn übernommen. Ich hatte überlegt: entweder den nicht abbildbaren Rest sichtbar stehen lassen, oder warnen und nichts überschreiben. Beides verlangt vom Anwender, einen Sonderfall zu verstehen. Deine Lösung macht den Sonderfall unmöglich - wo die Umwandlung nicht geht, gibt es den Weg gar nicht. Das ist die bessere Sorte Lösung: nicht eine Erklärung für ein Problem, sondern ein Aufbau, in dem es nicht auftritt.

    Und Deine Beobachtung dahinter trägt das. Wer die Maske benutzt, erzeugt nur Ausdrücke, die sich zurückverwandeln lassen - für diesen Weg ist die "Rundreise" vollständig. Unvollständig ist sie nur für von Hand Geschriebenes, und dort braucht sie niemand.

    Zwei Dinge habe ich dazugeschrieben:

    Der ausgegraute Knopf muss sagen, warum er ausgegraut ist. Sonst liest er sich als kaputt, und jemand meldet ihn als Fehler. Ein Tooltip in der
    Art: "Dieser Suchausdruck lässt sich in der Maske nicht abbilden - bearbeiten Sie ihn direkt im Feld darüber."

    Und die "Rundreise" gehört in beide Richtungen geprüft. Felder -> Ausdruck -> Felder ist das Naheliegende. Wichtiger ist aber Ausdruck ->
    Felder -> Ausdruck für jeden Ausdruck, den die Umwandlung als machbar meldet: Genau darauf verlässt sich der Knopf, wenn er sich anbietet.
    Wenn diese Zusage irgendwann nicht mehr stimmt, verschwindet still ein Stück Suchausdruck - und das merkt niemand, bis ein Suchordner
    plötzlich zu viel findet.

    Zu oo7: Kein Grund zur Eile, und NixOS wäre mir sogar lieber als ein vorgezogenes Fedora - dort sähe man, ob es an oo7 liegt oder an der
    Fedora-Ausstattung drumherum. Ich melde mich, sobald ich selbst etwas dazu habe.

    Danke fürs Mitdenken. Das war jetzt zweimal, dass Deine Rückmeldung nicht nur einen Fehler gezeigt, sondern die bessere Bauform mitgeliefert hat.

    Vielen Dank, die Suchordner hast du ziemlich genau so umgesetzt, wie ich es mir vorgestellt hatte.
    Einziger Schönheitsfehler: wenn vom Dialog "Suchordner bearbeiten" der "Ausführlich suchen" Dialog aufgerufen wird, dann hätte ich erwartet, dass die Felder entsprechend dem Suchausdruck vorgefüllt werden.

    Das hatte ich in meinem Branch von Claude implementieren lassen, allerdings fand ich die von Claude gefundene Lösung unbefriedigend: es speicherte die Feld-Werte Liste in einem eigenen Dictionary und damit redundant zum Suchausdruck. Man bräuchte die inverse Funktion zu mailburg.search.maske.ausdruck, um das zu vermeiden. Aber wie gesagt, nur ein Schönheitsfehler ohne hohe Priorität für mich.

    Ich kann meine Mailburg-Installation per "git pull" ständig aktualisieren. Aktuell habe schon die Version 1.6.0 in einem Fedora-44-Toolbox-Container. 😊

    Übrigens: Fedora hat angekündigt, in der kommenden Version 45 den GNOME-Keyring durch "oo7" zu ersetzen. Es könnte also sein, dass Applikationen wie Mailburg, die auf den Keyring zugreifen, angepasst werden müssen.

    Hallo joka63,

    danke – und danke besonders für den zweiten Absatz, der ist wertvoller als das Lob.

    Zum Vorfüllen der Maske

    Du hast recht, und zwar an beiden Stellen: Die Felder sollten gefüllt sein, und die Werte doppelt abzulegen ist der falsche Weg. Zwei Quellen für dieselbe Sache laufen irgendwann auseinander, und dann gewinnt die falsche.

    Die Umkehrfunktion zu maske.ausdruck() ist richtig gedacht. Beim Nachsehen ist mir aber aufgefallen, warum sie mehr Arbeit ist, als sie aussieht: Sie lässt sich nicht vollständig bauen. Die Maske kennt jedes Feld genau einmal, ein Suchausdruck darf dasselbe Wort aber mehrfach enthalten - "von:a von:b" etwa -, und wer den Ausdruck von Hand schreibt, kann Dinge hineinschreiben, für die es kein Feld gibt.

    Das wäre nicht schlimm, wenn die Maske nur läse. Sie schreibt aber zurück: Wer sie mit OK schließt, ersetzt den Ausdruck durch das, was in den Feldern steht. Alles, was sie nicht abbilden konnte, wäre damit stillschweigend weg - an einem Suchordner, den sich jemand über Monate zurechtgelegt hat.

    Deshalb muss vorher feststehen, was in diesem Fall passiert. Entweder bleibt der nicht abbildbare Rest sichtbar stehen, oder die Maske sagt, dass sie diesen Ausdruck nicht vollständig übernehmen kann, und überschreibt gar nichts. Absichern lässt sich das mit einer Rundreise:

    Felder -> Ausdruck -> Felder muss dasselbe ergeben. Steht auf der Liste, mit genau dieser Begründung.


    Zu oo7

    Danke für die Vorwarnung, das hätte ich sonst erst gemerkt, wenn es jemanden erwischt. MailBurg spricht über das Paket "keyring" mit der Secret-Service-Schnittstelle auf D-Bus. Solange oo7 dieselbe Schnittstelle bedient, sollte sich am Zugriff nichts ändern - aber "sollte" ist kein Befund, und ich habe kein Fedora zum Prüfen.

    Eine Stelle ist sicher betroffen: MailBurg erkennt am Prozessnamen, welcher Dienst gerade antwortet, und kennt bisher nur gnome-keyring, ksecretd und kwalletd. Das klingt nebensächlich, hat mir aber zweimal Stunden gespart - auf meinem Rechner liefen zwei Schlüsselbünde nebeneinander, und der falsche antwortete. oo7 fiele dort durchs Raster. Wenn Du Fedora 45 früh hast: Mich würde interessieren, ob Passwörter, die unter dem alten Dienst abgelegt wurden, noch ankommen. Das ist die Frage, an der es hängt.

    Und noch etwas in eigener Sache

    Du schreibst, Du bist auf 1.6.0. Bitte zieh bei Gelegenheit nach - in der 1.7.1 steckt ein Fehler, der Dich betreffen könnte: Unter bestimmten Umständen hat MailBurg neue Post übersehen, weil es sie für längst geholt hielt. Es fällt nicht auf, das ist das Ärgerliche daran. Nach dem Update einmal:

    Code
        mailburg abrufen --alle --voll

    Das geht durch alle Archive und holt nach, was übersprungen wurde. Doppelt landet dabei nichts im Archiv

    Betreff: MailBurg 1.7.3 – bitte einmal vollständig abrufen

    Hallo zusammen,

    es gibt eine neue Fassung, und dazu eine Bitte: Lasst nach dem Update einmal diesen Befehl im Terminal laufen.

    Code
       mailburg abrufen --alle --voll

    Was der macht

    Er geht nacheinander durch alle eure Archive – ihr müsst keinen Pfad heraussuchen, MailBurg weiß, welche es sind. In jedem davon sieht er
    sämtliche Ordner noch einmal durch, statt nur nach Neuem zu schauen.

    Doppelt landet dabei nichts im Archiv: MailBurg erkennt jede Nachricht an ihrem Inhalt wieder. Was schon da ist, bleibt unverändert, Fehlendes
    kommt dazu. Der Lauf dauert länger als ein gewöhnlicher Abruf, je nach Bestand einige Minuten.

    Schließt MailBurg vorher, sonst schreiben zwei Vorgänge ins selbe Archiv. Und falls eine externe Platte gerade nicht angesteckt ist: Das
    betreffende Archiv wird übersprungen und am Ende genannt.

    Warum die Bitte

    Unter bestimmten Umständen konnte MailBurg neue Post übersehen – es dachte, sie sei längst geholt. Bei mir sind so zwei Tage Mails liegen
    geblieben, ohne dass irgendwo etwas rot wurde: Das Archiv war in Ordnung, die Prüfung sagte das auch, und der Abruf meldete brav "nichts
    Neues". Gemerkt habe ich es nur, weil ich zufällig ins Postfach schaute.

    Betroffen war vor allem, wer die Proton Mail Bridge neu eingerichtet hat. Der Fehler ist behoben – aber was einmal übersprungen wurde, holt
    nur so ein vollständiger Durchlauf nach.

    Neu: Post -> Ist alles im Archiv?

    Daraus ist gleich etwas Nützliches entstanden. Der neue Menüpunkt fragt eure Postfächer, was dort älter als ein Stichtag ist, und vergleicht es
    mit dem Archiv. Erst wenn dort "vollständig" steht, könnt ihr im Mailprogramm beruhigt aufräumen.

    "Archiv prüfen" kann das nämlich nicht beantworten: Es sagt euch, ob euer Archiv heil ist – nicht, ob alles drin ist. Gelesen wird dabei nur,
    in euren Postfächern ändert sich nichts.

    Noch zwei Kleinigkeiten

    Gmail ist jetzt an echten Konten erprobt, und der Weg zum App-Passwort steht Schritt für Schritt im Handbuch. Google hatte ihn aus dem Menü
    genommen, unsere alte Anleitung führte ins Leere.

    Und falls jemand Outlook oder Microsoft 365 nutzt: Dort funktioniert nur die Anmeldung per OAuth2. Eingebaut ist sie, ausprobiert hat sie an
    einem echten Konto noch niemand. Wer Lust hat, das zu testen – ich begleite das gern.

    Hier geht es zur aktuellen Version: https://github.com/Stephan-Lefty/MailBurg

    Hallo joka63,

    vielen Dank – und melde Dich ruhig öfter so. Beides steckt jetzt in der 1.5.0.

    Mit dem Evolution-Pfad hattest Du recht, aber der Fehler saß tiefer. Es war kein vergessener Pfad, sondern eine zweite Liste: Der Einlesedialog
    hatte seine eigene, und die war eine andere als die, nach der MailBurg sonst sucht. Beim Nachrechnen fehlten dann gleich drei Pfade – Dein
    Evolution aus Flatpak, Thunderbird aus Snap und ~/.mozilla-thunderbird. Alle drei kannte das Programm an anderer Stelle seit Jahren. Jetzt fragt
    der Dialog dort nach, und ein Test passt auf, dass die beiden nicht wieder auseinanderlaufen.

    Die Suchordner haben mich überzeugt, und zwar wegen Deiner Begründung, nicht wegen des Wunsches. Wer seine Post MailBurg überlässt, gibt eine Ordnung auf, an der er jahrelang gebaut hat. Ohne Ersatz ist der Umstieg ein Verlust – das hatte ich schlicht nicht gesehen.

    Sie stehen jetzt links im Baum unter den Postfächern, anzulegen über "Suchen → Diese Suche als Suchordner sichern …". Auf der Kommandozeile geht es auch:

    mailburg suchordner ~/Mailarchiv hinzufuegen Telekom "von:telekom betreff:Rechnung"

    "Zuletzt gesucht" ist dabei. Der kniffligste Teil daran war nicht die Liste, sondern das Tippen: MailBurg sucht schon während der Eingabe, ein
    getipptes Wort löst also fünfzehn Suchen aus. Es bleibt deshalb nur der längste Stand einer Tippfolge übrig.

    Schau bitte mal, ob meine Fassung das trifft, was Du Dir gebaut hast. Wo sie hinter Deiner zurückbleibt, will ich es wissen – Du hast Deine im
    Alltag benutzt, ich meine nicht.

    Beim Umbenennen musst Du Dich noch gedulden. Der Kontoname hängt an vier Stellen gleichzeitig – Suchindex, Abrufzustand, Schlüsselbund und Archivzuordnung –, und die müssen alle zusammen umziehen. Sonst ist der Abrufzustand weg und der nächste Lauf holt das ganze Postfach noch einmal. Steht auf der Liste.

    Zu Deiner Frage: Ja, Pull Requests sind willkommen, klassisch über Fork und PR. Was ich mir wünsche, schreibe ich noch in eine CONTRIBUTING.md – kurz gesagt: Tests gehören dazu, keine echten Adressen (auch nicht in Testdaten und Screenshots), Kommentare, die das Warum erklären statt das Was, und Doku in beiden Sprachen. Oberfläche und Lesewege sehr gern; alles, was ins Archiv schreibt oder an der Hash-Kette hängt, mache ich lieber selbst – ich stehe dafür gerade, wenn jemand so ein Archiv in acht Jahren prüft. Mach vorher bitte einen Issue auf, damit Du keine Arbeit machst, die ich am Ende anders haben will.

    Und jetzt Deine eigentlich viel spannendere Frage.

    Ich glaube nicht, dass der Prompt den Pull Request ersetzt. Ein Prompt ist nicht reproduzierbar – derselbe Text liefert morgen anderen Code und in einem anderen Modell etwas völlig anderes. Der Diff dagegen ist eindeutig. Und Dein Prompt allein hätte gar nichts gebracht: Was Dein
    Claude gebaut hat, hing daran, dass er meinen Quelltext gelesen hat, die Suchsprache, die Konventionen. Genau dieser Teil steht in keinem Prompt.

    Die Tipparbeit war auch früher nie der Wert eines Beitrags. Der lag immer darin, ein fremdes Programm so weit zu verstehen, dass die eigene
    Ergänzung hineinpasst – und dieser Teil ist durch KI kein Stück kleiner geworden. Er ist inzwischen der ganze Rest.

    Was sich wirklich verschiebt: Etwas zu bauen ist billig geworden, es zu prüfen nicht. Damit wandert die Arbeit vom Beitragenden zum Betreuer.
    Meine Schlussfolgerung geht deshalb andersherum als Deine Vermutung – ein PR braucht heute mehr Begründung als früher, nicht weniger. Warum so und nicht anders, was hast Du verworfen, was hast Du wirklich ausprobiert. Nicht weil Dir jemand misstraut, sondern weil das die Information ist, die im Code nicht steht und die ein Modell auch nicht mitliefert.

    Den Prompt darfst Du gern dazuschreiben. Nur als Ersatz für den Diff taugt er nicht.

    Stephan, das ist keine Kritik und wirklich nur nur ein Rat meinerseits, da ich das Projekt wirklich cool finde. Wenn du Software entwickelst und das mit KI geschieht, ist das heutzutage keine große Sache mehr und irgendwie normal. Wenn du dann solche Projekte öffentlich vorstellest, würden die meisten aber vermutlich erwarten, dass du zumindest deine Texte, Antworten, etc hier selbst verfasst. Wenn dann aber die ganzen Texte auch von KI sind, könnte das eventuell eine ansonsten einwandfreie Reputation schmälern oder ankratzen.

    Das sind so KI-Konversationen zwischen Entwickler und LLM, die vermutlich die meisten so nicht als Antwort in einem Forum posten würden.

    Nochmals der Hinweis, dass das keine Kritik sein soll. Finde deinen Einsatz und das Projekt super.

    Hallo Boris,

    aktuell nutze ich die KI auch um die Dinge sauber zu erklären und aus Zeitgründen. Das klingt dann alles sehr technisch und nüchtern, aber ich denke, wenn Ihr Euch die Mühe macht, dann solltet Ihr auch zeitnah ein Feedback bekommen. Wenn es meine Zeit wieder zulässt, dann werde ich auch selbst wieder schreiben. Und noch etwas zum Thema Kritik: Ich bin für jede Kritik dankbar, weil sie mir auch zeigt, das sich andere Menschen über meine Projekte Gedanken machen. Dann habe ich ja schon das erste Ziel erreicht und das Projekt ist bei Euch "angekommen". Wenn es dann noch genutzt wird, dann bin ich schon glücklich!

    Hier mal ein Update was sich geändert hat! MailBurg – was sich diese Woche getan hat (1.4.3 bis 1.4.8)

    Eine Woche mit sechs Fassungen. Die meisten davon gehen auf Dinge zurück, die erst auffallen, wenn ein Programm bei anderen Leuten auf anderen Rechnern läuft – und nicht bei dem, der es gebaut hat.

    Ein AppImage: eine Datei, ausführbar machen, starten MailBurg gab es bisher als Debian-Paket und als Windows-Programm. Wer Ubuntu, Mint, Fedora, Arch oder openSUSE betreibt, musste den Quelltext holen und eine Viertelstunde übersetzen. Ab sofort liegt bei jederVeröffentlichung ein AppImage:

    Code
     chmod +x MailBurg-x86_64.AppImage 
    ./MailBurg-x86_64.AppImage

    Kein Python, keine Paketverwaltung. Zwei Dinge dazu, ehrlich gesagt:
    Das AppImage bringt die Oberfläche selbst mit, rund 200 MB, und bekommt deren Sicherheitsupdates erst mit der nächsten Fassung von MailBurg – wer Debian 13 oder GuideOS betreibt, bleibt besser beim .deb. Und es läuft nicht überall: Ubuntu 22.04, Mint 21 und Debian 12
    fehlen die Bibliotheken dafür. Ein zu altes SQLite sagt es jetzt, statt abzustürzen

    Beim Bauen des AppImage kam ein Befund heraus, der weit darüber hinausreicht. Auf älteren Systemen brach das Anlegen eines Archivs mit
    einer Aufrufliste ab – der Suchindex braucht eine neuere SQLite-Fassung, als dort vorhanden ist. Das stand nirgends und wurde nirgends
    geprüft. Jetzt sagt MailBurg es in einem Satz, und zwar bevor etwas schiefgeht. Nachgemessen statt geraten: Ubuntu 22.04 und Mint 21
    bringen 3.37 mit, Debian 12 dann 3.40 – beides zu wenig. Ab Ubuntu 24.04, Mint 22 und Debian 13 reicht es.

    MailBurg startete und tat nichts

    Ein Anwender auf Linux Mint schrieb, beim Klick auf den Menüeintrag passiere gar nichts – und entschuldigte sich dafür: "Meist liegt es ja an dem Honk vor dem Monitor." Es lag am Programm. MailBurg hatte die richtige Auskunft parat, welches Paket fehlt und wie es nachzurüsten
    ist, schrieb sie aber nur auf die Fehlerausgabe. Ein Menüeintrag startet ohne Terminal; die Zeile fiel also ins Nichts. Jetzt kommt ein Fenster. Und das .deb-Paket sagt es schon beim Installieren, bevor jemand zum ersten Mal vergeblich klickt.

    Ein Abruf, der aufgehört hat zu laufen, ohne dass es jemand sieht

    In den Zeitplan für den selbsttätigen Abruf schreibt MailBurg den vollen Pfad des Programms. Wer die MailBurg.exe danach aus dem Download-Ordner an ihren richtigen Platz legt – also das Vernünftige tut –, hat damit den Abruf abgestellt. Zu sehen war davon nichts: Der
    Eintrag stand weiter in der Aufgabenplanung, das Fenster meldete weiter "alle 30 Minuten", und es kam trotzdem keine Post. Aufgefallen wäre es erst beim Suchen einer Mail, die nie angekommen ist. MailBurg merkt das jetzt beim Öffnen des Archivs und bietet an, es geradezuziehen.

    Lesbarkeit: alle einunddreißig Fenster statt zehn

    MailBurg prüft bei jedem Testlauf, ob in irgendeinem Fenster Text abgeschnitten wird – in fünf Schriftgrößen von 9 bis 24 pt. Nur: Von einunddreißig Fenstern kannte die Prüfung zehn. Die anderen sah niemand nach, und gemeldet wurde trotzdem "nichts abgeschnitten". Jetzt sind alle dabei, und ein Test zählt die Fenster der Oberfläche nach: Wer ein neues baut und es nicht einträgt, bekommt einen roten Test.

    Gefunden hat die erweiterte Prüfung sofort zwei abgeschnittene Spaltenüberschriften – bei großer Schrift stand über dem Postfachbaum
    "Postfäch…" und über der Trefferliste "Absend…". Es trifft ausgerechnet die, die große Schrift brauchen, um überhaupt lesen zu können.

    Dazu kam eine Frage, die gar keine Fehlermeldung sein sollte: "War hier nicht eine Grafik vorher drin?" Es war nie eine drin. Das Fenster
    "Über MailBurg" ging dreimal so hoch auf, wie sein Inhalt braucht, und der Text stand mitten in einer leeren Fläche. Ein halbleeres Fenster
    liest sich wie ein kaputtes – man sucht den Fehler an einer Stelle, an der keiner ist.

    Proton Mail und ein Passwort, das sich ändert

    Die Proton Mail Bridge erzeugt bei jeder Neuanmeldung ein neues Passwort. Das muss man danach im Mailprogramm ändern – und eben auch in MailBurg. Im Fenster ging das längst (Postfächer verwalten → Passwort ändern), auf der Kommandozeile nicht; dort gab es nur "entfernen und neu anlegen", und dabei ginge der Abrufzustand verloren. Jetzt gibt es "mailburg konten passwort NAME". Und Proton steht endlich in der
    Anleitung: Bisher verwies die Einrichtung auf einen Abschnitt, den es nicht gab.

    Zum Schluss noch eine Lehre aus einem Nachmittag Fehlersuche: Eine Schlüsselbund-Abfrage, die wir vor neun Tagen behoben hatten, kam über einen zweiten Weg zurück. Die Ursache von damals war richtig – aber sie war nicht die einzige, und weil in der Anleitung nur die eine stand, suchten wir drei Stunden an einer Stelle, die nachweislich in Ordnung war. Jetzt stehen beide dort.

    Die aktuelle Fassung ist 1.4.8, mit AppImage, Windows-Programm und Debian-Paket: https://github.com/Stephan-Lefty/MailBurg/releases/latest

    ok, ich schaue mir das an. Vielen lieben Dank!

    Ich muss wohl an meinen Fähigkeiten arbeiten aber wie gesagt bei mir passiert nichts. Die Installation scheint ja geklappt zu haben (ich habe eine Verknüpfung auf dem Schreibtisch und einen Eintrag im "Büro" aber auf ihrer Github-Seite steht, dass mich nach der Installation und dem ersten Start ein Assistent durch die Einrichtung führt. Das passiert bei mir nicht. Ich habe ein E-Mailkonto in Evolution eingerichtet. aber es macht wie mehrfach geschrieben gar nichts. Ich werde hier einfach weiterhin mitlesen und mich für die Leute freuen bei denen es macht was es soll. Bitte keinen Aufwand wegen mir. Meist liegt es ja an dem Honk vor dem Monitor!

    Für Mint und Ubuntu ist der Weg ein anderer als das .deb. Drei Schritte:

    1. Das Paket wieder herunternehmen, sonst liegen zwei Installationen nebeneinander:

    sudo apt remove mailburg

    2. MailBurg im Benutzerordner einrichten:

    git clone https://github.com/Stephan-Lefty/MailBurg.git
    cd MailBurg
    ./install.sh

    Das Skript fragt einmal nach deinem Passwort — es installiert ein paar
    Systempakete (unter anderem python3-venv, das Mint nicht mitbringt).

    WICHTIG: Danach dauert es fünf bis fünfzehn Minuten. Die Oberfläche
    allein ist rund 150 MB, und je nach Python-Fassung wird das eine oder
    andere Paket erst übersetzt. Das Skript schreibt dabei mit, was es tut —
    bitte nicht abbrechen, auch wenn es zwischendurch still ist.

    3. Starten:

    mailburg-gui

    Oder über den Menüeintrag, der neu angelegt wird. Beim ersten Start
    kommt der Einrichtungsassistent: Er fragt nach dem Ort fürs Archiv
    (privat oder geschäftlich) und danach nach deinem Postfach.

    Warum das .deb bei dir nicht ging: Es holt sich die Oberfläche aus den
    Paketquellen der Distribution, und Mint führt PySide6 dort nicht. Der Weg
    über install.sh bringt sie selbst mit und ist davon unabhängig.

    Falls doch etwas hakt, starte einmal "mailburg-gui" im Terminal — dort
    stehen alle Meldungen im Klartext.

    ok, ich schaue mir das an. Vielen lieben Dank!

    Ich muss wohl an meinen Fähigkeiten arbeiten aber wie gesagt bei mir passiert nichts. Die Installation scheint ja geklappt zu haben (ich habe eine Verknüpfung auf dem Schreibtisch und einen Eintrag im "Büro" aber auf ihrer Github-Seite steht, dass mich nach der Installation und dem ersten Start ein Assistent durch die Einrichtung führt. Das passiert bei mir nicht. Ich habe ein E-Mailkonto in Evolution eingerichtet. aber es macht wie mehrfach geschrieben gar nichts. Ich werde hier einfach weiterhin mitlesen und mich für die Leute freuen bei denen es macht was es soll. Bitte keinen Aufwand wegen mir. Meist liegt es ja an dem Honk vor dem Monitor!

    Ich schaue mir das noch mal genauer an!

    Holla, ich hoffe ich stelle mich nicht wieder gaaaaaanz hinten und allzu blöde an aber gibt es Filmchen zur Arbeit mit dem Programm oder aber ein Handbuch? Ich habe es mir auf meiner Linux-Mint-Testmaschine installiert und wenn ich das Tool starte, passiert gar nichts (jedenfalls nichts was ich sehen oder bemerken kann) Aber grundsätzlich schonmal Danke für die Arbeit mit und um das Tool.

    So lange Du keine Mailadressen verknüpfst passiert nix. Schaue mal hier: https://github.com/Stephan-Lefty/…/docs/README.md

    Ein Video habe ich für mein Tool noch nicht erstellt.

    Da es ja grundsätzliches Interesse an MailBurg gibt hier mal der Wochenrückblick:

    **MailBurg – was diese Woche passiert ist**

    Seit Donnerstag läuft MailBurg im Alltag von mehreren Leuten, mein Firmenarchiv hat inzwischen knapp 68.000 Mails. Was seitdem dazugekommen ist:

    **Spam kommt gar nicht erst ins Archiv.** Papierkorb, Junk und Spam-Ordner bleiben beim Abrufen *und* beim Einlesen lokaler Postfächer draußen – ohne dass man etwas einstellen muss. Wer will, kann zusätzlich Mails fernhalten, deren Betreff mit [SPAM] beginnt. Der Schalter dafür steht unter Einstellungen → Was von selbst laufen soll und gilt für alle Postfächer auf einmal. Ab Werk ist er aus: Spam-Marker stehen auch auf Mails, die keine sind, und was nie archiviert wurde, fällt erst Jahre später auf.

    **Ein Debian-Paket, an jeder Veröffentlichung.** Installieren ist jetzt ein Befehl statt einer Anleitung – neben der Windows-.exe hängt an jedem Release ein .deb für Debian 13 und GuideOS. Es bringt kein eigenes Qt mit, sondern nimmt das der Distribution. Deshalb wiegt es zwei Megabyte statt zweihundert und bekommt Sicherheitsupdates über apt.

    **Mails aus MailStore lassen sich übernehmen.** Wer seine Postfächer als .eml exportiert hat, kann sie einlesen und dabei aus einer Liste auswählen, zu welchem Konto sie gehören – statt den Namen abzutippen und sich zu vertippen.

    **MailBurg sagt jetzt, wenn der Schlüsselbund zu ist.** Nach einem Systemupdate kam ich an meine eigenen Archive nicht mehr heran, und MailBurg meldete dazu – nichts. Es hielt einen gesperrten Schlüsselbund für einen leeren. Jetzt erkennt es den Unterschied, merkt sich, wo es ein Passwort abgelegt hat, und sagt es, wenn zwei Schlüsselbund-Dienste nebeneinander laufen.

    **Die Suche ist gemessen, nicht geschätzt.** Bei 68.000 Mails (19,5 GB): 2 bis 61 Millisekunden. Auch bei 39.000 Treffern. Das Archiv liegt dabei auf einer externen Platte – gelesen wird von ihr erst, wenn man eine Nachricht wirklich öffnet.

    **Und der Punkt, der mich diese Woche am meisten gelehrt hat:** MailBurg prüft vor jeder Veröffentlichung selbst nach, ob in seinen Fenstern Text abgeschnitten wird – in fünf Schriftgrößen. Diese Prüfung kannte zehn Fenster. Das Programm hat einunddreißig. Sie meldete trotzdem jedes Mal „nichts abgeschnitten".

    Jetzt sind alle einunddreißig dabei, und ein Test zählt selbst nach: Ein neues Fenster, das nicht in der Liste steht, lässt den Test fehlschlagen. Gefunden hat der erste vollständige Lauf zwei echte Fehler – bei großer Schrift stand über den Spalten „Postfäch…" und „Absend…" statt „Postfächer" und „Absender". Das trifft ausgerechnet die, die große Schrift brauchen, um überhaupt lesen zu können.

    Beides ist in 1.4.3 behoben.

    Herunterladen: https://github.com/Stephan-Lefty/MailBurg/releases/latest

    MailBurg ist ein Mail-Archiv für Windows und Linux, kostenlos und quelloffen!

    rclone gefällt mir. Hatte mich gefragt, wie du die Login Credential sicher ablegen willst bzw wo. Rclone beantwortet das natürlich. Schaue ich mir bei Gelegenheit mal an.

    Danke – und du legst den Finger auf eine Stelle, an der ich mich selbst zu früh beruhigt hatte.

    rclone nimmt mir die Ablage ab, ja: Die Zugänge landen in einer eigenen Datei unter ~/.config/wolkenernte/rclone.conf mit Modus 0600, getrennt von der rclone.conf, die jemand vielleicht selbst pflegt.

    Aber "sicher" ist zu viel gesagt. rclone verschleiert Kennwörter nur (obscure), es verschlüsselt sie nicht – "rclone reveal" dreht das in
    einer Zeile zurück. Wer die Datei lesen kann, liest die Kennwörter. rclones eigentliche Antwort darauf wäre "rclone config password", also
    eine verschlüsselte Konfiguration, und die unterstütze ich derzeit nicht: Ich starte rclone als Dienst mit --ask-password=false, weil ein
    Dienst kein Terminal hat, an dem er nach dem Hauptkennwort fragen könnte. Der Weg dahin wäre RCLONE_CONFIG_PASS über die Prozessumgebung – nicht über die Kommandozeile, die kann unter Linux jeder in /proc lesen. Offen ist vor allem, wer nach dem Hauptkennwort fragt und wie oft; bei jedem Programmstart danach zu fragen macht die Fensteranwendung unbenutzbar.

    - Bei Nextcloud ein App-Passwort, nicht das Kontokennwort. Es gilt nur für dieses Programm und lässt sich einzeln zurückziehen – bei
    eingeschalteter Zwei-Faktor-Anmeldung nimmt Nextcloud das Kontokennwort über WebDAV ohnehin nicht an.

    - Bei Dropbox, OneDrive, Google Drive, Box und pCloud läuft die Anmeldung über OAuth. Ein Kennwort erreicht das Programm dabei nie,
    nur ein Token, das man beim Anbieter widerrufen kann. Nebeneffekt: Weil der Anwender die Google-Zugangsdaten selbst anlegt, entfällt das
    jährliche CASA-Audit, das Google für weitreichende Rechte verlangt.
    - Die rclone-Schnittstelle selbst ist abgedichtet, und das war mir wichtiger: Sie ist laut rclones eigener Doku so mächtig wie ein Shell-Zugriff. Also nur 127.0.0.1, Benutzer und Kennwort bei jedem Start neu gewürfelt, übergeben über die Prozessumgebung, und --rc-no-auth niemals. Drei Tests nageln das fest.

    Und die unbequeme Wahrheit dahinter: Solange das Bildarchiv daneben aus gewöhnlichen Dateien besteht – und das ist Absicht, damit man die Fotos in zehn Jahren ohne dieses Programm noch öffnen kann –, schützt ein verschlüsselter Zugangsschlüssel wenig. Wer den Rechner hat, hat die Fotos. Sinnvoll ist es trotzdem, aber aus einem anderen Grund: Ein Zugangsschlüssel öffnet ein *fremdes* Konto, nicht nur die eigenen
    Daten.