Sophos Firewall Mail Protection in MTA mode instellen

In MTA mode neemt Sophos Firewall zelf e-mail aan, controleert die en levert die af bij de interne mailserver of de volgende mailhop. De mailflow werkt alleen wanneer het MX-record, de automatische MTA-regel, de SMTP route and scan Policy, relay, TLS en recipient verification op elkaar aansluiten.

De configuratie bestaat uit zes stappen: mailflow en fallbackpad bepalen, MTA mode activeren, het maildomein toevoegen, de route and scan Policy maken, relay beveiligen en het MX-record wijzigen. Daarna worden inkomende en uitgaande mailflow gevalideerd met externe opdrachten, quarantaine, spool en logs.

Wanneer MTA mode geschikt is

Mail Protection op de firewall is vooral zinvol in bewust ontworpen on-premises en hybride omgevingen waarin een lokale Exchange- of andere mailserver moet worden beschermd. Voor Microsoft 365, Google Workspace en veel volledig cloudgebaseerde omgevingen is Sophos Email of een andere cloudmailgateway meestal duidelijker. Twee gateways na elkaar maken quarantaine, headers, TLS, SPF/DKIM/DMARC en troubleshooting ingewikkelder.

Als Exchange Online bewust via de firewall-MTA moet lopen, beschrijft Sophos Firewall MTA met Microsoft 365 configureren het volledige EOP-, relay-, connector-, MX- en SPF-pad.

Drie Sophos Firewall-functies moeten worden onderscheiden:

• MTA mode: de firewall neemt e-mail aan, controleert die en routeert die verder.
• Legacy mode: transparante proxyverwerking van een bestaand SMTP-pad. Mail Protection in Legacy mode configureren legt NAT, regels, scanbeleid en validatie uit.
• SMTP Relay in Device Access: bepaalt vanuit welke zones de MTA bereikbaar is. Inkomende internetmail vereist WAN; uitgaande relay wordt bovendien beperkt tot specifieke interne mailservers.

Het ophalen van bestaande mailboxberichten via POP3 of IMAP is een afzonderlijke taak. POP3 en IMAP scannen en testen op Sophos Firewall behandelt TLS-vertrouwen, de optionele policy, de firewallregel en de acceptatietest.

Vereist zijn een geldige Email Protection-licentie, werkende routing en DNS, een bekend openbaar IP-adres, de interne mailserver met doelpoort en geplande strategieën voor TLS, quarantaine en fallback. Volgens het huidige Sophos-overzicht is MTA mode niet beschikbaar op XGS 87/87w en XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation en SXL2 Live Protection vereisen internettoegang. E-mailrouting, malwarescan, MIME-filtering en SPX kunnen met de juiste licentie in een airgapomgeving blijven werken, maar een actieve MTA betekent daar niet dat alle beschermingscontroles beschikbaar zijn.

MTA mode end-to-end instellen

1. Mailflow en fallbackpad bepalen

Voor inkomende mail wijst het openbare MX-record naar het adres waarop Sophos Firewall TCP 25 aanneemt. De firewall controleert het bericht en levert het af bij de interne server. Een oude DNAT-regel mag die server niet ongefilterd rechtstreeks vanaf internet bereikbaar houden, anders kan de MTA worden omzeild. Een server met DNAT publiceren legt de algemene DNAT-logica uit.

Voor uitgaande mail verzendt alleen de bedoelde mailserver via de firewall. Verzendpad, smarthost, PTR/rDNS, HELO, SPF, DKIM en DMARC moeten bij de openbare afzenderidentiteit passen. Een algemene LAN to WAN-regel is te breed; de regelbasis moet de toegestane SMTP-afzender duidelijk identificeren. Sophos Firewall-regels begrijpen behandelt de regelvolgorde.

Documenteer vóór de migratie:

• huidig MX-record, prioriteit en TTL;
• nieuw openbaar firewalladres en interne doelserver;
• bestaande DNAT- en SMTP-regels en mailserverconnectors;
• inkomende en uitgaande testafzenders;
• oud MX-record of mailpad als fallback;
• monitoring van mailserverqueue, firewallspool en quarantaine.

Verlaag de TTL tijdig als een snelle rollback nodig kan zijn. Wijzigingen aan het productie-MX horen in een onderhoudsvenster.

2. MTA mode en basisinstellingen voor SMTP configureren

Selecteer zo nodig Switch to MTA mode onder Email > General settings. Sophos Firewall maakt dan de Any-to-Any-regel Auto added firewall policy for MTA voor SMTP en SMTPS. Bewerk deze regel niet en laat hem bovenaan de firewallregels staan. Overschakelen naar Legacy mode verwijdert hem; terugschakelen maakt hem opnieuw.

Configureer daarna de basisinstellingen:

1. Vul bij SMTP hostname de domeinnaam in, bijvoorbeeld example.com, niet de hostname van de interne mailserver. De waarde verschijnt in HELO en de SMTP-banner van systeemmeldingen.

   Controleer de XML-API-respons: De SFOS 23-documentatie vermeldt status 506 met Message.AVGeneralConfInvalidSmtpNtfyHostname voor de XML-API-operatie Email Configuration. Dit is een operatiestatus, geen HTTP-statuscode. De sleutel is niet opgelost en is geen Engelse foutmelding; er kunnen geen specifieke validatieregels uit worden afgeleid. Controleer bij deze respons de ingediende hostnaam voor meldingen, de daadwerkelijke operatierespons en de opgeslagen configuratie voordat u aanneemt dat de wijziging is geslaagd. De extra documentatieregel bewijst niet dat dit gedrag tijdens uitvoering pas in SFOS 23 is geïntroduceerd.

2. Schakel Reject based on IP reputation in om verbindingen van afzenders met een slechte reputatie te weigeren.

3. Kies onder SMTP TLS configuration een publiek vertrouwd certificaat en sta Allow invalid certificate alleen toe voor gedocumenteerde uitzonderingen.

4. Schakel Disable legacy TLS protocols in, tenzij gedocumenteerde legacy-systemen dit verhinderen. De optie schakelt protocollen vóór TLS 1.1 uit, maar dwingt niet automatisch uitsluitend actuele TLS-versies af.

5. Schakel Scan outgoing mails in als uitgaande berichten ook moeten worden gecontroleerd.

Gebruik Require TLS negotiation voorzichtig: als SFOS de vereiste TLS-verbinding niet kan opbouwen, verwijdert het e-mail naar de betrokken bestemming of van het ingestelde afzenderdomein. De SFOS 22/23-help waarschuwt dat SMTP TLS-verbinding en -validatie het IP-adres van het domein gebruiken in plaats van de naam; meerdere domeinen op één IP kunnen daarom certificaatfouten veroorzaken. Dit is een documentatiewaarschuwing, geen bewijs van het certificaatvergelijkingsalgoritme op de gebruikte build.

Skip TLS negotiation selecteert externe mailhosts of netwerken voor onversleutelde SMTP-verbindingen; de gedocumenteerde limiet is 512 hostvermeldingen. Dit is geen oplossing voor een fout certificaat. Allow invalid certificate is een uitzondering op TLS-peervalidatie, geen omschakeling naar platte tekst. Neem geen voorrang aan bij overlap tussen Require- en Skip-lijsten, en geen terugval naar platte tekst als vereist TLS mislukt. Beperk en documenteer uitzonderingen en controleer het werkelijke verbindings- en certificaatresultaat op de gebruikte build voordat u ze wijzigt.

Globale SMTP-grenzen vóór de policies vastleggen

