How the K-line got its name: history of IRC daemon configuration

Most people who use IRC know that to K-line someone means to ban them from an IRC server. Since the origins of this terminology are now rather obscure, I thought it might be beneficial to explain the history of this terminology and how it came to be.

Many people might not realise that most IRC daemons that exist today are direct code (“blood”) descendants of the original IRC daemon, ircd, version 2.8. This is unlike for example HTTP, where there are many different HTTP servers of equal maturity but sharing no code relation. ircd might be one the most forked pieces of open source software there is, if you define a “fork” as only including actively maintained variants. The history of ircd forks runs in tandem with the history of IRC networks, with different networks taking the software in their own direction as they liked.

There are some IRC daemons with no code relation to ircd, such as InspIRCD. Most major networks, however, use IRC daemons that can trace their lineage back to ircd 2.8; this includes Liberachat (Solanum, a fork of Charybdis, itself a descendent of ratbox, itself a fork of hybrid, which comes from ircd 2.8), until recently Freenode (ircd-seven, a Freenode-specific fork of Charybdis), OFTC (hybrid), EFnet (the modern descendant of the original IRC network, using ratbox), Undernet (ircu, which comes ultimately from ircd 2.7), Quakenet (asuka, based on ircu), DALnet (Bahamut, a fork of Dreamforge which descends from ircd 2.8.21), Rizon (plexus, a fork of hybrid), as well as IRCnet (which is a story unto itself).

The following diagram from Wikipedia shows the “genealogical” relations of the various IRC daemons:

[Map of ircd implementations]
Diagram of IRC daemon implementations and their genealogical relations

In any case: it used to be the case that ircd was configured with configuration file that would be considered rather cryptic by modern standards. The configuration file would contain a number of lines, and each line would begin with a single letter designating the type of configuration it contained:


In short, banning someone from a server was facilitated by adding a K: line to the configuration file; the K stands for “kill”. This would look like this:


For example, to ban anyone with a hostmask matching *


Note that K-lines only ban someone from a specific server in a network, not the entire network. A G-line (presumably standing for global ban) is a newer invention which is propagated across an entire network, banning the matching host or username from the entire network. Although since K-lining has become common IRC terminology and G-lining is a less known term, it's probably common to also refer to global network bans as “K-lines”. The “kill line” terminology could conceivably originate from Usenet's “kill file” terminology.

A non-exhaustive list of configuration lines which might be placed in classic ircd configuration files is below. This list is based on UnrealIRCd 3.1.

`M:hostname:bind-IP:server-description:bind-port:server-ID`. Required, and sets the basic information about the server.
`A:Text:Text:Text`. This is used to set the output of the `/ADMIN` command, and is intended to list contact details for server admins.
`Y:class-number:ping-frequency:connect-frequency:max-connections:sendq`. Defines a connection class. Different clients and peering servers can be sorted into different connection classes, with different ping frequencies, maximum numbers of connections, and sendq buffer sizes in each class.

`I:user@IP-mask:optional-password:user@domain-mask::connection-class`. Client authorization lines (invite lines?). Connecting clients have to match at least one of these if they are to be allowed to connect; if you configure no I-lines, nobody can connect to your server. The I-line allows clients to be assigned to connection classes, as defined by a Y-line above, based on their IP or hostname, username, or a server password.

Today, “having an I-line” is used to refer to the idea of having some kind of special access that bypasses normal connection limitations. For example, IRC servers are usually configured using connection classes to limit the number of simultaneous connections which can be made from one IP address. However, services such as Matrix bridges need to be able to make one connection for each of the very large number of Matrix users they connect to an IRC network, so they are generally authorized to make a very large number of connections from one IP by virtue of being given an I-line.

`O:user@hostname:password:nickname:access-flags:class`. Operator line, granting IRC operator status to clients of some description. Being an IRC operator is still sometimes referred to as “having an O-line”.
`U:services-hostname:*:*`. The U-line is used to specify the hostname of the IRC services server. IRC services packages generally connect to IRC daemons as another server via a server-to-server (S2S) link, speaking the IRC daemon's S2S protocol. The U-line grants greater privileges to the specific server identified by its hostname, allowing it to override things ordinary servers generally aren't allowed to, but which services need to be able to do.
`X:die-password:restart-password`. The X-line specifies the passwords which must be provided to the `/DIE` and `/RESTART` commands by an IRC operator in order to shut down or restart the IRC daemon, respectively.
C and N-line
`C:remote-server-hostname:password:remote-server-name:port:connection-class:options`; `N:remote-server-hostname:password:remote-server-name:host-mask:connection-class`. These lines are used to allow servers to link to one another, and are always used together. The C-line defines a server which the server being configured should try to connect to; the N-line defines a server which the server being configured should allow connections from. It was always recommended to use different passwords for each, so that the password for server A to initiate a connection to server B is different to the password for server B to connect to server A.
`K:hostmask:reason:username`. Server-local ban. As discussed above.
Similar to a K-line, but global to a network, banning matching clients from the entire network.
`E:hostmask:reason:usermask`. Ban exemption; if this matches a client, they can connect even if they would be matched by a K-line.
`Q::reason:nickname`. Used to reserve nicknames so they cannot be taken by ordinary users. Usually this is used to reserve nicknames like `NickServ`, so they cannot be squatted on if network services accidentally go down.
`T:host:motd-file:rules-file`. Allows different MOTD files to be served to connecting clients based on their hostmask. Can be used to serve different language MOTDs to users if they e.g. have a hostname ending in `.fr`.
`Z:IP-mask:reason:*`. This configures a ban similar to a K-line, but it is based on IP addresses rather than hostnames and is applied earlier in the connection process, before registration or any need to do a reverse DNS lookup for a connecting IP address.
`P:bind-IP:flags:*:port`. Used to configure the IRC daemon to listen on additional ports. Flags can specify things like SSL, server use only, or client use only.

The list above is based on UnrealIRCd 3.1, which was the last version of UnrealIRCd to use this old configuration file format. UnrealIRCd 3.2, and indeed all modern ircd forks that I know of, now use more modern and less cryptic configuration file formats. For example, the modern equivalent of an I: line might now look like this:

// Equivalent to I:*@*::*@*::1
allow {
  ip             *@*;
  hostname       *@*;
  class           clients;

However, while they may not literally exist anymore, the terms K-line, G-line, Z-line, O-line and I-line are all still used on IRC today to refer to commonly understood concepts. Moreover, K-lines and G-lines are nowadays less likely to be configured directly in configuration file, in favour of being stored in separate ban databases or managed by IRC services.