Konfigurera Sophos Firewall Mail Protection i Legacy mode

I Legacy mode fungerar Sophos Firewall som en transparent e-postproxy. Den interna e-postservern förblir den faktiska SMTP-endpointen; brandväggen vidarebefordrar trafiken genom befintliga brandväggs- och NAT-regler och söker samtidigt efter spam, malware, filtyper och Data Control-träffar.

Detta skiljer sig grundläggande från MTA mode. Brandväggen blir inte en Mail Transfer Agent, tar inte över e-postleverans för skyddade domäner och erbjuder ingen MTA mail spool för denna väg. Ett lyckat SMTP-porttest bevisar därför varken proxyskanning eller att rätt policy tillämpas.

⚠️ En ändring av SMTP Deployment Mode är en global ändring av e-postskyddsvägen. Före växlingen måste backup, befintliga policyer, brandväggs- och NAT-regler samt en testad återställningsväg dokumenteras. Ett MTA-problem är inget skäl att oplanerat växla till Legacy mode.

Legacy mode i nio steg

1. Dokumentera den befintliga inkommande och utgående SMTP-vägen med IP-adresser, portar, NAT och Firewall Rule IDs.
2. Kontrollera om transparent proxy verkligen passar bättre än MTA mode.
3. Säkerställ en konfigurationsbackup och oberoende managementåtkomst.
4. Välj Switch to legacy mode under Email > General settings.
5. Fastställ SMTP hostname, storleksgränser, åtgärd för för stora meddelanden, IP Reputation, DoS-gränser, portar och TLS-beteende.
6. Skapa endast nödvändiga SMTP malware- och SMTP spam-policyer eller kontrollera deras ordning.
7. Begränsa inkommande DNAT- och utgående SNAT-vägar till den faktiska e-postservern.
8. Aktivera Scan SMTP eller Scan SMTPS i de brandväggsregler som faktiskt matchar.
9. Verifiera inkommande och utgående testmeddelanden med Rule ID, policyresultat, certifikat och Legacy-proxyloggar.

Välja Legacy mode eller MTA mode

Legacy mode passar främst befintliga miljöer där den interna e-postservern redan publiceras direkt via NAT och denna väg ska behållas. SFOS ligger transparent mellan den externa motparten och servern. MX-mål, SMTP-mottagning och leveranslogik förblir delar av den befintliga e-postserverdesignen.

MTA mode är det bättre valet när brandväggen själv ska ta emot meddelanden, routa dem per skyddad domän, relaya dem och behålla dem i en spool vid tillfälliga leveransfel. Mail logs och mail spool hör uttryckligen till denna driftsmodell. Den fullständiga konfigurationen finns i Konfigurera Mail Protection i MTA mode.

Enligt SFOS 22-hjälpen är MTA mode inte tillgängligt på XGS 87/87w och XGS 88/88w. Det gör dock inte automatiskt Legacy mode till en lämplig molne-postarkitektur. Microsoft 365, Google Workspace och moderna hostade tjänster använder egna krav för TLS, autentisering och skydd mot missbruk. Deras stöd för en transparent proxy måste bekräftas i förväg.

Kort sagt: MTA mode har ett eget e-postflöde. Legacy mode skyddar en redan fungerande SMTP-väg. Om dessa modeller blandas ihop söker man senare i fel logg, vid fel NAT-mål eller i en spool som inte finns.

Exempeltopologi och återställningsväg

Följande exempel använder dokumentationsvärden och måste anpassas till den verkliga miljön före implementering:

• intern e-postserver 10.20.30.25 i zonen DMZ
• offentlig SMTP-adress 192.0.2.25 på WAN-vägen
• inkommande SMTP-tjänst TCP 25
• valfri SMTPS på TCP 465, endast om peers och server faktiskt använder denna variant
• brandväggsregler SMTP_In_Legacy och SMTP_Out_Legacy

192.0.2.25 tillhör TEST-NET-intervallet och är inget produktionsvärde. Före ändringen utförs ett externt inkommande test och ett utgående test med tidsstämpel. Spara aktuella matchande Rule IDs, den offentliga källadress som används av den utgående servern och certifikatkedjan.

Återställningsvägen består inte bara av att byta tillbaka läget. Även nya skanningsalternativ, policyordning, DNAT, reflexive eller manuella SNAT-regler och tillfälliga tester måste kunna återställas till det dokumenterade tidigare tillståndet.

Fastställa globala e-postinställningar

Där MTA mode är tillgängligt anger hjälpen det som standardläge. Välj medvetet Switch to legacy mode under Email > General settings efter att den dokumenterade återställningsvägen har säkrats. Ett lägesbyte ensamt skapar ingen verifierad Legacy-e-postväg.

Under Email > General settings gäller SMTP hostname endast systemgenererade aviseringar i HELO- och SMTP-bannersträngar; standardvärdet är SMTP. Det ersätter varken produktionsserverns FQDN eller dess publika DNS. Efter en ändring ska därför en SFOS-avisering valideras, inte bara ett vanligt servergenererat meddelande.

Kontroll av XML-API: SFOS 23-dokumentationen anger operationsstatus 506 för Email Configuration, tillsammans med Message.AVGeneralConfInvalidSmtpNtfyHostname. Detta är en meddelandenyckel som inte har omvandlats till läsbar text, inte ett engelskt felmeddelande eller en HTTP-statuskod. Om denna status visas i det faktiska XML-API-svaret ska det inskickade värdnamnet för aviseringar, operationssvaret och den sparade konfigurationen kontrolleras innan ändringen betraktas som lyckad. Nyckeln fastställer inga specifika valideringsregler. Den extra dokumentationsposten bevisar varken att beteendet infördes med SFOS 23 eller att det gäller för REST.

Storleksgräns, åtgärd för stora meddelanden och DoS-skydd

Under Email > General settings > SMTP settings anger Don’t scan emails greater than den maximala meddelandestorleken för skanning. I SMTP-vägen betyder värdet 0 enligt SFOS 22-hjälpen 51,200 KB, inte obegränsat. För större meddelanden finns Accept, Reject och Drop.

Accept levererar ett för stort meddelande utan att skanna det. Reject avvisar det och informerar avsändaren, medan Drop tar bort det utan meddelande. Detta val är ett medvetet risk- och driftsbeslut. Ett otestat Drop försvårar felsökning; ett otestat Accept skapar ett skanningsgap som måste dokumenteras.

Verify sender’s IP reputation kontrollerar avsändarens IP-adress före spamkriterierna i SMTP-policyn och avvisar meddelanden från IP-adresser med dåligt rykte. De sex SMTP DoS-fälten godtar följande intervall i SFOS 22:

• Maximum connections: 1 till 20000 anslutningar till e-postservern
• Maximum connections/host: 1 till 10000 anslutningar från en värd
• Maximum emails/connection: 1 till 1000 meddelanden per anslutning
• Maximum recipients/email: 1 till 256 mottagare per meddelande
• Emails rate: 1 till 20000 meddelanden från en värd per minut
• Connections rate: 1 till 20000 anslutningar från en värd per sekund

Ett tillåtet värde är inte automatiskt lämpligt. Härled produktionsgränserna från den verkliga volymen och en baseline så att legitima sändningstoppar inte behandlas som DoS.

Bypass spam check for SMTP/S authenticated connections hoppar globalt över spamkontrollen för anslutningar som e-postservern rapporterar som autentiserade. Detta är endast acceptabelt efter att autentisering, tillåtna källor och skydd mot missbruk på denna väg har verifierats. En lyckad inloggning ersätter varken malware-skanning eller ett negativt test med en icke-autentiserad anslutning. Domäner under Spam check exceptions är också ett globalt undantag och används inte som en snabb ersättning för ett snävt avgränsat undantag.

Den globala e-postbannern erbjuder Inline, no conversion, MIME part och Off. Inline, no conversion lägger text direkt till utgående meddelanden; MIME part lägger till en separat MIME-del. Off lägger inte till någon banner. Ange endast text under Email banner, exempelvis en kort sekretessinformation. Bannern kräver SMTP- eller SMTPS-skanning i den matchande regeln. Kontrollera ett textmeddelande och ett HTML-meddelande hos mottagaren avseende innehåll, MIME-struktur och presentation. Eftersom ändringar i meddelandekroppen kan bryta en befintlig DKIM-signatur ska även headers på den faktiska utgående vägen kontrolleras.

Planera POP/IMAP och portar separat

POP/IMAP har ett eget CA-val TLS certificate under POP and IMAP TLS configuration. Låt Allow invalid certificate vara avstängt för att avvisa ogiltiga servercertifikat; även här blockerar Disable legacy TLS protocols bara protokoll äldre än TLS 1.1. SMTP-inställningarna ersätter inte denna konfiguration. Hela hämtningsvägen beskrivs i POP/IMAP-skanning av e-post, och CA- och certifikathantering i Certifikathantering.

Legacy mode omfattar även transparent POP3/S- och IMAP/S-skanning. Under POP/S and IMAP/S settings betyder 0 i Don’t scan emails greater than 10,240 KB. Recipient headers anger i vilka headers SFOS söker efter mottagare som används av POP/IMAP-policyer; standardvärdena är Delivered-To, Received och X-RCPT-TO. Ändra dem endast om en infångad meddelandeheader från den använda servern motiverar det.

De dokumenterade standardportarna är SMTP 25, SMTPS 465, POP3 med STARTTLS 110, POP3S 995, IMAP med STARTTLS 143 och IMAPS 993. SFOS kan även skanna e-post på andra portar; hjälpen nämner uttryckligen port 587. En alternativ port måste finnas som tjänst i den matchande brandväggsregeln och höra ihop med det skanningsprotokoll som faktiskt är aktiverat. Enbart ett portbyte gör inte implicit TLS till STARTTLS eller tvärtom.

En POP-IMAP scan-policy kan kombinera avsändar- och mottagargrupper med kriterier som inkommande klassificering, käll-IP-adress, meddelandestorlek eller meddelandeheader. Endast åtgärderna Accept och Prefix subject är tillgängliga. Policyn aktiverar inte proxyn på egen hand: under Scan email content i den matchande brandväggsregeln måste även protokollet POP3, POP3S, IMAP eller IMAPS som faktiskt används väljas.

Överskatta inte TLS på grund av en kryssruta

Under SMTP TLS configuration väljs det CA- eller servercertifikat som ska användas för skanningen. Allow invalid certificate förblir avstängt. Enligt hjälpen stänger Disable legacy TLS protocols endast av protokoll före TLS 1.1 och bevisar inte en konkret TLS 1.2- eller TLS 1.3-session.

Sophos påpekar dessutom en viktig Legacy-begränsning: brandväggen etablerar TLS-anslutningen via domänens IP-adress i stället för domännamnet. Om flera domäner delar en IP-adress kan certifikatvalideringen misslyckas. I detta fall rekommenderar Sophos en annan skyddsväg, till exempel Sophos Email Security. Kontrollen kringgås inte med Allow invalid certificate.

Require TLS negotiation tvingar TLS för valda Remote Hosts eller nätverk; Require sender email domains tvingar det för avsändardomäner. Om TLS-anslutningen inte kan etableras tar SFOS bort de berörda meddelandena. Skip TLS negotiation tillåter avsiktligt okrypterade SMTP-anslutningar till valda peers och hör endast hemma i dokumenterade undantag. Enligt hjälpen godtar varje fält högst 512 värdposter; uteslut överlapp mellan listor för tvång och undantag innan breda urval används.

Använda skanningspolicyer medvetet

Utan en giltig Email Protection-prenumeration kan e-posttrafik fortfarande tillåtas, men får inget Email Protection-skydd. Nåbarhet bevisar alltså varken licens eller skanning. Globala e-postinställningar behandlas före SMTP- och POP-IMAP-policyer. Aktivera IP-rykte i Legacy mode under Email > General settings > SMTP settings med Verify sender’s IP reputation och spara med Apply; MTA-alternativet heter Reject based on IP reputation. Den globala bannern för utgående e-post stöder endast text.

Efter aktivering av Email Protection-prenumerationen tillämpar Sophos Firewall automatiskt standardpolicyn default-smtp-av på SMTP-trafik i Legacy mode. Egna policyer skapas under Email > Policies och bearbetas i listordning. Kontrollera därför först vilken befintlig policy som matchar den aktuella avsändaren och mottagaren.

Skapa nya Legacy-SMTP-policyer under Email > Policies > Add policy med SMTP malware scan eller SMTP spam scan. För att ändra en befintlig policy går du till Email > Policies och väljer Edit för den aktuella policyn. Ändra de inställningar som behövs och spara policyn. Kontrollera därefter policyordningen och upprepa det positiva och det negativa testet.

Under Email > General settings > Malware protection väljs den primära antivirusmotorn globalt som Sophos eller Avira. Om Avira väljs stänger SFOS av Zero-day Protection i SMTP-policyer med Single antivirus. Inventera alla berörda policyer före motorbytet och validera dem igen efteråt.

SMTP malware scan

Ändra policyordningen genom att dra och släppa poster i listan. Dokumentera den tidigare positionen och upprepa båda testerna: en snäv pilotpolicy får inte döljas bakom en bredare policy som redan matchar.

