tessera-ctl/.planning/quick/260921-oxm-imap-starttls-wirklich-erzwingen-und-anh/260921-oxm-PLAN.md

phase, plan, type, autonomous, subsystem, requirements

phase	plan	type	autonomous	subsystem	requirements
quick-260921-oxm	01	tdd	true	apps/api/src/inbox

Quick-Aufgabe 260921-oxm: IMAP-STARTTLS wirklich erzwingen und Anhangs-Dateinamen richtig lesen

Ziel

Die beiden in 260921-m34 gemeldeten Befunde B-06 und B-05 in apps/api/src/inbox/imap.provider.ts beheben — mit Tests, die gegen den heutigen Stand rot sind, und ohne jede weitere Verhaltensaenderung.

Ausgangsmessung (vor der Arbeit, gemessen am 21.09.2026 auf ad83407)

Groesse	Wert
lint/suspicious/noExplicitAny in apps/api/src	15
lint/style/noNonNullAssertion in apps/api/src	56
as unknown as in apps/api/src	33
biome-ignore in apps/api/src	1
ts-expect-error / @ts-ignore	0

Aufgabe 1 — B-06: STARTTLS erzwingen (sicherheitsrelevant)

imapflow 1.4.3 deklariert doSTARTTLS?: boolean in ImapFlowOptions (lib/imap-flow.d.ts:81).

Test zuerst (rot): Zwei Faelle in imap.provider.spec.ts, die die an new ImapFlow(...) uebergebenen Optionen pruefen:

• encryption: 'starttls' ⇒ secure === false, doSTARTTLS === true, kein Feld requireTLS
• encryption: 'ssl-tls' ⇒ secure === true, doSTARTTLS !== true (Unvertraeglichkeit der Bibliothek: secure=true zusammen mit doSTARTTLS=true wirft)

Reparatur: requireTLS durch doSTARTTLS: config.encryption === 'starttls' ersetzen. Bei ssl-tls ergibt der Ausdruck false — das ist erlaubt und dokumentiert ("STARTTLS explicitly disabled by config", imap-flow.js:1210) und loest die Unvertraeglichkeit nicht aus, weil die nur bei doSTARTTLS === true zuschlaegt (imap-flow.js:1201).

Zusicherung: } as any am Ende von buildClient() faellt ersatzlos, sobald alle uebergebenen Felder deklariert sind. Danach pruefen.

Aufgabe 2 — B-05: Anhangs-Dateiname aus dem richtigen Feld

imapflow deklariert dispositionParameters?: { [key: string]: string } (lib/imap-flow.d.ts:450) und fuellt es in tools.js:887 mit kleingeschriebenen Schluesseln.

Test zuerst (rot): Ein application/octet-stream-Knoten, dessen dispositionParameters.filename auf .pdf endet, muss von fetchPdfAttachments() eingesammelt werden.

Reparatur: (node as any).disposition?.parameters?.filename durch den getypten Zugriff node.dispositionParameters?.filename ersetzen.

Verifikation

• pnpm type-check 4/4
• pnpm lint 5/5, keine Befunde der Schwere error
• apps/api mindestens 72 Dateien / 1143 Tests, apps/web 73/531
• Zaehler: as unknown as = 33, noNonNullAssertion = 56, biome-ignore = 1, ts-expect-error = 0, noExplicitAny < 15

Erfolgskriterien

• Beide Tests waren gegen den alten Stand nachweislich rot
• Keine Verhaltensaenderung ausser der in B-06 gewollten
• Keine neue Zusicherung, kein !, kein @ts-expect-error