I am not sure exactly how to address this and if it can be done as as module or if it should be a feature that should be tweaked in the src code of the ircd.

Problem:
If a user has +T the user will not receive ctcps. This includes version.
Knowing what client uses is needed and useful for the network admins in order to troubleshoot all sorts of problems such as malicious activities.

When a user connects he can set /umode +T automatically and then no one in ircd can get his reply.
However the umode only kicks in right after the ircd check for the client version

How come there are no ircops snomasks that allow the admins to see the version reply while a client is using +T?
The reply sent to the IRCd should be available to the ircops or at least admins with specific snomask and or available feature.

The reply the client sends to the ircd could also/or be outputted in the services and or log channel if no module is possible.

I have looked for info in the logs and nothing.
Some extra services such as stats services do this and provide the information.

A module to do this should be possible. Whats your feedback ?

Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We should not be living in 1990s irc management & developing standards just because it was cool.

Well, you may have already seen it cross your RSS bot, but I wrote a quick and (sort of) dirty module that should do the trick. It simply allows opers to do CTCPs even if the target has umode +T set. =]

I just tested the module and it is great to see it works but there is one detail. It requires that the oper is -T in order to receive the reply.
It would be perfect if the oper was able to maintain +T and still receive the ctcp reply from the client.

Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We should not be living in 1990s irc management & developing standards just because it was cool.

Should be fixed now, but it uses an additional ModData slot so you may run into certain issues. ;] Basically, once an oper initiates a CTCP it adds an "override" for the reply. So when that arrives it's allowed anyways. Also, oper2oper CTCPs get special treatment in that they're always allowed.

Some good news:
- certain known issues did not happen
- oper2oper CTCP works when both opers are +T
- When doing mode user -T this problem does not happen. However it still conflicts with it in a very special way which i will describe later.

Bad news:
oper to user with +T or -T does not work.

Notes:
Not using texshun at the moment of these results
When testing oper to user, always reconnect the user and oper from fresh connection. Not doing so in my case messed up accurate results.

Clients used:
irssi and weechat

Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We should not be living in 1990s irc management & developing standards just because it was cool.

I'm guessing these users are on a different server than the oper? I had that problem too and noticed my make script on my third dev server didn't quite do make install. :D So, can you make sure the module is in fact installed, loaded and up to date on all servers? Because on my end, this works:

Oper -T => local user -T

Oper -T => local user +T

Oper +T => local user -T

Oper +T => local user +T

Oper -T => remote user -T

Oper -T => remote user +T

Oper +T => remote user -T

Oper +T => remote user +T

Servers on both ends have to do some magic, so if the mod is missing or out of date on one, sending to remote users will be a bit glitchy.