Ange vid skapandet ett tydligt namn och avsändarnas och mottagarnas e-postadress- eller domängrupper. Välj bilagor som ska blockeras under Block file types; med Ctrl+Shift väljs flera typer. MIME whitelist tillåter de valda MIME-headerfälten, medan övriga filtyper blockeras enligt hjälpen. Detta filtypstillstånd kringgår inte antivirus. Disable betyder däremot uttryckligen att e-post inte skannas.

Delivery option for recipient gäller infekterade, skyddade och misstänkta bilagor:

• Don’t deliver: skickar varken meddelandet eller en avisering till mottagaren.
• Deliver original: skickar originalmeddelandet till mottagaren; det rensas inte.
• Remove and deliver: tar bort den infekterade bilagan, aviserar borttagningen och levererar meddelandet. Åtgärden gäller inte filtyper som anges under Block file types; detta fastställer ingen annan leveransåtgärd för blockerade typer.

Skyddade bilagor skannas inte; mottagaren aviseras som standard om inget annat har konfigurerats. Spara med Save och kontrollera faktisk leverans och avisering med ofarliga positiva och negativa fall.

En SMTP malware scan-policy styr blockerade filtyper, MIME-undantag, antivirusskanning och leveransåtgärder. Med Single antivirus gäller den valda motorn enligt hjälpen bara för inkommande meddelanden; utgående meddelanden skannas av båda motorerna. Dual antivirus kör primär och sekundär motor efter varandra.

Åtgärden Quarantine kombineras med åtgärderna för mottagare och administratör. Don’t deliver, Deliver original och Remove and deliver har mycket olika konsekvenser. En skyddad eller icke skanningsbar bilaga får inte automatiskt likställas med malware. Varje åtgärd behöver därför ett testmeddelande, ett förväntat mottagartillstånd och en dokumenterad frigivningsväg.

Quarantine betyder inte automatiskt att mottagaren inte får något meddelande; Delivery option for recipient är fortfarande avgörande. Enligt Sophos fungerar Notify sender endast tillsammans med Don’t deliver. Skyddade bilagor skannas inte, men kan fortfarande utlösa en avisering. Under Delivery option for administrator betyder Don’t deliver att administratörerna inte aviseras; Send original skickar originalmeddelandet till dem. Det kan innehålla farliga eller oskannade bilagor och ersätter inte en säker avisering. Kontrollera avsändar-, mottagar-, administratörs- och karantänresultat separat.

⚠️ Remove attachment under Delivery option for administrator undantas från denna guide: fältnamnet antyder en administratörsåtgärd, men beskrivningen nämner ett meddelande utan bilaga till mottagaren och en borttagningsavisering till administratörerna. Detta fastställer ingen säker leveransmappning. Aktivera inte alternativet som en ny inställning i produktion. Använd Don’t deliver för både mottagare och administratörer i en isolerad pilot för infekterade bilagor, övervaka karantän separat och kontrollera resultaten med ofarliga testmönster. Ändra en befintlig Remove attachment-inställning först efter dokumenterat klarläggande med Sophos Support och kontrollerad verifiering; anta varken ett rent resultat eller automatisk rensning.

En avgränsad pilot i stället för en overifierad exempelpolicy

Begränsa för e-postserver 10.20.30.25 inledningsvis en tydligt namngiven policy till en testmottagargrupp i exempeldomänen example.net; ersätt domän och grupp med egna kontrollerade värden. Lägg till domänen med Create new om den saknas i adressboken. Välj exempelvis Executable files under Block file types, välj Dual antivirus och Quarantine, och planera mottagar- och administratörsåtgärder separat enligt ovan. Lägg endast till ett MIME-tillstånd vid motiverat behov. En skyddad bilaga förblir oskannad; kopiera inte Send original för sådana bilagor blint från en exempelpolicy.

Exempelgränsen 2048 KB hör till Don’t scan emails greater than i de globala SMTP-inställningarna, inte till pilotpolicyn och inte till ett fast produktstandardvärde. Den begränsar skanning till små meddelanden. Planera före införandet åtgärden för större meddelanden och ett test strax över gränsen utifrån faktisk e-postvolym; annars skapar Accept en skanningslucka, eller orsakar Reject och Drop leveransproblem. Egna SMTP-spam- och POP/IMAP-policyer är valfria tillägg efter behov, inte förutsättningar för att enbart skapa NAT-vägen.

SMTP spam scan

Ange ett namn och avsändarnas och mottagarnas e-postadress- eller domängrupper. Välj medvetet exakt matchning eller nyckelordsmatchning för dessa grupper: nyckelordssökningen får inte oavsiktligt bredda omfattningen. Anta inte odokumenterad regex, jokertecken eller AND/OR-regler.

• Inbound email is och Outbound email is: välj riktningen separat; kriterierna är spam, probable spam, virus outbreak eller probable virus outbreak.
• Source IP/network address och Destination IP/network address: ange avsändarens eller mottagarens nödvändiga IP-adress eller nätverk.
• Sender remote blacklist: välj lämplig RBL-grupp för avsändaren.
• Message size: ange en övre eller undre gräns; förväxla inte denna med den globala gränsen för stora meddelanden.
• Message header: välj headerfältet; ange detaljer för Other, välj exakt matchning eller nyckelordsmatchning och ange nyckelordsvärdet.

Reject avvisar meddelandet och informerar avsändaren. Accept levererar det. Prefix subject lägger till ett prefix i ämnesraden och levererar också meddelandet; exempelvis markerar Probable spam ett kontrollerat test. Drop kastar utan att avisera avsändaren; Quarantine behåller meddelandet i karantän. Val av SPX-mall är dokumenterat för Accept och Prefix subject, endast för utgående e-post. Det visar varken SPX-stöd för övriga åtgärder eller automatisk kryptering av varje accepterat meddelande. Spara med Save och kontrollera matchning och åtgärd separat.

En SMTP spam scan-policy kan matcha spamklassificering, källa eller destination, RBL, meddelandestorlek, headers eller en Data Control List. Beroende på väg finns åtgärderna Reject, Accept, Change recipient, Prefix subject, Drop och Quarantine.

Kriteriet Data control list och SPX-tilldelningen i denna policy gäller endast utgående meddelanden. None tillämpar däremot den valda åtgärden på alla meddelanden mellan de angivna avsändar- och mottagargrupperna. Change recipient levererar inte dessutom till den ursprungliga mottagaren, utan ersätter den med den konfigurerade destinationen. Dessa tre omfattningar testas med ett positivt och ett negativt mottagarfall innan policyn placeras i produktionsordningen.

Förbered egna filtyper och Data Control

