Not only that, I think using RDBM will have a drastical impact on the performance. Not only it'll slow down a connecting client but it will also need more resources than now. And we should not forget about drones/botnets as well. I too agree with Vin King and would not think that /reportspam would be a good idea. We can't even follow a general rule which is to join #operhelp for IRCOp assistance but join their private channels, how can we make proper use of /reportspam :P. Nevertheless saying, that's my personal opinion.

Regards,

White`Shark.

On Fri, May 1, 2009 at 11:22 AM, Vin King <vin.king@gmail.com> wrote:

So what happens then if you're afk for a few minutes, come back, have received spam in the meantime, and then /reportspam? Also, since all traffic to channels is privmsg, would that open anyone chatting in a channel up for reports? What if a user happens to just post a lot of http:// links, like stuff from 4chan? I don't particularly see this being an effective methodology, and technically much more prone to being designed wrong than +C.

On Thu, Apr 30, 2009 at 9:03 PM, James Hess <mysidia@gmail.com> wrote:
> It would be easier but there are a lot of users who don't have a registered
> nick and probably don't want one either. They just want to chat and we
> shouldn't take that away from them.
> -Kobi_S.

Yes, and they have friends to who they may want to talk with. Blocking
those messages by default may hurt a lot of people. I suggest making a
+S mode for spamfilter. Which will block messages based on a list
of flexible criteria, and based on the user's "history", i.e.
reputation of their ip address.

The problem is this reputation can't merely be stored on one server,
all servers need immediate access to it; it needs to apply to all the
IP address' IRC sessions, and needs to persist, even if they reconnect
(otherwise spammers will /reconnect to reset their reputation).

And exempt registered, identified users get excluded from being blocked
based on 'reputation'. A database of IP addresses should be held on
the servers to reflect on the "reputation" of a non-registered
user's IP.

I suggest a RDBM be used here. When a user connects, IRCD makes an
asynchronous DB request for the IP address's "reputation" data;
which is then cached somewhere in their user structure and re-synced
at random (but long) intervals.

As long as their IRC session is still open there should be a 'session'
entry in the database, and a separate "persistent" entry. When an
IRC session is closed, and at prescribed intervals, the "persistent"
entry is updated and session stats are cleared.
The user's stats at any moment are the sum of all 'session' stats and
the persistent stats.

DB Performance would need careful consideration.
Possible elements of reputation score:

x How old is the reputation info? (old info is meaningless)
x How many total private /MSG commands has the IP issued in the past 72 hours?
x How many did they receive from users of high reputation (and
identified users), and what's the SENT:RECEIVED ratio? (People that
get a lot of messages are conversing, not spamming)
x Other commands to track usage on: private /NOTICE, /JOIN, /INVITE
x After removal of color codes and non-printables:
x How many /MSGs did the user send that contain "http://" in them?
x How many /MSGs did the user send that contain "//" in them?
x How many /MSGs did the user send that contain "/eval" in them?
x How many /MSGs did the user send that contain "/join" in them?
x How many /MSGs did the user send that contain "/server" in them?
x How many /MSGs did the user send that were blocked?

I suggest adding a /REPORTSPAM <nick>
command which increments a "spam reported" reputation counter
and effects their reputation score.

But if the target has not sent a private /MSG/NOTICE/INVITE in the
past 2 minutes, or
recipient had not received a private /MSG/NOTICE/INVITE from anyone
since their last
/REPORTSPAM, the reporter's reputation is penalized with a "bad
report" count (negating all further spam reports from the ip for 24
hours).

--
-J
_______________________________________________
DALnet-src mailing list
DALnet-src@lists.dal.net
https://lists.dal.net/mailman/listinfo/dalnet-src

_______________________________________________
DALnet-src mailing list
DALnet-src@lists.dal.net
https://lists.dal.net/mailman/listinfo/dalnet-src