E-mail-spoofing was mogelijk bij domein Testen voor Toegang

Testen voor Toegang, het platform van de Stichting Open Nederland dat in opdracht van Het Rijk coronatesten faciliteert voor evenementen waarbij test- of vaccinatiebewijzen verplicht zijn, had zijn e-mailinstellingen niet op orde, Daardoor was spoofing van het afzenderadres mogelijk.

Het Financieele Dagblad schrijft dat Testen voor Toegang zijn Sender Policy Framework Record niet had ingesteld; dat is een authenticatiemethode die ontworpen is om het vervalsen van het afzenderadres te voorkomen. Het lukte de krant, in samenwerking met securitybedrijf KnowBe4, om een e-mail naar zichzelf te versturen met als afzender [e-mail].

Iedere e-mailserver was onder deze instellingen bevoegd om e-mails te sturen vanaf het domein testenvoortoegang.org. Dat maakt het makkelijker voor criminelen om zich voor te doen als werkelijke eigenaren van het domein en via een vervalste e-mail geld of informatie te ontfutselen bij nietsvermoedende gebruikers.

De website is sinds twee weken actief. Het lek is nu naar alle waarschijnlijkheid gedicht, hoewel het FD dat niet uitdrukkelijk zegt. Wat het wel zegt is dat de stichting het lek 'moet dichten' en dat de e-mailbeveiliging 'niet op orde was', wat impliceert dat het lek inmiddels inderdaad gedicht is.

De Nederlandse Vereniging van Banken meldde vorige maand nog dat phishing en telefoonnummerspoofing in het betalingsverkeer in 2020 sterk toenamen. De schade door phishing steeg met ruim zestig procent tot 12,8 miljoen euro. Nummerspoofing zorgde voor ruim twee keer zoveel schade.

Reacties (138)

[CAPSLOCK2000]

Wat is het toch allemaal een drama. Ik heb een lichte hekel aan SPF/DKIM/DMARC/ARC/SRS/SMTP-STS en de meeste andere moderne e-mail standaarden. Het zijn allemaal gebrekkige lapmiddelen die conceptueel in de jaren 80 thuis horen en niet in overeenstemming zijn met moderne inzichten en niet meer dan piepkleine stapjes vooruit zijn.

Het moderne inzicht is End-to-End Encryptie. Dat is wat je wil, al het andere is niet genoeg. Sommige middelen zijn een goede aanvulling, zoals TLS, maar geen van allen kunnen ze e2e-encryptie vervangen.

We hebben verschillende standaarden voor e2e-enryptie voor e-mail zoals PGP en S/MIME die technisch gezien prima werken en met een klein beetje moeite breed inzetbaar zijn. Als ik heel eerlijk ben zijn die standaarden inmiddels wel erg oud aan het worden en beginnen ze gebreken te vertonen, maar ook met ouderdomskwaaltjes zijn ze veruit superieur aan SPF/DKIM/DMARC/etc.... Er wordt wel eens gezegd dat het te moeilijk is maar ik garandeer dat het makkelijker is dan de hele SPF/DKIM/DMARC/SMTP-STS/DANE/DNSSEC/ARC/SRS boom op te tuigen die je tegenwoordig geacht wordt te hebben.

Het is een beetje een kip/ei probleem. Mensen gebruiken het niet omdat anderen het niet gebruiken. De techniek ontwikkelt zich niet verder omdat het niet gebruikt wordt.
Persoonlijk vind ik dat Microsoft en Google de bal hebben laten vallen. Die twee partijen hebben samen een enorm stuk van de e-mail-markt in handen, maar ik zie eigenlijk geen pogingen om e2e-encryptie in te voeren. Zolang Outlook/Exchange en GMail niet actief promoten dat je iets met e2e-beveiliging voor e-mail moet doen gaat het er ook niet komen. (Ze kunnen het wel, tot op zekere hoogte, het krijgt alleen geen aandacht).

Ik pleit altijd voor 'beveiliging in lagen' dus ergens is het prima om SPF/DKIM/etc ook te hebben naast e2e-encryptie maar we moeten het niet omdraaien. Veel lagen hebben maakt het nog niet automatisch tot een goede beveiliging.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 21:51]

[flubbr]

Eens, PGP zou meer aandacht moeten krijgen.

Middelen voor goede authenticatie bestaan al decennia maar steeds probeert men nieuwe fratsen te bedenken.

Zou heel wat fijner werken als ik elders accounts kan maken op basis van public-key authenticatie.
In plaats van autorisatie aan de andere partij over te laten en hen mijn credentials te laten bewaren.

Maar is kip of ei verhaal; er werd mij gevraagd hoe iemand versleutelde mail kon versturen.
Koste flink wat inspanning om uit te leggen dat je prima mail kan versleutelen, maar hoe kan de geaddresseerde het dan ontcijferen? Die andere partij moet meewerken en jou van een sleutel voorzien.
Ze hadden een slimmere oplossing; gewoon "het wachtwoord' in een andere mail sturen.

De kloof is simpelweg te groot en wordt met de dag groter doordat alles maar aangepast moet worden op een steeds groter wordende, steeds minder kundige groep mensen.

Zagen we paar jaar terug al, bij reclames over dat je moest letten op het slotje in de adresbalk.
Want als dat slotje groen was, dan zat alles goed. Was toen niet waar, is nu nog steeds niet waar.
Maar mensen slikken dat voor zoete koek. Dat krijg je niet opgelost met techniek.

[CAPSLOCK2000]

Maar is kip of ei verhaal; er werd mij gevraagd hoe iemand versleutelde mail kon versturen.
Koste flink wat inspanning om uit te leggen dat je prima mail kan versleutelen, maar hoe kan de geaddresseerde het dan ontcijferen? Die andere partij moet meewerken en jou van een sleutel voorzien.

Kijk eens naar https://keybase.io/, dat heeft een paar prachtige oplossingen voor het sleutelprobleem. Zonder op de techniek in te gaan komt het er op neer dat je berichten kan sturen naar personen en dat keybase op de achtergrond voor de juiste keys zorgt op een manier die ook werkt als de ontvanger zelf nog geen sleutel heeft. Je kan bijvoorbeeld een berichtje sturen aan een bepaalde Twitter-handle. Als die persoon dat bericht wil lezen dan kan die z'n Twitter-handle registeren bij keybase en krijgt dan toegang tot de versleutelde berichten.

Bovenstaande uitleg gaat wat kort door de bocht dus reken het verhaal aub niet af op gebreken die je denkt te zien.

Want als dat slotje groen was, dan zat alles goed. Was toen niet waar, is nu nog steeds niet waar.

Dat klopt en toch was het nuttig. Hoewel de meeste mensen het niet echt goed begrijpen heeft dat slotje wel geholpen met SSL/HTTPS normaal te maken. Mensen leggen 'groen' verkeerd uit, maar 'rood' gaat over het algemeen wel goed. Dat slotje heeft geholpen om de hoeveelheid 'rood' te verkleinen tot het punt dat we er nu wel van uit mogen gaan dat iedere website op internet gebruik maakt van HTTPS.

[flubbr]

En op zijn beurt betekent HTTPS dat verkeer tussen jou en webserver versleutelt is.

Dus https://pincodeverificatie.rabobonk-telebankieren.nl/actie
Werkt prima, is groen en data tussen jou en webserver wordt versleutelt.
Dit weet je.

Versleutelen van verkeer is goed, begrijp me niet verkeerd.
Thanks voor de link naar keybase, maar heb liever je pub-key zonder franje en nog meer externe afhankelijkheden.

[CAPSLOCK2000]

Versleutelen van verkeer is goed, begrijp me niet verkeerd.
Thanks voor de link naar keybase, maar heb liever je pub-key zonder franje en nog meer externe afhankelijkheden.

Ik ook, maar in praktijk is dat helaas best lastig. De die-hard techneuten vinden wel een manier om sleutels veilig uit te wisselen, maar 99% van de bevolking komt daar nooit uit. Ik zie Keybase als een aanvulling op PGP, niet als vervanger.
Een secundaire functie van Keybase die ik ook wel tof vind is het koppelen van identiteiten. Zodat je kan controleren of CAPSLOCK200@tweakers dezelfde persoon is als CAPSLOCK2000@twitter, of niet.

Vroeger hadden we keyservers om elkaars sleutels op te zoeken maar die zijn tegenwoordig steeds minder bruikbaar.
Een andere aardige oplossing is het publiceren van je PGP-sleutels/identiteit via DNS.,

[mrdemc]

Daarnaast werkt het ook met de .well-known map: https://wiki.gnupg.org/WKD

Web Key Directories provide an easy way to discover public keys through HTTPS. They provide an important piece to the infrastructure to improve the user experience for exchanging secure emails and files.

A Web Key Directory keeps email addresses private (as you need to know an address already to ask for a public key). And it is an authoritative source for a public key for its domain.

How does it work?
The sender's mail client checks a "well known" URL on the domain of the recipient.
If a public key is available for that mail address, will be downloaded via HTTPS.
The downloaded pubkey can now be used without further user interaction.
Such an URL looks like:
<domain>/.well-known/openpgpkey/hu/g8td9rsyatrazsoiho37j9n3g5ypp34h for the mail address "aheinecke@<domain>"

Maar key-servers hebben we nog steeds, en zijn zover ik weet ook nog prima bruikbaar, zoals deze bijv. https://keyserver.ubuntu.com/

[Reactie gewijzigd door mrdemc op 23 juli 2024 21:51]

[CAPSLOCK2000]

Maar key-servers hebben we nog steeds, en zijn zover ik weet ook nog prima bruikbaar, zoals deze bijv. https://keyserver.ubuntu.com/

Ze zijn er wel maar het hele systeem hapert aan alle kanten. De software die er achter zit is pijnlijk verouderd en de pogingen om het te moderniseren zijn opgegeven. Eigenlijk moeten al die keyservers met elkaar in verbinding staan zodat alle informatie overal beschikbaar is. Dat werkt steeds minder goed. Er zijn nog wat eilandjes maar die worden steeds kleiner.
Zo is de identiteit die ik op mijn werk gebruik niet te vinden op de keyserver van Ubuntu maar wel op een andere bekende keyserver.

Daar komt bij dat die keyservers eigenlijk helemaal niet veilig zijn en niet erg privacy vriendelijk. De meeste mensen (inclusief ikzelf) zijn blij als zo'n keyserver een sleutel heeft voor je contact en doen dan eigenlijk geen moeite om te controleren of die sleutel wel echt de juiste is.

[Darkstriker]

Maar juist die harde controle ontbreekt toch bij praktisch alle diensten tegenwoordig. Ja, je kunt de identiteit van je WA/Signal contacten verifieeren als je naast elkaar zit, maar wie doet dat? Uitdeinlijk is het allemaal niet beter dan autocrypt, tenzijn mensen die extra stap doen en daar is nagenoeg nooit sprake van. Bovendien veranderen die sleutens nog wel eens en dan zou je dus weer moeten checken. En die messengers zijn net als keybase.io en dergelijk toch weer afhankelijk van een centraal punt.

[Reactie gewijzigd door Darkstriker op 23 juli 2024 21:51]

[mrdemc]

