Mailproviders markeren noodmail van BE-Alert als spam, waarschuwing komt te laat

BE-Alert waarschuwde veel mensen in België te laat voor het noodweer van vrijdag op zaterdag. De oorzaak was dat providers de alarmmail ten onrechte als spam of phishing bestempelden. Sommige Belgen kregen de waarschuwing pas uren later, toen het zware onweer al voorbij was.

Het Nationaal Crisiscentrum van België spreekt van een structureel probleem, meldt Het Laatste Nieuws. "Mailproviders beschouwen massale verzendingen vaak als spam, waardoor berichten vertraging oplopen", meldt de woordvoerder van het Belgische crisiscentrum. Die organisatie gaat nu in gesprek met de providers.

De gelijktijdige verzending van honderdduizenden e-mails met hetzelfde onderwerp activeert beveiligingssystemen en verplicht providers tot een veiligheidscontrole, legt de woordvoerder uit. Dit vertraagt de bulkverzending van noodberichten door BE-Alert. Het Belgische alarmsysteem was niet overbelast.

Advies: geen mail gebruiken

Kleinschaligere verzending van berichten, zoals voor steden en gemeenten, loopt in de regel niet aan tegen antispam- en antiphishingmaatregelen. Het aantal mails is dan veel kleiner. In het geval van de noodweerwaarschuwing dit weekend was dat voor een veel groter gebied en dus veel meer ontvangers. Het ging in totaal om meer dan een miljoen Belgen die een waarschuwing kregen.

Het Nationaal Crisiscentrum adviseert om bij dreigend gevaar geen e-mails te gebruiken. "Bij een acute situatie zijn sms'jes of gesproken berichten nog altijd het snelste kanaal", verklaart de woordvoerder. Burgers krijgen het advies om niet op één alarmsignaal te vertrouwen. Zij moeten media en sociale media in de gaten houden.

België, landkaart. Bron: BE-Alert
Landkaart van België. Bron: BE-Alert

Door Jasper Bakker

Nieuwsredacteur

21-06-2026 • 11:28

181

Submitter: jordy-maes

Reacties (181)

181
179
66
7
0
102

Sorteer op:

Weergave:

Ik zat bij een nederlandse kleinere provider, en omdat Telenet en Proximus die e-mail als spam aanzagen, ook al klopte DKIM, DMARC en SPF als een bus - heb ik mijn mail moeten verplaatsen (dat is op zich geen rocket-science maar je moet dat in stapjes doen en je hebt altijd het risico op dataverlies - dus ik til daar redelijk zwaar aan).

Hopelijk gaat het om die 2 providers en wordt er een onderzoek tegen hen gestart wegens niet-conformiteit en vooral monopolievorming.

Voorlopig heb ik geen problemen via proton-mail, we zullen zien wat er van wordt.

Het pleidooi om sociale media hiervoor te gebruiken volg ik niet - omdat ik al jaren a-sociaal ben qua media. Mijn privacy wordt onvoldoende beschermd dus weiger ik dat te gebruiken en er zijn er meer zoals ik. Dus sociale media zijn even ongeschikt als e-mail wat mij betreft.

[Reactie gewijzigd door mutley69 op 21 juni 2026 20:21]

Ik heb in discussie met andere systeembeheerders, specifiek zij die ook veel met e-mail werker, begrepen van hen dat veel grote email providers lock-in achtige praktijken uitoefenen.

Zo zouden grote partijen zoals Gmail en Outlook standaard de email wantrouwen als deze afkomstig is van een persoonlijke mailserver of een kleinschalige provider. Als je niet genoeg e-mail verstuurd bestempelen ze jou als verdacht.

Ook worden minder gebruikte top-level domains (bijv. .space, .xyz, .amsterdam, .shop) ofwel volledig geblokkeerd, of weggezet als spam.

Het is ook niet ongewoon dat bedrijven met een eigen mailserver ook soortgelijke blokkades opwerpen.
Als dagelijks beheerder van mailsystemen ben ik vooral benieuwd wat dan de reden is om als spam gemarkeerd te worden. Een bericht verstuurd vanaf een mailserver die aan alle voorwaarden als een volledige SSL/TLS keten, SPF, DKIM en DMARC voldoet, en een emailbericht dat opgesteld is als multi-part met zowel HTML als plain-text opmaak, waarbij linkjes dezelfde link in leesbare tekst hebben als de werkelijke link, en waarbij afbeeldingen vanuit hetzelfde domein gelinkt zijn, komen zelden tot nooit in aanmerking als spam. Waarschijnlijk dus gewoon bulkmail vanaf een slecht ingerichte server met slechte software.
Grote providers zetten zenders ook op de zwarte lijst als de bounce rate te hoog wordt. Als er veel mail wordt gestuurd naar niet (meer) bestaande mailadressen dan past dat, is het idee, bij het gedrag van een spammer die een grote lijst heeft van mailadressen die niet meer actueel is.

Het zou zomaar kunnen dat veel mensen nog een oud mailadres hebben ingevuld bij BE-alert.

Er wordt natuurlijk ook gekeken naar andere dingen. Zoals in het artikel staat: een domein dat opeens heel veel meer mail stuurt wordt ook gezien als verdacht terwijl dat precies de bedoeling is bij deze dienst: incidenteel hoog volume.
Als ik me niet vergis, is juist die DKIM specifiek bedoeld om aan de ontvangers te laten weten "hey, deze mail is legit", toch?

Met SPF en DMARC ben ik zelf niet bekend.
SPF geeft in DNS aan "mails vanaf [domeinnaam] worden verstuurd vanaf IP adres(sen) [...]". Is een mail niet afkomstig van een "bekend" IP adres is dat een grote red flag.

DMARC gaat voornamelijk over "wat als het niet goed is". In DNS vastgelegd of SPF en/of DKIM succesvol gecontroleerd moeten worden en wat er moet gebeuren als er een "afwijking" is (quarantaine vs weigeren) en als beheerder van het domein (/de verzendende mailserver) leg je daar ook een mailadres vast waar rapportage naar gestuurd wordt. Waarna de ontvangende mailserver periodiek een mailtje stuurt met "ik heb X mails ontvangen en Y kwamen door alle checks" etc.

DKIM is dan inderdaad dat de verzendende mailserver een deel van de mail cryptografisch doet ondertekenen. Waarbij de ontvangende mailserver, op basis van de public key, controleert of de juiste handtekening aanwezig is.

Maar zoals @SinergyX ook aangeeft bevestigd dit alleen dat de mail legitiem verstuurd is. Maar dit zegt niks over de inhoud. Een spammer kan ook een domeinnaam kopen, mailserver opzetten met SPF, DKIM, DMARC en beginnen te spammen. En met alleen deze zaken is de mail dan legitiem en "geen spam". Voor spam wordt veel naar andere zaken gekeken. (Bv een mailadres als naam van de afzender, die niet matcht met de daadwerkelijke afzender. Links die naar een ander domein gaan dan het domein van de afzender. Uitgeschreven links in tekst die afwijken van de daadwerkelijke URL die geopend wordt bij klikken. Een server die ineens honderden, duizenden, keren dezelfde mail ontvangt. ...).
Als ik me niet vergis, is juist die DKIM specifiek bedoeld om aan de ontvangers te laten weten "hey, deze mail is legit", toch?
DKIM geeft aan dat de mail is gestuurd door de eigenaar of in naam van de eigenaar van het domein waaronder de e-mail is gestuurd. Ik kan geen DKIM ondertekende mail versteuren vanuit het domein microsoft.com maar wel mijndomein.nl wanneer ik mijndomein.nl geregistreerd zou hebben onder mijn naam.

DKIM geeft op zichzelf niet aan of een mail legitiem is.
Dus met die logica kan elke spammer, zolang het maar alle 'checkboxes' heeft gehad, eindeloos spammen, want 'voldoet'?

SSL/TLS is voor onderschepping
SPF is juiste domein
DKIM is juiste afzender
DMARC is meer 'in geval van'

Alles wat die dingen doen is bewijzen dat mailtje legitiem is, niet dat 'geen spam' is.
Dat klopt eigenlijk allemaal niet.

SSL/TLS gaat over versleuteling op de verbinding naar de server . Die verbinding is dan versleuteld zodat derden op je netwerk bijvoorbeeld je wachtwoorden niet kunnen 'sniffen' (wat vroeger dus wel kon). Hetzelfde voor onderlinge communicatee tussen de servers.

Het spf record bevat een ipadres, of adressen, waarvanuit mail verzonden mag worden. Dit voorkomt dat jij zomaar sinergyx@tweakers.net kunt gebruiken. Of zoals SIDN het verwoord "In het geval van SPF wordt er een DNS-record opgenomen dat (onder meer) aangeeft welke systemen mail voor het betreffende domein mogen versturen".

DKIM is een public/private key systeem op domein niveau; "Bij DKIM maakt de verzendende server (MTA) met behulp van een ‘private key’ een cryptografische handtekening en voegt die toe aan de mail in de vorm van een zogenaamde DKIM-header. Een soort echtheidskenmerk dus. De ontvangende partij ziet deze handtekening, zoekt in het DNS de bijbehorende publieke sleutel op en valideert de handtekening (en dus de mail) daarmee. Als de digitale handtekening correct is, dan staat daarmee het afzenderdomein vast en is zeker dat de e-mail onderweg niet is aangepast. Een kwaadwillende beschikt immers niet over de private key en is niet in staat om DKIM-beschermde mails te maken."

DMARC geeft puur beleid door. "Met een DMARC-record tenslotte, kan in het DNS een soort beleid kenbaar worden gemaakt. Bijvoorbeeld (in versimpelde vorm): “als de DKIM-handtekening niet klopt, of als SPF faalt, stop deze mail dan in de spamfolder”. Met DMARC kun je de kans verminderen dat anderen jouw domein gebruiken voor spoofing, door dit stricter te zetten. Verder eigenlijk vooral nuttig voor de feedback reports functie. Je krijgt dan periodiek feedback rapportages terug van ontvangers op een mailadres naar keuze.

[Reactie gewijzigd door sdk1985 op 21 juni 2026 15:25]

