Sophos Firewall Mail Protection im MTA Mode einrichten

Im MTA Mode nimmt Sophos Firewall E-Mails selbst an, prüft sie und stellt sie an den internen Mailserver oder den nächsten Mailhop zu. Der Mailflow funktioniert nur, wenn MX-Record, automatische MTA-Regel, SMTP route and scan Policy, Relay, TLS und Empfängerprüfung zusammenpassen.

Die eigentliche Einrichtung besteht aus sechs Schritten: Mailflow und Rückfallweg festlegen, MTA Mode aktivieren, Maildomain anlegen, Route-and-scan-Policy erstellen, Relay absichern und den MX umstellen. Danach werden eingehender und ausgehender Mailflow mit externen Befehlen, Quarantäne, Spool und Logs geprüft.

Wann MTA Mode passt

Mail Protection auf der Firewall ist vor allem für bewusst geplante On-Premises- und Hybrid-Szenarien sinnvoll, in denen ein lokaler Exchange oder anderer Mailserver geschützt werden soll. Für Microsoft 365, Google Workspace und viele reine Cloud-Mail-Umgebungen ist Sophos Email oder ein anderes Cloud-Mail-Gateway meist die klarere Architektur. Zwei Mail-Gateways hintereinander erschweren Quarantäne, Header, TLS, SPF/DKIM/DMARC und Fehlersuche.

Soll Exchange Online bewusst über den Firewall-MTA geführt werden, erklärt Sophos Firewall MTA mit Microsoft 365 einrichten den vollständigen EOP-, Relay-, Connector-, MX- und SPF-Pfad.

Bei Sophos Firewall sind drei Funktionen zu unterscheiden:

• MTA Mode: Die Firewall nimmt E-Mails an, prüft sie und routet sie weiter.
• Legacy Mode: Transparente Proxy-Verarbeitung eines bestehenden SMTP-Pfads. NAT, Regeln, Scan-Policies und Abnahme erklärt Mail Protection im Legacy Mode einrichten.
• SMTP Relay in Device Access: Steuert, aus welchen Zonen der MTA erreichbar ist. Für eingehende Internet-Mail muss WAN erlaubt sein; ausgehendes Relay wird zusätzlich auf konkrete interne Mailserver begrenzt.

Der Abruf bestehender Postfachnachrichten über POP3 oder IMAP ist davon getrennt. Dafür führt POP3 und IMAP auf Sophos Firewall scannen und testen durch TLS-Vertrauen, optionale Scan-Policy, Firewall-Regel und Abnahme.

Vorausgesetzt werden eine gültige Email-Protection-Lizenz, funktionierendes Routing und DNS, eine bekannte öffentliche IP, der interne Mailserver mit Zielport sowie eine geplante TLS-, Quarantäne- und Rückfallstrategie. MTA Mode ist laut aktueller Sophos-Übersicht auf XGS 87/87w und XGS 88/88w nicht verfügbar.

Anti-Spam, RDNS, SPF, RBL, IP Reputation und SXL2 Live Protection benötigen Internetzugriff. E-Mail-Routing, Malware-Scan, MIME-Filter und SPX können mit passender Lizenz in einer Airgap-Umgebung weiter funktionieren; ein aktiver MTA bedeutet dort aber nicht, dass alle Schutzprüfungen verfügbar sind.

MTA Mode end-to-end einrichten

1. Mailflow und Rückfallweg festlegen

Beim eingehenden Mailflow zeigt der öffentliche MX-Record auf die Adresse, über die Sophos Firewall TCP 25 annimmt. Die Firewall prüft die Nachricht und stellt sie an den internen Mailserver zu. Eine alte DNAT-Regel darf den Mailserver nicht weiterhin ungefiltert aus dem Internet erreichbar machen, sonst lässt sich der MTA umgehen. Die allgemeine DNAT-Logik erklärt Server per DNAT veröffentlichen.

Beim ausgehenden Mailflow sendet nur der vorgesehene Mailserver über die Firewall. Vorher müssen Versandweg, Smarthost, PTR/rDNS, HELO, SPF, DKIM und DMARC zum verwendeten öffentlichen Absender passen. Eine allgemeine LAN to WAN-Regel ist dafür zu breit; die Regelbasis sollte den erlaubten SMTP-Absender klar erkennen lassen. Grundlagen zur Reihenfolge stehen in Sophos Firewall Regeln verstehen.

Vor der Umstellung werden dokumentiert:

• aktueller MX-Record, Priorität und TTL;
• neue öffentliche Firewall-Adresse und interner Zielserver;
• bestehende DNAT-, SMTP- und Mailserver-Connectoren;
• eingehender und ausgehender Testabsender;
• alter MX beziehungsweise alter Mailpfad als Rückfall;
• Monitoring für Mailserver-Queue, Firewall-Spool und Quarantäne.

Die TTL sollte frühzeitig reduziert werden, wenn ein schneller Rückfall nötig sein könnte. Änderungen am produktiven MX gehören in ein Wartungsfenster.

2. MTA Mode und SMTP-Basis konfigurieren

Unter Email > General settings wird bei Bedarf mit Switch to MTA mode umgestellt. Sophos Firewall erstellt dabei die Any-to-Any-Regel Auto added firewall policy for MTA für SMTP und SMTPS. Diese Regel darf nicht editiert werden und sollte ganz oben in der Firewall-Regelliste bleiben. Beim Wechsel zu Legacy Mode wird sie gelöscht und beim Rückwechsel neu erstellt.

Danach werden die Basiseinstellungen gesetzt:

1. Unter SMTP hostname den Domainnamen eintragen, zum Beispiel example.com – nicht den Hostnamen des internen Mailservers. Der Wert erscheint bei systemgenerierten Benachrichtigungen in HELO und SMTP-Banner.

   XML-API-Antwort prüfen: Die SFOS-23-Dokumentation führt für die XML-API-Operation Email Configuration den Status 506 mit Message.AVGeneralConfInvalidSmtpNtfyHostname auf. Das ist ein Operationsstatus, kein HTTP-Statuscode. Der Schlüssel ist nicht aufgelöst und keine englische Fehlermeldung; daraus lassen sich keine konkreten Validierungsregeln ableiten. Bei dieser Antwort prüft man den übermittelten Hostnamen für Benachrichtigungen, die tatsächliche Operationsantwort und die gespeicherte Konfiguration, bevor man von einer erfolgreichen Änderung ausgeht. Die zusätzliche Dokumentationszeile belegt nicht, dass das Laufzeitverhalten erst mit SFOS 23 eingeführt wurde.

2. Reject based on IP reputation aktivieren, wenn Verbindungen mit schlechter Absender-Reputation abgewiesen werden sollen.

3. Unter SMTP TLS configuration ein öffentlich vertrauenswürdiges Zertifikat wählen und Allow invalid certificate nur für begründete Ausnahmefälle zulassen.

4. Disable legacy TLS protocols aktivieren, sofern keine dokumentierten Altsysteme dagegen sprechen. Die Option deaktiviert Protokolle vor TLS 1.1; sie erzwingt nicht automatisch ausschliesslich aktuelle TLS-Versionen.

5. Scan outgoing mails aktivieren, wenn ausgehende Nachrichten ebenfalls geprüft werden sollen.

Bei Require TLS negotiation ist Vorsicht nötig: Kann SFOS die geforderte TLS-Verbindung nicht aufbauen, werden Nachrichten zum betroffenen Ziel beziehungsweise von der konfigurierten Senderdomain verworfen. Die SFOS-22/23-Hilfe warnt, dass SMTP-TLS-Verbindung und -Validierung die IP-Adresse der Domain statt ihres Namens verwenden; mehrere Domains auf einer IP können deshalb Zertifikatsfehler verursachen. Das ist ein Dokumentationshinweis, kein Nachweis des Zertifikatsabgleichs auf dem eingesetzten Build.

Skip TLS negotiation wählt entfernte Mailhosts oder Netze für unverschlüsselte SMTP-Verbindungen aus; dokumentiert sind maximal 512 Hosteinträge. Die Option ist keine Lösung für ein fehlerhaftes Zertifikat. Allow invalid certificate ist eine Ausnahme bei der TLS-Gegenstellenvalidierung, kein Wechsel zu Klartext. Bei überlappenden Require- und Skip-Listen keine Vorrangregel und bei fehlgeschlagenem erforderlichem TLS keinen Klartext-Fallback annehmen. Ausnahmen eng begrenzen und dokumentieren; das tatsächliche Verbindungs- und Zertifikatsergebnis vor Änderungen auf dem eingesetzten Build prüfen.

