PHP: Spam weren, maar dan zonder CAPTCHA

Door AndriesLouw op maandag 15 juni 2009 21:13 - Reacties (29)
Categorie: Webdevelopment, Views: 7.302

Schaamloze cross-post van mijn persoonlijke website

We herkennen het probleem allemaal wel, die eindeloze stromen welke binnenkomen in gastenboeken, op blogs, op forums. Zo'n beetje elke plaats op het internet waar gebruikers zelf iets kunnen toevoegen lijkt er aan te moeten geloven: Spam.

Natuurlijk zijn we allemaal zeer geïnteresseerd in die ge-wel-dige aanbiedingen van die Russische pillenboer, de echte Zwitserse uurwerken voor een dumpprijs, of die mooie business proposals van een Nigeriaanse neef. Maar wat als je, net als ik, niks te klagen hebt, en al ruim voorzien bent?

Voor de meeste webmasters is het antwoord al snel: Een CAPTCHA implementeren. Het grootste nadeel is bekend; een goede dient moeilijk te zijn voor computers, maar is dit helaas ook steeds vaker voor een mens.

Gelukkig is er een andere oplossing; spamfilters. Wie Wordpress gebruikt kent vast Akismet wel, een plugin die alle berichten controleert op spam-woorden. In deze post doe ik uit de doeken hoe je zelf zoiets maakt in PHP.


Achtergrond informatie
Maar eerst wat meer achtergrond informatie, ik was op zoek naar een anti-spam-oplossing die aan een aantal voorwaarden moest voldoen:
  • 1. De gebruiker mag er geen last van ondervinden.
  • 2. De oplossing moet snel zijn.
  • 3. Berichten mogen niet in een queue belanden.
  • 4. Bij het plaatsen moet voor de gebruiker direct bekend zijn of een bericht goed-, of afgekeurd wordt.
Ik had kunnen kiezen om een implementatie te schrijven voor Akismet, een bewezen oplossing binnen de blog wereld. Probleem bij Akismet is echter de wachtrij, het kan een hele poos duren voordat het bericht er door is.

Daarom heb ik besloten zelf een spamfilter te schrijven, maar waar moet je dan beginnen? Ik heb voor mezelf een klein lijstje gemaakt waar een typische spam-post uit bestaat:
  • 1. Er staan vaak 1 of meerdere links in.
  • 2. Deze links worden op allerlei manieren ingevoegd in een bericht, bijv.: [url], <a>, [link], http://, of enkel www.
  • 3. Men plaatst ze onder een valse, gegenereerde naam.
  • 4. Hetzelfde geld voor de e-mailadressen.
  • 5. De inhoud bestaat veelal uit dezelfde Engelse woorden.
  • 6. Vaak worden ze geplaatst via proxies, om IP-blokkeringen te voorkomen.
  • 7. Veelal wordt er maar wat gegist qua input velden.
Dit laatste punt vereist wat meer uitleg, het is zo dat elk formulier bestaat uit <input>-velden, deze hebben allemaal een name-attribuut waarop je ze in je code kunt aanspreken. Een spammer heeft echter vaak geen tijd/zin om uit te vogelen welke name-attributen je hebt meegegeven.

Wat hij daarop doet is simpel: Hij probeert zo veel mogelijk uit. Dus stuurt hij niet alleen een e-mailadres[/i] mee, maar ook een e-mail, email, mail, mailadres, emailadres, enz. In de hoop dat 1 van de velden geaccepteerd wordt.

De oplossing
Vervolgens ben ik voor elk punt bij langs gegaan hoe ik zo'n controle het eenvoudigst in code kon omzetten.

POST-velden
Om even bij het name-attribuut voorbeeld te blijven, dit is bijvoorbeeld simpel te controleren door te kijken of een poster niet meer velden opgeeft, dan je formulier uit bestaat:

PHP:
1
2
3
4
5
<?php
if(count($_POST)>5){
    //Vermoedelijk spam, te veel POST-velden
}
?>



Hiermee controleer je dus of er niet meer dan 5 velden worden meegestuurd, in mijn project werd er een naam, e-mail, website en bericht meegestuurd. De geoefende rekenaar telt er hier maar 4, en dat klopt, want ook een Verzenden-knop telt mee in $_POST, waarmee we dus op 5 uitkomen.