De instellingen onder Email > General settings gelden voor alle e-mails en worden vóór de SMTP- en POP-IMAP-policies verwerkt. Reject based on IP reputation is daarom geen afzonderlijke policyactie: SFOS controleert het IP-adres van de afzender al vóór de spamcontroles van de SMTP-policy. Ook Blocked senders is globaal, maar blokkeert alleen inkomende e-mails.

Onder SMTP settings bepaalt Don’t scan emails greater than de maximale berichtgrootte voor de globale SMTP-scan. 0 betekent 51,200 KB, niet onbeperkt. Voor grotere berichten zijn Accept, Reject en Drop beschikbaar. Accept levert zonder scan af, Reject weigert en informeert de afzender en Drop verwijdert zonder melding. Documenteer deze keuze als een bewuste scanlacune of afleverbeslissing en test met een bericht net boven en onder de grens.

De SMTP DoS settings beperken gelijktijdige verbindingen, e-mails per verbinding, ontvangers per e-mail en e-mail- en verbindingssnelheden. SFOS stelt het maximumaantal verbindingen in op basis van RAM en processor. De gedocumenteerde standaardwaarden zijn 1000 e-mails per verbinding en 100 ontvangers per bericht. Leid eigen waarden af uit het werkelijke mailvolume; een te lage grens kan legitieme distributielijsten of scanners als een aanval behandelen.

Onder Advanced SMTP settings kan SFOS een ongeldige HELO of ontbrekende RDNS weigeren en met Do strict RDNS checks een hostnaam die niet terug naar het bron-IP resolveert. Voer deze controles niet tegelijk met een brede uitzondering in. Leg eerst de werkelijke paden van partners, nieuwsbrieven en applicaties in het log vast en test ze vervolgens afzonderlijk.

Een uitgaande banner kan Inline, no conversion, een afzonderlijke MIME part of Off gebruiken. SMTP- of SMTPS-scanning moet actief zijn in de matchende firewallregel. Omdat een banner de body wijzigt en een bestaande DKIM-handtekening kan breken, wordt na deze wijziging ondertekend of wordt bij de ontvanger expliciet gecontroleerd of de geplande handtekening geldig blijft.

Leg vóór een upgrade ook de SMTP-snelheidslimieten vast. De gedocumenteerde bereiken zijn 1–1000 e-mails per verbinding, 1–512 ontvangers per e-mail, 1–1000 e-mails per host per minuut en 1–100 verbindingen per host per seconde. De standaardwaarden voor de twee snelheden zijn respectievelijk 1000 en 100. Bij migratie behoudt SFOS ondersteunde e-mail- en verbindingssnelheden, maar zet waarden boven het maximum terug naar de standaardwaarde. Vergelijk de opgeslagen waarden na de upgrade, niet alleen de oude configuratie-export.

3. Het maildomein als Address Group toevoegen

1. Open Email > Address group > Add.
2. Stel Group type in op Email address/domain en Type op Manual.
3. Voeg het beschermde domein toe, bijvoorbeeld example.com.
4. Sla de groep op.

Voer bij het aanmaken vóór het opslaan ook een duidelijke Name in. Gebruik voor een bestaande groep Edit onder Email > Address group; start een bestandsimport met Import. RBL (IPv4) accepteert IPv4-adressen en RBL (IPv6) IPv6-adressen. Email address/domain ondersteunt handmatige invoer of CSV-/tekstimport. RBL-matching gebruikt het verbindende IP-adres en de actie in de SMTP-policy; het afzonderlijk beschreven SPF/RBL-weigeringsgedrag blijft van toepassing. Laat de standaardnamen Premium RBL services en Standard RBL services ongewijzigd, tenzij een expliciet geplande wijziging anders vereist.

Address Groups zijn niet beperkt tot e-maildomeinen. Group type kan Email address/domain, IPv4 RBL of IPv6 RBL zijn. Hetzelfde adres kan in meerdere groepen voorkomen, zodat afzonderlijke policydoelen mogelijk zijn zonder de invoer te kopiëren of te hernoemen.

Voor grotere lijsten kan SFOS een CSV- of tekstbestand met maximaal 400 adressen of domeinen importeren. Ongeldige en dubbele invoer wordt overgeslagen. Controleer na de import het aantal en enkele voorbeelden voordat de groep aan een productiepolicy wordt toegewezen.

Nieuwe SMTP route and scan Policies worden rond domeinen ontworpen, niet rond afzonderlijke ontvangeradressen. Gemigreerde afzonderlijke adressen kunnen actief blijven, maar kunnen in actuele policies niet nieuw worden toegevoegd of bewerkt.

4. Een SMTP route and scan Policy maken

Open Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Geef een duidelijke naam op, bijvoorbeeld Inbound example.com to Exchange.
2. Selecteer onder Protected domain de Address Group.
3. Kies Route by:
   • Static host: vast intern mailserver-IP; bij uitval probeert de firewall de volgende host in de lijst.
   • DNS host: DNS-naam zoals mailserver.example.com; meerdere A-records worden over leveringen verdeeld en onbereikbare servers worden overgeslagen.
   • MX: aflevering op basis van een MX-record.
4. Selecteer bij Static host de mailserver onder Host list. Maak zo nodig de IP host onder Hosts and services > IP host.
5. Stel Global action in op Accept voor de domeinen die bewust worden beschermd. Reject zou alle inkomende en uitgaande berichten die betrekking hebben op die domeinen weigeren en de afzender informeren.
6. Activeer Spam protection en Malware protection volgens het bedrijfsconcept.
7. Activeer File protection en Data protection pas nadat de gevolgen voor bijlagen, grote berichten, SPX en DKIM duidelijk zijn.
8. Sla de policy op.

Kies voor een bestaande SMTP route and scan-policy onder Email > Policies and exceptions bij de betreffende policy Edit, wijzig de benodigde instellingen en sla de policy op. Controleer daarna met een gecontroleerd bericht opnieuw of de policy matcht en het bericht wordt afgeleverd.

Bij Route by MX mag het door de firewall gevonden MX-record niet naar dezelfde firewall terugwijzen, anders ontstaat een routinglus. Interne doelen moeten correct worden opgelost; DNS Request Routes helpen bij split DNS.

De optie Route inbound mail through gateway is alleen nodig voor bijzondere ontwerpen, zoals doelservers in de WAN-zone, toepassing van de oorspronkelijke regel op LAN/DMZ-doelen of selectie van een specifieke gateway bij meerdere internetverbindingen. Activeer deze niet zonder concrete routingreden.

5. Inkomende toegang en uitgaande relay beveiligen

Sta onder Administration > Device access SMTP Relay toe vanuit elke zone die de MTA moet bereiken. Inkomende internetmail vereist WAN; uitgaande mail daarnaast de zone van de interne mailserver, meestal LAN of DMZ. Beperk daarna onder Email > Relay settings > Host-based relay de toegang tot specifieke mailservers, scanners of applicaties.

Brede host- of netwerktoestemmingen creëren een open-relayrisico. Als printers of applicaties e-mail moeten verzenden, documenteer ze als specifieke hostobjecten. Sophos Firewall-toegang beveiligen legt de basis van Device Access uit.

De Allow- en Block-lijsten volgen niet het principe dat Block altijd wint. Als dezelfde host of hetzelfde netwerk in beide lijsten bij Host-based relay of Upstream host staat, staat SFOS de relay toe. Verwijder zulke overlappingen vóór activering en voer een negatieve test uit vanaf een niet-toegestane bron.

