Yahoo doet voorstel voor DomainKeys-standaard bij IETF

Yahoo heeft een voorlopige versie van zijn DomainKeys-standaard ingediend bij de Internet Engineering Task Force (IETF). DomainKeys is een techniek die het verzenden van spam en virussen met een vals afzendadres tegen moet gaan, door servers te laten controleren of een bericht daadwerkelijk van een bepaald domein afkomstig is. Het idee is gebaseerd op enkele standaard algoritmes om een digitale handtekening onder iedere verzonden e-mail te zetten. Mailservers die DomainKeys niet ondersteunen zullen deze handtekening negeren, maar degenen die de techniek wel herkennen kunnen met behulp van een uitbreiding op DNS de publieke sleutel van het domein waar het bericht vandaan claimt te komen opvragen, om zo controleren of de handtekening echt is.

In het ideale geval gaan alle normale mailservers DomainKeys ondersteunen, waardoor alle berichten zonder of met een valse handtekening meteen zwaar verdacht of zelfs genegeerd kunnen worden. De spammers zouden zich als gevolg daarvan niet meer in anonimiteit kunnen verhullen, waardoor ze veel makkelijker opgespoord of geblacklist kunnen worden. Op dit moment zijn de programmeurs van de populaire open source mailserver Sendmail al bezig om de standaard te implementeren, en Yahoo zelf zal een module aanbieden die onder andere geschikt is voor Qmail.

Het is echter nog afwachten hoe succesvol en effectief de nieuwe standaard in de praktijk zal blijken te zijn. Eén van de mogelijke struikelblokken is het feit dat Yahoo patent heeft aangevraagd op de technologie. Weliswaar met de belofte dat iedereen een gratis licentie kan krijgen, maar wellicht is dat toch niet 'open' genoeg om wereldwijd geaccepteerd te worden.

Reacties (43)

[dfr0st]

Betekend dit dat ik niet meer 1 SMTP server kan gebruiken voor meedere acccounts?
Of vraagt hij alleen de sending mail server of de echt van die server vanaf komt.

[brama]

Inderdaad - je moet je mail per account versturen via de outgoing mailserver(s) van het domein behorend bij dat account. Deze outgoing mailservers zijn nl. degenen die de private key hebben waarmee mailtjes voorzien worden van een 'echtheidskenmerk'!

Die outgoing mailserver voor elk domain moet dan natuurlijk wel een goede user-authentication hebben om te weten wie er mail mag versturen.

1: Dat kan makkelijk zijn; bijv. een ISP weet vanaf welke IP-ranges mail verstuurd kan worden voor zijn eigen domain (alle DSL klanten, alle medewerkers van een bedrijf, etc).

2: Het kan natuurlijk ook lastig zijn...stel je zit met je laptopje op een ander netwerk (thuis ipv op het werk). Dan moet de outgoing mailserver een andere manier van authenticatie gaan toepassen, want de IP-range check zal uitwijzen dat je ergens anders zit (tenzij je een VPN gebruikt, maar dat kan niet in alle situaties). Dus zal je op een andere manier moeten authenticeren met de mailserver, via een username/password bijvoorbeeld.

"Maar kan een spammer dan niet nog steeds spammen, door het From: adres aan te passen aan het domein vanaf waar het verstuurd wordt?" (in situatie 1) - Dat kan zeker, maar dan is het wel erg makkelijk te traceren. ISP's die vervolgens niet op klachten reageren van andere ISP's die merken dat er nog veel spam verstuurd wordt vanuit die ander, krijgen automatisch een slechte reputatie en kunnen daardoor makkelijker als spam worden gemarkeerd, of zelfs geblockt worden.

Het wordt dus lastiger om alle mail via 1 SMTP server naar buiten te sturen, maar dat is toevallig ook *het* zwakke punt op dit moment, waardoor iedereen lukraak From: adressen kan faken. Deze oplossing is 'mooi' omdat 'ie langzaam ingevoerd kan worden, terwijl 'oude' mailservers de mail toch kunnen ontvangen en doorsturen.