Een geldig e-mailadres
Dan het volgende punt, controleren of een e-mailadres wel geldig is, alhoewel de meeste spammers hier wel aan denken, is het natuurlijk ook wel handig voor de bezoeker om hem te laten weten dat zijn e-mailadres niet juist is. Een simpele controle daarop luid:

PHP:
1
2
3
4
5
<?php
if(!ereg('^[a-z0-9_\+-]+(\.[a-z0-9_\+-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*\.([a-z]{2,6})$',$_POST['email'])){
    //Het e-mailadres is ongeldig
}
?>



Ik ga er verder niet op in hoe deze zgn. regexp precies werkt, en neem voor het gemak aan dat het name-attribuut van je e-mail veld "email" heet.

Wat is de ratio van jouw naam?
Dan de naam, hoe controleer je nu of een naam "echt" of "nep" is? We zouden het bevolkingsregister kunnen raadplegen, maar omdat ik dan ruzie krijg met het CBP (College Bescherming Persoonsgegevens), zal ik hier een andere oplossing uitleggen.

Het is namelijk vrij simpel om de ernstige gevallen eruit te filteren, vaak lange willekeurige tekenreeksen zoals: YGaWqnXskCNidzp. Zelfs een kind van 6 ziet gelijk dat dit geen naam is, maar hoe leer je een computer dit?

De oplossing is wederom niet erg lastig; tel het aantal hoofdletters, het aantal kleine letters, en kijk wat de ratio ertussen is. Ik vind een ratio van 0.3 wel aardig klinken. Dat betekend dus 3 hoofdletters op 10 tekens, niets meer (maar wel minder).

Om te voorkomen dat onze geliefde "Jan" ineens wordt uitgesloten van reageren (immers, zijn naam kent een ratio van 0.33), controleren we ook of we voldoende naam hebben om te beoordelen. Laten we stellen dat men minimaal 8 letters moet hebben ingevuld om in aanmerking te komen voor onze razzia naar spam-namen.


PHP:
1
2
3
4
5
6
7
8
9
10
11
12
<?php
$name = $_POST['name'];

$uppercased = preg_match_all('/[A-Z]/', $name, $null1);
$allcased = preg_match_all('/[A-Za-z]/', $name, $null2);
$namelen = strlen($name);

$ucratio = $uppercased/$allcased;
if($namelen > 8 && $ucratio > 0.3){
    //Waarschijnlijk een spam-naam
}
?>



Ik hoop dat de code voor zich spreekt, maar mocht er behoefte aan uitleg zijn, dan wil ik één en ander wel uitdiepen in de reacties.

Proxy-servers
Dan nu over op intercity-tempo, het controleren op proxy servers kan in PHP onder andere door:

PHP:
1
2
3
4
5
6
<?php
if ((isset($_SERVER['HTTP_X_FORWARDED_FOR']) || isset($_SERVER['HTTP_VIA']) || isset($_SERVER['HTTP_COOKIE2']) || isset($_SERVER['HTTP_X_FORWARDED_SERVER']) || isset($_SERVER['HTTP_X_FORWARDED_HOST']) || isset($_SERVER['HTTP_MAX_FORWARDS']) || isset($_SERVER['HTTP_PROXY_CONNECTION']))){
    //Gebruiker gebruikt een proxy server
    $myscore += 5;
}
?>



Scores toekennen aan regels
De oplettende lezer spot gelijk "$myscore" (als je hem niet zag, en er problemen mee hebt: 0900-1450), hiermee ken ik dus een score toe aan een controle.

Zo kan ik stellen dat het hebben van een ongeldige naam, minder zwaar gerekend wordt dan het gebruik van een proxy server. Uiteindelijk kun je dan een drempelwaarde instellen waarboven een post als spam wordt aangemerkt. (Daaronder val je met de deur in huis, en staat je bericht direct online!)

De woordenfilter
Dan het belangrijkste onderdeel van onze spamfilter, de woordenfilter. Omdat we al met scores werken, lijkt het me handig om onderscheid te maken in 2 groepen: Hard-spam-woorden en Soft-spam-woorden (en ja, dat is redelijk vergelijkbaar met de classificatie in bepaalde natuurfilms).

