Sophos Email: hantera undantag för inkommande Allow/Block säkert

Inbound Allow/Block styr vilka avsändare Sophos Email tillåter eller blockerar för inkommande meddelanden. Administratörslistan gäller globalt för alla skyddade postlådor, medan en personlig lista bara gäller den berörda användaren. Vid en konflikt har Admin list företräde.

Snabb och säker rutin: exportera först den befintliga listan under Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block. Lägg sedan till det mest specifika avsändarvärdet i Admin list, aktivera Enforce Message Authentication för en Allow-post, dokumentera orsak och ansvarig och testa med ett matchande och ett icke-matchande meddelande. Breda domäner, jokertecken och nätverk ersätter inte en utredning av ett falskt positivt resultat.

Viktigt: en Allow-post stänger inte av allt skydd. För en matchande och tillräckligt autentiserad avsändare hoppar Sophos bara över kontrollerna nedan; skanning efter skadlig kod förblir aktiv. Utan obligatorisk autentisering kan ett förfalskat meddelande som använder en tillåten adress kringgå de dokumenterade kontrollerna och nå inkorgen. URL-listan för Time of Click är en separat funktion och hanteras inte här.

Förstå omfattning och matchning

Listorna gäller bara inkommande meddelanden. För adresser och domäner jämför Sophos både avsändaren i SMTP-kuvertet och adressen i det synliga From-huvudet. Om någon av dem matchar utlöses den konfigurerade Allow- eller Block-åtgärden. Kontrollera därför båda värdena i råhuvuden eller meddelandedetaljer.

Administratörslistan stöder:

enskilda e-postadresser som billing@example.com;
domäner som example.com;
IP-adresser som dokumentationsadressen 192.0.2.25;
IPv4-nät med prefix från /16 till /32, exempelvis 192.0.2.0/24;
jokertecken i början, mitten eller slutet av en adress eller domän, som *.example.com, name*@example.com, name@example*.com eller *.example;
jokertecken för hela toppdomäner, med *.example som säker dokumentationsform i stället för en toppdomän i produktion.

End user list stöder bara e-postadresser och domäner, inte IP-adresser eller jokertecken. Den dokumenterade gränsen för alla listor är 100 000 poster. En användare kan lägga till högst 500 poster i sin Allow- eller Block-lista; poster från Smart Banners kan överskrida denna användargräns.

Ett meddelande från en blockerad avsändare eller klient-IP avvisas utan ytterligare skanning. Meddelanden från adresser på en Block-lista avvisas normalt under SMTP, innan e-postservern accepterar dem. Om flera mottagare har olika personliga blockeringsinställningar accepteras meddelandet däremot först och blockeras sedan bara för dem som har blockerat avsändaren. I detta fall betyder SMTP-acceptans inte att meddelandet levereras till den blockerande mottagaren. Det konkreta testet beskrivs nedan.

Förbered och begränsa ändringen

Dokumentera före ändringen: ärende, verksamhetsskäl, ansvarig och slut- eller granskningsdatum; exakt listtyp (Admin list eller End user list); åtgärd och mest specifika värde; berörda användare; aktuell export och antal poster; samt testavsändare, testmottagare och förväntade resultat med och utan matchning.

Sophos dokumenterar inget automatiskt slutdatum per post. Planera därför granskningen i ändringssystemet och ta bort undantaget när behovet upphör. Beskrivningen ska kort ange orsak och ärende utan konfidentiella uppgifter.

Konfigurera administratörslistan

Klicka på Global Settings i Sophos Fusion (tidigare Sophos Central).
Öppna Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Välj Admin list och klicka på Add.
Välj Allow eller Block och ange exakt en adress, domän, IP-adress, ett CIDR-nät som stöds eller ett jokervärde.
Lägg till en Description med orsak och ärende, utan konfidentiella uppgifter och med högst 250 tecken.
Aktivera Enforce Message Authentication för Allow-poster. Stäng inte av alternativet för att kringgå misslyckad avsändarautentisering.
Spara och sök upp posten. Advanced Search filtrerar efter Allow/Block, Message Authentication samt avsändaradress eller domän.

Använd Override duplicates först efter att den befintliga posten har jämförts; Sophos använder sedan det senaste valet. Du kan ändra beskrivningen för flera administratörsposter eller aktivera Message Authentication för flera Allow-poster samtidigt, men får inte oavsiktligt slå samman olika orsaker eller ansvariga.

Inställningarna per post under Enforce Message Authentication speglar autentiseringsalternativen i User Settings. För varje Allow-post kan du behålla eller åsidosätta enskilda alternativ, bland annat SPF-kontroller och kuvertdomäner. Jämför och dokumentera även dessa värden, inte bara huvudreglaget. Det globala spoofingskyddet ersätter inte reglaget för posten: om Enforce Message Authentication är avstängt för en administratörs Allow-post kan en förfalskad avsändare utnyttja posten även när det globala alternativet är aktiverat.

