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, und der Scope enthält die kleinste belastbare Kombination aus Quell-IP, Absender und Empfänger. 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. Sources or hosts, Sender addresses und Recipient addresses so eng wie möglich festlegen.
5. Eine gleichartige Nachricht positiv und mindestens zwei Varianten ausserhalb des Scopes negativ testen.
6. In Mail logs und MTA-Logs bestätigen, dass nur die vorgesehene Prüfung übersprungen wurde und die übrigen Schutzfunktionen weiter greifen.
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.

Der allgemeine MTA-Pfad bleibt unter Mail Protection im MTA Mode einrichten dokumentiert. Für den transparenten Proxy gilt Mail Protection im Legacy Mode einrichten. Eine Ausnahme ersetzt in keinem Modus Routing, Relay, Firewall-Regel oder eine passende Scan-Policy.

Den Scope vor dem Speichern verstehen

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 das veröffentlichte und im eigenen Mailflow tatsächlich beobachtete Quellobjekt. Ändert der Anbieter seine Netze, wird die Ausnahme nicht blind auf Any erweitert, sondern erneut gegen Logs und Herstellerangaben geprüft.

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 Domain-Wildcard erfasst alle Absender beziehungsweise Empfänger dieser Domain und braucht daher einen engeren Gegenanker, etwa eine bestätigte Quell-IP und einen Pilotempfänger.

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. 203.0.113.25 ist eine Dokumentationsadresse und wird durch die tatsächlich im SMTP-Log beobachtete öffentliche Quell-IP ersetzt. partner.example und pilot@example.com sind ebenfalls Musterwerte.

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. Unter Sender addresses *@partner.example und unter Recipient addresses zunächst nur pilot@example.com setzen.
6. Speichern und die Ausnahme noch nicht auf weitere Empfänger ausweiten.

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 an das Pilotpostfach. Sie muss den vorgesehenen Mailflow durchlaufen und darf nicht mehr am bestätigten SPF-Grund scheitern. Mail logs, smtpd_main.log und bei Ablehnungen smtpd_reject.log werden mit Zeitstempel, Absender, Empfänger und Message-ID korreliert. Die Logzuordnung erklärt Sophos Firewall Services und Logs.

Danach folgen zwei Negativtests. Eine Nachricht desselben Absenders von einer anderen Quell-IP und eine Nachricht der bestätigten Quell-IP an einen anderen Empfänger dürfen nicht dieselbe Ausnahme erhalten. Zusätzlich bleibt eine harmlose Testdatei dem normalen Malware- und File-Protection-Pfad unterstellt. Es wird keine echte Malware verwendet.

Eine erfolgreiche Zustellung allein beweist den Scope nicht. Entscheidend ist, dass die erwartete Nachricht zugestellt wird, die Varianten ausserhalb des Scopes weiterhin normal geprüft werden und keine zweite Sicherheitsprüfung unbeabsichtigt übersprungen wurde.

Riskante Ausnahmen erkennen

Eine breite Domain-Wildcard zusammen mit einem grossen Quellnetz kann den Schutz für einen erheblichen Teil des Mailflows entfernen. Besonders Ausnahmen für Malware, Zero-Day Protection, Data protection und File protection benötigen eine dokumentierte Risikoentscheidung und einen sehr kleinen Pilotbereich. 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-Ebenen einzeln gegen den realen Mailflow vergleichen. Häufig ist *@domain ohne enge Quell-IP oder mit zu vielen Empfängern der breite Faktor. Die Ausnahme wird nicht durch weitere übersprungene Prüfungen korrigiert, sondern auf die kleinste bestätigte Kombination 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, TLS oder den Zielmailserver. Mail logs und Spool zeigen, ob die Nachricht nach dem Scan noch an DNS, Routing, Policy oder Zustellung scheitert. Die Ausnahme wird nicht erweitert, wenn der Fehler nach dem Sicherheitscheck liegt.

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.

Für den Rollback wird die Ausnahme entfernt oder auf den dokumentierten Vorzustand zurückgesetzt. 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.
• Sources or hosts, Sender und Recipient bilden den kleinsten sinnvollen Scope.
• Wildcard-FQDNs werden nicht als Hostausnahme verwendet.
• Eine BATV-Ausnahme enthält die Absenderadresse in beiden Adressfeldern.
• Positiv- und Negativtests bestätigen Match und Nicht-Match.
• Übrige Spam-, Malware-, Datei-, Daten- und DKIM-Prüfungen bleiben aktiv.
• Owner, Begründung, Review-Datum und Rollback sind dokumentiert.

FAQ