Rspamd i stedet for SpamAssassin: En fornuftig sammenligning af moderne spamfiltre

Mål for spamfiltre og uundgåelige fejlvurderinger

Et e-mail-spamfilter vurderer meddelelser i e-mail-strømmen ud fra tekniske og indholdsmæssige kendetegn. Afhængigt af produktet omfatter disse blandt andet afsender- og autentificeringsdata, header, URL’er, meddelelsestekst, HTML-struktur, statistiske klassificeringer og eksterne forespørgsler. Målet er ikke at fastslå, om en e-mail er sand, men at vurdere risikoen for, at den ikke bliver leveret, på en gennemsigtig måde. Rspamd Den samler ligeledes en lang række testmoduler og kan sammenfatte resultaterne i et beslutningsgrundlag.

Flere trin skal holdes adskilt: MTA’en modtager først en SMTP-besked eller afviser den under overførslen. Filtreringssystemet beregner derefter eller under behandlingen en score. En markering tilføjes for eksempel til overskriften, eller beskeden flyttes til en junk-mappe via efterfølgende regler. En afvisning afbryder derimod modtagelsen; den er derfor den mest vidtrækkende foranstaltning og ikke blot en stærkere markering.

En Falsk positiv opstår, når en legitim besked fejlagtigt klassificeres som spam. Det kan f.eks. ske med en ægte faktura fra en leverandør, hvor PDF-vedhæftet fil, betalingsopfordring eller et uvant afsenderdomæne udløser flere kontroller. Bliver den blot markeret, kan modtageren stadig finde den; bliver den afvist, når den slet ikke frem til indbakken. For forretningskommunikation er denne forskel afgørende.

Omvendt er en Falsk negativ en spam-besked, der slipper igennem filteret. Et typisk eksempel er en kampagne med let ændrede tekster, skiftende links og overskrifter, der ser teknisk korrekte ud. Sådanne beskeder øger risikoen for phishing, skadelig software eller uønsket reklame, men betyder ikke automatisk, at en kategorisk afvisning er berettiget. Et e-mail-spamfilter optimerer altid mellem disse to fejltyper og ikke med henblik på en fejlfri kvote.

Tærskelværdier er derfor en risikobestemmelse, der træffes af virksomheden. En lav tærskelværdi for afvisninger reducerer muligvis mængden af spam, der slipper igennem, men øger risikoen for, at legitim post går tabt. En højere værdi lægger større ansvar over på markering, karantæne og brugerkontrol. Det er fornuftigt at anvende en trinvis strategi: først markering og overvågning, derefter greylisting eller strengere foranstaltninger, men kun i de tilfælde, hvor logfiler, tilbagemeldinger og den egne e-mail-trafik understøtter beslutningen.

SpamAssassin: Regler, score og driftsmodel

SpamAssassin er et udvideligt, regel- og punktbaseret filter. Det analyserer blandt andet overskrifter, brødtekst, HTML og URL’er; derudover er der statistiske metoder, netværksforespørgsler og plugins til funktioner som Bayes, SPF, DKIM eller DMARC. Hvert enkelt match bidrager med point til resultatet. Summen af disse point udgør en score, der kan sammenlignes med en konfigureret tærskelværdi.

Egne tilpasninger foretages traditionelt i .cf-filer. Hermed kan man f.eks. definere header-, body- og URI-regler med egne scoreværdier. Denne model er særligt gennemsigtig, når et team skal forstå, hvorfor en bestemt regel er blevet udløst. Samtidig stiger vedligeholdelsesomkostningerne i takt med mange undtagelser, lokale regelpakker og forskellige vurderinger: Hver regel kræver en faglig begrundelse, en dokumenteret effekt og regelmæssig kontrol.

Ved kontinuerlig serverdrift overtager tjenesten normalt spamd modtager testopgaver, mens den slanke klient spamc overfører beskeder til ham. Denne opdeling undgår den ekstra arbejdsbyrde, der er forbundet med at starte programmet fuldt ud for hver enkelt besked, og er beregnet til tilbagevendende kontroller. Tjenesten kan desuden inddrage SQL- eller LDAP-konfigurationer samt brugerrelaterede indstillinger.