Ah, op die manier. Dat ben ik inderdaad met je eens. De WKD methode is daarvoor een mooie vervanging, mits het wat eenvoudiger bij te houden zal zijn.

[flubbr]

De die-hard techneuten vinden wel een manier om sleutels veilig uit te wisselen,

E-mail, chat, op een openbaar forum posten.
Hele wereld mag je pub key weten.

Heb je ook geen extra junk nodig zoals Twitter (waar je dan bv ook weer een e-mail account en mobiel telefoonnummer voor nodig hebt om daar een account te maken)

Als Twitter mij nu een account liet maken door ze van public key te voorzien, dan hou ik tenminste de sleutel nog in eigen handen.

[CAPSLOCK2000]

E-mail, chat, op een openbaar forum posten.
Hele wereld mag je pub key weten.

De vraag is hoe ik zeker weet dat ik de juiste key ontvang. Als die pubkey via onversleutelde mail verstuurd is dan kan ik die niet vertrouwen. En bij een forum op internet moet ik maar geloven de dat beheerder van het forum de key niet heeft vervangen door z'n eigen pubkey.
Op grond van het "web of trust" van PGP kom je nog wel een eind maar alleen voor mensen die goed in het netwerk zijn ingebed. Maar als ik met een willekeurige vreemde wil communiceren (ambtenaar X van de gemeente Kleingatterdam) voldoet dat in praktijk niet.

Een interessante optie is de chip in ons paspoort. Op ieder paspoort staat een persoonlijk SSL-certificaat dat we met weinig moeite zouden kunnen inzetten voor persoonlijke encryptie en communicatie. Er zitten natuurlijk ook wat conceptuele nadelen aan encryptie die wordt beheerd door de overheid, maar ik denk dat het z'n plek heeft en dat we daarmee grote stappen vooruit kunenn nemen.

In de meeste gevallen hoef ik overigens niet per se je "echte" identiteit te weten (zeg maar de naam die in je paspoort staat). In de meeste gevallen is het voor mij genoeg om te weten dat ik met dezelfde persoon communiceer als de vorige keer. Dat heeft voor- en nadelen bij het controleren van zo'n identiteit.

Heb je ook geen extra junk nodig zoals Twitter (waar je dan bv ook weer een e-mail account en mobiel telefoonnummer voor nodig hebt om daar een account te maken)

Volgens mij snap je keybase nog niet helemaal. Je hebt geen Twitter nodig om daar gebruik van te maken. Maar als je dan toch Twitter gebruikt dan kun je Keybase gebruiken om veilig te communiceren op grond van je Twitter handle. Maar je hoeft zelf niet eens Twitter te gebruiken. Toch kan je veilig berichten sturen naar mensen die wél Twitter gebruiken. En andersom. Zo hoef ik niet op Twitter.
En Twitter is maar een voorbeeld. Het kan ook met Matrix/Signal/WhatsApp/GMail/IRC en ieder ander communicatiesysteem waar je een identiteit hebt.

Als Twitter mij nu een account liet maken door ze van public key te voorzien, dan hou ik tenminste de sleutel nog in eigen handen.

Ik hoop dat we die kant op gaan. Moderne authenticatieprotocollen zoals webauthn en fido2 hebben dat in ieder geval binnen handbereik gebracht.

[Darkstriker]

Een interessante optie is de chip in ons paspoort. Op ieder paspoort staat een persoonlijk SSL-certificaat dat we met weinig moeite zouden kunnen inzetten voor persoonlijke encryptie en communicatie. Er zitten natuurlijk ook wat conceptuele nadelen aan encryptie die wordt beheerd door de overheid, maar ik denk dat het z'n plek heeft en dat we daarmee grote stappen vooruit kunenn nemen.

Laat nou net de overheid de ene partij zijn die in het verleden bij dit soort vertrouwenskwesties juist niet betrouwbaar was. Zij kunnen je ook een andere pubkey geven. Terwijl kriminelen alleen voor high-value-targets echt iets als een MITM opzetten en het voor normale mensen gewoon laten bij simpel spoofen van een naam of een domein. Juist de overheid zou ik deze verantwoordelijkheid niet willen geven.

[CAPSLOCK2000]

Laat nou net de overheid de ene partij zijn die in het verleden bij dit soort vertrouwenskwesties juist niet betrouwbaar was. Zij kunnen je ook een andere pubkey geven. Terwijl kriminelen alleen voor high-value-targets echt iets als een MITM opzetten en het voor normale mensen gewoon laten bij simpel spoofen van een naam of een domein. Juist de overheid zou ik deze verantwoordelijkheid niet willen geven.

Het is maar wat je doel is he. En of je het nu leuk vind of niet, zolang je in Nederland woont ben je afhankelijk van die overheid. En hoewel de overheid als beheerder van de paspoorten wel enige ruimte tot manipulatie heeft kunnen ze de wetten van de wiskunde niet veranderen. Zolang we maar weten wat de beperkingen van het systeem zijn hoeft het geen nadeel te zijn dat de overheid het beheert.

[GekkePrutser]

[...]Een interessante optie is de chip in ons paspoort. Op ieder paspoort staat een persoonlijk SSL-certificaat dat we met weinig moeite zouden kunnen inzetten voor persoonlijke encryptie en communicatie. Er zitten natuurlijk ook wat conceptuele nadelen aan encryptie die wordt beheerd door de overheid, maar ik denk dat het z'n plek heeft en dat we daarmee grote stappen vooruit kunenn nemen.

Absoluut niet alsjeblieft Het idee is juist dat ik helemaal niet wil koppelen aan mijn identiteit voor 90% van wat ik op internet doe. Het punt is door dit mogelijk te maken, verlaag je de drempel voor sites om je echte identiteit te vragen. Daardoor krijg je een spiraal waarbij je je steeds meer moet identificeren. Daarom ben ik ook tegen apps als IRMA, ondanks dat die dat op een veilige manier doen, ik wil gewoon helemaal niet dat sites dit makkelijk kunnen eisen Een hoge drempel vind ik fijn want dan wordt het niet te pas en te onpas gevraagd.

En die wens is er zeker wel, zie bijvoorbeeld The Post Online die een tijd alleen comments toestond via facebook zodat ze de echte identiteit wisten en spam minder voorkwam.

In de meeste gevallen hoef ik overigens niet per se je "echte" identiteit te weten (zeg maar de naam die in je paspoort staat). In de meeste gevallen is het voor mij genoeg om te weten dat ik met dezelfde persoon communiceer als de vorige keer. Dat heeft voor- en nadelen bij het controleren van zo'n identiteit.

Precies Dat dus. Maar zelfs als je dit eruit filtert ofzo, heb je toch altijd een koppeling met je echte identiteit. Toch weer een zwakte die er helemaal niet hoeft te zijn.

Gebruik dan liever een Fido2 token ofzo, zoals je zelf ook noemt. Kan je ook in software doen indien nodig, en je kan er meerdere kopen die niet noodzakelijk gekoppeld zijn aan je identiteit.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 21:51]

[CAPSLOCK2000]

Absoluut niet alsjeblieft Het idee is juist dat ik helemaal niet wil koppelen aan mijn identiteit voor 90% van wat ik op internet doe. Het punt is door dit mogelijk te maken, verlaag je de drempel voor sites om je echte identiteit te vragen. Daardoor krijg je een spiraal waarbij je je steeds meer moet identificeren. Daarom ben ik ook tegen apps als IRMA, ondanks dat die dat op een veilige manier doen, ik wil gewoon helemaal niet dat sites dit makkelijk kunnen eisen Een hoge drempel vind ik fijn want dan wordt het niet te pas en te onpas gevraagd.

Ik ben het eens met je zorgen. Ik wil ook niet dat iedere site mijn identiteit kent. Dat neemt niet weg dat er situaties zijn waarin ik denk dat het z'n plek heeft, bijvoorbeeld bij het betalen van belasting of andere zaken waar je Digid voor gebuikt. Daar vind ik een koppeling met mijn echte identiteit juist een noodzakelijke feature. Het systeem waarbij je Digid beschermd is met een SMS-code is ook niet ideaal.

[Darkstriker]

Absoluut niet alsjeblieft Het idee is juist dat ik helemaal niet wil koppelen aan mijn identiteit voor 90% van wat ik op internet doe. Het punt is door dit mogelijk te maken, verlaag je de drempel voor sites om je echte identiteit te vragen. Daardoor krijg je een spiraal waarbij je je steeds meer moet identificeren. Daarom ben ik ook tegen apps als IRMA, ondanks dat die dat op een veilige manier doen, ik wil gewoon helemaal niet dat sites dit makkelijk kunnen eisen Een hoge drempel vind ik fijn want dan wordt het niet te pas en te onpas gevraagd.

Ja, anonymiteit heeft iets, maar ik denk toch ook dat iets minder anonymiteit onze samenleving (globaal) veel goeds zou kunnen doen. Veel van de grote nadelen die zich in de laatste pakweg 10 jaar uit het internet hebben ontwikkelt zijn in grote omvang te schulden aan het gedrag dat mensen vertonen als ze (denken dat ze) anonym zijn. Van haatzaaien tot misinformatie, van het ontkennen van de menselijkheid van de ander en de respecteloosheid, veel van deze verschijnselen worden enorm versterkt en in sommige gevallen pas mogelijk als mensen anonym zijn. Dat je jezelf een beetje zou beteugelen op random internetfora zou de wereld een hoop goeds kunnen doen.

[GekkePrutser]

Ik denk dat je hier het belang van random internetfora een beetje overschat eigenlijk. En de groten zijn allemaal allang gemodereerd. Als je ziet wat er allemaal op facebook gepost wordt, heeft het gebruiken van de echte identiteit ook niet echt een afschrikkende werking.

Maar als een forum echte namen gaat vereisen dan doe ik gewoon niet meer mee. Niet omdat ik mensen uit wil schelden maar omdat ik dat gewoon niet wil. En dan zal ik me verplaatsen naar kleinere fora of andere niche omgevingen.

Het probleem met de invloed van 'het internet' op de samenleving ligt hem niet zozeer in de anonimiteit. Het probleem is dat grote belangen het gebruiken om onze meningen te beinvloeden door middel van bubbels en big data analyse ("wat gaat er goed vallen als je het roept"). De hele polarisatie die je ziet is juist heel erg gewenst door deze groepen. Het is een middel voor ze om een wig te drijven in de samenleving en hun zin door te drukken. Zie ook hoe bijvoorbeeld Brexit en Trump tot stand zijn gekomen. Zoveel tegenstellingen, zoveel valse informatie, zoveel loos gebrul. Dit is geen organische ontwikkeling geweest maar gewoon keihard aangestuurd. Wat je ook ziet is dat juist politici en instanties gewoon overduidelijk keihard liegen en ermee wegkomen. Trump is een goed voorbeeld, de "Brexit bus", zoveel harde beloften werden naderhand gewoon weggelachen. Cambridge Analytica lichtte een tipje van de sluier hierover op maar ik weet zeker dat dat het topje van de ijsberg is. Niettemin hebben dit soort belangen wel veel belang bij echte identiteiten want het maakt mensen meer beinvloedbaar.