E-postens fördefinierade filtypskategorier är Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files och Web files. De klassificerar utifrån filändelser eller MIME-headers och är inga säkerhetsomdömen. Executable files innehåller exempelvis exe, cmd, bat och com; pdf finns i både Document files och Page layout files, och application/octet-stream förekommer i flera kategorier. Behandla inte kategorierna som ömsesidigt uteslutande och tillåt inte en generell MIME-header brett för att lösa ett enda bilagefall. Den detaljerade interna referensen finns i Web Protection; kontrollera värdena på målinstallationen innan en mall väljs eller en snäv egen typ skapas.

CCL:er kan upptäcka mönster som kreditkorts- eller socialförsäkringsnummer, postadresser och e-postadresser. Använd syntetiska data för pilotverifiering, aldrig verkliga personuppgifter. Välj endast mönster som passar syfte och region; en matchning bevisar varken uppgifternas äkthet eller en juridisk klassificering.

Ge den egna filtypen ett namn och spara objektet med Save innan policyn ändras. Den separata MTA-vägen för skapande är Email > Policies and exceptions > File type > Add; den ersätter inte Legacy-vägen. Filtyper används även i webbpolicyer; konfigurationen hör till Web Protection. Ge också Data Control List ett tydligt namn och välj Save efter CCL-valet.

I Legacy mode skapas egna filtyper under Email > Policies > File type > Add från en mall, filändelser eller MIME-typer. Filändelser anges utan inledande punkt och endast egna typer kan redigeras. En ny typ läggs inte automatiskt till i befintliga policyer. Öppna den berörda scan-policyn, lägg till filtypen och spara policyn igen. Ett positivt test med en bilaga och ett liknande negativt test visar om den avsedda policyåtgärden verkligen används.

En Data Control List skapas under Email > Data control list > Add av de Content Control Lists som behövs. Filtren Type och Region hjälper till att välja endast relevanta mönster för finansiella uppgifter, identitetsdata eller andra känsliga uppgifter. En listmatchning definierar ännu ingen åtgärd; den anges i den länkade scan-policyn. En liten pilotlista med ett positivt och ett negativt innehållstest är säkrare än en bred samling overifierade CCL:er.

I Legacy mode kan SPX väljas i denna policy för utgående meddelanden. Lösenordsmodell, portal och verifiering är dock ett separat säkerhetsflöde; se Konfigurera SPX-e-postkryptering. Lägg inte till en Data Control List eller SPX-tilldelning i det första grundläggande proxytestet.

En bekräftad felklassificering ska inte åtgärdas genom att en brett tillämpad policy stängs av. I Legacy mode görs en riktad ändring av den relevanta SMTP malware scan- eller SMTP spam scan-policyn; ett positivt test och ett negativt test utanför den avsedda omfattningen måste bekräfta effekten. Skapa och testa e-postundantag på ett säkert sätt beskriver däremot endast undantagsobjektet i MTA mode: källa, avsändare eller mottagare är alternativa utlösare (OR), inte ett exakt kombinerat AND-villkor med alla tre egenskaperna. Detta MTA-undantagsobjekt är inte ett reglage för Legacy mode.

Dokumenterade filtypsmappningar

Denna referens bevarar e-postkategoriernas mappningar; den är varken en tillåtelselista eller bevis på malware. Kontrollera målinstallationens värden före ändringar. Tekniska MIME-token förblir oförändrade, även ovanliga dokumenterade stavningar som text/x-script.phyton; detta bevisar varken standardöverensstämmelse eller en ny egen MIME-regel.

Audio files

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

Backup files

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

Compressed files

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

Configuration files

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

Database files

• Filändelser: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• MIME-headers: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

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

Disk image files

• Filändelser: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME-headers: application/x-cdlink.

Document files

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

Dynamic files

• Filändelser: pl, jsp, asp, php, cgi, shtml.
• MIME-headers: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

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

Executable files

• Filändelser: exe, cmd, bat, com.
• MIME-headers: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Filändelser: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• MIME-headers: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

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

Plugin files

• Filändelser: 8bi, arx, crx, plugin, vst, xll.
• MIME-headers: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

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

Video files

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

Web files

• Filändelser: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME-headers: application/atom+xml.

Använda valfri e-postjournalföring med hänsyn till dataskydd

Ge journalposten ett tydligt namn och spara mottagarvalet och journaldestinationen med Save före följande tester.

Under Email > General settings > Email journaling > Add kan SFOS skicka kopior av inkommande SMTP/S-meddelanden för valda mottagare eller adressgrupper till en separat journaladress. Valet Any omfattar alla inkommande meddelanden. Funktionen gäller endast SMTP/S och journalför inte POP- eller IMAP-trafik.

Journalföring skapar en extra kopia av e-postmeddelandet. Den utgör inte automatiskt ett manipulationssäkert arkiv och bevisar inte att lagstadgade lagringskrav uppfylls. Före aktiveringen fastställs syfte, behöriga mottagare, åtkomst till journalbrevlådan, kryptering, lagringstid, lagringsbehov och ansvarig ägare.

För det första testet väljs en enda testbrevlåda i stället för Any. Ett inkommande meddelande till denna brevlåda ska visas både på den normala destinationen och i journalbrevlådan. Ett meddelande till en mottagare utanför urvalet får inte skapa någon journalkopia. Journaladressen får inte utlösa ett e-postflöde som skickar kopian tillbaka till SFOS och skapar en loop.

Mottagarurvalet utökas först efter det positiva och negativa testet. Vid rollback tas journalposten bort eller återställs till det dokumenterade tidigare tillståndet. Redan levererade kopior finns kvar i journalbrevlådan och måste hanteras enligt dess egna lagringsregler.

Koppla Legacy-e-postobjekt korrekt via XML API

XML-API-referenserna för SFOS 22 och 23 beskriver separata Legacy-e-postobjekt. En menyväg från MTA mode, en platt parametertabell eller ett exempel med alternativ åtskilda av snedstreck är inte en kopieringsklar begäran. API-åtkomst, transport, operationsstatus, olösta meddelandenycklar och kontroll efter skrivning förklaras i Säkra XML API-åtkomst. Följande kopplingar hjälper dig att läsa en befintlig konfiguration; de innebär inget påstående om ett testat skrivande API-anrop och gäller inte automatiskt för REST eller Central API.

Säkra backup, aktuellt objektinnehåll, refererande policyer och ordning före en ändring. Klarlägg den konkreta begäran och motstridiga fältvärden med hjälp av API-hjälpen för den installerade builden eller med Sophos Support. Kontrollera därefter de sparade objekten och den faktiska effekten på e-post separat. Att ett fält anges som obligatoriskt i tabellen säger inget om huruvida andra fält behåller sina tidigare värden när de utelämnas. Inte heller tömning, ersättning eller sammanslagning av listor eller atomära ändringar är belagda därmed.

EmailConfiguration: protokoll och TLS-kontext hör till fältet

Under EmailConfiguration skiljs fält med samma namn åt genom sina överordnade element:

• GeneralSettings/EmailSignature och GeneralSettings/EmailBannerMode gäller den utgående bannern. API-tabellen anger lägesvärdena inline_plain, mimepart och off; exemplet innehåller däremot alternativ som liknar UI-texterna. Behandla inte dessa texter som identiska API-värden utan kontroll. EmailSignature är en sträng med högst 2000 tecken enligt API-tabellen.
• SMTPSSettings/DontScanEmailsGreaterThan är SMTP-skanningsgränsen i KB; SMTPSSettings/ActionForOversizeEmails är den separata åtgärden Accept, Reject eller Drop. Även BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings och de sex DoS-gränsvärdena finns i SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan är en annan heltalsgräns i KB. POPIMAPSettings/RecipientHeaders/Header är en lista med headersträngar för mottagaridentifiering, inte en SMTP-mottagarlista.
• SMTPTLSConfiguration och POPSIMAPTLSConfiguration innehåller var sin uppsättning av TLSCertificate, AllowInvalidCertificate och DisableTLS1. SMTP-certifikatet ersätter inte POP/IMAP-certifikatet. RequireTLSWithHost, RequireTLSWithSenderDomain och SkipTLSHosts finns i SMTP-TLS-kontexten; de är separata listor med strängar, inte ett gemensamt på/av-undantag. Förväxla inte UI-gränsen på 512 värdposter med API-tabellens uppgift om högst 512 tecken.

Håll API-tabellen, exemplet och UI-referensen åtskilda: API-tabellen anger 1024 som standardvärde för båda skanningsgränserna. För MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate och ConnectionsRate anger den i tur och ordning 5000, 100, 100, 100, 1000 och 100. Exemplet använder däremot 1000 för MaximumEmailsConnection; UI-exemplet 2048 KB som förklaras ovan är i sin tur inget standardvärde. Betydelsen av 0 förblir den protokollspecifika UI-referens som beskrivs ovan, inte en inställning för obegränsad storlek som härleds från API-exemplet.

API-tabellen tillåter 1 till 512 för MaximumRecepientsEmail, medan UI-referensen anger 1 till 256 för Maximum recipients/email. API-stavningen MaximumRecepientsEmail förblir oförändrad; härled varken ett korrigerat fältnamn eller att 512 säkert är giltigt i UI från detta. De övriga fem DoS-intervallen stämmer med UI-intervallen som anges ovan. Det sparade tillståndet och hjälpen för målbuilden förblir avgörande.

Ytterligare konflikter hindrar att exemplet kopieras blint: för VerifySendersIPReputation anger tabellen on/off och listar Disable som standardvärde, medan exemplet visar Enable. För SMTPSDosSettings står datatypen INTEGER bredvid tabellens standardvärde Disable och exempelvärdet Enable. Enligt tabellen har BypassSpamCheck standardvärdet Disable, men exemplet aktiverar det. Båda TLS-kontexterna tillåter ogiltiga certifikat i exemplet. Använd varken dessa osäkra exempelinställningar eller de motstridiga uppgifterna för att konstruera en förmodat giltig payload; det säkra beslut om TLS och bypass som beskrivs ovan står fast.

För operationen Email Configuration dokumenteras 200 med Message.AVGeneralConfUpdateSuccess, 500 med Message.AVGeneralConfUpdateFail och 505 med Message.ASConfigSubOperationFail. SFOS 23 lägger till kopplingen 506 med Message.AVGeneralConfInvalidSmtpNtfyHostname, som redan förklaras ovan. Dessa är operationsstatusar och olösta nycklar, inte HTTP-koder eller bekräftade texter från körning. Läs särskilt efter 505 först tillbaka SMTP-, POP/IMAP- och TLS-inställningarna; förutsätt varken fullständig rollback eller fullständig lagring och upprepa inte anropet blint.

SMTP-malware: behandla mottagare och administratörer oberoende av varandra

Objektet heter AntiVirusMailSMTPScanningRules. Name anger policyn och After/Name den referens till föregående policy som visas i exemplet. SenderList/Sender och ReceiverList/Receiver är separata listor; BlockFileTypes/FileType är listan över blockerade filtyper. API-tabellen anger dessutom WhiteList som MIME-lista, men visar ingen motsvarande nästling i exemplet. Hitta inte på något ytterligare överordnat XML-element utifrån detta.

För Scanning anger API-tabellen Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) och Disable, med standardvärdet Disable. Exemplet Disable/Disable är varken en fullständig uppräkning av tillåtna värden eller ett användbart värde för den önskade antivirusskanningen. Quarantine och NotifySender är separata reglage med Enable/Disable; enligt API-tabellen är standardvärdet Disable för båda. Dessa tabellvärden ersätter varken den befintliga standardpolicyn eller bevis på aktuell skanningsstatus.

För infekterade, misstänkta och skyddade bilagor finns vardera två åtgärder som väljs oberoende av varandra:

• Mottagare: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment med Don'tDeliver, DeliverOriginal eller RemoveAndDeliver.
• Administratörer: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment med Don'tDeliver, SendOriginal eller RemoveAttachment.

API-tabellen anger Don'tDeliver som standardvärde för alla sex åtgärdsfält. Detta ska inte likställas med UI-beskrivningen av en standardavisering för skyddade bilagor och bevisar inget aktuellt leveranstillstånd. De effekter och begränsningar som förklaras ovan förblir avgörande: DeliverOriginal respektive SendOriginal kan vidarebefordra oskannade eller farliga bilagor; karantän bevisar inte att leverans till mottagaren har förhindrats. Det olösta administratörsalternativet RemoveAttachment förblir uteslutet även om API anger det som ett värde. Kontrollera avsändar-, mottagar-, administratörs- och karantänresultat separat.

AntiSpamRules: blanda inte ihop matchning, ordning och åtgärd

I AntiSpamRules identifierar Name regeln. After/Name är referensen som visas i exemplet för dess placering efter en annan regel. Säkra den faktiska ordningen och det refererade regelnamnet före Add, Edit eller Order; dokumentationen beskriver därmed inte automatiskt någon syntax för den första positionen eller för föregångare som inte finns.

RecipientList/Action med RecipientEmail och SenderEmailList/Action med SenderEmail styr mottagar- respektive avsändarmatchningen separat. API-tabellen anger Equals eller Contains för båda matchningsåtgärderna, med tabellstandardvärdet Contains. De är inte leveransåtgärden. MarkSpamIf innehåller däremot Condition och de tillhörande OtherHeader, Operator och MatchIs. En meddelandestorlek kräver en storleksjämförelse; en header kräver en textmatchning; en klassificering kräver ett klassificeringsvärde. Den platta tabellraden beskriver MatchIs som en meddelandestorlek i heltalsform, men exemplet använder Spam. Dra inte slutsatsen att alla villkorstyper är numeriska. Tabellvärdet 4 och de olika villkorsbeteckningarna i exemplet är ingen grund för en påhittad header- eller enum-mappning.

