Skapa och testa e-postundantag i Sophos Firewall på ett säkert sätt

Ett e-postundantag i Sophos Firewall tillåter inte bara en avsändare. Det hoppar över utvalda säkerhetskontroller för en definierad SMTP-väg. Just därför kan det lösa en bekräftad falsk positiv på ett precist sätt, men också obemärkt stänga av SPF, skanning efter skadlig kod, Zero-Day Protection eller DKIM-kontroller.

⚠️ Skapa ett undantag först efter att en falsk positiv har kunnat återskapas. Hoppa bara över den berörda kontrollen. Välj det snävaste tillförlitliga villkoret, eftersom källvärd, avsändare och mottagare är alternativ och inte ett gemensamt OCH-villkor. All checks och breda jokertecken är ingen snabb standardlösning.

Skapa undantaget i sju steg

1. Dokumentera testtid, SMTP-käll-IP, kuvertavsändare, mottagare, ämne, Message-ID och den exakta orsaken till avvisningen.
2. Kontrollera om DNS, routing, relay, TLS eller själva e-postpolicyn orsakar felet i stället för en säkerhetskontroll.
3. Välj bara den bevisat berörda kontrollen under Email > Policies and exceptions > Add an exception.
4. Aktivera bara det snävaste lämpliga villkoret under Sources or hosts, Sender addresses eller Recipient addresses.
5. Testa ett likvärdigt meddelande positivt och minst en variant utanför omfattningen negativt.
6. Jämför resultat och Reason före och efter under Email > Mail logs; testa andra skydd separat med ofarliga fall.
7. Dokumentera ägare, motivering och granskningsdatum och ta bort undantaget när orsaken har åtgärdats.

Vad ett undantag faktiskt hoppar över

SFOS grupperar de kontroller som kan hoppas över efter deras effekt. Under Spam protection finns RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF och BATV. Malware protection omfattar Malware och Zero-day protection. Under Other finns Data protection, File protection, Encryption, Banner addition, DKIM signing och DKIM verification.

Detta är inte en bekvämlighetslista. Ett undantag för SPF låter exempelvis återstående antispam- och malwarekontroller vara aktiva. Ett undantag för Malware eller Zero-day protection tar däremot bort en central innehållskontroll för alla meddelanden som matchar omfattningen. Encryption, DKIM signing eller DKIM verification ändrar dessutom sekretessen och integritetskontrollen för det utgående eller inkommande e-postflödet.

Det här undantaget hör till MTA mode. En SMTP route and scan-policy kombinerar routing med åtgärder för spam, malware, filer och data. I legacy mode fungerar SFOS som transparent proxy och använder separata SMTP malware scan- och SMTP spam scan-policyer; MTA-undantagsobjektet är inte rätt kontroll där. Se Konfigurera Mail Protection i MTA-läge på Sophos Firewall och Konfigurera Mail Protection i legacy-läge.

Encryption avser här e-postkryptering i MTA-policyn, exempelvis SPX Email Encryption, inte SMTP-transportkryptering. Require TLS negotiation, certifikatvalidering och Skip TLS negotiation styrs separat under Email > General settings > SMTP TLS configuration. Ett e-postundantag löser därför inte TLS-handskakning, routing, relay eller brandväggsregler.

Förstå matchningen innan du sparar

De tre grupperna bildar inget OCH-villkor. Det officiella SFOS 22.0-API:t benämner dem ForTheseSourceHost, ORTheseSenderAddresses och ORTheseRecipientAddresses. När flera grupper är aktiva räcker en träff på källvärd eller avsändare eller mottagare. Käll-IP, partnerdomän och pilotbrevlåda skapar alltså tre matchningsvägar, inte en snävare kombination.

Objektet kan inte uttrycka OCH mellan grupperna; två undantag skulle också bredda omfattningen. Om två samtidiga kriterier krävs ska orsaken korrigeras eller flödet separeras med en lämplig policy eller gatewayväg.

Sources or hosts

SFOS accepterar IP-adresser, IP-intervall, IP-listor, nätverk eller FQDN som källa. FQDN med jokertecken stöds inte för undantag för e-postvärdar. *.example.net är därför ingen giltig ersättning för den observerade SMTP-källadressen. För localhost behövs inget undantag, eftersom SFOS inte skannar lokala e-postmeddelanden som standard.

