Sophos Firewall SPX E-Mail-Verschlüsselung einrichten

Mit Secure PDF Exchange, kurz SPX, wandelt Sophos Firewall eine ausgehende E-Mail samt Anhängen in eine passwortgeschützte PDF-Datei um. Der Empfänger braucht keinen eigenen Verschlüsselungsclient. Je nach gewähltem Passwortmodell erhält er ein einmaliges Passwort, verwendet ein gespeichertes Passwort oder registriert selbst eines.

Für einen verlässlichen Betrieb müssen vier Teile zusammenpassen: ein SPX-Template, ein eindeutiger Auslöser, ein sicherer Passwortweg und bei Bedarf das SPX Reply Portal. Danach werden ein positiver und ein negativer Mailflow getestet. Eine zugestellte PDF allein beweist weder, dass die richtige Policy ausgelöst hat, noch dass Passwortregistrierung und sichere Antwort funktionieren.

SPX in acht Schritten

1. Email-Protection-Lizenz, MTA-Mailflow, Modellunterstützung, Portalzertifikat und den separaten SMTP-TLS-Pfad prüfen.
2. Festlegen, ob eine geschützte Domain, ein Data-Control-Treffer oder der Absender die Verschlüsselung auslöst.
3. Unter Email > Encryption > SPX templates > Add ein eigenes Template erstellen.
4. Passworttyp, PDF-Verschlüsselung, Benachrichtigung und Reply Portal bewusst wählen.
5. Unter Email > Encryption > SPX portal settings FQDN, erlaubte Netze und Port absichern.
6. Im MTA Mode die SMTP route and scan Policy konfigurieren und das Template zuordnen; ein Default SPX template ersetzt diese Policy nicht.
7. Mit einem externen Testempfänger PDF, Passwortweg, Registrierung und Antwort prüfen.
8. Einen Negativtest ohne SPX-Trigger durchführen und Mail logs, MTA-Logs sowie Rollback dokumentieren.

⚠️ Ein leeres Feld Allowed networks bedeutet beim SPX Portal nicht „kein Zugriff“, sondern fällt auf Any zurück. Sophos empfiehlt für das Reply Portal zudem einen eigenen Port. Portal-FQDN, Zertifikat, erlaubte Quellen und Passwortweg müssen deshalb vor dem produktiven Test feststehen.

Wann SPX passt

SPX eignet sich, wenn externe Empfänger ohne eigenen Verschlüsselungsclient vertrauliche Inhalte als geschützte PDF erhalten sollen. Es kann sowohl im MTA Mode als auch im Legacy Mode eingesetzt werden. Dieser Ablauf verwendet den MTA Mode, weil sich Domain, Data Control und Routing dort nachvollziehbar in der SMTP-Policy verbinden lassen. Den transparenten Alternativpfad erklärt Mail Protection im Legacy Mode einrichten.

SPX ist keine Transportverschlüsselung zwischen Mailservern und auch keine durchgängige Ende-zu-Ende-Verschlüsselung zwischen zwei Mailclients. Die Firewall verarbeitet den Klartext, erzeugt die PDF und steuert Passwort beziehungsweise Registrierung. Die PDF kann danach ausserhalb der Firewall in Postfächern, Archiven oder Downloads weiterbestehen. Empfängerkreis, Aufbewahrung und Passwortübermittlung gehören daher zum Sicherheitsdesign.

SMTP-Transportverschlüsselung wird unabhängig davon unter Email > General settings > SMTP TLS configuration gesteuert. Require TLS negotiation erzwingt TLS für ausgewählte Remote Hosts oder Netze; kann SFOS die TLS-Verbindung nicht aufbauen, verwirft es die E-Mail an dieses Ziel. Skip TLS negotiation erzwingt dagegen eine unverschlüsselte SMTP-Verbindung. Das dort gewählte TLS certificate schützt den SMTP-Pfad und ist nicht mit dem Zertifikat der SPX-Portale gleichzusetzen. SPX und SMTP-TLS werden deshalb getrennt geplant und gemeinsam im externen Mailflow geprüft.

Vorausgesetzt werden:

• eine gültige Email-Protection-Lizenz;
• ein bereits getesteter ausgehender Mailflow über Sophos Firewall;
• ein dokumentierter externer Testempfänger;
• ein vertrauenswürdiger FQDN und ein passendes Zertifikat für die verwendeten SPX-Portale;
• ein getrennter, sicherer Kanal für Passwörter, wenn sie nicht vom Empfänger registriert werden;
• ein Rückweg, mit dem sich Template- und Policy-Zuweisungen wieder entfernen lassen.