Een toegestane host omzeilt ook de e-mailscan niet. Als SFOS een voor host-based relay toegestane bron-IP niet kan scannen, wordt deze geweigerd. Een relaytoestemming bewijst dus noch succesvolle inhoudscontrole noch aflevering; controleer beide met een echt testbericht en de MTA-logs.

De SMTP route and scan Policy ondersteunt geen SMTP AUTH. Voor apparaten is Host-based relay daarom de betrouwbare methode. Er zijn aparte Authenticated relay settings voor gebruikers en groepen; volgens Sophos ondersteunen die echter geen RFC-conforme SMTP Authentication-standaard, zodat clientcompatibiliteit moet worden getest. Dit verschilt van authenticatie van de firewall bij een upstream-smarthost, waarvoor SFOS PLAIN en LOGIN ondersteunt. Gebruik nooit een interface-IP van dezelfde firewall als smarthost, want dat veroorzaakt een routinglus.

Configureer bij uitgaande mail via een smarthost Email > General settings > Smarthost settings: selecteer Hostname, stel Port in (standaard 25) en schakel alleen als de server dit vereist Authenticate device with smarthost in en voer de inloggegevens veilig in. Dit routeert uitgaande mail via een tussenliggende MTA; het geeft clients geen relaytoestemming via de firewall. Stem TLS-eisen en de uiteindelijke publieke afzenderidentiteit af op die extra hop en leg de vorige instellingen vast voor rollback.

Upstream-relay en mailservers in de cloud

Upstream host onder Email > Relay settings bepaalt welke upstream-SMTP-bronnen inkomende mail mogen afleveren; Host-based relay bepaalt welke hosts uitgaande relay mogen gebruiken. Configureer deze scopes afzonderlijk. Als een andere gateway eerst de publieke mail ontvangt, neem dan diens werkelijke bronnetwerken op in de upstream-lijst, niet het adres van de doelmailserver. In beide secties gaan overeenkomende toestemmingen vóór overlappende blokkeringen.

Schakel voor een mailserver in de cloud SMTP Relay in voor de bronzone, doorgaans WAN, en beperk uitgaande host-based relay tot de werkelijke bronadressen van de server. Ook de cloudserver moet de bedoelde relayverbinding met de firewall toestaan. Houd de publieke MX naar de firewall gescheiden van het afleverdoel dat SFOS resolveert: de cloudprocedure noemt beide MX-doelen zonder de DNS-scheiding uit te leggen. Gebruik een afzonderlijke DNS-host, een statisch doel of bewust beheerde split-DNS; Route by MX mag mail nooit terugsturen naar de firewall.

De cloudprocedure raadt ook aan naar Legacy en terug te schakelen als de automatische regel ontbreekt. Dit verwijdert en hermaakt de regel en verandert de actieve mailverwerking. Gebruik dit niet als ongeplande reparatie: leg eerst policies, wachtrijen en het fallbackpad vast en onderzoek de ontbrekende regel met support. Een goedgekeurde moduswijziging hoort in een onderhoudsvenster, met nieuwe inkomende, uitgaande en negatieve relaytests.

De oudere cloud- en financiële-data-voorbeelden vragen de uitgaande servernaam als SMTP hostname, terwijl de nieuwere MTA-configuratie het domein vraagt, niet de mailserver-hostname. Volg de nieuwere domeinrichtlijn voor systeemmeldingen; deze instelling bepaalt niet de identiteit van elk doorgestuurd bericht. Inkomende DKIM-verificatie gebruikt eveneens de publieke DNS-sleutel van de afzender en vereist geen eigen uitgaande ondertekeningssleutel alleen omdat het MTA-overzicht ondertekening naast verificatie noemt.

Meerdere WAN-interfaces of alias-IP-adressen

De MTA maakt de uitgaande SMTP-verbinding zelf. Wanneer meerdere openbare afzenderadressen mogelijk zijn, is een normale clientregel daarom niet voldoende. Sophos onderscheidt drie gevallen: bij één WAN-interface met meerdere alias-IP-adressen wordt een SNAT-regel met de gewenste openbare Translated source gemaakt. Bij meerdere WAN-interfaces zonder alias wordt een SD-WAN-route voor SMTP, SMTP(S) en SMTPS_465 gemaakt. Zijn meerdere WAN-interfaces en aliasadressen aanwezig, dan worden SNAT en de SD-WAN-route gecombineerd.

De SNAT-regel laat bestemming en service ongewijzigd, gebruikt de geplande WAN-lijn als uitgaande interface en vertaalt naar MASQ of het gewenste alias-IP. De SD-WAN-route gebruikt de internetgroep als bestemming, de drie SMTP-services en de geplande primaire gateway plus optioneel een backup. Een backup is alleen zinvol wanneer uitgaand TCP 25 daar werkelijk is toegestaan en ook dat openbare adres in het SPF-record van het maildomein staat.

Voor deze officiële multi-WAN-procedure vereist Sophos de route precedence static, vpn, sdwan_policyroute en wordt SD-WAN voor systeemgegenereerd verkeer ingeschakeld. Voer deze opdrachten uit in de Device Console (CLI-menuoptie 4), niet in Advanced Shell. Lees eerst beide beginwaarden, wijzig ze en controleer ze daarna opnieuw:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

Route precedence geldt globaal en is geen geïsoleerde mailschakelaar. Documenteer vóór de wijziging alle overlappende statische, VPN- en SD-WAN-paden en beide uitgelezen waarden. Herstel bij rollback de volledige vorige volgorde met system route_precedence set ... en zet system-generate-traffic terug naar de oorspronkelijke status enable of disable. Controleer daarna niet alleen SMTP-tellers, maar ook het werkelijk gebruikte bron-IP-adres, de aflevering, het SPF-resultaat en uitval van de primaire gateway. SD-WAN-routing voor systeemgegenereerd verkeer controleren beschrijft de algemene veiligheids- en rollbackprocedure.

Voor de SD-WAN-route voorkomt Route only through specified gateways bewust fallback naar andere gateways: als de geselecteerde gateways onbereikbaar zijn, laat de firewall het verkeer vallen. Bepaal of dit beter is dan een ongepland afzender-IP en test dat storingspad. Kies IPv4- of IPv6-objecten die bij het werkelijk gepubliceerde mailpad passen; kopieer geen IPv4-internetgroep naar een IPv6-ontwerp.

6. Het MX-record wijzigen

Wijzig het openbare MX-record pas naar het firewalladres nadat MTA-regel, domein, policy, relay en intern afleverpad gereed zijn. Stuur direct een extern testbericht en controleer of het in Log Viewer of Mail logs verschijnt, bij de interne server wordt afgeleverd en de mailbox bereikt.

Als externe afzenders de firewall niet bereiken of legitieme berichten breed worden geweigerd, herstel dan het gedocumenteerde oude mailpad. Door DNS-caches is deze rollback niet overal direct actief. Houd daarom zowel het oude als het nieuwe pad parallel operationeel en bewaak beide totdat ten minste de langste eerder geldige TTL is verstreken. Als de firewall berichten aanneemt maar niet aflevert, controleer eerst routing, DNS, TLS, recipient verification en mailserverlogs.

Bescherming bewust kiezen

Acties voor spam, malware en gevoelige gegevens

Kies voor inkomende spam, waarschijnlijke spam en bulkmail expliciet de actie: None levert ongewijzigd af, Warn voegt het ingestelde onderwerpvoorvoegsel toe, Quarantine houdt het bericht vast en Drop verwijdert het zonder de afzender te informeren. Stel de onderwerpvoorvoegsels voor spam en bulkmail naar behoefte in. Deze keuzes vervangen de afzonderlijke SPF/RBL-afwijzing niet.

