Konfigurera Sophos Firewall Mail Protection i MTA-läge

I MTA-läge tar Sophos Firewall själv emot e-post, kontrollerar den och levererar den till den interna e-postservern eller nästa e-posthopp. E-postflödet fungerar bara när MX-posten, den automatiska MTA-regeln, SMTP route and scan-policyn, relä, TLS och mottagarverifiering samverkar.

Konfigurationen består av sex steg: definiera e-postflödet och reservvägen, aktivera MTA-läge, lägg till e-postdomänen, skapa route and scan-policyn, säkra reläåtkomsten och ändra MX-posten. Validera därefter inkommande och utgående e-postflöde med externa kommandon, karantän, spool och loggar.

När MTA-läge passar

Mail Protection på brandväggen är främst användbart i medvetet utformade lokala miljöer och hybridmiljöer där en lokal Exchange-server eller en annan e-postserver ska skyddas. För Microsoft 365, Google Workspace och många rena molnmiljöer är Sophos Email eller en annan molnbaserad e-postgateway oftast den tydligare arkitekturen. Två e-postgatewayer efter varandra komplicerar karantän, headers, TLS, SPF/DKIM/DMARC och felsökning.

Om Exchange Online medvetet ska använda brandväggens MTA beskriver Konfigurera Sophos Firewall MTA med Microsoft 365 hela vägen för EOP, relay, connector, MX och SPF.

Tre funktioner i Sophos Firewall måste hållas isär:

• MTA mode: Brandväggen tar emot, kontrollerar och routar e-post.
• Legacy mode: Transparent proxybearbetning av en befintlig SMTP-väg. Konfigurera Mail Protection i Legacy mode förklarar NAT, regler, skanningspolicyer och verifiering.
• SMTP Relay i Device Access: Styr från vilka zoner MTA:n kan nås. Inkommande e-post från internet kräver WAN; utgående relä begränsas dessutom till specifika interna e-postservrar.

Att hämta befintliga meddelanden via POP3 eller IMAP är en separat uppgift. Skanna och testa POP3 och IMAP på Sophos Firewall beskriver TLS-förtroende, den valfria policyn, brandväggsregeln och acceptanstestet.

Förutsättningarna omfattar en giltig Email Protection-licens, fungerande routing och DNS, en känd offentlig IP-adress, den interna e-postservern och målporten samt planerade strategier för TLS, karantän och återställning. Enligt Sophos aktuella översikt är MTA-läge inte tillgängligt på XGS 87/87w och XGS 88/88w.

Anti-spam, RDNS, SPF, RBL, IP Reputation och SXL2 Live Protection kräver internetåtkomst. E-postrouting, skanning efter skadlig kod, MIME-filtrering och SPX kan fortsätta med rätt licens i en air-gap-miljö, men en aktiv MTA innebär inte att alla skyddskontroller är tillgängliga där.

Konfigurera MTA-läge från början till slut

1. Definiera e-postflödet och reservvägen

För inkommande e-post pekar den offentliga MX-posten på adressen där Sophos Firewall tar emot TCP 25. Brandväggen kontrollerar meddelandet och levererar det till den interna e-postservern. En gammal DNAT-regel får inte lämna servern direkt nåbar från internet utan kontroll, eftersom MTA:n då kan kringgås. Publicera en server med DNAT beskriver den allmänna DNAT-logiken.

För utgående e-post skickar endast den avsedda e-postservern via brandväggen. Leveransväg, smarthost, PTR/rDNS, HELO, SPF, DKIM och DMARC måste stämma överens med den offentliga avsändaridentiteten. En generell LAN to WAN-regel är för bred; regelbasen ska tydligt identifiera den tillåtna SMTP-avsändaren. Förstå regler i Sophos Firewall beskriver regelordningen.

Dokumentera följande före migreringen:

• aktuell MX-post, prioritet och TTL;
• ny offentlig brandväggsadress och intern målserver;
• befintliga DNAT- och SMTP-regler samt e-postserveranslutningar;
• testavsändare för inkommande och utgående e-post;
• gammal MX-post eller e-postväg som reserv;
• övervakning av e-postserverns kö, brandväggens spool och karantän.

Sänk TTL-värdet i god tid om en snabb återställning kan behövas. Ändringar av den produktiva MX-posten ska göras under ett underhållsfönster.

2. Konfigurera MTA-läge och grundläggande SMTP-inställningar

Gå till Email > General settings och välj Switch to MTA mode vid behov. Sophos Firewall skapar då Any-to-Any-regeln Auto added firewall policy for MTA för SMTP och SMTPS. Redigera inte regeln och behåll den högst upp i brandväggens regellista. Ett byte till Legacy mode tar bort den; ett byte tillbaka skapar den på nytt.

Konfigurera grundinställningarna:

1. Ange domännamnet, exempelvis example.com, som SMTP hostname, inte den interna e-postserverns värdnamn. Värdet visas i HELO och SMTP-bannern för systemgenererade meddelanden.

   Kontrollera XML-API-svaret: SFOS 23-dokumentationen anger status 506 med Message.AVGeneralConfInvalidSmtpNtfyHostname för XML-API-operationen Email Configuration. Det är en operationsstatus, inte en HTTP-statuskod. Nyckeln har inte lösts till en meddelandetext och är inget engelskt felmeddelande; den fastställer inga specifika valideringsregler. Om detta svar visas, kontrollera det inskickade värdnamnet för meddelanden, det faktiska operationssvaret och den sparade konfigurationen innan ändringen betraktas som lyckad. Den extra dokumentationsraden bevisar inte att detta beteende vid körning först infördes i SFOS 23.

2. Aktivera Reject based on IP reputation för att avvisa anslutningar från avsändare med dåligt rykte.

3. Välj ett offentligt betrott certifikat under SMTP TLS configuration och tillåt Allow invalid certificate endast för dokumenterade undantag.

4. Aktivera Disable legacy TLS protocols om inga dokumenterade äldre system kräver annat. Inställningen inaktiverar protokoll äldre än TLS 1.1; den tvingar inte automatiskt fram enbart aktuella TLS-versioner.

5. Aktivera Scan outgoing mails om även utgående meddelanden ska kontrolleras.

Använd Require TLS negotiation med försiktighet: om SFOS inte kan upprätta den TLS-anslutning som krävs kasseras e-post till berörd destination eller från den konfigurerade avsändardomänen. SFOS 22/23-hjälpen varnar för att SMTP TLS-anslutning och validering använder domänens IP-adress i stället för namnet; flera domäner på samma IP kan därför orsaka certifikatfel. Detta är en dokumentationsvarning, inte bevis för certifikatmatchningsalgoritmen i den driftsatta versionen.

Skip TLS negotiation väljer fjärranslutna e-postvärdar eller nätverk för okrypterade SMTP-anslutningar; den dokumenterade gränsen är 512 värdposter. Det är ingen lösning på ett felaktigt certifikat. Allow invalid certificate är ett undantag från TLS-validering av motparten, inte en övergång till klartext. Anta ingen prioritet om Require- och Skip-listor överlappar, och ingen klartextreserv när obligatorisk TLS misslyckas. Begränsa och dokumentera undantag och kontrollera det faktiska anslutnings- och certifikatresultatet i den driftsatta versionen innan de ändras.