Om te voorkomen dat ik straks heel populair ben in Google op deze spam-termen, heb ik een voorbeeld lijstje, wat ik gebruik, onder deze link geplaatst.

In mijn lijstje staan ook links onder de "hard"-classificatie, dit omdat ik voor het project heb gekozen gebruikers niet links te laten plaatsen in de comments, en dit ook duidelijk heb vermeld. Hiermee wordt al een hele hoop spam geweerd. En de gebruiker die graag zijn link wil zien, kan deze bij "website" invullen.

Vervolgens vullen we het lijstje aan met de volgende code:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$comments = $_POST['comments'];

foreach($spam_words_hard as $sw){
    if(strpos($comments,$sw) !== false){
        $myscore+=7;
    }
}
    
foreach($spam_words_soft as $sw){
    if(strpos($comments,$sw) !== false){
        $myscore+=3;
    }
}
?>



Hard krijg dus 7 punten, en soft 3 punten per woord. Een beetje spam bericht telt zo al lekker op, en ik ben in productie dan alleen op dit punt al scores boven de 50 tegengekomen.

Tot slot
Voor mensen die liever lui dan moe zijn, heb ik de door mij gebruikte functie online gezet op: http://dev.andrieslouw.nl/antispam.phps.

Een iets uitgebreidere versie van deze functie heeft tot nu toe in mijn project, een website met meer dan 12000 unieke bezoekers per maand, waaronder een 100-tal spambots, nog geen enkel spam-bericht doorgelaten (drempelwaarde van $myscore is bij mij 10).

Maar belangrijker is nog, dat de gebruikers er zelf geen last van ondervinden, de meesten merken niet eens op dat hun bericht door een filter gaat.

Ik wil iedereen wel van harte aanmoedigen om deze functie als basis te gebruiken, en niet zo maar in productie in te zetten. Het is natuurlijk aan jou om te bepalen wat er wel of niet met spam berichten gebeurd, welke woorden je filtert, welke score je toekent per onderdeel, en welke score je als drempelwaarde gebruikt.


Wat zien jullie tweakers het liefst? Dat ik in het vervolg artikelen ook hier in zijn geheel plaats? Of bevalt dit linken wel? En is het niveau te laag? Of juist te hoog? :+ Ik hoor het allemaal graag :)

Edit: Zoals jullie zien staat hij hier nu volledig, bedankt voor al het commentaar tot nu toe!

Volgende: Wensen 12-'07 Wensen

Reacties


Door Tweakers user Erkens, maandag 15 juni 2009 21:20

Wat zien jullie tweakers het liefst? Dat ik in het vervolg artikelen ook hier in zijn geheel plaats? Of bevalt dit linken wel?
Ik vind het best irritant dat ik moet doorklikken om alles te kunnen lezen, dat is dan vaak ook het punt waar ik dan afhaak :)

Door Tweakers user AndriesLouw, maandag 15 juni 2009 21:26

@Erkens: Oké, ik zit even met het duplicate content verhaal op Google, en dat ik graag alles centraal houd. Maar ik ga even goed nadenken over hoe we dit oplossen! Bedankt voor je commentaar.

Door Tweakers user JoWannes, maandag 15 juni 2009 21:28

Wat zien jullie tweakers het liefst? Dat ik in het vervolg artikelen ook hier in zijn geheel plaats? Of bevalt dit linken wel?
Enerzijds lezen we graag hier het hele verhaal, anderzijds is dit wel vrij lang, en dus minder prettig als je het artikel al gelezen hebt en een volgende keer enkel de comments leest...
Maar ik denk dat het eerste het meest mag doorwegen. ;)

Door Tweakers user AndriesLouw, maandag 15 juni 2009 21:32

@JoWannes: Dat maakt 2 stemmen voor hier volledig, 0 tegen. Als de resultaten zo blijven dan gaat de volgende sowieso volledig! :)

Door Tweakers user mithras, maandag 15 juni 2009 21:34

Het CSRF element van Zend werkt prima om in php al veel tegen te houden.

