Microsoft maakt SenderID openbaar

Microsoft heeft aangekondigd dat het de wereld wil helpen in de strijd tegen spam en 'toevallig' heeft het bedrijf daar nog wel een technologie voor in de kast liggen. Het bedrijf gebruikt de antispamtechnologie al voor zijn Hotmail-dienst, maar slaagde er desondanks niet in brede acceptatie voor de standaard te krijgen. Door het framework nu onder de Open Specification Promise vrij te geven, maakt Microsoft het mogelijk voor iedereen die een mailserver wil inrichten Sender ID te implementeren zonder een licentie te moeten nemen. Met de OSP-vrijgave verzekert Microsoft gebruikers van de technologie bovendien dat zij niet aangeklaagd zullen worden wegens patentschending. Eerder werd het Virtual PC Hard Disk-formaat ook al onder dit programma vrijgegeven. Of de vrijgave echter een stormloop op de technologie tot gevolg zal hebben, is twijfelachtig. Heel wat bedrijven hebben al concurrerende technologieën als SPF en CSV geïmplementeerd.

Reacties (41)

[martdj]

Zolang bedrijven geen Sender ID of SPF record implementeren gaat dit natuurlijk nooit werken. Het is een kip en het ei verhaal. Alle legale zenders moeten een record (in DNS) aanmaken om dit nuttig te laten zijn, maar aangezien dit momenteel toch niet werkt, nemen verreweg de meeste bedrijven niet de moeite om zo'n record aan te maken. Het aantal bedrijven met record is zelfs aan het afnemen.

Overigens maakt dit idee ook een heel normale werkwijze voor particulieren onmogelijk. Stel ik wil een mailtje sturen en ik gebruik mijn @gmail.com als standaard mailadres. Ik stuur het mailtje vanuit thuis waarbij Orange mijn provider is. Vanwege dit laatste moet ik mijn mails versturen via de smtp server van Orange. Dat is echter weer geen legale zender voor het @gmail.com domein en dus zou mijn mailtje als SPAM bestempeld worden. Ik vind het persoonlijk geen goede zaak.

Edit: De opmerking dat het aan het afnemen is, is misschien een beetje verwarrend. Wat ik eigenlijk bedoel: Met SPF moet je aangeven welke smtp servers mail voor jouw domein mogen versturen. Daarbij moet je aangeven hoe zeker je ervan bent dat dat alle servers zijn die mail voor jouw domein versturen. Wat je momenteel merkt is dat een hoop bedrijven die een SPF record hebben aangemaakt, merken dat er toch meer servers zijn die mail voor hun domein mogen versturen dan ze oorspronkelijk dachten. Als je daardoor een aantal keren legitieme mail van jouw domein terug ziet komen omdat er nog toch nog een mailserver blijkt te zijn die mail voor jouw domein mag versturen, worden veel beheerders lui en maken van de -all maar ~all of zelfs +all. Vooral met die laatste breng je SPF effectief om zeep. Toch neemt het aantal SPF records van dit type toe.

[halfgaar]

martdj, je hebt gelijk. Ik heb dat dus met een e-mail adres van mij. Mensen krijgen nog wel eens mail terug die ze naar mij sturen en geven mij dan de schuld...

Als mensen hun SMTP config niet zo instellen dat voor afzender adres x.com ook de SMTP van x.com wordt gebruikt, gaat het niet werken. En omdat er veel mail providers zijn die geen SMTP leveren, wordt dat een heel lastig verhaal.

Ik vind SPF eigenlijk een ontwerpfout. Zo kan je geen e-mail provider gebruiken die losstaat van je ISP, als ze geen SMTP leveren teminste. Ik ben benieuwd of die andere technieken dat beter doen.

[Firefox]

Ik kom het vergelijkbare probleem tegen met SPF record voor een bepaalde instantie. Deze (hogeschool/universiteit) heeft SFP record opgenomen, maar instrueert haar medewerkers niet om gebruik te maken van een specifieke (authenticated) smtp relay om de mail daarwerkelijk te versturen. Dan triggeren de SPF filters inderdaad....

