Sophos Firewall E-Mail-Ausnahmen sicher anlegen und testen

Eine E-Mail-Ausnahme auf Sophos Firewall erlaubt nicht einfach einen Absender. Sie überspringt ausgewählte Sicherheitsprüfungen für einen definierten SMTP-Pfad. Genau deshalb kann sie einen bestätigten False Positive sauber lösen, aber auch unbemerkt SPF, Malware-Scan, Zero-Day Protection oder DKIM-Prüfungen ausser Kraft setzen.

⚠️ Eine Ausnahme wird erst nach einem reproduzierbaren False Positive angelegt. Übersprungen wird nur die betroffene Prüfung. Für den Scope wird die kleinste belastbare Bedingung gewählt, denn Quellhost, Absender und Empfänger werden als Alternativen verknüpft, nicht als gemeinsame UND-Bedingung. Alle Prüfungen sowie breite Wildcards sind kein schneller Standard-Workaround.

Die Ausnahme in sieben Schritten

1. Testzeit, SMTP-Quell-IP, Envelope-Absender, Empfänger, Betreff, Message-ID und den konkreten Ablehnungsgrund sichern.
2. Prüfen, ob DNS, Routing, Relay, TLS oder die eigentliche Mail-Policy statt einer Sicherheitsprüfung den Fehler verursacht.
3. Unter Email > Policies and exceptions > Add an exception nur die nachgewiesen betroffene Prüfung auswählen.
4. Unter Sources or hosts, Sender addresses oder Recipient addresses nur die engste geeignete Bedingung aktivieren.
5. Eine gleichartige Nachricht positiv und mindestens eine Variante ausserhalb des Scopes negativ testen.
6. Unter Email > Mail logs Ergebnis und Reason vor und nach der Änderung vergleichen; weitere Schutzfunktionen mit harmlosen, kontrollierten Testfällen separat prüfen.
7. Owner, Begründung und Review-Datum dokumentieren; die Ausnahme nach der Ursachenbehebung entfernen.

Was eine Ausnahme tatsächlich überspringt

SFOS gruppiert die überspringbaren Prüfungen nach ihrer Wirkung. Unter Spam protection stehen RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF und BATV. Malware protection umfasst Malware und Zero-day protection. Unter Other liegen Data protection, File protection, Encryption, Banner addition, DKIM signing und DKIM verification.

Diese Auswahl ist keine Komfortliste. Eine Ausnahme für SPF lässt beispielsweise den übrigen Anti-Spam- und Malware-Pfad bestehen. Eine Ausnahme für Malware oder Zero-day protection entfernt dagegen eine zentrale Inhaltsprüfung für alle Nachrichten, die den Scope treffen. Encryption, DKIM signing oder DKIM verification verändern zusätzlich Vertraulichkeit und Integritätsnachweis des ausgehenden beziehungsweise eingehenden Mailflows.

Diese Ausnahme gehört zum MTA Mode. Dort bündelt eine SMTP route and scan Policy Routing sowie Spam-, Malware-, Datei- und Datenschutzaktionen. Im Legacy Mode arbeitet SFOS als transparenter Mail-Proxy und verwendet stattdessen getrennte SMTP malware scan- und SMTP spam scan-Policies; das MTA-Ausnahmeobjekt ist dort nicht der passende Weg. Die vollständigen Abläufe stehen unter Mail Protection im MTA Mode einrichten und Mail Protection im Legacy Mode einrichten.

Encryption in dieser Ausnahmeliste betrifft die E-Mail-Verschlüsselung der MTA-Policy, beispielsweise SPX Email Encryption. Sie ist keine Ausnahme für SMTP-Transportverschlüsselung. Require TLS negotiation, Zertifikatsprüfung und Skip TLS negotiation werden separat unter Email > General settings > SMTP TLS configuration gesteuert. Eine Mail-Ausnahme repariert deshalb weder einen TLS-Handshake noch Routing, Relay oder Firewall-Regeln.

Matching vor dem Speichern verstehen

Die drei Scope-Gruppen bilden kein UND. Die offizielle SFOS-22.0-Konfigurations-API benennt sie als ForTheseSourceHost, ORTheseSenderAddresses und ORTheseRecipientAddresses. Sobald mehrere Gruppen aktiviert sind, reicht somit ein Treffer auf Quellhost oder Absender oder Empfänger. Wer Quell-IP, Partnerdomain und Pilotpostfach gleichzeitig einträgt, begrenzt die Ausnahme daher nicht auf diese Kombination, sondern erweitert sie auf drei Trefferwege.

SFOS bietet in diesem Ausnahmeobjekt keine UND-Verknüpfung dieser drei Gruppen. Ist eine Ausnahme nur vertretbar, wenn Quelle und Adresse gleichzeitig stimmen, wird sie nicht mit zwei Ausnahmen nachgebaut: Auch diese würden den Scope erweitern. Dann ist die Ursache zu korrigieren oder der Mailflow über eine passend getrennte Policy beziehungsweise einen getrennten Gateway-Pfad abzugrenzen.

Sources or hosts

