E-mailbeveiligingsprotocollen DKIM, DMARC en Dane

E-mail is niet meer weg te denken uit de hedendaagse wereld. Dagelijks worden er wereldwijd ongeveer 250 biljoen e-mails verzonden waarvan ongeveer 60% zakelijke e-mails zijn en 40% privé e-mails. Dat betekend zo’n 2.5 miljoen e-mails per seconde. E-mail is ons grootste communicatiekanaal en het ziet er niet naar uit dat dit de komende tijd gaat veranderen. E-mail is by-design ook een zeer onveilig medium. Standaard is e-mail ongeveer vatbaar voor elke denkbare hack, onderschepping, vervalsing, fraude etc. Om e-mail toch wat veiliger te maken zijn er een aantal protocollen. Vanuit diverse hoeken probeert men het gebruik van deze protocollen te stimuleren. Zo zijn overheden verplicht om v.a. 2020 o.a. een strikte DMARC policy te hanteren en om DANE te implementeren. Maar om dit goed te doen moet je wel weten wat deze protocollen inhouden. En dat… lees je natuurlijk in deze post!

Mocht je mijn blog volgen dan weet je dat ik dit onderwerp al een keer behandeld heb, namelijk in deze post: https://jarnobaselier.nl/spf-dkim-dmarc-vechten-tegen-spam-phishing/. In deze post ga ik echter wat dieper op DKIM, DMARC en DANE in en wat minder diep op SPF.

SPF, DKIM, DMARC en DANE? Alle 4 opties zijn (geheel of gedeeltelijk) DNS based beveiligingsmethodes. Laten we ze even kort op een rijtje zetten:

• SPF – Sender Policy Framework. Doel: verminderen van SPAM en fraude.
• DKIM – DomainKeys Identified Mail. Doel: verminderen van SPAM
• DMARC – Domain-based Message Authentication, Reporting and Conformance. Doel: spoofing van e-mail mitigeren.
• DANE – DNS-based Authentication of Named Entities. Doel: het afdwingen van cryptografische oplossingen (STARTTLS).

Hoewel we deze post het meeste zullen inzoomen op DMARC en DANE is het handig om toch nog even SPF en DKIM te bespreken. Op deze manier krijg je een compleet beeld en is het makkelijk om DMARC en DANE te begrijpen en dus ook te implementeren.

SPF – Sender Policy Framework

SPF stond vroeger voor “Sender Permitted From” omdat SPF primair bedoeld is voor de beveiliging van het “From” veld. Dit veld stelt iedere e-mail gebruiker in staat om e-mail te verzenden namens een willekeurig persoon. Op het moment dat een e-mailserver een e-mail ontvangt dan zal deze kijken in de DNS records van het domein waar de e-mail van afkomstig lijkt te zijn. Als hier een SPF record in aanwezig is zal de inhoud gecontroleerd worden. Als de mailserver aanwezig is in het SPF record dan zal de e-mailserver de ontvangen e-mail aanmerken als SPF PASS. De e-mail zal nu doorgelaten worden. Komt de verzendende e-mailserver niet voor in het SPF record dan zal de verzonden e-mail een SPF FAIL krijgen. Het is vervolgens aan de ontvangen e-mailserver (of spamfilter) om te kijken wat er met deze e-mail gedaan moet worden. Het is dus belangrijk dat bedrijven hun SPF record op orde hebben en dat alle e-mailserver die e-mail namens het bedrijf verzenden hierin aanwezig zijn. Deze servers kunnen aangegeven zijn op naam en op IP. Wanneer een naam gebruikt wordt zal er een DNS lookup plaatsvinden om het IP adres te achterhalen. Let erop dat een SPF record niet meer dan 10 DNS lookups nodig heeft want anders faalt het record. En let op, wanneer je “include” gebruikt zullen ook DNS lookups plaatsvinden van domeinnamen in het SPF record van het domein welke je hier include. Op die manier heb je geen controle meer over het aantal lookups en moet je oppassen niet over de 10 lookups te gaan. Probeer “includes” dan ook zo veel mogelijk te vermeiden.

