1

(30 replies, posted in PunBB 1.2 discussion)

Hrm, no dice - just received another bounce from a .ru address a minute ago. The code looks solid, but something's not quite right.

Am I the only one receiving dozens of bogus .ru signups per day? How is everyone else handling this problem?

2

(30 replies, posted in PunBB 1.2 discussion)

D'oh! Thanks Smartys. Let's see how that does  over the next  24 hours.

Any chance this functionality will  be in a future release (or  plugin?)

3

(30 replies, posted in PunBB 1.2 discussion)

Dang - that didn't  work  either. Tweaked it this morning, but  just got another .ru signup attempt now. Grrr... thanks though.

4

(30 replies, posted in PunBB 1.2 discussion)

Hmmm.... nope, that didn't work - still seeing .ru emails going out. Can anyone see what's wrong with the code change above?

5

(30 replies, posted in PunBB 1.2 discussion)

Yemgi, umm... I know. I was asking for a code sample so I wouldn't blow the parentheses or something. But it turned out to be pretty easy:

    foreach ($pun_bans as $cur_ban)
    {
        if ($cur_ban['email'] != '' &&
            ($email == $cur_ban['email'] ||
            strstr('.ru',$email) ||
            (strpos($cur_ban['email'], '@') === false && stristr($email, '@'.$cur_ban['email']))))
            return true;
    }

I'll give it 24 hours to see if it works, that looks pretty solid.

6

(30 replies, posted in PunBB 1.2 discussion)

I've got no problem issuing CLI commands, nor do I have any problem with editing include/email.php, but... *what* commands can I use to ban all of .ru? Or... *where* in the ban function would I add the tld? Here's the function:

//
// Check if $email is banned
//
function is_banned_email($email)
{
    global $db, $pun_bans;

    foreach ($pun_bans as $cur_ban)
    {
        if ($cur_ban['email'] != '' &&
            ($email == $cur_ban['email'] ||
            (strpos($cur_ban['email'], '@') === false && stristr($email, '@'.$cur_ban['email']))))
            return true;
    }

    return false;
}

I don't see any obvious place in there where I could a .tld. In another thread, it's suggested to use the Ban admin section and enter a partial, but it accepts neither *.ru nor .ru .

So... can anyone clarify the process a bit? Thanks.

Ah, bingo! I didn't have a user Guest, but I did have user Anonymous in gid 4. Changed that to Guest in gid 3 and now it's working properly. I wonder if this could have had something to do with the fact that this board was converted directly from phpBB. Anyway, thanks much both!

Smartys -

Are you referring to the groups table in the db? If I look at that with phpmyadmin, I see a g_id of 3 for Guest. 

Guest is set to 0 for all other fields in that row except for g_read_board, which is set to 1. So if I understand you correctly, this board would appear to be configured correctly, but still mysteriously allowing guest posting. Or am I looking in the wrong table?

Thanks,
Scot

I'm in the same situation - guest posting is disabled in all forums, but unregistered users (mostly spammers) can post without any trouble (and I can log out of the board and post test entries easily). Just upgraded to v1.2.14 but the problem persists. This would seem to be a fairly critical bug, no?  Any timeline on a fix? Anything I can do to prevent guest posting until the bug is officially fixed?

Thanks.

10

(68 replies, posted in PunBB 1.2 discussion)

Well, I would not say that Akismet is automated - it depends entirely on users identifying comments as spam. It's automated in the sense that it does not require your intervention for each comment, but not automated in that its "intelligence" is purely based on what groups of humans designate as spam.

However, Akismet does require reliance on an external server / service. But I don't have a problem with that - it's been great, and with a very low failure rate.

11

(68 replies, posted in PunBB 1.2 discussion)

Twohawks -

Maybe I'm  not understanding correctly, but how is what you're describing different from Akismet?

Scot

12

(68 replies, posted in PunBB 1.2 discussion)

Smartys - Interesting distinction -- very different from many/most systems, where a plugin can modify any aspect of the system (for example WordPress plugins can affect virtually any aspect of WP, not just the back-end). Out of curiosity, why is this different with punBB?

13

(68 replies, posted in PunBB 1.2 discussion)

rgsuk - I agree about mods - and unfortunately there seem to be a whole lot more mods than plugins for punbb for some reason. However, User Management IS a plugin, not a mod, so I can't fault the devs for not including it in core.

14

(68 replies, posted in PunBB 1.2 discussion)

Absolutely brilliant - just what I was looking for. Note I couldn't find this at punres anywhere. For future searchers, the direct link is:

http://punbb.org/forums/viewtopic.php?id=5936&p=1

Thanks.

15

(6 replies, posted in PunBB 1.2 discussion)

Bingo, that's it.  So it looks like verification is  pretty effective.  9/10 of new registrants on my board today did not verify. So is there a mod that will auto-delete users with fewer than 1 post at some regular interval? Or should I just write a quick SQL statement into a php file and execute it via cron at regular intervals?

Thanks,
Scot

reviewum.com wrote:

I respect that opinion, but don't understand it at all.   Maybe I've just got too much time on my hands, but I ALWAYS want to know what people say in reply to my posts... you know, to see if they flame me or praise my greatness! cool

Don't most of you feel the same way when you look at your forum experiences... wouldn't you USUALLY want to see replies to a topic you replied to?

I totally agree. Except that I *don't* have too much time on my hands. I have NO time on my hands. Which is why every time I sign up for a new board, the first thing I do is go to my profile and select "Automatically subscribe me to all threads I post in." 

3/4 of the time, I'm  registering for a board not because I want to read everything that happens there or become part of a community, but because  I have some specific question or questions (e.g. in support forums like this one). There's no way I have time   to go look at a dozen or so  boards every day to see if my question has been answered. And if the default "subscribe" option is not checked, I may forget to check it manually and forget to ever come back. Heck, sometimes I receive an email from a thread I participated in two years ago, containing new and useful information. This is an indispensible feature.

Finally, it's a feature users have come to expect,  because it's so commonplace on other boards. Thus, its absensce from punBB is seen as a negative.

I totally sympathize on the bloat and resource thing (and yes, the question of whether this feature makes sense depends a lot on the popularity of any given board).   But to me, this one is important enough to be worth making the "bloat" compromise for.

Just my .02

17

(6 replies, posted in PunBB 1.2 discussion)

If you have verification turned on for registration, how can  you tell whether the user has actually verified? I don't see this anywhere in the user's profile. When I look in phpMyAdmin, there are fields in the users table for activate_string and activate_key, but these seem to be NULL in all cases.

I'm trying to figure out whether requiring verification is actually an effective deterrent to spammers, but it's tricky if I can't even tell whether they've done the email verification thing.

Thanks.

18

(68 replies, posted in PunBB 1.2 discussion)

Spam  is not a problem IF you can control your user list. That is, if you reasonable assurance that all users are legit, you don't need to worry about spam fighting techniques. So the question really boils down to keeping spammers from signing up. 

My experience managing lots of people's blogs tells me that nothing comes close to Akismet for efficacy. With boards, it's a bit different. Assuming you don't allow guest comments, the game is really about controlling user registrations. With that done, you don't need to worry too much about comment spam.

If Akismet or a similar system could deny bogus signups in real time via the "hive mind," I think we'd have a good solution on our hands.