Einstellungen im Detail.

Einstellungen im Detail

Microsoft 365

SMTP-Listener

Transportverschlüsselung

Ob ein Listener-Port unverschlüsselt, mit STARTTLS oder mit implizitem TLS arbeitet, stellen Sie beim jeweiligen Listener ein. Das Zertifikat dazu hat einen eigenen Abschnitt, weil es für alle Dienste dieses Rechners gilt: Alles Weitere steht im Kapitel Zertifikate.

Datenschutz im Mail-Protokoll

Retention

Log-Dateien und Mail-Tracker-DB haben getrennte Aufbewahrungszeiten. Beide Felder nutzen dasselbe Sentinel-Schema:

• -1 = Nicht speichern (komplett deaktiviert)
• 0 = Unbegrenzt (nie automatisch löschen)
• N > 0 = N Tage, danach wird automatisch gelöscht

Vordefinierte Optionen: 7 / 14 / 30 / 60 / 90 / 180 / 365 Tage. Defaults sind 7 Tage (Logs) und 14 Tage (Mail-Tracker).

Zustellung an Microsoft 365

Scheitert die Übergabe einer Mail an Microsoft 365, versucht SMTPly es wiederholt. Unter Wie lange erneut versuchen (Minuten) legen Sie fest, wie lange — erst danach gilt die Mail als unzustellbar. Der Standard von 55 Minuten überbrückt einen kurzen Internetausfall; bei Leitungen, die öfter länger ausfallen, setzen Sie den Wert höher. Die Einstellung gilt für alle Tenants gemeinsam und steht deshalb bei Microsoft 365, nicht beim SMTP-Listener: Wiederholt wird die Übergabe an Microsoft, nicht der Empfang per SMTP.

Die Wartezeiten zwischen den Versuchen sind fest (10 Sekunden, 30 Sekunden, danach alle zwei Minuten). Erreichbar sind daher nur bestimmte Werte; ein Zwischenwert wird auf den nächstliegenden gerundet, die Abweichung beträgt höchstens eine Minute. Eine Drosselung durch Microsoft (HTTP 429) und ein geöffneter Circuit Breaker laufen unabhängig davon weiter — sie zählen nicht gegen dieses Fenster.

Sicherung: Passphrase und Sofort-Test

Die Backup-Passphrase wird zweimal eingegeben. Das ist kein Formalismus: Ein Tippfehler fiele sonst erst auf, wenn das Backup gebraucht wird — und dann lässt sich die Datei nicht mehr öffnen, weil niemand mehr weiß, was tatsächlich eingegeben wurde.

Mit Backup jetzt erstellen legen Sie sofort eine Sicherung im eingestellten Ordner ab, ohne auf den geplanten Lauf zu warten. Erzeugt wird dieselbe Datei wie beim geplanten Export. Der E-Mail-Versand wird dabei nicht mitgeprüft, weil er im Dienst läuft.

Fenstergröße und Bedienung

SMTPly merkt sich Größe und Position des Fensters über einen Neustart hinweg. Liegt die gespeicherte Position auf keinem vorhandenen Bildschirm mehr — etwa nach dem Abziehen eines zweiten Monitors oder in einer RDP-Sitzung mit anderer Auflösung —, wird sie verworfen und das Fenster erscheint wieder mittig.

Die Oberfläche lässt sich ohne Maus bedienen: Strg + 1 bis 8 wechseln zwischen Dashboard, Maillog, System-Log, Mailfluss, Einstellungen, Lizenz, Über und Mailfluss mit Regel-Tester, Strg + , öffnet die Einstellungen, und F6 springt zwischen Navigationsleiste und Inhalt. Im Mailfluss markieren die Pfeiltasten eine Regel, Enter öffnet sie zum Bearbeiten, Strg + S speichert vorgemerkte Änderungen (auch in den Einstellungen), und Enter in einem Feld des Regel-Testers startet den Test.

Administratorrechte und „Immer als Administrator starten“

SMTPly liest und ändert die Konfiguration, die nur für Administratoren zugänglich ist. Ohne Administratorrechte startet die Oberfläche im Nur-Lese-Modus: Sichtbar bleiben der Maillog mit den laufenden Zahlen, Lizenz, Hilfe und Über; Dashboard, System-Log, Mailfluss und Einstellungen sind ausgeblendet. Unter Einstellungen → Allgemein lässt sich Immer als Administrator starten einschalten. Dann öffnet SMTPly bei jedem Start mit vollen Rechten, auch per Doppelklick auf die Verknüpfung oder aus dem Startmenü; Windows fragt dabei jedes Mal nach der Bestätigung. Die Einstellung gilt ab dem nächsten Start und nur für den angemeldeten Windows-Benutzer, sie ist nicht Teil der Sicherung. Sie nutzt die Windows-Kompatibilitätseinstellung „Als Administrator ausführen“ und lässt sich dort auch in den Eigenschaften der Verknüpfung wieder abschalten. Erreichbar ist das Kästchen nur im Administratormodus, beim ersten Mal also einmal über Rechtsklick und „Als Administrator ausführen“ starten.

Zertifikate

Seit Version 1.8.0 hat das Zertifikat in den Einstellungen einen eigenen Abschnitt, und zwar aus einem Grund, der die Einrichtung vereinfacht: Ein Zertifikat versorgt alle Dienste dieses Rechners. Die SMTP-Listener holen es von dort, der Monitoring-Endpunkt und die REST-Schnittstelle ebenso. Es ist derselbe Rechner unter demselben Namen; eine zweite Zertifikatsverwaltung wäre doppelte Pflege für denselben Zweck. Änderungen greifen ohne Neustart des Dienstes.

Wann Sie überhaupt eines brauchen

Standardmäßig ist die Transportverschlüsselung aus, und für Legacy-Geräte in einem vertrauenswürdigen LAN ist das meist auch richtig. Ein Zertifikat brauchen Sie, sobald einer dieser Fälle zutrifft:

• Ein Gerät verlangt STARTTLS: Die Verbindung beginnt im Klartext und wird per Kommando auf TLS umgeschaltet. Das ist der empfohlene Modus und passt zu den meisten modernen SMTP-Clients.
• Ein Gerät verlangt implizites TLS/SSL: Die Verbindung ist ab dem ersten Byte verschlüsselt, ganz ohne Klartext-Phase. Typisch für ältere Industriesteuerungen, die in ihrer Oberfläche schlicht „SSL" anbieten. Fehlt der Modus, scheitern sie mit Meldungen wie SSL23_GET_SERVER_HELLO:unknown protocol.
• Sie stellen Monitoring-Endpunkt oder REST-Schnittstelle auf HTTPS, weil sie nicht nur auf der Rückschleife lauschen.
• Sie nutzen die SMTP-Anmeldung mit Klartextpasswörtern. SMTPly verweigert die dann auf unverschlüsselten Verbindungen, sofern Sie die Ausnahme nicht ausdrücklich einschalten.

Ab der Business-Edition lassen sich mehrere Listener-Ports parallel betreiben, jeder mit eigenem TLS-Modus. Alte „SSL"-Geräte zeigen dann auf den einen Port, neuere STARTTLS-Geräte auf den anderen, und Sie brauchen die Geräte nicht einzeln umzustellen.

Woher das Zertifikat kommt

Vier Quellen stehen zur Auswahl, alle im Abschnitt Zertifikat:

Zertifikat prüfen und anzeigen

Neben der Zertifikatsquelle steht Aktuelles Zertifikat anzeigen. Der Knopf öffnet das Zertifikat, das der Dienst gerade tatsächlich verwendet, gleich aus welcher der vier Quellen, im gewohnten Windows-Dialog mit Fingerabdruck, Gültigkeit und alternativen Namen.

Wird die Transportverschlüsselung eingeschaltet, ohne dass ein verwendbares Zertifikat vorliegt, meldet SMTPly das beim Speichern und bietet an, sofort ein selbstsigniertes zu erzeugen. Lehnen Sie ab, wird die Verschlüsselung ausgeschaltet gespeichert, denn sonst würde der Dienst beim nächsten Start scheitern.

Der Selbsttest prüft das Zertifikat mit: Gültigkeit, Passung zum Listener und bei implizitem TLS ein echter Handshake gegen den eigenen Port.

Automatisch erneuern lassen

SMTPly stellt keine Zertifikate selbst aus und übernimmt keine ACME-Anmeldung. Das ist Absicht: Ein Werkzeug, das ausschließlich Zertifikate verwaltet, macht das gründlicher, und SMTPly muss dafür keine Anbieter-Schnittstellen pflegen. Die Aufgabe von SMTPly endet damit, ein erneuertes Zertifikat ohne Zutun zu übernehmen, und genau das kann es.

Der Kniff steht in einem Satz: Lassen Sie das Erneuerungswerkzeug das Zertifikat in den Windows-Speicher legen, und stellen Sie SMTPlys Zertifikatsquelle auf Antragsteller (Subject) statt auf den Fingerabdruck. Bei jeder Erneuerung ändert sich der Fingerabdruck, der Antragsteller bleibt. SMTPly sucht dann alle sechs Stunden das neueste gültige Zertifikat mit diesem Antragsteller und übernimmt es ohne Dienst-Neustart. Ohne diesen Kniff müssten Sie nach jeder Erneuerung den neuen Fingerabdruck von Hand eintragen.

Interne Zertifizierungsstelle (der häufigste Fall)

Wenn Ihre Geräte den Relay unter einem internen Namen wie smtp.firma.local oder einer IP ansprechen, ist eine interne CA der richtige Weg, nicht eine öffentliche. Active Directory Certificate Services (ADCS) stellt per Auto-Enrollment ein Server-Zertifikat aus und erneuert es selbständig im Windows-Speicher. Ihre Geräte vertrauen der internen CA ohnehin. Stellen Sie SMTPly auf den Antragsteller dieses Zertifikats, und die Erneuerung läuft für immer unbemerkt.