Daarnaast heb ik meestal twee input velden in mijn formulier staan met random namen. De ene is voor een verplicht veld (bijvoorbeeld naam), de andere verberg je dmv css. De namen zijn elke keer weer random en dus anders.
Vervolgens check je na de post of de ene leeg is en de andere gevuld. Dat werkt al tijden echt perfect.

Als je vervolgens de twee methodes combineert ben je helemaal safe :)

Door Tweakers user Vold, maandag 15 juni 2009 21:36

Interessant stukje! Je manier van aanpak doet me erg denken aan de "spam-bots" die op wikipedia.org draaien. Deze hebben een vergelijkbare manier van aanpak.

Door Tweakers user TeeDee, maandag 15 juni 2009 21:39

* TeeDee vind het doorlinken naar hele verhalen maar vervelend. Zo zijn er op de tweakblogs wel meer. Ook dat vind ik een (irritante) vorm van spam.

Inhoudelijk op je oplossing/idee:
Her en der heb ik wel wat forms gemaakt voor diverse sites en mijn simpele (en favoriete) oplossing is het verbergen (middels css) van een veld met een, voor de spammer, aantrekkelijke naam. Denk aan (email, e-mail etc. etc.) en het echte email adres veld een andere naam geven.

Is in de post het verborgen veld gevuld: rücksichtslos de reactie afkappen en een melding geven. Is het dan alsnog een echt persoon: tough shit.

Door Tweakers user TeeDee, maandag 15 juni 2009 21:40

@mithras: :)

O en Andries, ik kan niet editten :D

Door Tweakers user EdwinG, maandag 15 juni 2009 21:43

Ik stem ook voor volledig. Al is het maar omdat ik niet graag op veel verschillende websites reageer (en een e-mail adres achterlaat) en het erg vervelend is om commentaar niet bij het bericht te hebben.

Over e-mail gesproken:

code:
1
2
3
4
5
<?php
if(!ereg('^[-!#$%&\'*+\\./0-9=?A-Z^_`a-z{|}~]+'.'@'.'[-!#$%&\'*+\\/0-9=?A-Z^_`a-z{|}~]+\.'.'[-!#$%&\'*+\\./0-9=?A-Z^_`a-z{|}~]+$',$_POST['email']){
    //Het e-mailadres is ongeldig
}
?>



Is wel een erg ingewikkelde manier om de controle fout te doen :)

Zo mag in jouw voorbeeld een tld bestaan uit de volgende karakters:
code:
1
-!#$%&\'*+\\./0-9=?A-Z^_`a-z{|}~


Bijna elk printbaar ascii-teken dus. Ik zou graag willen weten waar het tld '!$' bij hoort.
Een strakkere controle voor het tld zou het volgende zijn:

code:
1
[a-z]{2,6}


(totdat de vele andere tekens in een top level domein worden toegelaten, maar dan staat jouw voorbeeld ook niet genoeg toe)

Overigens zijn er veel meer mensen die met dergelijke validatie zitten, dus waarom het wiel opnieuw uitvinden?

[Reactie gewijzigd op maandag 15 juni 2009 21:54]


Door Tweakers user AndriesLouw, maandag 15 juni 2009 21:44

@mithras & TeeDee: Jullie oplossingen zijn identiek, maar zeker interessant! Mijn oplossing met velden tellen is dus echt heel simpel, jullie uitbreiding stukken beter! :)

@Vold: Ik ken die spam-bots niet precies, dus ik ga er eventjes naar kijken, bedankt voor de tip in ieder geval!

@TeeDee: Ja, het is, ik geef toe, ook wel een beetje spam. O-) Ik verzamel de berichten echter graag op mijn site, maar mijn publiek zit hier. En ook dat speelt mee. Toch denk ik dat het niet onverstandig is dat ik voortaan alles hier ook volledig plaats, eventueel met een linkje naar mijn eigen site terug. (Ondersteund T.net trouwens track/pingbacks op één of andere manier?)

Door Tweakers user AndriesLouw, maandag 15 juni 2009 21:49

