Sophos Firewall Mail Protection im Legacy Mode einrichten

Im Legacy Mode arbeitet Sophos Firewall als transparenter Mail-Proxy. Der interne Mailserver bleibt der eigentliche SMTP-Endpunkt; die Firewall leitet den Verkehr über bestehende Firewall- und NAT-Regeln weiter und prüft ihn dabei auf Spam, Malware, Dateitypen oder Data-Control-Treffer.

Das unterscheidet den Legacy Mode grundlegend vom MTA Mode. Die Firewall wird nicht zum eigenen Mail Transfer Agent, übernimmt keine Mailzustellung über geschützte Domains und bietet für diesen Pfad keinen MTA-Mail-Spool. Ein grüner SMTP-Porttest beweist deshalb weder den Proxy-Scan noch die richtige Policy.

⚠️ Der Wechsel des SMTP Deployment Mode ist eine globale Änderung am Mail-Schutzpfad. Vor dem Umschalten müssen Backup, vorhandene Policies, Firewall- und NAT-Regeln sowie ein getesteter Rückweg dokumentiert sein. Ein MTA-Problem ist kein Grund, ungeplant auf Legacy Mode umzuschalten.

Legacy Mode in neun Schritten

1. Bestehenden eingehenden und ausgehenden SMTP-Pfad mit IP-Adressen, Ports, NAT und Firewall Rule IDs dokumentieren.
2. Prüfen, ob transparenter Proxy-Betrieb wirklich besser passt als der MTA Mode.
3. Konfigurationsbackup und unabhängigen Managementzugang sichern.
4. Unter Email > General settings auf Switch to legacy mode wechseln.
5. SMTP-Hostname, Grössenlimits, Oversize-Aktion, IP Reputation, DoS-Grenzen, Ports und TLS-Verhalten festlegen.
6. Nur die benötigten SMTP-Malware- und SMTP-Spam-Policies erstellen beziehungsweise deren Reihenfolge prüfen.
7. Eingehende DNAT- und ausgehende SNAT-Pfade eng auf den realen Mailserver begrenzen.
8. In den tatsächlich getroffenen Firewall-Regeln Scan SMTP beziehungsweise Scan SMTPS aktivieren.
9. Eingehende und ausgehende Testmails mit Rule ID, Policy-Ergebnis, Zertifikat und Legacy-Proxy-Logs abnehmen.

Legacy Mode oder MTA Mode wählen

Legacy Mode passt vor allem zu Bestandsumgebungen, in denen der interne Mailserver bereits direkt über NAT veröffentlicht ist und dieser Pfad beibehalten werden soll. SFOS sitzt dabei transparent zwischen Gegenstelle und Server. MX-Ziel, SMTP-Annahme und Zustelllogik bleiben beim vorhandenen Mailserverdesign.

MTA Mode ist dagegen die passendere Wahl, wenn die Firewall E-Mails selbst annehmen, nach geschützten Domains routen, relayen und bei temporären Zustellfehlern im Spool halten soll. Mail logs und Mail spool gehören ausdrücklich zu diesem Betriebsmodell. Der vollständige Aufbau steht unter Mail Protection im MTA Mode einrichten.

Bei XGS 87/87w und XGS 88/88w ist MTA Mode laut SFOS-22-Hilfe nicht verfügbar. Das macht Legacy Mode aber nicht automatisch zu einer guten Cloud-Mail-Architektur. Microsoft 365, Google Workspace und moderne gehostete Dienste verwenden eigene TLS-, Authentifizierungs- und Anti-Abuse-Vorgaben. Vor einem transparenten Proxy muss deren Unterstützung geklärt werden.

Kurz gesagt: MTA Mode besitzt einen eigenen Mailflow. Legacy Mode schützt einen bereits funktionierenden SMTP-Pfad. Wer diese beiden Modelle vermischt, sucht später im falschen Log, am falschen NAT-Ziel oder in einem nicht vorhandenen Spool.

Beispieltopologie und Rückfallweg

Das folgende Beispiel verwendet Dokumentationswerte und wird vor der Umsetzung an die reale Umgebung angepasst:

• interner Mailserver 10.20.30.25 in der Zone DMZ
• öffentliche SMTP-Adresse 192.0.2.25 am WAN-Pfad
• eingehender SMTP-Dienst TCP 25
• optional SMTPS auf TCP 465, nur wenn Gegenstellen und Server diese Variante tatsächlich verwenden
• Firewall-Regeln SMTP_In_Legacy und SMTP_Out_Legacy

192.0.2.25 gehört zum TEST-NET-Bereich und ist kein produktiver Wert. Vor der Änderung werden ein externer Eingangstest und ein ausgehender Test mit Zeitstempel durchgeführt. Die aktuell getroffenen Rule IDs, die öffentliche Quelladresse des ausgehenden Servers und die Zertifikatskette werden gesichert.

Der Rückfallweg besteht nicht nur aus dem Zurückschalten des Modus. Auch neue Scanoptionen, Policy-Reihenfolge, DNAT, reflexive oder manuelle SNAT-Regeln und temporäre Tests müssen auf den dokumentierten Vorzustand zurückgesetzt werden können.

Globale Mail-Einstellungen festlegen

Wo MTA Mode verfügbar ist, nennt die Hilfe ihn als Standardmodus. Unter Email > General settings mit Switch to legacy mode gezielt umstellen; vorher den dokumentierten Rückfallweg sichern. Ein Moduswechsel allein erstellt keinen geprüften Legacy-Mailpfad.

Unter Email > General settings gilt SMTP hostname nur für systemgenerierte Benachrichtigungen in HELO- und SMTP-Banner-Strings; der Default lautet SMTP. Der Wert ersetzt weder den produktiven FQDN des Mailservers noch dessen öffentliches DNS. Wird er geändert, muss deshalb eine SFOS-Benachrichtigung und nicht nur eine normale Servermail geprüft werden.

XML-API-Prüfung: Die SFOS-23-Dokumentation führt für Email Configuration den Operationsstatus 506 mit Message.AVGeneralConfInvalidSmtpNtfyHostname auf. Das ist ein nicht aufgelöster Meldungsschlüssel, kein englischer Fehlertext und kein HTTP-Statuscode. Erscheint dieser Status in der tatsächlichen XML-API-Antwort, den übermittelten Benachrichtigungs-Hostnamen, die Operationsantwort und die gespeicherte Konfiguration prüfen, bevor die Änderung als erfolgreich gilt. Aus dem Schlüssel lassen sich keine konkreten Validierungsregeln ableiten. Der zusätzliche Dokumentationseintrag belegt weder eine Einführung des Verhaltens mit SFOS 23 noch eine Gültigkeit für REST.

Grössenlimit, Oversize-Aktion und DoS-Schutz

Unter Email > General settings > SMTP settings legt Don’t scan emails greater than die maximale Nachrichtengrösse für den Scan fest. Der Wert 0 bedeutet im SMTP-Pfad laut SFOS-22-Hilfe 51,200 KB, nicht unbegrenzt. Für grössere Nachrichten stehen Accept, Reject und Drop zur Verfügung.

Accept stellt eine zu grosse Nachricht ohne Scan zu. Reject lehnt sie ab und informiert den Absender, Drop verwirft sie ohne Benachrichtigung. Diese Wahl ist eine bewusste Risiko- und Betriebsentscheidung. Ein ungeprüftes Drop erschwert die Fehlersuche; ein ungeprüftes Accept erzeugt eine dokumentationspflichtige Scan-Lücke.

Verify sender’s IP reputation prüft die Absender-IP vor den Spamkriterien der SMTP-Policy und weist E-Mails von IP-Adressen mit schlechter Reputation ab. Die sechs SMTP-DoS-Felder haben in SFOS 22 folgende zulässige Bereiche:

• Maximum connections: 1 bis 20000 Verbindungen zum Mailserver
• Maximum connections/host: 1 bis 10000 Verbindungen eines Hosts
• Maximum emails/connection: 1 bis 1000 Nachrichten pro Verbindung
• Maximum recipients/email: 1 bis 256 Empfänger pro Nachricht
• Emails rate: 1 bis 20000 Nachrichten eines Hosts pro Minute
• Connections rate: 1 bis 20000 Verbindungen eines Hosts pro Sekunde

Zulässig bedeutet nicht automatisch passend. Produktive Grenzwerte werden aus dem realen Mailvolumen und einer Baseline abgeleitet, damit legitime Versandspitzen nicht wie ein DoS behandelt werden.

Bypass spam check for SMTP/S authenticated connections überspringt den Spamcheck global für Verbindungen, die der Mailserver als authentifiziert meldet. Das ist nur vertretbar, wenn Authentisierung, erlaubte Quellen und Missbrauchsschutz dieses Pfads geprüft sind. Ein erfolgreicher Login ersetzt weder Malware-Scan noch einen Negativtest mit einer nicht authentifizierten Verbindung. Unter Spam check exceptions eingetragene Domains sind ebenfalls ein globaler Bypass und werden nicht als schneller Ersatz für eine eng begrenzte Ausnahme verwendet.

Der globale E-Mail-Banner bietet Inline, no conversion, MIME part und Off. Inline, no conversion hängt den Text direkt an ausgehende Nachrichten an; MIME part fügt ihn als separaten MIME-Teil hinzu. Off fügt keinen Banner hinzu. Im Feld Email banner wird nur Text eingetragen, beispielsweise ein kurzer Vertraulichkeitshinweis. Der Banner setzt SMTP- beziehungsweise SMTPS-Scanning in der getroffenen Firewall-Regel voraus. Mit einer Text- und einer HTML-Testmail beim Empfänger kontrollieren, ob Inhalt, MIME-Struktur und Darstellung wie vorgesehen erhalten bleiben. Da die Änderung am Body eine bereits vorhandene DKIM-Signatur brechen kann, wird der reale ausgehende Pfad zusätzlich mit Headerprüfung abgenommen.

POP/IMAP und Ports getrennt planen

POP/IMAP besitzt unter POP and IMAP TLS configuration eine eigene TLS certificate-Auswahl für die CA. Allow invalid certificate deaktiviert lassen, um ungültige Serverzertifikate abzuweisen; Disable legacy TLS protocols sperrt hier ebenfalls nur Protokolle vor TLS 1.1. SMTP-Einstellungen ersetzen diese Konfiguration nicht. Der vollständige Abrufpfad steht unter POP/IMAP-E-Mail-Scanning; CA- und Zertifikatsverwaltung unter Zertifikate verwalten.

Legacy Mode umfasst auch transparentes POP3/S- und IMAP/S-Scanning. Unter POP/S and IMAP/S settings bedeutet 0 bei Don’t scan emails greater than 10,240 KB. Die Recipient headers bestimmen, in welchen Headern SFOS Empfänger für POP/IMAP-Policies sucht; die Defaults sind Delivered-To, Received und X-RCPT-TO. Sie werden nur geändert, wenn ein aufgezeichneter Nachrichtenheader des eingesetzten Servers dies begründet.

Die dokumentierten Standardports sind SMTP 25, SMTPS 465, POP3 mit STARTTLS 110, POP3S 995, IMAP mit STARTTLS 143 und IMAPS 993. SFOS kann E-Mail-Scanning auch für andere Ports konfigurieren; Port 587 wird in der Hilfe ausdrücklich genannt. Ein alternativer Port gehört sowohl als Service in die passende Firewall-Regel als auch zum tatsächlich aktivierten Scanprotokoll. Ein Portwechsel allein macht aus implizitem TLS kein STARTTLS und umgekehrt.

Eine POP-IMAP scan Policy kann Absender- und Empfängergruppen mit Kriterien wie Eingangsklassifizierung, Quell-IP, Nachrichtengrösse oder Header verknüpfen. Als Aktionen stehen hier nur Accept und Prefix subject zur Verfügung. Die Policy aktiviert den Proxy nicht selbst: In der passenden Firewall-Regel muss unter Scan email content zusätzlich das tatsächlich verwendete POP3-, POP3S-, IMAP- oder IMAPS-Protokoll ausgewählt sein.

TLS nicht durch eine Checkbox überschätzen

Unter SMTP TLS configuration wird das für den Scan vorgesehene CA- oder Serverzertifikat gewählt. Allow invalid certificate bleibt deaktiviert. Disable legacy TLS protocols schaltet laut Hilfe nur Protokolle vor TLS 1.1 ab und beweist keine konkrete TLS-1.2- oder TLS-1.3-Sitzung.

Sophos weist zudem auf eine wichtige Legacy-Grenze hin: Die Firewall baut die TLS-Verbindung anhand der Domain-IP statt des Domainnamens auf. Teilen sich mehrere Domains dieselbe IP-Adresse, kann die Zertifikatsprüfung scheitern. In diesem Fall empfiehlt Sophos einen anderen Schutzpfad wie Sophos Email Security. Die Prüfung wird nicht mit Allow invalid certificate umgangen.

Require TLS negotiation erzwingt TLS für ausgewählte Remote Hosts oder Netze; Require sender email domains erzwingt es für Absenderdomains. Kann die TLS-Verbindung dann nicht aufgebaut werden, verwirft SFOS die betroffenen E-Mails. Skip TLS negotiation erlaubt bewusst unverschlüsselte SMTP-Verbindungen zu den ausgewählten Gegenstellen und gehört nur in dokumentierte Ausnahmefälle. Jedes dieser Felder nimmt laut Hilfe höchstens 512 Hosteinträge auf; vor breiten Listen werden Überschneidungen zwischen Erzwingen und Überspringen ausgeschlossen.

Scan-Policies bewusst einsetzen

Ohne gültige Email Protection-Subscription kann Mailtraffic weiterhin erlaubt sein, erhält aber keinen Email-Protection-Schutz. Erreichbarkeit ist deshalb kein Lizenz- oder Scannachweis. Globale E-Mail-Einstellungen werden vor SMTP- und POP-IMAP-Policies verarbeitet. IP Reputation unter Email > General settings > SMTP settings im Legacy Mode mit Verify sender’s IP reputation aktivieren und mit Apply speichern; der MTA-Schalter heisst dagegen Reject based on IP reputation. Der globale ausgehende E-Mail-Banner unterstützt nur Text.

Nach Aktivierung der Email-Protection-Subscription wendet Sophos Firewall im Legacy Mode die Standardpolicy default-smtp-av automatisch auf SMTP-Traffic an. Eigene Policies werden unter Email > Policies angelegt und in Listenreihenfolge verarbeitet. Deshalb wird zuerst geprüft, welche vorhandene Policy den konkreten Absender und Empfänger trifft.

Neue Legacy-SMTP-Policies unter Email > Policies > Add policy mit SMTP malware scan oder SMTP spam scan erstellen. Für eine bestehende Policy unter Email > Policies bei der betreffenden Policy Edit wählen, die benötigten Einstellungen ändern und die Policy anschliessend speichern. Danach die Policy-Reihenfolge prüfen und den Positiv- sowie den Negativtest wiederholen.

Die Reihenfolge lässt sich in der Policy-Liste per Drag-and-drop ändern. Die bisherige Position vor dem Verschieben festhalten und danach beide Testfälle wiederholen: Eine engere Pilotpolicy darf nicht hinter einer bereits passenden allgemeineren Policy verschwinden.

Unter Email > General settings > Malware protection wird die primäre Antivirus-Engine global als Sophos oder Avira gewählt. Wird Avira verwendet, schaltet SFOS Zero-day Protection in SMTP-Policies mit Single antivirus aus. Vor einem Engine-Wechsel werden deshalb alle betroffenen Single-Antivirus-Policies inventarisiert und nach dem Wechsel erneut geprüft.

SMTP malware scan

