Dateien nach "/" hochladen
This commit is contained in:
@@ -1,11 +1,12 @@
|
||||
# SMTPGraphRelay 1.7.0
|
||||
# SMTPGraphRelay 1.8.0
|
||||
|
||||
SMTPGraphRelay V1.7 ergänzt optionales lokales SMTP-AUTH für interne Clients.
|
||||
V1.8 ergänzt zwei Betriebsfunktionen:
|
||||
|
||||
> **Hinweis:** `AUTH LOGIN` und `AUTH PLAIN` werden hier bewusst ohne TLS angeboten,
|
||||
> weil dieses Relay für vertrauenswürdige interne Netze gedacht ist. Die Zugangsdaten
|
||||
> sind auf dem Netzwerkpfad daher nur Base64-kodiert, nicht verschlüsselt. Die
|
||||
> bestehende IP-Allowlist sollte weiterhin restriktiv gesetzt bleiben.
|
||||
- Failed-Queue-Verwaltung im Setup-/Manager
|
||||
- kooperativer Graceful Shutdown für Update, Repair und manuelles Stoppen über den Manager
|
||||
|
||||
Alle Funktionen aus V1.7 bleiben erhalten, insbesondere SMTP AUTH LOGIN/PLAIN,
|
||||
Queue-ID, Retry/Backpressure, Zertifikatsrotation, Health Check und Online-Update.
|
||||
|
||||
## Installation
|
||||
|
||||
@@ -15,234 +16,141 @@ SMTPGraphRelay V1.7 ergänzt optionales lokales SMTP-AUTH für interne Clients.
|
||||
$u='https://me-gitea.maieredv.cloud/MAIEREDV/SMTPGraphRelay/raw/branch/main/Setup-SMTPGraphRelay.ps1';$f="$env:TEMP\Setup-SMTPGraphRelay.ps1";Invoke-WebRequest $u -UseBasicParsing -OutFile $f;& $f
|
||||
```
|
||||
|
||||
## Neu in V1.7: SMTP AUTH
|
||||
## Failed Queue verwalten
|
||||
|
||||
Unterstützt:
|
||||
Im Manager:
|
||||
|
||||
```text
|
||||
AUTH LOGIN
|
||||
AUTH PLAIN
|
||||
```
|
||||
|
||||
EHLO bewirbt die Mechanismen, sobald mindestens ein SMTP-Benutzer existiert:
|
||||
|
||||
```text
|
||||
250-AUTH LOGIN PLAIN
|
||||
```
|
||||
|
||||
Erfolgreiche Anmeldung:
|
||||
|
||||
```text
|
||||
235 2.7.0 Authentication successful
|
||||
```
|
||||
|
||||
Fehlgeschlagene Anmeldung:
|
||||
|
||||
```text
|
||||
535 5.7.8 Authentication credentials invalid
|
||||
```
|
||||
|
||||
Wenn AUTH für den Client erforderlich ist:
|
||||
|
||||
```text
|
||||
530 5.7.0 Authentication required
|
||||
```
|
||||
|
||||
Nach standardmäßig fünf Fehlversuchen innerhalb derselben Verbindung werden
|
||||
weitere AUTH-Versuche temporär abgewiesen:
|
||||
|
||||
```text
|
||||
454 4.7.0 Too many authentication failures
|
||||
```
|
||||
|
||||
## IP-Allowlist bleibt vorgeschaltet
|
||||
|
||||
SMTP-AUTH ersetzt die bestehende `AllowedNetworks`-Prüfung **nicht**.
|
||||
|
||||
Ein Client muss zuerst aus einem erlaubten Netz kommen. Erst danach kann er sich
|
||||
optional bzw. verpflichtend authentifizieren.
|
||||
|
||||
AUTH kann daher niemals einem ansonsten nicht erlaubten Host Zugriff verschaffen.
|
||||
|
||||
## Passwortspeicherung
|
||||
|
||||
SMTP-Passwörter werden nicht im Klartext gespeichert.
|
||||
|
||||
Verwendet wird:
|
||||
|
||||
```text
|
||||
PBKDF2-HMAC-SHA256
|
||||
Salt: 16 Byte zufällig
|
||||
Iterations: 150000
|
||||
Hash: 32 Byte
|
||||
```
|
||||
|
||||
Beispiel in `config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"Username": "scanner01",
|
||||
"Salt": "...",
|
||||
"PasswordHash": "...",
|
||||
"Iterations": 150000
|
||||
}
|
||||
```
|
||||
|
||||
## Konfiguration
|
||||
|
||||
```json
|
||||
"Smtp": {
|
||||
"RequireAuth": true,
|
||||
"AuthMaxFailures": 5,
|
||||
"AllowUnauthenticatedNetworks": [
|
||||
"10.60.10.0/24"
|
||||
],
|
||||
"AuthUsers": [
|
||||
{
|
||||
"Username": "scanner01",
|
||||
"Salt": "...",
|
||||
"PasswordHash": "...",
|
||||
"Iterations": 150000
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### RequireAuth
|
||||
|
||||
```text
|
||||
false
|
||||
```
|
||||
|
||||
AUTH ist optional. Clients aus `AllowedNetworks` dürfen weiterhin ohne
|
||||
Benutzername/Passwort senden.
|
||||
|
||||
```text
|
||||
true
|
||||
```
|
||||
|
||||
Clients müssen sich authentifizieren, außer ihre IP liegt in
|
||||
`AllowUnauthenticatedNetworks`.
|
||||
|
||||
### AllowUnauthenticatedNetworks
|
||||
|
||||
Beispiel:
|
||||
|
||||
```json
|
||||
[
|
||||
"10.60.10.0/24",
|
||||
"192.168.50.10"
|
||||
]
|
||||
```
|
||||
|
||||
Diese Hosts/Netze dürfen trotz `RequireAuth=true` ohne AUTH senden.
|
||||
|
||||
Sie müssen trotzdem zusätzlich durch `AllowedNetworks` erlaubt sein.
|
||||
|
||||
## Benutzerverwaltung
|
||||
|
||||
Im Setup-/Manager gibt es jetzt:
|
||||
|
||||
```text
|
||||
[9] SMTP-AUTH verwalten
|
||||
[10] Failed Queue verwalten
|
||||
```
|
||||
|
||||
Untermenü:
|
||||
|
||||
```text
|
||||
[1] SMTP-AUTH erforderlich EIN/AUS
|
||||
[2] Benutzer hinzufügen
|
||||
[3] Benutzer anzeigen
|
||||
[4] Passwort ändern
|
||||
[5] Benutzer löschen
|
||||
[6] Netze ohne Auth verwalten
|
||||
[7] Max. Fehlversuche ändern
|
||||
[1] Failed Queue anzeigen
|
||||
[2] Details einer Mail anzeigen
|
||||
[3] Eine Mail erneut zustellen
|
||||
[4] Alle Mails erneut zustellen
|
||||
[5] Eine Mail endgültig löschen
|
||||
[6] Alle Failed-Mails endgültig löschen
|
||||
[0] Zurück
|
||||
```
|
||||
|
||||
Beim Hinzufügen bzw. Ändern eines Passworts erfolgt die Eingabe verdeckt.
|
||||
|
||||
## Graph-Sender bleibt unabhängig
|
||||
|
||||
Der SMTP-Benutzer dient ausschließlich zur Authentifizierung am lokalen Relay.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
SMTP AUTH: scanner01
|
||||
MAIL FROM: scanner@device.local
|
||||
|
|
||||
v
|
||||
SMTPGraphRelay
|
||||
|
|
||||
ForceSender=true
|
||||
|
|
||||
v
|
||||
info@example.com
|
||||
```
|
||||
|
||||
AUTH verändert weder die Entra-App noch das Graph-Zertifikat oder
|
||||
`Graph.SenderMailbox`.
|
||||
|
||||
## Queue-Metadaten
|
||||
|
||||
Bei authentifizierten Einlieferungen wird der Benutzer zusätzlich in den
|
||||
Queue-Metadaten gespeichert:
|
||||
|
||||
```json
|
||||
"AuthenticatedUser": "scanner01"
|
||||
```
|
||||
|
||||
und im Log ausgegeben:
|
||||
|
||||
```text
|
||||
[7F3A91C2D441] Mail angenommen | ... | Auth=scanner01
|
||||
```
|
||||
|
||||
Bei nicht authentifizierten, aber erlaubten Verbindungen:
|
||||
|
||||
```text
|
||||
Auth=unauthenticated
|
||||
```
|
||||
|
||||
## Health Check
|
||||
|
||||
Der Health Check validiert zusätzlich die SMTP-AUTH-Konfiguration.
|
||||
|
||||
Eine Testmail kann weiterhin mit:
|
||||
|
||||
```powershell
|
||||
.\Test-SMTPGraphRelay.ps1 -SendTestMail -TestRecipient "user@example.com"
|
||||
```
|
||||
|
||||
ausgeführt werden.
|
||||
|
||||
Ist AUTH erforderlich, fragt der Health Check bei Bedarf Benutzername und
|
||||
Passwort interaktiv ab.
|
||||
|
||||
Optional:
|
||||
|
||||
```powershell
|
||||
.\Test-SMTPGraphRelay.ps1 `
|
||||
-SendTestMail `
|
||||
-TestRecipient "user@example.com" `
|
||||
-SmtpUsername "scanner01"
|
||||
```
|
||||
|
||||
Das Passwort wird weiterhin verdeckt abgefragt.
|
||||
|
||||
## V1.6 Funktionen bleiben erhalten
|
||||
Die Übersicht zeigt u. a.:
|
||||
|
||||
- Queue-ID
|
||||
- Received-Header
|
||||
- automatische Message-ID
|
||||
- MaxRecipients
|
||||
- MaxMessagesPerConnection
|
||||
- MaxPendingMessages
|
||||
- MinFreeDiskSpaceMB
|
||||
- Queue-/Disk-Backpressure
|
||||
- parallele SMTP-Clients
|
||||
- Graph-Retry
|
||||
- Log-Rotation
|
||||
- Zertifikatsüberwachung
|
||||
- Online-Update / Repair / Rollback
|
||||
- Zeitpunkt
|
||||
- RetryCount
|
||||
- Envelope-From
|
||||
- Empfänger
|
||||
- letzten HTTP-/Graph-Status
|
||||
- Größe
|
||||
|
||||
In den Details steht zusätzlich die letzte Fehlermeldung und – falls vorhanden –
|
||||
der SMTP-AUTH-Benutzer.
|
||||
|
||||
### Requeue
|
||||
|
||||
Beim erneuten Zustellen wird die `.eml` samt Metadaten von `failed` nach
|
||||
`queue\pending` verschoben.
|
||||
|
||||
Dabei werden:
|
||||
|
||||
```text
|
||||
RetryCount = 0
|
||||
NextAttemptUtc = jetzt
|
||||
RequeuedUtc = jetzt
|
||||
```
|
||||
|
||||
gesetzt. Die alte Fehlerbeschreibung bleibt in den Metadaten erhalten, bis ein
|
||||
neuer Versandversuch sie aktualisiert.
|
||||
|
||||
Der laufende Queue-Worker nimmt die Mail anschließend automatisch wieder auf.
|
||||
|
||||
## Graceful Shutdown
|
||||
|
||||
Update und Repair verwenden nicht mehr zuerst `Stop-ScheduledTask`.
|
||||
|
||||
Stattdessen erstellt der Manager:
|
||||
|
||||
```text
|
||||
C:\Program Files\SMTPGraphRelay\shutdown.request
|
||||
```
|
||||
|
||||
Der Relay erkennt das Signal kurzfristig und führt diesen Ablauf aus:
|
||||
|
||||
```text
|
||||
Shutdown angefordert
|
||||
|
|
||||
v
|
||||
SMTP-Listener schließen
|
||||
|
|
||||
+--> keine neuen Verbindungen mehr
|
||||
|
|
||||
v
|
||||
laufende SMTP-Sessions auslaufen lassen
|
||||
|
|
||||
v
|
||||
Queue-/Graph-Worker beendet aktuellen Versand
|
||||
|
|
||||
+--> startet keine weitere Queue-Mail
|
||||
|
|
||||
v
|
||||
Runspaces schließen
|
||||
|
|
||||
v
|
||||
Graph-Verbindung trennen
|
||||
|
|
||||
v
|
||||
Relay beendet sich selbst
|
||||
```
|
||||
|
||||
Standard-Timeout:
|
||||
|
||||
```json
|
||||
"Smtp": {
|
||||
"GracefulShutdownSeconds": 30
|
||||
}
|
||||
```
|
||||
|
||||
Zulässiger Bereich:
|
||||
|
||||
```text
|
||||
5 bis 300 Sekunden
|
||||
```
|
||||
|
||||
Wenn der Relay innerhalb dieses Zeitraums nicht selbst beendet ist, verwendet
|
||||
der Manager als Fallback einen harten `Stop-ScheduledTask`.
|
||||
|
||||
Beim nächsten Start wird ein eventuell altes `shutdown.request` vorsorglich
|
||||
entfernt.
|
||||
|
||||
## Warum das für Updates wichtig ist
|
||||
|
||||
Ein Update/Repair kann damit nicht mehr unnötig mitten in:
|
||||
|
||||
- einer SMTP-DATA-Übertragung
|
||||
- einer aktiven SMTP-Session
|
||||
- oder einem laufenden Graph-sendMail-Aufruf
|
||||
|
||||
den Prozess beenden.
|
||||
|
||||
Wenn ein Client oder Graph länger als das konfigurierte Grace-Timeout hängt,
|
||||
wird nach Ablauf des Timeouts kontrolliert auf den bisherigen harten Stop
|
||||
zurückgefallen.
|
||||
|
||||
## Manager
|
||||
|
||||
```text
|
||||
[1] Neuinstallation aus Gitea
|
||||
[2] Installation aus Gitea reparieren
|
||||
[3] Nach Online-Updates suchen
|
||||
[4] Entra / Exchange RBAC prüfen
|
||||
[5] Zertifikat erneuern
|
||||
[6] Health Check ausführen
|
||||
[7] Deinstallieren
|
||||
[8] Status anzeigen
|
||||
[9] SMTP-AUTH verwalten
|
||||
[10] Failed Queue verwalten
|
||||
[0] Beenden
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user