Globale SMTP-Grenzen vor den Policies festlegen

Die Einstellungen unter Email > General settings gelten für alle E-Mails und werden vor den SMTP- und POP-IMAP-Policies verarbeitet. Reject based on IP reputation ist deshalb keine einzelne Policy-Aktion: SFOS prüft die Absender-IP bereits vor den Spamprüfungen der SMTP-Policy. Auch Blocked senders ist global, blockiert aber nur eingehende E-Mails.

Unter SMTP settings legt Don’t scan emails greater than die maximale Nachrichtengrösse für den globalen SMTP-Scan fest. Der Wert 0 bedeutet 51,200 KB, nicht unbegrenzt. Für grössere Nachrichten stehen Accept, Reject und Drop zur Verfügung. Accept stellt ohne Scan zu, Reject lehnt ab und informiert den Absender, Drop verwirft ohne Benachrichtigung. Diese Auswahl wird als bewusste Scan-Lücke beziehungsweise Zustellentscheidung dokumentiert und mit einer Nachricht knapp ober- und unterhalb der Grenze geprüft.

Die SMTP DoS settings begrenzen gleichzeitige Verbindungen, E-Mails pro Verbindung, Empfänger pro E-Mail sowie E-Mail- und Verbindungsrate. SFOS setzt die maximalen Verbindungen abhängig von RAM und Prozessor. Für Nachrichten und Empfänger gelten als dokumentierte Standardwerte 1000 E-Mails pro Verbindung und 100 Empfänger pro Nachricht. Eigene Werte werden aus dem realen Mailvolumen abgeleitet; ein zu kleiner Grenzwert kann legitime Verteiler oder Scanner wie einen Angriff behandeln.

Unter Advanced SMTP settings kann SFOS ungültiges HELO beziehungsweise fehlendes RDNS und mit Do strict RDNS checks einen Hostnamen ablehnen, der nicht zurück auf die Quell-IP auflöst. Diese Prüfungen werden nicht gleichzeitig mit einer breiten Ausnahme eingeführt. Zuerst werden die tatsächlich verwendeten Partner, Newsletter- und Applikationspfade im Log erfasst und danach einzeln getestet.

Ein ausgehender Banner kann als Inline, no conversion, als eigener MIME part oder mit Off betrieben werden. Dafür muss SMTP- beziehungsweise SMTPS-Scanning in der getroffenen Firewall-Regel aktiv sein. Weil ein Banner den Body verändert und eine vorhandene DKIM-Signatur brechen kann, wird entweder nach dieser Änderung signiert oder am Empfänger ausdrücklich geprüft, ob die geplante Signatur weiterhin gültig ist.

Vor einem Upgrade auch die SMTP-Ratenlimits festhalten. Dokumentiert sind 1–1000 E-Mails pro Verbindung, 1–512 Empfänger pro E-Mail, 1–1000 E-Mails pro Host und Minute sowie 1–100 Verbindungen pro Host und Sekunde. Die Standardwerte der beiden Raten sind 1000 und 100. Bei der Migration übernimmt SFOS unterstützte E-Mail- und Verbindungsraten, setzt Werte oberhalb des Maximums aber auf den Standard zurück. Nach dem Upgrade die gespeicherten Werte vergleichen, nicht nur den alten Konfigurationsexport.

3. Maildomain als Address Group anlegen

1. Email > Address group > Add öffnen.
2. Group type auf Email address/domain und Type auf Manual setzen.
3. Die geschützte Domain, zum Beispiel example.com, hinzufügen.
4. Speichern.

Beim Anlegen vor dem Speichern auch einen eindeutigen Name eintragen. Bestehende Gruppen unter Email > Address group mit Edit bearbeiten; einen Dateiimport mit Import starten. RBL (IPv4) nimmt IPv4-Adressen auf, RBL (IPv6) IPv6-Adressen. Email address/domain unterstützt manuelle Einträge oder CSV-/Textimport. Der RBL-Abgleich verwendet die verbindende IP-Adresse und die Aktion der SMTP-Policy; das separat dokumentierte SPF-/RBL-Reject-Verhalten gilt weiterhin. Die Standardnamen Premium RBL services und Standard RBL services unverändert lassen, sofern keine ausdrücklich geplante Änderung etwas anderes erfordert.

Address Groups sind nicht auf Maildomains beschränkt. Als Group type stehen Email address/domain, IPv4-RBL und IPv6-RBL zur Verfügung. Dieselbe Adresse darf in mehreren Gruppen vorkommen; dadurch lassen sich getrennte Policy-Ziele bilden, ohne den Eintrag zu kopieren oder umzubenennen.

Für grössere Listen kann SFOS eine CSV- oder Textdatei mit bis zu 400 Adressen beziehungsweise Domains importieren. Ungültige und doppelte Einträge werden übersprungen. Nach dem Import werden deshalb Anzahl und einige Stichproben kontrolliert, bevor die Gruppe einer produktiven Policy zugewiesen wird.

Neue SMTP-route-and-scan-Policies werden mit Domains geplant, nicht mit einzelnen Empfängeradressen. Migrierte Einzeladressen können weiter wirken, lassen sich in aktuellen Policies jedoch nicht neu anlegen oder bearbeiten.

4. SMTP route and scan Policy erstellen

Unter Email > Policies and exceptions > Add policy > SMTP route and scan wird die eigentliche MTA-Policy erstellt:

1. Einen klaren Namen setzen, zum Beispiel Inbound example.com to Exchange.
2. Unter Protected domain die Address Group auswählen.
3. Route by festlegen:
   • Static host: feste interne Mailserver-IP; bei Ausfall wird der nächste Host der Liste versucht.
   • DNS host: DNS-Name wie mailserver.example.com; mehrere A-Records werden verteilt genutzt und bei Ausfall übersprungen.
   • MX: Zustellung anhand eines MX-Records.
4. Bei Static host den Mailserver unter Host list auswählen. Das IP-Host-Objekt wird bei Bedarf unter Hosts and services > IP host angelegt.
5. Global action für die bewusst geschützten Domains auf Accept setzen. Reject würde alle ein- und ausgehenden Nachrichten ablehnen, die sich auf diese Domains beziehen, und den Absender informieren.
6. Spam protection und Malware protection passend zum Betriebskonzept aktivieren.
7. File protection und Data protection nur aktivieren, wenn Auswirkungen auf Anhänge, grosse Nachrichten, SPX und DKIM bekannt sind.
8. Speichern.

Für eine bestehende SMTP route and scan-Policy unter Email > Policies and exceptions bei der betreffenden Policy Edit wählen, die benötigten Einstellungen ändern und die Policy anschliessend speichern. Danach Policy-Match und Zustellung mit einer kontrollierten Nachricht erneut prüfen.

Bei Route by MX darf der von der Firewall aufgelöste MX nicht wieder auf dieselbe Firewall zeigen, sonst entsteht eine Routing-Schleife. Für interne Namen muss die Firewall den Zielserver korrekt auflösen können; bei Split-DNS hilft eine DNS Request Route.

Die Option Route inbound mail through gateway ist nur für besondere Designs nötig, etwa Zielserver in der WAN-Zone, die Übernahme der ursprünglichen Firewall-Regel für LAN/DMZ-Ziele oder eine definierte Gatewaywahl bei mehreren Internetleitungen. Sie sollte nicht ohne konkreten Routinggrund aktiviert werden.

5. Eingehenden Zugriff und ausgehendes Relay absichern

Unter Administration > Device access muss SMTP Relay aus den Zonen erlaubt sein, die den MTA erreichen sollen. Für eingehende Internet-Mail ist das WAN; für ausgehende E-Mail zusätzlich die Zone des internen Mailservers, meist LAN oder DMZ. Unter Email > Relay settings > Host-based relay wird danach auf die konkreten Mailserver, Scanner oder Applikationen eingeschränkt.

Breite Host- oder Netzwerkfreigaben erzeugen ein Open-Relay-Risiko. Wenn Drucker oder Applikationen senden müssen, werden sie als konkrete Hostobjekte dokumentiert. Die Device-Access-Grundlagen stehen in Sophos Firewall Zugriff absichern.

