Mail-Graveyard/review-snapshot-2026-07-16.md

Review — Snapshot (14-snapshot.go) + Streaming-Reindex

Geprueft von Claude am 2026-07-16 gegen den nicht-committeten Arbeitsstand.

Urteil

Der Snapshot ist richtig gebaut und darf so committet werden. Die Aenderung an normalizeMessageID darf NICHT ohne Fix ausgerollt werden.

Was gepasst hat

Die zwei Stellen, an denen ich Fehler erwartet habe, sind beide korrekt:

104:  DB.Exec(`VACUUM INTO ?`, databasePath)               // erst der Schnappschuss
120:  collectSnapshotWatermarks(snapshotDB, Cfg.MboxRoot)  // dann N DARAUS
      MAX(i.file_offset+i.frame_len)                       // richtige Wasserlinie
327:  os.Stat(...) -> info.Size() < watermark.Bytes        // stat nur als Notbremse

• indexed_bytes kommt nirgends vor (die Falle aus backup-brief.md).
• Reihenfolge stimmt; stat leitet N nicht ab, sondern verweigert nur.
• Zeile 145 bricht ab, wenn indizierte und abgebildete Datensaetze auseinander- laufen. Das stand nicht im Brief und ist besser als verlangt.
• Pfad-Ausbruchspruefung (relative == "..") vorhanden.
• snapshotPathKey senkt nur unter Windows auf Kleinschreibung — richtig herum: auf Linux sind Drafts und drafts zwei echte Dateien und duerfen nicht kollidieren, unter Windows wuerden sie es.
• Streaming-Reindex (06-mbox.go:293) liest nachrichtenweise ueber bufio statt 9,4 GB in den RAM.

Die Message-ID-Erhaltung im Reindex ist entgegen meinem ersten Verdacht sauber:

if storedIdentity.bodySHA256 != "" && storedIdentity.bodySHA256 == entry.BodySHA256 {
    entry.MessageID = storedIdentity.messageID
}

Die Position ist nur der Nachschlage-Schluessel, der Body-Hash ist die Bedingung. Eine falsche Zuordnung kann keine falsche Uebernahme ausloesen.

Nachgeprueft am realen Snapshot archive-20260716-2250: 228 Archivdateien, mbox_index 121.861 im Snapshot und in Produktion, 121.861 praezise copied-Identitaeten, integrity_check=ok. go vet sauber, go test -count=1 ./backend/ gruen (0,366s).

---

BEFUND 1 — Identitaetsaenderung, Dublettenrisiko (Blocker fuer Rollout)

 func normalizeMessageID(id string) string {
-	return strings.Trim(strings.TrimSpace(id), "<>")
+	if start := strings.IndexByte(id, '<'); start >= 0 { ... }

normalizeMessageID speist message_id = die halbe Identitaet. Alt und neu gegen die echten gespeicherten Werte verglichen (lauffaehig nachgestellt):

<476BDFDB019289BE@mail21.bluewin.ch> (added by postmaster@bluewin.ch)
  alt: [476BDFDB019289BE@mail21.bluewin.ch> (added by postmaster@bluewin.ch)]
  neu: [476BDFDB019289BE@mail21.bluewin.ch]                    <<< WEICHT AB

<22578196653698419217.BB8A0E8F48F3F290@dr-gold.de>+D271B1409C3C6028
  alt: [22578196653698419217.BB8A0E8F48F3F290@dr-gold.de>+D271B1409C3C6028]
  neu: [22578196653698419217.BB8A0E8F48F3F290@dr-gold.de]      <<< WEICHT AB

<1280874184.3726.1662111901550.JavaMail."LOCAL SERVICE"@DESV226350>   gleich
<476FE4C5.2060001@yahoo.com;Evy O'Brien>                             gleich
<13140-22021132765855760@strepack.de>                                gleich
13140-22021132765855760@strepack.de                                  gleich

Nur Werte mit einem verirrten > im Inneren aendern sich. Umfang gemessen: 3 Zeilen in copied, 2 in mbox_index von 121.861.

Warum die Reindex-Erhaltung nicht reicht: Sie schuetzt den Index, nicht den Live-Pfad. Dort gilt:

1. Praezise Abfrage message_id=NEU AND body_sha256=X → gespeichert ist ALT → kein Treffer.
2. Die Alias-Schleife hilft nicht: LegacyMessageID wird in identityForRawMessage ebenfalls mit der neuen Funktion gebildet (id := normalizeMessageID(...); legacyID := id) — sie traegt die alte Normalisierung nicht.
3. Ergebnis: CopyState{} → nicht kopiert → erneutes mbox.Append UND erneutes dst.Append.

Beim ersten Nachtlauf nach dem Rollout entstehen so 3 Dubletten in beiden Haelften — lautlos. Klein, aber es ist dieselbe Klasse wie die 4.024 Waisen, und Dubletten sind unsere Stopp-Bedingung.

Zwei Wege, Empfehlung (a)

(a) Alte Normalisierung als zusaetzlichen Alias fuehren. identityForRawMessage bekommt zusaetzlich den alt-normalisierten Wert; die Alias-Schleife in GetCopyIdentityStateWithFolderAlias muss ihn dann auch gegen praezise Zeilen pruefen, nicht nur gegen body_sha256=''. Additiv, mutiert keine Geschichte, nutzt vorhandene Maschinerie. Passt zur Linie „Aliase sind Rueckrollschutz".

(b) Einmal-Migration der 5 Zeilen auf den neuen Wert. Simpler, aber schreibt Geschichte um — und die Regel lautet: Aliase nicht ohne gesonderte, geprueefte Bereinigung anfassen.

Abnahme fuer den Fix

1. Lauf gegen ein Konto mit einer der beiden IDs: archived=0. Ein zweiter Lauf danach ebenfalls archived=0.
2. SELECT COUNT(*) FROM mbox_index WHERE message_id LIKE '%>%' bleibt bei 2 — nicht 4.
3. Test mit genau diesen zwei Roh-Headern als Fixture.

---

BEFUND 2 — Snapshot-DB world-readable (klein, aber schnell zu beheben)

600 root:root  .../backup/colak@dr-gold.de/INBOX.mbox   <- richtig
644 root:root  .../data/mail-graveyard.db               <- zu offen

Die Snapshot-DB enthaelt 23 Quell- und 23 Ziel-Passwoerter im Klartext. Heute schuetzt nur die 0700-Wurzel darueber — ein chmod von der Preisgabe entfernt, und inkonsistent zu den mbox-Dateien daneben. Bitte 0600.

---

Nicht deins

gofmt -l meldet backend/11-folders.go. Die Datei ist im Diff unveraendert (Altbestand), reine Ausrichtung einer Map. Kein Rollout-Hindernis.

Weiterhin offen (unveraendert aus backup-brief.md)

• Der Snapshot liegt auf derselben Platte — er ist die Vorstufe, nicht das Backup. Raeumlich getrennte, verschluesselte Kopie fehlt.
• Restore-Test gehoert wiederholt gefahren, nicht einmal.