Ange globala SMTP-gränser före policyerna

Inställningarna under Email > General settings gäller för alla e-postmeddelanden och behandlas före SMTP- och POP-IMAP-policyerna. Reject based on IP reputation är därför inte en enskild policyåtgärd: SFOS kontrollerar avsändarens IP-adress före SMTP-policyns spamkontroller. Blocked senders är också global, men blockerar endast inkommande e-post.

Under SMTP settings anger Don’t scan emails greater than den största meddelandestorleken för den globala SMTP-skanningen. 0 betyder 51,200 KB, inte obegränsat. För större meddelanden finns Accept, Reject och Drop. Accept levererar utan skanning, Reject avvisar och meddelar avsändaren och Drop kasserar utan meddelande. Dokumentera valet som en medveten skanningslucka eller ett leveransbeslut och testa med ett meddelande strax över och under gränsen.

SMTP DoS settings begränsar samtidiga anslutningar, e-postmeddelanden per anslutning, mottagare per meddelande och e-post- och anslutningshastigheter. SFOS anger det maximala antalet anslutningar baserat på RAM och processor. De dokumenterade standardvärdena är 1000 e-postmeddelanden per anslutning och 100 mottagare per meddelande. Härled egna värden från den verkliga e-postvolymen; en för låg gräns kan behandla legitima distributionslistor eller skannrar som en attack.

Under Advanced SMTP settings kan SFOS avvisa ogiltig HELO eller saknad RDNS och, med Do strict RDNS checks, ett värdnamn som inte pekar tillbaka till käll-IP-adressen. Inför inte dessa kontroller samtidigt med ett brett undantag. Registrera först de faktiska vägarna för partner, nyhetsbrev och applikationer i loggen och testa dem sedan individuellt.

En utgående banner kan använda Inline, no conversion, en separat MIME part eller Off. SMTP- eller SMTPS-skanning måste vara aktiv i den matchande brandväggsregeln. Eftersom en banner ändrar meddelandetexten och kan ogiltigförklara en befintlig DKIM-signatur ska signeringen ske efter ändringen eller så ska det uttryckligen verifieras hos mottagaren att den avsedda signaturen förblir giltig.

Dokumentera även SMTP-hastighetsgränserna före en uppgradering. De dokumenterade intervallen är 1–1000 e-postmeddelanden per anslutning, 1–512 mottagare per meddelande, 1–1000 meddelanden per värd och minut samt 1–100 anslutningar per värd och sekund. Standardvärdena för de två hastigheterna är 1000 respektive 100. Vid migrering behåller SFOS tillåtna e-post- och anslutningshastigheter men återställer värden över maximum till standardvärdet. Jämför de sparade värdena efter uppgraderingen, inte bara den gamla konfigurationsexporten.

3. Lägg till e-postdomänen som Address Group

1. Öppna Email > Address group > Add.
2. Ställ in Group type på Email address/domain och Type på Manual.
3. Lägg till den skyddade domänen, exempelvis example.com.
4. Spara gruppen.

Ange även ett tydligt Name innan gruppen sparas vid skapandet. Använd Edit under Email > Address group för en befintlig grupp; starta filimport med Import. RBL (IPv4) tar IPv4-adresser och RBL (IPv6) IPv6-adresser. Email address/domain stöder manuella poster eller CSV-/textimport. RBL-matchning använder anslutande IP-adress och åtgärden i SMTP-policyn; det separat dokumenterade SPF/RBL-avvisningsbeteendet gäller fortfarande. Behåll standardnamnen Premium RBL services och Standard RBL services om inte en uttryckligen planerad ändring kräver annat.

Address Groups är inte begränsade till e-postdomäner. Group type kan vara Email address/domain, IPv4 RBL eller IPv6 RBL. Samma adress kan ingå i flera grupper, vilket gör det möjligt att skapa separata policymål utan att kopiera eller byta namn på posten.

För större listor kan SFOS importera en CSV- eller textfil med upp till 400 adresser eller domäner. Ogiltiga och dubbla poster hoppas över. Kontrollera antalet och några exempel efter importen innan gruppen tilldelas en produktionspolicy.

Nya SMTP route and scan-policyer är utformade för domäner, inte enskilda mottagaradresser. Migrerade enskilda adresser kan fortsätta fungera, men de kan inte läggas till eller redigeras i aktuella policyer.

4. Skapa en SMTP route and scan-policy

Gå till Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Ange ett tydligt namn, exempelvis Inbound example.com to Exchange.
2. Välj Address Group under Protected domain.
3. Välj Route by:
   • Static host: Fast IP-adress till den interna e-postservern. Om den inte svarar provar brandväggen nästa värd i listan.
   • DNS host: Ett DNS-namn som mailserver.example.com. Flera A-poster används mellan leveranser och servrar som inte svarar hoppas över.
   • MX: Leverans utifrån en MX-post.
4. För Static host väljer du e-postservern under Host list. Skapa vid behov dess IP host under Hosts and services > IP host.
5. Ställ in Global action på Accept för de domäner som avsiktligt ska skyddas. Reject skulle avvisa alla inkommande och utgående meddelanden som hör till dessa domäner och informera avsändaren.
6. Aktivera Spam protection och Malware protection enligt driftpolicyn.
7. Aktivera File protection och Data protection först när deras påverkan på bilagor, stora meddelanden, SPX och DKIM är klarlagd.
8. Spara policyn.

För att ändra en befintlig SMTP route and scan-policy går du till Email > Policies and exceptions och väljer Edit för den aktuella policyn. Ändra de inställningar som behövs och spara policyn. Kontrollera därefter policymatchning och leverans på nytt med ett kontrollerat meddelande.

Med Route by MX får den MX-post som brandväggen löser upp inte peka tillbaka på samma brandvägg, eftersom det skapar en routningsloop. Brandväggen måste kunna lösa interna destinationer korrekt; DNS request routes hjälper vid split DNS.

Alternativet Route inbound mail through gateway behövs bara för särskilda designer, exempelvis målservrar i WAN-zonen, tillämpning av den ursprungliga brandväggsregeln på LAN/DMZ-mål eller val av en bestämd gateway med flera internetanslutningar. Aktivera det inte utan ett konkret routingkrav.

5. Säkra inkommande åtkomst och utgående relä

Tillåt under Administration > Device access SMTP Relay från varje zon som måste nå MTA:n. Inkommande e-post från internet kräver WAN; utgående e-post kräver dessutom den interna e-postserverns zon, vanligtvis LAN eller DMZ. Begränsa sedan åtkomsten till de specifika e-postservrarna, skannrarna eller programmen via Email > Relay settings > Host-based relay.

Breda värd- eller nätverksbehörigheter innebär risk för ett öppet relä. Om skrivare eller program måste skicka e-post ska de dokumenteras som specifika värdobjekt. Säkra åtkomst till Sophos Firewall beskriver grunderna i Device Access.

Allow- och Block-listorna följer inte principen att Block alltid har företräde. Om samma värd eller nätverk finns i båda listorna för Host-based relay eller Upstream host tillåter SFOS relay. Ta bort sådana överlappningar före aktivering och genomför ett negativt test från en källa som inte är tillåten.

