RE: [NeoStats-Devel] Secureserv and non-VERSION ctcp requests

DeadNotBuried wrote:
> With the number of posts on the forums about banning XDCC 
> Ccatcher, bottlers and iroffer, and the number of networks 
> running SecureServ that allow the same, i had the following 
> thought to hopefully satisfy both camps.
> 
> if we add a CTCP request list which is empty by default, and 
> as items are added (eg. LAG for XDCC catcher) SecureServ 
> would send that request to each client connecting, and if it 
> received a reply for that request it would automatically 
> akill the client. or as an option for each request a warning 
> could be sent, or a kill instead of an akill.
> 
> having it as a list would allow any extra replies that might 
> crop up in the future to be added as well. setting it as 
> default to be disbaled would keep things as they currently 
> are, and those networks that want the extra function could use it.
> 
> thoughts ?

Why they feel the need to fake their version reply and require networks to
use custom extensions to the CTCP protocol to determine the existence of a
small subset of their clients (with the obvious potential for false
positives in such detection) is IMO a statement on the morals of the
creators rather than an appropriate way forward. As such I do not see why we
should mutate SecureServ to account for them.

It would be trivial to create a simple module that could process such CTCP
request/reply scenarios that users wanting such functionality could use.
E.g. AntiCTCPLag which simply sends the required CTCP sequence and processes
the reply accordingly.

Depending on ongoing discussions (rev 2699 thread), the CTCP interface as
designed could be simply and quickly adapted to accommodate support for
unsupported extensions such as this without affecting the majority of the
codebase. 

Now that Justin has some perl support available, I assume the long planned
perl support for SecureServ will follow which would again offer some for of
specific and optional support.

Keeps SecureServ "clean" and optimal rather than trying to create some form
of adhoc support while providing a system for users that want to jump
through the hoops of the creators of P2P over IRC apps.

Remember the most important issue here is that very few of the clients will
actually be caught by the CTCP LAG sequence and you run the risk of false
positives by relying on such claims. It is their attempt to suggest they are
being helpful but their refusal to just provide a fixed CTCP VERSION field
suggests otherwise. Same goes for anything else they publish for a subset of
their clients including the "add this exact string to MOTD" rubbush which
again will only reject a small subset. If you follow all their rules, you
end up with a MOTD which is little more than anti client commands which
looks like it was written by a 4 year old Russian learning English using
only Japanses translations written in Greek and sending various strange CTCP
messages to every user but still do not actually detect the majority.

Many spam messages have offered a "remove" link even before the pathetic
legal requirements to do so. Research has shown it is BS. Until proven
otherwise, I will continue to believe that the steps offered by these client
creators are nothing more than a "spam me more" removal link in that they
are as effective as a chocolate fire guard.

I do not mean to rain on your parade since I know you are trying to find a
solution. I do think the solution is in the module CTCP interface and
encouraging someone to write a simple module rather than us making such a
change to SecureServ. I will not write the module and I am guessing Justin
is equally unlikely to do so for either similar personal concerns or time
constraints. If you wish to, that is fine and I will provide whatever core
support is required for non-standard CTCP protocol messages you might need
since it is something I need to do anyway for both CTCP and the DCC
extensions. If not, the only thing I could say is that our response to
requests becomes write a module that calls the (to be written)
irc_ctcp_unknown_req and processes EVENT_CTCPUNKNOWNRPL or similar interface
to IRC.

Mark.