View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002003 | unreal | ircd | public | 2004-08-01 23:12 | 2004-08-04 04:28 |
| Reporter | aquanight | Assigned To | |||
| Priority | normal | Severity | trivial | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0002003: Channel Mode +C (No CTCPs) does not block CTCP Replies. | ||||
| Description | The summary says it all. A user in a +C channel can still use /ctcpreply (or whatever the client's version of it is :P ) on the channel. CTCP Replies could indeed be blocked using +T, however, I think +C should block both forms of CTCPing a channel. A client should only reply to CTCPs in private, not to a channel... | ||||
| Steps To Reproduce | Join a channel. Set +C, then connect a clone. Have the clone do /ctcpreply #channel PING 1 (for mIRC), then look at the status/active window in your client :) . | ||||
| Additional Information | As I said, "PONG"ing a channel is kinda meaningless... so +C should block it as well :) . | ||||
| 3rd party modules | |||||
|
|
Umm, why? I don't quite see the point of this. |
|
|
O.o I stand corrected... After telnetting a bit, I found that ctcpreplies are ALREADY blocked! However, I received no numeric stating that this occured... |
|
|
Guess this can be closed then. > After telnetting a bit, I found that ctcpreplies are ALREADY blocked! > However, I received no numeric stating that this occured... Funny, seeing you in 0001769 being so in favor of that ;). a CTCP REPLY is a notice, and as you said... error replies should not be sent for notices.. great, isn't it? |