Sowieso is die verhuizing allang aan de gang. Ik doe helemaal niets meer met Facebook, Twitter, Google enz. Zelfs reddit is me nu te mainstream aan het worden. Ik gebruik daar alleen nog maar weggooi accounts.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 21:51]

[Eonfge]

Persoonlijk vind ik dat Microsoft en Google de bal hebben laten vallen.

Het probleem met die twee partijen, is dat ze graag een alternatief voor email introduceren maar alleen als ze daarmee de hele markt kunnen inpalmen. Technische lui bij Microsoft en Google zouden vast een decentraal, gefederaliseerd, systeem willen omarmen maar zodra sales en marketing aanschuiven, gaat het plan de bietenberg op. Daarom ook dat Google al meerdere chat systemen heeft geintroduceert, welke allemaal daarna ten dode waren opgeschreven.

Er komt geen alternatief op email uit de hoek van koker van een commerciële partij, simpelweg omdat het ontwerp van email niet te verenigen is met commerciële interesses. Misschien dat Matrix voet aan de grond kan krijgen dankzij Corona en de GPDR, maar anders blijven we gewoon bij email.

[Jay-v]

De website is sinds twee weken actief. Het lek is nu naar alle waarschijnlijkheid gedicht, hoewel het FD dat niet uitdrukkelijk zegt.

Ja, dat is gedicht:

dig +short TXT testenvoortoegang.org
"v=spf1 include:_spf.zivver.com include:spf.flowmailer.net include:u21679679.wl180.sendgrid.net ~all"
"D+g6PQCH7MSA/XwS+AD2m+G6PDFocdu8TAbiW7N4lDc="

[themuk128]

Echt, ik snap niet dat mensen nog in zee gaan met flowmailer en sendgrid. Onze organisatie 70000+ werknemers hebben zoveel last van malifide partijen welke deze partijen gebruiken om e-mails (legaal) te versturen!! Wij laten alleen nog organisaties toe welke een dedicated IP gebruiken van deze partijen icm met SPF, DKIM en Dmarc. Anders is het een NO go bij ons. Zelfs dan krijgen wij over Cisco Ironport nog genoeg rommel binnen!!

[OkselFris]

Je kan Sendgrid als bedrijf zelf wel prima gebruiken, zolang je SPF, DKIM en DMARC voor je domains en dus incl.sendgrid op orde hebt. Sendgrid ondersteunt gewoon DKIM.

Maar inderdaad heeft Sendgrid geen geweldige reputatie, en het wordt nog steeds regelmatig gebruikt voor phishing. Reden was het ontbreken van 2FA of het afdwingen daarvan, daardoor zijn veel accounts misbruikt. volgens mij wordt tegenwoordig 2FA standaard aangeboden, maar dwingen ze het nog steeds niet af voor bestaande accounts. ze hebben wat at betreft een discutabele reputatie.
Semndgrid staat bij ons ook hoog op de lijst als veelal verdacht en ik heb regelmatig de URL's naar het domein moeten blokkeren vanwege weer een storm van phishing mailtjes incl malafide links.

[Verwijderd]

Je argument slaat nergens op. Omdat kwaadwillenden een dienst gebruiken, zou niemand dat meer moeten doen. Wil je dan ook even telefonie en laptops toevoegen aan je rant? Worden ook heel veel stoute dingen mee gedaan.

[TheVivaldi]

Inderdaad. Dan zou niemand meer in zee mogen gaan met bijv. Microsoft omdat er heel wat neptelefoontjes van Microsoft voorbijkomen……

[Verwijderd]

Dan mag niemand zaken meer doen met alle Nederlanders, want er zitten moordenaars en dieven tussen.

[themuk128]

Die komen niet van MS. Zijn soms gespoofd maar de spam/malifide e-mails wel van flowmailer/sendgrid ip’s met een dynamische fqdn en geldige spf/DKIM/dmarc en daar mag deze partij wel wat beter op letten!!

[TheVivaldi]

Die komen niet van MS.

Klopt, maar dat was het punt niet. Lees even terug.

[themuk128]

Ik bedoel mensen kopen een account bij flowmailer en sendgrid en betalen dus hiervoor. Dan gaat men mass mails versturen met malifide content. Dit zou men bij hun al beter moeten checken en de accounts disablen/bannen. En juist dit gebeurd niet!! En ja ik ken heel veel grote bedrijven met hetzelfde soort probleem!
Dus ik snap je reactie niet zo goed dat je zegt dat dit nergens op slaat.

[GertMenkel]

Luiheid en/of gemak. Mail van sendgrid komt sneller aan bij spamfilters als die van MS en Google dan die van je eigen mailservers, de API scheelt je zelf een hoop onderhoud en je hoeft geen domeinkennis over emails te hebben.

De meeste mensen ontvangen geen mail via Ironports, die krijgen een bericht in Gmail en Outlook. Als het daar aankomt, is de overheid blij. Ja, Sendgrid stuurt ook een lading spam, maar die spam verschijnt bij het gros van de mensen wel in hun inbox, en dat is waar het om draait.

[SubSpace]

Waarom zou mail van eigen servers in de spam komen? Dat is echt onzin.

In mijn ervaring komt legitieme Sendgrid mail juist vaak in spam folders terecht. Zo vaak, dat ik het liever niet gebruik.

[GertMenkel]

Ik host mijn eigen mail en ik kan je vertellen dat ondanks DKIM, DMARC, SPF en een relatief gezonde IP-score je alsnog gewoon bij Gmail en Outlook in de spammap landt. Als iemand mij mailt en ik antwoord komt de mail wel altijd aan, als ik een mail stuur en die persoon antwoordt daarop dan is voor die persoon mijn mailadres de komende tijd ook weer buiten de spamlijst, maar wee o wee als ik een ander Gmail-adres probeer te mailen.

Het probleem zit niet alleen in Gmail, het komt ook voor bij hosted domeinen. Van Google weet ik dat ik in de spammap beland (want die stuurt mij updates n.a.v. DMARC), bij Outlook ga ik er maar van uit dat ik in de spammap sta als ik daar een mail naartoe stuur want ondanks alle verzoeken is het onmogelijk daar mail aan te laten komen.

Wat er ook voor automagisch spamdetectiealgoritme speelt, Google en Microsoft sturen enorm veel naar de spam. Ook bedrijven die redelijke volumes sturen en hun zaken op orde hebben qua SPF/DKIM/DMARC/PTR/etc. (de automatische mails van mijn huisarts, bijvoorbeeld, die je wel online móet plannen) komen in de spammap terecht.

Het algoritme van Google vangt wel veel spam, maar het lijkt meer te focussen op true positives dan dat het een lage hoeveelheid false positives wil zien.

Wellicht dat het voor de overheid mogelijk is om na een week of wat aan productie het algoritme te trainen, maar als je je eigen mail regelt, zul je sowieso een lading mails verliezen in de spammappen van je gebruikers.

[Jeoh]

Dat bieden ze gewoon aan hoor. Duizendmaal beter dan zelf met je transactional email hobbyen.

[RogerDad]

nou, of het lek daarmee gedicht is… Ik heb meermaals phishing mails afkomstig van sendgrid gezien. Sowieso wat mij betreft wat opgeblazen artikel. SPF en de andere “pas toe of leg uit” standaarden zijn een goed idee, maar ik zou het ontbreken daarvan geen lek noemen; wel slordig/onhandig/onnodig.

[Jay-v]

Eens, dit is geen lek. Gevalletje een artikel uit het FD overnemen. Een SPF config is natuurlijk wel een goed idee verder...

[GertMenkel]

Sendgrid stuurt inderdaad spam, maar valideert andermans domeinen wel. Je krijgt dus misschien wel "Jort Kelder wil je bitcoin geven" van "[e-mail]" binnen, maar je kunt via Sendgrid niet zomaar een "@testenvoortoegang.org"-adres gebruiken.

Ik zou het ontbreken van SPF inderdaad geen lek noemen, hooguit een configuratiefout. Een beetje spamfilter geeft dit soort mails een behoorlijke spamscore vanwege het ontbreken van SPF, dus zal de mail keihard geweigerd worden als de afzender een slechte IP-reputatie heeft/het algoritme spam herkent/een ander probleem ontstaat dat het bericht van "waarschijnlijk spam" naar "gebruiker ziet het niet" pusht.

De echte kwetsbaarheid hier is dat de mail van deze organisatie waarschijnlijk lastig aankomt.

[Trommelrem]

Maar dat klopt toch niet? De tilde is alleen voor testing purposes en niet voor productie omgevingen? Dat moet toch een dash zijn?

[Jay-v]

Nee, de tilde is een softfail, dat betekend dat alle mail van andere servers/domeinen wel doorgelaten mag worden maar geflagged moet worden als spam/suspicious. Een min (-all) is een hardfail en zou de mail moeten bouncen, maar lang niet elke ontvangende partij houdt zich daar aan.

[Trommelrem]

Over de ontvangende partij heb je geen controle. Dat zul je nooit hebben. Dat ontslaat je als verzendende partij niet van de plicht om zaken wel in orde te hebben.

Daarom is het ook gebruikelijk om een conditional access policy te maken voor guest users. Je immers geen controle over je guest users. Dat zij geen MFA hebben ingesteld, ontslaat jou niet van je verplichting om basale toegangscontrole in te stellen.

[parsa2020]

In theorie ja, in de praktijk nee. Als de ontvanger zich namelijk niet houdt aan de hardfail, dan zal deze de mail dus gewoon door laten. Naar mijn weten zit er binnen de hardfail geen fallback naar een softfail, dus is het 'of markeren als spam voor de meeste ontvangers' of 'blokkeren voor sommigen, en totaal doorlaten voor de rest'. Die keuze is natuurlijk nooit perfect, maar dan lijkt het markeren als spam me wel de meest logische optie, aangezien de meeste mensen echt niet in hun spambox kijken behalve als ze iets missen dus het risico hiermee wel het meest is gemitigeerd.

[aikebah]

Die dash gaat gegarandeerd gedonder geven met alle email forward mogelijkheden (vrijwel altijd zonder SRS) die mensen hebben. Veel logischer dus om bij SPF niet verder te gaan dan de softfail.

[CAPSLOCK2000]

Daar zijn oplossingen voor zoals DKIM.
Alleen SPF is tegenwoordig niet meer genoeg.

[aikebah]

Inderdaad, en vandaar dat je bij SPF dus ook volstaat met de softfail om de mailketen bij forwards zonder SRS niet te breken.

[CAPSLOCK2000]

Een vraag waar ik lang mee worstel is hoever je daar mee moet gaan.
Hoe lang moeten we nog rekening houden met mailservers die niet met de tijd meegaan?
Je zou ook kunnen stellen dat de partij die voor de forward zorgt maar voor een oplossing moet zorgen (zoals SRS). De gebruiker kiest voor een forward, niet de verzender. De gebruiker kan kiezen voor een forwarder die SRS (of iets anders) doet en de gebruiker kan kiezen op welke server de e-mail uitkomt en of die server SPF afdwingt.

