New members power to email others

There's a new member that seems to have written a script to email everyone else. I've looked for a way to limit brand new members from emailing other members, at least until they go up a level. I don't *think* I see it in Global Privs, or Permission Tree, but I do find this:

In Permission Tree, if I select the lowest (new member level) in the pull-down, and then I select Module: Contact Member, I see below an option to remove "View Access" - What will this actually do if I uncheck View Access?

I'm looking into adding some kind of Captcha in order to see emails on a case/email by case/email basis. Any ideas will point me in the right direction.
 

Removing view access from a page will stop users accessing that page. That's a good solution.

There's also a hidden option (which will be a normal option in v11), to force CAPTCHA for new members and/or members with few posts. That affects anywhere that supports CAPTCHA.

Code Book, part 3 (Miscellany) - Composr

E.g. run these commands in Commandr:

:set_value('captcha_member_days', 10);

:set_value('captcha_member_posts', 10);

I think that'll work perfectly. It would be interesting to see different kinds of challenges, like forcing folks to add two numbers (that are displayed in a fuzzy graphic) and things like that.

It's still got me stumped as to how he did it. His English was poor (in the emails) and his IP showed Senegal or somewhere with more pirates than programmers lol. But the timestamps on the emails show it was a burst of emails going out at exactly the same time. It might be that he manually went through all the members and emailed them manually, which means the system batch-sent the emails (very possible) at about the same second-mark. Otherwise, he wrote a script, which isn't likely given his English and location. Anyway...

Thanks Chris!

 
 

The alternatives to the graphical CAPTCHA are interesting, but it's probably not something I'd ever allow into core Composr because (to my knowledge) they are all either (1) security-by-obscurity or (2) corporate-focused.

1- For example, the number adding. A hacker could easily code up a solution to that, it's just they don't bother because they'd typically have to do it for each site that has it - but if we create a universal Composr solution, it becomes worthwhile the hacker just implementing that and being able to attack any Composr site as a result. It would be a fine addon for someone to make though.

2- For example, Google reCAPTCHA asking you to enter in door numbers or select the bikes or buses in an image. That's a big scale and inherently means hooking your site into Google, which has a range of concerns. Particularly around forcing users of your website to also have their web browser talking to Google (they are no longer allowed to block google.com should they so wish to, and google.com is being told what websites users are visiting). And our neutrality, we don't want to pick corporate winners. We have got a reCAPTCHA addon for v11 though because if a webmaster accepts those downsides it is a really nice solution when it can work completely invisible (using trust data Google already has about machines).

As for this user - often there are smart people in these low-opportunity countries who feel that hacking is one of the rare opportunities that allows them to capitalise on their intelligence. But regardless of that, I think there are probably toolkits out there to help spammers abuse forms like this, to give them a leg up. It's really unfortunate when people do crap like that   .
Timestamps matching, well the mail queue could cause that. Let's say you have the mail queue running every 5 minutes, if he could do all the HTTP hits within on average 2.5 minutes then that would cause them all to go out at once. You could confirm from the web logs if he hit the contact page a tonne of times with POST requests.