Voor malware biedt Selected antivirus action de opties None, Drop en Quarantine; configureer Notify sender afzonderlijk. Quarantine unscannable content betreft niet-inspecteerbare inhoud, waaronder beschadigde, versleutelde of gecomprimeerde bestanden, te grote berichten en interne scanfouten. Een voltooide aflevering bewijst niet dat alle bijlagen zijn gescand. Zero-Day Protection heeft een eigen maximale analysegrootte: grotere bestanden worden door die dienst niet geanalyseerd. Test die grens afzonderlijk van de globale SMTP-grootte en de verwijderlimieten van File protection.

Selecteer onder Data protection de exacte Data control list, de actie en indien van toepassing het SPX template: Accept levert af, Accept with SPX versleutelt en levert af, en Drop verwijdert zonder melding. Notify sender is een afzonderlijke keuze. Een SPX-toewijzing op domeinniveau versleutelt alle overeenkomende uitgaande mail; gebruik een Data Control-trigger als alleen overeenkomsten met financiële gegevens moeten worden versleuteld. Het voorbeeld met een ontvangerswachtwoord gebruikt Specified by recipient en houdt het bericht vast tot de wachtwoordregistratie. Configureer template, Reply Portal en registratiepad samen in het gekoppelde SPX-runbook en test een overeenkomend en een niet-overeenkomend bericht, in plaats van alleen Data protection in te schakelen.

Eigen bestandstypen en Data Control Lists gebruiken

In MTA mode wordt een eigen bestandstype onder Email > Policies and exceptions > File type > Add gemaakt op basis van een template, bestandsextensies of MIME-typen. Voer extensies zonder voorafgaande punt in. Alleen eigen bestandstypen zijn bewerkbaar. Een nieuw type wordt ook niet automatisch aan bestaande policies toegevoegd: open de betreffende SMTP route and scan Policy, voeg het onder File protection toe en sla de policy opnieuw op. Een positieve bijlagetest en een vergelijkbare negatieve test bewijzen de match betrouwbaarder dan alleen de objectnaam.

Onder File protection > Block file types blokkeert All e-mails met bijlagen; dit betekent niet alle bijlagen scannen. None staat bijlagen toe binnen deze bestandsfilterinstelling, maar omzeilt geen malware-, spam-, Data Protection- of andere controles. Volgens de policyhelp vullen geselecteerde MIME-headers de MIME whitelist: deze typen worden toegestaan en de overige geblokkeerd. MIME-headers en extensies bewijzen geen onschadelijke inhoud. Controleer toegestane en geblokkeerde bijlagen op de gebruikte build voordat u een precies whitelistrecept toepast.

Een Data Control List bestaat uit Content Control Lists, afgekort CCL’s, voor gedefinieerde inhoudstypen zoals financiële of persoonsgegevens. Filter bij het toevoegen onder Email > Data control list > Add de CCL’s op Type en Region en selecteer alleen wat werkelijk nodig is. De actie wordt pas in de gekoppelde policy bepaald. Test één gecontroleerde match en vergelijkbare inhoud zonder match om te bevestigen dat match en actie samenwerken zonder onnodige false positives.

Spam protection is meer dan de actie voor spam. Berichten die bij de SPF- of RBL-controle worden afgewezen, worden direct geweigerd en volgen niet de normale acties voor spam of probable spam. Greylisting weigert een bericht bewust tijdelijk en vereist dat de verzendende server opnieuw probeert.

Voor Reject based on BATV moet eerst onder Email > General settings > Advanced SMTP settings een gedeeld BATV secret zijn ingesteld. Gebruik hetzelfde secret op meerdere eigen MX-systemen. SFOS combineert dit met de tijdstempel en het afzenderadres tot de Return-Path-handtekening, die na zeven dagen verloopt. Vergelijk een BATV-fout daarom met het secret, de systeemtijd, het afzenderpad en de leeftijd van de handtekening in plaats van deze met een onbeperkte brede uitzondering te verbergen.

Recipient verification voorkomt berichten aan onbekende ontvangers:

• With callout: vraagt de doelmailserver. Als die tijdelijk niet beschikbaar is, accepteert SFOS ontvangers na een ingestelde periode in plaats van de hele mailflow blijvend te blokkeren.
• In Active Directory: controleert via Simple, SSL of STARTTLS met een timeout van 30 seconden. Geef de AD-server, Bind DN en Base DN op. Bind DN is de volledige distinguished name, inclusief de CN van de ingestelde bind-identiteit; Base DN is het startpunt voor directoryzoekopdrachten. Gebruik waarden die bij uw directory passen. Het beheerdersvoorbeeld uit de help bewijst niet dat Domain Admin-rechten nodig zijn. Kies een transport dat aan het gebruikte vertrouwens- en beveiligingsbeleid voldoet; het label SSL of STARTTLS alleen bewijst geen geslaagde certificaatvalidatie.

Malware Protection kan één of twee antivirusscans gebruiken. Voor Zero-Day Protection met één scan moet Sophos de primaire engine zijn. Sophos Firewall Zero-Day Protection legt grenzen en vrijgavebeslissingen uit.

Volgens de SFOS 22/23-policyhelp selecteert Single antivirus de primaire engine alleen voor inkomende mail; uitgaande mail gebruikt beide engines. Dual antivirus scant eerst met de primaire en daarna met de secundaire engine. Selecteer de primaire engine, Sophos of Avira, globaal onder Email > General settings. Avira kiezen schakelt Zero-day protection uit in SMTP-policies met één antivirusscan; Sophos moet primair zijn om Zero-Day Protection met één scan te gebruiken. De help voor algemene instellingen beschrijft één scan als alleen de primaire engine, zonder het richtingsonderscheid van de policytabel. Dit documentatieverschil bewijst geen waargenomen enginegebruik: controleer build, policy, mailrichting en beschermingsstatus vóór en na een wijziging. Leg de vorige instellingen vast; herstel van de enginekeuze bewijst niet dat Zero-day protection opnieuw is ingeschakeld.

De policygrens Drop message greater than onder File protection is niet hetzelfde als het globale gedrag voor te grote berichten: grotere berichten worden op dit punt verwijderd. SFOS controleert ook zichtbare inhoud en inhoud in verpakte formaten zoals docx, xlsx, pptx, odt, ods, odp en odg. Een positieve test met alleen een onverpakt tekstbestand bewijst daarom niet hoe dezelfde informatie in een Office-document wordt behandeld.

Als DKIM verification is ingeschakeld, onderscheidt SFOS een niet-overeenkomende hash, een ongeldige handtekening of niet-beschikbare openbare sleutel en een ontbrekende DKIM-handtekening. Voor elk resultaat zijn Accept, Quarantine en Reject beschikbaar. Volgens Sophos worden DKIM-ondertekende berichten met RSA-SHA1 of een sleutellengte buiten 1024 tot 4096 bits in quarantaine geplaatst. Test deze inkomende controle los van uitgaande ondertekening.

Bij uitgaande berichten is de verwerkingsvolgorde belangrijk. SPX-encryptie, onderwerpprefixen, File of Data Protection en uitgaande banners kunnen header of body wijzigen nadat een DKIM-handtekening is geplaatst. DKIM-validatie mislukt dan bij de ontvanger. Bepaal daarom of de interne mailserver, Sophos Firewall of een latere gateway ondertekent.

Uitgaande berichten op de firewall met DKIM ondertekenen

