MailBurg 1.8.2

Keine vier Stunden nach der 1.8.1, und das ist Absicht: Ein Fehler, der
Anwender still trifft, geht sofort heraus. Diese Fassung kommt aus einer
einzigen Frage im Betrieb – »Kann ich beim Tagesbericht mehrere
Mailadressen mit ; angeben?«

Ein Semikolon verschluckte alle Empfänger außer dem ersten

Wer den Tagesbericht an mehr als eine Adresse schickt, sollte diese
Fassung einspielen – und danach nachsehen, ob dort wirklich alle
stehen.

Outlook zeigt das Semikolon als Trenner an; das Mailformat kennt nur das
Komma. Wer a@example.org; b@example.net eintrug, bekam beim Zerlegen
dies:

[('', 'a@example.org'), ('', '')]

Die zweite Adresse war weg. Ohne Fehlermeldung.

Bei einem Störungsbericht ist das die teuerste Sorte Fehler. Der
Bericht ist die Einrichtung, die Alarm schlagen soll, wenn etwas klemmt.
Die Vertretung wartet dann auf eine Warnung, die nie kommt – und merkt
es nicht, denn ein ausbleibender Bericht sieht aus wie ein Tag ohne
Störung.

Und die Probe im Einrichtungsfenster bestätigte den Fehler sogar. Sie
nimmt denselben Weg: Der Mailserver nimmt die Nachricht für den ersten
Empfänger an, nichts wirft eine Ausnahme – also meldete der Knopf Erfolg.
Ausgerechnet die Prüfung, die das hätte aufdecken müssen, verdeckte es.

Beides ist behoben. Das Semikolon wird jetzt angenommen und umgesetzt,
aber nur außerhalb von Anführungszeichen: "Müller; Hans" <h@example.org> ist ein einziger Empfänger, und den zu zerreißen wäre
derselbe Schaden in die andere Richtung.

Die Probe nennt die tatsächlichen Empfänger, einzeln untereinander,
statt den Wortlaut des Eingabefelds zurückzugeben. Stehen dort zwei, sind
es zwei.

Ein Komma zu viel ließ den Bericht an niemanden gehen

Beim Nachmessen gefunden, auf Python 3.14: Bei einem Syntaxfehler
verwirft die Standardbibliothek die ganze Empfängerliste, nicht nur
den kaputten Teil.

'chef@example.org,'   →   [('', '')]

Ein Komma am Ende, und der Bericht hätte niemanden erreicht – während das
Eingabefeld gefüllt aussah. Eine Liste, aus der keine Adresse
herauskommt, gilt jetzt als nicht eingerichtet; dann sagt die Probe
»Noch unvollständig«, statt Erfolg für eine Mail ohne Empfänger zu
melden.

Die Fassungsnummer führt zu den Änderungen

Unten in der Weboberfläche stand »MailBurg 1.8.1« als toter Text. Das
beantwortet, welche Fassung läuft – nicht, was daran anders ist als
vorher. Wer das wissen wollte, musste das Repository suchen, den
Änderungen-Teil finden und darin den richtigen Abschnitt: drei Schritte
für eine Auskunft, die an diese Stelle gehört.

Verlinkt ist die Release-Seite dieser Fassung. Nicht der Vergleich
zweier Stände – der zeigt Quelltextzeilen und beantwortet die Frage für
niemanden, der dort klickt. Und nicht die Übersicht aller Fassungen, denn
dort müsste man wieder suchen, und auf einem Server läuft selten die
neueste.

Und ein Befehl in der Anleitung, der an der eigenen Falle vorbeifilterte

In der Windows-Server-Anleitung stand zum Ereignisprotokoll:

Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { … }

Das holt erst die fünfzig jüngsten Ereignisse aller Programme und
filtert danach. Auf einem Server mit lebhaftem Anwendungsprotokoll ist
die gesuchte Zeile längst herausgefallen – man sieht nichts und schließt,
es sei nichts gelaufen.

Genau dieser Unterschied führte am 7. Oktober zu einem Fehlschluss, der
eine Stunde Suche gekostet hat. Die Lehre stand danach in den
Projektnotizen – und in der Anleitung stand weiter der Befehl, der sie
auslöst. Jetzt -FilterHashtable, also im Protokolldienst selbst
gefiltert, mit der Begründung daneben.

---

2412 Tests, lesbarkeit.py ohne Befund, CI grün.