Dette er relevant for hostingmiljøer: Et domæne kan kræve forskellige hvidlister, mens enkelte e-mailkonti har deres egne præferencer eller læringsniveauer. Sådanne historisk opbyggede strukturer er ikke en teknisk fejl, men de gør en overgang vanskelig. Inden en omlægning bør det derfor stå klart, hvilke regler der rent faktisk er forretningskritiske, hvilke der blot er blevet overtaget historisk, og hvilke opgaver der allerede varetages af MTA eller en anden tjeneste.

En velvedligeholdt SpamAssassin-installation behøver ikke udskiftes alene på grund af sin alder. Hvis reglerne er forståelige, integrationen fungerer stabilt, og den administrative indsats står i rimeligt forhold til e-mail-mængden, kan målrettet vedligeholdelse være mere fornuftigt end en migrering. Omvendt er en høj andel af særregler, der er svære at vedligeholde, ikke et argument for blind kopiering: Det er en anledning til at Normbeholdning at foretage en kritisk rensning, uafhængigt af det filter, der senere vælges.

Rspamd: Worker, symboler og handlinger

Rspamd fungerer efter en master-worker-model. Masteren administrerer processer og konfiguration, mens de almindelige workere behandler meddelelser. En proxy-worker kan blandt andet modtage Milter-forespørgsler og videresende dem til scannere. Controlleren stiller administrationsfunktioner og en webgrænseflade til rådighed, men bør ikke være ubeskyttet på det offentlige net. Disse roller adskiller e-mail-trafik, behandling og administration tydeligere fra hinanden.

Det er vigtigt for arkitekturen, at ind- og udlæsning foregår uden blokering. DNS-, Redis- eller HTTP-forespørgsler kan udføres asynkront. Hvis en kontrol venter på et eksternt svar, behøver dette ikke nødvendigvis at standse andre scanninger fra den samme worker. Dette medfører dog ingen generel ydeevnegaranti: De faktiske resultater afhænger fortsat af regelværket, hardwaren, DNS-forsinkelser, Redis, MTA-forbindelsen og den faktiske sammensætning af meddelelser.

Oprettelse af prøver i Rspamd Symboler med anmeldelser og yderligere oplysninger. Filtret sammenfatter dem til en samlet score og kan foreslå en handling, for eksempel add header, greylist eller reject. Handlingen er ikke en automatisk leveringsbeslutning: Det er først konfigurationen og den konkrete integration i Postfix, Exim eller Sendmail, der afgør, om og hvordan MTA’en gennemfører den.

Netop derfor må eksisterende SpamAssassin-tærskelværdier ikke blot overtages som talværdier. En score afspejler altid samspillet mellem de aktiverede regler, deres vægtning og de tilgængelige datakilder. Selv kontroller med samme navn kan i de to systemer vægtes forskelligt, aggregeres forskelligt eller udføres på forskellige tidspunkter. En direkte sammenligning af required_score med en Rspamd-tærskel ville være fagligt vildledende.

For driften er adskillelsen mellem vurdering og håndhævelse en fordel: Du kan først observere symboludgivelser og foreslåede handlinger uden straks at afvise dem. Først på baggrund af egne legitime meddelelser, identificerede kampagner og tilbagemeldinger kan man afgøre, hvilke Handlingstærskler er rimelige. På den måde bliver en teknisk standardindstilling til en retningslinje for levering, der kan kontrolleres, i stedet for en angiveligt objektiv spamgrænse.

Sammenligning af den daglige e-mail-drift

Forskellene mellem SpamAssassin og Rspamd ligger ikke så meget i en enkelt detekteringsregel som i driftsmodellen. Begge vurderer e-mails ud fra mange signaler, men fremgangsmåderne for konfiguration, integration og distribueret drift er forskellige. Følgende sammenligning systematiserer disse punkter som grundlag for planlægning; den erstatter ikke en analyse af den egne e-mail-trafik.

For en lille enkeltstående server er en velvedligeholdt SpamAssassin-installation derfor ikke et teknisk nødstilfælde. Hvis egne regler er gennemsigtige, tjenesten fungerer stabilt, og fejlkvalificeringer håndteres, kan det være mindre besværligt at beholde den end at foretage ændringer. En genopbygning med Rspamd er dog stadig en mulighed, hvis dens Milter-integration og centralt samlede moduler passer bedre til det planlagte miljø.