En tillåten värd kringgår inte heller e-postskanningen. Om SFOS inte kan skanna en käll-IP som är tillåten för host-based relay avvisas den. En relaybehörighet bevisar därför varken lyckad innehållsgranskning eller leverans; kontrollera båda med ett verkligt testmeddelande och MTA-loggarna.

SMTP route and scan-policyn stöder inte SMTP AUTH. Host-based relay är därför det pålitliga alternativet för enheter. Det finns separata Authenticated relay settings för användare och grupper, men enligt Sophos följer de inte en RFC-kompatibel standard för SMTP-autentisering, så klientkompatibiliteten måste testas. Detta skiljer sig från när brandväggen autentiserar sig mot en överordnad smarthost, där SFOS stöder PLAIN och LOGIN. Ange aldrig en gränssnitts-IP från samma brandvägg som smarthost, eftersom det skapar en routningsloop.

Om utgående e-post använder en smarthost konfigurerar du Email > General settings > Smarthost settings: välj Hostname, ange Port (standard 25) och aktivera Authenticate device with smarthost endast om servern kräver det samt ange inloggningsuppgifterna säkert. Detta leder utgående e-post via en mellanliggande MTA; det ger inte klienter rätt att använda brandväggens relä. Anpassa TLS-krav och den slutliga offentliga avsändaridentiteten till det extra hoppet och dokumentera tidigare inställningar för återställning.

Upstream-relä och molnbaserade e-postservrar

Upstream host under Email > Relay settings styr vilka SMTP-källor uppströms som får leverera inkommande e-post; Host-based relay styr vilka värdar som får använda utgående relä. Konfigurera dessa områden separat. Om en annan gateway först tar emot offentlig e-post ska dess verkliga källnätverk finnas i upstream-listan, inte adressen till målservern. I båda avsnitten har matchande tillåtande poster företräde framför överlappande blockeringsposter.

För en molnbaserad server ska SMTP Relay aktiveras för dess källzon, vanligen WAN, och utgående värdbaserat relä begränsas till serverns verkliga källadresser. Molnservern måste också tillåta den avsedda reläanslutningen med brandväggen. Håll den offentliga MX-posten till brandväggen åtskild från leveransmålet som SFOS slår upp: molnproceduren nämner båda MX-målen utan att förklara DNS-uppdelningen. Använd ett separat DNS-värdnamn, ett statiskt mål eller avsiktligt underhållen split-DNS; Route by MX får aldrig skicka tillbaka e-post till brandväggen.

Molnproceduren rekommenderar också att växla till Legacy och tillbaka om den automatiska regeln saknas. Detta tar bort och återskapar regeln och ändrar den aktiva e-postbehandlingen. Använd det inte som en oplanerad reparation: dokumentera först policyer, köer och reservväg och undersök sedan den saknade regeln med supporten. Ett godkänt lägesbyte hör hemma i ett underhållsfönster med nya tester av inkommande och utgående e-post samt nekad reläåtkomst.

De äldre moln- och finansdataexemplen anger den utgående serverns namn som SMTP hostname, medan den nyare MTA-konfigurationen anger domänen, inte serverns värdnamn. Följ den nyare domänanvisningen för systemmeddelanden; inställningen fastställer inte identiteten för varje vidarebefordrat meddelande. Inkommande DKIM-verifiering använder på samma sätt avsändarens offentliga DNS-nyckel och kräver inte att du skapar en utgående signeringsnyckel bara för att MTA-översikten nämner signering tillsammans med verifiering.

Flera WAN-gränssnitt eller alias-IP-adresser

MTA:n skapar själv den utgående SMTP-anslutningen. När flera offentliga avsändaradresser är möjliga räcker därför inte en vanlig klientregel. Sophos skiljer mellan tre fall: med ett WAN-gränssnitt och flera alias-IP-adresser skapas en SNAT-regel med önskad publik Translated source. Med flera WAN-gränssnitt utan alias skapas en SD-WAN-route för SMTP, SMTP(S) och SMTPS_465. Om både flera WAN-gränssnitt och aliasadresser finns kombineras SNAT med SD-WAN-routen.

SNAT-regeln lämnar mål och service oförändrade, använder den planerade WAN-länken som utgående gränssnitt och översätter till MASQ eller önskad alias-IP. SD-WAN-routen använder internetgruppen som mål, de tre SMTP-tjänsterna och planerad primär gateway samt valfri backup. En backup är bara meningsfull om utgående TCP 25 verkligen är tillåten där och den publika adressen också finns med i e-postdomänens SPF-post.

För detta officiella multi-WAN-flöde kräver Sophos route precedence static, vpn, sdwan_policyroute och aktiverar SD-WAN för systemgenererad trafik. Kör kommandona i Device Console (alternativ 4 i CLI-menyn), inte i Advanced Shell. Läs först båda ursprungsvärdena, gör ändringarna och kontrollera dem sedan igen:

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 gäller globalt och är inte en isolerad e-postinställning. Före ändringen dokumenteras alla överlappande statiska, VPN- och SD-WAN-vägar samt de två avlästa värdena. Vid återställning återställs hela den tidigare ordningen med system route_precedence set ..., och system-generate-traffic sätts tillbaka till sitt ursprungliga läge enable eller disable. Därefter kontrolleras inte bara SMTP-räknare, utan även den käll-IP som faktiskt används, leverans, SPF-resultat och bortfall av den primära gatewayen. Kontrollera SD-WAN-routing för systemgenererad trafik beskriver den allmänna säkerhets- och återställningsprocessen.

För SD-WAN-rutten förhindrar Route only through specified gateways avsiktligt reservväxling till andra gateways: om de valda gatewayarna inte kan nås kasserar brandväggen trafiken. Avgör om detta är bättre än en oplanerad avsändar-IP och testa den felvägen. Välj IPv4- eller IPv6-objekt som passar den faktiskt publicerade e-postvägen; kopiera inte en IPv4-internetgrupp till en IPv6-design.

6. Ändra MX-posten

Ändra den offentliga MX-posten till brandväggens adress först när MTA-regeln, domänen, policyn, reläet och den interna leveransvägen är klara. Skicka omedelbart ett externt testmeddelande och kontrollera att det visas i Log Viewer eller Mail logs, levereras till den interna servern och når postlådan.

Om externa avsändare inte kan nå brandväggen eller legitima meddelanden avvisas i stor omfattning återställer du den dokumenterade tidigare e-postvägen. DNS-cachar gör att återställningen inte får omedelbar effekt överallt. Håll därför både den gamla och den nya vägen i drift parallellt och övervaka dem åtminstone tills den längsta tidigare giltiga TTL-tiden har löpt ut. Om brandväggen tar emot meddelanden men inte kan leverera dem kontrollerar du först routing, DNS, TLS, mottagarverifiering och e-postserverns loggar.

Välj skyddsinställningar medvetet

Åtgärder för spam, skadlig kod och känsliga uppgifter

