E-mailadres van ontvanger kan in PostNL barcode staan

[Componix]

Ik kwam er onlangs achter dat de 2D-barcode op PostNL-pakketlabels meer informatie bevat dan je zou verwachten -- je e-mailadres. De data is alleen gecomprimeerd (deflate), niet versleuteld. Iedereen met basiskennis kan dit uitlezen.


WAT ZIT ER IN DE BARCODE?

De code op een PostNL-label begint met een herkenbare prefix (bijv. PNL3STUNM...) gevolgd door een blok base64-gecodeerde data. Als je die base64 decodeert en vervolgens deflate-decompressie toepast (vanaf offset 1), krijg je een binaire structuur met daarin in plain text:

- Achternaam
- Voornaam
- Straatnaam + huisnummer
- Postcode
- Woonplaats
- Datum
- E-mailadres


HOE REPRODUCEER JE DIT?

Neem de lange code van een PostNL-label (de string die begint met PNL3S...). Knip het prefix eraf tot aan het base64-gedeelte (herkenbaar aan de + en = tekens en alfanumerieke karakters). Decode vervolgens:

code:

import base64, zlib

  b64_data = "<plak hier het base64 gedeelte>"
  raw = base64.b64decode(b64_data)
  decompressed = zlib.decompress(raw[1:], -15)

  for line in decompressed.split(b'\x00'):
      text = line.decode('utf-8', errors='ignore').strip()
      if len(text) > 2:
          print(text)

Je ziet dan je volledige NAW-gegevens en e-mailadres voorbijkomen.


WAAR KOMT DAT E-MAILADRES VANDAAN?

