Quote:
|
Originally Posted by Michael Morris
Since the master blacklist gets updated a lot I'd like to keep it seperate from the local list.
|
I wasn't suggesting that the two were stored together. Very much pro having local/standard rules.
Quote:
|
Originally Posted by Michael Morris
While storing as txt file is optional, storing as a template needs to be an option for those who have file systems set up such that php can't write to the file system (for this same reason vbulletin has the option to retain CSS definitions in the page itself although this is far less efficient).
The local list needs to be a template for quick accessability.
At 50K and growing, I don't think it's gonna fit in the phrase system.
|
Sounds sensible. I'm not much of a template expert, to be accessable in an environment where there are multiple styles will this template have to be inherited from a default style?
Quote:
|
Originally Posted by Michael Morris
At some point we need a cron job to go to jay allen's site and pull down the updates to the list (He's given his permission for this). To spare his bandwidth, we need to get the system to only do a full refresh when requested from the admincp. Most of the time the system should download the latest 100 additions about once every 3 to 5 days.
|
That should be easy to do by looking at the template.dateline field.
A little wrapper script in ./includes/cron and called via the scheduled tasks is probably the best way to go.
Quote:
|
Originally Posted by Michael Morris
On large boards such as mine there are many legit users that use numbers in their user names. Hence it would be difficult if not impossible to make it a useable discernment.
|
I wasn't suggesting that all users with bob90 style names should be banned just that using a points based system it could count against them.
Quote:
|
Originally Posted by Michael Morris
What would be idea is an algorythm to iterate over the user's signature, post, and title, extract all URL's and put them in an array. Then compare these arrays for a match. Depending on the number of matches we can extract domain names from the array and add them to the local list.
|
I was planning to make the library checking function use an input array so you can define different fields in the rules as per the most mature incarnation of spamkiller.
Quote:
|
Originally Posted by Michael Morris
The message itself should be scanned for spammyness. Repeated use of the $ character, FREE in all caps, and maybe use an unusual words list (user definable) for words that shouldn't occur on a normal basis - viagra for example.
|
I think that free at all should count towards it being spam. I've caught quite a few with the combination of "free", a url and "$" or "%" signs in a post.
Quote:
|
Originally Posted by Michael Morris
Sounds good. I'll start with the installer to set up the vboptions for this hack.
As far as functions - right now the code here has the actions taken inside the searching loop. To be honest these need to be seperate. Set up some kind of static variable to cound matches and return it, and put the ban action in a seperate function (or look into the possibility of using the existing ban functions. BTW, I noticed that in spam buster you wrote a routine to send mail - there's already a mail function in vbulletin: vbmail. It's defined in the functions library with is included on all executions of the vbulletin code.
|
I'll make stuff as reusable as possible. Certainly having functions to handle logging, banning, etc would make sense and it would make switching them in/out through configuration variables much easier.
The sb_send_mail function was just there to build the mail. vbmail() was used to do the sending
PHP Code:
function sb_send_mail($vars) {
$mail=array();
$mail[] = "This is an automated email from vB SpamBuster";
$mail[] = "";
$mail[] = "The user <%USER%> has just tried to post the following message:";
$mail[] = "";
$mail[] = "***********************************************";
$mail[] = "<%MESSAGE_TITLE%>";
$mail[] = "***********************************************";
$mail[] = "<%MESSAGE_BODY%>";
$mail[] = "***********************************************";
$mail[] = "";
$mail[] = "The vB SpamBuster system deemed it to be spam after it passed the following tests:";
$mail[] = "<%HITS_STR%>";
$mail[] = "";
$mail[] = "This post has now been put in the moderation queue";
$msg = implode("\n",$mail);
foreach($vars as $k => $v) {
$msg = str_replace("<%$k%>",$v,$msg);
}
$emails = explode(' ',SB_ALERT_EMAILS);
foreach($emails as $email) {
vbmail($email,'vB SpamBuster Alert',$msg);
}
}
Quote:
|
Originally Posted by Michael Morris
I personally avoid PRCE expressions like the plague, but sometimes they're the only way to go |
I think their speed is often overlooked - could be folklore but I've heard people say that the Perl regular expression has been so highly optimised over the years that often doing substr/strchr type operations is no less CPU intensive.
Right - there's plenty to bet getting on with now
More Information