View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001586 | unreal | ircd | public | 2004-02-24 11:42 | 2004-02-25 16:47 |
| Reporter | Fury | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0001586: channel spamfilter exempt | ||||
| Description | I thought i saw a simular report for this but i cant find it anymore or i totally oversee it, so ill ask anyways :) A possibillity to set a channel so it isnt affected by spamfilter. We have a help/admin room where users report spam messages. After report we add the spam to the spamfilter. When an other user comes in to report that same spam he gets glined, as he cant know that the spam is already added to the list I know we can take an x amount of time before adding it to the list ..so lagging.afk/away users have some time to report but i think it more secure to set for example a channel #report so it doesnt gline/kill/whatever ..when a user comes in to report a spam thats just been added The poor user doesnt know its been added already..hence pastes the spam and gets glined. If this is a duplicate feature requet or u say NO, u can close this one :) its not a big deal, just thought it would be handy | ||||
| 3rd party modules | |||||
|
|
yeah we have been thinking about it before... so the idea is good ;p. perhaps a simple set::spamfilter::except-chans edited on: 2004-02-24 11:57 |
|
|
If this could be done that would be verry helpfull indeed....thanks syzop :) (Hope u add it and not just think about it :P)...um whistle :) |
|
|
well unreal is currently a RC (release candicate) which should mean we don't add new features to it. However, we are breaking these rules a bit between RC1<->RC2, so... |
|
|
I guess the set::spamfilter::except-chans directive shouldn't be counted totally as a new feature, but rather a supplementary option to an existing feature to prevent a security issue. As I saw from Fury's words, support for exceptions is important this time. I would consider it, too. (Just my thoughts.) |
|
|
Only problem I see with such a suggestion is... where do we draw the line? Consider a similar scenarios: We have a virus scanning bot that we tell our users to DCC suspicious files to to check if they are safe. We need a way to exclude this bot from spamfilter. We have a #nohack type channel that we tell people to privmsg the ops the spam text they receive so we can find out the problem. The ops of #nohack must be exempt from spamfilter. We have a channel where users are allowed to display advertisements in onjoin messages, we want it so that if a user is in this channel they are allowed to send these messages to other users who are in the channel. We have $decode( blocked to try and prevent mIRC viruses, however in #mirc that should be allowed sonce someone might be asking for help. Therefore, people in #mirc should be allowed to be exempt from $decode( but everything else should apply. Examples abound. I see no way to really implement exceptions without starting down the path to adding things like those mentioned above. And to AngryWolf, yeah you're right it is just an "enhancement" not a "new feature" however, regardless of what it is called, it has the potential of introducing new bugs. That's what we're trying to prevent. |
|
|
- Added spamfilter::except which allows you to specify targets (eg: channels) where spamfilter should not take action. Requested by Fury (0001586). Ex: set { spamfilter { except "#spamreport,#help"; }; }; as you can see... a "simple except thingy" (at least for now)... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-02-24 11:42 | Fury | New Issue | |
| 2004-02-24 11:54 | syzop | Note Added: 0005175 | |
| 2004-02-24 11:57 | syzop | Note Edited: 0005175 | |
| 2004-02-24 12:03 | Fury | Note Added: 0005176 | |
| 2004-02-24 12:12 | syzop | Note Added: 0005177 | |
| 2004-02-24 16:45 | AngryWolf | Note Added: 0005181 | |
| 2004-02-24 16:58 |
|
Note Added: 0005184 | |
| 2004-02-25 16:47 | syzop | Status | new => closed |
| 2004-02-25 16:47 | syzop | Note Added: 0005208 |