SMTPAction/Action och SMTPAction/ActionParameter bestämmer SMTP-åtgärden och dess tilläggsvärde; SMTPAction/Quarantine är separat från dessa. POPIMAPAction/Action och POPIMAPAction/ActionParameter hör till hämtningsvägen, vars exempel endast visar Accept och Prefix Subject. Överför inte en SMTP-åtgärd till POP/IMAP. För Change recipient är parametern den ersättande leveransdestinationen, inte en extra journaladress. Begränsningarna för utgående Data Control och SPX som beskrivs ovan står fast.

Även här motsäger exemplet och tabellen varandra: för Quarantine visar exemplet Enable/Disable, medan tabellen tillåter 0 och Enable. SMTP-åtgärdstabellen listar dessutom Accept With SPX; härled inte denna API-stavning från UI-etiketten eller ett vanligt Accept. Klarlägg det konkreta villkorsberoende värdet före ett skrivande API-anrop i stället för att skicka exempelalternativen som är åtskilda av snedstreck.

För Order SMTP Scanning Policy anges 200 med Message.SpamRuleUpdateRuleOrderSuccess samt både 500 och 505 med Message.SpamRuleUpdateRuleOrderFail. Samma nyckel betecknar alltså två statusrader; den förklarar inte deras orsak. För Add SMTP Scanning Policy dokumenteras 502 med Message.SpamRuleRecordExists. Kontrollera befintligt namn, innehåll och sparad ordning före ett nytt Add eller Order; den centrala API-säkerhetskontrollen och både det positiva och det negativa policytestet gäller även här.

DataControlList: signaturer är ännu ingen leveransåtgärd

Legacy-objektet DataControlList innehåller Name och Signatures/Signature, en lista med CCL-signaturnamn. Den platta tabellen använder beteckningarna name och signaturename för dessa; det är inget skäl att tyst byta namn på XML-taggarna som visas i exemplet. Tabellen anger namnet som en obligatorisk sträng med högst 255 tecken och signaturerna som en valfri lista med strängar. Hämta det faktiska signaturnamnet från det egna tillgängliga CCL-urvalet, inte genom att kopiera landsexemplet. Åtgärden bestäms fortfarande först av den länkade policyn. Använd inte det andra objektet MTADataControlList i stället för detta Legacy-objekt.

För Add Data Control List och Update Data Control List anger båda referenserna 502 med Message.DLPAddSameName samt 545 med Message.MTAModeDisableCheck. 545 är en dokumenterad status-/nyckelkoppling, inte en verifierad uppgift om att Legacy mode förbjuder denna funktion eller att ett lägesbyte skulle krävas. Byt därför inte läge för att felsöka. Kontrollera den sparade listan och dess referenser före ett nytt Add eller Update och klarlägg det faktiska svaret med hjälp av hjälpen för den installerade builden eller med Sophos Support.

AVASAddressGroup: exakt en typberoende gren

AVASAddressGroup är Legacy-adressgruppen för dessa e-postregler, inte ett objekt vars likvärdighet har bevisats av en MTA-menyväg. Name identifierar gruppen; API-tabellen anger högst 50 tecken och högst 255 för den valfria Description. Tabellen för GroupType anger RBLIPv4, RBLIPv6, IPAddress och EmailAddressOrDomain, medan exemplet använder det generella RBL. Normalisera inte dessa stavningar utan att redovisa det.

Kommentaren i exemplet kräver exakt en gren som passar typen: RBLList/RBLName eller RBLFile, IPAddressList/IPAddressNetwork eller IPAddressFile, respektive EmailAddressList/EmailAddressDomain eller EmailAddressFile. Listposterna är strängar; tabellen anger att flera värden tillåts och att dubbletter ignoreras. Exemplet visar alternativen tillsammans, men är ingen uppmaning att skicka alla listor och filer. För e-post-/domängrupper skiljer EmailImportType mellan värdena Manual och Import. Tabellen anger formaten csv och txt för EmailAddressFile, men beskriver motsägelsefullt fältet som manuell inmatning; exemplet hänvisar till filnamnet i en multipart-begäran. Inget av detta belägger en fullständig multipart-koppling eller ett säkert importanrop. Klarlägg dessa detaljer för den aktuella builden före en import.

För Add Address Group dokumenteras 502 med Message.AddrGrpRecordExists, 541 med Message.AddrGrpImportFailed, 542 med Message.AddrGrpEmptyFile1 och 543 med Message.AddrGrpSomeEmailNotImported. Härled varken vilka poster som faktiskt importerats eller en fullständig rollback från de olösta nycklarna. Jämför de sparade medlemmarna med den avsedda listan före nästa import.

För Delete Address Group har 504, 505 och 506 samma nyckel Message.AddrGrpForeignKeyExists; 507 är kopplad till Message.AddrGrpEmailArcKeyExists. Nycklarna skiljer inte säkert mellan de enskilda refererande objekten. Inventera policyer och journalreferenser före borttagning, utvärdera det exakta operationssvaret och kontrollera därefter om gruppen finns kvar. Ta inte blint bort en länkad skyddspolicy för att tvinga igenom ett borttagningsanrop.

TrustedDomain, journalföring och motorval har olika omfattning

AntiSpamTrustedDomain/DomainList/DomainName är en lista med domänsträngar. Add och Delete använder DomainName som listidentitet. API-beskrivningen talar om att kringgå skanning för e-post från betrodda domäner, men anger inte exakt vilka skannrar som kringgås. UI beskriver Spam check exceptions som ett spam-undantag. Utvidga inte dessa två uppgifter till vare sig en garanti för alla skanningar eller en påvisad exakt likvärdighet mellan API och UI. Hantera domäner endast med ett dokumenterat syfte och snäv avgränsning; kontrollera listan och den förväntade skyddseffekten före och efter Add eller Delete. Hitta inte på en fullständig XML-begäran som saknas på Delete-sidan.

AntiSpamEmailArchiver skapar däremot kopior: Name namnger posten, RecipientList/Recipient begränsar originalmottagarna och SendCopyOfEmailTo är den separata kopieadressen. Enligt API-tabellen är namn, mottagare och kopieadress obligatoriska; namn och kopieadress får ha högst 50 tecken. Mottagarraden beskrivs som en skalär sträng, medan exemplet visar den under ett överordnat listelement. Lös inte denna avvikelse med en egen påhittad catch-all-payload. Piloten med en enda brevlåda som beskrivs ovan, inklusive dataskydd, loopskydd och negativt test, gäller även för automatisering; en mottagarändring är inte en ändring av kopieadressen.

