kimi.md: E2E-Registrierung verifiziert, Bounce-Loop-Fix im Mail-Relay dokumentiert

kimi.md

@@ -885,3 +885,11 @@ Zustellung an axel@hocks.eu status=sent, Test-Ticket bereinigt.
 - Fix: Backend sendet jetzt `Cache-Control: no-store` auf allen API-Responses — der heuristische Browser-Cache lieferte sonst nach Reload veraltete Daten (aufgetreten: gelöschte Registrierungscodes wurden weiter angezeigt). mp-api manuell neu gebaut, Header live verifiziert.
 - nginx-Cache-Optimierung: Bilder/Schriftarten im Root (logo.png etc., nicht hash-benannt) erhalten jetzt `Cache-Control: public, max-age=86400` (vorher keine Header → heuristischer Cache). `/assets/` mit `^~` markiert, damit das neue Regex die immutable-Regel nicht überschreibt. Template im Repo und auf dem Server synchron, mp-portal neu erstellt, alle Header live verifiziert.
 
+## 2026-10-07 — E2E-Test Registrierung + Bounce-Loop-Fix im Mail-Relay
+
+- UAT durchgespielt (laut Anleitung): Admin-Login → Code erzeugen (st-toeniser-we5/we6, prinzferdinand-we7) → Registrierung als Test-Mieter → Benutzer mit Wohnungszuordnung angelegt, Code verbraucht, Login mit Wahl-Passwort ok, Benachrichtigung an axel@hocks.eu UND joseph@hinterstein-immo.de jeweils `status=sent` (M365). Testdaten (3 User, Sessions, Codes) aufgeräumt.
+- Dabei entdeckt: **chronischer Bounce-Loop im mp-postfix** — NDRs an die nicht existente Absenderadresse noreply@hocks.eu wurden an M365 relayt (550 Access denied), erzeugten neue NDRs; Dutzende Logzeilen pro Sekunde, json-File des Containers rotierte weg (deshalb waren frühere Mails nicht mehr nachweisbar). Vermutlich seit 4.10. (letzte saubere Zustellungen 14:29).
+- Fix im mp-postfix-Image (`/opt/mp-mail/postfix/`, nur auf Server): `virtual_alias_maps = lmdb:/etc/postfix/virtual` mit `noreply@hocks.eu → axel@hocks.eu` — NDRs landen im echten Postfach, Loop unterbrochen. **Alpine-Gotcha:** postfix erzeugt `virtual.lmdb`, nicht `virtual.db` (hash nicht ohne Paket postfix-hash; Default-Dict ist lmdb). Queue geleert, Container neu gebaut.
+- Bekannte Lücke (nicht behoben): Mail-Versand aus der API ist fire-and-forget ohne Retry bei RCPT-Zeit-Fehlern (mail-api fängt nur OSError; smtplib.SMTPRecipientsRefused → Mail geht verloren, 451/550 beim Relay). Beim Test mit kaputter virtual-Map aufgetreten.
+- HINWEIS: sfg-mail (Schulportal, /opt/sfg-mail/postfix) hat denselben Aufbau (sender_canonical → noreply@hocks.eu) — dort ggf. denselben Loop prüfen/nachrüsten. Queue aktuell leer.
+