Sophos Firewall Mail Protection im MTA Mode einrichten

Sophos Firewall kann E-Mail-Traffic nicht nur als normale Firewall-Verbindung erlauben, sondern im MTA Mode selbst als Mail Transfer Agent zwischen Internet und internem Mailserver arbeiten. Die Firewall nimmt SMTP-Verbindungen an, prüft Nachrichten mit Mail Protection und stellt sie anschliessend an den definierten Mailserver zu.

Wir empfehlen Mail Protection auf der Firewall heute nur noch für bewusst geplante Spezialfälle, etwa wenn ein lokaler Exchange oder ein anderer interner Mailserver direkt über die Firewall geschützt werden soll. Für Microsoft 365, Google Workspace und die meisten modernen Cloud-Mail-Umgebungen ist Sophos Central Email in der Regel die bessere Lösung. Central Email ist näher am eigentlichen Maildienst, integriert sich sauberer in Cloud-Postfächer, reduziert die Komplexität im Firewall-Regelwerk und vermeidet viele klassische MTA-Themen wie MX-Umbauten, lokale Spools, Relay-Fragen und Fehleranalyse auf der Firewall.

Ein weiterer praktischer Punkt: Die Email Protection auf der Firewall wirkt im Vergleich zu Sophos Central Email schon länger wie eine Bestandsfunktion, die vor allem für bestehende On-Premises-Mailserver relevant bleibt. Wer heute neu plant, sollte deshalb zuerst prüfen, ob ein Cloud-Mail-Gateway die sauberere Architektur ist.

Das ist technisch stark, aber auch fehleranfällig, wenn DNS, MX-Record, TLS, Relay, Benutzerprüfung, Policies und Logs nicht sauber geplant sind. Ein falsch konfigurierter MTA kann legitime E-Mails blockieren, den Mailflow verzögern oder im schlimmsten Fall als Relay missverstanden werden.

Der Artikel erklärt den praktischen Aufbau für Sophos Firewall Mail Protection im MTA Mode. Er ersetzt keine Sophos-Central-Email-Planung. Für viele Microsoft-365- oder Google-Workspace-Umgebungen ist ein Cloud-Mail-Gateway oft passender. Wenn aber ein lokaler Exchange, ein hybrider Mailserver oder ein bewusst firewallbasierter SMTP-Pfad betrieben wird, braucht es einen klaren Betriebsplan.

Wann Mail Protection auf der Firewall sinnvoll ist

Mail Protection auf der Sophos Firewall ist vor allem dann sinnvoll, wenn SMTP-Traffic bewusst über die Firewall laufen soll und die Firewall dabei mehr tun soll als nur Port 25 weiterzuleiten.

Typische Szenarien:

• Eingehende E-Mails sollen zuerst auf der Firewall angenommen und geprüft werden.
• Ein interner Mailserver soll nicht direkt aus dem Internet erreichbar sein.
• Spam-, Malware-, Dateityp- oder Content-Prüfung soll vor der Zustellung greifen.
• Ausgehende E-Mails sollen kontrolliert über die Firewall oder einen Smarthost gesendet werden.
• Quarantäne, Mail-Spool und SMTP-Logs sollen auf der Firewall nachvollziehbar sein.

Nicht jedes Mailsetup sollte über die Firewall laufen. Wenn bereits Sophos Central Email, Microsoft Defender for Office 365 oder ein anderes Cloud-Mail-Gateway den kompletten Mailflow übernimmt, sollte man Mail Protection auf der Firewall nicht zusätzlich dazwischen schalten, ohne den Mailfluss genau zu dokumentieren. Doppelte Gateways führen schnell zu unklaren Zuständigkeiten bei Quarantäne, Headern, SPF/DKIM/DMARC, TLS und Fehlersuche.

MTA Mode, Legacy Mode und SMTP Relay unterscheiden

Bei Sophos Firewall muss man drei Dinge sauber trennen:

Der MTA Mode ist der normale Zielmodus für moderne Firewall-Mail-Protection-Szenarien. Der lokale Dienst SMTP Relay ist dagegen ein Device-Access-Thema. Er sollte nur aus definierten internen Netzen erreichbar sein. Eine zu breite Freigabe kann Relay-Missbrauch begünstigen. Die Härtung lokaler Dienste ist in Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren beschrieben.

Voraussetzungen

Vor der Einrichtung sollten diese Punkte geklärt sein:

• Sophos Firewall mit gültiger Email Protection oder passendem Bundle.
• Nicht jedes Modell unterstützt MTA Mode. XGS 87 und XGS 88 sind Appliances ohne MTA-Mode-Unterstützung.
• Öffentliche DNS-Zone und MX-Record sind bekannt.
• Interner Mailserver, Zielport und Zustellweg sind dokumentiert.
• Öffentliche IP-Adresse oder WAN-Adresse für eingehenden SMTP-Traffic ist definiert.
• Firewall kann den internen Mailserver routen und erreichen.
• Ausgehender DNS-Zugriff der Firewall funktioniert.
• Gewünschte TLS- und Zertifikatsstrategie ist geklärt.
• Quarantäne- und Freigabeprozess ist organisatorisch definiert.

Vor Änderungen am Mailflow sollte ein Wartungsfenster geplant werden. Ein Test an produktiven MX-Records ohne Rückfallplan ist riskant, weil eingehende E-Mails je nach Absender schnell verzögert oder abgewiesen werden.

Zielarchitektur festlegen

Zuerst sollte entschieden werden, welche Richtung die Firewall verarbeiten soll.

Eingehender Mailflow

Beim eingehenden Mailflow zeigen externe MX-Records auf die öffentliche Adresse, über die Sophos Firewall SMTP annimmt. Die Firewall prüft die Nachricht und leitet sie an den internen Mailserver weiter.

Typischer Ablauf:

1. Externer Absender verbindet sich per SMTP zur öffentlichen MX-Adresse.
2. Sophos Firewall nimmt die Verbindung im MTA Mode an.
3. Mail Protection prüft Absender, Empfänger, Spam, Malware, Anhänge und Policy.
4. Die Firewall stellt die E-Mail an den internen Mailserver zu.
5. Der interne Mailserver liefert ins Postfach oder verarbeitet die Nachricht weiter.

Wichtig ist, dass der interne Mailserver nicht zusätzlich ungefiltert aus dem Internet erreichbar bleibt. Wenn parallel noch eine DNAT-Regel direkt auf den Mailserver zeigt, läuft ein Teil des Traffics möglicherweise an der Mail Protection vorbei. Für normale Serververöffentlichungen ist Server per DNAT veröffentlichen die passende Grundlage, aber beim MTA Mode ist die Firewall selbst der SMTP-Annahmepunkt.

Ausgehender Mailflow

Beim ausgehenden Mailflow sendet der interne Mailserver über die Sophos Firewall. Die Firewall kann Nachrichten prüfen, an einen Smarthost weiterleiten oder direkt zustellen, je nach Konfiguration.

Vorher klären:

• Darf die öffentliche Firewall-IP E-Mails direkt versenden?
• Stimmen SPF, DKIM und DMARC für den gewählten Versandweg?
• Wird ein Provider-Smarthost benötigt?
• Muss ausgehender SMTP-Traffic auf bestimmte interne Systeme begrenzt werden?
• Wo werden abgewiesene oder verzögerte Nachrichten überwacht?

Für ausgehenden Mailtraffic sollte eine eigene, nachvollziehbare Regel- und Policy-Struktur verwendet werden. Eine allgemeine LAN to WAN-Regel ohne klare Einschränkung ist für Mailserver meistens zu grob. Die Grundlagen zu Regelreihenfolge und Security-Profilen stehen in Sophos Firewall Regeln verstehen und sauber aufbauen.

MX-Umstellung und externe Tests vorbereiten

Eine Mail-Protection-Umstellung wird erst dann kritisch, wenn externe Absender den neuen Weg wirklich verwenden. Deshalb sollte man MX-Record, DNS-TTL, externe Erreichbarkeit und Rollback vor dem produktiven Wechsel prüfen.

Vor der Umstellung:

• Aktuellen MX-Record, Priorität und TTL dokumentieren.
• DNS-TTL frühzeitig reduzieren, wenn ein schneller Rückfall nötig sein könnte.
• Alten Mailpfad und neue Sophos-Firewall-Adresse klar unterscheiden.
• Alte direkte DNAT-Regeln auf den Mailserver identifizieren.
• Testempfänger und Testabsender definieren.
• Rückfallplan festlegen: alter MX, alte DNAT-Regel oder temporärer Smarthost.
• Monitoring für Spool, Quarantäne und Mailserver-Queue vorbereiten.