De houding die jij je aanmeet is echter onjuist. Als GMail een geauthentiseerde smtp relay beschikbaar stelt waarbij een ieder met een G-mail account namens dat gmail account kan versturen via die relay met als afzender dat zelfde gmail account (Dat moet te regelen zijn), dan is er geen enkele reden om het voor een particulier een probleem te laten zijn om het zo te gebruiken.

De kern van het probleem zit hem niet in ontwerpfouten van SPF, da's bullshit, het zit in een protocol dat gebruikt is voor een compleet open communicatie in een compleet open en "ik vertrouw iedereen" houding van Univeristeiten: SMTP. Dit probleem is gigantisch groot, en los je niet op door je telkens te blijven verschuilen achter verworven vrijheden. Als (mail)provider ten alle tijde toegang bieden via authenticated relay smtp servers voor hun eigen klanten, dan is het nooit nodig naar een ander mail systeem uit te wijken met dat mail adres. Dan kan SPF, of SenderID in princiepe prima werken. Dat het nu niet lukt ligt aan de bereidheid bij de wereld om er tijd in te steken. Als ik het met een halfdagje lezen hoe en wat via www.openspf.org er uit kan komen, dan moet elke andere mailserver beheerder dat ook kunnen regelen...

En als bedrijf heb je sowieso veel meer invloed op hoe je medewerkers mailen... dus daar is het sowieso uitstekend toe te passen.

[Olaf van der Spek]

Zo kan je geen e-mail provider gebruiken die losstaat van je ISP, als ze geen SMTP leveren teminste.

Dat is toch een fout van die ISP en niet van SPF?

[dmace]

Dat het aan het afnemen is lijkt me nogal onwaarschijnlijk. Dat zou alleen zo zijn als het problemen op zou leveren. Aangezien het dat niet doet, haalt niemand het weg.

Heb al een paar gevalletjes SPF langsgehad. Boze belletjes van mensen die niet konden mailen naar ons. Bij nakijken in de logs en navragen bij de mailmanager/systeembeheerders van de desbetreffende persoon had deze heerlijk maar z'n eigen mailservertje opgezet zonder toestemming of medeweten van het bedrijf. Foutje Bedankt!

Zomaar een voorbeeld waarom ieder bedrijf even 5 minuten zou moeten steken in het opzetten van een SPF-record.

SPF is in ieder geval beter dat wat bijvoorbeeld Tiscali gebruik om spam tegen te gaan - Sender verification. Handig hoor, als als techniek om spammers te trappen de meeste mailserver toch wel ja tegen alle adressen zeggen.

[Roland684]

Zolang je toch nog mail zonder sender-id moet accepteren omdat vrijwel geen enkele mail het heeft, kun je er toch geen spam mee blocken (uitgegaan van de foutieve aanname dat spammers per definitie geen sender-id zullen gebruiken)

En als het niets oplost en er geen enkel uitzicht is op dat het dat op redelijke termijn wel gaat doen, waarom zou je er dan moeite in steken?

Het was een leuk stukje speelgoed,maar bij de volgende mailserver die opgezet wordt, wordt het weggelaten omdat het zinloos is en alleen maar voor problemen kan zorgen.

[Sendy]

Je begrijpt het niet. Het is niet een kwestie van "als sender-id/SPF niet beschikbaar dan blocken", het is een kwestie van "als sender-id/SPF foutief dan blocken".

Je kan dus prima nu al SPAM blocken. Voorbeeld: Ik krijg een e-mail van ene [e-mail] via de computer spam.zombie.nl. Ik vraag bij keurigdomein.nl op welke SMTP servers e-mail voor keurigdomein.nl mogen sturen. Bij de lijst die ik terugkrijg staat niet spam.zombie.nl. Ik kan dus blocken.

[Roland684]

Dan registreer ik toch spam2348965275.nl en doe niet mee met microsofts systeempje. Omdat jij de afzender niet kunt controleren (zoals vrijwel elke afzender) accepteer je de mail toch maar.
Dus hoe hou jij mij als spammer nou tegen?

(Natuurlijk wordt morgen spam2348965275.nl geblokkeerd, maar dan registreer ik vrolijk spam2348965276.nl)

Het enige dat je met dit systeem bereikt is dat cafe De Grote Zuiper niet meer kan mailen over de tweakdsl ADSLlijn in het cafe en [e-mail] gebruiken als afzender, maar een het bij de verbinding horende tweakdsl-adres (of een degrotezuiper.nl-webmail) moet gebruiken.

