IETF schaart zich achter DomainKeys

Het gaat mogelijk toch wat worden met DomainKeys Identified Mail. De anti-spam-techniek is door de IETF in een voorlopige versie goedgekeurd en voorgesteld als een uitbreiding op de bestaande e-mailprotocollen.

Met DKIM hopen de initiatiefnemers - Yahoo, Cisco, Sendmail en PGP Corporation - de aanhoudende spamgolf in te kunnen dammen. Nu de belangrijkste standaardisatie-organisatie voor internetprotocollen zijn zegen aan DKIM heeft gegeven, groeien de kansen voor de verificatiemethode. Bij het gebruik van DomainKeys Identified Mail wordt een e-mail voorzien van een digitale handtekening in de header, waarmee de afzender en het domein zichzelf identificeren. Om de standaard te laten werken moet zowel de ontvangende als de versturende partij zijn voorzien van software om elkaars identiteit te kunnen controleren. Indien een mailtje geen handtekening bevat, kan het gaan om een spambericht; een spammer geeft immers zijn identiteit liever niet prijs. DomainKeys Identified Mail geeft geen strikte regels voor de afhandeling van niet ondertekende berichten; het is dan aan de provider om dergelijke mail bijvoorbeeld in een aparte spamfolder te zetten.

De acceptatie en een mogelijk succes van DKIM staat of valt bij algemene invoering van de standaard, waardoor individuele spammers beter traceerbaar worden. De techniek wordt al sinds 2004 gebruikt door Yahoo en ook Google voorziet Gmail-berichten van een handtekening. Bedrijven als AOL, eBay, IBM, Belgacom en VeriSign hebben toegezegd DKIM te zullen omarmen. De standaard biedt volgens de initiatiefnemers op langere termijn ook meer perspectief dan het door Microsoft voorgestelde Sender ID, omdat de softwaregigant vooralsnog weigert om zijn gepatenteerde methode onder een opensourcelicentie beschikbaar te stellen. In een blogposting noemt Yahoo softwareontwikkelaar Mark Delany de goedkeuring door de IETF een belangrijke eerste stap. 'De e-mailmarkt is zo groot en divers, dat er nog veel evangelisatiewerk, voorlichting en aanmoediging nodig is om het succes van DKIM veilig te stellen,' aldus Delany.

Reacties (65)

[aliencowfarm]

Ik gebruik al een extensie in thunderbird die dit gebruikt:
https://addons.mozilla.org/en-US/thunderbird/addon/345

Een nadeel bijna geen enkele server gebruikt het. Zonder acceptatie kan je nog wel zoveel verzinnen maar dan heeft het geen nut.

[Verwijderd]

Bij onze voetbalclub hebben we 1 domeinnaam met daarbij meerdere emailadressen.

De voorzitter haalt thuis [e-mail] op en kan mailen onder die naam

De secretaris haalt thuis [e-mail] op en kan mailen onder die naam

enz. enz.

Dus vanaf diverse plaatsen wordt er gemaild met dit domein. Al deze mensen hebben hun eigen provider.

Dat werkt nu prima, met dit nieuwe systeem niet. Dus voor een hoop mensen onbruikbaar.

[Garyu]

Tuurlijk werkt dat wel. Je verstuurt die mail neem ik aan vanuit je @club.nl SMTP-server, en niet vanaf de lokale SMTP-server van je provider. Die zal dat vaak ook niet eens toestaan ("relaying not allowed").

[Verwijderd]

Deze provider heeft geen SMTP en laat je nu dus mailen via je eigen provider.

Dat werkt.

Met dit nieuwe systeem niet.

En dat dat eigenlijk niet hoort en weet ik veel wat, lekker belangrijk. Dit werkt, nieuwe techniek niet.

Dus nieuwe techniek: niet de moeite waard.

[MrMr]

Waarom neem je dat aan?
Er zijn zat providers die goedkope domeinregistratie en webhosting aanbieden zonder SMTP server op je eigen domein. Bovendien denk ik niet dat de gemiddelde gebruiker weet hoe hij thuis meerdere SMTP servers instelt, en dat zal toch echt moeten, of je prive mail wordt opeens niet meer geaccepteerd...