Välj åtgärd uttryckligen för inkommande spam, sannolikt spam och massutskick: None levererar oförändrat, Warn lägger till det konfigurerade ämnesprefixet, Quarantine håller kvar meddelandet och Drop kasserar det utan att meddela avsändaren. Ange ämnesprefix för spam och massutskick efter behov. Dessa val ersätter inte det separata SPF/RBL-avvisandet.

För skadlig kod erbjuder Selected antivirus action alternativen None, Drop och Quarantine; konfigurera Notify sender separat. Quarantine unscannable content omfattar innehåll som inte kan inspekteras, bland annat skadade, krypterade eller komprimerade filer, för stora meddelanden och interna skanningsfel. En genomförd leverans bevisar inte att alla bilagor har skannats. Zero-Day Protection har en egen maximal analysstorlek: större filer analyseras inte av den tjänsten. Testa den gränsen separat från den globala SMTP-storleken och gränserna för kassering i File protection.

Under Data protection väljer du exakt Data control list, dess åtgärd och vid behov SPX template: Accept levererar, Accept with SPX krypterar och levererar, och Drop kasserar utan meddelande. Notify sender är ett separat val. En SPX-tilldelning på domännivå krypterar all matchande utgående e-post; använd en Data Control-utlösare om bara meddelanden som matchar finansdata ska krypteras. Exemplet med mottagarlösenord använder Specified by recipient och håller kvar meddelandet tills lösenordet registrerats. Konfigurera mall, Reply Portal och registreringsväg tillsammans i den länkade SPX-runbooken och testa sedan ett matchande och ett icke-matchande meddelande i stället för att bara aktivera Data protection.

Använd egna filtyper och Data Control Lists

I MTA mode skapas en egen filtyp under Email > Policies and exceptions > File type > Add från en mall, filändelser eller MIME-typer. Filändelser anges utan inledande punkt. Endast egna filtyper kan redigeras. En ny typ läggs inte heller automatiskt till i befintliga policyer: öppna den aktuella SMTP route and scan-policyn, lägg till typen under File protection och spara policyn igen. Ett positivt test med en bilaga och ett liknande negativt test bekräftar matchningen bättre än enbart objektnamnet.

Under File protection > Block file types blockerar All e-post med bilagor; det betyder inte att alla bilagor skannas. None tillåter bilagor inom denna filfilterinställning men kringgår inte malware-, spam-, Data Protection- eller andra kontroller. Policyhjälpen säger att valda MIME-rubriker fyller MIME whitelist, tillåter dessa typer och blockerar återstående typer. MIME-rubriker och filändelser bevisar inte ofarligt innehåll. Kontrollera tillåtna och blockerade bilagor i den driftsatta versionen innan ett exakt whitelistrecept tillämpas.

En Data Control List består av Content Control Lists, eller CCL:er, för definierade innehållstyper som finansiella uppgifter eller personuppgifter. När den läggs till under Email > Data control list > Add filtreras CCL:erna efter Type och Region, och endast de poster som faktiskt behövs väljs. Åtgärden definieras först i den länkade policyn. Ett kontrollerat matchande innehåll och ett liknande innehåll utan matchning bekräftar att matchning och åtgärd fungerar tillsammans utan onödiga falska positiva resultat.

Spamskydd är mer än åtgärden som tillämpas på skräppost. Meddelanden som träffar SPF- eller RBL-kontrollerna avvisas direkt och följer inte de vanliga åtgärderna för spam eller probable spam. Greylisting avvisar avsiktligt ett meddelande tillfälligt och kräver att den sändande servern försöker igen.

För Reject based on BATV måste först ett gemensamt BATV secret konfigureras under Email > General settings > Advanced SMTP settings. Använd samma secret på flera egna MX-system. SFOS kombinerar den med tidsstämpeln och avsändaradressen för att skapa Return-Path-signaturen, som upphör att gälla efter sju dagar. Jämför därför ett BATV-fel med secret, systemtid, avsändarväg och signaturens ålder i stället för att dölja det med ett brett undantag utan tidsgräns.

Recipient verification förhindrar meddelanden till okända mottagare:

• With callout: Frågar målservern. Om den tillfälligt inte är tillgänglig godkänner SFOS mottagare efter en definierad tid i stället för att permanent blockera hela e-postflödet.
• In Active Directory: Kontrollerar via Simple, SSL eller STARTTLS och har en tidsgräns på 30 sekunder. Ange AD-server, Bind DN och Base DN. Bind DN är det fullständiga distinguished name, inklusive CN för den konfigurerade bind-identiteten; Base DN är startpunkten för katalogsökningar. Använd värden som passar den egna katalogen. Hjälpens administratörsexempel visar inte att Domain Admin-behörighet krävs. Välj en transport som uppfyller den driftsatta tillits- och säkerhetspolicyn; en SSL- eller STARTTLS-etikett bevisar inte i sig lyckad certifikatvalidering.

Malware Protection kan använda enkel eller dubbel antivirusskanning. För att använda Zero-Day Protection med enkel antivirusskanning ska Sophos anges som primär motor. Sophos Firewall Zero-Day Protection beskriver begränsningar och beslut om frisläppning.

Enligt SFOS 22/23-policyhjälpen väljer Single antivirus den primära motorn endast för inkommande e-post; utgående e-post använder båda motorerna. Dual antivirus skannar först med den primära och sedan med den sekundära motorn. Den primära motorn, Sophos eller Avira, väljs globalt under Email > General settings. Val av Avira inaktiverar Zero-day protection i SMTP-policyer med enkel antivirusskanning; Sophos måste vara primär för att använda Zero-Day Protection med en skanning. Hjälpen för allmänna inställningar beskriver enkel skanning som enbart den primära motorn, utan policytabellens riktningsskillnad. Denna dokumentationsskillnad bevisar inte observerad motoranvändning: kontrollera version, policy, e-postriktning och skyddsstatus före och efter en ändring. Dokumentera tidigare inställningar; återställning av motorvalet visar inte att Zero-day protection har aktiverats igen.

Policygränsen Drop message greater than under File protection är inte samma sak som det globala beteendet för för stora meddelanden: större meddelanden kasseras vid denna punkt. SFOS kontrollerar också synligt innehåll och innehåll i paketerade format som docx, xlsx, pptx, odt, ods, odp och odg. Ett positivt test med enbart en opaketerad textfil bevisar därför inte hur samma information behandlas i ett Office-dokument.

När DKIM verification är aktiverat skiljer SFOS mellan en hash som inte matchar, en ogiltig signatur eller otillgänglig publik nyckel och en saknad DKIM-signatur. För varje resultat kan Accept, Quarantine eller Reject väljas. Enligt Sophos placeras DKIM-signerade meddelanden som använder RSA-SHA1 eller en nyckellängd utanför 1024 till 4096 bitar i karantän. Testa denna inkommande verifiering separat från utgående signering.

För utgående meddelanden spelar bearbetningsordningen roll. SPX encryption, subject prefixes, File eller Data Protection och utgående banners kan ändra header eller body efter att en befintlig DKIM-signatur har lagts till. DKIM-valideringen misslyckas då hos mottagaren. Bestäm om den interna e-postservern, Sophos Firewall eller en senare gateway ska signera meddelanden.

Signera utgående meddelanden med DKIM på brandväggen

