Sophos Email: Inbound Allow/Block-Ausnahmen sicher verwalten

Mit Inbound Allow/Block steuert man, welche Absender Sophos Email bei eingehenden Nachrichten erlaubt oder blockiert. Die Admin-Liste gilt global für alle geschützten Postfächer; persönliche Benutzerlisten gelten für den jeweiligen Benutzer. Bei einem Konflikt hat die Admin list Vorrang.

Sicherer Schnellweg: Unter Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block zuerst die bestehende Liste exportieren. Danach in Admin list den kleinstmöglichen Absenderwert hinzufügen, bei einem Allow-Eintrag Enforce Message Authentication aktivieren, Grund und Owner dokumentieren und mit einer passenden sowie einer nicht passenden Testmail prüfen. Breite Domains, Wildcards und Netze sind kein Ersatz für die Analyse eines False Positives.

Wichtig: Ein Allow-Eintrag schaltet den Schutz nicht vollständig aus. Bei einem passenden und ausreichend authentifizierten Absender überspringt Sophos nur die unten dokumentierten Prüfungen; Malware scanning bleibt aktiv. Ohne erzwungene Authentifizierung kann eine gefälschte Nachricht mit einer erlaubten Absenderadresse die dokumentierten Prüfungen umgehen und den Posteingang erreichen. Die URL Allow List für Time of Click ist eine separate Funktion und wird hier nicht gepflegt.

Geltungsbereich und Matching verstehen

Die Listen gelten nur für eingehende Nachrichten. Für Adressen und Domains vergleicht Sophos sowohl den SMTP-Envelope-Sender als auch die Adresse im sichtbaren From-Header. Passt eine der beiden Adressen, wird die konfigurierte Allow- oder Block-Aktion ausgelöst. Deshalb muss man vor einer Ausnahme beide Werte in den Roh-Headern beziehungsweise Nachrichtendetails prüfen.

Die Admin-Liste unterstützt:

einzelne E-Mail-Adressen wie billing@example.com;
Domains wie example.com;
IP-Adressen wie die Dokumentationsadresse 192.0.2.25;
IPv4-Netze mit Präfixen von /16 bis /32, beispielsweise 192.0.2.0/24;
Wildcards am Anfang, in der Mitte oder am Ende einer Adresse oder Domain, etwa *.example.com, name*@example.com, name@example*.com oder *.example;
Wildcards für ganze Top-Level-Domains, beispielsweise *.example als sichere Dokumentationsform statt einer produktiven TLD.

Die Benutzerliste unterstützt dagegen nur E-Mail-Adressen und Domains, keine IP-Adressen und keine Wildcards. Die dokumentierte Obergrenze für alle Listen beträgt 100'000 Einträge. Pro Benutzer können höchstens 500 Einträge zur Allow- oder Block-Liste hinzugefügt werden; Einträge aus Smart Banners können diese benutzerbezogene Grenze überschreiten.

Ein blockierter Sender oder eine blockierte Client-IP wird ohne weitere Prüfung verworfen. Nachrichten von Adressen auf der Block-Liste werden während SMTP abgewiesen; der Sonderfall unterschiedlicher Benutzerlisten bei mehreren Empfängern wird weiter unten erklärt.

Änderung vorbereiten und eng begrenzen

Vor jeder Änderung hält man fest:

Ticket, Geschäftsgrund, Owner und ein Ablauf- oder Reviewdatum;
exakten Listentyp: Admin list oder End user list;
Aktion Allow oder Block und den kleinstmöglichen Wert;
betroffene Benutzer bei einer End-user-Regel;
aktuellen Export als Backup und Anzahl der Einträge;
Testsender, Testempfänger sowie erwartete Matching- und Non-Matching-Ergebnisse.