Als Sophos Firewall zelf moet ondertekenen, wordt onder Email > General settings > DKIM signing > Add voor elk afzenderdomein een handtekening toegevoegd. Domain is de FQDN van het maildomein; Key selector is exact de selector die daarna in het openbare DNS wordt gepubliceerd. Een naam zoals fw01 of zurich maakt latere sleutelrotaties begrijpelijker, maar is geen beveiligingsfunctie.

SFOS verwacht een private RSA-sleutel van 1024 tot 2048 bit tussen -----BEGIN RSA PRIVATE KEY----- en -----END RSA PRIVATE KEY-----. Voor nieuwe configuraties is 2048 bit de verstandige keuze. Gebruik geen RSA-SHA1. Volgens Sophos accepteert de firewall geen 1024-bits sleutel die met PuTTYgen is gegenereerd; kies daar dus eveneens 2048 bit. De private sleutel hoort uitsluitend op de firewall en nooit in DNS, tickets of openbare documentatie.

Na het opslaan wordt bij de autoritatieve DNS-provider het DKIM-TXT-record voor de selector met de publieke sleutel gepubliceerd. Pas wanneer dit record extern kan worden opgezocht, wordt een nieuw testbericht via het bedoelde uitgaande MTA-pad verzonden. De ontvangen header moet de verwachte selector en het domein bevatten en de DKIM-controle bij de ontvanger moet slagen. Ontbreekt de handtekening, controleer dan het afzenderdomein, de policymatch en Scan outgoing mails. Mislukt de controle, vergelijk dan eerst het DNS-record, de selector, de gebruikte sleutel en latere wijzigingen door SPX, banners, File Protection of Data Protection.

SPX-e-mailversleuteling configureren en testen legt uit hoe template, triggerprioriteit, wachtwoordmodel en Reply Portal samenwerken.

MTA-instellingen veilig automatiseren via de XML API

Voor automatisering blijven globale instellingen, Address Groups en SMTP-policies afzonderlijke doelen. Lees eerst de build, de actieve mailmodus, de opgeslagen waarden en de afhankelijke policies uit; bereid een back-up en een gericht rollbackpad voor. Verstuur de bevestigde request met een expliciete operatie alleen voor het benodigde doel. Vergelijk daarna de operatierespons, de opnieuw uitgelezen toestand en de bijbehorende mailflowtest. Lees ook na een fout of timeout eerst uit of er al iets is opgeslagen, in plaats van de schrijfrequest blind te herhalen. XML API-toegang beveiligen legt toegang, opslag van secrets en verwerking van responses uit.

De SFOS-22/23-objectreferenties zijn geen kant-en-klare productiepayloads. XML-voorbeelden, parametertabellen en WebAdmin-help kunnen verschillende schrijfwijzen, waarden of standaardwaarden vermelden. Lege cellen voor standaardwaarden of Any bevestigen noch een veilige lege waarde, noch het gedrag van weggelaten velden. Niet-opgeloste $EMAILPROTECTION{…}-constanten zijn geen bevestigde API-literals. Stop vóór het schrijven als de syntaxis, operatie of werking onduidelijk is en raadpleeg de API help van de geïnstalleerde build of vraag om officiële verduidelijking. Documentatieverschillen alleen bewijzen geen productwijziging.

Globale SMTP-, TLS- en relayinstellingen uit elkaar houden

Bij EmailConfiguration horen de SMTP-scanlimiet en DoS-waarden onder SMTPSSettings, en de afzonderlijke POP/IMAP-waarden onder POPIMAPSettings. Koppel het gelijknamige DontScanEmailsGreaterThan niet aan het verkeerde protocol. RecipientHeaders met herhaalde Header betreft de herkenning van POP/IMAP-ontvangers, niet SMTP-routing. Banners staan onder GeneralSettings. Ook SMTPTLSConfiguration en POPSIMAPTLSConfiguration zijn afzonderlijke contexten: TLSCertificate, AllowInvalidCertificate en DisableTLS1 kunnen niet eenduidig worden geadresseerd met één veldnaam zonder contextaanduiding. Een SMTP-uitzondering mag niet ongemerkt ook POP/IMAP minder strikt maken. Lees na het opslaan beide contexten afzonderlijk opnieuw uit en test alleen het bedoelde mailpad.

BypassSpamCheck onder SMTPSSettings beschrijft volgens de API-tabel het omzeilen van de spamscan voor geauthenticeerd verkeer. De tabel vermeldt de standaardwaarde Disable, maar het XML-voorbeeld stelt Enable in. Neem het voorbeeld niet over als een veilige standaardconfiguratie: verduidelijk vóór een wijziging welk verkeer in de betreffende build als geauthenticeerd geldt en welke spamcontrole wordt omzeild. Beperk een bedoelde uitzondering strikt en controleer het effect ervan op overeenkomende en niet-overeenkomende berichten; beschouw andere scansecties niet als automatisch uitgezonderd.

De herkomst van de SMTP-getallen is belangrijk: de API-tabel vermeldt voor DontScanEmailsGreaterThan 1024 KB, voor MaximumConnections 5000 binnen het bereik 1–20000 en voor MaximumConnectionsHost 100 binnen het bereik 1–10000. Voor MaximumEmailsConnection vermeldt deze de standaardwaarde 100, maar het XML-voorbeeld bevat 1000; de WebAdmin-help vermeldt eveneens 1000. MaximumRecepientsEmail is de schrijfwijze uit de bron, met standaardwaarde 100 en bereik 1–512. Voor EmailsRate en ConnectionsRate vermeldt de API-tabel standaardwaarden van 1000 en 100, beide met bereik 1–20000; de WebAdmin-help beperkt de snelheden daarentegen tot respectievelijk 1–1000 per minuut en 1–100 per seconde en bepaalt de verbindingsmaxima op basis van de hardware. Neem daarom noch tabelmaxima over als actuele UI-grenzen, noch voorbeeldwaarden als standaardwaarden. De hierboven beschreven WebAdmin-limieten en de upgradecontrole blijven leidend voor deze procedure; automatiseringen moeten de daadwerkelijk opgeslagen waarden van de build vergelijken.

Andere syntaxisconflicten verhinderen een blinde import van voorbeelden: VerifySendersIPReputation bevat in het XML-voorbeeld Enable, maar de API-tabel vermeldt on/off met standaardwaarde Disable; SMTPSDosSettings wordt daar beschreven als integer met standaardwaarde Disable, maar bevat in het voorbeeld Enable. Bij de banner staan voorbeeldteksten tegenover de tabelwaarden inline_plain, mimepart, off. ‘Repareer’ deze gegevens niet zelf, maar bevestig de geldige schrijfwijze en waarden vóór een request. Houd afzonderlijk rekening met de bestaande opmerking over Email Configuration, status 506.

AdvancedSMTPSetting is eveneens globaal. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks en ScanOutboundEmails sturen de hierboven uitgelegde HELO/RDNS-controles en controles voor uitgaande mail aan. FirewallRelateInboundMails betreft het afzonderlijke gateway-/firewallregelpad; het voorbeeld vermeldt Disable, de tabel Turn on/Turn off. Voor het BATV-secret bevat het voorbeeld BATVSecret, maar de tabel BATVsecret. Bevestig hoofdlettergebruik en geldige waarden vóór het schrijven en presenteer geen van deze varianten als een geteste payload. Gebruik het gedeelde secret uit beveiligde opslag en kopieer noch het voorbeeldsecret, noch het secret naar een ticket, repository of requestlog. Plan secretwijzigingen voor alle betrokken MX-systemen en controleer daarna BATV en normale verzending.