Beim Anlegen einen eindeutigen Namen sowie die E-Mail-Adress- oder Domaingruppen für Absender und Empfänger festlegen. Unter Block file types die zu sperrenden Anhänge wählen; mehrere Typen lassen sich mit Ctrl+Shift auswählen. MIME whitelist erlaubt die gewählten MIME-Header, während die übrigen Dateitypen laut Hilfe blockiert werden. Diese Dateityp-Freigabe ist kein Antivirus-Bypass. Disable bedeutet dagegen ausdrücklich, dass E-Mails nicht gescannt werden.

Die Delivery option for recipient gilt für infizierte, geschützte und verdächtige Anhänge:

• Don’t deliver: weder Nachricht noch Benachrichtigung an den Empfänger.
• Deliver original: ursprüngliche Nachricht an den Empfänger; diese Wahl ist keine Bereinigung.
• Remove and deliver: infizierten Anhang entfernen, über die Entfernung benachrichtigen und die Nachricht zustellen. Diese Aktion gilt nicht für die unter Block file types festgelegten Dateitypen; daraus lässt sich keine andere Zustellaktion für blockierte Typen ableiten.

Geschützte Anhänge bleiben ungeprüft; standardmässig wird der Empfänger benachrichtigt, sofern nicht anders konfiguriert. Nach der Konfiguration mit Save speichern und die tatsächlichen Zustell- und Benachrichtigungsergebnisse mit harmlosen Positiv- und Negativfällen prüfen.

Eine SMTP malware scan Policy steuert blockierte Dateitypen, MIME-Ausnahmen, Antivirus-Scan und Zustellaktionen. Bei Single antivirus gilt die gewählte Engine laut Hilfe nur für eingehende Nachrichten; ausgehende Nachrichten werden mit beiden Engines geprüft. Dual antivirus lässt primäre und sekundäre Engine nacheinander scannen.

Die Aktion Quarantine wird mit den Empfänger- und Administratoraktionen kombiniert. Don’t deliver, Deliver original und Remove and deliver haben deutlich unterschiedliche Folgen. Eine geschützte oder nicht scannbare Anlage darf nicht automatisch mit Malware gleichgesetzt werden. Jede Aktion braucht deshalb eine Testmail, einen erwarteten Empfängerzustand und einen dokumentierten Freigabeweg.

Quarantine bedeutet nicht automatisch, dass der Empfänger keine Nachricht erhält; die Delivery option for recipient bleibt entscheidend. Notify sender funktioniert laut Sophos nur zusammen mit Don’t deliver. Geschützte Anhänge werden nicht gescannt, können aber weiterhin eine Benachrichtigung auslösen. Unter Delivery option for administrator bedeutet Don’t deliver, dass Administratoren nicht benachrichtigt werden; Send original sendet ihnen die ursprüngliche Nachricht. Das Original kann gefährliche oder ungeprüfte Anhänge enthalten und ist kein sicherer Benachrichtigungsersatz. Absender-, Empfänger-, Administrator- und Quarantäneergebnis werden getrennt geprüft.

⚠️ Remove attachment unter Delivery option for administrator bleibt aus dieser Anleitung ausgeschlossen: Die Feldbezeichnung deutet auf eine Administratoraktion, die Beschreibung nennt aber eine Nachricht ohne Anhang an den Empfänger und eine Entfernungsbenachrichtigung an Administratoren. Daraus lässt sich keine sichere Zustellzuordnung ableiten. Die Option nicht neu produktiv aktivieren. Für den isolierten Pilot infizierter Anhänge Don’t deliver sowohl für Empfänger als auch Administratoren verwenden, Quarantäne separat überwachen und die Ergebnisse mit harmlosen Testmustern prüfen. Eine bereits verwendete Remove attachment-Option erst nach dokumentierter Klärung mit Sophos Support und kontrollierter Prüfung ändern; weder eine Entwarnung noch eine automatische Bereinigung unterstellen.

Begrenzter Pilot statt ungeprüfter Beispielpolicy

Für den Mailserver 10.20.30.25 zunächst eine eindeutig benannte Policy auf eine Testempfängergruppe der Beispieldomain example.net begrenzen; Domain und Gruppe werden durch eigene kontrollierte Werte ersetzt. Fehlt die Domain im Adressbuch, lässt sie sich über Create new anlegen. Unter Block file types etwa Executable files wählen, Dual antivirus und Quarantine festlegen und die Empfänger- sowie Administratoraktionen separat wie oben planen. Eine MIME-Freigabe nur ergänzen, wenn sie fachlich begründet ist. Eine geschützte Anlage ist weiterhin ungeprüft; Send original für geschützte Anhänge wird deshalb nicht blind aus einer Beispielpolicy übernommen.

Ein Beispielscanlimit von 2048 KB gehört zu Don’t scan emails greater than in den globalen SMTP-Einstellungen, nicht zur Pilotpolicy und nicht zu einem festen Produktdefault. Es begrenzt den Scan auf kleine Nachrichten. Vor Übernahme anhand des realen Mailvolumens die Oversize-Aktion und einen Test knapp oberhalb des Limits planen; andernfalls entsteht bei Accept eine Scan-Lücke oder bei Reject beziehungsweise Drop ein Zustellproblem. Eigene SMTP-Spam- und POP/IMAP-Policies sind bedarfsabhängige Ergänzungen, keine Voraussetzung zum blossen Anlegen des NAT-Pfads.

SMTP spam scan

Einen Namen und die E-Mail-Adress- oder Domaingruppen für Absender und Empfänger festlegen. Für diese Gruppen bewusst exakten Match oder Keyword-Match wählen: Eine Stichwortsuche darf nicht unbeabsichtigt den Geltungsbereich erweitern. Keine nicht belegte Regex-, Wildcard- oder AND/OR-Syntax voraussetzen.

• Inbound email is und Outbound email is: Richtung getrennt wählen; Kriterien sind Spam, probable spam, virus outbreak oder probable virus outbreak.
• Source IP/network address und Destination IP/network address: benötigte Absender- beziehungsweise Empfänger-IP oder das Netz angeben.
• Sender remote blacklist: die passende RBL-Gruppe für den Absender wählen.
• Message size: obere oder untere Grössengrenze festlegen, nicht mit dem globalen Oversize-Limit verwechseln.
• Message header: Header wählen; bei Other die Details eintragen, exakten oder Keyword-Match wählen und den Keyword-Wert festlegen.

Reject weist die Nachricht ab und informiert den Absender. Accept stellt sie zu. Prefix subject ergänzt den Betreff und stellt ebenfalls zu; etwa kennzeichnet ein Präfix Probable spam einen kontrollierten Test. Drop verwirft ohne Absenderbenachrichtigung, Quarantine hält die Nachricht in Quarantäne. Für Accept und Prefix subject ist die SPX-Template-Auswahl dokumentiert, ausschliesslich für ausgehende E-Mails. Daraus folgt weder SPX-Unterstützung für jede andere Aktion noch eine automatische Verschlüsselung jeder akzeptierten Nachricht. Mit Save speichern und Match sowie Aktion getrennt prüfen.

Eine SMTP spam scan Policy kann unter anderem auf Spamklassifizierung, Source oder Destination, RBL, Nachrichtengrösse, Header oder eine Data Control List reagieren. Als Aktionen stehen je nach Pfad Reject, Accept, Change recipient, Prefix subject, Drop und Quarantine zur Verfügung.

Die Kriterien Data control list und die SPX-Zuweisung gelten in dieser Policy nur für ausgehende Nachrichten. None wendet die gewählte Aktion dagegen auf alle Nachrichten zwischen den festgelegten Absender- und Empfängergruppen an. Change recipient liefert nicht zusätzlich an den ursprünglichen Empfänger, sondern ersetzt ihn durch das konfigurierte Ziel. Diese drei Reichweiten werden vor der produktiven Policy-Reihenfolge mit einem positiven und einem negativen Empfängerfall geprüft.

Eigene Dateitypen und Data Control vorbereiten