För molnbaserade e-posttjänster eller distribuerade gateways kan en enda IP-adress vara för snäv, medan ett helt leverantörsnät kan vara alldeles för brett. Använd bara ett publicerat källobjekt som faktiskt har observerats i det egna e-postflödet. Om andra kunder delar leverantörens IP-adresser kan även detta objekt vara för brett. Undanta inte en säkerhetskontroll enbart på grundval av det nätet.

Avsändare och mottagare

För Sender addresses och Recipient addresses tillåts en adress som sender@example.net eller ett jokertecken som *@example.net. En andra grupp är ingen snävare förankring eftersom den kopplas med ELLER. En avsändare är inget oberoende förtroendebevis när SPF eller DKIM undantas; ett mottagarundantag gäller matchande meddelanden från alla avsändare.

BATV har en ovanlig specialregel: För att hoppa över BATV-kontrollen för e-post från en avsändare måste adressen anges både under Sender addresses och under Recipient addresses. Om något av fälten saknas är undantaget ofullständigt för detta BATV-fall.

Skapa ett snävt undantag

Exemplet gäller en bekräftad falsk SPF-positiv från en dedikerad partnergateway. 203.0.113.25 är en dokumentationsadress som ersätts med publik IP från Mail logs. Exemplet passar bara om IP-adressen enbart tillhör den betrodda gatewayen; för ett delat molnrelay blir undantaget för brett.

1. Öppna Email > Policies and exceptions > Add an exception.
2. Ange ett spårbart namn som FP-SPF-partner-example-review-2026-09-30.
3. Välj enbart SPF bland kontrollerna som ska hoppas över.
4. Ange värden 203.0.113.25 under Sources or hosts.
5. Lämna Sender addresses och Recipient addresses avstängda eller tomma; de lägger till ELLER-träffar.
6. Spara utan att lägga till fler värdar eller kontroller.

Namnet innehåller avsiktligt orsak och granskningsdatum. Det ersätter dock inte dokumentation i ändringen eller supportärendet. Namnet tvingar inte tekniskt fram ett utgångsdatum; ägaren måste faktiskt genomföra granskningen.

Genomför positiva och negativa tester

Partnern skickar samma kontrollerade meddelande igen; det får inte längre misslyckas med bekräftad SPF-Reason. Filtrera under Email > Mail logs på tid, avsändare, mottagare eller ämne samt Result och Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification och BATV har egna Reason-filter. För djupare korrelation används smtpd_main.log och vid avvisningar smtpd_reject.log; Sophos Firewall-tjänster och loggar förklarar dem.

Kör sedan ett negativt test via en kontrollerad SMTP-väg som inte undantas. Det får inte kringgå den dokumenterade kontrollen på grund av detta undantag. Med ett rent källvärdsundantag är andra avsändare eller mottagare via samma IP inte negativa tester: de matchar samma ELLER-gren. En ofarlig fil kan separat testa Malware och File Protection; använd inte verklig skadlig kod.

En lyckad leverans bevisar inte omfattningen. Den officiella Mail logs-dokumentationen beskriver Reason och leveransstatus, men inget fält “matched exception” och ingen lista över överhoppade kontroller. Bedöm därför Reason före/efter, konfiguration och separata positiva och negativa fall tillsammans. Framställ inte leveransen som bevis på att alla andra skyddsfunktioner kördes.

Identifiera riskfyllda undantag

Redan ett brett domänjokertecken eller ett stort källnät kan ta bort skyddet för en betydande del av e-postflödet. Att ange båda gör inte omfattningen snävare utan lägger till ELLER-träffar. Särskilt undantag för Malware, Zero-Day Protection, Data protection och File protection kräver ett dokumenterat riskbeslut och en mycket liten, självständigt tillförlitlig omfattning. Vid ett fortfarande okänt skanningsfel ska inte hela gruppen stängas av i förebyggande syfte.