SPX ist laut aktueller Sophos-Hilfe auf XGS 87/87w nicht verfügbar. Der vollständige MTA Mode ist zusätzlich auf XGS 88/88w nicht verfügbar. Mailflow, Lizenz, Relay und Modellgrenzen erklärt Mail Protection im MTA Mode einrichten.

Trigger und Priorität festlegen

SPX kann aus drei Richtungen ausgelöst werden. Werden mehrere Wege konfiguriert, wendet Sophos Firewall im MTA Mode diese Reihenfolge an:

1. Geschützte Domain: Das unter Domains and routing target ausgewählte SPX-Template gilt für ausgehende Nachrichten der passenden geschützten Domain.
2. Data control list: Nur wenn auf Domain-Ebene kein SPX-Template gesetzt ist, kann ein Data-Control-Treffer das bei der Liste ausgewählte Template anwenden.
3. Absender-Trigger: Erst wenn weder Domain noch Data Control ein Template liefern, greift das unter Default SPX template vorgesehene Senderverfahren.

Eine Domain-Zuweisung ist breit und passt nur, wenn wirklich jede passende ausgehende Nachricht verschlüsselt werden soll. Data Control eignet sich für definierte Inhaltstypen, muss aber mit echten positiven und negativen Beispielen auf False Positives geprüft werden. Der Sender-Trigger gibt dem Absender die Entscheidung, setzt jedoch einen sauber dokumentierten Mailclient-Ablauf voraus.

Vor der Konfiguration wird pro Mailflow genau ein primärer Trigger festgelegt. Eine zweite Methode darf nicht unbemerkt eine andere übersteuern.

SPX-Template erstellen

Das Beispiel verwendet das Template Finance-SPX-Recipient. Der Name ist ein Dokumentationswert und wird an Zweck und Organisation angepasst.

Für unterschiedliche Kundendomains können getrennte Templates mit passenden Texten und Firmenlogos verwendet werden. Entscheidend ist nicht nur das Erscheinungsbild: Die Empfängerhinweise müssen zum Passwortmodell und zur tatsächlich zugeordneten Domain passen.

1. Email > Encryption > SPX templates öffnen.
2. Add wählen.
3. Als Namen zum Beispiel Finance-SPX-Recipient eintragen. Im Namen erlaubt SFOS keine Apostrophe, Schrägstriche, Kommas, Backslashes oder Anführungszeichen.
4. Den Organisationsnamen für die Benachrichtigungen setzen.
5. Encryption standard und PDF page size entsprechend der eigenen Vorgabe wählen.
6. Unter Password type das geplante Passwortmodell auswählen.
7. Betreff, Nachrichtentext und Empfängerhinweise prüfen und bei Bedarf anpassen.
8. Für diesen MTA-Ablauf Enable SPX reply portal aktivieren, wie es die Template-Hilfe verlangt. Den Portalzugriff vor dem Test wie unten beschrieben absichern.
9. Include original body into reply nur aktivieren, wenn die ursprüngliche Nachricht in der Antwort erscheinen darf.
10. Speichern.

Passwortmodell bewusst wählen

Sophos Firewall bietet vier Modelle:

• Specified by sender: Der Absender setzt das Passwort. Die Firewall entfernt es vor dem Versand und speichert es nicht. Das Passwort muss über einen getrennten sicheren Kanal zum Empfänger gelangen.
• Generate one-time password for every email: Die Firewall erzeugt für jede Nachricht ein neues Passwort und sendet es an den Absender. Dieser übermittelt es separat an den Empfänger. Das Passwort wird nicht gespeichert.
• Generated and stored for recipient: Die Firewall erzeugt ein empfängerspezifisches Passwort, sendet es an den Absender und verwendet es bis zum Ablauf weiter.
• Specified by recipient: Ein noch nicht registrierter Empfänger erhält einen Registrierungslink, legt sein Passwort selbst fest und verwendet es bis zum Ablauf für weitere SPX-Nachrichten der Organisation.

Bei Specified by recipient gilt: Die erste verschlüsselte Nachricht wird erst nach der Passwortregistrierung versendet; der Registrierungslink ist daher noch keine zugestellte SPX-PDF.

Für ein wiederkehrendes Partnerverhältnis ist Specified by recipient häufig der verständlichste Ablauf. Für einen einzelnen besonders sensiblen Versand kann ein Einmalpasswort besser passen. Verschiedene gespeicherte Passwortmodelle für denselben Empfänger sollten nicht ungeplant gemischt werden, weil der Empfänger sonst je Nachricht das zugehörige Passwort erkennen muss.

Bei Specified by sender wird das Passwort im Betreff im Muster [secure:<password>]<subject text> angegeben. Der Absender muss das Passwort danach getrennt übermitteln. Für Microsoft Outlook stellt Sophos einen Outlook Add-in unter Authentication > Client downloads bereit.

