Alle getroffen lezers zullen een persoonlijk bericht ontvangen over de hack en de gegevens die daarbij zijn buitgemaakt
Ik denk niet dat ze 350.000 personen een persoonlijk bericht gaan sturen, een algemeen en geautomatiseerd bericht lijkt mij meer voor de hand liggend. Hopelijk zetten ze de e-mailadressen in de Bcc :-)

Hopelijk maken ze automatisch 350.000 aparte berichten.
Geen enkele reden om een cc of bcc te gebruiken.
Bij voorkeur veilige mail en een controle op opvangst zonder spam spf fout.

Dat jij dat niet denkt wil natuurlijk nog niet zeggen dat dit niet gaat gebeuren.
Als er een database gelekt is waar allerlei info in staat waar onder een mail adres dan is het natuurlijk niet zo moeilijk
om een loopje over de records te doen en alle betrokkenen te mailen met de info die er over hen in die database stond.
(wat wellicht wisselend is per record)

Wel is het uitkijken dat je daar mee niet weer een nieuw datalek maakt natuurlijk.

Als de e-mails niet gepersonaliseerd zijn is er geen enkele reden om Bcc niet te gebruiken[*]. 350.000 e-mails stuur je niet handmatig maar met mailinglist-software of een mailinglist-provider, en die zijn erop ingericht om fouten met To- of Cc-headers niet te maken. Er is dan geen enkele reden om niet van de mogelijkheden van SMTP gebruik te maken om bandbreedte en verwerkingscapaciteit te besparen door een e-mail voor meerdere bestemmingen in hetzelfde domein een keer te sturen in plaats van vele malen.

[*] Bcc is niets anders dan het weglaten van de e-mailadressen van de ontvangers in de headers die bij de ontvangers bezorgd worden. In tegenstelling tot wat het Bcc-invoerveldje in e-mailclients suggereert is Bcc geen header in het e-mailbericht. SMTP gebruikt To en Cc niet voor de bezorging, die heeft een eigen "envelope" waarin ze natuurlijk wel opgenomen moeten worden om aan te komen. Die krijgt de ontvanger niet te zien. Neem domweg geen To- of Cc-headers op en de adressen zijn niet zichtbaar voor de ontvanger.

Blijkbaar weet jij niet wat een persoonlijk bericht is. In elk geval valt een automatisch gegenereerd bericht er niet onder.

Ik zou me niet druk maken over de bandbreedte in deze tijd.
Ooit werd beweeerd dat opslag en verwerkingssnelheid geen aandachtspunten zouden zijn wegens Moore.
Een berichtje naar een ieder apart biedt weer betere terugkoppeling voor het gelezen zijn om foutieve opgeheven adressen.
het rekensommetje is dat voor 1k of 350Mbyte gaat maak er 30k van en je zit bij 10Gbyte niet iets om van te schrikken.

Dat is zoiets als een overvloed aan lichten aan laten staan omdat je toch zuinige LED-lampen hebt. Of om bij IT te blijven: deze manier van denken heeft gemaakt dat het voordeel van snellere computers en meer geheugen vaak voor een groot deel zijn opgeslokt door bloat in allerlei applicaties die functioneel weinig of niets toe heeft gevoegd. Je hoeft de extra ruimte die er is niet meteen te gaan verkwisten enkel omdat het kan. Zeker niet als de moeilijkheidsgraad van zuinig zijn nauwelijks of niet afwijkt van die van niet zuinig zijn, en dat is hier zo.

Als ik een script zou moeten schrijven om e-mail naar een lijst met e-mailadressen te sturen (been there, done that, stelt niet veel voor) dan is het triviaal om de adressen op de domeinnaam uit het e-mailadres te sorteren en vervolgens de e-mail per bijvoorbeeld steeds 200 adressen aan je SMTP-server aan te bieden (afhankelijk van wat die aan eventuele limieten op aantallen adressen hanteert). Met triviaal bedoel ik dat een functie die het sorteren en groeperen doet in Python nog geen 10 regels extra programmacode kost. Dat levert geen risico op voor de ontvanger zichtbare e-mailadressen op omdat deze adressen in de SMTP-envelope terechtkomen en die krijgt de ontvanger niet te zien. In het voor iedereen gelijke bericht (headers+body) worden de e-mailadressen van de lijst niet opgenomen. De gegroepeerde verzending stelt de SMTP-server in staat om het aantal berichten dat naar andere SMTP-servers wordt gestuurd drastisch te reduceren.

Maar ik neem aan dat de Persgroep niet eens aan dat soort geknutsel hoeft te beginnen omdat ze de infrastructuur die nodig is om grote aantallen abonnees per e-mail te benaderen al lang en breed zullen hebben.