Sophos stellt kein hier belegtes automatisches Ablaufdatum pro Eintrag bereit. Das Ablaufdatum ist deshalb ein Betriebsprozess: Ausnahmen werden im Change-System terminiert, regelmässig geprüft und nach Wegfall des Grundes gelöscht. Eine Beschreibung nennt knapp Grund und Ticket, aber keine vertraulichen Daten.

Admin-Liste konfigurieren

Klicke in Sophos Fusion (ehemals Sophos Central) auf Global Settings.
Öffne Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Wähle Admin list und klicke auf Add.
Wähle Allow oder Block und trage genau eine Adresse, Domain, IP-Adresse, ein unterstütztes CIDR-Netz oder einen erforderlichen Wildcard-Wert ein.
Ergänze eine kurze Description mit Grund und Ticket. Die Beschreibung darf höchstens 250 Zeichen lang sein.
Aktiviere bei Allow-Einträgen Enforce Message Authentication, sofern nicht ein belegter und genehmigter Sonderfall dagegen spricht.
Speichere den Eintrag und suche ihn anschliessend in der Liste. Advanced Search kann nach Allow/Block, Message Authentication sowie Absenderadresse oder Domain filtern.

Existiert derselbe Wert bereits, verwendet man Override duplicates nur nach Vergleich des vorhandenen Eintrags. Sophos verwendet danach die zuletzt gewählte Einstellung. Mehrere markierte Admin-Einträge lassen sich gemeinsam beschreiben; bei Allow-Einträgen kann dabei auch Message Authentication aktiviert werden. Eine Sammeländerung darf jedoch nicht unbemerkt unterschiedliche Gründe oder Owner zusammenführen.

Die eintragsbezogenen Einstellungen unter Enforce Message Authentication spiegeln die Authentifizierungsoptionen aus User Settings. Pro Allow-Eintrag kann man einzelne Optionen beibehalten oder übersteuern, darunter SPF-Prüfungen und Envelope-Domains. Deshalb vergleicht und dokumentiert man diese Werte ebenfalls, statt nur den Hauptschalter zu aktivieren.

Was ein authentifizierter Allow-Treffer überspringt

Bei einem Admin-Allow-Eintrag mit erzwungener Authentifizierung muss mindestens eine Prüfung DMARC, SPF oder DKIM bestehen. Dann überspringt Sophos für diesen Treffer:

Header anomalies;
Impersonation protection;
Anti-spam;
BATV (Bounce Address Tag Validation);
Country of origin;
Language;
Data control.

Bei einem Benutzer-Allow-Eintrag ist Message Authentication nicht bedingungslos erzwungen: Die Authentifizierungsanforderung für den Scan-Bypass greift erst, wenn die globale Option Prevention of spoofing of allowed address aktiviert ist. Ein erfolgreich authentifizierter Treffer überspringt dort nur Impersonation protection, Anti-spam, Country of origin und Language. In beiden Fällen bleibt der Malware-Scan aktiv. Welche Inhalts- und URL-Prüfungen unabhängig davon greifen, erklärt die Anleitung zum Malware-, Anhang- und URL-Schutz.

Die globale Option Prevention of spoofing of allowed address unter User Settings ist möglicherweise noch nicht für jeden Mandanten verfügbar. Bei Bestandskunden ist sie standardmässig ausgeschaltet, damit die geänderte Allow-Listen-Logik den Mailflow nicht unerwartet stört; im ausgeschalteten Zustand darf man daher nicht annehmen, dass Benutzer-Allow-Einträge gegen gefälschte erlaubte Adressen authentifiziert werden. Ist sie eingeschaltet, darf eine erlaubte Adresse Prüfungen nur umgehen, wenn mindestens eine DMARC-, SPF- oder DKIM-Prüfung für die ausgerichtete Domain besteht. Besteht keine davon, ignoriert Sophos den Allow-Status und führt alle Scans aus. Für die bereits oben genannten Prüfverfahren gilt im Detail:

Ein DMARC-Pass genügt. Schlägt DMARC bei einer Absender-Policy ungleich p=none fehl, gilt die Allow-Authentifizierung nur dann als fehlgeschlagen, wenn der Spoofing-Schutz in User Settings eingeschaltet ist.
Bei p=none oder wenn DMARC nicht ausführbar ist, liefern SPF und DKIM die Entscheidung.
SPF prüft die Envelope-Domain der Nachricht.
DKIM muss für die Domain des Allow-Eintrags bestehen.
SPF check for non-aligned address kann einen SPF-Pass akzeptieren, obwohl die Envelope-Domain der Absenderadresse nicht mit der erlaubten Adresse ausgerichtet ist. Sophos empfiehlt diese Option nicht: Eine gefälschte Header-From-Adresse kann dadurch einem Benutzer-Allow-Eintrag entsprechen und das Spoofing-Risiko erhöhen.
SPF check for envelope domain lässt Sophos für jede vom Benutzer erlaubte Header-Adresse die Envelope-Domain lesen, damit SPF auf die Envelope-Domain der Nachricht angewendet wird. Diese Option verwendet man nur, wenn der belegte Ausnahmefall einer nicht ausgerichteten SPF-Prüfung erforderlich ist.

Dieser nicht ausgerichtete Ausnahmeweg verbreitert das Vertrauen und ist keine Standardlösung. Zuerst korrigiert man SPF, DKIM oder DMARC beim legitimen Versanddienst. Die Zusammenhänge und die Kontrolle der Ergebnisse sind im Artikel zur Absenderauthentifizierung beschrieben.

Benutzerlisten administrieren

User Settings kann im EMS-Modus nicht konfiguriert werden. Ausserhalb dieses Modus können Benutzer ihre persönliche Liste im Sophos Central Self Service Portal führen, sofern Release/Delete und Allow/Block List unter Global Settings > Products and Services > Email > User Settings passend freigegeben sind. Dabei gelten zwei sicherheitsrelevante Abhängigkeiten:

Ist End-user message settings eingeschaltet und sind auf den Smart Banners die Links Allow sender und Block sender konfiguriert, muss Allow/Block List eingeschaltet bleiben.
Ist End-user message settings ausgeschaltet und wird entweder Release/Delete oder Allow/Block List ausgeschaltet, umgeht Sophos die bereits vorhandenen Benutzer-Allow-/Block-Listen.

Der Administrator kann dieselben Listen zentral einsehen und ändern:

Öffne Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Wähle End user list und klicke auf Add.
Ordne den Eintrag dem richtigen Benutzer zu, wähle Allow oder Block und verwende nur eine E-Mail-Adresse oder Domain.
Speichere und kontrolliere den Eintrag mit Advanced Search nach Aktion, Absender oder Benutzer.

Auch hier ersetzt Override duplicates den vorhandenen gleichen Wert durch die jüngste Auswahl. Vor einer Änderung prüft man immer die globale Admin-Liste, denn sie übersteuert einen widersprechenden Benutzereintrag. Die Freigabe der Benutzeraktionen und Quarantäneberechtigungen behandelt der Quarantäne-Self-Service.

Mehrere Empfänger korrekt testen

Bei einer Nachricht an mehrere Empfänger können persönliche Listen für denselben Absender voneinander abweichen. Die offiziellen Quellen stimmen beim empfängerspezifischen Ergebnis überein, nennen aber unterschiedliche Verarbeitungszeitpunkte: Eine Quelle sagt „nach dem SMTP-Kommando“, die andere „erst nach der Zustellung“. Hat nur person1@example.com den Absender blockiert, erhält person2@example.com die Nachricht weiterhin; blockiert wird nur für person1@example.com. Unabhängig vom strittigen Zeitpunkt testet man beide Empfänger in derselben Nachricht und prüft das Ergebnis je Empfänger in Message History. Ein SMTP-Test mit nur einem Empfänger bildet diesen Sonderfall nicht ab.

