Apple Mail, Outlook 2016 en veel andere mailclients zijn kwetsbaar voor spoofing

Meer dan dertig e-mailclients, waaronder die van macOS, iOS en Windows 10, zijn kwetsbaar voor e-mailspoofing via een methode die e-mailservers en beveiliging als dmarc en spamfilters omzeilt.

Beveiligingsonderzoeker Sabri Haddouche, die de kwetsbaarheid ontdekte, noemt hem Mailsploit. Hij demonstreert de methode en heeft een demo gemaakt waardoor gebruikers zelf kunnen zien of hun e-mailclient kwetsbaar is.

In de afgelopen drie maanden heeft Haddouche de kwetsbaarheid gemeld bij de makers van de e-mailclients. Sommigen hebben het probleem opgelost, maar bij de meeste bedrijven ligt het probleem nog 'ter beoordeling'. Opera en Mozilla hebben aangegeven dat zij geen patch zullen uitbrengen, omdat zij vinden dat het een serverprobleem is.

De kwetsbaarheid is het gevolg van RFC-1342, een standaard uit 1992 die beschrijft hoe niet-ascii-tekens in e-mailheaders worden weergegeven. Haddouche ontdekte dat veel e-mailclients niet goed controleren op de aanwezigheid van kwaadaardige code bij het omzetten en dat e-mailspoofing daardoor eenvoudig is te doen. Bij enkele clients zorgt de kwetsbaarheid er zelfs voor dat het mogelijk is om kwaadaardige code uit te voeren. Bij de populairste e-mailclients is dat niet het geval, of is het opgelost.

Een overzicht van alle e-mailclients en de status is gepubliceerd in een Google Doc. Op het moment van schrijven komt de kwetsbaarheid nog voor in veelgebruikte e-mailclients zoals Apple Mail, Outlook 2016, Mozilla Thunderbird en SeaMonkey en de Mail-applicatie van Windows 10. Yahoo heeft de kwetsbaarheid in zijn e-mailclients voor iOS en Android opgelost en ook ProtonMail heeft dat gedaan. Gmail is niet kwetsbaar.

E-mailspoofing is niet nieuw. Onlangs kwam het fenomeen in het nieuws in Nederland omdat de e-mailservers van de Tweede Kamer niet beschermd bleken te zijn tegen de techniek. Bij de Mailsploit-methode is de beveiliging van de e-mailservers niet relevant, omdat die wordt omzeild.

Bekijk het volledige overzicht in een Google Doc

Reacties (57)

[thanx]

Het bronartikel is een stuk duidelijker.
Er wordt in essentie een complex emailadres opgebouwd, wat bestaat uit een gespoofd mailadres gevolgd door een geldig emailadres.
De servers verwerken het volledige complexe adres en valideren het domein op het geldige mailadres. Als dmarc, dkim, spf op het volledig domein juist zijn ziet de server een super betrouwbaar adres.
De clients struikelen over het complexe adres waardoor ze maar een deel weergeven en dat is natuurlijk het gespoofde adres. Zo lijkt de mail afkomstig van een bekende/betrouwbare bron terwijl misbruik aannemelijk is.

Ik denk dat mailservers/spamfilters dit wel gaan blokkeren maar ik snap niet waarom mozilla en opera haar clients hier niet voor willen aanpassen. de foute validatie zit echt in de clients.

[Laloeka]

Mijn spamfilter heeft 4 van de 14 test e-mails tegengehouden (wellicht dat bij 4 exemplaren de correcte afzender niet achterhaald kon worden waardoor de mailserver verificatie misliep).

In Mozilla Thunderbird is vervolgens bij 9 van de 10 binnengekomen e-mails een kleine of grote afwijking aan de naam van de afzender te zien (slechts 1 van de 10 geeft zonder fouten het 'neppe' afzender adres weer). Bij 5 van deze 10 e-mails krijgt Thunderbird het echter niet voor elkaar het correcte adres uit de e-mail te halen.

En dat alles terwijl de e-mailserver bij deze e-mails wel correcte dkim/spf verificatie heeft kunnen uitvoeren. Het lijkt me dus echt dat de fout hier in de e-mail client zit.

