MailBurg 1.8.0

Die erste Fassung, die aus dem laufenden Betrieb eines Firmenservers
stammt. Am 5. und 6. Oktober 2026 ist ein Geschäftsarchiv mit 70.133
Mails auf einen Windows Server 2025 gezogen – und was dabei fehlte,
steht hier.

Eine Ampel, bevor man liest

Ganz oben im Einrichtungsfenster, vor allem anderen:

Rot	Es fehlt etwas Zwingendes – der Dienst läuft nicht oder liefert nichts aus.
Gelb	Es läuft, aber etwas gehört nachgezogen. Der häufigste Fall: ein Dienst ohne Abruf, der ein Archiv ausliefert, das nicht mehr wächst.
Grün	Alles in Ordnung.

Daneben ein Knopf, der zur ersten offenen Sache führt.

Siebzehn Zeilen beantworten nicht die Frage, mit der man dieses
Fenster öffnet. Ein Verwalter will wissen, ob er handeln muss, und
zwar bevor er die Liste durchgeht. Erst danach interessiert ihn, was.

Unklares macht dabei nicht gelb: »Noch nicht nachgesehen« beim Update
ist eine offene Frage, keine Störung. Wer daraus Gelb machte, hätte
eine Ampel, die nie grün wird – und damit keine.

Und ein Fehlalarm, der die Ampel fast entwertet hätte

Beim ersten Öffnen am echten Server stand sie auf Rot: »Tresor: 7
Passwörter liegen in Ihrem Benutzerprofil.« Der Tresor war in Ordnung –
der Dienst holte seit Stunden Post.

Die Ursache stand zwei Zeilen darüber: Das Feld Gemeinsamer Ordner
war leer. gesetzte_variablen() las nur Archiv, Adresse und Port;
MAILBURG_EINSTELLUNGEN und MAILBURG_DATEN wurden geschrieben,
aber nie wieder gelesen. Die Prüfliste schloss daraus, der Dienst
finde den Tresor nicht.

Ein Fehlalarm ist teurer als eine fehlende Warnung. Wer dreimal
nachsieht und nichts findet, glaubt beim vierten Mal auch der richtigen
Meldung nicht mehr – und dann ist die ganze Ampel wertlos. Ein
Wächtertest hält jetzt fest, dass jede Variable, die das Fenster
schreibt, auch wieder gelesen wird.

Dazu zwei Kleinigkeiten aus demselben Lauf: Das Fenster hatte kein
Wappen (ein leeres Blatt in der Leiste, derselbe Befund wie am
28.08.2026 bei der gepackten Fassung) und ließ sich nicht rollen –
siebzehn Prüfzeilen plus Wartung plus Protokoll passen auf einen
entfernten Bildschirm nicht mehr.

Ein Tagesbericht per Mail

Warum ein Archivdienst eine Mail schreibt, obwohl er sonst nur
liest: Ein Dienst, der still arbeitet, ist von einem Dienst, der
still nicht arbeitet, nicht zu unterscheiden. Am 6. Oktober
scheiterte der Abruf tagelang in seiner ersten Zeile; die Meldung stand
im Ereignisprotokoll, wo man nur nachsieht, wenn man schon etwas ahnt.

Der Bericht nennt, wie viele Mails seit dem letzten Mal dazukamen, und
ob das Archiv in Ordnung ist – geprüft, nicht behauptet. Der Befund
steht im Betreff: Wer dreißig Tagesmails im Postfach hat, liest keine
davon, aber einen Betreff, der sich ändert, sieht er.

Einstellbar sind Empfänger, Uhrzeit und Takt (täglich, alle 7, 14 oder
30 Tage) sowie der Postausgangsserver – ausdrücklich ein eigenes
Postfach, nicht eines der archivierten; sonst landet jeder Bericht
beim nächsten Abruf wieder im Archiv. Das Versandpasswort liegt im
Tresor, nicht in der Registry.

Eine Störung wartet nicht auf die Uhrzeit. Sie geht sofort hinaus
und wiederholt sich nicht, solange sie dieselbe bleibt – sonst legt der
Empfänger nach dem dritten Mal eine Regel an und bekommt auch die
vierte nicht mehr, die etwas anderes sagt. Dafür kommt eine Entwarnung,
sobald es wieder läuft.

Und das Ausbleiben ist selbst eine Nachricht. Das steht in jeder
Mail.

Wartung statt nur Einrichtung

Das Fenster heißt jetzt einrichten und warten und hat einen eigenen
Kasten mit drei Werkzeugen, für die es bisher nur die Kommandozeile gab
– auf einem Server also nichts:

Archiv prüfen hält die Hash-Kette gegen die Ablage. Drei Fragen auf
einmal: Ist die Kette unversehrt, liegt zu jeder Mail noch eine Datei,
und liegt dort etwas, das im Journal nicht vorkommt? Das Letzte ist das
interessanteste – eine von Hand hineingelegte Datei ist nicht
archiviert, sondern untergeschoben.

Tresor prüfen fragt beide Richtungen ab: Postfächer ohne Anmeldung
(der Dienst holt dort nichts und meldet es nicht als Fehler) und
Einträge ohne Postfach (fremde Passwörter auf einem gemeinsamen
Rechner).

Mails einlesen übernimmt Post aus Dateien – ein Verzeichnis mit
.eml-Dateien, ein Maildir, eine MBOX oder ein Thunderbird-Profil. Der
Dienst wird dafür angehalten und bleibt es, bis Sie ihn wieder
starten: Zwei Vorgänge, die gleichzeitig ins selbe Archiv schreiben,
reißen die Hash-Kette. Lässt er sich nicht anhalten, wird gar nicht
eingelesen.

Der Text zählt dabei mehr als der Knopf. Eine beschädigte
Hash-Kette sieht ein Verwalter höchstens einmal – dann muss dastehen,
dass die Mails davon nicht betroffen sind, dass die Lückenlosigkeit
beanstandet ist, und was zu tun ist.

Zwei Befehle, die beim Umzug fehlten

mailburg tresor entfernen KENNUNG nimmt einen Eintrag heraus. Ein
Tresor vom Arbeitsplatz bringt alle dortigen Anmeldungen mit; die
Kontenliste lässt sich filtern, der Tresor nicht, denn er kennt keine
Archive. Jeder Eintrag ist einzeln verschlüsselt – herausnehmen lässt
die übrigen lesbar und braucht keinen neuen Hauptschlüssel. Stimmt eine
der genannten Kennungen nicht, wird keine entfernt.

mailburg zugaenge ARCHIV anzeigename NAME "Vor Nachname" ändert den
Klarnamen. Bisher ging das nur im Einrichtungsfenster – also an dem
Ort, den es auf einem Server gerade nicht gibt.

Alles zum Server an einer Stelle

Die Server-Dokumentation lag auf drei Seiten verteilt, und keine davon
war der Einstieg. MailBurg Server bündelt
jetzt alles: womit man anfängt, was im Betrieb zählt und die vier
Dinge, die man wissen sollte, bevor es ernst wird. Der Link steht in
der Kopfzeile aller Hauptdateien.

---

2291 Tests – geprüft mit und ohne Qt, denn der erste
CI-Lauf installiert absichtlich keine Oberfläche.
lesbarkeit.py ohne Befund, CI grün.