Nützliche externe Prüfungen von einem System ausserhalb des eigenen Netzwerks:

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

Die Befehle ersetzen keinen vollständigen Mailflow-Test, zeigen aber schnell, ob DNS, Port 25 und STARTTLS grundsätzlich erreichbar sind. example.com und mail.example.com müssen durch die echte Domain und den echten Mailhost ersetzt werden.

Nach dem Umschalten sollte man sofort eine eingehende Testmail senden und den gesamten Pfad dokumentieren:

• Verbindung im Log Viewer sichtbar?
• Eintrag in smtpd_main.log vorhanden?
• Empfängerprüfung erfolgreich?
• Zustellung an internen Mailserver erfolgt?
• Nachricht im Postfach angekommen?
• Keine parallele direkte Zustellung am MTA vorbei?

Wenn die Firewall zwar E-Mails annimmt, aber nicht zustellt, sollte nicht sofort der MX zurückgestellt werden. Zuerst klären, ob es ein internes Routing-, DNS-, TLS- oder Mailserver-Problem ist. Wenn externe Absender aber keine Verbindung zur Firewall aufbauen können oder legitime E-Mails breit abgewiesen werden, ist ein schneller Rückfall auf den vorherigen Mailpfad oft sinnvoller als längeres Experimentieren im produktiven MX-Pfad.

MTA Mode aktivieren

Die grundlegenden Einstellungen liegen in der Sophos Firewall unter:

Email > General settings

Dort wird der E-Mail-Modus festgelegt. Für diese Anleitung ist MTA mode relevant. Nach dem Wechsel sollte man prüfen, ob die vorhandenen Policies, Hostobjekte und Maildomains noch zum gewünschten Betrieb passen.

Bei bestehenden Umgebungen nicht einfach zwischen Legacy Mode und MTA Mode wechseln, ohne den Mailflow zu testen. Die Verarbeitung, Logs und Policy-Logik unterscheiden sich. Vor einer Migration sollten aktuelle Firewall-Konfiguration, MX-Records, Mailserver-Connectoren und Relay-Einstellungen dokumentiert werden.

SMTP Routing und Domains konfigurieren

Für eingehende E-Mails muss die Firewall wissen, welche Domains sie annehmen und wohin sie diese zustellen soll.

Typischer Ablauf:

1. Unter Email > Policies and exceptions beziehungsweise den Mail-Protection-Bereichen die betroffenen Domains und Zielserver planen.
2. Maildomain eintragen, zum Beispiel example.com.
3. Internen Mailserver oder Hostobjekt als Zustellziel definieren.
4. Prüfen, ob die Firewall den Mailserver auf dem Zielport erreicht.
5. TLS-Anforderungen und Zertifikate prüfen.
6. Testmail von extern an einen bekannten Empfänger senden.

Für interne Mailserver ist DNS besonders wichtig. Die Firewall muss interne Ziele korrekt auflösen können, und externe Absender müssen den öffentlichen MX-Eintrag erreichen. Wenn interne DNS-Auflösung eine Rolle spielt, hilft DNS Request Routes auf Sophos Firewall einrichten.

Policies für Spam, Malware und Anhänge planen

Mail Protection ist nur so gut wie die Policies, die tatsächlich greifen. Eine Policy sollte nicht nur erstellt, sondern mit einem klaren Zweck benannt werden.

Wichtige Policy-Fragen:

• Welche Domains oder Empfängergruppen sind betroffen?
• Wird eingehender, ausgehender oder beidseitiger Mailtraffic verarbeitet?
• Was passiert bei Spam, Malware, verdächtigen Anhängen oder unerwünschten Dateitypen?
• Werden E-Mails blockiert, quarantänisiert, zugestellt oder mit Headern markiert?
• Wer darf Quarantäne prüfen und E-Mails freigeben?
• Welche False-Positive-Prozesse gibt es?

Wenn Zero-Day Protection genutzt wird, können verdächtige E-Mail-Anhänge zusätzlich analysiert werden. Die Grenzen, Reports und Freigabeentscheidung sind in Sophos Firewall Zero-Day Protection verstehen und betreiben erklärt.

Relay und Device Access absichern

Ein häufiger Fehler ist die Verwechslung zwischen MTA-Mailflow und offenem SMTP Relay. Die Firewall darf nicht aus beliebigen Netzen als Relay verwendet werden.

Prüfen:

• Unter Administration > Device access ist SMTP Relay nur aus benötigten internen Zonen erreichbar.
• Wenn ACL Exception Rules genutzt werden, sind Quellen eng definiert.
• Nur definierte interne Mailserver, Scanner oder Applikationsserver dürfen über die Firewall relayen.
• Aus WAN, Gastnetzen und untrusted Zonen ist SMTP Relay nicht pauschal freigegeben.
• Logging ist aktiv, damit Missbrauch oder Fehlkonfigurationen auffallen.

Wenn Drucker, Scanner oder Applikationen E-Mails senden müssen, sollte dafür ein eigener interner Relay-Pfad dokumentiert werden. Solche Systeme sollten nicht direkt mit beliebigen externen SMTP-Zielen sprechen, wenn die Umgebung das vermeiden kann.

Mailflow testen

Nach der Einrichtung reicht ein einzelner erfolgreicher Versand nicht. Man sollte mehrere Tests durchführen und die Ergebnisse dokumentieren.

Eingehend testen

Mindestens prüfen:

• Externer MX-Record zeigt auf die erwartete Adresse.
• Port 25 ist von extern erreichbar.
• Firewall nimmt die Verbindung im MTA Mode an.
• E-Mail wird an den internen Mailserver weitergeleitet.
• Empfänger existiert und bekommt die Nachricht.
• Spam- oder Malware-Test wird erwartungsgemäss behandelt.
• Quarantäne- oder Logeintrag ist nachvollziehbar.

Ausgehend testen

Mindestens prüfen:

• Interner Mailserver sendet über die erwartete Route.
• Firewall-Regel und Mail-Policy greifen.
• SPF, DKIM und DMARC passen zum Versandweg.
• Zielserver akzeptiert die Nachricht.
• Bounces oder Deferred-Meldungen werden überwacht.
• Keine anderen internen Systeme senden ungeplant direkt nach extern.

Logs prüfen

Für schnelle Sichtprüfung hilft der Log Viewer. Für tiefere Analyse sind die Mail-Logdateien wichtig. Die Zuordnung steht in Sophos Firewall Troubleshooting: Services und Logs.

Relevante Logdateien:

Bei akutem Troubleshooting sollte man den Testzeitpunkt notieren, Absender, Empfänger, Betreff, Quell-IP und Message-ID sammeln und dann Log Viewer und Logdateien zeitlich korrelieren.

Quarantäne, Spool und Speicher

Mail Protection erzeugt lokale Daten. Je nach Volumen landen Nachrichten in Quarantäne, Spool oder temporären Bereichen. Dadurch werden Speicherplatz, SSD-Zustand und Recovery-Plan relevanter als bei einer reinen Firewall-Regel.

Praktische Betriebsfragen:

• Wer prüft Quarantäne und wie oft?
• Wie werden False Positives freigegeben?
• Wann wird eine Nachricht gelöscht statt freigegeben?
• Wie wird ein wachsender Mail-Spool erkannt?
• Gibt es Monitoring für Speicherplatz und System Health?
• Wird nach Firmware-Updates ein kurzer Mailflow-Test eingeplant?

Für Speicher- und Reporting-Themen passen Sophos Firewall Speicher und Reports aufräumen und Sophos Firewall SSD Health prüfen. In HA-Umgebungen sollte zusätzlich beachtet werden, dass Mail-Quarantäne und verarbeitete Maildaten nodebezogene Betriebsdaten sein können. Die HA-Grundlagen stehen in Sophos Firewall HA-Cluster Varianten.

Troubleshooting

Externe E-Mails kommen nicht an

Zuerst DNS und Erreichbarkeit prüfen: MX-Record, öffentliche IP, Port 25, NAT-Altlasten, MTA Mode und zuständige Maildomain. Danach im Log Viewer und in smtpd_main.log prüfen, ob die Verbindung die Firewall erreicht. Wenn keine Verbindung sichtbar ist, liegt das Problem wahrscheinlich vor der Mail Protection.

Firewall nimmt E-Mails an, stellt sie aber nicht zu

Dann sind interner Mailserver, Routing, DNS, Zielport, TLS, Empfängerprüfung oder Policy wahrscheinlicher. Man prüft, ob die Firewall den Mailserver erreichen kann und ob der Mailserver die Verbindung akzeptiert. Reject-Logs und Mailserver-Logs sollten zeitlich zusammen ausgewertet werden.