Misschien is de oplossing wel een simpelere e-mail adres structuur hanteren voor inkomende mail van een externe mailserver op het internet. Momenteel heb je minimaal ruim 400 tekens nodig om elk officieel geldig e-mail adres te valideren via een regular expression, terwijl je 99.99% van de e-mail adressen met een veel simpelere syntax kunt valideren:

[tt]^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$[/tt]

[RobinF]

Rspamd houdt 13 van de 14 demo emails al tegen/markeert deze als spam (afhankelijk van instelling). Maar dat is niet alleen om de afzender, ook om allerlei andere dingen

[Verwijderd]

Eh, niet doen.
Kijk eens naar het robuustheid principe van Jon Postel https://en.wikipedia.org/wiki/Robustness_principle door dit principe werkt het internet tenminste. Als bijv je browser bij elke fout die het tegenkwam niets laat zien, kreeg je op 99.99% van de pagina's een foutmelding

'[e-mail] is een geldig e-mail adres, maar komt niet door je test heen. Of het bestaat weet ik niet.

Veel erger is dat bedrijven zoals bijv eneco en afterpay in hun nieuwsbrieven e,d. technieken zoals dkim naar mijn idee onjuist gebruiken (from is eneco.nl dkim signed by msdp1.com) en in de hele mail is dan ook geen url te vinden naar hun eigen domein.

[Speleding]

Je regular expression houd email adressen met een single quote tegen, die wordt toch vrij veel gebruikt in Schotse achternamen, dus je mist wel wat meer dan 0.01% denk ik.

[Frenziefrenz]

Wordt Opera Mail überhaupt nog doorontwikkeld sinds de dood van Opera 12 een jaar of 4 geleden?

Om m'n eigen vraag te beantwoorden: zo af en toe een minieme veiligheidsfix: https://blogs.opera.com/s...era-mail-security-update/ (In dat geval van iets dat al twee jaar eerder bekend was… dus niet bepaald actief.)

[Sendy]

Ik heb gezocht waar Mozilla.org schrijft dat deze bug niet opgelost gaat worden. Ik kan ‘t niet vinden. Dit is de enige die ik kan vinden op Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1423319 Maar deze is op dit moment unconfirmed, en er is geen history, dus hij lijkt nooit wontfix te zijn geweest.
Heeft iemand een link met het statement van mozilla.org?

[Little Penguin]

Zoeken op mailsploit in bugzilla levert nu diverse andere resultaten op, de belangrijkste is https://bugzilla.mozilla.org/show_bug.cgi?id=1423432

Zoals ik het begrijp gaat men de bug m.b.t. het NULL-character oplossen en volgens mij lost dat dan ook gelijk de andere issues op.

Het is inderdaad een beetje vaag dat er geen duidelijke bron gemeld wordt m.b.t. het statement dat een bepaalde partij het niet op wil lossen. Mogelijk dat er geen informatie was op het moment dat het bericht geplaatst is, maart dat is wat anders mijns inziens.

[Trommelrem]

Maar het is toch op serverniveau dat SPF en DMARC wordt gecontroleerd? Hoe kan Outlook dan kwetsbaar zijn, terwijl de controle bij Office 365 plaatsvindt?

[sprankel]

Ik heb dit even getest voor een domein waar SPF, DMARC & DKIM actief staan => de mail word niet klassiek gespoofd, oftewel door als afzender @echtdomein op te geven.

De mail word verzonden van @valsdomein, komt binnen als @valsdomein, alle controles gebeuren dus op @valsdomein en niet op @echtdomein, vervolgens word een kwetsbaarheid misbruikt die de weergave afzender van @valsdomein veranderd naar @echtdomein. Het is dus pas op het allerlaatste moment dat de spoof gebeurd.
Als @valsdomein geldige SPF, DMARC & DKIM records heeft dan gaan die allemaal geldig zijn.

[Blokker_1999]

Omdat er niets mis is met SPF en DMARC. Deze worden correct gevalideerd. De meeste mailservers kijken gewoon naar het laatste domein dat ze tegenkomen in de afzender en gaan daarmee aan de slag. Het zijn hier de mail clients die proberen om van de encoded text opnieuw iets leesbaars te maken en in de fout gaan.

[Aetje]

Omdat als ik het goed lees, in laymans terms, de parsing van het mailbericht clientside niet goed gebeurt. De servers zijn het probleem niet, die volgen het mailprotocol correct en leveren het bericht ook correct en volledig aan de client af. Er wordt alleen gebruik gemaakt van een vorm van adressering die wel onderdeel is van het mailprotocol, maar nauwelijks nog legitiem gebruikt wordt.

