View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002625 | unreal | ircd | public | 2005-08-23 21:04 | 2007-04-27 04:35 |
| Reporter | Name141 | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | Linux | OS Version | 2.96-110 | ||
| Product Version | 3.2.3 | ||||
| Summary | 0002625: Spamfilter "test" option request | ||||
| Description | I'd like for a spamfilter "test" be added, so this way you don't ban everyone if the regex is bad. The test should include all possible things, cpnNPqdatu. By test I mean, it'll show what matches 1 time, and stop till new matches are met. Such as: (cows\-\d{5})!.+@.+:\1 added as a 'u' , would show cow-12345 (and of course the real name matching), and not do anything about it. Giving the NA the option of seeing what the spamfilter will really do, before he or she adds it. Thus stopping people from banning all the users on a bad typo, or anything else. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
This sounds like aquanights "warn" option... |
|
|
Has the added problem of being a super easy way to spy.. |
|
|
well, given that, block would also work as a 'spy' , and perhaps it could do the same thing as a 'block' . echoing "spamfilter test: you just matched a spamfilter test and the NA's have been notified of it!" to settle down that "spyness". Either way, there needs to be some way of seeing what the regex does before added to the real options. |
|
|
I like this idea, and there are 2 way I know of to keep people from using it to spy: - DO what Name141 said, and have it send a notice to the user and have it say something like "Opers have been notified of your last message for the following reason: spamfilter reason here" - Block broad regexes. Also, instead of having it be implimented as "test", I would like it as aquanights old "warn" option, because that makes more sense. |
|
|
What was this 'warn' option? And I think there already is some blocks on broad regex's. |
|
|
Yes... I too am curious as to where exactly I mentioned it on this bugtracker... (seeing as I don't remember) |
|
|
I am not entirely sure you mentioned it here, but you mentioned somewhere implimenting a spamfilter that would tell opers someone sent a message that matched a spamfilter. Such an option could be used for matching possibly abusive lines (like if someone did not mind server spam, but wanted to monitor/limit it, the spamfilter would tell them how often it is being used, but not block the messages). |
|
|
i like this idea as well, althou i think it should be implented as 'monitor' - also sending them a message im not so sure about, in the end all the opers who have the SNOmask will see the regex notice anyway, so its not as thou its only " 1 or two " opers. i think its pointless sending them a message to say " you matched a regex on the same filter, the netadmin have been notified of this " and it still sends, that to me is more " spying " then the message not being sent at all |
|
|
I was saying to send a notice/msg or something to the users that matched it. So they'd know their msg(s)/mask/whatever have been noticed to the administration. Taking out the ""hidden" spy" mumbo. And I don't care what the name is that's put in. Test/warn/etc.. Just as long their is a way to test before adding. |
|
|
Oh, and I'm sure some people might say block is perfectly sufficient to "debug" a regex, but sometimes - like when doing a user-target spamfilter where block is quite nearly the same as kill - it's better to allow it through anyway (because if there's anything worse than blocking legit text with a malformed regex, it's blocking legit *users*). Denying use of broad regexes might be nice. But how do you determine if it's "broad". "." is certainly broad, as is: .?, .*, ^.*$, ^.?.?.?.?.?.?.?.?.?.?.*$ ^.{0,63}.*$. In a user spamfilter, "!" and "@" and ":" would be matchalls (and maybe "\." depending on if nick!user@ip:real is sent through spamfilter u or not). There are infinite matchall regexes. One cannot catch them all unless you want to put some requirement on regexes that would effectively require you to have your own regex parsing engine. |
|
|
I'd second this, esp for the issue of limiting spam. Sometimes I want to knwo if they're spamming (consider the case of saying it once to a friend or two, vs telling 20 ppl about it after joining random channels and messaging everyone) Sometimes a block is excessive. and some things are _potential_ exploits (for example, some /dns of IP addresses), but aren't always. The ircd has no way of knowing if it is, so we have to block them all. That's not necessarily fair however, as often it's ok/legit. |
|
|
I reccommend you do not target pms with your spamfilter (I'm the same Jason you've reported this to), however, then there is the option of mass-pms. Perhaps warn would be useful. Just notify the user in some obvious way: I dont read my status unless I find some reason to, I would completely miss WARN reasons. |
|
|
So with all this said, what is the process that takes place to see if a warn/test/whatever/putfancynamehere will be added, and without the ability to spy? |
|
|
I'll split this up into 2 things: a 'test' option that will run the spamfilter regex over all the current users that are online and report results, basically this is only meant for target 'u'. The spamfilter will not be actually added, it is only run once. a 'warn' option that will work with any target, and will trigger the usual +s +S notice to opers, but will also send a numeric to the user issueing the command that it has been forwarded to ops or "has been flagged as spamming" or whatever (if possible)... For target 'u' it will also walk trough all users to check a match when it is being added. I think both will be useful. |
|
|
Sounds good, but will there be a module , or will it be intergrated in to the IRCd itself? Just wondering. |
|
|
ircd (cvs / 3.2.4) |
|
|
This was supposed to be in 3.2.4 ? /spamfilter add u test - Proxy_used_by_Blank_to_evade_(tabris 20060211) java@.+:Guest 04:27:54 !hanashi.surrealchat.net Invalid 'action' field (test) 04:27:54 !hanashi.surrealchat.net Use: /spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [tklreason] [regex] 04:27:54 !hanashi.surrealchat.net See '/helpop ?spamfilter' for more information. Warn works tho. |
|
|
Tabrisnet: it was in Unreal3.2.4 but called warn. Test and warn are identical, funcationality-wise. |
|
|
'warn' is in 3.2.4. 'test' did not make it, will be added later. EDIT: Jason: ehm no, 'test' will not be identical to 'warn', see comment of 2005-09-19 15:54 ;). |
|
|
Oops. They are close, and warn can be used as test then :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-08-23 21:04 | Name141 | New Issue | |
| 2005-08-23 21:22 | Stealth | Note Added: 0010384 | |
| 2005-08-24 07:52 | w00t | Note Added: 0010386 | |
| 2005-08-24 13:21 | Name141 | Note Added: 0010387 | |
| 2005-08-24 16:45 | Stealth | Note Added: 0010388 | |
| 2005-08-24 19:23 | Name141 | Note Added: 0010389 | |
| 2005-08-24 19:42 | aquanight | Note Added: 0010390 | |
| 2005-08-25 04:55 | Stealth | Note Added: 0010391 | |
| 2005-08-25 07:36 | White_Magic | Note Added: 0010392 | |
| 2005-08-25 17:26 | Name141 | Note Added: 0010394 | |
| 2005-08-25 18:44 | aquanight | Note Added: 0010395 | |
| 2005-08-27 14:34 | tabrisnet | Note Added: 0010399 | |
| 2005-08-28 15:21 | JasonTik | Note Added: 0010407 | |
| 2005-09-07 12:39 | Name141 | Note Added: 0010448 | |
| 2005-09-19 15:54 | syzop | Note Added: 0010490 | |
| 2005-09-19 16:09 | Name141 | Note Added: 0010491 | |
| 2005-09-19 17:32 | syzop | Note Added: 0010492 | |
| 2006-02-11 04:29 | tabrisnet | Note Added: 0011194 | |
| 2006-02-11 15:55 | JasonTik | Note Added: 0011209 | |
| 2006-02-11 16:01 | syzop | Note Added: 0011210 | |
| 2006-02-11 16:02 | syzop | Note Edited: 0011210 | |
| 2006-02-12 09:40 | JasonTik | Note Added: 0011216 | |
| 2007-04-27 04:35 |
|
Status | new => resolved |
| 2007-04-27 04:35 |
|
Resolution | open => fixed |
| 2007-04-27 04:35 |
|
Assigned To | => stskeeps |