Die E-Mail-Dateitypvorlagen heissen Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files und Web files. Es sind Klassifikationen anhand von Erweiterungen oder MIME-Headern, keine Sicherheitsurteile. Executable files enthält beispielsweise exe, cmd, bat und com; pdf steht sowohl unter Document files als auch unter Page layout files, und application/octet-stream kommt in mehreren Kategorien vor. Die Kategorien schliessen einander nicht aus. Ein generischer MIME-Header wird nicht breit freigegeben, um einen einzelnen Anhang zuzulassen. Die ausführliche interne Dateityp-Referenz steht in Web Protection; vor der Vorlagenwahl oder einer engen eigenen Definition werden die Werte auf dem Zielsystem geprüft.

Beim eigenen Dateityp einen Namen vergeben und das Objekt mit Save speichern, bevor die Policy angepasst wird. Der separate MTA-Anlegepfad lautet Email > Policies and exceptions > File type > Add; er ersetzt den Legacy-Pfad nicht. Dateitypen werden auch in Web-Policies verwendet; deren Konfiguration gehört zu Web Protection. Auch der Data Control List einen eindeutigen Namen geben und nach der CCL-Auswahl Save wählen.

Eigene Dateitypen werden im Legacy Mode unter Email > Policies > File type > Add aus einer Vorlage oder aus Dateiendungen beziehungsweise MIME-Typen erstellt. Dateiendungen werden ohne führenden Punkt eingetragen; nur eigene Typen sind editierbar. Ein neuer Typ ergänzt bestehende Policies nicht automatisch. Die betroffene Scan-Policy muss danach geöffnet, um den Dateityp ergänzt und erneut gespeichert werden. Ein positiver und ein ähnlicher negativer Anhangstest zeigen, ob wirklich die vorgesehene Policy-Aktion greift.

Eine Data Control List wird unter Email > Data control list > Add aus den benötigten Content Control Lists aufgebaut. Die Filter Type und Region helfen, nur passende Finanz-, Identitäts- oder andere sensible Datenmuster auszuwählen. Der Listenmatch bestimmt noch keine Aktion; diese wird in der verknüpften Scan-Policy festgelegt. Eine kleine Pilotliste mit positivem und negativem Inhaltstest ist deshalb sicherer als eine breite Sammlung ungeprüfter CCLs.

CCLs können beispielsweise Kreditkarten- oder Sozialversicherungsnummern, Postadressen und E-Mail-Adressen erkennen. Für die Pilotprüfung synthetische Daten verwenden, niemals echte personenbezogene Datensätze. Nur die für den eigenen Zweck und die Region passenden Muster aufnehmen; ein Treffer beweist weder die Echtheit der Daten noch eine rechtliche Klassifizierung.

SPX kann im Legacy Mode über diese Policy für ausgehende Nachrichten ausgewählt werden. Passwortmodell, Portal und Abnahme sind jedoch ein eigener Sicherheitsablauf; dafür dient SPX E-Mail-Verschlüsselung einrichten. Eine Data Control List oder SPX-Zuweisung wird nicht in den ersten reinen Proxytest aufgenommen.

Eine bestätigte Fehlklassifizierung wird nicht durch das Abschalten einer breit wirkenden Policy behoben. Im Legacy Mode wird stattdessen die passende SMTP malware scan- oder SMTP spam scan-Policy gezielt angepasst; ein Positivtest und ein Negativtest ausserhalb des vorgesehenen Geltungsbereichs müssen die Wirkung bestätigen. E-Mail-Ausnahmen sicher erstellen und testen beschreibt dagegen ausschliesslich das Ausnahmeobjekt im MTA Mode: Quelle, Absender oder Empfänger sind alternative Auslöser (OR), keine exakt kombinierte AND-Bedingung aus allen drei Merkmalen. Dieses MTA-Ausnahmeobjekt ist kein Legacy-Steuerelement.

Dokumentierte Dateitypzuordnungen

Diese Referenz hält die Zuordnungen der E-Mail-Vorlagen fest; sie ist keine Freigabeliste und kein Malware-Nachweis. Vor Änderungen werden die Werte des Zielsystems geprüft. Technische MIME-Tokens bleiben unverändert, auch ungewöhnliche dokumentierte Schreibweisen wie text/x-script.phyton; daraus folgt weder ihre Standardkonformität noch eine neue eigene MIME-Regel.

Audio files

• Dateiendungen: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• MIME-Header: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

• Dateiendungen: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• MIME-Header: application/octet-stream.

Compressed files

• Dateiendungen: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• MIME-Header: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Dateiendungen: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• MIME-Header: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Dateiendungen: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• MIME-Header: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Dateiendungen: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
• MIME-Header: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

• Dateiendungen: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME-Header: application/x-cdlink.

Document files

• Dateiendungen: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
• MIME-Header: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

• Dateiendungen: pl, jsp, asp, php, cgi, shtml.
• MIME-Header: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Dateiendungen: bin, enc, hex, hqx, mim, mime, uue.
• MIME-Header: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Dateiendungen: exe, cmd, bat, com.
• MIME-Header: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Dateiendungen: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• MIME-Header: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

• Dateiendungen: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• MIME-Header: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

• Dateiendungen: 8bi, arx, crx, plugin, vst, xll.
• MIME-Header: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

• Dateiendungen: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
• MIME-Header: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

• Dateiendungen: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• MIME-Header: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

• Dateiendungen: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME-Header: application/atom+xml.

Optionales Email Journaling datenschutzkonform einsetzen

Dem Journal-Eintrag einen eindeutigen Namen geben und Empfängerauswahl sowie Journalziel mit Save speichern, bevor die folgenden Tests beginnen.

Unter Email > General settings > Email journaling > Add kann SFOS Kopien der eingehenden SMTP/S-Nachrichten ausgewählter Empfänger oder Adressgruppen an eine separate Journaladresse senden. Die Auswahl Any erfasst alle eingehenden Nachrichten. Die Funktion gilt nur für SMTP/S; POP- und IMAP-Verkehr wird damit nicht journalisiert.

Journaling erzeugt eine zusätzliche E-Mail-Kopie. Es ist weder automatisch ein manipulationssicheres Archiv noch ein Nachweis, dass gesetzliche Aufbewahrungspflichten erfüllt sind. Vor der Aktivierung werden Zweck, berechtigte Empfänger, Zugriff auf das Journalpostfach, Verschlüsselung, Aufbewahrungsdauer, Speicherbedarf und verantwortlicher Owner festgelegt.

Für den ersten Test wird ein einzelnes Testpostfach statt Any gewählt. Eine eingehende Nachricht an dieses Postfach muss im normalen Ziel und im Journalpostfach erscheinen; eine Nachricht an einen nicht erfassten Empfänger darf keine Journal-Kopie erzeugen. Die Journaladresse darf keinen Mailflow auslösen, der die Kopie erneut an SFOS zurückführt und eine Schleife erzeugt.

Erst nach dem Positiv- und Negativtest wird die Empfängerauswahl bei Bedarf erweitert. Beim Rollback wird der Journal-Eintrag entfernt oder auf den dokumentierten Vorzustand gesetzt. Bereits zugestellte Kopien bleiben im Journalpostfach und müssen nach dessen eigenen Aufbewahrungsregeln behandelt werden.

Legacy-Mailobjekte per XML API sicher zuordnen

Die XML-API-Referenzen für SFOS 22 und 23 beschreiben eigene Legacy-Mailobjekte. Ein Menüpfad aus MTA Mode, eine flache Parametertabelle oder ein Sample mit durch Schrägstriche getrennten Alternativen ist kein kopierfertiger Request. API-Zugang, Transport, Operationsstatus, ungelöste Meldungsschlüssel und Kontrolle nach dem Schreiben erklärt XML API Zugriff absichern. Die folgenden Zuordnungen dienen zum Lesen einer vorhandenen Konfiguration und gelten nicht automatisch für REST oder die Central API.

