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 Central 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.

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: Ältere transparente Proxy-Verarbeitung für Bestandsumgebungen.
• 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.

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.
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. Zudem validiert die Firewall SMTP-TLS anhand der Domain-IP statt des Domainnamens. Mehrere Domains auf derselben IP können deshalb zu Zertifikatsfehlern führen.

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.

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 a 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 auf Accept setzen.
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.

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 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.

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. 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

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.

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.

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.

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.

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

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;
• 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.

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.

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. Alias-Adressen müssen im Quarantänekonzept separat geprüft werden; Nachrichten an Aliasse erscheinen nicht im User Portal.

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.

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.

SFOS 22.0 MR2 behebt zusätzlich NC-177930, bei dem Nachrichten wegen eines abgestürzten mailpoller im Spool blieben. Tritt das Problem auf einer älteren Version auf, gehört der Firmwarestand deshalb zur Diagnose.

Central meldet Invalid API request

Auf SFOS 22.0 MR1 konnten Release und Delete fehlschlagen, wenn die Firewall über Sophos Central geöffnet wurde. Der sichere Workaround ist die direkte Anmeldung am lokalen WebAdmin und die Aktion unter Email > SMTP quarantine. Der Fehler wurde mit SFOS 22.0 MR2 Build 546 behoben. Schlägt die Aktion dort weiterhin fehl, werden Adminprofil, Central-Zugriff und lokale Berechtigungen separat geprüft.

Reject based on RBL lässt sich nicht aktivieren

Sophos führt unter NC-144563 einen versionsgebundenen Fall für SFOS 20.0.2 MR2 Build 378: Wurden die vorgegebenen 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 kann die Option nach dem Deaktivieren nicht wieder eingeschaltet werden. Die aktuelle Known Issues List nennt keine Fixversion.

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.

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