Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 31 reacties
Bron: VNU

Een aantal grote bedrijven gaat, aangevoerd door Yahoo en Cisco, een gezamelijk standaardiseringsverzoek bij de Internet Engineering Taskforce (IETF) indienen, genaamd DomainKeys Identified Mail (DKIM). Het gaat om een combinatie van Yahoo's eerder aangemelde DomainKeys en Cisco's Identified Internet Mail. Bij de apart ontwikkelde maar vergelijkbare technieken komt het er in het kort op neer dat de verzendende server ieder mailtje voorziet van een digitale handtekening met een geheime encryptiesleutel, waarna de ontvangende server die met een publieke sleutel decodeert en de afzender verifieert. Afzenderverificatie is niet alleen van belang om spammers tegen te werken die hun identiteit proberen te verhullen, maar ook om phishingaanvallen te voorkomen, waarbij een kwaadaardige hacker een mailtje verstuurt dat bijvoorbeeld van de bank afkomstig lijkt te zijn, om fraudegevoelige informatie van de ontvanger los te peuteren (zoals onlangs nog gebeurde).

Anti-spam Andere partners in het standaardiseringsvoorstel zijn AOL, EarthLink, IBM, Microsoft, VeriSign, PGP en de SendMail-ontwikkelgemeenschap. Yahoo's DomainKeys wordt ondertussen al door Google's Gmail gebruikt. De voorstellen worden eind deze maand in Parijs besproken. Als ze worden aangenomen zullen licenties op de uiteindelijke DKIM-specificatie gratis zijn.

Microsoft lijkt ondertussen nog steeds van plan om in november de eigen Sender ID-technologie in Hotmail op te nemen, waardoor mailtjes die niet vanaf een server verstuurd zijn die gebruikmaakt van Microsoft's Sender Policy Framework als potentiŽle spam worden aangemerkt. Wat de invloed van eventuele adoptie van de DKIM-standaard op het beleid van Microsoft is, is vooralsnog onbekend.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (31)

Het grootste probleem met dit soort dingen is de ondersteuning van oude technieken (backward compatability dus). De oude manier heeft dit soort verbeteringen niet, maar mensen willen geen mail mislopen.

Dus als je een mailtje krijgt die bijvoorbeeld geen afzenderverificatie heeft, zal je hem waarschijnlijk toch wťl in je inbox willen hebben. Want voor hetzelfde geld is het gewoon iemand die een oude softwareversie gebruikt.

Juist dit soort dingen zorgen ervoor dat spam blijft bestaan, want anders was allang dat hele protocol tegen de helling gezet. Maar omdat sommige mensen ook nog oudere versies van programma's zullen gebruiken, vertraagd dat enorm...
Mensen willen geen mail mis lopen, althans sommige mensen willen niets mis lopen. Veel mensen geven nu al hun inbox over aan spamfilter wat een stuk onbetrouwbaarder is dan dit systeem.

Als je dit systeem kunt gebruiken als aanvulling op bestaande spamfilters is het zeker handig. Aangezien misschien wel 90% van al het mailverkeer over maar iets van zes verschillende typen mailservers loopt ben je met implementatie in zes pakketten mailserver-software al een heel eind. Zolang de standaard maar openbaar is en alle grote partijen meewerken.
Oud en nieuw is goed samen te gebruiken. Een email die geverifieerd kan worden met het/een nieuw systeem legt een andere weg af door het spam-filter systeem dan een email die niet geverifeerd kon worden, omdat de afzen het systeem niet ondersteund. Zo'n email zul je dus alsnog op SPAM moeten 'onderzoeken' (RBL, SURBL, SpamRules etc.), terwijl de geverifeerde mail direct door kan. Dit maakt de kans op een False Positive vele malen kleiner en een implementatie van het nieuwe systeem redelijk transparant. Het ligt dus aan de makers van de messaging-software wat zij doen met een email die wel of niet geverifieerd kan worden.
Ehm, omdat een mail geverifieerd kan worden met iets dergelijks als SPF of Domainkeys, wil niet zeggen dat je de mail niet meer hoeft te controleren op spam!

Deze technieken zorgen ervoor dat een spammer niet meer zijn afzendadres kan vervalsen en dus niet kan doen alsof de mail van een hotmail of yahoo adres komt. Ook handig is dat virussen dus ook niet zo snel meer een vals afzendadres kunnen gebruiken.
Dat staat er ook niet als je goed leest...
Eea is een follow up op OnTrackK.
No offence, maar, je antwoord is een beetje offtopic. SPF is voornamelijk iets dat providers/systeembeheerders moet worden geimplementeerd.
Gewone gebruikers zullen er weinig van merken, alleen gebruikers die een eigen mail-server draaien of hun mail versturen via servers die niet bij hun mail-account "horen".