Om Sophos Firewall ska signera meddelandena läggs en signatur till för varje avsändardomän under Email > General settings > DKIM signing > Add. Domain är e-postdomänens FQDN och Key selector är exakt den selector som sedan publiceras i publik DNS. Ett namn som fw01 eller zurich gör senare nyckelrotationer lättare att förstå, men är ingen säkerhetsfunktion.

SFOS kräver en privat RSA-nyckel på 1024 till 2048 bitar mellan -----BEGIN RSA PRIVATE KEY----- och -----END RSA PRIVATE KEY-----. För nya konfigurationer är 2048 bitar det lämpliga valet. Använd inte RSA-SHA1. Enligt Sophos accepterar brandväggen inte en 1024-bitarsnyckel som genererats med PuTTYgen, så välj även där 2048 bitar. Den privata nyckeln hör endast hemma på brandväggen och aldrig i DNS, ärenden eller publik dokumentation.

Efter att inställningen sparats publiceras DKIM-TXT-posten för selektorn med den publika nyckeln hos den auktoritativa DNS-leverantören. Först när posten kan slås upp externt skickas ett nytt testmeddelande via den avsedda utgående MTA-vägen. Den mottagna headern måste innehålla förväntad selector och domän, och mottagarens DKIM-verifiering måste lyckas. Om signaturen saknas kontrolleras avsändardomän, policymatchning och Scan outgoing mails. Om verifieringen misslyckas jämförs först DNS-post, selector, använd nyckel och senare ändringar genom SPX, banners, File Protection eller Data Protection.

Konfigurera och testa SPX-e-postkryptering förklarar hur mall, utlösarprioritet, lösenordsmodell och Reply Portal fungerar tillsammans.

Automatisera MTA-inställningar säkert via XML API

Vid automatisering är globala inställningar, Address Groups och SMTP-policyer separata mål. Läs först build, aktivt e-postläge, sparade värden och beroende policyer; förbered en säkerhetskopia och en riktad återställningsväg. Skicka den bekräftade begäran med en uttrycklig operation endast för det mål som behövs. Jämför därefter operationssvaret, det tillstånd som lästs tillbaka och motsvarande test av e-postflödet. Även efter ett fel eller en timeout ska du först läsa tillbaka och kontrollera om något redan har sparats, i stället för att blint upprepa skrivbegäran. Säkra XML API-åtkomst beskriver åtkomst, säker lagring av secrets och utvärdering av svar.

Objektreferenserna för SFOS 22/23 är inte färdiga payloads för produktion. XML-exempel, parametertabeller och WebAdmin-hjälpen kan ange olika stavningar, värden eller standardvärden. Tomma standardvärdesceller eller Any bekräftar varken ett säkert tomt värde eller hur utelämnade fält behandlas. Olösta $EMAILPROTECTION{…}-konstanter är inte bekräftade API-literaler. Stoppa före skrivning om syntax, operation eller effekt är oklar och använd API help för den installerade builden eller begär ett officiellt klargörande. Dokumentationsskillnader i sig bevisar ingen produktändring.

Håll isär globala SMTP-, TLS- och reläinställningar

I EmailConfiguration hör SMTP-skanningsgränsen och DoS-värdena hemma under SMTPSSettings, medan de separata POP/IMAP-värdena ligger under POPIMAPSettings. Fältet DontScanEmailsGreaterThan, som har samma namn i båda fallen, får inte kopplas till fel protokoll. RecipientHeaders med upprepade Header gäller identifiering av POP/IMAP-mottagare, inte SMTP-routing. Banners ligger under GeneralSettings. Även SMTPTLSConfiguration och POPSIMAPTLSConfiguration är separata kontexter: TLSCertificate, AllowInvalidCertificate och DisableTLS1 kan inte adresseras entydigt med ett enda okvalificerat fältnamn. Ett SMTP-undantag får inte obemärkt även sänka skyddet för POP/IMAP. Läs tillbaka båda kontexterna separat efter att inställningarna sparats och testa endast den avsedda e-postvägen.

BypassSpamCheck under SMTPSSettings beskriver enligt API-tabellen hur spamskanningen kringgås för autentiserad trafik. Tabellen anger standardvärdet Disable, medan XML-exemplet sätter värdet till Enable. Använd inte exemplet som en säker standardkonfiguration: klargör före en ändring vilken trafik som räknas som autentiserad i den aktuella builden och vilken spamkontroll som kringgås. Begränsa ett avsiktligt undantag snävt och kontrollera dess effekt på matchande och icke-matchande meddelanden; betrakta inte andra skanningsområden som automatiskt undantagna.

SMTP-värdenas ursprung är viktigt: API-tabellen anger för DontScanEmailsGreaterThan värdet 1024 KB, för MaximumConnections värdet 5000 inom intervallet 1–20000 och för MaximumConnectionsHost värdet 100 inom intervallet 1–10000. För MaximumEmailsConnection anger den standardvärdet 100, medan XML-exemplet anger 1000; även WebAdmin-hjälpen anger 1000. MaximumRecepientsEmail är källans stavning, med standardvärdet 100 och intervallet 1–512. För EmailsRate och ConnectionsRate anger API-tabellen standardvärdena 1000 respektive 100, båda med intervallet 1–20000; WebAdmin-hjälpen begränsar däremot hastigheterna till 1–1000 per minut respektive 1–100 per sekund och fastställer maximalt antal anslutningar utifrån maskinvaran. Använd därför varken tabellernas maxvärden som aktuella UI-gränser eller exempelvärden som standardvärden. De WebAdmin-gränser och den uppgraderingskontroll som beskrivs ovan är fortfarande styrande för detta arbetsflöde; automatisering måste stämma av de värden som faktiskt sparats i builden.

Ytterligare syntaxkonflikter förhindrar blind import av exempel: VerifySendersIPReputation visar Enable i XML-exemplet, men API-tabellen anger on/off med standardvärdet Disable; SMTPSDosSettings beskrivs där som ett heltal med standardvärdet Disable, men som Enable i exemplet. För bannern står exempeltexter mot tabellvärdena inline_plain, mimepart, off. ”Reparera” inte dessa uppgifter själv, utan bekräfta giltig stavning och giltiga värden före en begäran. Beakta separat den befintliga anmärkningen om Email Configuration, status 506.

AdvancedSMTPSetting är också global. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks och ScanOutboundEmails styr de HELO/RDNS-kontroller och kontroller av utgående e-post som beskrivs ovan. FirewallRelateInboundMails gäller den separata vägen via gateway-/brandväggsregler; exemplet anger Disable, tabellen Turn on/Turn off. För BATV-secret visar exemplet BATVSecret, medan tabellen anger BATVsecret. Bekräfta skiftläge och giltiga värden före skrivning; presentera ingen av varianterna som en testad payload. Använd den gemensamma secreten från skyddad lagring och kopiera varken exempel-secreten eller den faktiska secreten till ärenden, kodarkiv eller begärandeloggar. Planera byte av secret för alla berörda MX-system och kontrollera därefter BATV och normal sändning.