Även de till synes funktionella alternativen är säkerhetsrelevanta. Om Encryption hoppas över kan konfidentiellt innehåll skickas oskyddat. Utan DKIM signing saknas den planerade utgående signaturen, och utan DKIM verification utvärderas inte ett inkommande identitetsbevis. Ett Banner-undantag kan ta bort obligatoriska texter eller märkningar. Sådana ändringar ska samordnas med ansvariga för e-post och regelefterlevnad.

Avgränsa fel efter symptom

Meddelandet avvisas fortfarande

Bedöm först den nya loggposten i stället för det gamla testmeddelandet. Den faktiska käll-IP-adressen, kuvertavsändaren, mottagaren och Reason måste matcha omfattningen och den valda kontrollen. Ett FQDN med jokertecken under Sources or hosts fungerar inte. Om meddelandet avvisas på grund av RBL, IP reputation, RDNS/HELO eller en annan kontroll löser ett undantag enbart för SPF inte denna separata orsak.

Undantaget matchar för många meddelanden

Jämför de tre grupperna var för sig med flödet. Varje aktiv ELLER-grupp ökar antalet träffar. Minska undantaget till en tillförlitlig grupp med så få värden som möjligt och upprepa det negativa testet.

E-postmeddelandet klarar kontrollen men levereras inte

Ett undantag styr säkerhetskontroller, inte MX, den interna vägen, relay, SMTP-TLS eller målets e-postserver. Mail logs och spool visar om meddelandet efter skanningen fortfarande misslyckas på grund av DNS, routing, policy eller leverans. Vid ett TLS-fel ska certifikatet, Require TLS negotiation och motparten kontrolleras; Encryption i undantaget och en bredare omfattning löser inte felet.

BATV-undantaget tillämpas inte

Kontrollera att samma avsändaradress står under Sender addresses och Recipient addresses. Jämför sedan den specifika BATV-Reason och övriga omfattningsfält igen. Ett andra, bredare undantag ersätter inte det saknade BATV-fältet.

Drift och återställning

Varje undantag får en ägare, en belagd orsak till den falska positiva träffen och ett granskningsdatum. Jämför ändringar med audit trail; Spåra konfigurationsändringar på Sophos Firewall beskriver lämpligt underlag. Det faktiska e-postflödet förblir dessutom synligt i Mail logs och MTA-filerna.

Dokumentera först namn, kontroller, omfattningsvärden och tidigare Reason. För en tillståndsbevarande återställning tas bara det nya undantaget bort; policyer och andra undantag lämnas orörda. Testa sedan ursprungsfelet och ett kontrollmeddelande; planera först underhåll eller en snävare lösning om orsaken kvarstår.

Klassificera e-postundantag via XML API

Vid automatisering heter MTA-undantagsobjektet ExceptionPolicy. Spara det befintliga namnet, de kontroller som hoppas över och samtliga scope-värden före en ändring. Åtkomst, explicit skrivoperation, tolkning av XML-svar och säkra återförsök förklaras i Säkra åtkomsten till Sophos Firewall XML API. Följande klassificering beskriver det dokumenterade kontraktet för SFOS 22/23, inte en testad skrivbegäran.

Hantera Skip-reglage och matchningslistor separat

Kontrollfälten i MalwareProtection, SpamProtection och Other väljer vad som hoppas över; de aktiverar inte det allmänna e-postskyddet. Exempelvis är Malware i undantagsobjektet ett Skip-val, inte en aktivering av skannern för skadlig kod. Referensen anger Enable/Disable för de flesta av dessa fält. Separat från dessa aktiverar de likaså skalära reglagen ForTheseSourceHost, ORTheseSenderAddresses och ORTheseRecipientAddresses vilka scope-grupper som används. Även deras värden är Enable/Disable, inte IP- eller adresslistor.

De tillhörande värdena ligger separat och nästlat i det dokumenterade objektexemplet:

• SourceHostList/SourceHost: flera strängvärden för källvärdar; parametertexten anger IP/FQDN.
• SenderAddressesList/Address: flera avsändaradresser, med stöd för jokertecken i e-postadresser.
• RecipientAddresses/Address: flera mottagaradresser, även dessa med stöd för jokertecken i e-postadresser.