CSV sicher exportieren und importieren

Vor einem Massenimport exportiert man die ausgewählten Einträge oder die gesamte betroffene Liste als CSV. Dieser Export ist Backup und Vergleichsbasis. Er enthält zusätzliche Spalten und ist daher nicht unverändert als Importdatei geeignet. Für einen Import lädt man in Sophos Fusion die aktuelle Vorlage herunter und übernimmt exakt deren Format und Spalten; zusätzliche Exportspalten werden entfernt. Eigene, vermutete Spaltennamen sollte man nicht erfinden.

Öffne den richtigen Tab Admin list oder End user list.
Exportiere die vorhandene Liste und bewahre die Datei unverändert als Backup auf.
Wähle Add > Import allow/block list und lade die Vorlagendateien herunter.
Erstelle die CSV im Format der Vorlage. Prüfe Aktion, Wert, Description und bei Benutzerlisten die Benutzerzuordnung zeilenweise.
Kontrolliere vor dem Abschluss in der Importvorschau Stichproben für Allow und Block, Sonderzeichen, Domains sowie Benutzerzuordnung.
Importiere zuerst eine kleine Pilotdatei. Suche danach die neuen Einträge und teste ihre Wirkung, bevor weitere Dateien folgen.

Warnung: Replace existing list with this import entfernt beim Hinzufügen der CSV dauerhaft alle aktuellen Einträge der betroffenen Importliste. Diese Option nur mit freigegebenem Vollersatz, geprüftem Backup und erfolgreichem Pilot verwenden. Für eine Ergänzung darf sie nicht gewählt werden.

Vollersatz absichern und zurückrollen

Vor einem Vollersatz muss ein benannter Freigabeverantwortlicher den exakten Listentab, die unveränderte vollständige Sicherung, deren aufgezeichnete Zeilenzahl, die vorbereitete Wiederherstellungsdatei, das Pilotresultat und das Wartungsfenster bestätigen. Der Pilot verwendet dieselbe aktuelle Sophos-Vorlage in einem nicht produktiven Mandanten oder einer getrennten kontrollierten Testliste. Eine unvollständige Pilotdatei darf niemals mit Replace existing list with this import gegen die produktive Liste ausgeführt werden.

Fehlen nach dem Vollersatz Einträge oder sind sie falsch, stoppt man alle weiteren Importe und korrigiert nicht zeilenweise. Nach Incident- beziehungsweise Change-Freigabe überträgt man die zuvor exportierte, bekannte gute vollständige Liste in eine neue Datei nach der aktuellen Sophos-Vorlage; der unveränderte Export bleibt erhalten. Vor dem Import vergleicht man Zeilenzahl und repräsentative Allow- und Block-Einträge, bei Benutzerlisten zusätzlich Benutzerzuordnungen, sowie Stichproben vom Anfang und Ende. Danach importiert man diese vollständige Wiederherstellungsdatei im richtigen Tab kontrolliert mit Replace existing list with this import. Abschliessend müssen die Anzahl der Einträge dem Wert vor der Änderung entsprechen, dieselben Stichproben vorhanden sein und Matching-, Non-Matching- sowie Authentifizierungstests den bekannten guten Zustand bestätigen. Bei einer Abweichung bleibt der Change gestoppt und wird eskaliert; Malware scanning und die übrigen Schutzkontrollen bleiben aktiv.

Für den Import sind folgende belegte Grenzen getrennt zu beachten:

höchstens 500'000 Einträge in der erstellten Importliste;
höchstens 500 Einträge je Benutzer;
höchstens 1 MB pro CSV-Datei;
höchstens 250 Zeichen pro Description; längere Texte werden beim Import abgeschnitten.

Grössere Dateien teilt man auf und lädt sie stufenweise hoch. Ein Tabellenprogramm kann Trennzeichen, führende Zeichen oder die Zeichenkodierung verändern. Bei beschädigten Umlauten oder verschobenen Spalten bricht man den Import ab, erstellt die Datei erneut aus der unveränderten Sophos-Vorlage und kontrolliert die Vorschau. Man rät kein Encoding und korrigiert nicht direkt im Backup.