@EdwinG: Ik moet eerlijk bekennen dat die regexp overgenomen is uit één of ander boekje of website. Ik ga hem vervangen door jouw oplossing. Wederom, ook bedankt voor jouw stem (en motivatie). Wellicht zet ik het hier vanavond nog volledig neer (moet alleen een hoop code omzetten naar T.net tags).

@TeeDee: Editten ga ik aanzetten! (Als dat kan ;)) Edit: Het werkt! Succes ;)

[Reactie gewijzigd op maandag 15 juni 2009 22:04]


Door Tweakers user HyperBart, maandag 15 juni 2009 21:53

Best wel nice, maar je antwoordformulier bij je blog is bij mij in FF3 vernaggeld ?

Door Tweakers user AndriesLouw, maandag 15 juni 2009 22:03

@HyperBart: Bedankt voor de melding, ikzelf draai enkel Opera en Chrome, dus heb het niet opgemerkt, ik ga er naar kijken :)

Door Tweakers user veldmuis, maandag 15 juni 2009 22:23

Kijk dan ook gelijk maar naar IE.
Ergens behoorlijk gaar dat je eerst de input en dan het label hebt?

Door Tweakers user AndriesLouw, maandag 15 juni 2009 22:31

@veldmuis: Zal ik doen, reactie veld is overgenomen uit bestaande WP-template, gezien ik het niet echt als belangrijk zag. Maar het is storend, en ik zal het oplossen.

Edit: Solved ondertussen, bleek een CSS "conflict" te zijn met mijn contact formulier

[Reactie gewijzigd op maandag 15 juni 2009 22:37]


Door Tweakers user Johnny, maandag 15 juni 2009 23:06

Ik denk dat de conrole op hoofdletters in de naam veel echte reacties buitensluit. In de praktijk ervaar ik dat een enorme hoeveelheid mensen niet de moeite neemt om hun eigen naam met eenhoodletter te schrijven, zelfs niet als afzender bij hun emailadres of in gebruikersnamen terwijl het daar maar een eenmalige moeite is.

Zelf heb ik als oplossing voor dit probleem een aantal verborgen velden aan reactieformulieren toegevoegd die doormiddel met JavaScript automatisch worden gevuld, en bij ontvangst wordt gekeken of deze velden de juiste waarde hebben. In theorie zou iedere spam-bot met een JavaScript-parser het zo kunnen misbruiken maar in de praktijk blijkt het vooralsnog toch 100% van de spam tegen te houden. Gebruikers zonder JavaScript (en spam-bots) krijgen wanneer het plaatsen niet lukt de melding dat ze moeten inloggen, waarmee deze groep ook niet wordt buitengesloten.

Door Tweakers user Nick_S, maandag 15 juni 2009 23:09

Je regexp voor mail voldoet niet aan RFC-822. Zie hier voor eentje die er wel aan schijnt te voldoen. Ik ga hem hier niet posten en heb hem ook niet gecontroleerd. ;)

Door Tweakers user AndriesLouw, maandag 15 juni 2009 23:14

@Johnny:
En in dat geval is de ratio 0, en dus lager dan 0.3, prima toch? Mensen die met CAPS-LOCK aan typen, die komen op 1, en die heb ik liever ook niet ;) Maar gelukkig worden er niet zo veel strafpunten voor toegekent.

JavaScript enzo heb ik ook aan gedacht, maar ik wil niemand buiten sluiten, en check het liefst alles server-side. Daarnaast zijn de reactie-formulieren niet dynamisch, maar "gewoon" HTML, i.v.m. het hoge aantal pageviews erop, en de load die het anders veroorzaakt. Pas bij het plaatsen van een comment wordt PHP aangesproken, en daarvoor kan alles gecached HTML zijn. Dynamische velden vielen dus in mijn project ook al af.

@Nick_S:
Ik ben ondertussen druk aan het zoeken naar een verbeterde regexp, en probeer hem werkend te krijgen en goed te testen. Ik neem je "inzending" mee, bedankt! :)

Door Tweakers user doeternietoe, maandag 15 juni 2009 23:14