I RelaySettings finns HostBased och UpstreamHost, var och en med egna AllowRelay- och BlockRelay-listor. Under dessa finns HostsOrNetworks och upprepade HostsOrNetwork-poster. Samma namn på ett lövfält innebär alltså inte samma reläomfattning. AuthenticatedRelaySettings innehåller separat AuthenticatedRelay samt UsersOrGroups med UsersOrGroup. De öppna grupper respektive gästgrupper som visas i tillverkarens exempel är inget säkert val. Använd endast de planerade identiteterna och värdobjekten, rensa överlappningar mellan listorna och kontrollera därefter tillåten sändning samt otillåtet relä från en separat källa.

I SmarthostSettings aktiverar UseSmarthost det mellanliggande hoppet för utgående e-post; SmarthostList med upprepade Hostname väljer målen och Port målporten. API-tabellen anger 1–65535, men inget standardvärde för porten; 25 finns i exemplet och anges som standardvärde i WebAdmin-hjälpen. AuthenticateDevicewithSmarthost är separat: tillhandahåll Username och Password säkert endast om inloggning behövs. API-tabellen anger Disable som standard för båda aktiveringsreglagen, medan exemplet aktiverar båda. passwordform="encrypt" är exemplets lösenordssyntax, inte ett tillstånd att återanvända krypterade värden från en annan brandvägg. Stoppa begäran om ursprunget eller importkraven är oklara. Kontrollera därefter mål, TLS, autentisering och leverans via detta hopp, inte bara reläbehörigheten.

Ändra Address Groups och SMTP-policyer riktat

För MTA är exempelobjektet MTAAddressGroup avsett, inte det snarlikt namngivna AVASAddressGroup i den andra e-postkontexten. Name identifierar gruppen. GroupType bestämmer rätt lista: API-tabellen skiljer mellan RBLIPv4, RBLIPv6, IPAddress och EmailAddressOrDomain samt postfälten RBLName, IPAddressNetwork och EmailAddressDomain. Exemplet för e-postdomäner använder EmailAddressList med upprepade EmailAddressDomain och EmailImportType satt till Manual. För Import och EmailAddressFile måste du klargöra vilken filuppladdning som passar builden: beskrivningstexten kopplar motsägelsefullt filfältet till manuell import. Ett lyckat HTTP-svar bekräftar varken alla importerade poster eller gruppens slutliga sammansättning. Läs tillbaka antal, utelämnade poster och faktiska domänvärden innan en policy använder gruppen.

För Delete Address Group innehåller SFOS 22/23-sidorna statusrader, men ingen parameterdefinition och inget exempel på borttagning. Därifrån går det inte att härleda vare sig exakt objektidentitet för Remove eller en fungerande begäran. Sätt inte bara in Name eller objektet som användes vid skapandet i en Remove-payload. Kontrollera först användningen i e-post-, spam- och arkiveringskonfigurationer; hämta den exakta operationen och dess fullständiga begäran från installerad API help eller ett officiellt klargörande. Utför ingen automatisk borttagning innan dess. Efter en godkänd borttagning ska du kontrollera igen att exakt den avsedda gruppen har tagits bort och att nödvändiga referenser och e-postflödet är intakta.

I SMTPPolicy är Name policyns identitet; DomainList med DomainName kopplar de skyddade domänerna. RouteBy, DNSHostName och RouteList med HostName, routingid och routingorder beskriver olika leveransvägar, inte ytterligare domännamn. API-tabellen anger MX som standard för routing, men exemplet innehåller alternativa routingtexter i stället för ett enda värde. Kontrollera routingen i förväg mot den faktiska DNS-upplösningen så att ingen loop tillbaka till brandväggen uppstår.

De nästlade områdena SpamProtection, MalwareProtection, FiletypeFilter och DataProtection har oberoende statusfält. API-tabellen anger OFF som standard för dessa, trots att exemplet sätter dem till ON. En global åtgärd Accept aktiverar alltså inte automatiskt alla kontroller. Domänens SPX-fält SPXEncryption och det träffrelaterade DataProtectionSPXTemplate är inte heller utbytbara; DataProtectionPolicy måste referera till en befintlig, lämplig Data Control List. Kontrollera förutsättningarna för motorer, Zero-Day och BATV samt SPX-lösenordsmodellen i förväg. Tabellen beskriver mottagarverifiering som utgående, WebAdmin-hjälpen som inkommande; härled ingen ny kontrollriktning från detta. Riktningsspecifika positiva och negativa tester samt sparade policyvärden avgör om det planerade skyddskonceptet har genomförts.

För Data Control List visar XML-exemplet MTADataControlList, med Name och Signatures med upprepade Signature. Tabellens etiketter name och signaturename är ingen bekräftad instruktion att serialisera dessa som XML-taggar med gemener. Bekräfta MTA Mode i förväg, läs de tillgängliga signaturerna och välj endast lämpliga CCL:er. Listan ensam skapar ingen skyddsåtgärd: först kopplingen via DataProtectionPolicy och åtgärden i SMTP-policyn omsätter konceptet i praktiken. Läs därefter tillbaka listan och kopplingen och testa en kontrollerad träff samt ett liknande innehåll utan träff.

Likställ inte DKIM och undantag med routing

I DKIMVerification styr VerifactionStatus, som faktiskt stavas så i exemplet, aktiveringen. ActionForVerifactionFail är en annan selector än ActionForSignatureInvalid eller ActionForSignatureNotFound: den första gäller fel vid hash-/signaturverifiering, den andra en saknad eller syntaktiskt ogiltig offentlig DNS-nyckel och den tredje en saknad signatur. Korrigera inte stavfelen i de två första taggarna utan att ange det. XML-exemplet anger Pass, medan parametertabellen och WebAdmin-hjälpen anger Accept tillsammans med Quarantine och Reject. Detta bekräftar inte att API-värdena är utbytbara; klargör API-kontraktet för builden före en begäran och testa alla tre inkommande fall separat.

I DKIMSigning identifierar Domain signeringsdomänen, inte Name; även referensen för borttagning kräver Domain. Vid skapande och ändring är KeySelector och PrivateRSAKey obligatoriska fält. Enligt WebAdmin-hjälpen kan en domän ha flera signaturer, medan referensen för borttagning endast anger domänen: klargör den exakta omfattningen av borttagningen i förväg om det finns flera selectors, och anta inte att borttagning kan göras per selector. Lagra privata nycklar och API-inloggningsuppgifter skyddat och ta bort dem från svar och loggar; kontrollera därefter DNS och den nya mottagna signaturen enligt ovan.

Den globala inkommande listan använder MtaBlockedSenders med BlockedEmailAddresses och upprepade EmailAddress; API-tabellen tillåter enskilda adresser eller wildcard-domäner som *@example.com. Denna lista ersätter inte en fullständig anti-spam-policy och gäller i den MTA-kontext som beskrivs här endast inkommande meddelanden. Läs omfattningen och befintliga poster före en ändring och testa därefter en matchande och en icke-matchande avsändare.