Nach der geprüften Installation wird in Outlook für die zu verschlüsselnde Nachricht Encrypt gewählt. Ein installiertes Add-in allein löst die Verschlüsselung noch nicht aus.

Outlook Add-in kontrolliert installieren

Benutzer ohne WebAdmin-Zugang öffnen im User Portal Download client und wählen Download Sophos Outlook Add-in. Das heruntergeladene Archiv wird in einen temporären Ordner entpackt; für die interaktive Installation startet man dort setup.exe. Der administrative Download unter Authentication > Client downloads ist davon als Zugangsweg zu unterscheiden.

MSI-Dateiname vor der Verteilung prüfen: Die User-Portal-Hilfe für SFOS 22 und 23 nennt SophosOutlookAddInSetup.msi; die SPX-Installationsbeschreibung nennt dagegen SophosOutlookAddInSetupUTM.msi, wie im bestehenden Beispiel unten. Diese Namen sind nicht als austauschbar bestätigt. Im entpackten Paket muss der tatsächliche MSI-Dateiname geprüft werden. Das folgende Beispiel gilt nur, wenn die Datei wirklich SophosOutlookAddInSetupUTM.msi heisst. Bei einem Paket mit SophosOutlookAddInSetup.msi wird genau dieser vorhandene Name als Argument von /i verwendet; die dokumentierten Schalter /qr /i und T=1 EC=3 C=1 I=1 bleiben unverändert. Fehlt die erwartete MSI oder ist das Paket nicht eindeutig zugeordnet, wird die Verteilung gestoppt und das Paket geklärt, statt eine Datei umzubenennen oder eine moderne Plattformunterstützung anzunehmen.

Für eine interaktive Installation wird aus dem von der aktiven Firewall geladenen Paket setup.exe gestartet. Sophos dokumentiert für eine unbeaufsichtigte Verteilung diesen Befehl:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

Die öffentliche Kompatibilitätsliste ist auffällig alt: Die SFOS-Hilfe dokumentiert für die unbeaufsichtigte Installation des SPX Outlook Add-in folgende historische Voraussetzungen: Windows XP, Windows Vista, Windows 7 oder Windows 8, jeweils in 32-Bit- und 64-Bit-Ausführung; Microsoft Outlook 2007 SP3, 2010 oder 2013, ebenfalls jeweils in 32-Bit- und 64-Bit-Ausführung; Microsoft .NET Framework 4 Client Profile sowie Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. Daraus lässt sich keine Unterstützung für aktuelle Microsoft-365-Apps oder moderne Windows-Versionen ableiten. Vor einer breiten Verteilung werden deshalb das tatsächlich geladene Paket, Windows- und Outlook-Version samt Bitness, positiver und negativer SPX-Trigger sowie die Deinstallation auf einem Pilotgerät geprüft. Die nicht erläuterten MSI-Parameter werden nicht auf Verdacht verändert.

Die aktuelle Sophos-Hilfe verwendet für andere Mailclients zwei unterschiedliche Header-Schreibweisen: X-Sophos-SPXEncrypt: yes auf der Template-Seite und X-Sophos-SPX-Encrypt: yes in der allgemeinen Encryption-Seite. Diese Abweichung wird nicht als Copy-paste-Rezept behandelt. Vor einem produktiven Client-Rollout wird die tatsächlich funktionierende Schreibweise auf dem eingesetzten SFOS-Build geprüft. Wo möglich, sind Policy, Data Control oder der Sophos Outlook Add-in der besser nachvollziehbare Auslöser.

Benachrichtigung ohne neue Datenlücke gestalten

Für Benachrichtigungen stehen unter anderem diese Variablen zur Verfügung:

• %ENVELOPE_TO%: Empfänger des Passworts.
• %PASSWORD%: Passwort zum Öffnen der SPX-PDF.
• %ORGANIZATION_NAME%: im Template eingetragener Organisationsname.
• %SENDER%: Absender der E-Mail.
• %REG_LINK%: Link zur Passwortregistrierung.

Einfache HTML-Formatierung und Links sind möglich. Texte müssen erklären, von wem die Nachricht stammt, wie das Passwort sicher bezogen wird und wie lange Registrierung beziehungsweise Antwort möglich sind. Zugangsdaten oder vertrauliche Mailinhalte gehören nicht zusätzlich in einen ungeschützten Benachrichtigungstext.

Reset stellt die Standardbenachrichtigung wieder her. Vorher werden eigene Texte gesichert; nach dem Zurücksetzen werden Betreff, Nachrichtentext und Empfängerhinweise erneut geprüft.

