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.

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.

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.

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

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. SPF- en RBL-fouten 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.

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. Bij ingeschakelde recipient verification moet de ongeldige ontvanger worden geweigerd; als de verificatie uitstaat, 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 afleveren.
• 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