It seems that a CTCP NOTICE message to a channel, such as a KVIrc user changing their avatar, is treated the same as if it were a PRIVMSG, so ZNC is sending a configured response if there is one and not passing it on to the client. This seems to be erroneous: the NOTICE message should not be replied to automatically like this.
It seems that a CTCP `NOTICE` message to a channel, such as a KVIrc user changing their avatar, is treated the same as if it were a `PRIVMSG`, so ZNC is sending a configured response if there is one and not passing it on to the client. This seems to be erroneous: the `NOTICE` message should not be replied to automatically like this.
https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/IRCSock.cpp#L428-L434
(For normal private CTCP messages, the following lines deal with `NOTICE` replies:)
https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/IRCSock.cpp#L420-L422
<!-- github-sync-id:393759157 -->
Once upon a time, this worked fine. This must be a regression that was introduced by the `CMessage` "stuff". This handles both `PRIVMSG` CTCPs and `NOTICE` CTCPs as being of type `CTCP`. I guess the right fix would be to introduce a `CTCPReply` type here...
https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/Message.cpp#L226-L240
<!-- github-comment-id:449653667 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
It seems that a CTCP
NOTICEmessage to a channel, such as a KVIrc user changing their avatar, is treated the same as if it were aPRIVMSG, so ZNC is sending a configured response if there is one and not passing it on to the client. This seems to be erroneous: theNOTICEmessage should not be replied to automatically like this.https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/IRCSock.cpp#L428-L434
(For normal private CTCP messages, the following lines deal with
NOTICEreplies:)https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/IRCSock.cpp#L420-L422
Once upon a time, this worked fine. This must be a regression that was introduced by the
CMessage"stuff". This handles bothPRIVMSGCTCPs andNOTICECTCPs as being of typeCTCP. I guess the right fix would be to introduce aCTCPReplytype here...https://github.com/znc/znc/blob/b52fecc42d5c1d354c55d0c90eecd49051d4ab34/src/Message.cpp#L226-L240