MalwareProtection/PrimaryAntiVirusEngine är i sin tur en global skalär motorväljare, inte ett mottagarfilter eller en enskild skanningspolicy. API-tabellen anger Sophos som standardvärde; exemplet Sophos/Avira visar alternativ, inte ett kombinationsvärde som ska skickas. Effekten av Avira på Zero-day Protection i SMTP-policyer med Single antivirus, som förklaras ovan, måste fortfarande kontrolleras. Kontrollera det globalt sparade värdet och samtliga berörda policyer efter ett byte; separata dokumentationsvägar gör dem inte till oberoende motorkonfigurationer.

Kombinera NAT och brandväggsregler

Publicera den inkommande SMTP-vägen

Välj rätt IP-familj under Rules and policies > NAT rules och öppna Add NAT rule. Ett IP-värdobjekt för den interna servern måste finnas under Hosts and services > IP host för att den ska visas under Translated destination (DNAT). I det enkla inkommande exemplet förblir Translated source (SNAT) och Translated service (PAT) Original; välj under Original service endast använda SMTP-tjänster, exempelvis SMTP och SMTP[S]. Kontrollera alla fält före Save. NAT-destinationsöversättning är inte samma sak som brandväggsfältet Destination networks, som kvalificeras separat nedan.

För inkommande meddelanden översätter en DNAT-regel den offentliga WAN-adressen till den interna e-postservern. Original Source begränsas så långt e-postdesignen tillåter; Original Destination är den avsedda offentliga adressen; Translated Destination är 10.20.30.25 eller den faktiska e-postservern. Original service och translated service förblir begränsade till de SMTP-portar som verkligen erbjuds.

En reflexive regel skapar dessutom SNAT för motsatt riktning. Den väljs endast om exakt denna offentliga källidentitet är avsedd för den utgående vägen. Flera WAN-länkar, smarthosts eller avvikande operatörsvägar kräver en egen routing- och SNAT-design. Den allmänna ordningen och destinationszonen efter NAT förklaras i Publicera en server med DNAT.

Använda två snäva brandväggsregler

Välj den faktiska protokollfamiljen IPv4 eller IPv6 under Rules and policies > Firewall rules för att skapa en regel och öppna Add firewall rule > New firewall rule. Ange namn och nödvändiga fält och spara med Save. Använd inte artikelns IPv4-exempeladresser i en IPv6-regel.

⚠️ Beskrivningarna av Destination networks motsäger varandra: Legacy-e-postexemplet anger den interna servern, medan det allmänna DNAT-flödet baserar brandväggsmatchningen på den ursprungliga offentliga destinationen. Guiden löser inte det specifika proxyfallet genom att gissa. Dokumentera den redan styrkta inkommande regelmatchningen och behåll den för piloten. Härled ingen ny produktionsregel från någon av mappningarna och ändra inte destinationen utifrån antaganden. Klarlägg en ny väg med Sophos Support eller lämplig kontrollerad verifiering före godkännande, och styrk den med Rule ID, DNAT-träff och paketfångster före och efter översättningen. Den utgående SNAT-varianten löser inte konflikten.

För verifiering är separata regler tydligare än en dubbelriktad regel med flera zoner och Any-objekt:

• Inkommande: WAN till den interna e-postserverns zon, SMTP-slutpunkt 10.20.30.25, endast nödvändiga SMTP-tjänster, logging aktiverad. Slutpunkten är inget föreskrivet värde för det olösta fältet Destination networks.
• Utgående: den interna e-postserverns zon och host till WAN eller den specifika smarthosten, endast nödvändiga SMTP-tjänster, logging aktiverad

Under Scan email content aktiveras Scan SMTP i båda nödvändiga riktningarna och Scan SMTPS endast när SMTPS faktiskt används. Om standardporten för valt protokoll saknas under Services erbjuder SFOS Add ports. För en alternativ port ska motsvarande tjänst definieras medvetet. Tjänst, NAT, serverlistener och skanningsalternativ måste beskriva samma portväg; Add ports ersätter inte denna kontroll.

Placera reglerna ovanför mer allmänna regler som redan matchar samma trafik. Efter att de har sparats är den loggade Firewall Rule ID avgörande. Regelstruktur, NAT-zon och ordning behandlas i Konfigurera Sophos Firewall-regler säkert.

Valfritt: använda en annan offentlig källadress för utgående trafik

Denna konfiguration gäller vidarebefordrad SMTP-trafik från den interna servern, inte systemgenererade MTA-meddelanden. Den är användbar när en annan tilldelad offentlig identitet behövs i stället för WAN-MASQ-adressen. Operatörens tilldelning, routing, SPF, RDNS och operatörsgodkännande måste passa denna identitet; SNAT ändrar inte dessa förutsättningar.

1. Välj under Network > Interfaces > Add interface > Add alias det faktiska fysiska WAN-gränssnittet, IP version IPv4 och den tilldelade adressen med rätt IPv4/Netmask; Save. Operatörsväg, Device Access och aliaskontroller beskrivs i Konfigurera en alias-IP.
2. Skapa under Hosts and services > IP host > Add en namngiven värd för samma offentliga adress: IP family IPv4, Type IP, IP address den tilldelade adressen; Save. Ett värdobjekt ensamt binder ingen adress till gränssnittet.
3. Begränsa under Rules and policies > NAT rules > New NAT rule Original source till den faktiska interna e-postservern och ange den offentliga IP-värden som Translated source (SNAT). Begränsa Original destination till nödvändiga e-postdestinationer eller smarthost och Original service till nödvändiga SMTP-tjänster. Translated destination (DNAT) och Translated service (PAT) förblir Original. Inbound interface och Outbound interface måste motsvara den faktiska server-WAN-vägen. Spara med Save och placera ovanför andra SNAT-regler som också matchar; kontrollera NAT- och brandväggsordning separat. NAT-grunder förklarar första matchande regel. Any, Top, Port1 och Port2 i exempel är inte obligatoriska värden.
4. Skapa under Rules and policies > Firewall rules > Add firewall rule > New firewall rule en lämplig utgående IPv4-regel eller kontrollera den befintliga snäva regeln: Action Accept, faktisk serverzon och servervärd som källa, WAN och nödvändiga destinationer, endast nödvändiga SMTP-tjänster, Log firewall traffic aktiverat. Välj Scan SMTP och vid behov Scan SMTPS enligt ovan; Save och kontrollera brandväggsordningen oberoende av NAT.
5. Skapa en ny SMTP-anslutning till en kontrollerad extern mottagare. Kontrollera tillsammans Firewall Rule ID, NAT Rule ID, översatt käll-IP i fångsten eller hos den externa mottagaren och faktisk leverans. En befintlig session eller ett SMTP-porttest räcker inte. Testa också negativt med en källa utanför omfattningen eller en otillåten tjänst.