Makkelijkste methode van oplossen zou dus ook zijn om dit serverside niet toe te staan en dergelijke mails op de mail gateways af te schieten. Als ex-mailbeheerder zie ik hier een taak voor de anti-spam/anti-virus gateway.

Neemt niet weg dat mail clients die niet goed om kunnen gaan met dergelijke berichten gewoon een patch nodig hebben. Zeker waar code injection bij mogelijk is.

[RoestVrijStaal]

Eigenlijk moet er een hoop legacy in de standaarden die over mail gaan (zoals die van het artikel) worden opgevolgd door iets nieuwers wat wel aan de huidige kennis en kunde over beveiliging voldoet.

Problemen door ASCII zou echt niet meer moeten kunnen in 2017.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 06:48]

[Blokker_1999]

En hoe wil je dat doen? Heel het internet draait op standaarden uit de jaren 80 of ouder. Bedacht in een tijd dat iedereen nog letterlijk iedereen kende op het internet. Een tijd waarin beveiliging iets was waar niet over nagedacht moest worden. En door de jaren heen zijn we daar op blijven verderbouwen.

Kijk even naar hoeveel moeite men heeft om een relatief eenvoudige aanpassing zoals IPv6 door te voeren of DNSSEC. Recent kwam in het artikel over het 25 jarig bestaan van de SMS versie 2.0 nog eens ter sprake maar ook daar zie je: er wordt geen vooruitgang geboekt.

Je vervangt iets dat in heel de wereld door miljarden mensen gebruikt wordt niet zomaar snel even door iets anders. De antieke protocollen zijn zo cruciaal geworden op het internet dat je ze niet zomaar even kunt aanpassen of vervangen. Natuurlijk zou een internet 2.0 er totaal anders en veiliger uitzien. Maar dat zal er volgens mij nooit komen. We blijven de bestaande standaarden bijwerken. Net genoeg om heel het kaartenhuisje dat we gebouwd hebben niet te doen instorten.

[erikmeuk3]

Dit doe je door een aanvulling toe te passen.
Zelf check ik met een DKIM plugin, die maakt het adres groen als alles oké is.
Maar dit kan veel beter en zou standaard moeten worden in alle email clients.
Als je dan mail van de bank krijgt, komt er in het beveiligings-venster de naam van de bank te staan.
De techniek is er al jaren maar de wil er domweg niet.

[fastedje]

Zoals deze DKIM plugin vvor Thunder bird: https://addons.mozilla.or...bird/addon/dkim-verifier/

Het voordeel is ook dat de plugin onthoudt of eerdere mails van een afzender met DKIM ondertekend waren. Gespoofte mails herken je direct aan de rode balk.

[RoestVrijStaal]

Het hoeft natuurlijk niet met een vingerknip te gebeuren.

Een groepje internet bedrijven zou kunnen forceren dat ze nog enkel services ondersteunen die de laatste versie draait.

ISP's zouden bijvoorbeeld aan hun klanten kunnen eisen dat ze enkel MTA's mogen draaien die verouderd protocol xyz niet meer ondersteund. Scheelt ook weer een tijdelijk SpamHaus momentje omdat een klant aan het nooben is in de config van zijn mailserver.

Ontwikkelaars van mailservers zouden hun stukje software zo moeten schrijven dat het de middelvinger geeft aan verouderde clients en vice versa.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 06:48]

[Verwijderd]

Je kan je waarschijnlijk ook wel de reacties van klanten voorstellen als ISPs dat gaan eisen. En hoe zie je zo'n migratie in de praktijk? Tijdens een transitiefase moet je protocol xyz het nieuwe pqr protocol draaien maar zodra je over bent zit xyz er nog wel in. En iets wat er in zit is altijd te misbruiken.

En hoe leg je aan willekeurige gebruikers uit dat hun email ineens niet meer werkt?

Het is echt enorm complex om dit "even" te doen.

[RoestVrijStaal]

Zoals ik al zei: Niet van de een op de andere dag doen.

1. Stel in een uitgebreide, duidelijke how-to hoe te migreren naar nieuwe versies / standaarden.
2. Deprecate oude meuk en communiceer dat zo luid mogelijk zodat die how-to vanzelf relevant wordt.
3. Maak oude meuk dood, zodat de slapers en luilakken ook assed zijn om te migreren.

