diff options
Diffstat (limited to 'docs')
24 files changed, 2381 insertions, 10029 deletions
diff --git a/docs/Doxyfile b/docs/Doxyfile index 807020af5..3089a5170 100644 --- a/docs/Doxyfile +++ b/docs/Doxyfile @@ -1,6 +1,6 @@ DOXYFILE_ENCODING = UTF-8 PROJECT_NAME = InspIRCd -PROJECT_NUMBER = 2.0 +PROJECT_NUMBER = 3.0 PROJECT_BRIEF = PROJECT_LOGO = OUTPUT_DIRECTORY = docs/doxygen @@ -93,9 +93,9 @@ EXCLUDE = EXCLUDE_SYMLINKS = YES EXCLUDE_PATTERNS = */.git/* \ */doxygen/* \ - */commands/* \ - */modes/* \ - */modules/* + */coremods/* \ + */modules/* \ + */vendor/* EXCLUDE_SYMBOLS = EXAMPLE_PATH = EXAMPLE_PATTERNS = @@ -219,7 +219,8 @@ EXPAND_ONLY_PREDEF = NO SEARCH_INCLUDES = YES INCLUDE_PATH = INCLUDE_FILE_PATTERNS = -PREDEFINED = +PREDEFINED = CoreExport=/**/ \ + INSPIRCD_INTRUSIVE_LIST_NAME=intrusive_list EXPAND_AS_DEFINED = SKIP_FUNCTION_MACROS = YES TAGFILES = diff --git a/docs/conf/aliases/anope.conf.example b/docs/conf/aliases/anope.conf.example deleted file mode 100644 index 4d1441473..000000000 --- a/docs/conf/aliases/anope.conf.example +++ /dev/null @@ -1,20 +0,0 @@ -# Aliases for nickserv, chanserv, operserv, memoserv, hostserv, botserv -<alias text="NICKSERV" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CHANSERV" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OPERSERV" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="MEMOSERV" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="HOSTSERV" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="BOTSERV" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> - -# Shorthand aliases for nickserv, chanserv, operserv, memoserv, hostserv, botserv -<alias text="NS" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CS" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OS" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="MS" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="HS" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="BS" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> - -# /id [account] <password> -# Identify for a nickname -<alias text="ID" format="*" replace="PRIVMSG NickServ :IDENTIFY $2-" requires="NickServ" uline="yes"> -<alias text="IDENTIFY" format="*" replace="PRIVMSG NickServ :IDENTIFY $2-" requires="NickServ" uline="yes"> diff --git a/docs/conf/aliases/atheme.conf.example b/docs/conf/aliases/atheme.conf.example deleted file mode 100644 index 7a0bc015a..000000000 --- a/docs/conf/aliases/atheme.conf.example +++ /dev/null @@ -1,25 +0,0 @@ -# Aliases for nickserv, chanserv, operserv, memoserv -<alias text="NICKSERV" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CHANSERV" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OPERSERV" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="MEMOSERV" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="GAMESERV" replace="PRIVMSG GameServ :$2-" requires="GameServ" uline="yes"> -<alias text="BOTSERV" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HOSTSERV" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="ALIS" replace="PRIVMSG ALIS :$2-" requires="ALIS" uline="yes"> - -# Shorthand aliases for nickserv, chanserv, operserv, memoserv -<alias text="NS" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CS" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OS" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="MS" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="GS" replace="PRIVMSG GameServ :$2-" requires="GameServ" uline="yes"> -<alias text="BS" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HS" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="LS" replace="PRIVMSG ALIS :$2-" requires="ALIS" uline="yes"> - -# /id [channel] <password> -# Identify for a channel or nickname -<alias text="ID" format="#*" replace="PRIVMSG ChanServ :IDENTIFY $2 $3" requires="ChanServ" uline="yes"> -<alias text="ID" format="*" replace="PRIVMSG NickServ :IDENTIFY $2-" requires="NickServ" uline="yes"> - diff --git a/docs/conf/censor.conf.example b/docs/conf/censor.conf.example deleted file mode 100644 index ea9e08147..000000000 --- a/docs/conf/censor.conf.example +++ /dev/null @@ -1,12 +0,0 @@ -# Configuration file for m_censor.so - -# The tags for this module are formatted as follows: -# -# <badword text="simple word" -# replace="text to replace with"> -# -# You can specify <badword text="simple word" replace=""> -# to block lines containing the word - -<badword text="shit" replace="poo"> -<badword text="fuck" replace="(censored)"> diff --git a/docs/conf/filter.conf.example b/docs/conf/filter.conf.example index 45e5d2853..f9afc85a8 100644 --- a/docs/conf/filter.conf.example +++ b/docs/conf/filter.conf.example @@ -1,4 +1,4 @@ -# Configuration file for m_filter.so +# Configuration file for the filter module # The tags for this module are formatted as follows: # @@ -6,15 +6,18 @@ # reason="reason for filtering" # action="action to take" # flags="filter flags" -# duration="optional length of gline"> +# duration="optional duration of the G-line, Z-line or shun"> # # Valid actions for 'action' are: # +# warn This allows the line and sends out a notice to all opers +# with +s. +# # block This blocks the line, sends out a notice to all opers with # +s and informs the user that their message was blocked. # -# silent This blocks the line only, and informs the user their message -# was blocked, but does not notify opers. +# silent This blocks the line only, and informs the user that their +# message was blocked, but does not notify opers. # # none This action causes nothing to be done except logging. This # is the default action if none is specified. @@ -22,10 +25,21 @@ # kill This disconnects the user, with the 'reason' parameter as # the kill reason. # -# gline G-LINE the user for 'duration' length of time. Durations may -# be specified using the notation 1y2d3h4m6s in a similar way to -# other glines, omitting the duration or setting it to 0 makes -# any glines set by this filter be permanent. +# gline G-line the user for 'duration' length of time. Durations may +# be specified using the notation 1y2w3d4h5m6s in a similar way to +# other G-lines, omitting the duration or setting it to 0 makes +# any G-lines set by this filter be permanent. +# +# zline Z-line the user for 'duration' length of time. Durations may +# be specified using the notation 1y2w3d4h5m6s in a similar way to +# other Z-lines, omitting the duration or setting it to 0 makes +# any Z-lines set by this filter be permanent. +# +# shun Shun the user for 'duration' length of time. Durations may +# be specified using the notation 1y2w3d4h5m6s in a similar way to +# other X-lines, omitting the duration or setting it to 0 makes +# any shuns set by this filter be permanent. +# Requires the shun module to be loaded. # # You can add filters from IRC using the /FILTER command. If you do this, they # will be set globally to your entire network. @@ -40,21 +54,26 @@ # c: Strip color codes from text before trying to match # *: Represents all of the above flags # -: Does nothing, a no-op for when you do not want to specify any flags -# -# IMPORTANT NOTE: Because the InspIRCd config reader places special meaning on the -# '\' character, you must use '\\' if you wish to specify a '\' character in a regular -# expression. For example, to indicate numbers, use \\d and not \d. This does not -# apply when adding a regular expression over irc with the /FILTER command. -# Example filters for m_filter: +# Example filters: # # <keyword pattern="*qwerty*" reason="You qwertied!" action="block" flags="pn"> # <keyword pattern="*killmenow*" reason="As you request." action="kill" flags="*"> -# <keyword pattern="*blah*" reason="Dont blah!" action="gline" duration="1d6h" flags="-"> +# <keyword pattern="*blah*" reason="Don't blah!" action="gline" duration="1d6h" flags="-"> -# An example regexp filter for m_filter_pcre: +# An example regexp filter: # -# <keyword pattern="^blah.*?$" reason="Dont blah!" action="gline" duration="1d6h" flags="pnPq"> +# <keyword pattern="^blah.*?$" reason="Don't blah!" action="gline" duration="1d6h" flags="pnPq"> + +# You may specify specific channels that are exempt from being filtered: +#<exemptfromfilter target="#opers"> +#<exemptfromfilter target="#help"> + +# You can also exempt messages from being filtered if they are sent to +# specific nicks. +# Example that exempts all messages sent *to* NickServ: +#<exemptfromfilter target="NickServ"> -# An example of excluding a channel from filtering: -# <exemptfromfilter channel="#help"> +# Note that messages *from* services are never subject to filtering; +# <exemptfromfilter> tags are only for exempting messages sent *to* the +# configured targets. diff --git a/docs/conf/helpop-full.conf.example b/docs/conf/helpop-full.conf.example deleted file mode 100644 index 959f2249d..000000000 --- a/docs/conf/helpop-full.conf.example +++ /dev/null @@ -1,1101 +0,0 @@ -##################### -# Helpop Standard # -##################### - -<config format="xml"> - -<alias text="HELP" replace="HELPOP $2-"> - -<helpop key="start" value="InspIRCd Help System - -This system provides help for commands and modes. -Specify your question or a command name as the -parameter for this command. - -/HELPOP CUSER - To see a list of user commands -/HELPOP COPER - To see a list of oper commands -/HELPOP UMODES - To see a list of user modes -/HELPOP CHMODES - To see a list of channel modes -/HELPOP SNOMASKS - To see a list of oper snotice masks -/HELPOP EXTBANS - To see a list of extended bans"> - -<helpop key="nohelp" value="There is no help for the topic -you searched for. Please try again."> - -##################### -# User Commands # -##################### - -<helpop key="cuser" value="User Commands -------------- - -PRIVMSG NOTICE NICK JOIN PART -CYCLE KNOCK MODE DEVOICE TOPIC -KICK FPART REMOVE TBAN INVITE -UNINVITE AWAY DCCALLOW SILENCE ACCEPT -MKPASSWD VHOST TITLE SETNAME - -WHOIS WHOWAS ISON USERHOST WATCH -LIST NAMES WHO MOTD RULES -ADMIN MAP LINKS LUSERS TIME -STATS VERSION INFO MODULES COMMANDS -SSLINFO - -USER PASS PING PONG QUIT - -OPER"> - -<helpop key="sslinfo" value="/SSLINFO <nick> - -Displays information on the SSL connection and certificate of the -target user."> - -<helpop key="uninvite" value="/UNINVITE <nick> <channel> - -Uninvite a user from a channel, same syntax as INVITE."> - -<helpop key="tban" value="/TBAN <channel> <duration> <banmask> - -Sets a timed ban. The duration of the ban can be specified in the -following format: 1w2d3h4m6s which indicates a ban of one week, two -days, three hours, four minutes and six seconds. Alternatively the -ban may just be specified as a number of seconds. All timed bans -appear in the banlist as normal bans and may be safely removed -before their time is up."> - -<helpop key="dccallow" value="/DCCALLOW - List allowed nicks -/DCCALLOW LIST - This also lists allowed nicks -/DCCALLOW +<nick> [<duration>] - Add a nick -/DCCALLOW -<nick> - Remove a nick -/DCCALLOW HELP - Display help - -Duration is optional, and may be specified in seconds or in the -form of 1m2h3d4w5y."> - -<helpop key="accept" value="/ACCEPT * - List accepted nicks -/ACCEPT +<nick> - Add a nick -/ACCEPT -<nick> - Remove a nick -This command accepts multiple nicks like so: -/ACCEPT +<nick1>,+<nick2>,-<nick3> - -Manages your accept list. This list is used to determine who can -private message you when you have usermode +g set."> - -<helpop key="cycle" value="/CYCLE <channel> :[<reason>] - -Cycles a channel (leaving and rejoining), overrides restrictions that -would stop a new user joining, such as user limits and channel keys."> - -<helpop key="title" value="/TITLE <name> <password> - -Authenticate for a WHOIS title line and optionally a vhost using the -specified username and password."> - -<helpop key="watch" value="/WATCH - List watched nicks that are online -/WATCH L - List watched nicks, online and offline -/WATCH C - Clear all watched nicks -/WATCH S - Show statistics -/WATCH +<nick> - Add a nick -/WATCH -<nick> - Remove a nick -This command accepts multiple nicks like so: -/WATCH +<nick1> +<nick2> -<nick3>"> - -<helpop key="vhost" value="/VHOST <username> <password> - -Authenticate for a vhost using the specified username and password."> - -<helpop key="remove" value="/REMOVE <nick> <channel> [<reason>] - -Removes a user from a channel you specify. You must be at least a -channel halfoperator to remove a user. A removed user will part with -a message stating they were removed from the channel and by whom."> - -<helpop key="fpart" value="/FPART <channel> <nick> [<reason>] - -This behaves identically to /REMOVE, the only difference is that the -<channel> and <nick> parameters are switched around to match /KICK's -syntax. Also, /REMOVE is a built-in mIRC command which caused trouble -for some users."> - -<helpop key="devoice" value="/DEVOICE <channel> - -Devoices yourself on the specified channel."> - -<helpop key="silence" value="/SILENCE - Shows a list of silenced masks -/SILENCE +<mask> [<flags>] - Add a mask -/SILENCE -<mask> - Remove a mask - -A serverside ignore of the given n!u@h mask. The letter(s) at the end -specify what is to be ignored from this hostmask. - -Valid SILENCE Flags -------------------- - - p Block private messages - c Block channel messages - i Block invites - n Block private notices - t Block channel notices - a Block all of the above - x Exception - -Multiple letters may be specified. For an exception, you must pair x -with what you want excepted. For example, if you wanted to except -everything from people with a host matching *.foo.net, you would do -/SILENCE +*!*@*.foo.net xa - -/SILENCE without a parameter will list the masks that you have silenced."> - -<helpop key="knock" value="/KNOCK <channel> - -Sends a notice to a channel indicating you wish to join."> - -<helpop key="user" value="/USER <ident> <local host> <remote host> :<GECOS> - -This command is used by your client to register your -IRC session, providing your ident and GECOS to the -server. - -You should not use it during an established connection."> - -<helpop key="nick" value="/NICK <new nick> - -Change your nickname to <new nick>."> - -<helpop key="quit" value="/QUIT [<reason>] - -Quit from IRC and end your current session."> - -<helpop key="version" value="/VERSION - -Returns the server's version information."> - -<helpop key="ping" value="/PING <server> - -Ping a server. The server will answer with a PONG."> - -<helpop key="pong" value="/PONG <server> - -Your client should send this to answer server PINGs. You -should not issue this command manually."> - -<helpop key="admin" value="/ADMIN [<server>] - -Shows the administrative information for the given server."> - -<helpop key="privmsg" value="/PRIVMSG <target> <text> - -Sends a message to a user or channel specified in <target>."> - -<helpop key="notice" value="/NOTICE <target> <text> - -Sends a notice to a user or channel specified in <target>."> - -<helpop key="join" value="/JOIN <channel>[,<channel>] [<key>][,<key>] - -Joins one or more channels you provide the names for."> - -<helpop key="names" value="/NAMES <channel>[,<channel>] - -Return a list of users on the channels you provide."> - -<helpop key="part" value="/PART <channel>[,<channel>] [<reason>] - -Leaves one or more channels you specify."> - -<helpop key="kick" value="/KICK <channel> <nick>[,<nick>] [<reason>] - -Kicks a user from a channel you specify. You must be -at least a channel halfoperator to kick a user."> - -<helpop key="mode" value="/MODE <target> (+|-)<modes> [<mode parameters>] - Change modes of <target>. - -/MODE <target> - Show modes of <target>. - -/MODE <channel> <list mode char> - List bans, exceptions, etc. set on <channel>. - -Sets the mode for a channel or a nickname specified in <target>. -A user may only set modes upon themselves, and may not set the -+o usermode, and a user may only change channel modes of -channels where they are at least a halfoperator. - -For a list of all user and channel modes, enter /HELPOP UMODES or -/HELPOP CHMODES."> - -<helpop key="topic" value="/TOPIC <channel> [<topic>] - -Sets or retrieves the channel topic. If a channel topic is -given in the command and either the channel is not +t, or -you are at least a halfoperator, the channel topic will be -changed to the new one you provide."> - -<helpop key="who" value="/WHO <pattern> [afhilMmoprt] - -Looks up the information of users matching the range you provide. - -You may only /WHO nicknames in channels or on servers where you -share a common channel with them, or ones which are not +i (unless -you are a server operator). The search pattern may be a special -sequence of characters determined by the flags given below, or -it may be one of a nickname, a channel, a hostmask, an IP address -mask or a server mask. - -Valid WHO Flags ---------------- - -The following flags use <pattern> to match against the specified user data: - - a Show users who have an away message matching <pattern>. - i Show users who have an ident (username) matching <pattern>. - M Show users who have metadata attached to them with a key name matching - <pattern> (server operators only). - m Show users who have the modes listed in <pattern>. The pattern - should be in the same format as a mode change e.g. +ow-i (server - operators only). - p Show users who are connected to a port in the <pattern> range (server - operators only). - r Show users who have a real name matching <pattern>. - t Show users who have connected in the last <pattern> seconds. - -The following flags filter users by their status: - - f Only show users on remote (far) servers. - l Only show users on the local server. - o Only show server operators. - -The following flags modify the command output: - - h Show real hostnames rather than display hostnames (server operators - only). - -You may combine one flag from the first group and multiple from the others in -one WHO command."> - -<helpop key="motd" value="/MOTD [<server>] - -Show the message of the day for <server>. Messages of the day often -contain important server rules and notices and should be read prior -to using a server."> - -<helpop key="rules" value="/RULES - -Show the rules file for the local server. This is similar in effect to -except that these are not sent automatically on connect."> - -<helpop key="oper" value="/OPER <login> <password> - -Attempts to authenticate a user as an IRC operator. - -Both successful and unsuccessful oper attempts are -logged, and sent to online IRC operators."> - -<helpop key="list" value="/LIST [<pattern>] - -Creates a list of all existing channels matching the glob pattern -<pattern>, e.g. *chat* or bot*."> - -<helpop key="lusers" value="/LUSERS - -Shows a count of local and remote users, servers and channels."> - -<helpop key="userhost" value="/USERHOST <nick> [<nick>] - -Returns the hostname and nickname of a user, and some other -miscellaneous information."> - -<helpop key="away" value="/AWAY [<message>] - -If a message is given, marks you as being away, otherwise -removes your away status and previous message."> - -<helpop key="ison" value="/ISON <nick> [<nick> ...] - -Returns a subset of the nicks you give, showing only those -that are currently online."> - -<helpop key="invite" value="/INVITE <nick> <channel> [<time>] - -Invites a user to a channel. If the channel is NOT +A, only -channel halfoperators or above can invite people. If +A is set, -anyone can invite people to the channel, as long as the person -doing the invite is a member of the channel they wish to invite -the user to. - -Invited users may override bans, +k, and similar in addition to -+i, depending on configuration. - -If a time is provided, the invite expires after that time and the user -can no longer use it to enter the channel."> - -<helpop key="pass" value="/PASS <password> - -This command is used by your client when setting up -your IRC session to submit a server password to the -server. - -You should not use it during an established connection."> - -<helpop key="whowas" value="/WHOWAS <nick> - -Returns a list of times the user was seen recently on IRC along with -the time they were last seen and their server."> - -<helpop key="links" value="/LINKS - -Shows all servers linked to this one."> - -<helpop key="map" value="/MAP - -Shows a graphical representation of all users and servers on the -network, and the links between them, as a tree from the perspective -of your server."> - -<helpop key="whois" value="/WHOIS <nick> [<server>] - -Returns the WHOIS information of a user, their channels, hostname, -etc. If a second nickname or server is provided, then a whois is -performed from the server where the user is actually located rather -than locally, showing idle and signon times."> - -<helpop key="time" value="/TIME [<server>] - -Returns the local time of the server, or remote time of another -server."> - -<helpop key="info" value="/INFO [<server>] - -Returns information on the developers and supporters who made this -IRC server possible."> - -<helpop key="setname" value="/SETNAME <name> - -Sets your name to the specified name."> - - -##################### -# Oper Commands # -##################### - -<helpop key="coper" value="Oper Commands -------------- - -OPERMOTD CHECK CLONES USERIP TLINE -ALLTIME WALLOPS GLOBOPS MODENOTICE -CLOAK - -SETHOST SETIDENT CHGHOST CHGIDENT CHGNAME -SETIDLE SWHOIS - -SANICK NICKLOCK NICKUNLOCK - -SAJOIN SAPART SAMODE SATOPIC SAKICK - -KILL SAQUIT GLINE ZLINE QLINE -KLINE RLINE ELINE CBAN SHUN -FILTER OJOIN - -CONNECT SQUIT RCONNECT RSQUIT - -DIE RESTART REHASH -CLEARCACHE LOADMODULE UNLOADMODULE -RELOADMODULE GLOADMODULE GUNLOADMODULE -GRELOADMODULE CLOSE JUMPSERVER -LOCKSERV UNLOCKSERV"> - -<helpop key="userip" value="/USERIP <nick> [<nick>] - -Returns the ip and nickname of the given users."> - -<helpop key="tline" value="/TLINE <mask> - -This command returns the number of local and global clients matched, -and the percentage of clients matched, plus how they were matched -(by IP address or by hostname). Mask should be given as either a -nick!user@host or user@IP (wildcards acceptable)."> - -<helpop key="lockserv" value="/LOCKSERV - -Locks out all new connections notifying connecting users that the -service is temporarily closed and to try again later."> - -<helpop key="unlockserv" value="/UNLOCKSERV - -Opens the server up again for new connections."> - -<helpop key="jumpserver" value="/JUMPSERVER [<newserver> <newport> <(+|-)[flags]> :[<reason>]] - -Sets or cancels jumpserver mode. If no parameters are given, -jumpserver mode is cancelled, if it is currently set. If parameters -are given, a server address must be given for <newserver> and a -server port must be given for <newport>. Zero or more status flags -should be given for 'flags', from the list below (if you do not -wish to specify any flags just place a '+' in this field): - -1. +a: Redirect all users immediately (except for opers) and cause -them to quit with the given reason - -2. +n: Redirect any new users who connect and cause them to quit -during registration - -You may use + and - to set or unset these flags in the command, the -default flags are -a+n, which will just redirect new users. The -reason parameter is optional, and if not provided defaults to -'Please use this server/port instead' (the default given in various -numeric lists)"> - -<helpop key="filter" value="/FILTER <filter-definition> [<action> <flags> [<gline-duration>] :<reason>] - -This command will add a filter when more than one parameter is given, -for messages of the types specified by the flags, with the given -filter definition, action, gline duration (when the action is 'gline') -and reason. - -The filter will take effect when a message of any type specified by -the flags and matching the definition is sent to the server, and -perform the specified action. - -Valid FILTER Actions --------------------- - -None Does nothing -Block Blocks message and informs +s IRCops of the blocked message - and all relevant info -Silent Blocks message, but does not notify IRCops -Kill Kills the user -Gline Glines the user for the specified duration - -Valid FILTER Flags ------------------- - -p Block private and channel messages -n Block private and channel notices -P Block part messages -q Block quit messages -o Don't match against opers -c Strip all formatting codes from the message before matching -* Represents all of the above flags -- Does nothing, a non-op for when you do not want to specify any - flags - -The reason for the filter will be used as the reason for the action, -unless the action is 'none', and is sent to the user when their text is -blocked by 'block' and 'silent' actions. - -A gline duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, 5 -minutes and 6 seconds. All fields in this format are optional. - -When only one parameter is provided (the filter pattern) the provided -filter will be removed. Note that if you remove a -configuration-defined filter, it will reappear at next rehash unless -it is also removed from the config file."> - -<helpop key="ojoin" value="/OJOIN <channel> - -Force joins you to the specified channel, and gives you +Y and any other -configuration-defined modes on it, preventing you from being kicked. -Depending on configuration, may announce that you have joined the -channel on official network business."> - -<helpop key="clones" value="/CLONES <limit> - -Retrieves a list of users with more clones than the specified -limit."> - -<helpop key="check" value="/CHECK <nick|ip|hostmask|channel> [<server>] - -Allows opers to look up advanced information on channels, hostmasks -or IP addresses, in a similar way to WHO but in more detail, displaying -most information the IRCD has stored on the target, including all -metadata. - -With the second parameter given, runs the command remotely on the -specified server."> - -<helpop key="alltime" value="/ALLTIME - -Shows the time on all servers on the network."> - -<helpop key="rconnect" value="/RCONNECT <source mask> <target mask> - -The server matching <source mask> will try to connect to the first -server in the config file matching <target mask>."> - -<helpop key="rsquit" value="/RSQUIT <target mask> [<reason>] - -Causes a remote server matching <target mask> to be disconnected from -the network."> - -<helpop key="globops" value="/GLOBOPS <message> - -Sends a message to all users with the +g snomask."> - -<helpop key="cban" value="/CBAN <channel> [<duration> :[<reason>]] - -Sets or removes a channel ban. You must specify all three parameters -to add a ban, and one parameter to remove a ban (just the channel). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="sajoin" value="/SAJOIN <nick> <channel> - -Forces the user to join the channel."> - -<helpop key="sapart" value="/SAPART <nick> <channel> - -Forces the user to part the channel."> - -<helpop key="samode" value="/SAMODE <target> (+|-)<modes> [<parameters for modes>] - -Applies the given mode change to the channel or nick specified."> - -<helpop key="sanick" value="/SANICK <nick> <new nick> - -Changes the user's nick to the new nick."> - -<helpop key="sakick" value="/SAKICK <channel> <nick> <reason> - -Kicks the given user from the specified channel."> - -<helpop key="satopic" value="/SATOPIC <channel> <new topic> - -Applies the given topic to the specified channel."> - -<helpop key="saquit" value="/SAQUIT <nick> <reason> - -Forces user to quit with the specified reason."> - -<helpop key="setidle" value="/SETIDLE <idle time> - -Sets your idle time (in seconds) to the specified value."> - -<helpop key="sethost" value="/SETHOST <host> - -Sets your host to the specified host."> - -<helpop key="setident" value="/SETIDENT <ident> - -Sets your ident to the specified ident."> - -<helpop key="swhois" line="/SWHOIS <nick> <swhois> - -Sets the user's swhois field to the given swhois."> - -<helpop key="mkpasswd" value="/MKPASSWD <hashtype> <plaintext> - -Encodes the plaintext to a hash of the given type and displays -the result."> - -<helpop key="opermotd" value="/OPERMOTD - -Displays the Oper MOTD."> - -<helpop key="nicklock" value="/NICKLOCK <nick> <new nick> - -Changes the user's nick to the new nick, and forces -it to remain as such for the remainder of the session."> - -<helpop key="nickunlock" value="/NICKUNLOCK <nick> - -Allows a previously locked user to change nicks again."> - -<helpop key="chghost" value="/CHGHOST <nickname> <new hostname> - -Changes the hostname of the user to the new hostname."> - -<helpop key="chgname" value="/CHGNAME <nickname> <new name> - -Changes the name of the user to the new name."> - -<helpop key="chgident" value="/CHGIDENT <nickname> <new ident> - -Changes the ident of the user to the new ident."> - -<helpop key="shun" value="/SHUN <nick!user@host> [[<duration>] :<reason>] - -Sets or removes a shun (server side ignore) on a host and ident mask. -You must specify all three parameters to add a shun, and one parameter -to remove a shun (just the nick!user@host section). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="die" value="/DIE <password> - -This command shuts down the local server. A single parameter is -required, which must match the password in the configuration for the -command to function."> - -<helpop key="restart" value="/RESTART <password> - -This command restarts the local server. A single parameter is -required, which must match the password in the configuration for the -command to function."> - -<helpop key="commands" value="/COMMANDS - -Shows all currently available commands."> - -<helpop key="kill" value="/KILL <user> <reason> - -This command will disconnect a user from IRC with the given reason."> - -<helpop key="rehash" value="/REHASH <mask> - -This command will cause the server configuration file to be reread and -values reinitialized for all servers matching the server mask, or the -local server if one is not specified."> - -<helpop key="connect" value="/CONNECT <servermask> - -Add a connection to the server matching the given server mask. You must -have configured the server for linking in your configuration file -before trying to link them."> - -<helpop key="squit" value="/SQUIT <servermask> - -Disconnects the server matching the given server mask from this server."> - -<helpop key="modules" value="/MODULES - -Lists currently loaded modules, their memory offsets, version numbers, -and flags. If you are not an operator, you will see reduced detail."> - -<helpop key="loadmodule" value="/LOADMODULE <filename.so> - -Loads the specified module into the local server."> - -<helpop key="unloadmodule" value="/UNLOADMODULE <filename.so> - -Unloads a module from the local server. The module cannot have the -static flag set (see the output of /MODULES)."> - -<helpop key="reloadmodule" value="/RELOADMODULE <filename.so> - -Unloads and reloads a module on the local server. This module cannot -have the static flag set (see the output of /MODULES)."> - -<helpop key="gloadmodule" value="/GLOADMODULE <filename.so> - -Loads the specified module on all linked servers."> - -<helpop key="gunloadmodule" value="/GUNLOADMODULE <filename.so> - -Unloads a module from all linked servers. The module cannot have the -static flag set (see the output of /MODULES)."> - -<helpop key="greloadmodule" value="/GRELOADMODULE <filename.so> - -Unloads and reloads a module on all linked servers. This module cannot -have the static flag set (see the output of /MODULES)."> - -<helpop key="kline" value="/KLINE <user@host> [<duration> :<reason>] - -Sets or removes a k-line (local host based ban) on a host and ident mask. -You must specify all three parameters to add a ban, and one parameter -to remove a ban (just the user@host section). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="zline" value="/ZLINE <ipmask> [<duration> :<reason>] - -Sets or removes a z-line (ip based ban) on an ip range mask. -You must specify all three parameters to add a ban, and one parameter -to remove a ban (just the ipmask). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="qline" value="/QLINE <nickmask> [<duration> :<reason>] - -Sets or removes a q-line (nick based ban) on a nick mask. -You must specify all three parameters to add a ban, and one parameter -to remove a ban (just the nickmask). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="gline" value="/GLINE <user@host> [<duration> :<reason>] - -Sets or removes a g-line (host based ban) on host mask. -You must specify all three parameters to add a ban, and one -parameter to remove a ban (just the user@host section). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="eline" value="/ELINE <user@host> [<duration> :<reason>] - -Sets or removes a e-line (global ban exception) on host mask. -You must specify at least 3 parameters to add an exception, and one -parameter to remove an exception (just the user@host section). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional. - -This command has a few important limitations. Bans on *@<ip> can only -be negated by an eline on *@<ip>, bans on *@<host> can be negated by -elines on *@<ip>, or *@<host>, and bans on <ident>@* or <ident>@<host> -can be negated by any eline that matches."> - -<helpop key="wallops" value="/WALLOPS <message> - -Sends a message to all +w users."> - -<helpop key="rline" value="/RLINE <regex> [<duration> :<reason>] - -Sets or removes an r-line (regex line) on a n!u@h\sgecos mask. You -must specify all three parameters to add an rline, and one parameter -to remove an rline (just the regex). - -The duration may be specified in seconds, or in the format -1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, -5 minutes and 6 seconds. All fields in this format are optional."> - -<helpop key="clearcache" value="/CLEARCACHE - -This command clears the DNS cache of the local server."> - -<helpop key="close" value="/CLOSE - -Closes all unregistered connections to the local server."> - -<helpop key="modenotice" value="/MODENOTICE <modeletters> <message> - -Sends a notice to all users who have the given mode(s) set. -If multiple mode letters are given, the notice is only sent to users -who have all of them set."> - -<helpop key="cloak" value="/CLOAK <host> - -Generate the cloak of a host or IP. This is useful for example when -trying to get the cloak of a user from /WHOWAS and they were not -using their cloak when they quit."> - -###################### -# User/Channel Modes # -###################### - -<helpop key="umodes" value="User Modes ----------- - - c Blocks private messages and notices from users who do - not share a common channel with you (requires the - commonchans module). - d Deaf mode. User will not receive any messages or notices - from channels they are in (requires the deaf module). - g In combination with /ACCEPT, provides for server side - ignore (requires the callerid module). - h Marks as 'available for help' in WHOIS (IRCop only, - requires the helpop module). - i Makes invisible to /WHO if the user using /WHO is not in - a common channel. - k Prevents the user from being kicked from channels, or - having op modes removed from them (services only, - requires the servprotect module). - o Marks as a IRC operator. - s <mask> Receives server notices specified by <mask> - (IRCop only). - r Marks as a having a registered nickname - (requires the services account module). - w Receives wallops messages. - x Gives a cloaked hostname (requires the cloaking module). - B Marks as a bot (requires the botmode module). - G Censors messages sent to the user based on filters - configured for the network (requires the censor module). - H Hides an oper's oper status from WHOIS (requires the - hideoper module). - I Hides a user's entire channel list in WHOIS from - non-IRCops (requires the hidechans module). - L Stops redirections done by m_redirect (mode must be - enabled in the config). - R Blocks private messages from unregistered users - (requires the services account module). - S Strips formatting codes out of private messages - to the user (requires the stripcolor module). - W Receives notification when a user uses WHOIS on them - (IRCop only, requires the showwhois module)."> - -<helpop key="chmodes" value="Channel Modes -------------- - - v <nickname> Gives voice to <nickname>, allowing them to speak - while the channel is +m. - h <nickname> Gives halfop status to <nickname> (requires the - customprefix module). - o <nickname> Gives op status to <nickname>. - a <nickname> Gives protected status to <nickname>, preventing - them from being kicked (+q only, requires the - customprefix module). - q <nickname> Gives owner status to <nickname>, preventing them - from being kicked (Services or +q only, requires - the customprefix module). - - b <hostmask> Bans <hostmask> from the channel. - e <hostmask> Excepts <hostmask> from bans (requires the - banexception module). - I <hostmask> Excepts <hostmask> from +i, allowing matching - users to join while the channel is invite-only - (requires the inviteexception module). - - c Blocks messages that contain formatting codes - (requires the blockcolor module). - d <time> Blocks messages to a channel from new users - until they have been in the channel for <time> - seconds (requires the delaymsg module). - f [*]<lines>:<sec> Kicks on text flood equal to or above the - specified rate. With *, the user is banned - (requires the messageflood module). - g <mask> Blocks messages matching the given glob mask - (requires the chanfilter module). - i Makes the channel invite-only. - Users can only join if an operator - uses /INVITE to invite them. - j <joins>:<sec> Limits joins to the specified rate (requires - the joinflood module). - k <key> Set the channel key (password) to <key>. - l <limit> Set the maximum allowed users to <limit>. - m Enable moderation. Only users with +v, +h, or +o - can speak. - n Blocks users who are not members of the channel - from messaging it. - p Make channel private, hiding it in users' whoises - and replacing it with * in /LIST. - r Marks the channel as registered with Services - (requires the services account module). - s Make channel secret, hiding it in users' whoises - and /LIST. - t Prevents users without +h or +o from changing the - topic. - u Makes the channel an auditorium; normal users only - see themselves or themselves and the operators, - while operators see all the users (requires the - auditorium module). - w <flag>:<banmask> Adds basic channel access controls of <flag> to - <banmask>, via the +w listmode. - For example, +w o:R:Brain will op anyone identified - to the account 'Brain' on join. - (requires the autoop module) - z Blocks non-SSL clients from joining the channel. - - A Allows anyone to invite users to the channel - (normally only chanops can invite, requires - the allowinvite module). - B Blocks messages with too many capital letters, - as determined by the network configuration - (requires the blockcaps module). - C Blocks any CTCPs to the channel (requires the - noctcp module). - D Delays join messages from users until they message - the channel (requires the delayjoin module). - F <changes>:<sec> Blocks nick changes when they equal or exceed the - specified rate (requires the nickflood module). - G Censors messages to the channel based on the - network configuration (requires the censor module). - H <num>:<duration> Displays the last <num> lines of chat to joining - users. <duration> is the maximum time to keep - lines in the history buffer (requires the - chanhistory module). - J <seconds> Prevents rejoin after kick for the specified - number of seconds. This prevents auto-rejoin - (requires the kicknorejoin module). - K Blocks /KNOCK on the channel. - L <channel> If the channel reaches its limit set by +l, - redirect users to <channel> (requires the - redirect module). - M Blocks unregistered users from speaking (requires - the services account module). - N Prevents users on the channel from changing nick - (requires the nonicks module). - O Channel is IRCops only (can only be set by IRCops, - requires the operchans module). - P Makes the channel permanent; Bans, invites, the - topic, modes, and such will not be lost when it - empties (can only be set by IRCops, requires - the permchannels module). - Q Only ulined servers and their users can kick - (requires the nokicks module) - R Blocks unregistered users from joining (requires - the services account module). - S Strips formatting codes from messages to the - channel (requires the stripcolor module). - T Blocks /NOTICEs to the channel from users who are - not at least halfop (requires the nonotice module). - X <type>:<status> Makes users of <status> or higher exempt to the - specified restriction <type>. For example: flood:h - (requires the exemptchanops module). - Possible restriction types to exempt with +X are: - - auditorium-see Permission required to see the full user list of - a +u channel (requires the auditorium module). - auditorium-vis Permission required to be visible in a +u channel - (requires the auditorium module). - blockcaps Channel mode +B - blockcolor Channel mode +c - censor Channel mode +G - filter Channel mode +g - flood Channel mode +f - nickflood Channel mode +F - noctcp Channel mode +C - nonick Channel mode +N - nonotice Channel mode +T - regmoderated Channel mode +M - stripcolor Channel mode +S - topiclock Channel mode +t - -------------- -NOTE: A large number of these modes are dependent upon server-side modules -being loaded by a server/network administrator. The actual modes available -on your network may be very different to this list. Please consult your -help channel if you have any questions."> - -###################### -# Stats Symbols # -###################### - -<helpop key="stats" value="/STATS <symbol> - -Shows various server statistics. Depending on configuration, some -symbols may be only available to opers. - -Valid symbols are: - -e Show E-lines (local ban exemptions) -g Show G-lines (host bans) -k Show K-lines (local host bans) -q Show Q-lines (nick mask bans) -R Show R-lines (regular expression bans) -Z Show Z-lines (IP mask bans) - -s Show filters -C Show channel bans -H Show shuns - -c Show link blocks -d Show configured DNSBLs and related statistics -m Show command statistics, number of times commands have been used -o Show a list of all valid oper usernames and hostmasks -p Show open client ports, and the port type (ssl, plaintext, etc) -u Show server uptime -z Show memory usage statistics -i Show connect class permissions -l Show all client connections with information (sendq, commands, bytes, time connected) -L Show all client connections with information and IP address -P Show online opers and their idle times -T Show bandwidth/socket statistics -U Show U-lined servers -Y Show connection classes -O Show opertypes and the allowed user and channel modes it can set -E Show socket engine events -S Show currently held registered nicknames -G Show how many local users are connected from each country according to GeoIP - -Note that all /STATS use is broadcast to online IRC operators."> - -###################### -# SNOMASKS # -###################### - -<helpop key="snomasks" value="Server Notice Masks - - a Allows receipt of local announcement messages. - A Allows receipt of remote announcement messages. - c Allows receipt of local connect messages. - C Allows receipt of remote connect messages. - d Allows receipt of general (and sometimes random) debug messages. - f Allows receipt of flooding notices. - g Allows receipt of globops (requires the globops module). - j Allows receipt of channel creation notices (requires the chancreate module). - J Allows receipt of remote channel creation notices (requires the chancreate module). - k Allows receipt of local kill messages. - K Allows receipt of remote kill messages. - l Allows receipt of local linking related messages. - L Allows receipt of remote linking related messages. - n See local nickname changes (requires the seenicks module). - N See remote nickname changes (requires the seenicks modules). - o Allows receipt of oper-up, oper-down, and oper-failure messages. - O Allows receipt of remote oper-up, oper-down, and oper-failure messages. - q Allows receipt of local quit messages. - Q Allows receipt of remote quit messages. - r Allows receipt of local oper commands (requires the operlog module). - R Allows receipt of remote oper commands (requires the operlog module). - t Allows receipt of attempts to use /STATS (local and remote). - v Allows receipt of oper-override notices (requires the override module). - x Allows receipt of local Xline notices (g/Z/q/k/e/R/shuns). - X Allows receipt of remote Xline notices (g/Z/q/k/e/R/shuns)."> - -###################### -# EXTBANS # -###################### - -<helpop key="extbans" value="Extended Bans ----------- - -Extbans are split into two types; matching extbans, which match on -users in additional ways, and acting extbans, which restrict users -in different ways to a standard ban. - -To use an extban, simply set +b <ban> or +e <ban> with it as the ban, -instead of a normal nick!user@host mask, to ban or exempt matching -users. Ban exceptions on acting extbans exempt that user from matching -an extban of that type, and from any channel mode corresponding to the -restriction. Matching extbans may also be used for invite exceptions by -setting +I <extban>. - -Matching extbans: - - j:<channel> Matches anyone in the given channel. Does not support - wildcards (requires the channelban module). - r:<realname> Matches users with a matching realname (requires the - gecosban module). - s:<server> Matches users on a matching server (requires the - serverban module). - z:<certfp> Matches users having the given SSL certificate - fingerprint (requires the sslmodes module). - O:<opertype> Matches IRCops of a matching type, mostly useful as an - an invite exception (requires the operchans module). - R:<account> Matches users logged into a matching account (requires - the services account module). - U:<banmask> Matches unregistered users matching the given banmask. - (requires the services account module). - -Acting extbans: - - c:<banmask> Blocks any messages that contain formatting codes from - matching users (requires the blockcolor module). - m:<banmask> Blocks messages from matching users (requires the muteban - module). Users with +v or above are not affected. - p:<banmask> Blocks part messages from matching users (requires - the nopartmsg module). - A:<banmask> Blocks invites by matching users even when +A is set - (requires the allowinvite module). - B:<banmask> Blocks all capital or nearly all capital messages from - matching users (requires the blockcaps module). - C:<banmask> Blocks CTCPs from matching users (requires the noctcp - module). - N:<banmask> Blocks nick changes from matching users (requires - the nonicks module). - Q:<banmask> Blocks kicks by matching users (requires the nokicks - module). - S:<banmask> Strips formatting codes from messages from matching - users (requires the stripcolor module). - T:<banmask> Blocks notices from matching users (requires the - nonotice module). - -A ban given to an Acting extban may either be a nick!user@host mask -(unless stated otherwise), matched against users as for a normal ban, -or a Matching extban. - -There is an additional special type of extended ban, a redirect ban: - - Redirect n!u@h#channel will redirect the banned user to #channel - when they try to join (requires the banredirect module)."> diff --git a/docs/conf/helpop.conf.example b/docs/conf/helpop.conf.example index bdd3c4605..e12508659 100644 --- a/docs/conf/helpop.conf.example +++ b/docs/conf/helpop.conf.example @@ -1,16 +1,20 @@ -# Sample configuration file for m_helpop.so +# Sample configuration file for the helpop module. # You can either copy this into your conf folder and set up the module to use it, # or you can customize the responses for your network and/or add more. # # The way the new helpop system works is simple. You use one or more helpop tags. -# <helpop key="moo" value="something here">. +# <helpop key="moo" value="something here"> # key is what the user is looking for (i.e. /helpop moo), and value is what they get back # (note that it can span multiple lines!). # -- w00t 16/dec/2006 # +<config format="xml"> + <alias text="HELP" replace="HELPOP $2-"> +<helpmsg nohelp="There is no help for the topic you searched for. Please try again."> + <helpop key="start" value="InspIRCd Help System This system provides help for commands and modes. @@ -24,53 +28,799 @@ parameter for this command. /HELPOP SNOMASKS - To see a list of oper snotice masks /HELPOP EXTBANS - To see a list of extended bans"> -<helpop key="nohelp" value="There is no help for the topic -you searched for. Please try again."> - <helpop key="cuser" value="User Commands ------------- -PRIVMSG NOTICE NICK JOIN PART -CYCLE KNOCK MODE DEVOICE TOPIC -KICK FPART REMOVE TBAN INVITE -UNINVITE AWAY DCCALLOW SILENCE ACCEPT -MKPASSWD VHOST TITLE SETNAME +ACCEPT ADMIN AWAY COMMANDS CYCLE DCCALLOW +FPART INFO INVITE ISON JOIN KICK +KNOCK LINKS LIST LUSERS MAP MKPASSWD +MODE MODULES MONITOR MOTD NAMES NICK +NOTICE OPER PART PASS PING PONG +PRIVMSG QUIT REMOVE SETNAME SILENCE SQUERY +SSLINFO STATS TBAN TIME TITLE TOPIC +UNINVITE USER USERHOST VERSION VHOST WATCH +WHO WHOIS WHOWAS"> + +<helpop key="squery" value="/SQUERY <target> :<message> + +Sends a message to the network service specified in <target>."> + +<helpop key="sslinfo" value="/SSLINFO <nick> + +Displays information on the SSL connection and certificate of the +target user."> + +<helpop key="uninvite" value="/UNINVITE <nick> <channel> + +Uninvite a user from a channel, same syntax as INVITE."> + +<helpop key="tban" value="/TBAN <channel> <duration> <banmask> + +Sets a timed ban. The duration of the ban can be specified in the +form of 1y2w3d4h5m6s - meaning one year, two weeks, three days, +four hours, five minutes and six seconds. All fields in this +format are optional. Alternatively, the ban may just be specified +as a number of seconds. All timed bans appear in the banlist as +normal bans and may be safely removed before their time is up."> + +<helpop key="dccallow" value="/DCCALLOW [(+|-)<nick> [<time>]]|[LIST|HELP] + +/DCCALLOW - List allowed nicks +/DCCALLOW LIST - This also lists allowed nicks +/DCCALLOW +<nick> [<duration>] - Add a nick +/DCCALLOW -<nick> - Remove a nick +/DCCALLOW HELP - Display help + +Duration is optional, and may be specified in seconds or in the +form of 1y2w3d4h5m6s - meaning one year, two weeks, three days, +four hours, five minutes and six seconds. All fields in this +format are optional."> + +<helpop key="accept" value="/ACCEPT *|(+|-)<nick>[,(+|-)<nick>]+ + +Manages your accept list. This list is used to determine who can +private message you when you have user mode +g set. + +/ACCEPT * - List accepted nicks +/ACCEPT +<nick> - Add a nick +/ACCEPT -<nick> - Remove a nick + +This command accepts multiple nicks like so: +/ACCEPT +<nick>,-<nick>,+<nick>"> + +<helpop key="cycle" value="/CYCLE <channel> [:<reason>] + +Cycles a channel (leaving and rejoining), overrides restrictions that +would stop a new user joining, such as user limits and channel keys."> + +<helpop key="title" value="/TITLE <username> <password> + +Authenticate for a WHOIS title line and optionally a vhost using the +specified username and password."> + +<helpop key="watch" value="/WATCH C|L|l|S|(+|-)<nick> [(+|-)<nick>]+ + +/WATCH - List watched nicks that are online +/WATCH l - List watched nicks that are online +/WATCH L - List watched nicks, online and offline +/WATCH C - Clear all watched nicks +/WATCH S - Show statistics +/WATCH +<nick> - Add a nick +/WATCH -<nick> - Remove a nick + +This command accepts multiple nicks like so: +/WATCH +<nick> -<nick> +<nick>"> + +<helpop key="monitor" value="/MONITOR C|L|S|(+|-) <nick>[,<nick>]+ + +/MONITOR L - List all monitored nicks, not differentiating between + online and offline nicks +/MONITOR C - Clear all monitored nicks +/MONITOR S - List all monitored nicks, indicating which are online + and which are offline +/MONITOR + <nick> - Add a nick +/MONITOR - <nick> - Remove a nick + +This command accepts multiple nicks like so: +/MONITOR + <nick>,<nick>,<nick> +/MONITOR - <nick>,<nick>,<nick>"> + +<helpop key="vhost" value="/VHOST <username> <password> + +Authenticate for a vhost using the specified username and password."> + +<helpop key="remove" value="/REMOVE <channel> <nick> [:<reason>] + +Removes a user from a channel you specify. You must be at least a +channel halfoperator to remove a user. A removed user will part with +a message stating they were removed from the channel and by whom."> + +<helpop key="rmode" value="/RMODE <channel> <mode> [<pattern>] + +Removes listmodes from a channel, optionally matching a glob-based pattern. +E.g. '/RMODE #channel b m:*' will remove all mute extbans on the channel."> + +<helpop key="fpart" value="/FPART <channel> <nick> [:<reason>] + +This behaves identically to /REMOVE. /REMOVE is a built-in mIRC command +which caused trouble for some users."> + +<helpop key="silence" value="/SILENCE [(+|-)<mask> [CcdiNnPpTtx]] + +A server-side ignore of the given n!u@h mask. If the optional flags field is +specified then it must contain one or more flags which specify what kind of +messages should be blocked and how they should be blocked. + +/SILENCE - Shows a list of silenced masks +/SILENCE +<mask> [<flags>] - Add a mask +/SILENCE -<mask> - Remove a mask + +Valid SILENCE Flags +------------------- + C Matches a CTCP targeted at a user. + c Matches a CTCP targeted at a channel. + d Default behaviour; equivalent to CciNnPpTt. + i Matches an invite to a channel. + N Matches a NOTICE targeted at a user. + n Matches a NOTICE targeted at a channel. + P Matches a PRIVMSG targeted at a user. + p Matches a PRIVMSG targeted at a channel. + T Matches a TAGMSG targeted at a user. + t Matches a TAGMSG targeted at a channel. + x Exempt the mask from silence rules. + +Any combination of flags is valid."> + +<helpop key="knock" value="/KNOCK <channel> :<reason> + +Sends a notice to a channel indicating you wish to join."> + +<helpop key="user" value="/USER <username> <unused> <unused> :<realname> + +This command is used by your client to register your +IRC session, providing your ident and real name to the +server. + +You should not use it during an established connection."> + +<helpop key="nick" value="/NICK <newnick> + +Change your nickname to <newnick>."> + +<helpop key="quit" value="/QUIT [:<message>] + +Quit from IRC and end your current session."> + +<helpop key="version" value="/VERSION [<servername>] + +Returns the server's version information."> + +<helpop key="ping" value="/PING <servername> [:<servername>] + +Ping a server. The server will answer with a PONG."> + +<helpop key="pong" value="/PONG <servername> + +Your client should send this to answer server PINGs. You +should not issue this command manually."> + +<helpop key="admin" value="/ADMIN [<servername>] + +Shows the administrative information for the given server."> + +<helpop key="privmsg" value="/PRIVMSG <target>[,<target>]+ :<message> + +Sends a message to a user or channel specified in <target>."> + +<helpop key="notice" value="/NOTICE <target>[,<target>]+ :<message> + +Sends a notice to a user or channel specified in <target>."> + +<helpop key="join" value="/JOIN <channel>[,<channel>]+ [<key>[,<key>]+] + +Joins one or more channels you provide the names for."> + +<helpop key="names" value="/NAMES <channel>[,<channel>]+ + +Return a list of users on the channel(s) you provide."> -WHOIS WHOWAS ISON USERHOST WATCH -LIST NAMES WHO MOTD RULES -ADMIN MAP LINKS LUSERS TIME -STATS VERSION INFO MODULES COMMANDS -SSLINFO +<helpop key="part" value="/PART <channel>[,<channel>]+ [:<reason>] -USER PASS PING PONG QUIT +Leaves one or more channels you specify."> + +<helpop key="kick" value="/KICK <channel> <nick>[,<nick>]+ [:<reason>] + +Kicks a user from a channel you specify. You must be +at least a channel halfoperator to kick a user."> + +<helpop key="mode" value="/MODE <target> [[(+|-)]<modes> [<mode-parameters>]] + +Change or view modes of <target>. + +/MODE <target> - Show modes of <target>. + +/MODE <channel> <list mode char> - List bans, exceptions, etc. set on <channel>. + +Sets the mode for a channel or a nickname specified in <target>. +A user may only set modes upon themselves, and may not set the ++o user mode, and a user may only change channel modes of +channels where they are at least a halfoperator. + +For a list of all user and channel modes, enter /HELPOP UMODES or +/HELPOP CHMODES."> + +<helpop key="topic" value="/TOPIC <channel> [:<topic>] + +Sets or retrieves the channel topic. If a channel topic is +given in the command and either the channel is not +t, or +you are at least a halfoperator, the channel topic will be +changed to the new one you provide."> + +<helpop key="who" value="/WHO <pattern> [<flags>][%[<fields>[,<querytype>]]] <pattern> + +Looks up information about users matching the provided pattern. You can specify +a flag specific pattern, a channel name, user hostname, a user server name, a +user real name, or a user nickname. Matching users will only be included in the +WHO response if: + + 1) The specified pattern is an exact channel name that does not have the + private or secret channel modes set and the user does not have the invisible + user mode set. + 2) The specified pattern is an exact nickname. + 3) You share one or more common channels with the user. + 4) The user does not have the invisible user mode set. + 5) You are a server operator with the users/auspex privilege. + +If you specify any fields the response returned will be a WHOX response rather +than a RFC 1459 WHO response. + +Valid WHO Flags +--------------- + +The following flags use <pattern> to match against the specified user data: + + A Show users who have an away message matching <pattern>. + a Show users who have an account name matching <pattern>. + h Show users who have a hostname matching <pattern>. If the 'x' modifier + is specified then this will match against the real hostname instead of + the display hostname. + i Show users who have an IP address matching <pattern>. + m Show users who have the modes listed in <pattern>. The pattern + should be in the same format as a mode change e.g. +ow-i (server + operators only). + n Show users who have a nickname matching <pattern>. + p Show users who are connected to a port in the <pattern> range (server + operators only). + r Show users who have a real name matching <pattern>. + s Show users who are on a server with a name matching <pattern>. If the 'x' + modifier is specified then this will match against the real server name + instead of the masked server name. + t Show users who have connected in the last <pattern> seconds. + u Show users who have an ident (username) matching <pattern>. + +The following flags filter users by their status: + + f Only show users on remote (far) servers. + l Only show users on the local server. + o Only show server operators. + +The following flags modify the command output: + + x Show sensitive data like real user hostnames and, when hideserver is + enabled, real server hostnames. + +You may combine one flag from the first group and multiple from the others in +one WHO command. + +Valid WHO Fields +---------------- + + a Include the user's account name in the response. + c Include the first common channel name in the response. + d Include the user's server distance from you in the response. + f Include the user's away status, oper status, and highest channel prefix + in the response. + h Include the user's hostname in the response. If the 'x' flag was + specified then this is the real host rather than the display host. + i Include the user's IP address in the response. + l Include the user's idle time in the response. + n Include the user's nickname in the response. + o Include the user's channel operator rank level in the response. + r Include the user's real name in the response. + s Include the user's server name in the response. If the 'x' flag was + specified then this is the real server name rather than the masked server + name. + t Include the query type in the response. + u Include the user's ident in the response. + +"> + +<helpop key="motd" value="/MOTD [<servername>] + +Show the message of the day for <server>. Messages of the day often +contain important server rules and notices and should be read prior +to using a server."> + +<helpop key="oper" value="/OPER <username> <password> + +Attempts to authenticate as a server operator. + +Both successful and unsuccessful oper attempts are +logged, and sent to online server operators."> + +<helpop key="list" value="/LIST [<pattern>] + +Creates a list of all existing channels matching the glob pattern +<pattern>, e.g. *chat* or bot*."> + +<helpop key="lusers" value="/LUSERS + +Shows a count of local and remote users, servers and channels."> + +<helpop key="userhost" value="/USERHOST <nick> [<nick>]+ + +Returns the hostname and nickname of a user, and some other +miscellaneous information."> + +<helpop key="away" value="/AWAY [:<message>] + +If a message is given, marks you as being away, otherwise +removes your away status and previous message."> + +<helpop key="ison" value="/ISON <nick> [<nick>]+ + +Returns a subset of the nicks you give, showing only those +that are currently online."> + +<helpop key="invite" value="/INVITE [<nick> <channel> [<time>]] + +Invites a user to a channel. If the channel is NOT +A, only +channel halfoperators or above can invite people. If +A is set, +anyone can invite people to the channel, as long as the person +doing the invite is a member of the channel they wish to invite +the user to. + +Invited users may override bans, +k, and similar in addition to ++i, depending on configuration. + +If a time is provided, the invite expires after that time and the user +can no longer use it to enter the channel. The time can be specified +in the form of 1y2w3d4h5m6s - meaning one year, two weeks, three days, +four hours, five minutes and six seconds. All fields in this format +are optional. Alternatively, the time may just be specified as a number +of seconds. + +/INVITE without a parameter will list pending invitations for channels +you have been invited to."> + +<helpop key="pass" value="/PASS <password> + +This command is used by your client when setting up +your IRC session to submit a server password to the +server. + +You should not use it during an established connection."> + +<helpop key="whowas" value="/WHOWAS <nick> + +Returns a list of times the user was seen recently on IRC along with +the time they were last seen and their server."> + +<helpop key="links" value="/LINKS + +Shows all linked servers."> + +<helpop key="map" value="/MAP + +Shows a graphical representation of all users and servers on the +network, and the links between them, as a tree from the perspective +of your server."> + +<helpop key="whois" value="/WHOIS [<servername>] <nick>[,<nick>]+ + +Returns the WHOIS information of a user, their channels, hostname, +etc. If a servername is provided, then a whois is performed from +the server where the user is actually located rather than locally, +showing idle and signon times."> + +<helpop key="time" value="/TIME [<servername>] + +Returns the local time of the server, or remote time of another +server."> + +<helpop key="info" value="/INFO [<servername>] + +Returns information on the developers and supporters who made this +IRC server possible."> + +<helpop key="setname" value="/SETNAME :<realname> + +Sets your real name to the specified real name."> -OPER"> <helpop key="coper" value="Oper Commands ------------- -OPERMOTD CHECK CLONES USERIP TLINE -ALLTIME WALLOPS GLOBOPS MODENOTICE -CLOAK +ALLTIME CBAN CHECK CHGHOST CHGIDENT +CHGNAME CLEARCHAN CLOAK CLONES CONNECT +DIE ELINE FILTER GLINE GLOADMODULE +GLOBOPS GRELOADMODULE GUNLOADMODULE KILL KLINE +LOADMODULE LOCKSERV MODENOTICE NICKLOCK NICKUNLOCK +OJOIN OPERMOTD QLINE RCONNECT REHASH +RELOADMODULE RESTART RLINE RSQUIT SAJOIN +SAKICK SAMODE SANICK SAPART SAQUIT +SATOPIC SETHOST SETIDENT SETIDLE SHUN +SQUIT SWHOIS TLINE UNLOADMODULE UNLOCKSERV +USERIP WALLOPS ZLINE"> + +<helpop key="userip" value="/USERIP <nick> [<nick>]+ + +Returns the IP address and nickname of the given user(s)."> + +<helpop key="tline" value="/TLINE <mask> + +This command returns the number of local and global clients matched, +and the percentage of clients matched, plus how they were matched +(by IP address or by hostname). Mask should be given as either +nick!user@host or user@IP (wildcards and CIDR blocks are accepted)."> -SETHOST SETIDENT CHGHOST CHGIDENT CHGNAME -SETIDLE SWHOIS +<helpop key="lockserv" value="/LOCKSERV [:<message>] -SANICK NICKLOCK NICKUNLOCK +Locks out all new connections notifying connecting users that the +service is temporarily closed and to try again later."> -SAJOIN SAPART SAMODE SATOPIC SAKICK +<helpop key="unlockserv" value="/UNLOCKSERV -KILL SAQUIT GLINE ZLINE QLINE -KLINE RLINE ELINE CBAN SHUN -FILTER +Opens the server up again for new connections."> -CONNECT SQUIT RCONNECT RSQUIT +<helpop key="filter" value="/FILTER <pattern> [<action> <flags> [<duration>] :<reason>] -DIE RESTART REHASH -CLEARCACHE LOADMODULE UNLOADMODULE -RELOADMODULE GLOADMODULE GUNLOADMODULE -GRELOADMODULE CLOSE JUMPSERVER -LOCKSERV UNLOCKSERV"> +This command will add a global filter when more than one parameter is +given, for messages of the types specified by the flags, with the given +filter pattern, action, duration (when the action is 'gline', 'zline' +or 'shun'), and reason. + +The filter will take effect when a message of any type specified by +the flags and matching the pattern is sent to the server, and +perform the specified action. + +Valid FILTER Actions +-------------------- + +None Does nothing +Warn Lets the message through and informs +s server operators + of the message and all relevant info +Block Blocks message and informs +s server operators of the blocked + message and all relevant info +Silent Blocks message, but does not notify server operators +Kill Kills the user +Gline G-lines the user for the specified duration +Zline Z-lines the user for the specified duration +Shun Shuns the user for the specified duration (requires the shun module) + +Valid FILTER Flags +------------------ + +p Block private and channel messages +n Block private and channel notices +P Block part messages +q Block quit messages +o Don't match against opers +c Strip all formatting codes from the message before matching +* Represents all of the above flags +- Does nothing, a non-op for when you do not want to specify any + flags + +The reason for the filter will be used as the reason for the action, +unless the action is 'none', and is sent to the user when their text is +blocked by 'block' and 'silent' actions. + +A G-line, Z-line or shun duration may be specified in seconds, or in the +format 1y2w3d4h5m6s - meaning one year, two weeks, three days, 4 hours, 5 +minutes and 6 seconds. All fields in this format are optional. + +When only one parameter is provided (the filter pattern) the provided +filter will be removed. Note that if you remove a +configuration-defined filter, it will reappear at next rehash unless +it is also removed from the config file."> + +<helpop key="ojoin" value="/OJOIN <channel> + +Force joins you to the specified channel, and gives you +Y and any other +configuration-defined modes on it, preventing you from being kicked. +Depending on configuration, may announce that you have joined the +channel on official network business."> + +<helpop key="clones" value="/CLONES <limit> + +Retrieves a list of users with more clones than the specified +limit."> + +<helpop key="check" value="/CHECK <nick>|<ipmask>|<hostmask>|<channel> [<servername>] + +Allows opers to look up advanced information on nicknames, IP addresses, +hostmasks or channels, in a similar way to WHO but in more detail, +displaying most information the server has stored on the target, +including all metadata. + +With the second parameter given, runs the command remotely on the +specified server, useful especially if used on a nickname that is +online on a remote server."> + +<helpop key="alltime" value="/ALLTIME + +Shows the date and time of all servers on the network."> + +<helpop key="rconnect" value="/RCONNECT <remote-server-mask> <target-server-mask> + +The server matching <remote-server-mask> will try to connect to the first +server in the config file matching <target-server-mask>."> + +<helpop key="rsquit" value="/RSQUIT <target-server-mask> [:<reason>] + +Causes a remote server matching <target-server-mask> to be disconnected from +the network."> + +<helpop key="globops" value="/GLOBOPS :<message> + +Sends a message to all users with the +g snomask."> + +<helpop key="cban" value="/CBAN <channel> [<duration> [:<reason>]] + +Sets or removes a global channel ban. You must specify all three parameters +to add a ban, and one parameter to remove a ban (just the channel). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="sajoin" value="/SAJOIN [<nick>] <channel>[,<channel>]+ + +Forces the user to join the channel(s). +If no nick is given, it joins the oper doing the /SAJOIN."> + +<helpop key="sapart" value="/SAPART <nick> <channel>[,<channel>]+ [:<reason>] + +Forces the user to part the channel(s), with an optional reason."> + +<helpop key="samode" value="/SAMODE <target> (+|-)<modes> [<mode-parameters>] + +Applies the given mode change to the channel or nick specified."> + +<helpop key="sanick" value="/SANICK <nick> <newnick> + +Changes the user's nick to the new nick."> + +<helpop key="sakick" value="/SAKICK <channel> <nick> [:<reason>] + +Kicks the given user from the specified channel, with an optional reason."> + +<helpop key="satopic" value="/SATOPIC <channel> :<topic> + +Applies the given topic to the specified channel."> + +<helpop key="saquit" value="/SAQUIT <nick> :<reason> + +Forces user to quit with the specified reason."> + +<helpop key="setidle" value="/SETIDLE <duration> + +Sets your idle time to the specified value. + +The time can be specified in the form of 1y2w3d4h5m6s - meaning one year, +two weeks, three days, four hours, five minutes and six seconds. +All fields in this format are optional. Alternatively, the time may +just be specified as a number of seconds."> + +<helpop key="sethost" value="/SETHOST <host> + +Sets your host to the specified host."> + +<helpop key="setident" value="/SETIDENT <ident> + +Sets your ident to the specified ident."> + +<helpop key="swhois" line="/SWHOIS <nick> :<swhois> + +Sets the user's swhois field to the given swhois message. +This will be visible in their /WHOIS. + +To remove this message again, use: +/SWHOIS <nick> :"> + +<helpop key="mkpasswd" value="/MKPASSWD <hashtype> <plaintext> + +Encodes the plaintext to a hash of the given type and displays +the result."> + +<helpop key="opermotd" value="/OPERMOTD [<servername>] + +Displays the Oper MOTD."> + +<helpop key="nicklock" value="/NICKLOCK <nick> <newnick> + +Changes the user's nick to the new nick, and forces +it to remain as such for the remainder of the session."> + +<helpop key="nickunlock" value="/NICKUNLOCK <nick> + +Allows a previously locked user to change nicks again."> + +<helpop key="chghost" value="/CHGHOST <nick> <host> + +Changes the host of the user to the specified host."> + +<helpop key="chgname" value="/CHGNAME <nick> :<realname> + +Changes the real name of the user to the specified real name."> + +<helpop key="chgident" value="/CHGIDENT <nick> <ident> + +Changes the ident of the user to the specified ident."> + +<helpop key="shun" value="/SHUN <nick!user@host> [<duration> :<reason>] + +Sets or removes a shun (global server-side ignore) on a nick!user@host mask. +You must specify all three parameters to add a shun, and one parameter +to remove a shun (just the nick!user@host). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="die" value="/DIE <servername> + +This command shuts down the local server. A single parameter is +required, which must match the name of the local server."> + +<helpop key="restart" value="/RESTART <servername> + +This command restarts the local server. A single parameter is +required, which must match the name of the local server."> + +<helpop key="commands" value="/COMMANDS + +Shows all currently available commands."> + +<helpop key="kill" value="/KILL <nick>[,<nick>]+ :<reason> + +This command will disconnect a user from IRC with the given reason."> + +<helpop key="rehash" value="/REHASH [<servermask>] + +This command will cause the server configuration file to be reread and +values reinitialized for all servers matching the server mask, or the +local server if one is not specified."> + +<helpop key="connect" value="/CONNECT <servermask> + +Add a connection to the server matching the given server mask. You must +have configured the server for linking in your configuration file +before trying to link them."> + +<helpop key="squit" value="/SQUIT <servermask> + +Disconnects the server matching the given server mask from this server."> + +<helpop key="modules" value="/MODULES [<servername>] + +Lists currently loaded modules, their memory offsets, version numbers, +and flags. If you are not an operator, you will see reduced detail."> + +<helpop key="loadmodule" value="/LOADMODULE <modulename> + +Loads the specified module into the local server."> + +<helpop key="unloadmodule" value="/UNLOADMODULE <modulename> + +Unloads a module from the local server."> + +<helpop key="reloadmodule" value="/RELOADMODULE <modulename> + +Unloads and reloads a module on the local server."> + +<helpop key="gloadmodule" value="/GLOADMODULE <modulename> [<servermask>] + +Loads the specified module on all linked servers."> + +<helpop key="gunloadmodule" value="/GUNLOADMODULE <modulename> [<servermask>] + +Unloads a module from all linked servers."> + +<helpop key="greloadmodule" value="/GRELOADMODULE <modulename> [<servermask>] + +Unloads and reloads a module on all linked servers."> + +<helpop key="kline" value="/KLINE <user@host> [<duration> :<reason>] + +Sets or removes a K-line (local user@host based ban) on a user@host mask. +You must specify all three parameters to add a ban, and one parameter +to remove a ban (just the user@host). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="zline" value="/ZLINE <ipmask> [<duration> :<reason>] + +Sets or removes a Z-line (global IP based ban) on an IP mask. +You must specify all three parameters to add a ban, and one parameter +to remove a ban (just the ipmask). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="qline" value="/QLINE <nickmask> [<duration> :<reason>] + +Sets or removes a Q-line (global nick based ban) on a nick mask. +You must specify all three parameters to add a ban, and one parameter +to remove a ban (just the nickmask). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="gline" value="/GLINE <user@host> [<duration> :<reason>] + +Sets or removes a G-line (global user@host based ban) on a user@host mask. +You must specify all three parameters to add a ban, and one +parameter to remove a ban (just the user@host). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="eline" value="/ELINE <user@host> [<duration> :<reason>] + +Sets or removes a E-line (global user@host ban exception) on a user@host mask. +You must specify at least 3 parameters to add an exception, and one +parameter to remove an exception (just the user@host). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional. + +This command has a few important limitations. Bans on *@<ip> can only +be negated by an E-line on *@<ip>, bans on *@<host> can be negated by +E-lines on *@<ip>, or *@<host>, and bans on <ident>@* or <ident>@<host> +can be negated by any E-line that matches."> + +<helpop key="wallops" value="/WALLOPS :<message> + +Sends a message to all +w users."> + +<helpop key="rline" value="/RLINE <regex> [<duration> :<reason>] + +Sets or removes an R-line (global regex ban) on a n!u@h\srealname mask. You +must specify all three parameters to add an R-line, and one parameter +to remove an R-line (just the regex). + +The duration may be specified in seconds, or in the format +1y2w3d4h5m6s - meaning one year, two weeks, three days, four hours, +five minutes and six seconds. All fields in this format are optional."> + +<helpop key="clearchan" value="/CLEARCHAN <channel> [KILL|KICK|G|Z] [:<reason>] + +Quits or kicks all non-opers from a channel, optionally G/Z-lines them. +Useful for quickly nuking bot channels. + +The default method, KILL, simply disconnects the victims from the server, +while methods G and Z also add G/Z-lines for all the targets. + +When used, the victims won't see each other getting kicked or quitting."> + +<helpop key="modenotice" value="/MODENOTICE <modeletters> :<message> + +Sends a notice to all users who have the given mode(s) set. +If multiple mode letters are given, the notice is only sent to users +who have all of them set."> + +<helpop key="cloak" value="/CLOAK <host> + +Generate the cloak of a host or IP. This is useful for example when +trying to get the cloak of a user from /WHOWAS and they were not +using their cloak when they quit."> <helpop key="umodes" value="User Modes ---------- @@ -80,37 +830,41 @@ LOCKSERV UNLOCKSERV"> commonchans module). d Deaf mode. User will not receive any messages or notices from channels they are in (requires the deaf module). - g In combination with /ACCEPT, provides for server side + g In combination with /ACCEPT, provides for server-side ignore (requires the callerid module). - h Marks as 'available for help' in WHOIS (IRCop only, - requires the helpop module). + h Marks as 'available for help' in WHOIS (server operators + only, requires the helpop module). i Makes invisible to /WHO if the user using /WHO is not in a common channel. k Prevents the user from being kicked from channels, or having op modes removed from them (services only, requires the servprotect module). - o Marks as a IRC operator. + o Marks as a server operator. s <mask> Receives server notices specified by <mask> - (IRCop only). + (server operators only). r Marks as a having a registered nickname (requires the services account module). w Receives wallops messages. x Gives a cloaked hostname (requires the cloaking module). + z Only allow private messages from SSL users (requires the + sslmode module). B Marks as a bot (requires the botmode module). + D Privdeaf mode. User will not receive any private messages + or notices from users (requires the deaf module). G Censors messages sent to the user based on filters configured for the network (requires the censor module). H Hides an oper's oper status from WHOIS (requires the hideoper module). I Hides a user's entire channel list in WHOIS from - non-IRCops (requires the hidechans module). - L Stops redirections done by m_redirect (mode must be - enabled in the config). + non-server operators (requires the hidechans module). + L Stops redirections done by the redirect module (requires + the redirect module). R Blocks private messages from unregistered users (requires the services account module). S Strips formatting codes out of private messages to the user (requires the stripcolor module). - W Receives notification when a user uses WHOIS on them - (IRCop only, requires the showwhois module)."> + W Receives notifications when a user uses WHOIS on them + (server operators only, requires the showwhois module)."> <helpop key="chmodes" value="Channel Modes ------------- @@ -172,7 +926,8 @@ LOCKSERV UNLOCKSERV"> For example, +w o:R:Brain will op anyone identified to the account 'Brain' on join. (requires the autoop module) - z Blocks non-SSL clients from joining the channel. + z Blocks non-SSL clients from joining the channel + (requires the sslmodes module). A Allows anyone to invite users to the channel (normally only chanops can invite, requires @@ -184,6 +939,10 @@ LOCKSERV UNLOCKSERV"> noctcp module). D Delays join messages from users until they message the channel (requires the delayjoin module). + E [~|*]<lines>:<sec>[:<difference>][:<backlog>] Allows blocking of + similar messages (requires the repeat module). + Kicks as default, blocks with ~ and bans with * + The last two parameters are optional. F <changes>:<sec> Blocks nick changes when they equal or exceed the specified rate (requires the nickflood module). G Censors messages to the channel based on the @@ -195,7 +954,8 @@ LOCKSERV UNLOCKSERV"> J <seconds> Prevents rejoin after kick for the specified number of seconds. This prevents auto-rejoin (requires the kicknorejoin module). - K Blocks /KNOCK on the channel. + K Blocks /KNOCK on the channel (requires the + knock module). L <channel> If the channel reaches its limit set by +l, redirect users to <channel> (requires the redirect module). @@ -203,14 +963,14 @@ LOCKSERV UNLOCKSERV"> the services account module). N Prevents users on the channel from changing nick (requires the nonicks module). - O Channel is IRCops only (can only be set by IRCops, - requires the operchans module). + O Channel is server operators only (can only be set + by server operators, requires the operchans module). P Makes the channel permanent; Bans, invites, the topic, modes, and such will not be lost when it - empties (can only be set by IRCops, requires - the permchannels module). - Q Only ulined servers and their users can kick - (requires the nokicks module) + empties (can only be set by server operators, + requires the permchannels module). + Q Only U-lined servers and their users can kick + (requires the nokicks module). R Blocks unregistered users from joining (requires the services account module). S Strips formatting codes from messages to the @@ -220,6 +980,24 @@ LOCKSERV UNLOCKSERV"> X <type>:<status> Makes users of <status> or higher exempt to the specified restriction <type>. For example: flood:h (requires the exemptchanops module). + Possible restriction types to exempt with +X are: + + auditorium-see Permission required to see the full user list of + a +u channel (requires the auditorium module). + auditorium-vis Permission required to be visible in a +u channel + (requires the auditorium module). + blockcaps Channel mode +B + blockcolor Channel mode +c + censor Channel mode +G + filter Channel mode +g + flood Channel mode +f + nickflood Channel mode +F + noctcp Channel mode +C + nonick Channel mode +N + nonotice Channel mode +T + regmoderated Channel mode +M + stripcolor Channel mode +S + topiclock Channel mode +t ------------- NOTE: A large number of these modes are dependent upon server-side modules @@ -227,14 +1005,55 @@ being loaded by a server/network administrator. The actual modes available on your network may be very different to this list. Please consult your help channel if you have any questions."> +<helpop key="stats" value="/STATS <symbol> [<servername>] + +Shows various server statistics. Depending on configuration, some +symbols may be only available to opers. + +Valid symbols are: + +e Show E-lines (global user@host ban exceptions) +g Show G-lines (global user@host bans) +k Show K-lines (local user@host bans) +q Show Q-lines (global nick bans) +R Show R-lines (global regular expression bans) +Z Show Z-lines (global IP mask bans) + +s Show filters (global) +C Show channel bans (global) +H Show shuns (global) + +c Show link blocks +d Show configured DNSBLs and related statistics +m Show command statistics, number of times commands have been used +o Show a list of all valid oper usernames and hostmasks +p Show open client ports, and the port type (ssl, plaintext, etc) +u Show server uptime +z Show memory usage statistics +i Show connect class permissions +l Show all client connections with information (sendq, commands, bytes, time connected) +L Show all client connections with information and IP address +P Show online opers and their idle times +T Show bandwidth/socket statistics +U Show U-lined servers +Y Show connection classes +O Show opertypes and the allowed user and channel modes it can set +E Show socket engine events +S Show currently held registered nicknames +G Show how many local users are connected from each country + +Note that all /STATS use is broadcast to online server operators."> + <helpop key="snomasks" value="Server Notice Masks a Allows receipt of local announcement messages. A Allows receipt of remote announcement messages. c Allows receipt of local connect messages. C Allows receipt of remote connect messages. - d Allows receipt of general (and sometimes random) debug messages. - f Allows receipt of flooding notices. + d Allows receipt of local DNSBL messages (requires the dnsbl module). + D Allows receipt of remote DNSBL messages (requires the dnsbl module). + f Allows receipt of local filter messages (requires the filter module). + F Allows receipt of remote filter messages (requires the filter module). g Allows receipt of globops (requires the globops module). j Allows receipt of channel creation notices (requires the chancreate module). J Allows receipt of remote channel creation notices (requires the chancreate module). @@ -242,8 +1061,8 @@ help channel if you have any questions."> K Allows receipt of remote kill messages. l Allows receipt of local linking related messages. L Allows receipt of remote linking related messages. - n See local nickname changes (requires the seenicks module). - N See remote nickname changes (requires the seenicks modules). + n Allows receipt of local nickname changes (requires the seenicks module). + N Allows receipt of remote nickname changes (requires the seenicks modules). o Allows receipt of oper-up, oper-down, and oper-failure messages. O Allows receipt of remote oper-up, oper-down, and oper-failure messages. q Allows receipt of local quit messages. @@ -251,9 +1070,9 @@ help channel if you have any questions."> r Allows receipt of local oper commands (requires the operlog module). R Allows receipt of remote oper commands (requires the operlog module). t Allows receipt of attempts to use /STATS (local and remote). - v Allows receipt of oper-override notices (requires the override module). - x Allows receipt of local Xline notices (g/Z/q/k/e/R/shuns). - X Allows receipt of remote Xline notices (g/Z/q/k/e/R/shuns)."> + v Allows receipt of oper override notices (requires the override module). + x Allows receipt of local X-line notices (G/Z/Q/K/E/R/SHUN/CBan). + X Allows receipt of remote X-line notices (G/Z/Q/K/E/R/SHUN/CBan)."> <helpop key="extbans" value="Extended Bans ---------- @@ -271,16 +1090,22 @@ setting +I <extban>. Matching extbans: + a:<mask> Matches user with both a matching banmask and real name, + where <mask> is in the format nick!user@host+realname + (requires gecosban module). j:<channel> Matches anyone in the given channel. Does not support wildcards (requires the channelban module). - r:<realname> Matches users with a matching realname (requires the + n:<class> Matches users in a matching connect class (requires + the classban module). + r:<realname> Matches users with a matching real name (requires the gecosban module). s:<server> Matches users on a matching server (requires the serverban module). z:<certfp> Matches users having the given SSL certificate fingerprint (requires the sslmodes module). - O:<opertype> Matches IRCops of a matching type, mostly useful as an - an invite exception (requires the operchans module). + O:<opertype> Matches server operators of a matching type, mostly + useful as an invite exception (requires the + operchans module). R:<account> Matches users logged into a matching account (requires the services account module). U:<banmask> Matches unregistered users matching the given banmask. diff --git a/docs/conf/inspircd.conf.example b/docs/conf/inspircd.conf.example index d54cdc916..18b9cd366 100644 --- a/docs/conf/inspircd.conf.example +++ b/docs/conf/inspircd.conf.example @@ -34,6 +34,15 @@ # # ######################################################################## +#-#-#-#-#-#-#-#-#-# CONFIGURATION FORMAT #-#-#-#-#-#-#-#-#-#-#-#-#-#- +# # +# In order to maintain compatibility with older configuration files, # +# you can change the configuration parser to parse as it did in # +# previous releases. When using the "compat" format, you need to use # +# C++ escape sequences (e.g. \n) instead of XML ones (e.g. &nl;) and # +# can not use <define> to create macros. # +#<config format="compat"> + #-#-#-#-#-#-#-#-#-# INCLUDE CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-#-# # # # This optional tag allows you to include another config file # @@ -65,11 +74,6 @@ # # # Variables may be redefined and may reference other variables. # # Value expansion happens at the time the tag is read. # -# # -# Using variable definitions REQUIRES that the config format be # -# changed to "xml" from the default "compat" that uses escape # -# sequences such as "\"" and "\n", and does not support <define> # -<config format="xml"> <define name="bindip" value="1.2.2.3"> <define name="localips" value="&bindip;/24"> @@ -93,8 +97,7 @@ #id="97K" # network: Network name given on connect to clients. - # Should be the same on all servers on the network and - # not contain spaces. + # Should be the same on all servers on the network. network="Omega"> @@ -128,7 +131,7 @@ # |_| \_\___|\__,_|\__,_| |_| |_| |_|_|___/ |____/|_|\__(_) # # # # If you want to link servers to InspIRCd you must load the # -# m_spanningtree.so module! Please see the modules list for # +# spanningtree module! Please see the modules list for # # information on how to load this module! If you do not load this # # module, server ports will NOT work! # @@ -148,58 +151,59 @@ # to this bind section. type="clients" - # ssl: If you want the port(s) in this bind tag to use SSL, set this - # to either "gnutls" or "openssl". The appropriate SSL module must be - # loaded for SSL to work. If you do not want the port(s) in this bind - # tag to support SSL, just remove or comment out this option. + # ssl: If you want the port(s) in this bind tag to use SSL, set this to + # the name of a custom <sslprofile> tag that you have defined or one + # of "openssl", "gnutls", "mbedtls" if you have not defined any. See the + # docs page for the SSL module you are using for more details. + # + # You will need to load the ssl_openssl module for OpenSSL, ssl_gnutls + # for GnuTLS and ssl_mbedtls for mbedTLS. ssl="gnutls" + + # defer: When this is non-zero, connections will not be handed over to + # the daemon from the operating system before data is ready. + # In Linux, the value indicates the time period we'll wait for a + # connection to come up with data. Don't set it too low! + # In BSD the value is ignored; only zero and non-zero is possible. + # Windows ignores this parameter completely. + # Note: This does not take effect on rehash. + # To change it on a running bind, you'll have to comment it out, + # rehash, comment it in and rehash again. + defer="0" + + # free: When this is enabled the listener will be created regardless of + # whether the interface that provides the bind address is available. This + # is useful for if you are starting InspIRCd on boot when the server may + # not have brought the network interfaces up yet. + free="no" > <bind address="" port="6660-6669" type="clients"> -# When linking servers, the OpenSSL and GnuTLS implementations are completely -# link-compatible and can be used alongside each other -# on each end of the link without any significant issues. -# Supported SSL types are: "openssl" and "gnutls". -# You must load m_ssl_openssl for OpenSSL or m_ssl_gnutls for GnuTLS. +# Listener accepting HTML5 WebSocket connections. +# Requires the websocket module and SHA-1 hashing support (provided by the sha1 +# module). +#<bind address="" port="7002" type="clients" hook="websocket"> -<bind address="" port="7000,7001" type="servers"> -<bind address="1.2.3.4" port="7005" type="servers" ssl="openssl"> +# EXPERIMENTAL: Listener that binds on a UNIX endpoint instead of a TCP/IP endpoint: +#<bind path="/tmp/inspircd.sock" type="clients"> +# You can define a custom <sslprofile> tag which defines the SSL configuration +# for this listener. See the docs page for the SSL module you are using for +# more details. +# +# Alternatively, you can use one of the default SSL profiles which are created +# when you have not defined any: +# "openssl" (requires the ssl_openssl module) +# "gnutls" (requires the ssl_gnutls module) +# "mbedtls" (requires the ssl_mbedtls module) +# +# When linking servers, the OpenSSL, GnuTLS, and mbedTLS implementations are +# completely link-compatible and can be used alongside each other on each end +# of the link without any significant issues. -#-#-#-#-#-#-#-#-#-#- DIE/RESTART CONFIGURATION -#-#-#-#-#-#-#-#-#-#- -# # -# You can configure the passwords here which you wish to use for # -# the /DIE and /RESTART commands. Only trusted ircops who will # -# need this ability should know the die and restart password. # -# # - -<power - # hash: what hash these passwords are hashed with. - # Requires the module for selected hash (m_md5.so, m_sha256.so - # or m_ripemd160.so) be loaded and the password hashing module - # (m_password_hash.so) loaded. - # Options here are: "md5", "sha256" and "ripemd160", or one of - # these prefixed with "hmac-", e.g.: "hmac-sha256". - # Optional, but recommended. Create hashed passwords with: - # /mkpasswd <hash> <password> - #hash="sha256" - - # diepass: Password for opers to use if they need to shutdown (die) - # a server. - # - # IMPORTANT: leaving this field empty does not disable the use of - # the DIE command. In order to prevent the use of this command you - # should remove it from the command privileges of your opers. - diepass="" - - # restartpass: Password for opers to use if they need to restart - # a server. - # - # IMPORTANT: leaving this field empty does not disable the use of - # the RESTART command. In order to prevent the use of this command - # you should remove it from the command privileges of your opers. - restartpass=""> +<bind address="" port="7000,7001" type="servers"> +<bind address="1.2.3.4" port="7005" type="servers" ssl="openssl"> #-#-#-#-#-#-#-#-#-#- CONNECTIONS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# @@ -212,7 +216,7 @@ # -- It is important to note that connect tags are read from the -- # # TOP DOWN. This means that you should have more specific deny # # and allow tags at the top, progressively more general, followed # -# by a <connect allow="*" (should you wish to have one). # +# by a <connect allow="*"> (should you wish to have one). # # # # Connect blocks are searched twice for each user - once when the TCP # # connection is accepted, and once when the user completes their # @@ -245,25 +249,26 @@ # a CIDR range here. allow="203.0.113.*" - # hash: what hash this password is hashed with. requires the module - # for selected hash (m_md5.so, m_sha256.so or m_ripemd160.so) be - # loaded and the password hashing module (m_password_hash.so) - # loaded. Options here are: "md5", "sha256" and "ripemd160". - # Optional, but recommended. Create hashed passwords with: - # /mkpasswd <hash> <password> - #hash="sha256" + # hash: the hash function this password is hashed with. Requires the + # module for the selected function (bcrypt, md5, sha1, or sha256) and + # the password hashing module (password_hash) to be loaded. + # + # You may also use any of the above other than bcrypt prefixed with + # either "hmac-" or "pbkdf2-hmac-" (requires the pbkdf2 module). + # Create hashed passwords with: /MKPASSWD <hashtype> <plaintext> + #hash="bcrypt" # password: Password to use for this block/user(s) password="secret" # maxchans: Maximum number of channels a user in this class - # be in at one time. This overrides every other maxchans setting. - #maxchans="30" + # be in at one time. + maxchans="20" - # timeout: How long (in seconds) the server will wait before - # disconnecting a user if they do not do anything on connect. + # timeout: How long the server will wait before disconnecting + # a user if they do not do anything on connect. # (Note, this is a client-side thing, if the client does not - # send /nick, /user or /pass) + # send /NICK, /USER or /PASS) timeout="10" # localmax: Maximum local connections per IP (or CIDR mask, see below). @@ -275,26 +280,34 @@ # maxconnwarn: Enable warnings when localmax or globalmax are reached (defaults to on) maxconnwarn="off" + # resolvehostnames: If disabled, no DNS lookups will be performed on connecting users + # in this class. This can save a lot of resources on very busy servers. + resolvehostnames="yes" + # usednsbl: Defines whether or not users in this class are subject to DNSBL. Default is yes. - # This setting only has effect when m_dnsbl is loaded. + # This setting only has effect when the dnsbl module is loaded. #usednsbl="yes" # useident: Defines if users in this class MUST respond to a ident query or not. useident="no" + # webirc: Restricts usage of this class to the specified WebIRC gateway. + # This setting only has effect when the cgiirc module is loaded. + #webirc="name" + # limit: How many users are allowed in this class limit="5000" - # modes: Usermodes that are set on users in this block on connect. - # Enabling this option requires that the m_conn_umodes module be loaded. - # This entry is highly recommended to use for/with IP Cloaking/masking. - # For the example to work, this also requires that the m_cloaking + # modes: User modes that are set on users in this block on connect. + # Enabling this option requires that the conn_umodes module be loaded. + # This entry is highly recommended to use for/with IP cloaking/masking. + # For the example to work, this also requires that the cloaking # module be loaded as well. modes="+x" # requireident, requiressl, requireaccount: require that users of this # block have a valid ident response, use SSL, or have authenticated. - # Requires m_ident, m_sslinfo, or m_services_account respectively. + # Requires ident, sslinfo, or the services_account module, respectively. requiressl="on" # NOTE: For requireaccount, you must complete the signon prior to full # connection. Currently, this is only possible by using SASL @@ -303,19 +316,24 @@ # Alternate MOTD file for this connect class. The contents of this file are # specified using <files secretmotd="filename"> or <execfiles ...> + # + # NOTE: the following escape sequences for IRC formatting characters can be + # used in your MOTD: + # Bold: \b + # Color: \c<fg>[,<bg>] + # Italic: \i + # Monospace: \m (not widely supported) + # Reset: \x + # Reverse: \r + # Strikethrough: \s (not widely supported) + # Underline: \u + # See https://defs.ircdocs.horse/info/formatting.html for more information + # on client support for formatting characters. motd="secretmotd" - # Allow color codes to be processed in the message of the day file. - # the following characters are valid color code escapes: - # \002 or \b = Bold - # \037 or \u = Underline - # \003 or \c = Color (with a code postfixed to this char) - # \017 or \x = Stop all color sequences - allowmotdcolors="false" - - # port: What port this user is allowed to connect on. (optional) - # The port MUST be set to listen in the bind blocks above. - port="6697"> + # port: What port range this user is allowed to connect on. (optional) + # The ports MUST be set to listen in the bind blocks above. + port="6697,9999"> <connect # name: Name to use for this connect block. Mainly used for @@ -328,17 +346,17 @@ allow="*" # maxchans: Maximum number of channels a user in this class - # be in at one time. This overrides every other maxchans setting. - #maxchans="30" + # be in at one time. + maxchans="20" - # timeout: How long (in seconds) the server will wait before - # disconnecting a user if they do not do anything on connect. + # timeout: How long the server will wait before disconnecting + # a user if they do not do anything on connect. # (Note, this is a client-side thing, if the client does not - # send /nick, /user or /pass) + # send /NICK, /USER or /PASS) timeout="10" - # pingfreq: How often (in seconds) the server tries to ping connecting clients. - pingfreq="120" + # pingfreq: How often the server tries to ping connecting clients. + pingfreq="2m" # hardsendq: maximum amount of data allowed in a client's send queue # before they are dropped. Keep this value higher than the length of @@ -349,11 +367,11 @@ # softsendq: amount of data in a client's send queue before the server # begins delaying their commands in order to allow the sendq to drain - softsendq="8192" + softsendq="10240" # recvq: amount of data allowed in a client's queue before they are dropped. - # Entering "8K" is equivalent to "8192", see above. - recvq="8K" + # Entering "10K" is equivalent to "10240", see above. + recvq="10K" # threshold: This specifies the amount of command penalty a user is allowed to have # before being quit or fakelagged due to flood. Normal commands have a penalty of 1, @@ -384,16 +402,20 @@ # globalmax: Maximum global (network-wide) connections per IP. globalmax="3" + # resolvehostnames: If disabled, no DNS lookups will be performed on connecting users + # in this class. This can save a lot of resources on very busy servers. + resolvehostnames="yes" + # useident: Defines if users in this class must respond to a ident query or not. useident="no" # limit: How many users are allowed in this class limit="5000" - # modes: Usermodes that are set on users in this block on connect. - # Enabling this option requires that the m_conn_umodes module be loaded. - # This entry is highly recommended to use for/with IP Cloaking/masking. - # For the example to work, this also requires that the m_cloaking + # modes: User modes that are set on users in this block on connect. + # Enabling this option requires that the conn_umodes module be loaded. + # This entry is highly recommended to use for/with IP cloaking/masking. + # For the example to work, this also requires that the cloaking # module be loaded as well. modes="+x"> @@ -425,11 +447,11 @@ # This file has all the information about oper classes, types and o:lines. # You *MUST* edit it. -<include file="conf/examples/opers.conf.example"> +<include file="examples/opers.conf.example"> # This file has all the information about server links and ulined servers. # You *MUST* edit it if you intend to link servers. -<include file="conf/examples/links.conf.example"> +<include file="examples/links.conf.example"> #-#-#-#-#-#-#-#-#-#- MISCELLANEOUS CONFIGURATION -#-#-#-#-#-#-#-#-#-# # # @@ -437,23 +459,12 @@ # Files block - contains files whose contents are used by the ircd # # motd - displayed on connect and when a user executes /MOTD -# rules - displayed when the user executes /RULES # Modules can also define their own files -<files motd="conf/examples/motd.txt.example" rules="conf/examples/rules.txt.example"> +<files motd="examples/motd.txt.example"> # Example of an executable file include. Note this will be read on rehash, # not when the command is run. -#<execfiles rules="wget -O - https://www.example.com/rules.txt"> - -#-#-#-#-#-#-#-#-#-#-#-# MAXIMUM CHANNELS -#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# # - -<channels - # users: Maximum number of channels a user can be in at once. - users="20" - - # opers: Maximum number of channels an oper can be in at once. - opers="60"> +#<execfiles motd="wget -O - https://www.example.com/motd.txt"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-# DNS SERVER -#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # If these values are not defined, InspIRCd uses the default DNS resolver @@ -469,7 +480,7 @@ # # server="127.0.0.1" - # timeout: seconds to wait to try to resolve DNS/hostname. + # timeout: time to wait to try to resolve DNS/hostname. timeout="5"> # An example of using an IPv6 nameserver @@ -487,47 +498,27 @@ #<pid file="/path/to/inspircd.pid"> -#-#-#-#-#-#-#-#-#-#-#-#-#- BANLIST LIMITS #-#-#-#-#-#-#-#-#-#-#-#-#-#-# +#-#-#-#-#-#-#-#-#-#-#-#-#- LIST MODE LIMITS #-#-#-#-#-#-#-#-#-#-#-#-#-# # # -# Use these tags to customise the ban limits on a per channel basis. # -# The tags are read from top to bottom, and any tag found which # -# matches the channels name applies the banlimit to that channel. # +# The <maxlist> tag is used customise the maximum number of each list # +# mode that can be set on a channel. # +# The tags are read from top to bottom and the list mode limit from # +# the first tag found which matches the channel name and mode type is # +# applied to that channel. # # It is advisable to put an entry with the channel as '*' at the # -# bottom of the list. If none are specified or no maxbans tag is # -# matched, the banlist size defaults to 64 entries. # +# bottom of the list. If none are specified or no maxlist tag is # +# matched, the banlist size defaults to 100 entries. # # # -<banlist chan="#largechan" limit="128"> -<banlist chan="*" limit="69"> - -#-#-#-#-#-#-#-#-#-#-#- DISABLED FEATURES -#-#-#-#-#-#-#-#-#-#-#-#-#-# -# # -# This tag is optional, and specifies one or more features which are # -# not available to non-operators. # -# # -# For example you may wish to disable NICK and prevent non-opers from # -# changing their nicknames. # -# Note that any disabled commands take effect only after the user has # -# 'registered' (e.g. after the initial USER/NICK/PASS on connection) # -# so for example disabling NICK will not cripple your network. # -# # -# You can also define if you want to disable any channelmodes # -# or usermodes from your users. # -# # -# `fakenonexistant' will make the ircd pretend that nonexistant # -# commands simply don't exist to non-opers ("no such command"). # -# # -#<disabled commands="TOPIC MODE" usermodes="" chanmodes="" fakenonexistant="yes"> - - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- RTFM LINE -#-#-#-#-#-#-#-#-#-#-#-#-#-# -# # -# Just remove this... Its here to make you read ALL of the config # -# file options ;) # - -<die value="You should probably edit your config *PROPERLY* and try again."> +# Allows #largechan to have up to 200 ban entries. +#<maxlist mode="ban" chan="#largechan" limit="200"> +# Allows #largechan to have up to 200 ban exception entries. +#<maxlist mode="e" chan="#largechan" limit="200"> +# Allows all channels and list modes not previously matched to have +# up to 100 entries. +<maxlist chan="*" limit="100"> #-#-#-#-#-#-#-#-#-#-#-#-#- SERVER OPTIONS -#-#-#-#-#-#-#-#-#-#-#-#-# # # @@ -564,21 +555,19 @@ # the correct parameters are. syntaxhints="no" - # cyclehosts: If enabled, when a user gets a host set, it will cycle - # them in all their channels. If not, it will simply change their host - # without cycling them. - cyclehosts="yes" + # casemapping: This sets the case mapping method to be used by the + # server. This MUST be the same on all servers. Possible values are: + # "ascii" (recommended) + # "rfc1459" (default, required for linking to 2.0 servers) + # NOTE: if you are using the nationalchars module this setting will be + # ignored. You should use <nationalchars:casemapping> instead. + casemapping="ascii" # cyclehostsfromuser: If enabled, the source of the mode change for # cyclehosts will be the user who cycled. This can look nicer, but # triggers anti-takeover mechanisms of some obsolete bots. cyclehostsfromuser="no" - # ircumsgprefix: Use undernet-style message prefixing for NOTICE and - # PRIVMSG. If enabled, it will add users' prefix to the line, if not, - # it will just message the user normally. - ircumsgprefix="no" - # announcets: If set to yes, when the timestamp on a channel changes, all users # in the channel will be sent a NOTICE about it. announcets="yes" @@ -597,21 +586,33 @@ # in the topic. If set to no, it will only show the nick of the topic setter. hostintopic="yes" - # pingwarning: If a server does not respond to a ping within x seconds, + # pingwarning: If a server does not respond to a ping within this period, # it will send a notice to opers with snomask +l informing that the server # is about to ping timeout. pingwarning="15" - # serverpingfreq: How often pings are sent between servers (in seconds). - serverpingfreq="60" + # serverpingfreq: How often pings are sent between servers. + serverpingfreq="1m" + + # splitwhois: Whether to split private/secret channels from normal channels + # in WHOIS responses. Possible values for this are: + # 'no' - list all channels together in the WHOIS response regardless of type. + # 'split' - split private/secret channels to a separate WHOIS response numeric. + # 'splitmsg' - the same as split but also send a message explaining the split. + splitwhois="no" # defaultmodes: What modes are set on a empty channel when a user # joins it and it is unregistered. - defaultmodes="nt" + defaultmodes="not" - # moronbanner: This is the text that is sent to a user when they are + # xlinemessage: This is the text that is sent to a user when they are # banned from the server. - moronbanner="You're banned! Email abuse@example.com with the ERROR line below for help." + xlinemessage="You're banned! Email irc@example.com with the ERROR line below for help." + + # allowzerolimit: If enabled then allow a limit of 0 to be set on channels. + # This is non-standard behaviour and should only be enabled if you need to + # link with servers running 2.0. Defaults to yes. + allowzerolimit="no" # exemptchanops: Allows users with with a status mode to be exempt # from various channel restrictions. Possible restrictions are: @@ -646,18 +647,13 @@ # See m_exemptchanops in modules.conf.example for more details. exemptchanops="censor:o filter:o nickflood:o nonick:v regmoderated:o" - # invitebypassmodes: This allows /invite to bypass other channel modes. + # invitebypassmodes: This allows /INVITE to bypass other channel modes. # (Such as +k, +j, +l, etc.) invitebypassmodes="yes" # nosnoticestack: This prevents snotices from 'stacking' and giving you # the message saying '(last message repeated X times)'. Defaults to no. - nosnoticestack="no" - - # welcomenotice: When turned on, this sends a NOTICE to connecting users - # with the text Welcome to <networkname>! after successful registration. - # Defaults to yes. - welcomenotice="yes"> + nosnoticestack="no"> #-#-#-#-#-#-#-#-#-#-#-# PERFORMANCE CONFIGURATION #-#-#-#-#-#-#-#-#-#-# @@ -672,33 +668,41 @@ # in the accept queue. This is *NOT* the total maximum number of # connections per server. Some systems may only allow this to be up # to 5, while others (such as Linux and *BSD) default to 128. + # Setting this above the limit imposed by your OS can have undesired + # effects. somaxconn="128" - # limitsomaxconn: By default, somaxconn (see above) is limited to a - # safe maximum value in the 2.0 branch for compatibility reasons. - # This setting can be used to disable this limit, forcing InspIRCd - # to use the value specified above. - limitsomaxconn="true" - # softlimit: This optional feature allows a defined softlimit for # connections. If defined, it sets a soft max connections value. softlimit="12800" + # clonesonconnect: If this is set to false, we won't check for clones + # on initial connection, but only after the DNS check is done. + # This can be useful where your main class is more restrictive + # than some other class a user can be assigned after DNS lookup is complete. + # Turning this option off will make the server spend more time on users we may + # potentially not want. Normally this should be neglible, though. + # Default value is true + clonesonconnect="true" + + # timeskipwarn: The time period that a server clock can jump by before + # operators will be warned that the server is having performance issues. + timeskipwarn="2s" + # quietbursts: When syncing or splitting from a network, a server # can generate a lot of connect and quit messages to opers with # +C and +Q snomasks. Setting this to yes squelches those messages, # which makes it easier for opers, but degrades the functionality of # bots like BOPM during netsplits. - quietbursts="yes" - - # nouserdns: If enabled, no DNS lookups will be performed on - # connecting users. This can save a lot of resources on very busy servers. - nouserdns="no"> + quietbursts="yes"> #-#-#-#-#-#-#-#-#-#-#-# SECURITY CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-# # # <security + # allowcoreunload: If this value is set to yes, Opers will be able to + # unload core modules (e.g. core_privmsg). + allowcoreunload="no" # announceinvites: This option controls which members of the channel # receive an announcement when someone is INVITEd. Available values: @@ -709,33 +713,28 @@ # higher ranked users. This is the recommended setting. announceinvites="dynamic" - # hidemodes: If enabled, then the listmodes given will be hidden - # from users below halfop. This is not recommended to be set on +b - # as it may break some functionality in popular clients such as mIRC. - hidemodes="eI" - # hideulines: If this value is set to yes, U-lined servers will - # be hidden from non-opers in /links and /map. + # be hidden from non-opers in /LINKS and /MAP. hideulines="no" - # flatlinks: If this value is set to yes, /map and /links will + # flatlinks: If this value is set to yes, /MAP and /LINKS will # be flattened when shown to non-opers. flatlinks="no" - # hidewhois: When defined, the given text will be used in place - # of the server a user is on when whoised by a non-oper. Most - # networks will want to set this to something like "*.netname.net" - # to conceal the actual server a user is on. - # Note that enabling this will cause users' idle times to only be - # shown when the format /WHOIS <nick> <nick> is used. - hidewhois="" + # hideserver: When defined, the given text will be used in place + # of the server name in public messages. As with <server:name> this + # does not need to resolve but does need to be a valid hostname. + # + # NOTE: enabling this will cause users' idle times to only be shown + # when a remote whois (/WHOIS <nick> <nick>) is used. + #hideserver="*.example.com" - # hidebans: If this value is set to yes, when a user is banned ([gkz]lined) + # hidebans: If this value is set to yes, when a user is banned ([KGZ]-lined) # only opers will see the ban message when the user is removed # from the server. hidebans="no" - # hidekills: If defined, replaces who set a /kill with a custom string. + # hidekills: If defined, replaces who executed a /KILL with a custom string. hidekills="" # hideulinekills: Hide kills from clients of ulined servers from server notices. @@ -747,19 +746,13 @@ hidesplits="no" # maxtargets: Maximum number of targets per command. - # (Commands like /notice, /privmsg, /kick, etc) + # (Commands like /NOTICE, /PRIVMSG, /KICK, etc) maxtargets="20" - # customversion: Displays a custom string when a user /version's - # the ircd. This may be set for security reasons or vanity reasons. + # customversion: A custom message to be displayed in the comments field + # of the VERSION command response. This does not hide the InspIRCd version. customversion="" - # operspywhois: show opers (users/auspex) the +s and +p channels a user is in. Values: - # splitmsg Split secret/private from public channels with an explanatory message - # yes Show secret/private channels - # no Do not show secret/private channels - operspywhois="no" - # runasuser: If this is set, InspIRCd will attempt to switch # to run as this user, which allows binding of ports under 1024. # You should NOT set this unless you are starting as root. @@ -774,16 +767,17 @@ # restrictbannedusers: If this is set to yes, InspIRCd will not allow users # banned on a channel to change nickname or message channels they are - # banned on. + # banned on. This can also be set to silent to restrict the user but not + # notify them. restrictbannedusers="yes" # genericoper: Setting this value to yes makes all opers on this server - # appear as 'is an IRC operator' in their WHOIS, regardless of their + # appear as 'is a server operator' in their WHOIS, regardless of their # oper type, however oper types are still used internally. This only # affects the display in WHOIS. genericoper="no" - # userstats: /stats commands that users can run (opers can run all). + # userstats: /STATS commands that users can run (opers can run all). userstats="Pu"> #-#-#-#-#-#-#-#-#-#-#-#-# LIMITS CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-# @@ -804,7 +798,7 @@ <limits # maxnick: Maximum length of a nickname. - maxnick="31" + maxnick="30" # maxchan: Maximum length of a channel name. maxchan="64" @@ -813,7 +807,10 @@ maxmodes="20" # maxident: Maximum length of a ident/username. - maxident="11" + maxident="10" + + # maxhost: Maximum length of a hostname. + maxhost="64" # maxquit: Maximum length of a quit message. maxquit="255" @@ -824,12 +821,20 @@ # maxkick: Maximum length of a kick message. maxkick="255" - # maxgecos: Maximum length of a GECOS (realname). - maxgecos="128" + # maxreal: Maximum length of a real name. + maxreal="128" # maxaway: Maximum length of an away message. maxaway="200"> +#-#-#-#-#-#-#-#-#-#-#-#-# PATHS CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# +# # +# This configuration tag defines the location that InspIRCd stores # +# various types of files such as configuration files, log files and # +# modules. You will probably not need to change these from the values # +# set when InspIRCd was built unless you are using a binary package # +# where you do not have the ability to set build time configuration. # +#<path configdir="conf" datadir="data" logdir="logs" moduledir="modules"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Logging @@ -839,8 +844,8 @@ # the behaviour of the logging of the IRCd. # # An example log tag would be: -# <log method="file" type="OPER" level="default" target="logs/opers.log"> -# which would log all information on /oper (failed and successful) to +# <log method="file" type="OPER" level="default" target="opers.log"> +# which would log all information on /OPER (failed and successful) to # a file called opers.log. # # There are many different types which may be used, and modules may @@ -848,8 +853,7 @@ # - USERS - information relating to user connection and disconnection # - OPER - succesful and failed oper attempts # - KILL - kill related messages -# - snomask - server notices (*all* snomasks will be logged) -# - FILTER - messages related to filter matches (m_filter) +# - FILTER - messages related to filter matches (filter module) # - CONFIG - configuration related messages # - COMMAND - die and restart messages, and messages related to unknown user types # - SOCKET - socket engine informational/error messages @@ -873,24 +877,29 @@ # - USERINPUT # - USEROUTPUT # +# If your server is producing a high levels of log messages you can also set the +# flush="[positive number]" attribute to specify how many log messages should be +# buffered before flushing to disk. You should probably not specify this unless +# you are having problems. +# # The following log tag is highly default and uncustomised. It is recommended you # sort out your own log tags. This is just here so you get some output. -<log method="file" type="* -USERINPUT -USEROUTPUT" level="default" target="logs/ircd.log"> +<log method="file" type="* -USERINPUT -USEROUTPUT" level="default" target="ircd.log"> #-#-#-#-#-#-#-#-#-#-#-#-#- WHOWAS OPTIONS -#-#-#-#-#-#-#-#-#-#-#-#-# # # -# This tag lets you define the behaviour of the /whowas command of # +# This tag lets you define the behaviour of the /WHOWAS command of # # your server. # # # <whowas # groupsize: Maximum entries per nick shown when performing - # a /whowas nick. + # a /WHOWAS <nick>. groupsize="10" # maxgroups: Maximum number of nickgroups that can be added to - # the list so that /whowas does not use a lot of resources on + # the list so that /WHOWAS does not use a lot of resources on # large networks. maxgroups="100000" @@ -918,12 +927,8 @@ # nick: Nick to disallow. Wildcards are supported. nick="ChanServ" - # reason: Reason to display on /nick. - reason="Reserved For Services"> - -<badnick nick="NickServ" reason="Reserved For Services"> -<badnick nick="OperServ" reason="Reserved For Services"> -<badnick nick="MemoServ" reason="Reserved For Services"> + # reason: Reason to display on /NICK. + reason="Reserved for a network service"> <badhost # host: ident@hostname to ban. @@ -936,25 +941,25 @@ <badhost host="root@*" reason="Don't IRC as root!"> <badhost host="*@198.51.100.0/24" reason="This subnet is bad."> -# exception: Hosts that are exempt from [kgz]lines. +# exception: Hosts that are exempt from [KGZ]-lines. <exception # host: ident@hostname to exempt. # Wildcards and CIDR (if you specify an IP) can be used. - host="*@ircop.example.com" + host="*@serverop.example.com" - # reason: Reason for exception. Only shown in /stats e + # reason: Reason for exception. Only shown in /STATS e. reason="Oper's hostname"> #-#-#-#-#-#-#-#-#-#-#- INSANE BAN OPTIONS -#-#-#-#-#-#-#-#-#-#-#-#-#-# # # -# This optional tag allows you to specify how wide a gline, eline, # -# kline, zline or qline can be before it is forbidden from being # -# set. By setting hostmasks="yes", you can allow all G, K, E lines, # +# This optional tag allows you to specify how wide a G-line, E-line, # +# K-line, Z-line or Q-line can be before it is forbidden from being # +# set. By setting hostmasks="yes", you can allow all G-, K-, E-lines, # # no matter how many users the ban would cover. This is not # -# recommended! By setting ipmasks="yes", you can allow all Z lines, # +# recommended! By setting ipmasks="yes", you can allow all Z-lines, # # no matter how many users these cover too. Needless to say we # # don't recommend you do this, or, set nickmasks="yes", which will # -# allow any qline. # +# allow any Q-line. # # # <insane @@ -973,13 +978,6 @@ # will be banning 955 or more users. trigger="95.5"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- YAWN -#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# # -# You should already know what to do here :) # - -<die value="User error. You didn't edit your config properly. Go back and try again."> - #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# MODULES #-#-#-#-#-#-#-#-#-#-#-#-#-#-# # ____ _ _____ _ _ ____ _ _ _ # # | _ \ ___ __ _ __| | |_ _| |__ (_)___ | __ )(_) |_| | # @@ -994,23 +992,22 @@ # provide almost all the features of InspIRCd. :) # # # # The default does nothing -- we include it for simplicity for you. # -<include file="conf/examples/modules.conf.example"> +<include file="examples/modules.conf.example"> -# Here are some pre-built modules.conf files that closely match the -# default configurations of some popular IRCd's. You still may want to -# look over them and make sure if everything is correct for you and setup -# the proper SSL information. +#-#-#-#-#-#-#-#-#-#-#-# SERVICES CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-# +# # +# If you use services you will probably want to include one of the # +# following files which set up aliases, nick reservations and filter # +# exemptions for services pseudoclients: # # -# *NOTE*: These files have no comments for what the modules do. If you -# are interested in that, please read the modules.conf.example. It is also -# recommended that you make your own modules file based on modules.conf.example. - -# Settings similar to UnrealIRCd defaults. -#<include file="conf/examples/modules/unrealircd.conf.example"> - -# Settings similar to Charybdis IRCd defaults. -#<include file="conf/examples/modules/charybdis.conf.example"> - +# Anope users should uncomment this: +#<include file="examples/services/anope.conf.example"> +# +# Atheme users should uncomment this: +#<include file="examples/services/atheme.conf.example"> +# +# Users of other services should uncomment this: +#<include file="examples/services/generic.conf.example"> ######################################################################### # # diff --git a/docs/conf/links.conf.example b/docs/conf/links.conf.example index 8d62bb42f..09b3bb3d5 100644 --- a/docs/conf/links.conf.example +++ b/docs/conf/links.conf.example @@ -10,7 +10,7 @@ # |_| \_\___|\__,_|\__,_| |_| |_| |_|_|___/ |____/|_|\__(_) # # # # If you want to link servers to InspIRCd you must load the # -# m_spanningtree.so module! # +# spanningtree module! # # # # # @@ -29,26 +29,28 @@ # allowmask: Range of IP addresses to allow for this link. # Can be a CIDR (see example). - allowmask="203.0.113.0/24" + allowmask="203.0.113.0/24 127.0.0.0/8 2001:db8::/32" # timeout: If defined, this option defines how long the server # will wait to consider the connect attempt failed and try the # failover (see above). - timeout="300" + timeout="5m" - # ssl: If defined, this states the SSL module that will be used when - # making an outbound connection to the server. Options are: "openssl" - # and "gnutls" (they are compatible with each other). + # ssl: If defined, this states the SSL profile that will be used when + # making an outbound connection to the server. Options are the name of an + # <sslprofile> tag that you have defined or one of "openssl", "gnutls", + # "mbedtls" if you have not defined any. See the docs page for the SSL + # module you are using for more details. # - # You will need to load the m_ssl_openssl.so module for OpenSSL, - # m_ssl_gnutls.so for GnuTLS. The server port that you connect to - # must be capable of accepting this type of connection. + # You will need to load the ssl_openssl module for OpenSSL, ssl_gnutls + # for GnuTLS and ssl_mbedtls for mbedTLS. The server port that you + # connect to must be capable of accepting this type of connection. ssl="gnutls" # fingerprint: If defined, this option will force servers to be - # authenticated using SSL Fingerprints. See http://docs.inspircd.org/2/modules/spanningtree - # for more information. This will require an SSL link for both inbound - # and outbound connections. + # authenticated using SSL certificate fingerprints. See + # https://docs.inspircd.org/3/modules/spanningtree for more information. + # This will require an SSL link for both inbound and outbound connections. #fingerprint="" # bind: Local IP address to bind to. @@ -62,20 +64,20 @@ # servers will not be shown when users do a /MAP or /LINKS. hidden="no" - # passwords: the passwords we send and receive. + # passwords: The passwords we send and receive. # The remote server will have these passwords reversed. # Passwords that contain a space character or begin with # a colon (:) are invalid and may not be used. sendpass="outgoing!password" recvpass="incoming!password"> -# A duplicate of the first link block without comments +# A duplicate of the first link block without comments, # if you like copying & pasting. <link name="hub.example.org" ipaddr="penguin.example.org" port="7000" - allowmask="203.0.113.0/24" - timeout="300" + allowmask="203.0.113.0/24 127.0.0.0/8 2001:db8::/32" + timeout="5m" ssl="gnutls" bind="1.2.3.4" statshidden="no" @@ -92,27 +94,31 @@ sendpass="penguins" recvpass="polarbears"> -# Simple autoconnect block. This enables automatic connection of a server +# Simple autoconnect block. This enables automatic connections to a server. # Recommended setup is to have leaves connect to the hub, and have no # automatic connections started by the hub. -<autoconnect period="300" server="hub.example.org"> +<autoconnect period="10m" server="hub.example.org"> # Failover autoconnect block. If you have multiple hubs, or want your network # to automatically link even if the hub is down, you can specify multiple # space separated servers to autoconnect; they will be tried in a round # robin fashion until one succeeds. Period defines the time for restarting # a single loop. -<autoconnect period="120" +<autoconnect period="2m" server="hub.us.example.org hub.eu.example.org leaf.eu.example.org"> -#-#-#-#-#-#-#-#-#-#-#-#- ULINES CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# -# This tag defines a ulined server. A U-Lined server has special # -# permissions, and should be used with caution. Services servers are # -# usually u-lined in this manner. # -# # -# The 'silent' value, if set to yes, indicates that this server should# -# not generate quit and connect notices, which can cut down on noise # -# to opers on the network. # -# # +#-#-#-#-#-#-#-#-#-#-#-#-# U-LINES CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# +# This tag defines a U-lined server. A U-lined server has special # +# permissions, and should be used with caution. Services servers are # +# usually U-lined in this manner. # +# # +# The 'silent' value, if set to yes, indicates that this server should # +# not generate quit and connect notices, which can cut down on noise # +# to opers on the network. # +# # <uline server="services.example.com" silent="yes"> + +# Once you have edited this file you can remove this line. This is just to +# ensure that you don't hastily include the file without reading it. +<die reason="Using links.conf.example without editing it is a security risk"> diff --git a/docs/conf/modules.conf.example b/docs/conf/modules.conf.example index 65d34e70f..517c55720 100644 --- a/docs/conf/modules.conf.example +++ b/docs/conf/modules.conf.example @@ -10,7 +10,7 @@ # # # By default, ALL modules are commented out. You must uncomment them # # or add lines to your config to load modules. Please refer to # -# https://docs.inspircd.org/2/modules for a list of modules and # +# https://docs.inspircd.org/3/modules for a list of modules and # # each modules link for any additional conf tags they require. # # # # ____ _ _____ _ _ ____ _ _ _ # @@ -19,8 +19,8 @@ # | _ < __/ (_| | (_| | | | | | | | \__ \ | |_) | | |_|_| # # |_| \_\___|\__,_|\__,_| |_| |_| |_|_|___/ |____/|_|\__(_) # # # -# To link servers to InspIRCd, you MUST load the m_spanningtree # -# module. If you don't do this, server links will NOT work at all. # +# To link servers to InspIRCd, you MUST load the spanningtree module. # +# If you don't do this, server links will NOT work at all. # # This is by design, to allow for the implementation of other linking # # protocols in modules in the future. This module is at the bottom of # # this file. # @@ -31,38 +31,31 @@ # cryptographic uses and security. # # IMPORTANT: -# Other modules such as m_cloaking.so and m_password_hash.so may rely on +# Other modules such as cloaking and password_hash may rely on # this module being loaded to function. # -#<module name="m_md5.so"> -# +#<module name="md5"> + #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SHA256 module: Allows other modules to generate SHA256 hashes, # usually for cryptographic uses and security. # # IMPORTANT: -# Other modules such as m_password_hash.so may rely on this module being -# loaded to function. Certain modules such as m_spanningtree.so will +# Other modules such as password_hash may rely on this module being +# loaded to function. Certain modules such as spanningtree will # function without this module but when it is loaded their features will # be enhanced (for example the addition of HMAC authentication). # -#<module name="m_sha256.so"> -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# RIPEMD160 module: Allows other modules to generate RIPEMD160 hashes, -# usually for cryptographic uses and security. -# -# IMPORTANT: -# Other modules may rely on this module being loaded to function. -#<module name="m_ripemd160.so"> +#<module name="sha256"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Abbreviation module: Provides the ability to abbreviate commands a-la # BBC BASIC keywords. -#<module name="m_abbreviation.so"> +#<module name="abbreviation"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Alias module: Allows you to define server-side command aliases. -#<module name="m_alias.so"> +#<module name="alias"> # # Set the 'prefix' for in-channel aliases (fantasy commands) to the # specified character. If not set, the default is "!". @@ -72,9 +65,9 @@ # #-#-#-#-#-#-#-#-#-#-#- ALIAS DEFINITIONS -#-#-#-#-#-#-#-#-#-#-#-#-#-# # # -# If you have the m_alias.so module loaded, you may also define # -# aliases as shown below. They are commonly used to provide shortcut # -# commands to services, however they are not limited to just this use.# +# If you have the alias module loaded, you may also define aliases as # +# shown below. They are commonly used to provide shortcut commands to # +# services, however they are not limited to just this use. # # An alias tag requires the following values to be defined in it: # # # # text - The text to detect as the actual command line. # @@ -86,7 +79,7 @@ # read from the top of the file to the bottom. # # # # usercommand - If this is true, the alias can be run simply as # -# /aliasname. Defaults to true. # +# /ALIASNAME. Defaults to true. # # # # channelcommand - If this is true, the alias can be used as an # # in-channel alias or 'fantasy command', prefixed # @@ -124,9 +117,9 @@ # the user receives a 'no such nick' 401 numeric. # # # # uline - Setting this to true will ensure that the user # -# given in 'requires' is also on a u-lined server, # +# given in 'requires' is also on a U-lined server, # # as well as actually being on the network. If the # -# user is online, but not on a u-lined server, # +# user is online, but not on a U-lined server, # # then an oper alert is sent out as this is # # possibly a sign of a user trying to impersonate # # a service. # @@ -135,34 +128,21 @@ # If a non-oper attempts to use the alias, it will # # appear to not exist. # # # -#<alias text="NICKSERV" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -#<alias text="CHANSERV" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -#<alias text="OPERSERV" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -#<alias text="BOTSERV" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -#<alias text="HOSTSERV" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -#<alias text="MEMOSERV" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -#<alias text="NS" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -#<alias text="CS" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -#<alias text="OS" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -#<alias text="BS" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -#<alias text="HS" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -#<alias text="MS" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> # # An example of using the format value to create an alias with two # different behaviours depending on the format of the parameters. # -#<alias text="ID" format="#*" replace="PRIVMSG ChanServ :IDENTIFY $2 $3" +#<alias text="ID" format="#*" replace="SQUERY ChanServ :IDENTIFY $2 $3" # requires="ChanServ" uline="yes"> # -#<alias text="ID" replace="PRIVMSG NickServ :IDENTIFY $2" +#<alias text="ID" replace="SQUERY NickServ :IDENTIFY $2" # requires="NickServ" uline="yes"> # # This alias fixes a glitch in xchat 2.6.x and above and the way it # assumes IDENTIFY must be prefixed by a colon (:) character. It should -# be placed ABOVE the default NICKSERV alias (the first example) listed -# above. +# be placed ABOVE the default NICKSERV alias. # -#<alias text="NICKSERV" format=":IDENTIFY *" replace="PRIVMSG NickServ :IDENTIFY $3-" +#<alias text="NICKSERV" format=":IDENTIFY *" replace="SQUERY NickServ :IDENTIFY $3-" # requires="NickServ" uline="yes"> # # You may also add aliases to trigger based on something said in a @@ -171,7 +151,7 @@ # command must be preceded by the fantasy prefix when used. # #<alias text="CS" usercommand="no" channelcommand="yes" -# replace="PRIVMSG ChanServ :$1 $chan $2-" requires="ChanServ" uline="yes"> +# replace="SQUERY ChanServ :$1 $chan $2-" requires="ChanServ" uline="yes"> # # This would be used as "!cs <command> <options>", with the channel # being automatically inserted after the command in the message to @@ -180,18 +160,32 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Allowinvite module: Gives channel mode +A to allow all users to use # /INVITE, and extban A to deny invite from specific masks. -#<module name="m_allowinvite.so"> +#<module name="allowinvite"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Alltime module: Shows time on all connected servers at once. # This module is oper-only and provides /ALLTIME. # To use, ALLTIME must be in one of your oper class blocks. -#<module name="m_alltime.so"> +#<module name="alltime"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Anticaps module: Adds channel mode +B which allows you to punish +# users that send overly capitalised messages to channels. Unlike the +# blockcaps module this module is more flexible as it has more options +# for punishment and allows channels to configure their own punishment +#Â policies. +#<module name="anticaps"> +# +# You may also configure the characters which anticaps considers to be +# lower case and upper case. Any characters not listed here are assumed +# to be punctuation and will be ignored when counting: +# <anticaps lowercase="abcdefghijklmnopqrstuvwxyz" +# uppercase="ABCDEFGHIJKLMNOPQRSTUVWXYZ"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Auditorium module: Adds channel mode +u which makes everyone else # except you in the channel invisible, used for large meetings etc. -#<module name="m_auditorium.so"> +#<module name="auditorium"> # # Auditorium settings: # @@ -215,28 +209,37 @@ # Another useful combination is with SSL client certificate # fingerprints: +w h:z:72db600734bb9546c1bdd02377bc21d2a9690d48 will # give halfop to the user(s) having the given certificate. -#<module name="m_autoop.so"> +#<module name="autoop"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Ban except module: Adds support for channel ban exceptions (+e). -#<module name="m_banexception.so"> +#<module name="banexception"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Ban redirection module: Allows bans which redirect to a specified # channel. e.g. +b nick!ident@host#channelbanneduserissentto -#<module name="m_banredirect.so"> +#<module name="banredirect"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# bcrypt module: Allows other modules to generate bcrypt hashes, +# usually for cryptographic uses and security. +#<module name="bcrypt"> +# +# rounds: Defines how many rounds the bcrypt function will run when +# generating new hashes. +#<bcrypt rounds="10"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Block amsg module: Attempt to block all usage of /amsg and /ame. -#<module name="m_blockamsg.so"> +#<module name="blockamsg"> # #-#-#-#-#-#-#-#-#-#-#- BLOCKAMSG CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# If you have the m_blockamsg.so module loaded, you can configure it # -# with the <blockamsg> tag: # +# If you have the blockamsg module loaded, you can configure it with # +# the <blockamsg> tag: # # # -# delay - How many seconds between two messages to force # -# them to be recognised as unrelated. # +# delay - How much time between two messages to force them # +# to be recognised as unrelated. # # action - Any of 'notice', 'noticeopers', 'silent', 'kill' # # or 'killopers'. Define how to take action when # # a user uses /amsg or /ame. # @@ -245,114 +248,145 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Block CAPS module: Adds channel mode +B, blocks all-CAPS messages. -#<module name="m_blockcaps.so"> +# +# NOTE: This module is deprecated and will be removed in a future version +# of InspIRCd. You should use the anticaps module shown above instead. +#<module name="blockcaps"> # #-#-#-#-#-#-#-#-#-#-#- BLOCKCAPS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# percent - How many percent of text must be caps before text # +# percent - The percentage of a message which must be upper # +# case before it will be blocked. # +# # +# minlen - The minimum length a message must be before it # # will be blocked. # # # -# minlen - The minimum length a line must be for the block # -# percent to have any effect. # +# lowercase - The characters which will be considered lower # +# case. # # # -# capsmap - A list of chars to be considered CAPS. Can be used # -# to add CAPS characters for your language. Also you # -# can add things like ! and space to further lock # -# down on caps usage. # +# uppercase - The characters which will be considered upper # +# case. # +# #<blockcaps percent="50" # minlen="5" -# capsmap="ABCDEFGHIJKLMNOPQRSTUVWXYZ! "> +# lowercase="abcdefghijklmnopqrstuvwxyz" +# uppercase="ABCDEFGHIJKLMNOPQRSTUVWXYZ"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Block color module: Blocking color-coded messages with chan mode +c. -#<module name="m_blockcolor.so"> +#<module name="blockcolor"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Botmode module: Adds the user mode +B. If set on a user, it will # show that the user is a bot in /WHOIS. -#<module name="m_botmode.so"> +#<module name="botmode"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# CallerID module: Adds usermode +g which activates hybrid-style +# CallerID module: Adds user mode +g which activates hybrid-style # callerid: block all private messages unless you /ACCEPT first. -#<module name="m_callerid.so"> +#<module name="callerid"> # #-#-#-#-#-#-#-#-#-#-#- CALLERID CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# maxaccepts - Maximum number of entries a user can add to his # -# /ACCEPT list. Default is 16 entries. # -# operoverride - Can opers (note: ALL opers) override callerid? # -# Default is no. # -# tracknick - Preserve /accept entries when a user changes nick? # +# maxaccepts - Maximum number of entries a user can add to their # +# /ACCEPT list. Default is 30 entries. # +# tracknick - Preserve /ACCEPT entries when a user changes nick? # # If no (the default), the user is removed from # -# everyone's accept list if he changes nickname. # -# cooldown - Amount of time (in seconds) that must pass since # -# the last notification sent to a user before he can # -# be sent another. Default is 60 (1 minute). # -#<callerid maxaccepts="16" -# operoverride="no" +# everyone's accept list if their nickname changes. # +# cooldown - Amount of time that must pass since the last # +# notification sent to a user before they can be # +# sent another. Default is 1 minute. # +#<callerid maxaccepts="30" # tracknick="no" -# cooldown="60"> +# cooldown="1m"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # CAP module: Provides the CAP negotiation mechanism required by the -# m_sasl, m_namesx, m_uhnames, and m_ircv3 modules. -# It is also recommended for the STARTTLS support in m_ssl_gnutls. -#<module name="m_cap.so"> +# sasl, namesx, uhnames, and ircv3 modules. +# It is also recommended for STARTTLS support in the starttls module. +#<module name="cap"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # CBAN module: Lets you disallow channels from being used at runtime. # This module is oper-only and provides /CBAN. # To use, CBAN must be in one of your oper class blocks. -#<module name="m_cban.so"> +#<module name="cban"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Censor module: Adds channel and user mode +G. -#<module name="m_censor.so"> +# Censor module: Adds channel and user mode +G which block phrases that +# are listed in the server bad words list. +#<module name="censor"> # #-#-#-#-#-#-#-#-#-#-#- CENSOR CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# Optional - If you specify to use the m_censor module, then you must # -# specify some censor tags. See also: # -# https://docs.inspircd.org/2/modules/censor # -# -#<include file="conf/examples/censor.conf.example"> +# If you have the censor module loaded you should specify one or more # +# phrases to replace/block in user messages. The config for this is # +# formatted as follows: # +# # +# Replaces "eggplant" with "aubergine" within messages: # +# <badword text="eggplant" replace="aubergine"> # +# # +# Blocks messages that contain "fluffy capybaras": # +#<badword text="fluffy capybaras"> # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# CGI:IRC module: Adds support for automatic host changing in CGI:IRC -# (http://cgiirc.sourceforge.net). -#<module name="m_cgiirc.so"> +# CGI:IRC module: Enables forwarding the real IP address of a user from +# a gateway to the IRC server. +#<module name="cgiirc"> # #-#-#-#-#-#-#-#-#-#-#-# CGIIRC CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# # -# Optional - If you specify to use m_cgiirc, then you must specify one -# or more cgihost tags which indicate authorised CGI:IRC servers which -# will be connecting to your network, and an optional cgiirc tag. -# For more information see: https://docs.inspircd.org/2/modules/cgiirc -# -# Set to yes if you want to notice opers when CGI:IRC clients connect. +# If you use the cgiirc module then you must specify the gateways which +# are authorised to forward IP/host information to your server. There +# are currently two ways to do this: +# +# The webirc method is the recommended way to allow gateways to forward +# IP/host information. When using this method the gateway sends a WEBIRC +# message to the server on connection. For more details please read the +# IRCv3 WebIRC specification at: https://ircv3.net/specs/extensions/webirc.html +# +# When using this method you must specify a wildcard mask or CIDR range +# to allow gateway connections from and at least one of either a SSL +# client certificate fingerprint for the gateway or a password to be +# sent in the WEBIRC command. +# +# <cgihost type="webirc" +# fingerprint="bd90547b59c1942b85f382bc059318f4c6ca54c5" +# mask="192.0.2.0/24"> +# <cgihost type="webirc" +# password="$2a$10$WEUpX9GweJiEF1WxBDSkeODBstIBMlVPweQTG9cKM8/Vd58BeM5cW" +# hash="bcrypt" +# mask="*.webirc.gateway.example.com"> +# +# Alternatively if your gateway does not support sending the WEBIRC +# message then you can configure InspIRCd to look for the client IP +# address in the ident sent by the user. This is not recommended as it +# only works with IPv4 connections. +# +# When using this method you must specify a wildcard mask or CIDR range to allow +# gateway connections from. You can also optionally configure the static value +# that replaces the IP in the ident to avoid leaking the real IP address of +# gateway clients (defaults to "gateway" if not set). +# +# <cgihost type="ident" +# mask="198.51.100.0/24" +# newident="wibble"> +# <cgihost type="ident" +# mask="*.ident.gateway.example.com" +# newident="wobble"> +# +# By default gateway connections are logged to the +w snomask. If you +# do not want this to happen then you can uncomment this to disable it. # <cgiirc opernotice="no"> -# -# The type field indicates where the module should get the real -# client's IP address from, for further information, please see the -# CGI:IRC documentation. -# -# Old style: -# <cgihost type="pass" mask="www.example.com"> # Get IP from PASS -# <cgihost type="ident" mask="otherbox.example.com"> # Get IP from ident -# <cgihost type="passfirst" mask="www.example.com"> # See the docs -# New style: -# <cgihost type="webirc" password="foobar" -# mask="somebox.example.com"> # Get IP from WEBIRC -# + # IMPORTANT NOTE: # --------------- # -# When you connect CGI:IRC clients, there are two connect classes which +# When you connect gateway clients, there are two connect classes which # apply to these clients. When the client initially connects, the connect -# class which matches the CGI:IRC site's host is checked. Therefore you -# must raise the maximum local/global clients for this ip as high as you -# want to allow cgi clients. After the client has connected and is -# determined to be a cgi:irc client, the class which matches the client's +# class which matches the gateway site's host is checked. Therefore you +# must raise the maximum local/global clients for this IP as high as you +# want to allow gateway clients. After the client has connected and is +# determined to be a gateway client, the class which matches the client's # real IP is then checked. You may set this class to a lower value, so that # the real IP of the client can still be restricted to, for example, 3 # sessions maximum. @@ -361,30 +395,35 @@ # Channel create module: Adds snomask +j, which will notify opers of # any new channels that are created. # This module is oper-only. -#<module name="m_chancreate.so"> +#<module name="chancreate"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Channel filter module: Allows channel-op defined message filtering # using simple string matches (channel mode +g). -#<module name="m_chanfilter.so"> +#<module name="chanfilter"> # # If hidemask is set to yes, the user will not be shown the mask when # his/her message is blocked. -#<chanfilter hidemask="yes"> +# +# If maxlen is set then it defines the maximum length of a filter entry. +# +# If notifyuser is set to no, the user will not be notified when +# his/her message is blocked. +#<chanfilter hidemask="yes" maxlen="50" notifyuser="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Channel history module: Displays the last 'X' lines of chat to a user # joining a channel with +H 'X:T' set; 'T' is the maximum time to keep # lines in the history buffer. Designed so that the new user knows what # the current topic of conversation is when joining the channel. -#<module name="m_chanhistory.so"> +#<module name="chanhistory"> # # Set the maximum number of lines allowed to be stored per channel below. # This is the hard limit for 'X'. # If notice is set to yes, joining users will get a NOTICE before playback # telling them about the following lines being the pre-join history. # If bots is set to yes, it will also send to users marked with +B -#<chanhistory maxlines="20" notice="yes" bots="yes"> +#<chanhistory maxlines="50" notice="yes" bots="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Channel logging module: Used to send snotice output to channels, to @@ -393,7 +432,7 @@ # The "channel" field is where you want the messages to go, "snomasks" # is what snomasks you want to be sent to that channel. Multiple tags # are allowed. -#<module name="m_chanlog.so"> +#<module name="chanlog"> #<chanlog snomasks="AOcC" channel="#opers"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# @@ -401,7 +440,7 @@ # characters in the channel name such as bold, colorcodes, etc. which # can be quite annoying and allow users to on occasion have a channel # that looks like the name of another channel on the network. -#<module name="m_channames.so"> +#<module name="channames"> #<channames # denyrange: characters or range of characters to deny in channel @@ -414,40 +453,13 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Channelban: Implements extended ban j:, which stops anyone already -# in a channel matching a ban like +b j:#channel*mask from joining. +# in a channel matching a ban like +b j:#channel from joining. +# It is also possible to ban based on their status in that channel, +# like so: +b j:@#channel, this example prevents the ops from joining. # Note that by default wildcard characters * and ? are allowed in -# channel names. To disallow them, load m_channames and add characters -# 42 and 63 to denyrange (see above). -#<module name="m_channelban.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Chanprotect module: Gives +q and +a channel modes. -# -# IMPORTANT: This module has been removed in the next major version of -# InspIRCd. You should use m_customprefix instead. -#<module name="m_chanprotect.so"> - -#<chanprotect - # noservices: With this set to yes, when a user joins an empty channel, - # the server will set +q on them. If set to no, it will only set +o - # on them until they register the channel. - #noservices="no" - - # qprefix: Prefix (symbol) to use for +q users. - #qprefix="~" - - # aprefix: Prefix (symbol) to use for +a users. - #aprefix="&" - - # deprotectself: If this value is set (true, yes or 1), it will allow - # +a and +q users to remove the +a and +q from themselves, otherwise, - # the status will have to be removed by services. - #deprotectself="yes" - - # deprotectothers: If this value is set to yes, true, or 1, then any - # user with +q or +a may remove the +q or +a from other users. - #deprotectothers="yes"> - +# channel names. To disallow them, load the channames module and +# add characters 42 and 63 to denyrange (see above). +#<module name="channelban"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Check module: Adds the /CHECK command. @@ -455,7 +467,7 @@ # IP addresses and hosts. # This module is oper-only. # To use, CHECK must be in one of your oper class blocks. -#<module name="m_check.so"> +#<module name="check"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # CHGHOST module: Adds the /CHGHOST command. @@ -464,7 +476,7 @@ # NOTE: Services will not be able to set vhosts on users if this module # isn't loaded. If you're planning on running services, you probably # want to load this. -#<module name="m_chghost.so"> +#<module name="chghost"> # #-#-#-#-#-#-#-#-# /CHGHOST - /SETHOST CONFIGURATION #-#-#-#-#-#-#-#-# # Optional - If you want to use special chars for hostnames you can # @@ -479,64 +491,70 @@ # CHGIDENT module: Adds the /CHGIDENT command. # This module is oper-only. # To use, CHGIDENT must be in one of your oper class blocks. -#<module name="m_chgident.so"> +#<module name="chgident"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # CHGNAME module: Adds the /CHGNAME command. # This module is oper-only. # To use, CHGNAME must be in one of your oper class blocks. -#<module name="m_chgname.so"> +#<module name="chgname"> +# +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Connection class ban module: Adds support for extban 'n' which +# matches against the class name of the user's connection. +# This module assumes that connection classes are named in a uniform +# way on all servers of the network. Wildcards are accepted. +#<module name="classban"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Clear chan module: Allows opers to masskick, masskill or +# mass G/Z-line all users on a channel using /CLEARCHAN. +#<module name="clearchan"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Cloaking module: Adds usermode +x and cloaking support. -# Relies on the module m_md5.so being loaded. -# To cloak users when they connect, load m_conn_umodes and set +# Cloaking module: Adds user mode +x and cloaking support. +# Relies on the md5 module being loaded. +# To cloak users when they connect, load the conn_umodes module and set # <connect:modes> to include the +x mode. The example <connect> tag -# shows this. See the m_conn_umodes module for more information. -#<module name="m_cloaking.so"> +# shows this. See the conn_umodes module for more information. +#<module name="cloaking"> # #-#-#-#-#-#-#-#-#-#-#- CLOAKING CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# To use m_cloaking, you must define a cloak key, and optionally a # +# To use cloaking, you must define a cloak key, and optionally a # # cloak prefix as shown below. The cloak key must be shared across # -# the network for correct cloaking. # +# the network for consistent cloaking and must be at least thirty # +# characters long. # # # -# There are four methods of cloaking: # +# There are two methods of cloaking: # # # -# half Cloak only the "unique" portion of a host; show # -# the last 2 parts of the domain, /16 subnet of IPv4 # -# or /48 subnet of the IPv6 address. # +# half Cloak only the "unique" portion of a host; by # +# default show the last 2 parts of the domain, # +# /16 subnet of IPv4 or /48 subnet of the IPv6 # +# address. # +# To change the number of shown parts, modify the # +# domainparts option. # # # # full Cloak the users completely, using three slices for # # common CIDR bans (IPv4: /16, /24; IPv6: /48, /64). # # # -# These methods use a single key that can be any length of text. # +# The methods use a single key that can be any length of text. # # An optional prefix may be specified to mark cloaked hosts. # # # -# The following methods are maintained for backwards compatibility; # -# they are slightly less secure, and always hide unresolved IPs. # -# # -# compat-host InspIRCd 1.2-compatible host-based cloaking. # -# compat-ip InspIRCd 1.2-compatible ip-always cloaking. # -# # -# If you use a compat cloaking mode then you must specify key1, key2, # -# key3, key4; the values must be less than 0x80000000 and should be # -# picked at random. Prefix is mandatory, will default to network name # -# if not specified, and will always have a "-" appended. # -# # -# IMPORTANT: The compat-host and compat-ip modes have been removed in # -# the next major version of InspIRCd. You should ONLY use them if you # -# need backwards compatibility with InspIRCd 1.2. # +# IMPORTANT: Changing these details will break all of your existing # +# bans. If you do not want this to happen you can define multiple # +# cloak tags. The first will be used for cloaking and the rest will # +# be used for checking if a user is banned in a channel. # +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # #<cloak mode="half" -# key="secret" +# key="changeme" +# domainparts="3" +# prefix="net-"> +# +#<cloak mode="full" +# key="changeme" # prefix="net-"> - -#-#-#-#-#-#-#-#-#-#-#-#- CLOSE MODULE #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Close module: Allows an oper to close all unregistered connections. -# This module is oper-only and provides the /CLOSE command. -# To use, CLOSE must be in one of your oper class blocks. -#<module name="m_close.so"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Clones module: Adds an oper command /CLONES for detecting cloned @@ -544,42 +562,47 @@ # issued, use with care. # This module is oper-only. # To use, CLONES must be in one of your oper class blocks. -#<module name="m_clones.so"> +#<module name="clones"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Common channels module: Adds user mode +c, which, when set, requires # that users must share a common channel with you to PRIVMSG or NOTICE # you. -#<module name="m_commonchans.so"> +#<module name="commonchans"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Auto join on connect module: Allows you to force users to join one -# or more channels automatically upon connecting to the server. -#<module name="m_conn_join.so"> +# or more channels automatically upon connecting to the server, or +# join them in case they aren't on any channels after being online +# for X seconds. +#<module name="conn_join"> # #-#-#-#-#-#-#-#-#-#-#-#- CONNJOIN CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # -# If you have m_conn_join.so loaded, you can configure it using the -# following values, or set autojoin="#chat,#help" in <connect> blocks. +# If you have the conn_join module loaded, you can configure it below +# or set autojoin="#chat,#help" in <connect> blocks. # +# Join users immediately after connection to #one #two and #three. #<autojoin channel="#one,#two,#three"> +# Join users to #chat after 15 seconds if they aren't on any channels. +#<autojoin channel="#chat" delay="15"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Set modes on connect module: When this module is loaded <connect> # blocks may have an optional modes="" value, which contains modes to # add or remove from users when they connect to the server. -#<module name="m_conn_umodes.so"> +#<module name="conn_umodes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Wait for PONG on connect module: Send a PING to all connecting users # and don't let them connect until they reply with a PONG. # This is useful to stop certain kinds of bots and proxies. -#<module name="m_conn_waitpong.so"> +#<module name="conn_waitpong"> # #-#-#-#-#-#-#-#-#-#-#- WAITPONG CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# If you have the m_conn_waitpong.so module loaded, configure it with # -# the <waitpong> tag: # +# If you have the conn_waitpong module loaded, configure it with the # +# <waitpong> tag: # # # # sendsnotice - Whether to send a helpful notice to users on # # connect telling them how to connect, should # @@ -593,13 +616,13 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Channel cycle module: Adds the /CYCLE command which is a server-side # /HOP that bypasses restrictive modes. -#<module name="m_cycle.so"> +#<module name="cycle"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Connectban: Provides IP connection throttling. Any IP range that -# connects too many times (configurable) in an hour is Z-Lined for a +# connects too many times (configurable) in an hour is Z-lined for a # (configurable) duration, and their count resets to 0. -#<module name="m_connectban.so"> +#<module name="connectban"> # # ipv4cidr and ipv6cidr allow you to turn the comparison from # individual IP addresses (32 and 128 bits) into CIDR masks, to allow @@ -608,14 +631,16 @@ # # This allows for 10 connections in an hour with a 10 minute ban if # that is exceeded. -#<connectban threshold="10" duration="10m" ipv4cidr="32" ipv6cidr="128"> +#<connectban threshold="10" duration="10m" ipv4cidr="32" ipv6cidr="128" +# A custom ban message may optionally be specified. +# banmessage="Your IP range has been attempting to connect too many times in too short a duration. Wait a while, and you will be able to connect."> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Connection throttle module. -#<module name="m_connflood.so"> +#<module name="connflood"> # #-#-#-#-#-#-#-#-#-#-#- CONNTHROTTLE CONFIGURATION -#-#-#-#-#-#-#-#-#-# -# seconds, maxconns - Amount of connections per <seconds>. +# period, maxconns - Amount of connections per <period>. # # timeout - Time to wait after the throttle was activated # before deactivating it. Be aware that the time @@ -631,9 +656,8 @@ # quitmsg="Throttled" bootwait="10"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Custom prefixes: Allows for channel prefixes to be added. -# This replaces m_chanprotect and m_halfop. -#<module name="m_customprefix.so"> +# Custom prefixes: Allows for channel prefixes to be configured. +#<module name="customprefix"> # # name The name of the mode, must be unique from other modes. # letter The letter used for this mode. Required. @@ -641,26 +665,31 @@ # rank A numeric rank for this prefix, defining what permissions it gives. # The rank of voice, halfop and op is 10000, 20000, and 30000, # respectively. -# ranktoset The numeric rank required to set/unset this mode. Defaults to rank. +# ranktoset The numeric rank required to set this mode. Defaults to rank. +# ranktounset The numeric rank required to unset this mode. Defaults to ranktoset. # depriv Can you remove the mode from yourself? Defaults to yes. #<customprefix name="founder" letter="q" prefix="~" rank="50000" ranktoset="50000"> #<customprefix name="admin" letter="a" prefix="&" rank="40000" ranktoset="50000"> #<customprefix name="halfop" letter="h" prefix="%" rank="20000" ranktoset="30000"> -#<customprefix name="halfvoice" letter="V" prefix="-" rank="1" ranktoset="20000"> # -# Do /RELOADMODULE m_customprefix.so after changing the settings of this module. +# You can also override the configuration of prefix modes added by both the core +# and other modules by adding a customprefix tag with change="yes" specified. +# <customprefix name="op" change="yes" rank="30000" ranktoset="30000"> +# <customprefix name="voice" change="yes" rank="10000" ranktoset="10000" depriv="no"> +# +# Do /RELOADMODULE customprefix after changing the settings of this module. #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Custom title module: Adds the /TITLE command which allows for trusted # users to gain a custom whois line and an optional vhost can be # specified. -#<module name="m_customtitle.so"> +#<module name="customtitle"> # #-#-#-#-#-#-#-#-#-#- CUSTOM TITLE CONFIGURATION -#-#-#-#-#-#-#-#-#-# # name - The username used to identify. # password - The password used to identify. # hash - The hash for the specific user's password (optional). -# m_password_hash.so and a hashing module must be loaded +# password_hash and a hashing module must be loaded # for this to work. # host - Allowed hostmask (optional). # title - Title shown in whois. @@ -668,11 +697,11 @@ # #<title name="foo" password="bar" title="Official Chat Helper"> #<title name="bar" password="foo" host="ident@test.org" title="Official Chat Helper" vhost="helper.test.org"> -#<title name="foo" password="fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9" hash="sha256" title="Official Chat Helper"> +#<title name="foo" password="$2a$10$UYZ4OcO8NNTCCGyCdY9SK.2GHiqGgxZfHFPOPmWuxEVWVQTtoDC7C" hash="bcrypt" title="Official Chat Helper"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # DCCALLOW module: Adds the /DCCALLOW command. -#<module name="m_dccallow.so"> +#<module name="dccallow"> # #-#-#-#-#-#-#-#-#-#-#- DCCALLOW CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # blockchat - Whether to block DCC CHAT as well as DCC SEND. @@ -692,9 +721,24 @@ #<banfile pattern="*.txt" action="allow"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Deaf module: Adds support for the usermode +d - deaf to channel -# messages and channel notices. -#<module name="m_deaf.so"> +# Deaf module: Adds support for user modes +d and +D: +# d - deaf to channel messages and notices. +# D - deaf to user messages and notices. +# The +D user mode is not enabled by default to enable link compatibility +# with 2.0 servers. +#<module name="deaf"> +# +#-#-#-#-#-#-#-#-#-#-#-#- DEAF CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# +# bypasschars - Characters that bypass deaf to a regular user. +# bypasscharsuline - Characters that bypass deaf to a U-lined user (services). +# Both of these take a list of characters that must match +# the starting character of a message. +# If 'bypasscharsuline' is empty, then 'bypasschars' will +# match for both regular and U-lined users. +# enableprivdeaf - Whether to enable user mode +D (privdeaf). +# privdeafuline - Whether U-lined users bypass user mode +D (privdeaf). +# +#<deaf bypasschars="" bypasscharsuline="!" enableprivdeaf="no" privdeafuline="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Delay join module: Adds the channel mode +D which delays all JOIN @@ -702,24 +746,24 @@ # speaking, their quit or part message will not be shown to the channel # which helps cut down noise on large channels in a more friendly way # than the auditorium mode. Only channel ops may set the +D mode. -#<module name="m_delayjoin.so"> +#<module name="delayjoin"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Delay message module: Adds the channel mode +d which disallows a user # from talking in the channel unless they've been joined for X seconds. # Settable using /MODE #chan +d 30 -#<module name="m_delaymsg.so"> +#<module name="delaymsg"> # Set allownotice to no to disallow NOTICEs too. Defaults to yes. #<delaymsg allownotice="no"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Deny channels module: Deny channels from being used by users. -#<module name="m_denychans.so"> +#<module name="denychans"> # #-#-#-#-#-#-#-#-#-#-#- DENYCHAN DEFINITIONS -#-#-#-#-#-#-#-#-#-#-#-# # # -# If you have the m_denychans.so module loaded, you need to specify # -# the channels to deny: # +# If you have the denychans module loaded, you need to specify the # +# channels to deny: # # # # name - The channel name to deny (glob masks are ok). # # allowopers - If operators are allowed to override the deny. # @@ -737,16 +781,49 @@ # Glob masks are accepted here also. # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Devoice module: Let users devoice themselves using /DEVOICE #chan. -#<module name="m_devoice.so"> +# Disable module: Provides support for disabling commands and modes. # +#<module name="disable"> +# +#-#-#-#-#-#-#-#-#-#-#-#- DISABLE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# +# # +# If you have the disable module loaded then you need to specify the # +# commands and modes that you want disabled. Users who have not fully # +# connected yet are exempt from this module so you can e.g. disable # +# the NICK command but still allow users to connect to the server. # +# # +# commands - A space-delimited list of commands that can not be used # +# by users. You can exempt server operators from this with # +# the servers/use-disabled-commands privilege. # +# # +# chanmodes - One or more channel modes that can not be added/removed # +# by users. You can exempt server operators from this # +# with the servers/use-disabled-modes privilege. # +# # +# usermodes - One or more user modes that can not be added/removed by # +# users. You can exempt server operators from this with # +# the servers/use-disabled-modes privilege. # +# # +# fakenonexistent - Whether to pretend that a disabled command/mode # +# does not exist when executed/changed by a user. # +# Defaults to no. # +# # +# notifyopers - Whether to send a notice to snomask `a` when a user # +# is prevented from using a disabled command/mode. # +# Defaults to no. # +# # +#<disabled commands="KICK TOPIC" # +# chanmodes="kp" # +# usermodes="iw" # +# fakenonexistent="yes" # +# notifyopers="no"> # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # DNS blacklist module: Provides support for looking up IPs on one or # # more blacklists. # -#<module name="m_dnsbl.so"> # +#<module name="dnsbl"> # # -# For configuration options please see the docs page for m_dnsbl at # -# https://docs.inspircd.org/2/modules/dnsbl # +# For configuration options please see the docs page for dnsbl at # +# https://docs.inspircd.org/3/modules/dnsbl # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Exempt channel operators module: Provides support for allowing # @@ -756,74 +833,108 @@ # nonick, nonotice, regmoderated, stripcolor, and topiclock. # # See <options:exemptchanops> in inspircd.conf.example for a more # # detailed list of the restriction modes that can be exempted. # -# These are settable using /mode #chan +X <restriction>:<status> # -#<module name="m_exemptchanops.so"> # +# These are settable using: /MODE #chan +X <restriction>:<status> # +#<module name="exemptchanops"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Filter module: Provides message filtering, similar to SPAMFILTER. # -#<module name="m_filter.so"> +#<module name="filter"> # # -# This module depends upon a regex provider such as m_regex_pcre or # -# m_regex_glob to function. You must specify which of these you want # -# m_filter to use via the tag below. # +# This module depends upon a regex provider such as regex_pcre or # +# regex_glob to function. You must specify which of these you want # +# the filter module to use via the tag below. # # # # Valid engines are: # # # -# glob - Glob patterns, provided via m_regex_glob. # -# pcre - PCRE regexps, provided via m_regex_pcre, needs libpcre. # -# tre - TRE regexps, provided via m_regex_tre, requires libtre. # -# posix - POSIX regexps, provided via m_regex_posix, not available # +# glob - Glob patterns, provided via regex_glob. # +# pcre - PCRE regexps, provided via regex_pcre, needs libpcre. # +# tre - TRE regexps, provided via regex_tre, requires libtre. # +# posix - POSIX regexps, provided via regex_posix, not available # # on Windows, no dependencies on other operating systems. # -# stdlib - stdlib regexps, provided via m_regex_stdlib, see comment # +# stdlib - stdlib regexps, provided via regex_stdlib, see comment # # at the <module> tag for info on availability. # # # -#<filteropts engine="glob"> # +# If notifyuser is set to no, the user will not be notified when # +# his/her message is blocked. # +#<filteropts engine="glob" notifyuser="yes"> +# # +# Your choice of regex engine must match on all servers network-wide. # +# # +# To learn more about the configuration of this module, read # +# examples/filter.conf.example, which covers the various types of # +# filters and shows how to add exemptions. # # # -# Your choice of regex engine must match on all servers network-wide. -# -# You may specify specific channels that are exempt from being filtered: -#<exemptfromfilter channel="#blah"> -# #-#-#-#-#-#-#-#-#-#-#- FILTER CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# Optional - If you specify to use the m_filter module, then # +# Optional - If you specify to use the filter module, then # # specify below the path to the filter.conf file, or define some # -# <filter> tags. # +# <keyword> tags. # # # -#<include file="conf/examples/filter.conf.example"> +#<include file="examples/filter.conf.example"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Gecos ban: Implements extended ban 'r', which stops anyone matching -# a mask like +b r:*realname?here* from joining a channel. -#<module name="m_gecosban.so"> +# Flash Policy Daemon module: Allows Flash IRC clients (e.g. LightIRC)# +# to connect. If no file is specified, it'll serve a default policy # +# allowing all IPs to connect to all plaintext IRC ports # +#<bind address="" port="8430" type="flashpolicyd"> # +#<flashpolicyd timeout="5" file=""> # +#<module name="flashpolicyd"> # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# GeoIP module: Allows the server admin to match users by country code. -# This module is in extras. Re-run configure with: -# ./configure --enable-extras=m_geoip.cpp -# and run make install, then uncomment this module to enable it. -# This module requires GeoIP to be installed on your system, -# use your package manager to find the appropriate packages -# or check the InspIRCd docs page for this module. -#<module name="m_geoip.so"> -# -# The actual allow/ban actions are done by connect classes, not by the -# GeoIP module. An example connect class to ban people from russia or -# turkey: -# -# <connect deny="*" geoip="TR,RU"> -# -# The country code must be in capitals and should be an ISO country -# code such as TR, GB, or US. Unknown IPs (localhost, LAN IPs, etc) -# will be assigned the country code "UNK". Since connect classes are -# matched from top down, your deny classes must be above your allow -# classes for them to match. +# Real name ban: Implements two extended bans: # +# 'a', which matches a n!u@h+realname mask like +b a:*!*@host+*real* # +# 'r', which matches a realname mask like +b r:*realname?here* # +#<module name="gecosban"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Geolocation ban module: Adds support for extban 'G' which matches # +# against the ISO 3166-1 alpha-2 codes for the countries that users # +# are connecting from. Users connecting from unknown origins such as # +# internal networks can be matched against using the XX alpha-2 code. # +# A full list of ISO 3166-1 alpha-2 codes can be found at # +# https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 # +#<module name="geoban"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Geolocation connect class module: Adds support for limiting connect # +# classes to users from specific countries. With this module you can # +# specify a space-delimited list of two character the ISO 3166-1 # +# alpha-2 codes in the "country" field of a connect class. e.g. to # +# deny connections from users in Russia or Turkey: # +# # +# <connect deny="*" country="TR RU"> # +# # +# Users connecting from unknown origins such as internal networks can # +# be matched against using the XX alpha-2 code. A full list of ISO # +# 3166-1 alpha-2 codes can be found at # +# https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 # +#<module name="geoclass"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# MaxMindDB geolocation module: Provides geolocation information for # +# other modules that need it using the libMaxMindDB library. # +# # +# This module is in extras. Re-run configure with: # +# ./configure --enable-extras=m_geo_maxmind.cpp +# and run make install, then uncomment this module to enable it. # +# # +# This module requires libMaxMindDB to be installed on your system. # +# Use your package manager to find the appropriate packages or check # +# the InspIRCd documentation page for this module. # +#<module name="geo_maxmind"> +# # +# If you use the geo_maxmind module you MUST provide a database file # +# to look up geolocation information in. You can either purchase this # +# from MaxMind at https://www.maxmind.com/en/geoip2-country-database # +# or use the free CC-BY-SA licensed GeoLite2 Country database which # +# can be downloaded at https://dev.maxmind.com/geoip/geoip2/geolite2/ # +#<maxmind file="GeoLite2-Country.mmdb"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Globops module: Provides the /GLOBOPS command and snomask +g. # This module is oper-only. # To use, GLOBOPS must be in one of your oper class blocks. -#<module name="m_globops.so"> +#<module name="globops"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Global load module: Allows loading and unloading of modules network- @@ -832,29 +943,29 @@ # and /GRELOADMODULE. # To use, GLOADMODULE, GUNLOADMODULE and GRELOADMODULE # must be in one of your oper class blocks. -#<module name="m_globalload.so"> +#<module name="globalload"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Halfop module: Provides the +h (halfops) channel status mode. -# -# IMPORTANT: This module has been removed in the next major version of -# InspIRCd. You should use m_customprefix instead. -#<module name="m_halfop.so"> +# HAProxy module: Adds support for the HAProxy PROXY v2 protocol. To +# use this module specify hook="haproxy" in the <bind> tag that HAProxy +# has been configured to connect to. +#<module name="haproxy"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# HELPOP module: Provides the /HELPOP command. -#<module name="m_helpop.so"> +# HELPOP module: Provides the /HELPOP command +#<module name="helpop"> # #-#-#-#-#-#-#-#-#-#-#-#- HELPOP CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# If you specify to use the m_helpop.so module, then specify below # -# the path to the helpop.conf file. # -#<include file="conf/examples/helpop-full.conf.example"> +# If you specify to use the helpop module, then specify below the # +# path to the helpop.conf file. # +# # +#<include file="examples/helpop.conf.example"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Hide chans module: Allows users to hide their channels list from non- # opers by setting user mode +I on themselves. -#<module name="m_hidechans.so"> +#<module name="hidechans"> # # This mode can optionally prevent opers from seeing channels on a +I # user, for more privacy if set to true. @@ -862,50 +973,86 @@ #<hidechans affectsopers="false"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Hide list module: Allows for hiding the list of listmodes from users +# who do not have sufficient channel rank. +#<module name="hidelist"> +# +# Each <hidelist> tag configures one listmode to hide. +# mode: Name of the listmode to hide. +# rank: Minimum rank required to view the list. If set to 0, all +# members of the channel may view the list, but non-members may not. +# The rank of the built-in op and voice mode is 30000 and 10000, +# respectively; the rank of other prefix modes is configurable. +# Defaults to 20000. +# +# Hiding the ban list is not recommended because it may break some +# clients. +# +# Hide filter (+g) list: +#<hidelist mode="filter" rank="30000"> +# Only show invite exceptions (+I) to channel members: +#<hidelist mode="invex" rank="0"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Hide mode module: Allows for hiding mode changes from users who do not +# have sufficient channel privileges. +#<module name="hidemode"> +# +# Hide bans (+b) from people who are not voiced: +#<hidemode mode="ban" rank="10000"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Hide oper module: Allows opers to hide their oper status from non- # opers by setting user mode +H on themselves. # This module is oper-only. -#<module name="m_hideoper.so"> +#<module name="hideoper"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Hostchange module: Allows a different style of cloaking. -#<module name="m_hostchange.so"> +#<module name="hostchange"> # #-#-#-#-#-#-#-#-#-#-#- HOSTCHANGE CONFIGURATION -#-#-#-#-#-#-#-#-#-# # # -# See https://docs.inspircd.org/2/modules/hostchange for help. # +# See https://docs.inspircd.org/3/modules/hostchange for help. # # # -#<host suffix="invalid.org" separator="." prefix=""> -#<hostchange mask="*@42.theanswer.example.org" action="addnick"> -#<hostchange mask="*root@*" action="suffix"> +#<hostchange mask="*@42.theanswer.example.org" action="addaccount" suffix=".users.example.com"> +#<hostchange mask="*root@*" action="addnick" prefix="example/users/"> #<hostchange mask="a@example.com" action="set" value="foo.bar.baz"> -#<hostchange mask="localhost" ports="7000,7001,7005-7007" action="set" value="blahblah.foo"> +#<hostchange mask="*@localhost" ports="7000,7001,7005-7007" action="set" value="blahblah.foo"> + +# hostcycle: If loaded, when a user gets a host or ident set, it will +# cycle them in all their channels. If not loaded it will simply change +# their host/ident without cycling them. +# This module is compatible with the ircv3_chghost module. Clients +# supporting the chghost extension will get the chghost message instead +# of seeing a host cycle. +#<module name="hostcycle"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # httpd module: Provides HTTP server support for InspIRCd. -#<module name="m_httpd.so"> +#<module name="httpd"> # #-#-#-#-#-#-#-#-#-#-#-#- HTTPD CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # -# If you choose to use the m_httpd.so module, then you will need to add +# If you choose to use the httpd module, then you will need to add # a <bind> tag with type "httpd", and load at least one of the other -# m_httpd_* modules to provide pages to display. +# httpd_* modules to provide pages to display. # <bind address="127.0.0.1" port="8067" type="httpd"> # <bind address="127.0.0.1" port="8097" type="httpd" ssl="gnutls"> # # You can adjust the timeout for HTTP connections below. All HTTP -# connections will be closed after (roughly) this many seconds. +# connections will be closed after (roughly) this time period. #<httpd timeout="20"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# HTTP ACL module: Provides access control lists for m_httpd dependent +# HTTP ACL module: Provides access control lists for httpd dependent # modules. Use this module to restrict pages by IP address and by # password. -#<module name="m_httpd_acl.so"> +#<module name="httpd_acl"> # #-#-#-#-#-#-#-#-#-#-#-#- HTTPD ACL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # -# Restrict access to the m_httpd_stats module to all but the local +# Restrict access to the httpd_stats module to all but the local # network and when the correct password is specified: # <httpdacl path="/stats*" types="password,whitelist" # username="secrets" password="mypasshere" whitelist="127.0.0.*,10.*"> @@ -915,44 +1062,47 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # HTTP config module: Allows the server configuration to be viewed over -# HTTP via the /config path. Requires m_httpd.so to be loaded for it to -# function. +# HTTP via the /config path. Requires the httpd module to be loaded for +# it to function. # # IMPORTANT: This module exposes extremely sensitive information about # your server and users so you *MUST* protect it using a local-only -# <bind> tag and/or the m_httpd_acl.so module. See above for details. -#<module name="m_httpd_config.so"> +# <bind> tag and/or the httpd_acl module. See above for details. +#<module name="httpd_config"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # HTTP stats module: Provides server statistics over HTTP via the /stats -# path. Requires m_httpd.so to be loaded for it to function. +# path. Requires the httpd module to be loaded for it to function. # # IMPORTANT: This module exposes extremely sensitive information about # your server and users so you *MUST* protect it using a local-only -# <bind> tag and/or the m_httpd_acl.so module. See above for details. -#<module name="m_httpd_stats.so"> +# <bind> tag and/or the httpd_acl module. See above for details. +#<module name="httpd_stats"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Ident: Provides RFC 1413 ident lookup support. # When this module is loaded <connect:allow> tags may have an optional # useident="yes|no" boolean value, determining whether or not to lookup # ident on users matching that connect tag. -#<module name="m_ident.so"> +#<module name="ident"> # #-#-#-#-#-#-#-#-#-#-#-#- IDENT CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# Optional - If you are using the m_ident.so module, then you can # -# specify the timeout for ident lookups here. If not defined, it will # -# default to 5 seconds. This is a non-blocking timeout which holds # -# the user in a 'connecting' state until the lookup is complete. # -# The bind value indicates which IP to bind outbound requests to. # +# Optional - If you are using the ident module, then you can specify # +# the timeout for ident lookups here. If not defined, it will default # +# to 5 seconds. This is a non-blocking timeout which holds the user # +# in a 'connecting' state until the lookup is complete. # +# prefixunqueried: If on, the idents of users being in a connect class# +# with ident lookups disabled (i.e. <connect useident="off">) will be # +# prefixed with a "~". If off, the ident of those users will not be # +# prefixed. Default is off. # # -#<ident timeout="5"> +#<ident timeout="5" prefixunqueried="no"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Invite exception module: Adds support for channel invite exceptions # (+I). -#<module name="m_inviteexception.so"> +#<module name="inviteexception"> # bypasskey: If this is enabled, exceptions will bypass +k as well as +i #<inviteexception bypasskey="yes"> @@ -961,40 +1111,102 @@ # extended-join, away-notify and account-notify. These are optional # enhancements to the client-to-server protocol. An extension is only # active for a client when the client specifically requests it, so this -# module needs m_cap to work. +# module needs the cap module to work. # # Further information on these extensions can be found at the IRCv3 # working group website: -# http://ircv3.net/irc/ +# https://ircv3.net/irc/ # -#<module name="m_ircv3.so"> +#<module name="ircv3"> # The following block can be used to control which extensions are -# enabled. Note that extended-join can be incompatible with m_delayjoin +# enabled. Note that extended-join can be incompatible with delayjoin # and host cycling. #<ircv3 accountnotify="on" awaynotify="on" extendedjoin="on"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Join flood module: Adds support for join flood protection +j X:Y. -# Closes the channel for 60 seconds if X users join in Y seconds. -#<module name="m_joinflood.so"> +# IRCv3 account-tag module. Adds the 'account' tag which contains the +# services account name of the message sender. +#<module name="ircv3_accounttag"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Jump server module: Adds support for the RPL_REDIR numeric. -# This module is oper-only. -# To use, JUMPSERVER must be in one of your oper class blocks. -# If your server is redirecting new clients and you get disconnected, -# do a REHASH from shell to open up again. -#<module name="m_jumpserver.so"> +# IRCv3 batch module: Provides the batch IRCv3 extension which allows +# the server to inform a client that a group of messages are related to +# each other. +#<module name="ircv3_batch"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 cap-notify module: Provides the cap-notify IRCv3 extension. +# Required for IRCv3 conformance. +#<module name="ircv3_capnotify"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 chghost module: Provides the chghost IRCv3 extension which +# allows capable clients to learn when the host/ident of another user +# changes without cycling the user. This module is compatible with the +# hostcycle module. If both are loaded, clients supporting the chghost +# extension will get the chghost message and won't see host cycling. +#<module name="ircv3_chghost"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 client-to-client tags module: Provides the message-tags IRCv3 +#Â extension which allows clients to add extra data to their messages. +# This is used to support new IRCv3 features such as replies and ids. +#<module name="ircv3_ctctags"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 echo-message module: Provides the echo-message IRCv3 +# extension which allows capable clients to get an acknowledgement when +# their messages are delivered and learn what modifications, if any, +# were applied to them. +#<module name="ircv3_echomessage"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 invite-notify module: Provides the invite-notify IRCv3 +# extension which notifies supporting clients when a user invites +# another user into a channel. This respects <options:announceinvites>. +#<module name="ircv3_invitenotify"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 server-time module. Adds the 'time' tag which adds a timestamp +# to all messages received from the server. +#<module name="ircv3_servertime"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# IRCv3 Strict Transport Security module: Provides the sts IRCv3 +# extension which allows clients connecting insecurely to upgrade their +# connections to TLS. +#<module name="ircv3_sts"> +# +# If using the ircv3_sts module you MUST define a STS policy to send +# to clients using the <sts> tag. This tag takes the following +# attributes: +# +# host - A glob match for the SNI hostname to apply this policy to. +# duration - The amount of time that the policy lasts for. Defaults to +# approximately two months by default. +# port - The port on which TLS connections to the server are being +# accepted. You MUST have a CA-verified certificate on this +# port. Self signed certificates are not acceptable. +# preload - Whether client developers can include your certificate in +# preload lists. +# +# <sts host="*.example.com" duration="60d" port="6697" preload="yes"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Join flood module: Adds support for join flood protection +j X:Y. +# Closes the channel for N seconds if X users join in Y seconds. +#<module name="joinflood"> +# +# The number of seconds to close the channel for: +#<joinflood duration="1m"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Anti auto rejoin: Adds support for prevention of auto-rejoin (+J). -#<module name="m_kicknorejoin.so"> -# Set the maximum time that is accepted as a parameter for +J here. -#<kicknorejoin maxtime="1m"> +#<module name="kicknorejoin"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Knock module: Adds the /KNOCK command and channel mode +K. -#<module name="m_knock.so"> +#<module name="knock"> # # This setting specifies what to do when someone successfully /KNOCKs. # If set to "notice", then a NOTICE will be sent to the channel. @@ -1006,24 +1218,38 @@ #<knock notify="notice"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# LDAP module: Allows other SQL modules to access a LDAP database +# through a unified API. +# This modules is in extras. Re-run configure with: +# ./configure --enable-extras=m_ldap.cpp +# and run make install, then uncomment this module to enable it. +# +#<module name="ldap"> +#<database module="ldap" id="ldapdb" server="ldap://localhost" binddn="cn=Manager,dc=inspircd,dc=org" bindauth="mysecretpass" searchscope="subtree"> +# The server parameter indicates the LDAP server to connect to. The # +# ldap:// style scheme before the hostname proper is MANDATORY. # +# # +# The binddn and bindauth indicate the DN to bind to for searching, # +# and the password for the distinguished name. Some LDAP servers will # +# allow anonymous searching in which case these two values do not # +# need defining, otherwise they should be set similar to the examples # +# above. # +# # +# The searchscope value indicates the subtree to search under. On our # +# test system this is 'subtree'. Your mileage may vary. # + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # LDAP authentication module: Adds the ability to authenticate users # -# via LDAP. This is an extra module which must be enabled explicitly # -# by symlinking it from modules/extra, and requires the OpenLDAP libs # -# This module is in extras. To enable it, Re-run configure with: # -# ./configure --enable-extras=m_ldapauth.cpp # -# and run make install, then uncomment this module. # -#<module name="m_ldapauth.so"> +# via LDAP. # +#<module name="ldapauth"> # # # Configuration: # # # -# <ldapauth baserdn="ou=People,dc=brainbox,dc=cc" # +# <ldapauth dbid="ldapdb" # +# baserdn="ou=People,dc=brainbox,dc=cc" # # attribute="uid" # -# server="ldap://brainwave.brainbox.cc" # -# allowpattern="Guest*" # +# allowpattern="Guest* Bot*" # # killreason="Access denied" # -# searchscope="subtree" # -# binddn="cn=Manager,dc=brainbox,dc=cc" # -# bindauth="mysecretpass" # # verbose="yes" # # host="$uid.$ou.inspircd.org" # # useusername="no"> # @@ -1038,32 +1264,21 @@ # The attribute value indicates the attribute which is used to locate # # a user account by name. On POSIX systems this is usually 'uid'. # # # +# The allowpattern value allows you to specify a space separated list # +# of wildcard masks which will always be allowed to connect # +# regardless of if they have an account, for example guest and bot # +# users. # +# # # The useusername setting chooses whether the user's username or # # nickname is used when locating a user account, if a username isn't # # provided in PASS. # # # -# The server parameter indicates the LDAP server to connect to. The # -# ldap:// style scheme before the hostname proper is MANDATORY. # -# # -# The allowpattern value allows you to specify a wildcard mask which # -# will always be allowed to connect regardless of if they have an # -# account, for example guest users. # -# # # Killreason indicates the QUIT reason to give to users if they fail # # to authenticate. # # # -# The searchscope value indicates the subtree to search under. On our # -# test system this is 'subtree'. Your mileage may vary. # -# # # Setting the verbose value causes an oper notice to be sent out for # # every failed authentication to the server, with an error string. # # # -# The binddn and bindauth indicate the DN to bind to for searching, # -# and the password for the distinguished name. Some LDAP servers will # -# allow anonymous searching in which case these two values do not # -# need defining, otherwise they should be set similar to the examples # -# above. # -# # # ldapwhitelist indicates that clients connecting from an IP in the # # provided CIDR do not need to authenticate against LDAP. It can be # # repeated to whitelist multiple CIDRs. # @@ -1083,25 +1298,18 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # LDAP oper configuration module: Adds the ability to authenticate # -# opers via LDAP. This is an extra module which must be enabled # -# explicitly by symlinking it from modules/extra, and requires the # -# OpenLDAP libs. Re-run configure with: # -# ./configure --enable-extras=m_ldapoper.cpp -# and run make install, then uncomment this module to enable it. # -#<module name="m_ldapoper.so"> +# opers via LDAP. # +#<module name="ldapoper"> # # # Configuration: # # # -# <ldapoper baserdn="ou=People,dc=brainbox,dc=cc" -# server="ldap://brainwave.brainbox.cc" -# searchscope="subtree" -# binddn="cn=Manager,dc=brainbox,dc=cc" -# bindauth="mysecretpass" +# <ldapoper dbid="ldapdb" +# baserdn="ou=People,dc=brainbox,dc=cc" # attribute="uid"> # # # Available configuration items are identical to the same items in # -# m_ldapauth above (except for the verbose setting, that is only # -# supported in m_ldapauth). # +# ldapauth above (except for the verbose setting, that is only # +# supported in ldapauth). # # Please always specify a password in your <oper> tags even if the # # opers are to be authenticated via LDAP, so in case this module is # # not loaded the oper accounts are still protected by a password. # @@ -1115,39 +1323,37 @@ # If your server is locked and you get disconnected, do a REHASH from # # shell to open up again. # # This module is oper-only. -#<module name="m_lockserv.so"> +#<module name="lockserv"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Map hiding module: replaces /MAP and /LINKS output to users with a # -# message to see a website, set by maphide="http://test.org/map" in # +# message to see a website, set by maphide="https://test.org/map" in # # the <security> tag, instead. # -#<module name="m_maphide.so"> +#<module name="maphide"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Message flood module: Adds message/notice flood protection via # channel mode +f. -#<module name="m_messageflood.so"> +#<module name="messageflood"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # MLOCK module: Adds support for server-side enforcement of services # side MLOCKs. Basically, this module suppresses any mode change that # would likely be immediately bounced by services. -#<module name="m_mlock.so"> +#<module name="mlock"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# MsSQL module: Allows other SQL modules to access MS SQL Server -# through a unified API. -# This module is in extras. Re-run configure with: -# ./configure --enable-extras=m_mssql.cpp -# and run make install, then uncomment this module to enable it. -#<module name="m_mssql.so"> -# -#-#-#-#-#-#-#-#-#-#-#-#- SQL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# -# # -# m_mssql.so is more complex than described here, see docs for more # -# info https://docs.inspircd.org/2/modules/mssql # +# Modenotice module: Adds the /MODENOTICE command that allows opers to +# send notices to all users having the given user mode(s) set. +#<module name="modenotice"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Monitor module: Adds support for MONITOR which is used by clients to +# maintain notify lists. +#<module name="monitor"> # -#<database module="mssql" name="db" user="user" pass="pass" host="localhost" id="db1"> +# Set the maximum number of entries on a user's monitor list below. +#<monitor maxentries="30"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # MySQL module: Allows other SQL modules to access MySQL databases @@ -1155,33 +1361,33 @@ # This module is in extras. Re-run configure with: # ./configure --enable-extras=m_mysql.cpp # and run make install, then uncomment this module to enable it. -#<module name="m_mysql.so"> +#<module name="mysql"> # #-#-#-#-#-#-#-#-#-#-#-#- SQL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # -# m_mysql.so is more complex than described here, see the docs for # -# more: https://docs.inspircd.org/2/modules/mysql # +# mysql is more complex than described here, see the docs for more # +# info: https://docs.inspircd.org/3/modules/mysql # # #<database module="mysql" name="mydb" user="myuser" pass="mypass" host="localhost" id="my_database2"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Named modes module: Allows for the display and set/unset of channel # modes via long-form mode names via +Z and the /PROP command. -# For example, to set a ban, do /mode #channel +Z ban=foo!bar@baz or +# For example, to set a ban, do /MODE #channel +Z ban=foo!bar@baz or # /PROP #channel ban=foo!bar@baz -#<module name="m_namedmodes.so"> +#<module name="namedmodes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # NAMESX module: Provides support for the NAMESX extension which allows # clients to see all the prefixes set on a user without getting confused. # This is supported by mIRC, x-chat, klient, and maybe more. -#<module name="m_namesx.so"> +#<module name="namesx"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # National characters module: # 1) Allows using national characters in nicknames. # 2) Allows using custom (national) casemapping over the network. -#<module name="m_nationalchars.so"> +#<module name="nationalchars"> # # file - Location of the file which contains casemapping rules. If this # is a relative path then it is relative to "<PWD>/../locales" @@ -1195,47 +1401,54 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Nickchange flood protection module: Provides channel mode +F X:Y # which allows up to X nick changes in Y seconds. -#<module name="m_nickflood.so"> +#<module name="nickflood"> +# +# The number of seconds to prevent nick changes for: +#<nickflood duration="1m"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Nicklock module: Let opers change a user's nick and then stop that # user from changing their nick again until unlocked. # This module is oper-only. # To use, NICKLOCK and NICKUNLOCK must be in one of your oper class blocks. -#<module name="m_nicklock.so"> +#<module name="nicklock"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# No CTCP module: Adds the channel mode +C to block CTCPs and extban -# 'C' to block CTCPs sent by specific users. -#<module name="m_noctcp.so"> +# No CTCP module: Adds the channel mode +C and user mode +T to block +# CTCPs and extban 'C' to block CTCPs sent by specific users. +#<module name="noctcp"> +# +# The +T user mode is not enabled by default to enable link compatibility +# with 2.0 servers. You can enable it by uncommenting this: +#<noctcp enableumode="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # No kicks module: Adds the +Q channel mode and the Q: extban to deny # certain users from kicking. -#<module name="m_nokicks.so"> +#<module name="nokicks"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # No nicks module: Adds the +N channel mode, as well as the 'N' extban. # +N stops all users from changing their nick, the N extban stops # anyone from matching a +b N:nick!user@host mask from changing their # nick. -#<module name="m_nonicks.so"> +#<module name="nonicks"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # No part message module: Adds extban 'p' to block part messages from # # matching users. # -#<module name="m_nopartmsg.so"> +#<module name="nopartmsg"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # No notice module: Adds the channel mode +T and the extban 'T' to # block specific users from noticing the channel. -#<module name="m_nonotice.so"> +#<module name="nonotice"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Network business join module: # Allows an oper to join a channel using /OJOIN, giving them +Y on the -# channel which makes them immune to kick/deop/etc. -#<module name="m_ojoin.so"> +# channel which makes them immune to kicks. +#<module name="ojoin"> # # Specify the prefix that +Y will grant here. # Leave 'prefix' empty if you do not wish +Y to grant a prefix. @@ -1247,19 +1460,20 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Oper channels mode: Adds the +O channel mode and extban O:<mask> # to ban, except, etc. specific oper types. For example -# /mode #channel +iI O:* is equivalent to channel mode +O, but you +# /MODE #channel +iI O:* is equivalent to channel mode +O, but you # may also set +iI O:AdminTypeOnly to only allow admins. # Modes +I and +e work in a similar fashion. -#<module name="m_operchans.so"> +#<module name="operchans"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Oper join module: Auto-joins opers to a channel upon oper-up. -# This module is oper-only. For the user equivalent, see m_conn_join. -#<module name="m_operjoin.so"> +# This module is oper-only. For the user equivalent, see the conn_join +# module. +#<module name="operjoin"> # #-#-#-#-#-#-#-#-#-#-# OPERJOIN CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# If you are using the m_operjoin.so module, specify options here: # +# If you are using the operjoin module, specify options here: # # # # channel - The channel name to join, can also be a comma # # separated list e.g. "#channel1,#channel2". # @@ -1279,7 +1493,7 @@ # type "m_operlog" at default loglevel), and optionally to the 'r' # snomask. # This module is oper-only. -#<module name="m_operlog.so"> +#<module name="operlog"> # # If the following option is on then all oper commands will be sent to # the snomask 'r'. The default is off. @@ -1287,66 +1501,74 @@ #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Oper prefixing module: Adds a channel prefix mode +y which is given -# to all IRC operators automatically on all channels they are in. +# to all server operators automatically on all channels they are in. # This prefix mode is more powerful than channel op and other regular # prefix modes. # -# Load this module if you want all your IRC operators to have channel -# operator powers. -#<module name="m_operprefix.so"> +# Load this module if you want all your server operators to have +# channel operator powers. +#<module name="operprefix"> # # You may additionally customise the prefix character. #<operprefix prefix="!"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Oper MOTD module: Provides support for separate message of the day +# Oper MOTD module: Provides support for a separate message of the day # on oper-up. # This module is oper-only. -#<module name="m_opermotd.so"> +#<module name="opermotd"> # #-#-#-#-#-#-#-#-#-#-# OPERMOTD CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# If you are using the m_opermotd.so module, specify the motd here. # +# If you are using the opermotd module, specify the motd file here. # # # # onoper - If on, the message is sent on /OPER, otherwise it's # # only sent when /OPERMOTD is used. # # # -# processcolors - Allow color codes to be processed in the opermotd. # -# Read the comment above <connect:allowmotdcolors> in # -# inspircd.conf.example for details. # -# # -#<opermotd file="conf/examples/opermotd.txt.example" onoper="yes" processcolors="false"> +#<opermotd file="examples/opermotd.txt.example" onoper="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Override module: Adds support for oper override. # This module is oper-only. -#<module name="m_override.so"> +#<module name="override"> # #-#-#-#-#-#-#-#-#-#-# OVERRIDE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# m_override.so is too complex it describe here, see the docs: # -# https://docs.inspircd.org/2/modules/override # +# Much of override's configuration relates to your oper blocks. # +# For more information on how to allow opers to override, see: # +# https://docs.inspircd.org/3/modules/override # +# # +# noisy - If enabled, all oper overrides will be announced # +# via channel notice. # +# # +# requirekey - If enabled, overriding on join requires a channel # +# key of "override" to be specified. # +# # +# enableumode - If enabled, user mode +O is required for override. # +# # +#<override noisy="yes" requirekey="no" enableumode="true"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Oper levels module: Gives each oper a level and prevents actions # being taken by lower level opers against higher level opers. # Specify the level as the 'level' parameter of the <type> tag. # This module is oper-only. -#<module name="m_operlevels.so"> +#<module name="operlevels"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Oper modes module: Allows you to specify modes to add/remove on oper. # Specify the modes as the 'modes' parameter of the <type> tag # and/or as the 'modes' parameter of the <oper> tag. -# This module is oper-only. For the user equivalent, see m_conn_umodes. -#<module name="m_opermodes.so"> +# This module is oper-only. For the user equivalent, see the +# conn_umodes module. +#<module name="opermodes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Password forwarding module: Forwards a password users can send on # connect to the specified client below. The client is usually NickServ # and this module is usually used to authenticate users with NickServ # using their connect password. -#<module name="m_passforward.so"> +#<module name="passforward"> <passforward # nick: nick to forward connect passwords to. @@ -1360,12 +1582,12 @@ # cmd: Command for the user to run when it receives a connect # password. - cmd="PRIVMSG $nickrequired :IDENTIFY $pass"> + cmd="SQUERY $nickrequired :IDENTIFY $pass"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Password hash module: Allows hashed passwords to be used. -# To be useful, a hashing module like m_sha256.so also needs to be loaded. -#<module name="m_password_hash.so"> +# To be useful, a hashing module like bcrypt also needs to be loaded. +#<module name="password_hash"> # #-#-#-#-#-#-#-#-#-# PASSWORD HASH CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-# # @@ -1374,37 +1596,52 @@ # # <oper name="Brain" # host="ident@dialup15.isp.test.com" -# hash="sha256" -# password="01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" +# hash="bcrypt" +# password="$2a$10$Mss9AtHHslZTLBrXqM0FB.JBwD.UTSu8A48SfrY9exrpxbsRiRTbO" # type="NetAdmin"> # -# Starting from 2.0, you can use a more secure salted hash that prevents simply -# looking up the hash's value in a rainbow table built for the hash. +# If you are using a hash algorithm which does not perform salting you can use +# HMAC to salt your passwords in order to prevent them from being looked up in +# a rainbow table. +# # hash="hmac-sha256" password="lkS1Nbtp$CyLd/WPQXizsbxFUTqFRoMvaC+zhOULEeZaQkUJj+Gg" # # Generate hashes using the /MKPASSWD command on the server. # Don't run it on a server you don't trust with your password. #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# PBKDF2 module: Allows other modules to generate PBKDF2 hashes, +# usually for cryptographic uses and security. +# This module relies on other hash providers (e.g. SHA256). +#<module name="pbkdf2"> +# +# iterations: Iterations the hashing function runs when generating new +# hashes. +# length: Length in bytes of the derived key. +#<pbkdf2 iterations="12288" length="32"> +# You can override these values with specific values +# for specific providers if you want to. Example given for SHA256. +#<pbkdf2prov hash="sha256" iterations="24576"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Permanent channels module: Channels with the permanent channel mode # will remain open even after everyone else has left the channel, and # therefore keep things like modes, ban lists and topic. Permanent # channels -may- need support from your Services package to function # properly with them. This adds channel mode +P. # This module is oper-only. -#<module name="m_permchannels.so"> +#<module name="permchannels"> # -# If you like, m_permchannels can write a config file of permanent channels +# If you like, this module can write a config file of permanent channels # whenever +P is set, unset, or the topic/modes on a +P channel is changed. # If you want to do this, set the filename below, and uncomment the include. # # If 'listmodes' is true then all list modes (+b, +I, +e, +g...) will be # saved. Defaults to false. -#<permchanneldb filename="data/permchannels.conf" listmodes="true"> -#<include file="data/permchannels.conf"> +#<permchanneldb filename="permchannels.conf" listmodes="true"> +#<include file="permchannels.conf"> # # You may also create channels on startup by using the <permchannels> block. -# Don't forget to set them +P in the modes, or they won't stay permanent. #<permchannels channel="#opers" modes="isP" topic="Opers only."> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# @@ -1413,68 +1650,71 @@ # This module is in extras. Re-run configure with: # ./configure --enable-extras=m_pgsql.cpp # and run make install, then uncomment this module to enable it. -#<module name="m_pgsql.so"> +#<module name="pgsql"> # #-#-#-#-#-#-#-#-#-#-#-#- SQL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # -# m_pgsql.so is more complex than described here, see the docs for # -# more: https://docs.inspircd.org/2/modules/pgsql # +# pgsql is more complex than described here, see the docs for # +# more: https://docs.inspircd.org/3/modules/pgsql # # #<database module="pgsql" name="mydb" user="myuser" pass="mypass" host="localhost" id="my_database" ssl="no"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Muteban: Implements extended ban 'm', which stops anyone matching # a mask like +b m:nick!user@host from speaking on channel. -#<module name="m_muteban.so"> +#<module name="muteban"> +# +# If notifyuser is set to no, the user will not be notified when +# his/her message is blocked. +#<muteban notifyuser="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Random quote module: Provides a random quote on connect. # NOTE: Some of these may mimic fatal errors and confuse users and # opers alike - BEWARE! -#<module name="m_randquote.so"> +#<module name="randquote"> # #-#-#-#-#-#-#-#-#-#- RANDOMQUOTES CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# # # -# Optional - If you specify to use the m_randquote.so module, then # -# specify below the path to the quotes file. # +# Optional - If you specify to use the randquote module, then specify # +# below the path to the quotes file. # # # #<randquote file="quotes.txt"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Redirect module: Adds channel redirection mode +L. # -# Optional: <redirect:antiredirect> to add usermode +L to stop forced # -# redirection and instead print an error. # -# # -# Note: You can not update this with a simple rehash, it requires # -# reloading the module for it to take effect. # -# This also breaks linking to servers that do not have the option. # -# This defaults to false for the 2.0 version, it will be enabled in # -# all the future versions. # -#<module name="m_redirect.so"> -#<redirect antiredirect="true"> +# Redirect module: Adds channel mode +L which redirects users to # +# another channel when the channel has reached its user limit and # +# user mode +L which stops redirection. # +#<module name="redirect"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Regular expression provider for glob or wildcard (?/*) matching. -# You must have at least 1 provider loaded to use m_filter or m_rline +# You must have at least 1 provider loaded to use the filter or R-line # modules. This module has no additional requirements, as it uses the # matching already present in InspIRCd core. -#<module name="m_regex_glob.so"> +#<module name="regex_glob"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Regular expression provider for PCRE (Perl-Compatible Regular # Expressions). You need libpcre installed to compile and load this -# module. You must have at least 1 provider loaded to use m_filter or -# m_rline. -#<module name="m_regex_pcre.so"> +# module. You must have at least 1 provider loaded to use the filter or +# R-line modules. +#<module name="regex_pcre"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Regular Expression Provider for RE2 Regular Expressions. +# You need libre2 installed and in your include/library paths in order +# to compile and load this module. +#<module name="regex_re2"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Regular expression provider for POSIX regular expressions. # You shouldn't need any additional libraries on a POSIX-compatible # system (i.e.: any Linux, BSD, but not Windows). You must have at -# least 1 provider loaded to use m_filter or m_rline. +# least 1 provider loaded to use the filter or R-line modules. # On POSIX-compliant systems, regex syntax can be found by using the # command: 'man 7 regex'. -#<module name="m_regex_posix.so"> +#<module name="regex_posix"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Regular expression provider for C++11 std::regex regular expressions. @@ -1484,7 +1724,7 @@ # You should verify that std::regex is supported by your setup before # using this module, as it may compile normally but won't do anything # on some implementations. -#<module name="m_regex_stdlib.so"> +#<module name="regex_stdlib"> # # Specify the regular expression engine to use here. Valid settings are # bre, ere, awk, grep, egrep, ecmascript (default if not specified). @@ -1496,57 +1736,91 @@ # if you are most familiar with the syntax of /SPAMFILTER from there, # this is the provider you want. You need libtre installed in order # to compile and load this module. -#<module name="m_regex_tre.so"> +#<module name="regex_tre"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Registered users only channel creation module. If enabled, only -# registered users and opers can create new channels. +# Remove module: Adds the /REMOVE command which is a peaceful +# alternative to /KICK. It also provides the /FPART command which works +# in the same way as /REMOVE. +#<module name="remove"> +# +# supportnokicks: If true, /REMOVE is not allowed on channels where the +# nokicks (+Q) mode is set. Defaults to false. +# protectedrank: Members having this rank or above may not be /REMOVE'd +# by anyone. Set to 0 to disable this feature. Defaults to 50000. +#<remove supportnokicks="true" protectedrank="50000"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Repeat module: Allows to block, kick or ban upon similar messages +# being uttered several times. Provides channel mode +E. +# +# Syntax: [~|*]<lines>:<sec>[:<difference>][:<backlog>] +# ~ is to block, * is to ban, default is kick. +# lines - In mode 1, the amount of lines that has to match consecutively. +# In mode 2, the size of the backlog to keep for matching. +# seconds - How old the message has to be before it's invalidated. +# difference - Edit distance, in percent, between two strings to trigger on. +# backlog - When set, the function goes into mode 2. In this mode the +# function will trigger if this many of the last <lines> matches. +# +# As this module can be rather CPU-intensive, it comes with some options. +# maxbacklog - Maximum size that can be specified for backlog. 0 disables +# multiline matching. +# maxdistance - Max percentage of difference between two lines we'll allow +# to match. Set to 0 to disable edit-distance matching. +# maxlines - Max lines of backlog to match against. +# maxtime - Maximum period of time a user can set. 0 to allow any. +# size - Maximum number of characters to check for, can be used to +# truncate messages before they are checked, resulting in +# less CPU usage. Increasing this beyond 512 doesn't have +# any effect, as the maximum length of a message on IRC +# cannot exceed that. +#<repeat maxbacklog="20" maxdistance="50" maxlines="20" maxtime="0" size="512"> +#<module name="repeat"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Restricted channels module: Allows only opers with the +# channels/restricted-create priv and/or registered users to +# create channels. # # You probably *DO NOT* want to load this module on a public network. # -#<module name="m_regonlycreate.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Remove module: Adds the /REMOVE command which is a peaceful -# alternative to /KICK. -#<module name="m_remove.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Restricted channels module: Allows only opers to create channels. +#<module name="restrictchans"> # -# You probably *DO NOT* want to load this module on a public network. +# allowregistered: should registered users be allowed to bypass the restrictions? +#<restrictchans allowregistered="no"> # -#<module name="m_restrictchans.so"> +# Allow any channel matching #user-* to be created, bypassing restrictchans checks +#<allowchannel name="#user-*"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Restrict message module: Allows users to only message opers. # # You probably *DO NOT* want to load this module on a public network. # -#<module name="m_restrictmsg.so"> -# -# Uncomment this to allow users to message ulines (e.g. services): -#<restrictmsg uline="yes"> +#<module name="restrictmsg"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# R-Line module: Ban users through regular expression patterns. -#<module name="m_rline.so"> +# R-line module: Ban users through regular expression patterns. +#<module name="rline"> # #-#-#-#-#-#-#-#-#-#-#-#- RLINE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # If you wish to re-check a user when they change nickname (can be # useful under some situations, but *can* also use CPU with more users # on a server) then set 'matchonnickchange' to yes. +# If you additionally want Z-lines to be added on matches, then +# set 'zlineonmatch' to yes. # Also, this is where you set what Regular Expression engine is to be -# used. If you ever change it while running, all of your R-Lines will -# be wiped. This is the regex engine used by all R-Lines set, and -# m_regex_<engine>.so must be loaded, or rline will be non-functional +# used. If you ever change it while running, all of your R-lines will +# be wiped. This is the regex engine used by all R-lines set, and +# regex_<engine> must be loaded, or rline will be non-functional # until you load it or change the engine to one that is loaded. # -#<rline matchonnickchange="yes" engine="pcre"> +#<rline matchonnickchange="yes" zlineonmatch="no" engine="pcre"> # -# Generally, you will NOT want to use 'glob' here, as this turns -# rline into just another gline. The exceptions are that rline will +# Generally, you will NOT want to use 'glob' here, as this turns an +# R-line into just another G-line. The exceptions are that R-lines will # always use the full "nick!user@host realname" string, rather than only # user@host, but beware that only the ? and * wildcards are available, # and are the only way to specify where the space can occur if you do @@ -1554,18 +1828,28 @@ # so that at least \s or [[:space:]] is available. #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# RMODE module: Adds the /RMODE command. +# Allows channel operators to remove list modes en masse, optionally +# matching a glob-based pattern. +# Syntax: /RMODE <channel> <mode> [<pattern>] +# E.g. '/RMODE #channel b m:*' will remove all mute extbans on the channel. +#<module name="rmode"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SAJOIN module: Adds the /SAJOIN command which forcibly joins a user # to the given channel. # This module is oper-only. # To use, SAJOIN must be in one of your oper class blocks. -#<module name="m_sajoin.so"> +# Opers need the users/sajoin-others priv to be able to /SAJOIN users +# other than themselves. +#<module name="sajoin"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SAKICK module: Adds the /SAKICK command which kicks a user from the # given channel. # This module is oper-only. # To use, SAKICK must be in one of your oper class blocks. -#<module name="m_sakick.so"> +#<module name="sakick"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SAMODE module: Adds the /SAMODE command which allows server operators @@ -1573,50 +1857,51 @@ # channel priviliges. Also allows changing user modes for any user. # This module is oper-only. # To use, SAMODE must be in one of your oper class blocks. -#<module name="m_samode.so"> +#<module name="samode"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SANICK module: Adds the /SANICK command which allows opers to change # users' nicks. # This module is oper-only. # To use, SANICK must be in one of your oper class blocks. -#<module name="m_sanick.so"> +#<module name="sanick"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SAPART module: Adds the /SAPART command which forcibly parts a user # from a channel. # This module is oper-only. # To use, SAPART must be in one of your oper class blocks. -#<module name="m_sapart.so"> +#<module name="sapart"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SAQUIT module: Adds the /SAQUIT command which forcibly quits a user. # This module is oper-only. # To use, SAQUIT must be in one of your oper class blocks. -#<module name="m_saquit.so"> +#<module name="saquit"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SATOPIC module: Adds the /SATOPIC command which allows changing the # topic on a channel without requiring any channel priviliges. # This module is oper-only. # To use, SATOPIC must be in one of your oper class blocks. -#<module name="m_satopic.so"> +#<module name="satopic"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SASL authentication module: Provides support for IRC Authentication -# Layer via AUTHENTICATE. Note: You also need to have m_cap.so loaded +# Layer via AUTHENTICATE. Note: You also need to have cap loaded # for SASL to work. -#<module name="m_sasl.so"> +#<module name="sasl"> # Define the following to your services server name to improve security # by ensuring the SASL messages are only sent to the services server # and not to all connected servers. This prevents a rogue server from -# capturing SASL messages. +# capturing SASL messages and disables the SASL cap when services is +# down. #<sasl target="services.mynetwork.com"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Secure list module: Prevent /LIST in the first minute of connection, # crippling most spambots and trojan spreader bots. -#<module name="m_securelist.so"> +#<module name="securelist"> # #-#-#-#-#-#-#-#-#-# SECURELIST CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # @@ -1630,27 +1915,27 @@ # Define the following variable to change how long a user must wait # # before issuing a LIST. If not defined, defaults to 60 seconds. # # # -#<securelist waittime="60"> # +#<securelist waittime="1m"> # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Servprotect module: Provides support for Austhex style +k / # UnrealIRCD +S services mode. -#<module name="m_servprotect.so"> +#<module name="servprotect"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # See nicks module: Adds snomask +n and +N which show local and remote # nick changes. # This module is oper-only. -#<module name="m_seenicks.so"> +#<module name="seenicks"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Set idle module: Adds a command for opers to change their idle time. # This module is oper-only. # To use, SETIDLE must be in one of your oper class blocks. -#<module name="m_setidle.so"> +#<module name="setidle"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Services support module: Adds several usermodes such as +R and +M. +# Services support module: Adds several user modes such as +R and +M. # This module implements the 'identified' state via account names, # and is similar in operation to the way asuka and ircu handle services. # @@ -1662,39 +1947,89 @@ # +b R: (stop matching account names from joining) # +b U:n!u@h (blocks matching unregistered users) # -#<module name="m_services_account.so"> +#<module name="services_account"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Sethost module: Adds the /SETHOST command. # This module is oper-only. # To use, SETHOST must be in one of your oper class blocks. -# See m_chghost for how to customise valid chars for hostnames. -#<module name="m_sethost.so"> +# See the chghost module for how to customise valid chars for hostnames. +#<module name="sethost"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Setident module: Adds the /SETIDENT command. # This module is oper-only. # To use, SETIDENT must be in one of your oper class blocks. -#<module name="m_setident.so"> +#<module name="setident"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SETNAME module: Adds the /SETNAME command. -#<module name="m_setname.so"> +#<module name="setname"> +# +#-#-#-#-#-#-#-#-#-#-#-#- SETNAME CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# +# # +# operonly - Whether the SETNAME command should only be usable by # +# server operators. Defaults to no. # +# # +# notifyopers - Whether to send a snotice to snomask `a` when a user # +# changes their real name. Defaults to to yes if # +# oper-only and no if usable by everyone. # +# # +#<setname notifyopers="yes" +# operonly="no"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Serverban: Implements extended ban 's', which stops anyone connected # to a server matching a mask like +b s:server.mask.here from joining. -#<module name="m_serverban.so"> +# Wildcards are accepted. +#<module name="serverban"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# SHA1 module: Allows other modules to generate SHA1 hashes. +# Required by the WebSocket module. +#<module name="sha1"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Show whois module: Adds the +W usermode which allows opers to see +# Showfile: Provides support for showing a text file to users when # +# they enter a command. # +# This module adds one command for each <showfile> tag that shows the # +# given file to the user as a series of messages or numerics. # +#<module name="showfile"> +# # +#-#-#-#-#-#-#-#-#-#-# SHOWFILE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# +# # +# name - The name of the command which displays this file. This is # +# the only mandatory setting, all others are optional. # +# file - The text file to be shown to the user. # +# By default same as the command name. # +# method - How should the file be shown? # +# * numeric: Send contents using a numeric # +# (similar to /MOTD; the default). # +# * notice: Send contents as a series of notices. # +# * msg: Send contents as a series of private messages. # +# # +# When using the method "numeric", the following extra settings are # +# available: # +# # +# introtext - Introductory line, "Showing <name>" by default. # +# intronumeric - Numeric used for the introductory line. # +# numeric - Numeric used for sending the text itself. # +# endtext - Ending line, "End of <name>" by default. # +# endnumeric - Numeric used for the ending line. # +# # +#<showfile name="RULES" +# file="rules.txt" +# introtext="Server rules:" +# endtext="End of server rules."> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# Show whois module: Adds the +W user mode which allows opers to see # when they are /WHOIS'd. # This module is oper-only by default. -#<module name="m_showwhois.so"> +#<module name="showwhois"> # # If you wish, you may also let users set this mode. Only opers with the -# users/auspex priv will see real hosts of people, though. This setting -# is not reloadable via /REHASH, changing it requires /RELOADMODULE. +# users/auspex priv will see real hosts of people, though. #<showwhois opersonly="yes" # # You may also set whether or not users should receive whois notices, @@ -1706,7 +2041,7 @@ # executing all except configured commands. # This module is oper-only. # To use, SHUN must be in one of your oper class blocks. -#<module name="m_shun.so"> +#<module name="shun"> # # You may also configure which commands you wish a user to be able to # perform when shunned. It should be noted that if a shunned user @@ -1719,64 +2054,84 @@ #<shun enabledcommands="ADMIN PING PONG QUIT PART JOIN" notifyuser="yes" affectopers="no"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# SSL channel mode module: Adds support for SSL-only channels via -# channel mode +z and the 'z' extban which matches SSL client -# certificate fingerprints. +# SSL mode module: Adds support for SSL-only channels via the '+z' +# channel mode, SSL-only private messages via the '+z' user mode and +# the 'z:' extban which matches SSL client certificate fingerprints. +# # Does not do anything useful without a working SSL module and the -# m_sslinfo module (see below). -#<module name="m_sslmodes.so"> +# sslinfo module (see below). +#<module name="sslmodes"> +# +# The +z user mode is not enabled by default to enable link compatibility +# with 2.0 servers. You can enable it by uncommenting this: +#<sslmodes enableumode="yes"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# SSL rehash signal module: Allows the SSL modules to be rehashed by +# sending SIGUSR1 to a running InspIRCd process. +# This modules is in extras. Re-run configure with: +# ./configure --enable-extras=m_sslrehashsignal.cpp +# and run make install, then uncomment this module to enable it. +#<module name="sslrehashsignal"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # GnuTLS SSL module: Adds support for SSL connections using GnuTLS, # if enabled. You must answer 'yes' in ./configure when asked or # manually symlink the source for this module from the directory # src/modules/extra, if you want to enable this, or it will not load. -#<module name="m_ssl_gnutls.so"> +#<module name="ssl_gnutls"> # #-#-#-#-#-#-#-#-#-#-#- GNUTLS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# m_ssl_gnutls.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_gnutls # +# ssl_gnutls is too complex to describe here, see the docs: # +# https://docs.inspircd.org/3/modules/ssl_gnutls # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SSL info module: Allows users to retrieve information about other # users' peer SSL certificates and keys. This can be used by client -# scripts to validate users. For this to work, one of m_ssl_gnutls.so -# or m_ssl_openssl.so must be loaded. This module also adds the +# scripts to validate users. For this to work, one of ssl_gnutls +# or ssl_openssl must be loaded. This module also adds the # "* <user> is using a secure connection" whois line, the ability for -# opers to use SSL fingerprints to verify their identity and the +# opers to use SSL cert fingerprints to verify their identity and the # ability to force opers to use SSL connections in order to oper up. # It is highly recommended to load this module if you use SSL on your # network. # For how to use the oper features, please see the first example <oper> tag # in opers.conf.example. # -#<module name="m_sslinfo.so"> +#<module name="sslinfo"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# mbedTLS SSL module: Adds support for SSL/TLS connections using mbedTLS. +#<module name="ssl_mbedtls"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # OpenSSL SSL module: Adds support for SSL connections using OpenSSL, # if enabled. You must answer 'yes' in ./configure when asked or symlink # the source for this module from the directory src/modules/extra, if # you want to enable this, or it will not load. -#<module name="m_ssl_openssl.so"> +#<module name="ssl_openssl"> # #-#-#-#-#-#-#-#-#-#-#- OPENSSL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# m_ssl_openssl.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_openssl # +# ssl_openssl is too complex to describe here, see the docs: # +# https://docs.inspircd.org/3/modules/ssl_openssl # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Strip color module: Adds channel mode +S that strips mIRC color -# codes from all messages sent to the channel. -#<module name="m_stripcolor.so"> +# Strip color module: Adds channel mode +S that strips color codes and +# all control codes except CTCP from all messages sent to the channel. +#<module name="stripcolor"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Silence module: Adds support for the /SILENCE command, which allows # users to have a server-side ignore list for their client. -#<module name="m_silence.so"> +#<module name="silence"> # # Set the maximum number of entries allowed on a user's silence list. -#<silence maxentries="32"> +#<silence maxentries="32" +# +# Whether messages from U-lined servers will bypass silence masks. +#exemptuline="yes"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SQLite3 module: Allows other SQL modules to access SQLite3 # @@ -1785,12 +2140,12 @@ # ./configure --enable-extras=m_sqlite3.cpp # and run make install, then uncomment this module to enable it. # # -#<module name="m_sqlite3.so"> +#<module name="sqlite3"> # #-#-#-#-#-#-#-#-#-#-#-#- SQL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # -# m_sqlite.so is more complex than described here, see the docs for # -# more: https://docs.inspircd.org/2/modules/sqlite3 # +# sqlite is more complex than described here, see the docs for more # +# info: https://docs.inspircd.org/3/modules/sqlite3 # # #<database module="sqlite" hostname="/full/path/to/database.db" id="anytext"> @@ -1798,61 +2153,64 @@ # SQL authentication module: Allows IRCd connections to be tied into # a database table (for example a forum). # -#<module name="m_sqlauth.so"> +#<module name="sqlauth"> # #-#-#-#-#-#-#-#-#-#-#- SQLAUTH CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # -# m_sqlauth.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/sqlauth # +# sqlauth is too complex to describe here, see the docs: # +# https://docs.inspircd.org/3/modules/sqlauth # #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# SQL oper module: Allows you to store oper credentials in an SQL table +# SQL oper module: Allows you to store oper credentials in an SQL +# table. You can add additional table columns like you would config +# tags in opers.conf. Opers in opers.conf will override opers from +# this module. # -#<module name="m_sqloper.so"> +#<module name="sqloper"> # #-#-#-#-#-#-#-#-#-#-#- SQLOPER CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# # # # dbid - Database ID to use (see SQL modules). # -# hash - Hashing provider to use for password hashing. # # # -# See also: https://docs.inspircd.org/2/modules/sqloper # +# See also: https://docs.inspircd.org/3/modules/sqloper # # # -#<sqloper dbid="1" hash="md5"> +#<sqloper dbid="1"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# StartTLS module: Implements STARTTLS, which allows clients # +# connected to non SSL enabled ports to enable SSL, if a proper SSL # +# module is loaded (either ssl_gnutls or ssl_openssl). # +#<module name="starttls"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# SVSHold module: Implements SVSHOLD. Like Q:Lines, but can only be # +# SVSHold module: Implements SVSHOLD. Like Q-lines, but can only be # # added/removed by Services. # -#<module name="m_svshold.so"> -# If silent is true no snotices will be generated by SVSHOLD. +#<module name="svshold"> +# SVSHOLD does not generate server notices by default, you can turn +# notices on by uncommenting the next line. #<svshold silent="false"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # SWHOIS module: Allows you to add arbitrary lines to user WHOIS. # This module is oper-only. # To use, SWHOIS must be in one of your oper class blocks. -#<module name="m_swhois.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Test module: Enable this to create a command useful in testing -# flood control. To avoid accidental use on live networks, the server -# name must contain ".test" to load the module -#<module name="m_testnet.so"> +#<module name="swhois"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Timed bans module: Adds timed channel bans with the /TBAN command. -#<module name="m_timedbans.so"> +#<module name="timedbans"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Test line module: Adds the /TLINE command, used to test how many # users a /GLINE or /ZLINE etc. would match. # This module is oper-only. # To use, TLINE must be in one of your oper class blocks. -#<module name="m_tline.so"> +#<module name="tline"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Topiclock module: implements server-side topic locking to achieve deeper # integration with services packages. -#<module name="m_topiclock.so"> +#<module name="topiclock"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # UHNAMES support module: Adds support for the IRCX style UHNAMES @@ -1860,23 +2218,23 @@ # each user, saving clients from doing a WHO on the channel. # If a client does not support UHNAMES it will not enable it, this will # not break incompatible clients. -#<module name="m_uhnames.so"> +#<module name="uhnames"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Uninvite module: Adds the /UNINVITE command which lets users remove # pending invites from channels without waiting for the user to join. -#<module name="m_uninvite.so"> +#<module name="uninvite"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Userip module: Adds the /USERIP command. # Allows users to query their own IP, also allows opers to query the IP # of anyone else. -#<module name="m_userip.so"> +#<module name="userip"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Vhost module: Adds the VHOST command which allows for adding virtual # hosts which are accessible using a username and password in the config. -#<module name="m_vhost.so"> +#<module name="vhost"> # #-#-#-#-#-#-#-#-#-#-#- VHOST CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# # # @@ -1885,32 +2243,51 @@ # pass - Password for the vhost. # # # # hash - The hash for the specific user (optional) # -# m_password_hash.so and a hashing module must be loaded # -# for this to work. # +# password_hash and a hashing module must be loaded for # +# this to work. # # # # host - Vhost to set. # # #<vhost user="some_username" pass="some_password" host="some.host.test.cc"> -#<vhost user="foo" password="fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9" hash="sha256" host="some.other.host.example.com"> +#<vhost user="foo" password="$2a$10$iTuYLT6BRhRlOgzfsW9oPe62etW.oXwSpyKw5rJit64SGZanLXghO" hash="bcrypt" host="some.other.host.example.com"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # Watch module: Adds the WATCH command, which is used by clients to # maintain notify lists. -#<module name="m_watch.so"> +#<module name="watch"> # # Set the maximum number of entries on a user's watch list below. #<watch maxentries="32"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# XLine database: Stores all *Lines (G/Z/K/R/any added by other modules) +# WebSocket module: Adds HTML5 WebSocket support. +# Specify hook="websocket" in a <bind> tag to make that port accept +# WebSocket connections. Compatible with SSL/TLS. +# Requires SHA-1 hash support available in the sha1 module. +#<module name="websocket"> +# +# Whether to re-encode messages as UTF-8 before sending to WebSocket +# clients. This is recommended as the WebSocket protocol requires all +# text frames to be sent as UTF-8. If you do not have this enabled +# messages will be sent as binary frames instead. +#<websocket sendastext="yes"> +# +# If you use the websocket module you MUST specify one or more origins +# which are allowed to connect to the server. You should set this as +# strict as possible to prevent malicious webpages from connecting to +# your server. +# <wsorigin allow="https://*.example.com/"> + +#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# +# X-line database: Stores all *-lines (G/Z/K/R/any added by other modules) # in a file which is re-loaded on restart. This is useful # for two reasons: it keeps bans so users may not evade them, and on # bigger networks, server connections will take less time as there will # be a lot less bans to apply - as most of them will already be there. -#<module name="m_xline_db.so"> +#<module name="xline_db"> # Specify the filename for the xline database here. -#<xlinedb filename="data/xline.db"> +#<xlinedb filename="xline.db"> #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# # ____ _ _____ _ _ ____ _ _ _ # @@ -1919,8 +2296,8 @@ # | _ < __/ (_| | (_| | | | | | | | \__ \ | |_) | | |_|_| # # |_| \_\___|\__,_|\__,_| |_| |_| |_|_|___/ |____/|_|\__(_) # # # -# To link servers to InspIRCd, you MUST load the m_spanningtree # -# module. If you don't do this, server links will NOT work at all. # +# To link servers to InspIRCd, you MUST load the spanningtree module. # +# If you don't do this, server links will NOT work at all. # # This is by design, to allow for the implementation of other linking # # protocols in modules in the future. # @@ -1929,4 +2306,4 @@ # tree protocol (see the READ THIS BIT section above). # You will almost always want to load this. # -#<module name="m_spanningtree.so"> +#<module name="spanningtree"> diff --git a/docs/conf/modules/charybdis.conf.example b/docs/conf/modules/charybdis.conf.example deleted file mode 100644 index 39238ec5f..000000000 --- a/docs/conf/modules/charybdis.conf.example +++ /dev/null @@ -1,302 +0,0 @@ -<module name="m_md5.so"> -<module name="m_sha256.so"> -<module name="m_alias.so"> -<alias text="NICKSERV" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CHANSERV" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OPERSERV" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="BOTSERV" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HOSTSERV" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="MEMOSERV" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="NS" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CS" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OS" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="BS" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HS" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="MS" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="ID" replace="PRIVMSG NickServ :IDENTIFY $2" requires="NickServ" uline="yes"> - -<module name="m_banexception.so"> -<module name="m_banredirect.so"> -<module name="m_blockcolor.so"> -<module name="m_callerid.so"> -<callerid maxaccepts="16" - operoverride="no" - tracknick="no" - cooldown="60"> - -<module name="m_cap.so"> -<module name="m_cban.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# CGI:IRC module: Adds support for automatic host changing in CGI:IRC -# (http://cgiirc.sourceforge.net). -#<module name="m_cgiirc.so"> -# -#-#-#-#-#-#-#-#-#-#-#-# CGIIRC CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# -# -# Optional - If you specify to use m_cgiirc, then you must specify one -# or more cgihost tags which indicate authorised CGI:IRC servers which -# will be connecting to your network, and an optional cgiirc tag. -# For more information see: https://docs.inspircd.org/2/modules/cgiirc -# -# Set to yes if you want to notice opers when CGI clients connect -# <cgiirc opernotice="no"> -# -# The type field indicates where the module should get the real -# client's IP address from, for further information, please see the -# CGI:IRC documentation. -# -# Old style: -# <cgihost type="pass" mask="www.mysite.com"> # Get IP from PASS -# <cgihost type="ident" mask="otherbox.mysite.com"> # Get IP from ident -# <cgihost type="passfirst" mask="www.mysite.com"> # See the docs -# New style: -# <cgihost type="webirc" password="foobar" -# mask="somebox.mysite.com"> # Get IP from WEBIRC -# -# IMPORTANT NOTE: -# --------------- -# -# When you connect CGI:IRC clients, there are two connect classes which -# apply to these clients. When the client initially connects, the connect -# class which matches the cgi:irc site's host is checked. Therefore you -# must raise the maximum local/global clients for this ip as high as you -# want to allow cgi clients. After the client has connected and is -# determined to be a cgi:irc client, the class which matches the client's -# real IP is then checked. You may set this class to a lower value, so that -# the real IP of the client can still be restricted to, for example, 3 -# sessions maximum. -# - -<module name="m_chancreate.so"> -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Channel names module: Allows disabling channels which have certain -# characters in the channel name such as bold, colorcodes, etc. which -# can be quite annoying and allow users to on occasion have a channel -# that looks like the name of another channel on the network. -<module name="m_channames.so"> - -<channames - # denyrange: characters or range of characters to deny in channel - # names. - denyrange="2" - - # allowrange: characters or range of characters to specifically allow - # in channel names. - allowrange=""> - -<module name="m_channelban.so"> -<module name="m_chghost.so"> -<hostname charmap="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_/0123456789"> -<module name="m_chgident.so"> -<module name="m_chgname.so"> -<module name="m_cloaking.so"> -# -#-#-#-#-#-#-#-#-#-#-#- CLOAKING CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# If you specify the m_cloaking.so module as above, you must define # -# cloak keys, and optionally a cloak prefix as shown below. The cloak # -# keys must be shared across the network for correct cloaking. # -# # -# There are four methods of cloaking: # -# # -# half Cloak only the "unique" portion of a host; show # -# the last 2 parts of the domain, /16 subnet of IPv4 # -# or /48 subnet of the IPv6 address. # -# # -# full Cloak the users completely, using three slices for # -# common CIDR bans (IPv4: /16, /24; IPv6: /48, /64) # -# # -# These methods use a single key that can be any length of text. # -# An optional prefix may be specified to mark cloaked hosts. # -# # -# The following methods are maintained for backwards compatibility; # -# they are slightly less secure, and always hide unresolved IPs # -# # -# compat-host InspIRCd 1.2-compatible host-based cloaking # -# compat-ip InspIRCd 1.2-compatible ip-always cloaking # -# # -# You must specify key1, key2, key3, key4 for the compat cloaking # -# modes; the values must be less than 0x80000000 and should be picked # -# at random. Prefix is mandatory, will default to network name if not # -# specified, and will always have a "-" appended. # -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# -<cloak mode="half" - key="secret" - prefix="net-"> - -<module name="m_close.so"> -<module name="m_conn_umodes.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Connectban: Provides IP connection throttling. Any IP range that connects -# too many times (configurable) in an hour is zlined for a (configurable) -# duration, and their count resets to 0. -# -# ipv4cidr and ipv6cidr allow you to turn the comparison from individual -# IP addresses (32 and 128 bits) into CIDR masks, to allow for throttling -# over whole ISPs/blocks of IPs, which may be needed to prevent attacks. -# -#<connectban threshold="10" duration="10m" ipv4cidr="32" ipv6cidr="128"> -# This allows for 10 connections in an hour with a 10 minute ban if that is exceeded. -# -#<module name="m_connectban.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Connection throttle module. -#<module name="m_connflood.so"> -# -#-#-#-#-#-#-#-#-#-#-#- CONTHROTTLE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# seconds, maxconns - Amount of connections per <seconds>. -# -# timeout - Time to wait after the throttle was activated -# before deactivating it. Be aware that the time -# is seconds + timeout. -# -# quitmsg - The message that users get if they attempt to -# connect while the throttle is active. -# -# bootwait - Amount of time to wait before enforcing the -# throttling when the server just booted. -# -#<connflood seconds="30" maxconns="3" timeout="30" -# quitmsg="Throttled" bootwait="10"> - -<module name="m_deaf.so"> -<module name="m_dnsbl.so"> -<module name="m_gecosban.so"> -<module name="m_globalload.so"> -<module name="m_ident.so"> -<ident timeout="1"> -<module name="m_inviteexception.so"> -<module name="m_joinflood.so"> -<module name="m_knock.so"> -<module name="m_namesx.so"> -<module name="m_operchans.so"> -<module name="m_operlog.so"> -<module name="m_opermodes.so"> -<module name="m_password_hash.so"> -<module name="m_permchannels.so"> -<module name="m_muteban.so"> -<module name="m_redirect.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for glob or wildcard (?/*) matching. -# You must have at least 1 provider loaded to use m_filter or m_rline -# modules. This module has no additional requirements, as it uses the -# matching already present in InspIRCd core. -#<module name="m_regex_glob.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for PCRE (Perl-Compatible Regular -# Expressions). You need libpcre installed to compile and load this -# module. You must have at least 1 provider loaded to use m_filter or -# m_rline. -#<module name="m_regex_pcre.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for POSIX regular expressions. -# You shouldn't need any additional libraries on a POSIX-compatible -# system (ie: any Linux, BSD, but not Windows). You must have at least -# 1 provider loaded to use m_filter or m_rline. -# On POSIX-compliant systems, regex syntax can be found by using the -# command: 'man 7 regex'. -#<module name="m_regex_posix.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Registered users only channel creation -# Allows only registered users and opers to create new channels. -# -# You probably *DO NOT* want to load this module on a public network. -# -#<module name="m_regonlycreate.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Ban users through regular expression patterns -#<module name="m_rline.so"> -# -#-#-#-#-#-#-#-#-#-#-#-#- RLINE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-#-# -# -# If you wish to re-check a user when they change nickname (can be -# useful under some situations, but *can* also use CPU with more users -# on a server) then set the following configuration value: -# Also, this is where you set what Regular Expression engine is to be -# used. If you ever change it while running, all of your R-Lines will be -# wiped. This is the regex engine used by all R-Lines set, and -# m_regex_<engine>.so must be loaded, or rline will be nonfunctional -# until you load it or change the engine to one that is loaded. -# -#<rline matchonnickchange="yes" engine="pcre"> -# -# Generally, you will NOT want to use 'glob' here, as this turns -# rline into just another gline. The exceptions are that rline will -# always use the full nick!user@host realname string, rather than only -# user@host, but beware that only the ? and * wildcards are available, -# and are the only way to specify where the space can occur if you do -# use glob. For this reason, is recommended to use a real regex engine -# so that at least \s or [[:space:]] is available. - -<module name="m_sasl.so"> -<module name="m_servprotect.so"> -<module name="m_services_account.so"> -<module name="m_sethost.so"> -<module name="m_serverban.so"> -<module name="m_showwhois.so"> -<showwhois opersonly="yes" showfromopers="yes"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# SSL channel mode module: Adds support for SSL-only channels via -# channel mode +z and the 'z' extban which matches SSL client -# certificate fingerprints. -# Does not do anything useful without a working SSL module (see below). -#<module name="m_sslmodes.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# GnuTLS SSL module: Adds support for SSL connections using GnuTLS, -# if enabled. You must answer 'yes' in ./configure when asked or -# manually symlink the source for this module from the directory -# src/modules/extra, if you want to enable this, or it will not load. -#<module name="m_ssl_gnutls.so"> -# -#-#-#-#-#-#-#-#-#-#-#- GNUTLS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# m_ssl_gnutls.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_gnutls # - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# SSL Info module: Allows users to retrieve information about other -# user's peer SSL certificates and keys. This can be used by client -# scripts to validate users. For this to work, one of m_ssl_gnutls.so -# or m_ssl_openssl.so must be loaded. This module also adds the -# "* <user> is using a secure connection" whois line, the ability for -# opers to use SSL fingerprints to verify their identity and the ability -# to force opers to use SSL connections in order to oper up. -# It is highly recommended to load this module especially if -# you use SSL on your network. -# For how to use the oper features, please see the first example <oper> tag -# in opers.conf.example. -# -#<module name="m_sslinfo.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# OpenSSL SSL module: Adds support for SSL connections using OpenSSL, -# if enabled. You must answer 'yes' in ./configure when asked or symlink -# the source for this module from the directory src/modules/extra, if -# you want to enable this, or it will not load. -#<module name="m_ssl_openssl.so"> -# -#-#-#-#-#-#-#-#-#-#-#- OPENSSL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# m_ssl_openssl.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_openssl # - -<module name="m_stripcolor.so"> -<module name="m_svshold.so"> -<module name="m_tline.so"> -<module name="m_uhnames.so"> -<module name="m_watch.so"> -<watch maxentries="32"> -<module name="m_xline_db.so"> - -<module name="m_spanningtree.so"> diff --git a/docs/conf/modules/unrealircd.conf.example b/docs/conf/modules/unrealircd.conf.example deleted file mode 100644 index 1d2ea39cc..000000000 --- a/docs/conf/modules/unrealircd.conf.example +++ /dev/null @@ -1,399 +0,0 @@ -<module name="m_md5.so"> -<module name="m_sha256.so"> -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Alias module: Allows you to define server-side command aliases. -<module name="m_alias.so"> -<fantasy prefix="!" allowbots="no"> -# Aliases -<alias text="NICKSERV" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CHANSERV" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OPERSERV" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="BOTSERV" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HOSTSERV" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="MEMOSERV" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -<alias text="NS" replace="PRIVMSG NickServ :$2-" requires="NickServ" uline="yes"> -<alias text="CS" replace="PRIVMSG ChanServ :$2-" requires="ChanServ" uline="yes"> -<alias text="OS" replace="PRIVMSG OperServ :$2-" requires="OperServ" uline="yes" operonly="yes"> -<alias text="BS" replace="PRIVMSG BotServ :$2-" requires="BotServ" uline="yes"> -<alias text="HS" replace="PRIVMSG HostServ :$2-" requires="HostServ" uline="yes"> -<alias text="MS" replace="PRIVMSG MemoServ :$2-" requires="MemoServ" uline="yes"> -# -# An example of using the format value to create an alias with two -# different behaviours depending on the format of the parameters. -# -#<alias text="ID" format="#*" replace="PRIVMSG ChanServ :IDENTIFY $2 $3" -# requires="ChanServ" uline="yes"> -# -#<alias text="ID" replace="PRIVMSG NickServ :IDENTIFY $2" -# requires="NickServ" uline="yes"> -# -# This alias fixes a glitch in xchat 2.6.x and above and the way it -# assumes IDENTIFY must be prefixed by a colon (:) character. It should -# be placed ABOVE the default NICKSERV alias (the first example) listed -# above. -# -#<alias text="NICKSERV" format=":IDENTIFY *" replace="PRIVMSG NickServ :IDENTIFY $3-" -# requires="NickServ" uline="yes"> - -<module name="m_allowinvite.so"> -<module name="m_alltime.so"> -<module name="m_auditorium.so"> -<auditorium showops="yes" operoverride="yes"> -<module name="m_banexception.so"> -<module name="m_blockcaps.so"> -<blockcaps percent="50" - minlen="5" - capsmap="ABCDEFGHIJKLMNOPQRSTUVWXYZ! "> -<module name="m_blockcolor.so"> -<module name="m_botmode.so"> -<module name="m_censor.so"> -<include file="inspircd.censor.example"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# CGI:IRC module: Adds support for automatic host changing in CGI:IRC -# (http://cgiirc.sourceforge.net). -#<module name="m_cgiirc.so"> -# -#-#-#-#-#-#-#-#-#-#-#-# CGIIRC CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-#-# -# -# Optional - If you specify to use m_cgiirc, then you must specify one -# or more cgihost tags which indicate authorised CGI:IRC servers which -# will be connecting to your network, and an optional cgiirc tag. -# For more information see: https://docs.inspircd.org/2/modules/cgiirc -# -# Set to yes if you want to notice opers when CGI clients connect -# <cgiirc opernotice="no"> -# -# The type field indicates where the module should get the real -# client's IP address from, for further information, please see the -# CGI:IRC documentation. -# -# Old style: -# <cgihost type="pass" mask="www.mysite.com"> # Get IP from PASS -# <cgihost type="ident" mask="otherbox.mysite.com"> # Get IP from ident -# <cgihost type="passfirst" mask="www.mysite.com"> # See the docs -# New style: -# <cgihost type="webirc" password="foobar" -# mask="somebox.mysite.com"> # Get IP from WEBIRC -# -# IMPORTANT NOTE: -# --------------- -# -# When you connect CGI:IRC clients, there are two connect classes which -# apply to these clients. When the client initially connects, the connect -# class which matches the cgi:irc site's host is checked. Therefore you -# must raise the maximum local/global clients for this ip as high as you -# want to allow cgi clients. After the client has connected and is -# determined to be a cgi:irc client, the class which matches the client's -# real IP is then checked. You may set this class to a lower value, so that -# the real IP of the client can still be restricted to, for example, 3 -# sessions maximum. -# - -<module name="m_chanfilter.so"> -<chanfilter hidemask="yes"> - -<module name="m_chanprotect.so"> - -<chanprotect - noservices="no" - qprefix="~" - aprefix="&" - deprotectself="yes" - deprotectothers="yes"> - -<module name="m_check.so"> -<module name="m_chghost.so"> -<hostname charmap="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_/0123456789"> - -<module name="m_chgident.so"> -<module name="m_chgname.so"> -<module name="m_cloaking.so"> -<cloak mode="half" - key="secret" - prefix="net-"> - -<module name="m_close.so"> -<module name="m_clones.so"> -<module name="m_commonchans.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Auto join on connect module: Allows you to force users to join one -# or more channels automatically upon connecting to the server. -#<module name="m_conn_join.so"> -# -#-#-#-#-#-#-#-#-#-#-#-#- CONNJOIN CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# -# If you have m_conn_join.so loaded, you can configure it using the -# follow values: -# -#<autojoin channel="#one,#two,#three"> - -<module name="m_conn_umodes.so"> -<module name="m_cycle.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Connection throttle module. -#<module name="m_connflood.so"> -# -#-#-#-#-#-#-#-#-#-#-#- CONTHROTTLE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# seconds, maxconns - Amount of connections per <seconds>. -# -# timeout - Time to wait after the throttle was activated -# before deactivating it. Be aware that the time -# is seconds + timeout. -# -# quitmsg - The message that users get if they attempt to -# connect while the throttle is active. -# -# bootwait - Amount of time to wait before enforcing the -# throttling when the server just booted. -# -#<connflood seconds="30" maxconns="3" timeout="30" -# quitmsg="Throttled" bootwait="10"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# DCCALLOW module: Adds the /DCCALLOW command. -<module name="m_dccallow.so"> -# -#-#-#-#-#-#-#-#-#-#-#- DCCALLOW CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# blockchat - Whether to block DCC CHAT as well as DCC SEND -# length - Default duration of entries in DCCALLOW list -# action - Default action to take if no action is specified -# can be 'block' or 'allow' -# -# File configuration: -# pattern - The glob pattern to match against -# action - Action to take if a user attempts to send a file -# that matches this pattern, can be 'block' or 'allow' -# -#<dccallow blockchat="yes" length="5m" action="block"> -#<banfile pattern="*.exe" action="block"> -#<banfile pattern="*.txt" action="allow"> -# -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# - -<module name="m_deaf.so"> -<module name="m_denychans.so"> -#<badchan name="#gods*" allowopers="yes" reason="Tortoises!"> # -#<badchan name="#heaven" redirect="#hell" reason="Nice try!"> # - -<module name="m_devoice.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Filter module: Provides message filtering, similar to SPAMFILTER. -<module name="m_filter.so"> -# # -# This module depends upon a regex provider such as m_regex_pcre or # -# m_regex_glob to function. You must specify which of these you want # -# m_filter to use via the tag below. # -# # -# Valid engines are: # -# # -# glob - Glob patterns, provided via m_regex_glob. # -# pcre - PCRE regexps, provided via m_regex_pcre, needs libpcre. # -# tre - TRE regexps, provided via m_regex_tre, requires libtre. # -# posix - POSIX regexps, provided via m_regex_posix, not available # -# on Windows, no dependencies on other operating systems. # -# stdlib - stdlib regexps, provided via m_regex_stdlib, see comment # -# at the <module> tag for info on availability. # -# # -<filteropts engine="glob"> -# # -# Your choice of regex engine must match on all servers network-wide. -# -# You may specify specific channels that are exempt from being filtered: -#<exemptfromfilter channel="#blah"> -# -#-#-#-#-#-#-#-#-#-#-#- FILTER CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# Optional - If you specify to use the m_filter module, then # -# specfiy below the path to the filter.conf file, or define some # -# <filter> tags. # -# # -#<include file="filter.conf"> - -<module name="m_gecosban.so"> -<module name="m_globops.so"> -<module name="m_globalload.so"> -<module name="m_halfop.so"> -<module name="m_helpop.so"> -<include file="inspircd.helpop-full.example"> - -<module name="m_hidechans.so"> -<hidechans affectsopers="false"> - -<module name="m_hideoper.so"> -<module name="m_ident.so"> -<ident timeout="1"> -<module name="m_inviteexception.so"> -<module name="m_joinflood.so"> -<module name="m_jumpserver.so"> -<module name="m_knock.so"> -<module name="m_messageflood.so"> -<module name="m_namesx.so"> -<module name="m_nickflood.so"> -<module name="m_noctcp.so"> -<module name="m_nokicks.so"> -<module name="m_nonicks.so"> -<module name="m_nopartmsg.so"> -<module name="m_nonotice.so"> -<module name="m_operchans.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Oper join module: Auto-joins opers to a channel upon oper-up. -# This module is oper-only. For the user equivalent, see m_conn_join. -<module name="m_operjoin.so"> -# -#-#-#-#-#-#-#-#-#-#-# OPERJOIN CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# # -# If you are using the m_operjoin.so module, specify options here: # -# # -# channel - The channel name to join, can also be a comma # -# separated list eg. "#channel1,#channel2". # -# # -# override - Lets the oper join walking thru any modes that # -# might be set, even bans. Use "yes" or "no". # -# # -#<operjoin channel="#channel" override="no"> -# -# Alternatively you can use the autojoin="channellist" in a <type> # -# tag to set specific autojoins for a type of oper, for example: # -# -#<type name="Helper" autojoin="#help" classes="..."> - -<module name="m_operlog.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Oper MOTD module: Provides support for separate message of the day -# on oper-up. -# This module is oper-only. -#<module name="m_opermotd.so"> -# -#-#-#-#-#-#-#-#-#-#-# OPERMOTD CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# # -# If you are using the m_opermotd.so module, specify the motd here # -# # -# onoper - If on, the message is sent on /OPER, otherwise it's # -# only sent when /OPERMOTD is used. # -# # -#<opermotd file="oper.motd" onoper="yes"> - -<module name="m_override.so"> -#-#-#-#-#-#-#-#-#-#-# OVERRIDE CONFIGURATION -#-#-#-#-#-#-#-#-#-#-# -# # -# m_override.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/override # - -<module name="m_operlevels.so"> -<module name="m_opermodes.so"> -<module name="m_password_hash.so"> -<module name="m_muteban.so"> - -<module name="m_redirect.so"> -<module name="m_regex_glob.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for PCRE (Perl-Compatible Regular -# Expressions). You need libpcre installed to compile and load this -# module. You must have at least 1 provider loaded to use m_filter or -# m_rline. -#<module name="m_regex_pcre.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for POSIX Regular Expressions. -# You shouldn't need any additional libraries on a POSIX-compatible -# system (ie: any Linux, BSD, but not Windows). You must have at least -# 1 provider loaded to use m_filter or m_rline. -# On POSIX-compliant systems, regex syntax can be found by using the -# command: 'man 7 regex'. -#<module name="m_regex_posix.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Regular expression provider for TRE Regular Expressions. -# This is the same regular expression engine used by UnrealIRCd, so -# if you are most familiar with the syntax of /spamfilter from there, -# this is the provider you want. You need libtre installed in order -# to compile and load this module. -#<module name="m_regex_tre.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Registered users only channel creation module. If enabled, only -# registered users and opers can create new channels. -# -# You probably *DO NOT* want to load this module on a public network. -# -#<module name="m_regonlycreate.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Restricted channels module: Allows only opers to create channels. -# -# You probably *DO NOT* want to load this module on a public network. -# -#<module name="m_restrictchans.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# Restrict message module: Allows users to only message opers. -# -# You probably *DO NOT* want to load this module on a public network. -# -#<module name="m_restrictmsg.so"> - -<module name="m_sajoin.so"> -<module name="m_sakick.so"> -<module name="m_samode.so"> -<module name="m_sanick.so"> -<module name="m_sapart.so"> -<module name="m_saquit.so"> -<module name="m_satopic.so"> -<module name="m_servprotect.so"> -<module name="m_seenicks.so"> -<module name="m_setidle.so"> -<module name="m_services_account.so"> -<module name="m_sethost.so"> -<module name="m_setident.so"> -<module name="m_setname.so"> -<module name="m_showwhois.so"> -<showwhois opersonly="yes" showfromopers="yes"> - -<module name="m_shun.so"> -<shun enabledcommands="PING PONG QUIT PART JOIN" notifyuser="no" affectopers="no"> - -<module name="m_sslmodes.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# GnuTLS SSL module: Adds support for SSL connections using GnuTLS, -# if enabled. You must answer 'yes' in ./configure when asked or symlink -# the source for this module from the directory src/modules/extra, if -# you want to enable this, or it will not load. -#<module name="m_ssl_gnutls.so"> -# -#-#-#-#-#-#-#-#-#-#-#- GNUTLS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# m_ssl_gnutls.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_gnutls # - -<module name="m_sslinfo.so"> - -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-# -# OpenSSL SSL module: Adds support for SSL connections using OpenSSL, -# if enabled. You must answer 'yes' in ./configure when asked or symlink -# the source for this module from the directory src/modules/extra, if -# you want to enable this, or it will not load. -#<module name="m_ssl_openssl.so"> -# -#-#-#-#-#-#-#-#-#-#-#- OPENSSL CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#-# -# # -# m_ssl_openssl.so is too complex to describe here, see the docs: # -# https://docs.inspircd.org/2/modules/ssl_openssl # - -<module name="m_stripcolor.so"> -<module name="m_svshold.so"> -<module name="m_swhois.so"> -<module name="m_tline.so"> -<module name="m_uhnames.so"> -<module name="m_userip.so"> -<module name="m_watch.so"> -<watch maxentries="32"> - -<module name="m_spanningtree.so"> diff --git a/docs/conf/opers.conf.example b/docs/conf/opers.conf.example index 75b54faf0..7cad2589c 100644 --- a/docs/conf/opers.conf.example +++ b/docs/conf/opers.conf.example @@ -1,4 +1,4 @@ -#-#-#-#-#-#-#-#-#-#-#-#- CLASS CONFIGURATION -#-#-#-#-#-#-#-#-#-#-#- +#-#-#-#-#-#-#-#-#-#-#-#-# CLASS CONFIGURATION #-#-#-#-#-#-#-#-#-#-#-# # # # Classes are a group of commands which are grouped together and # # given a unique name. They're used to define which commands # @@ -19,29 +19,40 @@ # privs: Special privileges that users with this class may utilise. # VIEWING: - # - channels/auspex: allows opers with this priv to see more detail about channels than normal users. + # - channels/auspex: allows opers with this priv to see more details about channels than normal users. # - users/auspex: allows opers with this priv to view more details about users than normal users, e.g. real host and IP. - # - servers/auspex: allows opers with this priv to see more detail about server information than normal users. - # ACTIONS: - # - users/mass-message: allows opers with this priv to PRIVMSG and NOTICE to a server mask (e.g. NOTICE $*) - # - channels/high-join-limit: allows opers with this priv to join <channels:opers> total channels instead of <channels:users> total channels. - # PERMISSIONS: - # - users/flood/no-fakelag: prevents opers from being penalized with fake lag for flooding (*NOTE) - # - users/flood/no-throttle: allows opers with this priv to send commands without being throttled (*NOTE) - # - users/flood/increased-buffers: allows opers with this priv to send and receive data without worrying about being disconnected for exceeding limits (*NOTE) + # - users/channel-spy: allows opers with this priv to view the private/secret channels that a user is on. + # - servers/auspex: allows opers with this priv to see more details about server information than normal users. + # ACTIONS: + # - users/mass-message: allows opers with this priv to PRIVMSG and NOTICE to a server mask (e.g. NOTICE $*). + # - users/samode-usermodes: allows opers with this priv to change the user modes of any other user using /SAMODE. + # PERMISSIONS: + # - channels/ignore-noctcp: allows opers with this priv to send a CTCP to a +C channel. + # - channels/ignore-nonicks: allows opers with this priv to change their nick when on a +N channel. + # - channels/restricted-create: allows opers with this priv to create channels if the restrictchans module is loaded. + # - users/flood/increased-buffers: allows opers with this priv to send and receive data without worrying about being disconnected for exceeding limits (*NOTE). + # - users/flood/no-fakelag: prevents opers from being penalized with fake lag for flooding (*NOTE). + # - users/flood/no-throttle: allows opers with this priv to send commands without being throttled (*NOTE). + # - users/ignore-callerid: allows opers with this priv to message people using callerid without being on their callerid list. + # - users/ignore-commonchans: allows opers with this priv to send a message to a +c user without sharing common channels. + # - users/ignore-noctcp: allows opers with this priv to send a CTCP to a +T user. + # - users/ignore-privdeaf: allows opers with this priv to message users with +D set. + # - users/sajoin-others: allows opers with this priv to /SAJOIN users other than themselves. + # - servers/use-disabled-commands: allows opers with this priv to use disabled commands. + # - servers/use-disabled-modes: allows opers with this priv to use disabled modes. # # *NOTE: These privs are potentially dangerous, as they grant users with them the ability to hammer your server's CPU/RAM as much as they want, essentially. - privs="users/auspex channels/auspex servers/auspex users/mass-message channels/high-join-limit users/flood/no-throttle users/flood/increased-buffers" + privs="users/auspex channels/auspex servers/auspex users/mass-message users/flood/no-throttle users/flood/increased-buffers" - # usermodes: Oper-only usermodes that opers with this class can use. + # usermodes: Oper-only user modes that opers with this class can use. usermodes="*" # chanmodes: Oper-only channel modes that opers with this class can use. chanmodes="*"> <class name="SACommands" commands="SAJOIN SAPART SANICK SAQUIT SATOPIC SAKICK SAMODE OJOIN"> -<class name="ServerLink" commands="CONNECT SQUIT RCONNECT RSQUIT MKPASSWD ALLTIME SWHOIS JUMPSERVER LOCKSERV UNLOCKSERV" usermodes="*" chanmodes="*" privs="servers/auspex"> -<class name="BanControl" commands="KILL GLINE KLINE ZLINE QLINE ELINE TLINE RLINE CHECK NICKLOCK NICKUNLOCK SHUN CLONES CBAN CLOSE" usermodes="*" chanmodes="*"> +<class name="ServerLink" commands="CONNECT SQUIT RCONNECT RSQUIT MKPASSWD ALLTIME SWHOIS LOCKSERV UNLOCKSERV" usermodes="*" chanmodes="*" privs="servers/auspex"> +<class name="BanControl" commands="KILL GLINE KLINE ZLINE QLINE ELINE TLINE RLINE CHECK NICKLOCK NICKUNLOCK SHUN CLONES CBAN" usermodes="*" chanmodes="*"> <class name="OperChat" commands="WALLOPS GLOBOPS" usermodes="*" chanmodes="*" privs="users/mass-message"> <class name="HostCloak" commands="SETHOST SETIDENT SETIDLE CHGNAME CHGHOST CHGIDENT" usermodes="*" chanmodes="*" privs="users/auspex"> @@ -54,23 +65,24 @@ # # <type - # name: Name of type. Used in actual server operator accounts below. - # Cannot contain spaces. If you would like a space, use - # the _ character instead and it will translate to a space on whois. + # name: Name of the type. Used in actual server operator accounts below. name="NetAdmin" # classes: Classes (blocks above) that this type belongs to. classes="SACommands OperChat BanControl HostCloak Shutdown ServerLink" - # vhost: Host opers of this type get when they log in (oper up). This is optional. + # vhost: Host that opers of this type get when they log in (oper up). This is optional. vhost="netadmin.omega.example.org" + # maxchans: Maximum number of channels opers of this type can be in at once. + maxchans="60" + # modes: User modes besides +o that are set on an oper of this type # when they oper up. Used for snomasks and other things. - # Requires that m_opermodes.so be loaded. + # Requires the opermodes module to be loaded. modes="+s +cCqQ"> -<type name="GlobalOp" classes="SACommands OperChat BanControl HostCloak ServerLink" vhost="ircop.omega.example.org"> +<type name="GlobalOp" classes="SACommands OperChat BanControl HostCloak ServerLink" vhost="serverop.omega.example.org"> <type name="Helper" classes="HostCloak" vhost="helper.omega.example.org"> @@ -80,9 +92,9 @@ # Remember to only make operators out of trustworthy people. # # # -# Operator account with a plain-text password. +# Operator account with a plaintext password. <oper - # name: Oper login that is used to oper up (/oper name password). + # name: Oper login that is used to oper up (/OPER <username> <password>). # Remember: This is case sensitive. name="Attila" @@ -96,26 +108,26 @@ host="attila@inspircd.org *@2001:db8::/32" # ** ADVANCED ** This option is disabled by default. - # fingerprint: When using the m_sslinfo module, you may specify - # a key fingerprint here. This can be obtained by using the /sslinfo + # fingerprint: When using the sslinfo module, you may specify + # a key fingerprint here. This can be obtained by using the /SSLINFO # command while the module is loaded, and is also noticed on connect. # This enhances security by verifying that the person opering up has # a matching SSL client certificate, which is very difficult to # forge (impossible unless preimage attacks on the hash exist). - # If m_sslinfo isn't loaded, this option will be ignored. + # If the sslinfo module isn't loaded, this option will be ignored. #fingerprint="67cb9dc013248a829bb2171ed11becd4" - # autologin: If an SSL fingerprint for this oper is specified, you can - # have the oper block automatically log in. This moves all security of the - # oper block to the protection of the client certificate, so be sure that - # the private key is well-protected! Requires m_sslinfo. + # autologin: If an SSL certificate fingerprint for this oper is specified, + # you can have the oper block automatically log in. This moves all security + # of the oper block to the protection of the client certificate, so be sure + # that the private key is well-protected! Requires the sslinfo module. #autologin="on" - # sslonly: If on, this oper can only oper up if they're using a SSL connection. + # sslonly: If on, this oper can only oper up if they're using an SSL connection. # Setting this option adds a decent bit of security. Highly recommended # if the oper is on wifi, or specifically, unsecured wifi. Note that it # is redundant to specify this option if you specify a fingerprint. - # This setting only takes effect if m_sslinfo is loaded. + # This setting only takes effect if the sslinfo module is loaded. #sslonly="yes" # vhost: Overrides the vhost in the type block. Class and modes may also @@ -136,22 +148,22 @@ # Operator with a hashed password. It is highly recommended to use hashed passwords. <oper - # name: Oper login that is used to oper up (/oper name password). + # name: Oper login that is used to oper up (/OPER <username> <password>). # Remember: This is case sensitive. name="Adam" - # hash: What hash this password is hashed with. - # Requires the module for selected hash (m_md5.so, m_sha256.so - # or m_ripemd160.so) be loaded and the password hashing module - # (m_password_hash.so) loaded. - # Options here are: "md5", "sha256" and "ripemd160", or one of - # these prefixed with "hmac-", e.g.: "hmac-sha256". - # Create hashed passwords with: /mkpasswd <hash> <password> - hash="hmac-sha256" + # hash: The hash function this password is hashed with. Requires the + # module for the selected function (bcrypt, md5, sha1, or sha256) and + # the password hashing module (password_hash) to be loaded. + # + # You may also use any of the above other than bcrypt prefixed with + # either "hmac-" or "pbkdf2-hmac-" (requires the pbkdf2 module). + # Create hashed passwords with: /MKPASSWD <hashtype> <plaintext>. + hash="bcrypt" # password: A hash of the password (see above option) hashed - # with /mkpasswd <hash> <password>. See m_password_hash in modules.conf - # for more information about password hashing. + # with /MKPASSWD <hashtype> <plaintext>. See the password_hash module + # in modules.conf for more information about password hashing. password="qQmv3LcF$Qh63wzmtUqWp9OXnLwe7yv1GcBwHpq59k2a0UrY8xe0" # host: What hostnames and IPs are allowed to use this operator account. @@ -163,3 +175,7 @@ # type: Which type of operator this person is; see the block # above for the list of types. NOTE: This is case-sensitive as well. type="Helper"> + +# Once you have edited this file you can remove this line. This is just to +# ensure that you don't hastily include the file without reading it. +<die reason="Using opers.conf.example without editing it is a security risk"> diff --git a/docs/conf/quotes.txt.example b/docs/conf/quotes.txt.example index 56a580e33..c07e1379a 100644 --- a/docs/conf/quotes.txt.example +++ b/docs/conf/quotes.txt.example @@ -82,7 +82,7 @@ It just keeps going and going and going and going and goi <BANG> All that I know is that nukes are comming from 127.0.0.1 I know all about the irc and the mirc cops. M re ink n ed d, ple s r fil -Please refrain from feeding the IRC Operators. Thank you. +Please refrain from feeding the server operators. Thank you. I know all about mirc stuff, hmm.. I think this channel is experiencing packet loss.. MacDonalds claims Macintosh stole their next idea of the iMac I can't hold her any longer, captain, she's gonna bl.. sorry, got caught up in the moment diff --git a/docs/conf/rules.txt.example b/docs/conf/rules.txt.example deleted file mode 100644 index 1a4b99a70..000000000 --- a/docs/conf/rules.txt.example +++ /dev/null @@ -1,3 +0,0 @@ -This is the InspIRCd rules file. - -Place any network or server rules here :) diff --git a/docs/conf/services/anope.conf.example b/docs/conf/services/anope.conf.example new file mode 100644 index 000000000..5c8f859ff --- /dev/null +++ b/docs/conf/services/anope.conf.example @@ -0,0 +1,9 @@ +# This file contains aliases and nickname reservations which are used +# by Anope. See https://www.anope.org for more information on Anope. + +# This file inherits from the generic config to avoid repetition. +<include file="examples/services/generic.conf.example"> + +# /GLOBAL <message> +# Sends a global notice. +<alias text="GLOBAL" format="*" replace="SQUERY $requirement :GLOBAL $2-" requires="Global" uline="yes" operonly="yes"> diff --git a/docs/conf/services/atheme.conf.example b/docs/conf/services/atheme.conf.example new file mode 100644 index 000000000..d509522b8 --- /dev/null +++ b/docs/conf/services/atheme.conf.example @@ -0,0 +1,53 @@ +# This file contains aliases and nickname reservations which are used +# by Atheme. See https://atheme.github.io/atheme.html for more +# information on Atheme. + +# This file inherits from the generic config to avoid repetition. +<include file="examples/services/generic.conf.example"> + +# Long hand aliases for services pseudoclients. +<alias text="ALIS" replace="SQUERY $requirement :$2-" requires="ALIS" uline="yes"> +<alias text="CHANFIX" replace="SQUERY $requirement :$2-" requires="ChanFix" uline="yes"> +<alias text="GAMESERV" replace="SQUERY $requirement :$2-" requires="GameServ" uline="yes"> +<alias text="GLOBAL" replace="SQUERY $requirement :$2-" requires="Global" uline="yes" operonly="yes"> +<alias text="GROUPSERV" replace="SQUERY $requirement :$2-" requires="GroupServ" uline="yes"> +<alias text="HELPSERV" replace="SQUERY $requirement :$2-" requires="HelpServ" uline="yes"> +<alias text="INFOSERV" replace="SQUERY $requirement :$2-" requires="InfoServ" uline="yes"> +<alias text="PROXYSCAN" replace="SQUERY $requirement :$2-" requires="Proxyscan" uline="yes" operonly="yes"> +<alias text="RPGSERV" replace="SQUERY $requirement :$2-" requires="RPGServ" uline="yes"> + +# Short hand aliases for services pseudoclients. +<alias text="CF" replace="SQUERY $requirement :$2-" requires="ChanFix" uline="yes"> +<alias text="GL" replace="SQUERY $requirement :$2-" requires="Global" uline="yes" operonly="yes"> +<alias text="GS" replace="SQUERY $requirement :$2-" requires="GroupServ" uline="yes"> +<alias text="IS" replace="SQUERY $requirement :$2-" requires="InfoServ" uline="yes"> +<alias text="LS" replace="SQUERY $requirement :$2-" requires="ALIS" uline="yes"> +<alias text="PS" replace="SQUERY $requirement :$2-" requires="Proxyscan" uline="yes" operonly="yes"> +<alias text="RS" replace="SQUERY $requirement :$2-" requires="RPGServ" uline="yes"> + +# These short hand aliases conflict with other pseudoclients. You can enable +# them but you will need to comment out the uncommented ones above first, +#<alias text="GS" replace="SQUERY $requirement :$2-" requires="GameServ" uline="yes"> +#<alias text="HS" replace="SQUERY $requirement :$2-" requires="HelpServ" uline="yes"> + +# Prevent clients from using the nicknames of services pseudoclients. +<badnick nick="ALIS" reason="Reserved for a network service"> +<badnick nick="ChanFix" reason="Reserved for a network service"> +<badnick nick="GameServ" reason="Reserved for a network service"> +<badnick nick="GroupServ" reason="Reserved for a network service"> +<badnick nick="HelpServ" reason="Reserved for a network service"> +<badnick nick="InfoServ" reason="Reserved for a network service"> +<badnick nick="Proxyscan" reason="Reserved for a network service"> +<badnick nick="RPGServ" reason="Reserved for a network service"> +<badnick nick="SaslServ" reason="Reserved for a network service"> + +# Exempt services pseudoclients from filters. +<exemptfromfilter target="ALIS"> +<exemptfromfilter target="ChanFix"> +<exemptfromfilter target="GameServ"> +<exemptfromfilter target="GroupServ"> +<exemptfromfilter target="HelpServ"> +<exemptfromfilter target="InfoServ"> +<exemptfromfilter target="Proxyscan"> +<exemptfromfilter target="RPGServ"> +<exemptfromfilter target="SaslServ"> diff --git a/docs/conf/services/generic.conf.example b/docs/conf/services/generic.conf.example new file mode 100644 index 000000000..9a45c0639 --- /dev/null +++ b/docs/conf/services/generic.conf.example @@ -0,0 +1,47 @@ +# This file contains aliases and nickname reservations which are used +# by all common services implementations. + +<module name="alias"> + +# Long hand aliases for services pseudoclients. +<alias text="BOTSERV" replace="SQUERY $requirement :$2-" requires="BotServ" uline="yes"> +<alias text="CHANSERV" replace="SQUERY $requirement :$2-" requires="ChanServ" uline="yes"> +<alias text="HOSTSERV" replace="SQUERY $requirement :$2-" requires="HostServ" uline="yes"> +<alias text="MEMOSERV" replace="SQUERY $requirement :$2-" requires="MemoServ" uline="yes"> +<alias text="NICKSERV" replace="SQUERY $requirement :$2-" requires="NickServ" uline="yes"> +<alias text="OPERSERV" replace="SQUERY $requirement :$2-" requires="OperServ" uline="yes" operonly="yes"> +<alias text="STATSERV" replace="SQUERY $requirement :$2-" requires="StatServ" uline="yes"> + +# Short hand aliases for services pseudoclients. +<alias text="BS" replace="SQUERY $requirement :$2-" requires="BotServ" uline="yes"> +<alias text="CS" replace="SQUERY $requirement :$2-" requires="ChanServ" uline="yes"> +<alias text="HS" replace="SQUERY $requirement :$2-" requires="HostServ" uline="yes"> +<alias text="MS" replace="SQUERY $requirement :$2-" requires="MemoServ" uline="yes"> +<alias text="NS" replace="SQUERY $requirement :$2-" requires="NickServ" uline="yes"> +<alias text="OS" replace="SQUERY $requirement :$2-" requires="OperServ" uline="yes" operonly="yes"> +<alias text="SS" replace="SQUERY $requirement :$2-" requires="StatServ" uline="yes"> + +# /ID [account] <password> +# Identifies to a services account. +<alias text="ID" format="*" replace="SQUERY $requirement :IDENTIFY $2-" requires="NickServ" uline="yes"> +<alias text="IDENTIFY" format="*" replace="SQUERY $requirement :IDENTIFY $2-" requires="NickServ" uline="yes"> + +# Prevent clients from using the nicknames of services pseudoclients. +<badnick nick="BotServ" reason="Reserved for a network service"> +<badnick nick="ChanServ" reason="Reserved for a network service"> +<badnick nick="Global" reason="Reserved for a network service"> +<badnick nick="HostServ" reason="Reserved for a network service"> +<badnick nick="MemoServ" reason="Reserved for a network service"> +<badnick nick="NickServ" reason="Reserved for a network service"> +<badnick nick="OperServ" reason="Reserved for a network service"> +<badnick nick="StatServ" reason="Reserved for a network service"> + +# Exempt services pseudoclients from filters. +<exemptfromfilter target="BotServ"> +<exemptfromfilter target="ChanServ"> +<exemptfromfilter target="Global"> +<exemptfromfilter target="HostServ"> +<exemptfromfilter target="MemoServ"> +<exemptfromfilter target="NickServ"> +<exemptfromfilter target="OperServ"> +<exemptfromfilter target="StatServ"> diff --git a/docs/rfc/rfc1035.txt b/docs/rfc/rfc1035.txt deleted file mode 100644 index b1a9bf5a9..000000000 --- a/docs/rfc/rfc1035.txt +++ /dev/null @@ -1,3077 +0,0 @@ -Network Working Group P. Mockapetris -Request for Comments: 1035 ISI - November 1987 -Obsoletes: RFCs 882, 883, 973 - - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION - - -1. STATUS OF THIS MEMO - -This RFC describes the details of the domain system and protocol, and -assumes that the reader is familiar with the concepts discussed in a -companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. - -The domain system is a mixture of functions and data types which are an -official protocol and functions and data types which are still -experimental. Since the domain system is intentionally extensible, new -data types and experimental behavior should always be expected in parts -of the system beyond the official protocol. The official protocol parts -include standard queries, responses and the Internet class RR data -formats (e.g., host addresses). Since the previous RFC set, several -definitions have changed, so some previous definitions are obsolete. - -Experimental or obsolete features are clearly marked in these RFCs, and -such information should be used with caution. - -The reader is especially cautioned not to depend on the values which -appear in examples to be current or complete, since their purpose is -primarily pedagogical. Distribution of this memo is unlimited. - - Table of Contents - - 1. STATUS OF THIS MEMO 1 - 2. INTRODUCTION 3 - 2.1. Overview 3 - 2.2. Common configurations 4 - 2.3. Conventions 7 - 2.3.1. Preferred name syntax 7 - 2.3.2. Data Transmission Order 8 - 2.3.3. Character Case 9 - 2.3.4. Size limits 10 - 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10 - 3.1. Name space definitions 10 - 3.2. RR definitions 11 - 3.2.1. Format 11 - 3.2.2. TYPE values 12 - 3.2.3. QTYPE values 12 - 3.2.4. CLASS values 13 - - - -Mockapetris [Page 1] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 3.2.5. QCLASS values 13 - 3.3. Standard RRs 13 - 3.3.1. CNAME RDATA format 14 - 3.3.2. HINFO RDATA format 14 - 3.3.3. MB RDATA format (EXPERIMENTAL) 14 - 3.3.4. MD RDATA format (Obsolete) 15 - 3.3.5. MF RDATA format (Obsolete) 15 - 3.3.6. MG RDATA format (EXPERIMENTAL) 16 - 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16 - 3.3.8. MR RDATA format (EXPERIMENTAL) 17 - 3.3.9. MX RDATA format 17 - 3.3.10. NULL RDATA format (EXPERIMENTAL) 17 - 3.3.11. NS RDATA format 18 - 3.3.12. PTR RDATA format 18 - 3.3.13. SOA RDATA format 19 - 3.3.14. TXT RDATA format 20 - 3.4. ARPA Internet specific RRs 20 - 3.4.1. A RDATA format 20 - 3.4.2. WKS RDATA format 21 - 3.5. IN-ADDR.ARPA domain 22 - 3.6. Defining new types, classes, and special namespaces 24 - 4. MESSAGES 25 - 4.1. Format 25 - 4.1.1. Header section format 26 - 4.1.2. Question section format 28 - 4.1.3. Resource record format 29 - 4.1.4. Message compression 30 - 4.2. Transport 32 - 4.2.1. UDP usage 32 - 4.2.2. TCP usage 32 - 5. MASTER FILES 33 - 5.1. Format 33 - 5.2. Use of master files to define zones 35 - 5.3. Master file example 36 - 6. NAME SERVER IMPLEMENTATION 37 - 6.1. Architecture 37 - 6.1.1. Control 37 - 6.1.2. Database 37 - 6.1.3. Time 39 - 6.2. Standard query processing 39 - 6.3. Zone refresh and reload processing 39 - 6.4. Inverse queries (Optional) 40 - 6.4.1. The contents of inverse queries and responses 40 - 6.4.2. Inverse query and response example 41 - 6.4.3. Inverse query processing 42 - - - - - - -Mockapetris [Page 2] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 6.5. Completion queries and responses 42 - 7. RESOLVER IMPLEMENTATION 43 - 7.1. Transforming a user request into a query 43 - 7.2. Sending the queries 44 - 7.3. Processing responses 46 - 7.4. Using the cache 47 - 8. MAIL SUPPORT 47 - 8.1. Mail exchange binding 48 - 8.2. Mailbox binding (Experimental) 48 - 9. REFERENCES and BIBLIOGRAPHY 50 - Index 54 - -2. INTRODUCTION - -2.1. Overview - -The goal of domain names is to provide a mechanism for naming resources -in such a way that the names are usable in different hosts, networks, -protocol families, internets, and administrative organizations. - -From the user's point of view, domain names are useful as arguments to a -local agent, called a resolver, which retrieves information associated -with the domain name. Thus a user might ask for the host address or -mail information associated with a particular domain name. To enable -the user to request a particular type of information, an appropriate -query type is passed to the resolver with the domain name. To the user, -the domain tree is a single information space; the resolver is -responsible for hiding the distribution of data among name servers from -the user. - -From the resolver's point of view, the database that makes up the domain -space is distributed among various name servers. Different parts of the -domain space are stored in different name servers, although a particular -data item will be stored redundantly in two or more name servers. The -resolver starts with knowledge of at least one name server. When the -resolver processes a user query it asks a known name server for the -information; in return, the resolver either receives the desired -information or a referral to another name server. Using these -referrals, resolvers learn the identities and contents of other name -servers. Resolvers are responsible for dealing with the distribution of -the domain space and dealing with the effects of name server failure by -consulting redundant databases in other servers. - -Name servers manage two kinds of data. The first kind of data held in -sets called zones; each zone is the complete database for a particular -"pruned" subtree of the domain space. This data is called -authoritative. A name server periodically checks to make sure that its -zones are up to date, and if not, obtains a new copy of updated zones - - - -Mockapetris [Page 3] - -RFC 1035 Domain Implementation and Specification November 1987 - - -from master files stored locally or in another name server. The second -kind of data is cached data which was acquired by a local resolver. -This data may be incomplete, but improves the performance of the -retrieval process when non-local data is repeatedly accessed. Cached -data is eventually discarded by a timeout mechanism. - -This functional structure isolates the problems of user interface, -failure recovery, and distribution in the resolvers and isolates the -database update and refresh problems in the name servers. - -2.2. Common configurations - -A host can participate in the domain name system in a number of ways, -depending on whether the host runs programs that retrieve information -from the domain system, name servers that answer queries from other -hosts, or various combinations of both functions. The simplest, and -perhaps most typical, configuration is shown below: - - Local Host | Foreign - | - +---------+ +----------+ | +--------+ - | | user queries | |queries | | | - | User |-------------->| |---------|->|Foreign | - | Program | | Resolver | | | Name | - | |<--------------| |<--------|--| Server | - | | user responses| |responses| | | - +---------+ +----------+ | +--------+ - | A | - cache additions | | references | - V | | - +----------+ | - | cache | | - +----------+ | - -User programs interact with the domain name space through resolvers; the -format of user queries and user responses is specific to the host and -its operating system. User queries will typically be operating system -calls, and the resolver and its cache will be part of the host operating -system. Less capable hosts may choose to implement the resolver as a -subroutine to be linked in with every program that needs its services. -Resolvers answer user queries with information they acquire via queries -to foreign name servers and the local cache. - -Note that the resolver may have to make several queries to several -different foreign name servers to answer a particular user query, and -hence the resolution of a user query may involve several network -accesses and an arbitrary amount of time. The queries to foreign name -servers and the corresponding responses have a standard format described - - - -Mockapetris [Page 4] - -RFC 1035 Domain Implementation and Specification November 1987 - - -in this memo, and may be datagrams. - -Depending on its capabilities, a name server could be a stand alone -program on a dedicated machine or a process or processes on a large -timeshared host. A simple configuration might be: - - Local Host | Foreign - | - +---------+ | - / /| | - +---------+ | +----------+ | +--------+ - | | | | |responses| | | - | | | | Name |---------|->|Foreign | - | Master |-------------->| Server | | |Resolver| - | files | | | |<--------|--| | - | |/ | | queries | +--------+ - +---------+ +----------+ | - -Here a primary name server acquires information about one or more zones -by reading master files from its local file system, and answers queries -about those zones that arrive from foreign resolvers. - -The DNS requires that all zones be redundantly supported by more than -one name server. Designated secondary servers can acquire zones and -check for updates from the primary server using the zone transfer -protocol of the DNS. This configuration is shown below: - - Local Host | Foreign - | - +---------+ | - / /| | - +---------+ | +----------+ | +--------+ - | | | | |responses| | | - | | | | Name |---------|->|Foreign | - | Master |-------------->| Server | | |Resolver| - | files | | | |<--------|--| | - | |/ | | queries | +--------+ - +---------+ +----------+ | - A |maintenance | +--------+ - | +------------|->| | - | queries | |Foreign | - | | | Name | - +------------------|--| Server | - maintenance responses | +--------+ - -In this configuration, the name server periodically establishes a -virtual circuit to a foreign name server to acquire a copy of a zone or -to check that an existing copy has not changed. The messages sent for - - - -Mockapetris [Page 5] - -RFC 1035 Domain Implementation and Specification November 1987 - - -these maintenance activities follow the same form as queries and -responses, but the message sequences are somewhat different. - -The information flow in a host that supports all aspects of the domain -name system is shown below: - - Local Host | Foreign - | - +---------+ +----------+ | +--------+ - | | user queries | |queries | | | - | User |-------------->| |---------|->|Foreign | - | Program | | Resolver | | | Name | - | |<--------------| |<--------|--| Server | - | | user responses| |responses| | | - +---------+ +----------+ | +--------+ - | A | - cache additions | | references | - V | | - +----------+ | - | Shared | | - | database | | - +----------+ | - A | | - +---------+ refreshes | | references | - / /| | V | - +---------+ | +----------+ | +--------+ - | | | | |responses| | | - | | | | Name |---------|->|Foreign | - | Master |-------------->| Server | | |Resolver| - | files | | | |<--------|--| | - | |/ | | queries | +--------+ - +---------+ +----------+ | - A |maintenance | +--------+ - | +------------|->| | - | queries | |Foreign | - | | | Name | - +------------------|--| Server | - maintenance responses | +--------+ - -The shared database holds domain space data for the local name server -and resolver. The contents of the shared database will typically be a -mixture of authoritative data maintained by the periodic refresh -operations of the name server and cached data from previous resolver -requests. The structure of the domain data and the necessity for -synchronization between name servers and resolvers imply the general -characteristics of this database, but the actual format is up to the -local implementor. - - - - -Mockapetris [Page 6] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Information flow can also be tailored so that a group of hosts act -together to optimize activities. Sometimes this is done to offload less -capable hosts so that they do not have to implement a full resolver. -This can be appropriate for PCs or hosts which want to minimize the -amount of new network code which is required. This scheme can also -allow a group of hosts can share a small number of caches rather than -maintaining a large number of separate caches, on the premise that the -centralized caches will have a higher hit ratio. In either case, -resolvers are replaced with stub resolvers which act as front ends to -resolvers located in a recursive server in one or more name servers -known to perform that service: - - Local Hosts | Foreign - | - +---------+ | - | | responses | - | Stub |<--------------------+ | - | Resolver| | | - | |----------------+ | | - +---------+ recursive | | | - queries | | | - V | | - +---------+ recursive +----------+ | +--------+ - | | queries | |queries | | | - | Stub |-------------->| Recursive|---------|->|Foreign | - | Resolver| | Server | | | Name | - | |<--------------| |<--------|--| Server | - +---------+ responses | |responses| | | - +----------+ | +--------+ - | Central | | - | cache | | - +----------+ | - -In any case, note that domain components are always replicated for -reliability whenever possible. - -2.3. Conventions - -The domain system has several conventions dealing with low-level, but -fundamental, issues. While the implementor is free to violate these -conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in -ALL behavior observed from other hosts. - -2.3.1. Preferred name syntax - -The DNS specifications attempt to be as general as possible in the rules -for constructing domain names. The idea is that the name of any -existing object can be expressed as a domain name with minimal changes. - - - -Mockapetris [Page 7] - -RFC 1035 Domain Implementation and Specification November 1987 - - -However, when assigning a domain name for an object, the prudent user -will select a name which satisfies both the rules of the domain system -and any existing rules for the object, whether these rules are published -or implied by existing programs. - -For example, when naming a mail domain, the user should satisfy both the -rules of this memo and those in RFC-822. When creating a new host name, -the old rules for HOSTS.TXT should be followed. This avoids problems -when old software is converted to use domain names. - -The following syntax will result in fewer problems with many - -applications that use domain names (e.g., mail, TELNET). - -<domain> ::= <subdomain> | " " - -<subdomain> ::= <label> | <subdomain> "." <label> - -<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] - -<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> - -<let-dig-hyp> ::= <let-dig> | "-" - -<let-dig> ::= <letter> | <digit> - -<letter> ::= any one of the 52 alphabetic characters A through Z in -upper case and a through z in lower case - -<digit> ::= any one of the ten digits 0 through 9 - -Note that while upper and lower case letters are allowed in domain -names, no significance is attached to the case. That is, two names with -the same spelling but different case are to be treated as if identical. - -The labels must follow the rules for ARPANET host names. They must -start with a letter, end with a letter or digit, and have as interior -characters only letters, digits, and hyphen. There are also some -restrictions on the length. Labels must be 63 characters or less. - -For example, the following strings identify hosts in the Internet: - -A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA - -2.3.2. Data Transmission Order - -The order of transmission of the header and data described in this -document is resolved to the octet level. Whenever a diagram shows a - - - -Mockapetris [Page 8] - -RFC 1035 Domain Implementation and Specification November 1987 - - -group of octets, the order of transmission of those octets is the normal -order in which they are read in English. For example, in the following -diagram, the octets are transmitted in the order they are numbered. - - 0 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 1 | 2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 3 | 4 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 5 | 6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -Whenever an octet represents a numeric quantity, the left most bit in -the diagram is the high order or most significant bit. That is, the bit -labeled 0 is the most significant bit. For example, the following -diagram represents the value 170 (decimal). - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - |1 0 1 0 1 0 1 0| - +-+-+-+-+-+-+-+-+ - -Similarly, whenever a multi-octet field represents a numeric quantity -the left most bit of the whole field is the most significant bit. When -a multi-octet quantity is transmitted the most significant octet is -transmitted first. - -2.3.3. Character Case - -For all parts of the DNS that are part of the official protocol, all -comparisons between character strings (e.g., labels, domain names, etc.) -are done in a case-insensitive manner. At present, this rule is in -force throughout the domain system without exception. However, future -additions beyond current usage may need to use the full binary octet -capabilities in names, so attempts to store domain names in 7-bit ASCII -or use of special bytes to terminate labels, etc., should be avoided. - -When data enters the domain system, its original case should be -preserved whenever possible. In certain circumstances this cannot be -done. For example, if two RRs are stored in a database, one at x.y and -one at X.Y, they are actually stored at the same place in the database, -and hence only one casing would be preserved. The basic rule is that -case can be discarded only when data is used to define structure in a -database, and two names are identical when compared in a case -insensitive manner. - - - - -Mockapetris [Page 9] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Loss of case sensitive data must be minimized. Thus while data for x.y -and X.Y may both be stored under a single location x.y or X.Y, data for -a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In -general, this preserves the case of the first label of a domain name, -but forces standardization of interior node labels. - -Systems administrators who enter data into the domain database should -take care to represent the data they supply to the domain system in a -case-consistent manner if their system is case-sensitive. The data -distribution system in the domain system will ensure that consistent -representations are preserved. - -2.3.4. Size limits - -Various objects and parameters in the DNS have size limits. They are -listed below. Some could be easily changed, others are more -fundamental. - -labels 63 octets or less - -names 255 octets or less - -TTL positive values of a signed 32 bit number. - -UDP messages 512 octets or less - -3. DOMAIN NAME SPACE AND RR DEFINITIONS - -3.1. Name space definitions - -Domain names in messages are expressed in terms of a sequence of labels. -Each label is represented as a one octet length field followed by that -number of octets. Since every domain name ends with the null label of -the root, a domain name is terminated by a length byte of zero. The -high order two bits of every length octet must be zero, and the -remaining six bits of the length field limit the label to 63 octets or -less. - -To simplify implementations, the total length of a domain name (i.e., -label octets and label length octets) is restricted to 255 octets or -less. - -Although labels can contain any 8 bit values in octets that make up a -label, it is strongly recommended that labels follow the preferred -syntax described elsewhere in this memo, which is compatible with -existing host naming conventions. Name servers and resolvers must -compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII -with zero parity. Non-alphabetic codes must match exactly. - - - -Mockapetris [Page 10] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.2. RR definitions - -3.2.1. Format - -All RRs have the same top level format shown below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - -where: - -NAME an owner name, i.e., the name of the node to which this - resource record pertains. - -TYPE two octets containing one of the RR TYPE codes. - -CLASS two octets containing one of the RR CLASS codes. - -TTL a 32 bit signed integer that specifies the time interval - that the resource record may be cached before the source - of the information should again be consulted. Zero - values are interpreted to mean that the RR can only be - used for the transaction in progress, and should not be - cached. For example, SOA records are always distributed - with a zero TTL to prohibit caching. Zero values can - also be used for extremely volatile data. - -RDLENGTH an unsigned 16 bit integer that specifies the length in - octets of the RDATA field. - - - -Mockapetris [Page 11] - -RFC 1035 Domain Implementation and Specification November 1987 - - -RDATA a variable length string of octets that describes the - resource. The format of this information varies - according to the TYPE and CLASS of the resource record. - -3.2.2. TYPE values - -TYPE fields are used in resource records. Note that these types are a -subset of QTYPEs. - -TYPE value and meaning - -A 1 a host address - -NS 2 an authoritative name server - -MD 3 a mail destination (Obsolete - use MX) - -MF 4 a mail forwarder (Obsolete - use MX) - -CNAME 5 the canonical name for an alias - -SOA 6 marks the start of a zone of authority - -MB 7 a mailbox domain name (EXPERIMENTAL) - -MG 8 a mail group member (EXPERIMENTAL) - -MR 9 a mail rename domain name (EXPERIMENTAL) - -NULL 10 a null RR (EXPERIMENTAL) - -WKS 11 a well known service description - -PTR 12 a domain name pointer - -HINFO 13 host information - -MINFO 14 mailbox or mail list information - -MX 15 mail exchange - -TXT 16 text strings - -3.2.3. QTYPE values - -QTYPE fields appear in the question part of a query. QTYPES are a -superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the -following QTYPEs are defined: - - - -Mockapetris [Page 12] - -RFC 1035 Domain Implementation and Specification November 1987 - - -AXFR 252 A request for a transfer of an entire zone - -MAILB 253 A request for mailbox-related records (MB, MG or MR) - -MAILA 254 A request for mail agent RRs (Obsolete - see MX) - -* 255 A request for all records - -3.2.4. CLASS values - -CLASS fields appear in resource records. The following CLASS mnemonics -and values are defined: - -IN 1 the Internet - -CS 2 the CSNET class (Obsolete - used only for examples in - some obsolete RFCs) - -CH 3 the CHAOS class - -HS 4 Hesiod [Dyer 87] - -3.2.5. QCLASS values - -QCLASS fields appear in the question section of a query. QCLASS values -are a superset of CLASS values; every CLASS is a valid QCLASS. In -addition to CLASS values, the following QCLASSes are defined: - -* 255 any class - -3.3. Standard RRs - -The following RR definitions are expected to occur, at least -potentially, in all classes. In particular, NS, SOA, CNAME, and PTR -will be used in all classes, and have the same format in all classes. -Because their RDATA format is known, all domain names in the RDATA -section of these RRs may be compressed. - -<domain-name> is a domain name represented as a series of labels, and -terminated by a label with zero length. <character-string> is a single -length octet followed by that number of characters. <character-string> -is treated as binary information, and can be up to 256 characters in -length (including the length octet). - - - - - - - - -Mockapetris [Page 13] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.1. CNAME RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / CNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -CNAME A <domain-name> which specifies the canonical or primary - name for the owner. The owner name is an alias. - -CNAME RRs cause no additional section processing, but name servers may -choose to restart the query at the canonical name in certain cases. See -the description of name server logic in [RFC-1034] for details. - -3.3.2. HINFO RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / CPU / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / OS / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -CPU A <character-string> which specifies the CPU type. - -OS A <character-string> which specifies the operating - system type. - -Standard values for CPU and OS can be found in [RFC-1010]. - -HINFO records are used to acquire general information about a host. The -main use is for protocols such as FTP that can use special procedures -when talking between machines or operating systems of the same type. - -3.3.3. MB RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <domain-name> which specifies a host which has the - specified mailbox. - - - -Mockapetris [Page 14] - -RFC 1035 Domain Implementation and Specification November 1987 - - -MB records cause additional section processing which looks up an A type -RRs corresponding to MADNAME. - -3.3.4. MD RDATA format (Obsolete) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <domain-name> which specifies a host which has a mail - agent for the domain which should be able to deliver - mail for the domain. - -MD records cause additional section processing which looks up an A type -record corresponding to MADNAME. - -MD is obsolete. See the definition of MX and [RFC-974] for details of -the new scheme. The recommended policy for dealing with MD RRs found in -a master file is to reject them, or to convert them to MX RRs with a -preference of 0. - -3.3.5. MF RDATA format (Obsolete) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <domain-name> which specifies a host which has a mail - agent for the domain which will accept mail for - forwarding to the domain. - -MF records cause additional section processing which looks up an A type -record corresponding to MADNAME. - -MF is obsolete. See the definition of MX and [RFC-974] for details ofw -the new scheme. The recommended policy for dealing with MD RRs found in -a master file is to reject them, or to convert them to MX RRs with a -preference of 10. - - - - - - - -Mockapetris [Page 15] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.6. MG RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MGMNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MGMNAME A <domain-name> which specifies a mailbox which is a - member of the mail group specified by the domain name. - -MG records cause no additional section processing. - -3.3.7. MINFO RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / RMAILBX / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / EMAILBX / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -RMAILBX A <domain-name> which specifies a mailbox which is - responsible for the mailing list or mailbox. If this - domain name names the root, the owner of the MINFO RR is - responsible for itself. Note that many existing mailing - lists use a mailbox X-request for the RMAILBX field of - mailing list X, e.g., Msgroup-request for Msgroup. This - field provides a more general mechanism. - - -EMAILBX A <domain-name> which specifies a mailbox which is to - receive error messages related to the mailing list or - mailbox specified by the owner of the MINFO RR (similar - to the ERRORS-TO: field which has been proposed). If - this domain name names the root, errors should be - returned to the sender of the message. - -MINFO records cause no additional section processing. Although these -records can be associated with a simple mailbox, they are usually used -with a mailing list. - - - - - - - - -Mockapetris [Page 16] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.8. MR RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / NEWNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -NEWNAME A <domain-name> which specifies a mailbox which is the - proper rename of the specified mailbox. - -MR records cause no additional section processing. The main use for MR -is as a forwarding entry for a user who has moved to a different -mailbox. - -3.3.9. MX RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PREFERENCE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / EXCHANGE / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -PREFERENCE A 16 bit integer which specifies the preference given to - this RR among others at the same owner. Lower values - are preferred. - -EXCHANGE A <domain-name> which specifies a host willing to act as - a mail exchange for the owner name. - -MX records cause type A additional section processing for the host -specified by EXCHANGE. The use of MX RRs is explained in detail in -[RFC-974]. - -3.3.10. NULL RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / <anything> / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -Anything at all may be in the RDATA field so long as it is 65535 octets -or less. - - - - -Mockapetris [Page 17] - -RFC 1035 Domain Implementation and Specification November 1987 - - -NULL records cause no additional section processing. NULL RRs are not -allowed in master files. NULLs are used as placeholders in some -experimental extensions of the DNS. - -3.3.11. NS RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / NSDNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -NSDNAME A <domain-name> which specifies a host which should be - authoritative for the specified class and domain. - -NS records cause both the usual additional section processing to locate -a type A record, and, when used in a referral, a special search of the -zone in which they reside for glue information. - -The NS RR states that the named host should be expected to have a zone -starting at owner name of the specified class. Note that the class may -not indicate the protocol family which should be used to communicate -with the host, although it is typically a strong hint. For example, -hosts which are name servers for either Internet (IN) or Hesiod (HS) -class information are normally queried using IN class protocols. - -3.3.12. PTR RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / PTRDNAME / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -PTRDNAME A <domain-name> which points to some location in the - domain name space. - -PTR records cause no additional section processing. These RRs are used -in special domains to point to some other location in the domain space. -These records are simple data, and don't imply any special processing -similar to that performed by CNAME, which identifies aliases. See the -description of the IN-ADDR.ARPA domain for an example. - - - - - - - - -Mockapetris [Page 18] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.13. SOA RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / RNAME / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | SERIAL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | REFRESH | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RETRY | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | EXPIRE | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | MINIMUM | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MNAME The <domain-name> of the name server that was the - original or primary source of data for this zone. - -RNAME A <domain-name> which specifies the mailbox of the - person responsible for this zone. - -SERIAL The unsigned 32 bit version number of the original copy - of the zone. Zone transfers preserve this value. This - value wraps and should be compared using sequence space - arithmetic. - -REFRESH A 32 bit time interval before the zone should be - refreshed. - -RETRY A 32 bit time interval that should elapse before a - failed refresh should be retried. - -EXPIRE A 32 bit time value that specifies the upper limit on - the time interval that can elapse before the zone is no - longer authoritative. - - - - - -Mockapetris [Page 19] - -RFC 1035 Domain Implementation and Specification November 1987 - - -MINIMUM The unsigned 32 bit minimum TTL field that should be - exported with any RR from this zone. - -SOA records cause no additional section processing. - -All times are in units of seconds. - -Most of these fields are pertinent only for name server maintenance -operations. However, MINIMUM is used in all query operations that -retrieve RRs from a zone. Whenever a RR is sent in a response to a -query, the TTL field is set to the maximum of the TTL field from the RR -and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower -bound on the TTL field for all RRs in a zone. Note that this use of -MINIMUM should occur when the RRs are copied into the response and not -when the zone is loaded from a master file or via a zone transfer. The -reason for this provison is to allow future dynamic update facilities to -change the SOA RR with known semantics. - - -3.3.14. TXT RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / TXT-DATA / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -TXT-DATA One or more <character-string>s. - -TXT RRs are used to hold descriptive text. The semantics of the text -depends on the domain where it is found. - -3.4. Internet specific RRs - -3.4.1. A RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ADDRESS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ADDRESS A 32 bit Internet address. - -Hosts that have multiple Internet addresses will have multiple A -records. - - - - - -Mockapetris [Page 20] - -RFC 1035 Domain Implementation and Specification November 1987 - - -A records cause no additional section processing. The RDATA section of -an A line in a master file is an Internet address expressed as four -decimal numbers separated by dots without any imbedded spaces (e.g., -"10.2.0.52" or "192.0.5.6"). - -3.4.2. WKS RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ADDRESS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PROTOCOL | | - +--+--+--+--+--+--+--+--+ | - | | - / <BIT MAP> / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ADDRESS An 32 bit Internet address - -PROTOCOL An 8 bit IP protocol number - -<BIT MAP> A variable length bit map. The bit map must be a - multiple of 8 bits long. - -The WKS record is used to describe the well known services supported by -a particular protocol on a particular internet address. The PROTOCOL -field specifies an IP protocol number, and the bit map has one bit per -port of the specified protocol. The first bit corresponds to port 0, -the second to port 1, etc. If the bit map does not include a bit for a -protocol of interest, that bit is assumed zero. The appropriate values -and mnemonics for ports and protocols are specified in [RFC-1010]. - -For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port -25 (SMTP). If this bit is set, a SMTP server should be listening on TCP -port 25; if zero, SMTP service is not supported on the specified -address. - -The purpose of WKS RRs is to provide availability information for -servers for TCP and UDP. If a server supports both TCP and UDP, or has -multiple Internet addresses, then multiple WKS RRs are used. - -WKS RRs cause no additional section processing. - -In master files, both ports and protocols are expressed using mnemonics -or decimal numbers. - - - - -Mockapetris [Page 21] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.5. IN-ADDR.ARPA domain - -The Internet uses a special domain to support gateway location and -Internet address to host mapping. Other classes may employ a similar -strategy in other domains. The intent of this domain is to provide a -guaranteed method to perform host address to host name mapping, and to -facilitate queries to locate all gateways on a particular network in the -Internet. - -Note that both of these services are similar to functions that could be -performed by inverse queries; the difference is that this part of the -domain name space is structured according to address, and hence can -guarantee that the appropriate data can be located without an exhaustive -search of the domain space. - -The domain begins at IN-ADDR.ARPA and has a substructure which follows -the Internet addressing structure. - -Domain names in the IN-ADDR.ARPA domain are defined to have up to four -labels in addition to the IN-ADDR.ARPA suffix. Each label represents -one octet of an Internet address, and is expressed as a character string -for a decimal value in the range 0-255 (with leading zeros omitted -except in the case of a zero octet which is represented by a single -zero). - -Host addresses are represented by domain names that have all four labels -specified. Thus data for Internet address 10.2.0.52 is located at -domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to -read, allows zones to be delegated which are exactly one network of -address space. For example, 10.IN-ADDR.ARPA can be a zone containing -data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for -MILNET. Address nodes are used to hold pointers to primary host names -in the normal domain space. - -Network numbers correspond to some non-terminal nodes at various depths -in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, -2, or 3 octets. Network nodes are used to hold pointers to the primary -host names of gateways attached to that network. Since a gateway is, by -definition, on more than one network, it will typically have two or more -network nodes which point at it. Gateways will also have host level -pointers at their fully qualified addresses. - -Both the gateway pointers at network nodes and the normal host pointers -at full address nodes use the PTR RR to point back to the primary domain -names of the corresponding hosts. - -For example, the IN-ADDR.ARPA domain will contain information about the -ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's - - - -Mockapetris [Page 22] - -RFC 1035 Domain Implementation and Specification November 1987 - - -net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI -gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET- -GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 -and a name GW.LCS.MIT.EDU, the domain database would contain: - - 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. - 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. - -Thus a program which wanted to locate gateways on net 10 would originate -a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It -would receive two RRs in response: - - 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - -The program could then originate QTYPE=A, QCLASS=IN queries for MILNET- -GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of -these gateways. - -A resolver which wanted to find the host name corresponding to Internet -host address 10.0.0.6 would pursue a query of the form QTYPE=PTR, -QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive: - - 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. - -Several cautions apply to the use of these services: - - Since the IN-ADDR.ARPA special domain and the normal domain - for a particular host or gateway will be in different zones, - the possibility exists that that the data may be inconsistent. - - - Gateways will often have two names in separate domains, only - one of which can be primary. - - - Systems that use the domain database to initialize their - routing tables must start with enough gateway information to - guarantee that they can access the appropriate name server. - - - The gateway data only reflects the existence of a gateway in a - manner equivalent to the current HOSTS.TXT file. It doesn't - replace the dynamic availability information from GGP or EGP. - - - -Mockapetris [Page 23] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.6. Defining new types, classes, and special namespaces - -The previously defined types and classes are the ones in use as of the -date of this memo. New definitions should be expected. This section -makes some recommendations to designers considering additions to the -existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the -forum where general discussion of design issues takes place. - -In general, a new type is appropriate when new information is to be -added to the database about an existing object, or we need new data -formats for some totally new object. Designers should attempt to define -types and their RDATA formats that are generally applicable to all -classes, and which avoid duplication of information. New classes are -appropriate when the DNS is to be used for a new protocol, etc which -requires new class-specific data formats, or when a copy of the existing -name space is desired, but a separate management domain is necessary. - -New types and classes need mnemonics for master files; the format of the -master files requires that the mnemonics for type and class be disjoint. - -TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes -respectively. - -The present system uses multiple RRs to represent multiple values of a -type rather than storing multiple values in the RDATA section of a -single RR. This is less efficient for most applications, but does keep -RRs shorter. The multiple RRs assumption is incorporated in some -experimental work on dynamic update methods. - -The present system attempts to minimize the duplication of data in the -database in order to insure consistency. Thus, in order to find the -address of the host for a mail exchange, you map the mail domain name to -a host name, then the host name to addresses, rather than a direct -mapping to host address. This approach is preferred because it avoids -the opportunity for inconsistency. - -In defining a new type of data, multiple RR types should not be used to -create an ordering between entries or express different formats for -equivalent bindings, instead this information should be carried in the -body of the RR and a single type used. This policy avoids problems with -caching multiple types and defining QTYPEs to match multiple types. - -For example, the original form of mail exchange binding used two RR -types one to represent a "closer" exchange (MD) and one to represent a -"less close" exchange (MF). The difficulty is that the presence of one -RR type in a cache doesn't convey any information about the other -because the query which acquired the cached information might have used -a QTYPE of MF, MD, or MAILA (which matched both). The redesigned - - - -Mockapetris [Page 24] - -RFC 1035 Domain Implementation and Specification November 1987 - - -service used a single type (MX) with a "preference" value in the RDATA -section which can order different RRs. However, if any MX RRs are found -in the cache, then all should be there. - -4. MESSAGES - -4.1. Format - -All communications inside of the domain protocol are carried in a single -format called a message. The top level format of message is divided -into 5 sections (some of which are empty in certain cases) shown below: - - +---------------------+ - | Header | - +---------------------+ - | Question | the question for the name server - +---------------------+ - | Answer | RRs answering the question - +---------------------+ - | Authority | RRs pointing toward an authority - +---------------------+ - | Additional | RRs holding additional information - +---------------------+ - -The header section is always present. The header includes fields that -specify which of the remaining sections are present, and also specify -whether the message is a query or a response, a standard query or some -other opcode, etc. - -The names of the sections after the header are derived from their use in -standard queries. The question section contains fields that describe a -question to a name server. These fields are a query type (QTYPE), a -query class (QCLASS), and a query domain name (QNAME). The last three -sections have the same format: a possibly empty list of concatenated -resource records (RRs). The answer section contains RRs that answer the -question; the authority section contains RRs that point toward an -authoritative name server; the additional records section contains RRs -which relate to the query, but are not strictly answers for the -question. - - - - - - - - - - - - -Mockapetris [Page 25] - -RFC 1035 Domain Implementation and Specification November 1987 - - -4.1.1. Header section format - -The header contains the following fields: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode |AA|TC|RD|RA| Z | RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ID A 16 bit identifier assigned by the program that - generates any kind of query. This identifier is copied - the corresponding reply and can be used by the requester - to match up replies to outstanding queries. - -QR A one bit field that specifies whether this message is a - query (0), or a response (1). - -OPCODE A four bit field that specifies kind of query in this - message. This value is set by the originator of a query - and copied into the response. The values are: - - 0 a standard query (QUERY) - - 1 an inverse query (IQUERY) - - 2 a server status request (STATUS) - - 3-15 reserved for future use - -AA Authoritative Answer - this bit is valid in responses, - and specifies that the responding name server is an - authority for the domain name in question section. - - Note that the contents of the answer section may have - multiple owner names because of aliases. The AA bit - - - -Mockapetris [Page 26] - -RFC 1035 Domain Implementation and Specification November 1987 - - - corresponds to the name which matches the query name, or - the first owner name in the answer section. - -TC TrunCation - specifies that this message was truncated - due to length greater than that permitted on the - transmission channel. - -RD Recursion Desired - this bit may be set in a query and - is copied into the response. If RD is set, it directs - the name server to pursue the query recursively. - Recursive query support is optional. - -RA Recursion Available - this be is set or cleared in a - response, and denotes whether recursive query support is - available in the name server. - -Z Reserved for future use. Must be zero in all queries - and responses. - -RCODE Response code - this 4 bit field is set as part of - responses. The values have the following - interpretation: - - 0 No error condition - - 1 Format error - The name server was - unable to interpret the query. - - 2 Server failure - The name server was - unable to process this query due to a - problem with the name server. - - 3 Name Error - Meaningful only for - responses from an authoritative name - server, this code signifies that the - domain name referenced in the query does - not exist. - - 4 Not Implemented - The name server does - not support the requested kind of query. - - 5 Refused - The name server refuses to - perform the specified operation for - policy reasons. For example, a name - server may not wish to provide the - information to the particular requester, - or a name server may not wish to perform - a particular operation (e.g., zone - - - -Mockapetris [Page 27] - -RFC 1035 Domain Implementation and Specification November 1987 - - - transfer) for particular data. - - 6-15 Reserved for future use. - -QDCOUNT an unsigned 16 bit integer specifying the number of - entries in the question section. - -ANCOUNT an unsigned 16 bit integer specifying the number of - resource records in the answer section. - -NSCOUNT an unsigned 16 bit integer specifying the number of name - server resource records in the authority records - section. - -ARCOUNT an unsigned 16 bit integer specifying the number of - resource records in the additional records section. - -4.1.2. Question section format - -The question section is used to carry the "question" in most queries, -i.e., the parameters that define what is being asked. The section -contains QDCOUNT (usually 1) entries, each of the following format: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / QNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QTYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QCLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -QNAME a domain name represented as a sequence of labels, where - each label consists of a length octet followed by that - number of octets. The domain name terminates with the - zero length octet for the null label of the root. Note - that this field may be an odd number of octets; no - padding is used. - -QTYPE a two octet code which specifies the type of the query. - The values for this field include all codes valid for a - TYPE field, together with some more general codes which - can match more than one type of RR. - - - -Mockapetris [Page 28] - -RFC 1035 Domain Implementation and Specification November 1987 - - -QCLASS a two octet code that specifies the class of the query. - For example, the QCLASS field is IN for the Internet. - -4.1.3. Resource record format - -The answer, authority, and additional sections all share the same -format: a variable number of resource records, where the number of -records is specified in the corresponding count field in the header. -Each resource record has the following format: - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -NAME a domain name to which this resource record pertains. - -TYPE two octets containing one of the RR type codes. This - field specifies the meaning of the data in the RDATA - field. - -CLASS two octets which specify the class of the data in the - RDATA field. - -TTL a 32 bit unsigned integer that specifies the time - interval (in seconds) that the resource record may be - cached before it should be discarded. Zero values are - interpreted to mean that the RR can only be used for the - transaction in progress, and should not be cached. - - - - - -Mockapetris [Page 29] - -RFC 1035 Domain Implementation and Specification November 1987 - - -RDLENGTH an unsigned 16 bit integer that specifies the length in - octets of the RDATA field. - -RDATA a variable length string of octets that describes the - resource. The format of this information varies - according to the TYPE and CLASS of the resource record. - For example, the if the TYPE is A and the CLASS is IN, - the RDATA field is a 4 octet ARPA Internet address. - -4.1.4. Message compression - -In order to reduce the size of messages, the domain system utilizes a -compression scheme which eliminates the repetition of domain names in a -message. In this scheme, an entire domain name or a list of labels at -the end of a domain name is replaced with a pointer to a prior occurance -of the same name. - -The pointer takes the form of a two octet sequence: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 1| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -The first two bits are ones. This allows a pointer to be distinguished -from a label, since the label must begin with two zero bits because -labels are restricted to 63 octets or less. (The 10 and 01 combinations -are reserved for future use.) The OFFSET field specifies an offset from -the start of the message (i.e., the first octet of the ID field in the -domain header). A zero offset specifies the first byte of the ID field, -etc. - -The compression scheme allows a domain name in a message to be -represented as either: - - - a sequence of labels ending in a zero octet - - - a pointer - - - a sequence of labels ending with a pointer - -Pointers can only be used for occurances of a domain name where the -format is not class specific. If this were not the case, a name server -or resolver would be required to know the format of all RRs it handled. -As yet, there are no such cases, but they may occur in future RDATA -formats. - -If a domain name is contained in a part of the message subject to a -length field (such as the RDATA section of an RR), and compression is - - - -Mockapetris [Page 30] - -RFC 1035 Domain Implementation and Specification November 1987 - - -used, the length of the compressed name is used in the length -calculation, rather than the length of the expanded name. - -Programs are free to avoid using pointers in messages they generate, -although this will reduce datagram capacity, and may cause truncation. -However all programs are required to understand arriving messages that -contain pointers. - -For example, a datagram might need to use the domain names F.ISI.ARPA, -FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the -message, these domain names might be represented as: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 20 | 1 | F | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 22 | 3 | I | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 24 | S | I | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 26 | 4 | A | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 28 | R | P | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 30 | A | 0 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 40 | 3 | F | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 42 | O | O | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 44 | 1 1| 20 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 64 | 1 1| 26 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 92 | 0 | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -The domain name for F.ISI.ARPA is shown at offset 20. The domain name -FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to -concatenate a label for FOO to the previously defined F.ISI.ARPA. The -domain name ARPA is defined at offset 64 using a pointer to the ARPA -component of the name F.ISI.ARPA at 20; note that this pointer relies on -ARPA being the last label in the string at 20. The root domain name is - - - -Mockapetris [Page 31] - -RFC 1035 Domain Implementation and Specification November 1987 - - -defined by a single octet of zeros at 92; the root domain name has no -labels. - -4.2. Transport - -The DNS assumes that messages will be transmitted as datagrams or in a -byte stream carried by a virtual circuit. While virtual circuits can be -used for any DNS activity, datagrams are preferred for queries due to -their lower overhead and better performance. Zone refresh activities -must use virtual circuits because of the need for reliable transfer. - -The Internet supports name server access using TCP [RFC-793] on server -port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP -port 53 (decimal). - -4.2.1. UDP usage - -Messages sent using UDP user server port 53 (decimal). - -Messages carried by UDP are restricted to 512 bytes (not counting the IP -or UDP headers). Longer messages are truncated and the TC bit is set in -the header. - -UDP is not acceptable for zone transfers, but is the recommended method -for standard queries in the Internet. Queries sent using UDP may be -lost, and hence a retransmission strategy is required. Queries or their -responses may be reordered by the network, or by processing in name -servers, so resolvers should not depend on them being returned in order. - -The optimal UDP retransmission policy will vary with performance of the -Internet and the needs of the client, but the following are recommended: - - - The client should try other servers and server addresses - before repeating a query to a specific address of a server. - - - The retransmission interval should be based on prior - statistics if possible. Too aggressive retransmission can - easily slow responses for the community at large. Depending - on how well connected the client is to its expected servers, - the minimum retransmission interval should be 2-5 seconds. - -More suggestions on server selection and retransmission policy can be -found in the resolver section of this memo. - -4.2.2. TCP usage - -Messages sent over TCP connections use server port 53 (decimal). The -message is prefixed with a two byte length field which gives the message - - - -Mockapetris [Page 32] - -RFC 1035 Domain Implementation and Specification November 1987 - - -length, excluding the two byte length field. This length field allows -the low-level processing to assemble a complete message before beginning -to parse it. - -Several connection management policies are recommended: - - - The server should not block other activities waiting for TCP - data. - - - The server should support multiple connections. - - - The server should assume that the client will initiate - connection closing, and should delay closing its end of the - connection until all outstanding client requests have been - satisfied. - - - If the server needs to close a dormant connection to reclaim - resources, it should wait until the connection has been idle - for a period on the order of two minutes. In particular, the - server should allow the SOA and AXFR request sequence (which - begins a refresh operation) to be made on a single connection. - Since the server would be unable to answer queries anyway, a - unilateral close or reset may be used instead of a graceful - close. - -5. MASTER FILES - -Master files are text files that contain RRs in text form. Since the -contents of a zone can be expressed in the form of a list of RRs a -master file is most often used to define a zone, though it can be used -to list a cache's contents. Hence, this section first discusses the -format of RRs in a master file, and then the special considerations when -a master file is used to create a zone in some name server. - -5.1. Format - -The format of these files is a sequence of entries. Entries are -predominantly line-oriented, though parentheses can be used to continue -a list of items across a line boundary, and text literals can contain -CRLF within the text. Any combination of tabs and spaces act as a -delimiter between the separate items that make up an entry. The end of -any line in the master file can end with a comment. The comment starts -with a ";" (semicolon). - -The following entries are defined: - - <blank>[<comment>] - - - - -Mockapetris [Page 33] - -RFC 1035 Domain Implementation and Specification November 1987 - - - $ORIGIN <domain-name> [<comment>] - - $INCLUDE <file-name> [<domain-name>] [<comment>] - - <domain-name><rr> [<comment>] - - <blank><rr> [<comment>] - -Blank lines, with or without comments, are allowed anywhere in the file. - -Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is -followed by a domain name, and resets the current origin for relative -domain names to the stated name. $INCLUDE inserts the named file into -the current file, and may optionally specify a domain name that sets the -relative domain name origin for the included file. $INCLUDE may also -have a comment. Note that a $INCLUDE entry never changes the relative -origin of the parent file, regardless of changes to the relative origin -made within the included file. - -The last two forms represent RRs. If an entry for an RR begins with a -blank, then the RR is assumed to be owned by the last stated owner. If -an RR entry begins with a <domain-name>, then the owner name is reset. - -<rr> contents take one of the following forms: - - [<TTL>] [<class>] <type> <RDATA> - - [<class>] [<TTL>] <type> <RDATA> - -The RR begins with optional TTL and class fields, followed by a type and -RDATA field appropriate to the type and class. Class and type use the -standard mnemonics, TTL is a decimal integer. Omitted class and TTL -values are default to the last explicitly stated values. Since type and -class mnemonics are disjoint, the parse is unique. (Note that this -order is different from the order used in examples and the order used in -the actual RRs; the given order allows easier parsing and defaulting.) - -<domain-name>s make up a large share of the data in the master file. -The labels in the domain name are expressed as character strings and -separated by dots. Quoting conventions allow arbitrary characters to be -stored in domain names. Domain names that end in a dot are called -absolute, and are taken as complete. Domain names which do not end in a -dot are called relative; the actual domain name is the concatenation of -the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as -an argument to the master file loading routine. A relative name is an -error when no origin is available. - - - - - -Mockapetris [Page 34] - -RFC 1035 Domain Implementation and Specification November 1987 - - -<character-string> is expressed in one or two ways: as a contiguous set -of characters without interior spaces, or as a string beginning with a " -and ending with a ". Inside a " delimited string any character can -occur, except for a " itself, which must be quoted using \ (back slash). - -Because these files are text files several special encodings are -necessary to allow arbitrary data to be loaded. In particular: - - of the root. - -@ A free standing @ is used to denote the current origin. - -\X where X is any character other than a digit (0-9), is - used to quote that character so that its special meaning - does not apply. For example, "\." can be used to place - a dot character in a label. - -\DDD where each D is a digit is the octet corresponding to - the decimal number described by DDD. The resulting - octet is assumed to be text and is not checked for - special meaning. - -( ) Parentheses are used to group data that crosses a line - boundary. In effect, line terminations are not - recognized within parentheses. - -; Semicolon is used to start a comment; the remainder of - the line is ignored. - -5.2. Use of master files to define zones - -When a master file is used to load a zone, the operation should be -suppressed if any errors are encountered in the master file. The -rationale for this is that a single error can have widespread -consequences. For example, suppose that the RRs defining a delegation -have syntax errors; then the server will return authoritative name -errors for all names in the subzone (except in the case where the -subzone is also present on the server). - -Several other validity checks that should be performed in addition to -insuring that the file is syntactically correct: - - 1. All RRs in the file should have the same class. - - 2. Exactly one SOA RR should be present at the top of the zone. - - 3. If delegations are present and glue information is required, - it should be present. - - - -Mockapetris [Page 35] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 4. Information present outside of the authoritative nodes in the - zone should be glue information, rather than the result of an - origin or similar error. - -5.3. Master file example - -The following is an example file which might be used to define the -ISI.EDU zone.and is loaded with an origin of ISI.EDU: - -@ IN SOA VENERA Action\.domains ( - 20 ; SERIAL - 7200 ; REFRESH - 600 ; RETRY - 3600000; EXPIRE - 60) ; MINIMUM - - NS A.ISI.EDU. - NS VENERA - NS VAXA - MX 10 VENERA - MX 20 VAXA - -A A 26.3.0.103 - -VENERA A 10.1.0.52 - A 128.9.0.32 - -VAXA A 10.2.0.27 - A 128.9.0.33 - - -$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT - -Where the file <SUBSYS>ISI-MAILBOXES.TXT is: - - MOE MB A.ISI.EDU. - LARRY MB A.ISI.EDU. - CURLEY MB A.ISI.EDU. - STOOGES MG MOE - MG LARRY - MG CURLEY - -Note the use of the \ character in the SOA RR to specify the responsible -person mailbox "Action.domains@E.ISI.EDU". - - - - - - - -Mockapetris [Page 36] - -RFC 1035 Domain Implementation and Specification November 1987 - - -6. NAME SERVER IMPLEMENTATION - -6.1. Architecture - -The optimal structure for the name server will depend on the host -operating system and whether the name server is integrated with resolver -operations, either by supporting recursive service, or by sharing its -database with a resolver. This section discusses implementation -considerations for a name server which shares a database with a -resolver, but most of these concerns are present in any name server. - -6.1.1. Control - -A name server must employ multiple concurrent activities, whether they -are implemented as separate tasks in the host's OS or multiplexing -inside a single name server program. It is simply not acceptable for a -name server to block the service of UDP requests while it waits for TCP -data for refreshing or query activities. Similarly, a name server -should not attempt to provide recursive service without processing such -requests in parallel, though it may choose to serialize requests from a -single client, or to regard identical requests from the same client as -duplicates. A name server should not substantially delay requests while -it reloads a zone from master files or while it incorporates a newly -refreshed zone into its database. - -6.1.2. Database - -While name server implementations are free to use any internal data -structures they choose, the suggested structure consists of three major -parts: - - - A "catalog" data structure which lists the zones available to - this server, and a "pointer" to the zone data structure. The - main purpose of this structure is to find the nearest ancestor - zone, if any, for arriving standard queries. - - - Separate data structures for each of the zones held by the - name server. - - - A data structure for cached data. (or perhaps separate caches - for different classes) - -All of these data structures can be implemented an identical tree -structure format, with different data chained off the nodes in different -parts: in the catalog the data is pointers to zones, while in the zone -and cache data structures, the data will be RRs. In designing the tree -framework the designer should recognize that query processing will need -to traverse the tree using case-insensitive label comparisons; and that - - - -Mockapetris [Page 37] - -RFC 1035 Domain Implementation and Specification November 1987 - - -in real data, a few nodes have a very high branching factor (100-1000 or -more), but the vast majority have a very low branching factor (0-1). - -One way to solve the case problem is to store the labels for each node -in two pieces: a standardized-case representation of the label where all -ASCII characters are in a single case, together with a bit mask that -denotes which characters are actually of a different case. The -branching factor diversity can be handled using a simple linked list for -a node until the branching factor exceeds some threshold, and -transitioning to a hash structure after the threshold is exceeded. In -any case, hash structures used to store tree sections must insure that -hash functions and procedures preserve the casing conventions of the -DNS. - -The use of separate structures for the different parts of the database -is motivated by several factors: - - - The catalog structure can be an almost static structure that - need change only when the system administrator changes the - zones supported by the server. This structure can also be - used to store parameters used to control refreshing - activities. - - - The individual data structures for zones allow a zone to be - replaced simply by changing a pointer in the catalog. Zone - refresh operations can build a new structure and, when - complete, splice it into the database via a simple pointer - replacement. It is very important that when a zone is - refreshed, queries should not use old and new data - simultaneously. - - - With the proper search procedures, authoritative data in zones - will always "hide", and hence take precedence over, cached - data. - - - Errors in zone definitions that cause overlapping zones, etc., - may cause erroneous responses to queries, but problem - determination is simplified, and the contents of one "bad" - zone can't corrupt another. - - - Since the cache is most frequently updated, it is most - vulnerable to corruption during system restarts. It can also - become full of expired RR data. In either case, it can easily - be discarded without disturbing zone data. - -A major aspect of database design is selecting a structure which allows -the name server to deal with crashes of the name server's host. State -information which a name server should save across system crashes - - - -Mockapetris [Page 38] - -RFC 1035 Domain Implementation and Specification November 1987 - - -includes the catalog structure (including the state of refreshing for -each zone) and the zone data itself. - -6.1.3. Time - -Both the TTL data for RRs and the timing data for refreshing activities -depends on 32 bit timers in units of seconds. Inside the database, -refresh timers and TTLs for cached data conceptually "count down", while -data in the zone stays with constant TTLs. - -A recommended implementation strategy is to store time in two ways: as -a relative increment and as an absolute time. One way to do this is to -use positive 32 bit numbers for one type and negative numbers for the -other. The RRs in zones use relative times; the refresh timers and -cache data use absolute times. Absolute numbers are taken with respect -to some known origin and converted to relative values when placed in the -response to a query. When an absolute TTL is negative after conversion -to relative, then the data is expired and should be ignored. - -6.2. Standard query processing - -The major algorithm for standard query processing is presented in -[RFC-1034]. - -When processing queries with QCLASS=*, or some other QCLASS which -matches multiple classes, the response should never be authoritative -unless the server can guarantee that the response covers all classes. - -When composing a response, RRs which are to be inserted in the -additional section, but duplicate RRs in the answer or authority -sections, may be omitted from the additional section. - -When a response is so long that truncation is required, the truncation -should start at the end of the response and work forward in the -datagram. Thus if there is any data for the authority section, the -answer section is guaranteed to be unique. - -The MINIMUM value in the SOA should be used to set a floor on the TTL of -data distributed from a zone. This floor function should be done when -the data is copied into a response. This will allow future dynamic -update protocols to change the SOA MINIMUM field without ambiguous -semantics. - -6.3. Zone refresh and reload processing - -In spite of a server's best efforts, it may be unable to load zone data -from a master file due to syntax errors, etc., or be unable to refresh a -zone within the its expiration parameter. In this case, the name server - - - -Mockapetris [Page 39] - -RFC 1035 Domain Implementation and Specification November 1987 - - -should answer queries as if it were not supposed to possess the zone. - -If a master is sending a zone out via AXFR, and a new version is created -during the transfer, the master should continue to send the old version -if possible. In any case, it should never send part of one version and -part of another. If completion is not possible, the master should reset -the connection on which the zone transfer is taking place. - -6.4. Inverse queries (Optional) - -Inverse queries are an optional part of the DNS. Name servers are not -required to support any form of inverse queries. If a name server -receives an inverse query that it does not support, it returns an error -response with the "Not Implemented" error set in the header. While -inverse query support is optional, all name servers must be at least -able to return the error response. - -6.4.1. The contents of inverse queries and responses Inverse -queries reverse the mappings performed by standard query operations; -while a standard query maps a domain name to a resource, an inverse -query maps a resource to a domain name. For example, a standard query -might bind a domain name to a host address; the corresponding inverse -query binds the host address to a domain name. - -Inverse queries take the form of a single RR in the answer section of -the message, with an empty question section. The owner name of the -query RR and its TTL are not significant. The response carries -questions in the question section which identify all names possessing -the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows -about all of the domain name space, the response can never be assumed to -be complete. Thus inverse queries are primarily useful for database -management and debugging activities. Inverse queries are NOT an -acceptable method of mapping host addresses to host names; use the IN- -ADDR.ARPA domain instead. - -Where possible, name servers should provide case-insensitive comparisons -for inverse queries. Thus an inverse query asking for an MX RR of -"Venera.isi.edu" should get the same response as a query for -"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should -produce the same result as an inverse query for "IBM-pc unix". However, -this cannot be guaranteed because name servers may possess RRs that -contain character strings but the name server does not know that the -data is character. - -When a name server processes an inverse query, it either returns: - - 1. zero, one, or multiple domain names for the specified - resource as QNAMEs in the question section - - - -Mockapetris [Page 40] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 2. an error code indicating that the name server doesn't support - inverse mapping of the specified resource type. - -When the response to an inverse query contains one or more QNAMEs, the -owner name and TTL of the RR in the answer section which defines the -inverse query is modified to exactly match an RR found at the first -QNAME. - -RRs returned in the inverse queries cannot be cached using the same -mechanism as is used for the replies to standard queries. One reason -for this is that a name might have multiple RRs of the same type, and -only one would appear. For example, an inverse query for a single -address of a multiply homed host might create the impression that only -one address existed. - -6.4.2. Inverse query and response example The overall structure -of an inverse query for retrieving the domain name that corresponds to -Internet address 10.1.0.52 is shown below: - - +-----------------------------------------+ - Header | OPCODE=IQUERY, ID=997 | - +-----------------------------------------+ - Question | <empty> | - +-----------------------------------------+ - Answer | <anyname> A IN 10.1.0.52 | - +-----------------------------------------+ - Authority | <empty> | - +-----------------------------------------+ - Additional | <empty> | - +-----------------------------------------+ - -This query asks for a question whose answer is the Internet style -address 10.1.0.52. Since the owner name is not known, any domain name -can be used as a placeholder (and is ignored). A single octet of zero, -signifying the root, is usually used because it minimizes the length of -the message. The TTL of the RR is not significant. The response to -this query might be: - - - - - - - - - - - - - - -Mockapetris [Page 41] - -RFC 1035 Domain Implementation and Specification November 1987 - - - +-----------------------------------------+ - Header | OPCODE=RESPONSE, ID=997 | - +-----------------------------------------+ - Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU | - +-----------------------------------------+ - Answer | VENERA.ISI.EDU A IN 10.1.0.52 | - +-----------------------------------------+ - Authority | <empty> | - +-----------------------------------------+ - Additional | <empty> | - +-----------------------------------------+ - -Note that the QTYPE in a response to an inverse query is the same as the -TYPE field in the answer section of the inverse query. Responses to -inverse queries may contain multiple questions when the inverse is not -unique. If the question section in the response is not empty, then the -RR in the answer section is modified to correspond to be an exact copy -of an RR at the first QNAME. - -6.4.3. Inverse query processing - -Name servers that support inverse queries can support these operations -through exhaustive searches of their databases, but this becomes -impractical as the size of the database increases. An alternative -approach is to invert the database according to the search key. - -For name servers that support multiple zones and a large amount of data, -the recommended approach is separate inversions for each zone. When a -particular zone is changed during a refresh, only its inversions need to -be redone. - -Support for transfer of this type of inversion may be included in future -versions of the domain system, but is not supported in this version. - -6.5. Completion queries and responses - -The optional completion services described in RFC-882 and RFC-883 have -been deleted. Redesigned services may become available in the future. - - - - - - - - - - - - - -Mockapetris [Page 42] - -RFC 1035 Domain Implementation and Specification November 1987 - - -7. RESOLVER IMPLEMENTATION - -The top levels of the recommended resolver algorithm are discussed in -[RFC-1034]. This section discusses implementation details assuming the -database structure suggested in the name server implementation section -of this memo. - -7.1. Transforming a user request into a query - -The first step a resolver takes is to transform the client's request, -stated in a format suitable to the local OS, into a search specification -for RRs at a specific name which match a specific QTYPE and QCLASS. -Where possible, the QTYPE and QCLASS should correspond to a single type -and a single class, because this makes the use of cached data much -simpler. The reason for this is that the presence of data of one type -in a cache doesn't confirm the existence or non-existence of data of -other types, hence the only way to be sure is to consult an -authoritative source. If QCLASS=* is used, then authoritative answers -won't be available. - -Since a resolver must be able to multiplex multiple requests if it is to -perform its function efficiently, each pending request is usually -represented in some block of state information. This state block will -typically contain: - - - A timestamp indicating the time the request began. - The timestamp is used to decide whether RRs in the database - can be used or are out of date. This timestamp uses the - absolute time format previously discussed for RR storage in - zones and caches. Note that when an RRs TTL indicates a - relative time, the RR must be timely, since it is part of a - zone. When the RR has an absolute time, it is part of a - cache, and the TTL of the RR is compared against the timestamp - for the start of the request. - - Note that using the timestamp is superior to using a current - time, since it allows RRs with TTLs of zero to be entered in - the cache in the usual manner, but still used by the current - request, even after intervals of many seconds due to system - load, query retransmission timeouts, etc. - - - Some sort of parameters to limit the amount of work which will - be performed for this request. - - The amount of work which a resolver will do in response to a - client request must be limited to guard against errors in the - database, such as circular CNAME references, and operational - problems, such as network partition which prevents the - - - -Mockapetris [Page 43] - -RFC 1035 Domain Implementation and Specification November 1987 - - - resolver from accessing the name servers it needs. While - local limits on the number of times a resolver will retransmit - a particular query to a particular name server address are - essential, the resolver should have a global per-request - counter to limit work on a single request. The counter should - be set to some initial value and decremented whenever the - resolver performs any action (retransmission timeout, - retransmission, etc.) If the counter passes zero, the request - is terminated with a temporary error. - - Note that if the resolver structure allows one request to - start others in parallel, such as when the need to access a - name server for one request causes a parallel resolve for the - name server's addresses, the spawned request should be started - with a lower counter. This prevents circular references in - the database from starting a chain reaction of resolver - activity. - - - The SLIST data structure discussed in [RFC-1034]. - - This structure keeps track of the state of a request if it - must wait for answers from foreign name servers. - -7.2. Sending the queries - -As described in [RFC-1034], the basic task of the resolver is to -formulate a query which will answer the client's request and direct that -query to name servers which can provide the information. The resolver -will usually only have very strong hints about which servers to ask, in -the form of NS RRs, and may have to revise the query, in response to -CNAMEs, or revise the set of name servers the resolver is asking, in -response to delegation responses which point the resolver to name -servers closer to the desired information. In addition to the -information requested by the client, the resolver may have to call upon -its own services to determine the address of name servers it wishes to -contact. - -In any case, the model used in this memo assumes that the resolver is -multiplexing attention between multiple requests, some from the client, -and some internally generated. Each request is represented by some -state information, and the desired behavior is that the resolver -transmit queries to name servers in a way that maximizes the probability -that the request is answered, minimizes the time that the request takes, -and avoids excessive transmissions. The key algorithm uses the state -information of the request to select the next name server address to -query, and also computes a timeout which will cause the next action -should a response not arrive. The next action will usually be a -transmission to some other server, but may be a temporary error to the - - - -Mockapetris [Page 44] - -RFC 1035 Domain Implementation and Specification November 1987 - - -client. - -The resolver always starts with a list of server names to query (SLIST). -This list will be all NS RRs which correspond to the nearest ancestor -zone that the resolver knows about. To avoid startup problems, the -resolver should have a set of default servers which it will ask should -it have no current NS RRs which are appropriate. The resolver then adds -to SLIST all of the known addresses for the name servers, and may start -parallel requests to acquire the addresses of the servers when the -resolver has the name, but no addresses, for the name servers. - -To complete initialization of SLIST, the resolver attaches whatever -history information it has to the each address in SLIST. This will -usually consist of some sort of weighted averages for the response time -of the address, and the batting average of the address (i.e., how often -the address responded at all to the request). Note that this -information should be kept on a per address basis, rather than on a per -name server basis, because the response time and batting average of a -particular server may vary considerably from address to address. Note -also that this information is actually specific to a resolver address / -server address pair, so a resolver with multiple addresses may wish to -keep separate histories for each of its addresses. Part of this step -must deal with addresses which have no such history; in this case an -expected round trip time of 5-10 seconds should be the worst case, with -lower estimates for the same local network, etc. - -Note that whenever a delegation is followed, the resolver algorithm -reinitializes SLIST. - -The information establishes a partial ranking of the available name -server addresses. Each time an address is chosen and the state should -be altered to prevent its selection again until all other addresses have -been tried. The timeout for each transmission should be 50-100% greater -than the average predicted value to allow for variance in response. - -Some fine points: - - - The resolver may encounter a situation where no addresses are - available for any of the name servers named in SLIST, and - where the servers in the list are precisely those which would - normally be used to look up their own addresses. This - situation typically occurs when the glue address RRs have a - smaller TTL than the NS RRs marking delegation, or when the - resolver caches the result of a NS search. The resolver - should detect this condition and restart the search at the - next ancestor zone, or alternatively at the root. - - - - - -Mockapetris [Page 45] - -RFC 1035 Domain Implementation and Specification November 1987 - - - - If a resolver gets a server error or other bizarre response - from a name server, it should remove it from SLIST, and may - wish to schedule an immediate transmission to the next - candidate server address. - -7.3. Processing responses - -The first step in processing arriving response datagrams is to parse the -response. This procedure should include: - - - Check the header for reasonableness. Discard datagrams which - are queries when responses are expected. - - - Parse the sections of the message, and insure that all RRs are - correctly formatted. - - - As an optional step, check the TTLs of arriving data looking - for RRs with excessively long TTLs. If a RR has an - excessively long TTL, say greater than 1 week, either discard - the whole response, or limit all TTLs in the response to 1 - week. - -The next step is to match the response to a current resolver request. -The recommended strategy is to do a preliminary matching using the ID -field in the domain header, and then to verify that the question section -corresponds to the information currently desired. This requires that -the transmission algorithm devote several bits of the domain ID field to -a request identifier of some sort. This step has several fine points: - - - Some name servers send their responses from different - addresses than the one used to receive the query. That is, a - resolver cannot rely that a response will come from the same - address which it sent the corresponding query to. This name - server bug is typically encountered in UNIX systems. - - - If the resolver retransmits a particular request to a name - server it should be able to use a response from any of the - transmissions. However, if it is using the response to sample - the round trip time to access the name server, it must be able - to determine which transmission matches the response (and keep - transmission times for each outgoing message), or only - calculate round trip times based on initial transmissions. - - - A name server will occasionally not have a current copy of a - zone which it should have according to some NS RRs. The - resolver should simply remove the name server from the current - SLIST, and continue. - - - - -Mockapetris [Page 46] - -RFC 1035 Domain Implementation and Specification November 1987 - - -7.4. Using the cache - -In general, we expect a resolver to cache all data which it receives in -responses since it may be useful in answering future client requests. -However, there are several types of data which should not be cached: - - - When several RRs of the same type are available for a - particular owner name, the resolver should either cache them - all or none at all. When a response is truncated, and a - resolver doesn't know whether it has a complete set, it should - not cache a possibly partial set of RRs. - - - Cached data should never be used in preference to - authoritative data, so if caching would cause this to happen - the data should not be cached. - - - The results of an inverse query should not be cached. - - - The results of standard queries where the QNAME contains "*" - labels if the data might be used to construct wildcards. The - reason is that the cache does not necessarily contain existing - RRs or zone boundary information which is necessary to - restrict the application of the wildcard RRs. - - - RR data in responses of dubious reliability. When a resolver - receives unsolicited responses or RR data other than that - requested, it should discard it without caching it. The basic - implication is that all sanity checks on a packet should be - performed before any of it is cached. - -In a similar vein, when a resolver has a set of RRs for some name in a -response, and wants to cache the RRs, it should check its cache for -already existing RRs. Depending on the circumstances, either the data -in the response or the cache is preferred, but the two should never be -combined. If the data in the response is from authoritative data in the -answer section, it is always preferred. - -8. MAIL SUPPORT - -The domain system defines a standard for mapping mailboxes into domain -names, and two methods for using the mailbox information to derive mail -routing information. The first method is called mail exchange binding -and the other method is mailbox binding. The mailbox encoding standard -and mail exchange binding are part of the DNS official protocol, and are -the recommended method for mail routing in the Internet. Mailbox -binding is an experimental feature which is still under development and -subject to change. - - - - -Mockapetris [Page 47] - -RFC 1035 Domain Implementation and Specification November 1987 - - -The mailbox encoding standard assumes a mailbox name of the form -"<local-part>@<mail-domain>". While the syntax allowed in each of these -sections varies substantially between the various mail internets, the -preferred syntax for the ARPA Internet is given in [RFC-822]. - -The DNS encodes the <local-part> as a single label, and encodes the -<mail-domain> as a domain name. The single label from the <local-part> -is prefaced to the domain name from <mail-domain> to form the domain -name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI- -NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the -<local-part> contains dots or other special characters, its -representation in a master file will require the use of backslash -quoting to ensure that the domain name is properly encoded. For -example, the mailbox Action.domains@ISI.EDU would be represented as -Action\.domains.ISI.EDU. - -8.1. Mail exchange binding - -Mail exchange binding uses the <mail-domain> part of a mailbox -specification to determine where mail should be sent. The <local-part> -is not even consulted. [RFC-974] specifies this method in detail, and -should be consulted before attempting to use mail exchange support. - -One of the advantages of this method is that it decouples mail -destination naming from the hosts used to support mail service, at the -cost of another layer of indirection in the lookup function. However, -the addition layer should eliminate the need for complicated "%", "!", -etc encodings in <local-part>. - -The essence of the method is that the <mail-domain> is used as a domain -name to locate type MX RRs which list hosts willing to accept mail for -<mail-domain>, together with preference values which rank the hosts -according to an order specified by the administrators for <mail-domain>. - -In this memo, the <mail-domain> ISI.EDU is used in examples, together -with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for -ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would -route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name -VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host -addresses. - -8.2. Mailbox binding (Experimental) - -In mailbox binding, the mailer uses the entire mail destination -specification to construct a domain name. The encoded domain name for -the mailbox is used as the QNAME field in a QTYPE=MAILB query. - -Several outcomes are possible for this query: - - - -Mockapetris [Page 48] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 1. The query can return a name error indicating that the mailbox - does not exist as a domain name. - - In the long term, this would indicate that the specified - mailbox doesn't exist. However, until the use of mailbox - binding is universal, this error condition should be - interpreted to mean that the organization identified by the - global part does not support mailbox binding. The - appropriate procedure is to revert to exchange binding at - this point. - - 2. The query can return a Mail Rename (MR) RR. - - The MR RR carries new mailbox specification in its RDATA - field. The mailer should replace the old mailbox with the - new one and retry the operation. - - 3. The query can return a MB RR. - - The MB RR carries a domain name for a host in its RDATA - field. The mailer should deliver the message to that host - via whatever protocol is applicable, e.g., b,SMTP. - - 4. The query can return one or more Mail Group (MG) RRs. - - This condition means that the mailbox was actually a mailing - list or mail group, rather than a single mailbox. Each MG RR - has a RDATA field that identifies a mailbox that is a member - of the group. The mailer should deliver a copy of the - message to each member. - - 5. The query can return a MB RR as well as one or more MG RRs. - - This condition means the the mailbox was actually a mailing - list. The mailer can either deliver the message to the host - specified by the MB RR, which will in turn do the delivery to - all members, or the mailer can use the MG RRs to do the - expansion itself. - -In any of these cases, the response may include a Mail Information -(MINFO) RR. This RR is usually associated with a mail group, but is -legal with a MB. The MINFO RR identifies two mailboxes. One of these -identifies a responsible person for the original mailbox name. This -mailbox should be used for requests to be added to a mail group, etc. -The second mailbox name in the MINFO RR identifies a mailbox that should -receive error messages for mail failures. This is particularly -appropriate for mailing lists when errors in member names should be -reported to a person other than the one who sends a message to the list. - - - -Mockapetris [Page 49] - -RFC 1035 Domain Implementation and Specification November 1987 - - -New fields may be added to this RR in the future. - - -9. REFERENCES and BIBLIOGRAPHY - -[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena - Technical Plan - Name Service, April 1987, version 1.9. - - Describes the fundamentals of the Hesiod name service. - -[IEN-116] J. Postel, "Internet Name Server", IEN-116, - USC/Information Sciences Institute, August 1979. - - A name service obsoleted by the Domain Name System, but - still in use. - -[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks", - Communications of the ACM, October 1986, volume 29, number - 10. - -[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network - Information Center, SRI International, December 1977. - -[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, - USC/Information Sciences Institute, August 1980. - -[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, - USC/Information Sciences Institute, September 1981. - -[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, - September 1981. - - Suggests introduction of a hierarchy in place of a flat - name space for the Internet. - -[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, - USC/Information Sciences Institute, February 1982. - -[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD - Internet Host Table Specification", RFC-810, Network - Information Center, SRI International, March 1982. - - Obsolete. See RFC-952. - -[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames - Server", RFC-811, Network Information Center, SRI - International, March 1982. - - - - -Mockapetris [Page 50] - -RFC 1035 Domain Implementation and Specification November 1987 - - - Obsolete. See RFC-953. - -[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, - Network Information Center, SRI International, March - 1982. - -[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for - Internet User Applications", RFC-819, Network - Information Center, SRI International, August 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, - USC/Information Sciences Institute, August 1980. - -[RFC-830] Z. Su, "A Distributed System for Internet Name Service", - RFC-830, Network Information Center, SRI International, - October 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-882] P. Mockapetris, "Domain names - Concepts and - Facilities," RFC-882, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-883] P. Mockapetris, "Domain names - Implementation and - Specification," RFC-883, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", - RFC-920, USC/Information Sciences Institute, - October 1984. - - Explains the naming scheme for top level domains. - -[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host - Table Specification", RFC-952, SRI, October 1985. - - Specifies the format of HOSTS.TXT, the host/address - table replaced by the DNS. - - - - - -Mockapetris [Page 51] - -RFC 1035 Domain Implementation and Specification November 1987 - - -[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", - RFC-953, SRI, October 1985. - - This RFC contains the official specification of the - hostname server protocol, which is obsoleted by the DNS. - This TCP based protocol accesses information stored in - the RFC-952 format, and is used to obtain copies of the - host table. - -[RFC-973] P. Mockapetris, "Domain System Changes and - Observations", RFC-973, USC/Information Sciences - Institute, January 1986. - - Describes changes to RFC-882 and RFC-883 and reasons for - them. - -[RFC-974] C. Partridge, "Mail routing and the domain system", - RFC-974, CSNET CIC BBN Labs, January 1986. - - Describes the transition from HOSTS.TXT based mail - addressing to the more powerful MX system used with the - domain system. - -[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Concepts and Methods", - RFC-1001, March 1987. - - This RFC and RFC-1002 are a preliminary design for - NETBIOS on top of TCP/IP which proposes to base NetBIOS - name service on top of the DNS. - -[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Detailed - Specifications", RFC-1002, March 1987. - -[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010, - USC/Information Sciences Institute, May 1987. - - Contains socket numbers and mnemonics for host names, - operating systems, etc. - -[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, - November 1987. - - Describes a plan for converting the MILNET to the DNS. - -[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for - Administrators", RFC-1032, November 1987. - - - -Mockapetris [Page 52] - -RFC 1035 Domain Implementation and Specification November 1987 - - - Describes the registration policies used by the NIC to - administer the top level domains and delegate subzones. - -[RFC-1033] M. Lottor, "Domain Administrators Operations Guide", - RFC-1033, November 1987. - - A cookbook for domain administrators. - -[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET - Name Server", Computer Networks, vol 6, nr 3, July 1982. - - Describes a name service for CSNET which is independent - from the DNS and DNS use in the CSNET. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 53] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Index - - * 13 - - ; 33, 35 - - <character-string> 35 - <domain-name> 34 - - @ 35 - - \ 35 - - A 12 - - Byte order 8 - - CH 13 - Character case 9 - CLASS 11 - CNAME 12 - Completion 42 - CS 13 - - Hesiod 13 - HINFO 12 - HS 13 - - IN 13 - IN-ADDR.ARPA domain 22 - Inverse queries 40 - - Mailbox names 47 - MB 12 - MD 12 - MF 12 - MG 12 - MINFO 12 - MINIMUM 20 - MR 12 - MX 12 - - NS 12 - NULL 12 - - Port numbers 32 - Primary server 5 - PTR 12, 18 - - - -Mockapetris [Page 54] - -RFC 1035 Domain Implementation and Specification November 1987 - - - QCLASS 13 - QTYPE 12 - - RDATA 12 - RDLENGTH 11 - - Secondary server 5 - SOA 12 - Stub resolvers 7 - - TCP 32 - TXT 12 - TYPE 11 - - UDP 32 - - WKS 12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 55] - diff --git a/docs/rfc/rfc1413.txt b/docs/rfc/rfc1413.txt deleted file mode 100644 index 17ede58a2..000000000 --- a/docs/rfc/rfc1413.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group M. St. Johns -Request for Comments: 1413 US Department of Defense -Obsoletes: 931 February 1993 - - - Identification Protocol - -Status of this Memo - - This RFC specifies an IAB standards track protocol for the Internet - community, and requests discussion and suggestions for improvements. - Please refer to the current edition of the "IAB Official Protocol - Standards" for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - -1. INTRODUCTION - - The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident - Protocol") provides a means to determine the identity of a user of a - particular TCP connection. Given a TCP port number pair, it returns - a character string which identifies the owner of that connection on - the server's system. - - The Identification Protocol was formerly called the Authentication - Server Protocol. It has been renamed to better reflect its function. - This document is a product of the TCP Client Identity Protocol - Working Group of the Internet Engineering Task Force (IETF). - -2. OVERVIEW - - This is a connection based application on TCP. A server listens for - TCP connections on TCP port 113 (decimal). Once a connection is - established, the server reads a line of data which specifies the - connection of interest. If it exists, the system dependent user - identifier of the connection of interest is sent as the reply. The - server may then either shut the connection down or it may continue to - read/respond to multiple queries. - - The server should close the connection down after a configurable - amount of time with no queries - a 60-180 second idle timeout is - recommended. The client may close the connection down at any time; - however to allow for network delays the client should wait at least - 30 seconds (or longer) after a query before abandoning the query and - closing the connection. - - - - - - - -St. Johns [Page 1] - -RFC 1413 Identification Protocol February 1993 - - -3. RESTRICTIONS - - Queries are permitted only for fully specified connections. The - query contains the local/foreign port pair -- the local/foreign - address pair used to fully specify the connection is taken from the - local and foreign address of query connection. This means a user on - address A may only query the server on address B about connections - between A and B. - -4. QUERY/RESPONSE FORMAT - - The server accepts simple text query requests of the form: - - <port-on-server> , <port-on-client> - - where <port-on-server> is the TCP port (decimal) on the target (where - the "ident" server is running) system, and <port-on-client> is the - TCP port (decimal) on the source (client) system. - - N.B - If a client on host A wants to ask a server on host B about a - connection specified locally (on the client's machine) as 23, 6191 - (an inbound TELNET connection), the client must actually ask about - 6191, 23 - which is how the connection would be specified on host B. - - For example: - - 6191, 23 - - The response is of the form - - <port-on-server> , <port-on-client> : <resp-type> : <add-info> - - where <port-on-server>,<port-on-client> are the same pair as the - query, <resp-type> is a keyword identifying the type of response, and - <add-info> is context dependent. - - The information returned is that associated with the fully specified - TCP connection identified by <server-address>, <client-address>, - <port-on-server>, <port-on-client>, where <server-address> and - <client-address> are the local and foreign IP addresses of the - querying connection -- i.e., the TCP connection to the Identification - Protocol Server. (<port-on-server> and <port-on-client> are taken - from the query.) - - For example: - - 6193, 23 : USERID : UNIX : stjohns - 6195, 23 : ERROR : NO-USER - - - -St. Johns [Page 2] - -RFC 1413 Identification Protocol February 1993 - - -5. RESPONSE TYPES - -A response can be one of two types: - -USERID - - In this case, <add-info> is a string consisting of an - operating system name (with an optional character set - identifier), followed by ":", followed by an - identification string. - - The character set (if present) is separated from the - operating system name by ",". The character set - identifier is used to indicate the character set of the - identification string. The character set identifier, - if omitted, defaults to "US-ASCII" (see below). - - Permitted operating system names and character set - names are specified in RFC 1340, "Assigned Numbers" or - its successors. - - In addition to those operating system and character set - names specified in "Assigned Numbers" there is one - special case operating system identifier - "OTHER". - - Unless "OTHER" is specified as the operating system - type, the server is expected to return the "normal" - user identification of the owner of this connection. - "Normal" in this context may be taken to mean a string - of characters which uniquely identifies the connection - owner such as a user identifier assigned by the system - administrator and used by such user as a mail - identifier, or as the "user" part of a user/password - pair used to gain access to system resources. When an - operating system is specified (e.g., anything but - "OTHER"), the user identifier is expected to be in a - more or less immediately useful form - e.g., something - that could be used as an argument to "finger" or as a - mail address. - - "OTHER" indicates the identifier is an unformatted - character string consisting of printable characters in - the specified character set. "OTHER" should be - specified if the user identifier does not meet the - constraints of the previous paragraph. Sending an - encrypted audit token, or returning other non-userid - information about a user (such as the real name and - phone number of a user from a UNIX passwd file) are - - - -St. Johns [Page 3] - -RFC 1413 Identification Protocol February 1993 - - - both examples of when "OTHER" should be used. - - Returned user identifiers are expected to be printable - in the character set indicated. - - The identifier is an unformatted octet string - - all - octets are permissible EXCEPT octal 000 (NUL), 012 (LF) - and 015 (CR). N.B. - space characters (040) following the - colon separator ARE part of the identifier string and - may not be ignored. A response string is still - terminated normally by a CR/LF. N.B. A string may be - printable, but is not *necessarily* printable. - -ERROR - - For some reason the port owner could not be determined, <add-info> - tells why. The following are the permitted values of <add-info> and - their meanings: - - INVALID-PORT - - Either the local or foreign port was improperly - specified. This should be returned if either or - both of the port ids were out of range (TCP port - numbers are from 1-65535), negative integers, reals or - in any fashion not recognized as a non-negative - integer. - - NO-USER - - The connection specified by the port pair is not - currently in use or currently not owned by an - identifiable entity. - - HIDDEN-USER - - The server was able to identify the user of this - port, but the information was not returned at the - request of the user. - - UNKNOWN-ERROR - - Can't determine connection owner; reason unknown. - Any error not covered above should return this - error code value. Optionally, this code MAY be - returned in lieu of any other specific error code - if, for example, the server desires to hide - information implied by the return of that error - - - -St. Johns [Page 4] - -RFC 1413 Identification Protocol February 1993 - - - code, or for any other reason. If a server - implements such a feature, it MUST be configurable - and it MUST default to returning the proper error - message. - - Other values may eventually be specified and defined in future - revisions to this document. If an implementer has a need to specify - a non-standard error code, that code must begin with "X". - - In addition, the server is allowed to drop the query connection - without responding. Any premature close (i.e., one where the client - does not receive the EOL, whether graceful or an abort should be - considered to have the same meaning as "ERROR : UNKNOWN-ERROR". - -FORMAL SYNTAX - - <request> ::= <port-pair> <EOL> - - <port-pair> ::= <integer> "," <integer> - - <reply> ::= <reply-text> <EOL> - - <EOL> ::= "015 012" ; CR-LF End of Line Indicator - - <reply-text> ::= <error-reply> | <ident-reply> - - <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type> - - <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field> - ":" <user-id> - - <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" - | "HIDDEN-USER" | <error-token> - - <opsys-field> ::= <opsys> [ "," <charset>] - - <opsys> ::= "OTHER" | "UNIX" | <token> ...etc. - ; (See "Assigned Numbers") - - <charset> ::= "US-ASCII" | ...etc. - ; (See "Assigned Numbers") - - <user-id> ::= <octet-string> - - <token> ::= 1*64<token-characters> ; 1-64 characters - - <error-token> ::= "X"1*63<token-characters> - ; 2-64 chars beginning w/X - - - -St. Johns [Page 5] - -RFC 1413 Identification Protocol February 1993 - - - <integer> ::= 1*5<digit> ; 1-5 digits. - - <digit> ::= "0" | "1" ... "8" | "9" ; 0-9 - - <token-characters> ::= - <Any of these ASCII characters: a-z, A-Z, - - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; > - ; upper and lowercase a-z plus - ; printables minus the colon ":" - ; character. - - <octet-string> ::= 1*512<octet-characters> - - <octet-characters> ::= - <any octet from 00 to 377 (octal) except for - ASCII NUL (000), CR (015) and LF (012)> - -Notes on Syntax: - - 1) To promote interoperability among variant - implementations, with respect to white space the above - syntax is understood to embody the "be conservative in - what you send and be liberal in what you accept" - philosophy. Clients and servers should not generate - unnecessary white space (space and tab characters) but - should accept white space anywhere except within a - token. In parsing responses, white space may occur - anywhere, except within a token. Specifically, any - amount of white space is permitted at the beginning or - end of a line both for queries and responses. This - does not apply for responses that contain a user ID - because everything after the colon after the operating - system type until the terminating CR/LF is taken as - part of the user ID. The terminating CR/LF is NOT - considered part of the user ID. - - 2) The above notwithstanding, servers should restrict the - amount of inter-token white space they send to the - smallest amount reasonable or useful. Clients should - feel free to abort a connection if they receive 1000 - characters without receiving an <EOL>. - - 3) The 512 character limit on user IDs and the 64 - character limit on tokens should be understood to mean - as follows: a) No new token (i.e., OPSYS or ERROR-TYPE) - token will be defined that has a length greater than 64 - and b) a server SHOULD NOT send more than 512 octets of - user ID and a client MUST accept at least 512 octets of - - - -St. Johns [Page 6] - -RFC 1413 Identification Protocol February 1993 - - - user ID. Because of this limitation, a server MUST - return the most significant portion of the user ID in - the first 512 octets. - - 4) The character sets and character set identifiers should - map directly to those defined in or referenced by RFC 1340, - "Assigned Numbers" or its successors. Character set - identifiers only apply to the user identification field - - all other fields will be defined in and must be sent - as US-ASCII. - - 5) Although <user-id> is defined as an <octet-string> - above, it must follow the format and character set - constraints implied by the <opsys-field>; see the - discussion above. - - 6) The character set provides context for the client to - print or store the returned user identification string. - If the client does not recognize or implement the - returned character set, it should handle the returned - identification string as OCTET, but should in addition - store or report the character set. An OCTET string - should be printed, stored or handled in hex notation - (0-9a-f) in addition to any other representation the - client implements - this provides a standard - representation among differing implementations. - -6. Security Considerations - - The information returned by this protocol is at most as trustworthy - as the host providing it OR the organization operating the host. For - example, a PC in an open lab has few if any controls on it to prevent - a user from having this protocol return any identifier the user - wants. Likewise, if the host has been compromised the information - returned may be completely erroneous and misleading. - - The Identification Protocol is not intended as an authorization or - access control protocol. At best, it provides some additional - auditing information with respect to TCP connections. At worst, it - can provide misleading, incorrect, or maliciously incorrect - information. - - The use of the information returned by this protocol for other than - auditing is strongly discouraged. Specifically, using Identification - Protocol information to make access control decisions - either as the - primary method (i.e., no other checks) or as an adjunct to other - methods may result in a weakening of normal host security. - - - - -St. Johns [Page 7] - -RFC 1413 Identification Protocol February 1993 - - - An Identification server may reveal information about users, - entities, objects or processes which might normally be considered - private. An Identification server provides service which is a rough - analog of the CallerID services provided by some phone companies and - many of the same privacy considerations and arguments that apply to - the CallerID service apply to Identification. If you wouldn't run a - "finger" server due to privacy considerations you may not want to run - this protocol. - -7. ACKNOWLEDGEMENTS - - Acknowledgement is given to Dan Bernstein who is primarily - responsible for renewing interest in this protocol and for pointing - out some annoying errors in RFC 931. - -References - - [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January - 1985. - - [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, - USC/Information Sciences Institute, July 1992. - -Author's Address - - Michael C. St. Johns - DARPA/CSTO - 3701 N. Fairfax Dr - Arlington, VA 22203 - - Phone: (703) 696-2271 - EMail: stjohns@DARPA.MIL - - - - - - - - - - - - - - - - - - - -St. Johns [Page 8] -
\ No newline at end of file diff --git a/docs/rfc/rfc1459.txt b/docs/rfc/rfc1459.txt deleted file mode 100644 index 09fbf34f7..000000000 --- a/docs/rfc/rfc1459.txt +++ /dev/null @@ -1,3643 +0,0 @@ - - - - - - -Network Working Group J. Oikarinen -Request for Comments: 1459 D. Reed - May 1993 - - - Internet Relay Chat Protocol - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. Discussion and suggestions for improvement are requested. - Please refer to the current edition of the "IAB Official Protocol - Standards" for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - -Abstract - - The IRC protocol was developed over the last 4 years since it was - first implemented as a means for users on a BBS to chat amongst - themselves. Now it supports a world-wide network of servers and - clients, and is stringing to cope with growth. Over the past 2 years, - the average number of users connected to the main IRC network has - grown by a factor of 10. - - The IRC protocol is a text-based protocol, with the simplest client - being any socket program capable of connecting to the server. - -Table of Contents - - 1. INTRODUCTION ............................................... 4 - 1.1 Servers ................................................ 4 - 1.2 Clients ................................................ 5 - 1.2.1 Operators .......................................... 5 - 1.3 Channels ................................................ 5 - 1.3.1 Channel Operators .................................... 6 - 2. THE IRC SPECIFICATION ....................................... 7 - 2.1 Overview ................................................ 7 - 2.2 Character codes ......................................... 7 - 2.3 Messages ................................................ 7 - 2.3.1 Message format in 'pseudo' BNF .................... 8 - 2.4 Numeric replies ......................................... 10 - 3. IRC Concepts ................................................ 10 - 3.1 One-to-one communication ................................ 10 - 3.2 One-to-many ............................................. 11 - 3.2.1 To a list .......................................... 11 - 3.2.2 To a group (channel) ............................... 11 - 3.2.3 To a host/server mask .............................. 12 - 3.3 One to all .............................................. 12 - - - -Oikarinen & Reed [Page 1] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 3.3.1 Client to Client ................................... 12 - 3.3.2 Clients to Server .................................. 12 - 3.3.3 Server to Server ................................... 12 - 4. MESSAGE DETAILS ............................................. 13 - 4.1 Connection Registration ................................. 13 - 4.1.1 Password message ................................... 14 - 4.1.2 Nickname message ................................... 14 - 4.1.3 User message ....................................... 15 - 4.1.4 Server message ..................................... 16 - 4.1.5 Operator message ................................... 17 - 4.1.6 Quit message ....................................... 17 - 4.1.7 Server Quit message ................................ 18 - 4.2 Channel operations ...................................... 19 - 4.2.1 Join message ....................................... 19 - 4.2.2 Part message ....................................... 20 - 4.2.3 Mode message ....................................... 21 - 4.2.3.1 Channel modes ................................. 21 - 4.2.3.2 User modes .................................... 22 - 4.2.4 Topic message ...................................... 23 - 4.2.5 Names message ...................................... 24 - 4.2.6 List message ....................................... 24 - 4.2.7 Invite message ..................................... 25 - 4.2.8 Kick message ....................................... 25 - 4.3 Server queries and commands ............................. 26 - 4.3.1 Version message .................................... 26 - 4.3.2 Stats message ...................................... 27 - 4.3.3 Links message ...................................... 28 - 4.3.4 Time message ....................................... 29 - 4.3.5 Connect message .................................... 29 - 4.3.6 Trace message ...................................... 30 - 4.3.7 Admin message ...................................... 31 - 4.3.8 Info message ....................................... 31 - 4.4 Sending messages ........................................ 32 - 4.4.1 Private messages ................................... 32 - 4.4.2 Notice messages .................................... 33 - 4.5 User-based queries ...................................... 33 - 4.5.1 Who query .......................................... 33 - 4.5.2 Whois query ........................................ 34 - 4.5.3 Whowas message ..................................... 35 - 4.6 Miscellaneous messages .................................. 35 - 4.6.1 Kill message ....................................... 36 - 4.6.2 Ping message ....................................... 37 - 4.6.3 Pong message ....................................... 37 - 4.6.4 Error message ...................................... 38 - 5. OPTIONAL MESSAGES ........................................... 38 - 5.1 Away message ............................................ 38 - 5.2 Rehash command .......................................... 39 - 5.3 Restart command ......................................... 39 - - - -Oikarinen & Reed [Page 2] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 5.4 Summon message .......................................... 40 - 5.5 Users message ........................................... 40 - 5.6 Operwall command ........................................ 41 - 5.7 Userhost message ........................................ 42 - 5.8 Ison message ............................................ 42 - 6. REPLIES ..................................................... 43 - 6.1 Error Replies ........................................... 43 - 6.2 Command responses ....................................... 48 - 6.3 Reserved numerics ....................................... 56 - 7. Client and server authentication ............................ 56 - 8. Current Implementations Details ............................. 56 - 8.1 Network protocol: TCP ................................... 57 - 8.1.1 Support of Unix sockets ............................ 57 - 8.2 Command Parsing ......................................... 57 - 8.3 Message delivery ........................................ 57 - 8.4 Connection 'Liveness' ................................... 58 - 8.5 Establishing a server-client connection ................. 58 - 8.6 Establishing a server-server connection ................. 58 - 8.6.1 State information exchange when connecting ......... 59 - 8.7 Terminating server-client connections ................... 59 - 8.8 Terminating server-server connections ................... 59 - 8.9 Tracking nickname changes ............................... 60 - 8.10 Flood control of clients ............................... 60 - 8.11 Non-blocking lookups ................................... 61 - 8.11.1 Hostname (DNS) lookups ............................ 61 - 8.11.2 Username (Ident) lookups .......................... 61 - 8.12 Configuration file ..................................... 61 - 8.12.1 Allowing clients to connect ....................... 62 - 8.12.2 Operators ......................................... 62 - 8.12.3 Allowing servers to connect ....................... 62 - 8.12.4 Administrivia ..................................... 63 - 8.13 Channel membership ..................................... 63 - 9. Current problems ............................................ 63 - 9.1 Scalability ............................................. 63 - 9.2 Labels .................................................. 63 - 9.2.1 Nicknames .......................................... 63 - 9.2.2 Channels ........................................... 64 - 9.2.3 Servers ............................................ 64 - 9.3 Algorithms .............................................. 64 - 10. Support and availability ................................... 64 - 11. Security Considerations .................................... 65 - 12. Authors' Addresses ......................................... 65 - - - - - - - - - -Oikarinen & Reed [Page 3] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -1. INTRODUCTION - - The IRC (Internet Relay Chat) protocol has been designed over a - number of years for use with text based conferencing. This document - describes the current IRC protocol. - - The IRC protocol has been developed on systems using the TCP/IP - network protocol, although there is no requirement that this remain - the only sphere in which it operates. - - IRC itself is a teleconferencing system, which (through the use of - the client-server model) is well-suited to running on many machines - in a distributed fashion. A typical setup involves a single process - (the server) forming a central point for clients (or other servers) - to connect to, performing the required message delivery/multiplexing - and other functions. - -1.1 Servers - - The server forms the backbone of IRC, providing a point to which - clients may connect to to talk to each other, and a point for other - servers to connect to, forming an IRC network. The only network - configuration allowed for IRC servers is that of a spanning tree [see - Fig. 1] where each server acts as a central node for the rest of the - net it sees. - - - [ Server 15 ] [ Server 13 ] [ Server 14] - / \ / - / \ / - [ Server 11 ] ------ [ Server 1 ] [ Server 12] - / \ / - / \ / - [ Server 2 ] [ Server 3 ] - / \ \ - / \ \ - [ Server 4 ] [ Server 5 ] [ Server 6 ] - / | \ / - / | \ / - / | \____ / - / | \ / - [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] - - : - [ etc. ] - : - - [ Fig. 1. Format of IRC server network ] - - - -Oikarinen & Reed [Page 4] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -1.2 Clients - - A client is anything connecting to a server that is not another - server. Each client is distinguished from other clients by a unique - nickname having a maximum length of nine (9) characters. See the - protocol grammar rules for what may and may not be used in a - nickname. In addition to the nickname, all servers must have the - following information about all clients: the real name of the host - that the client is running on, the username of the client on that - host, and the server to which the client is connected. - -1.2.1 Operators - - To allow a reasonable amount of order to be kept within the IRC - network, a special class of clients (operators) is allowed to perform - general maintenance functions on the network. Although the powers - granted to an operator can be considered as 'dangerous', they are - nonetheless required. Operators should be able to perform basic - network tasks such as disconnecting and reconnecting servers as - needed to prevent long-term use of bad network routing. In - recognition of this need, the protocol discussed herein provides for - operators only to be able to perform such functions. See sections - 4.1.7 (SQUIT) and 4.3.5 (CONNECT). - - A more controversial power of operators is the ability to remove a - user from the connected network by 'force', i.e. operators are able - to close the connection between any client and server. The - justification for this is delicate since its abuse is both - destructive and annoying. For further details on this type of - action, see section 4.6.1 (KILL). - -1.3 Channels - - A channel is a named group of one or more clients which will all - receive messages addressed to that channel. The channel is created - implicitly when the first client joins it, and the channel ceases to - exist when the last client leaves it. While channel exists, any - client can reference the channel using the name of the channel. - - Channels names are strings (beginning with a '&' or '#' character) of - length up to 200 characters. Apart from the the requirement that the - first character being either '&' or '#'; the only restriction on a - channel name is that it may not contain any spaces (' '), a control G - (^G or ASCII 7), or a comma (',' which is used as a list item - separator by the protocol). - - There are two types of channels allowed by this protocol. One is a - distributed channel which is known to all the servers that are - - - -Oikarinen & Reed [Page 5] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - connected to the network. These channels are marked by the first - character being a only clients on the server where it exists may join - it. These are distinguished by a leading '&' character. On top of - these two types, there are the various channel modes available to - alter the characteristics of individual channels. See section 4.2.3 - (MODE command) for more details on this. - - To create a new channel or become part of an existing channel, a user - is required to JOIN the channel. If the channel doesn't exist prior - to joining, the channel is created and the creating user becomes a - channel operator. If the channel already exists, whether or not your - request to JOIN that channel is honoured depends on the current modes - of the channel. For example, if the channel is invite-only, (+i), - then you may only join if invited. As part of the protocol, a user - may be a part of several channels at once, but a limit of ten (10) - channels is recommended as being ample for both experienced and - novice users. See section 8.13 for more information on this. - - If the IRC network becomes disjoint because of a split between two - servers, the channel on each side is only composed of those clients - which are connected to servers on the respective sides of the split, - possibly ceasing to exist on one side of the split. When the split - is healed, the connecting servers announce to each other who they - think is in each channel and the mode of that channel. If the - channel exists on both sides, the JOINs and MODEs are interpreted in - an inclusive manner so that both sides of the new connection will - agree about which clients are in the channel and what modes the - channel has. - -1.3.1 Channel Operators - - The channel operator (also referred to as a "chop" or "chanop") on a - given channel is considered to 'own' that channel. In recognition of - this status, channel operators are endowed with certain powers which - enable them to keep control and some sort of sanity in their channel. - As an owner of a channel, a channel operator is not required to have - reasons for their actions, although if their actions are generally - antisocial or otherwise abusive, it might be reasonable to ask an IRC - operator to intervene, or for the usersjust leave and go elsewhere - and form their own channel. - - The commands which may only be used by channel operators are: - - KICK - Eject a client from the channel - MODE - Change the channel's mode - INVITE - Invite a client to an invite-only channel (mode +i) - TOPIC - Change the channel topic in a mode +t channel - - - - -Oikarinen & Reed [Page 6] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - A channel operator is identified by the '@' symbol next to their - nickname whenever it is associated with a channel (ie replies to the - NAMES, WHO and WHOIS commands). - -2. The IRC Specification - -2.1 Overview - - The protocol as described herein is for use both with server to - server and client to server connections. There are, however, more - restrictions on client connections (which are considered to be - untrustworthy) than on server connections. - -2.2 Character codes - - No specific character set is specified. The protocol is based on a a - set of codes which are composed of eight (8) bits, making up an - octet. Each message may be composed of any number of these octets; - however, some octet values are used for control codes which act as - message delimiters. - - Regardless of being an 8-bit protocol, the delimiters and keywords - are such that protocol is mostly usable from USASCII terminal and a - telnet connection. - - Because of IRC's scandanavian origin, the characters {}| are - considered to be the lower case equivalents of the characters []\, - respectively. This is a critical issue when determining the - equivalence of two nicknames. - -2.3 Messages - - Servers and clients send eachother messages which may or may not - generate a reply. If the message contains a valid command, as - described in later sections, the client should expect a reply as - specified but it is not advised to wait forever for the reply; client - to server and server to server communication is essentially - asynchronous in nature. - - Each IRC message may consist of up to three main parts: the prefix - (optional), the command, and the command parameters (of which there - may be up to 15). The prefix, command, and all parameters are - separated by one (or more) ASCII space character(s) (0x20). - - The presence of a prefix is indicated with a single leading ASCII - colon character (':', 0x3b), which must be the first character of the - message itself. There must be no gap (whitespace) between the colon - and the prefix. The prefix is used by servers to indicate the true - - - -Oikarinen & Reed [Page 7] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - origin of the message. If the prefix is missing from the message, it - is assumed to have originated from the connection from which it was - received. Clients should not use prefix when sending a message from - themselves; if they use a prefix, the only valid prefix is the - registered nickname associated with the client. If the source - identified by the prefix cannot be found from the server's internal - database, or if the source is registered from a different link than - from which the message arrived, the server must ignore the message - silently. - - The command must either be a valid IRC command or a three (3) digit - number represented in ASCII text. - - IRC messages are always lines of characters terminated with a CR-LF - (Carriage Return - Line Feed) pair, and these messages shall not - exceed 512 characters in length, counting all characters including - the trailing CR-LF. Thus, there are 510 characters maximum allowed - for the command and its parameters. There is no provision for - continuation message lines. See section 7 for more details about - current implementations. - -2.3.1 Message format in 'pseudo' BNF - - The protocol messages must be extracted from the contiguous stream of - octets. The current solution is to designate two characters, CR and - LF, as message separators. Empty messages are silently ignored, - which permits use of the sequence CR-LF between messages - without extra problems. - - The extracted message is parsed into the components <prefix>, - <command> and list of parameters matched either by <middle> or - <trailing> components. - - The BNF representation for this is: - - -<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf> -<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ] -<command> ::= <letter> { <letter> } | <number> <number> <number> -<SPACE> ::= ' ' { ' ' } -<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ] - -<middle> ::= <Any *non-empty* sequence of octets not including SPACE - or NUL or CR or LF, the first of which may not be ':'> -<trailing> ::= <Any, possibly *empty*, sequence of octets not including - NUL or CR or LF> - -<crlf> ::= CR LF - - - -Oikarinen & Reed [Page 8] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -NOTES: - - 1) <SPACE> is consists only of SPACE character(s) (0x20). - Specially notice that TABULATION, and all other control - characters are considered NON-WHITE-SPACE. - - 2) After extracting the parameter list, all parameters are equal, - whether matched by <middle> or <trailing>. <Trailing> is just - a syntactic trick to allow SPACE within parameter. - - 3) The fact that CR and LF cannot appear in parameter strings is - just artifact of the message framing. This might change later. - - 4) The NUL character is not special in message framing, and - basically could end up inside a parameter, but as it would - cause extra complexities in normal C string handling. Therefore - NUL is not allowed within messages. - - 5) The last parameter may be an empty string. - - 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must - not be used in server to server communications and is only - intended for server to client messages in order to provide - clients with more useful information about who a message is - from without the need for additional queries. - - Most protocol messages specify additional semantics and syntax for - the extracted parameter strings dictated by their position in the - list. For example, many server commands will assume that the first - parameter after the command is the list of targets, which can be - described with: - - <target> ::= <to> [ "," <target> ] - <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask> - <channel> ::= ('#' | '&') <chstring> - <servername> ::= <host> - <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames - <nick> ::= <letter> { <letter> | <number> | <special> } - <mask> ::= ('#' | '$') <chstring> - <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and - comma (',')> - - Other parameter syntaxes are: - - <user> ::= <nonwhite> { <nonwhite> } - <letter> ::= 'a' ... 'z' | 'A' ... 'Z' - <number> ::= '0' ... '9' - <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' - - - -Oikarinen & Reed [Page 9] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR - (0xd), and LF (0xa)> - -2.4 Numeric replies - - Most of the messages sent to the server generate a reply of some - sort. The most common reply is the numeric reply, used for both - errors and normal replies. The numeric reply must be sent as one - message consisting of the sender prefix, the three digit numeric, and - the target of the reply. A numeric reply is not allowed to originate - from a client; any such messages received by a server are silently - dropped. In all other respects, a numeric reply is just like a normal - message, except that the keyword is made up of 3 numeric digits - rather than a string of letters. A list of different replies is - supplied in section 6. - -3. IRC Concepts. - - This section is devoted to describing the actual concepts behind the - organization of the IRC protocol and how the current - implementations deliver different classes of messages. - - - - 1--\ - A D---4 - 2--/ \ / - B----C - / \ - 3 E - - Servers: A, B, C, D, E Clients: 1, 2, 3, 4 - - [ Fig. 2. Sample small IRC network ] - -3.1 One-to-one communication - - Communication on a one-to-one basis is usually only performed by - clients, since most server-server traffic is not a result of servers - talking only to each other. To provide a secure means for clients to - talk to each other, it is required that all servers be able to send a - message in exactly one direction along the spanning tree in order to - reach any client. The path of a message being delivered is the - shortest path between any two points on the spanning tree. - - The following examples all refer to Figure 2 above. - - - - - -Oikarinen & Reed [Page 10] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -Example 1: - A message between clients 1 and 2 is only seen by server A, which - sends it straight to client 2. - -Example 2: - A message between clients 1 and 3 is seen by servers A & B, and - client 3. No other clients or servers are allowed see the message. - -Example 3: - A message between clients 2 and 4 is seen by servers A, B, C & D - and client 4 only. - -3.2 One-to-many - - The main goal of IRC is to provide a forum which allows easy and - efficient conferencing (one to many conversations). IRC offers - several means to achieve this, each serving its own purpose. - -3.2.1 To a list - - The least efficient style of one-to-many conversation is through - clients talking to a 'list' of users. How this is done is almost - self explanatory: the client gives a list of destinations to which - the message is to be delivered and the server breaks it up and - dispatches a separate copy of the message to each given destination. - This isn't as efficient as using a group since the destination list - is broken up and the dispatch sent without checking to make sure - duplicates aren't sent down each path. - -3.2.2 To a group (channel) - - In IRC the channel has a role equivalent to that of the multicast - group; their existence is dynamic (coming and going as people join - and leave channels) and the actual conversation carried out on a - channel is only sent to servers which are supporting users on a given - channel. If there are multiple users on a server in the same - channel, the message text is sent only once to that server and then - sent to each client on the channel. This action is then repeated for - each client-server combination until the original message has fanned - out and reached each member of the channel. - - The following examples all refer to Figure 2. - -Example 4: - Any channel with 1 client in it. Messages to the channel go to the - server and then nowhere else. - - - - - -Oikarinen & Reed [Page 11] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -Example 5: - 2 clients in a channel. All messages traverse a path as if they - were private messages between the two clients outside a channel. - -Example 6: - Clients 1, 2 and 3 in a channel. All messages to the channel are - sent to all clients and only those servers which must be traversed - by the message if it were a private message to a single client. If - client 1 sends a message, it goes back to client 2 and then via - server B to client 3. - -3.2.3 To a host/server mask - - To provide IRC operators with some mechanism to send messages to a - large body of related users, host and server mask messages are - provided. These messages are sent to users whose host or server - information match that of the mask. The messages are only sent to - locations where users are, in a fashion similar to that of channels. - -3.3 One-to-all - - The one-to-all type of message is better described as a broadcast - message, sent to all clients or servers or both. On a large network - of users and servers, a single message can result in a lot of traffic - being sent over the network in an effort to reach all of the desired - destinations. - - For some messages, there is no option but to broadcast it to all - servers so that the state information held by each server is - reasonably consistent between servers. - -3.3.1 Client-to-Client - - There is no class of message which, from a single message, results in - a message being sent to every other client. - -3.3.2 Client-to-Server - - Most of the commands which result in a change of state information - (such as channel membership, channel mode, user status, etc) must be - sent to all servers by default, and this distribution may not be - changed by the client. - -3.3.3 Server-to-Server. - - While most messages between servers are distributed to all 'other' - servers, this is only required for any message that affects either a - user, channel or server. Since these are the basic items found in - - - -Oikarinen & Reed [Page 12] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - IRC, nearly all messages originating from a server are broadcast to - all other connected servers. - -4. Message details - - On the following pages are descriptions of each message recognized by - the IRC server and client. All commands described in this section - must be implemented by any server for this protocol. - - Where the reply ERR_NOSUCHSERVER is listed, it means that the - <server> parameter could not be found. The server must not send any - other replies after this for that command. - - The server to which a client is connected is required to parse the - complete message, returning any appropriate errors. If the server - encounters a fatal error while parsing a message, an error must be - sent back to the client and the parsing terminated. A fatal error - may be considered to be incorrect command, a destination which is - otherwise unknown to the server (server, nick or channel names fit - this category), not enough parameters or incorrect privileges. - - If a full set of parameters is presented, then each must be checked - for validity and appropriate responses sent back to the client. In - the case of messages which use parameter lists using the comma as an - item separator, a reply must be sent for each item. - - In the examples below, some messages appear using the full format: - - :Name COMMAND parameter list - - Such examples represent a message from "Name" in transit between - servers, where it is essential to include the name of the original - sender of the message so remote servers may send back a reply along - the correct path. - -4.1 Connection Registration - - The commands described here are used to register a connection with an - IRC server as either a user or a server as well as correctly - disconnect. - - A "PASS" command is not required for either client or server - connection to be registered, but it must precede the server message - or the latter of the NICK/USER combination. It is strongly - recommended that all server connections have a password in order to - give some level of security to the actual connections. The - recommended order for a client to register is as follows: - - - - -Oikarinen & Reed [Page 13] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 1. Pass message - 2. Nick message - 3. User message - -4.1.1 Password message - - - Command: PASS - Parameters: <password> - - The PASS command is used to set a 'connection password'. The - password can and must be set before any attempt to register the - connection is made. Currently this requires that clients send a PASS - command before sending the NICK/USER combination and servers *must* - send a PASS command before any SERVER command. The password supplied - must match the one contained in the C/N lines (for servers) or I - lines (for clients). It is possible to send multiple PASS commands - before registering but only the last one sent is used for - verification and it may not be changed once registered. Numeric - Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Example: - - PASS secretpasswordhere - -4.1.2 Nick message - - Command: NICK - Parameters: <nickname> [ <hopcount> ] - - NICK message is used to give user a nickname or change the previous - one. The <hopcount> parameter is only used by servers to indicate - how far away a nick is from its home server. A local connection has - a hopcount of 0. If supplied by a client, it must be ignored. - - If a NICK message arrives at a server which already knows about an - identical nickname for another client, a nickname collision occurs. - As a result of a nickname collision, all instances of the nickname - are removed from the server's database, and a KILL command is issued - to remove the nickname from all other server's database. If the NICK - message causing the collision was a nickname change, then the - original (old) nick must be removed as well. - - If the server recieves an identical NICK from a client which is - directly connected, it may issue an ERR_NICKCOLLISION to the local - client, drop the NICK command, and not generate any kills. - - - -Oikarinen & Reed [Page 14] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME - ERR_NICKNAMEINUSE ERR_NICKCOLLISION - - Example: - - NICK Wiz ; Introducing new nick "Wiz". - - :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy. - -4.1.3 User message - - Command: USER - Parameters: <username> <hostname> <servername> <realname> - - The USER message is used at the beginning of connection to specify - the username, hostname, servername and realname of s new user. It is - also used in communication between servers to indicate new user - arriving on IRC, since only after both USER and NICK have been - received from a client does a user become registered. - - Between servers USER must to be prefixed with client's NICKname. - Note that hostname and servername are normally ignored by the IRC - server when the USER command comes from a directly connected client - (for security reasons), but they are used in server to server - communication. This means that a NICK must always be sent to a - remote server when a new user is being introduced to the rest of the - network before the accompanying USER is sent. - - It must be noted that realname parameter must be the last parameter, - because it may contain space characters and must be prefixed with a - colon (':') to make sure this is recognised as such. - - Since it is easy for a client to lie about its username by relying - solely on the USER message, the use of an "Identity Server" is - recommended. If the host which a user connects from has such a - server enabled the username is set to that as in the reply from the - "Identity Server". - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Examples: - - - USER guest tolmoon tolsun :Ronnie Reagan - - - -Oikarinen & Reed [Page 15] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - ; User registering themselves with a - username of "guest" and real name - "Ronnie Reagan". - - - :testnick USER guest tolmoon tolsun :Ronnie Reagan - ; message between servers with the - nickname for which the USER command - belongs to - -4.1.4 Server message - - Command: SERVER - Parameters: <servername> <hopcount> <info> - - The server message is used to tell a server that the other end of a - new connection is a server. This message is also used to pass server - data over whole net. When a new server is connected to net, - information about it be broadcast to the whole network. <hopcount> - is used to give all servers some internal information on how far away - all servers are. With a full server list, it would be possible to - construct a map of the entire server tree, but hostmasks prevent this - from being done. - - The SERVER message must only be accepted from either (a) a connection - which is yet to be registered and is attempting to register as a - server, or (b) an existing connection to another server, in which - case the SERVER message is introducing a new server behind that - server. - - Most errors that occur with the receipt of a SERVER command result in - the connection being terminated by the destination host (target - SERVER). Error replies are usually sent using the "ERROR" command - rather than the numeric since the ERROR command has several useful - properties which make it useful here. - - If a SERVER message is parsed and attempts to introduce a server - which is already known to the receiving server, the connection from - which that message must be closed (following the correct procedures), - since a duplicate route to a server has formed and the acyclic nature - of the IRC tree broken. - - Numeric Replies: - - ERR_ALREADYREGISTRED - - Example: - - - - -Oikarinen & Reed [Page 16] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server - ; New server test.oulu.fi introducing - itself and attempting to register. The - name in []'s is the hostname for the - host running test.oulu.fi. - - -:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server - ; Server tolsun.oulu.fi is our uplink - for csd.bu.edu which is 5 hops away. - -4.1.5 Oper - - Command: OPER - Parameters: <user> <password> - - OPER message is used by a normal user to obtain operator privileges. - The combination of <user> and <password> are required to gain - Operator privileges. - - If the client sending the OPER command supplies the correct password - for the given user, the server then informs the rest of the network - of the new operator by issuing a "MODE +o" for the clients nickname. - - The OPER message is client-server only. - - Numeric Replies: - - ERR_NEEDMOREPARAMS RPL_YOUREOPER - ERR_NOOPERHOST ERR_PASSWDMISMATCH - - Example: - - OPER foo bar ; Attempt to register as an operator - using a username of "foo" and "bar" as - the password. - -4.1.6 Quit - - Command: QUIT - Parameters: [<Quit message>] - - A client session is ended with a quit message. The server must close - the connection to a client which sends a QUIT message. If a "Quit - Message" is given, this will be sent instead of the default message, - the nickname. - - When netsplits (disconnecting of two servers) occur, the quit message - - - -Oikarinen & Reed [Page 17] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - is composed of the names of two servers involved, separated by a - space. The first name is that of the server which is still connected - and the second name is that of the server that has become - disconnected. - - If, for some other reason, a client connection is closed without the - client issuing a QUIT command (e.g. client dies and EOF occurs - on socket), the server is required to fill in the quit message with - some sort of message reflecting the nature of the event which - caused it to happen. - - Numeric Replies: - - None. - - Examples: - - QUIT :Gone to have lunch ; Preferred message format. - -4.1.7 Server quit message - - Command: SQUIT - Parameters: <server> <comment> - - The SQUIT message is needed to tell about quitting or dead servers. - If a server wishes to break the connection to another server it must - send a SQUIT message to the other server, using the the name of the - other server as the server parameter, which then closes its - connection to the quitting server. - - This command is also available operators to help keep a network of - IRC servers connected in an orderly fashion. Operators may also - issue an SQUIT message for a remote server connection. In this case, - the SQUIT must be parsed by each server inbetween the operator and - the remote server, updating the view of the network held by each - server as explained below. - - The <comment> should be supplied by all operators who execute a SQUIT - for a remote server (that is not connected to the server they are - currently on) so that other operators are aware for the reason of - this action. The <comment> is also filled in by servers which may - place an error or similar message here. - - Both of the servers which are on either side of the connection being - closed are required to to send out a SQUIT message (to all its other - server connections) for all other servers which are considered to be - behind that link. - - - - -Oikarinen & Reed [Page 18] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - Similarly, a QUIT message must be sent to the other connected servers - rest of the network on behalf of all clients behind that link. In - addition to this, all channel members of a channel which lost a - member due to the split must be sent a QUIT message. - - If a server connection is terminated prematurely (e.g. the server on - the other end of the link died), the server which detects - this disconnection is required to inform the rest of the network - that the connection has closed and fill in the comment field - with something appropriate. - - Numeric replies: - - ERR_NOPRIVILEGES ERR_NOSUCHSERVER - - Example: - - SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has - been terminated because of "Bad Link". - - :Trillian SQUIT cm22.eng.umd.edu :Server out of control - ; message from Trillian to disconnect - "cm22.eng.umd.edu" from the net - because "Server out of control". - -4.2 Channel operations - - This group of messages is concerned with manipulating channels, their - properties (channel modes), and their contents (typically clients). - In implementing these, a number of race conditions are inevitable - when clients at opposing ends of a network send commands which will - ultimately clash. It is also required that servers keep a nickname - history to ensure that wherever a <nick> parameter is given, the - server check its history in case it has recently been changed. - -4.2.1 Join message - - Command: JOIN - Parameters: <channel>{,<channel>} [<key>{,<key>}] - - The JOIN command is used by client to start listening a specific - channel. Whether or not a client is allowed to join a channel is - checked only by the server the client is connected to; all other - servers automatically add the user to the channel when it is received - from other servers. The conditions which affect this are as follows: - - 1. the user must be invited if the channel is invite-only; - - - - -Oikarinen & Reed [Page 19] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 2. the user's nick/username/hostname must not match any - active bans; - - 3. the correct key (password) must be given if it is set. - - These are discussed in more detail under the MODE command (see - section 4.2.3 for more details). - - Once a user has joined a channel, they receive notice about all - commands their server receives which affect the channel. This - includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The - JOIN command needs to be broadcast to all servers so that each server - knows where to find the users who are on the channel. This allows - optimal delivery of PRIVMSG/NOTICE messages to the channel. - - If a JOIN is successful, the user is then sent the channel's topic - (using RPL_TOPIC) and the list of users who are on the channel (using - RPL_NAMREPLY), which must include the user joining. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN - ERR_INVITEONLYCHAN ERR_BADCHANNELKEY - ERR_CHANNELISFULL ERR_BADCHANMASK - ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS - RPL_TOPIC - - Examples: - - JOIN #foobar ; join channel #foobar. - - JOIN &foo fubar ; join channel &foo using key "fubar". - - JOIN #foo,&bar fubar ; join channel #foo using key "fubar" - and &bar using no key. - - JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar". - and channel #bar using key "foobar". - - JOIN #foo,#bar ; join channels #foo and #bar. - - :WiZ JOIN #Twilight_zone ; JOIN message from WiZ - -4.2.2 Part message - - Command: PART - Parameters: <channel>{,<channel>} - - - - -Oikarinen & Reed [Page 20] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - The PART message causes the client sending the message to be removed - from the list of active users for all given channels listed in the - parameter string. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_NOTONCHANNEL - - Examples: - - PART #twilight_zone ; leave channel "#twilight_zone" - - PART #oz-ops,&group5 ; leave both channels "&group5" and - "#oz-ops". - -4.2.3 Mode message - - Command: MODE - - The MODE command is a dual-purpose command in IRC. It allows both - usernames and channels to have their mode changed. The rationale for - this choice is that one day nicknames will be obsolete and the - equivalent property will be the channel. - - When parsing MODE messages, it is recommended that the entire message - be parsed first and then the changes which resulted then passed on. - -4.2.3.1 Channel modes - - Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>] - [<ban mask>] - - The MODE command is provided so that channel operators may change the - characteristics of `their' channel. It is also required that servers - be able to change channel modes so that channel operators may be - created. - - The various modes available for channels are as follows: - - o - give/take channel operator privileges; - p - private channel flag; - s - secret channel flag; - i - invite-only channel flag; - t - topic settable by channel operator only flag; - n - no messages to channel from clients on the outside; - m - moderated channel; - l - set the user limit to channel; - - - -Oikarinen & Reed [Page 21] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - b - set a ban mask to keep users out; - v - give/take the ability to speak on a moderated channel; - k - set a channel key (password). - - When using the 'o' and 'b' options, a restriction on a total of three - per mode command has been imposed. That is, any combination of 'o' - and - -4.2.3.2 User modes - - Parameters: <nickname> {[+|-]|i|w|s|o} - - The user MODEs are typically changes which affect either how the - client is seen by others or what 'extra' messages the client is sent. - A user MODE command may only be accepted if both the sender of the - message and the nickname given as a parameter are both the same. - - The available modes are as follows: - - i - marks a users as invisible; - s - marks a user for receipt of server notices; - w - user receives wallops; - o - operator flag. - - Additional modes may be available later on. - - If a user attempts to make themselves an operator using the "+o" - flag, the attempt should be ignored. There is no restriction, - however, on anyone `deopping' themselves (using "-o"). Numeric - Replies: - - ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS - ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK - ERR_NOTONCHANNEL ERR_KEYSET - RPL_BANLIST RPL_ENDOFBANLIST - ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL - - ERR_USERSDONTMATCH RPL_UMODEIS - ERR_UMODEUNKNOWNFLAG - - Examples: - - Use of Channel Modes: - -MODE #Finnish +im ; Makes #Finnish channel moderated and - 'invite-only'. - -MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on - - - -Oikarinen & Reed [Page 22] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - channel #Finnish. - -MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. - -MODE #Fins -s ; Removes 'secret' flag from channel - #Fins. - -MODE #42 +k oulu ; Set the channel key to "oulu". - -MODE #eu-opers +l 10 ; Set the limit for the number of users - on channel to 10. - -MODE &oulu +b ; list ban masks set for channel. - -MODE &oulu +b *!*@* ; prevent all users from joining. - -MODE &oulu +b *!*@*.edu ; prevent any user from a hostname - matching *.edu from joining. - - Use of user Modes: - -:MODE WiZ -w ; turns reception of WALLOPS messages - off for WiZ. - -:Angel MODE Angel +i ; Message from Angel to make themselves - invisible. - -MODE WiZ -o ; WiZ 'deopping' (removing operator - status). The plain reverse of this - command ("MODE WiZ +o") must not be - allowed from users since would bypass - the OPER command. - -4.2.4 Topic message - - Command: TOPIC - Parameters: <channel> [<topic>] - - The TOPIC message is used to change or view the topic of a channel. - The topic for channel <channel> is returned if there is no <topic> - given. If the <topic> parameter is present, the topic for that - channel will be changed, if the channel modes permit this action. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL - RPL_NOTOPIC RPL_TOPIC - ERR_CHANOPRIVSNEEDED - - - -Oikarinen & Reed [Page 23] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - Examples: - - :Wiz TOPIC #test :New topic ;User Wiz setting the topic. - - TOPIC #test :another topic ;set the topic on #test to "another - topic". - - TOPIC #test ; check the topic for #test. - -4.2.5 Names message - - Command: NAMES - Parameters: [<channel>{,<channel>}] - - By using the NAMES command, a user can list all nicknames that are - visible to them on any channel that they can see. Channel names - which they can see are those which aren't private (+p) or secret (+s) - or those which they are actually on. The <channel> parameter - specifies which channel(s) to return information about if valid. - There is no error reply for bad channel names. - - If no <channel> parameter is given, a list of all channels and their - occupants is returned. At the end of this list, a list of users who - are visible but either not on any channel or not on a visible channel - are listed as being on `channel' "*". - - Numerics: - - RPL_NAMREPLY RPL_ENDOFNAMES - - Examples: - - NAMES #twilight_zone,#42 ; list visible users on #twilight_zone - and #42 if the channels are visible to - you. - - NAMES ; list all visible channels and users - -4.2.6 List message - - Command: LIST - Parameters: [<channel>{,<channel>} [<server>]] - - The list message is used to list channels and their topics. If the - <channel> parameter is used, only the status of that channel - is displayed. Private channels are listed (without their - topics) as channel "Prv" unless the client generating the query is - actually on that channel. Likewise, secret channels are not listed - - - -Oikarinen & Reed [Page 24] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - at all unless the client is a member of the channel in question. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_LISTSTART - RPL_LIST RPL_LISTEND - - Examples: - - LIST ; List all channels. - - LIST #twilight_zone,#42 ; List channels #twilight_zone and #42 - -4.2.7 Invite message - - Command: INVITE - Parameters: <nickname> <channel> - - The INVITE message is used to invite users to a channel. The - parameter <nickname> is the nickname of the person to be invited to - the target channel <channel>. There is no requirement that the - channel the target user is being invited to must exist or be a valid - channel. To invite a user to a channel which is invite only (MODE - +i), the client sending the invite must be recognised as being a - channel operator on the given channel. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHNICK - ERR_NOTONCHANNEL ERR_USERONCHANNEL - ERR_CHANOPRIVSNEEDED - RPL_INVITING RPL_AWAY - - Examples: - - :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel - #Dust - - INVITE Wiz #Twilight_Zone ; Command to invite WiZ to - #Twilight_zone - -4.2.8 Kick command - - Command: KICK - Parameters: <channel> <user> [<comment>] - - The KICK command can be used to forcibly remove a user from a - channel. It 'kicks them out' of the channel (forced PART). - - - -Oikarinen & Reed [Page 25] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - Only a channel operator may kick another user out of a channel. - Each server that receives a KICK message checks that it is valid - (ie the sender is actually a channel operator) before removing - the victim from the channel. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED - ERR_NOTONCHANNEL - - Examples: - -KICK &Melbourne Matthew ; Kick Matthew from &Melbourne - -KICK #Finnish John :Speaking English - ; Kick John from #Finnish using - "Speaking English" as the reason - (comment). - -:WiZ KICK #Finnish John ; KICK message from WiZ to remove John - from channel #Finnish - -NOTE: - It is possible to extend the KICK command parameters to the -following: - -<channel>{,<channel>} <user>{,<user>} [<comment>] - -4.3 Server queries and commands - - The server query group of commands has been designed to return - information about any server which is connected to the network. All - servers connected must respond to these queries and respond - correctly. Any invalid response (or lack thereof) must be considered - a sign of a broken server and it must be disconnected/disabled as - soon as possible until the situation is remedied. - - In these queries, where a parameter appears as "<server>", it will - usually mean it can be a nickname or a server or a wildcard name of - some sort. For each parameter, however, only one query and set of - replies is to be generated. - -4.3.1 Version message - - Command: VERSION - Parameters: [<server>] - - - - -Oikarinen & Reed [Page 26] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - The VERSION message is used to query the version of the server - program. An optional parameter <server> is used to query the version - of the server program which a client is not directly connected to. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_VERSION - - Examples: - - :Wiz VERSION *.se ; message from Wiz to check the version - of a server matching "*.se" - - VERSION tolsun.oulu.fi ; check the version of server - "tolsun.oulu.fi". - -4.3.2 Stats message - - Command: STATS - Parameters: [<query> [<server>]] - - The stats message is used to query statistics of certain server. If - <server> parameter is omitted, only the end of stats reply is sent - back. The implementation of this command is highly dependent on the - server which replies, although the server must be able to supply - information as described by the queries below (or similar). - - A query may be given by any single letter which is only checked by - the destination server (if given as the <server> parameter) and is - otherwise passed on by intermediate servers, ignored and unaltered. - The following queries are those found in the current IRC - implementation and provide a large portion of the setup information - for that server. Although these may not be supported in the same way - by other versions, all servers should be able to supply a valid reply - to a STATS query which is consistent with the reply formats currently - used and the purpose of the query. - - The currently supported queries are: - - c - returns a list of servers which the server may connect - to or allow connections from; - h - returns a list of servers which are either forced to be - treated as leaves or allowed to act as hubs; - i - returns a list of hosts which the server allows a client - to connect from; - k - returns a list of banned username/hostname combinations - for that server; - l - returns a list of the server's connections, showing how - - - -Oikarinen & Reed [Page 27] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - long each connection has been established and the traffic - over that connection in bytes and messages for each - direction; - m - returns a list of commands supported by the server and - the usage count for each if the usage count is non zero; - o - returns a list of hosts from which normal clients may - become operators; - y - show Y (Class) lines from server's configuration file; - u - returns a string showing how long the server has been up. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_STATSCLINE RPL_STATSNLINE - RPL_STATSILINE RPL_STATSKLINE - RPL_STATSQLINE RPL_STATSLLINE - RPL_STATSLINKINFO RPL_STATSUPTIME - RPL_STATSCOMMANDS RPL_STATSOLINE - RPL_STATSHLINE RPL_ENDOFSTATS - - Examples: - -STATS m ; check the command usage for the server - you are connected to - -:Wiz STATS c eff.org ; request by WiZ for C/N line - information from server eff.org - -4.3.3 Links message - - Command: LINKS - Parameters: [[<remote server>] <server mask>] - - With LINKS, a user can list all servers which are known by the server - answering the query. The returned list of servers must match the - mask, or if no mask is given, the full list is returned. - - If <remote server> is given in addition to <server mask>, the LINKS - command is forwarded to the first server found that matches that name - (if any), and that server is then required to answer the query. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_LINKS RPL_ENDOFLINKS - - Examples: - - - - -Oikarinen & Reed [Page 28] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -LINKS *.au ; list all servers which have a name - that matches *.au; - -:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first - server matching *.edu for a list of - servers matching *.bu.edu. - -4.3.4 Time message - - Command: TIME - Parameters: [<server>] - - The time message is used to query local time from the specified - server. If the server parameter is not given, the server handling the - command must reply to the query. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_TIME - - Examples: - - TIME tolsun.oulu.fi ; check the time on the server - "tolson.oulu.fi" - - Angel TIME *.au ; user angel checking the time on a - server matching "*.au" - -4.3.5 Connect message - - Command: CONNECT - Parameters: <target server> [<port> [<remote server>]] - - The CONNECT command can be used to force a server to try to establish - a new connection to another server immediately. CONNECT is a - privileged command and is to be available only to IRC Operators. If - a remote server is given then the CONNECT attempt is made by that - server to <target server> and <port>. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NOPRIVILEGES - ERR_NEEDMOREPARAMS - - Examples: - -CONNECT tolsun.oulu.fi ; Attempt to connect a server to - tolsun.oulu.fi - - - -Oikarinen & Reed [Page 29] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -:WiZ CONNECT eff.org 6667 csd.bu.edu - ; CONNECT attempt by WiZ to get servers - eff.org and csd.bu.edu connected on port - 6667. - -4.3.6 Trace message - - Command: TRACE - Parameters: [<server>] - - TRACE command is used to find the route to specific server. Each - server that processes this message must tell the sender about it by - sending a reply indicating it is a pass-through link, forming a chain - of replies similar to that gained from using "traceroute". After - sending this reply back, it must then send the TRACE message to the - next server until given server is reached. If the <server> parameter - is omitted, it is recommended that TRACE command send a message to - the sender telling which servers the current server has direct - connection to. - - If the destination given by "<server>" is an actual server, then the - destination server is required to report all servers and users which - are connected to it, although only operators are permitted to see - users present. If the destination given by <server> is a nickname, - they only a reply for that nickname is given. - - Numeric Replies: - - ERR_NOSUCHSERVER - - If the TRACE message is destined for another server, all intermediate - servers must return a RPL_TRACELINK reply to indicate that the TRACE - passed through it and where its going next. - - RPL_TRACELINK - A TRACE reply may be composed of any number of the following numeric - replies. - - RPL_TRACECONNECTING RPL_TRACEHANDSHAKE - RPL_TRACEUNKNOWN RPL_TRACEOPERATOR - RPL_TRACEUSER RPL_TRACESERVER - RPL_TRACESERVICE RPL_TRACENEWTYPE - RPL_TRACECLASS - - Examples: - -TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi - - - - -Oikarinen & Reed [Page 30] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust - -4.3.7 Admin command - - Command: ADMIN - Parameters: [<server>] - - The admin message is used to find the name of the administrator of - the given server, or current server if <server> parameter is omitted. - Each server must have the ability to forward ADMIN messages to other - servers. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_ADMINME RPL_ADMINLOC1 - RPL_ADMINLOC2 RPL_ADMINEMAIL - - Examples: - - ADMIN tolsun.oulu.fi ; request an ADMIN reply from - tolsun.oulu.fi - - :WiZ ADMIN *.edu ; ADMIN request from WiZ for first - server found to match *.edu. - -4.3.8 Info command - - Command: INFO - Parameters: [<server>] - - The INFO command is required to return information which describes - the server: its version, when it was compiled, the patchlevel, when - it was started, and any other miscellaneous information which may be - considered to be relevant. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_INFO RPL_ENDOFINFO - - Examples: - - INFO csd.bu.edu ; request an INFO reply from - csd.bu.edu - - :Avalon INFO *.fi ; INFO request from Avalon for first - server found to match *.fi. - - - -Oikarinen & Reed [Page 31] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - INFO Angel ; request info from the server that - Angel is connected to. - -4.4 Sending messages - - The main purpose of the IRC protocol is to provide a base for clients - to communicate with each other. PRIVMSG and NOTICE are the only - messages available which actually perform delivery of a text message - from one client to another - the rest just make it possible and try - to ensure it happens in a reliable and structured manner. - -4.4.1 Private messages - - Command: PRIVMSG - Parameters: <receiver>{,<receiver>} <text to be sent> - - PRIVMSG is used to send private messages between users. <receiver> - is the nickname of the receiver of the message. <receiver> can also - be a list of names or channels separated with commas. - - The <receiver> parameter may also me a host mask (#mask) or server - mask ($mask). In both cases the server will only send the PRIVMSG - to those who have a server or host matching the mask. The mask must - have at least 1 (one) "." in it and no wildcards following the - last ".". This requirement exists to prevent people sending messages - to "#*" or "$*", which would broadcast to all users; from - experience, this is abused more than used responsibly and properly. - Wildcards are the '*' and '?' characters. This extension to - the PRIVMSG command is only available to Operators. - - Numeric Replies: - - ERR_NORECIPIENT ERR_NOTEXTTOSEND - ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL - ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS - ERR_NOSUCHNICK - RPL_AWAY - - Examples: - -:Angel PRIVMSG Wiz :Hello are you receiving this message ? - ; Message from Angel to Wiz. - -PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ; - Message to Angel. - -PRIVMSG jto@tolsun.oulu.fi :Hello ! - ; Message to a client on server - - - -Oikarinen & Reed [Page 32] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - tolsun.oulu.fi with username of "jto". - -PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. - ; Message to everyone on a server which - has a name matching *.fi. - -PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions - ; Message to all users who come from a - host which has a name matching *.edu. - -4.4.2 Notice - - Command: NOTICE - Parameters: <nickname> <text> - - The NOTICE message is used similarly to PRIVMSG. The difference - between NOTICE and PRIVMSG is that automatic replies must never be - sent in response to a NOTICE message. This rule applies to servers - too - they must not send any error reply back to the client on - receipt of a notice. The object of this rule is to avoid loops - between a client automatically sending something in response to - something it received. This is typically used by automatons (clients - with either an AI or other interactive program controlling their - actions) which are always seen to be replying lest they end up in a - loop with another automaton. - - See PRIVMSG for more details on replies and examples. - -4.5 User based queries - - User queries are a group of commands which are primarily concerned - with finding details on a particular user or group users. When using - wildcards with any of these commands, if they match, they will only - return information on users who are 'visible' to you. The visibility - of a user is determined as a combination of the user's mode and the - common set of channels you are both on. - -4.5.1 Who query - - Command: WHO - Parameters: [<name> [<o>]] - - The WHO message is used by a client to generate a query which returns - a list of information which 'matches' the <name> parameter given by - the client. In the absence of the <name> parameter, all visible - (users who aren't invisible (user mode +i) and who don't have a - common channel with the requesting client) are listed. The same - result can be achieved by using a <name> of "0" or any wildcard which - - - -Oikarinen & Reed [Page 33] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - will end up matching every entry possible. - - The <name> passed to WHO is matched against users' host, server, real - name and nickname if the channel <name> cannot be found. - - If the "o" parameter is passed only operators are returned according - to the name mask supplied. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_WHOREPLY RPL_ENDOFWHO - - Examples: - - WHO *.fi ; List all users who match against - "*.fi". - - WHO jto* o ; List all users with a match against - "jto*" if they are an operator. - -4.5.2 Whois query - - Command: WHOIS - Parameters: [<server>] <nickmask>[,<nickmask>[,...]] - - This message is used to query information about particular user. The - server will answer this message with several numeric messages - indicating different statuses of each user which matches the nickmask - (if you are entitled to see them). If no wildcard is present in the - <nickmask>, any information about that nick which you are allowed to - see is presented. A comma (',') separated list of nicknames may be - given. - - The latter version sends the query to a specific server. It is - useful if you want to know how long the user in question has been - idle as only local server (ie. the server the user is directly - connected to) knows that information, while everything else is - globally known. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN - RPL_WHOISUSER RPL_WHOISCHANNELS - RPL_WHOISCHANNELS RPL_WHOISSERVER - RPL_AWAY RPL_WHOISOPERATOR - RPL_WHOISIDLE ERR_NOSUCHNICK - RPL_ENDOFWHOIS - - - -Oikarinen & Reed [Page 34] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - Examples: - - WHOIS wiz ; return available user information - about nick WiZ - - WHOIS eff.org trillian ; ask server eff.org for user - information about trillian - -4.5.3 Whowas - - Command: WHOWAS - Parameters: <nickname> [<count> [<server>]] - - Whowas asks for information about a nickname which no longer exists. - This may either be due to a nickname change or the user leaving IRC. - In response to this query, the server searches through its nickname - history, looking for any nicks which are lexically the same (no wild - card matching here). The history is searched backward, returning the - most recent entry first. If there are multiple entries, up to - <count> replies will be returned (or all of them if no <count> - parameter is given). If a non-positive number is passed as being - <count>, then a full search is done. - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK - RPL_WHOWASUSER RPL_WHOISSERVER - RPL_ENDOFWHOWAS - - Examples: - - WHOWAS Wiz ; return all information in the nick - history about nick "WiZ"; - - WHOWAS Mermaid 9 ; return at most, the 9 most recent - entries in the nick history for - "Mermaid"; - - WHOWAS Trillian 1 *.edu ; return the most recent history for - "Trillian" from the first server found - to match "*.edu". - -4.6 Miscellaneous messages - - Messages in this category do not fit into any of the above categories - but are nonetheless still a part of and required by the protocol. - - - - - -Oikarinen & Reed [Page 35] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -4.6.1 Kill message - - Command: KILL - Parameters: <nickname> <comment> - - The KILL message is used to cause a client-server connection to be - closed by the server which has the actual connection. KILL is used - by servers when they encounter a duplicate entry in the list of valid - nicknames and is used to remove both entries. It is also available - to operators. - - Clients which have automatic reconnect algorithms effectively make - this command useless since the disconnection is only brief. It does - however break the flow of data and can be used to stop large amounts - of being abused, any user may elect to receive KILL messages - generated for others to keep an 'eye' on would be trouble spots. - - In an arena where nicknames are required to be globally unique at all - times, KILL messages are sent whenever 'duplicates' are detected - (that is an attempt to register two users with the same nickname) in - the hope that both of them will disappear and only 1 reappear. - - The comment given must reflect the actual reason for the KILL. For - server-generated KILLs it usually is made up of details concerning - the origins of the two conflicting nicknames. For users it is left - up to them to provide an adequate reason to satisfy others who see - it. To prevent/discourage fake KILLs from being generated to hide - the identify of the KILLer, the comment also shows a 'kill-path' - which is updated by each server it passes through, each prepending - its name to the path. - - Numeric Replies: - - ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS - ERR_NOSUCHNICK ERR_CANTKILLSERVER - - - KILL David (csd.bu.edu <- tolsun.oulu.fi) - ; Nickname collision between csd.bu.edu - and tolson.oulu.fi - - - NOTE: - It is recommended that only Operators be allowed to kill other users - with KILL message. In an ideal world not even operators would need - to do this and it would be left to servers to deal with. - - - - - -Oikarinen & Reed [Page 36] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -4.6.2 Ping message - - Command: PING - Parameters: <server1> [<server2>] - - The PING message is used to test the presence of an active client at - the other end of the connection. A PING message is sent at regular - intervals if no other activity detected coming from a connection. If - a connection fails to respond to a PING command within a set amount - of time, that connection is closed. - - Any client which receives a PING message must respond to <server1> - (server which sent the PING message out) as quickly as possible with - an appropriate PONG message to indicate it is still there and alive. - Servers should not respond to PING commands but rely on PINGs from - the other end of the connection to indicate the connection is alive. - If the <server2> parameter is specified, the PING message gets - forwarded there. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Examples: - - PING tolsun.oulu.fi ; server sending a PING message to - another server to indicate it is still - alive. - - PING WiZ ; PING message being sent to nick WiZ - -4.6.3 Pong message - - Command: PONG - Parameters: <daemon> [<daemon2>] - - PONG message is a reply to ping message. If parameter <daemon2> is - given this message must be forwarded to given daemon. The <daemon> - parameter is the name of the daemon who has responded to PING message - and generated this message. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Examples: - - PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to - - - -Oikarinen & Reed [Page 37] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - tolsun.oulu.fi - -4.6.4 Error - - Command: ERROR - Parameters: <error message> - - The ERROR command is for use by servers when reporting a serious or - fatal error to its operators. It may also be sent from one server to - another but must not be accepted from any normal unknown clients. - - An ERROR message is for use for reporting errors which occur with a - server-to-server link only. An ERROR message is sent to the server - at the other end (which sends it to all of its connected operators) - and to all operators currently connected. It is not to be passed - onto any other servers by a server if it is received from a server. - - When a server sends a received ERROR message to its operators, the - message should be encapsulated inside a NOTICE message, indicating - that the client was not responsible for the error. - - Numerics: - - None. - - Examples: - - ERROR :Server *.fi already exists; ERROR message to the other server - which caused this error. - - NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists - ; Same ERROR message as above but sent - to user WiZ on the other server. - -5. OPTIONALS - - This section describes OPTIONAL messages. They are not required in a - working server implementation of the protocol described herein. In - the absence of the option, an error reply message must be generated - or an unknown command error. If the message is destined for another - server to answer then it must be passed on (elementary parsing - required) The allocated numerics for this are listed with the - messages below. - -5.1 Away - - Command: AWAY - Parameters: [message] - - - -Oikarinen & Reed [Page 38] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - With the AWAY message, clients can set an automatic reply string for - any PRIVMSG commands directed at them (not to a channel they are on). - The automatic reply is sent by the server to client sending the - PRIVMSG command. The only replying server is the one to which the - sending client is connected to. - - The AWAY message is used either with one parameter (to set an AWAY - message) or with no parameters (to remove the AWAY message). - - Numeric Replies: - - RPL_UNAWAY RPL_NOWAWAY - - Examples: - - AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch. - Back in 5". - - :WiZ AWAY ; unmark WiZ as being away. - - -5.2 Rehash message - - Command: REHASH - Parameters: None - - The rehash message can be used by the operator to force the server to - re-read and process its configuration file. - - Numeric Replies: - - RPL_REHASHING ERR_NOPRIVILEGES - -Examples: - -REHASH ; message from client with operator - status to server asking it to reread its - configuration file. - -5.3 Restart message - - Command: RESTART - Parameters: None - - The restart message can only be used by an operator to force a server - restart itself. This message is optional since it may be viewed as a - risk to allow arbitrary people to connect to a server as an operator - and execute this command, causing (at least) a disruption to service. - - - -Oikarinen & Reed [Page 39] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - The RESTART command must always be fully processed by the server to - which the sending client is connected and not be passed onto other - connected servers. - - Numeric Replies: - - ERR_NOPRIVILEGES - - Examples: - - RESTART ; no parameters required. - -5.4 Summon message - - Command: SUMMON - Parameters: <user> [<server>] - - The SUMMON command can be used to give users who are on a host - running an IRC server a message asking them to please join IRC. This - message is only sent if the target server (a) has SUMMON enabled, (b) - the user is logged in and (c) the server process can write to the - user's tty (or similar). - - If no <server> parameter is given it tries to summon <user> from the - server the client is connected to is assumed as the target. - - If summon is not enabled in a server, it must return the - ERR_SUMMONDISABLED numeric and pass the summon message onwards. - - Numeric Replies: - - ERR_NORECIPIENT ERR_FILEERROR - ERR_NOLOGIN ERR_NOSUCHSERVER - RPL_SUMMONING - - Examples: - - SUMMON jto ; summon user jto on the server's host - - SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a - server named "tolsun.oulu.fi" is - running. - - -5.5 Users - - Command: USERS - Parameters: [<server>] - - - -Oikarinen & Reed [Page 40] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - The USERS command returns a list of users logged into the server in a - similar format to who(1), rusers(1) and finger(1). Some people - may disable this command on their server for security related - reasons. If disabled, the correct numeric must be returned to - indicate this. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_FILEERROR - RPL_USERSSTART RPL_USERS - RPL_NOUSERS RPL_ENDOFUSERS - ERR_USERSDISABLED - - Disabled Reply: - - ERR_USERSDISABLED - - Examples: - -USERS eff.org ; request a list of users logged in on - server eff.org - -:John USERS tolsun.oulu.fi ; request from John for a list of users - logged in on server tolsun.oulu.fi - -5.6 Operwall message - - Command: WALLOPS - Parameters: Text to be sent to all operators currently online - - Sends a message to all operators currently online. After - implementing WALLOPS as a user command it was found that it was - often and commonly abused as a means of sending a message to a lot - of people (much similar to WALL). Due to this it is recommended - that the current implementation of WALLOPS be used as an - example by allowing and recognising only servers as the senders of - WALLOPS. - - Numeric Replies: - - ERR_NEEDMOREPARAMS - - Examples: - - :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS - message from csd.bu.edu announcing a - CONNECT message it received and acted - upon from Joshua. - - - -Oikarinen & Reed [Page 41] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -5.7 Userhost message - - Command: USERHOST - Parameters: <nickname>{<space><nickname>} - - The USERHOST command takes a list of up to 5 nicknames, each - separated by a space character and returns a list of information - about each nickname that it found. The returned list has each reply - separated by a space. - - Numeric Replies: - - RPL_USERHOST ERR_NEEDMOREPARAMS - - Examples: - - USERHOST Wiz Michael Marty p ;USERHOST request for information on - nicks "Wiz", "Michael", "Marty" and "p" - -5.8 Ison message - - Command: ISON - Parameters: <nickname>{<space><nickname>} - - The ISON command was implemented to provide a quick and efficient - means to get a response about whether a given nickname was currently - on IRC. ISON only takes one (1) parameter: a space-separated list of - nicks. For each nickname in the list that is present, the server - adds that to its reply string. Thus the reply string may return - empty (none of the given nicks are present), an exact copy of the - parameter string (all of them present) or as any other subset of the - set of nicks given in the parameter. The only limit on the number - of nicks that may be checked is that the combined length must not be - too large as to cause the server to chop it off so it fits in 512 - characters. - - ISON is only be processed by the server local to the client sending - the command and thus not passed onto other servers for further - processing. - - Numeric Replies: - - RPL_ISON ERR_NEEDMOREPARAMS - - Examples: - - ISON phone trillian WiZ jarlek Avalon Angel Monstah - ; Sample ISON request for 7 nicks. - - - -Oikarinen & Reed [Page 42] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -6. REPLIES - - The following is a list of numeric replies which are generated in - response to the commands given above. Each numeric is given with its - number, name and reply string. - -6.1 Error Replies. - - 401 ERR_NOSUCHNICK - "<nickname> :No such nick/channel" - - - Used to indicate the nickname parameter supplied to a - command is currently unused. - - 402 ERR_NOSUCHSERVER - "<server name> :No such server" - - - Used to indicate the server name given currently - doesn't exist. - - 403 ERR_NOSUCHCHANNEL - "<channel name> :No such channel" - - - Used to indicate the given channel name is invalid. - - 404 ERR_CANNOTSENDTOCHAN - "<channel name> :Cannot send to channel" - - - Sent to a user who is either (a) not on a channel - which is mode +n or (b) not a chanop (or mode +v) on - a channel which has mode +m set and is trying to send - a PRIVMSG message to that channel. - - 405 ERR_TOOMANYCHANNELS - "<channel name> :You have joined too many \ - channels" - - Sent to a user when they have joined the maximum - number of allowed channels and they try to join - another channel. - - 406 ERR_WASNOSUCHNICK - "<nickname> :There was no such nickname" - - - Returned by WHOWAS to indicate there is no history - information for that nickname. - - 407 ERR_TOOMANYTARGETS - "<target> :Duplicate recipients. No message \ - - - -Oikarinen & Reed [Page 43] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - delivered" - - - Returned to a client which is attempting to send a - PRIVMSG/NOTICE using the user@host destination format - and for a user@host which has several occurrences. - - 409 ERR_NOORIGIN - ":No origin specified" - - - PING or PONG message missing the originator parameter - which is required since these commands must work - without valid prefixes. - - 411 ERR_NORECIPIENT - ":No recipient given (<command>)" - 412 ERR_NOTEXTTOSEND - ":No text to send" - 413 ERR_NOTOPLEVEL - "<mask> :No toplevel domain specified" - 414 ERR_WILDTOPLEVEL - "<mask> :Wildcard in toplevel domain" - - - 412 - 414 are returned by PRIVMSG to indicate that - the message wasn't delivered for some reason. - ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that - are returned when an invalid use of - "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted. - - 421 ERR_UNKNOWNCOMMAND - "<command> :Unknown command" - - - Returned to a registered client to indicate that the - command sent is unknown by the server. - - 422 ERR_NOMOTD - ":MOTD File is missing" - - - Server's MOTD file could not be opened by the server. - - 423 ERR_NOADMININFO - "<server> :No administrative info available" - - - Returned by a server in response to an ADMIN message - when there is an error in finding the appropriate - information. - - 424 ERR_FILEERROR - ":File error doing <file op> on <file>" - - - -Oikarinen & Reed [Page 44] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - - Generic error message used to report a failed file - operation during the processing of a message. - - 431 ERR_NONICKNAMEGIVEN - ":No nickname given" - - - Returned when a nickname parameter expected for a - command and isn't found. - - 432 ERR_ERRONEUSNICKNAME - "<nick> :Erroneus nickname" - - - Returned after receiving a NICK message which contains - characters which do not fall in the defined set. See - section x.x.x for details on valid nicknames. - - 433 ERR_NICKNAMEINUSE - "<nick> :Nickname is already in use" - - - Returned when a NICK message is processed that results - in an attempt to change to a currently existing - nickname. - - 436 ERR_NICKCOLLISION - "<nick> :Nickname collision KILL" - - - Returned by a server to a client when it detects a - nickname collision (registered of a NICK that - already exists by another server). - - 441 ERR_USERNOTINCHANNEL - "<nick> <channel> :They aren't on that channel" - - - Returned by the server to indicate that the target - user of the command is not on the given channel. - - 442 ERR_NOTONCHANNEL - "<channel> :You're not on that channel" - - - Returned by the server whenever a client tries to - perform a channel effecting command for which the - client isn't a member. - - 443 ERR_USERONCHANNEL - "<user> <channel> :is already on channel" - - - Returned when a client tries to invite a user to a - channel they are already on. - - - -Oikarinen & Reed [Page 45] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 444 ERR_NOLOGIN - "<user> :User not logged in" - - - Returned by the summon after a SUMMON command for a - user was unable to be performed since they were not - logged in. - - 445 ERR_SUMMONDISABLED - ":SUMMON has been disabled" - - - Returned as a response to the SUMMON command. Must be - returned by any server which does not implement it. - - 446 ERR_USERSDISABLED - ":USERS has been disabled" - - - Returned as a response to the USERS command. Must be - returned by any server which does not implement it. - - 451 ERR_NOTREGISTERED - ":You have not registered" - - - Returned by the server to indicate that the client - must be registered before the server will allow it - to be parsed in detail. - - 461 ERR_NEEDMOREPARAMS - "<command> :Not enough parameters" - - - Returned by the server by numerous commands to - indicate to the client that it didn't supply enough - parameters. - - 462 ERR_ALREADYREGISTRED - ":You may not reregister" - - - Returned by the server to any link which tries to - change part of the registered details (such as - password or user details from second USER message). - - - 463 ERR_NOPERMFORHOST - ":Your host isn't among the privileged" - - - Returned to a client which attempts to register with - a server which does not been setup to allow - connections from the host the attempted connection - is tried. - - - -Oikarinen & Reed [Page 46] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 464 ERR_PASSWDMISMATCH - ":Password incorrect" - - - Returned to indicate a failed attempt at registering - a connection for which a password was required and - was either not given or incorrect. - - 465 ERR_YOUREBANNEDCREEP - ":You are banned from this server" - - - Returned after an attempt to connect and register - yourself with a server which has been setup to - explicitly deny connections to you. - - 467 ERR_KEYSET - "<channel> :Channel key already set" - 471 ERR_CHANNELISFULL - "<channel> :Cannot join channel (+l)" - 472 ERR_UNKNOWNMODE - "<char> :is unknown mode char to me" - 473 ERR_INVITEONLYCHAN - "<channel> :Cannot join channel (+i)" - 474 ERR_BANNEDFROMCHAN - "<channel> :Cannot join channel (+b)" - 475 ERR_BADCHANNELKEY - "<channel> :Cannot join channel (+k)" - 481 ERR_NOPRIVILEGES - ":Permission Denied- You're not an IRC operator" - - - Any command requiring operator privileges to operate - must return this error to indicate the attempt was - unsuccessful. - - 482 ERR_CHANOPRIVSNEEDED - "<channel> :You're not channel operator" - - - Any command requiring 'chanop' privileges (such as - MODE messages) must return this error if the client - making the attempt is not a chanop on the specified - channel. - - 483 ERR_CANTKILLSERVER - ":You cant kill a server!" - - - Any attempts to use the KILL command on a server - are to be refused and this error returned directly - to the client. - - - - -Oikarinen & Reed [Page 47] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 491 ERR_NOOPERHOST - ":No O-lines for your host" - - - If a client sends an OPER message and the server has - not been configured to allow connections from the - client's host as an operator, this error must be - returned. - - 501 ERR_UMODEUNKNOWNFLAG - ":Unknown MODE flag" - - - Returned by the server to indicate that a MODE - message was sent with a nickname parameter and that - the a mode flag sent was not recognized. - - 502 ERR_USERSDONTMATCH - ":Cant change mode for other users" - - - Error sent to any user trying to view or change the - user mode for a user other than themselves. - -6.2 Command responses. - - 300 RPL_NONE - Dummy reply number. Not used. - - 302 RPL_USERHOST - ":[<reply>{<space><reply>}]" - - - Reply format used by USERHOST to list replies to - the query list. The reply string is composed as - follows: - - <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname> - - The '*' indicates whether the client has registered - as an Operator. The '-' or '+' characters represent - whether the client has set an AWAY message or not - respectively. - - 303 RPL_ISON - ":[<nick> {<space><nick>}]" - - - Reply format used by ISON to list replies to the - query list. - - 301 RPL_AWAY - "<nick> :<away message>" - - - -Oikarinen & Reed [Page 48] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 305 RPL_UNAWAY - ":You are no longer marked as being away" - 306 RPL_NOWAWAY - ":You have been marked as being away" - - - These replies are used with the AWAY command (if - allowed). RPL_AWAY is sent to any client sending a - PRIVMSG to a client which is away. RPL_AWAY is only - sent by the server to which the client is connected. - Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the - client removes and sets an AWAY message. - - 311 RPL_WHOISUSER - "<nick> <user> <host> * :<real name>" - 312 RPL_WHOISSERVER - "<nick> <server> :<server info>" - 313 RPL_WHOISOPERATOR - "<nick> :is an IRC operator" - 317 RPL_WHOISIDLE - "<nick> <integer> :seconds idle" - 318 RPL_ENDOFWHOIS - "<nick> :End of /WHOIS list" - 319 RPL_WHOISCHANNELS - "<nick> :{[@|+]<channel><space>}" - - - Replies 311 - 313, 317 - 319 are all replies - generated in response to a WHOIS message. Given that - there are enough parameters present, the answering - server must either formulate a reply out of the above - numerics (if the query nick is found) or return an - error reply. The '*' in RPL_WHOISUSER is there as - the literal character and not as a wild card. For - each reply set, only RPL_WHOISCHANNELS may appear - more than once (for long lists of channel names). - The '@' and '+' characters next to the channel name - indicate whether a client is a channel operator or - has been granted permission to speak on a moderated - channel. The RPL_ENDOFWHOIS reply is used to mark - the end of processing a WHOIS message. - - 314 RPL_WHOWASUSER - "<nick> <user> <host> * :<real name>" - 369 RPL_ENDOFWHOWAS - "<nick> :End of WHOWAS" - - - When replying to a WHOWAS message, a server must use - the replies RPL_WHOWASUSER, RPL_WHOISSERVER or - ERR_WASNOSUCHNICK for each nickname in the presented - - - -Oikarinen & Reed [Page 49] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - list. At the end of all reply batches, there must - be RPL_ENDOFWHOWAS (even if there was only one reply - and it was an error). - - 321 RPL_LISTSTART - "Channel :Users Name" - 322 RPL_LIST - "<channel> <# visible> :<topic>" - 323 RPL_LISTEND - ":End of /LIST" - - - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark - the start, actual replies with data and end of the - server's response to a LIST command. If there are - no channels available to return, only the start - and end reply must be sent. - - 324 RPL_CHANNELMODEIS - "<channel> <mode> <mode params>" - - 331 RPL_NOTOPIC - "<channel> :No topic is set" - 332 RPL_TOPIC - "<channel> :<topic>" - - - When sending a TOPIC message to determine the - channel topic, one of two replies is sent. If - the topic is set, RPL_TOPIC is sent back else - RPL_NOTOPIC. - - 341 RPL_INVITING - "<channel> <nick>" - - - Returned by the server to indicate that the - attempted INVITE message was successful and is - being passed onto the end client. - - 342 RPL_SUMMONING - "<user> :Summoning user to IRC" - - - Returned by a server answering a SUMMON message to - indicate that it is summoning that user. - - 351 RPL_VERSION - "<version>.<debuglevel> <server> :<comments>" - - - Reply by the server showing its version details. - The <version> is the version of the software being - - - -Oikarinen & Reed [Page 50] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - used (including any patchlevel revisions) and the - <debuglevel> is used to indicate if the server is - running in "debug mode". - - The "comments" field may contain any comments about - the version or further version details. - - 352 RPL_WHOREPLY - "<channel> <user> <host> <server> <nick> \ - <H|G>[*][@|+] :<hopcount> <real name>" - 315 RPL_ENDOFWHO - "<name> :End of /WHO list" - - - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used - to answer a WHO message. The RPL_WHOREPLY is only - sent if there is an appropriate match to the WHO - query. If there is a list of parameters supplied - with a WHO message, a RPL_ENDOFWHO must be sent - after processing each list item with <name> being - the item. - - 353 RPL_NAMREPLY - "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]" - 366 RPL_ENDOFNAMES - "<channel> :End of /NAMES list" - - - To reply to a NAMES message, a reply pair consisting - of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the - server back to the client. If there is no channel - found as in the query, then only RPL_ENDOFNAMES is - returned. The exception to this is when a NAMES - message is sent with no parameters and all visible - channels and contents are sent back in a series of - RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark - the end. - - 364 RPL_LINKS - "<mask> <server> :<hopcount> <server info>" - 365 RPL_ENDOFLINKS - "<mask> :End of /LINKS list" - - - In replying to the LINKS message, a server must send - replies back using the RPL_LINKS numeric and mark the - end of the list using an RPL_ENDOFLINKS reply. - - 367 RPL_BANLIST - "<channel> <banid>" - 368 RPL_ENDOFBANLIST - - - -Oikarinen & Reed [Page 51] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - "<channel> :End of channel ban list" - - - When listing the active 'bans' for a given channel, - a server is required to send the list back using the - RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate - RPL_BANLIST is sent for each active banid. After the - banids have been listed (or if none present) a - RPL_ENDOFBANLIST must be sent. - - 371 RPL_INFO - ":<string>" - 374 RPL_ENDOFINFO - ":End of /INFO list" - - - A server responding to an INFO message is required to - send all its 'info' in a series of RPL_INFO messages - with a RPL_ENDOFINFO reply to indicate the end of the - replies. - - 375 RPL_MOTDSTART - ":- <server> Message of the day - " - 372 RPL_MOTD - ":- <text>" - 376 RPL_ENDOFMOTD - ":End of /MOTD command" - - - When responding to the MOTD message and the MOTD file - is found, the file is displayed line by line, with - each line no longer than 80 characters, using - RPL_MOTD format replies. These should be surrounded - by a RPL_MOTDSTART (before the RPL_MOTDs) and an - RPL_ENDOFMOTD (after). - - 381 RPL_YOUREOPER - ":You are now an IRC operator" - - - RPL_YOUREOPER is sent back to a client which has - just successfully issued an OPER message and gained - operator status. - - 382 RPL_REHASHING - "<config file> :Rehashing" - - - If the REHASH option is used and an operator sends - a REHASH message, an RPL_REHASHING is sent back to - the operator. - - 391 RPL_TIME - - - -Oikarinen & Reed [Page 52] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - "<server> :<string showing server's local time>" - - - When replying to the TIME message, a server must send - the reply using the RPL_TIME format above. The string - showing the time need only contain the correct day and - time there. There is no further requirement for the - time string. - - 392 RPL_USERSSTART - ":UserID Terminal Host" - 393 RPL_USERS - ":%-8s %-9s %-8s" - 394 RPL_ENDOFUSERS - ":End of users" - 395 RPL_NOUSERS - ":Nobody logged in" - - - If the USERS message is handled by a server, the - replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and - RPL_NOUSERS are used. RPL_USERSSTART must be sent - first, following by either a sequence of RPL_USERS - or a single RPL_NOUSER. Following this is - RPL_ENDOFUSERS. - - 200 RPL_TRACELINK - "Link <version & debug level> <destination> \ - <next server>" - 201 RPL_TRACECONNECTING - "Try. <class> <server>" - 202 RPL_TRACEHANDSHAKE - "H.S. <class> <server>" - 203 RPL_TRACEUNKNOWN - "???? <class> [<client IP address in dot form>]" - 204 RPL_TRACEOPERATOR - "Oper <class> <nick>" - 205 RPL_TRACEUSER - "User <class> <nick>" - 206 RPL_TRACESERVER - "Serv <class> <int>S <int>C <server> \ - <nick!user|*!*>@<host|server>" - 208 RPL_TRACENEWTYPE - "<newtype> 0 <client name>" - 261 RPL_TRACELOG - "File <logfile> <debug level>" - - - The RPL_TRACE* are all returned by the server in - response to the TRACE message. How many are - returned is dependent on the the TRACE message and - - - -Oikarinen & Reed [Page 53] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - whether it was sent by an operator or not. There - is no predefined order for which occurs first. - Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and - RPL_TRACEHANDSHAKE are all used for connections - which have not been fully established and are either - unknown, still attempting to connect or in the - process of completing the 'server handshake'. - RPL_TRACELINK is sent by any server which handles - a TRACE message and has to pass it on to another - server. The list of RPL_TRACELINKs sent in - response to a TRACE command traversing the IRC - network should reflect the actual connectivity of - the servers themselves along that path. - RPL_TRACENEWTYPE is to be used for any connection - which does not fit in the other categories but is - being displayed anyway. - - 211 RPL_STATSLINKINFO - "<linkname> <sendq> <sent messages> \ - <sent bytes> <received messages> \ - <received bytes> <time open>" - 212 RPL_STATSCOMMANDS - "<command> <count>" - 213 RPL_STATSCLINE - "C <host> * <name> <port> <class>" - 214 RPL_STATSNLINE - "N <host> * <name> <port> <class>" - 215 RPL_STATSILINE - "I <host> * <host> <port> <class>" - 216 RPL_STATSKLINE - "K <host> * <username> <port> <class>" - 218 RPL_STATSYLINE - "Y <class> <ping frequency> <connect \ - frequency> <max sendq>" - 219 RPL_ENDOFSTATS - "<stats letter> :End of /STATS report" - 241 RPL_STATSLLINE - "L <hostmask> * <servername> <maxdepth>" - 242 RPL_STATSUPTIME - ":Server Up %d days %d:%02d:%02d" - 243 RPL_STATSOLINE - "O <hostmask> * <name>" - 244 RPL_STATSHLINE - "H <hostmask> * <servername>" - - 221 RPL_UMODEIS - "<user mode string>" - - - - -Oikarinen & Reed [Page 54] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - - To answer a query about a client's own mode, - RPL_UMODEIS is sent back. - - 251 RPL_LUSERCLIENT - ":There are <integer> users and <integer> \ - invisible on <integer> servers" - 252 RPL_LUSEROP - "<integer> :operator(s) online" - 253 RPL_LUSERUNKNOWN - "<integer> :unknown connection(s)" - 254 RPL_LUSERCHANNELS - "<integer> :channels formed" - 255 RPL_LUSERME - ":I have <integer> clients and <integer> \ - servers" - - - In processing an LUSERS message, the server - sends a set of replies from RPL_LUSERCLIENT, - RPL_LUSEROP, RPL_USERUNKNOWN, - RPL_LUSERCHANNELS and RPL_LUSERME. When - replying, a server must send back - RPL_LUSERCLIENT and RPL_LUSERME. The other - replies are only sent back if a non-zero count - is found for them. - - 256 RPL_ADMINME - "<server> :Administrative info" - 257 RPL_ADMINLOC1 - ":<admin info>" - 258 RPL_ADMINLOC2 - ":<admin info>" - 259 RPL_ADMINEMAIL - ":<admin info>" - - - When replying to an ADMIN message, a server - is expected to use replies RLP_ADMINME - through to RPL_ADMINEMAIL and provide a text - message with each. For RPL_ADMINLOC1 a - description of what city, state and country - the server is in is expected, followed by - details of the university and department - (RPL_ADMINLOC2) and finally the administrative - contact for the server (an email address here - is required) in RPL_ADMINEMAIL. - - - - - - - -Oikarinen & Reed [Page 55] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -6.3 Reserved numerics. - - These numerics are not described above since they fall into one of - the following categories: - - 1. no longer in use; - - 2. reserved for future planned use; - - 3. in current use but are part of a non-generic 'feature' of - the current IRC server. - - 209 RPL_TRACECLASS 217 RPL_STATSQLINE - 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES - 233 RPL_SERVICE 234 RPL_SERVLIST - 235 RPL_SERVLISTEND - 316 RPL_WHOISCHANOP 361 RPL_KILLDONE - 362 RPL_CLOSING 363 RPL_CLOSEEND - 373 RPL_INFOSTART 384 RPL_MYPORTIS - 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK - 492 ERR_NOSERVICEHOST - -7. Client and server authentication - - Clients and servers are both subject to the same level of - authentication. For both, an IP number to hostname lookup (and - reverse check on this) is performed for all connections made to the - server. Both connections are then subject to a password check (if - there is a password set for that connection). These checks are - possible on all connections although the password check is only - commonly used with servers. - - An additional check that is becoming of more and more common is that - of the username responsible for making the connection. Finding the - username of the other end of the connection typically involves - connecting to an authentication server such as IDENT as described in - RFC 1413. - - Given that without passwords it is not easy to reliably determine who - is on the other end of a network connection, use of passwords is - strongly recommended on inter-server connections in addition to any - other measures such as using an ident server. - -8. Current implementations - - The only current implementation of this protocol is the IRC server, - version 2.8. Earlier versions may implement some or all of the - commands described by this document with NOTICE messages replacing - - - -Oikarinen & Reed [Page 56] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - many of the numeric replies. Unfortunately, due to backward - compatibility requirements, the implementation of some parts of this - document varies with what is laid out. On notable difference is: - - * recognition that any LF or CR anywhere in a message marks the - end of that message (instead of requiring CR-LF); - - The rest of this section deals with issues that are mostly of - importance to those who wish to implement a server but some parts - also apply directly to clients as well. - -8.1 Network protocol: TCP - why it is best used here. - - IRC has been implemented on top of TCP since TCP supplies a reliable - network protocol which is well suited to this scale of conferencing. - The use of multicast IP is an alternative, but it is not widely - available or supported at the present time. - -8.1.1 Support of Unix sockets - - Given that Unix domain sockets allow listen/connect operations, the - current implementation can be configured to listen and accept both - client and server connections on a Unix domain socket. These are - recognized as sockets where the hostname starts with a '/'. - - When providing any information about the connections on a Unix domain - socket, the server is required to supplant the actual hostname in - place of the pathname unless the actual socket name is being asked - for. - -8.2 Command Parsing - - To provide useful 'non-buffered' network IO for clients and servers, - each connection is given its own private 'input buffer' in which the - results of the most recent read and parsing are kept. A buffer size - of 512 bytes is used so as to hold 1 full message, although, this - will usually hold several commands. The private buffer is parsed - after every read operation for valid messages. When dealing with - multiple messages from one client in the buffer, care should be taken - in case one happens to cause the client to be 'removed'. - -8.3 Message delivery - - It is common to find network links saturated or hosts to which you - are sending data unable to send data. Although Unix typically - handles this through the TCP window and internal buffers, the server - often has large amounts of data to send (especially when a new - server-server link forms) and the small buffers provided in the - - - -Oikarinen & Reed [Page 57] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - kernel are not enough for the outgoing queue. To alleviate this - problem, a "send queue" is used as a FIFO queue for data to be sent. - A typical "send queue" may grow to 200 Kbytes on a large IRC network - with a slow network connection when a new server connects. - - When polling its connections, a server will first read and parse all - incoming data, queuing any data to be sent out. When all available - input is processed, the queued data is sent. This reduces the number - of write() system calls and helps TCP make bigger packets. - -8.4 Connection 'Liveness' - - To detect when a connection has died or become unresponsive, the - server must ping each of its connections that it doesn't get a - response from in a given amount of time. - - If a connection doesn't respond in time, its connection is closed - using the appropriate procedures. A connection is also dropped if - its sendq grows beyond the maximum allowed, because it is better to - close a slow connection than have a server process block. - -8.5 Establishing a server to client connection - - Upon connecting to an IRC server, a client is sent the MOTD (if - present) as well as the current user/server count (as per the LUSER - command). The server is also required to give an unambiguous message - to the client which states its name and version as well as any other - introductory messages which may be deemed appropriate. - - After dealing with this, the server must then send out the new user's - nickname and other information as supplied by itself (USER command) - and as the server could discover (from DNS/authentication servers). - The server must send this information out with NICK first followed by - USER. - -8.6 Establishing a server-server connection. - - The process of establishing of a server-to-server connection is - fraught with danger since there are many possible areas where - problems can occur - the least of which are race conditions. - - After a server has received a connection following by a PASS/SERVER - pair which were recognised as being valid, the server should then - reply with its own PASS/SERVER information for that connection as - well as all of the other state information it knows about as - described below. - - When the initiating server receives a PASS/SERVER pair, it too then - - - -Oikarinen & Reed [Page 58] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - checks that the server responding is authenticated properly before - accepting the connection to be that server. - -8.6.1 Server exchange of state information when connecting - - The order of state information being exchanged between servers is - essential. The required order is as follows: - - * all known other servers; - - * all known user information; - - * all known channel information. - - Information regarding servers is sent via extra SERVER messages, user - information with NICK/USER/MODE/JOIN messages and channels with MODE - messages. - - NOTE: channel topics are *NOT* exchanged here because the TOPIC - command overwrites any old topic information, so at best, the two - sides of the connection would exchange topics. - - By passing the state information about servers first, any collisions - with servers that already exist occur before nickname collisions due - to a second server introducing a particular nickname. Due to the IRC - network only being able to exist as an acyclic graph, it may be - possible that the network has already reconnected in another - location, the place where the collision occurs indicating where the - net needs to split. - -8.7 Terminating server-client connections - - When a client connection closes, a QUIT message is generated on - behalf of the client by the server to which the client connected. No - other message is to be generated or used. - -8.8 Terminating server-server connections - - If a server-server connection is closed, either via a remotely - generated SQUIT or 'natural' causes, the rest of the connected IRC - network must have its information updated with by the server which - detected the closure. The server then sends a list of SQUITs (one - for each server behind that connection) and a list of QUITs (again, - one for each client behind that connection). - - - - - - - -Oikarinen & Reed [Page 59] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -8.9 Tracking nickname changes - - All IRC servers are required to keep a history of recent nickname - changes. This is required to allow the server to have a chance of - keeping in touch of things when nick-change race conditions occur - with commands which manipulate them. Commands which must trace nick - changes are: - - * KILL (the nick being killed) - - * MODE (+/- o,v) - - * KICK (the nick being kicked) - - No other commands are to have nick changes checked for. - - In the above cases, the server is required to first check for the - existence of the nickname, then check its history to see who that - nick currently belongs to (if anyone!). This reduces the chances of - race conditions but they can still occur with the server ending up - affecting the wrong client. When performing a change trace for an - above command it is recommended that a time range be given and - entries which are too old ignored. - - For a reasonable history, a server should be able to keep previous - nickname for every client it knows about if they all decided to - change. This size is limited by other factors (such as memory, etc). - -8.10 Flood control of clients - - With a large network of interconnected IRC servers, it is quite easy - for any single client attached to the network to supply a continuous - stream of messages that result in not only flooding the network, but - also degrading the level of service provided to others. Rather than - require every 'victim' to be provide their own protection, flood - protection was written into the server and is applied to all clients - except services. The current algorithm is as follows: - - * check to see if client's `message timer' is less than - current time (set to be equal if it is); - - * read any data present from the client; - - * while the timer is less than ten seconds ahead of the current - time, parse any present messages and penalize the client by - 2 seconds for each message; - - which in essence means that the client may send 1 message every 2 - - - -Oikarinen & Reed [Page 60] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - seconds without being adversely affected. - -8.11 Non-blocking lookups - - In a real-time environment, it is essential that a server process do - as little waiting as possible so that all the clients are serviced - fairly. Obviously this requires non-blocking IO on all network - read/write operations. For normal server connections, this was not - difficult, but there are other support operations that may cause the - server to block (such as disk reads). Where possible, such activity - should be performed with a short timeout. - -8.11.1 Hostname (DNS) lookups - - Using the standard resolver libraries from Berkeley and others has - meant large delays in some cases where replies have timed out. To - avoid this, a separate set of DNS routines were written which were - setup for non-blocking IO operations and then polled from within the - main server IO loop. - -8.11.2 Username (Ident) lookups - - Although there are numerous ident libraries for use and inclusion - into other programs, these caused problems since they operated in a - synchronous manner and resulted in frequent delays. Again the - solution was to write a set of routines which would cooperate with - the rest of the server and work using non-blocking IO. - -8.12 Configuration File - - To provide a flexible way of setting up and running the server, it is - recommended that a configuration file be used which contains - instructions to the server on the following: - - * which hosts to accept client connections from; - - * which hosts to allow to connect as servers; - - * which hosts to connect to (both actively and - passively); - - * information about where the server is (university, - city/state, company are examples of this); - - * who is responsible for the server and an email address - at which they can be contacted; - - * hostnames and passwords for clients which wish to be given - - - -Oikarinen & Reed [Page 61] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - access to restricted operator commands. - - In specifying hostnames, both domain names and use of the 'dot' - notation (127.0.0.1) should both be accepted. It must be possible to - specify the password to be used/accepted for all outgoing and - incoming connections (although the only outgoing connections are - those to other servers). - - The above list is the minimum requirement for any server which wishes - to make a connection with another server. Other items which may be - of use are: - - * specifying which servers other server may introduce; - - * how deep a server branch is allowed to become; - - * hours during which clients may connect. - -8.12.1 Allowing clients to connect - - A server should use some sort of 'access control list' (either in the - configuration file or elsewhere) that is read at startup and used to - decide what hosts clients may use to connect to it. - - Both 'deny' and 'allow' should be implemented to provide the required - flexibility for host access control. - -8.12.2 Operators - - The granting of operator privileges to a disruptive person can have - dire consequences for the well-being of the IRC net in general due to - the powers given to them. Thus, the acquisition of such powers - should not be very easy. The current setup requires two 'passwords' - to be used although one of them is usually easy guessed. Storage of - oper passwords in configuration files is preferable to hard coding - them in and should be stored in a crypted format (ie using crypt(3) - from Unix) to prevent easy theft. - -8.12.3 Allowing servers to connect - - The interconnection of server is not a trivial matter: a bad - connection can have a large impact on the usefulness of IRC. Thus, - each server should have a list of servers to which it may connect and - which servers may connect to it. Under no circumstances should a - server allow an arbitrary host to connect as a server. In addition - to which servers may and may not connect, the configuration file - should also store the password and other characteristics of that - link. - - - -Oikarinen & Reed [Page 62] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -8.12.4 Administrivia - - To provide accurate and valid replies to the ADMIN command (see - section 4.3.7), the server should find the relevant details in the - configuration. - -8.13 Channel membership - - The current server allows any registered local user to join upto 10 - different channels. There is no limit imposed on non-local users so - that the server remains (reasonably) consistant with all others on a - channel membership basis - -9. Current problems - - There are a number of recognized problems with this protocol, all of - which hope to be solved sometime in the near future during its - rewrite. Currently, work is underway to find working solutions to - these problems. - -9.1 Scalability - - It is widely recognized that this protocol does not scale - sufficiently well when used in a large arena. The main problem comes - from the requirement that all servers know about all other servers - and users and that information regarding them be updated as soon as - it changes. It is also desirable to keep the number of servers low - so that the path length between any two points is kept minimal and - the spanning tree as strongly branched as possible. - -9.2 Labels - - The current IRC protocol has 3 types of labels: the nickname, the - channel name and the server name. Each of the three types has its - own domain and no duplicates are allowed inside that domain. - Currently, it is possible for users to pick the label for any of the - three, resulting in collisions. It is widely recognized that this - needs reworking, with a plan for unique names for channels and nicks - that don't collide being desirable as well as a solution allowing a - cyclic tree. - -9.2.1 Nicknames - - The idea of the nickname on IRC is very convenient for users to use - when talking to each other outside of a channel, but there is only a - finite nickname space and being what they are, its not uncommon for - several people to want to use the same nick. If a nickname is chosen - by two people using this protocol, either one will not succeed or - - - -Oikarinen & Reed [Page 63] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - both will removed by use of KILL (4.6.1). - -9.2.2 Channels - - The current channel layout requires that all servers know about all - channels, their inhabitants and properties. Besides not scaling - well, the issue of privacy is also a concern. A collision of - channels is treated as an inclusive event (both people who create the - new channel are considered to be members of it) rather than an - exclusive one such as used to solve nickname collisions. - -9.2.3 Servers - - Although the number of servers is usually small relative to the - number of users and channels, they two currently required to be known - globally, either each one separately or hidden behind a mask. - -9.3 Algorithms - - In some places within the server code, it has not been possible to - avoid N^2 algorithms such as checking the channel list of a set - of clients. - - In current server versions, there are no database consistency checks, - each server assumes that a neighbouring server is correct. This - opens the door to large problems if a connecting server is buggy or - otherwise tries to introduce contradictions to the existing net. - - Currently, because of the lack of unique internal and global labels, - there are a multitude of race conditions that exist. These race - conditions generally arise from the problem of it taking time for - messages to traverse and effect the IRC network. Even by changing to - unique labels, there are problems with channel-related commands being - disrupted. - -10. Current support and availability - - Mailing lists for IRC related discussion: - Future protocol: ircd-three-request@eff.org - General discussion: operlist-request@eff.org - - Software implemenations - cs.bu.edu:/irc - nic.funet.fi:/pub/irc - coombs.anu.edu.au:/pub/irc - - Newsgroup: alt.irc - - - - -Oikarinen & Reed [Page 64] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -Security Considerations - - Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and - 7. - -12. Authors' Addresses - - Jarkko Oikarinen - Tuirantie 17 as 9 - 90500 OULU - FINLAND - - Email: jto@tolsun.oulu.fi - - - Darren Reed - 4 Pateman Street - Watsonia, Victoria 3087 - Australia - - Email: avalon@coombs.anu.edu.au - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Oikarinen & Reed [Page 65] -
\ No newline at end of file diff --git a/docs/sql/sqloper.mysql.sql b/docs/sql/sqloper.mysql.sql new file mode 100644 index 000000000..a8a2b7e1d --- /dev/null +++ b/docs/sql/sqloper.mysql.sql @@ -0,0 +1,12 @@ +CREATE TABLE ircd_opers ( + id bigint(20) NOT NULL auto_increment, + name text NOT NULL, + password text NOT NULL, + hash text, + host text NOT NULL, + type text NOT NULL, + fingerprint text, + autologin tinyint(1) NOT NULL DEFAULT 0, + active tinyint(1) NOT NULL DEFAULT 1, + PRIMARY KEY (id) +) ENGINE=MyISAM; diff --git a/docs/sql/sqloper.pgsql.sql b/docs/sql/sqloper.pgsql.sql new file mode 100644 index 000000000..954bc84fa --- /dev/null +++ b/docs/sql/sqloper.pgsql.sql @@ -0,0 +1,13 @@ +CREATE TABLE ircd_opers ( + "id" serial NOT NULL, + "name" text NOT NULL, + "password" text NOT NULL, + "hash" text, + "host" text NOT NULL, + "type" text NOT NULL, + "fingerprint" text, + "autologin" smallint NOT NULL DEFAULT 0, + "active" smallint NOT NULL DEFAULT 1 +); +ALTER TABLE ONLY ircd_opers + ADD CONSTRAINT ircd_opers_pkey PRIMARY KEY (id); diff --git a/docs/sql/sqloper.sqlite3.sql b/docs/sql/sqloper.sqlite3.sql new file mode 100644 index 000000000..6aec5a118 --- /dev/null +++ b/docs/sql/sqloper.sqlite3.sql @@ -0,0 +1,10 @@ +CREATE TABLE ircd_opers ( +id integer primary key, +name text NOT NULL, +password text NOT NULL, +hash text, +host text NOT NULL, +type text NOT NULL, +fingerprint text, +autologin integer NOT NULL DEFAULT 0, +active integer NOT NULL DEFAULT 1); |