Niet, maar vervolgens de uitleg geven van precies het kernwoord welke ik benoem...
Totaal anders toch? Als je het in kernwoorden wil:
  • Ssl/tls is beveiligde verbinding
  • Spf is de juiste server
  • Dkim is een valide handtekening
  • Dmarc is het spam beleid
Misschien nog een minder bekende maar ook zeer nuttige technologie even aanhalen: MTA-STS.

Daarmee kun je andere mailservers die dit ondersteunen verplichten om enkel e-mails naar jouw server te versturen over een gecontroleerde SSL-verbinding en nooit terug te vallen op een onveilige verbinding.
Mee eens, SPF, DKIM en DMARC zijn de standaarden die we afgesproken hebben om als afzender te bewijzen dat je bericht legitiem is. Dan moet het ook afgeleverd worden. Ik erger me aan spamfilters die allerlei eigen criteria gaan verzinnen. Vooral die van de 'gratis' e-maildiensten van Amerikaanse reclamebedrijven.
Als de standaarden niet meer voldoen moeten ze verbeterd worden. Nu is het een crime om als nieuwe organisatie je nieuwsbrief die aan alle standaarden voldoet afgeleverd te krijgen.

Los daarvan is e-mail natuurlijk niet een geschikt kanaal voor urgente waarschuwingen als waar dit artikel over gaat.
Mee eens, SPF, DKIM en DMARC zijn de standaarden die we afgesproken hebben om als afzender te bewijzen dat je bericht legitiem is. Dan moet het ook afgeleverd worden. Ik erger me aan spamfilters die allerlei eigen criteria gaan verzinnen.
En wat zeggen die standaarden over de inhoud? Helemaal niets. Tegenwoordig is goede spam/phishing voorzien van de juiste authenticatie en integriteit mechanismes.

Tegenwoordig draai je alleen mee als mailserver als je verbanden kan leggen en contextuele factoren meeneemt. Een vleugje AI zou absoluut geen kwaad kunnen.
Ja zeg, waar is al die AI die alles beter zou maken voor de gewone mens gebleven? ;) Buiten loze beloftes, datacentra in de achtertuin, gebruikers(meta)data binnenrijven en GDPR aan de laars lappen, miljarden schulden hebben en de hardwareprijzen doen exploderen?

Dat zat bij Gmail ook in de spam!

SMS lijkt me voor zo iets het makkelijkst, maar is misschien wel wat duurder? Gsm van de meeste mensen ligt altijd aan en met dat het niet meer zo veel gebruikt wordt, veel meer in het oog springend dan de rest.

[Reactie gewijzigd door Wim Cossement op 23 juni 2026 06:36]

Mee eens, SPF, DKIM en DMARC zijn de standaarden die we afgesproken hebben om als afzender te bewijzen dat je bericht legitiem is. Dan moet het ook afgeleverd worden.
Nee. Je vergeet daarbij één cruciaal aspect. Het vertelt niet dat de afzender legitiem is.
Dus een spammer kan een domein inrichten dat keurig aan al die standaarden voldoet en spam berichten versturen. Die wil je dan niet afleveren.

Met SPF, DKIM en DMARC weet je dat de mails daadwerkelijk van de afzender af komen. En als je die afzender dan vertrouwt dan kun je instellen dat je die mails vertrouwt. Maar je vertrouwt ze dus niet omdat SPF, DKIM en DMARC kloppen. Je vertrouwt ze omdat je de afzender vertrouwt.

Een subtiel maar belangrijk verschil.
Nu even vanuit mijzelf als legitieme afzender geredeneerd. Ik verstuur als vrijwilliger-webmaster nieuwsbrieven namens allerlei sportclubs en andere verenigingen. De leden hebben zich expliciet ingeschreven. SPF, DKIM, DMARC, list-unsubscribe headers etc. allemaal 100% OK. En toch wordt het door b.v. Ziggo in eerste instantie geblokkeerd "omdat uw SMTP server (= de MX) niet heel bekend is". Of als een paar leden met een Hotmail adres het makkelijker vinden om op 'dit is spam' te klikken dan zich netjes uit te schrijven blokkeert Microsoft de nieuwsbrief voor alle hotmail.com, live.nl en outlook.com adressen. Gmail weigert nieuwsbrieven die via een auto-forward binnenkomen (b.v. via een hotmail.com mailbox).

Maar er is geen IETF standaard die zegt dat de SMTP server bekend moet zijn. Er is geen standaard die zegt hoeveel % van de ontvangers maximaal geklaagd mag hebben. Er is geen standaard die zegt waar een autoforward aan moet voldoen. Of hoeveel links naar een ander domein dan de afzender er maximaal in de mail mogen zitten. Het is een tombola geworden, volkomen doorgeslagen. Elke e-mail provider, elk spamfilter hanteert zijn eigen extra criteria. En die veranderen per maand.

Ik kan me voorstellen dat er meer nodig is dan wat we nu hebben met SPF, DKIM, DMARC. Maar dat moet wel gestandaardiseerd zijn. Nu weet ik niet waar ik aan toe ben als afzender.
Dat is heel vervelend voor je als afzender. Maar denk je ook aan de ontvangers die overspoelt worden door spam?

Overigens valt me op dat de spam filters ontzettend verslechterd lijken te zijn de afgelopen paar jaar.
En grote clubs zoals hotmail zouden echt het gedrag van een afzender zoals jij, met een paar domme mensen die op spam drukken ipv unsubscribe, makkelijk moeten kunnen onderscheiden van de spammers. Maar het lijkt wel alsof ze er niet veel moeite meer voor doen
Rate en reputation zijn 2 van de waarschijnlijk vele factoren die je nog totaal vergeet. Als een domein plots 10 of 100x meer ontvangers van je infrastructuur mailt tot bijna 10% van de totale bevolking, dan is dit geen overdreven reactie van een geautomatiseerd systeem.

Als je zo'n grote doelgroep hebt, dan zou ik bij het merendeel van de providers waar mogelijk ook een aantal mailboxen aanmaken die je kan monitorren zodanig dat je snel merkt dat er een impactvolle partij je alerts blocked en korte communicatielijnen vragen (als overheid zelfs eisen) die in zulke noodsituaties alsnog snel kunnen ingrijpen.
Oei. Ik vrees dat jij in de toekomst, of hoogstwaarschijnlijk nu al , meer ongewenste/kwaadaardige mail doorlaat dan je beseft :)
Zeker niet, en alles dat tegengehouden wordt, is ook terecht tegengehouden. 50k+ mails per dag verwerkt. Geen phishing, geen spam naar de gebruikers. Maar mailings van leveranciers komen keurig binnen zonder whitelisting wanneer ze aan alle eisen voldoen. Kwestie van opvoeden en ze leren hoe email nou eigenlijk werkt en waarop AV/AS op controleert.
Een bericht verstuurd vanaf een mailserver die aan alle voorwaarden als een volledige SSL/TLS keten, SPF, DKIM en DMARC voldoet, en een emailbericht dat opgesteld is als multi-part met zowel HTML als plain-text opmaak, waarbij linkjes dezelfde link in leesbare tekst hebben als de werkelijke link, en waarbij afbeeldingen vanuit hetzelfde domein gelinkt zijn, komen zelden tot nooit in aanmerking als spam.
Het punt wat ik probeerde te maken is dat ik dit als malafide partij ook allemaal kan regelen. No problem.

En als een andere malafide partij dat niet in de gaten heeft, dan is deze ook bij jou op het goede adres :+ :
Kwestie van opvoeden en ze leren hoe email nou eigenlijk werkt en waarop AV/AS op controleert.
Niet om vervelend te doen hoor, maar ik probeer alleen (voor iedereen) duidelijk te maken dat:
  • op basis van RFC, configuratie, authenticatie en best practices, 1 is, de inhoud en intentie is 2.
  • je aan niemand laat weten hoe jij je controle slagen uitvoert. Dus ook geen gedetailleerde notificaties of bounces met specieke reden terugsturen naar iedereen die het verkeerd doet. Daar voed je potentiele aanvallers mee.
Als men na meer dan 20 jaar SPF, nog steeds hun SPF verprutst, dan mogen ze de communicatie maar via andere kanalen gaan voortzetten. Ondertussen zitten kwaadaardige mails ertussen die wel alles op orde hebben, maar waar een context awareness filter alarm op zou moeten slaan. Waarom krijgt medewerker A een mail vanuit een adres waar nooit eerder communicatie is geweest, met een Braziliaans IP adres vanuit een domein die 3 dagen geleden is geregistreerd?

[Reactie gewijzigd door Aurora op 21 juni 2026 21:19]

Helemaal eens met je. Er zijn nog tientallen criteria waarop gecontroleerd wordt. Dit zijn slechts de basale punten die veel spammers maar ook bulkmaildiensten niet op orde hebben.
Vergeet ook niet dat de HELO name met het reverse DNS record en source IP moeten matchen. Echter, mail/SMTP is het meest gebroken protocol dat er ondehand heeft bestaan. Er zijn zoveel gaten die elke keer met een ander protocol pljistertje worden gepatcht en dat terwijl spam nog aan de orde van de dag is. Het zorgt er ook voor dat er veel legitieme mail wordt geblokkeerd. Dat Helo name, reverse records, SPF, DKIM DMARC en DANE op orde zijn mag je verwachten, maar zelfs dan verdwijnt veel mail nog in de spambox of worden uitgaande mailserver IPs geblokeerd omdat er b.v. in een relatief korte tijd meer dan normaal wordt verstuurd. Het basisprovleem.is dat het oplichters bijna niets kost om heel veel spam te sturen.

Helaas stamt SMTP uit een tijdperk waar de meeste gebruikers en providers op het internet elkaar nog enigszins konden vertrouwen. Wellicht zou een chain/web of trust net als bij certificates het probleem grotendeels kunmen oplossen, maat dan nog zal.het spam niet kunnen voorkomen.
Zekers. PTR-record (reverse DNS), afzenderadres moet overeenkomen met het domein van gebruikt wordt in HELO/EHLO, links die valide zijn, afbeeldingen niet gelinkt aan externe bronnen buiten de domeinnaam van het emailadres etc.
De gelijktijdige verzending van honderdduizenden e-mails met hetzelfde onderwerp activeert beveiligingssystemen en verplicht providers tot een veiligheidscontrole, legt de woordvoerder uit.
Begrijpelijk en volkomen logisch. En terecht.