Die Allow- und Block-Listen arbeiten nicht nach dem Prinzip, dass Block immer gewinnt. Steht derselbe Host oder dasselbe Netz bei Host-based relay oder Upstream host gleichzeitig in beiden Listen, erlaubt SFOS das Relay. Solche Überschneidungen werden deshalb vor der Aktivierung bereinigt und mit einer nicht erlaubten Testquelle negativ geprüft.

Auch ein erlaubter Host umgeht den Mail-Scan nicht. Kann SFOS eine für Host-based relay freigegebene Quell-IP nicht scannen, wird sie abgewiesen. Eine Relay-Freigabe bestätigt somit weder erfolgreiche Inhaltsprüfung noch Zustellung; beides wird mit einer echten Testmail und den MTA-Logs geprüft.

Die SMTP-route-and-scan-Policy unterstützt kein SMTP AUTH. Für Geräte ist Host-based relay deshalb der verlässliche Weg. Daneben gibt es separate Authenticated relay settings für Benutzer und Gruppen; Sophos weist jedoch darauf hin, dass diese keinen RFC-konformen SMTP-Authentication-Standard unterstützen, weshalb die Clientkompatibilität getestet werden muss. Davon zu unterscheiden ist die Anmeldung der Firewall an einem Upstream-Smarthost: Dafür unterstützt SFOS PLAIN und LOGIN. Als Smarthost darf nie eine Interface-IP derselben Firewall eingetragen werden, weil dadurch eine Routing-Schleife entsteht.

Läuft ausgehende Mail über einen Smarthost, Email > General settings > Smarthost settings konfigurieren: Hostname wählen, Port setzen (Standard 25) und nur bei Bedarf des Servers Authenticate device with smarthost aktivieren sowie dessen Zugangsdaten sicher eingeben. Das leitet ausgehende Nachrichten über einen weiteren MTA; es erlaubt Clients nicht das Relay über die Firewall. TLS-Anforderungen und endgültige öffentliche Absenderidentität auf diesen zusätzlichen Hop abstimmen und die vorherigen Einstellungen für den Rollback festhalten.

Upstream-Relay und Cloud-Mailserver

Upstream host unter Email > Relay settings steuert, welche vorgeschalteten SMTP-Quellen eingehende E-Mails zustellen dürfen; Host-based relay steuert die Hosts mit Berechtigung für ausgehendes Relay. Diese Bereiche getrennt konfigurieren. Empfängt zuerst ein anderes Gateway die öffentlichen E-Mails, gehören dessen tatsächliche Quellnetze in die Upstream-Liste, nicht die Adresse des Zielmailservers. Passende Allow-Einträge haben in beiden Bereichen Vorrang vor überlappenden Block-Einträgen.

Für einen Cloud-Mailserver SMTP Relay in dessen Quellzone aktivieren, meist WAN, und das ausgehende Host-based relay auf die tatsächlichen Quelladressen des Servers begrenzen. Auch der Cloud-Server muss die vorgesehene Relay-Verbindung mit der Firewall erlauben. Den öffentlichen MX zur Firewall vom Zustellziel trennen, das SFOS auflöst: Die Cloud-Anleitung nennt beide MX-Ziele, ohne die DNS-Trennung zu erklären. Einen separaten DNS-Host, ein statisches Ziel oder bewusst gepflegtes Split-DNS verwenden; Route by MX darf nie zurück zur Firewall zustellen.

Die Cloud-Anleitung empfiehlt bei fehlender automatischer Regel ausserdem einen Wechsel zu Legacy und zurück. Dabei wird die Regel gelöscht und neu erstellt und die laufende Mailverarbeitung geändert. Das ist kein ungeplanter Reparaturschritt: Zuerst Policies, Queues und Rückfallweg festhalten, dann die fehlende Regel mit dem Support untersuchen. Ein freigegebener Moduswechsel gehört ins Wartungsfenster mit erneuten Tests für eingehende und ausgehende E-Mails sowie unerlaubtes Relay.

Die älteren Cloud- und Finanzdatenbeispiele verlangen den Namen des ausgehenden Servers als SMTP hostname, die neuere MTA-Einrichtung dagegen die Domain statt des Mailserver-Hostnamens. Für systemgenerierte Benachrichtigungen der neueren Domain-Anleitung folgen; die Einstellung legt nicht die Identität jeder weitergeleiteten Nachricht fest. Ebenso verwendet eingehende DKIM-Verifikation den öffentlichen DNS-Schlüssel des Absenders. Sie erfordert keinen eigenen ausgehenden Signierschlüssel, nur weil die MTA-Übersicht Signierung neben Verifikation erwähnt.

Mehrere WAN-Interfaces oder Alias-IP-Adressen

Der MTA erzeugt die ausgehende SMTP-Verbindung selbst. Bei mehreren möglichen öffentlichen Absenderadressen reicht deshalb eine normale Client-Regel nicht aus. Sophos unterscheidet drei Fälle: Bei einem WAN-Interface mit mehreren Alias-IP-Adressen wird eine SNAT-Regel mit der gewünschten öffentlichen Translated source benötigt. Bei mehreren WAN-Interfaces ohne Alias wird eine SD-WAN Route für SMTP, SMTP(S) und SMTPS_465 erstellt. Sind mehrere WAN-Interfaces und Alias-Adressen vorhanden, werden SNAT und SD-WAN Route kombiniert.

Die SNAT-Regel behält Ziel und Service unverändert, verwendet als ausgehendes Interface die geplante WAN-Leitung und übersetzt auf MASQ oder die gewünschte Alias-IP. Die SD-WAN Route erhält als Ziel die Internet-Gruppe, die drei SMTP-Services und das vorgesehene primäre sowie optional ein Backup-Gateway. Ein Backup ist nur sinnvoll, wenn TCP 25 dort tatsächlich ausgehend erlaubt ist und auch diese öffentliche Adresse im SPF-Record der Maildomain berücksichtigt wird.

Für diesen offiziellen Mehrfach-WAN-Ablauf verlangt Sophos die Route Precedence static, vpn, sdwan_policyroute und aktiviert SD-WAN für systemgenerierten Traffic. Die Befehle gehören in die Device Console (CLI-Menüoption 4), nicht in die Advanced Shell. Zuerst werden beide Ausgangswerte gelesen, danach geändert und erneut kontrolliert:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

Die Route Precedence gilt global und ist kein isolierter Mail-Schalter. Vor der Änderung werden deshalb alle überlappenden statischen, VPN- und SD-WAN-Pfade sowie die gelesenen Werte dokumentiert. Beim Rollback wird die frühere Reihenfolge mit system route_precedence set ... vollständig wiederhergestellt und system-generate-traffic je nach Ausgangswert mit enable oder disable zurückgesetzt. Danach werden nicht nur SMTP-Zähler, sondern die tatsächlich verwendete Quell-IP, Zustellung, SPF-Ergebnis und ein Ausfall des primären Gateways geprüft. Der allgemeine Sicherheits- und Rollback-Ablauf steht unter SD-WAN Routing für systemgenerierten Traffic prüfen.

Bei der SD-WAN-Route verhindert Route only through specified gateways bewusst den Rückfall auf andere Gateways: Sind die ausgewählten Gateways nicht erreichbar, verwirft die Firewall den Traffic. Entscheiden, ob das einer ungeplanten Absender-IP vorzuziehen ist, und diesen Fehlerpfad testen. IPv4- oder IPv6-Objekte passend zum tatsächlich veröffentlichten Mailpfad wählen; keine IPv4-Internetgruppe in ein IPv6-Design kopieren.

6. MX umstellen

Erst wenn MTA-Regel, Domain, Policy, Relay und interner Zustellweg vorbereitet sind, wird der öffentliche MX auf die Firewall-Adresse umgestellt. Danach sofort eine externe Testmail senden und prüfen, ob sie in Log Viewer beziehungsweise Mail logs erscheint, an den internen Server zugestellt wird und im Postfach ankommt.