Vor einer Änderung Backup, aktuellen Objektinhalt, referenzierende Policies und Reihenfolge sichern. Den konkreten Request und widersprüchliche Feldwerte anhand der API-Hilfe des installierten Builds oder mit Sophos Support klären. Danach die gespeicherten Objekte und die tatsächliche Mailwirkung getrennt prüfen. Ein erforderliches Feld in der Tabelle ist keine Aussage darüber, ob das Weglassen anderer Felder deren bisherigen Wert erhält. Auch Leeren, Ersetzen oder Zusammenführen von Listen sowie atomare Änderungen sind damit nicht belegt.

EmailConfiguration: Protokoll und TLS-Kontext gehören zum Feld

Unter EmailConfiguration sind gleichnamige Felder durch ihre Eltern getrennt:

• GeneralSettings/EmailSignature und GeneralSettings/EmailBannerMode betreffen den ausgehenden Banner. Die API-Tabelle nennt die Moduswerte inline_plain, mimepart und off; das Muster enthält dagegen UI-nahe Alternativen. Diese Texte nicht ungeprüft als identische API-Werte behandeln. EmailSignature ist eine Zeichenkette mit laut API-Tabelle höchstens 2000 Zeichen.
• SMTPSSettings/DontScanEmailsGreaterThan ist das SMTP-Scanlimit in KB; SMTPSSettings/ActionForOversizeEmails die davon getrennte Aktion Accept, Reject oder Drop. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings und die sechs DoS-Grenzwerte liegen ebenfalls in SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan ist ein anderes ganzzahliges KB-Limit. POPIMAPSettings/RecipientHeaders/Header ist eine Liste von Header-Zeichenketten zur Empfängererkennung, keine SMTP-Empfängerliste.
• SMTPTLSConfiguration und POPSIMAPTLSConfiguration enthalten jeweils eigene TLSCertificate, AllowInvalidCertificate und DisableTLS1. Das SMTP-Zertifikat ersetzt das POP/IMAP-Zertifikat nicht. RequireTLSWithHost, RequireTLSWithSenderDomain und SkipTLSHosts stehen im SMTP-TLS-Kontext; es sind getrennte Listen von Zeichenketten, keine gemeinsame Ein-/Aus-Ausnahme. Die UI-Grenze von 512 Hosteinträgen nicht mit der API-Tabellenangabe von maximal 512 Zeichen verwechseln.

API-Tabelle, Muster und UI-Referenz getrennt halten: Die API-Tabelle nennt für beide Scanlimits 1024 als Default. Für MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate und ConnectionsRate nennt sie der Reihe nach 5000, 100, 100, 100, 1000 und 100. Das Sample verwendet für MaximumEmailsConnection dagegen 1000; das oben erläuterte UI-Beispiel 2048 KB ist wiederum kein Default. Die Bedeutung von 0 bleibt die oben beschriebene protokollspezifische UI-Referenz, nicht eine aus dem API-Muster abgeleitete Unendlich-Einstellung.

Die API-Tabelle erlaubt für MaximumRecepientsEmail 1 bis 512, während die UI-Referenz für Maximum recipients/email 1 bis 256 nennt. Die API-Schreibweise MaximumRecepientsEmail bleibt unverändert; daraus weder einen korrigierten Feldnamen noch die sichere UI-Gültigkeit von 512 ableiten. Die anderen fünf DoS-Bereiche stimmen mit den oben genannten UI-Bereichen überein. Der gespeicherte Zustand und die Hilfe des Zielbuilds bleiben massgebend.

Weitere Konflikte verhindern die blinde Sample-Übernahme: Für VerifySendersIPReputation nennt die Tabelle on/off, führt Disable als Default auf, während das Muster Enable zeigt. Bei SMTPSDosSettings steht der Datentyp INTEGER neben dem Tabellen-Default Disable und dem Sample-Wert Enable. BypassSpamCheck hat laut Tabelle den Default Disable, das Muster aktiviert ihn jedoch. Beide TLS-Kontexte erlauben im Muster ungültige Zertifikate. Weder diese unsicheren Sample-Einstellungen übernehmen noch aus den widersprüchlichen Angaben einen vermeintlich gültigen Payload konstruieren; die oben beschriebene sichere TLS- und Bypass-Entscheidung bleibt bestehen.

Bei der Operation Email Configuration sind 200 mit Message.AVGeneralConfUpdateSuccess, 500 mit Message.AVGeneralConfUpdateFail und 505 mit Message.ASConfigSubOperationFail dokumentiert. SFOS 23 ergänzt die bereits oben erläuterte Zuordnung 506 mit Message.AVGeneralConfInvalidSmtpNtfyHostname. Es sind Operationsstatus und ungelöste Schlüssel, keine HTTP-Codes oder bestätigten Laufzeittexte. Insbesondere nach 505 erst SMTP-, POP/IMAP- und TLS-Einstellungen zurücklesen; weder vollständigen Rollback noch vollständige Speicherung voraussetzen und nicht blind wiederholen.

SMTP-Malware: Empfänger und Administratoren unabhängig behandeln

Das Objekt heisst AntiVirusMailSMTPScanningRules. Name bezeichnet die Policy, After/Name die im Sample gezeigte Vorgängerreferenz. SenderList/Sender und ReceiverList/Receiver sind getrennte Listen; BlockFileTypes/FileType ist die Liste blockierter Dateitypen. Die API-Tabelle führt ausserdem WhiteList als MIME-Liste auf, zeigt im Sample aber keine entsprechende Verschachtelung. Daraus keinen zusätzlichen XML-Elternknoten erfinden.

Für Scanning nennt die API-Tabelle Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) und Disable, mit Default Disable. Das Sample Disable/Disable ist weder ein vollständiger Enum noch ein brauchbarer Wert für den gewünschten Antivirus-Scan. Quarantine und NotifySender sind eigenständige Schalter mit Enable/Disable; laut API-Tabelle ist jeweils Disable der Default. Diese Tabellenwerte ersetzen weder die vorhandene Standardpolicy noch einen Nachweis des aktuellen Scanstatus.

Für infizierte, verdächtige und geschützte Anhänge gibt es jeweils zwei unabhängig gewählte Aktionen:

• Empfänger: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment mit Don'tDeliver, DeliverOriginal oder RemoveAndDeliver.
• Administratoren: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment mit Don'tDeliver, SendOriginal oder RemoveAttachment.

Die API-Tabelle nennt für alle sechs Aktionsfelder Don'tDeliver als Default. Das ist nicht mit der UI-Beschreibung einer standardmässigen Benachrichtigung für geschützte Anhänge gleichzusetzen und belegt keinen aktuellen Zustellzustand. Die oben erläuterten Wirkungen und Grenzen bleiben entscheidend: DeliverOriginal beziehungsweise SendOriginal kann ungeprüfte oder gefährliche Anhänge weitergeben; Quarantäne ist kein Beweis für unterdrückte Empfängerzustellung. Die ungeklärte Administratoroption RemoveAttachment bleibt ausgeschlossen, auch wenn die API sie als Wert aufführt. Absender-, Empfänger-, Administrator- und Quarantäneergebnis separat kontrollieren.

AntiSpamRules: Match, Reihenfolge und Aktion nicht vermischen

Bei AntiSpamRules identifiziert Name die Regel. After/Name ist die im Sample dargestellte Referenz für ihre Position nach einer anderen Regel. Vor Add, Edit oder Order die wirkliche Reihenfolge und den referenzierten Regelnamen sichern; die Dokumentation beschreibt damit nicht automatisch eine Syntax für die erste Position oder nicht vorhandene Vorgänger.