[Chatslet]

Onzin, dan sturen ze daar lekker via smtp.degrotezuiper.nl omdat dat domein door een goede systeembeheerder wordt beheerd is dat een smtp server met authenticatie.
Ik zie het probleem niet zo....

[Sendy]

Onzin degrotezuiper.nl kan in zijn SPF records prima de SMTP server van tweakdsl opnemen.

Verder heb je gelijk dat een spammer een eigen domein kan nemen en ik die e-mails dan niet (wegens SPF) kan blocken. Maar goed, dat doen spammers meestal ook niet; die nemen een bestaand domein. En dan kan het wel helpen.

SPF/sender-id is ook niet de oplossing; zie het meer als radartje in het geheel. Het heeft weinig inpact op bestaande domeinen (want je kan niet blocken als er geen SPF is), en je kan het met een kleine aanpassing wel gebruiken. En als alleen het probleem van misbruikte domeinnamen wordt opgelost zijn er al een boel mensen gelukkig

[mjtdevries]

SPF/SenderID is wel de oplossing.

Alleen nog niet tijdens de beginfase waarin veel domeinen nog geen SPF record aangemaakt hebben.

Maar wanneer dat wel gemeengoed is geworden, ga je gewoon ook de domeinen blokkeren die geen SPF record hebben.

[feuniks]

Jij gebruikt Gmail als voorbeeld. En laat dat nu eens het juiste voorbeeld te zijn waarom deze techniek wel kan werken:

Gmail heeft naast de POP mailserver, die jij gebruikt voor het binnenhalen van je mail ook een SMTP server. Deze server kun je ook gebruiken. Alleen moet je je aanmelden op die server met je gebruikersnaam en wachtwoord.

Wat de providers en bedrijven dus moeten doen is het openzetten van de mailservers met de beperking van een gebruikersnaam en wachtwoord. Op dat moment kun je deze techniek mooi inzetten en gebruiken en zul je merken dat ook een hoop spam kan worden weggevangen.

Je kunt als je deze truuk zelfs nog een beetje strikter doorvoeren: Als je al besluit om aanmelden noodzakelijk te maken om mails te mogen versturen via een server, waarom dan niet ook meteen specificeren welke mails: een provider weet welke mail adressen bij welk account horen. Waarom niet ervoor zorgen dat je alleen maar mails kunt versturen vanuit de mail adressen die bekend zijn bij jouw account.

Ik denk dat dit soort technieken het probleem van SPAM behoorlijk kunnen beperken. Alleen vergt het zoals je ziet een correcte inplementatie van alle partijen.

--
edit: Typo weggehaald

[niqck]

@feuniks

En wat als je ISP nu enkel maar SMTP-verkeer (poort 25) toelaat naar zijn eigen mail-server? Mijn ISP doet dat.
GMail gebruikt dacht ik gelukkig wel SSMTP (poort 465) en die wordt niet vaak geblokkeerd door een ISP. Maar hoeveel mailservers zijn geconfigurreerd voor SSMTP?

[DSmarty]

En waarom zou dit niet werken ?

Ik heb een eigen mailserver draaien voor een aantal domeinen, deze zijn allemaal voorzien van SPF/DomainKeys. (bijv. dsmarty.com)
Als ik mail stuur vanaf willekeurig welke lokatie dan mail ik via mail.dsmarty.com (Je authenticeert je op de SMTP server)
Bij de SPF check is alles dus gewoon keurig in orde.

Dat is dus ISP onafhankelijk, zoiets kan GMail ook simpel implementeren als men wil.

[Roland684]

En nu kom je op een lokatie waar smtp (poort 25) alleen is toegestaan naar de lokale mailserver. Dat is een heel gebruikelijke situatie, veel ISP's werken zelfs zo. Jouw oplossing werkt daar niet.
Zowiezo is een eigen mailserver draaien geen oplossing voor de gewone man.

[cybero]

Je zult de public key van het mailtje moeten ophalen bij een keyserver. Outlook e.a. doen dit automatisch. Zie bijvoorbeeld Wikipedia en bijvoorbeeld Thawte voor een gratis certificaat.