Gültigkeit und Fehlerbenachrichtigungen einstellen

Unter Email > Encryption > SPX configuration, nicht unter SPX portal settings, werden die Zeiträume und Fehlerempfänger festgelegt:

• Keep unused password for: Gültigkeit eines gespeicherten Passworts, wenn an diesen Empfänger keine SPX-Nachricht gesendet wird. Bei beispielsweise drei Tagen endet die Gültigkeit laut Hilfe um Mitternacht am Ende des dritten Tages. Das ist ein Inaktivitätszeitraum, keine pauschale Lebensdauer jeder PDF.
• Allow secure reply for: Anzahl Tage, in denen der Empfänger über das SPX Reply Portal antworten kann; diese Einstellung gehört zum MTA-Ablauf.
• Allow password registration for: Zeitraum, nach dem der Registrierungslink abläuft. Er ist vom Zeitraum für gespeicherte Passwörter getrennt.
• Send error notification to: Zuständige Empfänger der SPX-Fehlerbenachrichtigungen. Die Fehlermeldungen werden auch im SMTP-Log aufgeführt.

Die Zeiträume werden nach Antwortbedarf und Sicherheitsvorgaben der Organisation gewählt. Im Pilot werden Registrierung, Passwort-Inaktivität und Reply-Frist getrennt geprüft. Ein Ablauf auf der Firewall ist kein Nachweis, dass eine bereits zugestellte PDF gelöscht oder unlesbar geworden ist.

SPX-Portale absichern

Unter Email > Encryption > SPX portal settings werden Passwortregistrierung und Portalzugriff festgelegt:

1. Unter Hostname den FQDN eintragen, unter dem externe Empfänger das Portal tatsächlich erreichen.
2. Bei Allowed networks nur die benötigten Quellnetze setzen. Any ist nur sinnvoll, wenn beliebige externe Empfänger das Portal erreichen müssen und das Risiko bewusst akzeptiert ist.
3. Den Port dokumentieren. Das Password Registration Portal verwendet standardmässig TCP 8094.
4. Für das SPX Reply Portal einen eigenen Port verwenden.

Bleibt Allowed networks leer, verwendet SFOS Any, weil das SPX Reply Portal standardmässig in der WAN-Zone aktiv ist. Wird das Reply Portal nicht benötigt, beschreibt Sophos als Abschaltung eine unbenutzte vertrauenswürdige private Adresse, zum Beispiel 169.254.0.1, als einziges erlaubtes Netz. Dieser Dokumentationswert darf nicht einer produktiv genutzten Adresse entsprechen.

CAPTCHA ist am SPX Portal immer aktiv und lässt sich nicht deaktivieren. Die Grenzen anderer Portal-CAPTCHAs erklärt CAPTCHA auf Sophos Firewall bewusst steuern.

WebAdmin, User Portal, VPN Portal, Captive Portal und die beiden SPX-Portale verwenden dieselbe zentrale Zertifikatsauswahl. Ein Wechsel kann deshalb mehrere Dienste gleichzeitig betreffen. Zertifikat, SANs, Rückweg und echte Portal-URL werden nach Zertifikate auf Sophos Firewall verwalten geplant. Für einen öffentlichen Namen kann ein Let’s-Encrypt-Zertifikat auf Sophos Firewall passen.

Die Auswahl liegt unter Administration > Admin and user settings > Admin console and end-user interaction > Certificate. Die Zertifikatsidentität in SAN beziehungsweise CN muss zum unter Hostname verwendeten Portal-FQDN passen, und die vollständige CA-Kette muss auf der Firewall vorhanden sein. Ein Zertifikatswechsel wird daher nicht als reine SPX-Änderung behandelt: WebAdmin und die anderen Portale werden nach dem Wechsel ebenfalls geprüft.

Template mit der SMTP-Policy verbinden

Für MTA Mode wird das SPX-Template unter Email > Policies and exceptions in der passenden SMTP route and scan Policy ausgewählt.

Domain als Auslöser

Unter Domains and routing target wird das Template der geschützten Domain zugewiesen. Danach gilt es für die passenden ausgehenden Nachrichten. Eine breite Domain-Zuweisung wird zuerst mit einem Pilotabsender und einem externen Testempfänger geprüft.

Data Control als Auslöser

Eine Data Control List ist keine frei formulierte Inhaltsregel. Sie wird aus Sophos Content Control Lists, kurz CCLs, für definierte Datenmuster aufgebaut. Beim Anlegen werden die CCLs nach Type und Region gefiltert. Für den Pilot gehören nur die tatsächlich benötigten Muster in die Liste, damit ein SPX-Versand nicht durch eine zu breite Auswahl unnötig ausgelöst wird.