Aan de andere kant zou het toch ook mogelijk moeten zijn om dit soort mails te whitelisten. Het is een geplande en doelbewuste mail, die neem ik aan van 1 specifiek emailadres/domain afkomstig is, en van 1 uitgaand IP-adres(block) komt.

Die combinatie van bekend tijdframe, bekend afzender-adres, en bekend Sender IP-adres zou het toch mogelijk moeten maken om deze tijdelijk (voor de duur van de mailcampagne) te whitelisten zou je zeggen?

Uiteraard whitelisten aan de ISP-zijde, dan heb je natuurlijk nog altijd mensen met een eigen scanner maar dat zal een véél kleiner aantal zijn.

Zeker gezien het belang van dit soort mails (we hebben het niet over reclamemails voor een pak koekjes ofzo) zou dat toch moeten worden ovewogen, imho uiteraard.
Die combinatie van bekend tijdframe, bekend afzender-adres, en bekend Sender IP-adres zou het toch mogelijk moeten maken om deze tijdelijk (voor de duur van de mailcampagne) te whitelisten zou je zeggen?
Waarom zou je het domein van de afzender niet permanent whitelisten?
Uiteraard wel met eisen aan DKIM, SPF en andere zaken.

[Reactie gewijzigd door Olaf van der Spek op 21 juni 2026 12:01]

Omdat je de BE-Alert infrastructuur dan een héééél aantrekkelijk doelwit voor spammers maakt. En het zal niet de eerste keer zijn dat zoiets gehackt is.

Daarnaast, "mail komt uren later aan" is geen bug. Email is nooit bedoeld geweest om direct afgeleverd te worden. Het is ontworpen voor een store-and-forward model, waarbij het niet in één keer naar de bestemmings-server gaat, maar stap voor stap een stukje dichterbij. Dial-up verbinding ligt er uit, of een server is onbereikbaar? Geen enkel probleem, probeer het een uurtje later nog een keer. Dit is waarom mail relays zo'n groot probleem waren toen spam op kwam, en waarom greylisting kan werken, en waarom een domein meerdere MX records kan hebben.

Als een partij tienduizenden identieke berichten verstuurt, is de kans groot dat het spam is - vooral als het geen geschiedenis van regelmatige grootschalige mailcampagnes heeft. Het is dus geheel naar verwachting dat de email daardoor bij Google & friends op een lijstje komt om handmatig door een moderator goedgekeurd te worden. En dat kost tijd. Maar het is email, dus vertraging is normaal.

Het feit dat BE-Alert ooit dacht dat dit niet zou gebeuren, geeft aan dat ze de werking van email fundamenteel niet begrijpen!
Daarnaast, "mail komt uren later aan" is geen bug. Email is nooit bedoeld geweest om direct afgeleverd te worden. Het is ontworpen voor een store-and-forward model, waarbij het niet in één keer naar de bestemmings-server gaat, maar stap voor stap een stukje dichterbij.
Dus omdat het ooit zo ontworpen is staat dit vast? Een telefoon was ontworpen met een kabel voor gesprekken en niet en niet als draadloze mobile computer in je had. En ik verwacht ook niet dat de eerste internet ontwikkeld was voor op de huidige manier dat we gebruiken / de protocollen die we nu gebruiken / de snelheden en verbinden (utp, wifi, upc kabel, glasvezel) in vedachten. De eerste...

Veel dingen zijn niet ontwikkeld voor de manier dat we het nu gebruiken. Dus ja het is goed dat we een backup hebben voor problemen. Maar als bedrijven dingen gaan eisen dat ik binnen 15 minuten een code moet invullen kan ik ook niet zeggen "maar emails zijn zo niet bedoeld dus je moet mijn code nog steeds accepteren". Dus ja ik vind dat emails gewoon bijna gelijk op de server moet staan waar ik het van kan downloaden / te bekijken is ondanks dat het geen bug is. De maatschappij (inclusief bedrijven zoals Google en Microsoft die dit ook vragen en ook een mail server hebben) heeft dit zelf gecreëerd dus mogen ze dit ook toepassen.
Greylisting is een techniek die mail altijd de eerste keer blokkeert. Pas als de mail opnieuw aangeboden wordt zal deze wel geaccepteerd worden.
En dan mag je vinden dat het onacceptabel is dat mail er langer over doet. En je zou alle beveiligingsmaatregelen af kunnen breken en dan heb je super snel mail in je mailbox. Maar wat je er dan ook bij krijgt is een stapel spam waar niemand op zit te wachten.
Mail is gewoon niet het middel als je in bulk miljoenen berichten tegelijkertijd wil versturen en er vanuit wil gaan dat het instant bij iedereen in zijn mailbox staat.
Edit: ook voor @Skywalker27
Edit: voordat men reactie geeft lees even de eerst regel.

Ik zeg ook niet dat het een goede manier is voor miljoenen tegelijkertijd (edit: of te wel niet geschikt voor een alert al kan het wel als een extra optie zijn). Maar om te zeggen dat het geen instant (lees binnen 15 minuten instant) is (edit: dus normale situaties en geen alarm) vind ik ook niet kloppen. Zoals ik zei dingen veranderen (snellere internet, snellere en grotere capaciteit computers / servers, minder stoningen meestal) dus om je vast te houden aan vroeger vind ik vreemd. En die mail met code is dus gewoon snel nodig en niet een paar uur later. Ja storingen, problemen en downtime kan altijd gebeuren daarom is het dus goed dat de mail niet gelijk verdwijnt. Maar dat deze mails niet gelijk binnen 15 minuten komen zou de uitzondering moeten zijn niet niet de norm (vanwege dat het hiervoor niet ontwikkeld was).

[Reactie gewijzigd door Daoka op 22 juni 2026 21:45]

Heel mooi en dapper om er zo naar te kijken.

Maar helaas, e-mail is slechts één van de vele communicatie mogelijkheden. Ik begrijp niet dat je e-mail voor een directe Alert zou willen gebruiken, anders dan preventief. Niet dat het systeem verouderd is, niet omdat het internet (en alles) zich ontwikkeld heeft, maar vooral, omdat e-mail altijd al een 'postbus' systeem was, is en zal blijven. Iets wat je niet continu hóéft te checken.

Ik begrijp heus je standpunt wel: Technologie veranderd, dingen gaan sneller, beter, meer bereik. Maar voor een Alert dan dus zoiets als een (digitale) brief gebruiken. Raar.

Er bestaan inmiddels al een paar decennia systemen die wèl voor directe Alerts gebruikt zouden kunnen worden, vooral omdat het directe karakter eigenlijk al omsloten zit in de naam: Instant Messaging

Je hoeft het niet te archiveren, komt direct binnen, op welk device dan ook, via Push meldingen. SMS of de modernere RCS is een voorbeeld, maar ook een bericht via een berichtendienst zoals een DM via MSN Messenger, ICQ, Instagram, Twitter/X, Facebook, Signal, WhatsApp, Telegram of het NL-Alert systeem (via je mobieltje). Allemaal voorbeelden van diensten die DIRECT een melding geven,..

Waarom kiezen ze niet voor een bericht in papierenkrant?
Edit: ook voor @Wouterie
Zoals ik inijn eerste regel zei: "Ik zeg ook niet dat het een goede manier is voor miljoenen tegelijkertijd.". Of te wel ik zeg niet dat ik dit wil voor alert. Al zou het zeker als extra optie erbij kunnen. Want hoe meer alarmen er gegegeven wordt des te beter.

Ik zeg alleen dat het dom is om te zeggen dat email geen instant bericht is (nogmaals 15 minuten instant).

Daarnaast is geen 1 ding compleet veilig. Ik heb ook wel eens geen sms ontvangen van bedrijven die een code via sms verstuurde. Zo moest ik bijvoorbeeld PayPal activeren maar tig keer aangevraagd en zelfs helpdesk die de aanvraag deed maar nooit ontvangen (en ja ik kon wel andere ontvangen). Twitch stuurt notificaties als de streamer die je volgt online gaat. Ook hier is het een aantal keren gebeurd dat ik pas een uur later een bericht kreeg. Ook andere hebben dit wel eens in de chat gezegd. Sterker nog het is ook wel eens gebeurd dat ik zag dat de streamer online kwam en ik aan het kijken was en een half uur later een bericht dat de streamers online is. De WhatsApp van mijn moeder krijgt ook niet altijd gelijk de bericht binnen. Ik app meestal dat ik er aan kom en het is ongeveer 10 minuten lopen. Ik ben wel eens binnen gekomen dat de bericht toen pas aan kwam. Meestal gaat het gelijk maar het is wel een aantal keren fout gegaan dat het niet binnen 1 minuut is. Ik heb ook nooit kunnen vinden waarom het soms traag is. Ze heeft geen internet storing want op haar tablet zit ze gewoon te browsen of YouTube te kijken. Dus meerdere manieren zou gewoon beter zijn dus.

[Reactie gewijzigd door Daoka op 22 juni 2026 18:57]

E-mail is per definitie geen instant messaging en zelfs SMS wordt er doorgaans niet onder gerekend. WhatsApp wel, maar je kunt je afvragen of het verstandig is dat een overheid leunt op een commerciële, niet EU dienst.
Daarom staat er letterlijk in mijn tekst (in verschillende reacties) 15 minuten instant (en geen 1 seconden instant). Of te wel niet gelijk maar we hoeven ook niet te doen alsof we dagen moeten wachten. Maar de meeste zijn zeker wel binnen een paar seconden beschikbaar (op de server van waar je die downloaden of online kan bekijken). Ik zeg dus niet bij de persoon maar dat de persoon de mail zou kunnen krijgen. Want ja er zijn omstandigheden te bedenken dat de persoon niet gelijk heeft zoals geen internet buiten, handmatig op de knop drukken, storing van de app of programma, account verkeerd ingesteld, ect ect ect.
die 15 minuten instant die jij noemt @Daoka , dat zijn toch echt jouw zelf hierbij 'verzonnen' 15 minuten.