Voor de meeste webmasters is het antwoord al snel: Een CAPTCHA implementeren. Het grootste nadeel is bekend; een goede dient moeilijk te zijn voor computers, maar is dit helaas ook steeds vaker voor een mens.
Dit laatste punt vereist wat meer uitleg, het is zo dat elk formulier bestaat uit <input>-velden, deze hebben allemaal een name-attribuut waarop je ze in je code kunt aanspreken. Een spammer heeft echter vaak geen tijd/zin om uit te vogelen welke name-attributen je hebt meegegeven.
Vanuit het perspectief van spammers gezien: Het is vele malen gemakkelijker om de html de parsen en alleen iets te sturen naar bestaande input-velden dan om een catchpa te lezen. Het kan nu best werken, maar zodra meer sites het implementeren is het zo afgelopen.

Je controle op een geldig e-mailadres kan nog worden uitgebreid met een controle of het mx-record bestaat. Zie hiervoor http://us2.php.net/manual/en/function.getmxrr.php .

Ik zou zelf controleren of voor het domein een mx-record bestaat en vervolgens het gedeelte voor de @ controleren op geldige tekens, dat maakt de regular expression ook een stuk minder complexer.
Proxy-servers
Dan nu over op intercity-tempo, het controleren op proxy servers kan in PHP onder andere door:
En bosjes normale internetters hebben deze header ook, simpelweg omdat ze via een bedrijfsnetwerk je site bezoeken of omdat hun ISP deze meestuurt. Ik zou bijvoorbeeld alvast een paar "spampunten" krijgen omdat mijn ISP een HTTP_X_FORWARDED_FOR mee stuurt.
Bij het plaatsen moet voor de gebruiker direct bekend zijn of een bericht goed-, of afgekeurd wordt.
Bouw dan wel een kleine (10 seconde oid) vertraging in, anders kan de spammer gewoon gaan uitproberen.
Om te voorkomen dat onze geliefde "Jan" ineens wordt uitgesloten van reageren (immers, zijn naam kent een ratio van 0.33), controleren we ook of we voldoende naam hebben om te beoordelen.
Again, zodra spammers doorhebben dat je ze op die manier beoordeelt heet iedereen Jan, Piet of Henk. (of een willekeurige tekenreeks van 4-5 karakters lang). Zolang jij de enige bent is er niks aan de hand, maar zodra deze beoordeling overal plaatsvindt werkt het niet meer.

Verder erg nice hoor :)

Door Tweakers user ZpAz, maandag 15 juni 2009 23:21

Wat ook wel eens wil werken.

Een normaal input veld 'hiden' dmv css (of zelfs evt JS) met als naam 'firstName' oid. Een botje weet niet dat hij niet zichtbaar is, en zal hem dus invullen.

(Verstoppen kan via display: none, evt, position: absolute en dan uit het beeld ofzo (mocht je denken dat botjes slim genoeg zijn voor display: none).

Een niet botje ziet hem niet (mens) en vult hem niet in.

Serverside controleren of hij is ingevult, en je hebt een spammer te pakken.

Zo houd je de algemene spammers buiten de deur, alleen spammers die zich echt op jou site richten zouden er doorheen komen.

Door Tweakers user AndriesLouw, maandag 15 juni 2009 23:26

@doeterniettoe:
Je hebt met alle punten gelijk, en ik moedig het dan ook aan om uitbreidingen te schrijven, je MX-check is zeker niet slecht, en er kunnen eenvoudig een paar punten aan worden gehangen! :)

De reden dat proxy-servers toch een paar puntjes krijgen is om ze zo net over die drempel heen te pushen in geval van twijfel. Het zijn ook maar ideeën, en je bent vrij om een set regels wel of niet de implementeren.

Het doel van deze blogpost was mensen te inspireren het eens anders te doen dan met CAPTCHA's, want die worden tegenwoordig ook gewoon ge-outsourced naar India, alwaar ze de hele dag ingetikt worden voor een hongerloontje. Spam-filters zul je ook continu moeten aanpassen, maar bieden wel een, vooral voor de gebruiker, minder vervelende oplossing.