1. Unter Email > Data control list eine klar benannte Liste erstellen oder die bestehende Liste prüfen.
2. In der SMTP-route-and-scan-Policy Data protection aktivieren und unter Data control list genau diese Liste auswählen.
3. Data control list action auf Accept with SPX setzen und das vorgesehene SPX template auswählen. Accept liefert ohne SPX aus, Drop verwirft die Nachricht ohne Absenderbenachrichtigung.
4. Einen positiven Inhaltstest und einen ähnlichen negativen Test durchführen.

Ist bereits ein SPX-Template unter Domains and routing target gesetzt, hat dieses Vorrang vor dem Data-Control-Template. Ein Treffer der Data Control List beweist zudem nur den konfigurierten Inhaltsmatch. Ob die richtige Nachricht verschlüsselt wurde, muss im realen Mailflow geprüft werden.

Absender-Trigger verwenden

Unter Email > Encryption > SPX configuration wird ein Default SPX template ausgewählt. Es greift für senderseitig ausgelöste SPX-Verschlüsselung nur dann, wenn die SMTP-Policy nicht bereits ein Template auf Domain- oder Data-Control-Ebene liefert. None schaltet diesen Defaultpfad aus.

Für den MTA Mode verlangt die Hilfe ausdrücklich eine konfigurierte SMTP route and scan Policy und die Template-Auswahl unter Domains and routing target oder Data control list. Sie nennt example.com als Dummy-Domain, wenn keine geschützte Domain angegeben werden soll. Das ist ein Dokumentationsbeispiel, keine produktive Maildomain und keine pauschale Relay- oder Routingfreigabe. Die betreffende Policy-Zuordnung und beide Testfälle müssen auch bei diesem Sonderfall stimmen. Die allgemeine Beschreibung des Default-Templates ist kein Beleg für einen MTA-Betrieb ohne SMTP-Policy. None deaktiviert nur den Defaultpfad, nicht eine SPX-Zuweisung in einer Policy.

SPX per XML API automatisieren

Bei wiederkehrenden Änderungen werden zuerst Mailmodus, vorhandene Templates und deren Policy- beziehungsweise Default-Zuweisungen erfasst. Die XML-Referenzen für SFOS 22 und 23 unterscheiden Legacy- und MTA-Objekte; gleiche Feldnamen machen ihre Payloads nicht austauschbar. Die folgenden Angaben erklären den dokumentierten Vertrag, sind aber kein ausführbarer Schreib-Request und kein Nachweis eines Labtests. Quellfreigabe, minimales Servicekonto, TLS-Prüfung, explizite Operation, Backup und Auswertung von XML- statt HTTP-Status stehen unter XML API Zugriff sicher begrenzen und Antworten prüfen. Vor dem Schreiben den vollständigen Objektvertrag in API help des installierten Builds bestätigen; ungeklärte Widersprüche werden nicht durch einen geratenen Payload überbrückt.

Globale Konfiguration: Legacy und MTA trennen

Legacy: Das dokumentierte Beispiel verschachtelt SPXConfiguration zweimal: äusseres SPXConfiguration, darin nochmals SPXConfiguration. Im inneren Element liegt SPXGlobalTemplate mit DefaultSPXTemplate; daneben stehen HostName, AllowedNetworks mit wiederholbaren Network-Einträgen, Port, KeepUnusedPassFor, AllowPassRegistrationFor und SendNotifcationErrorTo. Die doppelte Ebene nicht als vermeintlichen Tippfehler entfernen und das Beispiel nicht als allgemeines MTA-Schema verwenden.

MTA: Das separate Objekt heisst MTASPXConfiguration. Sein Beispiel enthält direkt SPXGlobalTemplate mit DefaultSPXTemplate sowie Hostname, Port, Passwortfristen und Fehlerbenachrichtigung, ohne die doppelte Legacy-Verschachtelung. Für beide Verträge nennt die Parametertabelle Network, DefaultSPXTemplate und HostName als optionale String-Arrays; das ist keine Bestätigung einer beliebig konstruierten Array-Struktur. Portal-FQDN und erlaubte Quellen werden mit den oben beschriebenen Portal- und Zertifikatskontrollen abgeglichen. Der MTA-Beispielwert None bei HostName belegt keinen sicheren Abschaltzustand.