Separat från detta beskriver API:t AntiSpamTrustedDomain med DomainList och upprepade DomainName som ett undantag för att kringgå e-postskanning för betrodda domäner. Vilka skannrar som exakt kringgås framgår inte av denna källa. Hitta därför varken på en GUI-sökväg eller garantera att ”alla skanningar är avstängda”, och blanda inte ihop Trusted Domains med skyddade routingdomäner. Klargör före skapande eller borttagning den exakta domänlistan, det nödvändiga undantaget och effekten på skanningen i den installerade builden; begränsa omfattningen snävt och verifiera med ett datum för omprövning samt matchande och icke-matchande meddelanden.

För Delete Trusted Domain anger parametertabellen DomainName som en obligatorisk array med flera möjliga värden, men ger inget exempel på borttagning. Använd därför inte nästlingen i Add-exemplet som en begäran om borttagning utan att först kontrollera den; bekräfta målvärdena och den fullständiga strukturen för begäran i förväg i installerad API help eller genom ett officiellt klargörande.

Den globala motorväljaren är MalwareProtection med PrimaryAntiVirusEngine, som enligt API-tabellen har Sophos som standard. Den är inte det nästlade policyelementet med samma namn och aktiverar inte i sig skanningsområdena. Kontrollera effekterna på enkel/dubbel skanning och Zero-Day Protection enligt ovan före och efter en ändring i de berörda policyerna.

Objektspecifika svar som diagnoshjälp

Följande kopplingar kommer från statusraderna för SFOS 22/23. Siffrorna är XML-operationskoder, inte HTTP-koder; Message.* är olösta källnycklar, inte bekräftade meddelandetexter eller entydiga felorsaker. Den allmänna API-säkerheten ovan gäller även här: stäm av det faktiska svaret och det sparade tillståndet före varje nytt försök, ta inte bort beroenden på chans och stoppa vid ett oklart partiellt tillstånd.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. De tre sista raderna gör importavstämningen särskilt viktig; anta inte att hela filen har avvisats eller importerats. Edit Address Group anger i dessa källor endast 200 → Message.AddrGrpUpdateSuccess och 500 → Message.AddrGrpUpdateFail; presentera inte Add-koderna som dokumenterade Edit-svar.
• Delete Address Group: 504, 505 och 506 hänvisar var och en till Message.AddrGrpForeignKeyExists; 507 till Message.AddrGrpEmailArcKeyExists. Samma symbolkoppling fastställer inte vilken referens som berörs. Kontrollera användningen och vilka grupper som faktiskt finns; dessa svar ersätter inte det saknade kontraktet för borttagning.
• Add Data Control List och Update Data Control List: båda anger 502 → Message.DLPAddSameName och 545 → Message.MTAModeDisableCheck. Även Update-nyckeln innehåller ”Add”; byt inte namn på den. Kontrollera namn, läge och sparad lista utan att fastställa en orsak enbart utifrån nyckeln.
• Add SMTP Policy och Edit SMTP Policy: båda anger 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck och 545 → Message.MTAModeDisableCheck. Endast Add SMTP Policy anger 502 → Message.SMTPProfileduplicateName. För 543 skiljer källan mellan Message.SMTPProfileSenderGenSPXAdd för Add och Message.SMTPProfileSenderGenSPXEdit för Edit. Kontrollera domänkopplingar, namn, läge och SPX-beroenden mot det verkliga tillståndet; utlös inget automatiskt namnbyte eller någon sänkning av skyddet.
• Email Configuration: 505 → Message.ASConfigSubOperationFail finns i båda versionerna. Läs tillbaka alla berörda SMTP-, POP/IMAP- och TLS-delområden före ett nytt försök; anta varken fullständig framgång eller fullständig återställning. Den extra SFOS 23-raden 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname omfattas fortfarande av de förbehåll som anges ovan.

Validera e-postflödet

Kör följande kommandon från ett system utanför det egna nätverket:

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

Ersätt example.com och mail.example.com med de riktiga värdena. Kommandona testar DNS, TCP 25 och STARTTLS, men inte reläbehörighet eller fullständig leverans. openssl s_client förblir interaktivt efter handskakningen; avsluta med Ctrl+C.

Testa åtminstone följande fall:

• externt meddelande till en giltig mottagare;
• med Recipient verification aktiverad, externt meddelande till en ogiltig mottagare;
• utgående meddelande via den avsedda e-postservern;
• spam- eller malwaretest som passar policyn;
• STARTTLS och den presenterade certifikatkedjan;
• karantänåtgärd och leverans efter frisläppning;
• blockerat reläförsök från en obehörig källa;
• ingen direktleverans som kringgår MTA:n via en gammal DNAT-regel.

Dokumentera endast observerade acceptansresultat: det giltiga testmeddelandet ska visas som Delivered i Mail logs och kunna spåras med Message-ID hela vägen till målbrevlådan. Förvänta endast att den ogiltiga mottagaren avvisas när mottagarverifiering är aktiverad, den valda verifieringsmetoden fungerar via en nåbar auktoritativ verifieringsväg och avvisning är konfigurerad. För With callout, skilj detta negativa test från det dokumenterade undantaget: SFOS godkänner mottagare när målservern för e-post inte kan nås under en angiven tidsperiod. Dokumentationen anger inte hur lång denna tidsperiod är; anta inte att samma undantag gäller för In Active Directory. När verifieringen är avstängd är ett avvisande inte det förväntade resultatet av detta negativa test. Det obehöriga reläförsöket får inte skapa något meddelande, och frisläppning från karantän ska visa en efterföljande leverans för samma Message-ID.

För den första kontrollen använder du Email > Mail logs, Email > Mail spool, Email > SMTP quarantine och Log Viewer. För en djupare analys noterar du testtid, avsändare, mottagare, ämne, käll-IP och Message-ID och korrelerar dem med följande filer:

• MTA: smtpd_main.log
• avvisningar: smtpd_reject.log
• skanningsfel: smtpd_error.log
• interna MTA-fel: smtpd_panic.log
• anti-spam: sasi.log
• äldre SMTP-proxy: awarrensmtp.log
• POP/IMAP-proxy: warren.log

Sophos Firewall-tjänster och loggar beskriver mappningen och Advanced Shell-åtkomst.

I Mail logs anger Result leveransstatus, medan Reason beskriver skannings- eller policyorsaken. Rejected innebär att SFOS kasserade meddelandet och informerade avsändaren. Dropped kasserar det utan meddelande; Bounced visas efter flera misslyckade leveransförsök. Dessa statusar är inte likvärdiga, eftersom de ger olika återkoppling och felsökningsvägar. Andra resultat är Delivered, Quarantined och manuellt Deleted; orsaker kan bland annat filtreras på Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM och BATV.

Hantera karantän och e-postspool

Under Email > SMTP quarantine kan du filtrera efter tid, avsändare, mottagare, ämne och karantänorsak:

• Release: Leverera meddelandet.
• Delete: Ta bort meddelandet.
• Release and report: Frisläpp och rapportera endast falska positiva som klassificerats som Spam eller Probable spam till SophosLabs.

Virusinfekterade meddelanden och meddelanden som Zero-Day Protection klassificerar som skadliga kan inte frisläppas. För att ta bort Zero-Day Protection-poster krävs skrivbehörighet för funktionen. När karantänen är full rensas äldre meddelanden bort.

