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.

E-Mail-Ausnahmen per XML API einordnen

Bei Automation heisst das MTA-Ausnahmeobjekt ExceptionPolicy. Vor einer Änderung den bestehenden Namen, die übersprungenen Prüfungen und sämtliche Scope-Werte sichern. Zugang, explizite Schreiboperation, XML-Antwortauswertung und sichere Wiederholungen erklärt Sophos Firewall XML API Zugriff absichern. Die folgenden Objektangaben für SFOS 22/23 sind noch kein vollständiger Schreib-Request.

Skip-Schalter und Trefferlisten getrennt behandeln

Die Prüfungsfelder innerhalb von MalwareProtection, SpamProtection und Other wählen aus, was übersprungen wird; sie schalten nicht den allgemeinen Mail-Schutz ein. Beispielsweise ist Malware im Ausnahmeobjekt eine Skip-Auswahl, keine Aktivierung des Malware-Scanners. Die Referenz führt für die meisten dieser Felder Enable/Disable auf. Davon getrennt aktivieren die ebenfalls skalaren Schalter ForTheseSourceHost, ORTheseSenderAddresses und ORTheseRecipientAddresses, welche Scope-Gruppen verwendet werden. Ihre Werte sind ebenfalls Enable/Disable, keine IP- oder Adresslisten.

Die zugehörigen Werte liegen im dokumentierten Objektbeispiel separat und verschachtelt:

• SourceHostList/SourceHost: mehrere String-Werte für Quellhosts; der Parametertext nennt IP/FQDN.
• SenderAddressesList/Address: mehrere Absenderadressen, mit Unterstützung für E-Mail-Wildcards.
• RecipientAddresses/Address: mehrere Empfängeradressen, ebenfalls mit Unterstützung für E-Mail-Wildcards.

Die beiden Address-Felder sind gleich benannt, aber nicht austauschbar: Erst der übergeordnete Container bestimmt Absender oder Empfänger. Ein gefüllter Container ersetzt nicht die Prüfung des zugehörigen Scope-Schalters. Weitere Listeneinträge sind keine zusätzliche UND-Bedingung; jede weitere aktivierte Gruppe schafft den oben beschriebenen ODER-Trefferweg. Insbesondere würde eine zusätzliche Empfängerliste den Quellhost-Bypass auch für Nachrichten anderer Quellen öffnen. Schalter und gespeicherte Listen deshalb immer gemeinsam gegen den genehmigten Scope vergleichen. Die BATV-Sonderregel und die Einschränkung für Wildcard-FQDNs gelten weiterhin.

Name ist laut Referenz verpflichtend und höchstens 100 Zeichen lang. Optionale Felder und leere Default-Spalten belegen dagegen nicht, dass ausgelassene Werte bei einem Update erhalten bleiben oder auf Disable gesetzt werden. Aus dem breiten Herstellerbeispiel keine Produktionsausnahme kopieren: Es aktiviert mehrere Skip-Felder und alle drei Scope-Gruppen gleichzeitig.

Vor einem Schreib-Request lokale API help prüfen: Das Beispiel zeigt CheckForSPF mit Disable, während die Parametertabelle CheckforSPF mit den ungelösten Werten $EMAILPROTECTION{SMTP_CHECK_SPF_ENABLE} und $EMAILPROTECTION{SMTP_CHECK_SPF_DISABLE} nennt. RBL und RDNSAndHelo stehen in der Tabelle, fehlen aber im Objektbeispiel; die Banner-Auswahl ist dort als BanerAddition geschrieben. Diese Schreibweisen nicht eigenmächtig korrigieren, Tokenwerte nicht erraten und aus fehlenden Feldern keine XML-Platzierung ableiten. Bleiben exakte Tags, zulässige Werte oder die konkrete Operation für den installierten Build ungeklärt, den Schreibvorgang stoppen und mit Support klären; deshalb enthält dieser Abschnitt keine ausführbare XML-Schreibvorlage.

Antworten unterscheiden und gespeicherten Zustand kontrollieren

Die Zuordnung der Referenz muss zusammen mit der Operation gelesen werden. Die Werte sind XML-Statuscodes, keine HTTP-Statuscodes; Message.* sind ungelöste Dokumentationssymbole, nicht nachgewiesene Laufzeittexte oder allein aus dem Namen ableitbare Fehlerursachen.

Add und Update bezeichnen hier Exception Policy Add beziehungsweise Exception Policy Update. Obwohl die Seite auch Exception Policy Delete im Titel nennt, enthält ihre Statustabelle keine Delete-Zuordnung. Weder einen Add-/Update-Erfolgscode auf Delete übertragen noch aus einem Symbolnamen eine konkrete Validierungsregel erfinden.

Nach jedem Schreibversuch, auch bei 200, die Ausnahme unter Email > Policies and exceptions erneut öffnen und den tatsächlich gespeicherten Namen, sämtliche Skip-Auswahlen, alle drei Scope-Schalter und jede Host-/Adressliste mit dem Sollzustand vergleichen. Beim Löschen das Fehlen genau des vorgesehenen Objekts und den unveränderten Zustand anderer Ausnahmen kontrollieren. Audit Trail und vollständige, bereinigte API-Antwort sichern. Erst danach bestätigen die oben beschriebenen Positiv-/Negativtests die Wirkung im Mailflow.

Bei 502, Fehler, Timeout oder unklarer Antwort vor jedem Retry den tatsächlichen Zustand nachlesen: Ein vorhandener Name kann bereits eine andere Ausnahme bezeichnen oder aus dem ersten Versuch stammen. Nicht mit neuem Namen duplizieren, keine zusätzlichen ODER-Gruppen ergänzen und keine weiteren Prüfungen überspringen, nur um den Fehler zu umgehen. Für 541–545 Operation, Code, tatsächlichen Antworttext und gespeicherte Konfiguration zusammen prüfen; eine ungelöste Symbolbezeichnung rechtfertigt keinen geratenen Reparatur-Request.

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