We use InstantForum (2016-2) and have the Spam integration. However, there are a few issues here.

First, it seems that at times spammers will script a large number of new posts in a short period of time. While the SPAM API will catch up, this results in pollution of the forums and notifications being sent to users that are subscribed, which is very upsetting to them.

Is there any way to limit the number of new posts for new users? It would be good to specify a threshhold that might limit a new user (< x number of posts or y number of time since registration) from posting more than z number of new threads or replies.

In line with this, is there a way to perhaps delay or limit notifications for a new thread until the SPAM service has had a chance to evaluate the post?


Steve Jones

www.sqlservercentral.com

Hi Steve,

Thank you again for your posts and suggestions. 

I'm afraid we don't have these two limits or restrictions currently however we'll ensure these are added in the next minor update. 

With InstantForum 2017 we have a single stored procedure that is responsible for inserting and updating all topics & replies. This is the if_sp_InsertUpdatePost stored procedure. If your using an earlier version this may be if_sp_InsertPost. Implementing a threshold for the number of posts a user can add for a specific interval would not be to tricky. A very simple approach would be to modify if_sp_InsertUpdatePost like so...

IF (@intPostID = 0)
BEGIN

    DECLARE @postsPerMintute INT = 5;
    DECLARE @postsInLastMinute INT = (
        SELECT COUNT(PostID) 
        FROM InstantForum_Topics 
        WHERE 
            UserID = @intUserID AND
            DateStamp >= DATEADD(s, -60, GetDate())
    )

    if (@postsPerMintute >= @postsInLastMinute) 
    BEGIN
        SET @intIdentity = 0;
        RETURN;
    END

    /* continue insert into InstantForum_Topics */

Of course this is not a production ready example but I wanted to show it should not be to much work for us to introduce this functionality within the next update. Of course we would need to make this configurable and handle this limit in a friendly manner to inform the user they must wait before submitting another post. 

With regards to the notification delay I think it would be more practical to introduce a feature that prevents a user from generating any email notification until they reach a specific reputation level or account age.  For example only after the account has existed for 1 day or only after the account reaches a specific reputation level would notifications be triggered for actions performed on that account. Would this be an acceptable solution Steve?

I look forward to hearing from you and assisting further with these requirements :)


Kindest Regards,

Ryan Healey



ryan@instantasp.co.uk
www.instantasp.co.uk
Blog | Community | Docs

   

Thanks, and we'll look at that sporc and see if there is something that helps us.

Perhaps I'm not explaining this well. The issue is really notifications of existing users.

Let's say that I have Sarah, who's been a member for years and answers a lot of questions. She's a great asset to the community, and enjoys helping. She subscribes to a forum so that she can quickly answer posts. A spammer registers, gets approved, level 1. He uses scripting to post 100 messages in 10 minutes before the SPAM system marks him as SPAM and hides his posts, moves to Banner Members. However, in that time, Sarah has gotten 100 notifications. Same for other subscribers.

There's a bit of a hole with the scripting capabilities of tools that can post without actually accessing the web page.

What I would like to do is not get immediate notifications, and instead somehow queue/delay these. If someone gets marked as SPAM and moved to banned members, read the queue and flush out notifications from that user.



Steve Jones

www.sqlservercentral.com

Hi Steve,

Thank you so much for your response and clarification.

Would adding a notification delay option to each permission set help with your described scenario? For example new members could automatically be placed into a "New Members" member group. This "New Members" member group would have a unique permission set associated with it and this permission set would include a notification delay. 

Let's say the "New Members" member group has a notification delay of 60 minutes. 

When users who have the "New Members" member group post new topics or replies any forum notifications they generate to other members subscribed to the forum the new users has posted within are added to the queue but won't actually be sent until 60 minutes after they are added to the queue. 

In the meantime if you delete or ban the user account the notifications would be automatically deleted from the queue. Tying the notification delay to our existing permission sets would allow you to still ensure notifications from trusted members are still sent without any delay. 

I would envision a new "Restrictions" section when adding or editing permission sets with the following example options...

Allow a maximum of X posts per X minute(s)
Allow a maximum of X posts per X hour(s)
Allow a maximum of X posts per X day(s)
Delay email notifications for X minute(s)

If X = 0 then no restriction would be applied. 

Would you like to see any additional restrictions on this list Steve?

To also help with your example scenario and Sarah receiving hundreds of individual subscription emails we are planning to introduce a new daily and weekly digest option in the coming releases. When subscribing to forums we'll provide a few options (immediate notification, daily digest & weekly digest). We'll also be adding a seperate way for assigned moderators to be informed of new posts within unmoderated forums without having to subscribe to the forum. 

Thanks again for all your feedback Steve. I look forward to hearing from you and working with you further to refine these requirements.


Kindest Regards,

Ryan Healey



ryan@instantasp.co.uk
www.instantasp.co.uk
Blog | Community | Docs

   

Thanks for the note Ryan. At first glance, this seems like a way that could limit the impact of automated SPAM.  I'll think about it more, but it seems that a delay that allows the spam checkers to catch up would be helpful.

Daily/Weekly digests would be fantastic.


Steve Jones

www.sqlservercentral.com