[Dorank]

Ik heb echt een hekel aan de xkcd die bij dit soort opmerkingen wordt aangehaald.

[RoestVrijStaal]

Heu? Dat doe ik toch niet?

[MacFreek]

Problemen door ASCII zou echt niet meer moeten kunnen in 2017.

Ik kan niet zeggen dat ik verrast ben. UTF-8 support voor email is een nachtmerrie.

Om te beginnen is SMTP grotendeels 7-bit encoded. Er is een SMTPUTF8 extensie, maar dat beschrijft maar een (heel) klein deel van het verhaal. Het is namelijk ook mogelijk om op een andere manier unicode characters in een email te zetten bij een SMTP client of server die SMTPUTF8 ondersteunt. En precies daar zit de moeilijkheid: hoe krijg je al die methodes compatible.

Al eerste is het deel achter de "@" anders gecodeeerd is dan het deel voor de "@". Het stuk achter de "@" maakt gebruikt van PUNYCODE, wat gespecificeerd is in IDNA (international domain names). Het deel voor de "@" is eigenlijk niet goed gespecificeerd.

Verder zijn er meerdere varianten van IDNA. "Some IDNs are invalid in IDNA2003, but valid in IDNA2008. Some IDNs are valid in IDNA2003, but invalid in IDNA2008. Some IDNs are valid in both, but resolve to different destinations." Bron: Unicode report tr46.

Maar in de praktijk gaat het meestal mis met het deel voor de "@": als de SMTPUTF8 extensie ondersteunt wordt, kan dat stuk gewoon in UTF-8 gestuurd worden. Wat echter veel clients doen is een MIME-encoding toepassen, zoals ""=?ISO-8859-1?Q?text?=", ongeacht of SMTPUTF8 wel of niet ondersteund wordt. Bron: Postfix SMTPUTF8 readme

Maar zelfs als je SMTP server of client met al deze varianten goed omgaat, dan nog heb je een grote kans dat niet alles goed ondersteunt wordt. Om een voorbeeld te geven: volgens de specificaties als een mail doorgestuurd (bijvoorbeeld de SMTP server van een gebruiker die het doorstuurt naar de STMP server van de ontvanger), en de ontvanger ondersteunt geen SMTPUTF8, dan zou de SMTP server een bounce bericht moeten sturen. Wat natuurlijk allerlei problemen geeft, omdat het specificatie die het formaat van de meeste bounce berichten definieert er eigenlijk van uitgaat dat alles in ASCII is, niet Unicode, dus is ook daar niet goed gespecificeerd hoe dat bounce bericht gecodeerd zou moeten zijn.

Gelukkig kiezen de meeste servers ervoor om geen bounce te sturen, maar bijvoorbeeld de Unicode-gespecificeerde delen van het email adres te vertalen naar MIME-encoding. Dat werkt al jaren uitstekend, en is voor eindgebruikers ook veel beter (de mail komt aan).

Voor de rest zijn er natuurlijk legio problemen met email. Wat bijvoorbeeld als het envelope TO adres (in het SMTP MAIL TO commando) dan het To adres (in de mail header), en de client of server moet beide vergelijken ten behoeve van DKIM of SPF. Als het echt een heel anders email adres is, is het duidelijk dat dat het een spam is. Maar wat als het een subtiel verschil is, bijvoorbeeld de ene local string is UTF-8 NFC (composed) genormaliseerd, en de andere UTF-8 NFD (decomposed) genormaliseerd. Is dat subtiel verschillend. Ik daag je uit een RFC te vinden die dit soort corner cases precies specificeert.

En dat soort corner cases, dat is precies waar dit soort exploits gebruik van maken.

Dus nee, problemen door ASCII komen vast niet meer voor in 2017. Maar problemen door non-ASCII: geloof me, meer dan genoeg.

[Reactie gewijzigd door MacFreek op 23 juli 2024 06:48]

[Verwijderd]

email spoofing is toch inherent aan SMTP?
HELO
MAIL FROM [e-mail]
My fellow Americans, I'm pleased to tell you today that I've signed legislation that will outlaw Russia forever. We begin bombing in five minutes.

[WhatsappHack]

