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 , , 28 reacties
Bron: Reuters

Versleutelen / Key / EncryptionYahoo en Earthlink hebben bekendgemaakt dat ze samen de DomainKeys-antispamtechnologie zullen testen. Met deze technologie wordt een versleutelde handtekening in het bericht vergeleken met de handtekening die opgeslagen werd op de server die de e-mail verstuurt. Als deze handtekeningen niet overeenkomen kan de ontvangende server beslissen het bericht te weigeren omdat het spam zou kunnen zijn. Volgens experts zou de DomainKeys-technologie weliswaar veiliger zijn dan Microsofts Sender ID, maar ook moeilijker te implementeren en tien procent meer rekenkracht vergen. Een van de bedrijven die DomainKeys al geļmplementeerd heeft is Google, voor zijn e-maildienst Gmail.

Moderatie-faq Wijzig weergave

Reacties (28)

Ik vindt de 10% meer rekenkracht eigenlijk niet zo'n argument, over 10 jaar zal voor hetzelfde systeem nog steeds dezelfde hoeveelheid rekenkracht nodig zijn (bij gelijkblijvende hoeveelheid mail). Je hardware 3 maand later kopen zorgt er bij wijze van spreke al voor dat je geen extra kosten kwijt bent door de extra rekenkracht die het vergt.
Wellicht dat je er rekening mee moet houden dat over tien jaar de implemantatie/mogelijkheden en gebruik van emial ook veranderd zijn waardoor de belasting op de systemen ook toeneemt en die 10% wel uitmaakt.
Als deze techniek werkt, moet het spam flink terugdringen. Minder spam betekent minder load op de servers. De techniek bespaart dus juist rekenkracht, data communicatie, opslagruimte, etc.
nu kan er in mail wel heel veel veranderen maar de belasting voor een systeem blijft hetzelfde er wordt namelijk een code gegenereerd en meegezonden met het bericht. Dus bij grotere mails blijft de belasting hetzelfde. Het enige waar het voor uitmaakt is de hoeveelheid mail die verzonden gaat worden in de toekomst.
een persoon kan maar een bepaad aantal mails per dag verzenden en dit getal zal mischien in de toekonst wel wat hoger worden maar niet exponentieel groeien.
Dus systeem belasting is niet zo'n probleem maar implementatie kan voor grotere problemen zorgen. Als het koppelen van systemen lastig gaat is het heel goed mogelijk dat hierdoor tal van problemen gaan ontstaan waardoor spammers alsnog misbruik kunnen maken van het systeem. Er valt te denken aan systemen die verkeerd zijn geconfigureerd, enz enz.
Wellicht dat je er rekening mee moet houden dat over tien jaar de implemantatie/mogelijkheden en gebruik van emial ook veranderd zijn waardoor de belasting op de systemen ook toeneemt en die 10% wel uitmaakt.
Je vergeet een aantal dingen:
1. Veel servers draaien momenteel anti-spam en anti-virussoftware. Die hebben ook behoorlijk wat resources nodig ;), met name de anti-spam-software die werkt op basis van patroonherkenning en bayesian filters.

2. SMTP [1], het protocol dat gebruikt wordt voor het verzenden en afleveren van e-mail, is al meer dan 20 jaar oud. Het feit dat het zo wijdgebruikt en -geimplementeerd is heeft er voor gezorgd dat er een onuitroeibaar protocol gebruikt wordt voor mail, terwijl het feitelijk allesbehalve afdoende is voor goed- en veilig gebruik van dit communicatiemiddel. Mijn punt is: ik zie niet zo snel dingen meer veranderen als het gaat om het SMTP, en kan me dan dus ook weinig voorstellen bij wat je nieuwe "implemantatie/mogelijkheden en gebruik van email" noemt. Wat er de afgelopen jaren met name gebeurd is, is lapmiddelen voor een (imo) slecht opgezet protocol voor de toepassing waar het nu voor gebruikt wordt :)