1 ding nog: De vertraging, ik heb er serieus over nagedacht, maar het heeft geen zin, zodra een spammer gaat multithreaden, dan vervalt mijn vertraging al. (Immers kan hij dan 100 verschillende versies submitten, 10 sec. totaal wachten, en dan is hij even ver als 100 verspreid over 10 seconden indienen in normale situatie.) En ik ga met 30 pageviews/seconde niet elk IP bijhouden in een database om te kijken of ze op dit moment niet al een poging doen om een reactie toe te voegen, dat wordt té complex. ;)

Door Tweakers user TeeDee, maandag 15 juni 2009 23:30

@ZpAz: dat zeggen mithras en ik ook al ;)

Een van de betere anti-spam oplossingen: een registratie, maar dat is natuurlijk een vrij grote drempel.

Door Tweakers user AndriesLouw, maandag 15 juni 2009 23:31

@ZpAz: Ook een mooie oplossing ja, lijkt ook wel op die van TeeDee en mithras. Zoals gezegd: mijn oplossing qua tellen van $_POST variabelen is heel simpel.

De kracht zit hem juist in het combineren van verschillende technieken, en het punten bijhouden. Als iedereen zelf iets verzint, wordt het voor een spammer enorm moeilijk om 1 tactiek te kiezen. :)

Door Tweakers user crisp, maandag 15 juni 2009 23:37

want ook een Verzenden-knop telt mee in $_POST
Alleen als je die een name-attribuut geeft, wat geen vereiste is ;)

Door Tweakers user AndriesLouw, maandag 15 juni 2009 23:41

@crisp: Oh, my bad, ik geef altijd alle input's een name-attribuut mee. En ik heb in het verleden vreemde dingen gezien met IE, die soms wel, soms niet submit's meestuurt. Daarbij, better safe, than sorry ;)

Door Tweakers user crisp, dinsdag 16 juni 2009 08:00

AndriesLouw: IE heeft zo wel eens z'n nukken, maar ook andere browsers zullen een name-value pair van een submit-button niet meesturen als het geen activated element is (bijvoorbeeld als een submit getriggered wordt dmv een <enter> in een tekstveld ipv een klik op de button).

Door Tweakers user Punkie, dinsdag 16 juni 2009 09:41

Het verbaast me dat met een dergelijk eenvoudige opzet een grote succesratio kent voor spam. Tenminste, een hoge successratio is ik wat ik denk dat je claimt want je informatie hierrond is nogal vaag. Voor iemand (inclusief jezelf) kan besluiten dat het weldegelijk goed werkt met er een evaluatie methode worden bepaald en cijfermateriaal worden verzameld.

Enkele vragen die belangrijk kunnen zijn:
Hoeveel "goede" berichten zijn er? Hoeveel spam berichten zijn er? Hoeveel goede berichten worden als spam geclassificeerd? Hoeveel spam berichten worden doorgelaten? Hoe meet je deze waarden? Hoeveel berichten worden herzonden (als in, submitted, failed spamtest, aangepast en resubmit)?
En hoe verhoud zich dat tot andere oplossingen?

Door Tweakers user StefSybo, dinsdag 16 juni 2009 09:50

Ik gebruik zelf ook altijd wat filters van het type zoals jij ze beschrijft om te kijken of er bijvoorbeeld niet te snel wordt gepost (binnen 3 seconden het formulier invullen is waarschijnlijk spam), maar daarnaast gebruik ik Linksleeve.
Dat is een webservice waar je je bericht naartoe stuurt en die controleert dan of er verdachte links in staan en die geeft direct een antwoord terug (dus geen queue). Verdachte links zijn links naar domeinen die Linksleeve te vaak tegenkomt. Mijn ervaring is dat spam hiermee goed gedetecteerd wordt en hoe meer mensen meedoen, hoe beter het wordt, omdat nieuwe spamdomeinen sneller gevonden worden.

Door Tweakers user basvd, dinsdag 16 juni 2009 10:20

Ik gebruik altijd dezelfde methode als ZpAz, en dit werkt altijd perfect. Daar waar ik eerst 50 berichten per dag kreeg zijn er dit nu 0.

Een andere simpele oplossing is om via JavaScript een hidden field toe te voegen aan het formulier. De meeste spambots ondersteunen geen javascript, dus 'geen veld in $_POST=spam'

Reageren is niet meer mogelijk