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 Central Email of een andere cloudmailgateway meestal duidelijker. Twee gateways na elkaar maken quarantaine, headers, TLS, SPF/DKIM/DMARC en troubleshooting ingewikkelder.

Drie Sophos Firewall-functies moeten worden onderscheiden:

• MTA mode: de firewall neemt e-mail aan, controleert die en routeert die verder.
• Legacy mode: oudere transparante proxyverwerking voor bestaande omgevingen.
• 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.

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.
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 firewall valideert SMTP TLS bovendien aan de hand van het IP-adres van het domein in plaats van de domeinnaam. Meerdere domeinen op één IP kunnen daarom certificaatfouten veroorzaken.

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.

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 a 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.
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.

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 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.

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. Als de firewall berichten aanneemt maar niet aflevert, controleer eerst routing, DNS, TLS, recipient verification en mailserverlogs.

Bescherming bewust kiezen

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.

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.

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.

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.

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;
• 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.

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.

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. Controleer aliasadressen apart in het quarantaineontwerp; berichten aan aliassen verschijnen niet in User Portal.

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.

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.

SFOS 22.0 MR2 verhelpt ook NC-177930, waarbij berichten na een crash van mailpoller in de spool bleven. Neem bij een oudere versie de firmware op in de diagnose.

Central meldt Invalid API request

In SFOS 22.0 MR1 konden Release en Delete mislukken wanneer de firewall via Sophos Central werd geopend. De veilige workaround is rechtstreeks aanmelden bij de lokale WebAdmin en de actie uitvoeren onder Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 heeft dit opgelost. Controleer bij aanhoudende fouten adminprofiel, Central-toegang en lokale rechten apart.

Reject based on RBL kan niet worden ingeschakeld

Sophos vermeldt onder NC-144563 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. De huidige Known Issues List vermeldt geen fixversie.

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.

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