RecipientList/Action mit RecipientEmail und SenderEmailList/Action mit SenderEmail steuern getrennt den Empfänger- und Absendermatch. Die API-Tabelle nennt für beide Match-Aktionen Equals oder Contains, mit Tabellen-Default Contains. Sie sind nicht die Zustellaktion. MarkSpamIf enthält dagegen Condition und die dazu passenden OtherHeader, Operator und MatchIs. Eine Nachrichtengrösse benötigt einen Grössenvergleich; ein Header einen Textmatch; eine Klassifikation einen Klassifikationswert. Die flache Tabellenzeile beschreibt MatchIs als ganzzahlige Nachrichtengrösse, das Muster verwendet aber Spam. Daraus nicht schliessen, dass jeder Bedingungstyp numerisch ist. Der Tabellenwert 4 und die unterschiedlichen Bedingungsbezeichner im Muster sind keine Grundlage für eine erfundene Header- oder Enum-Zuordnung.

SMTPAction/Action und SMTPAction/ActionParameter bestimmen die SMTP-Aktion und deren Zusatzwert; SMTPAction/Quarantine ist davon getrennt. POPIMAPAction/Action und POPIMAPAction/ActionParameter gehören zum Abrufpfad, dessen Sample nur Accept und Prefix Subject zeigt. Eine SMTP-Aktion nicht auf POP/IMAP übertragen. Bei Change recipient ist der Parameter das Ersatz-Zustellziel, keine zusätzliche Journaladresse. Die oben beschriebenen Einschränkungen für ausgehende Data Control und SPX bleiben bestehen.

Auch hier widersprechen sich Muster und Tabelle: Für Quarantine zeigt das Sample Enable/Disable, die Tabelle erlaubt 0 und Enable. Die SMTP-Aktionstabelle führt zudem Accept With SPX auf; diese API-Schreibweise nicht aus dem UI-Label oder einem normalen Accept ableiten. Vor einem Schreibaufruf den konkreten bedingungsabhängigen Wert klären, statt die durch Schrägstriche getrennten Sample-Alternativen zu senden.

Für Order SMTP Scanning Policy stehen 200 mit Message.SpamRuleUpdateRuleOrderSuccess sowie sowohl 500 als auch 505 mit Message.SpamRuleUpdateRuleOrderFail. Derselbe Schlüssel bezeichnet also zwei Statuszeilen; er erklärt deren Ursache nicht. Bei Add SMTP Scanning Policy ist 502 mit Message.SpamRuleRecordExists dokumentiert. Vor erneutem Add oder Order den vorhandenen Namen, Inhalt und die gespeicherte Reihenfolge prüfen; die zentrale API-Sicherheitsprüfung und der positive wie negative Policy-Test gelten auch hier.

DataControlList: Signaturen sind noch keine Zustellaktion

Das Legacy-Objekt DataControlList enthält Name und Signatures/Signature, eine Liste von CCL-Signaturnamen. Die flache Tabelle verwendet dafür die Bezeichnungen name und signaturename; sie ist kein Grund, die im Sample gezeigten XML-Tags still umzubenennen. Die Tabelle nennt den Namen als erforderliche Zeichenkette mit maximal 255 Zeichen und die Signaturen als optionale Liste von Zeichenketten. Den tatsächlichen Signaturnamen aus der eigenen verfügbaren CCL-Auswahl übernehmen, nicht aus dem Länderbeispiel kopieren. Die Aktion folgt weiterhin erst aus der verknüpften Policy. Das andere Objekt MTADataControlList nicht anstelle dieses Legacy-Objekts verwenden.

Für Add Data Control List und Update Data Control List führen beide Referenzen 502 mit Message.DLPAddSameName sowie 545 mit Message.MTAModeDisableCheck auf. 545 ist eine dokumentierte Status-/Schlüsselzuordnung, keine verifizierte Aussage, dass Legacy Mode diese Funktion verbietet oder dass ein Moduswechsel erforderlich wäre. Den Modus deshalb nicht zur Fehlerbehebung umschalten. Die gespeicherte Liste und ihre Referenzen vor erneutem Add oder Update prüfen und die tatsächliche Antwort mit der Hilfe des installierten Builds beziehungsweise Sophos Support klären.

AVASAddressGroup: genau ein typabhängiger Zweig

AVASAddressGroup ist die Legacy-Adressgruppe für diese Mailregeln, nicht ein durch einen MTA-Menüpfad bewiesenes gleichwertiges Objekt. Name identifiziert die Gruppe; die API-Tabelle nennt höchstens 50 Zeichen, für die optionale Description höchstens 255. Die GroupType-Tabelle nennt RBLIPv4, RBLIPv6, IPAddress und EmailAddressOrDomain, das Sample dagegen pauschal RBL. Diese Schreibweisen nicht stillschweigend normalisieren.

Der Sample-Kommentar verlangt genau einen zum Typ passenden Zweig: RBLList/RBLName oder RBLFile, IPAddressList/IPAddressNetwork oder IPAddressFile, beziehungsweise EmailAddressList/EmailAddressDomain oder EmailAddressFile. Die Listeneinträge sind Zeichenketten; die Tabelle nennt mehrere Werte und ignorierte Duplikate. Das Sample zeigt die Alternativen gemeinsam, ist aber kein Auftrag, alle Listen und Dateien zu senden. Bei E-Mail-/Domaingruppen trennt EmailImportType die Werte Manual und Import. Die Tabelle nennt für EmailAddressFile die Formate csv und txt, beschreibt das Feld jedoch widersprüchlich als manuelle Eingabe; das Sample verweist auf den Dateinamen eines Multipart-Requests. Beides belegt weder eine vollständige Multipart-Bindung noch einen sicheren Importaufruf. Diese Details vor einem Import build-spezifisch klären.

Bei Add Address Group sind 502 mit Message.AddrGrpRecordExists, 541 mit Message.AddrGrpImportFailed, 542 mit Message.AddrGrpEmptyFile1 und 543 mit Message.AddrGrpSomeEmailNotImported dokumentiert. Aus den ungelösten Schlüsseln weder die tatsächlich importierten Einträge noch einen vollständigen Rollback ableiten. Die gespeicherten Mitglieder vor dem nächsten Import mit der beabsichtigten Liste vergleichen.

Bei Delete Address Group haben 504, 505 und 506 denselben Schlüssel Message.AddrGrpForeignKeyExists; 507 ist mit Message.AddrGrpEmailArcKeyExists verknüpft. Die Schlüssel unterscheiden nicht sicher die einzelnen referenzierenden Objekte. Policies und Journal-Verweise vor dem Löschen inventarisieren, die genaue Operationsantwort auswerten und das Vorhandensein der Gruppe danach prüfen. Keine verknüpfte Schutzpolicy blind entfernen, um einen Löschaufruf zu erzwingen.

TrustedDomain, Journaling und Engine-Auswahl haben verschiedene Reichweiten

AntiSpamTrustedDomain/DomainList/DomainName ist eine Liste von Domain-Zeichenketten. Add und Delete verwenden DomainName als Listenidentität. Die API-Beschreibung spricht von einem Scan-Bypass für Mails vertrauenswürdiger Domains, benennt aber nicht, welche Scanner genau umgangen werden. Die UI beschreibt Spam check exceptions als Spam-Bypass. Diese beiden Aussagen weder zu einer Garantie für alle Scans noch zu einer nachgewiesenen exakten API-/UI-Gleichwertigkeit erweitern. Domains nur mit dokumentiertem Zweck und eng begrenzt verwalten; vor und nach Add oder Delete Liste und erwartete Schutzwirkung prüfen. Aus der Delete-Seite keinen fehlenden vollständigen XML-Request erfinden.

AntiSpamEmailArchiver erzeugt dagegen Kopien: Name benennt den Eintrag, RecipientList/Recipient begrenzt die Originalempfänger und SendCopyOfEmailTo ist die separate Kopieradresse. Laut API-Tabelle sind Name, Empfänger und Kopieradresse erforderlich; Name und Kopieradresse dürfen höchstens 50 Zeichen haben. Die Empfängerzeile ist als skalare Zeichenkette beschrieben, das Sample zeigt sie im Listen-Elternknoten. Diese Abweichung nicht durch einen selbst erfundenen Catch-all-Payload auflösen. Der oben beschriebene Einzelpostfach-Pilot samt Datenschutz, Schleifenschutz und Negativtest gilt auch für Automatisierung; eine Empfängeränderung ist keine Änderung der Kopieradresse.