Wenn externe Absender die Firewall gar nicht erreichen oder legitime Nachrichten breit abgewiesen werden, wird auf den dokumentierten alten Mailpfad zurückgestellt. Wegen DNS-Caches ist dieser Rückweg nicht sofort überall wirksam. Der alte und der neue Pfad bleiben deshalb parallel betriebsbereit und werden mindestens so lange überwacht, bis die längste zuvor gültige TTL abgelaufen ist. Nimmt die Firewall Nachrichten an, stellt sie aber nicht zu, werden zuerst Routing, DNS, TLS, Empfängerprüfung und Mailserver-Logs geprüft.

Schutzrichtlinien bewusst wählen

Aktionen für Spam, Malware und sensible Daten

Für eingehenden Spam, wahrscheinlichen Spam und Massenmail die Aktion ausdrücklich wählen: None stellt unverändert zu, Warn ergänzt das konfigurierte Betreffpräfix, Quarantine hält die Nachricht zurück und Drop verwirft sie ohne Benachrichtigung des Absenders. Die Betreffpräfixe für Spam und Massenmail passend setzen. Diese Auswahl hebt die separate SPF/RBL-Ablehnung nicht auf.

Für Malware bietet Selected antivirus action die Optionen None, Drop und Quarantine; Notify sender separat konfigurieren. Quarantine unscannable content betrifft nicht prüfbare Inhalte, darunter beschädigte, verschlüsselte oder komprimierte Dateien, übergrosse Nachrichten und interne Scanfehler. Eine erfolgreiche Zustellung beweist nicht, dass alle Anhänge geprüft wurden. Zero-Day Protection hat eine eigene maximale Analysegrösse: Grössere Dateien werden durch diesen Dienst nicht analysiert. Diese Grenze getrennt von globaler SMTP-Grösse und File-Protection-Drop-Limits testen.

Unter Data protection die genaue Data control list, ihre Aktion und gegebenenfalls das SPX template wählen: Accept stellt zu, Accept with SPX verschlüsselt und stellt zu, Drop verwirft ohne Benachrichtigung. Notify sender ist eine separate Auswahl. Eine SPX-Zuweisung auf Domain-Ebene verschlüsselt alle passenden ausgehenden Nachrichten; sollen nur Finanzdaten-Treffer verschlüsselt werden, einen Data-Control-Trigger verwenden. Das Empfängerpasswort-Beispiel nutzt Specified by recipient und hält die Nachricht bis zur Passwortregistrierung zurück. Template, Reply Portal und Registrierungsweg zusammen im verlinkten SPX-Runbook konfigurieren und eine passende sowie eine nicht passende Nachricht testen, statt nur Data protection einzuschalten.

Eigene Dateitypen und Data-Control-Listen einsetzen

Ein eigener Dateityp wird im MTA Mode unter Email > Policies and exceptions > File type > Add aus einer Vorlage oder aus Dateiendungen beziehungsweise MIME-Typen erstellt. Dateiendungen werden ohne führenden Punkt eingetragen. Nur eigene Dateitypen sind editierbar. Ein neu erstellter Typ wird ausserdem nicht automatisch in bestehende Policies übernommen: Die konkrete SMTP-route-and-scan-Policy muss anschliessend geöffnet, unter File protection ergänzt und erneut gespeichert werden. Ein positiver und ein ähnlicher negativer Anhangstest bestätigen den Match besser als der Objektname allein.

Unter File protection > Block file types blockiert All Nachrichten mit Anhängen; es bedeutet nicht, alle Anhänge zu scannen. None erlaubt Anhänge in dieser Dateifilter-Einstellung, umgeht aber weder Malware-, Spam- und Data-Protection-Prüfungen noch andere Kontrollen. Laut Policy-Hilfe füllen ausgewählte MIME-Header die MIME whitelist: Diese Typen werden erlaubt, die übrigen blockiert. MIME-Header und Dateiendungen beweisen keinen harmlosen Inhalt. Erlaubte und blockierte Anhänge auf dem eingesetzten Build prüfen, bevor eine konkrete Whitelist-Konfiguration angewendet wird.

Eine Data Control List besteht aus Content Control Lists, kurz CCLs, für definierte Inhaltstypen wie Finanz- oder Personendaten. Beim Anlegen unter Email > Data control list > Add werden die CCLs nach Type und Region gefiltert und nur die tatsächlich benötigten Einträge ausgewählt. Die Aktion entsteht erst in der verknüpften Policy. Deshalb wird mit einem kontrollierten Treffer und einem ähnlichen Inhalt ohne Treffer geprüft, ob Match und Aktion zusammenpassen und keine unnötigen False Positives entstehen.

Spam-Schutz ist mehr als eine Aktion für Spam. SPF- und RBL-Treffer werden direkt abgewiesen und folgen nicht den normalen Aktionen für Spam oder probable spam. Greylisting führt absichtlich zu einer temporären Ablehnung und setzt voraus, dass sendende Server erneut zustellen.

Für Reject based on BATV muss zuerst unter Email > General settings > Advanced SMTP settings ein gemeinsames BATV secret hinterlegt sein. Bei mehreren eigenen MX-Systemen wird dasselbe Secret verwendet. SFOS bildet daraus zusammen mit Zeitstempel und Absenderadresse die Return-Path-Signatur; sie läuft nach sieben Tagen ab. Ein BATV-Fehler wird deshalb gegen Secret, Systemzeit, Absenderpfad und Alter der Signatur geprüft, nicht mit einer unbefristeten breiten Ausnahme verdeckt.

Recipient verification verhindert Nachrichten an unbekannte Empfänger:

• With callout: Fragt den Zielmailserver ab. Ist dieser vorübergehend nicht erreichbar, akzeptiert SFOS Empfänger nach einer definierten Dauer, statt den gesamten Mailflow dauerhaft zu blockieren.
• In Active Directory: Prüft über Simple, SSL oder STARTTLS; die Abfrage hat ein Timeout von 30 Sekunden. AD-Server, Bind DN und Base DN angeben. Bind DN ist der vollständige Distinguished Name einschliesslich des CN der konfigurierten Bind-Identität; Base DN ist der Startpunkt der Verzeichnissuche. Zum eigenen Verzeichnis passende Werte verwenden. Das Administrator-Beispiel der Hilfe begründet keine erforderlichen Domain-Admin-Rechte. Der Transport muss die eingesetzte Vertrauens- und Sicherheitsrichtlinie erfüllen; die Bezeichnung SSL oder STARTTLS allein beweist keine erfolgreiche Zertifikatsvalidierung.

Bei Malware Protection kann Single- oder Dual-Antivirus gewählt werden. Soll Zero-Day Protection mit Single-Antivirus-Scan verwendet werden, muss Sophos als primäre Engine eingestellt sein. Grenzen und Freigabeentscheidungen erklärt Sophos Firewall Zero-Day Protection.

Laut SFOS-22/23-Policy-Hilfe wählt Single antivirus die primäre Engine nur für eingehende Nachrichten; ausgehende Nachrichten werden mit beiden Engines geprüft. Dual antivirus prüft zuerst mit der primären und danach mit der sekundären Engine. Die primäre Engine, Sophos oder Avira, wird global unter Email > General settings gewählt. Die Wahl von Avira deaktiviert Zero-day protection in SMTP-Policies mit Single-Antivirus-Scan; für Zero-Day Protection mit einem einzelnen Scan muss Sophos primär sein. Die Hilfe zu den allgemeinen Einstellungen beschreibt Single-Scanning pauschal als Prüfung nur durch die primäre Engine, ohne die Richtungsunterscheidung der Policy-Tabelle. Dieser Dokumentationsunterschied beweist keine beobachtete Engine-Nutzung: Build, Policy, Mailrichtung und Schutzstatus vor und nach einer Änderung prüfen. Vorherige Einstellungen festhalten; die Wiederherstellung der Engine-Wahl belegt keine erneute Aktivierung von Zero-day protection.

Die Policy-Grenze Drop message greater than unter File protection ist nicht mit dem globalen Oversize-Verhalten identisch: Grössere Nachrichten werden an dieser Stelle verworfen. Zudem prüft SFOS sichtbare Inhalte und Inhalte aus paketierten Formaten wie docx, xlsx, pptx, odt, ods, odp und odg. Ein positiver Test nur mit einer unverpackten Textdatei beweist deshalb nicht, wie dieselbe Information in einem Office-Dokument behandelt wird.