Een SPF record wordt aangemaakt in DNS als een TXT record en heeft de volgende opbouw:

"v=spf1 a mx ip4:211.181.40.14 include:_spf.marketingmail.nl ~all"

Alle qualifiers voor SPF zijn in mijn vorige blogpost te lezen (https://jarnobaselier.nl/spf-dkim-dmarc-vechten-tegen-spam-phishing/). Het SPF record begint met v=spf1 om aan te duiden dat dit een SPF record is en eindig met een streep (-) FAIL of een tilde (~) SOFTFAIL om aan te geven hoe er omgegaan moet worden met e-mail die afkomstig is van een server die niet aan het SPF record voldoet. Het is aan te raden om de SPF record zo streng mogelijk te maken en dus te sluiten met een streep.

DKIM – DomainKeys Identified Mail

DKIM is an-sich geen anti-spam technologie maar helpt spamfilters wel om de spamscore bij te stellen van een binnenkomend bericht welke zich niet tegenover DKIM geautoriseerd heeft. De DKIM oplossing bestaat uit een privé certificaat en een publiek certificaat. Een server die DKIM gebruikt zal geconfigureerd worden om berichten te ondertekenen met zijn privé sleutel. Het bericht wordt vervolgens ontvangen door een server die DKIM wel of niet ondersteund. Als er geen ondersteuning is dan is er niets aan de hand en wordt de ondertekening genegeerd. Een ontvangende server die wel DKIM ondersteund zal de ondertekening proberen te ontsleutelen. Hiervoor haalt hij de publieke DKIM sleutel op vanuit de DNS server van het verzendende domein. Als de ondertekening ontsleuteld kan worden dan is het bericht geautoriseerd. Na de DKIM ontsleuteling zullen de resultaten van de ontsleuteling geplaatst worden in een nieuwe “Authentication-Results” header. Het is vervolgens aan het spamfiler om een beslissing te maken op basis van deze header.

De publieke DKIM sleutel wordt ook opgenomen in een DNS TXT record. Dit ziet er als volgt uit:

k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCg/402SB9+BVlH6FIZVeVKSVtPHoU7sz/3pJZbdYZShpNLqZa7cwB9oVLBtpKvfZWlMLbKpqb
7XecKjoyP+0d6qh11aDW39Zl94kOZaWhuJtOZvtWPPPxLtJGKMjHEiqDnT7uQ5VfeKJszLwhCIgwW/zEYxopvtBcQvbddSmrD3wIDAQAB

De “k” staat voor het type sleutel en de “p” is de base64 encoded publieke sleutel.

Wanneer een uitgaande e-mailserver een bericht ondertekend zal dat in deze volgorde gebeuren:

Als de header toegevoegd is ziet deze er als volgt uit:
 

• De body van het bericht wordt gehashed
• De headers worden gehashed in de opgegeven volgorde van de “h” tag
• De hashed body en de hashed header worden samen ondertekend met de privé sleutel

Wanneer de ondertekening klaar is wordt deze als volgt opgebouwd en toegevoegd aan uitgaande e-mailbericht:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=voorbeeld.nl; c=relaxed/simple; 
b=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE45tYlPP89uutEPtr33+vM7tN6A5nYAqflz
GbVXayk6stdusH/PgM+mDlQNdfqWXpzULd1ahNm1FtkGwaf/9jFMUKT51T8dK9rbC2yCcPk5aNA
/Gs7597eJlGsNzhztM295HwUYPEO2Rx9JE5ps+M5K27xB5lXgdVqp2907AnSHjk61ri5m2XYRbQ
u7JUN1Wte8DMsqwPKJ3xSfOg+IvNn+TrbVV4322PDFwqvbprG;

• v = DKIM versie.
• a = signing algoritme.
• h = de volgorde van de headers die gehashed worden. Dit ziet er als volgt uit: “from:to:subject:date:keywords:keywords”.
• d = het domein welke de e-mail gesigned moet hebben.
• q = het type DNS record (default is een TXT record).
• s = type selector.
• c = standaardisatie van headers en body algoritmes. Hiermee wordt bepaald of kleine aanpassingen aan de e-mail zijn toegestaan (zoals spaties).
• bh = de hashed body
• t = creatiedatum van header
• x = verloopdatum van header
• b = de uiteindelijke digitale handtekening welke een versleuteling is van de hashed body en hashed headers.

Een DNS TXT record is maar 255 karakters lang. DKIM records kunnen soms langer zijn. Als dat het geval is kun je het record over 2 TXT records verdelen. Hoe je dit doet is afhankelijk van je DNS configuratie tool.

DMARC – Domain-based Message Authentication, Reporting and Conformance

DMARC werkt samen met SPF en DKIM en is ontwikkeld als extra policy om te vertellen wat er moet gebeuren als een e-mail niet voldoet aan je SPF of DKIM string. Door het instellen van een DMARC record bepaald je zelf wat er gebeurt met de e-mail i.p.v. dat je afhankelijk bent van een tussenliggend filter. DMARC bestaat sinds 2012 en valideert net als DKIM en SPF de e-mail ook op basis van een DNS record.

Wanneer DMARC is ingesteld ontvang je als user periodiek XML rapporten die je vertellen hoe DMARC functioneert. Omdat je echter veel e-mail kunt verliezen bij het foutief instellen van DMARC is het aan te raden om DMARC in te stellen op “Monitor Mode”. Dit doe je door de policy in te stellen op “none”. In dit geval wordt de e-mail gewoon doorgestuurd. Naast de “none” waarde kan je DMARC policy nog op 2 waardes worden ingesteld, namelijk:

• quarantine – berichten worden in quarantaine geplaatst (spam / junk folder)
• reject – berichten worden meteen verwijderd en niet verder behandeld

Een compleet DMARC record ziet er als volgt uit:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

• v=DMARC1 – Dit geeft aan dat dit je DMARC record is en dat je DMARC versie 1 gebruikt.
• sp – De sp tag gebruik je als het DMARC record door een subdomein gebruikt wordt. Je hebt hier net als met de p tag de opties “none” – “quarantine” en “reject”.
• pct – De pct tag staat voor “percentage”. Je kunt b.v. 50% van alle e-mails die falen verwijderen als je 100% te hoog vindt. In dat geval gebruik je p=reject en pct=50. Default is de pct waarde 100.
• rua = In de rua tag geef je de e-mailadressen op waar de XML rapportages naartoe gestuurd mogen worden. Wanneer een rua (of ruf) adres een extern e-mailadres is moet het externe domein een DMARC record hebben welke toestaat om de rapportages te ontvangen.
• ruf = In de ruf tag geef je de forensische e-mailadressen op waar de forensische XML rapportages naartoe gestuurd mogen worden.
• ri = Hier geef je de interval aan van de te ontvangen rapportages. Dit is een voorkeur setting. De default waarde is 86400. Deze waarde is in secondes en staat gelijk aan 1 dag. Je kunt deze waarde aanpassen maar de provider kan deze overrulen en de rapportages op dagelijkse basis versturen.
• aspf – Deze tag geeft aan wat je wilt doen als het SPF record een fail geeft. Deze kun je intellen als strict (s) (100% match en andere is het een fail) of als relaxed (r) waarbij een gedeeltelijke overeenkomst van het SPF record ook akkoord is.
• adkim – Deze tag specificeert wat er moet gebeuren als het DKIM record faalt. Net als bij het aspf record kennen we hier een strict (s) en een relaxed (r) setting.
• rf – Geeft de indeling aan voor forensische XML rapportages (ruf). De standaardinstelling is “Authentication Failure Reporting Format”. Ook wordt de “afrf” indeling ondersteund.
• fo – Met deze tag laat je aan de provider weten welke XML rapportages (rua) je wilt ontvangen. Er zijn 4 opties:
  0: Genereert een DMARC failure rapportage als SPF of DKIM gaan “pass” resultaat hebben.
  1: Genereert een DMARC failure rapportage als SPF en DKIM gaan “pass” resultaat hebben. Dit is de default waarde.
  d: Genereert een DMARC failure rapportage als het bericht een DKIM signature had welke niet geëvalueerd kon worden.
  s: Genereert een DMARC failure rapportage als SPF niet geëvalueerd kon worden.

Bij en DMARC record zijn alleen de v en p tags verplicht. Om DMARC goed te implementeren zou je het volgende scenario kunnen hanteren:

1. Monitoring mode

v=DMARC1; p=none; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

2. Quarantaine Mode 20%

v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

3. Quarantaine Mode 50%

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

4. Quarantaine Mode 100%

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

5. Strict mode 25%

v=DMARC1; p=strict; pct=25; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

6. Strict mode 50%

v=DMARC1; p=strict; pct=50; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

7 Strict mode 100%

v=DMARC1; p=strict; rua=mailto:dmarcreports@voorbeeld.nl; ruf=mailto: dmarcforensicreports@voorbeeld.nl

E-mail XML rapportages laten aan de gebruiker zien wat de status is per source IP. Hoeveel e-mails er ontvangen zijn en waarop de e-mail een pass of een fail heeft gekregen (SPF en/of DKIM). Ook laaat de rapportage zien of de e-mail uiteindelijk is doorgestuurd.

Forensische XML rapportages, ook wel “fail reports” genoemd, worden realtime gegenereerd en bestaan uit bewerkte kopieën van afzonderlijke e-mails die op basis van SPF, DKIM of beide zijn gefaald. De indeling van deze rapportages is vergelijkbaar met die van reguliere bounces. Deze rapportages bestaan uit een “bericht / rfc822” of een “tekst / rfc822-headers” opbouw.

DANE – DNS-based Authentication of Named Entities

We kunnen het eigenlijk niet over DANE hebben zonder het eerst over (START)TLS te hebben. TLS is namelijk een belangrijk protocol waar DANE beheer over voert.

TLS is een methode om beveiligde gegevensuitwisseling via TLS (Transport Layer Security) toe te voegen aan een bestaand netwerkprotocol (met backward compatibility). TLS kan o.a. gebruikt worden binnen XMPP, LDAP, IMAP, POP3 en SMTP. STARTTLS is de methode die gebruikt wordt om een “onveilige / platte” verbinding te upgraden naar een verbinding over TLS. Een verbinding die geüpgrade wordt door STARTTLS versleuteld dus berichten waardoor deze niet meer leesbaar zijn voor een niet-legitieme ontvanger of man-in-the-middle.

Wanneer STARTTLS gebruikt wordt voor de beveiliging van e-mail (SMTP) worden er certificaten gebruikt van beide mailservers. Het mooie van STARTTLS in tegenstelling tot andere technieken zoals PKI of PGP is dat het certificaat van de “tegenpartij” niet reeds aanwezig hoeft te zijn. Dit voorkomt vele handmatige acties. Voor STARTTLS moet de mailserver voorzien worden van een certificaat en er moet worden aangegeven dat STARTTLS gebruikt kan worden. Als de corresponderende server ook voorzien is STARTTLS dan zullen sleutels worden uitgewisseld. Als de corresponderende server niet voorzien is van STARTTLS capaciteit dan wordt de reguliere (onbeveiligde) e-mail methode (plain SMTP) worden gebruikt.

Het kan echter zo zijn dat een zogenaamde man-in-the-middle een rougue SMTP server opzet die zich voordoet als ontvangende server en geen TLS ondersteund. Op die manier zal het e-mailbericht leesbaar ontvangen worden en deze kan dus gelezen, gemodificeerd en doorgestuurd worden. Dit noemen we een “downgrade attack”. DANE is in het leven geroepen om juist dit probleem te verhelpen.

DANE bouwt voort op DNSSEC en is beschreven in RFC 6698. DNSSEC staat voor “Domain Name System Security Extensions” welke DNS records voorziet van een handtekening. Met DNSSEC is het niet mogelijk om DNS records te spoofen (cache-poisoning) omdat de ontvanger kan controleren of het geretourneerde record authentiek is.

DANE zorgt ervoor dat de identiteit van de ontvangende e-mailserver gecontroleerd is en dat een aanvaller zich niet ontvangende e-mailserver. Ook zorgt DANE ervoor dat STARTTLS wordt afgedwongen en dat dit niet door een aanvaller geblokkeerd kan worden.

DANE is in den beginne (RFC-6698) voorgesteld als alternatief voor certificate authorities (CA’s) omdat DANE in tegenstelling tot het platte CA-systeem waar elke vertrouwde CA een certificaat op naam van iemand kan uitgeven afhankelijk is van een hiërarchisch schema (de root, TLD’s, domeinen enzovoort). Er zijn dus meerdere afhankelijkheden. Maar er zijn zowel voor CA’s en voor DANE pro’s en con’s te bedenken.

Als DANE in-place is dan zal een e-mailverbinding (in de basis) als volgt verlopen.

MXA = Verzendende e-mailserver
MXB = Ontvangende e-mailserver

• MXA probeert een bericht af te leveren bij MXB
• MXA wilt zeker weten dat MXB ook echt MXB is en start doet een controle
• MXA kijkt in de DNS zone van MXB en zoekt naar de domeinnaam. Als deze bestaat en met DNSSEC beveiligd is dan kijkt hij in de juiste zone.
• Nu zoekt MXA naar het TLSA record en gebruikt het publieke certificaat (public key) om een TLS verbinding op te zetten met MXB. MXB kan de aanvraag ontvangen en decrypten omdat hij over de juiste privé sleutel beschikt (private key).
• Omdat alleen de ontvangende e-mailserver beschikt over de juiste key zal het slagen van de TLS verbinding nogmaals bevestigen dat MXA ook echt met de MXB server praat.
• De TLS verbinding tussen MXA en MXB wordt gemaakt en het bericht wordt verzonden.

Wanneer je onderzoek gaat doen op het internet dan worden DANE en TLSA vaak door elkaar gebruikt. In de DNS voeg je een zogenaamd TLSA record toe om de DANE beveiliging toe te passen. TLSA en DANE zijn dus vergelijkbare termen waarmee vaak hetzelfde bedoeld wordt. TLSA is puur het record en DANE is de gehele implementatie van het TLSA protocol.

Er zijn een aantal soorten TLSA records. Deze hebben te maken met de “certificate usage” waarde van het TLSA record. Deze waarde bepaald waarvoor het certificaat gebruikt mag worden. Er zijn 2 belangrijke verschillen:

• Certificate Usage 3 (DANE-EE) – Certificaat wordt gebruikt voor het opzetten van een TLS verbinding.
• Certificate Usage 2 (DANE-TA) – Nu wordt het certificaat gebruikt om het certificaat te ondertekenen dat door de server zal worden gebruikt om de TLS-verbinding tot stand te brengen. Dit is een wezenlijk verschil. Bij DANE-EE wordt het certificaat gebruikt welke in het record aangegeven is en bij DANE-TA wordt een ander CA certificaat gesigned waardoor het certificaat in het record als “trust anchor” fungeert.

Het is mogelijk om meerdere TLSA certificaten te publishen zodat er ruimte blijft voor fouten zoals het niet tijdig in de gaten hebben van een verlopen certificaat. Hou er b.v. rekening mee dat een certificate change 24 uur kan duren omdat DNS een tijdje nodig heeft om het TLSA record globaal te updaten.

Het TLSA record kan het volledige certificaat bevatten of een hash van dit certificaat. Laten we eens gaan kijken aar de opbouw van een TLSA record.

_443._tcp.jarnobaselier.nl. IN TLSA 3 1 2 111c8f49a69ab4c73476bd1321b2d52a6167d0f428334895ec328316aeca19fa064c84b0f5c2340f455
fac5f74714e53df4fe0fc7853d3e65b473f5e9fe33aq2

Verplicht in een TLSA record zijn de volgende service parameters:

• Poortnummer (_443)
• Protocol (._tcp)
• Domeinnaam (.jarnobaselier.nl)

Het type TLSA. Wij hebben in bovenstaande voorbeeld een zogenaamd “3 1 2” certificaat. Deze cijfers komen overeen het de volgende TLSA parameters:

Usage:
0 – PKIX-TA = Certificate Authority Constraint
1 – PKIX-EE – Service Certificate Constraint
2 – DANE-TA – Trust Anchor Assertion
3 – DANE-EE – Domain Issued Certificate

Selector:
0 – Cert – Use full certificate
1 – SPKI – Use subject public key

Matching Type:
0 – Full – No hash
1 – SHA-256 hash
2 – SHA-512 hash

Wij gebruiken dus een DANE-EE (Usage 3) certificaat met een public key (selector 1) verpakt in een SHA-512 hash (matching-type 2)

Je kunt ervoor kiezen om een 2e TLSA certificaat te publiceren, maar dan een Usage 2 (trust anchor) certificaat. Op die manier heb je een fallback optie en voorkom je het verliezen van e-mail. Met de selector 2 optie publiceer je een key welke niet toebehoord aan je server maar aan de CA authority welke je server certificaat uitgegeven heeft. In het geval van een externe CA zijn dit zijn root keys en in het geval van een self-signed certificate zijn dit de root keys van je eigen CA. Gebruik je geen CA dan moet je zelf de root keys en het root certificaat aanmaken alvorens je deze kunt gebruiken.

De keuze voor een selector is zeer afhankelijk van je certificate rollover policy. Wanneer je DANE gaat gebruiken is het zaak om een nieuw TLSA record te publiceren wanneer het certificaat vervangen wordt. Als het certificaat vervangen is maar er is geen nieuw TLSA record geplaats dan zal de DANE authenticatie falen en zullen er e-mails verloren gaan. Om dit probleem kun je ervoor kiezen om alleen Selector 1 certificaten (dus alleen de public key) te gebruiken. Dit is zinvol wanneer je de mogelijkheid hebt om certificaten te vervangen en dezelfde public key te behouden. Als dit geen optie is dan heeft de Selector 1 optie ook geen meerwaarde.

Tenslotte komt het certificaat (of de hash daarvan).

Het genereren van een TLSA record is relatief simpel. Je kunt een TLSA record genereren met CLI tools als “openssl” en “hash-slinger”. In openssl ziet een voorbeeld commando er als volgt uit:

openssl x509 -in jarnomail.crt -outform DER | openssl sha256 (stdin)= 99c0rt5c52750af093f4f14c8464bebbd6dede2738d11468dd953a3e6a3223ee

Nog makkelijker is de online TLSA generator van Shumon Hugue https://www.huque.com/bin/gen_tlsa.

Om Dane te gebruiken moet je de volgende stappen uitvoeren:

• 1. Zorg dat DNSSEC in-place is en dat je domeinnaam met DNSSEC beveiligd is
• 2. Zorg ervoor dat je mailserver STARTTLS ondersteund en voorzien is van een TLS certificaat
• 3. Maak een TLSA record aan en publiceer deze in je DNS

Nog niet genoeg informatie over DANE? Dan kun je hier nog de DANE factsheet downloaden.

Conclusie

Als TLS in-place is op de mailserver, en DNSSEC is operationeel dan is het volledig operationeel maken van DANE niet meer dan het plaatsen van een TLSA DNS record. Let op dat je wel blijft testen en monitoren nadat je het TLSA record geplaatst hebt. 1 Configuratiefoutje kan ervoor zorgen dat je veel of alle e-mail kwijtraakt. Nadat je je TLSA record succesvol geplaatst hebt is DANE meteen actief. Let er dus ook op dat je het TLSA record niet plaatst alvorens je alle voorbereidingen voltooid hebt. In een toekomstige post zal ik laten zien hoe je de mailserver configureerd met TLS, DNSSEC activeerd en het TLSA record plaatst. DANE is een fantastische aanvullig op het “veiliger maken” van e-mail. Ik hoop dat de adoptie snel gaat en dat ook Microsoft snel DANE (TLS) implementeerd op hun Office365 omgeving. Het uitblijven van DANE is een groot gemis, zeker voor de Nederlandse overheidsbedrijven die op Office365 zitten en het gemis van DANE nu op de pas-toe-of-leg-uit (ptolu) lijst moeten plaatsen.

Vond je dit een interessant bericht dan zou ik het supergaaf vinden als je me een leuke comment geeft, en dit bericht “liked” of deelt op je eigen kanalen. Positive-vibes-make-happy-people!