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 normalerweise während SMTP abgewiesen, bevor der Mailserver sie annimmt. Bei mehreren Empfängern mit unterschiedlichen persönlichen Block-Einstellungen wird die Nachricht dagegen zuerst angenommen und danach nur für diejenigen Empfänger blockiert, die den Absender gesperrt haben. SMTP-Annahme bedeutet in diesem Sonderfall nicht Zustellung an den blockierenden Empfänger. Der konkrete Test folgt weiter unten.

Ä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

In Sophos Fusion (ehemals Sophos Central) Global Settings öffnen.
Protection and Remediation > Allow and Block > Email > Inbound Allow/Block öffnen.
Admin list und dann Add wählen.
Allow oder Block wählen und genau eine Adresse, Domain, IP-Adresse, ein unterstütztes CIDR-Netz oder einen erforderlichen Wildcard-Wert eintragen.
Eine kurze Description mit Grund und Ticket ergänzen. Die Beschreibung darf höchstens 250 Zeichen lang sein.
Bei Allow-Einträgen Enforce Message Authentication aktivieren. Die Option nicht abschalten, um eine fehlgeschlagene Absenderauthentifizierung zu umgehen.
Den Eintrag speichern und anschliessend in der Liste suchen. 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. Der globale Spoofing-Schutz ersetzt den Eintragsschalter nicht: Ist Enforce Message Authentication am Admin-Allow-Eintrag ausgeschaltet, kann dieser Eintrag trotz eingeschalteter globaler Option für gefälschte Absender missbraucht werden.

Was ein authentifizierter Allow-Treffer überspringt

Bei einem Admin-Allow-Eintrag mit erzwungener Authentifizierung muss mindestens eine Prüfung DMARC, SPF oder DKIM bestehen. Die aktivierte Option Prevention of spoofing of allowed address und die eintragsbezogenen Einstellungen bestimmen die genauere Auswertung; insbesondere kann ein DMARC-Fail bei einer Policy ungleich p=none die Authentifizierung scheitern lassen. Ein beliebiger SPF-Pass genügt deshalb nicht als pauschaler Nachweis. Bei erfolgreich authentifiziertem Allow-Treffer überspringt Sophos:

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

Ein erfolgreich authentifizierter Benutzer-Allow-Treffer überspringt nur Impersonation protection, Anti-spam, Country of origin und Language. Die abweichende Beschreibung der Benutzer-Authentifizierung wird im nächsten Abschnitt eingeordnet. 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.

Benutzer-Allow: widersprüchliche Authentifizierungsbeschreibung

Die aktuelle Beschreibung von Inbound Allow/Block und der Allow-Listen-Verarbeitung sagt, dass Benutzer-Allow-Einträge immer Message Authentication erzwingen. Die Beschreibung von User Settings stellt Prevention of spoofing of allowed address dagegen als einschaltbare Voraussetzung für die dort erläuterte Benutzer-Allow-Authentifizierung dar. Sie nennt die Option für Bestandskunden standardmässig ausgeschaltet und möglicherweise noch nicht in jedem Mandanten verfügbar. Diese Beschreibungen sind nicht eindeutig aufeinander abgestimmt. Daraus lässt sich weder ein verlässlicher Authentifizierungs-Bypass bei ausgeschalteter Option noch eine für jeden Mandanten nachgewiesene Schutzwirkung unabhängig von dieser Option ableiten.

Für den Betrieb lässt man bestehende Schutzkontrollen aktiv und plant die Aktivierung von Prevention of spoofing of allowed address, wenn die Option verfügbar ist, mit einer kontrollierten Abnahme der legitimen Versandwege. Bei fehlender Option oder unklarer Wirkung stützt man keine neue Benutzer-Allow-Ausnahme auf eine vermutete Authentifizierungslogik, sondern klärt den Mandantenzustand mit bereinigten Nachrichtendetails und den aktuellen Einstellungen. Man deaktiviert weder Enforce Message Authentication noch Spoofing-Schutz oder andere Prüfungen als Workaround.

Für die dokumentierte Prüfung mit eingeschaltetem Prevention of spoofing of allowed address gilt: Eine erlaubte Adresse darf Prüfungen nur umgehen, wenn die Authentifizierung nach der folgenden Auswertung besteht. Besteht sie nicht, ignoriert Sophos den Allow-Status und führt alle Scans aus:

Ein DMARC-Pass genügt. Schlägt DMARC bei einer Absender-Policy ungleich p=none fehl, gilt die Allow-Authentifizierung in dieser aktivierten Prüfung als fehlgeschlagen.
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:

Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block öffnen.
End user list und dann Add wählen.
Den Eintrag dem richtigen Benutzer zuordnen, Allow oder Block wählen und nur eine E-Mail-Adresse oder Domain verwenden.
Den Eintrag speichern und mit Advanced Search nach Aktion, Absender oder Benutzer kontrollieren.

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. Hat nur person1@example.com den Absender blockiert, erhält person2@example.com die Nachricht weiterhin; blockiert wird nur für person1@example.com. Im normalen Block-Fall wird vor SMTP-Annahme abgewiesen. Im gemischten Mehr-Empfänger-Fall wird dagegen zuerst angenommen und anschliessend empfängerspezifisch blockiert. Eine erfolgreiche SMTP-Annahme beweist deshalb nicht, dass die Nachricht auch beim blockierenden Empfänger zugestellt wurde.