[Verwijderd]

Olaf, Brama,

Heb deze specifieke implementatie niet volledig doorgelezen, maar de discussie is klassiek, zoals ik wou aangeven.

Probleem met authenticatie op een hoger niveau, gebonden aan het domein is dat de spammers dan volop "wegwerpdomeinen" beginnen te registreren en doorgaan naar een volgend eens zo een geblacklist wordt of de key wordt gerevoked indien dit mogelijk is.

Indien er een serieuze barriere wordt opgeworpen tegen het a volonté registreren van domeinen en deze te voorzien van zo'n domeinkey, dan heeft ieder persoon met een eigen domein en mailserver hiervan te leiden denk ik.

In de tijd en moeite die het mezelf als particulier kost om m'n domein te voorzien van zo'n key kan elke bekwame (professionele) spammer tientallen, zoniet honderden domeintjes laten voorzien van een key, of goeie gevalideerde wegwerpdomeintjes kopen.

Meestal wordt na deze discussie voorgesteld om met ip blocks te gaan werken en dan kom je weer uit bij m'n vorig argument denk ik?

[brama]

I3,

Je hebt wel gelijk m.b.t. het registeren van wegwerpdomeinen. Het lijkt me echter wel dat het traceren van de spammer zo iets makkelijker wordt; iemand zal dat domein toch moeten registeren. Nou kan dat weer met een gestolen/valse credit card nr, maar dat lijkt me toch een extra barriere voor de spammert. Misschien ook wel niet, want op veel geweten kun je zo'n spammer niet betrappen..

Daarnaast wordt het blacklisten ook een stuk eenvoudiger, aangezien je maar enkele domeintjes hoeft te blacklisten. De tijd tussen het starten van de spamrun en het blacklisten wordt hierdoor wellicht korter. Het enige wat de spammer daar aan kan doen is bijv. elke X uur van domein wisselen. Wat helaas niet zo onwaarschijnlijk is

Het spammen wordt, zoals je zegt, inderdaad niet veel moeilijker nee.. het enige wat je echt bereikt is het voorkomen van geforgede email adressen.

Om het spammen echt tegen te gaan zal het er waarschijnlijk wel op neerkomen dat Jan Modaal niet zomaar meer z'n eigen servertje kan draaien, en idd. alleen een set 'trusted' mailhosts bijgehouden wordt. En om daar bij te mogen horen moet je dan flink wat meer moeite voor doen (en vooral meer identiteit vrijgeven).

[Verwijderd]

Je moet niet alles zo zwart wit zien ;-) Het is niet noodzakelijk om altijd direct te blacklisten. Het voordeel van een systeem als domainkeys of spf is dat je credibility aan domeinen kunt gaan toekennen.

Een domein waar je al jaren mail van ontvangt is credible en wordt a.h.w. automatisch gewhitelist (of handmatig zo je wilt). Mail van een domein dat nog geen credibility heeft opgebouwd wordt nauwkeurig bekeken op spam aanwijzingen.

Een ander groot voordeel is dat een domein geregistreerd moet worden en dat de koper in principe traceerbaar wordt en dus aan te paken met juridische maatregelen.

Het runnen van je eigen domein wordt weliswaar wat lastiger maar er zijn vast wel weer providers die dat gat in de markt zien en diensten gaan aanbieden om dat makkelijker te maken.

Het runnen van een eigen smart mailhost op je DSL lijn heeft mogelijk toch zijn langste tijd gehad. Ik heb deze week eens aan een mailserver zitten te sleutelen die overbelast raakte van de virusbombardementen. Bijna alles van DSL of kabelabonnees met besmette PC's die gewoon dag in dag uit virussen staan rond te sproeien. Wordt je niet vrolijk van. Ik laat nu maar automatisch de IP adressen blokkeren.

[Olaf van der Spek]

"Maar kan een spammer dan niet nog steeds spammen, door het From: adres aan te passen aan het domein vanaf waar het verstuurd wordt?" (in situatie 1) - Dat kan zeker, maar dan is het wel erg makkelijk te traceren.