I hostingmiljøer med flere scannere bliver Skalering vigtigere end det rene antal installerede regler. Rspamds proxy-worker kan videresende Milter-forespørgsler til andre workere; asynkrone eksterne forespørgsler skal ikke blokere hele workeren. Dette medfører dog ikke nogen generel ydeevneløfte: DNS-forsinkelser, regler, hardware og meddelelsesmix bestemmer den faktiske gennemstrømning.

MTA-integration, Redis og tilstandsbaserede moduler

Den tekniske integration bestemmer, hvor et e-mail-spamfilter returnerer sin vurdering til Mail Transfer Agent. Rspamd kan forbindes til Postfix og Sendmail via Milter. Exim bruger til dette sin integration via spamd_address. Filtret leverer et resultat, men det er stadig MTA’en og den valgte konfiguration, der afgør, om en besked skal markeres, forsinkes eller afvises.

Ikke alle kontroller kræver en fælles tilstand. SPF, DKIM og DMARC analyserer autentificeringsoplysninger; DNS-baserede lister og regulære udtryk kontrollerer yderligere egenskaber ved en enkelt besked. Selvom sådanne kontroller kan kræve eksterne DNS-svar, opbygger de ikke automatisk en læringshistorik. Deres pålidelighed afhænger blandt andet af korrekt DNS-drift og en passende vægtning i det samlede regelsæt.

At arbejde på en anden måde tilstandsbaserede moduler. Bayes-klassificering gemmer indlærte træk, greylisting skal genkende tidligere leveringsforsøg, og hastighedsbegrænsninger kræver tællere på tværs af flere forbindelser. Rspamd forudser brug af Redis i den dokumenterede arkitektur til Bayes, neuralt klassificering, greylisting og andre tilstande. Dette gør det muligt for flere instanser at få adgang til fælles information.

Redis er således hverken en udskiftelig detalje eller en forudsætning for hver enkelt Rspamd-kontrol. Uden tilgængelig lagerplads kan statiske moduler fortsat bruges, mens lærings- og omdømmefunktioner er begrænsede eller svigter. Operatører skal derfor fastlægge tilgængelighed, netværksforbindelse, adgangsbeskyttelse, sikkerhedskopiering og håndtering af en Redis-nedbrud, inden systemet tages i brug.

I praksis er det fornuftigt at opdele ansvarsområderne: MTA modtager SMTP-forbindelser og gennemfører filterbeslutningen, Rspamd vurderer meddelelser, og Redis opbevarer de nødvendige tilstande. Denne opdeling letter fejlfinding, men øger antallet af tjenester, der skal overvåges. En langsom eller utilgængelig afhængighed bør ikke kompenseres ved uovervejede afvisninger.

Kontrolleret overførsel af regler og læringsdata

En migrering begynder med en statusopgørelse, ikke med at kopiere alle filer. Især egne regler bør gennemgås: De kan afspejle forretningsmæssige krav, men kan også indeholde forældede undtagelser. Rspamd stiller et SpamAssassin-modul til rådighed, der kun behandler en del af reglerne. Den tekniske lighed mellem to regler er derfor ingen garanti for, at de har samme effekt.

Modulet kan blandt andet bestemte body-, rawbody-, header-, meta- og uri-Behandle regler. Netværks- og HTML-specifikke plugins er derimod ikke fuldt ud dækket. At indlæse omfattende eksterne regelsæt uden at kontrollere dem kan komplicere konfigurationen og belaste behandlingen. Det er bedre kun at anvende egne regler, hvor der er påviseligt behov for dem, og at foretrække indbyggede moduler.

Dette kræver særlig omhu Bayes-træning. Ifølge Rspamd-dokumentationen kan SpamAssassin-Bayes-databaser ikke importeres. Derfor er der behov for nye, kontrollerede korpora bestående af ønskede meddelelser og spam til Rspamd. Forkert klassificerede regninger, nyhedsbreve eller kampagner forvrider klassificeringen og kan forstærke senere fejlklassificeringer.

AWL bør heller ikke behandles som en filoverførsel. En tidligere afsenderhistorik og en aktuel omdømmevurdering har ganske vist beslægtede mål, men kan anvende forskellige datakilder og vægtninger. Dokumenter derfor først, hvilken effekt en eksisterende undtagelse eller tillidsregel skal have. Først derefter kan man beslutte, om en indbygget Rspamd-funktion eller en målrettet, egen regel er passende.

Sikker implementering af Rspamd i parallel drift