[Stevel]

De provider gaat e-mails die de klanten (het lokale netwerk als het ware) juist wel toestaan. Ik stuur de mailtjes van mijn gmail-adres bijvoorbeeld via de mailservers van de K.U.Leuven als ik op kot zit, als ik thuis zit verstuur ik andersom ook de mails vanaf mij K.U.Leuven-emailadres via de SMTP-server van mijn ISP.

Het systeem dat jij voorstelt lijkt meer op een open relay: iedereen zou dus mailtjes kunnen sturen via de club.nl-mailserver, zolang ze een adres gebruiken dat begint met @club.nl.

[Verwijderd]

Wat jij beschrijft is wat wij nu juist doen.

voorzitter heeft als provider chello mailt via smtp.chello.nl
secretaris heeft als provider xs4all mailt via smtp.xs4all.nl

Zo werkt dat al jaren.... Lijkt me geen open relay :-)

[trogdor]

Jawel, zo doen de meeste mensen dat wel.
En als je dat op de juiste manier in je DNS aangeeft is dat geen enkel probleem.

[Roland684]

Je kunt geen mail sturen via de mailserver van de hosting-provider,omdat jij niet op het netwerk van je hostingprovider zit
Je kunt alleen mail versturen vanaf de server van je accessprovider.

Alleen webscriptjes (zoals autoresponders en webmail) kunnen mailen via de hostingprovider.

Met het nieuwe systeem kun je vanaf b.v. een chello netwerk, alleen mailen met je chello emailadres als afzender.
Als TNT-post een dergelijk systeem zou implementeren kan je alleen nog maar post verzenden via 1 rode/oranje brievenbus in je eigen buurt en niet de brievenbus bij je school/werk/ouders in de buurt. Hoe dat spam gaat voorkomen is mij niet duidelijk, het maakt alleen een hoop handige zaken onmogelijk.

[MossMan]

Aan iedereen hierboven:

Dit is ook mijn grootste ergenis aan beide methodes - want er zijn ook een HOOP providers die je dwingen om HUN server te gebruiken ipv. een remote SMTP server!!!

Waarom...? Om spam tegen te werken, natuurlijk.


Zo kon ik bijvoorbeeld op een bepaalde moment thuis alleen maar de ISP server gebruiken en geen Yahoo!, Hotmail, enz. enz. Maar wat gebeurt er nu al als ik mail stuur van mijn eigen PC naar Hotmail met een address van mailhost X?!? Juist... mijn mail verdwijnt in het niets! (ook zonder een foutmelding terug te sturen, trouwens)

Ik ben nu gedwongen om de webmail van host X te gebruiken wil ik mijn mail gegarandeerd aan laten komen. Dit verwarring is echt een ramp, en ik ben alleen al blij dat host X een webmail service heeft... stel dat ik een server gebruik bij iemand die geen webmail wil/kan draaien.

[Xenan]

Een vreemd verhaal. Misschien moet je maar een andere provider proberen want dit heb ik nog niet meegemaakt bij geen enkele provider.

[Milt]

Helaas komt het vaker voor. Enkele van mijn klanten met een ADSL verbinding bij Planet hebben hier ook last van. Ik kom het zelf ook nog wel eens tegen als ik ergens in de wereld een hotspot gebruik (veelal problemen met Orange).

Ik snap de beweegredenen van die providers wel (zeker van de hotspot providers) maar dan zou je toch als provider ook je klant de mogelijkheid moeten bieden om het filter expliciet weer uit te zetten zodat de klant toch gebruik kan maken van zijn eigen SMTP server. Versturen via de SMTP server van de provider is niet altijd een optie.

[catfish]

klopt, maar het leuk aan het nieuwe systeem is dat jouw provider die beperking straks kan weghalen ZONDER extra risico!

[zenica]

Het is ook NOOIT de bedoeling geweest dat je gaat faken/spoofen wie je bent.

Als jullie een domain hebben dan zorg je maar voor een email server en dan kan je naar hart en lust mailen onder elke [e-mail] domain. This isn't a feature this is a bug