De båda Address-fälten har samma namn men är inte utbytbara: det är först den överordnade containern som avgör om det gäller avsändare eller mottagare. En ifylld container ersätter inte kontrollen av det tillhörande scope-reglaget. Ytterligare listposter är inte ett extra OCH-villkor; varje ytterligare aktiverad grupp skapar den ovan beskrivna ELLER-vägen för matchning. I synnerhet skulle en ytterligare mottagarlista öppna undantaget för källvärdar även för meddelanden från andra källor. Jämför därför alltid reglagen och de sparade listorna tillsammans med det godkända scopet. Specialregeln för BATV och begränsningen för FQDN med jokertecken gäller fortfarande.

Enligt referensen är Name obligatoriskt och får vara högst 100 tecken långt. Valfria fält och tomma standardvärdeskolumner visar däremot inte att utelämnade värden bevaras eller sätts till Disable vid en uppdatering. Kopiera inte ett produktionsundantag från tillverkarens omfattande exempel: det aktiverar flera Skip-fält och alla tre scope-grupper samtidigt.

Kontrollera lokal API help före en skrivbegäran: Exemplet visar CheckForSPF med Disable, medan parametertabellen anger CheckforSPF med de olösta värdena $EMAILPROTECTION{SMTP_CHECK_SPF_ENABLE} och $EMAILPROTECTION{SMTP_CHECK_SPF_DISABLE}. RBL och RDNSAndHelo finns i tabellen men saknas i objektexemplet; bannervalet skrivs där som BanerAddition. Korrigera inte dessa stavningar på eget initiativ, gissa inte tokenvärden och härled inte XML-placering från saknade fält. Om exakta taggar, tillåtna värden eller den konkreta operationen för den installerade versionen förblir oklara, stoppa skrivningen och reda ut detta med supporten; därför innehåller detta avsnitt ingen körbar XML-skrivmall.

Skilj mellan svar och kontrollera det sparade tillståndet

Referensens kopplingar måste läsas tillsammans med operationen. Värdena är XML-statuskoder, inte HTTP-statuskoder; Message.* är olösta dokumentationssymboler, inte verifierade texter vid körning eller felorsaker som kan härledas enbart från namnet.

Add och Update avser här Exception Policy Add respektive Exception Policy Update. Även om sidan också nämner Exception Policy Delete i titeln, innehåller dess statustabell ingen koppling till Delete. Överför inte en framgångskod för Add/Update till Delete och hitta inte på en konkret valideringsregel utifrån ett symbolnamn.

Efter varje skrivförsök, även vid 200, öppna undantaget igen under Email > Policies and exceptions och jämför det faktiskt sparade namnet, samtliga Skip-val, alla tre scope-reglage och varje värd-/adresslista med det avsedda tillståndet. Vid borttagning, kontrollera att exakt det avsedda objektet saknas och att andra undantags tillstånd är oförändrat. Spara Audit Trail och det fullständiga, sanerade API-svaret. Först därefter bekräftar de ovan beskrivna positiva och negativa testerna effekten i e-postflödet.

Vid 502, fel, timeout eller oklart svar, läs av det faktiska tillståndet före varje återförsök: ett befintligt namn kan redan avse ett annat undantag eller härröra från det första försöket. Duplicera inte med ett nytt namn, lägg inte till extra ELLER-grupper och hoppa inte över fler kontroller bara för att kringgå felet. För 541–545, kontrollera operation, kod, faktisk svarstext och sparad konfiguration tillsammans; en olöst symbolbeteckning motiverar inte en gissad reparationsbegäran.

Checklista

• Det finns en reproducerbar falsk positiv och exakt Reason.
• Käll-IP, kuvertavsändare, mottagare och Message-ID är dokumenterade.
• Endast den berörda kontrollen hoppas över.
• Föredra en lämplig grupp; ytterligare grupper breddar matchningen med ELLER.
• FQDN med jokertecken används inte som värdundantag.
• Ett BATV-undantag innehåller avsändaradressen i båda adressfälten.
• Positiva och negativa tester samt Reason före och efter bekräftar den avsedda effekten.
• Övriga kontroller för spam, malware, filer, data och DKIM förblir aktiva.
• Ägare, motivering, granskningsdatum och återställning är dokumenterade.

FAQ