En produktiv overgang begynder ikke med at udskifte det hidtidige filter, men med en statusopgørelse. Dokumentér MTA-forbindelsen, SpamAssassin-reglerne, brugerrelaterede undtagelser, DNS-afhængigheder, godkendte afsendere og den nuværende håndtering af mistænkelige meddelelser. Fastlæg desuden, hvilke nøgletal der senere vil være afgørende: for eksempel fejlagtigt markerede forretnings-e-mails, kampagner, der er sluppet igennem, og den manuelle arbejdsbyrde.

Installer først Rspamd adskilt fra den afgørende e-mail-sti, og integrer det på en sådan måde, at dets vurdering registreres, men uden at ændre leveringen. Den dokumenterede Shadow Mode muliggør netop denne observation: Rspamd kontrollerer meddelelser uden at gennemføre de foreslåede handlinger. Dermed forbliver SpamAssassin den eneste aktive beslutningstager i sammenligningsfasen.

Vurder ikke kun den samlede score, men især de udløste Symboler og den deraf følgende handling. En høj værdi kan skyldes autentificeringsfejl, URL-karakteristika, omdømmedata eller lokale regler; disse årsager kræver forskellige korrektioner. Kontroller derfor for hver mistænkelig besked overskriften, modtagergruppen og den handling, som filteret foreslår, inden du ændrer scoringer eller moduler.

En meningsfuld sammenligning indeholder målrettet både ønskede og uønskede grænsetilfælde. En legitim faktura fra en kendt leverandør kan for eksempel indeholde en PDF-fil og et eksternt sporingslink. En spamkampagne med mange varianter ændrer derimod løbende emnefelt, tekstblokke og afsender, men bevarer typiske URL'er eller strukturelle egenskaber. Begge typer meddelelser viser, om enkelte symboler bidrager på en meningsfuld måde, eller om en regel er for bredt formuleret.

Åg Tærskelværdier Først når der foreligger tilstrækkeligt mange eksempler, der kan kontrolleres. Rspamds score-skala kan ikke sidestilles med en hidtidig SpamAssassin-værdi; en direkte overtagelse kan derfor udløse uhensigtsmæssige handlinger. Beslut separat, hvornår der kun skal tilføjes header-oplysninger, hvornår der skal oprettes en midlertidig gråliste, og under hvilke betingelser der skal afvises. MTA-integrationen bestemmer her, om og hvordan en handling rent faktisk gennemføres.

Efter en planlagt observationsfase sker overgangen på en kontrolleret måde: Rspamd bliver det aktive filter, mens SpamAssassin forbliver installeret og konfigurerbart, men ikke længere træffer beslutninger i mailstrømmen. Denne overgangsperiode bør omfatte ansvarsfordeling, en dokumenteret metode til at skifte tilbage samt kriterier for afbrydelse. Derudover er en klart afgrænset firewall-konfiguration en hjælp; artiklen forklarer grundlaget for en trinvis overgang til nye regler. Netfilter vs. nftables.

Drift, logning og systematisk fejlfinding

I tilfælde af en uventet afvisning starter diagnosen med den konkrete besked og dens behandlingskæde, ikke med en generel lempelse af filtergrænsen. Kontroller MTA-loggen, Rspamd-resultatet, de udløste symboler, score og den foreslåede handling. Først denne sammenkobling viser, om det f.eks. var en lokal regel, en DNS-baseret kontrol eller MTA-håndhævelsen, der forårsagede afvisningen.

Spam, der er sluppet igennem, kræver en omvendt analyse. Find ud af, om meddelelsen overhovedet nåede frem til Rspamd, hvilke symboler der mangler, og om en konfigureret handling ikke blev udført på grund af scoren. Hvis forventede DNS-resultater mangler, skal du undersøge resolveren, tilgængeligheden og svartiderne, før du opretter nye indholdsregler. Ikke alle kampagner kan med fordel dækkes af en enkelt tærskelværdi.

Et Redis-nedbrud skal behandles særskilt, da det kan påvirke tilstandsbaserede funktioner. Kontroller filterets forbindelse til lageret, Redis-tjenestens logfiler og derefter, hvilke moduler der er afhængige af denne tilstand. Statiske kontroller kan fortsat levere resultater, men Bayes-træning, greylisting eller andre tilstandsafhængige analyser kræver et velfungerende datalager.

