The Inquirer meldt dat de Apache Software Foundation en het Debian GNU/Linux Project gisteren de tweede versie van Microsofts Sender ID hebben afgekeurd. Microsoft heeft vorige week een vernieuwde versie ingediend bij de Internet Engineering Taskforce (IETF), die volgens het bedrijf minder zwaar leunt op gepatenteerde technieken. Desondanks zijn Apache en Debian van mening dat de wijzigingen niet structureel zijn. Het gaat de twee Open Source-ontwikkelaars voornamelijk om de voorwaarden van de licentie waaraan de gebruikers van de Sender ID moeten voldoen. Apache stelt voor dat Microsoft de gewraakte patenten doneert aan de IETF, de organisatie die de Sender ID standaard moet gaan goedkeuren. Microsoft heeft voor zover bekend nog niet gereageerd op dit voorstel.
Apache en Debian keuren tweede versie Sender ID af
Lees meer
Microsoft maakt SenderID openbaar
Nieuws van 24 oktober 2006
Debian Common Core Alliance wordt binnenkort onthuld
Nieuws van 6 augustus 2005
Microsoft drukt Sender ID door met behulp van Hotmail
Nieuws van 24 juni 2005
Debian-ontwikkelaars: vaker nieuwe versies uitbrengen
Nieuws van 19 maart 2005
IETF wil International Domain Names-standaard verbeteren
Nieuws van 9 maart 2005
Steve Ballmer: 'Linux gebruiken riskant vanwege patenten'
Nieuws van 19 november 2004
Microsoft legt claim op internetprotocollen - Update
Nieuws van 8 november 2004
Microsoft past Sender ID aan na afwijzing door IETF
Nieuws van 27 oktober 2004
AOL accepteert Sender ID na aanpassing Microsoft
Nieuws van 26 oktober 2004
AOL gaat Microsoft Sender ID toch niet gebruiken
Nieuws van 17 september 2004
IETF wijst Sender ID af wegens patenten Microsoft
Nieuws van 14 september 2004
E-mail ID wordt misbruikt door spammers
Nieuws van 9 september 2004
Apache Software Foundation wijst Sender ID af
Nieuws van 3 september 2004
Open-sourcegemeenschap sceptisch over Sender ID
Nieuws van 28 augustus 2004
Microsoft blijft achter Sender ID staan, zoekt meer steun
Nieuws van 14 augustus 2004
AOL en Yahoo gaan afzenderauthenticatie gebruiken
Nieuws van 12 augustus 2004
Microsoft gaat Sender ID-plannen uitvoeren
Nieuws van 23 juli 2004
Reacties (22)
Het is een illusie dat senderID ook maar iets gaat veranderen aan spam. 99% van de spam probeert je iets te laten kopen bij een specifiek bedrijf, dus de opdrachtgever is zowiezo wel te achterhalen. En al maak je het strafbaar etc. dat zal ze worst wezen. Wat is een boete van €10.000 nou als je er €15.000 aan overhoudt?
Ook het onmogelijk maken gaat niet werken, elke beveiliging zal omzeild kunnen worden. Heeft er iemand tegenwoordig nog last van de beveiliging die op CD's en DVD's zit? De mensen met kennis (en zonder geweten) weten hun boodschap toch wel bij de gebruikers te brengen, desnoods via gehackte computers, virussen of ze verleggen hun werkterrein naar instant messengers, p2p-netwerken of sociale netwerken.
Maar wat het wel tot gevolg heeft is dat de kleine man gepakt wordt. Want die kan straks alleen nog maar zijn chello-adres (of welke provider je ook hebt) gebruiken. Persoonlijk zit ik daar niet op te wachten, ik heb andere adressen die ik wil gebruiken van thuis uit. Ik bestrijd spam door telkens een ander adres te gebruiken en als er op één van die adressen spam binnen gaat komen dan hef ik dat adres op en krijgen de afzenders een mailtje terug contact met mij op te nemen voor een nieuw adres. Daarmee heb ik de 20+ spamberichten die ik dagelijks ontving toen ik nog 1 adres had, teruggedrongen tot hooguit 1 per week. (en die spammer maak ik dan het leven zuur door te vragen om meer en meer informatie, "zijn uw viagra-pillen hypoallergeen?", "zijn ze geschikt voor mensen met glutenalergie?" en dan doe ik me voor als grote afnemer en vraag ze om wat proefexemplaren en reclamematerialen (liefst zo groot en zwaar mogelijk) op te sturen en/of een vertegenwoordiger langs te sturen en dan ben ik er de eerst 3 afspraken niet zodat de vertegenwoordiger voor niets aan de deur stond, etc. etc. bloeden zullen ze!). En ik kan ook nog zien wie/wat mijn adres heeft gelekt. (ik heb nog 1 oud adres in gebruik voor een mailinglist die ik beheer, daarop komen dagelijks 200+ spamberichten binnen, die gelukkig allemaal worden gestopt omdat het een members-only lijst is geworden)
Maar als wij straks met het hele gezin gedwongen worden jarenlang dat ene Chello adres overal voor te gaan gebruiken dan voorzie ik het ergste. Er hoeft maar één persoon te zijn die mijn adres bekend maakt en voor je het weet sta je op een internationale spamlijst die elke spammer kan aanschaffen. (Een bedrijf dat per ongeluk een mailtje stuurt met alle adressen in het to:-veld, of iemand die mijn adres in een "notify a fiend"-formuliertje op een site invullt is vaak al genoeg).
Bovendien heb ik een eigen domein dat ik wil gebruiken en zit ik niet te wachten op een e-mailadres van mijn provider, want als ik dan van provider wissel moet ik overal mijn adres gaan laten aanpassen.
Het is net zo onzinnig als proberen de ongewenste reclamedrukwerk tegen te houden door iedereen te verplichten post te versturen via het dichtsbijzijnde postkantoor.
Het helpt nauwelijks tot niets maar legt de flexibilitiet van het systeem enorm aan banden.
Ook het onmogelijk maken gaat niet werken, elke beveiliging zal omzeild kunnen worden. Heeft er iemand tegenwoordig nog last van de beveiliging die op CD's en DVD's zit? De mensen met kennis (en zonder geweten) weten hun boodschap toch wel bij de gebruikers te brengen, desnoods via gehackte computers, virussen of ze verleggen hun werkterrein naar instant messengers, p2p-netwerken of sociale netwerken.
Maar wat het wel tot gevolg heeft is dat de kleine man gepakt wordt. Want die kan straks alleen nog maar zijn chello-adres (of welke provider je ook hebt) gebruiken. Persoonlijk zit ik daar niet op te wachten, ik heb andere adressen die ik wil gebruiken van thuis uit. Ik bestrijd spam door telkens een ander adres te gebruiken en als er op één van die adressen spam binnen gaat komen dan hef ik dat adres op en krijgen de afzenders een mailtje terug contact met mij op te nemen voor een nieuw adres. Daarmee heb ik de 20+ spamberichten die ik dagelijks ontving toen ik nog 1 adres had, teruggedrongen tot hooguit 1 per week. (en die spammer maak ik dan het leven zuur door te vragen om meer en meer informatie, "zijn uw viagra-pillen hypoallergeen?", "zijn ze geschikt voor mensen met glutenalergie?" en dan doe ik me voor als grote afnemer en vraag ze om wat proefexemplaren en reclamematerialen (liefst zo groot en zwaar mogelijk) op te sturen en/of een vertegenwoordiger langs te sturen en dan ben ik er de eerst 3 afspraken niet zodat de vertegenwoordiger voor niets aan de deur stond, etc. etc. bloeden zullen ze!). En ik kan ook nog zien wie/wat mijn adres heeft gelekt. (ik heb nog 1 oud adres in gebruik voor een mailinglist die ik beheer, daarop komen dagelijks 200+ spamberichten binnen, die gelukkig allemaal worden gestopt omdat het een members-only lijst is geworden)
Maar als wij straks met het hele gezin gedwongen worden jarenlang dat ene Chello adres overal voor te gaan gebruiken dan voorzie ik het ergste. Er hoeft maar één persoon te zijn die mijn adres bekend maakt en voor je het weet sta je op een internationale spamlijst die elke spammer kan aanschaffen. (Een bedrijf dat per ongeluk een mailtje stuurt met alle adressen in het to:-veld, of iemand die mijn adres in een "notify a fiend"-formuliertje op een site invullt is vaak al genoeg).
Bovendien heb ik een eigen domein dat ik wil gebruiken en zit ik niet te wachten op een e-mailadres van mijn provider, want als ik dan van provider wissel moet ik overal mijn adres gaan laten aanpassen.
Het is net zo onzinnig als proberen de ongewenste reclamedrukwerk tegen te houden door iedereen te verplichten post te versturen via het dichtsbijzijnde postkantoor.
Het helpt nauwelijks tot niets maar legt de flexibilitiet van het systeem enorm aan banden.
Je maakt je een beetje druk om niets. Als je de standaard had gelezen is SPF/Sender Id helemaal niet om SPAM te stoppen; het is om joe-jobbing te stoppen (dat is dat jouw e-mail adres gebruikt wordt als afzender in een SPAM e-mail) Tevens kan je met een eigen domein prima gebruik maken van SPF/Sender Id, en dan kan je binnen je domein nog je eigen e-mail adres prefix (<roland>@...) kiezen.
Als je het helemaal goed begrijpt beschermt SPF jouw eigen domein dus.
Als je het helemaal goed begrijpt beschermt SPF jouw eigen domein dus.
Ik denk dat Roland Witvoet zich terecht druk maakt. Verbeter me als ik ernaast zit, maar in mijn ogen controleert het voorstel van Sender ID of een email die claimt van een bepaald domein afkomstig te zijn of de mailserver waar het vandaan komt wel van dat domein is. In andere woorden, als ik een mailje stuur met als afzender Pietje@bigfoot.com (een forward provider), terwijl ik die stuur via de SMTP server van Wanadoo wordt die mail dus gekilled. Je komt dus vast te zitten aan de email adressen van je provider of eventueel van je eigen betaalde domein en daar zitten zowel Roland als ik niet op te wachten.
Als een bepaald domein ervoor kiest SPF te gebruiken, dan zul je waarschijnlijk de mail van dat domein via de mailserver van dat domein moeten versturen ja.
Maar wat is daar mis mee? In elke moderne mailclient kun je per identity instellen welke mailserver gebruikt moet worden, en elk domain dat SPF zal aanzetten zal ook wel een mailserver hebben die gebruikt kan worden van buitenaf.
Het is een grote misvatting om te denken dat je per definitie geen mails van domein A meer zou kunnen versturen als je op een verbinding met domein B zit. Daar moet A eerst specifiek voor kiezen.
Maar wat is daar mis mee? In elke moderne mailclient kun je per identity instellen welke mailserver gebruikt moet worden, en elk domain dat SPF zal aanzetten zal ook wel een mailserver hebben die gebruikt kan worden van buitenaf.
Het is een grote misvatting om te denken dat je per definitie geen mails van domein A meer zou kunnen versturen als je op een verbinding met domein B zit. Daar moet A eerst specifiek voor kiezen.
Roland >
Je hoeft helemaal niet te "bewijzen" dat je bent wie je bent. Als je een e-mail adres gebruikt, kunnen ze alleen zien welke machine die e-mail _moet_ versturen. Je kan nu ook opzoeken naar welke machine e-mail met dat adres gaat. Waarom is het ene wel erg en het andere niet?
Vergelijk het als volgt:
Je stuurt een e-mail van je Tornadoo account via een gratis inbel dingetje van Maan.net. Het antwoord op dat mailtje gaat naar mail.tornadoo.net. De ontvanger weet nu twee dingen:
1) Je mail is verstuurd via Maan.net
2) Je hebt een mail adres bij Tornadoo.net
Nu stelt Tornadoo een SPF record in. Hierin staat dat mail verstuurd met een @tornado adres, van mail.tornadoo.net gestuurd zou moeten zijn. Jij stopt dus met e-mailen via Maan.net, en stuurt het gewoon naar mail.tornadoo.net. Je hebt al een account daar, dus je kan SMTP met auth doen, of iets anders om daar e-mail te mogen droppen. (Ik zie hier wel een zwak punt.) Een reply gaat natuurlijk gewoon naar mail.tornadoo.net. De ontvanger kent nu alleen maar mail.tornadoo.net, en ziet dus helemaal je (werkelijke) provider niet meer. Da's toch beter?
En om even terug te komen op het zwakke punt: Je moet direct je mail aanbieden aan de juiste SMTP server. Die accepteerd natuurlijk geen relaying, dus moet je je aanmelden, of SMTP after pop ofzo doen om toegang te krijgen. Ik kan me voorstellen dat veel providers (en werk-adressen) dat niet hebben. En dat lijkt me lastig.
Verder moet je een e-mail niet blocken als je geen SPF hebt (en natuurlijk als je SPF klopt). Als je SPF hebt _en_ je SPF klopt niet, dan is waarschijnlijk SPAM. Dit systeem voorkomt dat jouw e-mail adres gebruikt wordt in een e-mail van een spammer. Als (zeer) veel mensen SPF gebruiken, dan moeten spammers echte domeinen kopen. Ze kunnen per slot van rekening geen domein "stelen" en de echte eigenaar veel "fuck-off" replies laten ontvangen.
Dit geeft een makkelijk traceerbaar spoor naar de spammer. Twee voordelen dus:
1) Jij wordt niet genaait.
2) Je komt te weten wie de spammer is.
Je hoeft helemaal niet te "bewijzen" dat je bent wie je bent. Als je een e-mail adres gebruikt, kunnen ze alleen zien welke machine die e-mail _moet_ versturen. Je kan nu ook opzoeken naar welke machine e-mail met dat adres gaat. Waarom is het ene wel erg en het andere niet?
Vergelijk het als volgt:
Je stuurt een e-mail van je Tornadoo account via een gratis inbel dingetje van Maan.net. Het antwoord op dat mailtje gaat naar mail.tornadoo.net. De ontvanger weet nu twee dingen:
1) Je mail is verstuurd via Maan.net
2) Je hebt een mail adres bij Tornadoo.net
Nu stelt Tornadoo een SPF record in. Hierin staat dat mail verstuurd met een @tornado adres, van mail.tornadoo.net gestuurd zou moeten zijn. Jij stopt dus met e-mailen via Maan.net, en stuurt het gewoon naar mail.tornadoo.net. Je hebt al een account daar, dus je kan SMTP met auth doen, of iets anders om daar e-mail te mogen droppen. (Ik zie hier wel een zwak punt.) Een reply gaat natuurlijk gewoon naar mail.tornadoo.net. De ontvanger kent nu alleen maar mail.tornadoo.net, en ziet dus helemaal je (werkelijke) provider niet meer. Da's toch beter?
En om even terug te komen op het zwakke punt: Je moet direct je mail aanbieden aan de juiste SMTP server. Die accepteerd natuurlijk geen relaying, dus moet je je aanmelden, of SMTP after pop ofzo doen om toegang te krijgen. Ik kan me voorstellen dat veel providers (en werk-adressen) dat niet hebben. En dat lijkt me lastig.
Verder moet je een e-mail niet blocken als je geen SPF hebt (en natuurlijk als je SPF klopt). Als je SPF hebt _en_ je SPF klopt niet, dan is waarschijnlijk SPAM. Dit systeem voorkomt dat jouw e-mail adres gebruikt wordt in een e-mail van een spammer. Als (zeer) veel mensen SPF gebruiken, dan moeten spammers echte domeinen kopen. Ze kunnen per slot van rekening geen domein "stelen" en de echte eigenaar veel "fuck-off" replies laten ontvangen.
Dit geeft een makkelijk traceerbaar spoor naar de spammer. Twee voordelen dus:
1) Jij wordt niet genaait.
2) Je komt te weten wie de spammer is.
Het werkt natuurlijk alleen als iedereen het gaat gebruiken en als het eenmaal zo ver dat 90% het gebruikt zullen providers gaan besluiten dat mail van domeinen die niet mee doen per definitie verdacht is.
Post bestaat al honderden jaren en daar is het toch ook geen probleem dat aangepakt moet worden? Heb jij ooit je paspoort moeten laten zien als je een postpakketje verstuurde? En toch komt het daar op neer met dit systeem.
De eigenaar van het adres waar de e-mail vandaan komt zegt bijzonder weinig over de gebruikte mailserver. maar die koppeling wil men wel gaan forceren.
Er wordt een vreselijk agressief wapen (beperking van je mogelijkheden en je privacy) ingezet om een bijzonder klein probleem aan te pakken. (zoals al gezegd, spammers zullen hun identiteit niet verborgen kunnen houden als ze iets willen verkopen.)
Als je wilt aangeven dat jij daadwerkelijk bent wie je zegt te zijn, zijn daar al lang andere, betere methoden voor. (denk pgp/gpg-signatures, Alle populaire mailprogramma's ondersteunen dat allang)
Post bestaat al honderden jaren en daar is het toch ook geen probleem dat aangepakt moet worden? Heb jij ooit je paspoort moeten laten zien als je een postpakketje verstuurde? En toch komt het daar op neer met dit systeem.
De eigenaar van het adres waar de e-mail vandaan komt zegt bijzonder weinig over de gebruikte mailserver. maar die koppeling wil men wel gaan forceren.
Er wordt een vreselijk agressief wapen (beperking van je mogelijkheden en je privacy) ingezet om een bijzonder klein probleem aan te pakken. (zoals al gezegd, spammers zullen hun identiteit niet verborgen kunnen houden als ze iets willen verkopen.)
Als je wilt aangeven dat jij daadwerkelijk bent wie je zegt te zijn, zijn daar al lang andere, betere methoden voor. (denk pgp/gpg-signatures, Alle populaire mailprogramma's ondersteunen dat allang)
In de SPF record van _jouw_ domein kun je gewoon aangeven dat de smtp server van wanadoo gerechtigd is om voor jouw te relayen. niks aan het handje dus.als ik een mailje stuur met als afzender Pietje@bigfoot.com (een forward provider), terwijl ik die stuur via de SMTP server van Wanadoo wordt die mail dus gekilled.
het enigste (kleine) probleem is als je mail wilt forwarden: je bent dan wel de ontvanger, maar niet de originele afzender.
echter, je kunt de server waarnaar je forward dan gewoon vertellen dat jouw mailserver dat mag, en SPF werkt nog steeds, immers, de mailserver die oorspronkelijk het mailtje ontving kan de SPF informatie checken.
lees het protocol en het zal je duidelijk worden. SPF is ontzettend flexibel.
Zijn er geen OSS instanties met een eigen voorstel gekomen? Ik snap dat ze het niet helemaal eens zijn met Microsoft maar wat belet hun om een eigen voorstel te doen? In dit voorstel zouden ze dan uiteraard alleen gebruik maken van open source protocollen etcetera.
Dat is er al, en heet 'SPF'. Alleen microsoft heeft geen zin spf te gebruiken want ze vinden het te beperkt ofzo, dus willen ze het naar hun eigen hand zetten, door het in een xml-jasje te gieten en nog wat fratsen.
op zich niet onaardig, omdat het flexibeler wordt (denk aan compatibaliteit met domainkeys).
maar een standaard is pas een open standaard als je niet eerst een ondertekende licentie terug aan microsoft moet faxen, en dat moet nu wel, hoewel de licentie gratis is. en omdat de licentie gratis is begrijpt micorosoft het probleem zogenaamd niet.
op zich niet onaardig, omdat het flexibeler wordt (denk aan compatibaliteit met domainkeys).
maar een standaard is pas een open standaard als je niet eerst een ondertekende licentie terug aan microsoft moet faxen, en dat moet nu wel, hoewel de licentie gratis is. en omdat de licentie gratis is begrijpt micorosoft het probleem zogenaamd niet.
De licentie is wel "gratis" maar niet "vrij". Stel jij bent het niet eens met de richting die een open source mailer op gaat, en je wil op basis van die code een andere richting op gaan (een fork dus), dan kan dat dus niet als er een licentie voor nodig is.hoewel de licentie gratis is. en omdat de licentie gratis is begrijpt micorosoft het probleem zogenaamd niet.
maar stel dat de implementatie van sender-id buggy is, dan mag je dus niet eens forken om een betere implementatie te maken. En dat recht is toch zeker weten een goed idee.
De M$-versie van "vrij" heet dus "afhankelijk"..
Omdat het gratis is, doe je mee. Als het verandert, moet je mee..
Horror:
"Natuurlijk waren er alternatieven, zoals SPF, alleen zijn die de markt uitgedrukt ten tijde van de gratis verspreiding van het Sender ID. Nu zult u het moeten stellen met een betaalde licentie op Sender ID, want geen enkele provider ondersteunt nog enkel SPF.."
Vervolgens een tirade over de goedheid van Sender ID:
"Mede door de Sender ID hebben we alle spamservers kunnen platgooien. Goed voor die B52's. En hebben we ook de DNS servers van de staat China 'aangepast' aan onze standaarden. Kunnen ze tenminste surfen waar ze willen, die Chinezen. (gevolg: nu wordt er regelmatig een Chinees gefussilleerd, wegens verboden intellectueel bezit).
En hebben we ook nog die Franse terroristenvriend Chirac een kopje kleiner kunnen maken in zijn virtuele wereld. Maar allah, dat was niet persé nodig geweest.."
>>bibber<<
Omdat het gratis is, doe je mee. Als het verandert, moet je mee..
Horror:
"Natuurlijk waren er alternatieven, zoals SPF, alleen zijn die de markt uitgedrukt ten tijde van de gratis verspreiding van het Sender ID. Nu zult u het moeten stellen met een betaalde licentie op Sender ID, want geen enkele provider ondersteunt nog enkel SPF.."
Vervolgens een tirade over de goedheid van Sender ID:
"Mede door de Sender ID hebben we alle spamservers kunnen platgooien. Goed voor die B52's. En hebben we ook de DNS servers van de staat China 'aangepast' aan onze standaarden. Kunnen ze tenminste surfen waar ze willen, die Chinezen. (gevolg: nu wordt er regelmatig een Chinees gefussilleerd, wegens verboden intellectueel bezit).
En hebben we ook nog die Franse terroristenvriend Chirac een kopje kleiner kunnen maken in zijn virtuele wereld. Maar allah, dat was niet persé nodig geweest.."
>>bibber<<
ik denk niet dat forken in dit soort situaties een goed plan is 
Men moet juist tot een compromis komen dat door iedereen aanvaard wordt als dé standaard voor het internet...
Men moet juist tot een compromis komen dat door iedereen aanvaard wordt als dé standaard voor het internet...
Een ander systeem wat voor zover ik weet, wel voldoet aan de Apache eisen is Yahoo-Domainkeys, wat meer weg heeft van de manier waarop SSL werkt, privé encryptie sleutel wordt automatisch met email meegestuurt en openbare encryptie sleutel is verkrijgbaar via de DNS van het domein.
Wat betreft het uitbrengen van een soortgelijk Sender-ID systeem, dan krijg je dus het probleem waar Apache/etc bang voor is, dat Microsoft zijn patent kracht bij gaat zetten. Doordat Microsoft dit patent bezit, kunnen ze dus hun mening later veranderen en opeens zeggen dat de licentiekosten niet meer 'gratis' zijn. Als dat gebeurt nadat de hele wereld afhankelijk van het systeem is, dan is het lastiger om nee te zeggen.
Prior-art is in dit geval niet van toepassing, omdat Microsoft Sender-ID een ander systeem is, het werkt dan wel samen en gedeeltelijk gebaseerd op SPF, maar daar heeft Microsoft een overeenkomst voor met de maker van SPF. Het Microsoft patent is ook vooral op het XML gedeelte van hun systeem.
Wat betreft het uitbrengen van een soortgelijk Sender-ID systeem, dan krijg je dus het probleem waar Apache/etc bang voor is, dat Microsoft zijn patent kracht bij gaat zetten. Doordat Microsoft dit patent bezit, kunnen ze dus hun mening later veranderen en opeens zeggen dat de licentiekosten niet meer 'gratis' zijn. Als dat gebeurt nadat de hele wereld afhankelijk van het systeem is, dan is het lastiger om nee te zeggen.
Prior-art is in dit geval niet van toepassing, omdat Microsoft Sender-ID een ander systeem is, het werkt dan wel samen en gedeeltelijk gebaseerd op SPF, maar daar heeft Microsoft een overeenkomst voor met de maker van SPF. Het Microsoft patent is ook vooral op het XML gedeelte van hun systeem.
Dit hele debat wordt nogal vertroebeld doordat beide zijden zich verbergen achter allerlei principiele standpunten, maar de situatie is vrij concreet: ISPŽs willen zo snel mogelijk een bruikbaar identificatie/authorisatie protocol om hun enorme spam/virus verkeer te beperken en adres spoofing tegen te gaan, en het zal ze daarbij worst zijn of die oplossing nou Open Source is of niet, als het maar werkt.
Er is nu SPF, een veel minder krachtig OSS protocol dat vanwege die beperkingen in de huidige vorm niet acceptabel voor de gebruikers (lees: ISPŽs) is. De strategie van de OSS community is nu om zo lang mogelijk de meer geavanceerde Microsoft oplossing SenderID (dat wel de extra functionaliteit heeft die de gebruikers willen en ook backwards compatible is met SPF) tegen te houden, totdat er een gelijkwaardige 'kloon' van SenderID ontwikkeld is, die dan net als de SenderID gratis zou worden. De ISPŽs willen daar niet op wachten en hebben op het moment meer vertrouwen in Microsoft.
(edit: lekker is dat. ik geef als enige in deze thread aan WAAROM de ISPŽs ondanks de door OSS community beweerde 'superioriteit' toch niet met SPF willen werken en dat is overbodig? Tweakers wordt wel heel kritiekloos...)
Er is nu SPF, een veel minder krachtig OSS protocol dat vanwege die beperkingen in de huidige vorm niet acceptabel voor de gebruikers (lees: ISPŽs) is. De strategie van de OSS community is nu om zo lang mogelijk de meer geavanceerde Microsoft oplossing SenderID (dat wel de extra functionaliteit heeft die de gebruikers willen en ook backwards compatible is met SPF) tegen te houden, totdat er een gelijkwaardige 'kloon' van SenderID ontwikkeld is, die dan net als de SenderID gratis zou worden. De ISPŽs willen daar niet op wachten en hebben op het moment meer vertrouwen in Microsoft.
(edit: lekker is dat. ik geef als enige in deze thread aan WAAROM de ISPŽs ondanks de door OSS community beweerde 'superioriteit' toch niet met SPF willen werken en dat is overbodig? Tweakers wordt wel heel kritiekloos...)
/u/96415/crop5af40af719c6b_cropped.png?f=community){kind=small}
Er is nu SPF, een veel minder krachtig OSS protocol dat vanwege die beperkingen in de huidige vorm niet acceptabel voor de gebruikers (lees: ISPŽs) is.
Waar haal je die BS vandaan? Kun je dat onderbouwen?
Ik kan je behalve het principe argument van de licentie kwestie zo 2 technische redenen geven waarom SPF superieur is aan Sender-ID:
1) Het onnodig gebruik van XML in DNS records voor Sender-ID. Het voegt niets toe en verhoogd de overhead. Zelfs zo dat de DNS records te groot worden voor UDP en dus over TCP moeten.
2) Het Sender-ID protocol laat, itt SPF, niet toe dat een spammail direct na het ontvangen van de <MAIL FROM> geweigerd wordt. Dit kan pas na ontvangst van de hele body wat opnieuw leidt tot grotere overhead en verspilde bandbreedte.
Waar haal je die BS vandaan? Kun je dat onderbouwen?
Ik kan je behalve het principe argument van de licentie kwestie zo 2 technische redenen geven waarom SPF superieur is aan Sender-ID:
1) Het onnodig gebruik van XML in DNS records voor Sender-ID. Het voegt niets toe en verhoogd de overhead. Zelfs zo dat de DNS records te groot worden voor UDP en dus over TCP moeten.
2) Het Sender-ID protocol laat, itt SPF, niet toe dat een spammail direct na het ontvangen van de <MAIL FROM> geweigerd wordt. Dit kan pas na ontvangst van de hele body wat opnieuw leidt tot grotere overhead en verspilde bandbreedte.
:strip_icc():strip_exif()/u/75893/crop6829f1faf0987_cropped.jpg?f=community){kind=small}
Je kunt hier vinden hoe SPF werkt en wat je kunt doen om het te gaan gebruiken:
http://spf.pobox.com
http://spf.pobox.com
toch wel knap hoe je het omdraait. dus het licentie beleid wat microsoft voert is de schuld van de OSS community? De OSS community probeert de boel te vertragen omdat ze zich niet wensen te onderwerpen aan de nukken van microsoft?"De strategie van de OSS community is nu om zo lang mogelijk (...) SenderID (...) tegen te houden"
Apache en debian buigen zich niet voor niks over de kwestie. Als ze het niet wilden, lieten ze het wel links liggen en hoor je ze er niet over.
Er is best bereidheid om senderID te adopteren. Het is microsoft die wat water bij de wijn zal moeten doen wil het senderID als standaard. En water houdt in: het protocol licentievrij houden, en protocol-gerelateerde patenten aan het IETF schenken.
Vergelijk het maar met het HTTP protocol, als dat eigendom was van een bedrijf en je moest een licentie tekenen, dan zouden we wel een ander protocol gebruiken.
Ik wil ook geen licentie hoeven tekenen om nederlands, frans of swahili te mogen praten.
Goede zet van Apache & Debian, vind ik.
En een uitstekend voorstel van Apache erbij.
Deze patenten leveren een potentiëel gevaar op voor de DNS servers, daar het daarop moet worden geïmplementeerd. En ik zou niet graag zien dat M$ voor de volle 100% weet welke servers waar staan..
Dit in het kader van het Amerikaans beleid van de afgelopen jaren en de grote kans dat M$ hierinmee wandelt (DCMA, DRM, BWAH!,..)
En een uitstekend voorstel van Apache erbij.
Deze patenten leveren een potentiëel gevaar op voor de DNS servers, daar het daarop moet worden geïmplementeerd. En ik zou niet graag zien dat M$ voor de volle 100% weet welke servers waar staan..
Dit in het kader van het Amerikaans beleid van de afgelopen jaren en de grote kans dat M$ hierinmee wandelt (DCMA, DRM, BWAH!,..)
deze ken ik niet, waar staat dit voor?BWAH!,
Voordat we weer een discussie gaan starten mbt. OSS vs. niet OSS.......wie zijn er uiteindelijk weer het zaadje met een dagelijks portie penis vergrotende mailtjes ?
Als Sender ID met de huidige voorwwarden standaard wordt? De OSS gebruikers natuurlijk.
Op dit item kan niet meer gereageerd worden.