Bei eingeschalteter DKIM verification unterscheidet SFOS einen Hash-Mismatch, eine ungültige Signatur beziehungsweise einen nicht auffindbaren öffentlichen Schlüssel und eine fehlende DKIM-Signatur. Pro Ergebnis stehen Accept, Quarantine oder Reject zur Verfügung. DKIM-signierte Nachrichten mit RSA-SHA1 oder einer Schlüssellänge ausserhalb von 1024 bis 4096 Bit werden laut Sophos in Quarantäne verschoben. Diese Eingangsprüfung wird getrennt von der ausgehenden Signatur getestet.

Bei ausgehenden Nachrichten ist die Reihenfolge der Verarbeitung wichtig. SPX-Verschlüsselung, Subject-Präfixe, File oder Data Protection und ausgehende Banner können Header oder Body nach einer vorhandenen DKIM-Signatur verändern. Dadurch schlägt die DKIM-Prüfung beim Empfänger fehl. Es muss deshalb festgelegt werden, ob der interne Mailserver, Sophos Firewall oder ein späterer Gateway signiert.

Ausgehende Nachrichten auf der Firewall mit DKIM signieren

Soll Sophos Firewall selbst signieren, wird unter Email > General settings > DKIM signing > Add für jede Absenderdomain eine Signatur angelegt. Der Domain-Wert ist der FQDN der Maildomain; der Key selector bezeichnet genau den Selector, der anschliessend im öffentlichen DNS veröffentlicht wird. Ein Name wie fw01 oder zurich erleichtert spätere Schlüsselwechsel, ist aber kein Sicherheitsmerkmal.

SFOS erwartet einen privaten RSA-Schlüssel mit 1024 bis 2048 Bit zwischen -----BEGIN RSA PRIVATE KEY----- und -----END RSA PRIVATE KEY-----. Für neue Konfigurationen ist 2048 Bit die sinnvolle Wahl. RSA-SHA1 darf nicht verwendet werden; mit PuTTYgen akzeptiert die Firewall laut Sophos keinen 1024-Bit-Schlüssel, weshalb dort ebenfalls 2048 Bit gewählt wird. Der private Schlüssel gehört ausschliesslich in die Firewall und nie in DNS, Tickets oder öffentliche Dokumentation.

Nach dem Speichern wird der zum Selector gehörende DKIM-TXT-Record mit dem öffentlichen Schlüssel beim autoritativen DNS-Provider veröffentlicht. Erst wenn dieser Record extern auflösbar ist, wird eine neue Testmail über den vorgesehenen ausgehenden MTA-Pfad gesendet. Im empfangenen Nachrichtenheader müssen der erwartete Selector und die Domain erscheinen; die DKIM-Prüfung beim Empfänger muss erfolgreich sein. Fehlt die Signatur, werden Absenderdomain, Policy-Match und Scan outgoing mails geprüft. Schlägt die Prüfung fehl, werden zuerst DNS-Record, Selector, verwendeter Schlüssel und nachträgliche Änderungen durch SPX, Banner, File oder Data Protection abgeglichen.

Wie Template, Triggerpriorität, Passwortmodell und Reply Portal zusammenwirken, zeigt SPX E-Mail-Verschlüsselung einrichten und testen.

MTA-Einstellungen sicher per XML API automatisieren

Für Automationen bleiben globale Einstellungen, Address Groups und SMTP-Policies getrennte Ziele. Zuerst Build, aktiven Mailmodus, gespeicherte Werte und abhängige Policies lesen; Backup und gezielten Rückweg vorbereiten. Den bestätigten Request mit expliziter Operation nur für das benötigte Ziel senden. Danach die Operationsantwort, den erneut gelesenen Zustand und den passenden Mailflow-Test vergleichen. Auch nach einem Fehler oder Timeout zuerst nachlesen, ob bereits etwas gespeichert wurde, statt den Schreib-Request blind zu wiederholen. Zugriff, Secret-Ablage und Antwortauswertung erklärt XML API Zugriff absichern.

Die SFOS-22/23-Objektreferenzen sind keine fertigen Produktions-Payloads. XML-Beispiele, Parametertabellen und WebAdmin-Hilfe können verschiedene Schreibweisen, Werte oder Defaults nennen. Leere Defaultzellen beziehungsweise Any bestätigen weder einen sicheren Leerwert noch das Verhalten ausgelassener Felder. Unaufgelöste $EMAILPROTECTION{…}-Konstanten sind keine bestätigten API-Literale. Bei ungeklärter Syntax, Operation oder Wirkung vor dem Schreiben stoppen und die API help des installierten Builds oder eine offizielle Klärung heranziehen. Dokumentationsunterschiede allein belegen keine Produktänderung.

Globale SMTP-, TLS- und Relay-Einstellungen auseinanderhalten

Bei EmailConfiguration gehören SMTP-Scanlimit und DoS-Werte unter SMTPSSettings, die getrennten POP/IMAP-Werte unter POPIMAPSettings. Das gleichnamige DontScanEmailsGreaterThan darf nicht dem falschen Protokoll zugeordnet werden. RecipientHeaders mit wiederholtem Header betrifft POP/IMAP-Empfängererkennung, nicht SMTP-Routing. Banner stehen unter GeneralSettings. Ebenso sind SMTPTLSConfiguration und POPSIMAPTLSConfiguration eigene Kontexte: TLSCertificate, AllowInvalidCertificate und DisableTLS1 lassen sich nicht durch einen einzigen unqualifizierten Feldnamen eindeutig adressieren. Eine SMTP-Ausnahme darf nicht unbemerkt auch POP/IMAP lockern. Nach dem Speichern beide Kontexte separat nachlesen und nur den vorgesehenen Mailpfad testen.

BypassSpamCheck unter SMTPSSettings beschreibt laut API-Tabelle das Umgehen des Spam-Scans für authentifizierten Traffic. Die Tabelle nennt den Default Disable, das XML-Beispiel setzt dagegen Enable. Das Beispiel nicht als sichere Standardkonfiguration übernehmen: Vor einer Änderung klären, welcher Traffic im konkreten Build als authentifiziert gilt und welche Spam-Prüfung umgangen wird. Eine gewollte Ausnahme eng begrenzen und deren Wirkung auf passende sowie nicht passende Nachrichten prüfen; andere Scanbereiche nicht als automatisch ausgenommen betrachten.

Die Herkunft der SMTP-Zahlen ist wichtig: Die API-Tabelle nennt für DontScanEmailsGreaterThan 1024 KB, für MaximumConnections 5000 im Bereich 1–20000 und für MaximumConnectionsHost 100 im Bereich 1–10000. Für MaximumEmailsConnection nennt sie den Default 100, das XML-Beispiel dagegen 1000; die WebAdmin-Hilfe nennt ebenfalls 1000. MaximumRecepientsEmail ist die Schreibweise der Quelle, mit Default 100 und Bereich 1–512. Für EmailsRate und ConnectionsRate nennt die API-Tabelle Defaults 1000 und 100, jeweils mit Bereich 1–20000; die WebAdmin-Hilfe begrenzt die Raten dagegen auf 1–1000 pro Minute beziehungsweise 1–100 pro Sekunde und bestimmt Verbindungsmaxima anhand der Hardware. Deshalb weder Tabellenmaxima als aktuelle UI-Grenzen noch Beispielwerte als Defaults übernehmen. Die oben beschriebenen WebAdmin-Limits und die Upgrade-Kontrolle bleiben massgebend für diesen Ablauf; Automationen müssen die tatsächlich gespeicherten Build-Werte abgleichen.

Weitere Syntaxkonflikte verhindern einen blinden Beispielimport: VerifySendersIPReputation zeigt im XML-Beispiel Enable, die API-Tabelle aber on/off bei Default Disable; SMTPSDosSettings wird dort als Integer mit Default Disable beschrieben, im Beispiel aber als Enable. Beim Banner stehen Beispieltexte den Tabellenwerten inline_plain, mimepart, off gegenüber. Diese Angaben nicht selbst «reparieren», sondern die gültige Schreibweise und Werte vor einem Request bestätigen. Den bestehenden Hinweis zu Email Configuration, Status 506, getrennt beachten.

