Of Standaard.. Of Patent.

één van de twee, het maakt mij niet uit welke, maar allebei kan niet.

1. Jat een idee
2. Patenteer het
3. ??
4. Profit!!

<FLAME ON>
Is Microsoft niet dat bedrijf dat software maakt met veel security fouten?
Wat is de garantie dat zij een goed protocol kunnen maken (tegen spam)
dat niet lek is?
</FLAME OFF>

Ik gok dat MicroSuf niet eens de moeite heeft genomen zich
te verdiepen in RFC's of ook maar is begonnen zelf zo'n
request te schrijven voor SenderID.

Het beste van de bestaande protocollen is dat er door veel
meer partijen onderzoek naar is gedaan zonder
belangenverstrengeling of gepatenteer gedoe.

Alleen dan heeft het een kans van slagen. Dat MicroSuf het
nu gepatenteerd heeft zegt al veel over wat ze begrepen
hebben van de bestaande protocollen, visie voor de toekomst
en het belang van ons allemaal dat spam op een bepaalde
manier verminderd kan worden.

MicroSuf, zo leert de geschiedenis, is onbetrouwbaar,
onberekenbaar en zeer zeker puur met hun eigen belangen bezig.

Noem eens een ontwikkeling, een uitvinding die door MicroSuf
zelf is ontworpen en niet is gekopieerd, gestolen, opgekocht
of wat dan ook....... Nou? Wie? Precies.....

- Unomi -

Nou, bekijk het protocol eens en geef gefundeerde kritiek. Heeft iedereen
meer aan dan dit soort opmerkingen...

De werkgroep rond SenderID was opgeheven na de problemen met
de MS patenten. Dat MS nu opnieuw voorstellen naar de IETF
stuurt, zonder dat een uitgewerkte specificatie bestaat, is
geen goed idee.

Van de SPF mailing list:

Microsoft zal altijd deze smerige tactieken blijven
aanhouden... een patent ergens op, het gratis aanbieden maar
er pas geld mee gaan verdienen als het niet meer is weg te
denken.

Ik vond het juist heel mooi dat ze besloten een bestaande
standaard (namelijk SPF) uit te breiden, in plaats van een
hele eigen standaard erdoor te drukken. Alleen als het niet
vrij te gebruiken is is het niet nuttig...

Een interview waarin de lead developer van SPF het allemaal
vrij helder uitlegt:
http://www.circleid.com/article/634_0_1_0_C/

Embrace and extend. Vervolgens patenteren klaar.

Wat is er mis met SPF dan waarom er koste wat kost een
gepattenteerd systeem moet komen?
SenderID heeft dingen alleen slechter gemaakt door
verwarring te zaaien over wat er nu als standaard moet
worden gekozen. Als we gewoon bij SPF waren gebleven was er
tenminste écht één standaard.

1. of koop het bedrijfje op wat het idee bedacht heeft ...
legitiem stelen ;-)

3a. laat mensen het eerst een tijdje gebruiken
3b. zorg voor een sterke lockin
3c. bedenk een absurd licentie model
3d. kom terug van je oorspronkelijke idee, maar vraag toch
grof geld voor je patenten

5. ga langs strart en begin weer bij 1.

Wat is dit de nieuwe versie van monopolie ;-)

Ok, ik ben VOOR SPF, en tegen CallerID (M$ wilt SPF & CallerID
samenvoegen tot SenderID)

Waarom niet Caller-ID? :


Voor Caller-ID moet de MTA (mail transfer agent) elk message op een zeer
complexe manier parsen.
De MTA moet allemaal headers gaan parsen, en zeer veel verschillende
DNS-records gaan opvragen.
In deze records moet valid XML zitten, wat er vaak ook nog eens voor gaat
zorgen dat de DNS-packets
te groot worden, waardoor het over TCP moet, wat een totale ramp is voor
DNS. Daarnaast is Caller-ID
zo complex dat het mogelijk tot max. 20 DNS lookup's moet doen, wat een
totale ramp is voor de snelheid
waarmee een message deliverd kan worden.

De DNS records moeten valid XML bevatten!!, wat betekend dat elke
minimale fout in de implementatie
ervoor zorgt dat je invalid XML hebt, wat er dan weer voor zorgt dat alle mail
van dat domein als spam
aangemerkt wordt.

Verder kunnen er nog problemen zijn, omdat de XML ook UTF moet kunnen
bevatten, waardoor het aan de MTA
is om uit te zoeken of de DNS-TXT record nu UTF bevat, of ASCII. Dit is nu
net een van de dingen die
je NIET door een MTA moet laten doen. Een MTA moet mail afleveren bij
een client, en die moet zich af
gaan vragen wat erin zit.

Caller-ID werkt op de data van een mailtje (de headers), in plaats van op de
meta-data zoals traditioneel
altijd gedaan is. Dit is een totale transitie van de huidige manier van
werken, en zal de huidige lichte
MTA's omvormen tot logge krengen, die zeer foutgevoelig zullen zijn (zoals
MS Exchange server bijv. ).

Deze totale operatie (die erg zwaar is) moet Nota Bene gedaan worden
terwijl de remote SMTP-mailer nog verbonden
is (wat NATUURLIJK problemen gaat geven met de timeout's die SMTP-
mailers hanteren, en de ontvangende SMTP-
server moet zeggen dat het niet 'OK', is als de DATA gedaan is, in plaats
van bij de intiutieve stage tijdens
het opgeven van de 'From' en 'To' adressen.

Verder heb je nog het probleem in de specificatie dat een smtp-server een
message moet accepteren als de
SMTP sender door de check heen gekomen is, waarbij er totaal geen
rekening mee gehouden wordt dat er ook andere
factoren kunnen zijn die de verzending kunnen laten falen, zoals een loop
in forward, over quota, administratief
geblokeerd, etc, etc.. Dit is vragen om het creeeren van een Mail-Blackhole
(ok, dit is afhankelijk van de implementatie,
je kan eromheen werken).

Doordat de checks gedaan worden op de message in plaats van op de
sender (wat MS in feite voorstelt is, om de
totale user-from checks totaal achterwege te laten), moet de totale headers
geparst worden, wat mogelijke fouten
introduceerd in de header-parser, en de deur opend naar geadvanceerde
header-spoofing-technieken. Ook zouden er
fouten in deze parsing kunnen optreden (door buffer overflow's etc) die het
mogelijk maken om de totale mailserver
over te nemen. Deze mail-server zou dan gebruikt kunnen worden om
JUIST spam te sturen. De ironische situatie zou
zich voordoen dat juist de techniek die spam zou moeten tegenhouden, het
mogelijk zou maken om spam te versturen.

SPF aan de andere kant VERSTERKT de bestaande User-From checks, en
zorgt voor een methode waarmee het mogelijk is
ervoor te zorgen dat dit werkelijk werkt. SPF is ook op de mail-server zeer
eenvoudig te implementeren doordat het
nu altijd mogelijk is om een RBL-check te doen op een from-domein. Door
simpelweg de from-rbl-check te doen bij
een RLB dns-server die OOK checkt of de ip ook in de DNS geregistreerd
staat, is het mogelijk om in een zeer korte
tijd (weekje) een heel serverpark gebruik te laten maken van SPF zonder de
software zelf aan te hoeven passen.

Ik weet er wel een paar :

MS-BOB <http://toastytech.com/guis/bob2.html>
De Office Paperclip (Clippy)