Wirkung abnehmen

Nach einer Einzeländerung oder jedem Import führt man einen kleinen, dokumentierten Test durch:

Matching: Eine neue Nachricht mit exakt passendem Envelope-Sender oder From-Header muss die erwartete Allow- oder Block-Wirkung zeigen.
Non-Matching: Eine ähnliche Adresse oder benachbarte Domain ausserhalb des Eintrags muss normal geprüft werden. Das zeigt besonders bei Wildcards und CIDR, ob der Scope zu breit ist.
Authentifizierung bestanden: Ein erlaubter legitimer Sender mit dokumentiertem DMARC-, SPF- oder DKIM-Pass muss nur die dokumentierten Prüfungen überspringen; Malware scanning bleibt aktiv.
Authentifizierung fehlgeschlagen: Eine kontrollierte Nachricht, bei der alle drei Prüfungen fehlschlagen, darf den Allow-Status nicht nutzen und muss alle Scans durchlaufen.
Block und mehrere Empfänger: Bei persönlichen Block-Listen prüft man einen betroffenen und einen nicht betroffenen Pilotempfänger in derselben Nachricht.
CSV: Anzahl, Aktion, Wert, Description und Benutzerzuordnung mit Quelldatei und Backup vergleichen. Zusätzlich Stichproben am Anfang und Ende der Liste prüfen.

In Message History dokumentiert man Zeitpunkt, Envelope-Sender, sichtbares From, Client-IP, Empfänger, Authentifizierungsergebnisse und Aktion. Eine zugestellte Mail allein beweist nicht, dass der Allow-Eintrag gegriffen hat; sie könnte auch den normalen Scanweg bestanden haben.

Fehler eingrenzen und Ausnahmen pflegen

Allow greift nicht: Envelope-Sender und From mit dem Eintrag vergleichen, danach Admin-Priorität und DMARC/SPF/DKIM prüfen. Schlägt alles fehl, ist die normale Scanfolge beabsichtigt.
Block greift nur bei einzelnen Empfängern: Benutzerzuordnungen und den dokumentierten Mehr-Empfänger-Fall prüfen. Eine widersprechende Admin-Regel hat Vorrang.
Wildcard oder CIDR greift falsch: Syntax und Präfix kontrollieren. Nur /16 bis /32 ist dokumentiert; Benutzerlisten unterstützen weder IP/CIDR noch Wildcards. Bis zur Klärung den breiten Eintrag entfernen.
Import fehlt oder ist falsch: Richtigen Listentab, Dateigrösse, Benutzerlimit, Vorlagenformat, zusätzliche Exportspalten, abgeschnittene Beschreibungen und sichtbare Zeichenkodierung prüfen. Nicht mit Replace existing list with this import wiederholen, bevor Ursache und Backup geklärt sind.
Legitime Mail bleibt blockiert: Erst globale Admin-Liste, persönliche Liste, Envelope-/Header-Adresse und Client-IP vergleichen. Danach Authentifizierung und Message History auswerten; keinen zweiten breiteren Allow-Eintrag als Abkürzung anlegen.

Mindestens quartalsweise und bei jedem Owner-Wechsel vergleicht man Liste, Ticket und Geschäftsbedarf. Abgelaufene, ownerlose, doppelte oder zu breite Ausnahmen werden nach Freigabe gelöscht und mit Matching sowie Non-Matching erneut geprüft. Bleibt die Ursache unklar, setzt man den neuen Eintrag zurück und eskaliert mit Message-ID, Zeitstempel, Listenexport, betroffener Zeile und Authentifizierungsergebnissen – ohne vertrauliche Nachrichteninhalte oder vollständige produktive Listen offenzulegen.