Zelf doe ik m'n uiterste best om aan alle standaarden te voldoen maar vroeg of laat loop je tegen onmogelijke keuzes op. Zoals wat je doet met mail die binnenkomst niet voldoet aan SPF/DKIM/etc en die geforward moet worden. Als je wil dat die mail aankomt zou je afzenderadres kunnen herschrijven zodat de mail match met jouw SPF-record en er zelf een DKIM-handtekening onderzetten. Maar is die beslissing aan jou of ben je dan spam aan het witwassen?

[aikebah]

Tot op heden nog geen reden gezien om af te wijken van mijn policy daarin: wees zeer strikt voor waaar je zelf invloed op hebt (lees: richt SPF/DKIM/DMARC in en zorg dat wat jij stuurt altijd correct is voor de eerste ontvanger) en wees waar mogelijk toegeeflijk voor de fouten van anderen, oftewel blijf rekening houden met de (plain) forwards die SPF wel maar DKIM niet zullen breken.

Edit: En specifiek voor het spam forward risico: Hangt een beetje van het volume van mailverkeer af. Bij een beperkte omvang (domein voor een club/vereniging met wat forwards voor bestuursfuncties) kom je meestal een eind met een globale streng afgestelde quarantainebox voor verdachte mail; met een beetje trial en error zie je dat die behoorlijk strikt afgesteld kan zijn voordat false positives langskomen en dan zou je de resterende verdachte mail dus redelijk risicoloos kunnen forwarden inclusief SRS en moet je heel af en toe een legitieme mail alsnog handmatig doorzetten.

[Reactie gewijzigd door aikebah op 23 juli 2024 21:51]

[djiwie]

Onzin, dat gaat hier niet op. Die mails worden naar privepersonen gestuurd met bijvoorbeeld testuitslagen en die worden gewoon als attachment doorgestuurd, doorsturen met behoud van afzender (waar dit een issue zou kunnen zijn) is niet aan de orde.

[aikebah]

Ik zie anders genoeg SPF failures langskomen van privepersonen die hun '[e-mail]' kennelijk met plain forward hebben doorgesluisd naar hun Google mailbox.

[EdwinB]

Daar had ik dus ook last van. Opgelost door de mail niet door te sturen naar Gmail maar om deze met pop3 bij Gmail te krijgen. Duurt soms alleen iets langer voordat een mail mij bereikt.

[Ventieldopje]

In productie gooi je nooit meteen de deur dicht maar ga je gefaseerd te werk.

Overigens slaat je vergelijking die je nu elke keer blijft herhalen de plank compleet mis. Het is niet dat SPF nu niks doet, in tegendeel. De mail zal nog steeds aankomen maar wel aangemerkt worden als verdacht of spam. Met een dash zou deze mail helemaal niet aankomen.

[Trommelrem]

Met een dash komt e-mail prima aan. Leg mij a.u.b. uit waarom e-mail bij een normale configuratie niet zou aankomen als er een dash in de SPF staat.

[Reactie gewijzigd door Trommelrem op 23 juli 2024 21:51]

[aikebah]

Met een dash komt die niet aan als de geadresseerde de mail vanaf het adres forward naar zijn/haar gmailadres zonder sender rewriting scheme. Want dan wordt het een mail from you@trommelrem die verzonden wordt door de mailserver van me@mygreatforwardingservice. Niet verzonden door een geautoriseerde mailserver en dus conform SPF geweigerd aan de poort.
(dat type forwards komt heel veel voor bij heel veel hostingproviders met een mail forward op de lekker goedkope domeinnaam)

[Reactie gewijzigd door aikebah op 23 juli 2024 21:51]

[GertMenkel]

Wordt deze manier van mail forwarding nog veel gebruikt? Ik weet dat het een jaar of tien geleden nog enigszins populair was, maar ik geloof niet dat er nog veel ondersteuning voor is.

Als SPF je mail-forwardingschema kapotmaakt, lijkt me dat een probleem van je mailforwardingschema. Net zoals arbitraire afzenders op SMTP-servers toestaan is zo'n manier van mail forwarding een reliek uit de onbeveiligde tijd van het wilde westen van het internet.

In mijn optiek is het aan jou om zo'n configuratie werkend te krijgen met SPF, door bijvoorbeeld vanaf je forwardserver geen SPF te valideren. Zo'n systeem is leuk, maar als het de spambestrijding van de rest van de wereld in het geding brengt, is het het waard om dit soort uitzonderingen te breken als afzender.

Aangezien de doelgroep van deze website "de algemene Nederlander" is, en niet de subdoelgroep "Nederlanders met een domeinnaam bij een skere partij die wel zelf de mail hosten maar niet met een eigen mailserver en forwards ingesteld hebben staan", denk ik dat het geen enkel kwaad kan om SPF gewoon lekker strikt te zetten.

[aikebah]

De doelgroep is 'alle nederlanders', dus je wilt dat je mail ook aankomt bij de Nederlanders die een goedkoop domainaccount hebben voor een stoer mailadres op eigen domein, maar die hun gmail mailbox (met ingesteld afzenderalias) gebruiken voor mailstorage en de mail naar dat adres met een plain forward alias doorzetten naar hun gmail box.
Je krijgt GMmail echt niet zo ver om SPF validatie uit te zetten omdat sommige van hun gebruikers hun andere mails linea recta plain laten forwarden naar die makkelijke grote gmail box om de 1GB mailbox limiet van hun domein provider te omzeilen.

[GertMenkel]

Dat is dan toch het probleem van de mensen die Gmail gekozen hebben? Als je je server niet goed kan instellen, heb je je configuratie kapotgemaakt. Om heel Nederland phishinggevoeliger te maken voor die paarhonderd Nederlanders die de verkeerde mailhost gekozen hebben, lijkt me de omgekeerde wereld. Laat ze hun zooi maar fixen.

[aikebah]