Kontroller som en autentiserad Allow-matchning hoppar över

För en administratörs Allow-post med obligatorisk autentisering måste minst en kontroll av DMARC, SPF eller DKIM godkännas. Det aktiverade alternativet Prevention of spoofing of allowed address och inställningarna per post avgör den närmare bedömningen; ett DMARC-fel med en policy som inte är p=none kan exempelvis leda till att autentiseringen misslyckas. En godtycklig SPF-pass räcker därför inte som generellt bevis. Vid en korrekt autentiserad Allow-matchning hoppar Sophos över:

Header anomalies;
Impersonation protection;
Anti-spam;
BATV (Bounce Address Tag Validation);
Country of origin;
Language;
Data control.

En korrekt autentiserad Allow-matchning för en användare hoppar bara över Impersonation protection, Anti-spam, Country of origin och Language. Nästa avsnitt förklarar de motstridiga beskrivningarna av användarautentisering. Skanning efter skadlig kod förblir aktiv i båda fallen. Guiden om skydd mot skadlig kod, bilagor och URL:er beskriver vilka innehålls- och URL-kontroller som gäller oberoende av detta.

Användar-Allow: motstridiga beskrivningar av autentisering

De aktuella beskrivningarna av Inbound Allow/Block och behandlingen av Allow-listor anger att användarnas Allow-poster alltid kräver Message Authentication. User Settings beskriver däremot Prevention of spoofing of allowed address som ett alternativ som måste aktiveras för den användarautentisering som förklaras där. Enligt den beskrivningen är alternativet avstängt som standard för befintliga kunder och kanske ännu inte tillgängligt i alla klientorganisationer. Beskrivningarna stämmer inte entydigt överens. De visar varken att autentisering tillförlitligt kan kringgås när alternativet är avstängt eller att skyddet är bevisat i alla klientorganisationer oberoende av alternativet. Konflikten om autentisering är fortfarande olöst.

Behåll befintliga skyddskontroller aktiva i drift och planera, om Prevention of spoofing of allowed address är tillgängligt, aktiveringen med en kontrollerad verifiering av legitima sändningsvägar. Om alternativet saknas eller effekten är oklar ska ett nytt användar-Allow-undantag inte bygga på antaget autentiseringsbeteende. Klarlägg i stället klientorganisationens tillstånd med meddelandedetaljer där känsliga uppgifter har tagits bort och med de aktuella inställningarna. Stäng inte av Enforce Message Authentication, spoofingskydd eller andra kontroller som en lösning på problemet.

För den dokumenterade kontrollen med Prevention of spoofing of allowed address aktiverat får en tillåten adress bara hoppa över kontroller om autentiseringen klarar följande bedömning. Annars ignorerar Sophos Allow-statusen och utför alla skanningar:

En DMARC-pass räcker. Om DMARC misslyckas med en avsändarpolicy som inte är p=none misslyckas Allow-autentiseringen i denna testkonfiguration med alternativet aktiverat.
Vid p=none, eller om DMARC inte kan köras, avgör SPF och DKIM resultatet.
SPF kontrollerar meddelandets kuvertdomän.
DKIM måste godkännas för domänen i Allow-posten.
SPF check for non-aligned address kan godkänna en SPF-pass även om kuvertdomänen för avsändaradressen inte är anpassad till den tillåtna adressen. Sophos rekommenderar inte alternativet: en förfalskad header-from-adress kan då matcha en adress som användaren har tillåtit och öka risken för spoofing.
SPF check for envelope domain gör att Sophos läser kuvertdomänen för varje huvudadress som användaren har tillåtit, så att SPF tillämpas på meddelandets kuvertdomän. Använd det endast när detta exceptionella, icke-anpassade SPF-flöde krävs.

Denna icke-anpassade undantagsväg breddar förtroendet och är ingen standardlösning. Korrigera först SPF, DKIM eller DMARC hos den legitima sändningstjänsten. Se guiden om avsändarautentisering.

Administrera användarlistor

User Settings kan inte konfigureras i EMS-läge. Utanför det läget kan användare hantera sin lista i Sophos Central Self Service Portal om Release/Delete och Allow/Block List är aktiverade under Global Settings > Products and Services > Email > User Settings. Två säkerhetsberoenden gäller:

Om End-user message settings är aktiverat och länkarna Allow sender och Block sender har konfigurerats på Smart Banners måste Allow/Block List förbli aktiverat.
Om End-user message settings är avstängt och antingen Release/Delete eller Allow/Block List stängs av, kringgår Sophos användarnas befintliga Allow/Block-listor.

Administratören kan visa och ändra samma listor centralt:

Öppna Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Välj End user list och klicka på Add.
Tilldela posten till rätt användare, välj Allow eller Block och använd bara en e-postadress eller domän.
Spara och kontrollera posten med Advanced Search efter åtgärd, avsändare eller användare.

Även här ersätter Override duplicates ett identiskt värde med det senaste valet. Kontrollera först den globala administratörslistan, eftersom den har företräde framför en motstridig användarpost. Se guiden om självbetjäning för karantän.

Testa flera mottagare korrekt

I ett meddelande till flera mottagare kan personliga listor skilja sig åt för samma avsändare. Om bara person1@example.com har blockerat avsändaren får person2@example.com fortfarande meddelandet; det blockeras bara för person1@example.com. I det normala blockeringsfallet avvisas meddelandet före SMTP-acceptans. I det blandade fallet med flera mottagare accepteras det först och blockeras därefter per mottagare. Lyckad SMTP-acceptans bevisar alltså inte leverans till den mottagare som har blockerat avsändaren.

Använd två egna testpostlådor och en egen testavsändare för en kontrollerad pilot; ersätt exempeladresserna med dessa godkända värden. Kontrollera först den globala Admin list efter poster som har företräde och användarlistornas behörigheter enligt föregående avsnitt. Piloten kräver att användarlistorna faktiskt tillämpas. Särskilt när End-user message settings är avstängt kan avstängning av Release/Delete eller Allow/Block List kringgå befintliga användarlistor; detta är ingen lösning på ett oväntat testresultat.

Dokumentera de ursprungliga personliga posterna. Blockera testavsändaren endast för den första testmottagaren; den andra får inte ha någon motsvarande blockering.
Skicka ett nytt, ofarligt meddelande till båda mottagarna i en enda sändning. Kontrollera varje mottagaråtgärd separat i Message History och granska testpostlådorna: för den första förväntas blockering utan leverans, för den andra leverans, om ingen annan kontroll stoppar meddelandet.
Om SMTP-åtkomsten är uttryckligen godkänd ska du även spara loggen för sändningen och skilja acceptans från avvisning. Kontrollera att båda mottagarna ingår i samma SMTP-transaktion; separata transaktioner bevisar inte det blandade fallet. Jämför resultatet med ett separat test med en mottagare till den blockerande testpostlådan, där normal avvisning före acceptans förväntas. Härled inte någon SMTP-kod eller bearbetningsfas från enbart leveransstatus.
Återställ de dokumenterade personliga posterna efter piloten och kontrollera dem igen. Stoppa ändringen vid oväntat resultat och kontrollera administratörsprioritet, användartilldelning, matchning och behörigheter i stället för att skapa en bredare Allow-regel.

Ett SMTP-test med bara en mottagare återger inte det blandade fallet. Utan godkänd SMTP-åtkomst kan du verifiera mottagarresultaten, men inte dokumentera SMTP-fasen som självständigt bevisad.

Exportera och importera CSV säkert

Exportera listan som säkerhetskopia och jämförelseunderlag före massimport. Exportfilen har extra kolumner och är inte lämplig oförändrad som importfil. Hämta den aktuella mallen i Sophos Fusion, följ exakt dess format och kolumner och hitta inte på kolumnnamn.

Öppna rätt flik, Admin list eller End user list, och bevara exporten oförändrad.
Välj Add > Import allow/block list och hämta mallarna.
Skapa CSV-filen och kontrollera åtgärd, värde, Description och eventuell användare rad för rad.
Kontrollera Allow- och Block-poster, specialtecken, domäner och användare i förhandsgranskningen.
Importera först en liten pilotfil; sök upp och testa posterna innan du fortsätter.

Varning: Replace existing list with this import tar permanent bort alla aktuella poster i den berörda listan när CSV-filen läggs till. Använd bara alternativet för ett godkänt fullständigt byte med verifierad säkerhetskopia och lyckad pilot, aldrig för ett tillägg.

Skydda och återställ ett fullständigt byte

Före ett fullständigt byte måste en utsedd godkännare godkänna exakt listflik, den oförändrade fullständiga säkerhetskopian med registrerat radantal, den förberedda återställningsfilen, pilotresultatet och underhållsfönstret. Piloten ska använda samma aktuella Sophos-mall i en icke-produktionsklientorganisation eller en separat kontrollerad testlista. Kör aldrig en ofullständig pilotfil mot produktionslistan med Replace existing list with this import.