Återställ först de dokumenterade reglerna och deras ordning vid återgång, och kontrollera sedan tidigare käll-IP och leverans med en ny anslutning. Ta bort alias och IP-värd endast om ingen annan tjänst är beroende av dem.

Verifiera e-postflöde och proxyskanning

I den utgående brandväggsregeln avgör During scheduled time när regeln gäller. Välj medvetet All the time för en ständigt tillgänglig e-postserver. Ett begränsat schema kan ändra regelmatchningen utanför tidsfönstret; kontrollera även där Rule ID och e-postflöde. Detta är inget schema för SNAT-regeln. Brandväggsregeln som automatiskt skapas när MTA aktiveras hör till ett annat e-postflöde och ersätter inte denna Legacy-serverregel; använd MTA-guiden för den vägen.

Skicka först ett litet externt meddelande till en testbrevlåda. Låt därefter den interna e-postservern skicka ett andra meddelande till en kontrollerad extern mottagare. Ge båda testerna unika ämnesrader och UTC-tidsstämplar.

För STARTTLS på port 25 och en direkt TLS-anslutning på port 465 kan följande kontroller, som inte ändrar systemet, vara till hjälp från ett behörigt testsystem:

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

Ersätt mail.example.net med den verkliga FQDN och testa endast portar som faktiskt erbjuds. Dessa OpenSSL-kommandon visar den presenterade certifikatkedjan och de förhandlade TLS-parametrarna; granska eventuella fel vid certifikatverifieringen. De verifierar inte uttryckligen det förväntade värdnamnet och kan fortsätta trots verifieringsfel, så en anslutning är inte ett bevis på lyckad certifikatautentisering. De bevisar varken lyckad e-postleverans eller skanning av malware, spam eller Data Control.

I Log Viewer måste källa, destination, tjänst, åtgärd och Firewall Rule ID stämma överens med de nya reglerna. För Legacy SMTP/S-proxyn korreleras awarrensmtp.log och awarrenmta.log med samma tidsstämpel. Loggfilerna förklaras i Sophos Firewall-tjänster och loggar.

Utför därefter separata negativa tester för brandväggsregelns omfattning och matchningen mot meddelandepolicyn. En källa eller tjänst utanför pilotens omfattning får inte matcha pilotens brandväggsregel och måste följa det dokumenterade utfallet för tillåtelse eller blockering; en annan auktoriserad regel kan fortfarande ge skydd. Ett testmeddelande utan pilotpolicyns kriterium får inte matcha den policyn eller få dess specifika åtgärd, men ska fortfarande omfattas av all tillämplig standardskanning eller annan skanning. Dokumentera för varje fall förväntad Firewall Rule ID, policy och leveransutfall och jämför dem med det observerade resultatet. Använd inte verklig malware vid produktionstestning; använd etablerade ofarliga testmönster och en kontrollerad brevlåda för skanningsverifieringen.

Avgränsa fel efter symtom

SMTP fungerar, men policyn tillämpas inte

Kontrollera först Firewall Rule ID. Om en annan regel matchar korrigeras ordning, källa, destination, NAT-mål och tjänst. Om den förväntade regeln matchar måste Scan SMTP eller Scan SMTPS, policyordningen och avsändar- och mottagargrupperna passa testet. En policy i sig aktiverar inte den transparenta proxyn.

Inkommande e-post når inte servern

Kontrollera offentlig destinationsadress, DNAT-träff, translated destination, destinationszon, serverlistener och returväg separat. En öppen TCP-anslutning fram till brandväggen bevisar inte att DNAT och brandväggsregeln når den interna servern. Packet Capture och Rule ID måste visa ingång och vidarebefordran.

Utgående e-post använder fel offentlig IP-adress

Kontrollera SNAT, reflexive-regeln, WAN-gateway, SD-WAN-route och beteendet för reply packets. Legacy-proxyn väljer inte automatiskt den offentliga källadress som behövs för SPF, RDNS eller operatörens godkännande. Bevisa den konkreta vägen före en global ändring av Route Precedence.

TLS misslyckas efter att skanningen har aktiverats

Registrera FQDN, destinations-IP, certifikat, utfärdare, kedja och förhandlad version. Om flera domäner delar en IP-adress kan den dokumenterade IP-baserade certifikatkontrollen vara orsaken. Allow invalid certificate aktiveras inte som snabb lösning.

Ett meddelande saknas och inget syns i MTA mail spool

Detta är inget användbart framgångskriterium i Legacy mode, eftersom mail spool och MTA-specifika mail logs hör till MTA mode. Den relevanta kedjan består här av brandväggsregeln, NAT, SMTP-serverloggar, Log Viewer, awarrensmtp.log och awarrenmta.log. Kontrollera meddelanden i karantän separat under Email > SMTP quarantine.

Genomföra en säker rollback

För rollback återställs först pilotreglerna och skanningsalternativen till dokumenterat tidigare tillstånd. Därefter tas nya policytilldelningar bort eller deras ordning återställs. Tillfälliga ändringar av DNAT, SNAT eller certifikat tas endast bort om ingen annan tjänst är beroende av dem.

Först därefter återställs SMTP Deployment Mode om ändringen omfattade denna växling. Det ursprungliga inkommande och utgående e-postflödet måste åter fungera med förväntade Rule IDs, offentliga adresser och serverloggar. Meddelanden, karantäninnehåll eller proxyloggar raderas inte som standardåtgärd vid rollback.

Driftchecklista

• Transparent proxy har valts medvetet och MTA-krav har uteslutits.
• Backup, managementåtkomst och ursprungliga Rule IDs är dokumenterade.
• SMTP hostname, storleksgränser för SMTP och POP/IMAP, åtgärden för för stora meddelanden, IP Reputation och DoS-gränserna är motiverade.
• Använda standard- eller alternativa portar och POP/IMAP recipient headers stämmer med den verkliga servervägen.
• Den primära antivirusmotorn och dess effekt på Zero-day Protection i Single antivirus-policyer har kontrollerats.
• Certifikat, TLS-undantag och berörda domäner har kontrollerats.
• DNAT, SNAT, destinationszon och verkliga serverportar stämmer överens.
• Inkommande och utgående brandväggsregler är snäva, loggade och bevisat matchande.
• Standardpolicyer och egna policyer har en spårbar ordning.
• Valfri journalföring är begränsad till nödvändiga mottagare och har ett dokumenterat syfte för dataskydd och lagring.
• Positivt, negativt, TLS- och leveranstest har lyckats.
• Legacy-proxyloggar och e-postserverloggar kan tidskorreleras.
• Ansvarig, granskningsdatum och fullständig återställningsväg är dokumenterade.

FAQ