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.

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