Endast användare som har autentiserat sig mot brandväggen minst en gång får karantänsammanställningar. Som standard tillämpar SFOS inte sammanställningsinställningarna på aliasadresser; tilldela dem tillsammans med den primära adressen under Email > Quarantine settings > Change user’s quarantine digest settings eller i användarobjektet. Sammanställningen kan då ta med spam till primära adresser och alias. Meddelanden till alias visas fortfarande inte i själva User Portal.

Konfigurera och testa Sophos Firewall karantänsammanställning beskriver konfiguration, användartilldelning, frisläppningslänk och fullständigt funktionstest.

Email > Mail spool innehåller meddelanden som ännu inte har levererats eller vars leverans misslyckats. SFOS försöker leverera i tre dagar och kasserar meddelandena efter ytterligare fyra dagar; kasserade meddelanden är fortsatt synliga i Mail logs. En växande spool är därför en varningssignal för problem med routing, DNS, TLS, policy eller e-postservern, inte en anledning att upprepade gånger välja Retry utan diagnos.

Statusfiltret skiljer mellan Queued, Failed, SPX blocked, Zero-day protection och Error. SPX blocked väntar på att mottagaren ska skapa ett lösenord; Zero-day protection väntar på analysen. Endast meddelanden i error queue kan hämtas eller tas bort. För att ta bort eller skicka om Zero-Day Protection-meddelanden behöver administratörsprofilen läs- och skrivbehörighet för Zero-Day Protection Activity. Om en knapp saknas kontrolleras först status och profil i stället för att kringgå begränsningen med en tjänsteomstart.

Karantän och spool använder lokal lagring. Övervaka ledigt utrymme, SSD-status och System Health; se Rensa lagring och rapporter och Kontrollera SSD Health. I HA är loggar och rapporter separata för varje nod och synkroniseras inte, så kontrollera båda noderna. Sophos Firewall HA-kluster beskriver grunderna.

Felsökning

Extern e-post kommer inte fram

Kontrollera MX, A/AAAA, offentlig IP, TCP 25 och SMTP Relay från WAN. Kontrollera därefter att MTA-läge är aktivt, att den skyddade domänen matchar policyn och att ingen gammal DNAT-regel eller brandväggsregel med högre prioritet ändrar den förväntade vägen. Om smtpd_main.log inte visar någon anslutning ligger problemet sannolikt före Mail Protection.

Brandväggen tar emot e-post men levererar den inte

Kontrollera den interna e-postservern, routen, DNS, målporten, TLS och mottagarverifieringen. Static host, DNS host och MX använder olika vägar för namnuppslagning och redundans. Korrelera brandväggens avvisnings- och felloggar med e-postserverns loggar.

Många meddelanden ligger kvar i spoolen

Kontrollera först Email > Mail spool och MTA-loggarna. En vanlig orsak är en regel ovanför den automatiskt genererade MTA-regeln som redan matchar SMTP. Kontrollera under Rules and policies > Firewall rules nya regler som placerats vid Top, automatiskt genererade IPsec- eller hotspot-regler och andra överlappningar. Flytta inte en regel på måfå; det är dess faktiska SMTP-matchning som är avgörande.

Först när den nya överlappande regeln har bekräftats som orsak flyttas den så långt ned under Rules and policies > Firewall rules att den avsedda SMTP-regeln utvärderas igen. Därefter kontrolleras leverans och spool på nytt med ett kontrollerat meddelande; andra nödvändiga anslutningar måste även fortsättningsvis gå via sina avsedda regler.

NC-177930 åtgärdades i SFOS 22.0 MR2: meddelanden låg kvar i spoolen efter en mailpoller-krasch. Ta med firmwareversionen i diagnosen om problemet uppstår på en äldre version. Använd uppgraderingskontrollen för SFOS 22 för att välja målbuild, förbereda ändringen och därefter testa e-postflödet igen.

Sophos Fusion rapporterar Invalid API request

I SFOS 22.0 MR1 kunde Release och Delete misslyckas när brandväggen öppnades via Sophos Fusion (tidigare Sophos Central). Symptomet Invalid API request registreras som NC-182056; NC-181904 identifierar korrigeringen för misslyckad frisläppning via Sophos Fusion. Den säkra tillfälliga lösningen är att logga in direkt i lokal WebAdmin och utföra åtgärden under Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 åtgärdar problemet. Om det fortfarande misslyckas där kontrollerar du administratörsprofil, Sophos Fusion-åtkomst och lokala behörigheter separat. Följ den fullständiga processen för godkännande, förberedelse, validering och felsökning i Sophos Firewall firmwareuppdatering: förberedelser och bästa praxis vid en uppdatering.

Reject based on RBL kan inte aktiveras

NC-144563 är ett versionsspecifikt fall för SFOS 20.0.2 MR2 Build 378: om standard-RBL-grupperna under Email > Address group har bytt namn kan Reject based on RBL inte aktiveras när en SMTP route and scan-policy skapas. I en befintlig policy kan alternativet inte aktiveras igen efter att det har inaktiverats. Ingen korrigerad version är dokumenterad.

Standardgrupperna heter Premium RBL services och Standard RBL services. Dokumentera först exakt build och gruppernas aktuella namn. Om båda villkoren är uppfyllda återställs standard-RBL:ernas ursprungliga namn, policyn öppnas på nytt och alternativet kontrolleras. Blanda inte ihop egna RBL:er med dessa två systemgrupper.

På andra builds, eller om standardnamnen är oförändrade, bevisar ett nedtonat alternativ inte NC-144563. Kontrollera policytyp, Spam protection, Email Protection-licens och övrig konfiguration separat.

En legitim avsändare klassificeras som spam

Kontrollera avsändardomänen, SPF/DKIM/DMARC, headers, reputation, policymatchning och berörda mottagare. Skapa först därefter ett snävt undantag med ett datum för omprövning. Skapa och testa e-postundantag på ett säkert sätt beskriver hela processen för omfattning, test och återställning.

Interna system kan inte använda reläet

Kontrollera källzonen under Administration > Device access, värdobjektet under Email > Relay settings > Host-based relay och MTA-loggarna. Om en skanner förväntar sig SMTP AUTH enligt standard är Host-based relay normalt mer pålitligt. Testa det separata, icke RFC-kompatibla Authenticated relay med den aktuella klienten.

Checklista för drift

• Licens, modellstöd, DNS och nödvändiga internettjänster är verifierade.
• MX, TTL, offentliga och interna e-postvägar samt återställning är dokumenterade.
• Den automatiska MTA-regeln är oförändrad och ligger fortfarande högst upp.
• Ingen gammal DNAT-regel kringgår Mail Protection.
• Address Group, routingmål och policymatchning är testade.
• Inkommande SMTP Relay från WAN och utgående värdbehörigheter är korrekt åtskilda.
• Effekterna av SPF/RBL, mottagarverifiering, TLS, DKIM, SPX och banners är klarlagda.
• Externa positiva och negativa tester är slutförda.
• Karantän, spool, lagring och loggar övervakas.
• E-postflödet testas på nytt efter firmwareuppdateringar.

För längre lagring och korrelation använder du Central Firewall Reporting eller skickar Sophos Firewall-loggar till ett SIEM.

FAQ