AdvancedSMTPSetting ist ebenfalls global. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks und ScanOutboundEmails steuern die oben erklärten HELO/RDNS- und Ausgangsprüfungen. FirewallRelateInboundMails betrifft den gesonderten Gateway-/Firewall-Regelpfad; das Beispiel nennt Disable, die Tabelle Turn on/Turn off. Für das BATV-Secret zeigt das Beispiel BATVSecret, die Tabelle hingegen BATVsecret. Gross-/Kleinschreibung und gültige Werte vor dem Schreiben bestätigen, keine dieser Varianten als getesteten Payload ausgeben. Das gemeinsame Secret aus geschützter Ablage verwenden, weder Beispielsecret noch Secret in Ticket, Repository oder Request-Log kopieren. Secretwechsel über alle betroffenen MX-Systeme planen und BATV sowie normalen Versand danach prüfen.

In RelaySettings existieren HostBased und UpstreamHost jeweils mit eigenen AllowRelay- und BlockRelay-Listen. Darunter stehen HostsOrNetworks und wiederholte HostsOrNetwork-Einträge. Der gleiche Blattname bedeutet daher nicht den gleichen Relay-Scope. AuthenticatedRelaySettings enthält separat AuthenticatedRelay sowie UsersOrGroups mit UsersOrGroup. Die im Herstellerbeispiel gezeigten offenen beziehungsweise Gastgruppen sind keine sichere Auswahl. Nur die geplanten Identitäten und Hostobjekte einsetzen, Überlappungen der Listen bereinigen und danach erlaubten Versand sowie unerlaubtes Relay aus einer separaten Quelle prüfen.

Bei SmarthostSettings aktiviert UseSmarthost den ausgehenden Zwischenhop; SmarthostList mit wiederholtem Hostname wählt die Ziele, Port den Zielport. Die API-Tabelle nennt 1–65535, aber keinen Port-Default; 25 steht im Beispiel und als Default in der WebAdmin-Hilfe. AuthenticateDevicewithSmarthost ist getrennt: Nur bei benötigter Anmeldung Username und Password sicher bereitstellen. Die API-Tabelle nennt beide Aktivierungsschalter standardmässig Disable, während das Beispiel beide aktiviert. passwordform="encrypt" ist die Passwortsyntax des Beispiels, keine Erlaubnis, verschlüsselte Werte einer anderen Firewall wiederzuverwenden. Ungeklärte Herkunft oder Importanforderungen stoppen den Request. Anschliessend Ziel, TLS, Authentifizierung und Zustellung über diesen Hop prüfen, nicht nur die Relay-Freigabe.

Address Groups und SMTP-Policies gezielt ändern

Für den MTA ist das Beispielobjekt MTAAddressGroup vorgesehen, nicht das ähnlich benannte AVASAddressGroup des anderen Mailkontexts. Name identifiziert die Gruppe. GroupType bestimmt die passende Liste: Die API-Tabelle unterscheidet RBLIPv4, RBLIPv6, IPAddress und EmailAddressOrDomain sowie die Eintragsfelder RBLName, IPAddressNetwork und EmailAddressDomain. Das Maildomain-Beispiel verwendet EmailAddressList mit wiederholtem EmailAddressDomain und EmailImportType auf Manual. Für Import und EmailAddressFile den zum Build passenden Dateiupload klären: Der Beschreibungstext ordnet das Dateifeld widersprüchlich dem manuellen Import zu. Ein HTTP-Erfolg bestätigt weder alle importierten Einträge noch die endgültige Gruppenzusammensetzung. Anzahl, ausgelassene Einträge und konkrete Domainwerte nachlesen, bevor eine Policy die Gruppe verwendet.

Bei Delete Address Group liefern die SFOS-22/23-Seiten Statuszeilen, aber keine Parameterdefinition und kein Löschbeispiel. Daraus lässt sich weder die genaue Remove-Objektidentität noch ein funktionierender Request ableiten. Nicht einfach Name oder das Anlegeobjekt in einen Remove-Payload einsetzen. Zuerst Verwendungen in Mail-, Spam- und Archivierungskonfigurationen prüfen; die genaue Operation und ihren vollständigen Request aus der installierten API help beziehungsweise offizieller Klärung beziehen. Bis dahin keine automatische Löschung ausführen. Nach einer freigegebenen Löschung erneut prüfen, dass genau die beabsichtigte Gruppe entfernt wurde und benötigte Referenzen sowie Mailflow intakt sind.

Bei SMTPPolicy ist Name die Policy-Identität; DomainList mit DomainName bindet die geschützten Domains. RouteBy, DNSHostName und RouteList mit HostName, routingid und routingorder beschreiben unterschiedliche Zustellwege, nicht weitere Domainnamen. Die API-Tabelle nennt MX als Route-Default, das Beispiel enthält jedoch alternative Routentexte statt eines einzigen Wertes. Routing vorab gegen die tatsächliche DNS-Auflösung prüfen, damit keine Schleife zur Firewall entsteht.

Die verschachtelten Bereiche SpamProtection, MalwareProtection, FiletypeFilter und DataProtection haben unabhängige Statusfelder. Die API-Tabelle nennt diese standardmässig OFF, obwohl das Beispiel sie auf ON setzt. Eine globale Aktion Accept aktiviert also nicht automatisch alle Prüfungen. Ebenso sind das Domain-SPX-Feld SPXEncryption und das trefferbezogene DataProtectionSPXTemplate nicht austauschbar; DataProtectionPolicy muss eine vorhandene passende Data Control List referenzieren. Engine-, Zero-Day- und BATV-Voraussetzungen sowie SPX-Passwortmodell vorab prüfen. Die Tabelle beschreibt Empfängerprüfung als ausgehend, die WebAdmin-Hilfe als eingehend; daraus keine neue Prüfrichtung ableiten. Richtungsbezogene Positiv-/Negativtests und gespeicherte Policy-Werte entscheiden, ob das geplante Schutzkonzept umgesetzt ist.

Für die Data Control List zeigt das XML-Beispiel MTADataControlList, darin Name und Signatures mit wiederholtem Signature. Die Tabellenlabels name und signaturename sind keine bestätigte Anweisung, diese kleingeschrieben als XML-Tags zu serialisieren. MTA Mode vorab bestätigen, die verfügbaren Signaturen lesen und nur passende CCLs wählen. Die Liste allein erzeugt keine Schutzaktion: Erst die Bindung über DataProtectionPolicy und die Aktion in der SMTP-Policy setzen das Konzept um. Anschliessend Liste und Bindung nachlesen und einen kontrollierten Treffer sowie einen ähnlichen Nichttreffer prüfen.

DKIM und Ausnahmen nicht mit Routing gleichsetzen

Bei DKIMVerification steuert das im Beispiel tatsächlich so geschriebene VerifactionStatus die Aktivierung. ActionForVerifactionFail ist ein anderer Selector als ActionForSignatureInvalid oder ActionForSignatureNotFound: Der erste betrifft Hash-/Signaturverifikationsfehler, der zweite einen fehlenden beziehungsweise syntaktisch ungültigen öffentlichen DNS-Schlüssel, der dritte eine fehlende Signatur. Die Schreibfehler der ersten beiden Tags nicht still korrigieren. Das XML-Beispiel nennt Pass, die Parametertabelle und WebAdmin-Hilfe dagegen Accept neben Quarantine und Reject. Das bestätigt keine austauschbaren API-Werte; vor einem Request den Build-Vertrag klären und alle drei Eingangsfälle getrennt testen.

Bei DKIMSigning identifiziert Domain die Signierdomain, nicht Name; die Löschreferenz verlangt ebenfalls Domain. Beim Anlegen und Ändern sind KeySelector und PrivateRSAKey Pflichtfelder. Eine Domain kann laut WebAdmin-Hilfe mehrere Signaturen haben, während die Löschreferenz nur die Domain nennt: Bei mehreren Selectors den exakten Löschumfang vorab klären, nicht auf eine selectorbezogene Löschung schliessen. Private Schlüssel und API-Zugangsdaten geschützt speichern und aus Antworten sowie Logs entfernen; danach DNS und die neue empfangene Signatur wie oben prüfen.

Die globale Eingangsliste verwendet MtaBlockedSenders mit BlockedEmailAddresses und wiederholtem EmailAddress; die API-Tabelle erlaubt einzelne Adressen oder Wildcard-Domains wie *@example.com. Diese Liste ersetzt keine vollständige Anti-Spam-Policy und gilt im hier beschriebenen MTA-Kontext nur für eingehende Nachrichten. Vor einer Änderung Umfang und bestehende Einträge lesen, danach einen passenden und einen nicht passenden Absender testen.