Het bekijken van de Received headers van een email is ook relatief eenvoudig. Dan zie je ook zo van welke ISP het afkomstig is, maar blijkbaar doen veel ISPs weinig tegen abuse.

[Gwaihir]

je moet je mail per account versturen via de outgoing mailserver(s) van het domein behorend bij dat account.

Helaas veplicht een groot deel van de ISPs je alle mail via hun SMTP server te sturen (door uitgaand SMTP verkeer naar elders simpelweg te blokkeren). Dat betekent dat veel legitieme mail niet-ondertekend kan worden..

[Verwijderd]

Nee, dit houdt in dat wordt gecontroleerd of de afzender ook daadwerkelijk de afzender is.

Ik zie alleen niet de meerwaarde niet zo momenteel. Het dunkt mij dat heel wat ongemak zou kunnen worden afgevangen op een eenvoudige check die de het IP van de afzender verifieert met wat er in de DNS staat. Daarvoor heb ik geen authenticatie systeem voor nodig (ik zal wel ergens overheen hebben gelezen).

mijn dank aan de moderator voor het verplaatsen van mijn reactie naar de correcte reply.

[Olaf van der Spek]

met wat er in de DNS staat.

Welke DNS?

[Verwijderd]

een willekeurige rootDNS-server lijkt me

[Verwijderd]

Met wat er in de DNS staat voor de betreffende domeinnaam.
Let op: Het is een uitbreiding van de huidige DNS specificatie.

De grap is, vermoed ik, dat een domein zelf een key kan toevoegen waarmee kenbaar kan worden gemaakt dat er een athenticatie key is.

[PuzzleSolver]

Dat gaat alleen op als je de mailserver bent ide het mailtje het eerst ontvangt. Aangezien er meerdere systemen zijn die de mail relayen of opsparen voor een aantal domeinen kun je er niet altijd meer van uitgaang dat degene van wie je de mail ontvangt ook degene is die in de DNS als (een van de) MX'ers vermeld staat. Als daarintegen de eerste mailserver deze check uitvoerd en daarmee het mailtje van een authentieke handtekening voorziet waardoor een volgende mailserver dit weer bij hem kan verifieren dan kun je een waterdicht systeem bouwen (mits al de servers in het traject van dit protocol voorzien zijn). Lijkt het beschreven systeem zoiets is.

[Nico de Vries]

Een patent met gratis licenties is op zich niet slecht (mits keihard zwart op wit zo vastgelegd met de juiste handtekening er onder). Dit voorkomt dat kwaadwillenden het alsnog patenteren bijvoorbeeld.

Wat ik me wel afvraag is wat er in dit scenario gebeurd als de DomainKey van een bepaald domein gestolen wordt. Lijkt me dat spammers vervolgens met gestolen DomainKeys alsnog aan de slag kunnen.

Dit initiatief lijkt me in ieder geval stukken beter dan het "laten we voor alle e-mails geld gaan vragen" van Bill Gates en recent nog de OPTA.

[Verwijderd]

Ben ik niet helemaal mee eens. Als je de SSH keys (UNIX) bekijkt dan wordt een key gegenereerd voor een specifiek IP adres. Is er een wijziging in het IP adres, krijg je een untrusted certificaat is in de praktijk een waarschuwing. Ik ga er van uit dat er over dit probleem nagedacht is.

[Verwijderd]

Dat is NIET waar!
Er wordt een key gegenereerd, die vervolgens door de client machines in een cache wordt gezet, namelijk ~/.ssh/known_hosts.
Als het ipnummer wijzigt, is het niet afhankelijk van de key, dat er een fout komt. Dit is afhankelijk van het stukje "hostname,ipnummer" waarmee de regel van de known_hosts file begint.