E-mail relay kan tot uren en zelfs dagen duren voor dat deze uiteindelijk wordt afgeleverd. Dat zit zo in het protocol ingebakken. Zoals de post-bezorging ook de volgende dag kan zijn (standaard) maar ook een paar dagen vertraagd kan zijn, zo is e-mail meestal instant, maar dat is meer een gewoonte dan een feature.

Je kunt er niet op vertrouwen dat iets wat 'meestal instant werkt' bij toeval ook instant werkt in het geval van een Alert. De voorbeelden die jij noemt over SMS die niet instant werkt gaat over verstoringen van een systeem, waardoor SMS niet 'direct' aankomt, bij e-mail is er per definitie geen sprake van een verstoring van de functie als deze vertraagd wordt afgeleverd, maar juist van een waardevolle eigenschap: Het afleveren is best wel goed gegarandeerd, juist als er verbindings/server hickups zijn tussen jou en ontvanger op het moment dat de mail verstuurd wordt: 'vertraging >> aflevering'
Ik heb niet echt verzonnen maar ik zeg wat bedrijven verwachten. Die code in 15 minuten invullen zou er echt niet 50% van de tijd de mails pas een dag later zouden zijn. Maar inderdaad ook gewoon mijn ervaring is dus dat 99% van de tijd (tenminste van de keren dat ik kan bewijzen dat het snel of traag gaat) gewoon binnen een paar seconden of minuten binnen is. Ja het is ooit ontworpen met dus de leveringsgarantie en het is mooi dat dit er als backup er nog steeds in zit maar dat is niet de norm meer.

Je geeft zelf al de voorbeeld van pakket levering. Vroeger moest je een paar dagen wachten. Ga jij er nu nog steeds van uit dat je 3 dagen of langer moet wachten of verwacht je dat een pakket gewoon morgen binnen is? Ik neem aan dat je antwoord morgen is ondanks dat er dus dingen verkeerd kunnen gaan of dat het dus vroeger anders was
Je kunt er niet op vertrouwen dat iets wat 'meestal instant werkt' bij toeval ook instant werkt in het geval van een Alert.
Er staat in verschillende reacties dat ik zeg dat het dus niet bedoeld is als melding voor noodsituaties (al kan het zeker wel als extra melding zijn). Maar dat dus uitgaan van dagen omdat het ooit (lang geleden) zo gemaakt is gewoon niet meer de norm is ondanks dat er dus uitzonderingen zijn. Ik kan ieder geval de laatste keer dat ik minimaal 24 uur moest wachten op een mail niet meer herinneren ondanks dat dit nog steeds mogelijk is.

[Reactie gewijzigd door Daoka op 22 juni 2026 21:47]

Volgens mij slaat men vooral aan op het commentaar dat je levert op een systeem, wat in jouw ogen verouderd is, omdat het, bij bepaald gebruik, niet doet wat men zou willen (direct afleveren bij miljoenen mensen tegelijk). Omdat het niet dáárvoor ontworpen is (als directe alarmering), en omdat het dáártegen beveiligd is (tegen mass-mailing).

Je stapt daarbij over conventies heen, vooral vanuit eigen ervaringen én het (onhandige?) gebruik door bijvoorbeeld bedrijven. Want ja, als een bedrijf een geldigheid van 10 of 15 minuten aanhoud, dat is dát het tijdsspanne waaraan het e-mail systeem moet voldoen. (Neen: Vrije keuze van bedrijf om 2FA zo in te richten, wat voor 99% van de gevallen waarschijnlijk ook werkt en daarmee voldoet)

Maar ook ga je er vanuit dat 'iedereen' push-meldingen per e-mail krijgt en lees en daar naar handelt. Dat terwijl ik heel veel inboxen gebruik, waarvan ik een aantal maar een beperkt aantal dagen per week bekijk.

Dat er anti-spam oplossingen bestaan, juist tegen mass-mailings, omdat het systeem al in de jaren 90 misbruikt werd, en dat dáár door een alarmeringende instantie geen rekening mee wordt gehouden, is tot daaraan toe, maar dat je vervolgens de bal bij het 'e-mail protocol' neerlegt, als oplossing voor een niet bestaand probleem: daar schuurt het pas écht.

Als jij niet meer weet wanneer je langer dan 24 uur op een mail hebt gewacht, betekent dat vooral dat jouw e-mail provider waarschijnlijk al jaren dezelfde is. Maar niet dat het altijd zo is, en dat het systeem daar ook voor ontworpen is. Het afleveren van e-mails heeft een veel hogere prioriteit dan de snelheid van aflevering.

Ik kan het mij wel herinneren, dat ik heb zitten wachten op een 2FA bericht, en dat ik pas na een paar uur de code kreeg, en dat ie dus al lang verlopen was. En daarna nog 5 mails, met idem dito verlopen codes, omdat ik het natuurlijk meermaals geprobeerd had. Dat was afgelopen maart nog het geval. Heel vervelend, maar niet life-threadning ( al kon ik niet bij mijn betaalrekening, dus zeer vervelend was het wel )

Dus, afsluitend, wat @Wouterie hieronder schrijft: (...)een systeem wat hier niet voor ontworpen is kan niet zo betrouwbaar zijn als een systeem wat hier wel voor ontworpen is.
15 minuten is ook uit de lucht gegrepen. Het hele ontwerp van e-mail is niet bedoeld voor instant of 15 minuten 'instant' of 2 uur 'instant' het is hier niet voor ontworpen, niet voor bedoeld en niet echt voor geschikt. Dat het meestal goed gaat is dankzij de modernere technieken etc... Dat het werkt betekent niet dat het ook goed werkt en al helemaal niet dat het gegarandeerd goed werkt wanneer je het het hardst nodig hebt. Dan moet je het hebben van mazzel.

Maar bekijk het van de positieve kant! We zien nu allemaal dat e-mail niet goed werkt. Alle Europese overheden en diensten kunnen er nu niet meer onderuit. E-mail kan dus worden geschrapt als optie om de mensheid te informeren tijdens een noodsituatie. Uiteindelijk blijven er systemen en technieken over die wel betrouwbaar genoeg zijn in zo'n noodsituatie.
Even advocaat van de duivel spelen hoor ;) Je laatste zin zegt het eigenlijk al: het zou een uitzondering moeten zijn. En dat is nou precies het probleem dan een BE-Alert een uitzonderlijke situatie is. Normaal gesproken kun je er redelijk vanuit gaan dan een email binnen 10 minuten 'bezorgd' is. Maar een systeem wat hier niet voor ontworpen is kan niet zo betrouwbaar zijn als een systeem wat hier wel voor ontworpen is.

Dat het onder normale omstandigheden meestal goed gaat is geen garantie dat het onder uitzonderlijke omstandigheden ook meestal goed gaat. De aanname dat het dus wel goed gaat omdat er nieuwe technieken etc zijn en omdat het in een kleine oplage wel snel binnenkomt... die is best gevaarlijk als je hiermee een heel land vlot wilt bedienen.
JA, Net zo al die managers die niet willen begrijpen dat IT niet geschikt is voor Safety. Het mail protocol staat vast dat gaat 1 pipo niet veranderen. Je kan er nog wel laagjes boven opbouwen maar dat pakt niet uit in het voordeel voor snelheid. Ook leest niet iedereen zijn mail zo als met een SMS of een chat bericht. EN dan nog maar te zwijgen over account die geen push hebben.

edit; Ik wou eigenlijk nog een grap maken over UDP maar die komt waarschijnlijk toch niet aan.

[Reactie gewijzigd door Skywalker27 op 22 juni 2026 10:14]

edit; Ik wou eigenlijk nog een grap maken over UPD maar die komt waarschijnlijk toch niet aan.
UDP bedoel je waarschijnlijk ( :+ )
Precies dit. Email is per definitie niet geschikt voor tijdkritische en kritieke zaken.
Email is heel goed geschikt voor kritieke zaken! Het zit zo in elkaar dat als het nu niet aan komt, dan proberen we het de komende dagen/weken nog een paar keer. Het is maar net waar je de meeste waarde aan hecht. Snelheid is niet altijd alles.
Nope. Er is geen garantie van aflevering en je bent afhankelijk van de ontvangende server of deze zo vriendelijk is een ontvangstbevestiging terug te sturen. En dat is dan nog geen enkele garantie dat het bij de beoogde ontvanger is aangekomen.

Daarnaast ken ik verdomd weinig kritieke processen die niet afhankelijk zijn van tijd. Als het tijd heeft is het eigenlijk nooit kritiek. Dus ook daar gaat het mis.
En je bent ook niet zeker als afzender en ontvanger dat er onderweg niet geknoeid is met de e-mail. MTA-STS is al een verbetering als je weet dat de servers dit ondersteunen, maar dan nog moet je de servers zelf ook vertrouwen.
Vertel de mop maar. Gaan we zien of die aan komt. Daarnaast (voor de zoveelste kee aangezien jij niet de enigste was) ik zei in mijn eerste regel "Ik zeg ook niet dat het een goede manier is voor miljoenen tegelijkertijd" of te wel niet goed geschikt voor een alarm. Alleen dat ik niet vind dat we tegenwoordig vanuit moeten gaan dat email dus dagen duurt. Of te wel 15 minuten instant onder normale (geen ramp) situaties.
Ja, omdat het ooit zo ontworpen was staat het vast. Wil je dat aanpassen is er niemand die je tegenhoudt om een aanpassing van de standaard voor te stellen, maar email zal nooit een instant messaging oplossing worden.

En vele van de protocollen die we vandaag gebruiken, en ja, daar valt email ook onder, zijn in de basis decennia oud. Dat we er nieuwe mogelijkheden bovenop bouwen wil niet zeggen dat de basis die eronder zit mee gevolueerd is. Neen, dat gebeurt niet. Standaarden worden al sneller vervangen. Denk maar aan HTTP/2 wat een grotendeels nieuwe standaard is, gebasseerd op een technologie van Google. Maar een protocol zoals SMTP of TCP? Nope, nog altijd hetzelfde als in de jaren '80. En dat om de compatibiliteit te bewaren.

