4 ``+a``, server administrator
5 ----------------------------
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.
14 .. note:: This is a user umode, which anybody can set. It is not
15 specific to operators.
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.
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.
29 .. note:: This is a user umode, which anybody can set. It is not
30 specific to operators.
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.
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.
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``.
48 .. note:: This is a user umode, which anybody can set. It is not
49 specific to operators.
51 Invisible users do not show up in ``WHO`` and ``NAMES`` unless you can see them.
53 ``+l``, receive locops
54 ----------------------
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
60 Unlike ``OPERWALL``, any oper can send and receive ``LOCOPS``.
65 This indicates global operator status.
67 ``+Q``, disable forwarding
68 --------------------------
70 .. note:: This is a user umode, which anybody can set. It is not
71 specific to operators.
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.
77 ``+R``, reject messages from unauthenticated users
78 --------------------------------------------------
80 .. note:: This is a user umode, which anybody can set. It is not
81 specific to operators.
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.
87 Opers and accepted users (like in ``+g``) are exempt. Unlike ``+g``, the target
88 user is not notified of failed messages.
90 ``+s``, receive server notices
91 ------------------------------
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
97 ``+S``, network service
98 -----------------------
100 .. note:: This umode can only be set by servers named in a service{}
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``.
110 The exact effects of this umode are variable; no user or oper on an
111 actual charybdis server can set it.
113 ``+w``, receive wallops
114 -----------------------
116 .. note:: This is a user umode, which anybody can set. It is not
117 specific to operators.
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
124 ``+z``, receive operwall
125 ------------------------
127 ``OPERWALL`` differs from ``WALLOPS`` in that the ability to receive such
128 messages is restricted. Opers with ``+z`` set will receive ``OPERWALL``
134 This umode is set on clients connected via SSL/TLS. It cannot be set or
135 unset after initial connection.
140 Usage is as follows::
142 MODE nick +s +/-flags
150 To clear all snomasks.
152 Umode ``+s`` will be set if at least one snomask is set.
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.
157 Meanings of server notice masks
158 ===============================
163 Opers with the ``+b`` snomask set will receive warning messages from the
164 server when potential flooders and spambots are detected.
166 ``+c``, client connections
167 --------------------------
169 Opers who have the ``+c`` snomask set will receive server notices when
170 clients attach to the local server.
172 ``+C``, extended client connection notices
173 ------------------------------------------
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.
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.
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
197 ``+F``, far client connection notices
198 -------------------------------------
200 .. note:: This snomask is only available if the ``sno_farconnect.so``
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.
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.
211 There is no far equivalent of the ``+C`` snomask.
213 ``+k``, server kill notices
214 ---------------------------
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``.
220 ``+n``, nick change notices
221 ---------------------------
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.
227 ``+r``, notices on name rejections
228 ----------------------------------
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
234 ``+s``, generic server notices
235 ------------------------------
237 This snomask allows an oper to receive generic server notices. This
238 includes kills from opers (except services).
240 ``+u``, unauthorized connections
241 --------------------------------
243 This snomask allows an oper to see when users try to connect who do not
244 have an available auth{} block.
246 ``+W``, whois notifications
247 ---------------------------
249 .. note:: This snomask is only available if the ``sno_whois.so``
252 Opers with ``+W`` receive notices when a ``WHOIS`` is executed on them on their
253 server (showing idle time).
255 ``+x``, extra routing notices
256 -----------------------------
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.
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.
270 ``+Z``, operspy notices
271 -----------------------
273 Opers with ``+Z`` receive notices whenever an oper anywhere on the network
276 This snomask can be configured to be only effective for admins.