Als Quelle akzeptiert SFOS IP-Adressen, IP-Bereiche, IP-Listen, Netze oder FQDNs. Wildcard-FQDNs werden für E-Mail-Hostausnahmen nicht unterstützt. *.example.net ist deshalb kein gültiger Ersatz für die beobachtete SMTP-Quelladresse. Für localhost braucht es keine Ausnahme, weil SFOS lokale E-Mails standardmässig nicht scannt.

Bei Cloud-Maildiensten oder verteilten Gateways kann eine einzelne IP zu eng sein, ein komplettes Providernetz aber viel zu breit. Verwendet wird nur ein veröffentlichtes und im eigenen Mailflow tatsächlich beobachtetes Quellobjekt. Teilen sich fremde Mandanten dieselben Provider-IP-Adressen, kann bereits dieses Objekt zu breit sein. Dann ist eine Sicherheitsprüfung nicht allein aufgrund des Providernetzes auszunehmen.

Sender und Empfänger

Für Sender addresses und Recipient addresses sind eine einzelne Adresse wie sender@example.net oder eine Domain-Wildcard wie *@example.net zulässig. Eine zweite Scope-Gruppe ist kein engerer Gegenanker, weil sie mit ODER verknüpft wird. Besonders eine Absenderadresse ist bei einer Ausnahme für SPF oder DKIM kein unabhängiger Vertrauensbeweis: Genau diese Identitätsprüfung wird übersprungen. Eine Empfängerausnahme wiederum gilt für passende Nachrichten aller Absender.

BATV besitzt eine ungewöhnliche Sonderregel: Soll die BATV-Prüfung für E-Mails eines Absenders übersprungen werden, muss dessen Adresse sowohl unter Sender addresses als auch unter Recipient addresses eingetragen werden. Fehlt eines der beiden Felder, ist die Ausnahme für diesen BATV-Fall nicht vollständig.

Eine enge Ausnahme anlegen

Das Beispiel behandelt einen bestätigten SPF-False-Positive eines Partners mit einem dedizierten Mailgateway. 203.0.113.25 ist eine Dokumentationsadresse und wird durch die tatsächlich in den Mail logs beobachtete öffentliche Quell-IP ersetzt. Das Beispiel ist nur geeignet, wenn diese IP ausschliesslich dem vertrauenswürdigen Gateway zugeordnet ist; bei einem geteilten Cloud-Relay wäre der Bypass zu breit.

1. Email > Policies and exceptions > Add an exception öffnen.
2. Einen nachvollziehbaren Namen wie FP-SPF-partner-example-review-2026-09-30 setzen.
3. Unter den zu überspringenden Prüfungen ausschliesslich SPF auswählen.
4. Unter Sources or hosts den Host 203.0.113.25 eintragen.
5. Sender addresses und Recipient addresses deaktiviert beziehungsweise leer lassen. Sie würden den Scope durch zusätzliche ODER-Treffer erweitern.
6. Speichern und die Ausnahme nicht um weitere Hosts oder Prüfungen erweitern.

Der Name enthält bewusst Ursache und Review-Datum. Er ersetzt jedoch keine Dokumentation im Change oder Ticket. Ein Ablaufdatum wird durch den Namen nicht technisch erzwungen; der Owner muss die Prüfung tatsächlich durchführen.

Positiv- und Negativtest durchführen

Zuerst sendet der Partner dieselbe kontrollierte Nachricht erneut. Sie muss den vorgesehenen Mailflow durchlaufen und darf nicht mehr am bestätigten SPF-Grund scheitern. Unter Email > Mail logs lässt sich nach Zeitraum, Absender, Empfänger oder Betreff sowie nach Result und Reason filtern. Für SPF, RBL, Malware, Zero-day protection, DKIM verification und BATV existieren eigene Reason-Filter. smtpd_main.log und bei Ablehnungen smtpd_reject.log helfen bei der tieferen Korrelation; die Logzuordnung erklärt Sophos Firewall Services und Logs.

Danach folgt ein Negativtest über einen kontrollierten, nicht ausgenommenen SMTP-Pfad. Er darf nicht aufgrund dieser Ausnahme an der dokumentierten Prüfung vorbeikommen. Bei einer reinen Quellhost-Ausnahme sind andere Absender und Empfänger über die ausgenommene IP dagegen kein Negativtest: Sie treffen denselben ODER-Zweig ebenfalls. Eine harmlose Testdatei kann zusätzlich bestätigen, dass der normale Malware- und File-Protection-Pfad weiterhin reagiert; echte Malware wird nicht verwendet.

Eine erfolgreiche Zustellung allein beweist den Scope nicht. Die offizielle Beschreibung der Mail logs dokumentiert Scan-Reason und Zustellstatus, aber kein eindeutiges Feld «matched exception» und keine Liste aller übersprungenen Prüfungen. Deshalb werden Vorher-/Nachher-Reason, die Konfiguration der Ausnahme und getrennte Positiv- und Negativfälle gemeinsam bewertet. Ein erfolgreicher Versand wird nicht als Beweis für alle übrigen Schutzfunktionen ausgegeben.

