Verdammt - wir haben Mails verloren.
Heute um 13:40 Uhr haben wir die Startscripts unserer qmail-Instanzen unter U6 gepatcht, nachdem bekannt geworden war, dass eine bis dahin als rein theoretische und in der Praxis wohl nicht ausnutzbare Lücke unter bestimmten Umständen eben doch ausnutzbar ist. (U7 ist hiervon nicht betroffen; dort ist die bekannt gewordene Lücke bereits anderweitig geschlossen worden.)
Das Problem ist um 16:04 Uhr behoben worden.
Der eigentlich simpel anmutende Patch, der dafür sorgt, dass qmail-Services mit einem Memory-Limit - wie von DJB propagiert 123456578 - gefahren werden, hatte leider auch zur Folge, dass zum Ausführen von qmail-remote nicht mehr genug Luft war. Während lokal zugestellte Mails nur temporär verzögert zugestellt worden sind, weil eine fehlgeschlagene Ausführung von qmail-local nur zu einem “deferral” führt, führt die fehlgeschlagene Ausführung von qmail-remote direkt zu einem “failure” und qmail generiert eine Bouncemail - die dann aus dem gleichen Grund nicht zustellbar ist. qmail erstellt daraufhin eine Mail an uns als Postmaster, die über die Unzustellbarkeit der Bouncemail informiert, und, richtig geraten, jene ist aus dem gleichen Grund nicht zustellbar gewesen. Damit wird die Mail als “triple bounce” abschließend verworfen und Mails, die wir nach draußen schicken wollten, unwiderruflich verloren - sowohl jene, die per Relaying rausgeschickt worden sind, als auch jene, deren lokale Zieladresse eine Weiterleitung darstellte.
Wir haben umgehend alle Logs aus diesem Zeitraum gesichert und werten diese aktuell aus, um zumindest Informationen zusammenstellen zu können, welche Mails konkret betroffen waren. Dieser Prozess dauert derzeit noch an. Die eigentlichen Mails sind aber in jedem Fall wirklich weg.
Update 18:43 Uhr
Wir haben aus allen gesicherten Logs mit Hilfe von qmailanalog Daten formatiert, die wir anschließend spezifisch nach Zustellungen durchsuchen konnten, die mit der Meldung Unable_to_run_qmail-remote abgebrochen sind. In einem zweiten Schritt gehen wir aktuell mittels eines zu diesem Zweck selbst verfassten Scripts diese Einträge durch und ermitteln anhand der Domain des Absenders oder Empfängers die Zuordnung zu einem spezifischen Uberspace. Dabei verteilen wir die entsprechenden Log-Zeilen in ein Log pro User, was dann dieses Format hat:
Tue May 26 15:30:00 2020 from=irgendwas@deinedomain.de to=irgendwas@externedomain.de
Tue May 26 15:45:00 2020 from=irgendwas@externedomain.de to=irgendwas@deinedomain.de
Sobald dieser Prozess auf allen Hosts durchgeführt wurde, werden wir die entsprechenden User unter Angabe jener Log-Einträge informieren.
Die Logfiles enthalten keinerlei Daten zu Mailheadern (also auch nicht zu Betreff oder Message-ID) oder Mailinhalten. Außer Zeitpunkt, Absender und Empfänger können wir insofern nicht mehr Informationen ermitteln.
Es gibt leider einen Fall, den wir hiermit nicht abdecken können, nämlich die Zustellung von externen Adressen, die über einen Uberspace ebenfalls an eine externe Adresse weitergeleitet werden. In diesem Fall haben wir dann zwar Log-Einträge mit jenen beiden (externen) Adressen, können allerdings im Nachhinein leider keine Zugehörigkeit zu einem bestimmten Uberspace mehr herstellen.
Update 19:00 Uhr
Zur Klarstellung: Das zugrundeliegende Problem war zum Zeitpunkt der Veröffentlichung des Blogposts bereits behoben; die Updates zu diesem Blogpost beziehen sich insofern lediglich auf unsere Analysen und Nacharbeiten.
Update 19:40 Uhr
Wir haben alle Log-Einträge, die wir eindeutig einem bestimmten Uberspace zuordnen konnten, extrahiert und haben alle betroffenen User per E-Mail unter Verweis auf diesen Blogpost informiert. Die entsprechenden Log-Einträge sind auch jeweils unter ~/logs/lost-mails.log im Uberspace der einzelnen User einsehbar. Findet sich dort kein Log dieses Namens, liegen uns entsprechend auch keine Log-Einträge vor, die wir dem betreffenden Account zuordnen konnten.