SMTPGraphRelay V1.2 – Queue & Retry

Diese Version ersetzt nur SMTPGraphRelay.ps1. Die bestehende config.json, Entra-App, das Zertifikat und Exchange Application RBAC bleiben unverändert.

Neue Queue-Struktur

queue\
├── incoming\
├── pending\
└── processing\

failed\

• incoming: Mail wird gerade atomar geschrieben.
• pending: vollständig angenommene und sendbare Mail.
• processing: aktuell durch den Worker bearbeitet.
• failed: permanent fehlgeschlagene oder nach MaxRetries aufgegebene Mail.

Beim Start werden alte V1-Mails direkt aus queue\ nach pending\ migriert. Mails, die nach einem Absturz noch in processing\ liegen, werden nach pending\ zurückgestellt.

Retry

• HTTP 429: Retry-After wird verwendet; fehlt es, exponentielles Backoff.
• HTTP 408 und 5xx: Retry nach RetryMinutes aus config.json.
• Netzwerk-/Transportfehler ohne HTTP-Code: Retry.
• typische permanente 4xx wie 400/401/403/404/413/415/422: direkt nach failed.
• nach MaxRetries: nach failed.

Installation über bestehende Version

1. Scheduled Task stoppen:

Stop-ScheduledTask -TaskName "SMTPGraphRelay"

2. Bestehendes SMTPGraphRelay.ps1 sichern.
3. SMTPGraphRelay-V1.2.ps1 als SMTPGraphRelay.ps1 in den Programmordner kopieren.
4. Task starten:

Start-ScheduledTask -TaskName "SMTPGraphRelay"

5. Log prüfen:

Get-Content "C:\Program Files\SMTPGraphRelay\logs\SMTPGraphRelay.log" -Tail 100

Hinweis zu 202 Accepted

Microsoft Graph sendMail liefert bei erfolgreicher Annahme 202 Accepted. Das bedeutet, dass Graph die Nachricht angenommen hat, aber nicht, dass die endgültige Zustellung bereits abgeschlossen ist.

Eine absolut garantierte Exactly-Once-Zustellung kann ein SMTP→Graph-Gateway nicht sicherstellen: Falls Graph die Mail bereits angenommen hat und der lokale Prozess exakt vor dem Löschen der Queue-Datei abstürzt, kann ein erneuter Versuch theoretisch ein Duplikat erzeugen. V1.2 reduziert dieses Risiko durch die Processing-Queue, kann es aber nicht vollständig eliminieren.