Die Pflichtparameter sind KeepUnusedPassFor (als String dokumentierte Tageszahl, Default 30), AllowPassRegistrationFor (Integer-Tageszahl, Default 10), Port (Integer, Default 8094, Bereich 1025 bis 65535) und SendNotifcationErrorTo. Die Schreibweise SendNotifcationErrorTo bleibt trotz fehlendem Buchstaben unverändert. Die erlaubten Tokens sind SenderOnly und Nobody; das Legacy-Beispiel und die Defaultanzeige nennen dagegen Sender Only. Diese Abweichung nicht still normalisieren und keinen der beiden Werte allein aus der Anzeige als getesteten XML-Wert ableiten. Bei ungeklärtem Vertrag für den eingesetzten Build den Schreibjob stoppen.

Nur die MTA-Tabelle führt zusätzlich AllowSecureReplyfor als Pflichtfeld für die Reply-Frist auf (String-Tageszahl, Default 30). Genau dieses Feld fehlt im MTA-Beispiel. Das Beispiel ist deshalb kein vollständiger Beleg für einen produktionsreifen Request; die Reply-Frist nicht ungeprüft weglassen oder eine Schreibweise mit anderem Gross-/Kleinbuchstaben erfinden. Globales Template, Passwort-Inaktivität, Registrierung und Reply-Frist bleiben getrennte Entscheidungen; keine davon ersetzt die SMTP-Policy-Zuweisung.

Für Update SPX Configuration im Legacy-Vertrag sind folgende XML-Statuszuordnungen dokumentiert:

Der MTA-Vertrag derselben Operation nennt hingegen 200 mit Operation Successful. und 500 mit Operation Fail.. Den Legacy-Code 541 nicht als dort dokumentierte MTA-Antwort ausgeben. Bei der Legacy-Zuordnung 541 zuerst die tatsächliche Portbelegung und den gespeicherten Portalport prüfen, statt den Job unverändert zu wiederholen oder SMTP-TLS zu verändern.

Templates: Identität, Werte und Benachrichtigung schützen

Für Legacy ist SPXTemplates, für MTA MTASPXTemplates dokumentiert. Name ist die erforderliche eindeutige Template-Identität mit maximal 255 Zeichen und wird vor Update oder Löschung exakt mit dem bestehenden Objekt abgeglichen. Description und OrganizationName sind optionale Strings; für OrganizationName gilt ebenfalls maximal 255. Ein neuer Beschreibungstext ist kein Grund, ein gleichnamiges Objekt blind neu anzulegen.

Beide Verträge verlangen PDFEncryption, PageSize und PasswordType. Die exakten Auswahlwerte sind:

• PDFEncryption: AES/128 oder AES/256.
• PageSize: A/4, Letter oder Legal. Die Defaultanzeige A4 ist nicht das dokumentierte Auswahl-Token A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient oder SpecifiedByRecipient. Die Defaultanzeige Specified by sender ist keine XML-Token-Empfehlung.

NotificationSubject, NotificationBody und InstructionsForRecipient sind optionale Strings. Die beiden Notification-Felder sind laut Vertrag nur für die erzeugten beziehungsweise vom Empfänger registrierten Passwortmodelle anwendbar, nicht für SpecifiedBySender. Nur die MTA-Vorlage ergänzt SPXReplyPortal und IncludeOriginalBodyIntoReply: jeweils optional, Default Disabled, erlaubte Werte Disabled oder Enable. Das Beispiel Enable/Disabled ist eine Auswahlnotation, kein einzelner zu sendender Wert. Die Pflicht zum Reply Portal im oben beschriebenen MTA-GUI-Ablauf nicht mit dem optionalen API-Feld und dessen Default verwechseln.

Benachrichtigungstexte werden lokalisiert, technische Platzhalter hingegen unverändert erhalten. Die API-Beispiele zeigen zusätzlich %CURRENT_RECIPIENT% sowie im Betreff %%ENVELOPE_TO%% beziehungsweise %%ORGANIZATION_NAME%%; diese nicht automatisch in die oben aufgeführten einfach eingerahmten Variablen umschreiben. Vor einer Änderung die tatsächlich gespeicherte Vorlage sichern und die Variablenauflösung mit einer neuen Testnachricht prüfen. Stock-HTML, historische PDF-Reader-Hinweise und Beispielpasswörter aus der Referenz sind keine erforderliche Vorlage für eigene Benachrichtigungen. HTML, Anführungszeichen und Zeilenumbrüche müssen kontrolliert serialisiert und nach dem Speichern geprüft werden. Auch das im MTA-Beispiel sichtbare |n nicht ohne build-spezifische Bestätigung als universelles Escape-Verfahren übernehmen.

Für Legacy- und MTA-Templates stimmen die dokumentierten Zuordnungen überein:

Die Message.*-Bezeichner bleiben unaufgelöste Meldungsschlüssel der Referenz, keine belegten Laufzeittexte. Bei 502 die exakte Identität und den vorhandenen Inhalt prüfen, nicht automatisch von Add auf Update wechseln. Bei Update-541 die tatsächlichen Spam-/Data-Control- und SPX-Zuweisungen untersuchen, ohne aus dem Symbol einen universellen Konfliktmechanismus abzuleiten. Bei Delete-504 zuerst die Referenzen in Policies und globaler Konfiguration klären; die unten beschriebene Rollback-Reihenfolge bleibt verbindlich. Vor jedem Retry Antwort und tatsächlich gespeicherten Zustand abgleichen, auch nach 200 das Zielobjekt kontrollieren. Erst eine neue positive und negative Testmail samt Passwort- und Reply-Test nimmt die Betriebswirkung ab.

Verschlüsselten Mailflow abnehmen

Für die Abnahme werden Testzeit, Absender, Empfänger, Betreff und erwarteter Trigger notiert. Dann folgen mindestens diese Fälle:

1. Positivtest: Eine ausgehende Nachricht löst genau das vorgesehene SPX-Template aus.
2. Passworttest: Der Empfänger erhält Passwort oder Registrierungslink über den geplanten Weg und kann die PDF öffnen.
3. Inhaltstest: Betreff, Body und Anhänge sind in der PDF erwartungsgemäss vorhanden und lesbar.
4. Reply-Test: Wenn aktiviert, führt der Reply-Link zum erwarteten FQDN und eine Testantwort erreicht den ursprünglichen Absender.
5. Negativtest: Eine ähnliche Nachricht ohne Trigger wird nicht als SPX-PDF versendet.
6. Ablauftest: Registrierung, gespeichertes Passwort und Reply-Zeitraum verhalten sich nach der festgelegten Gültigkeit nachvollziehbar.
7. Zertifikatstest: Browser und externer Empfänger erhalten am Portal eine vollständige vertrauenswürdige Zertifikatskette für den verwendeten FQDN.

Die Prüfung beginnt unter Email > Mail logs. Unter Reason steht SPX encryption für SPX-verschlüsselte Nachrichten und SPX failure für nicht zugestellte SPX-Nachrichten; unter Result wird zusätzlich beispielsweise nach Delivered, Dropped oder Quarantined gefiltert. Absender, Empfänger, Betreff und Zeitfenster werden mit der Testnotiz abgeglichen. Für Detailfehler folgen der Log Viewer und die MTA-Dateien smtpd_main.log, smtpd_error.log und smtpd_panic.log. Zugriff und weitere Logdateien beschreibt Sophos Firewall Services und Logs.

SPX failure ist kein anderer Name für die SMTP-Quarantäne. Eine Nachricht erscheint unter Email > SMTP quarantine nur, wenn eine Spam-, Malware-, Unscannable-, DKIM- oder andere Policy-Aktion sie tatsächlich quarantänisiert hat. Beim Test wird eine quarantänisierte Nachricht daher nicht einfach freigegeben, bevor Grund und auslösende Policy dokumentiert sind; sonst würde man einen Scan- oder Policyfehler mit einem SPX-Fehler verwechseln.

In HA liegen Logs auf dem Node, der den Traffic verarbeitet hat. Nach einem kontrollierten Failover werden eine neue SPX-Mail, Passwortregistrierung und Reply separat geprüft. Eine bestehende Portal-Sitzung oder ein laufender Registrierungsprozess wird nicht als unterbrechungsfrei vorausgesetzt. Die HA-Grundlagen stehen unter Sophos Firewall HA-Cluster.

Fehler systematisch eingrenzen

Nachricht wird nicht verschlüsselt

Richtung, geschützte Domain, tatsächliche SMTP-route-and-scan-Policy und Triggerpriorität prüfen. Bei Data Control zusätzlich Data protection, die ausgewählte Data control list, Data control list action: Accept with SPX und das zugehörige SPX template kontrollieren. Beim Sender-Trigger muss ein Default-Template gesetzt sein und darf nicht durch ein Domain- oder Data-Control-Template übersteuert werden. Die zwei dokumentierten Header-Schreibweisen sind kein Grund, beide ungeprüft produktiv zu verteilen.

Mail logs zeigen SPX failure

In Email > Mail logs die betroffene Zeile über Zeit, Absender, Empfänger und Betreff eingrenzen und Reason: SPX failure bestätigen. Danach den dort sichtbaren Fehler mit smtpd_main.log, smtpd_error.log und bei schweren Prozessfehlern smtpd_panic.log zum gleichen Zeitpunkt korrelieren. Erst dann Passwortmodell, Template, Zustellung oder Portalpfad ändern. Steht als Result stattdessen Quarantined, wird die auslösende Scan- oder Policy-Aktion in Email > SMTP quarantine untersucht.