[1] RFC 821
10% is niks vergeleken bij de kracht die huidige spamfilters opeisen. Als dit waterdicht is heb je die niet meer nodig.
Jammer genoeg is et niet waterdicht. Als een spammer een PC overneemt via spyware en vervolgens mail begint te sturen vanaf die PC's domein zal de mailserver aan de andere kant netjes de domeinkey kunnen opvragen bij die gehijackte PC.
Da's waar, maar de spammer moet dan wel met een e-mai adres sturen waar de gedupeerde mee mag sturen, anders wordt de mail alsnog geweigerd, dus is het voor gespamden makkelijk de provider van de gedupeerde aan te spreken, die vervolgens met de klant het een en ander moet regelen
Maar als computer sneller worden wordt het doorgaans ook makkelijker om beveiligingen te kraken, dus is het vereist om de beveiliging omhoog te gooien = meer cpu kracht nodig...
Jij gaat nu denk ik uit van de kant van de client, maar wat denk je dat 10% kost voor e-mailservers waar vele e-mailaccounts gehost worden?

Alleen al het stroomverbruik neemt toe en daarmee de kosten.
Dat niet alleen, als ik een serverpark heb van 500 servers die staan te stampen, betekend dit dat ik er 50 bij moet gaan kopen. Dat is ongeveer 50*2000 = 100.000 euro (jaja, goedkope servertjes :p). Daarbij komen nog kosten voor je stroomvoorziening (ups enzo), de aanpassing van je airco en persooneels kosten voor het inrichten en onderhoud.

Vind ik toch wel een redelijke investering voor het gebruik van domainKeys.

Overigens moet je ook nog eens enorm veel mail gaan bouncen (zeker in het begin)
Overigens moet je ook nog eens enorm veel mail gaan bouncen
Da's natuurlijk niet slim. Als je d'r toch van overtuigd bent dat het spam is, kun je de mail in kwestie beter droppen
500 servers die mail staan te stampen?

Hoeveel miljoenen mails wil jij wel niet per dag versturen?
Ik denk dat gmail en dergelijke best veel emails willen versturen
Klopt allemaal wel, dat je die 10 procent serverload wel over mag hebben voor het bestrijden van Spam, maar dit is 10 pocent extra t.o.v. een concurrerend systeem.
Je kunt dus hetzelfde bereiken met 10% minder cpu-load, en dan zou ik kiezen voor het concurrerende systeem. Kun je weer met een server minder toe in een serverpark :-)
(correct me if i'n wrong...)
het is niet een tijdskritische taak voor een server en kan daarom dus ook met een lagere prioriteit uitworden gevoerd. Ergo je zult er eigenlijk niet veel van merken want de webserver taken etc. hebben toch voorrang. Je zult het alleen merken op dedicated mail servers daar is het gewoon een extra 10% en wat extra ruimte voor opslag.
Imho gewoon doen! (mits een goede implementatie mogelijk is natuurlijk!))
Als de systeem kracht 10% toeneemt en de spam over dezelfde periode volgend jaar met pakweg 40% afneemt dan denk ik dat de "winst" al eruitgehaald is. Verder is 10% rekenkracht op korttermijn al overtrefbaar, daar zie ik het probleem ook niet in.

Alleen: DomainKeys MOET ECHT naar behoren werken en niet te veel achterdeurtjes achterlaten en gaten moeten snel gedicht worden.
Ja, precies. Die 10% extra investering haal je er verderop in de lijn wel weer uit. Alle mail die je eruit filtert, hoeft niet meer te worden doorgestuurd. Daar bespaar je dan opslagruimte, netwerkbandbreedte en cpu-tijd mee.
Volgens experts zou de DomainKeys-technologie weliswaar veiliger zijn dan Microsofts Sender ID, maar ook moeilijker te implementeren en tien procent meer rekenkracht vergen.
So what, als het beter werkt.... Die nadelen vallen toch compleet in het niet met de kosten die al die spam nu met zich meebrengt :?
Dit gaat dus volgens mij alleen werken als op alle mailservers ook die key te installeren. Ik heb daar niet zoveel vertrouwen in, gezien het feit dat er nog steeds veel te veel open mailservers zijn.

Daarnaast zou dit denk ik betekenen dat je alleen nog mail kunt versturen vanaf het domein waar dat email adres op geldig is. Dus ik moet smtp.yahoo.com gebruiken als ik mail wil versturen van mijn ikkuhbestanie@yahoo.com. Niet erg handig als ik met mijn laptopje thuis zit en gewoon smtp.wanadoo.nl wil gebruiken en een uurtje later bij een klant en smtp.xs4all.nl wil gebruiken. En als ik toch al bij die klant zit, en ik wil dan een mailtje vanaf mijn wanadoo account sturen, dan kan ik niet eens de wanadoo mailserver gebruiken, want die zegt (hopelijk) relaying not permitted.