En ja, ik heb het al meermaals voorgehad dat ik een TOTP via email verstuurd krijg en die mail komt maar niet aan. Dat ik letterlijk op de edge van het netwerk kan gaan kijken dat die email nooit is binnengekomen. Dan zit het probleem niet eens in mijn netwerk, maar ergens op het internet. En daar heb je 0 controle over en dat ga je niet snel aanpassen.

Dat komt er net van wanneer mensen iets vanzelfsprekend vinden ondanks dat het nadrukkelijk NIET in een standaard is opgenomen. Mail kan en mag meerdere dagen doen over de aflevering. Jij mag dat gerust onaanvaardbaar vinden, maar ik heb liever dat als er iets misloopt, dat de verzender niet onmiddelijk een bounce krijgt maar dat men een tijd blijft proberen. En dat laatste zorgt ervoor dat je er NOOIT vanuit mag gaan dat mail onmiddelijk is.

Wil je onmiddelijke communicatie, dan moeten zender en otnvanger eerst een communicatiekanaal opzetten waarmee dat mogelijk is. Is dat communicatiekanaal er niet? Dan mag je er simpelweg NOOIT vanuit gaan dat je bericht snel zal aankomen.
Tja hoe oud zijn auto's? De principe van een motor die de carrosserie en de mensen erin verplaatst is ook niet echt veranderd. Toch gaan we sneller als de eerste auto, hebben we dingen als gordels gekregen, betere wegen, meer wetten, stoplichten, ect. Moeten we hier dan ook maar vanuit gaan dat de eerste auto geen 100 KM/h kon en dus alles aanpassen op hoe de eerste principe / snelheid / veiligheid / omstandigheden van de eerste auto was? Of zullen we de wetten zo houden omdat er dingen veranderd zijn (waaronder dus dingen buiten de auto)?

Daarnaast in de tekst staat "Ja storingen, problemen en downtime kan altijd gebeuren daarom is het dus goed dat de mail niet gelijk verdwijnt. En ja leuk gesproken. Maar ik verwacht echt wel dat als jij een mail verwacht (die binnen 15 minuten moet hebben) en de volgende dag pas binnen komt dat je ook niet denk van "zo zijn de protocollen het is normaal". Dan zal er waarschijnlijk wel een lichte vorm van irritatie (of andere gevoelens).

[Reactie gewijzigd door Daoka op 22 juni 2026 21:54]

Dit. Als SPF en DKIM succesvol is en de afzender is... [BE alert] dan ... [sta altijd toe / gooi -9000 over de spam score / ...]

Ik draai mijn eigen mailserver + spam checking. En in rspamd zit dit "bijna standaard" ingebouwd. Als ik mij niet vergis hoef je maar een "config" file met een lijst van domeinnamen te vullen. Waarbij de (juiste) filename bepaalt hoe die wordt toegepast (of alleen SPF succesvol moet zijn, of alleen DKIM succesvol moet zijn, of beiden). En uiteraard kun je all-out gaan en je eigen regel / rule schrijven.

Én er zit zelfs al een standaard lijst ingebakken. Die o.a. gevuld is met bv vele (internationaal opererende?) banken gevuld is. Zodat standaard mails van die banken dus niet als spam gemarkeerd kunnen worden. Je zou dus ook kunnen stellen dat BE alert moet zorgen dat ze op die lijsten komen zodat bv een standaard rspamd installatie nooit mails van BE alert als spam markeert (zolang dus SPF en DKIM checks succesvol zijn).
Jij zou dan ook 1-2 mailtjes krijgen, Google krijgt er ineens 1 miljoen richting Gmail, dan knalt het tegen de rate limits aan.

Moest ook België zijn die noodmeldingen via email gaat versturen. Wat een grap.
Dit. Als SPF en DKIM succesvol is en de afzender is... [BE alert] dan ... [sta altijd toe / gooi -9000 over de spam score / ...]
Laten we deze logica doornemen.

MAIL-FROM: 6567.lolz.ru ----> SPF pass
DKIM signature domain: lolz.ru ----> DKIM pass
From header domain (afzender): be-alert.be

Sta toe.

Oftwel, je hebt DMARC en/of domain alignment controle nodig. En buiten alles om, whitelisting, in welke vorm dan ook, is een big no-no. Je gaat niet de problemen/non-compliancy van andere systemen/externe partijen maskeren.

En nog iets, stel dat be-alert.be daadwerkelijk het emaildomein in kwestie is, vergeet dan maar DMARC:
;QUESTION
_dmarc.be-alert.be. IN TXT
;ANSWER
_dmarc.be-alert.be. 21600 IN TXT "v=DMARC1; p=none"

[Reactie gewijzigd door Aurora op 21 juni 2026 16:37]

Ondanks juiste SPF en DKIM kan er nog steeds reden zijn om de mail tegen te houden. De afzender kan gecompromitteerd zijn en malware/phishing troep versturen.

Alles maar klakkeloos op de whitelist zetten (‘oogkleppen op zetten’) lijkt mij dan ook een slecht idee.

[Reactie gewijzigd door ThinkPad op 21 juni 2026 15:42]

Je hebt helemaal gelijk. DKIM en SPF zijn helemaal geen garantie voor veiligheid. Ik zou google.com blacklisten als die site malware aan het verspreiden is. "Not too big to block".

DKIM en SPF op zichzelf bewijzen alleen maar dat de verzender geautoriseerd is om mail te versturen namens een bepaald domein. Maar zoals we weten is de Amerikaanse snowshoe spam vrijwel altijd voorzien van DKIM en SPF. Daarom scoort DKIM en SPF niet negatief bij scoring spamfilters zoals SpamAssassin.

Waar het over gaat is de combinatie van een bepaald domein en autorisatie. Dus de combinatie van een specifiek domein en controle van DKIM/SPF/DMARC is wel goed.

In de praktijk echter worden domeinen gewoon gewhitelist door blacklists. Een URI BL zal niet google.com blacklisten. Dat kan pas na handmatig ingrijpen, maar het is nog nooit gebeurd.

De realiteit is dat veel spamfilters nog altijd ontzettend dom zijn, dat bedoel ik letterlijk. Ze kijken naar scores of zelfs alleen het voorkomen van woorden die vaak in phishing wordt gezien. Er zijn mede daardoor eindeloos veel false positives. De grootste techbedrijven met een emailvoorziening maken zich daar schuldig aan, bijvoorbeeld Google en Microsoft.
Het is zelfs nog erger. Ik zie regelmatig dat een legitieme email verzonden aan meerdere personen in 1 domein, de mailbox van de ene gebruiker wel bereikt. Bij de andere zit die in de spam en bij een derde komt het bericht helemaal niet binnen en is al op de server blijven hangen.
Ondanks juiste SPF en DKIM kan er nog steeds reden zijn om de mail tegen te houden. De afzender kan gecompromitteerd zijn en malware/phishing troep versturen.
Ach, zelfs als je IP geen slechte reputatie heeft, en alles perfect is ingesteld met een mail-tester score van 10/10 kan je mail afleveren in iemands spambox.

Een tijd geleden was dit mijn issue, nooit weten op te lossen ook. Mail altijd in spambox, ondanks perfecte configuratie?

Mail is een prachtig medium, maar een ramp om goed geconfigureerd te krijgen, en eenmaal een slechte reputatie waarvan je de oorzaak nooit zult achrerhalen, dan kan je beter maar stoppen.
Heel eerlijk. Als je kijkt van hoeveel verschillende componenten en partijen email afhankelijk is, dan is het eigenlijk een godswonder dat het überhaupt werkt.
Oprecht even waardering voor het runnen van je eigen mailserver anno 2026.
want? Ik draai hem ook zelf, want het is goedkoper een vps te nemen om meerdere domeinen te voorzien van mail, dan dit ergens onder te brengen. Zo ingewikkeld is dat tegenwoordig ook weer niet.
Simpelweg omdat er - mijns inziens - ook betere alternatieven zijn om te communiceren dan e-mail, waar e-mail ook gevoelig is voor o.a. spam en phishing en dergelijken. Ook moet een bepaald IP-adres en domain combinatie tegenwoordig wel regelmatig e-mailen omdat het anders ook als een mogelijke spammer wordt gezien. Het wordt langzaam maar zeker eigenlijk niet meer interessant om een (eigen) e-mailserver te draaien.

Hoewel wellicht een wat kromme analogie, maar we rijden ook niet meer primair in auto's uit de jaren '60 of '70 van de vorige eeuw, de technologie ontwikkeld en verbeterd zich immers. Auto's zijn comfortabeler en zuiniger geworden, zo geldt dat ook voor (manieren van) communiceren en bestandsoverdracht; ook daar zijn gemakkelijkere manieren voor dan SCP of de verschillende vormen van FTP bijvoorbeeld.

[Reactie gewijzigd door CH4OS op 21 juni 2026 16:59]

IMAP4 is van 1990, dus best recent ;)
Niets mis met IMAP als je mijn werkgever vraagt :X
Welke open gestandaardiseerde alternatieven zijn er dan? Wat ik bijzonder vind is eerder dat in het artikel SMS is aangehaald als alternatief.

Waarom niet gewoon alert broadcasts op mobieltjes? Wordt in NL gebruikt en zou verwachten dat dat in BE ook zo is.
Kosten-baten afweging. Ik heb verschillende domeinen met een flink aantal mailboxen. Uitbesteden aan een mailpartij is onderaan de streep duurder dan zelf een server inrichten.
Het is maar hoe je het bekijkt. Een Microsoft 365 Basic per menselijke gebruiker. Van alle overige mailboxen gedeelde mailboxen maken. Kan met meerdere domeinen ook in 1 tenant. Kost het je alles bij elkaar net iets meer dan niks
De domeinen en gebruikers hebben werkelijk 0,0 overlap, ik zal dus per gebruiker een licentie moeten afnemen. Dan heb ik niks aan 365 Basic, dat kan niet met een eigen domein. 365 Business Basic wel, maar dan is een Hosted Exchange-licentie weer wat voordeliger als het alleen om email gaat.

Maar dan ben ik 3-4 euro per gebruiker per maand verder. Is per gebruiker niet duur nee. Ga ik optellen dan heb ik er 2x een complete server voor draaien incl de afschrijving en een backup op een 2e locatie •en• heb ik zelf inzicht in we er bij de data kan.