In RelaySettings hebben HostBased en UpstreamHost elk hun eigen AllowRelay- en BlockRelay-lijsten. Daaronder staan HostsOrNetworks en herhaalde HostsOrNetwork-vermeldingen. Dezelfde naam van een bladelement betekent dus niet dezelfde relayscope. AuthenticatedRelaySettings bevat afzonderlijk AuthenticatedRelay en UsersOrGroups met UsersOrGroup. De open groepen of gastgroepen in het voorbeeld van de fabrikant zijn geen veilige keuze. Gebruik alleen de geplande identiteiten en hostobjecten, verwijder overlappingen tussen de lijsten en controleer daarna toegestane verzending en niet-toegestane relay vanaf een afzonderlijke bron.

Bij SmarthostSettings activeert UseSmarthost de uitgaande tussenhop; SmarthostList met herhaalde Hostname selecteert de doelen, Port de doelpoort. De API-tabel vermeldt 1–65535, maar geen standaardpoort; 25 staat in het voorbeeld en als standaardwaarde in de WebAdmin-help. AuthenticateDevicewithSmarthost staat hiervan los: lever Username en Password alleen veilig aan als aanmelding nodig is. De API-tabel vermeldt voor beide activeringsschakelaars standaard Disable, terwijl het voorbeeld beide activeert. passwordform="encrypt" is de wachtwoordsyntaxis van het voorbeeld, geen toestemming om versleutelde waarden van een andere firewall opnieuw te gebruiken. Stop de request als de herkomst of importvereisten onduidelijk zijn. Controleer vervolgens doel, TLS, authenticatie en aflevering via deze hop, niet alleen de relaytoestemming.

Address Groups en SMTP-policies gericht wijzigen

Voor de MTA is het voorbeeldobject MTAAddressGroup bedoeld, niet het gelijksoortig benoemde AVASAddressGroup uit de andere mailcontext. Name identificeert de groep. GroupType bepaalt de bijbehorende lijst: de API-tabel onderscheidt RBLIPv4, RBLIPv6, IPAddress en EmailAddressOrDomain en de invoervelden RBLName, IPAddressNetwork en EmailAddressDomain. Het maildomeinvoorbeeld gebruikt EmailAddressList met herhaalde EmailAddressDomain en EmailImportType ingesteld op Manual. Verduidelijk voor Import en EmailAddressFile welke bestandsupload bij de build past: de beschrijving koppelt het bestandsveld op tegenstrijdige wijze aan handmatige import. Een succesvolle HTTP-respons bevestigt noch alle geïmporteerde vermeldingen, noch de uiteindelijke groepssamenstelling. Lees het aantal, de overgeslagen vermeldingen en de concrete domeinwaarden opnieuw uit voordat een policy de groep gebruikt.

Bij Delete Address Group bevatten de SFOS-22/23-pagina’s statusregels, maar geen parameterdefinitie en geen verwijdervoorbeeld. Daaruit kan noch de exacte objectidentiteit voor Remove, noch een werkende request worden afgeleid. Zet niet zomaar Name of het aanmaakobject in een Remove-payload. Controleer eerst waar de groep wordt gebruikt in mail-, spam- en archiveringsconfiguraties; haal de exacte operatie en de volledige bijbehorende request uit de geïnstalleerde API help of verkrijg officiële verduidelijking. Voer tot die tijd geen automatische verwijdering uit. Controleer na een goedgekeurde verwijdering opnieuw of precies de bedoelde groep is verwijderd en of benodigde referenties en mailflow intact zijn.

Bij SMTPPolicy is Name de policy-identiteit; DomainList met DomainName koppelt de beschermde domeinen. RouteBy, DNSHostName en RouteList met HostName, routingid en routingorder beschrijven verschillende afleverpaden, niet extra domeinnamen. De API-tabel vermeldt MX als standaardwaarde voor de route, maar het voorbeeld bevat alternatieve routeteksten in plaats van één waarde. Controleer de routing vooraf tegen de daadwerkelijke DNS-resolutie, zodat er geen lus naar de firewall ontstaat.

De geneste secties SpamProtection, MalwareProtection, FiletypeFilter en DataProtection hebben onafhankelijke statusvelden. De API-tabel vermeldt hiervoor standaard OFF, hoewel het voorbeeld ze op ON zet. Een globale actie Accept activeert dus niet automatisch alle controles. Ook zijn het SPX-veld op domeinniveau SPXEncryption en het matchgerelateerde DataProtectionSPXTemplate niet onderling uitwisselbaar; DataProtectionPolicy moet verwijzen naar een bestaande, passende Data Control List. Controleer vooraf de voorwaarden voor engines, Zero-Day en BATV en het SPX-wachtwoordmodel. De tabel beschrijft ontvangerverificatie als uitgaand, de WebAdmin-help als inkomend; leid hieruit geen nieuwe controlerichting af. Richtingsgebonden positieve en negatieve tests en opgeslagen policywaarden bepalen of het geplande beschermingsconcept is geïmplementeerd.

Voor de Data Control List toont het XML-voorbeeld MTADataControlList, met daarin Name en Signatures met herhaalde Signature. De tabellabels name en signaturename zijn geen bevestigde instructie om deze in kleine letters als XML-tags te serialiseren. Bevestig vooraf MTA Mode, lees de beschikbare signatures uit en kies alleen passende CCL’s. De lijst alleen creëert geen beschermingsactie: pas de koppeling via DataProtectionPolicy en de actie in de SMTP-policy implementeren het concept. Lees daarna de lijst en de koppeling opnieuw uit en test een gecontroleerde match en een vergelijkbaar geval zonder match.

DKIM en uitzonderingen niet gelijkstellen aan routing

Bij DKIMVerification stuurt VerifactionStatus, dat in het voorbeeld daadwerkelijk zo is gespeld, de activering aan. ActionForVerifactionFail is een andere selector dan ActionForSignatureInvalid of ActionForSignatureNotFound: de eerste betreft fouten bij hash-/handtekeningverificatie, de tweede een ontbrekende of syntactisch ongeldige openbare DNS-sleutel en de derde een ontbrekende handtekening. Corrigeer de spelfouten in de eerste twee tags niet stilzwijgend. Het XML-voorbeeld vermeldt Pass, maar de parametertabel en WebAdmin-help vermelden Accept naast Quarantine en Reject. Dit bevestigt niet dat de API-waarden onderling uitwisselbaar zijn; verduidelijk vóór een request het API-contract van de build en test alle drie de inkomende gevallen afzonderlijk.

Bij DKIMSigning identificeert Domain het ondertekeningsdomein, niet Name; de verwijderreferentie vereist eveneens Domain. Bij het aanmaken en wijzigen zijn KeySelector en PrivateRSAKey verplichte velden. Volgens de WebAdmin-help kan een domein meerdere handtekeningen hebben, terwijl de verwijderreferentie alleen het domein vermeldt: verduidelijk bij meerdere selectors vooraf de exacte omvang van de verwijdering en neem niet aan dat verwijderen per selector mogelijk is. Bewaar private sleutels en API-inloggegevens beveiligd en verwijder ze uit responses en logs; controleer daarna DNS en de nieuw ontvangen handtekening zoals hierboven beschreven.

De globale lijst voor inkomende mail gebruikt MtaBlockedSenders met BlockedEmailAddresses en herhaalde EmailAddress; de API-tabel staat afzonderlijke adressen of wildcarddomeinen zoals *@example.com toe. Deze lijst vervangt geen volledige antispampolicy en geldt in de hier beschreven MTA-context alleen voor inkomende berichten. Lees vóór een wijziging de scope en bestaande vermeldingen uit en test daarna een overeenkomende en een niet-overeenkomende afzender.