Riskante Ausnahmen erkennen

Bereits eine breite Domain-Wildcard oder ein grosses Quellnetz kann den Schutz für einen erheblichen Teil des Mailflows entfernen. Werden beide eingetragen, werden sie nicht enger, sondern schaffen zusätzliche ODER-Treffer. Besonders Ausnahmen für Malware, Zero-Day Protection, Data protection und File protection benötigen eine dokumentierte Risikoentscheidung und einen sehr kleinen, eigenständig vertrauenswürdigen Scope. Bei einem noch unbekannten Scanfehler wird nicht vorsorglich die ganze Gruppe deaktiviert.

Auch die scheinbar funktionalen Optionen sind sicherheitsrelevant. Das Überspringen von Encryption kann vertrauliche Inhalte ungeschützt versenden. Ohne DKIM signing fehlt die geplante ausgehende Signatur; ohne DKIM verification wird ein eingehender Identitätsnachweis nicht bewertet. Eine Banner-Ausnahme kann Pflichttexte oder Kennzeichnungen entfernen. Solche Änderungen werden mit dem Mail- und Compliance-Owner abgestimmt.

Fehler nach Symptom eingrenzen

Die Nachricht wird weiterhin abgewiesen

Zuerst den neuen Logeintrag statt die alte Testmail beurteilen. Tatsächliche Quell-IP, Envelope-Absender, Empfänger und Reason müssen zum Scope und zur gewählten Prüfung passen. Ein Wildcard-FQDN unter Sources or hosts funktioniert nicht. Wird die Nachricht wegen RBL, IP reputation, RDNS/HELO oder einer anderen Prüfung abgewiesen, löst eine reine SPF-Ausnahme diesen separaten Grund nicht.

Die Ausnahme trifft zu viele Nachrichten

Die drei Scope-Gruppen einzeln gegen den realen Mailflow vergleichen. Häufig wurde fälschlich angenommen, Quell-IP, *@domain und Empfänger würden gemeinsam gelten. Tatsächlich vergrössert jede aktivierte ODER-Gruppe die Treffermenge. Die Ausnahme wird auf genau eine belastbare Gruppe mit möglichst wenigen Werten zurückgeführt und erneut negativ getestet.

Die E-Mail besteht die Prüfung, wird aber nicht zugestellt

Eine Ausnahme steuert Sicherheitschecks, nicht MX, interne Route, Relay, SMTP-TLS oder den Zielmailserver. Mail logs und Spool zeigen, ob die Nachricht nach dem Scan noch an DNS, Routing, Policy oder Zustellung scheitert. Bei einem TLS-Fehler werden Zertifikat, Require TLS negotiation und Gegenstelle geprüft; Encryption in der Ausnahme und ein breiterer Scope lösen diesen Fehler nicht.

Die BATV-Ausnahme greift nicht

Prüfen, ob die identische Absenderadresse in Sender addresses und Recipient addresses steht. Danach den konkreten BATV-Reason und die übrigen Scope-Felder erneut abgleichen. Eine zweite, breitere Ausnahme ist kein Ersatz für das fehlende BATV-Feld.

Betrieb und Rollback

Jede Ausnahme erhält einen Owner, einen belegten False-Positive-Grund und ein Review-Datum. Änderungen werden mit dem Audit Trail abgeglichen; Konfigurationsänderungen auf Sophos Firewall nachvollziehen beschreibt den passenden Nachweis. Der tatsächliche Mailflow bleibt zusätzlich in Mail logs und den MTA-Dateien sichtbar.

Vor der Änderung werden Name, gewählte Prüfungen, Scope-Werte und der bisherige Mail-log-Reason festgehalten. Für einen zustandserhaltenden Rollback wird die neu angelegte Ausnahme wieder gelöscht; bestehende Policies und andere Ausnahmen bleiben unangetastet. Danach werden die ursprüngliche Fehlersituation und eine zulässige Kontrollnachricht erneut getestet. Ist die Hersteller- oder DNS-Ursache noch nicht behoben, darf der Rückbau nicht stillschweigend zu produktiven Mailverlusten führen; zuerst wird ein Wartungsfenster oder eine alternative, engere Korrektur geplant.

Checkliste

• Ein reproduzierbarer False Positive und der exakte Reason liegen vor.
• Quell-IP, Envelope-Absender, Empfänger und Message-ID sind dokumentiert.
• Nur die betroffene Prüfung wird übersprungen.
• Genau eine geeignete Scope-Gruppe ist bevorzugt; zusätzliche Gruppen würden per ODER erweitern.
• Wildcard-FQDNs werden nicht als Hostausnahme verwendet.
• Eine BATV-Ausnahme enthält die Absenderadresse in beiden Adressfeldern.
• Positiv- und Negativtests sowie Vorher-/Nachher-Reasons bestätigen die beabsichtigte Wirkung.
• Übrige Spam-, Malware-, Datei-, Daten- und DKIM-Prüfungen bleiben aktiv.
• Owner, Begründung, Review-Datum und Rollback sind dokumentiert.

FAQ