Als het nu om 2-3 mailboxjes gaat, dan is het een ander verhaal
Ik draai al mijn eigen mailserver sinds 1999. Niet alleen mail, maar ook DNS (afgeschermd als Cloudflare als 'authoritative' en IPSEC VPN. Ik heb zelfs een shadow domain welke intern andere IP terug geeft (192.168.2.0/24), terwijl als je hem extern benaderd dan geeft deze het IP van de DMZ VPN (172.16.29.0/24) terug. Pengolin maakt na authorisatie (Authelia welke authoriseerd tegen Samba DC) diverse web interfaces bereikbaar. Op die manier kan ik gewoon overal mijn NextCloud bereiken of diverse *arr sites. Ik 'download' ook best wel veek YouTube filmpjes. Op die manier heb ik een hoop oude TV series terug gevonden.

Mijn 'gateways' draaien in een Duits en Fins datacenter (Hetzner) en de kosten daarvan zijn al jaren lager dan een enkele VPS bij TransIP waar ik eerst zat.
En als beheerder van mail infra zorgen wij ervoor dat onze whitelist zo leeg mogelijk is. Je wil geen whitelisting, want dat is letterlijk spammers uitnodigen om de verzende kant te hacken en je dan maar te gaan bestoken met "legitieme" email. Want jij vertrouwt die afzender expliciet.
Waarom zou je het domein van de afzender niet permanent whitelisten?
Geen whitelisting toepassen staat hoog in de lijst van email security best practices. Als het bedrijf/instantie wordt gecompromitteerd komen alle mails namelijk vrolijk door je eerste laag van bescherming heen. Zeker je tegenwoordig een redelijk veilig scala een beveiligingsopties hebt met de combinatie SPF, DKIM en DMARC. Zie ik geen enkele reden om een domein te whitelisten buiten je eigen netwerk om.

Als op de een of andere manier bepaalde afzenders wel standaard uitgesloten worden van bulk filtering, dan zou dat voor een situatie als deze wel een uitkomst zijn. Hoe je dat dan weer tegen misbruik kan beschermen is een tweede.
Sterker nog: het komt vrijwel in iedere serieuze securityrichtlijn terug, niet alleen bij e-mail. Het is een van de meest fundamentele security best practices. Toch lijkt whitelisten voor veel mensen maar ook organisaties de standaardoplossing zodra iets niet functioneert wat men voor ogen heeft.

Hoe vaak ik niet zie dat leveranciers van third-party software adviseren om complete mappen uit te sluiten / whitelisten van antivirus- of EDR-scans, is werkelijk verbazingwekkend. In plaats van hun software compatibel en veilig te maken, wordt de beveiliging afgezwakt om het probleem te omzeilen.

Dat is niet alleen slechte praktijk, maar ook een risico dat zich vroeg of laat tegen je kan keren.
Ja, maar…

Het zijn niet de signature-based scans die de detectie geven, maar de heuristische scanners. Sommige software moet dingen doen die op een virus lijken. Hoe moet je dat dan oplossen?

Als het zo simpel was om dat eventjes anders te programmeren, dan deden de virusmakers dat toch ook gewoon? Ik werkte vroeger bij een webbedrijf wat veel gemeentes, provincies etc. als klant had. Hoe vaak ons wel niet gevraagd werd om ‘even’ de spamfilters te omzeilen want hun nieuwsbrieven kwamen in de spamfilters terecht.. en dan weer uit moeten leggen dat dat niet echt kon, want als dat wel zou kunnen, zouden de spammers dat ook doen. Dit was ver voor DKIM en dat soort dingen ook.
Ik ben het daar gedeeltelijk mee eens. Sommige legitieme software vertonen inderdaad gedrag dat ook door malware wordt gebruikt, waardoor bepaalde detectie kan afgaan. Maar dat betekent niet automatisch dat whitelisting de juiste oplossing is. Sterker nog, een oplettende aanvaller kan dit juist gebruiken als aanvalspunt.

Softwareleveranciers kunnen veel doen om false positives te verminderen: code signing toepassen (dit gebeurd veel en veelste weinig), reputatie opbouwen, hun software vooraf laten testen bij AV/EDR-leveranciers en verdachte technieken vermijden waar mogelijk (Microsoft's Defender for Endpoint is hier heel erg goed in).

Daarom is "zet onze X maar op de exclusionslijst" vanuit security-oogpunt vaak een zwaktebod.

Natuurlijk zijn uitzonderingen soms onvermijdelijk (bijv. bij legacy applicaties die geen updates meer ontvangen.. jep ook die zijn er), maar wat mij stoort is dat ze te vaak als standaardadvies worden gegeven in plaats van als laatste redmiddel na een technische analyse van de detectie.
Aan de andere kant zou het toch ook mogelijk moeten zijn om dit soort mails te whitelisten. Het is een geplande en doelbewuste mail, die neem ik aan van 1 specifiek emailadres/domain afkomstig is, en van 1 uitgaand IP-adres(block) komt.
E-mail is gedecentraliseerd. Dit zul je dan moeten gaan coördineren met honderden, misschien duizenden e-mail providers. Dat is echt onbegonnen werk. Er is ook geen centrale autoriteit van e-mail providers waarbij je dit soort zaken geregeld kunt krijgen.
80% van de mailboxen wordt beheerd door Google, Microsoft, Apple, of Yahoo. Met die vier ben je al een heel eind.

Maar als het inderdaad móet aankomen én meteen gelezen moet worden is mail niet het geschikte medium.
Ja, en dan ga je eigenlijk weer meer richting het idee dat je een account nodig hebt bij een grote cloud provider om mee te doen en goed geïnformeerd te blijven in de samenleving. Het zelfde als dat je tegenwoordig een Apple of Google account met toestel nodig hebt om bepaalde bank apps te gebruiken en de geplande NL Wallet.
Met email is dat dus juist niet zo. Iedereen kan zelf een server opzetten en naar wens dingen whitelisten of juist blokkeren. Ook als je het gewoon afneemt bij een kleinere provider (in belgie zelf) mag je verwachten dat die zoiets als dit nationale alarm white list.
Alle mailproviders, in binnen- en buitenland, op 1 lijn krijgen zodat ze allemaal rekening houden met zulke massale verzendingen van elke overheid die noodmails wil versturen is denk ik niet realistisch. Je kunt je focussen op de grote mailproviders, met name in eigen land, maar kunt het veel beter enkel zien als een extra kanaal om noodberichten te versturen naar sms, internet, radio en TV e.d.

[Reactie gewijzigd door jumbos7 op 21 juni 2026 15:09]

De afspraken die ooit zijn verzonnen om te bepalen hoe e-mail werkt, zijn al decennia niet meer bijgewerkt naar de dagelijkse realiteit van spam en phishing. Er zijn wel allerlei verbeteringen verzonnen, maar die zijn niet verplicht.

Behalve dat er geen garanties zijn over hoe lang het duurt voor een mailtje aankomt, zitten ook de gebruikers nou niet bepaald constant in de gaten te houden of er nog een mailtje binnenkomt. Daarvoor hebben we nou juist sms en allerlei chat-apps.

Daarnaast zou je verwachten dat bij échte noodsituaties zoals bij NL-Alert een cell broadcast afgaat, waar je niet op geabonneerd hoeft te zijn, want dan wil je gewoon iedereen bereiken. Aanvulling: BE-Alert laat je blijkbaar zelf kiezen via welk kanaal je berichten krijgt; per mail, sms en of spraak.

[Reactie gewijzigd door laptopleon op 21 juni 2026 16:13]

"Het is een geplande en doelbewuste mail". Het feit dat het een noodmail is, geeft aan dat het niet een geplande campagne is. Je wil toch niet afhankelijk zijn bij een noodbericht of er iemand bij de providers aanwezig is om zo'n mail te whitelisten.

Dit staat overigens los van het dat ik vind dat e-mail niet de meest geschikte methode is om zo'n bericht te versturen (en zeker niet als enige methode).
Noodberichten via e-mail? Wie heeft dat bedacht? Voor dit soort zaken zijn er cell broadcasts.
Die zijn niet voor storm waarschuwingen, tenzij die accuut levensbedreigend zijn

Zou je in geval van een gewone storm het luchtalarm laten afgaan om te waarschuwen? Dan moet t wel echt een wervelwind of verwoestende orkaan zijn.

[Reactie gewijzigd door fre0n op 21 juni 2026 12:02]

Cell broadcasts hebben diverse niveaus en op specniveau kun je alles behalve het hoogste niveau als het goed is uitzetten. EU-Alert level 4 is precies waar je dit sort dingen in verstuurt. Voorheen was dit EU Info, maar in versie 1.4.1 (de nieuwste die ik kan vinden) van ETSI TS 102 900 is dat hernoemd naar EU-Alert level 4.

Sommige telefoons behandelen alles van AMBER-alerts tot topwaarschuwing als één en hetzelfde, maar dat is een telefoonprobleem, niet een cell broadcastprobleem. In de instellingen van je telefoon kun je de niet-extreme meldingen uitzetten en de extreme meldingen gewoon ontvangen.
In Nederland worden cell broadcasts wel degelijk voor dit soort zaken gebruikt.
Precies en dat is nietnde bedoeling. Er zijn geen regels voor en veiligheidsregios krijgen er zelf de regie over


Hierdoor worden mensen midden in de nacht gewekt voor storm of gladheid en hebben veel mensen nl alert uitgeschakeld
Cell broadcasts ondersteunen meerdere prioriteitsniveau's. "Zeer heftige regenval, neem alleen contact op met hulpdiensten bij acuut levensbedreigende situaties" kan prima via één van de lagere niveau's verzonden worden - en krijgt dan ook niet de acute niet-weg-te-drukken toeters en bellen die nodig zijn voor een tsunamiwaarschuwing.
In Belgie hebben we niet eens een luchtalarm.
Wij binnenkort ook niet
Ik denk dat je het nieuws hebt gemist. Het luchtalarm blijft gewoon bestaan.
Dit hadden ze met een vooraf aangekondigd testbericht vantevoren ook al kunnen uitvogelen. Als overheidsorgaan een systeem gebruiken waarvan je niet eens weet of het werkt in een dergelijke noodsituatie is pure incompetentie.
Maar als men een test email krijgt wordt die vaak ook direct als spam gemarkeerd waardoor toekomstige emails ook gezien worden als spam.
Dan loop je alleen wel het risico dat die testmail ook als spam/phishing gemarkeerd wortdt en het adres op de blacklist komt. Dan komt je 'echte' mail ook meteen niet meer aan. Niet handig voor een alarm-mail zeg maar.
Als ze dit tijdig hadden getest, net zoals we in NL doen met het maandelijks testen van het alarm en elke 6 maanden een NL alert dan weet je waar de problemen zitten. Dan had je nog voldoende tijd om het op te lossen tot het moment dat het echt nodig is.

Dit is een beetje testen in productie, wat kan er mis gaan.
Dit is een beetje testen in productie, wat kan er mis gaan.
Is er bij dit soort zaken niet alleen 'productie'?

Je zou dan test en acceptatie omgevingen moeten maken waarin overheden en providers dit soort zaken kunnen testen.
Iedere systeembeheerder heeft een testomgeving.

Sommigen hebben het geluk dat ze ook een productieomgeving hebben
Even afgezonderd dat een systeem per email niet optimaal is.

Dit soort dingen als in (mogelijke) noodsituaties kunnen communiceren met je burgers, moet dat geen EU project zijn? Inclusief een EU budget. Volgens mij loopt elk land in Europa tegen vergelijkbare problemen aan. Zie ook in NL waar de discussie met name speelt over het aanblijven van de sirenes in noodsituaties.

Ik snap dat niet alle landen de zelfde problemen in omgeving hebben. In NL is alles plat versus Oostenrijk met bergen. Hoog 5g internet dekking versus laag. Etc etc. Dus de requirement zullen per land gefinetuned moeten worden. Maar volgens mij praten we hier over een algemeen probleem en lijkt mij perfect om samen vanuit de EU aan te pakken.

Als je dit samen aanpakt, dan deel je al waardvolle kennis uit. Eventueel kan je al praten over inbreng van technologie (al dan niet tegen een vergoeding). In mijn ogen precies waarvoor de EU-budgetten bedoeld zijn. Iets waar ieder land wat aan heeft.

Ik vind het het altijd nog moeilijk om te volgen wanneer geld naar welk land gaat in de EU. Ik zou veel meer vertrouwen hebben in een budget dat wordt gebruikt voor dit soort dingen. Dat sommige requirements dan iets meer kosten (hoog in de bergen een werkend systeem) so be it. Dus in mijn ogen, pakt dit samen op. Doe dit met EU budget en we worden er allemaal in Europa sterker van!
Dat is het ook, en dat is het al: het heet EU-Alert. België is alleen één van de weinige landen dat zo eigenwijs is om die standaard te negeren en te proberen het zelf maar via SMS en email te DIYen.
Dat had NL kunnen zijn. Meestal vindt men hier dat men het wiel opnieuw moet uitvinden, zie oa de OV-Chipkaart.
1 woord: redundacy.

Waarom niet gewoon en/en: Mail, whatsapp, sms (en voor mijn part rooksignalen) etc.
Er is redundancy. Je registreert je op be-alert met een e-mailadres, en kan daarnaast ook telefoonnummer(s) registreren waarop je sms wenst te ontvangen. ;)
Dat is dan beter geregeld dan ik dacht, hoewel er ook wat low/non tech opties zouden moeten zijn.

In Nederland wilden ze in eerste instantie het lucht alarm afschaffen.

Het werd als niet meer nodig beschouwd door de politiek omdat we nu ook NL-alert hebben.

Gelukkig is er veel backlash over geweest en het (luchtalarm) wordt nu gemoderniseerd.
Ik heb geen idee welke middelen er nog bestaan voor echte noodgevallen. Be-alert is slechts een (vrijwillig, vrijblijvend!) middel. O.a. geschikt ter verwittiging voor aankomende storm binnen een paar uur, zodat elk de nodige maatregelen kan nemen (binnen blijven, losse zaken vastmaken, openluchtevenement staken, etc.). Daar voor gaat men geen sirenes over heel het land laten loeien: de noodsituatie is er niet binnen 5 minuutjes. Voor chemische noodsituaties, bv. brand in nabijgelegen chemische industrie, bestaat er het zgn. Seveso-alarm, waarvoor be-alert slechts 1 van de communicatiekanalen is - politie in de straat is dan een ander: https://www.seveso.be/nl/wat-kan-jij-doen/meteen-verwittigd-schrijf-je-op-be-alert Hoe meer kanalen, hoe meer mensen je bereikt dan.

Wat de beschikbare maatregelen er allemaal zouden beschikbaar zijn bij een echte urgente noodsituatie, bv. een nucleaire noodsituatie, zou ik niet weten.
Onder redundantie verstaan we niet de mogelijkheid maar dat het daadwerkelijk in de praktijk redundant is. Zelfs al zou iedereen zich naast email voor sms hebben opgegeven dan werd die sms hier kennelijk niet ook gebruikt. Er werd niet aan redundantie gedaan terwijl de mails niet ooptijd bezorgd werden.
Ik ben misschien van een andere generatie, maar als je mensen direct nodig hebt of wilt waarschuwen dan gebruik je instant messaging. SMS, WhatsApp, etc...
Indien je een mail stuurt, moet je ervan uit gaan dat het als post behandeld wordt bij veel mensen. 1x per dag wordt in de box gekeken. Men kan er bij het crisiscentrum niet van uit gaat dat ieder een smartphone heeft. Laat het bij extreme hitte en onweer net ouderen zijn die hier het grootste gevaar lopen en laat deze mensen -als ze al een gsm hebben- meestal een dumb phone hebben.
Niet eens Whatsapp, Signal of Telegram - alleen SMS.

Als ik soms zie hoe groot de vertraging in WhatsApp is maar ook in chat apps zoals Discord en hoe afhankelijk aflevering is van bereik, verbinding, nestcongestie is de enige oplossing SMS.
SMS kan er ook dagen over doen zeg ik uit eigen ervaring uit een nieuwjaarsnacht waarbij het bericht pas na 10 dagen aankwam. Ontvanger: Huh, waar gaat dit over?

Cell broadcast is naast audio zoals een luchtalarm nog het meest betrouwbare middel omdat het provider/abonnement onafhankelijk alle binnen bereik zijnde apparaten kan bereiken. En anders politie/brandweer met hun omroepinstallaties laten rond gaan.
Het gaat over een waarschuwing voor felle storm in de komende uren. Niet over noodweer, niet over een stortvloed van 1953, niet over een nucleaire ramp, niet over een luchtaanval. Het moet wel in verhouding blijven. Voor een groot onweer binnen 3 uur ga je niet over heel het land 3 uur lang alle sirenes laten loeien zodat mensen. Een verwittiging via sms of mail volstaat ruim.
Voor een groot onweer binnen 3 uur ga je niet over heel het land 3 uur lang alle sirenes laten loeien
Dat is ook helemaal niet het idee. Een Cell Broadcast kan ook op niveau "EU-Info" verzonden worden, wat slechts een iets hoger niveau heeft dan reguliere SMS. En zo'n broadcast kan je op mastniveau verzenden, dus je kan het héél lokaal versturen, op X minuten voordat het noodweer op die locatie aankomt. Compleet niet te vergelijken met een landelijk sirene-alert, dus.
Ehhhm, sirenes die drie uur lang over het hele land loeien? Zelfs in 1953 zouden de sirenes op de Veluwe niet hebben geloeid.

Cell-broadcast kun je zoals ook @laurxp aangeeft vanaf zeer lokaal tot landelijk of daarboven inzetten, net als je dat met sirenes kunt. Overigens is cell-broadcast in mijn optiek een "mild" middel waar je wel meteen weet waarom je het bericht krijgt want dat staat in de omschrijving. Nadeel: Je moet een werkend apparaat en dekking in je buurt hebben om gewaarschuwd te worden.

Mijn voorkeur voor waarschuwingen/alarmeringen gaat nog steeds uit naar snoeiluide sirenes. Daar heb je alleen maar werkende oren bij nodig. Nee, je weet niet waarom ze loeien dat zul je actief moeten nazoeken (internet, telefoon, radio, TV) - of er moet iets in de toonhoogte en/of het patroon zitten, maar daar heb ik nog geen beschrijving van gezien. Maar sirenes is het middel met de meeste kans dat een waarschuwing/signaal overkomt.
SMS lijkt me ook niet zo handig. Ik heb de notificaties daarvan uit staan omdat ik nooit meer prive communicatie daarop krijg. Alleen maar heel veel spam (het meeste nog van mijn provider zelf) en achterhaalde 2FA systemen, waar ik geen notificatie voor nodig heb omdat ik het op dat moment zelf initieer.
Als je een goed geïsoleerd huis hebt en lekker binnen zit, dan heb je vaak geen mobiel netwerk. Je kan wel aan het internet via Wifi en kan bellen en gebeld worden via VoWifi, maar geen SMS ontvangen.
Dan wil je die noodmelding wel horen dat er uit een industrieterrein een chemische wolk over je huis gaat wegens een brand en je alle ramen en deuren moet sluiten en ventilatie moet uit zetten.

In tijden van nood, waar we spreken over de gezondheid en het welzijn van honderden tot mijloenen mensen, zal het mij een worst wezen welke kanalen de overheid gebruikt om mensen te waarschuwen en veilig te houden.

En ivm jouw bericht hieronder; als jij hebt doorgegeven wat jouw nummer is en dat je Whatsapp zou gebruiken, waar is dat een inbreuk op je privacy? En uit nieuwsgierigheid: wat vind jij het belangrijkste? Jouw privacy rond 1 bericht om je te waarschuwen voor iets, of het welzijn van alle andere inwoners die wel Whatsapp gebruiken?
Bor Coördinator Frontpage Admins / FP Powermod @Genosha21 juni 2026 11:48
Niet eens Whatsapp, Signal of Telegram - alleen SMS.
Is dat juist niet slim? Je bent dan niet afhankelijk van commerciële (en buitenlandse) partijen en vermindert daarmee de kwetsbaarheid rond verstoringen en in het extreemste geval opzettelijke frustratie van het systeem. Keep it simple. Elke telefoon kan tegenwoordig een SMS ontvangen en zo hoef je geen rekening te houden met wie welke instant messaging client op welk moment gebruikt.

[Reactie gewijzigd door Bor op 21 juni 2026 14:19]

Inderdaad. En als ik opeens een Whatsapp bericht krijg van de overheid vind ik dat toch wel een hele grote inbreuk van mijn privacy.
Hoe is dat opzich een 'hele grote inbreuk' tegenover een SMS?
Als iemand jou een sms stuurt dan komt niet direct jouw hele contact met mogelijk volledige naam, adres, e-mail, verjaardag, telefoonnummers, etc bij Mark Zuckerberg terecht (de meeste mensen zijn dom genoeg om whatsapp daar volledige toegang toe te geven)

[Reactie gewijzigd door chrome moral op 21 juni 2026 12:14]

Het gaat over een bericht ontvangen op WA, niet over je eigen registratie en data die je zelf deelt met Meta.

Het ontvangen van whatsapp berichten is niet een inbreuk op je privacy, zeker niet als je dat zelf zou kiezen als gewenste communicatie wijze.
Ze weten al lang wie je bent op basis van je telefoonnummer door de anti terreur wet. Die is er komen omdat bij de aanslag in Brussel wegwerp simkaarten werden gebruikt.
Op de pagina van be-alert op site van crisiscentrum:
"Thanks to BE-Alert, the authorities can send you a text message, e-mail or voice call"

De kritiek op email is terecht, maar niemand hier lijkt de moeite te nemen om eens te kijken of dat effectief de enigste optie is.

Mijn sms kwam alleszins tijdig toe...
Is dit echter het probleem? Dat de burger niet voor de beste optie kiest? Naar mijn mening moet je die keuze niet overlaten aan degene die er geen verstand van hebben (veel van de gebruikers). Wellicht moet je hier als overheid zeggen; Sorry, maar mail is niet goed genoeg. Dit is geen optie.

[Reactie gewijzigd door Lagonas op 21 juni 2026 11:52]

Sja, je moet kiezen, of je krijgt digitale privacy, en de overheid moet zich houden aan de wetgeving ivm persoonlijke data, of je krijgt een meer absolute overheid die zich er niets van aan trekt en gewoon jouw gegevens opvraagt en gebruikt indien nodig.

Geen enkele instantie mag in Belgie je email, telefoon of whatever gebruiken zonder je toestemming. Het hele be-alert moet je dus al zelf op inschrijven en is geen algemeen systeem, en velen kiezen hierbij om de overheid geen telefoonnummer te geven. Dan heb je nog 1 optie over. (wat onnozel is want de belastingdienst heeft die allicht al. Maar het crisiscentrum is de FOD financien niet).

Can't have your cake, and eat it too.

Wat zou jij dan voorstellen trouwens als communicatie manier?
Whatsapp of gelijk wat andere app? Welke app dekt jouw hele bevolking? Kan dat wel? Er zijn mensen zonder smartphone... Die wil je niet uitsluiten, zijn tenslotte ook deel van je bevolking. Of verdienen bejaarden en luddieten geen waarschuwing? :)