Vandaar dat je dus SPF softfail+DKIM+DMARC inricht. Die combo pakt echt wel een berg weg terwijl de meeste legitieme mail al dan niet langs duistere achterafstraatjes uiteindelijk in ieder geval nog in de mailbox van de bedoelde ontvanger aankomt (al dan niet met een 'suspected junk' melding.

SPF hard fail staat die aflevering al direct in de weg (mits compliant geimplementeerd door de ontvanger, want hard fail staat voor: weigeren als je het niet direct aangeleverd krijgt door een toegestane verzender)

Voor je eigen mail mag je wat mij betreft prima de aflevering steviger frustreren en accepteren dat je mail soms gewoon zonder melding van de postbode wordt weggegooid (SPF hardfail). Van een organisatie als deze verwacht ik een iets meer meegaande policy om de kans op aflevering te vergroten (uit ervaring weet ik dat er de nodige partijen niet aan DMARC reporting doen (slechts partiale failure reporting ontvangen bij een plain forward zonder SRS waarbij ik wist dat er meer domeinen betrokken waren als ontvanger van diezelfde plain-forwarded mail), dus DMARC failure reporting heb je ook niet voldoende aan om in de softfail testfase te concluderen dat een hard fail geen kwaad kan)

[Trommelrem]

En er is een reden waarom een e-mail forward inmiddels op alle tenants op disabled staat. Om precies de reden die je noemt. Dergelijke e-mail wordt dan ook terecht geblokkeerd.

[aikebah]

Tsja.. kun je voor kiezen inderdaad, maar het probleem is: je hebt geen invloed op de configuratie van geadresseerden van mail. Die kun je niet dwingen om geen mail forwards in te stellen, maar met een hard fail SPF heb je er wel last van.

[Trommelrem]

Een hard fail SPF lost dus een security probleem op.

[Blizz]

Hard fail wordt bij SPF over het algemeen alleen aangeraden te gebruiken in de situatie dat je nooit e-mails verstuurt vanaf een bepaald (sub)domein. Je kunt er zelf voor kiezen of er lang over discussiëren, maar dit standaardadvies zal niet veranderen omdat het de instructie reject/bounce geeft in plaats van markeer als verdacht/verplaats naar spam.

Het verschil in de discussie is dat jij er andersom naar kijkt (strenger), wat niet fout is, maar afwijkend omdat e-mailauthenticatie priegelen is en die spambox niet voor niks bestaat. Normaal gesproken kijkt men bij SPF naar 'is alles goed ingesteld en komen DNS record/e-mailserver overeen, dan vertrouwen en zo niet dan verdacht'. Jij kijkt ernaar als 'de stempel op het envelop vertelt het volledige verhaal', namelijk: 'is dit volledig volgens het DNS-record, zo nee, dan moet je het niet eens afleveren'. Hard fail biedt meer nadelen dan zekerheden en die zekerheden heb je sowieso al als je DKIM en DMARC hebt ingesteld. DMARC beschouwt normaal gesproken, zeker als je het goed instelt, een softfail als een fail. Dus dan heb je de voordelen en niet de nadelen.

Aan het eind van de dag weet je ook niet hoeveel spam er onder jouw naam wordt verstuurd, tenzij je zeker weet dat dit een groot probleem is, is de kans groter dat er legitieme e-mail verloren gaat.

[Reactie gewijzigd door Blizz op 23 juli 2024 21:51]

[CAPSLOCK2000]

Met een dash komt e-mail prima aan. Leg mij a.u.b. uit waarom e-mail bij een normale configuratie niet zou aankomen als er een dash in de SPF staat.

Als het goed gaat komt mail inderdaad aan. Maar mensen maken wel eens fouten. Zo'n softfail is een aardige manier om even aan het water te wennen voor je er in springt. Aangezien dit domein momenteel best wel belangrijk is en ze de verandering in productie moeten doen snap ik helemaal dat ze voorzichtig zijn met veranderingen.

[Blokker_1999]

De dash staat voor een hardfail. Dat wil zeggen dat als er ook maar iets mis is, als er ook maar iets niet in orde is dan moet je de mail blokkeren en niet laten doorgaan. Stuur je dan bijvoorbeeld een email naar een externe distributiegroep en die mailserver stuurt de email opnieuw door naar andere externe ontvangers gaan die ontvangende servers zeggen: deze mail komt van een server die niet bevoegd is en de gevraagde policy is hardfail. Ik drop die mail zonder iemand op de hoogte te stellen.

[aikebah]

Hangt uiteraard ook af van wat je beveiligd met die login, maar lang niet alles waar een login gebruikt wordt is belangrijk genoeg voor MFA.

[joenevd]

Dit SPF is met een tilde (~all) dit is dus niet afgedicht. Zou veranderd moeten worden naar -all.

[Platpoot]

"Gedicht" ze hebben er een softfail op gezet. Dat noem ik niet dichten.
Daar komt verder bij, spf kijkt naar de envelope-from, wat gebruikers in outlook zien is de header-from, dus die kunnen met alleen spf nog prima mail ontvangen uit het testenvoortoegang.org domein. Uiteraard kijken grote mailproviders hier naar en zal de spamscore verhoogd worden, maar dat is niet waterdicht tot je dmarc/dkim inricht (wat uiteraard ook alleen maar waterdicht is als de ontvangende kant zijn zaakjes op orde heeft).

[BrennuS]

Klopt ik snap dit ook niet. Elke overheidswebsite moet aan standaarden voldoen. Deze staan beschreven op https://www.forumstandaar...pen-standaarden/verplicht. Deze standaarden zijn natuurlijk voor elke site aan te bevelen.

Deze kan je als requirements zo meenemen en checken of in een aanbesteding naar verwijzen.

Edit: typo

[Reactie gewijzigd door BrennuS op 23 juli 2024 21:51]

[kodak]

De stichting is niet van de overheid. Dat ze betaald krijgen om ook voor de overheid een opdracht uit te voeren wil niet zomaar zeggen dat de verplichting voor domeinen van de overheid dus ook op zulke stichtingen of bedrijven van toepassing is. Al lijkt het me heel redelijk als de overheid eisen stelt dat een bedrijf of stichting die van de overheid gemeenschapsgeld krijgt om een opdracht uit te voeren dus ook aan dit soort erkende standaarden moet voldoen vanaf de start van de opdracht. Helaas lees ik zowel bij het FD als tweakers niet welke eisen de overheid hierover stelt en daar echt contole op doet.

[CAPSLOCK2000]

Al lijkt het me heel redelijk als de overheid eisen stelt dat een bedrijf of stichting die van de overheid gemeenschapsgeld krijgt om een opdracht uit te voeren dus ook aan dit soort erkende standaarden moet voldoen

Dat is denk ik de beste samenvatting van de situatie. Misschien moeten we onze pijlen richten op de overheid die zo'n dienst afneemt zonder daar de juiste voorwaarden aan te stellen. Daar kan dat bedrijf niks aan doen. De overheid mag zich echter niet verschuilen achter leveranciers om zo onder de regels uit te komen.

Maar tegelijkertijd vind ik het ook wel een vorm van nalatigheid van de leverancier. Als leverancier heb je een zekere plicht om een goed product te leveren. Als de overheid een auto koopt dan staat er vast niet in de aanbesteding dat de auto een stuur en remmen moet hebben, dat is vanzelfsprekend.
In mijn ogen hoort SPF er tegenwoordig bij als je iets met e-mail doet.

[kodak]

Het voorbeeld wat je bij mogelijke nalatigheid geeft laat waarschijnlijk eerder zien waar een onderdeel van het probleem zit. De rem en het stuur zijn namelijk juist wettelijke verplichtingen en zulke verplichtingen worden in de autowereld ook met enige regelmaat aangescherpt omdat het deels een vrije markt is. De markt van de ict is daarbij nog veel vrijer.

Iedereen die maar iets met ict wil bereiken kan dat proberen, zonder ook maar de minste kennis van standaarden te hebben of zich wat aan te trekken van wat bijvoorbeeld een meerderheid aan concurrenten als mening over wat goed is heeft. In die vrije markt heb je ook de vrijheid voor klanten om maar liever te verwachten dat iemand die je geld geeft dan wel goed genoeg is, zonder zelfs eisen te hoeven stellen.

Als mensen de vrijheid nemen om het naar hun mening veiliger te maken kun je ook verwachten dat anderen de vrijheid nemen om dat (on)bewust te negeren. Het lijkt me hoe dan ook redelijk als de mensen en organisaties die het voor zichzelf belangrijk vinden dan ook zorgend dat als ze eisen over standaarden kunnen stellen dat dan ook doen. Maar dat zal waarschijnlijk dus ook afhangen wie de onderhandelingen doen en of die personen het belangrijk vinden.

[BrennuS]

Het mag wel een stichting zijn maar het is gewoon een verplichting voor overheids sites. https://forumstandaardisatie.nl/basisinformatie

En ja, onder "pas toe of leg uit" kan je veel plaatsen en zeker bij oude systemen. Denk aan bijvoorbeeld digitoegankelijk voor oude systemen. Voor nieuwe systemen gaat dat niet op en is er geen excuus. Zeker niet voor wat dns instellingen.

[kodak]

Laat je opzettelijk weg dat de stichting niet van de overheid is? Want zoals je zelf al stelt gaat de verplichting op voor de overheid, omdat de overheid het voor zichzelf tot verplichting heeft gemaakt.

Zolang de wet dit niet verplicht stelt kan je niet zomaar verwachten dat bedrijven of andere organisaties dat soort verplichtingen van een ander over gaan nemen. Je kan er wel een beroep op doen, of als klant er eisen aan stellen voor je (gemeenschaps)geld geeft.

[BrennuS]

@kodak
Daar heb je inderdaad helemaal gelijk in. Het is een stichting die is ingezet door de overheid.

Of het nu de overheid is of een stichting die in naam van de overheid zaken regelt doet er voor mij als burger niet zo toe. Ik zou verwachten dat ze deze uitgangspunten ook voor een dergelijke site/leverancier gebruiken.

Misschien is dit niet bij wet verplicht maar het is wel een best practice en relatief eenvoudig te voorkomen zonder extra middelen.

Vind het een erg domme fout die ze hadden kunnen voorkomen

[michielRB]

Opmerkelijk dat ODF er in staat als standaard en dat er geen vermelding is voor OOXML. Ik vraag me af hoeveel ambtenaren wel gewoon DOCX en XLSX documenten maken, gebruiken en versturen.

[CAPSLOCK2000]

Opmerkelijk dat ODF er in staat als standaard en dat er geen vermelding is voor OOXML. Ik vraag me af hoeveel ambtenaren wel gewoon DOCX en XLSX documenten maken, gebruiken en versturen.

Dat is inderdaad een enorm zuur punt. OOXML is geen echte open standaard. Het lijkt er wel een beetje op maar er zitten een hoop verwijzingen naar andere standaarden (zoals het oude .doc formaat) die niet open zijn. Daardoor kun je er eigenlijk nog steeds niet op vertrouwen.

Hier is een enorm gevecht over gevoerd met de overheid die graag wilde dat MS Office gebruik zou gaan maken van ODF als standaardformaat. Na lang touwtrekken heeft MS het wel toegevoegd als ondersteund formaat, maar niet als het standaard formaat. Ambtenaren moeten dus iedere keer dat ze een bestand opslaan expliciet opgeven dat het als ODF moet. Dat gebeurt in praktijk niet want het is maar onhandig en de meesten weten niet eens dat ze dat zouden moeten doen.

[barefoot]

Ik zag 'm nog niet langs komen in de comments, maar naast het Forum Standaardisatie van de Nederlandse overheid is er ook internet.nl. Daar kun je eenvoudig testen of een site voldoet aan het merendeel van de standaarden van het Forum. Het Forum neemt ook deel in internet.nl. Testen voor toegang krijgt nog altijd geen score van 100% op dit moment: https://internet.nl/site/www.testenvoortoegang.org/1246876/

[dwizzy]

Er is nog meer informatie:
Maar in een kwart van de aanbestedingen van de overheid wordt naar SPF gevraagd als het relevant is, volgens de Monitor Open Standaarden 2020. Het ligt vooral aan leveranciers die het uit zichzelf leveren.

We zijn wel ver gekomen met de eis voor SPF; ik kan me niet voorstellen dat het een paar jaar geleden voor een krantenkop zou zorgen. Vijf jaar geleden had net de helft van alle overheidssites überhaupt SPF, en toen letten we niet eens op strict of ~all. Nu voldoet >95%
Ik hielp met het onderzoek voor Forum Standaardisatie voor hun rapportage aan de Tweede Kamer, nog voordat internet.nl bestond.

De oude jaarlijkse rapportages kan je niet makkelijk bij het Forum Standaardisatie vinden, maar wel hier: Monitor Open Standaarden - NORA

[Reactie gewijzigd door dwizzy op 23 juli 2024 21:51]

[WokeBroke]

Ik begrijp het niet helemaal. Het was toch altijd al mogelijk om ieder email adres te spoofen met een simpele PHP mail() Function script?

[CAPSLOCK2000]

Ik begrijp het niet helemaal. Het was toch altijd al mogelijk om ieder email adres te spoofen met een simpele PHP mail() Function script?

Ja, en technisch gezien is het nog steeds mogelijk. Het verschil zit bij de ontvanger. Met behulp van SPF kan die zien dat jouw server niet bevoegd is om te mailen te versturen met dat e-mail-adres.

Dat was decennia lang wel mogelijk, SPF is een vrij recente ontwikkeling (nou ja, het is een jaar of 10 oud). Dit is volgens mij voor het eerst dat ik een nieuwsbericht zie dat iets zegt over een missend SPF-record alsof dat bijzonder is. Volgens mij heeft de meerderheid van de domeinen z'n SPF nog niet op orde.

Maar ik vind het terecht om hier kritiek op te leveren. De overheid heeft zichzelf namelijk verplicht om wel gebruik te maken van SPF, dus dan mag je kritiek geven als ze het niet doen. Sterker nog er is een enorme lijst technische standaarden (waaronder ook dkim en dmarc, de vaste broertje van SPF) waar de overheid zich in principe aan moet houden. Er is nog veel werk te verichten.

Voor de duidelijkheid, dit is geen kritiek op het IT beleid van de overheid. Sterker nog, op dit gebied doen ze het best wel goed. Fors beter dan de markt. Maar dan nog is er nog steeds veel te verbeteren.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 21:51]

[Keypunchie]

Ik heb zelf een domein (zoals velen) en ik moet zeggen dat ik, ondanks mijn IT-kennis, die naar mijn eigen bescheiden mening best groot is, ik moeite heb om te snappen wat DMARC, DKIM en SPF doen. Laat staan dat je een begrijpelijke uitleg kunt vinden in lekentaal, hoe het in te stellen.

Naar hoe ik het begrijp en snap:
SPF (Sender Policy Framework): Je hebt (in de DNS van je domein) een text-record met daarin een lijstje van toegestane mailservers en een instructie wat te doen met mail van een ander domein.
Je kunt zowel IP-adressen als DNS-adressen van mailservers opgeven. Dus bijvoorbeeld alle mailservers van Google via "include:_spf.google.com". Mail van andere kun je aangeven dat die "verdacht" moeten worden gemeld (~all) of geweigerd (-all).

DKIM: Domain Key IdentifiedMail.
Hiervoor moet je ook echt dingen instellen op de mailserver. Als ik het goed begrijp wordt een bericht daadwerkelijk voorzien van een 'handtekening', die op een vergelijkbare manier werkt als certificaten. Wederom in DNS heb je de publieke sleutel staan in een text-record.

DMARC: Domain-based Message Authentication, Reporting and Conformance
Een soort van "meta-policy" waarin je aan andere mailservers niet alleen vertelt hoe ze mail moeten verifieren, maar ook waar ze "bad mails" heen kunnen sturen, zodat je rapportage kunt maken of je mail/wel niet aankomt. Deze vind ik het minst begrijpelijk.

En hier heb ik dan uit pure interesse, als IT'er, wel wat hobby-uurtjes ingestopt om het met mijn mailprovider te laten werken en ik heb nog steeds twijfels of ik alles goed heb ingesteld.

Een grote organisatie kan een echte specialist inhuren, maar hoe in vredesnaam het MKB, laat staan de ZZP'er op de hoek verwacht kan worden om dit allemaal een beetje acceptabel ingesteld te krijgen is mij een raadsel. Helemaal als je naast reguliere bedrijfsmail ook nog bvb. third-party mailtjes voor marketing of orderverwerking, etc. hebt die je ook graag wilt laten doorkomen.

[CAPSLOCK2000]