Hvis en forventet regel ikke udløses, skal du først kontrollere dens faktiske indlæsningssted, syntaksen og den meddelelsesform, den skal fungere på. Kontrol af overskrifter, råtekst, HTML og URL'er vedrører forskellige typer data. I SpamAssassin kan regelarkiver kontrolleres med en syntaksprøve, inden de tages i brug; følgende kommando kontrollerer konfigurationen og påvirker ikke den produktive e-mail-levering.

spamassassin --lint

For tilbagevendende fejl skal du samle tidsstempler, køadfærd, DNS-forespørgsler og svarfejl i en samlet oversigt. På den måde kan du skelne mellem, om en forsinket levering skyldes MTA’en, en ekstern forespørgsel eller filterprocessen. For yderligere Linux-telemetri og overvågning af kørende systemer henvises til det supplerende indlæg bpftool til moderne kerneanalyse tekniske grundlag.

Du bør ikke refleksmæssigt ændre globale scoringer eller omfattende regelsæt efter en enkelt hændelse. Sørg i stedet for at gemme den pågældende besked i overensstemmelse med databeskyttelsesreglerne, sammenlign den med lignende tilfælde, og dokumenter årsagen samt ændringen. Dette Analyse af fejl sikrer gennemsigtige korrektioner og mindsker risikoen for, at en undtagelsesregel senere behandler store mængder legitime eller uønskede e-mails forkert.

Træf beslutning ud fra serverprofilen

Det er fornuftigt at fortsætte med at bruge SpamAssassin målrettet, hvis den eksisterende mailserver administreres pålideligt med sine egne regler, brugerindstillinger og driftsprocedurer. Systemet kan udvides på basis af regler og punkter og understøtter plugins samt forskellige konfigurations- og lagringsmetoder. Et skift alene på grund af en installations alder giver ingen faglig fordel, hvis der ikke foreligger et konkret driftsproblem.

Rspamd er et oplagt valg til en nyopbygning, hvis Milter-integration, moderne autentificeringskontroller, central styring og tilstandsbaserede moduler planlægges sammen fra starten. Dens arkitektur omfatter worker-roller til databehandling, proxy-forbindelser og administration; samtidig skal DNS og eventuelt Redis drives pålideligt som driftsmæssige afhængigheder. Dette er en arkitektonisk beslutning, ikke et generelt løfte om ydeevne.

Til etablerede hostingmiljøer med mange særlige tilfælde er Parallel drift er som regel den mest robuste løsning. Den viser, hvilke af ens egne SpamAssassin-regler der stadig er brug for, om Rspamd-symbolerne afspejler de forventede årsager, og hvilke modtagergrupper der er særligt følsomme over for fejlklassificeringer. Først på dette grundlag kan man træffe en beslutning om en fuldstændig overgang eller om bevidst at beholde den eksisterende løsning.

Valget afhænger derfor ikke så meget af antallet af postkasser alene, men snarere af vedligeholdelseskapaciteten og afhængighederne. Hvis man på lang sigt kan påtage sig ansvaret for Redis, DNS-resolver, loganalyse og opdateringer, kan man drive Rspamd, herunder de selvlærende og tilstandsbaserede funktioner, på en konsistent måde. Mangler disse ressourcer, kan en slank, veldokumenteret løsning med klare regler udgøre den mindste driftsrisiko.

Uanset hvilket produkt der er tale om, gælder følgende: Rspamd-controlleren må ikke stilles til rådighed i netværket uden beskyttelse. I dokumentationen anbefales lokal binding eller firewall-beskyttelse; ved fjernadgang er adgangsbeskyttelse og en adgangskode-hash påkrævet. Du må desuden ikke overtage andres regler eller historiske scoringer uden at have kontrolleret dem først. Enkelte målinger eller påfaldende kampagner udgør ikke et grundlag for en global filterpolitik.

Den rigtige beslutning er altså en Risikovurdering: Beskyttelse mod uønskede meddelelser står over for konsekvenserne af tabte legitime e-mails. Definer for hver handling, hvem der er ansvarlig for den, hvordan den kontrolleres, og hvordan man kan vende tilbage til den tidligere tilstand. På den måde forbliver e-mail-spamfilteret en kontrollerbar del af e-mail-driften i stedet for en automatisk instans, der er svær at gennemskue.