Spam bestaat om verschillende redenen, maar de voornaamste is gewoon omdat er geld mee kan worden verdiend. Zolang het meer opbrengt dan dat het kost om te versturen en niet strafbaar wordt zal het blijven bestaan.
Als deze standaard geimplementeerd wordt, komt de methode van de encryptie plus de public decryption metode ook vrij voor het publiek? Anders krijg je met eigen programma's die gebruik maken van het mail protocol het probleem dat ze standaard als spam worden aangemerkt.
is dit een probleem dan? je kan wel werken hoe een slot werkt, maar om hem open te maken heb je nog steeds de sleutel nodig :+
tweakers.net/nieuws/32531

Op dit moment zijn de programmeurs van de populaire open source mailserver Sendmail al bezig om de standaard [Yahoo Domainkeys] te implementeren, en Yahoo zelf zal een module aanbieden die onder andere geschikt is voor Qmail.
Het lijkt erop dat het inderdaad een open standaard is.
Volgens mij is "Cisco's techniek is ongepubliceerd gebleven" gewoon dit: http://www.identifiedmail.com
en dat lijkt me grofweg hetzelfde te doen als Yahoo's DomainKeys. ( en Microsofts Sender ID. ) edit: en hier had ik wel een strikethrough tag kunnen gebruiken...

DKIM als combinatie is volgens mij dan ook niet veel anders dan een samenwerking tegen Microsofts Sender ID, waarbij zowel Cisco als Yahoo vol kunnen houden dat ze hun eigen voorstel niet hebben laten vallen ten faveure van een voorstel van een ander.
Want dat schijnt een doodzonde te zijn tegenwoordig.
en dat lijkt me grofweg hetzelfde te doen als Yahoo's DomainKeys. ( en Microsofts Sender ID. )
Die twee (DomainKeys / SenderID) doen NIET hetzelfde!
Van wp:
SPF, CSV, and SenderID authenticate just a domain name. DomainKeys uses a Digital Signature to authenticate a domain name and the entire content of a message.
Kortom, DomainKeys werkt met asymetrische encryptie waarmee ook de mailinhoud geverifieerd wordt, SenderID niet.
juist.
en dan kan je dus dat microsoft ding gewoon lekker blijven spoofen maar on-the-fly de juiste keys genereren gaat een beetje moeilijk.

in mijn ogen idd vele malen beter dan microsofts techniek.

ik denk ook eigenlijk dat microsoft snel even met iets op de proppen gekomen was toen ze vernamen dat de rest aan het werk was aan een anti-spam techniek.
en natuurlijk moet je microsoft servers gebruiken om het te kunnen gebruiken.
ook weer typisch ms.
Waar alleen niemand aan denkt is dat je een flinke mail server nodig gaat hebben voor een domein waar flink wat mail verkeer door heen gaat. Zo'n mailserver staat dan de hele dag keys te genereren en te ontcijferen, lijkt me een duur grapje zoiets. Dat kun je beter caller ID hebben waarbij er in de DNS server van een domein gewoon een record word opgenomen met mail servers die mail mogen versturen voor het domein, dus zeg maar het zelfde als een MX-record maar dan omgekeerd. Lijk mij effectief genoeg want je kan niet zomaar een IP adres van zo een server spoofen.
Nee dat klopt, daar hebben we DNS Spoofing voor :+
een probleem van dit soord ideeen is dat het een vals gevoel van veiligheid geeft.

doordat er hoog van de toren wordt geschreewt dat dit de oplossing is.

er een hoop mail programatuur is die hier niet mee overweg kan. daarom zal in elk pakket de komende tijd totdat dit opgelost is gewoon alle mail door laten (omdat het dus van een pakket kan komen die dit niet ondersteund) of alles van een eigen mail pakket komt niet aan omdat het als spamm wordt aangemerkt en geweigerd word of in een speciale map wordt geplaatst waar niemand kijkt
Erm, het is zelfs nog erger: de spam zal eerder deze technologie ondersteunen dan legitime gebruikers. Ter lering en vermaak moet je dit artikel van security guru Peter Gutmann maar eens lezen.
Ik vind dat Hotmail veeeeeeeeeeeeeeel te commercieel is. Een zeer trage pagina met reclame en soms ook popups. Standaard nog steeds de 2MB Mailbox. Maar daar is uiteindelijk na veel concurrentie een einde aan gekomen (anders was het nu nog maar 2MB hoor, ben maar niet bang!)

Nog een paar weken en GMail heeft XS4All ingehaald :) Ik blijf gewoon bij GMail. Lekker snel, genoeg plek. Altijd al je mail en contactpersonen bij de hand.

Dat Microsoft alle email die niet met hun systeem samenwerkt als spam gaat 'behandelen' ben ik het zo ontzettend niet mee eens. Ik vind dat het gewoon echt niet kan.. Maak het dan zo dat deze bericht niet bij spam terecht komen, maar dan niet een geel-achtige lijn hebben, maar een rood-achtige lijn. (Dan bedoel ik de lijn waar de afzender, onderwerp en grootte staan).
Gebruik gewoon geen Hotmail?
Als dit serieus inhoud dat iedereen en z'n hond DomainKeys gebruikt behalve hotmail, dan is de kans dat meer en meer mensen van hotmail afstappen best aanwezig.