De eerste stap om spam te fighten is dat mailservers gewoon goed worden geinstalleerd: geen fake headers meer toestaan, netjes de history in de header toevoegen en bij twijfel meteen melding maken in de header. Verder geen open relay servers toestaan. En bij klachten de mogelijkheid dat incorrect ingestelde mailservers gewoon botweg van internet worden afgesloten. Beetje moeilijk, want het beheer van de DNS (en dus de MX records) ligt meestal gewoon bij dezelfde beheerder. Dus dan maar afkoppelen van het hele domein. Jaren geleden is dit een aantal keren gebeurd in de VS en de betreffende domeinen hebben allemaal eieren voor hun geld gekozen.
Dit gaat dus volgens mij alleen werken als op alle mailservers ook die key te installeren.
Elk domein is verantwoordelijk voor z'n eigen keys. Als het je als eigenaar van een domein niets uitmaakt dat mensen spam versturen met jouw domein.. tsja, dan verdien je het gewoon om op een blacklist te komen. :)
Daarnaast zou dit denk ik betekenen dat je alleen nog mail kunt versturen vanaf het domein waar dat email adres op geldig is. Dus ik moet smtp.yahoo.com gebruiken als ik mail wil versturen van mijn ikkuhbestanie@yahoo.com.
Precies.
Niet erg handig als ik met mijn laptopje thuis zit en gewoon smtp.wanadoo.nl wil gebruiken en een uurtje later bij een klant en smtp.xs4all.nl wil gebruiken. En als ik toch al bij die klant zit, en ik wil dan een mailtje vanaf mijn wanadoo account sturen, dan kan ik niet eens de wanadoo mailserver gebruiken, want die zegt (hopelijk) relaying not permitted.
In elke fatsoenlijke mailclient kun je per identity instellen welke uitgaande mailserver gebruikt moet worden, dus dat maakt niks uit. Op welke manier je spam ook aan wilt pakken, zolang je mail maar via elke mailserver kunt versturen wordt het niks.
De eerste stap om spam te fighten is dat mailservers gewoon goed worden geinstalleerd: geen fake headers meer toestaan, netjes de history in de header toevoegen en bij twijfel meteen melding maken in de header. Verder geen open relay servers toestaan.
Je kunt de verantwoordelijkheid wel volledig bij de gebruikte mailserver leggen, maar zolang dat elke mogelijke open relay van elke willekeurige gebruiker kan zijn schiet het niet op. Als je dat kunt beperken tot de paar mailservers van een domein zelf, is dat al een grote winst.
Lijkt me juist handig, als ik nu thuis zit moet ik de @Home SMTP gebruiken, en op school weer een andere, en bij een vriend weer een andere... liever een en dezelfde voor een mailadres, lijkt me veel makkelijker?
[edit]
Ja, je hebt gelijk inderdaad. Alleen moeten alle servers SMTP AUTH gaan ondersteunen (of een andere authenticatie techniek).
[edit]
gewoon de doodstraf instellen voor spammers. is het zo afgelopen met die ongein :+
Wat is nu 10% extra rekenkracht vergeleken met de disk capaciteit die de berichten in beslag nemen om deze op te slaan.
..requires about 10 percent more computing power to process.
Wat MIJ nou interessant lijkt om te weten is 10 procent meer dan WAT, wat is de benodigde "computing power" van de andere methode? Als de andere methode 0.01 procent van de totale "computing power" kost en dit wordt 10 procent meer dan wordt het 0.011 procent van de totale "computing power".
Aangezien dit nergens duidelijk staat vermeld (ook niet in het bron artikel), en tevens het begrip "computing power" niet nader wordt toegelicht vind ik het nog niet zulke sterke tegenargumenten.
DE nadelen wegen imho niet op tegen de voordelen. Het laatste jaar is er enorm veel te doen geweest rond spam en hoe schadelijk het is voor het bedrijvsleven (en ook ons priveleven). Dan vind ik dat men wel een extra inspanning mag doen.
Helemaal correct, maar ook als jij als gebruiker meer moet betalen? Heb jij het er dan voor over?

Ik wel, maar velen vast niet.

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