Ik heb zelf een domein (zoals velen) en ik moet zeggen dat ik, ondanks mijn IT-kennis, die naar mijn eigen bescheiden mening best groot is, ik moeite heb om te snappen wat DMARC, DKIM en SPF doen. Laat staan dat je een begrijpelijke uitleg kunt vinden in lekentaal, hoe het in te stellen.

Je legt hieronder prima uit, DKIM en SPF snap je in ieder geval wel.

SPF (Sender Policy Framework): Je hebt (in de DNS van je domein) een text-record met daarin een lijstje van toegestane mailservers en een instructie wat te doen met mail van een ander domein.

Correct

DKIM: Domain Key IdentifiedMail.
Hiervoor moet je ook echt dingen instellen op de mailserver. Als ik het goed begrijp wordt een bericht daadwerkelijk voorzien van een 'handtekening', die op een vergelijkbare manier werkt als certificaten. Wederom in DNS heb je de publieke sleutel staan in een text-record.

Correct. Een klein puntje, de term 'certificaat' wordt meestal gebruikt voor point-to-point ssl-verbindingen en niet voor digitale handtekeningen, maar technisch gezien komt het behoorlijk op hetzelfde neer.
Het belangrijkste om te begrijpen is dat je met DKIM een handtekening zet onder onder mail die je verstuurt, net zoals je ook je handtekening onder aan een papieren brief zet om die 'echt' te maken.

DMARC: Domain-based Message Authentication, Reporting and Conformance
Een soort van "meta-policy" waarin je aan andere mailservers niet alleen vertelt hoe ze mail moeten verifieren, maar ook waar ze "bad mails" heen kunnen sturen, zodat je rapportage kunt maken of je mail/wel niet aankomt. Deze vind ik het minst begrijpelijk.

Toch leg je het goed uit
DMARC is een signaal zodat de rest van de wereld weet dat jij SPF en DKIM doet en dat ze je daar op mogen, nee moeten, afrekenen. Dus geen sympathie voor twijfelachtige mail, de beheerder heeft zelf gezegd dat er hard moet worden opgetreden als SPF en DKIM niet in orde zijn.
Klein detail, alleen SPF of alleen DKIM is genoeg. Ze hoeven niet allebij te kloppen, daar zijn technische redenen voor.

Een grote organisatie kan een echte specialist inhuren, maar hoe in vredesnaam het MKB, laat staan de ZZP'er op de hoek verwacht kan worden om dit allemaal een beetje acceptabel ingesteld te krijgen is mij een raadsel. Helemaal als je naast reguliere bedrijfsmail ook nog bvb. third-party mailtjes voor marketing of orderverwerking, etc. hebt die je ook graag wilt laten doorkomen.

Ik ben het met je eens dat het eigenlijk niet te doen is als je geen gedegen IT-achtergrond hebt. Natuurlijk zouden een hoop mensen het best kunnen als ze er lang genoeg op studeren, maar als ze dat hadden gewild waren ze wel in de IT gaan werken. Je kan niet van de loodgieter verwachten dat die weet wat SPF is.
De simpele oplossing is natuurlijk dat je het dan maar inkoopt. ZZP'ers kopen hun auto's, computers en mailservers nu ook al in. Persoonlijk vind ik dat SPF/DKIM/DMARC standaard zou moeten zijn als je ergens e-mail-dienstverlening koopt.
Ik snap dat dit een hoop extra werk en gedoe oplevert maar iemand zal het moeten doen.

Ergens vind ik het wel heel vervelend dat het steeds moeilijker wordt om je eigen IT te doen. Zelfs voor grote organisaties wordt het steeds moeilijker want er komt steeds meer bij kijken en dat maakt het ook weer duurder. Van de ene kant heb ik natuurlijk liever dat er professionals worden ingeschakeld, maar van de andere kant heb ik liever dat de bedrijven (en de hele maatschappij) zelf iets meer IT-kennis opdoen. Het voelt nu vaak als een maatschappij die de elektriciteit al heeft uitgevonden maar waarvan de meeste leden niet snappen hoe het lichtknopje werkt of dat je van de koperen draden af moet blijven. Dat soort kennis kun je natuurlijk inkopen maar het zou veel geld en levens sparen als mensen het zelf snappen.

Iedere organisatie in deze wereld doet tegenwoordig iets met IT. Voor de meeste organisaties is het hun belangrijkste dagelijkse activiteit. Computerkennis is net zo essentieel als een vulpen kunnen bedienen. Nu hoeft niet iedereen SPF en DKIM te snappen, maar er moet toch nog wel een hoop gebeuren.

[RoestVrijStaal]

Ergens vind ik het wel heel vervelend dat het steeds moeilijker wordt om je eigen IT te doen. Zelfs voor grote organisaties wordt het steeds moeilijker want er komt steeds meer bij kijken en dat maakt het ook weer duurder. Van de ene kant heb ik natuurlijk liever dat er professionals worden ingeschakeld, maar van de andere kant heb ik liever dat de bedrijven (en de hele maatschappij) zelf iets meer IT-kennis opdoen. Het voelt nu vaak als een maatschappij die de elektriciteit al heeft uitgevonden maar waarvan de meeste leden niet snappen hoe het lichtknopje werkt of dat je van de koperen draden af moet blijven. Dat soort kennis kun je natuurlijk inkopen maar het zou veel geld en levens sparen als mensen het zelf snappen.

Iedere organisatie in deze wereld doet tegenwoordig iets met IT. Voor de meeste organisaties is het hun belangrijkste dagelijkse activiteit. Computerkennis is net zo essentieel als een vulpen kunnen bedienen. Nu hoeft niet iedereen SPF en DKIM te snappen, maar er moet toch nog wel een hoop gebeuren.

Ik snap niet waarom de ICANN het voortouw neemt, terwijl die dat wel kan doen.

Zo zou de ICANN haar aangesloten tld-registries verplichten dat hun registrars (="domeinboeren" en webhosters) verplicht een API aan hun klanten moeten aanbieden.

Op zo'n manier hoeven klanten enkel met een simpele commando met credentials (desnoods in de email-server-applicatie zelf, waarom niet?) de juiste SPF, DKIM en DMAC in de records van hun domeinen in te stellen

[sprankel]

Het basis probleem is dat mail techniek is uit de beginjaren van internet waarbij er van security geen sprake is. Als je iets wilt aanpassen dan moet je heel de wereld mee krijgen terwijl je compatibel moet blijven met alle mailservers te wereld.

Bijkomstig zijn we het compleet gebrek aan security bij mail handig gaan vinden, je geeft het zelf aan, wat met third party maill voor marketing of orderverwerking? Een 3de partij die mails stuurt uit jou naam en dat werkt gewoon, geen security, geen bevoegdheden, geen logins, PHP scriptje en je bent klaar, handig toch? Maar vervolgens wel klagen over de spam en spoofing, tjah.

In een poging dat ongedaan te krijgen heb je SPF dat inderdaad zegt van welke mailserver een mail van jou domein mag komen.

Een ander probleem is de mogelijkheid dat mails aangepast worden voor ze afgeleverd worden, jij stuurt een offerte van 10 000 euro per mail maar bij ontvanger staat er 1000 euro. Om dat af te vangen ga je een handtekening toevoegen (DKIM) waaraan de ontvanger kan zien dat de inhoud niet aangepast is.

Het volgende probleem is dat zowel DKIM als SPF zo lek is al iets. Immers welke mailservers worden meestal gebruikt? Die van een provider, MS, Google enzovoort. Ik hoef maar naar je SPF record te kijken en ik weet al waar ik klant moet worden om vervolgens mails in jou naam te sturen met een geldig SPF record. En zelfs al heb je een unieke mail server, dan staat er meestal wel een of andere 3th party bij voor marketing of andere mails te kunnen versturen vanuit jou naam waar ik gemakkelijk klant word.

Die digitale handtekening is ook simpel te omzeilen, ik pas de mail aan en ik gooi de handtekening gewoon de vuilbak in, immers hoe kan ik nu weten of jou domein wel of niet digitale handtekeningen gebruikt in mails? Dus dan hebben we DMARC uitgevonden waarmee je simpel gezegd aangeeft, hey, als je een mail van dit domein hebt, dan moet hij EN SPF hebben EN hij moet altijd digitaal getekend zijn met als optie een return adress mee te geven zodat gespoofde mails naar je worden doorgestuurd (als je dat wenst).

Echter dan moet je third party, vaak met handen en voeten, gaan uitleggen dat ze hun 3th party mails moeten tekenen met een private key om vervolgens te horen dat je de 1ste bent van hun 500 klanten die daar om vraagt.

Heel het SPF, DKIM & DMARC gebeuren zit bij de ontvanger, het is de ontvanger die moet controleren want je hebt geen enkele manier om te verhinderen dat valse mails in jou naam verstuurd worden. Dat wilt ook zeggen dat alle instellingen die je meegeeft "voorkeuren" zijn, als de ontvanger beslist harde controles te doen ook al geef jij een soft fail mee, dan doet de ontvanger dat. Als de ontvanger beslist alle controles te negeren en de mail gewoon af te leveren, dan doet de ontvanger dat.

Vandaag de dag, als je geen SPF record publiceert gaan de meeste je mail als spam markeren, sommige bedrijven gaan vlakaf je mails droppen dus je gaat vrij snel klachten krijgen. DKIM & DMARC word nog niet echt afgedwongen maar spam filters hebben liever dat het wel aanwezig is.

Overigens is ook na DMARC de boel nog lek omdat alles vertrouwd op DNS al is het al een pak lastiger om via die weg te gaan. Maar lang verhaal kort, na DMARC heb je DNSSEC nodig ofwel secure DNS.

Of we moeten eens besluiten dat mail zo antiek is dat het echt wel nodig is dat we met mail 2.0 afkomen maar veel geluk met heel de planeet te overtuigen.

[Donstil]

Een grote organisatie kan een echte specialist inhuren, maar hoe in vredesnaam het MKB, laat staan de ZZP'er op de hoek verwacht kan worden om dit allemaal een beetje acceptabel ingesteld te krijgen is mij een raadsel. Helemaal als je naast reguliere bedrijfsmail ook nog bvb. third-party mailtjes voor marketing of orderverwerking, etc. hebt die je ook graag wilt laten doorkomen.

Nah dat valt allemaal wel mee. Ik werk in een IT organisatie waar we een paar honderd klanten bedienen. Van alle servicedeskmedewerkers op de afdeling techniek (30 ofz) snapt zeker de helft hoe SPF en DKIM werkt en kan het inrichten.

Het is een kwestie van wat vaker doen denk ik en dan is het echt niet spannend.

[GertMenkel]

Ik heb zelf een domein (zoals velen) en ik moet zeggen dat ik, ondanks mijn IT-kennis, die naar mijn eigen bescheiden mening best groot is, ik moeite heb om te snappen wat DMARC, DKIM en SPF doen. Laat staan dat je een begrijpelijke uitleg kunt vinden in lekentaal, hoe het in te stellen.

Je legt het anders prima uit, dus zoveel moeite lijk je niet te hebben