Om poster saknas eller är felaktiga efter bytet ska alla fortsatta importer stoppas och listan inte korrigeras rad för rad. Efter incident- eller ändringsgodkännande konverterar du den tidigare exporterade, kända fungerande fullständiga listan till en ny fil enligt den aktuella Sophos-mallen; behåll originalexporten oförändrad. Före importen jämför du radantal och representativa Allow- och Block-poster, samt användartilldelningar för användarlistor och stickprov från början och slutet. Importera sedan den fullständiga återställningsfilen på rätt flik och under ett kontrollerat fönster med Replace existing list with this import. Kräv slutligen att antalet poster motsvarar antalet före ändringen, bekräfta samma stickprov och upprepa tester av matchning, utebliven matchning och autentisering för att visa att det kända fungerande läget har återställts. Vid varje avvikelse ska ändringen förbli stoppad och eskaleras; skanning efter skadlig kod och alla andra skyddskontroller förblir aktiva.

Separata gränser: högst 500 000 poster i den skapade importlistan, 500 per användare, 1 MB per CSV-fil och 250 tecken per Description; längre text kapas. Dela stora filer. Om kalkylprogram ändrar avgränsare, inledande tecken eller kodning ska du avbryta, återskapa filen från den oförändrade Sophos-mallen och kontrollera förhandsgranskningen. Gissa inte kodningen och redigera inte säkerhetskopian.

Validera resultatet

Utför ett litet, dokumenterat test efter en enskild ändring eller varje import:

Matchning: Ett nytt meddelande med exakt matchande kuvertavsändare eller From-huvud ska visa den förväntade Allow- eller Block-effekten.
Ingen matchning: En liknande adress eller närliggande domän utanför posten ska genomgå normala kontroller. Särskilt för jokertecken och CIDR visar detta om omfattningen är för bred.
Autentisering godkänd: Kontrollera en legitim avsändare med dokumenterat autentiseringsresultat mot de globala alternativen och alternativen per post som faktiskt är aktiverade. Behåll Enforce Message Authentication aktiverat för administratörs-Allow; använd det tillgängliga och aktiverade Prevention of spoofing of allowed address för det kontrollerade testet av användar-Allow. Bara de kontroller som dokumenterats för respektive fall får hoppas över; skanning efter skadlig kod förblir aktiv. En ensam SPF-pass bevisar inte en lyckad Allow-matchning vid en striktare DMARC-bedömning.
Autentisering misslyckad: I denna skyddade testkonfiguration får ett kontrollerat meddelande där alla tre kontroller misslyckas inte dra nytta av Allow-status och ska genomgå alla skanningar. Kontrollera även DMARC-fel med en policy som inte är p=none om det ingår i det godkända testet. Utan en verifierbar testkonfiguration för användar-Allow förblir verifieringen öppen; stäng inte av en skyddskontroll för att tvinga fram leverans.
Block och flera mottagare: Testa för personliga Block-listor en berörd och en oberörd pilotmottagare i samma meddelande och dokumentera båda åtgärderna separat. Verifiera även SMTP-acceptans eller avvisning endast med godkänd åtkomst, inte utifrån enbart leverans.
CSV: Jämför antal, åtgärd, värde, Description och användartilldelning med källfilen och säkerhetskopian. Kontrollera även stickprov från början och slutet av listan.

Dokumentera tid, kuvertavsändare, From, klient-IP, mottagare, autentisering och åtgärd i Message History. Leverans ensam bevisar inte en Allow-matchning: meddelandet kan ha klarat den normala kontrollvägen.

Felsök och underhåll undantag

Allow fungerar inte: jämför kuvertavsändaren och From med posten och kontrollera sedan administratörsprioritet, alternativ per post och DMARC/SPF/DKIM. Normal skanning är avsedd när obligatorisk autentisering misslyckas. Dokumentera även spoofingskyddets faktiska tillstånd om effekten av användar-Allow är oklar; kringgå inte den beskrivna konflikten mellan källorna genom att stänga av skyddskontroller.
Block påverkar bara vissa mottagare: kontrollera användare och fallet med flera mottagare; administratörsregeln har företräde.
Wildcard eller CIDR matchar fel: kontrollera syntax och prefix; bara /16–/32 är dokumenterat och användarlistor stöder inte IP/CIDR eller jokertecken. Ta bort den breda posten under utredningen.
Importen saknas eller är fel: kontrollera flik, filstorlek, användargräns, mall, extra kolumner, kapade beskrivningar och synlig kodning. Försök inte igen med Replace existing list with this import förrän orsaken är känd och säkerhetskopian verifierad.
Legitim e-post är fortfarande blockerad: jämför listor, kuvert, From och IP, därefter autentisering och Message History. Skapa inte en bredare Allow-post som genväg.

Granska minst varje kvartal och vid byte av ansvarig. Ta efter godkännande bort utgångna, ägarlösa, dubbla eller för breda undantag och upprepa testerna. Om orsaken förblir okänd ska posten återställas och eskaleras med meddelande-ID, tidpunkt, export, berörd rad och autentiseringsresultat, utan att röja konfidentiella meddelanden eller kompletta produktionslistor.