Sophos Firewall Mail Protection im MTA Mode einrichten

Sophos Firewall kann SMTP-Traffic im MTA Mode selbst annehmen, prüfen und an den internen Mailserver oder den nächsten Mailhop weiterleiten. Die Firewall ist dann nicht nur eine Portfreigabe für TCP 25, sondern ein aktiver Mail Transfer Agent mit Routing, Spam- und Malware-Prüfung, Quarantäne, Spool und Mail-Logs.

Wir empfehlen Mail Protection auf der Firewall heute vor allem für bewusst geplante On-Premises- oder Hybrid-Szenarien, 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 viele moderne Cloud-Mail-Umgebungen ist Sophos Central Email oder ein anderes Cloud-Mail-Gateway meistens die sauberere Architektur, weil MX, Quarantäne, Header, TLS, SPF/DKIM/DMARC und Support näher am eigentlichen Maildienst liegen.

Wenn Mail Protection im MTA Mode eingesetzt wird, muss der Artikel mehr leisten als eine Feature-Erklärung: MX-Record, automatische MTA-Regel, SMTP route and scan Policy, Relay-Freigaben, TLS, Benutzerprüfung, Spool, Quarantäne und Logs müssen zusammenpassen. Sonst kann die Firewall legitime E-Mails abweisen, Mail verzögern oder unbeabsichtigt als Relay erreichbar werden.

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:

• MTA Mode: Die Firewall nimmt E-Mail an, prüft sie und stellt sie weiter zu. Das passt für eingehenden oder ausgehenden SMTP-Mailflow mit Policies.
• Legacy Mode: Ältere proxy-basierte Mailverarbeitung. Relevant für Bestandsumgebungen, die migriert oder bewusst weiterbetrieben werden.
• SMTP Relay als lokaler Dienst: Interne Systeme senden über die Firewall. Typische Beispiele sind Drucker, Scanner, Applikationen oder Monitoring-Systeme.

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/87w und XGS 88/88w 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 unter:

Email > General settings

Für diese Anleitung muss MTA mode aktiv sein. Wenn die Firewall noch im Legacy Mode läuft, wird mit Switch to MTA mode umgestellt.

Nach dem Aktivieren erstellt Sophos Firewall automatisch eine Firewall-Regel für SMTP/SMTPS mit dem Namen Auto added firewall policy for MTA. Diese Regel sollte sichtbar bleiben und weit oben in der Regelbasis stehen. Eine MTA-Regel darf nicht wie eine normale LAN-to-WAN-Regel behandelt oder nebenbei nach unten verschoben werden, weil sonst eingehender SMTP-Traffic nicht mehr im erwarteten MTA-Pfad landet.

Danach werden die Basiseinstellungen geprüft:

1. Unter SMTP settings den SMTP hostname setzen. Das ist der Hostname, den die Firewall in HELO- und Banner-Kontexten für systemgenerierte Nachrichten verwendet. Nicht blind den internen Mailservernamen eintragen, wenn der öffentliche Mailname ein anderer ist.
2. Reject based on IP reputation aktivieren, wenn eingehende SMTP-Verbindungen anhand schlechter Sender-Reputation abgewiesen werden sollen.
3. Unter SMTP TLS configuration ein passendes öffentlich vertrauenswürdiges Zertifikat wählen, wenn SMTP TLS über die Firewall sauber präsentiert werden soll.
4. Disable legacy TLS protocols aktivieren, sofern keine bewusst dokumentierten Alt-Systeme dagegen sprechen.
5. Scan outgoing mails aktivieren, wenn ausgehende Nachrichten vom Mailserver über die Firewall ebenfalls geprüft werden sollen.

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.

Address Group für Maildomains anlegen

Zuerst wird eine Address Group für die geschützten Maildomains erstellt:

1. Email > Address group öffnen.
2. Add klicken.
3. Group type auf Email address/domain prüfen.
4. Type auf Manual belassen, wenn die Domains manuell gepflegt werden.
5. Unter Email address/domain die Domain eintragen, zum Beispiel example.com, und hinzufügen.
6. Save klicken.

