Redactioneel Wat is het verschil tussen een server-side spam filter en een lokaal spamfilter ?

We weten allemaal wat spam is en - spijtig genoeg - met een spamfilter zijn we allemaal vertrouwd, uit noodzaak.
Het lukt meestal aardig om spam van mailadressen die regelmatig hiervoor gebruikt worden tegen te houden als gebruiker. Daarover verderop meer.
Maar de aanleiding tot dit artikel is vooral het omgekeerde fenomeen :
  • je schrijft je in op een mailing list, om een nieuwsbrief te ontvangen ;
  • maar elke keer komt die mail terug in je spamfolder terecht ;
  • als regelmatige mailgebruiker weet je dan wat je moet doen : nl. de afzender in je 'Safe Senders'-lijst opnemen ;
  • maar toch ... vaak negeert de mail precies je mening en blijft de mails in spam gooien ...
Frustratie alom maar een eenvoudige verklaring : je hebt te maken met Server-side spamfiltering !


Hoe spamcontrole op een mailserver werkt — simpel uitgelegd

1. De mail komt aan bij het “digitale postkantoor”

De verzender probeert een mail binnen te duwen. De server zegt in feite:
“Wie ben jij en mag jij dit gebouw binnen?”

2. Eerste controle aan de voordeur
Nog vóór de mail wordt binnengepakt, kijkt de server naar dingen zoals:
– Is het adres van de afzender echt?
– Komt het bericht van een bekende verdachte bron?
– Gedraagt de afzender zich verdacht (te snel, te veel, verkeerde gegevens)?

Als dit niet vertrouwenwekkend is, zegt de server:
“Sorry, levering geweigerd.”
De mail wordt niet opgeslagen, ze komt niet eens binnen.

1764519590069.png


3. Mail wordt geaccepteerd en in een tijdelijke bak gelegd
Is alles voorlopig oké? Dan wordt de mail binnen gelaten en gaat ze in een soort wachtruimte.

4. De spamcontroleur neemt het bericht vast
Een aparte dienst op de server leest nu de mail volledig door, met een check op woorden niet op samenhang. Je privacy is dus niet in het geding.
Hij onderzoekt:
– Hoe ziet de mail eruit?
– Klopt de afzender nog steeds?
– Zien we typische spamkenmerken?
– Zijn er signalen van andere systemen die zeggen: “Dit lijkt spam”? Dit zijn dan vb. 'blacklists' van mail afzenders die als spammers werden geregistreerd.

5. De spamcontroleur geeft het systeem dan een 'advies'
Hij geeft de mail één van deze labels:
OK → mag naar de inbox
Verdacht → naar de spammap
Gevaarlijk → in quarantaine
Overduidelijk misbruik → onmiddellijk tegenhouden

De server volgt dit advies.

6. De mail wordt afgeleverd, tenzij in de laatst vermelde mogelijkheid.
De mail gaat naar de juiste map in de mailbox van de ontvanger.

7. Wat jij doet, telt ook mee
Als jij iets markeert als spam of “dit is géén spam”, leert het systeem daarmee bij.
Zo worden toekomstige beslissingen slimmer en kan het beterschap geven. Maar nog géén zekerheid want het systeem leert traag en jouw 'spamzender' is misschien niet zo bekend.


Hoe spamcontrole in je mailcliënt werkt — opnieuw simpel uitgelegd

Spamfiltering in je mailcliënt is de “lokale huisvader” van de beveiliging: niet zo streng als de server, maar wél iemand die zegt “hier in mijn woonkamer gelden mijn regels.”

(Thunderbird, Outlook, Apple Mail, …)

1. De mail is al binnen

De server heeft de mail al doorgelaten en in je mailbox gezet.
De mailcliënt werkt dus achteraf, niet aan de voordeur.

2. De mailcliënt downloadt of synchroniseert de mail
Zodra de cliënt de mail ziet, bekijkt hij zelf ook even “wat voor vlees er in de kuip zit”.

3. Hij voert zijn eigen checkjes uit
Niets wereldschokkends, maar wél effectief:
– Woorden die vaak in spam voorkomen
– Afzenders die je nooit opent
– Patroontjes in de tekst
– Vergelijking met mails die jij eerder als spam gemarkeerd hebt

Dit is lokale intelligentie, meestal lerend: hoe meer jij markeert, hoe slimmer hij wordt.

4. Hij bouwt een persoonlijk profiel van jouw voorkeuren
Wanneer je:
– een mail “Ongewenst” noemt → de cliënt verhoogt het risico van soortgelijke mails
– een fout-positieve spam herstelt → risico omlaag
Het systeem leert als een brave hond: “Goed zo, baasje, zo moet ik het dus doen.”

