diff --git a/apps/api/src/inbox/imap.provider.ts b/apps/api/src/inbox/imap.provider.ts index e356c09..f6b96f6 100644 --- a/apps/api/src/inbox/imap.provider.ts +++ b/apps/api/src/inbox/imap.provider.ts @@ -62,20 +62,14 @@ function collectPdfParts( const type = node.type?.toLowerCase() ?? ''; // Some mail clients (e.g. Outlook) send PDFs as application/octet-stream. // Fall back to checking the filename from Content-Disposition or Content-Type parameters. - // BLEIBT als any, mit Befund (260921-m34, Aufgabe 3c, D-01/D-03): - // imapflow deklariert `disposition` als ZEICHENKETTE (imap-flow.d.ts:448, - // also "attachment"/"inline"), und die zugehoerigen Parameter liegen in - // einem eigenen Feld `dispositionParameters` (:450). Der Ausdruck unten - // liest `.parameters` von einer Zeichenkette und ist damit zur Laufzeit - // IMMER undefined — dispositionFilename ist stets ''. Das ist ein Befund - // im Bestandscode, kein Typproblem: ihn hier auf `dispositionParameters` - // umzubiegen waere eine Verhaltensaenderung (Outlook-Anhaenge als - // application/octet-stream wuerden ab dann erstmals erkannt), und die ist - // in dieser Aufgabe verboten. Gemeldet im SUMMARY, Entscheidung beim - // Menschen. Die Zusicherung bleibt sichtbar stehen, damit der Befund - // nicht verschwindet. - const dispositionFilename = - ((node as any).disposition?.parameters?.filename as string | undefined)?.toLowerCase() ?? ''; + // Repariert in 260921-oxm (Befund B-05 aus 260921-m34): hier stand zuvor + // `disposition?.parameters?.filename`, auf einem zu any umgedeuteten Knoten. + // imapflow deklariert `disposition` aber als ZEICHENKETTE (imap-flow.d.ts:448, also + // "attachment"/"inline") und legt die zugehoerigen Parameter in ein eigenes + // Feld `dispositionParameters` (:450, gefuellt in tools.js:887 mit + // kleingeschriebenen Schluesseln). Der alte Ausdruck las `.parameters` von + // einer Zeichenkette und war zur Laufzeit IMMER undefined. + const dispositionFilename = node.dispositionParameters?.filename?.toLowerCase() ?? ''; // Hier dagegen war die Zusicherung schlicht ueberfluessig: imapflow // deklariert `parameters?: { [key: string]: string }` (imap-flow.d.ts:438). const typeFilename = node.parameters?.name?.toLowerCase() ?? ''; @@ -383,22 +377,21 @@ export class ImapProvider implements InboxProvider { port: config.port, // ssl-tls = implicit TLS (port 993); starttls = STARTTLS upgrade (port 143) secure: config.encryption === 'ssl-tls', - requireTLS: config.encryption === 'starttls', + // Repariert in 260921-oxm (Befund B-06 aus 260921-m34): hier stand zuvor + // `requireTLS`, eine Option, die imapflow 1.4.3 nirgends kennt und still + // verwirft. Die Bibliothek heisst sie `doSTARTTLS` (imap-flow.d.ts:81). + // true -> vor der Anmeldung auf TLS hochstufen; scheitert, wenn der + // Server kein STARTTLS anbietet (imap-flow.js:1183) + // false -> STARTTLS ausdruecklich aus (imap-flow.js:1210); bei ssl-tls + // ist das noetig, weil secure=true zusammen mit + // doSTARTTLS=true ungueltig waere (imap-flow.js:1201) + doSTARTTLS: config.encryption === 'starttls', auth: config.username ? { user: config.username, pass: config.password ?? '' } : undefined, // T-07-03: suppress imapflow verbose logs — they include auth credentials logger: false, - // BLEIBT als Zusicherung, mit Befund (260921-m34, Aufgabe 3c, D-03): - // `requireTLS` oben kommt in imapflow 1.4.3 NIRGENDS vor — weder in - // ImapFlowOptions (lib/imap-flow.d.ts) noch im Laufzeitcode - // (lib/imap-flow.js), beides durchsucht. Die Option wird also still - // verworfen; STARTTLS wird nicht durch sie erzwungen. Genau diese - // Zusicherung hat das bisher verdeckt. Sie bleibt trotzdem stehen: - // die Option zu entfernen waere eine stille Reparatur einer falschen - // Annahme (verboten), und der `any`-Befund haelt die Stelle in der - // Zaehlung sichtbar, bis ein Mensch entscheidet. Gemeldet im SUMMARY. - } as any); + }); } }