Los daarvan beschrijft de API AntiSpamTrustedDomain met DomainList en herhaalde DomainName als uitzondering om mailscanning voor vertrouwde domeinen te omzeilen. Deze bron legt niet vast welke scanners precies worden omzeild. Verzin daarom geen GUI-pad, geef geen garantie dat ‘alle scans uit’ zijn en verwar Trusted Domains niet met beschermde routingdomeinen. Verduidelijk vóór het aanmaken of verwijderen de exacte domeinlijst, de benodigde uitzondering en het effect op scans op de geïnstalleerde build; beperk de uitzondering strikt en controleer deze met een reviewdatum en overeenkomende en niet-overeenkomende berichten.

Voor Delete Trusted Domain vermeldt de parametertabel DomainName als een verplichte array met meerdere mogelijke waarden, maar geeft deze geen verwijdervoorbeeld. Neem de geneste structuur van het Add-voorbeeld daarom niet zonder controle over als verwijderrequest; bevestig vooraf de doelwaarden en de volledige requeststructuur in de geïnstalleerde API help of via officiële verduidelijking.

De globale engineselector is MalwareProtection met PrimaryAntiVirusEngine, in de API-tabel standaard Sophos. Dit is niet het gelijknamige geneste policy-element en schakelt niet zelf de scansecties in. Controleer de gevolgen voor single-/dual-scanning en Zero-Day Protection zoals hierboven beschreven vóór en na een wijziging in de betrokken policies.

Objectspecifieke responses als diagnosehulp

De volgende koppelingen zijn afkomstig uit de SFOS-22/23-statusregels. Getallen zijn XML-operatiecodes, geen HTTP-codes; Message.* zijn niet-opgeloste bronsleutels, geen bevestigde meldingsteksten of eenduidige foutoorzaken. De algemene API-veiligheidsregels hierboven gelden ook hier: vergelijk vóór elke retry de daadwerkelijke respons en de opgeslagen toestand, verwijder afhankelijkheden niet op basis van vermoedens en stop als een gedeeltelijke toestand onduidelijk is.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. De laatste drie regels maken controle van het importresultaat extra belangrijk; neem niet aan dat het hele bestand is verworpen of overgenomen. Edit Address Group vermeldt in deze bronnen alleen 200 → Message.AddrGrpUpdateSuccess en 500 → Message.AddrGrpUpdateFail; presenteer de Add-codes niet als gedocumenteerde Edit-responses.
• Delete Address Group: 504, 505 en 506 verwijzen elk naar Message.AddrGrpForeignKeyExists; 507 naar Message.AddrGrpEmailArcKeyExists. Dezelfde symboolkoppeling bepaalt niet welke referentie betrokken is. Controleer het gebruik en welke groepen daadwerkelijk aanwezig zijn; deze responses vervangen het ontbrekende verwijdercontract niet.
• Add Data Control List en Update Data Control List: elk 502 → Message.DLPAddSameName en 545 → Message.MTAModeDisableCheck. De Update-sleutel bevat eveneens ‘Add’; hernoem deze niet. Controleer namen, modus en de opgeslagen lijst zonder alleen op basis van de sleutel een oorzaak vast te stellen.
• Add SMTP Policy en Edit SMTP Policy: elk 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck en 545 → Message.MTAModeDisableCheck. Alleen Add SMTP Policy vermeldt 502 → Message.SMTPProfileduplicateName. Bij 543 onderscheidt de bron Message.SMTPProfileSenderGenSPXAdd voor Add en Message.SMTPProfileSenderGenSPXEdit voor Edit. Controleer domeinkoppelingen, namen, modus en SPX-afhankelijkheden tegen de werkelijke toestand; activeer geen automatische hernoeming of versoepeling van de bescherming.
• Email Configuration: 505 → Message.ASConfigSubOperationFail staat in beide versies. Lees vóór een retry alle betrokken SMTP-, POP/IMAP- en TLS-subsecties opnieuw uit en neem geen volledig succes of volledige rollback aan. De aanvullende SFOS-23-regel 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname blijft onder de hierboven genoemde kwalificaties vallen.

Mailflow valideren

Voer de volgende opdrachten uit vanaf een systeem buiten het eigen netwerk:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Vervang example.com en mail.example.com door de echte waarden. De opdrachten testen DNS, TCP 25 en STARTTLS, maar niet de relayautorisatie of volledige aflevering. openssl s_client blijft na de handshake interactief; stop met Ctrl+C.

Test minimaal deze gevallen:

• extern bericht aan een geldige ontvanger;
• bij ingeschakelde Recipient verification een extern bericht aan een ongeldige ontvanger;
• uitgaand bericht via de bedoelde mailserver;
• spam- of malwaretest passend bij de policy;
• STARTTLS en de getoonde certificaatketen;
• quarantaineactie en aflevering na vrijgave;
• geblokkeerde relaypoging vanaf een niet-toegestane bron;
• geen directe aflevering die de MTA via een oude DNAT-regel omzeilt.

Leg alleen waargenomen acceptatieresultaten vast: het geldige testbericht moet in Mail logs als Delivered staan en via de Message-ID tot in de doelmailbox te volgen zijn. Verwacht alleen dat de ongeldige ontvanger wordt geweigerd als ontvangerverificatie is ingeschakeld, de geselecteerde verificatiemethode via een bereikbaar gezaghebbend verificatiepad werkt en weigering is geconfigureerd. Maak bij With callout onderscheid tussen deze negatieve test en de gedocumenteerde uitzondering: SFOS accepteert ontvangers wanneer de doelmailserver gedurende een bepaalde periode onbereikbaar is. De documentatie vermeldt niet hoelang die periode is; neem niet aan dat dezelfde uitzondering geldt voor In Active Directory. Als de verificatie is uitgeschakeld, is een weigering niet het verwachte resultaat van deze negatieve test. De niet-toegestane relaypoging mag geen bericht creëren en het vrijgeven uit quarantaine moet voor dezelfde Message-ID een daaropvolgende aflevering tonen.

Gebruik voor de eerste controle Email > Mail logs, Email > Mail spool, Email > SMTP quarantine en Log Viewer. Noteer voor diepere analyse testtijd, afzender, ontvanger, onderwerp, bron-IP en Message-ID en correleer deze met:

• MTA: smtpd_main.log
• weigeringen: smtpd_reject.log
• scanfouten: smtpd_error.log
• interne MTA-fouten: smtpd_panic.log
• anti-spam: sasi.log
• legacy SMTP-proxy: awarrensmtp.log
• POP/IMAP-proxy: warren.log

Sophos Firewall-services en logs legt de koppeling en toegang via Advanced Shell uit.

In Mail logs geeft Result de afleverstatus aan, terwijl Reason de scan- of policyreden beschrijft. Rejected betekent dat SFOS het bericht heeft verwijderd en de afzender heeft geïnformeerd. Dropped verwijdert het zonder melding; Bounced verschijnt na meerdere mislukte afleverpogingen. Deze statussen zijn niet gelijkwaardig, omdat ze verschillende feedback en diagnosepaden opleveren. Andere resultaten zijn Delivered, Quarantined en handmatig Deleted; redenen kunnen onder meer worden gefilterd op Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM en BATV.

Quarantaine en Mail spool beheren

Filter onder Email > SMTP quarantine op periode, afzender, ontvanger, onderwerp en quarantainereden:

• Release: het bericht vrijgeven.
• Delete: het bericht verwijderen.
• Release and report: alleen false positives met classificatie Spam of Probable spam vrijgeven en aan SophosLabs melden.

