Antispamtechnieken stap dichterbij standaardisering

De Internet Engineering Steering Group, onderdeel van de Internet Engineering Task Force, heeft 'experimentele' RFC's gepubliceerd voor twee concurrerende antispamtechnieken, Sender Policy Framework en Microsofts daarop gebaseerde Sender ID. Vorig jaar september liet de IETF Microsofts Sender ID-technologie nog vallen omdat de softwarereus een aantal patenten geheimhield. Het nog steeds ontbreken van consensus over welke techniek gebruikt moet worden noopte de standaardiseerders kennelijk beide technieken de status van 'experimenteel' te verlenen; maatregelen tegen spam, phishing en ander ongerief nodig zijn immers steeds harder nodig. Discussies en praktijktests moeten nu duidelijk maken welke standaarden officieel zullen worden.

SPF, dat al door rond de vijftigduizend mailservers gebruikt wordt, controleert aan de hand van het "From"-adres of mail afkomstig is van een mailserver die door het bijbehorende domein geautoriseerd is. Het nadeel van deze techniek is uiteraard dat domeinen bijzonder goedkoop en bovendien redelijk anoniem te verwerven zijn. SPF zal een goede bescherming tegen phishing geven, maar tegen spam is dit systeem minder effectief als er niet ook actief domeinen geblacklist worden. Sender ID is een combinatie van SPF en Microsofts 'Caller ID'-technologie. Critici beschuldigen de softwarereus ervan zijn oplossing erdoor te willen drukken; bovendien is Caller ID beschermd door een licentie die het Microsoft toestaat om het gebruik door developers onder bepaalde voorwaarden te verbieden. Het vrij intensieve tweerichtingsverkeer dat Sender ID vergt, maakt het systeem bovendien kwetsbaar voor denial of service-aanvallen.

Naast deze twee technieken zijn er nog andere deelnemers aan de strijd om anti-spamstandaarden. Yahoo promoot het cryptografische en daardoor resource-intensieve DomainKeys, dat niet alleen gebruikt wordt om de afzender de authentificeren, maar ook om de inhoud van de mail te beschermen. Daarnaast is er nog de CSV-standaard, die volgens IETF's Andrew Norton naast Sender ID gebruikt kan worden. Welke van al deze technieken uiteindelijk zal zegevieren zal de tijd moeten leren.

Reacties (13)

...concurrerende antispamtechnieken... ...beschermd door een licentie... ...deelnemers aan de strijd... ...uiteindelijk zal zegevieren...

Waar zijn we nou mee bezig dan? Wat zijn de doelen van deze organisaties/bedrijven? Eigen standaarden promoten/doordrukken of eindelijk eens wat aan die spam doen? Waarom kan er nou nooit effectief samengewerkt worden om het de consument beter te maken?

Het is toch ongelooflijk dat telkens het eigen belang boven het belang van de gebruiker gaat. Tuurlijk, het is hun geld, maar uiteindelijk levert goed samenwerken om spam te voorkomen meer op dan eigen standaardjes promoten. (HD-DVD/BlueRay anyone?)
Laat ze nu eens objectief kijken naar de techniekjes en beslissen wat het wordt, geen uitstel van executie...

Ja.. zo werkt het hier op aarde dus niet.
Objectbeveiligingsbedrijfjes varen wel bij criminelen die gaan struinen op industrieterreinen.
Antivirusbedrijfjes varen wel bij (zelfgemaakte) virussen
Antispambedrijven varen wel bij SPAM

Er zit gewoon geld in beveiliging. Dat laat je dan toch niet liggen..

Nou als IBM en Sun samen kunnen gaan werken kan dat ook wel.. het enige wat nodig is...... is een beetje inzet!

Waar zijn we nou mee bezig dan? Wat zijn de doelen van deze organisaties/bedrijven? Eigen standaarden promoten/doordrukken of eindelijk eens wat aan die spam doen? Waarom kan er nou nooit effectief samengewerkt worden om het de consument beter te maken?