5. De cliënt verplaatst mails op basis van eigen regels
– Verdacht → naar Ongewenste mail
– Duidelijk veilig → blijft in Inbox

Het is alsof je mailapp zegt:
“De server vond het OK, maar ik vertrouw het toch niet helemaal. Ik zet het even apart.”

6. Regels van de gebruiker krijgen voorrang
Als je zelf regels maakt zoals:
– “Als mail van X → altijd naar map Y”
– “Als onderwerp Z → meteen verwijderen”
Dan werkt dat als een huiselijke HR-policy: de cliënt voert ze zonder discussie uit.

7. De cliënt stuurt soms feedback terug naar de server
Bij moderne services (Gmail, Outlook.com, iCloud):
– Markeer je iets lokaal als spam → gaat vaak terug naar de server als signaal
– Zo werkt het ecosysteem samen: de server wordt slimmer, jij krijgt minder rommel.



Even vergelijken misschien ?

“De veiligheidsdienst aan de poort” vs. “de conciërge in het gebouw”

1. WAAR GEBEURT HET?

Server-side

– Op de mailserver, voordat de mail jouw mailbox bereikt.
– Denk: security check aan de hoofdingang.

Client-side
– In je mailprogramma (Outlook, Thunderbird, Apple Mail).
– Denk: de conciërge die rondloopt in de gangen nadat de bezoekers al binnen zijn.

2. DOEL

Server-side

– Rommel tegenhouden vóór het gebouw binnenkomt.
– Ontworpen voor schaal, betrouwbaarheid en risicobeheer.

Client-side
– Rommel sorteren nadat het al binnen is, op basis van jouw gedrag.
– Persoonlijke filtering en fine-tuning.

3. WAT GEBRUIKT HET?

Server-side tools

– Zware reputatiesystemen (IP, domeinen, DMARC)
– Machine learning op massadata
– Wereldwijde feedback van miljoenen gebruikers
– Sandboxing, virus-engines, AI-signatures

Client-side tools
– Lokale woordlijsten
– Gepersonaliseerde patronen
– Leren van wat jij als spam markeert
– Regels die je zelf instelt

4. HOE HARD KAN HET INGRIJPEN?

Server-side

– Kan mail weigeren, terugsturen, blokkeren of quarantainen.
– De mail kan volledig verdwijnen voor je ze ooit ziet.
– Dit is “enterprise-grade gatekeeping”.

Client-side
– Kan enkel mails verplaatsen of markeren.
– De mail blijft bestaan, alleen in een andere map.
– Soft-policy, geen harde maatregelen.

5. RISICO’S

Server-side

– Fout-positieven kunnen betekenen dat je mail nooit krijgt.
– Maar wél het krachtigste schild.

Client-side
– Minder risico op verlies, want alles is al binnen.
– Minder krachtig, want het werkt zonder grote datasets.

6. LEERPROCES

Server-side

– Leert van miljoenen gebruikers wereldwijd.
– Centralized intelligence.

Client-side
– Leert vooral van jouw persoonlijke voorkeuren.
– Localized intelligence.

Dus alles komt goed ?

Nee, vaak blijf je toch gefrustreerd achter : zelfs dat regelmatig aangeven dat iets géén spam is brengt vaak geen soelaas.
Maar er is alvast één goed werkende truc hiervoor ... die komt eraan.

De realiteit-check: Als vb. Proximus iets server-side als spam flagt, dan kan jouw lokale Trusted Senders-whitelist net zo goed een Post-it op een datacenterdeur zijn. Het helpt, maar het stuurt de trein niet om.
Wil je nu meteen voor altijd je mail van die afzender "gewoon" ontvangen, doe dan het volgende :

1764520743385.png


Maak in Webmail een expliciete filterregel
  • Settings → Rules/Filters →
    Regel: Als afzender = X → verplaats naar Inbox.
Dit overschrijft vaak hun standaard scoring, een old-school “force override”.
 
Maar er is alvast één goed werkende truc hiervoor ... die komt eraan.
Kleine aanvulling.
Zelfs die truuk werkt niet altijd. Als het SPF (en evt. DKIM) record niet klopt of de afzender in een RBL staat kun je doen wat je wilt, dan gaat ie nooit aankomen.

Trusted-senders wordt op server niveau pas naar gekeken -na- de initiele controle van spf/dkim/dmarc en RBL's.

Dus daar dient men wel rekening mee te houden.

Voor de rest mooi stukje eenvoudige uitleg!
 
Terug
Bovenaan