De keys die daarop staan zijn gevalideerd met op zijn minst een e-mail check. Dit komt er op neer dat het e-mail adres en de e-mail niet geforged kunnen worden. Je moet dus wel voorkomen dat spammers keys gaan posten op deze servers.

Ik geef toe het is moeilijk om iedereen aan zoiets te krijgen, maar dat geld ook voor sender-id. Terwijl dit eigenlijk beter is. Het zegt namelijk ook of de e-mail body is veranderd.

edit:
* cybero zeker op verkeerde post gereageerd..

[nxt]

En nu kom je op een lokatie waar smtp (poort 25) alleen is toegestaan naar de lokale mailserver....

Dat kan zeker wel werken. Het enige wat je dan hoeft te doen is de SMTP server van je provider the authorizeren bij je domeinnamen waarmee je wilt mailen.
Wel zul je dan een eigen domeinnaam voor moeten hebben.

[Aetje]

SPF is heerlijk. Een simpel DNS recordje en mits de ontvanger het gebruikt, kan jan en alleman nagaan of de mail ook daadwerkelijk van onze mailservers komt. Voor domeinen die het niet gebruiken (mailadmin te lui om een text record in DNS te gooien?) wil dat natuurlijk niet...

[BasieP]

het probleem is dat elk bedrijf zijn eigen standaard gaat zitten bedenken, en dat is juist niet het idee van een 'standaard'

Verder zullen ISP's weinig behoefte hebben aan dit soort standaarden, aangezien het er te veel zijn en ze wel eens willen wijzigen (denk bijv. aan updates en bugfixes)

Het zal eens tijd worden dat al deze bedrijven samen rond de tafel gaan zitten, en samen met bijv. internet beheerinstanties tot 1 standaard komen

[Roland684]

Als het nou spam tegenging, al la, maar het voegt allen identificatieplicht toe aan e-mail.

Alsof je bankroven tegenhoudt door iedereen te verplichten een paspoort bij zich te hebben.... NOT

[Verwijderd]

Als je de bank niet binnenkomt zonder je paspoort te laten zien, valt er weinig te roven.

Aannemende dat het de enige ingang is en men zich niet als een ander kan voordoen. Dat laatste is uiteraard mogelijk door een relaypc te hacken/misbruiken.

Ach, het is een stapje in de goede richting. Op deze manier weet je iig wie je spamt Of het echt werkt, betwijfel ik ook, maar hoe meer identificatie, hoe lastiger 't wordt voor een spammer (hoop ik).

[Dark Angel 58]

Als je de bank niet binnenkomt zonder je paspoort te laten zien, valt er weinig te roven.

Een paspoort is niet genoeg... dat kan juist gevaarlijk zijn, want.... een bankrover vermomt als meneer Jansen, met gekopieerde vingertoppen (of zoiets ) en na de identificatie... en hij berooft een bank en vlucht weg....
Volgende dag wordt een ECHTE meneer Jansen gearresteerd....

tja.... Volgens mij is een irisscan wel genoeg, want als ik goed heb, is iris makkelijk na te maken met een ooglens, maar oogbloedbanen kun je nooit namaken...

[Roland684]

Jij gaat er weer even heel gemakkelijk van uit dat een bankovervaller zich netjes aan de regels houdt en de toegangscontrolesystemen gebruikt. Denk je echt dat hij netjes in de rij op zijn beurt gaat staan wachten? Nee hoor, die rijdt met een gestolen Hummer gewoon het hele irisscan, vingerafdruk, DNA, anal probe en metaaldetector-poortje omver.

Metaaldetectorpoortjes gaan ook alleenmaar af als een kassiere per ongeluk een tag vergeten is te demagnetiseren, gevolg: boven de betalende klant gaat een bordje "dief dief dief!" knipperen. Een beetje winkeldief stopt de spullen in een geprepareerde tas en loop zo door de poortjes heen. (nee, dit is geen handleiding shopliften, het stond vorige week nog in de krant.)

Leuk bedacht al die beveiliging, maar het werkt alleen voor degene die er zich aan wil houden. De kwaadwillenden trekken er zich niets van aan, alleen de good guys zijn de dupe.

