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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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. Der ungültige Empfänger muss bei aktiver Empfängerprüfung abgewiesen werden; ist die Prüfung ausgeschaltet, ist dieser Negativtest kein erwarteter Reject. 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.

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