Davon getrennt beschreibt die API AntiSpamTrustedDomain mit DomainList und wiederholtem DomainName als Ausnahme zum Umgehen von Mail-Scanning für vertrauenswürdige Domains. Welche Scanner genau umgangen werden, legt diese Quelle nicht fest. Deshalb weder einen GUI-Pfad erfinden noch eine Garantie «alle Scans aus» geben oder Trusted Domains mit geschützten Routingdomains verwechseln. Vor Anlegen oder Entfernen genaue Domainliste, benötigte Ausnahme und Scanwirkung auf dem installierten Build klären; eng begrenzen und mit Review-Datum sowie passenden und nicht passenden Nachrichten prüfen.

Für Delete Trusted Domain nennt die Parametertabelle DomainName als verpflichtendes Array mit mehreren möglichen Werten, liefert aber kein Löschbeispiel. Die Verschachtelung des Add-Beispiels deshalb nicht ungeprüft als Löschrequest übernehmen; Zielwerte und vollständige Request-Struktur vorab in der installierten API help oder durch offizielle Klärung bestätigen.

Der globale Engine-Selector ist MalwareProtection mit PrimaryAntiVirusEngine, in der API-Tabelle standardmässig Sophos. Er ist nicht das gleichnamige verschachtelte Policy-Element und schaltet nicht selbst die Scanbereiche ein. Auswirkungen auf Single-/Dual-Scanning und Zero-Day Protection wie oben vor und nach einer Änderung an den betroffenen Policies kontrollieren.

Objektspezifische Antworten als Diagnosehilfe

Die folgenden Zuordnungen stammen aus den SFOS-22/23-Statuszeilen. Zahlen sind XML-Operationscodes, keine HTTP-Codes; Message.* sind unaufgelöste Quellschlüssel, keine bestätigten Meldungstexte oder eindeutigen Fehlerursachen. Die allgemeine API-Sicherheit oben gilt auch hier: tatsächliche Antwort und gespeicherten Zustand vor jedem Retry abgleichen, Abhängigkeiten nicht auf Verdacht entfernen und bei ungeklärtem Teilzustand stoppen.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. Die letzten drei Zeilen machen den Importabgleich besonders wichtig; keine Annahme, dass die ganze Datei verworfen oder übernommen wurde. Edit Address Group führt in diesen Quellen nur 200 → Message.AddrGrpUpdateSuccess und 500 → Message.AddrGrpUpdateFail auf; die Add-Codes nicht als dokumentierte Edit-Antworten ausgeben.
• Delete Address Group: 504, 505 und 506 verweisen jeweils auf Message.AddrGrpForeignKeyExists; 507 auf Message.AddrGrpEmailArcKeyExists. Die gleiche Symbolzuordnung bestimmt nicht, welche Referenz betroffen ist. Verwendungen und tatsächlichen Gruppenbestand prüfen; diese Antworten ersetzen nicht den fehlenden Löschvertrag.
• Add Data Control List und Update Data Control List: jeweils 502 → Message.DLPAddSameName und 545 → Message.MTAModeDisableCheck. Der Update-Schlüssel enthält ebenfalls «Add»; ihn nicht umbenennen. Namen, Modus und gespeicherte Liste prüfen, ohne aus dem Schlüssel allein eine Ursache festzulegen.
• Add SMTP Policy und Edit SMTP Policy: jeweils 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck und 545 → Message.MTAModeDisableCheck. Nur Add SMTP Policy führt 502 → Message.SMTPProfileduplicateName auf. Bei 543 unterscheidet die Quelle Message.SMTPProfileSenderGenSPXAdd für Add und Message.SMTPProfileSenderGenSPXEdit für Edit. Domainbindungen, Namen, Modus und SPX-Abhängigkeiten gegen den realen Zustand prüfen; keine automatische Umbenennung oder Schutzlockerung auslösen.
• Email Configuration: 505 → Message.ASConfigSubOperationFail steht in beiden Versionen. Vor einem Retry alle betroffenen SMTP-, POP/IMAP- und TLS-Unterbereiche nachlesen, nicht vollständigen Erfolg oder vollständigen Rollback annehmen. Die zusätzliche SFOS-23-Zeile 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname bleibt wie oben qualifiziert.

Mailflow abnehmen

Die folgenden Befehle werden von einem System ausserhalb des eigenen Netzwerks ausgeführt:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

example.com und mail.example.com werden durch die echten Werte ersetzt. Die Befehle prüfen DNS, TCP 25 und STARTTLS, aber weder Relay-Berechtigung noch vollständige Zustellung. openssl s_client bleibt nach dem Handshake interaktiv und wird mit Ctrl+C beendet.

Danach werden mindestens diese Fälle getestet:

• externe Nachricht an einen gültigen Empfänger;
• bei aktivierter Recipient verification eine externe Nachricht an einen ungültigen Empfänger;
• ausgehende Nachricht über den vorgesehenen Mailserver;
• Spam- oder Malware-Test entsprechend der Policy;
• STARTTLS und präsentierte Zertifikatskette;
• Quarantäneaktion und Zustellung nach einer Freigabe;
• blockierter Relay-Versuch aus einer nicht erlaubten Quelle;
• keine direkte Zustellung an einer alten DNAT-Regel vorbei.

Die Abnahme hält nur beobachtete Ergebnisse fest: Die gültige Testmail muss im Mail logs als Delivered erscheinen und anhand ihrer Message-ID bis ins Zielpostfach verfolgt werden. Eine Abweisung des ungültigen Empfängers ist nur dann zu erwarten, wenn die Empfängerprüfung aktiviert ist, die gewählte Prüfmethode über einen erreichbaren massgeblichen Prüfpfad funktioniert und die Abweisung konfiguriert ist. Bei With callout ist dieser Negativtest von der dokumentierten Ausnahme zu unterscheiden: SFOS akzeptiert Empfänger, wenn der Zielmailserver für eine festgelegte Dauer nicht erreichbar ist. Die Dokumentation nennt diese Dauer nicht; dieselbe Ausnahme darf für In Active Directory nicht angenommen werden. Bei ausgeschalteter Prüfung ist eine Abweisung nicht das erwartete Ergebnis dieses Negativtests. Der unerlaubte Relay-Versuch darf keine Nachricht erzeugen, und die Quarantäne-Freigabe muss für dieselbe Message-ID eine anschliessende Zustellung zeigen.

Für die erste Sichtprüfung dienen Email > Mail logs, Email > Mail spool, Email > SMTP quarantine und der Log Viewer. Für tiefere Analyse werden Testzeit, Absender, Empfänger, Betreff, Quell-IP und Message-ID notiert und mit diesen Dateien korreliert:

• MTA: smtpd_main.log
• Rejects: smtpd_reject.log
• Scanfehler: smtpd_error.log
• interne MTA-Fehler: smtpd_panic.log
• Anti-Spam: sasi.log
• Legacy SMTP Proxy: awarrensmtp.log
• POP/IMAP Proxy: warren.log

Die Zuordnung und der Zugriff über Advanced Shell stehen in Sophos Firewall Services und Logs.

In Mail logs bezeichnet Result den Zustellstatus, während Reason den Scan- oder Policygrund beschreibt. Rejected bedeutet, dass SFOS die Nachricht verworfen und den Absender informiert hat. Dropped verwirft ohne Benachrichtigung; Bounced erscheint nach mehreren erfolglosen Zustellversuchen. Diese Zustände werden nicht gleichgesetzt, weil sie unterschiedliche Rückmeldungen und Fehlerpfade erzeugen. Weitere Resultate sind Delivered, Quarantined und manuell Deleted; als Gründe lassen sich unter anderem Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM und BATV filtern.

Quarantäne und Mail-Spool betreiben

Unter Email > SMTP quarantine kann nach Zeitraum, Absender, Empfänger, Betreff und Quarantänegrund gefiltert werden:

• Release: Nachricht freigeben.
• Delete: Nachricht löschen.
• Release and report: Nur False Positives mit Einstufung Spam oder Probable spam freigeben und an SophosLabs melden.