Met de hoeveelheid spam en brakke, lekke servers die aan het internet hangen, is het denk ik het beste als mensen die dit niet snappen gewoon niet in de buurt komen van mailconfiguratie. Als je standaard providerconfiguratie je mail weigert omdat je een vage derde partij in de arm neemt (Mailchimp etc.) dan is het aan die derde partij om je de nodige informatie en uitleg te verstrekken. Doen ze dat niet, dan kun je beter naar de concurrent.

Als je de kennis niet zelf hebt, moet je die kennis kopen, of dat nou is omdat je niet weet hoe je je DKIM instelt of dat dat is omdat je niet weet hoe je de bedrading in je kantoor veilig aansluit. Zo is het nu eenmaal in de bedrijfsvoering.

De ZZP'er op de hoek kan gewoon een hosted domein van Google kopen en de support van Mailchimp, Sendgrid en whatever bellen als de mails niet aankomen. Of, zoals de meeste het doen, een mailtje sturen vanuit de interface van Gmail met een hele lading adressen in de To: omdat zo'n iemand toch niet weet hoe BCC werkt.

[KennieNL]

DMARC is zelfs een must imo...
Zolang SPF in de mail op 'Return-Path' controleert (en dus niet op 'From' adres) vind ik SPF tegenwoordig relatief weinig toevoegen... DMARC daar in tegen controleert wel 'From'.

[theorganiser]

het gekke is dat bij Office 365 je geen mogelijkheid hebt tot DMARC.

hoe wil je het dan oplossen ?

[VHware]

Voor DMARC is een DNS-record nodig. Aan de mailproviderkant hoef je niets in te stellen. In het DNS-record vertel je wat de policy is (none, quarantine of reject) en waar rapportage naartoe gemaild mag worden. Bij policy=none krijg je de rapportage maar de mailproviders doen verder alsof er geen DMARC is. Dus om effectief te zijn moet het minstens quarantine zijn.

Valimail is een partij waar je de rapportage naartoe kunt laten sturen die van deze rapportage-informatie mooi inzichtelijk maakt.

Zie: https://learn.valimail.com/dmarc-monitor/

N.b. momenteel is het zo (helaas) dat Office365 (Microsoft) momenteel als ontvangende partij geen DMARC-rapportage stuurt over je domein. Als je de werking wilt testen kun je o.a. met gmail-accounts testen (als ontvanger). Google stuurt wel DMARC-rapportage.

[Reactie gewijzigd door VHware op 23 juli 2024 21:51]

[aikebah]

het gekke is dat bij Office 365 je geen mogelijkheid hebt tot DMARC.

hoe wil je het dan oplossen ?

Hoezo niet?
DMarc is een in DNS gepubliceeerde policy die beschrijft hoe omgegaan moet worden met mails omtrent SPF en DKIM compliancy.
Heb zelf DKIM+SPF+DMARC ingericht op een domein dat voor de mail in Microsoft365 cloud draait en zie toch echt de mail de controles (meestal) volledig correct doorlopen. Af en toe een failure door een adres dat op onjuiste wijze doorstuurt en/of een mail die op vervalste wijze verzonden is.

[robvh99]

Ja, dat kan inderdaad
Maar de ontvangende server kan op basis van spf controleren dat het ip address van jouw machine niet 'gemachtigd' is namens dit domein email te versturen en zal afhankelijk van de instelling (en spf) de email als spam markeren of zelfs direct verwijderen

[jeffreytigch]

Klopt, je kan met je eigen SMTP server elk email adres als afzender instellen. Waar het hier om gaat, is dat (de server van) de ontvanger dit wel accepteert. Met het SPF record geef je aan: deze mail servers mogen namens dit domein mail versturen.

[roooii]

The receiving server extracts the domain's SPF record and then checks if the source email server IP is approved to send emails for that domain. Receiving servers verify SPF by checking a specific TXT DNS entry in your domain, which includes a list of approved IP addresses.

Maw met een spf record kan dat dus niet meer.

[HKLM_]

Nu alleen hun DKIM records nog toevoegen.... Dit lijken ze nog niet gedaan te hebben.
Hun MX records verwijzen naar https://flowmailer.com/ maar die spreken op de website alleen van SPF en DMARC dus ze zullen wel niet weten hoe en wat

[Reactie gewijzigd door HKLM_ op 23 juli 2024 21:51]

[Vorkie]

Mag Tweakers.net ook eens doen, samen met DMARC...
vinger wijzen naar anderen is makkelijk, maar zorg dan op zijn minst dat je hele eigen, IT website, ook zijn, in dit geval echt basale, zaakjes op orde heeft

[ETH0.1]

Voor een IT website vind ik het artikel bijzonder karig artikel met weinig of geen eigen onderzoek. Ik stoor me ontzettend aan het zinnetje:

"Het lek is nu naar alle waarschijnlijkheid gedicht, hoewel het FD dat niet uitdrukkelijk zegt."

Hoezo check je dat niet zelf even, sorry maar je schrijft niet voor een site als nu.nl maar voor een websites vol professionals, we mogen toch wel iets van inhoud en onderzoek verwachten ipv het simpel weg herschrijven van een artikel van een niet technische kant?

[Alex3]

Dan wordt het gelijk een plusartikel.

[djiwie]

"Het lek is nu naar alle waarschijnlijkheid gedicht, hoewel het FD dat niet uitdrukkelijk zegt."

Dat stoorde me ook enorm toen ik dit artikel las.

Voor de redactie, hier mijn "onderzoek":

~ nslookup -type=txt testenvoortoegang.nl
Server: 2001:b88:1002::10
Address: 2001:b88:1002::10#53

Non-authoritative answer:
testenvoortoegang.nl text = "v=spf1 mx a ptr include:spf.topdesk.net include:spf.flowmailer.net include:spf.protection.outlook.com ~all"

Ja, er staat nu ook SPF record ingesteld. Nee, het houdt niet alles tegen (~all ipv -all), dus kan beter.

Niveau weer hoor tweakers

[sypie]

Zelf onderzoek doen geldt alleen wanneer je een nieuw topic opent met een vraag. Dit geldt niet voor het schrijven van een nieuwsbericht. Ook dat is al vaker besproken, dat er te weinig onderzoek wordt gedaan door de redactie. Dit komt voort uit het punt dat er geproduceerd moet worden, onderzoek duurt te lang en stokt de productie van nieuwsberichten.

[smiba]

Hoe moeilijk is het om even de SPF record op te vragen?? Als 5 minuten onderzoekswerk te veel is als tech journalist, waar ben je dan mee bezig?

[n4m3l355]

De vraag is, is Tweakers een website dat nieuws herhaald of zelf maakt. In Tweakers geval doen ze beiden, ze maken zelf content, ze herhalen artikels. Maar dat hoeft hun niet te beletten om zelf ook navraag te doen, zij het bij alle testen of zelf even een record opvragen. Sterker nog bij Tweakers zou je toch verwachten met technische artikelen dat ze zelf wel iets van te zeggen hebben. Op dit moment is Tweakers toegevoegde waarde net zoveel als nu.nl, 0.

[MrMonkE]

Dit komt voort uit het punt dat er geproduceerd moet worden

"Dit komt voort uit het punt dat er geproduceerd gekopieerd moet worden"

En door kopiëren komen de leugens in de wereld. De hele goegemeente wordt geïnformeerd door 'journalisten' die alles van elkaar kopiëren en na-papegaaien met het gevaar dat de onjuiste informatie wordt verspreidt.

[HKLM_]

Daar heb ik ze laats n.a.v hun 2FA wijzigen op gewezen

[Reactie gewijzigd door HKLM_ op 23 juli 2024 21:51]

[CAPSLOCK2000]

Teleurstellend want SPF en DKIM hebben (juridisch gezien) dezelfde status. Ze staan naast elkaar op de lijst van standaarden waar de overheid zich aan moet houden.
Helaas zie ik dit veel te vaak. Er wordt zo snel mogelijk iets in het gat gepropt zonder na te denken over het hoe of waarom. Ja, het is nu beter dan het was, maar eigenlijk is het nog steeds niet goed genoeg.

Het probleem is dat ze te weinig doen aan spoofing. SPF is een van de middelen die je daar tegen in kan zetten. Iedere expert kan je vertellen dat alleen SPF niet genoeg is.

Ik hoop dat ze achter de schermen bezig zijn om de boel op orde te krijgen.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 21:51]

[lenwar]

DKIM en SPF zijn natuurlijk hele goede standaarden, maar het kan ook voor veel gedoe zorgen. Zeker als je je mail in de cloud hebt zitten.

(( disclaimer: onderstaande statements zijn effectief gechargeerd. Het gaat om het principe ervan ))

SPF in de cloud creëert een lijst van toegestane adressen die zo groot wordt dat het relatief weinig meer uithaalt.

DKIM kan bij ‘doorsturen’ van mail ook voor gedoe zorgen. Als de mail eerst langs een derde partij gaat die spam afvangt en de goede mail doorstuurt, is de DKIM-handtekening mogelijk niet meer geldig.

Beide technieken zijn in de basis gewoon goed, maar een (te) strakke/strikte implementatie kan voor heel veel gedoe zorgen bij zowel de verstuurder, maar vooral de ontvangende kant. Het zijn in de basis een soort lappen op een open wond. Ze helpen wel, maar ze zijn niet ideaal en kunnen voor problemen zorgen

(( bovenstaande voorbeelden ben ik zelf meermalen tegenaan gelopen ))

[Jeoh]

DKIM hebben ze al geconfigureerd. Is alleen wat lastiger achter te komen als je geen mail van ze ontvangt, maar de records zijn wel goed geconfigureerd: fm1._domainkey.testenvoortoegang.nl. / fm2._domainkey.testenvoortoegang.nl.

[kftnl]

Geen SPF hebben op een derderangs overheidssite is nu ook al een kwestbaarheid waarvoor we krantenartikelen schrijven? Ik vermoed dat hun probleem hiermee vooral was dat hun mail bijna overal in de spambox komt, niet dat het spoofen van mail zo veel makkelijker wordt.

[flubbr]

Dit ja. Geen SPF hebben is niet een kwetsbaarheid.
Het is netter om SPF in te stellen, maar het is absoluut géén kwetsbaarheid.

In plaats van doen alsof het een kwetsbaarheid is, zouden mensen beter kunnen worden opgevoed en worden uitgelegd dat een e-mailafzender niet autoritief is.

Net als dat je een brief op de post kan doen, en op de enveloppe een random afzender kan opgeven, zo kan dat ook met e-mail. E-mail is niet 'betrouwbaar' en zal dat ook nooit worden.

[djiwie]

De combinatie van SPF en DKIM/DMARC maakt de afzender wel autoritief, en aangezien vrijwel iedere grote organisatie dit doet is het niet raar dat mensen daar steeds meer op vertrouwen. En het is toch raar dat ze vergeten zijn SPF in te stellen? Zit nota bene in de standaard wizard van Office 365.

[CAPSLOCK2000]

Dit ja. Geen SPF hebben is niet een kwetsbaarheid.
Het is netter om SPF in te stellen, maar het is absoluut géén kwetsbaarheid.

Het is een beetje een kwestie van definities, zoals de vraag of een 'inbreker' ook een 'inbreker' is als de deur open stond. Je hebt helemaal gelijk dat we SPF meestal niet als kwetsbaarheid behandelen. Maar ik vind dat we dat wel moeten doen.