Met virus geïnfecteerde berichten en door Zero-Day Protection als schadelijk geclassificeerde berichten kunnen niet worden vrijgegeven. Voor het verwijderen van Zero-Day Protection-items heeft het adminprofiel schrijfrechten nodig. Wanneer de quarantaine vol is, worden oude berichten opgeschoond.

Alleen gebruikers die zich minstens eenmaal bij de firewall hebben geauthenticeerd ontvangen quarantainedigests. Standaard past SFOS de digestinstellingen niet toe op aliasadressen; wijs ze samen met het primaire adres toe onder Email > Quarantine settings > Change user’s quarantine digest settings of in het gebruikersobject. De digest kan dan spam voor primaire en aliasadressen bevatten. Berichten aan aliassen verschijnen nog steeds niet in User Portal zelf.

Sophos Firewall quarantainedigest instellen en testen beschrijft configuratie, gebruikerstoewijzing, de vrijgavelink en de volledige functietest.

Email > Mail spool bevat nog niet afgeleverde of mislukte berichten. SFOS probeert drie dagen opnieuw en verwijdert berichten na nog eens vier dagen; verwijderde berichten blijven in Mail logs zichtbaar. Een groeiende spool waarschuwt dus voor routing-, DNS-, TLS-, policy- of mailserverproblemen en is geen reden om zonder diagnose herhaaldelijk Retry te kiezen.

Het statusfilter onderscheidt Queued, Failed, SPX blocked, Zero-day protection en Error. SPX blocked wacht totdat de ontvanger een wachtwoord maakt; Zero-day protection wacht op de analyse. Alleen berichten in de error queue kunnen worden gedownload of verwijderd. Voor het verwijderen of opnieuw verzenden van Zero-Day Protection-berichten heeft het administratorprofiel lees- en schrijfrechten voor Zero-Day Protection Activity nodig. Ontbreekt een knop, controleer dan eerst status en profiel in plaats van de beperking met een serviceherstart te omzeilen.

Quarantaine en spool gebruiken lokale opslag. Bewaak vrije ruimte, SSD-status en System Health; zie Opslag en reports opschonen en SSD Health controleren. In HA zijn logs en reports per node gescheiden en niet gesynchroniseerd; controleer beide nodes. Sophos Firewall HA-clusters behandelt de basis.

Troubleshooting

Externe e-mail komt niet aan

Controleer MX, A/AAAA, openbaar IP, TCP 25 en SMTP Relay vanuit WAN. Controleer daarna of MTA mode actief is, het beschermde domein bij de policy past en geen oude DNAT- of hoger geplaatste regel het verwachte pad wijzigt. Als smtpd_main.log geen verbinding toont, ligt het probleem waarschijnlijk vóór Mail Protection.

De firewall neemt aan maar levert niet af

Controleer interne mailserver, route, DNS, doelpoort, TLS en recipient verification. Static host, DNS host en MX gebruiken verschillende resolutie- en failoverpaden. Correleer reject- en errorlogs met de mailserverlogs.

Veel berichten blijven in de spool

Controleer eerst Email > Mail spool en de MTA-logs. Een veelvoorkomende oorzaak is een regel boven de automatische MTA-regel die SMTP al matcht. Controleer onder Rules and policies > Firewall rules nieuwe regels met positie Top, automatisch gemaakte IPsec- of hotspotregels en andere overlappingen. Verplaats niets blind; de werkelijke SMTP-match is doorslaggevend.

Pas nadat de nieuwe overlappende regel als oorzaak is bevestigd, wordt deze onder Rules and policies > Firewall rules zo ver naar beneden verplaatst dat de bedoelde SMTP-regel weer wordt geëvalueerd. Daarna worden de aflevering en de spool opnieuw gecontroleerd met een gecontroleerd bericht; andere benodigde verbindingen moeten hun bedoelde regels blijven gebruiken.

NC-177930 is opgelost in SFOS 22.0 MR2: berichten bleven na een crash van mailpoller in de spool staan. Neem bij een oudere versie de firmware op in de diagnose. Gebruik de SFOS 22-upgradecontrole om de doelbuild te kiezen, de wijziging voor te bereiden en daarna de mailflow opnieuw te testen.

Sophos Fusion meldt Invalid API request

In SFOS 22.0 MR1 konden Release en Delete mislukken wanneer de firewall via Sophos Fusion (voorheen Sophos Central) werd geopend. Het symptoom Invalid API request wordt bijgehouden als NC-182056; NC-181904 identificeert de correctie voor mislukte vrijgave via Sophos Fusion. De veilige workaround is rechtstreeks aanmelden bij de lokale WebAdmin en de actie uitvoeren onder Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 verhelpt het probleem. Controleer bij aanhoudende fouten adminprofiel, Sophos-Fusion-toegang en lokale rechten apart. Volg voor een update het volledige goedkeurings-, voorbereidings-, validatie- en troubleshootingproces in Sophos Firewall-firmware-update: voorbereiding en best practices.

Reject based on RBL kan niet worden ingeschakeld

NC-144563 is een versiespecifiek geval voor SFOS 20.0.2 MR2 Build 378: als de standaard RBL-groepen onder Email > Address group zijn hernoemd, kan Reject based on RBL niet worden ingeschakeld bij het maken van een SMTP route and scan-policy. In een bestaande policy kan de optie na het uitschakelen niet opnieuw worden ingeschakeld. Er is geen opgeloste versie gedocumenteerd.

De standaardgroepen heten Premium RBL services en Standard RBL services. Documenteer eerst de exacte build en de huidige groepsnamen. Als aan beide voorwaarden is voldaan, herstel dan de oorspronkelijke namen van de standaard-RBL’s, open de policy opnieuw en controleer de optie. Verwar aangepaste RBL’s niet met deze twee systeemgroepen.

Bij andere builds, of wanneer de standaardnamen niet zijn gewijzigd, bewijst een grijs weergegeven optie NC-144563 niet. Controleer het policytype, Spam protection, de Email Protection-licentie en de overige configuratie afzonderlijk.

Een legitieme afzender wordt als spam geclassificeerd

Controleer afzenderdomein, SPF/DKIM/DMARC, headers, reputatie, policy match en betrokken ontvangers. Maak pas daarna een smalle uitzondering met reviewdatum. E-mailuitzonderingen veilig maken en testen beschrijft de volledige procedure voor scope, tests en rollback.

Interne systemen kunnen niet relayen

Controleer bronzone onder Administration > Device access, hostobject onder Email > Relay settings > Host-based relay en MTA-logs. Als een scanner standaard SMTP AUTH verwacht, is Host-based relay meestal betrouwbaarder. Test de aparte, niet-RFC-conforme Authenticated relay met de specifieke client.

Operationele checklist

• Licentie, modelondersteuning, DNS en benodigde internetdiensten zijn gecontroleerd.
• MX, TTL, openbare en interne mailpaden en fallback zijn gedocumenteerd.
• De automatische MTA-regel is ongewijzigd en staat bovenaan.
• Geen oude DNAT-regel omzeilt Mail Protection.
• Address Group, routingdoel en policy match zijn getest.
• Inkomende SMTP Relay vanuit WAN en uitgaande hosttoestemmingen zijn correct gescheiden.
• Effecten van SPF/RBL, recipient verification, TLS, DKIM, SPX en banners zijn begrepen.
• Externe positieve en negatieve tests zijn uitgevoerd.
• Quarantaine, spool, opslag en logs worden bewaakt.
• Mailflow wordt na firmware-updates opnieuw getest.

Gebruik voor langere retentie en correlatie Central Firewall Reporting of stuur Sophos Firewall-logs naar een SIEM.

FAQ