Virus-infizierte oder von Zero-Day Protection als bösartig bewertete Nachrichten können nicht freigegeben werden. Zum Löschen von Zero-Day-Protection-Einträgen braucht das Adminprofil Schreibrechte für diese Funktion. Bei voller Quarantäne werden alte Nachrichten bereinigt.

Quarantäne-Digests erhalten nur Benutzer, die sich mindestens einmal an der Firewall authentifiziert haben. Standardmässig wendet SFOS die Digest-Einstellungen nicht auf Alias-Adressen an; sie müssen zusammen mit der primären Adresse unter Email > Quarantine settings > Change user’s quarantine digest settings oder am Benutzerobjekt zugewiesen werden. Dann kann der Digest Spam für primäre und Alias-Adressen aufführen. Im User Portal selbst erscheinen Nachrichten an Aliasse weiterhin nicht.

Einrichtung, Benutzerzuweisung, Release-Link und vollständigen Funktionstest erklärt Sophos Firewall Quarantäne-Digest einrichten und testen.

Unter Email > Mail spool stehen noch nicht zugestellte oder fehlerhafte Nachrichten. SFOS versucht die Zustellung drei Tage lang und verwirft sie nach weiteren vier Tagen; verworfene Nachrichten bleiben in Mail logs sichtbar. Ein wachsender Spool ist deshalb ein Alarm für Routing-, DNS-, TLS-, Policy- oder Mailserverprobleme und kein Grund für blindes wiederholtes Retry.

Der Statusfilter unterscheidet Queued, Failed, SPX blocked, Zero-day protection und Error. SPX blocked wartet auf ein vom Empfänger zu erzeugendes Passwort; Zero-day protection wartet auf die Analyse. Nur Nachrichten in der Error Queue können heruntergeladen oder gelöscht werden. Zum Löschen oder erneuten Senden von Zero-Day-Protection-Nachrichten benötigt das Adminprofil Lese- und Schreibrechte für Zero-Day Protection Activity. Ein fehlender Button wird deshalb zuerst gegen Status und Profil geprüft, nicht mit einem Service-Neustart umgangen.

Quarantäne und Spool belegen lokalen Speicher. Freier Speicher, SSD-Zustand und System Health müssen überwacht werden; Hinweise bieten Speicher und Reports aufräumen und SSD Health prüfen. In HA sind Logs und Reports pro Node getrennt und werden nicht synchronisiert; beide Nodes müssen deshalb geprüft werden. Die Grundlagen erklärt Sophos Firewall HA-Cluster.

Troubleshooting

Externe E-Mails kommen nicht an

MX, A/AAAA, öffentliche IP, TCP 25 und SMTP Relay aus WAN prüfen. Danach kontrollieren, ob MTA Mode aktiv ist, die geschützte Domain zur Policy passt und keine alte DNAT- oder höher priorisierte Firewall-Regel den erwarteten Pfad verändert. Ist in smtpd_main.log keine Verbindung sichtbar, liegt das Problem wahrscheinlich vor der Mail Protection.

Firewall nimmt an, stellt aber nicht zu

Internen Mailserver, Route, DNS, Zielport, TLS und Recipient verification prüfen. Bei Static host, DNS host und MX gelten unterschiedliche Failover- und Auflösungswege. Reject- und Error-Logs der Firewall werden zeitlich mit den Mailserver-Logs verglichen.

Viele Nachrichten bleiben im Spool

Zuerst Email > Mail spool und die MTA-Logs prüfen. Eine häufige Ursache ist eine Regel oberhalb der automatisch erstellten MTA-Regel, die SMTP bereits matched. Unter Rules and policies > Firewall rules werden deshalb neue Regeln mit Position Top, automatisch erzeugte IPsec- oder Hotspot-Regeln und andere Überschneidungen kontrolliert. Keine Regel wird blind verschoben; entscheidend ist ihr tatsächlicher SMTP-Match.

Ist die überlagernde neue Regel als Ursache bestätigt, wird sie unter Rules and policies > Firewall rules so weit nach unten verschoben, dass die vorgesehene SMTP-Regel wieder ausgewertet wird. Danach werden Zustellung und Spool mit einer kontrollierten Nachricht erneut geprüft; andere benötigte Verbindungen müssen weiterhin über die vorgesehenen Regeln laufen.

NC-177930 wurde in SFOS 22.0 MR2 behoben: Nachrichten blieben wegen eines abgestürzten mailpoller im Spool. Tritt das Problem auf einer älteren Version auf, gehört der Firmwarestand deshalb zur Diagnose. Mit dem SFOS-22-Upgrade-Check werden Ziel-Build und Änderung festgelegt und der Mailflow danach erneut getestet.

Sophos Fusion meldet Invalid API request

Auf SFOS 22.0 MR1 konnten Release und Delete fehlschlagen, wenn die Firewall über Sophos Fusion (ehemals Sophos Central) geöffnet wurde. Das Fehlerbild Invalid API request wird unter NC-182056 geführt; NC-181904 bezeichnet den Fix für die fehlgeschlagene Freigabe über Sophos Fusion. Der sichere Workaround ist die direkte Anmeldung am lokalen WebAdmin und die Aktion unter Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 behebt das Problem. Schlägt die Aktion dort weiterhin fehl, werden Adminprofil, Sophos-Fusion-Zugriff und lokale Berechtigungen separat geprüft. Für ein Update gilt der vollständige Freigabe-, Vorbereitungs-, Prüf- und Troubleshooting-Prozess unter Sophos Firewall Firmware Update: Vorbereitung und Best Practices.

Reject based on RBL lässt sich nicht aktivieren

NC-144563 ist ein versionsspezifischer Fall für SFOS 20.0.2 MR2 Build 378: Wurden die Standard-RBL-Gruppen unter Email > Address group umbenannt, lässt sich Reject based on RBL beim Erstellen einer SMTP route and scan-Policy nicht aktivieren. In einer bestehenden Policy lässt sich die Option nach dem Deaktivieren nicht wieder einschalten. Eine behobene Version ist nicht dokumentiert.

Die Defaultgruppen heissen Premium RBL services und Standard RBL services. Zuerst den exakten Build und die aktuellen Gruppennamen dokumentieren. Treffen beide Bedingungen zu, die Default-RBLs auf ihre Originalnamen zurücksetzen, die Policy erneut öffnen und die Option prüfen. Eigene RBLs nicht mit den beiden Systemgruppen verwechseln.

Auf anderen Builds oder bei unveränderten Defaultnamen beweist eine ausgegraute Option NC-144563 nicht. Dann Policy-Typ, Spam protection, Email-Protection-Lizenz und die übrige Konfiguration getrennt prüfen.

Legitimer Absender wird als Spam erkannt

Absenderdomain, SPF/DKIM/DMARC, Header, Reputation, Policy-Match und betroffene Empfänger prüfen. Ausnahmen werden erst danach eng angelegt und mit einem Review-Datum dokumentiert. Den vollständigen Scope-, Test- und Rollback-Ablauf zeigt E-Mail-Ausnahmen sicher anlegen und testen.

Interne Systeme können nicht relayen

Quellzone unter Administration > Device access, Hostobjekt unter Email > Relay settings > Host-based relay und die MTA-Logs prüfen. Erwartet ein Scanner Standard-SMTP-AUTH, ist Host-based relay meist der verlässlichere Weg. Das separate, nicht RFC-konforme Authenticated relay muss mit dem konkreten Client getestet werden.

Betriebscheckliste

• Lizenz, Modellunterstützung, DNS und benötigte Internetdienste sind geprüft.
• MX, TTL, öffentlicher und interner Mailpfad sowie Rückfall sind dokumentiert.
• Die automatische MTA-Regel ist unverändert und steht oben.
• Keine alte DNAT-Regel umgeht Mail Protection.
• Address Group, Routingziel und Policy-Match sind getestet.
• Eingehendes SMTP Relay aus WAN und ausgehende Host-Freigaben sind korrekt getrennt.
• SPF/RBL-, Recipient-Verification-, TLS-, DKIM-, SPX- und Banner-Wirkung sind verstanden.
• Externe Positiv- und Negativtests wurden durchgeführt.
• Quarantäne, Spool, Speicher und Logs werden überwacht.
• Nach Firmware-Updates wird der Mailflow erneut geprüft.

Für längere Aufbewahrung und Korrelation eignen sich Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden.

FAQ