M:server name:[bind address]:description
the name the server will claim to be to clients and to other servers, and usually is chosen to be something that resolves to the server's IP address. The text description is sent out in LINKS and when clients connect.
The optional bind address is which interface to bind to/send from when making outgoing connections.
This line should contain exactly three text fields, which can contain any arbitrary text. It is returned by the ADMIN command. It is suggested that it contains the name of the organisation running the IRC network, and a means to contact the network/server administrator (probably email).
Y:class:ping frequency:connect frequency:maximum links:sendq size
Y:lines define classes of connections for later use. The class number is used to connect them to other lines in the config file.
All fields are integers. The class field must be a value greater than zero, and must uniquely identify the connection class within the config. The rate at which things in this connection are pinged to see if their connection is still alive is controlled by the second field.
connect frequency for a server connection is the time in seconds this server will wait before attempting to make a connection (if autoconnect is allowed). If the connect frequency is 0 then only one connection will be attempted, at server startup. For a client class, this is the number of connections which will be allowed from the same originating IP address, or 0 for no limit.
sendq is the size in bytes of the queue which holds messages awaiting delivery to the target. For clients a few hundred thousand bytes is adequete; for servers at least 4Mb is recommended.
When picking a server to connect to, the ircd will try higher connection classes first, unless they are waiting for the "connect frequency" time to elapse before trying again.
I:IP mask:[password]:domain mask::connection class
I:lines allow client connections to the server, and control/set various flags about those connections.
If the IP mask is a CIDR mask, then the I:line matches anything coming from the range it indicates and the domain mask is matched against the nick of the connecting user, otherwise the domain mask contains a nick@host mask which is matched against the resolved hostname. If the domain mask is of the nick@host form, then the IP mask field contains instead the hostname to spoof to. This will be used if the = flag is specified.
If a password is given, then it must be used at connection time or the connection will be dropped, without checking any other I:lines.
The domain mask matches may (and usually does) contain wildcards. The domain mask may have several prefixes which affect the client connection. They are:
- Don't prefix a ~ to the username if the ident check fails.
+ Require ident check to succeed to connect.
! Only allow n connections (as defined in the Y:line) per IP address, not per hostmask.
^ Exempt from K/G lines. Partially exempt from D lines.
& Will not be killed by the bot check.
> Exempt from connection limits.
_ Exempt from G:lines.
= The IP mask field contains the hostname to spoof to.
/ Spoof the hostname automatically on connect.
Note that you cannot specify an IP address range *and* a domain mask at the same time. The IP mask will be parsed as the hostname to spoof to if the = flag is given, otherwise it will be ignored when using a domain mask.
If no = flag is given, then SPOOF_LIMIT_HOST in config.h will be used as the hostname to spoof to, if any.
O:hostname:password:nick:allowed umodes:connection class:default umodes
O:lines define who may use the OPER command to gain extended privileges.
The hostname may be a mask, and must match for an OPER command to work. The password may be encrypted as an MD5 hash, depending on compile-time configuration.
Dancer uses a very different system than most ircds. Rather than a capabilities field, it has a field which contains the list of umodes an oper may have. This allows for very fine control of what a person can and can't do.
When an OPER command succeeds, the user will be moved into the connection class specified in the O:line, and they will have all the umodes in the "default umodes" field set.
These always appear in matched pairs, and define what servers may connect or be connected to.
The hostname must match that of the remote server. The cleartext password in the C:line on one side of a link must match the (possibly hashed) password in the N:line on the other side. The name must match that given in the first field of the M:line on the remote server.
If a port is given in the C:line, a connection will be automatically attempted according to the connection class, on startup, and at regular intervals when a server is not connected.
In order for a server to be listed in the LINKS response, it must have an N:line (it need not have a C:line, nor need there be a valid password in the N:line). If the last (6th field) is present (ie: trailing colon after connection class), then the server will not be listed in LINKS. This allows you to have locally connected servers which are not listed, and listed servers which are not locally connected.
A K:line bans all users matching a given user and host from connecting to the server. Both the hostname and the username may contain wildcards.
The time ranges field is deprecated. It allows a range of times in which the K:line is in effect.
D:lines (dumps) drop all connections from the given address or CIDR mask. This is notably less expensive on the server than a K:line, so should be used by preference to deal with persistant attackers. Note that D:lines must be individually placed on each server, and should not be used lightly.
Q:lines (quarantines) prevent the given nick or anything matching the given mask from being used, unless the user is connected matching the given user@host mask.
X:lines match the mask against the realname field for the a client attempting to connect. If kill is non-zero (true) then the client will be dropped as if they were K:lined, instead of being allowed to connect, otherwise a warning notice will be broadcast to the opers with +r set.
H:domain mask::server name
An H:line allows a remote server matching the given masks to introduce other servers.
P::[bind address]::port number
A P:line specifies what ports a server should listen on.