Ik maakte de berekening voor de impact niet voor niets.
Net zoals jij (zie mijn eerdere opmerking met Moore verwijzing) heb ik een hekel aan onnodige verkwisting van resources.
Anderzijds moet je bedenken dat hoe eenvoudiger iets kan met minder werk des te sneller en met minder risico het gaat.

Ooit was machinetaal heilig want niet te evenaren in snelheid door een specialist. Alleen die afhankelijkheid van specialisten vond men niet prettig. Beter 10 goedkopere krachten die ook wel iets voor elkaar krijgen als is het niet zo efficiënt. Een extra loopje met rekening houden van beperkingen je terugkoppelingen etc.

In algemene zin heb je daar natuurlijk gelijk in, maar bij de inschatting van wat eenvoudiger en sneller is moet je wel enige kennis van zaken toepassen. Ik heb wat uitgewerkt om het aanschouwelijk te maken.

Het opmaken van een e-mail-tekst, inclusief headers, is gescheiden van het programmatisch versturen ervan. Het niet lekken van e-mailadressen is zuiver en alleen een kwestie van ze niet in de e-mailitekst opnemen. Ik laat de opmaak verder voor wat die is, daar is software voor. Versturen doe je met een SMTP-library waar je de volledig opgemaakte e-mail aan doorgeeft. Die ontvangt ook een afzender en een lijst met bestemmingen. Deze worden niet aan de headers van de e-mail toegevoegd maar in de SMTP-dialoog gebruikt (de 'envelope'), en die worden niet zichtbaar voor de ontvangers. Of je zo'n sendmail()-call met dezelfe e-mailtekst en een lijstje van 1 bestemming, alle bestemmingen in een keer of plukjes van bestemmingen maakt nagenoeg niets uit in complexiteit, en er is helemaal geen verschil in risico's die je ermee loopt. Een ongeordende lijst e-mailadressen sorteren en groeperen is in Python niet meer dan zoiets:


Dit gebruik je zo:


Dat is nagenoeg identiek aan het stuk voor stuk afleveren:


Het verschil is dus één import, een triviale functie van 6 regels die een ervaren Python-programmeur in minuten schrijft en test (het opgtuigen van de testdata die je sowieso nodig hebt voor je met echte adressen gaat werken kost heel wat meer tijd) en een klein verschil in twee regels van de rest van de code. Dat is alles. En het risico op het lekken van adressen zit hoe dan ook niet in deze code maar in het apart aangemaakte bericht.

Een ervaren Perl-programmeur kan ongetwijfeld iets dergelijks voor Perl laten zien en voor andere talen/platforms zal ook zoiets gelden, al zijn veel daarvan een stuk breedsprakiger dan Python of Perl.

Natuurlijk gaat het groeperen niet op als je gepersonaliseerde e-mails aanmaakt, maar daar hadden we het even niet over.

@redactie: ik zie dat de code-bbtag voorloopspaties weghaalt. Ik heb dat nu "opgelost" door no-break-spaces te gebruiken voor inspringen, maar code moet natuurlijk met handhaving van inspringen worden weergegeven. In talen die {} gebruiken om blokken te markeren is dat voor de leesbaarheid goed, in talen als Python waar het inspringen zelf blokken markeert verminkt het weglaten van voorloopspaties de code tot iets dat syntactisch onjuist is. De code-tag is er om code goed weer te geven, niet om hem te verminken.

Ik dacht dat er verschil was tussen "gepersonaliseerde" (=voorzien van en gedifferentieerd op persoonlijke gegevens van de ontvanger) en "persoonlijke" (=van persoon tot persoon) email, maar het zal wel aan mij liggen.

Nee hoor, je maakt een goed punt.

Je kan er alleen zeker van zijn dat de Persgroep geen honderdduizenden mensen van persoon tot persoon zal gaan benaderen, dat zou een enorme hoeveelheid werk vergen die door de lange doorlooptijd en foutgevoeligheid daarvan het resultaat eerder verslechtert dan verbetert. Het zal om praktische redenen wel een automatisch verstuurde standaardtekst moeten worden, lijkt mij. Of die wel of niet gepersonaliseerd wordt weet ik niet. Ook als ze dat wel doen zou ik in hun plaats niet de precieze gelekte waarden in de e-mail opnemen maar me beperken tot een opsomming van de typen gegevens die gelekt zijn ("uw naam, e-mailadres, ..."). Niet alleen omdat dat de verwerking eenvoudiger maakt maar ook omdat onversleutelde e-mail niet het meest robuuste medium is om persoonsgegevens mee te versturen.

Een minuut geleden kwam dit mailtje bij mij:


Dit is zeker geen persoonlijk bericht. Zelfs geen 'gepersonaliseerd' bericht.

Kijk even in het aan: / to: veld in de mail. het is de meest eenvoudige vorm van persoonlijk.
Kan weinig mis mee gaan, niet doorsturen :)) Anoniem 13:43, dat is goed voorspeld.