MalwareProtection/PrimaryAntiVirusEngine ist wiederum ein globaler skalarer Engine-Selektor, kein Empfängerfilter und keine einzelne Scanpolicy. Die API-Tabelle nennt Sophos als Default; das Muster Sophos/Avira zeigt Alternativen, keinen zu sendenden Kombinationswert. Die oben erläuterte Auswirkung von Avira auf Zero-day Protection in Single-Antivirus-SMTP-Policies bleibt zu prüfen. Den global gespeicherten Wert und sämtliche betroffenen Policies nach einem Wechsel kontrollieren; getrennte Dokumentationsrouten machen daraus keine unabhängigen Engine-Konfigurationen.

NAT und Firewall-Regeln zusammenführen

Eingehenden SMTP-Pfad veröffentlichen

Für eingehende E-Mails übersetzt eine DNAT-Regel die öffentliche WAN-Adresse auf den internen Mailserver. Original Source wird so eng begrenzt, wie es das Maildesign erlaubt; Original Destination ist die vorgesehene öffentliche Adresse; Translated Destination ist 10.20.30.25 beziehungsweise der echte Mailserver. Original und translated Service bleiben auf den tatsächlich angebotenen SMTP-Ports.

Unter Rules and policies > NAT rules die passende IP-Familie wählen und Add NAT rule öffnen. Damit der interne Server unter Translated destination (DNAT) auswählbar ist, muss sein IP-Hostobjekt unter Hosts and services > IP host existieren. Im einfachen eingehenden Beispiel bleiben Translated source (SNAT) und Translated service (PAT) auf Original; unter Original service nur die verwendeten SMTP-Dienste auswählen, etwa SMTP und SMTP[S]. Erst nach Prüfung aller Felder mit Save speichern. Die NAT-Zielübersetzung ist nicht mit dem unten gesondert qualifizierten Firewall-Feld Destination networks gleichzusetzen.

Eine reflexive Regel erzeugt zusätzlich SNAT für die Gegenrichtung. Sie wird nur gewählt, wenn genau diese öffentliche Quellidentität für den ausgehenden Pfad vorgesehen ist. Mehrere WAN-Links, Smarthosts oder abweichende Provider-Routen benötigen ein eigenes Routing- und SNAT-Design. Die allgemeine Reihenfolge und die Zielzone nach NAT erklärt Server per DNAT veröffentlichen.

Zwei enge Firewall-Regeln verwenden

Zum Anlegen unter Rules and policies > Firewall rules die tatsächliche Protokollfamilie IPv4 oder IPv6 wählen und Add firewall rule > New firewall rule öffnen. Name und benötigte Felder festlegen, mit Save speichern. Die IPv4-Beispieladressen dieses Artikels nicht in eine IPv6-Regel übernehmen.

⚠️ Für Destination networks widersprechen sich die Beschreibungen: Das Legacy-Mailbeispiel nennt den internen Mailserver, der allgemeine DNAT-Regelablauf orientiert das Firewall-Matching am ursprünglichen öffentlichen Ziel. Diese Anleitung entscheidet den speziellen Proxy-Fall nicht durch Vermutung. Den bereits nachweislich funktionierenden eingehenden Regelmatch dokumentieren und für den Pilot beibehalten. Keine neue produktive Eingangsregel aus einer der beiden Feldzuordnungen ableiten und das Ziel nicht auf Verdacht wechseln. Bei einem neuen Pfad vor Freigabe mit Sophos Support beziehungsweise einer passenden kontrollierten Prüfung klären und mit Rule ID, DNAT-Hit sowie Capture vor und nach Übersetzung belegen. Die ausgehende SNAT-Variante löst diesen Konflikt nicht.

Für die Abnahme sind getrennte Regeln verständlicher als eine bidirektionale Regel mit mehreren Zonen und Any-Objekten:

• Eingehend: WAN zur Zone des internen Mailservers, SMTP-Endpunkt 10.20.30.25, nur benötigte SMTP-Dienste, Logging aktiv. Der Endpunkt ist hier keine Vorgabe für das ungeklärte Feld Destination networks.
• Ausgehend: Zone und Host des internen Mailservers zu WAN oder zum konkreten Smarthost, nur benötigte SMTP-Dienste, Logging aktiv

Unter Scan email content werden in beiden tatsächlich benötigten Richtungen Scan SMTP und nur bei echtem SMTPS-Betrieb Scan SMTPS aktiviert. Fehlt der Standardport des gewählten Protokolls unter Services, bietet SFOS Add ports an. Bei einem abweichenden Port wird stattdessen zuerst der passende Service bewusst definiert. Service, NAT, Serverlistener und Scanoption müssen denselben Portpfad beschreiben; Add ports ersetzt diese Prüfung nicht.

Die Regeln stehen oberhalb allgemeinerer Regeln, die denselben Traffic bereits matchen. Nach dem Speichern entscheidet die protokollierte Firewall Rule ID. Regelaufbau, NAT-Zone und Reihenfolge sind unter Sophos Firewall-Regeln sicher konfigurieren vertieft.

Optional: ausgehend eine andere öffentliche Quelladresse verwenden

Dieser Aufbau gilt für weitergeleiteten SMTP-Traffic des internen Servers, nicht für systemgenerierte MTA-Nachrichten. Er ist sinnvoll, wenn statt der WAN-MASQ-Adresse eine andere zugeteilte öffentliche Identität benötigt wird. Providerzuteilung, Route sowie SPF, RDNS und Providerfreigaben müssen zu dieser Identität passen; SNAT ändert diese Voraussetzungen nicht.

1. Unter Network > Interfaces > Add interface > Add alias das tatsächliche physische WAN-Interface, IP version IPv4 und die zugeteilte Adresse mit passender IPv4/Netmask wählen; Save. Providerpfad, Device Access und Aliasprüfung erklärt Alias-IP einrichten.
2. Unter Hosts and services > IP host > Add einen benannten Host für dieselbe öffentliche Adresse anlegen: IP family IPv4, Type IP, IP address die zugeteilte Adresse; Save. Ein Hostobjekt allein bindet keine Adresse ans Interface.
3. Unter Rules and policies > NAT rules > New NAT rule Original source auf den tatsächlichen internen Mailserver begrenzen und Translated source (SNAT) auf den öffentlichen IP Host setzen. Original destination auf die benötigten Mailziele beziehungsweise den Smarthost, Original service auf die benötigten SMTP-Dienste begrenzen. Translated destination (DNAT) und Translated service (PAT) bleiben Original. Inbound interface und Outbound interface müssen dem wirklichen Server-zu-WAN-Pfad entsprechen. Mit Save speichern und oberhalb anderer ebenfalls passender SNAT-Regeln einordnen; NAT- und Firewall-Reihenfolge getrennt prüfen. NAT-Grundlagen erklärt das First-Match-Modell. Any, Top, Port1 und Port2 aus Beispielen sind keine Pflichtwerte.
4. Unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule eine passende ausgehende IPv4-Regel erstellen oder die vorhandene enge Regel prüfen: Action Accept, tatsächliche Serverzone und Serverhost als Quelle, WAN und die benötigten Ziele, nur die benötigten SMTP-Dienste, Log firewall traffic aktiv. Scan SMTP und gegebenenfalls Scan SMTPS wie oben wählen; Save und die Firewall-Reihenfolge unabhängig von NAT prüfen.
5. Eine neue SMTP-Verbindung zu einem kontrollierten externen Empfänger erzeugen. Firewall Rule ID, NAT Rule ID, übersetzte Quell-IP im Capture beziehungsweise beim externen Empfänger und tatsächliche Zustellung gemeinsam prüfen. Eine bestehende Session oder ein SMTP-Porttest genügt nicht. Auch eine nicht erfasste Quelle beziehungsweise ein nicht erlaubter Dienst wird negativ geprüft.