Viele E-Mails bleiben im Spool

Ein wachsender Spool deutet oft auf Zustellprobleme hin: interner Mailserver nicht erreichbar, TLS-Anforderung passt nicht, DNS-Auflösung schlägt fehl oder Zielserver lehnt die Nachricht ab. In diesem Fall nicht nur einzelne Nachrichten erneut zustellen, sondern die Ursache im Routing- und SMTP-Pfad suchen.

Ein wichtiger Regelreihenfolge-Fall wird leicht übersehen: Wenn eine automatisch oder manuell erstellte Firewall-Regel oberhalb der MTA-Regel liegt und SMTP-Traffic matched, wird die eigentliche MTA-Regel nicht mehr ausgewertet. Dann können E-Mails im Mail-Spool hängen bleiben, obwohl DNS, Port 25 und Mailserver grundsätzlich korrekt aussehen.

Prüfen:

1. Rules and policies > Firewall rules öffnen.
2. Regeln oberhalb der MTA- oder SMTP-Regel prüfen.
3. Neue automatisch erzeugte Regeln, IPsec-Regeln, Hotspot-Regeln oder manuell auf Top gesetzte Regeln kontrollieren.
4. SMTP-Test erneut durchführen und Log Viewer, Mail-Spool und smtpd_main.log vergleichen.

Die Regel darf nicht blind nach unten verschoben werden, wenn sie andere produktive Zwecke erfüllt. Entscheidend ist, ob sie SMTP-Traffic unerwartet vor der MTA-Regel abfängt.

Quarantäne-Digest fehlt für Alias-Adressen

Wenn Benutzer Alias-Adressen verwenden, sollte man Quarantäne-Einstellungen nicht nur für die primäre Mailadresse prüfen. Laut Sophos werden Quarantäne-Einstellungen standardmässig nicht automatisch auf Alias-Adressen angewendet. Wenn Digest-Mails oder Freigaben für Alias-Empfänger fehlen, müssen Alias-Adressen zusammen mit der primären Adresse im Quarantäne- beziehungsweise Benutzerkontext berücksichtigt werden.

Legitimer Absender wird als Spam erkannt

False Positives sollten nicht sofort mit breiten Ausnahmen beantwortet werden. Zuerst Absenderdomain, SPF/DKIM/DMARC, Header, Reputation, Policy-Match und betroffene Empfänger prüfen. Wenn eine Ausnahme nötig ist, sollte sie eng begrenzt und mit Review-Datum dokumentiert werden.

Interne Systeme können nicht relayen

Prüfen, ob SMTP Relay unter Administration > Device access aus der richtigen Zone erlaubt ist und ob die Quelle zur ACL passt. Danach Mail-Logs prüfen. Wenn ein Scanner oder eine Applikation relayen soll, sollte die Quelle als Hostobjekt dokumentiert und nicht ein komplettes Netz unnötig freigegeben werden.

Nach Firmware-Update funktioniert Mail anders

Nach Firmware-Updates sollten MTA Mode, Policies, Zertifikate, Mail-Spool, Quarantäne und relevante Logs geprüft werden. Für grössere Updates passt zusätzlich Sophos Firewall vor SFOS 22 Upgrade prüfen.

Betriebscheckliste

• Mail Protection Lizenz und Appliance-Unterstützung geprüft.
• MTA Mode bewusst gewählt und dokumentiert.
• MX-Record, öffentliche IP und interner Zielserver stimmen.
• MX-Umstellung, externe Tests und Rollback sind vorbereitet.
• Keine parallele ungefilterte DNAT-Regel umgeht den MTA.
• Eingehende und ausgehende Policies sind verständlich benannt.
• Firewall-Regelreihenfolge verhindert nicht, dass die MTA-Regel greift.
• SMTP Relay ist nur aus definierten internen Quellen erlaubt.
• Quarantäne- und False-Positive-Prozess sind festgelegt.
• Alias-Adressen sind im Quarantäne- und Digest-Prozess berücksichtigt.
• Mail-Spool, Speicherplatz und System Health werden überwacht.
• Logs werden lokal, in Sophos Central oder per Syslog ausreichend lange aufbewahrt.
• Nach Firmware-Updates wird ein Mailflow-Test durchgeführt.

Für längere Aufbewahrung und Korrelation mit anderen Sicherheitsereignissen sollte man Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden prüfen.

FAQ