4 <title>Meanings of user modes</title>
6 <title>+a, server administrator</title>
8 This vanity usermode is used to denote a server administrator in WHOIS output.
9 All local <quote>admin</quote> privileges are independent of it, though services
10 packages may grant extra privileges to +a users.
14 <title>+D, deaf</title>
18 This is a user umode, which anybody can set. It is not specific to operators.
21 Users with the +D umode set will not receive messages sent to
22 channels. Joins, parts, topic changes, mode changes, etc are
23 received as normal, as are private messages.
26 Support of this umode is indicated by the DEAF token in
27 RPL_ISUPPORT (005); the parameter indicates the letter
28 of the umode. Note that several common IRCD implementations have
29 an umode like this (typically +d) but do not have the token in 005.
33 <title>+g, Caller ID</title>
37 This is a user umode, which anybody can set. It is not specific to operators.
40 Users with the +g umode set will only receive private messages from users on a
41 session-defined whitelist, defined by the /accept command. If a user who is not
42 on the whitelist attempts to send a private message, the target user will receive a rate-limited notice saying that the user
43 wishes to speak to them.
46 Network operators are not affected by the callerid whitelist system in the event
47 that they need to speak to users who have it enabled.
50 Support of this umode is indicated by the CALLERID token in
51 RPL_ISUPPORT (005); the optional parameter indicates the letter
52 of the umode, otherwise +g.
56 <title>+i, invisible</title>
60 This is a user umode, which anybody can set. It is not specific to operators.
63 Invisible users do not show up in WHO and NAMES unless you can see them.
66 <!-- not planned (jilles)
68 <title>+I, refuse invite</title>
72 This is a user umode, which anybody can set. It is not specific to operators.
75 If you have the +I umode set, nobody will be able to issue an INVITE to let you
79 This mode is not yet implemented. It will be implemented in Charybdis 1.1.
84 <title>+l, receive locops</title>
86 LOCOPS is a version of OPERWALL that is sent to opers on a single
87 server only. With cluster{} and shared{} blocks they can optionally
88 be propagated further.
91 Unlike OPERWALL, any oper can send and receive LOCOPS.
95 <title>+o, operator</title>
97 This indicates global operator status.
101 <title>+Q, disable forwarding</title>
105 This is a user umode, which anybody can set. It is not specific to operators.
108 This umode prevents you from being affected by channel forwarding.
109 If enabled on a channel, channel forwarding sends you to another
110 channel if you could not join. See channel mode +f for more
115 <title>+R, reject messages from unauthenticated users</title>
119 This is a user umode, which anybody can set. It is not specific to operators.
122 If a user has the +R umode set, then any users who are not authenticated
123 will receive an error message if they attempt to send a private
124 message or notice to the +R user.
127 Opers and accepted users (like in +g) are exempt.
128 Unlike +g, the target user is not notified of failed messages.
132 <title>+s, receive server notices</title>
134 This umode allows an oper to receive server notices.
135 The requested types of server notices are specified as a
136 parameter (<quote>snomask</quote>) to this umode.
140 <title>+S, network service</title>
144 This umode can only be set by servers named in a service{}
148 This umode grants various features useful for services. For example,
149 clients with this umode cannot be kicked or deopped on channels,
150 do not show channels the querying user is not on in WHOIS,
151 and do not appear in /stats p.
154 The exact effects of this umode are variable; no user or oper on
155 an actual charybdis server can set it.
159 <title>+w, receive wallops</title>
163 This is a user umode, which anybody can set. It is not specific to operators.
166 Users with the +w umode set will receive WALLOPS messages sent by opers.
167 Opers with +w additionally receive WALLOPS sent by servers (e.g.
168 remote CONNECT, remote SQUIT, various severe misconfigurations,
169 many services packages).
173 <title>+z, receive operwall</title>
175 OPERWALL differs from WALLOPS in that the ability to receive such messages is
176 restricted. Opers with +z set will receive OPERWALL messages.
180 <title>+Z, SSL user</title>
182 This umode is set on clients connected via SSL/TLS.
183 It cannot be set or unset after initial connection.
187 <sect1 id="snomaskusage">
188 <title>Snomask usage</title>
192 <cmdsynopsis><command>MODE</command>
193 <arg choice=plain><replaceable>nick</replaceable></arg>
194 <arg choice=plain>+s</arg>
195 <arg choice=plain><replaceable>+/-flags</replaceable></arg>
200 <cmdsynopsis><command>MODE</command>
201 <arg choice=plain><replaceable>nick</replaceable></arg>
202 <arg choice=plain>-s</arg>
205 To clear all snomasks.
208 Umode +s will be set if at least one snomask is set.
211 Umode +s is oper only by default, but even if you allow nonopers to
212 set it, they will not get any server notices.
215 <sect1 id="snomasklist">
216 <title>Meanings of server notice masks</title>
218 <title>+b, bot warnings</title>
220 Opers with the +b snomask set will receive warning messages from the server when potential
221 flooders and spambots are detected.
225 <title>+c, client connections</title>
227 Opers who have the +c snomask set will receive server notices when clients attach to the
232 <title>+C, extended client connection notices</title>
234 Opers who have the +C snomask set will receive server notices when clients attach to the
235 local server. Unlike the +c snomask, the information is displayed in a format intended
236 to be parsed by scripts, and includes the two unused fields of the USER command.
240 <title>+d, debug</title>
242 The +d snomask provides opers extra information which may be of interest to debuggers.
243 It will also cause the user to receive server notices if certain assertions fail inside the
244 server. Its precise meaning is variable. Do not depend on the
245 effects of this snomask as they can and will change without notice in later revisions.
249 <title>+f, full warning</title>
251 Opers with the +f snomask set will receive notices when a user
252 connection is denied because a connection limit is exceeded
253 (one of the limits in a class{} block, or the total per-server
254 limit settable with /quote set max).
258 <title>+F, far client connection notices</title>
262 This snomask is only available if the <filename>sno_farconnect.so</filename> extension is loaded.
265 Opers with +F receive server notices when clients connect or
266 disconnect on other servers. The notices have the same format
267 as those from the +c snomask, except that the class is ? and
268 the source server of the notice is the server the user is/was on.
271 No notices are generated for netsplits and netjoins.
272 Hence, these notices cannot be used to keep track of all
273 clients on the network.
276 There is no far equivalent of the +C snomask.
280 <title>+k, server kill notices</title>
282 Opers with the +k snomask set will receive server notices when
283 services kill users and when
284 other servers kill and save (forced nick change to UID) users.
285 Kills and saves by this server are on +d or +s.
289 <title>+n, nick change notices</title>
291 An oper with +n set will receive a server notice every time a local user changes their nick,
292 giving the old and new nicks.
293 This is mostly useful for bots that track all users on a single server.
297 <title>+r, notices on name rejections</title>
299 Opers with this snomask set will receive a server notice when somebody tries to use an
300 invalid username, or if a dumb HTTP proxy tries to connect.
304 <title>+s, generic server notices</title>
306 This snomask allows an oper to receive generic server notices.
307 This includes kills from opers (except services).
311 <title>+u, unauthorized connections</title>
313 This snomask allows an oper to see when users try to connect who do not have an
314 available auth{} block.
318 <title>+W, whois notifications</title>
322 This snomask is only available if the <filename>sno_whois.so</filename> extension is loaded.
325 Opers with +W receive notices when a WHOIS is executed on them
326 on their server (showing idle time).
330 <title>+x, extra routing notices</title>
332 Opers who have the +x snomask set will get notices about servers
333 connecting and disconnecting on the whole network. This includes
334 all servers connected behind the affected link. This can get
335 rather noisy but is useful for keeping track of all linked
340 <title>+y, spy</title>
342 Opers with +y receive notices when users try to join RESV'ed (<quote>juped</quote>) channels.
343 Additionally, if certain extension modules are loaded, they will
344 receive notices when special commands are used.
348 <title>+Z, operspy notices</title>
350 Opers with +Z receive notices whenever an oper anywhere on the
351 network uses operspy.
354 This snomask can be configured to be only effective for admins.
359 <!-- Keep this comment at the end of the file
364 sgml-namecase-general:t
365 sgml-general-insert-case:lower
366 sgml-minimize-attributes:nil
367 sgml-always-quote-attributes:t
370 sgml-parent-document: ("charybdis-oper-guide.sgml" "book")
371 sgml-exposed-tags:nil
373 sgml-validate-command: "nsgmls -e -g -s -u charybdis-oper-guide.sgml"