Edit: typo

[Reactie gewijzigd door IskaRiot op 21 juni 2026 12:15]

Ik keek even op de site, en wat je moet doen om een noodmelding te ontvangen.
Wat een idioot omslachtig systeem. Je moet een heel account aanmaken met mailadres, volledige naam, Wachtwoord, telefoonnummer, Hoofdwoonplaats etc.
Wordt je dan alleen gealarmeerd als er iets in je woonplaats gebeurt? Slim hoor, woon je in Leuven, ben je in Brussel, gaat daar wat mis, krijg je geen SMS. Welke dodo heeft dit systeem bedacht?
Wanneer er gewoon met cellbroadcasting wordt gewerkt heb je dit probleem helemaal niet. Je bereikt precies de mensen in het bron- en effectgebied.

[Reactie gewijzigd door William_H op 24 juni 2026 22:58]

Het zou anders wel mooi zijn als we maatschappelijk appen etc. meer gaan behandelen net als mail. Maatschappelijk zijn de verwachtingen dusdanig dat de verzender in principe tijd eist van ontvanger, voldoe je niet aan die verwachting wordt het al snel als negatief ervaren.
Het zou mooi zijn moesten IM's standaard geen notificaties geven, tenzij bij mensen die jij als ontvanger aangeeft.
Ik denk wel dat een verzender een "urgent" optie moet hebben zodat er wél een notificatie af gaat. Een optie die je bij misbruik voor die gebruiker kan af zetten, beperken in frequentie of -als genoeg mensen klagen, de persoon tijdelijk blacklisten voor "urgent"-gebruik.