Für einen kontrollierten Pilot verwendet man zwei eigene Testpostfächer und einen eigenen Testsender; die Beispieladressen ersetzt man durch diese freigegebenen Werte. Vorher prüft man die globale Admin list auf übersteuernde Einträge und die Benutzerlisten-Berechtigungen aus dem vorherigen Abschnitt. Der Pilot benötigt wirksame Benutzerlisten. Insbesondere wenn End-user message settings ausgeschaltet ist, kann das Abschalten von Release/Delete oder Allow/Block List bestehende Benutzerlisten umgehen; dies ist kein Workaround für ein abweichendes Testresultat.

Die ursprünglichen persönlichen Einträge dokumentieren. Den Testsender nur beim ersten Testempfänger als Block hinterlegen; beim zweiten darf kein entsprechender Block bestehen.
Eine neue, harmlose Nachricht in einem Versandvorgang an beide Empfänger senden. In Message History jede Empfängeraktion einzeln und die Testpostfächer kontrollieren: Beim ersten erwartet man den Block ohne Zustellung, beim zweiten die Zustellung, sofern keine andere Prüfung die Nachricht aufhält.
Wenn der SMTP-Zugriff ausdrücklich autorisiert ist, wird zusätzlich das Protokoll dieses Versandvorgangs gesichert und Annahme von Ablehnung unterschieden. Dabei kontrollieren, dass beide Empfänger derselben SMTP-Transaktion angehören; getrennte Transaktionen belegen den gemischten Sonderfall nicht. Das Resultat mit einem separaten Ein-Empfänger-Test an das blockierende Testpostfach, für den die normale Ablehnung vor Annahme erwartet wird, vergleichen. Keinen SMTP-Code oder Zeitpunkt aus einem blossen Zustellstatus ableiten.
Nach dem Pilot die zuvor dokumentierten persönlichen Einträge wiederherstellen und erneut kontrollieren. Bei unerwartetem Ergebnis stoppt man den Change und prüft Admin-Priorität, Benutzerzuordnung, Matching und Berechtigungen, statt eine breitere Allow-Regel anzulegen.

Ein SMTP-Test mit nur einem Empfänger bildet den gemischten Sonderfall nicht ab. Fehlt der autorisierte SMTP-Zugriff, kann man die Empfängerresultate prüfen, aber die SMTP-Phase nicht als selbst nachgewiesen dokumentieren.

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.

Den richtigen Tab Admin list oder End user list öffnen.
Die vorhandene Liste exportieren und die Datei unverändert als Backup aufbewahren.
Add > Import allow/block list wählen und die Vorlagendateien herunterladen.
Die CSV im Format der Vorlage erstellen. Aktion, Wert, Description und bei Benutzerlisten die Benutzerzuordnung zeilenweise prüfen.
Vor dem Abschluss in der Importvorschau Stichproben für Allow und Block, Sonderzeichen, Domains sowie Benutzerzuordnung kontrollieren.
Zuerst eine kleine Pilotdatei importieren. Danach die neuen Einträge suchen und ihre Wirkung testen, 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: Einen legitimen Sender mit dokumentiertem Authentifizierungsergebnis gegen die tatsächlich aktivierten globalen und eintragsbezogenen Optionen prüfen. Beim Admin-Allow bleibt Enforce Message Authentication aktiv; für den kontrollierten Benutzer-Allow-Test verwendet man die verfügbare, aktivierte Option Prevention of spoofing of allowed address. Nur die jeweils dokumentierten Prüfungen dürfen übersprungen werden; Malware scanning bleibt aktiv. Ein einzelner SPF-Pass beweist bei strengerer DMARC-Auswertung keinen erfolgreichen Allow-Treffer.
Authentifizierung fehlgeschlagen: In diesem geschützten Testzustand darf eine kontrollierte Nachricht, bei der alle drei Prüfungen fehlschlagen, den Allow-Status nicht nutzen und muss alle Scans durchlaufen. Zusätzlich den DMARC-Fail bei einer Policy ungleich p=none prüfen, wenn dieser Fall zum freigegebenen Test gehört. Ohne überprüfbaren Benutzer-Allow-Testzustand bleibt dessen Abnahme offen; zum Erzwingen einer Zustellung wird kein Schutzschalter abgeschaltet.
Block und mehrere Empfänger: Bei persönlichen Block-Listen prüft man einen betroffenen und einen nicht betroffenen Pilotempfänger in derselben Nachricht und dokumentiert beide Aktionen separat. SMTP-Annahme beziehungsweise Ablehnung prüft man nur mit autorisiertem Zugriff zusätzlich, nicht anhand der Zustellung allein.
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, eintragsbezogene Optionen und DMARC/SPF/DKIM prüfen. Bei erzwungener, fehlgeschlagener Authentifizierung ist die normale Scanfolge beabsichtigt. Für unklare Benutzer-Allow-Wirkung zusätzlich den tatsächlichen Spoofing-Schutz-Zustand dokumentieren; den beschriebenen Quellenkonflikt nicht durch Abschalten von Schutzkontrollen umgehen.
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.