Öffentliches Zertifikat mit win-acme (Let's Encrypt)

Nur sinnvoll, wenn der Relay unter einem öffentlich auflösbaren Namen erreichbar ist und eine ACME-Prüfung erfüllen kann. Für einen rein internen Namen oder eine IP stellt keine öffentliche Zertifizierungsstelle aus, mit keiner Prüfmethode. Trifft das auf Sie zu, ist der Weg mit win-acme kurz:

1. win-acme herunterladen und als Administrator starten.
2. Ein Zertifikat für den öffentlichen Namen des Servers anfordern. Die Prüfung läuft je nach Erreichbarkeit über HTTP (Port 80 muss aus dem Internet erreichbar sein) oder über DNS (ein TXT-Eintrag, den ein Skript setzt).
3. Als Speicherziel Windows Certificate Store wählen (nicht nur eine PEM-Datei). win-acme legt eine Aufgabe in der Aufgabenplanung an und erneuert das Zertifikat künftig selbständig.
4. In SMTPly unter Zertifikat die Quelle Windows-Zertifikatsspeicher wählen und den Antragsteller eintragen, nicht den Fingerabdruck.

Bedenken Sie den Trust: Ein Let's-Encrypt-Zertifikat verlangt, dass das Gerät die Stammzertifizierungsstelle kennt. Ältere Drucker und Branchengeräte tun das oft nicht. In solchen Fällen ist ein selbstsigniertes Zertifikat, das Sie einmal bewusst in die Geräte legen, oder eines aus der internen PKI die verlässlichere Wahl.

Ablauf im Blick behalten

Unabhängig von der Quelle warnt SMTPly per E-Mail, wenn ein Zertifikat sich dem Ablauf nähert; der Schalter dafür steht bei den Benachrichtigungen. Der Monitoring-Endpunkt nennt die Restlaufzeit als certificateDays beziehungsweise smtply_tls_certificate_days_remaining, die REST-Schnittstelle führt sie in /api/v1/status. Negative Werte heißen „seit N Tagen abgelaufen", und genau darauf lässt sich alarmieren. Sollte eine Erneuerung einmal ausbleiben, erfahren Sie es also, bevor der Versand steht.

Wenn ein Gerät dem Zertifikat nicht traut

Das häufigste Bild nach dem Einschalten von TLS: Das Gerät sendet unverschlüsselt anstandslos und bricht mit Verschlüsselung ohne brauchbare Meldung ab. Ursache ist fast immer das selbstsignierte Zertifikat, dessen Aussteller das Gerät nicht kennt. Der Fehler entsteht dabei auf der Seite des Geräts, weshalb im System-Log von SMTPly oft gar nichts steht. Die Schritte zur Abhilfe stehen unter Troubleshooting.

Client Secret erneuern

Client Secrets in Microsoft Entra haben eine begrenzte Laufzeit — läuft das Secret ab, steht der Mailversand. SMTPly warnt ab 14 Tagen vor Ablauf in der Oberfläche und per E-Mail an Ihre Benachrichtigungsadresse. Für die Erneuerung gibt es zwei Wege: von Hand oder selbsttätig Business.

Von Hand erneuern

1. Einstellungen → Microsoft 365 öffnen. Neben dem Ablaufdatum steht der Knopf Secret erneuern …
2. Auf Secret erneuern … klicken. Es öffnet sich das Anmeldefenster von Microsoft.
3. Mit einem Administratorkonto Ihres Tenants anmelden. SMTPly legt an der vorhandenen App-Registrierung ein zusätzliches Secret an — App, Dienstprinzipal und Berechtigungen bleiben unangetastet.
4. SMTPly übernimmt das neue Secret samt Ablaufdatum automatisch. Anschließend Speichern und den Dienst neu starten.

Einstellungen → Microsoft 365: Ablaufdatum und der Knopf zum Erneuern.

Das bisherige Secret wird dabei nicht entfernt. Es bleibt bis zu seinem regulären Ablauf gültig, sodass zwischen Erneuerung und Neustart keine Lücke entsteht. Bei mehreren Tenants Business hat jede Tenant-Karte einen eigenen Knopf — melden Sie sich jeweils an dem Tenant an, dessen Secret erneuert werden soll.

Selbsttätig erneuern Business

Einmal eingerichtet, erneuert der Dienst das Secret ab 21 Tagen Restlaufzeit von selbst — der Kalendereintrag entfällt.

1. In Einstellungen → Microsoft 365 (oder in einer Tenant-Karte) das Kästchen Client Secret vor Ablauf selbsttätig erneuern anhaken.
2. Ein kurzer Dialog erklärt, was dafür nötig ist, und lässt die Wahl zwischen Von SMTPly einrichten lassen und Selbst im Entra Admin Center. Für den ersten Weg auf Jetzt einrichten klicken.
3. Im Anmeldefenster von Microsoft mit einem Administratorkonto Ihres Tenants anmelden. SMTPly erteilt der App-Registrierung einmalig die Berechtigung Application.ReadWrite.OwnedBy und macht sie zur Eigentümerin ihrer eigenen Registrierung.
4. Fertig. Ab jetzt erneuert der Dienst das Secret ab 21 Tagen vor Ablauf selbst. Auf Wunsch informiert eine E-Mail über jeden Lauf (standardmäßig an).

Schritt 2: Der Assistent nennt die einmalig nötige Berechtigung.

Was Sie dafür eintauschen. Die App-Registrierung bekommt einmalig die Berechtigung Application.ReadWrite.OwnedBy und wird Eigentümerin ihrer eigenen Registrierung. Damit darf sie Registrierungen ändern, die ihr selbst gehören — und nur diese; Application.ReadWrite.All wird bewusst nicht verlangt.

Das ist mehr Recht, als der reine Mailversand braucht. Deshalb ist die Funktion ausdrücklich abschaltbar und standardmäßig aus: Wer sie nicht möchte, erneuert weiterhin von Hand und verliert dabei nichts. Auch hier bleibt das alte Secret bis zu seinem regulären Ablauf gültig.

Was während der Anmeldung passiert. Schritt 3 meldet Sie über Microsofts eigene Anwendung „Microsoft Graph Command Line Tools" an. Microsoft verlangt dafür eine Zustimmung im Namen der Organisation — dadurch erhält diese Microsoft-Anwendung in Ihrem Tenants dauerhaft die Rechte Application.ReadWrite.All und AppRoleAssignment.ReadWrite.All. Das ist eine notwendige Voraussetzung, um der SMTPly-App anschließend die eng begrenzte OwnedBy-Berechtigung erteilen zu können — beides zusammen lässt sich in Entra nicht ohne diesen Zwischenschritt vergeben.

Diese Rechte bleiben nach dem Lauf bestehen. Sie lassen sich im Entra Admin Center unter Unternehmensanwendungen → Microsoft Graph Command Line Tools → Berechtigungen jederzeit wieder entziehen, ohne dass die bereits erteilte OwnedBy-Berechtigung der SMTPly-App davon betroffen ist.

Ohne Anmeldung: beide Berechtigungen von Hand vergeben

Wer die Entra-Änderungen lieber selbst nachvollziehen möchte, richtet dieselben zwei Dinge direkt im Entra Admin Center ein — ohne Anmeldefenster:

1. App-Registrierungen → Ihre SMTPly-App → API-Berechtigungen → Berechtigung hinzufügen → Microsoft Graph → Anwendungsberechtigungen, darin Application.ReadWrite.OwnedBy auswählen und hinzufügen. Anschließend „Administratorzustimmung erteilen für [Tenant]" anklicken (erfordert die Rolle Globaler Administrator).
2. Die App muss zusätzlich Eigentümerin ihrer eigenen Registrierung werden. Das lässt sich im Entra-Portal selbst nicht einstellen — am einfachsten geht es über den Graph Explorer mit Ihrem Admin-Konto: POST auf https://graph.microsoft.com/v1.0/applications/{Objekt-ID der App}/owners/$ref mit dem Body {"@odata.id": "https://graph.microsoft.com/v1.0/servicePrincipals/{Objekt-ID des Dienstprinzipals}"}. Beide Objekt-IDs stehen auf der Übersichtsseite der App-Registrierung bzw. des zugehörigen Enterprise-Application-Eintrags.
3. Erst danach in SMTPly das Kästchen Client Secret vor Ablauf selbsttätig erneuern anhaken. Im folgenden Dialog „Selbst im Entra Admin Center" wählen und die beiden Schritte bestätigen — damit öffnet sich kein Anmeldefenster.

Bis Version 1.7.31 war das anders: Dort öffnete sich das Anmeldefenster auch dann, wenn die Berechtigung längst von Hand vergeben war, und meldete nur „Berechtigung war bereits erteilt". Seit 1.7.32 ist der manuelle Weg ein eigenständiger Weg und kein Zwischenschritt mehr.

Der Dialog nach dem Anhaken: links der Weg über die Anmeldung bei Microsoft, rechts der manuelle. Wer rechts wählt, bestätigt die beiden oben beschriebenen Schritte und ist fertig — ohne Anmeldefenster.

So sieht es in Entra danach aus: Mail.Send steht unter „Konfigurierte Berechtigungen", Application.ReadWrite.OwnedBy taucht — egal ob von SMTPly oder von Hand vergeben — unter „Weitere gewährte Berechtigungen" auf. Beide mit Status „Gewährt".

Webhooks einrichten

{
  "event": "delivery.failed",
  "timestamp": "2026-07-31T08:45:13+02:00",
  "server": "SRV-RELAY01",
  "version": "1.7.16",
  "data": {
    "from": "drucker@example.com",
    "to": "buchhaltung@example.com",
    "subject": "Scan vom 31.07.2026",
    "error": "HTTP 403 Forbidden",
    "tenant": "Haupt-Tenant",
    "attempts": 5
  }
}

# PowerShell-Beispiel für den Empfänger
$secret   = "IhrSignaturGeheimnis"
$body     = $request.Body          # exakt wie empfangen, nicht neu formatieren
$hmac     = [System.Security.Cryptography.HMACSHA256]::new([Text.Encoding]::UTF8.GetBytes($secret))
$hash     = $hmac.ComputeHash([Text.Encoding]::UTF8.GetBytes($body))
$expected = "sha256=" + ([BitConverter]::ToString($hash) -replace '-','').ToLower()

if ($expected -ne $request.Headers["X-Smtply-Signature"]) { throw "Ungueltige Signatur" }

Monitoring anbinden

{
  "status": "ok",                  // "ok" oder "degraded"
  "version": "1.7.13",
  "uptimeSeconds": 86400,          // Sekunden seit Dienststart
  "queueLength": 0,                // Mails in Warteschlange/Retry
  "circuitBreaker": "Closed",      // Closed | Open | HalfOpen
  "today": { "sent": 312, "failed": 1, "pending": 0 }
}

"sandbox": { "configured": false, "activeNow": false },
"expiry": {
  "certificateDays": 42,           // null, wenn TLS aus ist
  "clientSecretDaysMin": 17,       // kleinster Wert über alle Tenants
  "clientSecrets": [ { "tenant": "Firma 1", "days": 17 } ]
}

smtply_up 1
smtply_uptime_seconds 86400
smtply_queue_length 0
smtply_circuit_breaker_open 0
smtply_mails_sent_today 312
smtply_mails_failed_today 1
smtply_mails_pending_today 0

# smtply-healthcheck.ps1 — Beispiel, Port ggf. anpassen
$url = "http://127.0.0.1:8025/health"
try {
    $h = Invoke-RestMethod -Uri $url -TimeoutSec 5
    if ($h.circuitBreaker -eq "Open") {
        Write-Output "CRITICAL: Versand pausiert (Circuit-Breaker offen), Queue=$($h.queueLength)"
        exit 2
    }
    if ($h.queueLength -gt 50) {
        Write-Output "WARNING: Queue-Rueckstau ($($h.queueLength) Mails)"
        exit 1
    }
    Write-Output "OK: v$($h.version), heute $($h.today.sent) gesendet, $($h.today.failed) fehlgeschlagen, Queue=$($h.queueLength)"
    exit 0
}
catch {
    Write-Output "CRITICAL: SMTPly-Endpoint nicht erreichbar ($($_.Exception.Message))"
    exit 2
}

Sicherung & Wiederherstellung

{
  "format": "smtply-encrypted-backup",
  "version": 1,
  "createdAt": "2026-07-30T23:51:45+02:00",
  "payload": "portable:v1:600000:…"
}

# Test im Kontext des Computerkontos (benötigt PsExec aus den Sysinternals)
psexec -s -accepteula powershell -Command "New-Item '\\nas\backup\smtply\test.txt' -ItemType File; Remove-Item '\\nas\backup\smtply\test.txt'"

Wiederherstellen: nur Teile übernehmen

Vor dem Übernehmen zeigt SMTPly, was sich ändern würde: Sektion, Feld, aktueller Wert, eingelesener Wert. Geänderte Zeilen sind hervorgehoben, Geheimnisse erscheinen nie im Klartext, sondern nur als „gesetzt", „geändert" oder „unverändert".

Seit Version 1.8.0 lässt sich in dieser Vorschau jede Zeile einzeln abhaken. Übernommen wird nur, was angehakt bleibt; alles andere behält den Wert, der jetzt auf dem Server steht. Zwei Knöpfe wählen alles oder nichts aus.

Der Anlass ist eine alltägliche Lage: Eine ältere Sicherung enthält die richtigen Listener-Einstellungen, aber ein inzwischen ausgetauschtes Client Secret. Vorher hieß Import alles oder nichts, und wer den Listener zurückholte, bekam die alten Zugangsdaten ungefragt mit. Jetzt haken Sie Port, Bind-Adresse und Whitelist an und lassen Microsoft 365 unberührt.

Zwei Dinge, die dabei zusammengehören und deshalb in einer Zeile stehen: das Syslog-Ziel (Server, Port und Übertragungsart) sowie Bind-Adresse und Port der REST- und MCP-Schnittstelle. Einzeln übernommen ergäben sie halbe Konfigurationen. Die Liste der zusätzlichen Tenants hat eine eigene Zeile und wird übernommen wie jedes andere Feld: nur wenn angehakt. Feldweise mischen ließe sie sich nicht sinnvoll, deshalb steht sie als Ganzes darin.

Sichern: nur Teile aufnehmen

Denselben Weg gibt es auch in die andere Richtung. Neben Sicherung erstellen steht Auswahl exportieren…: Sie sehen dieselbe Liste, haken an, was in die Datei soll, und alles Übrige steht darin auf dem Wert einer Neuinstallation. Nützlich, wenn eine Sicherung an den Support geht oder auf einen zweiten Server wandert, ohne die Zugangsdaten mitzunehmen.

Eine so erzeugte Datei merkt sich, welche Felder sie enthält (verschlüsselt wie ihr übriger Inhalt). Beim Zurückspielen bietet die Vorschau nur diese an; die übrigen Zeilen erscheinen als „(nicht in dieser Datei)" und lassen sich nicht anhaken. Das ist wichtiger, als es klingt: Ohne diesen Vermerk sähe eine Sicherung mit drei Feldern so aus, als wollte sie alles Übrige auf Standardwerte zurücksetzen, und ein Klick auf Alle auswählen hätte genau das getan. Ältere Sicherungen ohne diesen Vermerk bleiben lesbar und verhalten sich wie bisher.

Dashboard: Zahlen und Verlauf

Seit Version 1.9.0 beginnt die Oberfläche mit einer Auswertung. Sie zeigt auf einen Blick, was in den letzten Stunden oder Tagen durch das Relay gegangen ist, und beantwortet die Fragen, die sonst Filterarbeit in der Mail-Tabelle wären. Die Tabelle selbst heißt seit dieser Version Maillog.

Was das Dashboard zeigt

• Kacheln: zugestellt, in Zustellung, fehlgeschlagen, abgelehnt, zugestelltes Volumen (die Größe der zugestellten Mails) und der Anteil der Mails, die verschlüsselt angenommen wurden (STARTTLS oder implizites TLS gegenüber Klartext). Mails aus der Zeit vor Version 1.8.0, deren Transportart nicht erfasst wurde, und Ablehnungen zählen dabei nicht mit.
• Verlauf: Mails über die Zeit, getrennt nach zugestellt und fehlgeschlagen oder abgelehnt. Vorgabe sind 7 Tage. „Heute“ zeigt jede Stunde, „7 Tage“ und „30 Tage“ zeigen jeden Tag, jeweils nach der Ortszeit des Servers.
• Ranglisten: die häufigsten Absender, Empfänger, Quell-IPs und SMTP-Konten sowie die Gründe, aus denen Mails abgelehnt wurden. Jede Liste zeigt die fünf häufigsten Einträge.

Datenbasis und Grenzen

Alle Zahlen kommen aus dem Mail-Tracker, also aus denselben Metadaten wie im Maillog. Ohne Enterprise-Lizenz reicht der Blick 14 Tage zurück, mit Aufbewahrung über 14 Tage auch weiter. Ausgewertet werden höchstens die neuesten 50.000 Mails des gewählten Zeitraums; ist der Zeitraum größer, steht ein Hinweis darunter.

Anonymisierung: Ist im Datenschutzabschnitt der Einstellungen die teilweise Maskierung eingeschaltet, erscheinen Adressen, IPs und Konten auch im Dashboard maskiert, und zwar bei der Anzeige. Auch ältere Einträge, die vor dem Einschalten im Klartext geschrieben wurden, sind damit geschützt. Gruppiert wird nach der maskierten Form, die Ranglisten werden dadurch etwas gröber.

Zurücksetzen: Auswertung zurücksetzen setzt die Zahlen auf null und zählt ab diesem Zeitpunkt neu. Das betrifft nur die Anzeige dieses Windows-Benutzers, die Mail-Historie bleibt erhalten.

Nur mit Administratorrechten: Die Datenbank ist nur für Administratoren lesbar. Ohne sie steht das Dashboard nicht in der Navigation, die Oberfläche beginnt im Maillog mit den laufenden Zahlen.

Maillog (Mail-Tracker)

Bis Version 1.8 hieß diese Ansicht Dashboard. Seit 1.9.0 ist sie der zweite Eintrag der Navigation und trägt den Namen Maillog; sie funktioniert unverändert.

Der Mail-Tracker zeigt jede angenommene Mail mit Zeit, Absender, Empfänger, Betreff, Quell-IP, Benutzer, Transport, Größe und Status. Gespeichert werden ausschließlich diese Metadaten — keine Mail-Inhalte. Absender, Empfänger, Betreff, Quell-IP und Fehlermeldung liegen in der Datenbank einzeln verschlüsselt.

Spalten wählen

Über Spalten oberhalb der Tabelle lässt sich jede Spalte ab- und wieder anwählen. Die Auswahl gilt je Windows-Benutzer und bleibt über Neustarts erhalten. Eine Spalte, die eine spätere Version hinzufügt, erscheint mit ihrer Vorgabe — eine ältere Auswahl wird dadurch nicht ungültig.

Filtern

Über der Tabelle steht eine Filterzeile: Freitext über alle sichtbaren Spalten, dazu Status und Zeitraum. Ein Rechtsklick auf eine Zelle bietet zusätzlich Nach diesem Wert filtern — der schnellste Weg von „diese eine Adresse fällt auf" zu „was hat sie sonst noch geschickt".

Detailansicht

Ein Klick auf das Dreieck am Zeilenanfang klappt den Eintrag auf und zeigt, was in der Tabelle keinen Platz hat: Dauer, Versuchszahl, Tenant, Graph-Nachrichten-ID und die vollständige Fehlermeldung. Die beiden letzten stehen in auswählbaren Feldern, weil sie im Support kopiert werden. Leere Felder blenden ihre Zeile aus. Ein zweiter Klick klappt wieder zu.

Seit 1.8.8 sind Absender, Empfänger und Quell-IP in der Detailansicht anklickbar. Ein Klick öffnet ein Menü mit dem aktuellen Stand (erlaubt, gesperrt, nicht freigegeben) und den passenden Aktionen: erlauben, Sperre aufheben, Adresse oder ganze Domäne sperren. Gesperrte Werte erscheinen rot, nicht freigegebene Quell-IPs gelb, in der Detailansicht wie in der Tabelle. Einzelheiten unter Sperrlisten und Freischalten.

Farbliche Kennzeichnung

Zeilen, die nicht erfolgreich waren, sind farblich hinterlegt: rot für endgültig gescheitert, rot für abgewiesen (vom Listener, bevor die Mail in die Warteschlange ging), gelb für „wird wiederholt", grau für „wartet noch". Erfolgreiche Zeilen bleiben unmarkiert — die Farbe soll etwas heißen.

Tageszahlen und Statusleiste

Über der Tabelle stehen die Zahlen des Tages: gesendet, ausstehend, Fehler. Zurücksetzen lassen sie sich per Rechtsklick auf die Kacheln oder unter Einstellungen → Allgemein → Tageszähler zurücksetzen. Das betrifft nur die Anzeige, die Mail-Historie bleibt erhalten.

Unten rechts zeigt die Statusleiste auf jeder Seite den Zustand des Dienstes: grüner Punkt, wenn er läuft, gelb im Übergang oder wenn die Live-Verbindung zur Oberfläche fehlt, rot, wenn er steht. Ein Klick darauf öffnet ein Menü zum Starten, Stoppen und Neustarten. In den Einstellungen stehen links in derselben Leiste Speichern und, wenn eine Änderung es verlangt, Dienst jetzt neu starten.

Mailfluss und Regel-Tester

Die Ansicht Mailfluss (seit 1.9.0, Strg+4) zeigt, welche Regeln der Einstellungen gerade auf eine Mail wirken, in der Reihenfolge, in der SMTPly sie prüft. Sie ist eine zweite Ansicht auf dieselben Einstellungen: Nichts wird doppelt gespeichert, und alle Einstellungen bleiben an ihrer bisherigen Stelle. Die Ansicht braucht Administratorrechte, weil sie die Konfiguration liest.

Aufbau

Oben steht der Weg einer Mail: Gerät, dann die drei Stufen in SMTPly, dann Microsoft 365. Ein Klick auf eine Stufe springt zu ihren Regeln, mit der Maus darüber werden sie hervorgehoben. Darunter steht das Regelwerk mit den Spalten Regel, Bedingungen, Aktion, Zustand und Zähler. In Bedingungen stehen alle Kriterien einer Regel, beschriftet mit Quelle, Absender, Empfänger oder Betreff, etwa „Quelle in: 192.168.10.0/24“. Es ist gegliedert nach den Stufen:

• Annahme: zuerst die Sperren (gesperrte Quell-IPs, Absender und Empfänger, weisen ab, wenn sie zutreffen), dann die Voraussetzungen: erlaubte Quell-IPs, Empfänger-Beschränkung, Freigabelisten, Ratenbegrenzung und Nachrichtengröße. Alle Voraussetzungen müssen zusammen erfüllt sein, damit eine Mail angenommen wird. Am Ende steht „Alles andere: Ablehnen“. Der Zähler bei einer Voraussetzung zählt die Mails, die an ihr scheiterten.
• Zuordnung: AUTH-Bindungen, Tenants nach Absenderdomäne und ausgehende Regeln. Die Schlussregel „Kein Tenant passt“ weist die Mail ab.
• Zustellung: Absender ersetzen, Betreffkennzeichnung, Sandbox-Modus und Journal-BCC, am Ende „Übergabe an Microsoft 365“.

Wie bei einem Firewall-Regelwerk gilt die Reihenfolge von oben nach unten. Die Nummern sind Positionen im Regelwerk; wenn ausgeschaltete Regeln ausgeblendet sind (Vorgabe), bleiben Lücken in der Zählung. Nicht lizenzierte Regeln bleiben sichtbar und sind gelb gekennzeichnet, weil sie eine Warnung sind. Jede Gruppe lässt sich mit dem Pfeil zu- und aufklappen, „+ Regel hinzufügen“ steht als Knopf am Kopf jeder Gruppe. Bei der Zustellung öffnet er die Funktionen Absender ersetzen, Betreffkennzeichnung, Sandbox-Modus und Journal-BCC zum Einschalten; was die Lizenz nicht hergibt, steht ausgegraut mit dem Grund. Die Spalten lassen sich in der Breite ziehen und verschieben.

Bearbeiten

Hinter den Bedingungen jeder Regel steht ein kleiner Stift, auch bei ausgeschalteten Regeln. Er öffnet ein Fenster mit genau den Feldern dieser Regel. Ein Doppelklick auf eine Regel öffnet stattdessen die passende Stelle der Einstellungen. Ausgehende Regeln haben zusätzlich Pfeile, mit denen sich ihre Reihenfolge ändern lässt, denn nur dort verändert die Reihenfolge das Ergebnis. Per Tastatur: Pfeiltasten markieren eine Regel, Enter bearbeitet sie, Alt + Pfeil hoch oder runter verschiebt eine ausgehende Regel, Einfg öffnet „Regel hinzufügen“ der Stufe.

Die Ansicht schreibt nie selbst an der Konfiguration vorbei: Änderungen gehen denselben Weg wie in den Einstellungen, mit denselben Prüfungen und Lizenzschranken. Änderungen werden nur vorgemerkt: Über dem Regelwerk steht ein Hinweis, und unten in der Leiste erscheint „Speichern“ (auch Strg + S), danach „Dienst jetzt neu starten“. So lassen sich mehrere Änderungen in einem Durchgang übernehmen, und der Dienst startet nie ungefragt neu. Die Tabelle zeigt die Änderung sofort; gespeichert ist sie aber erst mit „Speichern“. Einiges bleibt den Einstellungen vorbehalten, etwa AUTH-Bindungen, ein neuer Tenant oder das Zeitfenster der Sandbox; dort führt der Doppelklick direkt hin.

Regel-Tester

Unter dem Regelwerk steht der Regel-Tester, beim Öffnen aufgeklappt (auch über Strg+8). Er beantwortet die Frage „Was passiert mit dieser Mail?“, ohne etwas zu versenden. Sie geben Quell-IP, optional einen AUTH-Benutzer, Absender, Empfänger, Betreff und Größe an; der Tester führt dieselbe Auswertung aus wie der Dienst und zeigt das Ergebnis (angenommen mit Tenant und Absenderadresse, oder abgewiesen mit Grund und SMTP-Code). Die beteiligten Stufen und Regeln werden im Diagramm und in der Tabelle markiert, „Alle Schritte“ zeigt die Prüfung Schritt für Schritt.

Mit Edition annehmen lässt sich durchspielen, was eine andere Lizenzstufe ändern würde. Nicht simuliert werden die Ratenbegrenzung und die Sitzungsobergrenzen: Sie hängen vom Verkehr im Moment ab, nicht von den Einstellungen.

Zähler der Regeln

Seit 1.9.0 zählt SMTPly, wie oft jede Regel gegriffen hat, und zeigt das als Spalte Zähler im Mailfluss. So sieht man, ob eine Regel im Alltag überhaupt etwas tut, und welche Regel eine unerwartete Ablehnung ausgelöst hat.

Was gezählt wird

• Regeln der Annahme zählen Annahmeversuche, die sie abgewiesen haben. Geräte wiederholen eine abgewiesene Mail oft, deshalb kann die Zahl höher sein als die Zahl der Mails.
• Zuordnung (Tenants, AUTH-Bindungen, ausgehende Regeln) und die Schlussregel der Annahme zählen angenommene Mails.
• Regeln der Zustellung zählen zugestellte Mails, und zwar einmal nach dem erfolgreichen Versand, nicht je Versuch. Der Umschlag-Bcc wird nicht gezählt.

Der Zähler steht immer bei genau der Regel, die gegriffen hat: bei Sperrlisten je Liste, bei der Empfänger-Beschränkung je Regel, die für die Quell-IP gilt. Gelöscht man eine Regel, verschwindet ihr Zähler mit dem nächsten Dienststart; eine neue Regel beginnt bei null.

Zurücksetzen und Speicherung

Zähler zurücksetzen fragt nach und setzt alle Zähler auf null; daneben steht, seit wann gezählt wird. Die Oberfläche kann den Dienst nicht direkt steuern, sie legt deshalb eine Markierung ab, die der Dienst binnen Sekunden abholt. Die Zahlen liegen in einer Datei im geschützten Konfigurationsordner und bleiben über Neustarts erhalten. Sie enthalten nur Schrittnamen, Kennungen und Zahlen, keine Adressen. Ein harter Absturz kostet höchstens die Zahlen der letzten Sekunden. Die Zähler sind Betriebsdaten und keine Einstellung, deshalb stehen sie nicht in der Sicherung.

Für Überwachung und Support

• Monitoring (Business und Enterprise): /metrics führt die Reihe smtply_rule_counter_total{rule="…"}. Die Bezeichnung nennt den Schritt und, wo nötig, primary oder tenant-N für Tenants, rule-N für ausgehende Regeln und restriction-N für Empfänger-Beschränkungen. Namen und Adressen kommen nie vor, weil der Endpunkt keine Anmeldung kennt.
• REST-Schnittstelle (Enterprise): der Status enthält den Block ruleCounters mit denselben Bezeichnungen und dem Zeitpunkt, seit dem gezählt wird.
• Diagnose-Paket: configuration-summary.txt führt die Zähler unter „Trefferzähler der Regeln“ auf.

Journal-BCC und bedingtes Journaling

Business- und Enterprise-Funktion. Journal-BCC legt eine Blindkopie jeder relayten Mail in ein Archivpostfach. Technisch wird dafür eine Bcc:-Zeile in die Rohnachricht eingefügt (bzw. eine vorhandene erweitert); Microsoft nimmt die Empfänger daraus in die Zustellung auf und entfernt die Zeile vor der Auslieferung — normale BCC-Semantik. Am übrigen Inhalt der Nachricht ändert sich nichts.

Bedingtes Journaling (ab Version 1.8.0) schränkt das auf bestimmte Absender ein: In Einstellungen → Microsoft 365 → Nur journalisieren für tragen Sie Adressen oder ganze Domänen ein, eine je Zeile. Ein Eintrag ohne @ gilt als Domäne, example.com und @example.com meinen dasselbe. Groß- und Kleinschreibung spielt keine Rolle.

Bleibt das Feld leer, wird alles journalisiert — das Verhalten vor 1.8.0. Das Feld erscheint erst, wenn ein Archivpostfach eingetragen ist; ein Filter ohne Ziel wäre eine Einstellung ohne Wirkung.

Im Sandbox-Modus ist Journal-BCC abgeschaltet. Ausgehende Regeln können das Journalisieren je Mail erzwingen oder unterdrücken und gehen dem Filter vor.

Aufbewahrung mit Nachweis

Enterprise-Funktion, ab Version 1.8.0. Sie beantwortet eine Frage, die in Prüfungen regelmäßig gestellt wird: Woran sehen Sie, dass an Ihrer Versandhistorie nachträglich nichts geändert wurde?

Wie es arbeitet

Jeder Eintrag im Mail-Tracker bekommt beim Schreiben eine Prüfsumme (SHA-256) über seine eigenen Felder und über die Prüfsumme des vorhergehenden Eintrags. Dadurch entsteht eine Kette: Wer eine Zeile nachträglich ändert oder löscht, ändert deren Prüfsumme — und ab dieser Stelle passt keine der folgenden mehr.

In die Prüfsumme gehen Zeitstempel, Absender, Empfänger, Betreff, Größe, Status, Tenant, Versuchszahl und die Graph-Nachrichten-ID ein. Die Kette wird beim Schreiben gebildet, nicht nachträglich — es gibt also keinen Zeitpunkt, zu dem sich eine Zeile unbemerkt einfügen ließe.

Kette prüfen

Einstellungen → Aufbewahrung → Kette prüfen. SMTPly liest die Historie einmal durch und meldet entweder, dass alle Glieder zusammenpassen, oder nennt Zeitstempel und Kennung des ersten Eintrags, an dem die Kette bricht. Von dort an ist die Reihe nicht mehr belegbar — davor schon.

Zeilen aus der Zeit vor 1.8.0 tragen keine Prüfsumme. Sie brechen die Kette nicht, sondern setzen sie neu an; im Prüfbericht steht, ab welchem Zeitpunkt der Nachweis greift.

Signierter Export

Einstellungen → Aufbewahrung → Nachweis exportieren. Erzeugt zwei Dateien: eine CSV mit den Einträgen samt ihrer Prüfsummen und ein Manifest mit dem Zeitraum, der Anzahl der Zeilen, der Prüfsumme der CSV-Datei selbst und dem letzten Glied der Kette. Das Manifest ist bewusst kurz und in Klartext gehalten, damit ein Prüfer es ohne SMTPly lesen kann.

Was der Nachweis belegt — und was nicht

Belegt wird, dass die exportierte Reihe in sich stimmig ist und seit dem Schreiben nicht verändert wurde. Wer die Datenbank vollständig löscht und neu beginnt, hinterlässt dagegen eine kürzere, aber in sich stimmige Kette — dass etwas fehlt, zeigt der Nachweis nicht von selbst. Deshalb steht der Beginn der Kette im Manifest: Eine Reihe, die auffällig spät beginnt, ist die Nachfrage wert.

Das Verfahren ist keine GoBD-Zertifizierung und ersetzt keine revisionssichere Archivierung. Es belegt die Unversehrtheit der Versandhistorie von SMTPly — die Mails selbst liegen in Microsoft 365, nicht hier. Für die Archivierung der Nachrichten selbst ist Journal-BCC gedacht.

Einzelne Einträge nachträglich maskieren

Manchmal steht in der Historie etwas, das dort nicht bleiben soll: ein Betreff mit einer Diagnose, die Privatadresse einer Beschäftigten, ein Löschverlangen nach Artikel 17 DSGVO. Dafür lässt sich seit Version 1.8.0 ein einzelner Eintrag nachträglich maskieren, ohne die ganze Historie zu leeren.

Maillog → Rechtsklick auf die Zeile → Diesen Eintrag maskieren. Absender, Empfänger und Betreff werden durch ihre maskierte Fassung ersetzt, so wie sie das Privacy-Masking auch beim Schreiben erzeugt. Alles Übrige bleibt: Zeitpunkt, Status, Größe, Dauer, Quell-IP, Tenant. Der Eintrag verschwindet also nicht, er wird nur unpersönlich.

Es ist endgültig. Die Werte werden in der Datenbank überschrieben, nicht bloß ausgeblendet. Eine Wiederherstellung gibt es nicht, auch nicht mit Administratorrechten. Deshalb kommt vorher eine Rückfrage.

Der Zeitpunkt der Maskierung wird festgehalten und in der Detailansicht des Eintrags angezeigt: Maskiert am …

Aufbewahrungsdauer

Bis 14 Tage kann jede Edition. Darüber hinaus — 30, 60, 90, 180, 365 Tage oder unbegrenzt — ist Enterprise nötig; die längeren Einträge stehen in der Auswahlliste, sind ohne Enterprise aber nicht wählbar. Läuft eine Installation mit längerer Frist auf eine kleinere Lizenz zurück, werden Einträge jenseits von 14 Tagen nicht mehr angezeigt und nicht mehr exportiert, aber auch nicht gelöscht. Gelöscht wird weiterhin nach der eingestellten Frist. Der Dienst schreibt die Einschränkung einmal ins System-Log.

Der Unterschied ist wichtig: Fällt die Lizenz vorübergehend weg, etwa weil dreißig Tage lang niemand auf „online prüfen" gedrückt hat, bleibt Ihre Historie vollständig erhalten und ist nach der Reaktivierung wieder da. Ein Datenverlust darf keine Nebenwirkung eines Lizenzzustands sein.

Sandbox- und Migrationsmodus

Enterprise-Funktion, ab Version 1.8.0. Gedacht für den Tag, an dem hunderte Geräte auf SMTPly umgestellt werden und niemand weiß, was sie tatsächlich verschicken.

Ist der Modus aktiv, geht jede Mail an ein einziges Prüfpostfach statt an die echten Empfänger. Der Betreff bekommt ein Präfix (Vorgabe [SANDBOX] ), dahinter nennt ein Etikett die ursprünglichen Empfänger, etwa [SANDBOX] [orig: kunde@example.com, buchhaltung@example.com +1] Rechnung 4711 (bis zu drei Adressen, danach ein Zähler). Eine eigene Kopfzeile ist nicht möglich, weil Microsoft Graph beim Versand jede selbst gesetzte X-Kopfzeile verwirft. Journal-BCC ist in diesem Modus abgeschaltet — sonst ginge doch noch etwas an ein anderes Postfach.

Zeitfenster. Beginn und Ende lassen sich getrennt setzen, beide sind freiwillig. Ohne beides gilt der Modus vom Einschalten bis zum Abschalten; mit Beginn startet er später, mit Ende gibt er die Zustellung selbsttätig wieder frei. Maßgeblich ist die Ortszeit des Servers, das Ende zählt nicht mehr dazu — ein Fenster bis 08:00 lässt die um 08:00:00 angenommene Mail bereits normal laufen.

Weil ein eingeschalteter Modus, der gerade nicht greift, die verwirrendste aller Lagen ist, steht beides im System-Log: beim Dienststart, ob umgeleitet wird oder nicht, und bei jeder Mail außerhalb des Fensters eine Zeile mit dem Grund. Im Diagnosepaket steht es auf der ersten Seite.

Ohne Enterprise-Lizenz stellt ein eingeschalteter Sandbox-Modus gar nichts mehr zu. Das klingt hart und ist die einzig vertretbare Antwort: Wer den Modus einschaltet, will ausdrücklich, dass nichts beim echten Empfänger ankommt. Würde die Umleitung mangels Lizenz einfach ausbleiben, ginge die Post genau dorthin, obwohl die Oberfläche „aktiv" meldet. Die betroffenen Mails bleiben in der Warteschlange, und im System-Log steht der Grund. Abhilfe: Modus abschalten oder Lizenz aktivieren.

Scheitert die Umleitung an einer unbrauchbaren Adresse, wird die Mail nicht versendet. Im Migrationsmodus wäre die Zustellung an die echten Empfänger der schlechteste denkbare Ausgang.

Ausgehende Regeln

Enterprise-Funktion, ab Version 1.8.0. Regeln steuern den Zustellweg einer Mail: über welchen Tenants sie geht, unter welcher Absenderadresse, und ob sie journalisiert wird. Sie ändern niemals den Inhalt der Nachricht — kein Textbaustein, keine Signatur, kein Haftungsausschluss. Das ist keine Auslassung, sondern Grundregel des Produkts: Was der Listener entgegennimmt, geht Byte für Byte an Microsoft weiter.

Eine Regel besteht aus Bedingungen (Absenderadresse, Absenderdomäne, Empfängerdomäne, Quell-IP, AUTH-Benutzer) und Aktionen (Tenant, Absenderadresse, Journal erzwingen oder unterdrücken). Bei den Empfängern genügt ein passender Empfänger, damit die Regel greift.

Die erste passende Regel gewinnt; spätere Regeln überschreiben eine getroffene Entscheidung nicht. Die Reihenfolge lässt sich in den Einstellungen verschieben. Trifft keine Regel zu, gilt das normale Routing über Absenderdomäne oder AUTH-Benutzerbindung.

REST-Schnittstelle

Enterprise-Funktion, ab Version 1.8.0. Gibt Betriebszustand und Mail-Historie als JSON heraus, damit sich eigene Werkzeuge um SMTPly herum bauen lassen — ein Dashboard über mehrere Server, ein nächtliches Skript, das Fehlschläge einsammelt, oder die Anbindung an ein Ticketsystem.

Nur lesend. Es gibt keinen Endpunkt, der Mail verschickt oder die Konfiguration ändert. Wer das Zugriffs-Secret erbeutet, sieht Verkehrsdaten; anstellen kann er nichts.

Einrichtung unter Einstellungen → REST-Schnittstelle: einschalten, Port und Bind-Adresse festlegen, Zugriffs-Secret erzeugen. Das Secret wird einmal im Klartext angezeigt und danach nur noch verschlüsselt vorgehalten — notieren Sie es sofort. Ohne Secret startet die Schnittstelle nicht.

curl -H "Authorization: Bearer <Secret>" http://127.0.0.1:8026/api/v1/status

Standardmäßig lauscht die Schnittstelle nur auf 127.0.0.1. Wird sie ins Netz gestellt, gehört TLS eingeschaltet — das Kästchen TLS verwenden (HTTPS) steht direkt darunter. Verwendet wird dasselbe Zertifikat wie für den SMTP-Listener; eine zweite Zertifikatsverwaltung gibt es bewusst nicht, es ist derselbe Rechner mit demselben Namen. Ohne brauchbares Zertifikat startet die Schnittstelle nicht, und der Grund steht im System-Log.

Bleibt TLS aus, obwohl die Schnittstelle nicht auf Loopback beschränkt ist, schreibt der Dienst beim Start eine Warnung: Absender, Empfänger und Betreffe gingen dann im Klartext über die Leitung, geschützt wäre nur der Zugang durch das Zeichen.

Auf Wunsch werden Adressen und Betreffe in den Antworten maskiert, nach denselben Regeln wie im Mail-Tracker. Sinnvoll, wo die Auswertung außer Haus geht; standardmäßig aus, weil wer die Schnittstelle einschaltet in aller Regel auswerten will.

Jede erste Anfrage je Aufrufer steht im System-Log, danach eine stündliche Zusammenfassung. Fehlgeschlagene Anmeldungen stehen immer einzeln als Warnung darin.

Welche Daten herauskommen

Vorab das Wichtigste: Mail-Inhalte gibt es nicht. SMTPly speichert weder Text noch Anhänge — die Nachricht geht durch und wird nicht abgelegt. Was die Schnittstelle herausgibt, sind Verkehrsdaten aus dem Mail-Tracker.

Ein Eintrag aus /api/v1/messages enthält diese Felder:

/api/v1/status liefert Version, Edition, Startzeit und Laufzeit, Länge der Warteschlange, Zustand des Sicherungsschalters, den Zustand des Sandbox-Modus samt Zeitfenster, die Restlaufzeit von Zertifikat und Client Secrets je Tenant sowie die Zähler des laufenden Tages. /api/v1/stats gibt dieselben Zähler je Kalendertag samt übertragenem Volumen. /api/v1/tenants nennt Tenant-Name, Verzeichnis-ID, Anwendungs-ID, Absenderadresse und erlaubte Absenderdomänen.

Was nie herauskommt: Mail-Inhalte und Anhänge, Client Secrets, Zugriffstoken, Kennwörter von SMTP-Benutzern und der Inhalt der Konfigurationsdatei. Die Anwendungs-ID steht in den Tenant-Daten, das zugehörige Secret nicht.

Beispiele

Die gescheiterten Zustellungen von gestern, für ein nächtliches Skript:

$kopf = @{ Authorization = "Bearer <Secret>" }
$von  = (Get-Date).AddDays(-1).ToString("yyyy-MM-dd")
$bis  = (Get-Date).ToString("yyyy-MM-dd")

$antwort = Invoke-RestMethod -Headers $kopf `
  -Uri "https://mailrelay01:8026/api/v1/messages?from=$von&to=$bis&status=Failed&limit=200"

$antwort.items | Select-Object timestamp, from, to, errorMessage | Format-Table

Ampel für ein Dashboard über mehrere Server — auch die Restlaufzeit der Geheimnisse, denn die nimmt eine Installation lautlos aus dem Betrieb:

$z = Invoke-RestMethod -Headers $kopf -Uri "https://mailrelay01:8026/api/v1/status"

if ($z.status -ne "ok")               { "ROT:  Versand pausiert ($($z.circuitBreaker))" }
elseif ($z.sandbox.activeNow)         { "GELB: Sandbox aktiv — nichts geht an echte Empfänger" }
elseif ($z.expiry.clientSecretDaysMin -lt 14) { "GELB: Secret läuft in $($z.expiry.clientSecretDaysMin) Tagen ab" }
else                                  { "GRÜN: $($z.today.sent) Mails heute" }

Volumen der letzten 30 Tage als CSV, etwa für eine Abrechnung:

$s = Invoke-RestMethod -Headers $kopf -Uri "https://mailrelay01:8026/api/v1/stats?days=30"
$s.items | Export-Csv -Path volumen.csv -NoTypeInformation -Encoding UTF8

Und der kürzeste Weg, überhaupt erst zu sehen, ob es läuft:

curl -H "Authorization: Bearer <Secret>" https://127.0.0.1:8026/api/v1/status

MCP-Server

Enterprise, ab Version 1.8.0. Bietet dieselben lesenden Abfragen wie die REST-Schnittstelle als Werkzeuge an, die ein KI-Assistent aufrufen kann — Claude Desktop, Claude Code und alles andere, das MCP spricht.

Der Nutzen ist die Fehlersuche im Gespräch. „Warum ist die Rechnung vom Drucker gestern nicht rausgegangen?" beantwortet sich damit in einem Satz, statt dass jemand Zeitraum, Absender und Status von Hand zusammenfiltert.

Was zu bedenken ist, bevor Sie einschalten

Was ein Werkzeug zurückgibt, geht an ein Sprachmodell — je nach Aufbau in die Cloud. Das sind Absender, Empfänger und Betreffe, niemals Mail-Inhalte: Die speichert SMTPly nirgends. Trotzdem sind es Verkehrsdaten Ihrer Organisation.

Deshalb ist der MCP-Server ab Werk aus, die Maskierung ist standardmäßig ein — anders herum als bei der REST-Schnittstelle — und wer sie abschaltet, findet das als Warnung im System-Log. Ob das für Sie in Ordnung geht, entscheiden Sie; SMTPly trifft die Entscheidung nicht für Sie.

Einrichten

Einstellungen → MCP-Server: einschalten, Port und Bind-Adresse festlegen, Zugriffs-Secret erzeugen. Das Secret wird einmal im Klartext angezeigt und danach nur noch verschlüsselt vorgehalten. Ohne Secret startet der Server nicht.

Darunter steht der fertige Eintrag zum Kopieren. Für Claude Desktop gehört er in claude_desktop_config.json, für Claude Code in .mcp.json im Projektordner:

{
  "mcpServers": {
    "smtply": {
      "type": "http",
      "url": "https://127.0.0.1:8027/mcp",
      "headers": {
        "Authorization": "Bearer <Secret>"
      }
    }
  }
}

Die Werkzeuge

Alle fünf sind nur lesend. Es gibt kein Werkzeug, das Mail verschickt oder etwas einstellt.

Welche Daten der Assistent sieht

Dieselben wie über die REST-Schnittstelle, in denselben Feldern: Zeitpunkt, Absender, Empfänger, Betreff, Größe, Quell-IP, angemeldeter Benutzer, Transportart, Status, Versuche, Dauer, Fehlermeldung, Graph-Kennung und Tenant. Dazu Zustand und Tageszahlen aus smtply_status.

Mail-Inhalte und Anhänge sind nicht dabei — die speichert SMTPly nicht. Client Secrets, Zugriffstoken und Kennwörter ebenfalls nicht.

Bei eingeschalteter Maskierung — der Vorgabe — sieht der Assistent m**l@e*****e.com statt der Adresse und vom Betreff die ersten 15 Zeichen. Fehlersuche geht damit weiterhin: Zeitpunkt, Status, Fehlermeldung und Gerät bleiben unverändert lesbar.

Beispielfragen

Gemeint sind Fragen, die sonst Filterarbeit im Dashboard wären:

• „Welche Mails sind gestern fehlgeschlagen und warum?"
• „Hängt gerade etwas in der Warteschlange, und seit wann?"
• „Welches Gerät im Netz versendet am meisten — und über welche Transportart?"
• „Zeig mir alle Zustellungen des Tenants Firma 1 aus der letzten Woche mit Status Failed."
• „Hat der Drucker in der Buchhaltung (192.168.10.44) heute etwas verschickt?"
• „Wie viele Mails gingen in den letzten 30 Tagen raus, und wie verteilt sich das über die Wochentage?"
• „Läuft in den nächsten Wochen ein Client Secret oder das Zertifikat ab?"
• „Ist der Sandbox-Modus gerade aktiv?"
• „Vergleiche die Fehlerquote dieser Woche mit der letzten."

Auch nützlich, weil es sonst zwei Abfragen wären: „Fasse mir zusammen, was heute schiefgelaufen ist, und nenne für jeden Fehler das einliefernde Gerät."

Selbst ausprobieren

Das Protokoll ist JSON-RPC 2.0 über HTTP POST — man kann es ohne Assistenten prüfen:

# Verbindung aufbauen
curl -s -X POST https://127.0.0.1:8027/mcp `
  -H "Authorization: Bearer <Secret>" `
  -H "Content-Type: application/json" `
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-06-18","capabilities":{},
                 "clientInfo":{"name":"curl","version":"1"}}}'