EDIT:
Wat deze techniek doet is niets anders dan dit:

Jou mail server krijgt een mail aangeboden die kijkt er naar en ziet staan [e-mail]. Je mail server gaat nu kijken of x.com mailtje heeft verstuurt of dat ikbeneenspammer.com dat heeft gedaan. Indien het mail daadwerkelijk van een x.com server komt dan komt het mail binnen anders niet. Dat wil zeggen als jij gewoon via outlook of via webmail connecti maakt met de x.com server je naar hart en lust kan mailen van welke locatie dan ook.

[Roland684]

Maar vrijwel elke accessprovider blokkeert smtp-verkeer naar een andere server dan hun eigen server, dat is al eens ingevoerd als mislukte poging spam tegen te gaan. Je kunt wel willen mailen via de mailserver van je eigen domeintje, maar dat kan gewoon niet. Je moet een adres (gaan) gebruiken van de accessprovider wiens lijntje je gebruikt.

Het is gewoon krankzinnig dat ik niet vanaf lokatie x een bericht kan sturen met als afzender lokatie y. e-mail wordt nu lokatiegebonden gemaakt, zonder dat duidelijk is hoe dit spam gaat stoppen.

[Verwijderd]

[Als jullie een domain hebben dan zorg je maar voor een email server

Zie daar het succes van dit nieuwe systeem...

U doet maar dit.....

Denk het niet

[zenica]

Dat is dus ook het reden waarom er zo veel spam is omdat je je kan voordoen als iemand anders, zo als ik al zij het is geen functionaliteit in het systeem maar een fout!

[StainlessSteel]

Dan zorg je toch gewoon dat iedereen via de club.nl SMTP server verstuurt. Of omdat je een derde server gebruikt, wordt er geen key toegevoegd, en heb je helemaal niets met het systeem te maken.

[Roland684]

Zonder key gaan ontvangers je mail tegenhouden omdat ze vinden dat het spam is. En je kunt je eigen mailserver niet gebruiken omdat je provider dit blokkeerd...
Mail vanaf je eigen domein (of eigenlijk beter gezegd: met jouw domein als afzender) gaat in de toekomst gewoon niet meer werken. Maar dit gaat 0 spam tegenhouden omdat spammers toch gewoon vanaf hun eigen domein mailen.

[ktf]

En als je dat nou eens zou kunnen combineren met het opengooien van de SMTP poorten van de ISP's en daarbij overstappen op beveiligde SMTP naar de SMTP server van je domein? Zou het dan wel werken?

De internetstandaarden moeten toch op de schop (of het hele internet wordt vervangen met internet 2.0) dus als dat zou kunnen, dan reduceren we spam in ieder geval.

[Morphine]

Ik vraag me af in hoeverre dit echt gaat werken. Volgens mij kunnen spammers altijd een domeinnamen registreren met valse gegevens en vervolgens onder deze domeinnamen mails versturen?

[Verwijderd]

Daar is het (in dit geval) niet om te doen... e-mail spoofing wordt zo tegengegaan...

[e-mail] kan dus alleen van ebay.com komen en [e-mail] alleen van thisismyspamsite.com

als er een email van [e-mail] komt zonder digitale handtekening kan dat dus aangemerkt worden als spam (of in ieder geval spoofing)

verder is het dus ook makkelijker om alle mails van thisismyspamsite.com (eenmalig) te weren, het opgeven van 1000 en 1 verschillende domeinen wordt zo wel ontmoedigd

[ktf]

Maar dan kun je zulke domeinen in ieder geval eenvoudiger blokkeren lijkt mij... Daarbij gaan dan de kosten van een mailtje omhoog (domeinnamen kosten geld) wat het minder aantrekkelijk maakt voor spammers.

Ik ben benieuwd, de ontwikkeling op zich lijkt me interessant. Sender ID heeft bij mij ook altijd goed gewerkt.

[TD-er]

Daarbij gaan dan de kosten van een mailtje omhoog (domeinnamen kosten geld)

Zolang bijvoorbeeld de .com registrar nog steeds een try-before-you-buy strategie hanteert, gaat die prijs voor de spammers niet echt omhoog.

[Calamor]

Lijk me dat ze dan wel in de filter zetten als een domein zoveel dagen oud is dat het ook nog spam kan zijn.

[Roland684]

Domeinen waar spam vandaan komt worden zowiezo al snel geblokkeerd. Het enige dat je er mee bereikt is dat de verzender ook echt vanaf het domein zelf moet mailen en geen verzonnen adres kan gebruiken. Maar omdat sommige spamfilters al controleren of het afzenderdomein bestaat, registreren spammers duizenden domeinen per dag om span vanaf te versturen en vaak dezelfde dag nog te laten verzallen omdat het domein inmiddels bekend staat als spam-domein.

[SlimNewRatSkin]

Dus ik moet bij elke mail mijn wachtwoord intikken?
Of doet mijn mailprogramma dat automatisch?
In dat laatste geval helpt het niet veel. Want de gemiddelde zombie-PC blijft dan vrolijk spam verzenden, compleet met de aanwezige handtekening van de eigenaar. En als die zombie-PC gewoon in een vaag land staat, met een louche provider, is er niemand die er iets tegen gaat doen.

En verder geldt (zoals ik zo vaak op tweakers lees wanneer het bijvoorbeeld om DVD's gaat): elke beveiliging wordt op den duur gekraakt.

[Fuzzillogic]

DKIM is volledig onafhankelijk van de client. Je hoeft als eindgebruiker er dus niets voor te doen.

Dat 'alles is te kraken' is onzin. Ja ook DKIM is 'te kraken' middels brute force, maar dan zijn we een paar decenia verder. Het systeem werkt met PKI, en zolang de private key veilig staat bij jouw eigen SMTP-server is het systeem veilig. (Bij AACS zijn juist de keys in handen gevallen van de hackers)

[ronny]

Dit is niet voor mailprogramma's maar voor de server.
Jouw mailprogramma stuurt het mailtje naar de mailserver van jousw provider. Deze stuurt het vervolgens door naar de mailserver van de persoon waar jij het mailtje wilt hebben.
De server van jouwprovider zet in de mail een handtekening dat het mailtje van [e-mail] is verstuurd door de server van provider.nl
Op dit moment kan ik mijn mailserver instellen op provider.nl en vervolgens mailtjes versturen.
Elke ontvanger denkt dan dat het ook zo is.
een botnet gebuikt alijd eigen mailservers en die kunnen als het goed is niet de mail ondertekenen met geregistreerde domeinen met handtekening.
Hierdoor krijgt het mailtje direct de stempel onbetrouwbaar.
Als er maar genoeg betrouwbare systemen zijn kan je automatisch de onbetrouwbare mail weg gooien zonder veel te missen en is het spam probleem opgelost.

[klakkie.57th]

dus hoe ga ik dan mijn eigen mailserver gebruiken, die nu mijn mails forward naar de smtp host van mijn provider ??

[StainlessSteel]

Het betreft hier geen systeem met wachtwoorden, maar een bepaalde gecodeerde header die alleen gecodeerd kan worden door de verzender, en met een publieke sleutel in het DNS gedecodeerd kan worden (automatisch bij ontvangst). Komt de informatie in de header NIET overeen met de eigenschappen van het bericht (o.a. To adressen, subject, sender, message-id), dan betreft het dus een spam bericht. Indien het maitje gewoon door miep verzonden is, zal de gecodeerde header altijd overeenstemmen met het bericht.

[fevenhuis]

Dit is niet persé nodig, wat er ontbreekt is volume management, beperkingen aan hoeveel één adres en/of domein aan mailtjes mag verturen, het kan makkelijk gestelt worden dat een enkele gebruiker (sender of replyadres en/of IP bijv.) geen 100.000 mailtjes per dag hoef te versturen, en dat je om zulke hoeveelheden mail te versturen je als bedrijf moet aanmelden bij ISP ofzo, ook voor nieuwsbrieven kan er dus een regeling worden aangebracht.
Een stuk minder omslachtig dan ALLE emails ter wereld apart proberen te beheersen.

[blah modhell]

[Larsie]

Aan de andere kant, wat jij voorstelt is een lapmiddel. Als een paar ISP's zich er niet aan houden heb je ook nog steeds spam.

De oplossing in het nieuwsbericht is daarentegen een echte oplossing. Het is niet zo ingewikkeld als het lijkt, het is alleen een systeem om te verifiëren dat jij ook daad werkelijk dat mailtje hebt gestuurd en niet iemand anders onder een valse naam.

[fevenhuis]

Het lapmiddel is direct toepasbaar en valt vast nog wel uit te breiden, de bovenstaande oplossing werkt alleen als we met z'n allen tegelijk springen (wereldwijd), iets wat ten sterkste valt af te raden (ook i.v.m. de bevingmeters) en daarnaast gaat om een theoretische oplossing, het kan best zo zijn dat er in praktijk zó omheen gespammed kan worden (niet geheel ondenkelijk in de computerwereld), waarna er dus in één klap zeer zware investeringen teniet worden gedaan.

[ronny]

Dit is geen stuctrurele oplossing. Dit kost heel veel tijd en moeite om dit op te zetten en te controleren.
Bovendien is dit meer symtoom bestrijding als oorzaak bestrijden.
Door te zorgen dat je weet wie de zender is kan je ook makkelijk de zender aanpakken als deze toch gaat spammen. Domein is geregistreerd en betaald dus is een eigenaar te achterhalen en domein te blokeren.
Dan is het probleem structureel opgelost.
Jou idee is net zo iets als poort 25 blokeren door providers. De spammers zoeken een andere poort en het probleem blijft bestaan.

[fevenhuis]

Nee ik heb het niet over maatregelen (zoals poorten blokkeren) gehad, enkelt over het beheren van emailtraffic (volumes) op provider nivo.
Door het email-verkeer wat niet door providers op volume gecontroleerd wordt steeds verder dicht te draaien kan er dus geleidelijk worden overgegaan op deze toepassing (lijkt het mij) en op zijn minst op korte termijn het volume van spam aardig omlaag geholpen worden, ook weer dus zonder wereldwijde software update (wat? hoekenda).

Ik heb het meer gebruik maken van de informatie die we nu voor handen hebben omdat er bekent is wie er grote volumes mail verstuurd (en moet versturen) en wie niet.
En wie grote volumes wil gaan versturen eventueel op provider nivo moet een uitzondering (max zoveel) krijgen, ik heb het dus ook over het toepassen van deze regels van providers op elkaar (dus door als ISP uit de band te springen wordt geleidenlijk aan steeds moeilijker als de grotere ISP's de volumecontroles steeds meer gaan toepassen).

Of en hoe zoiets te implementeren valt weet ik ook niet, maar zoiets lijkt mij toch een meer haalbare weg.
Overigens DKIM kan natuurlijk ook worden toegepast in combinatie met mijn voorstel oplossing en wellicht kunnen beiden en tegelijk en geleidenlijk worden ingezet.

[catfish]

dat lukt dus echt niet hoor, als een spammer 1000000 mails verstuurd naar 1000000 verschillende adressen met een script waardoor om de 10 adressen z'n email veranderd, dan gaat jouw programma dat allemaal moeten controleren, vergelijken,... wat veel te veel rekenkracht vraagt
als nu overal een ID header van de oorspronkelijke server in zit, dan kan ik direct zien waar het vandaan komt
indien deze server dan veel spam verstuurd wordt deze direct geblokt
indien er geen header is, blok je direct alles (want we gaan er van uit dat alle legitieme servers een ID meesturen)

ik weet niet of het volautomatisch kan werken, maar je kan vooral makkelijk de problemen identificeren aangezien je weet waar het vandaan komt, wat op dit moment quasi onmogelijk is
zomaar restricties opleggen is ook onrealistisch, want er zijn 1000den servers die elke dag nieuwsbrieven rondsturen die geen spam zijn

[Isnowiz]

Wat doet dit nu meer/minder dan SMTP-AUTH?

Uitstekende ontwikkeling verder...Weg met spam!

[TheGhostInc]

SMTP-AUTH gaat over de communicate client <-> mail server
Hierdoor weet een globale SMTP server welke client mail aan het sturen is(bij bijvoorbeeld je provider)

Dit systeem werkt tussen servers, dus je weet zeker dat als je een mailtje ontvangt van [e-mail], dat dat domein.nl het mailtje heeft goed gekeurd, en dat het niet door anderdomein.nl is gestuurd die eigenlijk een spammer is.

[Niemand_Anders]

Nee, dit systeem werkt van zender tot (eind) ontvanger en gaat verder dan alleen de mailservers. Ook de mail client kan de controle doen mocht de server nog geen domainkeys implementatie hebben. Veel linux mailserver zullen deze controle uitbesteden aan spamassassin of een vergelijkbaar systeem.

Het is het eenvoudigst te vergelijken met SPF DNS records in combinatie met PGP. Via SPF geef je aan welke mailservers zijn 'gemachtigd' om mail onder jouw naam te versturen. Op deze mailservers zul je je private domain key moeten installeren. Via een aantal DNS TXT records kan vervolgens de publieke key worden samengesteld.

De originele versturende mailserver voegt een extra header aan het bericht toe. Deze header 'DKIM-Signature' bevat uiteindelijk een soort van checksum.

Middels de publieke key en een aantal parameters uit de DKIM header kan de checksum worden gevalideerd.

Is de validatie succesvol, dan is de mail oorspronkelijk verstuurd door een mailserver van het betreffende domein.

Er zit echter wel een aantal kleine nadeeltjes aan dit systeem. Een slecht geconfigureerde DNS server kan gevoelig zijn voor DNS injection (Dynamic Updates) waardoor ook niet authoritive mailservers aan het domein kunnen worden toegevoegd. Spam welke via dergelijke mailservers wordt verstuurd zal NIET als spam worden aangemerkt. Ook werkt het systeem niet als een van de authoritive mailserver een open relay vormt.

[Sendy]

Wat is dan het nut van deze domain keys boven SPF? Als het enige gebruik is het verifieren of een e-mail door de gemachtigde SMTP server verstuurd is, dan is een ipadres toch voldoende?

[arjankoole]

Er zit echter wel een aantal kleine nadeeltjes aan dit systeem. Een slecht geconfigureerde DNS server kan gevoelig zijn voor DNS injection (Dynamic Updates)

Het merendeel van de nameservers is bind volgens mij, en het leuke van bind is dat je zones niet kan 'mixen'. Dus het kan niet een dynamic, en een normale zone zijn. Dus, als iemand de zonefile heeft gemaakt / gegenereerd, dan kan je nooit meer via DNS injection iets aan die zone veranderen.

En met dynamic zones kun je volgens mij alleen maar IN A toevoegen, niet zaken als IN MX, IN TXT, etc.

[mariusvw]

Heb de kans nog niet gehad me er mee bezig te houden, vraag me toch alleen wel af hoe ze dat gaan doen.

Dit wil zeggen dat je voor elk domein een key moet hebben.

Mooi als je een shared cluster hebt met >300 domeinen er aan vast gekoppeld.
Elk domein een key is me duidelijk, maar dat betekent wel dat _elke_ ontvanger wel de nodige checker moet hebben om iets met die key te doen.

Daarnaast, Het blocken van domeinen kan je dan wel doen maar als je de key van een ander domein weet te bemachtigen kan je dus spammen met dat domein en dus word iemand die 'er niets aan kan doen' geblocked?

Okay, tijd om me er in te verdiepen, merk het al

[zenica]

Ik denk dat dit voldoende is voor je antwoord:


DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier
requests the public key from a repository in the domain of the
claimed signer directly rather than from a third party.

The DNS is proposed as the initial mechanism for the public keys.
Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available.

[gamepower2005]

Spammers maken vaak gebruik van botnets. Wat weerhoudt een spammer om de identiteit van een gehackte persoon te stelen, en die in de e-mail te zetten?

Ik denk niet dat encryptie hier veel aan kan doen, waardoor ik me afvraag wat het nut nog is van de Domainkeys.

[ktf]

Het handige is dat je bij een gestolen identiteit meteen na kunt gaan dat die persoon zich in een botnet bevindt, en die kan daarvoor gewaarschuwd worden denk ik. Nu kan dat nog niet omdat de gebruikers er zich helemaal niet bewust van zijn.

[mashell]

Maar wat zal de gebruiker doen die een "you are member of a botnet" mailtje krijgt? Het mailtje waarschijjnlijk als spam beschouwen en het in de prullebak smijten.

[Distael]

Je ISP krijgt die mail toch ook? Simpel om dan als ISP te melden dat je mail is geblokkeerd totdat je ervoor hebt gezorgd dat je geen Spam meer verstuurd!

[mashell]

Je ISP krijgt die mail toch ook

En die gaat jouw email toch niet lezen? En al helemaal geen actie ondernemen op iets wat een derde van buiten schrijft? Dus als een ISP botnets willen bestrijden zullen ze bijvoorbeeld aan hun eigen poorten moeten snuffelen en gebruikers bijvoorbeeld maximaal 100 mails per dag toestaan.

[Xenan]

@ mashell: Heb je wel eens van het kopietje gehoord: cc:
Als een persoon wordt verdacht van het onderdeel zijn van een botnet zal ook de ISP wel gewaarschuwd worden, juist omdat de ISP beter zal begrijpen waar het over gaat.

[sb37]

Maar als je daarintegen 1000 (of meer) mailtjes krijgt met de melding "you are member of a botnet" kan ik mij niet voorstellen dat je dan nog aan spam denkt.

[Roland684]

inderdaad, dit biedt geen enkele bescherming tegen botnets. En gebruikers/providers op de hoogte stellen van een sequrity-breuk op een specifieke machine, is veeeel te traag, dan is de spam al lang verstuurd.

[edit]
@BlackOwl: Nee hoor. Dit systeem werkt niet met blacklists, meer verplicht alleen dat jij ook inderdaad mailt vanaf het domein waar je vandaan zegt te mailen. Zolang een bot op het chello netwerk maar @chello.nl afzender-adressen gebruikt, komt de mail gewoon door, ook al blijft die bot jou jarenlang doorgaan met mail sturen van [e-mail]. Die bot kan alleen geen mail meer sturen vanaf het chello netwerk met als afzender [e-mail]. Het enige dat dit systeem doet is vaststellen "hey, deze mail zegt van kpn af te komen, maar komt van chello, dan zal het wel spam zijn." Maar zodra dat werkelijk spam gaat tegenhouden, nemen de spammers wel de moeite om even de juiste providernaam in te stellen.
Het enige dat ermee bereikt wordt is dat vastgesteld kan worden dat ergens van binnen het chello netwerk mail gestuurd wordt, maar dat was dankzij de mailheaders toch al geen probleem.

[BlackOwl]

Kan zijn, maar een volgende lading spam van dezelfde bot kan zo voorkomen worden.

[ktf]

Het systeem werkt ook niet met blacklists, maar mijn spamfilter eventueel wel, als zo'n systeem er komt. Als de spammer niet te vlug van domein wisseld in ieder geval....

[Verwijderd]

Ben benieuwd, nu mail ik via een andere poort en dus ook naam mijn mail omdat mijn provider poort 25 geblocked heeft. Is dit dan straks ook niet meer mogelijk

[Sendy]

Jij kan geen andere port dan 25 gebruiken om direct e-mail naar toe te sturen. Jij stuurt je e-mail eerst naar een relay. Deze relay kan dan natuurlijk ook die headers toevoegen voordat je e-mail het net op gaat.

[MittaM]

Zoals al meer tweakers zeggen. De domainkey is vast en zeker ook wel te faken. De spammer kan tenslotte gewoon een valse domainkey meesturen of licht het toch wat ingewikkelder? Zo ja dan zijn er altijd nog de botnets. Zolang die botnets er zijn omdat teveel mensen hun pc niet goed beschermt hebben blijft de spam golf groeien.

Grtz,
Mitta