Registrierungslink oder Portal ist nicht erreichbar

FQDN, öffentliche DNS-Auflösung, Port, Zertifikat, Allowed networks und Gültigkeit des Links prüfen. Ein leerer Allowed-Networks-Wert wird als Any behandelt und ist daher kein sicherer Abschaltzustand. Erreicht der Client einen anderen Host oder ein anderes Portal, stimmen URL, NAT oder Zertifikatszuweisung nicht mit dem geplanten Pfad überein.

PDF lässt sich nicht öffnen

Passworttyp und konkrete Nachricht zuerst abgleichen. Bei Einmalpasswörtern gilt nur das Passwort dieser E-Mail. Bei gespeicherten beziehungsweise registrierten Passwörtern können Ablauf oder mehrere Passwortmodelle die Ursache sein. Nach einem SPX Password Reset muss der Absender das neue Passwort wieder sicher an den Empfänger übermitteln.

Für einen gezielten Reset unter Email > Encryption > SPX password reset die E-Mail-Adresse des betroffenen Empfängers eintragen und vor dem Auslösen kontrollieren. Der Reset und die sichere Übermittlung des neuen Passworts werden mit Absender und Empfänger koordiniert; danach wird eine neue SPX-Testnachricht geöffnet. Daraus folgt keine Zusage, dass ältere PDFs mit dem neuen Passwort geöffnet werden können.

Sichere Antwort kommt nicht an

Im Template Enable SPX reply portal, Reply-Zeitraum, Portal-FQDN, Port, Zertifikat und erlaubte Quellen kontrollieren. Danach Mail logs und MTA-Logs für die konkrete Antwort prüfen. Das erfolgreiche Öffnen der PDF beweist nicht, dass der Rückkanal funktioniert.

DKIM-Prüfung schlägt nach SPX fehl

SPX verändert Body und Anhänge. Wird eine Nachricht vor dieser Änderung signiert, kann die Signatur beim Empfänger ungültig werden. Festlegen, ob interner Mailserver, Sophos Firewall oder ein späterer Gateway nach allen geplanten Änderungen signiert. Die Verarbeitungskette und ein externer Test gehören zusammen.

Sicher zurückrollen

1. Zuerst die konkrete SPX-Zuweisung aus Domains and routing target entfernen. Bei einem Data-Control-Trigger wird Data control list action in der SMTP-Policy vom Wert Accept with SPX auf die dokumentierte vorherige Aktion zurückgesetzt.
2. Falls verwendet, Default SPX template auf None setzen.
3. Einen ausgehenden Negativtest durchführen und prüfen, dass keine neue SPX-PDF erzeugt wird.
4. Reply- und Registration-Portal nur dann zurücknehmen, wenn keine andere aktive SPX-Policy darauf angewiesen ist.
5. Temporäre öffentliche Port-, DNS- oder Portal-Freigaben auf den dokumentierten Vorzustand setzen. Separat geänderte SMTP-TLS-Vorgaben nur anhand ihres eigenen Vorzustands zurückrollen.
6. Template erst löschen, wenn keine Policy und kein laufender Betriebsablauf mehr darauf verweist.
7. Mail logs und MTA-Logs für den letzten verschlüsselten und den ersten unverschlüsselten Test sichern.

Vor Änderungen an produktiven Mail- und Portalpfaden wird ein aktuelles Sophos Firewall Backup erstellt. In Airgap-Umgebungen kann SPX zwar weiter funktionieren, externe DNS-, Zertifikats- und Portalabhängigkeiten müssen aber separat erreichbar sein. Die Produktgrenzen stehen unter SFOS-Funktionen ohne Internetzugriff.

Betriebscheckliste

• Lizenz, Modell, MTA-Mailflow und externer Empfänger sind geprüft.
• Trigger und Triggerpriorität sind dokumentiert.
• Passworttyp und sicherer Übermittlungskanal passen zum Anwendungsfall.
• Portal-FQDN, zentrales Portalzertifikat, Port und Allowed Networks sind eng geplant; SMTP-TLS ist separat dokumentiert.
• Domain-, Data-Control- oder Default-Zuweisung ist eindeutig.
• Positiv-, Negativ-, Passwort-, PDF- und Reply-Test sind bestanden.
• Die Mail-log-Filter SPX encryption und SPX failure sowie die MTA-Logs lassen sich zur Testmail korrelieren; Quarantäneaktionen sind davon getrennt.
• HA-Failover und Node-lokale Logs sind im Betriebsablauf berücksichtigt.
• Owner, Ablaufzeiten, Review-Datum und Rollback sind dokumentiert.

FAQ