marktwerking, dat is mooi spul.
Dat Microsoft alle email die niet met hun systeem samenwerkt als spam gaat 'behandelen' ben ik het zo ontzettend niet mee eens.
Ach, soep en heet en eten en zo...
Ik denk dat als het voorstel van de DKIM aanvaard wordt als standaard, MS de Hotmail omgeving wel aan zal passen zodat Hotmail in ieder geval e-mail gemarkeerd met deze standaard zal accepteren. Al is het maar om een stortvloed aan klachten te voorkomen.
Of ze het ook voor uitgaande mail zullen gaan doen, is weer een ander verhaal... Dat denk ik niet: met de implementatie van SenderID in Exchange in combinatie met Hotmail zal MS waarschijnlijk proberen om hun "standaard" er toch door heen te drukken...
Micrtosoft's Sender Policy Framework
Sender Policy Framework is niet van Microsoft, noch een idee van Microsoft zelf. Het is een onderdeel van Sender-ID, wat opzichzelf een combinatie is van SPF en M$'s Caller-ID.
en geldt die standaard dan ook voor de niet-grote bedrijven? zo niet, dan verschuiven de pishing- en spampraktijken dus naar andere providers. De weg van de minste weerstand zullen we maar zeggen.

dus wat winnen we er in dat geval mee?!

(of zouden de mailtjes die bij de grote providers aankomen niet worden doorgestuurd omdat ze een sleutel missen? in dat geval worden de kleine providers met andere ideeŽn uit de markt gedrukt)
Internet Engineering Taskforce (IEFT) -> tiepfoutje, IETF lijkt me een beter idee

verder vind ik het een fantastisch idee!
tja 2 maanden overleg en 1 dag om het gekraakt te worden.

standaarden betekend gewoon makkelijker te kraken omdat je maar 1 versie van beveiling hoeft te kraken inplaats van meerdere.

je kan het proberen, maar het is het zelfde als standaarden opstellen tegen illegaal kopieeren en virussen
bah wat ben jij een doemdenker :+
Alleen hoef je nu helemaal niets te kraken omdat er geen beveiliging is.

Alles wat de vloed van spam kan (al is het maar een beetje) indammen is goed, als het gratis is dan des te beter.
Had je dan meerdere standaarden gewilt? Dan ga je ineens krijgewn dat mensen hun familie in het buitenland niet meer kunnen mailen omdat ze daar een andere standaard gebruiken. Lijkt me geen goed plan en op die manier zou de defenitie standaard niet echt meer op gaan toch?
En toch is dit een goede ontwikkeling, het ontmoedigt wel weer enigzins.

Maar idd, de research om het op te stellen heeft meer tijd als om het met brute force te kraken ben ik bang...

@ dudes onder me ;)
MM, lullig voor je dat je reactie als troll werd gezien en mijn 2 inzichtvol, ik denk dat het ook aan de formuliering ligt.

Maurits, ik zei ook niet dat het de moeite waard was, het is echter hacktechnisch via bruteforce wel te doen en dat kan voor spammers heus wel interessant zijn.
Waarom zou er iets gekraakt worden?

Trusted Third Party systemen zoals SSL encryptie voor websites zijn theoretisch wel te kraken maar in de praktijk vrijwel onmogelijk en de moeite van het kraken zelden waard. Dit lijkt er redelijk op eigenlijk...
Het kraken van een pak m beet 256 bit SSL encryptie en deze ook nog gebruiken om zo het afzend adres te faken lijkt mij echt TEVEEL moeite.

Zeker als er regelmatig nieuwe keys gegenereerd worden. Andere servers hoeven dan alleen de public key te krijgen. Hiermee kan een eventuele kraker ook niets.

Kijk voor de gein naar het rc5 project wat een aantal jaar heeft gelopen. daar ging het uit mijn hoofd om een 56(?) bit (triple?)des encryptie. Dat heeft al jaren gekost met vele krachtige computers ! Laat staan dat trusted mail hosts elke maand of wat mij betreft elk uur een nieuwe key genereren !

(ik hoop dat ik links en rechts geen encryptie technieken door elkaar aan het halen ben nu ;))
Het word sowieso al vrij pittig wanneer ze dingen als kerberos gaan toepassen omdat dit een encryptie is waar de huidige tijd in de sleutel word mee genomen. Active Directory is daar een goed voorbeeld van, zet alle domein controllers maar eens op een andere tijd met ongeveer anderhalf uur verschil reken maar dat je netwerk dan plat gaat. Mochten ze met brute force ooit een key te pakken krijgen dan werkt deze maar op 1 moment, een seconde later is er alweer een nieuwe key nodig.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True