Any client can see all the KILLs occuring on the network by joining the &KILLS channel. There are various reasons which can trigger a KILL, and the notice sent is the only way to determine it.

This document assumes that you already have knowledge of the IRC protocol and that you understand it.

General notice format NOTICE &KILLS :Received KILL message for target. From source Path: kill-path (description)

Field short description:

nickname being killed
since 2.11 in the nick!user@host[] format
who issued the kill (IRC Operator nick or server name)
where the kill comes from
Example path of server kill:!*.fi[]!*.hu[]!

In this example, we can follow the path took by the KILL to reach us:

  1. the kill was issued on
  2. It was then received on the next server from *.hu ( identifies the *.hu connection as network link with the host which didn't reply to the ident lookup).
  3. The next server to received the kill got it from *.fi ( identifies the *.fi connection as network link with the host which didn't reply to the ident lookup).
  4. Finally, the server who sent the notice to &KILLS had received it from
Note: as of 2.11 version, identifications (the stuff in square brackets) are not shown.

Example path of oper kill:!*!*.at![unknown@]!!OperServ

Oper kill path is read the same as server kill and it ends with:
  1. server of the IRC Operator that issued kill (not shown for local kills)
  2. IRC Operator hostname
  3. IRC Operator nickname OperServ
IRC Operator kill: reason given by the operator when s/he issued the kill.
Server kill: see below.

Understanding server kills

You will find all description formats below with a short explanation. Unless otherwise noted, the point of view of the following is the server issuing the kill.
nickname[serverA] != serverB
This is commonly known as a Fake Prefix error condition. nickname has been introduced by serverA but serverB is sending data claiming it comes from nickname (which is impossible since nickname is behind serverA and not behind serverB).

Both serverA and serverB are local connections.

serverA <- serverB
serverB is a new server being introduced on the network, but its name is currently being used by another client as a nickname (this client was introduced by serverA). This is a Server/nick collision.
serverA != serverB[serverB hostname]
The nickname being killed is being introduced by serverB and is supposed to be a client using serverA. It is impossible because serverA is not behind serverB.
server <- nickname!user@hostname
server is propagating an illegal nickname change for nickname!user@hostname.
serverA <- local connection name
This is a Nick/Server collision, the local connection is a server which introduced a nickname using the same name as a server behind serverA.
This is not possible since version 2.10(?)
* (userA@hostA)serverA <- (userB@hostB)serverB
This is a classic nickname collision. The nickname being killed was known from serverA but serverB introduced it again. userB@hostB identifies the new user which was being introduced, and userA@hostA the user which got collided.
* serverA <- serverB(nickB)
* serverA(nickA) <- serverB
This is a nickname change collision. Both nickA and nickB are registered clients. The server issuing the kill does so because nickB tried to change its name to nickA (which is already taken).

In theory this shouldn't happen. However, large networks are commonly affected by ``lag (delays) which makes this kind of situation possible.

Note: KILLs marked with * in pure 2.11+ network will not be seen. Clients will have their nicks forcibly changed to their UIDs and proper notice will be sent to &SAVE server channel. They still may be observed in mixed net, though.

Written by Christophe Kalt, revised for 2.11 by Piotr Kucharski.

$Id: kills.html,v 1.4 1997/09/29 12:05:57 kalt Exp $
$Id: kills.html,v 1.5 2004/07/13 16:24:42 chopin Exp $