Hier geht es um Domains, nicht um einzelne Empfängeradressen. Einzelne bestehende oder migrierte E-Mail-Adressen können je nach Konfiguration weiter greifen, lassen sich in aktuellen SMTP-route-and-scan-Policies aber nicht mehr als neue Einträge planen. Für einen sauberen Zielzustand sollte man deshalb mit Domains und passenden Empfängerprüfungen arbeiten.

SMTP route and scan Policy erstellen

Die eigentliche MTA-Policy wird unter folgendem Pfad erstellt:

Email > Policies and exceptions > Add a policy > SMTP route and scan

Ein typischer Ablauf für eingehende Mails zu einem internen Mailserver:

1. Einen sprechenden Name setzen, zum Beispiel Inbound example.com to Exchange.
2. Unter Protected domain die zuvor erstellte Address Group auswählen.
3. Route by festlegen:
   • Static host: Für feste interne Mailserver-IP-Adressen.
   • DNS host: Für einen DNS-Namen wie mailserver.example.com.
   • MX: Wenn die Firewall anhand von MX-Records zustellen soll.
4. Bei Static host den internen Mailserver unter Host list auswählen. IP-Hosts werden bei Bedarf unter Hosts and services > IP host angelegt.
5. Global action auf Accept setzen, wenn die Domain angenommen und nach Policy geprüft werden soll.
6. Spam protection aktivieren und bewusst entscheiden, ob Spam gewarnt, quarantänisiert, gedroppt oder ohne Aktion zugestellt wird.
7. Malware protection aktivieren. Für Zero-Day Protection mit Single-Antivirus-Scan muss Sophos als primäre Engine verwendet werden.
8. File protection und Data protection nur aktivieren, wenn die Auswirkungen auf Anhänge, grosse Nachrichten, SPX und DKIM verstanden sind.
9. Save klicken.

Bei mehreren internen Mailservern ist die Routing-Art wichtig. Bei Static host wird zum nächsten Host gewechselt, wenn der erste Host nicht erreichbar ist. Bei DNS host mit mehreren A-Records kann die Zustellung verteilt werden. Das ist praktisch, muss aber zum Mailserver-Design, zu TLS-Zertifikaten und zur Fehleranalyse passen.

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?
• Soll Recipient verification per Callout oder Active Directory eingesetzt werden?
• Wer darf Quarantäne prüfen und E-Mails freigeben?
• Welche False-Positive-Prozesse gibt es?

Bei Spam Protection sollte man SPF, RBL, Greylisting, BATV und Recipient verification nicht als reine Checkboxen behandeln. RBL- oder SPF-Treffer werden nicht wie normale Spam-Aktionen verarbeitet, sondern können Nachrichten direkt abweisen. Recipient verification reduziert Backscatter und ungültige Empfänger, kann aber bei AD-, TLS- oder Mailserver-Problemen selbst zur Fehlerquelle werden.

Bei ausgehenden Nachrichten ist DKIM besonders empfindlich. SPX-Verschlüsselung, Subject-Präfixe, blockierte Dateitypen, Data Protection oder ein ausgehender Banner können Header oder Body verändern. Dadurch kann ein DKIM-Hash beim Empfänger-MTA brechen. Wenn ausgehende Signaturen wichtig sind, sollte man entscheiden, ob die Signierung auf dem Mailserver, auf Sophos Firewall oder an einem späteren Gateway passieren soll.

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.

Für eingehende E-Mails muss SMTP an der WAN-Seite grundsätzlich angenommen werden können, damit externe Mailserver die Domain zustellen können. Für ausgehende E-Mails muss dagegen klar sein, welche internen Hosts über die Firewall relayen dürfen.

Prüfen:

• Unter Administration > Device access ist SMTP Relay nur in den wirklich benötigten Zonen aktiviert.
• Wenn ACL Exception Rules genutzt werden, sind Quellen eng definiert.
• Unter Email > Relay settings sind bei Host-based relay nur definierte Mailserver, Scanner oder Applikationsserver als erlaubte Quellen eingetragen.
• Nicht benötigte Zonen, Gastnetze und untrusted Netze dürfen nicht pauschal relayen.
• Wenn Cloud-Dienste wie Exchange Online Protection über die Firewall zustellen oder relayen sollen, müssen die erlaubten Quellbereiche sehr genau gepflegt werden. Breite Any-Freigaben sind ein Open-Relay-Risiko.
• 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:

• SMTP MTA: smtpd_main.log.
• SMTP Fehler: smtpd_error.log, smtpd_panic.log und smtpd_reject.log.
• Anti-Spam: sasi.log.
• Legacy SMTP/MTA: awarrensmtp.log, awarrenmta.log und awarrenmta_debug.log.
• POP/IMAP Proxy: warren.log.

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.

Quarantäne direkt im WebAdmin prüfen

Wenn eine Firewall über Sophos Central verwaltet wird, ist der Zugriff über Central praktisch. Für Mail Protection sollte man trotzdem wissen, wo die Quarantäne lokal liegt und wie man sie direkt auf der Firewall prüft.

Der lokale Pfad lautet:

Email > SMTP quarantine

Dort kann man quarantänisierte Nachrichten nach Zeitraum, Absender, Empfänger, Betreff und Quarantänegrund filtern. Für den Betrieb sind vor allem drei Aktionen relevant:

• Delete: Nachricht aus der Quarantäne löschen.
• Release: Nachricht an den Empfänger freigeben.
• Release and report: False Positive freigeben und an SophosLabs melden.

Wichtig: Virus-infizierte Nachrichten und Nachrichten, die von Zero-Day Protection als bösartig bewertet wurden, können nicht einfach freigegeben werden. Für Zero-Day-Protection-Einträge braucht es ausserdem passende Berechtigungen, wenn sie gelöscht werden sollen. Wenn die Quarantäne voll läuft, werden ältere E-Mails bereinigt. Das ist ein weiterer Grund, Quarantäne und Speicher nicht erst bei Beschwerden zu prüfen.

Bei SFOS 22.0 MR1 gibt es einen wichtigen Sonderfall: Wenn man die Firewall über Sophos Central verwaltet, können Quarantäne-Aktionen wie Release oder Delete mit Invalid API request fehlschlagen. Das bedeutet nicht automatisch, dass der Mailflow, die Quarantäne selbst oder die MTA-Policy defekt ist. Der praktische Workaround ist, sich direkt am lokalen WebAdmin der Firewall anzumelden und die Nachricht unter Email > SMTP quarantine dort freizugeben oder zu löschen.

Nach einem Update auf SFOS 22.0 MR2 oder neuer sollte man den Ablauf erneut testen: eine harmlose Testnachricht quarantänisieren, die Aktion über den geplanten Administrationsweg ausführen und danach Log Viewer, Quarantäne und Empfängerpostfach prüfen. So bleibt klar, ob das Problem wirklich behoben ist oder ob zusätzlich Rollen, Central-Zugriff oder lokale Berechtigungen beteiligt sind.

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.

Quarantäne-Aktion meldet Invalid API request

Wenn Release oder Delete bei einer über Sophos Central geöffneten Firewall mit Invalid API request fehlschlägt, zuerst die SFOS-Version prüfen. Bei SFOS 22.0 MR1 kann genau dieser Ablauf betroffen sein.

Der nächste Schritt ist nicht, die Mail-Policy umzubauen. Zuerst direkt auf den lokalen WebAdmin der Firewall wechseln und die Nachricht unter Email > SMTP quarantine bearbeiten. Danach dokumentieren:

1. SFOS-Version und Build.
2. Ob die Aktion über Sophos Central oder direkt im WebAdmin ausgeführt wurde.
3. Absender, Empfänger, Betreff und Quarantänegrund.
4. Ergebnis nach einem Test über den direkten WebAdmin.
5. Ob ein Update auf SFOS 22.0 MR2 oder neuer geplant oder bereits installiert ist.

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.
• Address Group für die geschützten Domains ist sauber gepflegt.
• Firewall-Regelreihenfolge verhindert nicht, dass die MTA-Regel greift.
• TLS, DKIM, Banner, SPX und Data Protection sind auf Nebenwirkungen geprüft.
• 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.
• Direkter WebAdmin-Zugriff für Quarantäne-Freigaben ist bekannt, falls Central-Aktionen fehlschlagen.
• 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