In mijn werk heb ik hier ook wel eens mee te maken. Ik probeer woorden als 'kwetsbaarheid' te vermijden omdat mensen automatisch in de verdeding schieten maar het zuiver technisch af te handelen: "zet feature X aan want dat hebben we afgesproken in ons contract". Anders moet ik op eens gaan bewijzen dat het niet hebben van een SPF-record een security risico is en als de andere kant de kennis mist om het probleem te begrijpen dan lukt dat nooit. Dat is zonde van ieders tijd want ik stop niet tot het geregeld is.
En als het teveel moeite kost om te krijgen wat we willen dan zoek ik wel een andere leverancier. Opmerking: Ik werk voor een organisatie die groot genoeg is om zelf mensen in dienst te hebben met verstand van zaken die de juiste vragen kunnen stellen. De meesten zijn niet zo groot en weten dus niet wat ze moeten vragen anders dan "het moet wel veilig zijn, he!".

In plaats van doen alsof het een kwetsbaarheid is, zouden mensen beter kunnen worden opgevoed en worden uitgelegd dat een e-mailafzender niet autoritief is.

Daar ben ik het op zich wel mee eens, maar mij is het de afgelopen 25 jaar nog niet gelukt om die boodschap te laten hangen. Ik heb het misschien wel 1000 keer uitgelegd, maar meestal is de reactie zoiets als "en wat gaat IT doen om dit probleem op te lossen? Jullie zijn van security dus los het maar op".

Net als dat je een brief op de post kan doen, en op de enveloppe een random afzender kan opgeven, zo kan dat ook met e-mail. E-mail is niet 'betrouwbaar' en zal dat ook nooit worden.

Hoeveel mensen controleren of hun papieren post echt is?
Persoonlijk heb ik dat misschien 3 keer in mijn leven gedaan. Als je een blauwe enveloppe door de brievenbus duwt die een beetje geloofwaardig is dan betaal ik. Als je een krant door mijn brievenbus duwt dan geloof ik dat het echt de krant van die dag is.

[flubbr]

Het is een beetje een kwestie van definities, zoals de vraag of een 'inbreker' ook een 'inbreker' is als de deur open stond.

Meer: ik bel bij iemand aan en zeg dat ik CAPSLOCK2000 ben.
Daar kan jij niets tegen doen en sta jij buiten.

Zelfde mentaliteit kom je tegen bij oplichting waar mensen geld overmaken en daarna bij de bank gaan zitten klagen.

SPF, DMARC en DKIM zijn zaken die je instelt om een ander te helpen controles uit te voeren, niet jezelf.
Zelf heb jij er geen controle over wat een ander doet.

[Trommelrem]

Het instellen van SPF is een minimale eis om je mail goed te configureren. In de Microsoft adminportal blijft je domeinnaam ook gewoon aangeven dat er issues zijn als je SPF niet instelt. Bovendien ben je echt een malloot als je SPF vergeet, het is een van de records in hetzelfde overzicht als de MX records van de Microsoft adminpagina.

[kftnl]

Weten we of zij uberhaupt email gebruikten op dat domein? Als je geen SPF configureert heb je vrij snel door dat je mail bijna nergens aankomt lijkt me.

[CAPSLOCK2000]

Geen SPF hebben op een derderangs overheidssite is nu ook al een kwestbaarheid waarvoor we krantenartikelen schrijven? Ik vermoed dat hun probleem hiermee vooral was dat hun mail bijna overal in de spambox komt, niet dat het spoofen van mail zo veel makkelijker wordt.

Ik vind het ook opmerkelijk maar wel goed. Ik weet dat we Tweakers de komende 10 jaar zouden kunnen vullen met berichten over domeinen zonder SPF. Toch denk ik dat het goed is dat er eens iets van gezegd worden. De overheid heeft zichzelf verplicht om SPF te gebruiken. Maar als niemand op z'n kop krijgt als dat niet gedaan wordt verandert er nooit iets.
Gezien de grote spanningen rond Corona en testen denk ik dat het terecht is om dit domein te bekritseren.

[CAPSLOCK2000]

Ik verbaas me er ook een beetje over. Het ruikt naar een journalist die ofwel op zoek is naar een schandaaltje, ofwel voor het eerst iets met IT doet en nog niet beseft hoe laag het gemiddelde niveau ligt.

Ik krijg hetzelfde gevoel als wanneer een leek voor het eerst de logs van een firewall ziet en dan overstuur komt melden dat er wel 10 aanvallen per minuut worden tegengehouden. Iedere ervaren IT'er weet dat er iedere seconde pakketjes worden tegengehouden en dat dit geen reden tot paniek is maar helaas normaal.

Maar dat neemt niet weg dat ik het prima vind dat we onze overheid controleren en bekritiseren wanneer ze hun eigen regels niet nakomen. Als we alles maar stilletjes accepteren verandert het nooit.

[VHware]

Tegenwoordig zou je verwachten dat overal SPF, DKIM en DMARC wordt ingesteld. Zeker bij nieuwe implementaties is het eenvoudig om dat meteen te doen, gezien je minder hoeft te testen.

[batjes]

Je zou het verwachten, maar heel veel partijen hebben dus geen SPF records ingesteld. Bij ons is het met EOP de voornamelijkste reden dat behoorlijk veel mail in onze spamfilter terecht komt. Meestal zijn het kleine bedrijven of kleine organisaties, maar daar zitten ook best wat grote partijen tussen.

[VHware]

Ja ik weet het, heb daar ook ‘last’ van. Als je vervolgens dan probeert hen er op te wijzen begrijpen ze het ook niet.

[Trommelrem]

De adminportal van Microsoft blijft op je domeinnamen zelfs waarschuwingen geven als je SPF niet instelt. Als je die als sysadmin negeert, dan ben je wel echt een ...

[sgt frankieboy]

Ziet er naar uit dat de SPF record er nu wel is:

v=spf1 include:_spf.zivver.com include:spf.flowmailer.net include:u21679679.wl180.sendgrid.net ~all

DMARC ook, dus het is gefixed. Weet niet of ze ook DKIM records hebben.

[Reactie gewijzigd door sgt frankieboy op 23 juli 2024 21:51]

[g1n0]

Een SPF met een soft-fail vind ik nou niet echt een fix.

[Blokker_1999]

Een SPF met een hardfail vind ik dan weer not done. Laat die netjes softfailen met een waarschuwing naar de gebruiker. Dan kan dan de gebruiker zelf bepalen wat er met de mail moet gebeuren.

[djiwie]

In welke situatie zouden er dan @testenvoortoegang.nl mails buiten de officiele mailomgeving gestuurd moeten worden? Hardfail zou hier juist perfect zijn. Laagste kans op misbruik.

[CAPSLOCK2000]

In welke situatie zouden er dan @testenvoortoegang.nl mails buiten de officiele mailomgeving gestuurd moeten worden? Hardfail zou hier juist perfect zijn. Laagste kans op misbruik.

Bij forwards. Heel wat mensen hebben tegenwoordig een eigen domein maar laten de mail die daarop ontvangen wordt doorsturen naar een ander e-mail-adres, bijvoorbeeld naar Gmail. Dan wordt zo'n mail opnieuw verzonden vanaf je eigen mailserver en dan zou SPF niet matchen.

Er zijn betere oplossingen zoals DKIM/DMARC of SRS maar ze hebben allemaal hun eigen nadelen, een perfecte oplossing bestaat helaas niet, voor zover ik weet.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 21:51]

[djiwie]

Ja, oke, maar ik vind niet dat je daarom maar je SPF record minder streng in moet stellen. Mensen die een dergelijke constructie voor hun mail hebben ingesteld zullen wel vaker mails in de spambox terugvinden. En eigenlijk is dit nooit goed te krijgen zonder een expliciete whitelist voor de doorsturende partij bij de ontvangende mailbox - iets wat je niet kan configureren als onafhankelijke derde.

[Earry]

;; ANSWER SECTION:
testenvoortoegang.org. 152 IN TXT "D+g6PQCH7MSA/XwS+AD2m+G6PDFocdu8TAbiW7N4lDc="
testenvoortoegang.org. 152 IN TXT "v=spf1 include:_spf.zivver.com include:spf.flowmailer.net include:u21679679.wl180.sendgrid.net ~all"

Ja, SPF staat nu ingesteld. SPF wordt sowieso niet door iedereen gebruikt, dus zelfs hiermee kan het nog plaatsvinden. De vraag is of ze nu ook meteen DKIM/DMARC hebben ingesteld.

[Trommelrem]

Ja. Het staat ingesteld. Dat is hetzelfde als MFA instellen met de status "disabled". Of Conditional Access instellen met een exclusion voor All Users.

Het moet ook goed worden ingesteld. Een tilde is alleen voor testing purposes, niet voor productie omgevingen. In productie omgevingen gebruik je een dash.

[Blokker_1999]

Ik denk dat jij nog eens wat documentatie moet lezen. Een tilde is helemaal niet testing en een dash productie. Het is softfail en hardfail en er zijn verschillen tussen die twee en je wil echt niet altijd een hardfail hebben want dat houdt ook weer risico's in. Namelijk dat emails niet aankomen waar ze moeten aankomen.

[CAPSLOCK2000]

Ik denk dat jij nog eens wat documentatie moet lezen. Een tilde is helemaal niet testing en een dash productie. Het is softfail en hardfail en er zijn verschillen tussen die twee en je wil echt niet altijd een hardfail hebben want dat houdt ook weer risico's in. Namelijk dat emails niet aankomen waar ze moeten aankomen.

Dat is een keuze. Het ligt er maar aan wat je belangrijker vindt, dat de mails aankomen of dat er niet mee gerommeld kan worden.

Persoonlijk denk ik dat SPF met softfail zo weinig toevoegt dat het nauwelijks de moeite waard is. Maar nog altijd beter dan niets.

[Pogostokje]

Dit nieuwsbericht heeft echt helemaal niks te maken met best practise op een Office 365 omgeving, die hier ook helemaal niet gebruikt wordt gezien de SPF details. Voor veel mensen zal het niet te volgen zijn waar je het over hebt.

[Reactie gewijzigd door Pogostokje op 23 juli 2024 21:51]

[bkor]

Voor veel mensen zal het niet te volgen zijn waar je het over hebt.

Simpel gezegd: SPF is nu wel ingesteld, echter als er een mail wordt gestuurd vanuit een andere server (IP adres), dan moet de ontvanger maar beslissen wat te doen. Oftewel, er wordt gezegd dat er een kwetsbaarheid is, echter kan je met deze instellingen nog prima mails versturen namens "Testen voor Toegang". Om de kwetsbaarheid echt op te lossen had "Testen voor Toegang" moeten aangeven dat alle andere bronnen geweigerd moesten worden ("-all").

[djiwie]

Er wordt wel degelijk Office 365 gebruikt (check de MX records maar), maar niet uitsluitend. Maar dat wil niet zeggen dat softfail een goede practice is.

[Jeoh]

Dat een softfail voor het testen van je record is is nogal een hardnekkig misverstand. Dat werd tien jaar geleden geroepen, maar hierover lees je niets in de RFC (https://datatracker.ietf.org/doc/html/rfc7208).