Dat is dus één van de grote nadelen van het kapitalisme. Het draait niet meer om het dienen van de consument en hun behoefte, maar om het verdienen van geld door de behoefte van de consument te gebruiken.

Je kan het ook positiever zien. Wellicht zijn beide partijen overtuigd dat hun oplossing het beste voor de consument is, en willen dus niet toegeven zodat de consument uiteindelijk met een slechte oplossing zit.

Gebruik van SPF+caller ID is beter dan alleen SPF, maar daartegenover staat dan weer dat er een licentie nodig is voor caller ID die niet iedereen kan/wil nemen.

Is dus moeilijk te zeggen welke situatie voor de consument uiteindelijk beter uitpakt. Technisch betere beveiliging in minder programma's, of technisch mindere beveiliging in alle programma's.

Je kan het ook positiever zien. Wellicht zijn beide partijen overtuigd dat hun oplossing het beste voor de consument is, en willen dus niet toegeven zodat de consument uiteindelijk met een slechte oplossing zit.

In het geval van MS: als dat zo was, waarom hebben ze die licenties dan zo gemaakt dat ze weten dat ze voor OSS projecten onacceptabel zijn?

Tja, het lijkt inderdaad weer de HD-DVD vs. BlueRay all-over te gaan worden....

Kennelijk is commercieel belang nog altijd belangrijker dan een mega-image verbetering door te stellen als markt: We slaan de handen ineen, en komen met een gecombineerde methode die voor iedereen beter is... Ok... dan verdienen we maar veel minder, en lopen we de kans om misschien marktleider te worden met onze individuele oplossing maar mis...

Het zijn nog steeds bedrijven die erachter zitten, geen Open-Source initiatieven....

Misschien een idee, om een SourceForge projectje te openen, en daarin alles pogen te combineren...

Toegeven, NOG een kandidaat is niet wenselijk maar kijk eens naar bijv. Trillian.....

Grappig dat ik op Microsoft's site over Sender ID (http://www.microsoft.com/senderid) weinig kan vinden over het toegevoegde Caller ID en vervolgens Sender ID hetzelfde is als het gewone SPF. Zie bijvoorbeeld de 'How it works?' pagina. Mooie beschrijving hoe Sender ID werkt, of toch gewoon SPF?

Ik hoop dat het snel een beetje onder controle krijgen. Al hoewel ik denk dat het vrij wel onmogelijk is. Er zullen altijd wel weer nieuwe manieren worden gevonden om te spammen

Spammers ondersteunen dit soort sender validatie technieken veel sneller dan normale email programma's.Nu al passeert er 6 keer zoveel spam de SPF filters dan gewone email. Tel uit je winst....

Standaardisering heeft naar mijn visie echt geen doen, er worden toch wel nieuwe manieren gevonden, spyware door backdoors van software, popups door lekken in de browsers, ga zo maar door. Spam blijft, zen zij iemand een systeem ontwikkeld wat ALLES controleerd en kan denken als een mens!

PS, voor de mensen die het willen weten, zo'n systeem komt toch niet de komende 10 jaar!

Standaardisering heeft in dit geval wel degelijk zin.

Het spamprobleem wordt immers niet veroorzaakt doordat spammers allerlei backdoors of lekker vinden, maar doordat de SMTP specificatie gewoon niet meer van deze tijd is.

Als je die specificatie kunt aanpassen zou je spam effectief aan kunnen pakken. Maar ja, dat is niet zo makkelijk en bovendien moet iedereen het ook gaan gebruiken voordat het effect heeft.

Betekent het met SPF dat als ik mail stuur van mijn eigen SMTP server, die thuis staat, dat het altijd als spam wordt gemarkeerd?

Het encrypten van DomainKeys snap ik ook niet helemaal. Daar zijn al systemen voor, met publieke keyservers en al (GnuPG/GPG (opensource) en SMIME (commerciëel))