In der ausgehenden Firewall-Regel bestimmt During scheduled time, wann diese Regel gilt. Für einen dauerhaft erreichbaren Mailserver All the time bewusst wählen. Ein eingeschränkter Zeitplan kann den Regelmatch ausserhalb des Fensters verändern; dort ebenfalls Rule ID und Mailflow prüfen. Dies ist kein Zeitplan der SNAT-Regel. Die automatisch beim Aktivieren von MTA Mode angelegte Firewall-Regel gehört zu einem anderen Mailflow und wird nicht als Ersatz für diese Legacy-Serverregel bearbeitet; dafür gilt das MTA-Runbook.

Beim Rückbau zuerst die dokumentierten Regeln und ihre Reihenfolge wiederherstellen und mit einer neuen Verbindung die frühere Quell-IP und Zustellung prüfen. Alias und IP Host erst entfernen, wenn kein anderer Dienst davon abhängt.

Mailflow und Proxy-Scan abnehmen

Zuerst wird eine kleine externe Nachricht an ein Testpostfach gesendet. Danach versendet der interne Mailserver eine zweite Nachricht an einen kontrollierten externen Empfänger. Beide Tests erhalten eindeutige Betreffe und UTC-Zeitstempel.

Für STARTTLS auf Port 25 und eine direkte TLS-Verbindung auf Port 465 helfen von einem zulässigen Testsystem folgende lesende Prüfungen:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net durch den tatsächlichen FQDN ersetzen und nur Ports testen, die tatsächlich angeboten werden. Diese OpenSSL-Befehle zeigen die präsentierte Zertifikatskette und die ausgehandelten TLS-Parameter an; alle Fehler bei der Zertifikatsprüfung kontrollieren. Sie prüfen den erwarteten Hostnamen nicht explizit und können trotz Prüfungsfehlern fortfahren. Eine Verbindung ist daher kein Nachweis für eine erfolgreiche Zertifikatsauthentifizierung. Sie beweisen weder eine erfolgreiche Mailzustellung noch Malware-, Spam- oder Data-Control-Scanning.

Im Log Viewer müssen Source, Destination, Service, Action und Firewall Rule ID zu den neuen Regeln passen. Für den Legacy SMTP/S Proxy werden awarrensmtp.log und awarrenmta.log mit demselben Zeitpunkt korreliert. Die Logdateien sind unter Sophos Firewall Services und Logs eingeordnet.

Anschliessend separate Negativtests für den Geltungsbereich der Firewall-Regel und die Übereinstimmung mit der Nachrichten-Policy durchführen. Eine Quelle oder ein Dienst ausserhalb des Pilotumfangs darf nicht mit der Pilot-Firewall-Regel übereinstimmen und muss gemäss dem dokumentierten Ergebnis zugelassen oder blockiert werden; eine andere autorisierte Regel kann weiterhin Schutz bieten. Eine Testnachricht ohne das Kriterium der Pilot-Policy darf nicht mit dieser Policy übereinstimmen oder deren spezifische Aktion erhalten; alle anwendbaren standardmässigen oder sonstigen Scans müssen jedoch erhalten bleiben. Für jeden Fall die erwartete Firewall Rule ID, die Policy und das Zustellergebnis dokumentieren und mit dem beobachteten Ergebnis vergleichen. Bei Tests in der Produktionsumgebung keine echte Malware verwenden; für die Scanvalidierung dienen etablierte harmlose Testmuster und ein kontrolliertes Postfach.

Fehler nach Symptom eingrenzen

SMTP funktioniert, aber die Policy greift nicht

Zuerst die Firewall Rule ID prüfen. Trifft eine andere Regel, sind Reihenfolge, Source, Destination, NAT-Ziel und Service zu korrigieren. Trifft die erwartete Regel, müssen Scan SMTP beziehungsweise Scan SMTPS, Policy-Reihenfolge sowie Absender- und Empfängergruppe zum Test passen. Eine Policy allein aktiviert den transparenten Proxy nicht.

Eingehende Mail erreicht den Server nicht

Öffentliche Zieladresse, DNAT-Hit, translated Destination, Zielzone, Serverlistener und Rückweg getrennt kontrollieren. Eine offene TCP-Verbindung bis zur Firewall beweist nicht, dass DNAT und Firewall-Regel den internen Server erreichen. Packet Capture und Rule ID müssen Eingang und Weiterleitung zeigen.

Ausgehende Mail verwendet die falsche öffentliche IP

SNAT, reflexive Regel, WAN-Gateway, SD-WAN-Route und Reply-Packet-Verhalten prüfen. Der Legacy Proxy wählt nicht automatisch die für SPF, RDNS oder Providerfreigabe gewünschte Quelladresse. Vor einer globalen Route-Precedence-Änderung wird der konkrete Pfad belegt.

TLS schlägt nach Aktivierung des Scans fehl

FQDN, Ziel-IP, Zertifikat, Aussteller, Kette und ausgehandelte Version erfassen. Bei mehreren Domains auf derselben IP kann die dokumentierte IP-basierte Zertifikatsprüfung die Ursache sein. Allow invalid certificate wird nicht als schneller Fix aktiviert.

Eine Nachricht fehlt und im MTA-Spool steht nichts

Das ist im Legacy Mode kein verwertbares Erfolgskriterium, weil Mail spool und die MTA-spezifischen Mail logs zum MTA Mode gehören. Firewall-Regel, NAT, SMTP-Serverlogs, Log Viewer, awarrensmtp.log und awarrenmta.log bilden hier die relevante Kette. Quarantänierte Nachrichten werden separat unter Email > SMTP quarantine geprüft.

Sicher zurückrollen

Für den Rollback werden zuerst die Pilotregeln und Scanoptionen auf den dokumentierten Vorzustand gesetzt. Danach werden neue Policy-Zuweisungen beziehungsweise deren Reihenfolge zurückgenommen. Temporäre DNAT-, SNAT- oder Zertifikatsänderungen werden nur entfernt, wenn kein anderer Dienst davon abhängt.

Erst dann wird der SMTP Deployment Mode zurückgestellt, falls der Change genau diesen Wechsel umfasste. Der ursprüngliche eingehende und ausgehende Mailflow muss wieder mit den erwarteten Rule IDs, öffentlichen Adressen und Serverlogs funktionieren. Nachrichten, Quarantäne oder Proxy-Logs werden nicht als Standard-Rollback gelöscht.

Betriebscheckliste

• Transparenter Proxy ist bewusst gewählt; MTA-Anforderungen wurden ausgeschlossen.
• Backup, Managementzugang und ursprüngliche Rule IDs sind dokumentiert.
• SMTP-Hostname, SMTP- und POP/IMAP-Grössenlimit, Oversize-Aktion, IP Reputation und DoS-Grenzen sind begründet.
• Verwendete Standard- oder Alternativports und POP/IMAP-Recipient-Headers stimmen mit dem realen Serverpfad überein.
• Primäre Antivirus-Engine und die Auswirkung auf Zero-day Protection in Single-Antivirus-Policies sind geprüft.
• Zertifikat, TLS-Ausnahmen und betroffene Domains sind geprüft.
• DNAT, SNAT, Zielzone und reale Serverports stimmen überein.
• Eingehende und ausgehende Firewall-Regel sind eng, geloggt und treffen nachweislich.
• Standard- und eigene Policies besitzen eine nachvollziehbare Reihenfolge.
• Optionales Journaling ist auf die benötigten Empfänger begrenzt und besitzt einen dokumentierten Datenschutz- und Aufbewahrungszweck.
• Positiv-, Negativ-, TLS- und Zustelltest sind bestanden.
• Legacy-Proxy-Logs und Mailserverlogs lassen sich zeitlich korrelieren.
• Owner, Review-Datum und vollständiger Rückfallweg sind festgehalten.

FAQ