doc/oper-guide/umodes.rst

   1 User modes
   2 ==========
   3
   4 ``+a``, server administrator
   5 ----------------------------
   6
   7 This vanity usermode is used to denote a server administrator in WHOIS
   8 output. All local “admin” privileges are independent of it, though
   9 services packages may grant extra privileges to ``+a`` users.
  10
  11 ``+D``, deaf
  12 ------------
  13
  14 .. note:: This is a user umode, which anybody can set. It is not
  15           specific to operators.
  16
  17 Users with the ``+D`` umode set will not receive messages sent to channels.
  18 Joins, parts, topic changes, mode changes, etc are received as normal,
  19 as are private messages.
  20
  21 Support of this umode is indicated by the ``DEAF`` token in ``RPL_ISUPPORT``
  22 (005); the parameter indicates the letter of the umode. Note that
  23 several common IRCD implementations have an umode like this (typically
  24 ``+d``) but do not have the token in 005.
  25
  26 ``+g``, Caller ID
  27 -----------------
  28
  29 .. note:: This is a user umode, which anybody can set. It is not
  30     specific to operators.
  31
  32 Users with the ``+g`` umode set will only receive private messages
  33 from users on a session-defined whitelist, defined by the ``/accept``
  34 command. If a user who is not on the whitelist attempts to send a
  35 private message, the target user will receive a rate-limited notice
  36 saying that the user wishes to speak to them.
  37
  38 Network operators are not affected by the callerid whitelist system in
  39 the event that they need to speak to users who have it enabled.
  40
  41 Support of this umode is indicated by the ``CALLERID`` token in
  42 ``RPL_ISUPPORT`` (005); the optional parameter indicates the letter of
  43 the umode, otherwise ``+g``.
  44
  45 ``+i``, invisible
  46 -----------------
  47
  48 .. note:: This is a user umode, which anybody can set. It is not
  49           specific to operators.
  50
  51 Invisible users do not show up in ``WHO`` and ``NAMES`` unless you can see them.
  52
  53 ``+l``, receive locops
  54 ----------------------
  55
  56 ``LOCOPS`` is a version of ``OPERWALL`` that is sent to opers on a single server
  57 only. With cluster{} and shared{} blocks they can optionally be
  58 propagated further.
  59
  60 Unlike ``OPERWALL``, any oper can send and receive ``LOCOPS``.
  61
  62 ``+o``, operator
  63 ----------------
  64
  65 This indicates global operator status.
  66
  67 ``+Q``, disable forwarding
  68 --------------------------
  69
  70 .. note:: This is a user umode, which anybody can set. It is not
  71           specific to operators.
  72
  73 This umode prevents you from being affected by channel forwarding. If
  74 enabled on a channel, channel forwarding sends you to another channel if
  75 you could not join. See channel mode ``+f`` for more information.
  76
  77 ``+R``, reject messages from unauthenticated users
  78 --------------------------------------------------
  79
  80 .. note:: This is a user umode, which anybody can set. It is not
  81           specific to operators.
  82
  83 If a user has the ``+R`` umode set, then any users who are not authenticated
  84 will receive an error message if they attempt to send a private message
  85 or notice to the ``+R`` user.
  86
  87 Opers and accepted users (like in ``+g``) are exempt. Unlike ``+g``, the target
  88 user is not notified of failed messages.
  89
  90 ``+s``, receive server notices
  91 ------------------------------
  92
  93 This umode allows an oper to receive server notices. The requested types
  94 of server notices are specified as a parameter (“snomask”) to this
  95 umode.
  96
  97 ``+S``, network service
  98 -----------------------
  99
 100 .. note:: This umode can only be set by servers named in a service{}
 101           block.
 102
 103 This umode grants various features useful for services. For example,
 104 clients with this umode cannot be kicked or deopped on channels, can
 105 send to any channel, do not show channels in ``WHOIS``, can be the target of
 106 services aliases and do not appear in ``/stats p``. No server notices are
 107 sent for hostname changes by services clients; server notices about
 108 kills are sent to snomask ``+k`` instead of ``+s``.
 109
 110 The exact effects of this umode are variable; no user or oper on an
 111 actual charybdis server can set it.
 112
 113 ``+w``, receive wallops
 114 -----------------------
 115
 116 .. note:: This is a user umode, which anybody can set. It is not
 117           specific to operators.
 118
 119 Users with the ``+w`` umode set will receive ``WALLOPS`` messages sent by opers.
 120 Opers with ``+w`` additionally receive ``WALLOPS`` sent by servers (e.g. remote
 121 ``CONNECT``, remote ``SQUIT``, various severe misconfigurations, many services
 122 packages).
 123
 124 ``+z``, receive operwall
 125 ------------------------
 126
 127 ``OPERWALL`` differs from ``WALLOPS`` in that the ability to receive such
 128 messages is restricted. Opers with ``+z`` set will receive ``OPERWALL``
 129 messages.
 130
 131 ``+Z``, SSL user
 132 ----------------
 133
 134 This umode is set on clients connected via SSL/TLS. It cannot be set or
 135 unset after initial connection.
 136
 137 Snomask usage
 138 =============
 139
 140 Usage is as follows::
 141
 142   MODE nick +s +/-flags
 143
 144 To set snomasks.
 145
 146 ::
 147
 148    MODE nick -s
 149
 150 To clear all snomasks.
 151
 152 Umode ``+s`` will be set if at least one snomask is set.
 153
 154 Umode ``+s`` is oper only by default, but even if you allow nonopers to set
 155 it, they will not get any server notices.
 156
 157 Meanings of server notice masks
 158 ===============================
 159
 160 ``+b``, bot warnings
 161 --------------------
 162
 163 Opers with the ``+b`` snomask set will receive warning messages from the
 164 server when potential flooders and spambots are detected.
 165
 166 ``+c``, client connections
 167 --------------------------
 168
 169 Opers who have the ``+c`` snomask set will receive server notices when
 170 clients attach to the local server.
 171
 172 ``+C``, extended client connection notices
 173 ------------------------------------------
 174
 175 Opers who have the ``+C`` snomask set will receive server notices when
 176 clients attach to the local server. Unlike the ``+c`` snomask, the
 177 information is displayed in a format intended to be parsed by scripts,
 178 and includes the two unused fields of the ``USER`` command.
 179
 180 ``+d``, debug
 181 -------------
 182
 183 The ``+d`` snomask provides opers extra information which may be of interest
 184 to debuggers. It will also cause the user to receive server notices if
 185 certain assertions fail inside the server. Its precise meaning is
 186 variable. Do not depend on the effects of this snomask as they can and
 187 will change without notice in later revisions.
 188
 189 ``+f``, full warning
 190 --------------------
 191
 192 Opers with the ``+f`` snomask set will receive notices when a user
 193 connection is denied because a connection limit is exceeded (one of the
 194 limits in a class{} block, or the total per-server limit settable with
 195 ``/quote set max``).
 196
 197 ``+F``, far client connection notices
 198 -------------------------------------
 199
 200 .. note:: This snomask is only available if the ``sno_farconnect.so``
 201           extension is loaded.
 202
 203 Opers with ``+F`` receive server notices when clients connect or disconnect
 204 on other servers. The notices have the same format as those from the ``+c``
 205 snomask, except that the class is ? and the source server of the notice
 206 is the server the user is/was on.
 207
 208 No notices are generated for netsplits and netjoins. Hence, these
 209 notices cannot be used to keep track of all clients on the network.
 210
 211 There is no far equivalent of the ``+C`` snomask.
 212
 213 ``+k``, server kill notices
 214 ---------------------------
 215
 216 Opers with the ``+k`` snomask set will receive server notices when services
 217 kill users and when other servers kill and save (forced nick change to
 218 UID) users. Kills and saves by this server are on ``+d`` or ``+s``.
 219
 220 ``+n``, nick change notices
 221 ---------------------------
 222
 223 An oper with ``+n`` set will receive a server notice every time a local user
 224 changes their nick, giving the old and new nicks. This is mostly useful
 225 for bots that track all users on a single server.
 226
 227 ``+r``, notices on name rejections
 228 ----------------------------------
 229
 230 Opers with this snomask set will receive a server notice when somebody
 231 tries to use an invalid username, or if a dumb HTTP proxy tries to
 232 connect.
 233
 234 ``+s``, generic server notices
 235 ------------------------------
 236
 237 This snomask allows an oper to receive generic server notices. This
 238 includes kills from opers (except services).
 239
 240 ``+u``, unauthorized connections
 241 --------------------------------
 242
 243 This snomask allows an oper to see when users try to connect who do not
 244 have an available auth{} block.
 245
 246 ``+W``, whois notifications
 247 ---------------------------
 248
 249 .. note:: This snomask is only available if the ``sno_whois.so``
 250           extension is loaded.
 251
 252 Opers with ``+W`` receive notices when a ``WHOIS`` is executed on them on their
 253 server (showing idle time).
 254
 255 ``+x``, extra routing notices
 256 -----------------------------
 257
 258 Opers who have the ``+x`` snomask set will get notices about servers
 259 connecting and disconnecting on the whole network. This includes all
 260 servers connected behind the affected link. This can get rather noisy
 261 but is useful for keeping track of all linked servers.
 262
 263 ``+y``, spy
 264 -----------
 265
 266 Opers with ``+y`` receive notices when users try to join ``RESV``'ed (“juped”)
 267 channels. Additionally, if certain extension modules are loaded, they
 268 will receive notices when special commands are used.
 269
 270 ``+Z``, operspy notices
 271 -----------------------
 272
 273 Opers with ``+Z`` receive notices whenever an oper anywhere on the network
 274 uses operspy.
 275
 276 This snomask can be configured to be only effective for admins.