# Werkzeuge auflisten
curl -s -X POST https://127.0.0.1:8027/mcp `
  -H "Authorization: Bearer <Secret>" `
  -H "Content-Type: application/json" `
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# Zustand abfragen
curl -s -X POST https://127.0.0.1:8027/mcp `
  -H "Authorization: Bearer <Secret>" `
  -H "Content-Type: application/json" `
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call",
       "params":{"name":"smtply_status","arguments":{}}}'

Auf Windows PowerShell steht das Zeilenfortsetzungszeichen — der Accent grave — am Zeilenende; unter bash ist es der umgekehrte Schrägstrich.

Der erste Aufruf je Gegenstelle steht im System-Log, danach folgt eine stündliche Zusammenfassung. Fehlgeschlagene Anmeldungen stehen immer einzeln als Warnung darin.

Syslog- und SIEM-Weiterleitung

Enterprise-Funktion, ab Version 1.8.0. Schickt dasselbe, was im System-Log steht, zusätzlich an einen Syslog-Empfänger — Graylog, Splunk, Wazuh, rsyslog und alles andere, was RFC 5424 versteht. Es entsteht bewusst keine zweite, eigene Ereignisliste, die mit der Zeit auseinanderlaufen würde.

Einstellbar sind Empfänger und Port, die Übertragungsart (UDP, TCP oder TCP mit TLS), die Facility, der Anwendungsname und die Mindeststufe. Ein Testknopf schickt eine einzelne Meldung — nötig vor allem bei UDP, wo niemand zurückmeldet, dass die Meldungen im Nichts landen.