PostNL vraagt webshops actief om het e-mailadres van de ontvanger mee te sturen bij het aanmaken van een verzendlabel. In hun officiele Labelling API documentatie (https://developer.postnl.nl) staat bij het Contact type:

"Please add the e-mail address of the receiver to improve the
Mijn PostNL experience of your customer."

Dit e-mailadres wordt vervolgens opgenomen in de gecomprimeerde data die in de barcode op het fysieke label terechtkomt. Voor bepaalde producten (avondlevering, ophalen bij PostNL-punt) is het zelfs verplicht om minstens e-mail, SMS-nummer of telefoonnummer mee te sturen.


WAAROM IS DIT EEN PROBLEEM?

1. Geen encryptie
De data is alleen gecomprimeerd, niet versleuteld. Decompressie is triviaal.

2. Meer data dan zichtbaar
Op het label zelf zie je naam en adres in leesbare tekst. Maar het e-mailadres is alleen zichtbaar als je de barcode decodeert. Een consument verwacht niet dat zijn e-mailadres fysiek op een pakketlabel staat.

3. Dataminimalisatie (AVG art. 5 lid 1c)
Het e-mailadres is niet nodig voor de fysieke bezorging. Waarom zit het dan in een barcode die iedereen kan scannen?

4. Transparantie (AVG art. 13/14)
PostNL informeert consumenten niet dat hun e-mailadres in de barcode op het pakket zit. De privacyverklaring noemt het verwerken van e-mailadressen, maar niet dat deze fysiek uitleesbaar op het pakket staan.

5. Praktisch risico
Iedereen die een foto maakt van je pakketlabel -- een buurman, iemand in een sorteercentrum, een voorbijganger bij een stapel retouren -- kan met een simpel script je naam, adres en e-mailadres achterhalen. Dat is een combinatie die bruikbaar is voor gerichte phishing.


WAT IK NIET HEB GEVONDEN

Ik heb uitgebreid gezocht op Tweakers, Radar-forum, Security.nl en in internationale bronnen. Er zijn wel discussies over PostNL en privacy (QR-code scannen bij pakketpunten, metadata van brieven, clipboard-uitlezing door de app), maar het feit dat het e-mailadres onversleuteld in de barcode op het pakketlabel staat lijkt nog nergens publiek beschreven te zijn.


ADVIES

- Scheur altijd het label van je pakket voordat je de doos weggooit
- Overweeg bij webshops een apart e-mailadres te gebruiken voor bestellingen
- PostNL zou de data in de barcode moeten versleutelen, of op z'n minst het e-mailadres eruit moeten halen -- het is niet nodig voor de bezorging

Ik ben benieuwd of anderen dit kunnen bevestigen met hun eigen pakketlabels.

[Teleluvr]

Hoe is dit, afgezien van je E-mailadres, anders dan wanneer het adres op het pakket geschreven staat?

[MissingDog]

Teleluvr schreef op woensdag 11 februari 2026 @ 11:42:
Hoe is dit, afgezien van je E-mailadres, anders dan wanneer het adres op het pakket geschreven staat?

Het is niet nodig om het pakket fysiek te kunnen bezorgen en hierdoor ontbreekt de verwerkingsgrond van dit persoonsgegeven (emailadres)?

[Razr]

MissingDog schreef op woensdag 11 februari 2026 @ 11:47:
[...]

Het is niet nodig om het pakket fysiek te kunnen bezorgen en hierdoor ontbreekt de verwerkingsgrond van dit persoonsgegeven (emailadres)?

Volgens PostNL en hun policy niet: https://www.postnl.nl/privacy-verklaring/

Als je een brief of pakket verstuurt, ga je een overeenkomst met ons aan. Om die overeenkomst uit te voeren, verwerken we persoonsgegevens van jou als afzender.

Bij brieven gaat het om persoonsgegevens zoals:

e-mailadres (alleen voor de bevestiging)
betaalmiddel

Bij pakketten en aangetekende post gaat het om persoonsgegevens zoals:

e-mailadres (voor bevestiging, verzendlabel en track & trace-info)
naam, adres en woonplaats (voor op het verzendlabel)
betaalmiddel 

[Detmer]

MissingDog schreef op woensdag 11 februari 2026 @ 11:47:
[...]

Het is niet nodig om het pakket fysiek te kunnen bezorgen en hierdoor ontbreekt de verwerkingsgrond van dit persoonsgegeven (emailadres)?

PostNL heeft tegenwoordig voor sommige categorieën een ontvangstcode: https://www.postnl.nl/kla...et-barcode/ontvangstcode/ . Een mailadres is daarbij verplicht, want zonder code geen pakket.

[RM-rf]

Teleluvr schreef op woensdag 11 februari 2026 @ 11:42:
Hoe is dit, afgezien van je E-mailadres, anders dan wanneer het adres op het pakket geschreven staat?

Het gaat natuurlijk juist vooral om dat email adres...

Verder is je huisadres een noodzakelijke informatie voor verwerking, maar het is niet noodzakelijk dit extra op te gaan slaan voor bv verdere feedback (als het bv gaat om regionale data of verwerkingskantoren van post is het veel zorgvuldiger en ge-anonymiseert als men dan de betreffende regionale gegevens opslaat en niet persoonsgebonden gegevens).

Juist als gebruikers hier bv geen weet van hebben vergroot dit de kans dat ze adreslabels van ontvangen pakketten gewoon tussen het oud papier doen en daardoor ongecontroleerd onbevoegde derden dit kunnen vinden en vervolgens de data eenvoudig kunnen verzamelen...

Sowieso kunnen er allerhande zaken mee gedaan worden, die de ontvanger misschien helemaal niet wil... als het om een zichtbaar adres-label gaat is dat dan je eigen keuze... het is direct zichtaar dat dit goed leesbaar is, maar veel mensen zullen niet realiseren dat in de barcode onversleuteld exact dezelfde gegevens staan (en daardoor zullen ze misschien nalaten dit van een label weg te scheuren of onleesbaar te maken)

[MissingDog]

Detmer schreef op woensdag 11 februari 2026 @ 11:50:
[...]


PostNL heeft tegenwoordig voor sommige categorieën een ontvangstcode: https://www.postnl.nl/kla...et-barcode/ontvangstcode/ . Een mailadres is daarbij verplicht, want zonder code geen pakket.

Zelfs dan hoeft het mailadres niet encoded te worden in de barcode.

[Detmer]

MissingDog schreef op woensdag 11 februari 2026 @ 11:53:
[...]


Zelfs dan hoeft het mailadres niet encoded te worden in de barcode.

Goed punt inderdaad wel. Had ik nog niet zo over nagedacht .

[Qwerty-273]

Razr schreef op woensdag 11 februari 2026 @ 11:50:
Volgens PostNL en hun policy niet: https://www.postnl.nl/privacy-verklaring/

Hier gaat het om het e-mailadres van de ontvanger. De verzender neemt een dienst af van PostNL, vaak digitaal, en daar zal men dus ook een e-mail adres gebruiken om informatie te delen. Die wordt inderdaad gedekt door dat stukje tekst dat je quote.

[Componix]

Bedankt voor de reacties. Even een paar verduidelijkingen:
@Teleluvr: Het verschil is dat naam en adres noodzakelijk zijn voor de bezorging - die moeten op het label staan. Een e-mailadres is dat niet. Bovendien: de meeste mensen beseffen dat hun adres zichtbaar op het pakket staat en kunnen daar bewust mee omgaan (label wegscheuren). Dat hun e-mailadres in de barcode zit weten ze niet, en dat is precies het probleem.

@Razr: Dat stuk uit de privacyverklaring gaat over de gegevens van de verzender die een overeenkomst aangaat met PostNL. Het e-mailadres in de barcode is dat van de ontvanger. Die heeft geen overeenkomst met PostNL. PostNL verwerkt die gegevens onder "gerechtvaardigd belang" en noemt daar inderdaad e-mailadres — maar informeert nergens dat dit in een fysiek uitleesbare barcode op het pakket terechtkomt.

@Detmer: De ontvangstcode is een goed voorbeeld van waarom PostNL het e-mailadres van de ontvanger nodig heeft. Maar zoals MissingDog terecht opmerkt: dat kan prima server-side. PostNL kent de koppeling tussen barcodenummer en ontvanger in hun systeem. Er is geen technische reden om het e-mailadres mee te coderen in de fysieke barcode.

De kern van het probleem zit hem niet in de vraag of PostNL e-mailadressen mag verwerken — dat mogen ze voor bepaalde doeleinden. Het gaat erom dat ze het onversleuteld in een fysiek uitleesbaar medium stoppen zonder dat de ontvanger daarvan op de hoogte is. In hun eigen privacyverklaring staat dat ze persoonsgegevens "versleuteld opslaan waar het kan". Deflate-compressie is geen encryptie.

[jadjong]

Teleluvr schreef op woensdag 11 februari 2026 @ 11:42:
Hoe is dit, afgezien van je E-mailadres, anders dan wanneer het adres op het pakket geschreven staat?

In theorie hoeft er niet eens een adres in de barcode te staan. De code zou genoeg moeten zijn om met de scanner een DB query te doen en daar volgt dan het adres uit. Vanwege praktische overwegingen(offline scanners) is dat niet gedaan.

[TimDJ]

Melden bij autoriteit persoonsgegevens ?

[Yorinn]

Dit is meer een onderwerp voor Privacy & Beveiliging, ik verhuis het topic die kant.

[F_J_K]

TimDJ schreef op woensdag 11 februari 2026 @ 12:18:
Melden bij autoriteit persoonsgegevens ?

Nee, bij de FG van PostNL. Alleen de AP een tip geven als er geen bevredigend antwoord komt.

En inderdaad: min of meer openbaar het adres tonen lijkt me prima uit te leggen (bezorgen moet ook kunnen als er geen databereik is), mailadres min of meer openbaar is nooit nodig (want niet bruikbaar als geen databereik).

[CH4OS]

Componix schreef op woensdag 11 februari 2026 @ 11:39:
WAT IK NIET HEB GEVONDEN

Ik heb uitgebreid gezocht op Tweakers, Radar-forum, Security.nl en in internationale bronnen. Er zijn wel discussies over PostNL en privacy (QR-code scannen bij pakketpunten, metadata van brieven, clipboard-uitlezing door de app), maar het feit dat het e-mailadres onversleuteld in de barcode op het pakketlabel staat lijkt nog nergens publiek beschreven te zijn.

ADVIES

- Scheur altijd het label van je pakket voordat je de doos weggooit
- Overweeg bij webshops een apart e-mailadres te gebruiken voor bestellingen
- PostNL zou de data in de barcode moeten versleutelen, of op z'n minst het e-mailadres eruit moeten halen -- het is niet nodig voor de bezorging

Ik ben benieuwd of anderen dit kunnen bevestigen met hun eigen pakketlabels.

Ik begrijp het doel van het topic niet helemaal. Wat wil je nu precies alhier bespreken? Het bericht komt op mij vooral over om te bashen richting PostNL, terwijl zij ook gewoon een Functionaris Gegevensbescherming (FG) hebben. Heb je die toevallig ook gesproken, bijvoorbeeld? Aldus hun privacy verklaring kan je die per e-mail bereiken op [e-mail].

Verder lijkt het me vooral een ding om iemand te kunnen bereiken wanneer diens pakket niet bestelbaar is (bezorgd kan worden) en om contact gegevens te hebben, ook als er geen verbinding is kan dan een bericht klaargezet worden voor dat e-mail adres of op de app, zodat het bericht verzonden kan worden wanneer er wel verbinding is, bijvoorbeeld. Men zal vast een reden hebben, die de FG waarschijnlijk prima uitleggen kan.

[ Voor 25% gewijzigd door CH4OS op 11-02-2026 14:28 ]

[BytePhantomX]

We zijn wel goed geworden om intussen de kleinst mogelijke potentiële privacyschendingen te vinden en groot te maken. Complimenten dat je hebt kunnen achterhalen dat deze data er in zit, maar dit is, zelfs na jou uitleg, bepaald niet voor veel mensen uitvoerbaar.

Maak je je hier druk over, zorg dan dat je unieke email adressen gebruikt voor elke dienst en je neemt het heft in eigen handen. Voor de rest van Nederland die toch al op Facebook zit en Insta gebruikt, is dit een risico in ieder geval niet begrepen wordt en ze vaak ook niet zal interesseren.

De ontvangstcode is een goed voorbeeld van waarom PostNL het e-mailadres van de ontvanger nodig heeft. Maar zoals MissingDog terecht opmerkt: dat kan prima server-side. PostNL kent de koppeling tussen barcodenummer en ontvanger in hun systeem. Er is geen technische reden om het e-mailadres mee te coderen in de fysieke barcode.

PostNL heeft duidelijk het email adres nodig in het proces dat zij hebben ingericht. En net als met voetbal, staan er veel coaches langs de kant die zonder context en met veel aannames beter weten hoe het perfect ingericht kan worden. En ja, soms hebben die gelijk, maar vaak ook niet. In dit geval lijkt het mij op zijn minst lastig om op basis van enkele aannames en heel beperkte info te kunnen concluderen dat dit een onterechte verwerking zou zijn.

1. Geen encryptie.
Waar is dat een specifieke eis in de AVG? Waarom zou hier encryptie moeten worden toegepast? Het huisadres is ook zichtbaar. Je zou kunnen stellen dat je dat ook kan versleutelen op een etiket en dat een postbezorger dan maar alles moet scannen om het adres te achterhalen. Waar is dan de balans tussen werkbaar en privacy. Daarnaast heeft in principe geen enkele derde toegang tot het pakket. Het is van de leverancier, postbezorger en jouw huis. Hoe kun je hier op grote schaal data harvesten? Zal maximaal 1 of een enkel gegeven zijn.

2. Meer data dan zichtbaar
Wat is hier nu het punt? Heb je liever dat ze het in plain tekst op de doos zetten? Het is duidelijk bedoeld voor een systeem verwerking, niet voor iemand om te kunnen lezen. En dan is base64 encoding een legitieme manier om iets machineleesbaar te maken.

3. Data minimalisatie
Ik weet vrijwel zeker dat PostNL haar dienst niet alleen omschrijft als het bezorgen van een pakje. De dienst is ook het informeren van de gebruiker over de voortgang. Ik zou verwachten van niet, maar misschien slaat PostNL wel geen centraal email adres op en hebben ze het op deze manier nodig om jou een mail te sturen. Dat zou juist data minimalisatie zijn.

4. Transparantie
PostNL en de partij waar je koopt zeggen toch dat ze jouw email adres nodig hebben voor het uitvoeren van de dienst. Daarmee zijn ze toch transparant in het feit dat ze je email adres verwerken. Moeten ze van a tot z uitleggen wat ze met jouw data doen? In welke systemen het wordt opgeslagen etc. Dat is zeker geen eis in de AVG om dat te delen.

5. Praktisch risico
Zou je niet denken dat een pakje van Coolblue met jouw naam en adres misschien een groter risico is dan je email adres? Als je een laptop bestelt, is dat vaak goed zichtbaar en als iemand kwaad wil, weten ze precies waar ze het op kunnen halen. Wat is dan nog het extra praktische risico van een email adres? Phishing? Dat wil je doen op 1000-en email adressen, niet op een enkele. En daar zijn genoeg datalekken voor te vinden of te kopen die veel effectiever zijn.

Grote kans dat PostNL een DPIA heeft gedaan, mogelijk wel een risico ziet, maar dat het base64 encoden prima mitigerende maatregel is en dat daarnaast een belang is om het het email adres te gebruiken voor het uitvoeren van de dienstverlening. Vrijwel zeker dat een FG iets in die trant terug gaat communiceren en daarmee het dossier sluit.
---------
Einde van mijn rant

[Componix]

Ik waardeer de uitgebreide reactie, maar er zitten een paar aannames in die ik wil rechtzetten.

"Bepaald niet voor veel mensen uitvoerbaar" — dat is nu zo. Maar de stap van "iemand post een script online" naar "iemand bouwt een scan-app" is klein. Het gaat niet om wat vandaag praktisch is, maar om wat morgen triviaal kan zijn. Privacy beoordeel je niet op basis van de huidige drempel, maar op het risico.

Over je punten:

De AVG vereist geen encryptie als specifieke maatregel, maar art. 32 vereist wel "passende technische maatregelen" afgestemd op het risico. Het zichtbare adres is noodzakelijk voor de bezorging. Een e-mailadres heeft geen functie op het fysieke label — het is een extra persoonsgegeven dat zonder technische noodzaak wordt meegegeven in een medium dat fysiek toegankelijk is voor derden.

Base64 is geen beveiligingsmaatregel, het is een encoderingsformaat — vergelijkbaar met UTF-8. Jij noemt het zelf een "mitigerende maatregel" in de context van een DPIA, maar geen enkele DPO zou base64 als risicoverlaging accepteren. Het enige wat het doet is de data niet direct leesbaar maken voor het blote oog. Dat is iets anders dan bescherming.

PostNL slaat e-mailadressen wel degelijk centraal op. Ze sturen track & trace-mails, bezorgnotificaties en ontvangstcodes — dat gaat allemaal server-side via hun systemen, gekoppeld aan het barcodenummer. Juist daarom is het overbodig om het e-mailadres ook nog in de fysieke barcode te stoppen. Het argument dat dit "juist dataminimalisatie zou zijn" klopt dus niet: het is het tegenovergestelde.

Transparantie betekent niet dat PostNL al hun systemen moet beschrijven. Het betekent dat een betrokkene redelijkerwijs kan verwachten hoe zijn gegevens worden verwerkt. Niemand verwacht dat zijn e-mailadres fysiek uitleesbaar op een pakket staat. Dat PostNL ergens in hun privacyverklaring "e-mailadres" noemt in de context van bezorging maakt het niet transparant als de specifieke verwerking — opnemen in een fysiek uitleesbare barcode — nergens wordt vermeld.

Je hebt gelijk dat bulk phishing op datalekken draait, niet op individuele labels. Maar gerichte phishing (spear phishing) werkt juist met kleine hoeveelheden specifieke data. "Beste [naam], je bestelling bij [webshop] is vertraagd" — met naam, adres en e-mailadres van een recent pakket heb je alles voor een overtuigend bericht. Dat is een ander dreigingsmodel.

Over de DPIA: goed mogelijk dat PostNL die heeft gedaan. Ik ben dan benieuwd naar de uitkomst, want als "base64 encoding" daarin als mitigerende maatregel staat, is die DPIA aan herziening toe.

[P1nGu1n]

@Componix heb je deze vraag al uitgezet bij de FB van PostNL, of ga je dat nog doen? Want dat is, zoals al genoemd, stap 1.

[CH4OS]

Componix schreef op woensdag 11 februari 2026 @ 15:50:
Over je punten:

De AVG vereist geen encryptie als specifieke maatregel, maar art. 32 vereist wel "passende technische maatregelen" afgestemd op het risico. Het zichtbare adres is noodzakelijk voor de bezorging. Een e-mailadres heeft geen functie op het fysieke label — het is een extra persoonsgegeven dat zonder technische noodzaak wordt meegegeven in een medium dat fysiek toegankelijk is voor derden.

Waar maak je uit op dat het niet nodig is voor de verwerking van het pakket totdat het door de postbezorger wel bezorgt kan worden, dat de gegevens niet nodig zijn? Heb je zicht op het gehele proces van PostNL?

Is dat alleen het adres dat op het label staat? Daarnaast heeft PostNL ook wettelijke plichten, zij zijn immers de aangewezen partij (in principe) die de posterijen voor Nederland uitvoeren. Wellicht is er dus een wettelijke eis waardoor deze informatie in het label staat, zodat het machinaal verwerkt kan worden.

Base64 is geen beveiligingsmaatregel, het is een encoderingsformaat — vergelijkbaar met UTF-8. Jij noemt het zelf een "mitigerende maatregel" in de context van een DPIA, maar geen enkele DPO zou base64 als risicoverlaging accepteren. Het enige wat het doet is de data niet direct leesbaar maken voor het blote oog. Dat is iets anders dan bescherming.

Base64 is zeker niet hetzelfde als UTF-8, vergelijk het dan met MD5 of zo. Je kunt prima UTF-8 of zelfs -16 of -32 characters in een base64 codering zetten. Ik gok zomaar, dat PostNL een boel machinaal verwerkt en daarom een boel extra informatie in het label opslaat, nog voordat de bezorger het bij jou thuis bezorgt. Ik kan mij dan ook voorstellen dat men zoveel mogelijk informatie heeft en omdat de verwerking ook zo hoog moet liggen voor de machines, dat base64 gebruiken nu eenmaal sneller is dan een GPG ervan te maken, wat ook weer keys e.d. nodig heeft.

PostNL slaat e-mailadressen wel degelijk centraal op. Ze sturen track & trace-mails, bezorgnotificaties en ontvangstcodes — dat gaat allemaal server-side via hun systemen, gekoppeld aan het barcodenummer. Juist daarom is het overbodig om het e-mailadres ook nog in de fysieke barcode te stoppen. Het argument dat dit "juist dataminimalisatie zou zijn" klopt dus niet: het is het tegenovergestelde.

Wie zegt dat al die zaken in 1 (centrale en daarmee logge) database staan?

Transparantie betekent niet dat PostNL al hun systemen moet beschrijven. Het betekent dat een betrokkene redelijkerwijs kan verwachten hoe zijn gegevens worden verwerkt. Niemand verwacht dat zijn e-mailadres fysiek uitleesbaar op een pakket staat. Dat PostNL ergens in hun privacyverklaring "e-mailadres" noemt in de context van bezorging maakt het niet transparant als de specifieke verwerking — opnemen in een fysiek uitleesbare barcode — nergens wordt vermeld.

Maar iedereen verwacht wel dat PostNL snel en goedkoop bezorgd, dat betekent dat er links- of rechtsom concessies moeten worden gemaakt. Wil je wel een top of the line beveiliging, zal je veel dieper in de buidel moeten tasten, ik denk dat dat in combinatie met snelheid en lage kosten redelijk een utopie is. Of een andere partij kiezen voor verzendingen, die dan waarschijnlijk net zo goed duurder is.

Nogmaals, stel jouw vragen aan [e-mail] en je krijgt ongetwijfeld een uitgebreider antwoord dan mening Tweaker je alhier met aannames kan geven.

[ Voor 4% gewijzigd door CH4OS op 11-02-2026 16:10 ]

[Componix]

@CH4OS: Ik heb de FG inmiddels gemaild, dus die stap is gezet. Ik koppel hier terug als daar een reactie op komt.

Kort op je inhoudelijke punten: de fysieke barcode wordt gebruikt voor routering en sortering. Daar is een e-mailadres niet voor nodig. Track & trace-mails en notificaties draaien server-side, gekoppeld aan het barcodenummer — die koppeling bestaat al. En de eenvoudigste oplossing is niet encryptie, maar het e-mailadres er gewoon niet in zetten.

Maar goed, ik werk inderdaad met aannames over de interne processen van PostNL — net als jij trouwens. Laten we kijken wat de FG ervan zegt.

[CH4OS]

Componix schreef op woensdag 11 februari 2026 @ 16:10:
Kort op je inhoudelijke punten: de fysieke barcode wordt gebruikt voor routering en sortering. Daar is een e-mailadres niet voor nodig. Track & trace-mails en notificaties draaien server-side, gekoppeld aan het barcodenummer — die koppeling bestaat al. En de eenvoudigste oplossing is niet encryptie, maar het e-mailadres er gewoon niet in zetten.

Maar je beantwoord de vraag niet; waaruit maak jij op dat dat zo is wat je zegt? Voor hetzelfde geld heeft de PostNL een wettelijke plicht hiervoor. Dus stellen dat het e-mailadres er niet voor in te zetten de oplossing is, is gewoon (te) kort door de bocht.

Begrijp me niet verkeerd, voor de fysieke bezorging door de bezorger op het opgegeven adres is het e-mailadres niet nodig, dat ben ik zeker met je eens. Maar voordat het bij jou thuis is, is er wellicht wel een lange weg afgelegd. Ook die weg zal ongetwijfeld voorwaarden kennen en dat kan ook best vanuit de Wet iets zijn bijvoorbeeld. Maar zolang we dat niet weten, lijkt het vooral op stampij maken, een storm in een glas water.

[ Voor 30% gewijzigd door CH4OS op 11-02-2026 16:22 ]

[Jazzy]

Titel even iets aangepast, het woord 'barcode' was bij een eerdere aanpassing weggevallen.

Welkom op het forum van Tweakers.net, @Componix. Goede stap om de FG aan te schrijven om te horen of PostNL vindt dat ze een goede reden hebben om dat mailadres in de barcode op te slaan.

Overigens is het optioneel om het mailadres van de ontvanger mee te geven bij een verzendopdracht.

[BytePhantomX]

PostNL slaat e-mailadressen wel degelijk centraal op. Ze sturen track & trace-mails, bezorgnotificaties en ontvangstcodes — dat gaat allemaal server-side via hun systemen, gekoppeld aan het barcodenummer. Juist daarom is het overbodig om het e-mailadres ook nog in de fysieke barcode te stoppen. Het argument dat dit "juist dataminimalisatie zou zijn" klopt dus niet: het is het tegenovergestelde.

1. Aanmaken label -> eenmalige mail, opslaan niet nodig.
2. Pakket ontvangen -> scan van het label, email versturen op basis van die data
3. Pakket in soorteercentrum -> scan, email vesturen op basis van data op het label
4. Pakket ingeladen in de bus -> weer een scan
5. Pakket bezorgd -> weer een scan

Zonder dat wij het proces weten, zou het zomaar kunnen dat dit juist de data minimalisatie is. En waar ik eerst dacht dat ze het daadwerkelijk centraal opslaan, begin ik daar na het uitschrijven van de proces, eigenlijk aan te twijfelen. Wat mij betreft hebben ze het dan juist privacy vriendelijk ingericht.

En Base64 is zeker een maatregel. Het is geen encryptie, en ik weet ook zeker dat bij PostNL mensen werken die het niet als encryptie bedoeld hebben. Het maakt echter wel dat iemand het niet zomaar kan lezen en een extra handeling moet doen. Daarmee maak je het moeilijker. Gezien het risico zou dat weleens een prima maatregel kunnen zijn.

Of email wel of niet een functie heeft, kunnen wij niet weten. Ligt aan het proces van PostNL.

En t.a.v spearphishing. Als het misbruikt wordt, zeker een kans van slagen. Maar er zijn zoveel mogelijkheden die misbruikt kunnen worden. Soms is het ook prima voor een bedrijf om te reageren als zo'n situatie zich voordoet en dan pas maatregelen te nemen.

@Componix je verhaal staat vol aannames en trekt conclusies zonder dat je precies weet hoe het zit. Nogmaals gaaf dat je dit vind, maar daar zulke conclusies aan verbinden en privacy zo principieel benaderen gaat mij echt te ver.

En zelfs als je enigszins gelijk hebt, was is dan nu echt het risico. Een hele kleine kans dat een enkel email adres uitlekt? Ja principieel zou het allemaal niet moeten, maar AVG is op basis van risico afwegingen en ik zie niet in dat PostNL hier een andere risicoafweging zou moeten maken.

[Jazzy]

CH4OS schreef op woensdag 11 februari 2026 @ 12:51:
Het bericht komt op mij vooral over om te bashen richting PostNL,

CH4OS schreef op woensdag 11 februari 2026 @ 16:15:
lijkt het vooral op stampij maken, een storm in een glas water.

De toon mag een stukje minder aanvallend, dank u. Kritisch zijn is één, maar laten we uitgaan van elkaars goede intenties. Ook in het kader van .plan: Wij willen een vriendelijker Tweakers

[Componix]

CH4OS schreef op woensdag 11 februari 2026 @ 16:15:
[...]
Maar je beantwoord de vraag niet; waaruit maak jij op dat dat zo is wat je zegt? Voor hetzelfde geld heeft de PostNL een wettelijke plicht hiervoor. Dus stellen dat het e-mailadres er niet voor in te zetten de oplossing is, is gewoon (te) kort door de bocht.

Ik heb de barcodedata verder geanalyseerd en de structuur kunnen mappen op PostNL's eigen Shipping API-documentatie (developer.postnl.nl).
Bijvoorbeeld de strings "006", "118" en "015" in de data zijn geen sorteer- of routeringscodes, maar ProductOption-codes die PostNL zelf documenteert:

characteristic 118, option 006 = avondlevering
characteristic 118, option 015 = sameday delivery

De barcode blijkt een geserialiseerd Shipment-object te bevatten van 315 bytes, met onder andere boolean flags voor verzendopties, een 16-byte interne identifier, productopties, NAW-gegevens, en als laatste veld: het e-mailadres.
Wat hieruit blijkt is dat PostNL het volledige Shipment API-object in de barcode serialiseert — inclusief velden die duidelijk bedoeld zijn voor server-side verwerking, zoals bezorgtype en interne identifiers. Het e-mailadres zit erin als onderdeel van het Contacts-object uit de API, niet omdat het een functie heeft op het fysieke label, maar omdat het gehele object zonder filtering wordt weggeschreven.

[Componix]

BytePhantomX schreef op woensdag 11 februari 2026 @ 16:32:
[...]


1. Aanmaken label -> eenmalige mail, opslaan niet nodig.
2. Pakket ontvangen -> scan van het label, email versturen op basis van die data
3. Pakket in soorteercentrum -> scan, email vesturen op basis van data op het label
4. Pakket ingeladen in de bus -> weer een scan
5. Pakket bezorgd -> weer een scan

Zonder dat wij het proces weten, zou het zomaar kunnen dat dit juist de data minimalisatie is. En waar ik eerst dacht dat ze het daadwerkelijk centraal opslaan, begin ik daar na het uitschrijven van de proces, eigenlijk aan te twijfelen. Wat mij betreft hebben ze het dan juist privacy vriendelijk ingericht.

En Base64 is zeker een maatregel. Het is geen encryptie, en ik weet ook zeker dat bij PostNL mensen werken die het niet als encryptie bedoeld hebben. Het maakt echter wel dat iemand het niet zomaar kan lezen en een extra handeling moet doen. Daarmee maak je het moeilijker. Gezien het risico zou dat weleens een prima maatregel kunnen zijn.

Of email wel of niet een functie heeft, kunnen wij niet weten. Ligt aan het proces van PostNL.

En t.a.v spearphishing. Als het misbruikt wordt, zeker een kans van slagen. Maar er zijn zoveel mogelijkheden die misbruikt kunnen worden. Soms is het ook prima voor een bedrijf om te reageren als zo'n situatie zich voordoet en dan pas maatregelen te nemen.

@Componix je verhaal staat vol aannames en trekt conclusies zonder dat je precies weet hoe het zit. Nogmaals gaaf dat je dit vind, maar daar zulke conclusies aan verbinden en privacy zo principieel benaderen gaat mij echt te ver.

En zelfs als je enigszins gelijk hebt, was is dan nu echt het risico. Een hele kleine kans dat een enkel email adres uitlekt? Ja principieel zou het allemaal niet moeten, maar AVG is op basis van risico afwegingen en ik zie niet in dat PostNL hier een andere risicoafweging zou moeten maken.

Interessant punt over het proces, en ik snap de redenering. Maar er zitten een paar problemen in.
Over het scanproces en dataminimalisatie:
Het scenario dat je schetst — bij elke scan het e-mailadres uit het label lezen en direct een mail sturen — zou betekenen dat PostNL bij iedere statusupdate de barcode decodeert, het e-mailadres eruit haalt en een mail verstuurt, zonder dat adres ergens op te slaan. Dat is technisch mogelijk, maar niet realistisch. PostNL biedt via Mijn PostNL een compleet overzicht van al je zendingen, inclusief bezorgvoorkeuren, afleverlocaties en notificatie-instellingen. Dat werkt niet als ze per scan alles weggooien. Ze koppelen zendingen aan accounts — dat is per definitie centrale opslag.
Maar zelfs áls jouw scenario zou kloppen: dan verwerk je bij iedere scan opnieuw een persoonsgegeven dat fysiek op een label staat dat door tientallen handen gaat, op transportbanden ligt, in sorteercentra en busjes. Dat is niet dataminimalisatie, dat is hetzelfde gegeven maximaal blootstellen.
Over base64 als maatregel:
Base64 is een coderingsformaat, net als UTF-8 of ASCII. Het is bedoeld om binaire data als tekst te kunnen transporteren, niet om iets te beschermen. Dat het een "extra handeling" vereist is waar, maar die handeling is één regel code of een gratis online tool. Geen enkele functionaris gegevensbescherming accepteert encoding als beveiligingsmaatregel in een DPIA. Het NCSC en de AP hanteren dezelfde lijn: encoding ≠ beveiliging.
Over aannames:
Ik baseer me op PostNL's eigen API-documentatie op developer.postnl.nl. De structuur van de barcodedata komt exact overeen met hun Shipment API-object — inclusief ProductOption-codes die PostNL zelf documenteert (characteristic 118, option 006 = avondlevering). Dat is geen aanname, dat is reverse engineering aan de hand van hun eigen publieke documentatie.

Over risico-afweging:
De AVG vraagt inderdaad om een risico-afweging, maar dan een vooraf, niet achteraf. "We wachten wel tot het misgaat" is precies het tegenovergestelde van wat de AVG voorschrijft. Artikel 25 (privacy by design) en artikel 32 (passende maatregelen) vereisen dat je risico's voorkomt, niet dat je ze repareert nadat ze zich voordoen. En het risico is niet "een enkel e-mailadres dat uitlekt" — het is een structureel ontwerpbesluit dat op miljoenen labels per dag wordt toegepast.

[BytePhantomX]

Componix schreef op woensdag 11 februari 2026 @ 16:35:
[...]

Ik heb de barcodedata verder geanalyseerd en de structuur kunnen mappen op PostNL's eigen Shipping API-documentatie (developer.postnl.nl).
Bijvoorbeeld de strings "006", "118" en "015" in de data zijn geen sorteer- of routeringscodes, maar ProductOption-codes die PostNL zelf documenteert:

characteristic 118, option 006 = avondlevering
characteristic 118, option 015 = sameday delivery

De barcode blijkt een geserialiseerd Shipment-object te bevatten van 315 bytes, met onder andere boolean flags voor verzendopties, een 16-byte interne identifier, productopties, NAW-gegevens, en als laatste veld: het e-mailadres.
Wat hieruit blijkt is dat PostNL het volledige Shipment API-object in de barcode serialiseert — inclusief velden die duidelijk bedoeld zijn voor server-side verwerking, zoals bezorgtype en interne identifiers. Het e-mailadres zit erin als onderdeel van het Contacts-object uit de API, niet omdat het een functie heeft op het fysieke label, maar omdat het gehele object zonder filtering wordt weggeschreven.

Het wordt voor mij steeds aannemelijker dat ze dit wegschrijven op het pakket omdat ze het nodig hebben voor het proces. Bijvoorbeeld omdat ze (een deel van) dat proces zonder server willen kunnen uitvoeren.

Misschien is er wel een centrale database waarin ze dit opslaan, maar is de email functionaliteit voor performance redenen een aparte service en wordt de input van het label gebruikt voor het versturen van de email?
Misschien iets als scan label -> x aantal berichten op een message queue:
- bericht om email te versturen
- bericht om erp te updaten
- bericht voor performance monitoring.

Klinkt mij als een hele moderne manier om applicaties te ontwikkelen en geen centrale monoliet te hebben met allerlei performance problemen.

De AVG vraagt inderdaad om een risico-afweging, maar dan een vooraf, niet achteraf. "We wachten wel tot het misgaat" is precies het tegenovergestelde van wat de AVG voorschrijft. Artikel 25 (privacy by design) en artikel 32 (passende maatregelen) vereisen dat je risico's voorkomt, niet dat je ze repareert nadat ze zich voordoen. En het risico is niet "een enkel e-mailadres dat uitlekt" — het is een structureel ontwerpbesluit dat op miljoenen labels per dag wordt toegepast.

Als ik de risicoafweging zou maken, dan zou op basis van het label enkele gegevens uitlekken. Het is namelijk ondoenlijk om zoveel labels te scannen en te verzamelen. Dan zou iemand dat zoveel moeten doen dat die niet meer aan werken toekomt, of je moet op PostNL in de sorteerstraat je eigen camera's gaan ophangen. Een bulk lek is m.i. onrealistisch.
Daarnaast moet je voor de AVG bepalen wat dan de impact zou zijn op betrokkenen. Die is m.i. klein. Het is een email adres, geen bijzonder persoonsgegeven. Dus kans is klein en impact is klein. Je maakt het daarnaast voor mensen onleesbaar (je hebt een app nodig die nog niet bestaat) en je komt m.i. terecht tot de conclusie dat verdere maatregelen niet nodig zijn en als het nodig is voor het proces, dat het een terechte verwerking is.
Daarnaast, je volledige naam en adres staat al leesbaar op het pakket. Het toevoegen van een, voor een mens onleesbaar, email adres is wat mij betreft amper risicoverhogend.

[ Voor 27% gewijzigd door BytePhantomX op 11-02-2026 16:52 ]

[Acid Vendetta]

Detmer schreef op woensdag 11 februari 2026 @ 11:50:
[...]


PostNL heeft tegenwoordig voor sommige categorieën een ontvangstcode: https://www.postnl.nl/kla...et-barcode/ontvangstcode/ . Een mailadres is daarbij verplicht, want zonder code geen pakket.

Als de barcode toegevoegd wordt in de PostNL app van de ontvanger ziet diegene de ontvangstcode. Geen email nodig.. Al lijkt het wel zo.

[CH4OS]

Componix schreef op woensdag 11 februari 2026 @ 16:35:
[...]

Ik heb de barcodedata verder geanalyseerd en de structuur kunnen mappen op PostNL's eigen Shipping API-documentatie (developer.postnl.nl).
Bijvoorbeeld de strings "006", "118" en "015" in de data zijn geen sorteer- of routeringscodes, maar ProductOption-codes die PostNL zelf documenteert:

characteristic 118, option 006 = avondlevering
characteristic 118, option 015 = sameday delivery

De barcode blijkt een geserialiseerd Shipment-object te bevatten van 315 bytes, met onder andere boolean flags voor verzendopties, een 16-byte interne identifier, productopties, NAW-gegevens, en als laatste veld: het e-mailadres.
Wat hieruit blijkt is dat PostNL het volledige Shipment API-object in de barcode serialiseert — inclusief velden die duidelijk bedoeld zijn voor server-side verwerking, zoals bezorgtype en interne identifiers. Het e-mailadres zit erin als onderdeel van het Contacts-object uit de API, niet omdat het een functie heeft op het fysieke label, maar omdat het gehele object zonder filtering wordt weggeschreven.

Dus het is in de ochtend niet belangrijk om te weten dat samedaydelivery aan staat bij een pakket? Ik kan mij best voorstellen dat er een reden is dat dat ook in het label zit en niet server-side opgehaald hoeft te worden iedere keer, elke keer opnieuw wanneer een pakket langs een scanner komt. Je lijkt wat dat betreft teveel als een back-end ontwikkelaar te denken, waar dit proces niet (uitsluitend) op gemaakt is.

Hou er rekening mee, dat de post- en pakketbezorging met dit soort labels gewoon doorgang kan vinden, zonder dat er altijd een back-end beschikbaar moet zijn, want ook dat is ook in 2026 geen garantie dat de back-end altijd en eeuwig beschikbaar is. Storingen kunnen ook langdurig zijn, maar PostNL heeft wel de Wet die zegt dat men bepaalde post binnen een bepaalde tijd moeten bezorgen.

Sterker nog, er zijn zelfs speciale diensten van PostNL die zorgen dat jij op Maandag altijd een rouwkaart kan krijgen bijvoorbeeld. Goed, dat is weliswaar niet de casus die je hier aanhaalt, maar geeft wel aan dat er zaken zijn waaraan PostNL moet voldoen en wat ook bij een lange downtime van de back-end werken moet.

[ Voor 22% gewijzigd door CH4OS op 11-02-2026 18:35 ]