IM's zijn naar mijn mening nog gebouwd op de ICQ mentaliteit. "Achter een computer, niet steeds verbonden".
Het feit dat je zelf moet inschrijven op dergelijke systemen, is inefficiënt. Hoeveel kans bestaat er dat de NL vakantieganger of buitenlandse trucker is ingeschreven op een alert dat niet in zijn land is ? Dan zou iedereen zich in alle landen moeten registreren waar hij komt. De enige goede oplossing is cell-broadcast. Zou bereik je iedereen binnen het crisis gebied. Het heeft ook geen zin om mensen in Groningen te verwittigen om ramen en deuren te sluiten bij een grote brand in Limburg, dus stuur je SMS broadcast aan iedereen die binnen bereik van zendmasten xyz bevind.
Eens, er is niet 1 oplossing die voor elk type persoon in dat gebied zal werken.
Zoals je terecht aangeeft, zijn er ook toeristen. Dan moet je je ook de vraag stellen: spreken die toeristen de taal? Ga je bij buitenlandse kaarten naar Engels? Spreken ze wel Engels?

Een algemene SBS Broadcast is "level 1"
Inschrijven voor berichtgeving voor bepaalde gebieden is "level 2". Je wilt misschien ook wel alerts krijgen van waar je zoon of dochter woont, of je ouders, of waar de school van je kinderen is?

Voor level 2 kan je dan kiezen tussen verschillende media.

Lvl 3 zou bvb notificatie via overheids-apps zijn. of apps van publiek nut (app publiek transport oid)
Bor Coördinator Frontpage Admins / FP Powermod 21 juni 2026 11:35
E-mail is helemaal niet geschikt voor het afleveren van kritische berichten. Je hebt geen enkele garantie dat mail wordt afgeleverd. Er zijn simpelweg te veel variabelen waardoor aflevering kan worden verstoord. Ook krijgt je als verzender niet gegarandeerd een ontvangst bevestiging. E-mail werkt op basis van best effort, niet meer en niet minder. Voor kritische berichten heb je een ander systeem nodig.
Ik vind het meer schokkend dat naar socials verwezen wordt! Ik gebruik geen socials en weiger dat ook.
Bor Coördinator Frontpage Admins / FP Powermod @Zebby21 juni 2026 12:25
Dan kies je toch gewoon voor bijvoorbeeld sms notificatie? Die keuze heb je gewoon zo te zien. Notificatie via socials wordt niet als optie genoemd (en lijkt mij ook niet geschikt).
"Thanks to BE-Alert, the authorities can send you a text message, e-mail or voice call"

[Reactie gewijzigd door Bor op 21 juni 2026 12:26]

De opmerking was niet dat social media wel een verstandige manier is terwijl email het niet is.
Dat is in NL ook wel zo soms, ook de activiteit van lui alleen daar. "Officiele" communicatie van de overheid via social media. Ik heb in de basis niks tegen social media maar dat de rijksoverheid (en ook lokale overheden) dat als suggestie geven voor nieuwsbron vind ik kansloos.

Wordt toch tijd voor een gov.nl/actueel en gov.be om de basics te hebben.

Versnippering tegen gaan.
Waar wordt er verwezen naar socials? Ik heb de mail bekeken en zie nergens een link naar socials staan?
Dit artikel legt de schuld wel erg bij de honderden mailproviders. Het is algemeen bekend dat wanneer je in een keer 100.000 e-mails verstuurt, spamfilters daar kritisch naar kijken en berichten kunnen blokkeren of als spam markeren. De markering als spam is niet onterecht. De spamfilters doen exact waar ze voor gemaakt zijn.

Is dit vooraf niet getest? Ik vraag me af waarom de ontwikkelaars achter BE-Alert hier vooraf geen rekening mee hebben gehouden en waarom dit dan uberhaupt een optie is geworden.

[Reactie gewijzigd door jordynegen11 op 21 juni 2026 11:39]

Feitelijk valt deze mailbom technisch inderdaad precies binnen de omschrijving van spam. Echter krijgen wij in Nederland in principe ook geen KNMI meldingen via NL alert, daar hebben ze wel een eigen app voor.
De KNMI-meldingen zijn in de meeste gevallen dan ook niet NL-Alert waardig. Pas bij Code Rood moet je écht actie ondernemen en is het iets dat je moet weten, Geel en Oranje is meer iets waar je naar kijkt als je van plan bent om de hele dag buiten te zijn.
In principe kunnen de lagere prioriteiten van EU-Alert prima weerwaarschuwingen bevatten. Dat zou wellicht de stormschade hebben kunnen beperken toen de KNMI plots van code geel naar code oranje ging afgelopen vrijdag.

Level 4 kan voor dingen als "je moet drinkwater koken als je verzwakt bent", een plotselinge onweersbui is van datzelfde of zelfs een hoger kaliber. De onnegeerbare level-1 alerts moet je wel beperkt inzetten natuurlijk, maar ik geloof niet dat die tot nu toe zijn ingezet in Nederland.
Bijna alle alerts die ik via NL-Alert binnen krijg zijn anders veredelde weerberichten.
Ja hoor. Het systeem is al langer succesvol in gebruik. En ook testberichten werden de voorbije jaren gestuurd. Het systeem werkte ook nu voor velen hoor. Sowieso werkt sms. Enkel bleek ditmaal een aantal e-mailproviders wat te ijverig met vertraging inbouwen.

Om te kunnen reageren moet je ingelogd zijn