# Abnahme im Browser — 2026-09-09

Durchgefuehrt auf **alpha** (https://alpha.tessera.ctl.de) gegen den echten
Exchange-Server `owa.ctl.de`, nachdem die Container mit dem neuen Image neu
erstellt wurden. Schliesst WINDOWS.md **#16**.

## Voraussetzung: Container tatsaechlich getauscht

Der blosse `pull` genuegte nicht — die Container liefen 41 Stunden alt weiter.
Hart belegt statt vermutet: die neue Route war im gezogenen Image vorhanden und
im laufenden Container nicht.

```
laufender Container: grep "email-config/test" /app/apps/api/dist  → nichts
neues Image:         grep "email-config/test" /app/apps/api/dist  → 3 Treffer
```

Nach `docker compose up -d --force-recreate api web` ist die Route gemappt:

```
[RouterExplorer] Mapped {/modules/tender-radar/email-config/test, POST} route
```

## Die vier Abnahmepunkte

| # | Pruefung | Ergebnis |
|---|----------|----------|
| 1 | Gespeicherte Konfiguration, **Passwortfeld leer** | **"Verbindung erfolgreich"** — belegt zugleich den Rueckgriff auf die gespeicherten verschluesselten Zugangsdaten, denn das Passwort wird nie an die Oberflaeche zurueckgegeben |
| 2 | Absichtlich falscher Server (`owa-gibtsnicht.ctl.de`) | **"Verbindung fehlgeschlagen: getaddrinfo ENOTFOUND owa-gibtsnicht.ctl.de"** — rot, mit der echten Meldung |
| 3 | Zugangsdaten im API-Protokoll | **keine.** Die drei Treffer einer Mustersuche waren Routennamen beim Start (`/auth/reset-password` und Geschwister), keine Daten |
| 4 | Schreibt der Test etwas? | **nein** — die gespeicherte Konfiguration war nach beiden Laeufen unveraendert |

Belege: `uat-2026-09-09/w16-verbindung-erfolgreich.png`,
`uat-2026-09-09/w16-verbindung-fehlgeschlagen.png`

## Nebenbefund mit Gewicht: der EWS-Weg laeuft gegen den echten Server

Das API-Protokoll des erfolgreichen Laufs zeigt eine **echte Antwort von Exchange
2019**, nicht von einer Attrappe:

```
[ExchangeInboxProvider] EWS FindFolder response for "DKV":
  <s:Header><h:ServerVersionInfo MajorVersion="15" MinorVersion="2"
  MajorBuildNumber="2562" MinorBuildNumber="46" .../></s:Header>
[ExchangeInboxProvider] EWS FindFolder: resolved "DKV" → FolderId AAAQAGtzY2hhbGxlckBj…
```

Damit ist der handgeschriebene NTLM/SOAP-Weg erstmals gegen einen echten
Exchange-Server gemessen: Anmeldung, `FindFolder` und Ordneraufloesung
funktionieren. Genau dieser Verbindungsaufbau war in Plan 14-03 als
"documented-fragile" markiert und bisher nur gegen gemocktes `httpntlm.post`
geprueft.

## Ausdruecklich NICHT belegt

Das Einlesen einer echten Alarm-Mail (WINDOWS #12). Dafuer gibt es intern derzeit
kein Postfach, in das Ausschreibungs-Alarme hereinkommen — Entscheidung des Users
vom 2026-09-09, der Punkt ist im Ledger zurueckgestellt. Der hier gepruefte Ordner
`DKV` enthaelt Tankkarten-Rechnungen und diente nur als erreichbares Ziel fuer den
Verbindungsaufbau.

## Beobachtung fuer spaeter (kein Mangel)

Der `ExchangeInboxProvider` schreibt die vollstaendige SOAP-Antwort als
DEBUG-Zeile ins Protokoll. Das ist sehr gespraechig; Zugangsdaten stehen nicht
darin, aber vor einem Produktivbetrieb waere zu ueberlegen, ob diese Ausgabe dort
noch sinnvoll ist.