Maar het is absoluut mogelijk om 1 key op meerdere hosts te draaien. (Ik doe dat nl voor m'n tijdelijke test-servers/vmwares, die krijgen allemaal dezelfde key)

Wat wel waar is: hij wordt 'untrusted' op dat moment. Maar iedere server waar je voor het eerst een mailtje heen stuurt is automatisch untrusted, dus dat moet toch geautomatiseerd worden geaccepteerd.

[Verwijderd]

Het moge duidelijk zijn dat ik de SSH keys alleen aanhaal om aan te geven dat er een waarschuwing wordt gegeven op moment het IP adres wijzigd.

Vergeet niet dat de truuk is dat je middels de DNS voor je zelf een stukje zekerheid publiceert naar de buitenwereld.

[Wouter Tinus]

Als een key gestolen wordt dan moet die vervangen worden door een nieuwe. Er kan voor nieuwe mails direct overgestapt worden op een andere key, terwijl de oude nog even kan blijven bestaan (zodat de laatst verzonden mailtjes met de oude key niet als 'vals' worden bestempeld).

[lammert]

Een patent met gratis licenties is op zich niet slecht (mits keihard zwart op wit zo vastgelegd met de juiste handtekening er onder). Dit voorkomt dat kwaadwillenden het alsnog patenteren bijvoorbeeld.

Iets wat publiekelijk bekend is kan je per definitie niet meer patenteren...het is namelijk niet meer 'nieuw'. Een simpele publieke bekendmaking is al genoeg om patentering door anderen te voorkomen.

[Verwijderd]

Iets wat publiekelijk bekend is kan je per definitie niet meer patenteren...het is namelijk niet meer 'nieuw'.

Leg dat even uit aan de amerikanen... bijvoorbeeld het patenteren van subdomeinen, virtual desktop pagers en het reageren op verschillende manieren van klikken op een knopje is gewoon toegestaan in amerika.

En zelfs al is het patent misschien niets waard, er is geen ene open source programmeur die de juridische strijd kan betalen.

[pietje63]

Eén van de mogelijke struikelblokken is het feit dat Yahoo patent heeft aangevraagd op de technologie.

Ik kan me haast niet voorstellen dat ze er misbruik van willen maken. Als ze dat zouden doen zijn ze in een keer hun goede naam kwijt.

Iedereen is spam zat (en heeft er zat van ) ik denk echter dat het niet heel hard gaat werken. Mensen versturen 2M mails, komt op de zwarte lijst en pakt de volgende server... Als je de mails wilt versturen lukt dat toch wel. Wat volgens mij toch het beste werkt is een whitelist systeem. Bij nieuwe contacten een keer lastig, maar het werkt goed.

[Verwijderd]

Als het gebruik gratis is, dan is de drempel lekker laag en de acceptatiegraad kan snel hoog worden. Waarom het patent? Iemand moet de CA gaan spelen en de certificaten uitgeven. En die kosten net als SSL-certs gewoon geld, elke jaar of om de twee jaar opnieuw ! (zie: http://www.sslreview.com/ssl-certificate-content/ssl-compare-table/ind ex.html ). Nu snap je wel wie de CA gaat worden en waarom ze de techniek patenteren. Mega$$$$$

[Wouter Tinus]

Niet waar. De distributie loopt via DNS en dat is voldoende garantie dat de key die je krijgt ook de key is die bij het domein hoort. Er is verder in principe niemand nodig om dat te bevestigen. Zie ook de FAQ:

Does DomainKeys require signing of the public key by a Certificate Authority (CA)?

DomainKeys does not require a CA. Much like a trusted Notary Public, Certificate Authorities are used in public/private key systems to sign, or "endorse," public keys so that the external users of public keys can know that the public keys they receive are truly owned by the people who sent them. Since DomainKeys leverages DNS as the public key distribution system, and since only a domain owner can publish to their DNS, external users of DomainKeys know that the public key they pull is truly for that domain. The CA is not needed to verify the owner of the public key - the presence in that domain's DNS is the verification. However, it is possible that Certificate Authorities may become a valuable addition to the DomainKeys solution to add an even greater level of security and trust.

[Verwijderd]

Self-signed certs hebben niets met trustworthyness te maken. Je kunt wel voor je eigen domain je eigen private/public keypair genereren, je eigen pub-key signen en in je DNS registeren, maar wie zegt dat je te vertrouwen bent? Vandaar de opmerking:

However, it is possible that Certificate Authorities may become a valuable addition to the DomainKeys solution to add an even greater level of security and trust.

[Wouter Tinus]

Dit systeem is helemaal niet bedoeld om te controleren of een domein te vertrouwen is, alleen om te zien of een e-mail wel van het domein waar hij vandaan zegt te komen komt.

[Gerco]

Als een mail nu geen domainkey bij zich draagt, zal een domainkeys ondersteunende mailserver dus ook niet gaan controleren of die key klopt (die is er immers niet). Een spammer stuurt gewoon geen key mee en is weer helemaal vrij om in anonimiteit te doen wat hij wil. Ik zie hier de oplossing niet zo in.

[pietje63]

Dat zegt het artikel toch... Als vrijwel alle severs het wel ondersteunen is een mail zonder key al meteen verdacht.

[Verwijderd]

En hoelang denk je dat het duurt voordat alle smtp-servers en dns-servers en mx-records aangepast zijn dat je eerlijk kunt zeggen dat een mail zonder key verdacht is?

Ik vrees dat als je dit 1 juli dit jaar invoert, je heel wat jaren verder bent voordat je een nieuwe, stabiele situatie over de wereld hebt.
Tot die tijd zitten we dus gewoon met spam en daarna heb jij gelijk.

[Xenan]

Goede zaak. Als ze het nu als een RFC indienen ipv van patenteren dan kunnen we eindelijjk van de SPAM verlost worden

[Roland684]

en je bent meteen ook van enige vorm van privacy verlost.

[miw]

Dit systeem gaat over authenticatie, dus dat de ontvanger zekerheid heeft over de verzender van het bericht.
Authenticatie zegt niets over het bekend worden van de inhoud van je boodschap. DomainKeys zorgt dus niet voor een verslechtering van je privacy. Uitbreidingen van dit systeem met versleuteling van de email zelf, maken zelfs een verbetering van privacy mogelijk.
Het enige mogelijke nadeel is dat je met DomainKeys niet meer kan ontkennen dat je een email aan iemand gestuurd hebt.

[Olaf van der Spek]

Het enige mogelijke nadeel is dat je met DomainKeys niet meer kan ontkennen dat je een email aan iemand gestuurd hebt.

Dat kan nog steeds.
DK zegt alleen dat de email met de key van een domein getekend is. Of die key gestolen was of welke user van dat domein de email gestuurd heeft, is niet bekend.

[Roland684]

Dat je bij elk bericht meteen je adres moet geven is wel degelijk een verslechtering van je privacy. Het wordt voor grote organisaties makkelijker om je doen en laten te volgen.
Er zijn zat momenten te bedenken dat ik even iets wil doorgeven zonder dat ik opgenomen wil worden in het 'klantenbestand' van een organisatie. Stel je voor dat je bij elke winel waar je even naar iets informeert meteen je adres moet opgeven zodat ze je 'interessante aanbiedingen' kunnen gaan sturen.

[BlackOwl]

Voor dat soort dingen open je gewoon een of ander gratis webmail account.

[nxt]

als ik het goed begrijp, dan wordt er als je een mailtje verstuurd door de ontvangende mailserver gecontroleerd of het wel verstuurd is via de smtp server die bij het domein v/h email adres hoort van de afzender.

als dat klopt lijkt 't me niet zo handig, meestal krijg je geen smtp bij het registreren van een domein naam, dus gebruik je die van je internet provider, maar als dit doorgaat lijkt 't me onmogelijk om nog mail te verzenden met email adressen van je eigen domein?

[Olaf van der Spek]

Dan kun je toch de public key van je ISP in jouw DNS record publiceren?

Dit levert alleen problemen op als je meerdere SMTP servers wil gebruiken.

[goalgetter]

Als ik het goed begrepen heb is dat niet het geval. De check wordt gedaan op de versturende mailserver. Dit kan je eigen server zijn, of 1 van je ISP. Het gaat erom dat er geverifieerd wordt dat het mailtje daadwerkelijk van die server afkomt. Als blijkt dat het toch spam is, dan weet je tenminste waar het echt vandaan komt, en kan die server op de blacklist.

[Verwijderd]

Dit is geen nieuw idee. Als je dit doordenkt is het helemaal geen oplossing voor de gewone gebruiker.

Twee uitspringende resultaten:
1- grote bedrijven en ISP's zullen dit of iets soortgelijks adopten, en dit vrijwaart hen van hun domein misbruikt te zien door spammers. (sender spoofing) i.e. spams versturen die zich voordoen als bvb van *.yahoo.com, of *.msn.com zal zal niet langer lukken omdat deze geen correcte "signature" van die mailserver bevatten.

2- vergeet maar al om je eigen SMTP te draaien in een IP subnet block van een grote ISP. Deze linkt zijn IP blocks aan de sigs van de eigen mailservers en alle andere mails verstuurd uit dit netblock zullen als "SPAM" worden aanzien want deze kunnen geen correcte sig produceren.

Dat 2e is een gigantisch nadeel, maar dit zie ik wel als een grote oplossing voor o.a. alle spammers met een DSL/cable lijn en all PC's met een virus of spyware met eigen SMTP deamon die als relay dient...

[Olaf van der Spek]

2- vergeet maar al om je eigen SMTP te draaien in een IP subnet block van een grote ISP. Deze linkt zijn IP blocks aan de sigs van de eigen mailservers en alle andere mails verstuurd uit dit netblock zullen als "SPAM" worden aanzien want deze kunnen geen correcte sig produceren.

Zo werkt het niet. IP adressen hebben hier niks mee te maken.
Het domein deel van het from adres wordt bekeken, het 'DK' record van dat domein wordt via DNS opgevraagd en er wordt gecontroleerd of de email ondertekent is met een van de keys uit het DK record.

[brama]

Dat gaat niet werken, aangezien de spammer zelf die DK records ook kan opvragen en daarmee de mail kan kenmerken. De truuk is dat er een select aantal mailservers is die de GEHEIME sleutel bevatten. *alleen die* mailservers kunnen de mailtjes voorzien van een echtheidskenmerk. Iedereen kan dat controlleren mbv de PUBLIEKE (DK record) sleutel. Mailtjes die niet mbv de geheime sleutel zijn gekenmerkt, vallen door de mand.

[Verwijderd]

Je ondertekent idd met je private key (die dus niemand heeft) en in het "DK" record staat de publieke sleutel.
Gevolg is dat je de ondertekening wiskundig kunt controleren maar niet reproduceren want je mist het private part, die in deze setup wel op de server(s) moet staan en niet bij de clients.

Wat je hiermee dus wel gaat krijgen is dat er domeinen komen, MET key, waarvan de spammers gaan handelen in de private keys (die dan niet meer private zijn). Of proberen de smtp-servers te cracken om de private te vinden.
Gevolg is, dat je mail, afkomstig van domein X, met key ABC niet trusted is. Dus bouw je blacklists op met domein/key combo's. En imho zijn we dan weer bijna terug bij af.
Ik geef toe dat er iets meer werk aan zit aan de kant van de spammer, maar volgens mij houd ze dat helaas niet tegen. ls je ziet wat ze doen met vrussen en wormen om spam-zombies te krijgen.....

[Olaf van der Spek]

Mailing lists that change the message and headers should re-sign the message with their own private key and claim authorship of the message.

Dat vind ik toch wel een groot nadeel. Normaal wordt From gebruikt om de verzender van een email naar een mailing list aan te geven, maar nu kan dat dus niet meer.

[gumkop]

nog een nadeel: om een vertrouwt cerificaat te krijgen moet je altijd zo krankzinnig veel betelan, dit maakt het dus lastiger voor kleine bedrijfjes om een eigen mail server te houden

[perlboy]

Wat is er mis met het SPF protocol? Dat is volgend mij een stuk lichter en werkt denk ik ook afdoende.
http://spf.pobox.com/