Daar hebben we dus een aantal mooie technieken voor waardoor de spam probability enorm omhoog gaat. Zie SPF, DKIM, DMARC en indien het van een nog waziger ingestelde server komt ook nog een falende controle op PTR.

[Croga]

Vervolgens zegt de server "Je SPF records komen niet overeen met je IP adres dus weiger ik je bericht". Spoof onmogelijk gemaakt.....

[Verwijderd]

Ja, maar dat gaat toch over de server dan, niet over de clients waar het artikel over bericht.

[Laloeka]

Het probleem zit dus in de clients. De e-mailserver werkt volgens het protocol en ziet door de trucjes in de naam van de afzender heen ("[e-mail]"\0([e-mail])@evilwebsite.com); haalt de echte afzender (evilwebsite.com) uit het adres. De e-mailserver voert vervolgens zijn checks uit en komt erachter dat de e-mail daadwerkelijk afkomstig is van evilwebsite.com. Check. Dit is een valide e-mail.

Vervolgens struikelen de e-mail clients over het adres en geven [e-mail] als afzender aan. Omdat je er vanuit gaat dat de e-mailserver de afzender heeft gecontroleerd (en dat is ook daadwerkelijk volgens protocol gebeurd), denk je nu dat je een mail van een andere persoon hebt ontvangen (omdat de e-mail client het ingewikkelde adres verkeerd weergeeft).

[Reactie gewijzigd door Laloeka op 23 juli 2024 06:48]

[dakathefox]

Heldere uitleg. Tegelijkertijd: als het zo eenvoudig is, waarom duurt het dan zo lang voordat er patches worden uitgebracht?

[darkfader]

Te veel moeite? Komt te weinig voor? Beetje jammer, maar als het echt belangrijk e email is kijk je naar de source van 't mailtje.

[dakathefox]

Allereerst lijkt het me niet zoveel moeite te zijn. Zet hier iemand een halve dag op en het moet toch te tackelen zijn. Stellen dat het te weinig voorkomt is ook maar een aanname.

Verder vind ik het een typische IT-er gedachte om het probleem bij Henk (van Ingrid) te leggen. Jij denkt echt dat Henk (van Ingrid) weet hoe hij de source van een e-mail zou moeten kunnen lezen én interpreteren?

[.Johnny]

Alhier (outlook 2016) is ingebouwd dat geen enkel email bericht dat van buiten komt wordt vertrouwd: er staat altijd een dikke banner boven die aangeeft dat de mail potentieel niet te vertrouwen is.

Dat lijkt mij toch een rigidere aanpak dan dat je op domein niveau je vertrouwen gaat opbouwen? Dat betekent namelijk ook dat je altijd de servers van het andere domein vertrouwt terwijl je daar helemaal geen controle over hebt. Stel dat de SMTP van whitehouse.gov was gehacked? Niet jou server dus weet jij veel of ze hun patches op orde hebben.

[Croga]

Dit gaat over het domein-deel van het adres wat jij probeert te spoofen. Dat wordt hier tegen gehouden.

De bug bestaat er uit dat iemand met zijn eigen domein maar een "bugged" EMail adres de client kan laten denken dat de mail alsnog van whitehouse.gov (of iets dergelijks) af komt.

Ofwel: Ik stuur een mail met <vreemde tekens>@croga.com. Dat mag ik aangezien ik croga.com ben. De vreemde tekens triggeren de bug waardoor de client denkt dat ik @whitehouse.gov ben. Spoof complete.

[pe0mot]

"Je opent toch überhaupt geen onbekende mail? Je weet precies wat je binnen krijgt"
Inderdaad, dat is dus de truc. Vertrouwen in wat je ziet.
Je vertrouwt het adres wat je ziet in je scherm, terwijl de afzender iemand anders is.

[Durandal]

En bekende mail dan? Die open je wel, toch?

Dan ben je nu gespoofd.

[Verwijderd]

Nee niet echt zal het beter uitleggen.

Als ik bv telefonisch contact heb gehad met mijn bank en ze zeggen dat ze [blabla] op de mail doorsturen, dan weet ik dus dat ik een mail van de bank krijg. Krijg ik een mail van de bank terwijl ik geen contact of iets heb gehad verwijder ik het zonder te openen, en dat doe ik dus met alles.
Dat bedoel ik met “ik weet wat ik binnen krijg”.