Scheitert die Übertragung, wird das nicht ins System-Log geschrieben. Das klingt falsch, ist aber Absicht: Ein Fehler beim Weiterleiten würde eine Meldung erzeugen, deren Weiterleitung wieder scheitert — die Schleife hätte kein Ende. Ob die Meldungen ankommen, prüft man am Empfänger.

So sieht eine Meldung aus

RFC 5424, wie sie über die Leitung geht:

<14>1 2026-08-23T14:07:11.482+02:00 mailrelay01 SMTPly 4812 - - Mail a1f3… an m**l@e*****e.com zugestellt (Tenant „Firma 1", 412 ms)

Vorn steht die Priorität aus Facility und Stufe, dann Zeitstempel mit Zeitzone, Rechnername, Anwendungsname, Prozesskennung. Der Anwendungsname lässt sich einstellen — sinnvoll, wenn mehrere Relays in dasselbe SIEM schreiben.

Empfänger einrichten

rsyslog — eine Datei je Absender, damit SMTPly nicht im allgemeinen Syslog untergeht:

# /etc/rsyslog.d/10-smtply.conf
module(load="imudp")
input(type="imudp" port="514")

if ($programname == "SMTPly") then {
    action(type="omfile" file="/var/log/smtply.log")
    stop
}

Graylog: System → Inputs → Syslog UDP, Port 514, dann ohne weitere Zutat. Die Felder aus RFC 5424 werden erkannt, gesucht wird danach mit application_name:SMTPly.

Splunk: einen UDP-Input auf Port 514 anlegen und sourcetype = syslog setzen. Suche:

index=* sourcetype=syslog "SMTPly" | search "abgewiesen" OR "fehlgeschlagen"

Wazuh: Der Manager liest Syslog über <remote> mit connection=syslog; SMTPly braucht dafür nichts Besonderes.

Womit man rechnen sollte

Bei UDP meldet niemand zurück, dass die Meldungen im Nichts landen — deshalb der Testknopf in den Einstellungen. Er schickt eine einzelne Meldung; ob sie ankommt, sehen Sie nur am Empfänger.

Scheitert die Übertragung, schreibt SMTPly das nicht ins System-Log. Das klingt falsch und ist Absicht: Ein Fehler beim Weiterleiten erzeugte eine Meldung, deren Weiterleitung wieder scheitert — die Schleife hätte kein Ende.

Die Datenschutz-Einstellungen greifen unverändert: Was maskiert im System-Log steht, geht auch maskiert hinaus.

SMTP-Benutzer per CSV anlegen

Business- und Enterprise-Funktion, ab Version 1.8.0. Wer hunderte Geräte-Konten anlegt, klickt sie nicht einzeln.

Einstellungen → SMTP-Authentifizierung → Benutzer importieren. Eine Mustervorlage liegt gleich daneben („Vorlage speichern"). Erkannt werden Komma, Semikolon und Tabulator als Trennzeichen sowie deutsche und englische Spaltenüberschriften. Vor dem Übernehmen zeigt SMTPly, was gelesen wurde, und benennt jede Zeile, die nicht verwendbar ist — mit Zeilennummer und Grund.

Selbsttätiges Update

Ab Version 1.8.2, alle Editionen, im Auslieferungszustand ausgeschaltet. Eingeschaltet installiert der Dienst eine neue Fassung selbständig, sobald der nächste Zeitpunkt in Ihrem Wartungsfenster liegt.

Der Dienst und nicht die Oberfläche, denn unbeaufsichtigt heißt, dass niemand angemeldet ist. Den Ein-Klick-Update in der Oberfläche gibt es weiterhin; wer ihn benutzt, braucht diese Funktion nicht.

Warum es das erst jetzt gibt

Ein Dienst, der Dateien aus dem Netz lädt und ausführt, verhält sich wie Schadsoftware, und zwar unabhängig davon, ob er es gut meint. Vertretbar wurde der Weg erst durch zwei Dinge: die Signierung aller Programmdateien seit Version 1.7.18 und die Signaturprüfung im Updater seit 1.8.2.

Geprüft wird beides, und beides vor dem Ausführen:

• die SHA-256-Prüfsumme gegen das Manifest auf smtply.app
• die Authenticode-Signatur gegen den Herausgeber IT-Beratung - Andreas Hähnel

Keine der beiden Prüfungen genügt allein. Die Prüfsumme steht auf derselben Seite wie der Verweis auf die Datei: Wer die Seite kontrolliert, liefert beides passend zueinander. Die Signatur wiederum belegt den Herausgeber, nicht die Version, mit ihr allein ließe sich eine ältere, echt signierte Fassung unterschieben. Schlägt eine der Prüfungen fehl, wird die Datei gelöscht und der Grund ins System-Log geschrieben.

Das Wartungsfenster

Beginn und Ende in Ortszeit des Servers, dazu wahlweise bestimmte Wochentage. Kein angehakter Wochentag bedeutet täglich.

• Liegt das Ende vor dem Beginn, reicht das Fenster über Mitternacht.
• Der Wochentag ist der Tag, an dem das Fenster beginnt: „Sonntag, 22:00 bis 04:00" ist die Nacht von Sonntag auf Montag, nicht zwei Stummel an zwei verschiedenen Sonntagen.
• Das Ende zählt nicht mehr dazu. Ein Fenster bis 04:00 endet mit der letzten Sekunde davor.

Der Dienst sieht alle zehn Minuten nach. Feiner lohnt sich nicht, ein Wartungsfenster ist üblicherweise Stunden lang.

Was während der Installation passiert

Der Installer hält den Dienst an, tauscht die Dateien und startet ihn wieder. In dieser Zeit nimmt der SMTP-Listener nichts entgegen; Geräte, die währenddessen zustellen wollen, bekommen einen Verbindungsfehler und versuchen es üblicherweise selbst erneut. Bereits eingereihte Nachrichten gehen nicht verloren, sie laufen nach dem Neustart weiter.

Schalten Sie die Funktion nur ein, wenn eine kurze Unterbrechung in diesem Fenster hinnehmbar ist. Wer rund um die Uhr zustellt, lässt sie besser aus und aktualisiert von Hand.

Eine Fassung, die sich nicht installieren ließ, wird nicht in jedem Fenster erneut geladen. Erst eine neuere löst wieder aus. Ohne diese Bremse zöge ein Server mit einem hartnäckigen Problem jede Nacht rund hundert Megabyte und scheiterte jede Nacht gleich.

Wo Sie nachsehen können

• Einstellungen → Updates: Zeitpunkt und Ergebnis des letzten selbsttätigen Versuchs
• System-Log: jeder Versuch mit Begründung, Fehlschläge als Fehler
• Monitoring-Endpunkt und REST-Schnittstelle: unter autoUpdate, dazu die Metriken smtply_auto_update_enabled und smtply_auto_update_in_window. Damit erklärt sich eine Unterbrechung um drei Uhr nachts von selbst, statt als Ausfall zu erscheinen.
• Diagnose-Paket: unter Updates

Zwei Fälle, in denen nichts passiert

Beide sehen im Betrieb gleich aus, nämlich nach „es tut sich nichts". Deshalb melden sich beide von selbst, im System-Log und im Diagnose-Paket:

• Das Wartungsfenster lässt sich nicht lesen, etwa nach einem Tippfehler. Die Warnung erscheint einmal und nicht alle zehn Minuten erneut.
• Die selbsttätige Installation ist eingeschaltet, „Automatisch auf Updates prüfen" aber ausgeschaltet. Dann erfährt der Dienst nie von einer neuen Fassung.

Wartezeit vor der Installation

Seit Version 1.8.7, alle Editionen. Unter Einstellungen → Updates lässt sich festlegen, dass der Dienst eine neue Fassung erst installiert, wenn seit ihrer Veröffentlichung 7 oder 14 Tage vergangen sind (Vorgabe: sofort). Gezählt wird ab dem Veröffentlichungszeitpunkt auf GitHub, nicht ab dem ersten Sehen auf diesem Server. Das gibt anderen Kunden Zeit, ein Problem zuerst zu melden, bevor es Ihren Server erreicht.

Lässt sich der Veröffentlichungszeitpunkt nicht ermitteln, etwa weil der Server GitHub nicht erreicht, installiert der Dienst vorsichtshalber nicht, statt die Wartezeit zu überspringen. Der Grund steht im System-Log.

Ist ein Update verfügbar, zeigt die Navigation neben Über eine grüne „1“.

Empfänger-Beschränkung je Quell-IP

Seit Version 1.8.7, in allen Editionen, im Auslieferungszustand ausgeschaltet. Legt fest, an wen ein bestimmtes Gerät senden darf. Gedacht für Geräte, die aus der Natur ihrer Aufgabe nie beliebige Empfänger brauchen, etwa eine Alarmanlage, die nur die eigene Firma benachrichtigt. Wird ein solches Gerät gekapert oder falsch konfiguriert, wird es dadurch nicht zum offenen Relay nach außen.

Einstellungen → Absender und Empfänger, je SMTP-Listener. Eine Regel besteht aus:

• Quell-IP oder CIDR-Netz, zum Beispiel 192.168.1.5 oder 192.168.1.0/24 (IPv4 und IPv6)
• Erlaubten Empfängern, einer je Zeile: eine volle Adresse wie alarm@example.com oder @example.com für die ganze Domäne

So wird geprüft:

• Geprüft werden die Umschlag-Empfänger (RCPT TO) und die Empfänger in den Kopfzeilen To:, Cc: und Bcc:. Microsoft 365 stellt an die Kopfzeilen zu; bis Version 1.8.8 wurden nur die Umschlag-Empfänger geprüft. Ein Gerät, das in die Kopfzeilen andere Empfänger schreibt als in den Umschlag, wird seit 1.8.9 abgewiesen.
• Gilt für eine Quell-IP keine Regel, bleibt sie unbeschränkt. Die Funktion engt nur die Geräte ein, für die Sie eine Regel anlegen.
• Passt auch nur ein Empfänger zu keiner erlaubten Angabe, lehnt SMTPly die ganze Mail mit SMTP 550 ab. Einzelne Empfänger werden nicht herausgestrichen, weil SMTPly Nachrichten grundsätzlich nicht verändert.
• Die Ablehnung steht im System-Log und im Mail-Tracker. Der Selbsttest warnt, wenn eine Regel eingeschaltet ist, aber keine erlaubten Empfänger enthält.

Bewusst an keine Edition gebunden: Das ist eine Sicherheitshärtung, und gerade Installationen mit vielen ungewarteten Altgeräten brauchen sie.

Freigabe- und Sperrlisten

In allen Editionen und im Auslieferungszustand alle ausgeschaltet: die drei Sperrlisten seit Version 1.8.8, die Freigabelisten für Absender und Empfänger seit 1.8.9. Bestehende Installationen verhalten sich nach dem Update unverändert. Freigaben gab es schon vorher: erlaubte Quell-IPs, erlaubte Absender-Domänen je Tenant und die Empfänger-Beschränkung. Die Sperrlisten schließen einzelne Geräte, Absender oder Empfänger innerhalb einer Freigabe aus, die Freigabelisten lassen nur noch bestimmte Adressen durch.

Absender und Empfänger tragen Sie als volle Adresse ein (mail@example.com) oder als Domäne (@example.com). Eine Domäne trifft genau diese Domäne, keine Subdomänen. Trifft ein Eintrag, lehnt SMTPly die ganze Mail mit SMTP 550 ab (Quell-IP gesperrt, Absender gesperrt oder Empfänger gesperrt). Einzelne Empfänger werden nicht herausgestrichen, weil SMTPly Nachrichten nicht verändert.

Freigabelisten für Absender und Empfänger

Die erlaubten Absender-Domänen beim Tenant gelten für eine ganze Domäne. Wer nur einzelne Absender zulassen will, etwa nur scanner@example.com und @erp.example.com, schaltet unter Einstellungen → Absender und Empfänger die Freigabeliste für Absender ein. Ebenso lässt die Freigabeliste für Empfänger nur Mails an die eingetragenen Adressen oder Domänen durch, etwa nur an die eigene Firma, von jeder Quell-IP aus. Für einzelne Geräte gibt es daneben weiter die Empfänger-Beschränkung je Quell-IP.

• Die Freigabelisten gelten zusätzlich zu den erlaubten Absender-Domänen der Tenants und auch für Geräte mit SMTP-Anmeldung.
• Die Sperrlisten werden vorher geprüft: Eine Sperre gewinnt immer, auch gegen einen Eintrag in der Freigabe.
• Nicht freigegebene Mails werden mit SMTP 550 abgelehnt (Absender nicht freigegeben bzw. Empfänger nicht freigegeben), bei Empfängern die ganze Mail, sobald einer nicht passt.
• Eine eingeschaltete, aber leere Freigabeliste lässt keine einzige Mail durch. SMTPly fragt deshalb vor dem Speichern nach, der Selbsttest meldet sie als Fehler.
• Die Testmail aus den Einstellungen läuft ebenfalls über den Listener. Tragen Sie ihre Absender- und Empfängeradresse mit ein, sonst wird auch sie abgelehnt.

Eine abgelehnte Mail wird weder angenommen noch zwischengespeichert noch an Microsoft 365 weitergegeben. Das einsendende Gerät erfährt die Ablehnung direkt in der SMTP-Sitzung, mit Grund. Ob daraus eine Unzustellbarkeitsnachricht oder nur ein Eintrag im Geräteprotokoll wird, entscheidet das Gerät. Im Maillog zählt die Mail unter Fehler, im Nutzungsreport als abgelehnt.

Rückmeldung per Mail (optional)

Unter Einstellungen → E-Mail-Benachrichtigungen gibt es seit 1.8.8 zwei weitere Anlässe, beide standardmäßig aus:

• Warn-Mail bei abgelehnter Mail an die Benachrichtigungs-Adresse, mit Grund, Quell-IP, Absender und Empfänger. Höchstens eine Mail pro 15 Minuten, weitere Fälle werden mitgezählt.
• Absender über Ablehnung informieren: eine kurze Mail mit dem Grund an den Absender. Bewusst eng gefasst, weil sich Absenderadressen fälschen lassen und eine Antwort an fremde Adressen in Ihrem Namen hinausginge: nur für Absender, deren Domäne bei einem Tenant erlaubt ist, nie bei Ablehnungen wegen der Quell-IP, nie bei gesperrten oder nicht freigegebenen Absendern, nie bei der Empfänger-Beschränkung je Quell-IP, nie bei unlesbaren Mails, nie bei vorübergehender Ratenbegrenzung, höchstens einmal pro Stunde je Absender und höchstens 20 Rückmeldungen je Stunde insgesamt. Die Rückmeldung nennt Grund und Zeitpunkt, aber weder Betreff noch Empfänger der abgelehnten Mail. Sie ist seit 1.8.10 immer englisch, weil SMTPly die Sprache des Absenders nicht kennt, und die Sperre „einmal pro Stunde" übersteht einen Neustart des Dienstes.

Alle Hinweis-Mails an den Administrator (Warn-Mails, Ablaufwarnungen, Lizenz, Statusbericht, Sicherung) erscheinen seit 1.8.10 in der Oberflächensprache, die in SMTPly eingestellt ist; bei „Automatisch" in der Windows-Sprache des Servers.

Direkt aus dem Mail-Tracker

In der Detailansicht eines Eintrags sind Absender, Empfänger und Quell-IP anklickbar. Das Menü zeigt oben den Stand und darunter nur, was dazu passt:

• Sperren: bei Absender und Empfänger wahlweise die Adresse oder die ganze Domäne, bei mehreren Empfängern je Empfänger. Die passende Sperrliste wird dabei eingeschaltet. Adressen des Servers selbst lassen sich nicht sperren, sonst träfe es Testmail, Selbsttest und lokale Anwendungen.
• Sperre aufheben: bei einem gesperrten Wert; alle Einträge, die ihn treffen, werden entfernt.
• Erlauben: bei einer nicht freigegebenen Quell-IP (sie kommt in die Freigabe), bei einem Absender, dessen Domäne keinem Tenant zugeordnet ist (die Domäne wird beim Haupt-Tenant erlaubt), und bei eingeschalteter Freigabeliste für Absender oder Empfänger wahlweise die Adresse oder die ganze Domäne. Eine ausgeschaltete Freigabeliste schaltet der Mail-Tracker nie selbst ein, sonst wären alle übrigen Absender auf einen Schlag ausgesperrt.

Gesperrte Werte sind rot, nicht freigegebene gelb, auch in künftigen Einträgen und in der Tabelle. Erlaubte Werte bleiben ungefärbt, weil das fast jede Zeile wäre.

Jede Aktion fragt nach, speichert die Einstellungen und startet den Dienst neu, damit sie sofort greift. Die abgelehnte Mail selbst wird nicht nachträglich zugestellt, das Gerät muss sie erneut senden. Gibt es in den Einstellungen noch ungespeicherte Änderungen, trägt SMTPly nur den Wert ein und bittet ums Speichern, statt fremde Änderungen ungefragt mitzuspeichern. Die Links setzen Administratorrechte voraus.

Wo es sichtbar ist

Jede Ablehnung steht im System-Log und im Mail-Tracker. Beim Start des Listeners meldet das Protokoll, welche Listen aktiv sind, eine leere Freigabeliste als Warnung. Das Diagnose-Paket führt alle Listen auf, der Selbsttest warnt bei einer eingeschalteten, aber leeren Sperrliste, bei einer IP-Sperre, die den Server selbst trifft, und bei einer Absender-Freigabe ohne die Absenderadresse des Haupt-Tenant. Sicherung und Wiederherstellung übernehmen die Listen wie jede andere Einstellung.

IPv4 und IPv6

Beide Adressfamilien sind gleichwertig, am SMTP-Listener wie an den HTTP-Schnittstellen. Was Sie als Bind-Adresse eintragen, wird überall gleich ausgelegt:

Bei „alle Schnittstellen" öffnet der SMTP-Listener je Adressfamilie einen eigenen Socket auf demselben Port. Das ist kein Umweg, sondern nötig: Ein Socket auf 0.0.0.0 nimmt ausschließlich IPv4 entgegen, einer auf :: ausschließlich IPv6.

Auch die Whitelist versteht IPv6, als Einzeladresse und als CIDR-Netz, gemischt mit IPv4-Regeln in derselben Liste. Eine Regel mit Tippfehler wird sofort gemeldet, statt stillschweigend übersprungen zu werden. Die Ratenbegrenzung zählt bei IPv6 auf dem /64, nicht je Adresse: Ein Gerät bekommt dort üblicherweise ein ganzes /64 und wechselt seine Adresse darin selbständig, ein Limit je Adresse liefe also ins Leere.

Wo Sie nachsehen können, welche Familien tatsächlich bedient werden:

• Selbsttest: Zeile IPv4 / IPv6, mit Warnung, wenn der Rechner IPv6 hat, der Listener aber nur IPv4 bedient
• Diagnose-Paket: unter SMTP-Listener, samt Hinweis bei Schieflage
• System-Log: jede angenommene Mail vermerkt die Familie hinter der Quell-IP
• Maillog: Spalte IP-Version (vorab abgewählt) und ein Kennzeichen in der Detailansicht, beides such- und filterbar

Eine als IPv4 gemappte IPv6-Adresse (::ffff:…) zählt als IPv4, denn die Gegenstelle hat IPv4 gesprochen.

Grenzwerte & Limits

SMTPly hält sich an alle Graph-Throttling-Hinweise — wenn Microsoft einen Retry-After-Header schickt, respektiert die Queue das automatisch und wartet entsprechend.

Lizenzierung

SMTPly wird als Einmalkauf mit einer pro Server gebundenen Lizenz angeboten. Die Aktivierung erfolgt online über das Polar-Lizenzsystem.

• 14-Tage-Testphase — voller Enterprise-Funktionsumfang, keine Limits, automatisch beim ersten Start. Wer testet, soll alles sehen können, was zu kaufen ist.
• Aktivierung — Lizenzschlüssel in GUI → „Lizenz" einfügen und bestätigen.
• Hardware-Bindung — Fingerabdruck aus mehreren voneinander unabhängigen Merkmalen der Maschine, allen voran der SMBIOS-UUID. Auf virtuellen Maschinen gehört sie zur VM selbst und wandert bei der Live-Migration mit: Ein Knotenwechsel im Failover-Cluster, eine ausgetauschte Netzwerkkarte oder eine Wiederherstellung aus dem Backup machen die Lizenz nicht ungültig. Ein Umzug auf einen anderen Server erfordert weiterhin die vorherige Deaktivierung.
• Offline-Grace — nach erfolgreicher Aktivierung läuft SMTPly bis zu 30 Tage ohne Internet-Check weiter.
• Selbsttätige Online-Prüfung — der Dienst prüft die Lizenz seit Version 1.8.6 einmal täglich selbständig online, unabhängig davon, ob jemand die Oberfläche öffnet. Ist der Netzabgang eingeschränkt, muss dieser Aufruf erlaubt sein, sonst greift nach 30 Tagen die Offline-Grace.
• Deaktivierung — GUI → „Lizenz" → „Deaktivieren". Danach kann der Schlüssel woanders aktiviert werden.
• Frühwarnung (seit 1.8.7, Business und Enterprise): Nähert sich die letzte erfolgreiche Online-Prüfung der 30-Tage-Grenze, warnt SMTPly 14, 7, 3 und 1 Tag vorher per E-Mail und Webhook (license.revalidation_due). Einzuschalten unter Einstellungen → E-Mail-Benachrichtigungen.
• Ohne gültige Lizenz (seit 1.8.9) pausiert der Versand: Geräte erhalten eine vorübergehende Ablehnung (451) und versuchen es später erneut, wartende Mails bleiben in der Warteschlange und gehen nach der Aktivierung hinaus. SMTPlys eigene Hinweise an den Administrator gehen weiter. Nach abgelaufener Testphase und bei einer von Polar widerrufenen Lizenz gilt das sofort. Ist eine bezahlte Lizenz nur gerade nicht bestätigbar (30 Tage ohne Online-Prüfung, Hardware nach einer Migration nicht wiedererkannt), läuft SMTPly noch 14 Tage mit allen Funktionen der gekauften Edition weiter (Business bleibt Business, Enterprise bleibt Enterprise); SMTPly warnt in dieser Zeit täglich per E-Mail, im System-Log, im Selbsttest und in der Oberfläche. Vor dem Ende der Testphase erinnert SMTPly drei Tage und einen Tag vorher.
• Wiederherstellen (seit 1.8.7): Ist die Lizenz nur unbestätigt, weil 30 Tage lang keine Online-Prüfung gelang, steht auf der Seite Lizenz der Knopf Online neu prüfen. Eine erfolgreiche Prüfung stellt die Lizenz vollständig wieder her, ohne erneute Aktivierung. Daneben führt ein Link ins Kundenportal von Polar.

Für Aktivierung, Deaktivierung und jede Online-Prüfung (manuell wie selbsttätig) spricht SMTPly ausschließlich diesen einen Endpunkt an:

Kein weiterer Host ist für den Lizenz-Abgleich nötig. Der Ein-Klick-Update-Mechanismus prüft zusätzlich smtply.app (ebenfalls Port 443), das ist aber ein eigener, vom Lizenz-Abgleich unabhängiger Vorgang.

Sitzungsobergrenzen

Seit Version 1.8.2 begrenzt SMTPly die Zahl gleichzeitig offener SMTP-Sitzungen, insgesamt und je Quell-IP. Das ist eine Schutzmaßnahme gegen einen einzelnen Client, der eine Verbindung öffnet und dann endlos Daten schiebt, ohne die Nachricht zu beenden. Ein solcher Client bindet Arbeitsspeicher im Dienst, und ohne Obergrenze summiert sich das über viele Verbindungen.

Der normale Betrieb schlägt nie an: Drucker, ERP-Systeme und Monitoring liefern seriell über eine oder wenige Verbindungen ein, nicht über Dutzende parallel. Wird eine weitere Sitzung abgewiesen, steht das im System-Log; überzählige Verbindungen werden geschlossen, bestehende laufen unberührt weiter. Die drei Werte sind Sonderfall-Einstellungen ohne eigene Oberfläche und lassen sich bei Bedarf von Hand in der Konfiguration ändern. Der Zustand steht auch im Diagnose-Paket unter SMTP-Listener.