[Roland684]

Probleem is dat het de vrijheid (vrijheid is vooral een gevoel) flink belemmert, terwijl het spammers nauwelijks zal tegenhouden. Je kunt nu ook al achterhalen wie je spamt, dat staat gewoon in de mailheaders.

Zoals de naam van het beestje al aangeeft is het vooral een identificatieplicht die aan e-mail toegevoegd wordt en is het nog volkomen onduidelijk hoe dat spam zou moeten gaan stoppen.

Er wordt nu geschoten met een kanon op een mug, in een poging een vlieg op de andere muur te doden.

SenderID is destructief voor vrijheid en mist zijn doel compleet.

[Chatslet]

Mailheaders kunnen vervalst of zelfs geheel verborgen worden. Knutsel maar eens een mail progje in elkaar waarmee je valse envelop headers kunt maken, klopt er al geen zak meer van want dan denkt men dat jij tussen station bent ipv sender. Een ander leuk truukje is de header helemaal vol met spaties gooien zodat de ip[ informatie wordt weggedrukt, bij veel mailservers werkt dit nog. Zie het sender id verhaal als iedere brief aangetekend versturen en dit heeft helemaal niets met beperken van vrijheid te maken er is gewoon duidelijkheid wie de mail verzonden heeft en voorkomt fraude. Stel je eens voor dat iemand in de door jouw zo begeerde vrijheid met jouw email adres als afzender allemaal nazi propaganda gaat zitten mailen. Ben jij dan blij?

[Frank-L]

Probleem is dat het de vrijheid (vrijheid is vooral een gevoel) flink belemmert

In principe heb je gelijk, maar zeg nou zelf: hoe vaak heb jij het afgelopen jaar een mail verstuurd waarbij je anoniem wilde blijven? Even aangenomen dat je zelf geen spammer bent natuurlijk.

[Verwijderd]

Dit is nou een perfect idee van MS om dit te doen


door dit zal het zeker hoperlijk tot 1 van de standaard woorden om nog beter spam tegen te gaan !

[Roland684]

En hoe doet het dat dan?
Want het grootste probleem van deze technologie is dat het flinke beperkingen oplegt aan het verzenden van mail (en dat is al niet makkelijk met lokatiegebonden smtp-servers) het een flinke belemmering voor privacy is (natuurlijk hebben jij en ik niets te verbergen, maar om nu op elke straathoek een agent neer te zetten die je paspoort wil zien, is gewoon niet prettig. Zo ook verplichte identificatiebij e-mail niet) en geen spam tegenhoudt. Een simpele gebruiker kan alleen niet meer annoniem mailen, maar spammers vinden daar wel een oplossing voor (virussen, trojans, malware, etc.)

Je kunt met microsoft technologie alleen maar mailen vanaf een computer binnen het eigen domein. Dus je chello adres kun je alleen maar gebruiken vanaf het chello netwerk, niet meer op je werk/opleiding. Voor hotmail is dat geen probleem, dat is alleen maar een webmail, maar voor mailprogramma's is het een ramp, die worden ineens lokatiegebonden.

Het geeft een iets betere mogelijheid om de domste spammers (die toch wel door hun provider worden afgesloten) achteraf aan te pakken, maar legt tegelijkertijd enorme beperkingen op aan e-mail.

[Olaf van der Spek]

Dus je chello adres kun je alleen maar gebruiken vanaf het chello netwerk, niet meer op je werk/opleiding.

Ondersteunt Chello's SMTP server geen authenticatie dan?
Een fatsoenlijke ISP heeft wel een SMTP server met authenticatie waardoor je ook buiten het domein er gebruik van kunt maken.

[Verwijderd]

Juist niet. Dit zou de server alleen maar gevoelig maken voor aanvallen. Doorgaans maak je gebruik van de SMTP server van de betreffende ISP. In hotels is vaak een SMTP catch waardoor alle SMTP verzoeken aan een werkende SMTP server worden aangeboden.

[siepeltjuh]

Leg mij dan maar eens uit waarom een server met authenticatie opeens een groter risicio loopt dan zonder?!

Met authenticatie is de misbruiker toch veel makkelijker op te sporen / verwijderen.

[Verwijderd]

Ik weet niet of de reden die NL0RAF opgeeft klopt, maar wat hij zegt wel iig. Demon bijvoorbeeld, toch niet te lulligste ISP, laat abbonnees alleen gebruik maken van SMTP vanaf een Demon domein.

[darkfader]

@siepeltjuh: Ze hoeven niets op te sporen, een automatische blokkade houdt spammers al flink tegen.
'k Vraag me af of dit ook in een standaard/aanbeveling is beschreven.

[_Thanatos_]

Ach, wat is erop tegen om alle drie de standaarden te implementeren... alleen de truuk is denk ik niet zozeer de technologie, maar de ISP zover krijgen dat ie ze implementeert.

[djack]

Het sluiten van allerhanden open relays zou al een oplossing zijn.

ISP's zouden hier een rol kunnen innemen.
Al wat op hun netwerk is aangesloten checken indien open relay effe de volledige internet toegang afsluiten.

Voor de rest het hard aanpakken van personen/bedrijven die zich hier mee inlaten.

Maar boven al is dit een probleem dat internationaal opgelost moet worden. Op VN niveau.

[Roland684]

Welk land gaat zijn internationale handelsbetrekkingen op het spel zetten in de strijd tegen spam?
Wil je heel rusland en china maar gewoon afsluiten van het westerse internet? En wat denk je van vrijstaatjes als Monaco?

Zowiezo zijn Botnets erg interessant om spam te versturen. 100.000 computers die elk 10 mailtjes per dag versturen. Knappe ISP die dat weet te detecteren. En dan nog ben je te laat.

[cybero]

Waarom niet signen/encrypten van e-mail?
Sig fout dan in spam box of in lage prioriteit box.
Outlook het zelfs al, eigenlijk bestaat het al heel lang.
Key staan ook nu al op keyservers, dus daar kunnen dan ook spam keys worden geblocked.

Zelf heb ik veel verschillende e-mail adressen en locaties. Ik stuur eigenlijk alles (verschillende adressen) via xs4all smtps. (Dit is handig, want dan maakt het niet uit waar ik zit.) en dat is precies mijn bezwaar tegen dit sender-id gebeuren dat ik niet meer vanaf overal mijn mailtjes kan sturen?!

[Roland684]

Spam kun je toch ook signen/encrypten?
Dat zou alleen maar werken als je dit ook koppelt aan een whitelist. Maar dat betekent dat iedereen die je (nog) niet kent, als spam aangemerkt wordt. Je moet dan alsnog je map met spammailtjes doorzoeken op onterecht als spam aangemerkte mails.

[cybero]

Hmm op een of andere manier staat mijn post ergens anders. Maar komt er op neer dat het niet zo makkelijk is om je public key ergens geregistreerd te krijgen zonder toegang te hebben tot het e-mail account. Wat dus betekent dat spammers vanaf 'eigen' accounts moeten gaan spammen. Dat zal beheersbaar zijn door keys te revoken op de server.

[RutgerDB]

SPF is zeker een interessante technologie. Al is het allemaal maar om phishing te voorkomen. Als alle banken SPF records opnemen in hun DNS is het phishing principe al een stuk lastiger voor kwaadwillenden.

Als iedereen standaard alles 'afzeikt' dan wordt het nooit wat. In de omgeving waar ik werk zijn ruim 250.000 mailtransacties (valide). Het totale mailvolume is ruim 1.5 miljoen berichten per dag.

SPAM is een levensgroot probleem en kost bedrijven klauwen met geld.

Een ander voordeel van Sender ID is dat als jij dit netjes doet en stuurt naar een bedrijf dat dit ook gebruikt, het SPAM filter jouw mail een veel lagere rating geeft. Je hebt dus ook geen gezeur dat je mailtje niet doorkomt omdat je maar één regel tekst hebt getypt als toelichting bij je Word documentje.

Kortom, alle kleine beetjes helpen.

Persoonlijk zie ik de meest toegevoegde waarde in hash-cash. Een payload die een SMTP client moet doorrekenen voordat hij een mailtje mag afleveren. Dit kan ook DDOS attacks op mailservers voorkomen of in ieder geval drastisch doen verminderen.

Hier wat info over Hash-Cash.
http://www.hashcash.org/faq/