[dakathefox]

De praktijk is dat ik dagelijks emails krijg die mij niet vooraf zijn aangekondigd.

[PierreDuc]

Weet je als bedrijf zijnde ook als een nieuwe klant je benaderd voor eventuele interesse in jouw product? Wellicht moet je dan aan de slag gaan als helderziende

[Frenziefrenz]

Twee maar?

[Verwijderd]

Jep, 1 voor belangrijke zaken, dus ik weet of ik een e-mail kan verwachten.
En 1 voor minder belangrijke zaken als tweakers, webshops, games of degelijke.

[DigitalExorcist]

Klopt. Echter, een maand of 3 geleden ben ik overgestapt van T-Mobile naar Vodafone. Prompt kreeg ik een maand later (kon de agenda er praktisch op naslaan!) een factuur van T-Mobile -met écht ogend briefhoofd en alles!- met een herinnering dat ik nog een termijn moest betalen.

Heb me even oprecht achter de oren moeten krabben wat ik dan gemist zou hebben. Alleen het zinnetje dat ik per bitcoin kon betalen viel wel héél erg op.

De timing was *perfect* geweest voor een succesvolle scam. En dáár hopen ze op.

[hackerhater]

Als ZZP'er krijg ik vaak genoeg mail van vreemden die offertes vragen ed.
Daarom staat het spamfilter op mijn server ook op standje parionide
Als de score te hoog is gaat het enkeltje /dev/null en krijg ik de mail nooit te zien.
Vanuit gaand dat de mail uberhaupt langs de greylisting end SPF-checks komt.
Volgens de logs wordt 96% van alle mail geweerd / naar de spammap gegooit.............

[Reactie gewijzigd door hackerhater op 23 juli 2024 06:48]

[RobinF]

Mis je hierbij geen aanvragen van potentiële klanten die een wat minder goed ingestelde mailserver gebruiken?

[hackerhater]

Als ze de boel slecht ingesteld hebben ja
Zoals niet kloppende SPF met hard fail.
Of een mail-server die niet reageerd op een foutcode (greylisting)
Maar als je server zo slecht staat moet je je admin ontslaan en een betere inhuren.
Dan komt namelijk je mail op een hoop hosts niet aan.

[Reactie gewijzigd door hackerhater op 23 juli 2024 06:48]

[citegrene]

96% is erg veel , het zou eerder tussen de 80 en 90 moeten liggen. Misschien zou je die 10 tot 16% die de mailserver verkeerd heeft ingesteld een automatisch mailtje terug kunnen doen dat ze bij jou moeten zijn voor systeembeheer.

[hackerhater]

Ik beheer ook mailservers voor de doorsnee jan-met-de-pet.
Je wilt niet weten wat hun allemaal ontvangen. Waarschijnlijk gevalletjes van email overal achter laten.
Op mijn eigen adressen ligt het op 50% of zo.

[Zezura]

Nog slimmer: https://10minutemail.com

[Mic2000]

Mailspoofing:

"Hierdoor lijkt het alsof de e-mail afkomstig is van een andere bron. E-mail spoofing is een veelgebruikte techniek voor het versturen van spam. Ook zijn er computervirussen die e-mail spoofing gebruiken om zichzelf te verspreiden."

Weer wat geleerd

[locke960]

Opera en Mozilla hebben aangegeven dat zij geen patch zullen uitbrengen, omdat zij vinden dat het een serverprobleem is.

Briljante redenering. Dat is net zoiets als naar de hoeren gaan zonder condoom omdat "het haar verantwoordelijkheid is om SOA vrij te zijn".

[dakathefox]

Toch wel jammer om te zien dat de belangrijkste mailclients het probleem na al die tijd nog niet opgelost hebben.

[desalniettemin]

Net even geprobeerd Thunderbird 52.5.0, maar gebeurt niets. De laatste update van Thunderbird heeft het blijkbaar al verholpen.

[rbr320]

Apart, aangezien het artikel zegt dat Mozilla het niet in de client gaat fixen.

[desalniettemin]

Wacht even ik had het blijkbaar verkeerd begrepen Heb ze alle 14 gedaan en toen wel. Werd gemarkeerd als junk, maar belandde wel gewoon in mijn inbox.

[Reactie gewijzigd door desalniettemin op 23 juli 2024 06:48]