Commit run/7b4cc56f-2db2-403c-b8c9-0e47890f393f/main - golang-github-fluffle-goirc

New upstream release. Debian Janitor 1 year, 5 months ago

15 changed file(s) with 8775 addition(s) and 39 deletion(s). Raw diff Collapse all Expand all

-8

~~.gitignore~~ less more

0		/gobot
1		*.[568]
2		_obj/
3		_test/
4		*.swp
5		*~
6		*.out
7		/.gitconfig

-2

.travis.yml less more

1	1	language: go
2	2
3	3	go:
4		- 1.16.2
5		- 1.15.10
	4	- 1.18
	5	- 1.17.8
	6	- 1.16.15
	7	- 1.15.15
6	8
7	9	sudo : false
8	10

-1

README.md less more

81	81	server will probably result in an inconsistent state and a lot of warnings to
82	82	STDERR ;-)
83	83
	84	### Projects using GoIRC
	85
	86	- [xdcc-cli](https://github.com/ostafen/xdcc-cli): A command line tool for searching and downloading files from the IRC network.
	87
	88
84	89	### Misc.
85	90
86	91	Sorry the documentation is crap. Use the source, Luke.

91	96	the re-organisation and channel-based communication structure of `*Conn.send()`
92	97	and `*Conn.recv()`. I'm sure things could be more asynchronous, still.
93	98
94		This code is (c) 2009-15 Alex Bramley, and released under the same licence terms
	99	This code is (c) 2009-23 Alex Bramley, and released under the same licence terms
95	100	as Go itself.
96	101
97	102	Contributions gratefully received from:

109	114	- [jakebailey](https://github.com/jakebailey)
110	115	- [stapelberg](https://github.com/stapelberg)
111	116	- [shammash](https://github.com/shammash)
	117	- [ostafen](https://github.com/ostafen)
	118	- [supertassu](https://github.com/supertassu)
112	119
113	120	And thanks to the following for minor doc/fix PRs:
114	121

+29

-3

client/commands.go less more

9	9	CONNECTED = "CONNECTED"
10	10	DISCONNECTED = "DISCONNECTED"
11	11	ACTION = "ACTION"
	12	AUTHENTICATE = "AUTHENTICATE"
12	13	AWAY = "AWAY"
13	14	CAP = "CAP"
14	15	CTCP = "CTCP"

83	84	return append(msgs, msg)
84	85	}
85	86
	87	func splitArgs(args []string, maxLen int) []string {
	88	res := make([]string, 0)
	89
	90	i := 0
	91	for i < len(args) {
	92	currArg := args[i]
	93	i++
	94
	95	for i < len(args) && len(currArg)+len(args[i])+1 < maxLen {
	96	currArg += " " + args[i]
	97	i++
	98	}
	99	res = append(res, currArg)
	100	}
	101	return res
	102	}
	103
86	104	// Raw sends a raw line to the server, should really only be used for
87	105	// debugging purposes but may well come in handy.
88	106	func (conn *Conn) Raw(rawline string) {

298	316	if len(capabilities) == 0 {
299	317	conn.Raw(CAP + " " + subcommmand)
300	318	} else {
301		conn.Raw(CAP + " " + subcommmand + " :" + strings.Join(capabilities, " "))
302		}
303		}
	319	cmdPrefix := CAP + " " + subcommmand + " :"
	320	for _, args := range splitArgs(capabilities, defaultSplit-len(cmdPrefix)) {
	321	conn.Raw(cmdPrefix + args)
	322	}
	323	}
	324	}
	325
	326	// Authenticate send an AUTHENTICATE command to the server.
	327	func (conn *Conn) Authenticate(message string) {
	328	conn.Raw(AUTHENTICATE + " " + message)
	329	}

+19

-0

client/commands_test.go less more

1	1
2	2	import (
3	3	"reflect"
	4	"strconv"
	5	"strings"
4	6	"testing"
5	7	)
6	8

202	204	c.VHost("user", "pass")
203	205	s.nc.Expect("VHOST user pass")
204	206	}
	207
	208	func TestSplitCommand(t *testing.T) {
	209	nArgs := 100
	210
	211	args := make([]string, 0)
	212	for i := 0; i < nArgs; i++ {
	213	args = append(args, "arg"+strconv.Itoa(i))
	214	}
	215
	216	for maxLen := 1; maxLen <= defaultSplit; maxLen *= 2 {
	217	for _, argStr := range splitArgs(args, maxLen) {
	218	if len(argStr) > maxLen && len(strings.Split(argStr, " ")) > 1 {
	219	t.Errorf("maxLen = %d, but len(cmd) = %d", maxLen, len(argStr))
	220	}
	221	}
	222	}
	223	}

+54

-17

client/connection.go less more

12	12	"sync"
13	13	"time"
14	14
	15	"github.com/emersion/go-sasl"
15	16	"github.com/fluffle/goirc/logging"
16	17	"github.com/fluffle/goirc/state"
17	18	"golang.org/x/net/proxy"

43	44	in chan *Line
44	45	out chan string
45	46	connected bool
	47
	48	// Capabilities supported by the server
	49	supportedCaps *capSet
	50
	51	// Capabilites currently enabled
	52	currCaps *capSet
	53
	54	// SASL internals
	55	saslRemainingData []byte
46	56
47	57	// CancelFunc and WaitGroup for goroutines
48	58	die context.CancelFunc

88	98	// Passed through to https://golang.org/pkg/net/#Dialer
89	99	DualStack bool
90	100
	101	// Enable IRCv3 capability negotiation.
	102	EnableCapabilityNegotiation bool
	103
	104	// A list of capabilities to request to the server during registration.
	105	Capabilites []string
	106
	107	// SASL configuration to use to authenticate the connection.
	108	Sasl sasl.Client
	109
91	110	// Replaceable function to customise the 433 handler's new nick.
92	111	// By default an underscore "_" is appended to the current nick.
93	112	NewNick func(string) string

124	143	// name, but these are optional.
125	144	func NewConfig(nick string, args ...string) *Config {
126	145	cfg := &Config{
127		Me: &state.Nick{Nick: nick},
128		PingFreq: 3 * time.Minute,
129		NewNick: DefaultNewNick,
130		Recover: (*Conn).LogPanic, // in dispatch.go
131		SplitLen: defaultSplit,
132		Timeout: 60 * time.Second,
	146	Me: &state.Nick{Nick: nick},
	147	PingFreq: 3 * time.Minute,
	148	NewNick: DefaultNewNick,
	149	Recover: (*Conn).LogPanic, // in dispatch.go
	150	SplitLen: defaultSplit,
	151	Timeout: 60 * time.Second,
	152	EnableCapabilityNegotiation: false,
133	153	}
134	154	cfg.Me.Ident = "goirc"
135	155	if len(args) > 0 && args[0] != "" {

202	222	}
203	223	}
204	224
	225	if cfg.Sasl != nil && !cfg.EnableCapabilityNegotiation {
	226	logging.Warn("Enabling capability negotiation as it's required for SASL")
	227	cfg.EnableCapabilityNegotiation = true
	228	}
	229
205	230	conn := &Conn{
206		cfg: cfg,
207		dialer: dialer,
208		intHandlers: handlerSet(),
209		fgHandlers: handlerSet(),
210		bgHandlers: handlerSet(),
211		stRemovers: make([]Remover, 0, len(stHandlers)),
212		lastsent: time.Now(),
	231	cfg: cfg,
	232	dialer: dialer,
	233	intHandlers: handlerSet(),
	234	fgHandlers: handlerSet(),
	235	bgHandlers: handlerSet(),
	236	stRemovers: make([]Remover, 0, len(stHandlers)),
	237	lastsent: time.Now(),
	238	supportedCaps: capabilitySet(),
	239	currCaps: capabilitySet(),
	240	saslRemainingData: nil,
213	241	}
214	242	conn.addIntHandlers()
215	243	return conn

229	257	// affect client behaviour. To disable flood protection temporarily,
230	258	// for example, a handler could do:
231	259	//
232		// conn.Config().Flood = true
233		// // Send many lines to the IRC server, risking "excess flood"
234		// conn.Config().Flood = false
235		//
	260	// conn.Config().Flood = true
	261	// // Send many lines to the IRC server, risking "excess flood"
	262	// conn.Config().Flood = false
236	263	func (conn Conn) Config() Config {
237	264	return conn.cfg
238	265	}

288	315	}
289	316	}
290	317
	318	// SupportsCapability returns true if the server supports the given capability.
	319	func (conn *Conn) SupportsCapability(cap string) bool {
	320	return conn.supportedCaps.Has(cap)
	321	}
	322
	323	// HasCapability returns true if the given capability has been acked by the server during negotiation.
	324	func (conn *Conn) HasCapability(cap string) bool {
	325	return conn.currCaps.Has(cap)
	326	}
	327
291	328	// Per-connection state initialisation.
292	329	func (conn *Conn) initialise() {
293	330	conn.io = nil

+234

-7

client/handlers.go less more

3	3	// to manage tracking an irc connection etc.
4	4
5	5	import (
	6	"sort"
6	7	"strings"
	8	"sync"
7	9	"time"
8	10
	11	"encoding/base64"
9	12	"github.com/fluffle/goirc/logging"
10	13	)
11	14
	15	// saslCap is the IRCv3 capability used for SASL authentication.
	16	const saslCap = "sasl"
	17
12	18	// sets up the internal event handlers to do essential IRC protocol things
13	19	var intHandlers = map[string]HandlerFunc{
14		REGISTER: (*Conn).h_REGISTER,
15		"001": (*Conn).h_001,
16		"433": (*Conn).h_433,
17		CTCP: (*Conn).h_CTCP,
18		NICK: (*Conn).h_NICK,
19		PING: (*Conn).h_PING,
20		}
	20	REGISTER: (*Conn).h_REGISTER,
	21	"001": (*Conn).h_001,
	22	"433": (*Conn).h_433,
	23	CTCP: (*Conn).h_CTCP,
	24	NICK: (*Conn).h_NICK,
	25	PING: (*Conn).h_PING,
	26	CAP: (*Conn).h_CAP,
	27	"410": (*Conn).h_410,
	28	AUTHENTICATE: (*Conn).h_AUTHENTICATE,
	29	"903": (*Conn).h_903,
	30	"904": (*Conn).h_904,
	31	"908": (*Conn).h_908,
	32	}
	33
	34	// set up the ircv3 capabilities supported by this client which will be requested by default to the server.
	35	var defaultCaps = []string{}
21	36
22	37	func (conn *Conn) addIntHandlers() {
23	38	for n, h := range intHandlers {

34	49
35	50	// Handler for initial registration with server once tcp connection is made.
36	51	func (conn Conn) h_REGISTER(line Line) {
	52	if conn.cfg.EnableCapabilityNegotiation {
	53	conn.Cap(CAP_LS)
	54	}
	55
37	56	if conn.cfg.Pass != "" {
38	57	conn.Pass(conn.cfg.Pass)
39	58	}
40	59	conn.Nick(conn.cfg.Me.Nick)
41	60	conn.User(conn.cfg.Me.Ident, conn.cfg.Me.Name)
	61	}
	62
	63	func (conn Conn) getRequestCapabilities() capSet {
	64	s := capabilitySet()
	65
	66	// add capabilites supported by the client
	67	s.Add(defaultCaps...)
	68
	69	if conn.cfg.Sasl != nil {
	70	// add the SASL cap if enabled
	71	s.Add(saslCap)
	72	}
	73
	74	// add capabilites requested by the user
	75	s.Add(conn.cfg.Capabilites...)
	76
	77	return s
	78	}
	79
	80	func (conn *Conn) negotiateCapabilities(supportedCaps []string) {
	81	conn.supportedCaps.Add(supportedCaps...)
	82
	83	reqCaps := conn.getRequestCapabilities()
	84	reqCaps.Intersect(conn.supportedCaps)
	85
	86	if reqCaps.Size() > 0 {
	87	conn.Cap(CAP_REQ, reqCaps.Slice()...)
	88	} else {
	89	conn.Cap(CAP_END)
	90	}
	91	}
	92
	93	func (conn *Conn) handleCapAck(caps []string) {
	94	gotSasl := false
	95	for _, cap := range caps {
	96	conn.currCaps.Add(cap)
	97
	98	if conn.cfg.Sasl != nil && cap == saslCap {
	99	mech, ir, err := conn.cfg.Sasl.Start()
	100
	101	if err != nil {
	102	logging.Warn("SASL authentication failed: %v", err)
	103	continue
	104	}
	105
	106	// TODO: when IRC 3.2 capability negotiation is supported, ensure the
	107	// capability value is used to match the chosen mechanism
	108
	109	gotSasl = true
	110	conn.saslRemainingData = ir
	111
	112	conn.Authenticate(mech)
	113	}
	114	}
	115
	116	if !gotSasl {
	117	conn.Cap(CAP_END)
	118	}
	119	}
	120
	121	func (conn *Conn) handleCapNak(caps []string) {
	122	conn.Cap(CAP_END)
	123	}
	124
	125	const (
	126	CAP_LS = "LS"
	127	CAP_REQ = "REQ"
	128	CAP_ACK = "ACK"
	129	CAP_NAK = "NAK"
	130	CAP_END = "END"
	131	)
	132
	133	type capSet struct {
	134	caps map[string]bool
	135	mu sync.RWMutex
	136	}
	137
	138	func capabilitySet() *capSet {
	139	return &capSet{
	140	caps: make(map[string]bool),
	141	}
	142	}
	143
	144	func (c *capSet) Add(caps ...string) {
	145	c.mu.Lock()
	146	for _, cap := range caps {
	147	if strings.HasPrefix(cap, "-") {
	148	c.caps[cap[1:]] = false
	149	} else {
	150	c.caps[cap] = true
	151	}
	152	}
	153	c.mu.Unlock()
	154	}
	155
	156	func (c *capSet) Has(cap string) bool {
	157	c.mu.RLock()
	158	defer c.mu.RUnlock()
	159	return c.caps[cap]
	160	}
	161
	162	// Intersect computes the intersection of two sets.
	163	func (c capSet) Intersect(other capSet) {
	164	c.mu.Lock()
	165
	166	for cap := range c.caps {
	167	if !other.Has(cap) {
	168	delete(c.caps, cap)
	169	}
	170	}
	171
	172	c.mu.Unlock()
	173	}
	174
	175	func (c *capSet) Slice() []string {
	176	c.mu.RLock()
	177	defer c.mu.RUnlock()
	178
	179	capSlice := make([]string, 0, len(c.caps))
	180	for cap := range c.caps {
	181	capSlice = append(capSlice, cap)
	182	}
	183
	184	// make output predictable for testing
	185	sort.Strings(capSlice)
	186	return capSlice
	187	}
	188
	189	func (c *capSet) Size() int {
	190	c.mu.RLock()
	191	defer c.mu.RUnlock()
	192	return len(c.caps)
	193	}
	194
	195	// This handler is triggered when an invalid cap command is received by the server.
	196	func (conn Conn) h_410(line Line) {
	197	logging.Warn("Invalid cap subcommand: ", line.Args[1])
	198	}
	199
	200	// Handler for capability negotiation commands.
	201	// Note that even if multiple CAP_END commands may be sent to the server during negotiation,
	202	// only the first will be considered.
	203	func (conn Conn) h_CAP(line Line) {
	204	subcommand := line.Args[1]
	205
	206	caps := strings.Fields(line.Text())
	207	switch subcommand {
	208	case CAP_LS:
	209	conn.negotiateCapabilities(caps)
	210	case CAP_ACK:
	211	conn.handleCapAck(caps)
	212	case CAP_NAK:
	213	conn.handleCapNak(caps)
	214	}
	215	}
	216
	217	// Handler for SASL authentication
	218	func (conn Conn) h_AUTHENTICATE(line Line) {
	219	if conn.cfg.Sasl == nil {
	220	return
	221	}
	222
	223	if conn.saslRemainingData != nil {
	224	data := "+" // plus sign representing empty data
	225	if len(conn.saslRemainingData) > 0 {
	226	data = base64.StdEncoding.EncodeToString(conn.saslRemainingData)
	227	}
	228
	229	// TODO: batch data into chunks of 400 bytes per the spec
	230
	231	conn.Authenticate(data)
	232	conn.saslRemainingData = nil
	233	return
	234	}
	235
	236	// TODO: handle data over 400 bytes long (which will be chunked into multiple messages per the spec)
	237	challenge, err := base64.StdEncoding.DecodeString(line.Args[0])
	238	if err != nil {
	239	logging.Error("Failed to decode SASL challenge: %v", err)
	240	return
	241	}
	242
	243	response, err := conn.cfg.Sasl.Next(challenge)
	244	if err != nil {
	245	logging.Error("Failed to generate response for SASL challenge: %v", err)
	246	return
	247	}
	248
	249	// TODO: batch data into chunks of 400 bytes per the spec
	250	data := base64.StdEncoding.EncodeToString(response)
	251	conn.Authenticate(data)
	252	}
	253
	254	// Handler for RPL_SASLSUCCESS.
	255	func (conn Conn) h_903(line Line) {
	256	conn.Cap(CAP_END)
	257	}
	258
	259	// Handler for RPL_SASLFAILURE.
	260	func (conn Conn) h_904(line Line) {
	261	logging.Warn("SASL authentication failed")
	262	conn.Cap(CAP_END)
	263	}
	264
	265	// Handler for RPL_SASLMECHS.
	266	func (conn Conn) h_908(line Line) {
	267	logging.Warn("SASL mechanism not supported, supported mechanisms are: %v", line.Args[1])
	268	conn.Cap(CAP_END)
42	269	}
43	270
44	271	// Handler to trigger a CONNECTED event on receipt of numeric 001

+51

-0

client/handlers_test.go less more

455	455	s.st.EXPECT().GetNick("user2").Return(nil)
456	456	c.h_671(ParseLine(":irc.server.org 671 test user2 :some ignored text"))
457	457	}
	458
	459	func TestCap(t *testing.T) {
	460	c, s := setUp(t)
	461	defer s.tearDown()
	462
	463	c.Config().EnableCapabilityNegotiation = true
	464	c.Config().Capabilites = []string{"cap1", "cap2", "cap3", "cap4"}
	465
	466	c.h_REGISTER(&Line{Cmd: REGISTER})
	467	s.nc.Expect("CAP LS")
	468	s.nc.Expect("NICK test")
	469	s.nc.Expect("USER test 12 * :Testing IRC")
	470
	471	// Ensure that capabilities not supported by the server are not requested
	472	s.nc.Send("CAP * LS :cap2 cap4")
	473	s.nc.Expect("CAP REQ :cap2 cap4")
	474
	475	s.nc.Send("CAP * ACK :cap2 cap4")
	476	s.nc.Expect("CAP END")
	477
	478	for _, cap := range []string{"cap2", "cap4"} {
	479	if !c.SupportsCapability(cap) {
	480	t.Fail()
	481	}
	482
	483	if !c.HasCapability(cap) {
	484	t.Fail()
	485	}
	486	}
	487
	488	for _, cap := range []string{"cap1", "cap3"} {
	489	if c.HasCapability(cap) {
	490	t.Fail()
	491	}
	492	}
	493
	494	// test disable capability after registration
	495	s.c.Cap("REQ", "-cap4")
	496	s.nc.Expect("CAP REQ :-cap4")
	497
	498	s.nc.Send("CAP * ACK :-cap4")
	499	s.nc.Expect("CAP END")
	500
	501	if !c.HasCapability("cap2") {
	502	t.Fail()
	503	}
	504
	505	if c.HasCapability("cap4") {
	506	t.Fail()
	507	}
	508	}

+103

-0

client/sasl_test.go less more

	0	package client
	1
	2	import (
	3	"github.com/emersion/go-sasl"
	4	"testing"
	5	)
	6
	7	func TestSaslPlainSuccessWorkflow(t *testing.T) {
	8	c, s := setUp(t)
	9	defer s.tearDown()
	10
	11	c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
	12	c.Config().EnableCapabilityNegotiation = true
	13
	14	c.h_REGISTER(&Line{Cmd: REGISTER})
	15	s.nc.Expect("CAP LS")
	16	s.nc.Expect("NICK test")
	17	s.nc.Expect("USER test 12 * :Testing IRC")
	18	s.nc.Send("CAP * LS :sasl foobar")
	19	s.nc.Expect("CAP REQ :sasl")
	20	s.nc.Send("CAP * ACK :sasl")
	21	s.nc.Expect("AUTHENTICATE PLAIN")
	22	s.nc.Send("AUTHENTICATE +")
	23	s.nc.Expect("AUTHENTICATE AGV4YW1wbGUAcGFzc3dvcmQ=")
	24	s.nc.Send("904 test :SASL authentication successful")
	25	s.nc.Expect("CAP END")
	26	}
	27
	28	func TestSaslPlainWrongPassword(t *testing.T) {
	29	c, s := setUp(t)
	30	defer s.tearDown()
	31
	32	c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
	33	c.Config().EnableCapabilityNegotiation = true
	34
	35	c.h_REGISTER(&Line{Cmd: REGISTER})
	36	s.nc.Expect("CAP LS")
	37	s.nc.Expect("NICK test")
	38	s.nc.Expect("USER test 12 * :Testing IRC")
	39	s.nc.Send("CAP * LS :sasl foobar")
	40	s.nc.Expect("CAP REQ :sasl")
	41	s.nc.Send("CAP * ACK :sasl")
	42	s.nc.Expect("AUTHENTICATE PLAIN")
	43	s.nc.Send("AUTHENTICATE +")
	44	s.nc.Expect("AUTHENTICATE AGV4YW1wbGUAcGFzc3dvcmQ=")
	45	s.nc.Send("904 test :SASL authentication failed")
	46	s.nc.Expect("CAP END")
	47	}
	48
	49	func TestSaslExternalSuccessWorkflow(t *testing.T) {
	50	c, s := setUp(t)
	51	defer s.tearDown()
	52
	53	c.Config().Sasl = sasl.NewExternalClient("")
	54	c.Config().EnableCapabilityNegotiation = true
	55
	56	c.h_REGISTER(&Line{Cmd: REGISTER})
	57	s.nc.Expect("CAP LS")
	58	s.nc.Expect("NICK test")
	59	s.nc.Expect("USER test 12 * :Testing IRC")
	60	s.nc.Send("CAP * LS :sasl foobar")
	61	s.nc.Expect("CAP REQ :sasl")
	62	s.nc.Send("CAP * ACK :sasl")
	63	s.nc.Expect("AUTHENTICATE EXTERNAL")
	64	s.nc.Send("AUTHENTICATE +")
	65	s.nc.Expect("AUTHENTICATE +")
	66	s.nc.Send("904 test :SASL authentication successful")
	67	s.nc.Expect("CAP END")
	68	}
	69
	70	func TestSaslNoSaslCap(t *testing.T) {
	71	c, s := setUp(t)
	72	defer s.tearDown()
	73
	74	c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
	75	c.Config().EnableCapabilityNegotiation = true
	76
	77	c.h_REGISTER(&Line{Cmd: REGISTER})
	78	s.nc.Expect("CAP LS")
	79	s.nc.Expect("NICK test")
	80	s.nc.Expect("USER test 12 * :Testing IRC")
	81	s.nc.Send("CAP * LS :foobar")
	82	s.nc.Expect("CAP END")
	83	}
	84
	85	func TestSaslUnsupportedMechanism(t *testing.T) {
	86	c, s := setUp(t)
	87	defer s.tearDown()
	88
	89	c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
	90	c.Config().EnableCapabilityNegotiation = true
	91
	92	c.h_REGISTER(&Line{Cmd: REGISTER})
	93	s.nc.Expect("CAP LS")
	94	s.nc.Expect("NICK test")
	95	s.nc.Expect("USER test 12 * :Testing IRC")
	96	s.nc.Send("CAP * LS :sasl foobar")
	97	s.nc.Expect("CAP REQ :sasl")
	98	s.nc.Send("CAP * ACK :sasl")
	99	s.nc.Expect("AUTHENTICATE PLAIN")
	100	s.nc.Send("908 test external :are available SASL mechanisms")
	101	s.nc.Expect("CAP END")
	102	}

-0

debian/changelog less more

	0	golang-github-fluffle-goirc (1.3.0+ds-1) UNRELEASED; urgency=low
	1
	2	* New upstream release.
	3
	4	-- Debian Janitor <janitor@jelmer.uk> Sun, 18 Dec 2022 04:05:11 -0000
	5
0	6	golang-github-fluffle-goirc (1.1.1+ds-2) unstable; urgency=medium
1	7
2	8	[ Debian Janitor ]

+1067

-0

doc/rfc2811.txt less more

	0
	1
	2
	3
	4
	5
	6	Network Working Group C. Kalt
	7	Request for Comments: 2811 April 2000
	8	Updates: 1459
	9	Category: Informational
	10
	11
	12	Internet Relay Chat: Channel Management
	13
	14	Status of this Memo
	15
	16	This memo provides information for the Internet community. It does
	17	not specify an Internet standard of any kind. Distribution of this
	18	memo is unlimited.
	19
	20	Copyright Notice
	21
	22	Copyright (C) The Internet Society (2000). All Rights Reserved.
	23
	24	Abstract
	25
	26	One of the most notable characteristics of the IRC (Internet Relay
	27	Chat) protocol is to allow for users to be grouped in forums, called
	28	channels, providing a mean for multiple users to communicate
	29	together.
	30
	31	There was originally a unique type of channels, but with the years,
	32	new types appeared either as a response to a need, or for
	33	experimental purposes.
	34
	35	This document specifies how channels, their characteristics and
	36	properties are managed by IRC servers.
	37
	38	Table of Contents
	39
	40	1. Introduction ............................................... 2
	41	2. Channel Characteristics .................................... 3
	42	2.1 Namespace .............................................. 3
	43	2.2 Channel Scope .......................................... 3
	44	2.3 Channel Properties ..................................... 4
	45	2.4 Privileged Channel Members ............................. 4
	46	2.4.1 Channel Operators ................................. 5
	47	2.4.2 Channel Creator ................................... 5
	48	3. Channel lifetime ........................................... 5
	49	3.1 Standard channels ...................................... 5
	50	3.2 Safe Channels .......................................... 6
	51	4. Channel Modes .............................................. 7
	52	4.1 Member Status .......................................... 7
	53	4.1.1 "Channel Creator" Status .......................... 7
	54
	55
	56
	57	Kalt Informational [Page 1]
	58
	59	RFC 2811 Internet Relay Chat: Channel Management April 2000
	60
	61
	62	4.1.2 Channel Operator Status ........................... 8
	63	4.1.3 Voice Privilege ................................... 8
	64	4.2 Channel Flags .......................................... 8
	65	4.2.1 Anonymous Flag .................................... 8
	66	4.2.2 Invite Only Flag .................................. 8
	67	4.2.3 Moderated Channel Flag ............................ 9
	68	4.2.4 No Messages To Channel From Clients On The Outside 9
	69	4.2.5 Quiet Channel ..................................... 9
	70	4.2.6 Private and Secret Channels ....................... 9
	71	4.2.7 Server Reop Flag .................................. 10
	72	4.2.8 Topic ............................................. 10
	73	4.2.9 User Limit ........................................ 10
	74	4.2.10 Channel Key ...................................... 10
	75	4.3 Channel Access Control ................................. 10
	76	4.3.1 Channel Ban and Exception ......................... 11
	77	4.3.2 Channel Invitation ................................ 11
	78	5. Current Implementations .................................... 11
	79	5.1 Tracking Recently Used Channels ........................ 11
	80	5.2 Safe Channels .......................................... 12
	81	5.2.1 Channel Identifier ................................ 12
	82	5.2.2 Channel Delay ..................................... 12
	83	5.2.3 Abuse Window ...................................... 13
	84	5.2.4 Preserving Sanity In The Name Space ............... 13
	85	5.2.5 Server Reop Mechanism ............................. 13
	86	6. Current problems ........................................... 14
	87	6.1 Labels ................................................. 14
	88	6.1.1 Channel Delay ..................................... 14
	89	6.1.2 Safe Channels ..................................... 15
	90	6.2 Mode Propagation Delays ................................ 15
	91	6.3 Collisions And Channel Modes ........................... 15
	92	6.4 Resource Exhaustion .................................... 16
	93	7. Security Considerations .................................... 16
	94	7.1 Access Control ......................................... 16
	95	7.2 Channel Privacy ........................................ 16
	96	7.3 Anonymity ............................................... 17
	97	8. Current support and availability ........................... 17
	98	9. Acknowledgements ........................................... 17
	99	10. References ................................................ 18
	100	11. Author's Address .......................................... 18
	101	12. Full Copyright Statement ................................... 19
	102
	103	1. Introduction
	104
	105	This document defines in detail on how channels are managed by the
	106	IRC servers and will be mostly useful to people working on
	107	implementing an IRC server.
	108
	109
	110
	111
	112
	113	Kalt Informational [Page 2]
	114
	115	RFC 2811 Internet Relay Chat: Channel Management April 2000
	116
	117
	118	While the concepts defined here are an important part of IRC, they
	119	remain non essential for implementing clients. While the trend seems
	120	to be towards more and more complex and "intelligent" clients which
	121	are able to take advantage of knowing the internal workings of
	122	channels to provide the users with a more friendly interface, simple
	123	clients can be implemented without reading this document.
	124
	125	Many of the concepts defined here were designed with the IRC
	126	architecture [IRC-ARCH] in mind and mostly make sense in this
	127	context. However, many others could be applied to other
	128	architectures in order to provide forums for a conferencing system.
	129
	130	Finally, it is to be noted that IRC users may find some of the
	131	following sections of interest, in particular sections 2 (Channel
	132	Characteristics) and 4 (Channel Modes).
	133
	134	2. Channel Characteristics
	135
	136	A channel is a named group of one or more users which will all
	137	receive messages addressed to that channel. A channel is
	138	characterized by its name, properties and current members.
	139
	140	2.1 Namespace
	141
	142	Channels names are strings (beginning with a '&', '#', '+' or '!'
	143	character) of length up to fifty (50) characters. Channel names are
	144	case insensitive.
	145
	146	Apart from the the requirement that the first character being either
	147	'&', '#', '+' or '!' (hereafter called "channel prefix"). The only
	148	restriction on a channel name is that it SHALL NOT contain any spaces
	149	(' '), a control G (^G or ASCII 7), a comma (',' which is used as a
	150	list item separator by the protocol). Also, a colon (':') is used as
	151	a delimiter for the channel mask. The exact syntax of a channel name
	152	is defined in "IRC Server Protocol" [IRC-SERVER].
	153
	154	The use of different prefixes effectively creates four (4) distinct
	155	namespaces for channel names. This is important because of the
	156	protocol limitations regarding namespaces (in general). See section
	157	6.1 (Labels) for more details on these limitations.
	158
	159	2.2 Channel Scope
	160
	161	A channel entity is known by one or more servers on the IRC network.
	162	A user can only become member of a channel known by the server to
	163	which the user is directly connected. The list of servers which know
	164
	165
	166
	167
	168
	169	Kalt Informational [Page 3]
	170
	171	RFC 2811 Internet Relay Chat: Channel Management April 2000
	172
	173
	174	of the existence of a particular channel MUST be a contiguous part of
	175	the IRC network, in order for the messages addressed to the channel
	176	to be sent to all the channel members.
	177
	178	Channels with '&' as prefix are local to the server where they are
	179	created.
	180
	181	Other channels are known to one (1) or more servers that are
	182	connected to the network, depending on the channel mask:
	183
	184	If there is no channel mask, then the channel is known to all
	185	the servers.
	186
	187	If there is a channel mask, then the channel MUST only be known
	188	to servers which has a local user on the channel, and to its
	189	neighbours if the mask matches both the local and neighbouring
	190	server names. Since other servers have absolutely no knowledge of
	191	the existence of such a channel, the area formed by the servers
	192	having a name matching the mask has to be contiguous for the
	193	channel to be known by all these servers. Channel masks are best
	194	used in conjunction with server hostmasking [IRC-SERVER].
	195
	196	2.3 Channel Properties
	197
	198	Each channel has its own properties, which are defined by channel
	199	modes. Channel modes can be manipulated by the channel members. The
	200	modes affect the way servers manage the channels.
	201
	202	Channels with '+' as prefix do not support channel modes. This means
	203	that all the modes are unset, with the exception of the 't' channel
	204	flag which is set.
	205
	206	2.4 Privileged Channel Members
	207
	208	In order for the channel members to keep some control over a channel,
	209	and some kind of sanity, some channel members are privileged. Only
	210	these members are allowed to perform the following actions on the
	211	channel:
	212
	213	INVITE - Invite a client to an invite-only channel (mode +i)
	214	KICK - Eject a client from the channel
	215	MODE - Change the channel's mode, as well as
	216	members' privileges
	217	PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
	218	TOPIC - Change the channel topic in a mode +t channel
	219
	220
	221
	222
	223
	224
	225	Kalt Informational [Page 4]
	226
	227	RFC 2811 Internet Relay Chat: Channel Management April 2000
	228
	229
	230	2.4.1 Channel Operators
	231
	232	The channel operators (also referred to as a "chop" or "chanop") on a
	233	given channel are considered to 'own' that channel. Ownership of a
	234	channel is shared among channel operators.
	235
	236	Channel operators are identified by the '@' symbol next to their
	237	nickname whenever it is associated with a channel (i.e., replies to
	238	the NAMES, WHO and WHOIS commands).
	239
	240	Since channels starting with the character '+' as prefix do not
	241	support channel modes, no member can therefore have the status of
	242	channel operator.
	243
	244	2.4.2 Channel Creator
	245
	246	A user who creates a channel with the character '!' as prefix is
	247	identified as the "channel creator". Upon creation of the channel,
	248	this user is also given channel operator status.
	249
	250	In recognition of this status, the channel creators are endowed with
	251	the ability to toggle certain modes of the channel which channel
	252	operators may not manipulate.
	253
	254	A "channel creator" can be distinguished from a channel operator by
	255	issuing the proper MODE command. See the "IRC Client Protocol"
	256	[IRC-CLIENT] for more information on this topic.
	257
	258	3. Channel lifetime
	259
	260	In regard to the lifetime of a channel, there are typically two
	261	groups of channels: standard channels which prefix is either '&', '#'
	262	or '+', and "safe channels" which prefix is '!'.
	263
	264	3.1 Standard channels
	265
	266	These channels are created implicitly when the first user joins it,
	267	and cease to exist when the last user leaves it. While the channel
	268	exists, any client can reference the channel using the name of the
	269	channel.
	270
	271	The user creating a channel automatically becomes channel operator
	272	with the notable exception of channels which name is prefixed by the
	273	character '+', see section 4 (Channel modes). See section 2.4.1
	274	(Channel Operators) for more details on this title.
	275
	276
	277
	278
	279
	280
	281	Kalt Informational [Page 5]
	282
	283	RFC 2811 Internet Relay Chat: Channel Management April 2000
	284
	285
	286	In order to avoid the creation of duplicate channels (typically when
	287	the IRC network becomes disjoint because of a split between two
	288	servers), channel names SHOULD NOT be allowed to be reused by a user
	289	if a channel operator (See Section 2.4.1 (Channel Operators)) has
	290	recently left the channel because of a network split. If this
	291	happens, the channel name is temporarily unavailable. The duration
	292	while a channel remains unavailable should be tuned on a per IRC
	293	network basis. It is important to note that this prevents local
	294	users from creating a channel using the same name, but does not
	295	prevent the channel to be recreated by a remote user. The latter
	296	typically happens when the IRC network rejoins. Obviously, this
	297	mechanism only makes sense for channels which name begins with the
	298	character '#', but MAY be used for channels which name begins with
	299	the character '+'. This mechanism is commonly known as "Channel
	300	Delay".
	301
	302	3.2 Safe Channels
	303
	304	Unlike other channels, "safe channels" are not implicitly created. A
	305	user wishing to create such a channel MUST request the creation by
	306	sending a special JOIN command to the server in which the channel
	307	identifier (then unknown) is replaced by the character '!'. The
	308	creation process for this type of channel is strictly controlled.
	309	The user only chooses part of the channel name (known as the channel
	310	"short name"), the server automatically prepends the user provided
	311	name with a channel identifier consisting of five (5) characters.
	312	The channel name resulting from the combination of these two elements
	313	is unique, making the channel safe from abuses based on network
	314	splits.
	315
	316	The user who creates such a channel automatically becomes "channel
	317	creator". See section 2.4.2 (Channel Creator) for more details on
	318	this title.
	319
	320	A server MUST NOT allow the creation of a new channel if another
	321	channel with the same short name exists; or if another channel with
	322	the same short name existed recently AND any of its member(s) left
	323	because of a network split. Such channel ceases to exist after last
	324	user leaves AND no other member recently left the channel because of
	325	a network split.
	326
	327	Unlike the mechanism described in section 5.2.2 (Channel Delay), in
	328	this case, channel names do not become unavailable: these channels
	329	may continue to exist after the last user left. Only the user
	330	creating the channel becomes "channel creator", users joining an
	331	existing empty channel do not automatically become "channel creator"
	332	nor "channel operator".
	333
	334
	335
	336
	337	Kalt Informational [Page 6]
	338
	339	RFC 2811 Internet Relay Chat: Channel Management April 2000
	340
	341
	342	To ensure the uniqueness of the channel names, the channel identifier
	343	created by the server MUST follow specific rules. For more details
	344	on this, see section 5.2.1 (Channel Identifier).
	345
	346	4. Channel Modes
	347
	348	The various modes available for channels are as follows:
	349
	350	O - give "channel creator" status;
	351	o - give/take channel operator privilege;
	352	v - give/take the voice privilege;
	353
	354	a - toggle the anonymous channel flag;
	355	i - toggle the invite-only channel flag;
	356	m - toggle the moderated channel;
	357	n - toggle the no messages to channel from clients on the
	358	outside;
	359	q - toggle the quiet channel flag;
	360	p - toggle the private channel flag;
	361	s - toggle the secret channel flag;
	362	r - toggle the server reop channel flag;
	363	t - toggle the topic settable by channel operator only flag;
	364
	365	k - set/remove the channel key (password);
	366	l - set/remove the user limit to channel;
	367
	368	b - set/remove ban mask to keep users out;
	369	e - set/remove an exception mask to override a ban mask;
	370	I - set/remove an invitation mask to automatically override
	371	the invite-only flag;
	372
	373	Unless mentioned otherwise below, all these modes can be manipulated
	374	by "channel operators" by using the MODE command defined in "IRC
	375	Client Protocol" [IRC-CLIENT].
	376
	377	4.1 Member Status
	378
	379	The modes in this category take a channel member nickname as argument
	380	and affect the privileges given to this user.
	381
	382	4.1.1 "Channel Creator" Status
	383
	384	The mode 'O' is only used in conjunction with "safe channels" and
	385	SHALL NOT be manipulated by users. Servers use it to give the user
	386	creating the channel the status of "channel creator".
	387
	388
	389
	390
	391
	392
	393	Kalt Informational [Page 7]
	394
	395	RFC 2811 Internet Relay Chat: Channel Management April 2000
	396
	397
	398	4.1.2 Channel Operator Status
	399
	400	The mode 'o' is used to toggle the operator status of a channel
	401	member.
	402
	403	4.1.3 Voice Privilege
	404
	405	The mode 'v' is used to give and take voice privilege to/from a
	406	channel member. Users with this privilege can talk on moderated
	407	channels. (See section 4.2.3 (Moderated Channel Flag).
	408
	409	4.2 Channel Flags
	410
	411	The modes in this category are used to define properties which
	412	affects how channels operate.
	413
	414	4.2.1 Anonymous Flag
	415
	416	The channel flag 'a' defines an anonymous channel. This means that
	417	when a message sent to the channel is sent by the server to users,
	418	and the origin is a user, then it MUST be masked. To mask the
	419	message, the origin is changed to "anonymous!anonymous@anonymous."
	420	(e.g., a user with the nickname "anonymous", the username "anonymous"
	421	and from a host called "anonymous."). Because of this, servers MUST
	422	forbid users from using the nickname "anonymous". Servers MUST also
	423	NOT send QUIT messages for users leaving such channels to the other
	424	channel members but generate a PART message instead.
	425
	426	On channels with the character '&' as prefix, this flag MAY be
	427	toggled by channel operators, but on channels with the character '!'
	428	as prefix, this flag can be set (but SHALL NOT be unset) by the
	429	"channel creator" only. This flag MUST NOT be made available on
	430	other types of channels.
	431
	432	Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
	433	presence of other users on channels for which the anonymous flag is
	434	set.
	435
	436	4.2.2 Invite Only Flag
	437
	438	When the channel flag 'i' is set, new members are only accepted if
	439	their mask matches Invite-list (See section 4.3.2) or they have been
	440	invited by a channel operator. This flag also restricts the usage of
	441	the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
	442	channel operators.
	443
	444
	445
	446
	447
	448
	449	Kalt Informational [Page 8]
	450
	451	RFC 2811 Internet Relay Chat: Channel Management April 2000
	452
	453
	454	4.2.3 Moderated Channel Flag
	455
	456	The channel flag 'm' is used to control who may speak on a channel.
	457	When it is set, only channel operators, and members who have been
	458	given the voice privilege may send messages to the channel.
	459
	460	This flag only affects users.
	461
	462	4.2.4 No Messages To Channel From Clients On The Outside
	463
	464	When the channel flag 'n' is set, only channel members MAY send
	465	messages to the channel.
	466
	467	This flag only affects users.
	468
	469	4.2.5 Quiet Channel
	470
	471	The channel flag 'q' is for use by servers only. When set, it
	472	restricts the type of data sent to users about the channel
	473	operations: other user joins, parts and nick changes are not sent.
	474	From a user's point of view, the channel contains only one user.
	475
	476	This is typically used to create special local channels on which the
	477	server sends notices related to its operations. This was used as a
	478	more efficient and flexible way to replace the user mode 's' defined
	479	in RFC 1459 [IRC].
	480
	481	4.2.6 Private and Secret Channels
	482
	483	The channel flag 'p' is used to mark a channel "private" and the
	484	channel flag 's' to mark a channel "secret". Both properties are
	485	similar and conceal the existence of the channel from other users.
	486
	487	This means that there is no way of getting this channel's name from
	488	the server without being a member. In other words, these channels
	489	MUST be omitted from replies to queries like the WHOIS command.
	490
	491	When a channel is "secret", in addition to the restriction above, the
	492	server will act as if the channel does not exist for queries like the
	493	TOPIC, LIST, NAMES commands. Note that there is one exception to
	494	this rule: servers will correctly reply to the MODE command.
	495	Finally, secret channels are not accounted for in the reply to the
	496	LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
	497	CLIENT]) when the <mask> parameter is specified.
	498
	499
	500
	501
	502
	503
	504
	505	Kalt Informational [Page 9]
	506
	507	RFC 2811 Internet Relay Chat: Channel Management April 2000
	508
	509
	510	The channel flags 'p' and 's' MUST NOT both be set at the same time.
	511	If a MODE message originating from a server sets the flag 'p' and the
	512	flag 's' is already set for the channel, the change is silently
	513	ignored. This should only happen during a split healing phase
	514	(mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
	515
	516	4.2.7 Server Reop Flag
	517
	518	The channel flag 'r' is only available on channels which name begins
	519	with the character '!' and MAY only be toggled by the "channel
	520	creator".
	521
	522	This flag is used to prevent a channel from having no channel
	523	operator for an extended period of time. When this flag is set, any
	524	channel that has lost all its channel operators for longer than the
	525	"reop delay" period triggers a mechanism in servers to reop some or
	526	all of the channel inhabitants. This mechanism is described more in
	527	detail in section 5.2.4 (Channel Reop Mechanism).
	528
	529	4.2.8 Topic
	530
	531	The channel flag 't' is used to restrict the usage of the TOPIC
	532	command to channel operators.
	533
	534	4.2.9 User Limit
	535
	536	A user limit may be set on channels by using the channel flag 'l'.
	537	When the limit is reached, servers MUST forbid their local users to
	538	join the channel.
	539
	540	The value of the limit MUST only be made available to the channel
	541	members in the reply sent by the server to a MODE query.
	542
	543	4.2.10 Channel Key
	544
	545	When a channel key is set (by using the mode 'k'), servers MUST
	546	reject their local users request to join the channel unless this key
	547	is given.
	548
	549	The channel key MUST only be made visible to the channel members in
	550	the reply sent by the server to a MODE query.
	551
	552	4.3 Channel Access Control
	553
	554	The last category of modes is used to control access to the channel,
	555	they take a mask as argument.
	556
	557
	558
	559
	560
	561	Kalt Informational [Page 10]
	562
	563	RFC 2811 Internet Relay Chat: Channel Management April 2000
	564
	565
	566	In order to reduce the size of the global database for control access
	567	modes set for channels, servers MAY put a maximum limit on the number
	568	of such modes set for a particular channel. If such restriction is
	569	imposed, it MUST only affect user requests. The limit SHOULD be
	570	homogeneous on a per IRC network basis.
	571
	572	4.3.1 Channel Ban and Exception
	573
	574	When a user requests to join a channel, his local server checks if
	575	the user's address matches any of the ban masks set for the channel.
	576	If a match is found, the user request is denied unless the address
	577	also matches an exception mask set for the channel.
	578
	579	Servers MUST NOT allow a channel member who is banned from the
	580	channel to speak on the channel, unless this member is a channel
	581	operator or has voice privilege. (See Section 4.1.3 (Voice
	582	Privilege)).
	583
	584	A user who is banned from a channel and who carries an invitation
	585	sent by a channel operator is allowed to join the channel.
	586
	587	4.3.2 Channel Invitation
	588
	589	For channels which have the invite-only flag set (See Section 4.2.2
	590	(Invite Only Flag)), users whose address matches an invitation mask
	591	set for the channel are allowed to join the channel without any
	592	invitation.
	593
	594	5. Current Implementations
	595
	596	The only current implementation of these rules as part of the IRC
	597	protocol is the IRC server, version 2.10.
	598
	599	The rest of this section deals with issues that are mostly of
	600	importance to those who wish to implement a server but some parts may
	601	also be of interest for client writers.
	602
	603	5.1 Tracking Recently Used Channels
	604
	605	This mechanism is commonly known as "Channel Delay" and generally
	606	only applies to channels which names is prefixed with the character
	607	'#' (See Section 3.1 "Standard channels").
	608
	609	When a network split occurs, servers SHOULD keep track of which
	610	channels lost a "channel operator" as the result of the break. These
	611	channels are then in a special state which lasts for a certain period
	612	of time. In this particular state, the channels cannot cease to
	613
	614
	615
	616
	617	Kalt Informational [Page 11]
	618
	619	RFC 2811 Internet Relay Chat: Channel Management April 2000
	620
	621
	622	exist. If all the channel members leave the channel, the channel
	623	becomes unavailable: the server local clients cannot join the channel
	624	as long as it is empty.
	625
	626	Once a channel is unavailable, it will become available again either
	627	because a remote user has joined the channel (most likely because the
	628	network is healing), or because the delay period has expired (in
	629	which case the channel ceases to exist and may be re-created).
	630
	631	The duration for which a channel death is delayed SHOULD be set
	632	considering many factors among which are the size (user wise) of the
	633	IRC network, and the usual duration of network splits. It SHOULD be
	634	uniform on all servers for a given IRC network.
	635
	636	5.2 Safe Channels
	637
	638	This document introduces the notion of "safe channels". These
	639	channels have a name prefixed with the character '!' and great effort
	640	is made to avoid collisions in this name space. Collisions are not
	641	impossible, however they are very unlikely.
	642
	643	5.2.1 Channel Identifier
	644
	645	The channel identifier is a function of the time. The current time
	646	(as defined under UNIX by the number of seconds elapsed since
	647	00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
	648	characters using the following base:
	649	"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
	650	value starting from 0 for 'A' to 35 for '0').
	651
	652	The channel identifier therefore has a periodicity of 36^5 seconds
	653	(about 700 days).
	654
	655	5.2.2 Channel Delay
	656
	657	These channels MUST be subject to the "channel delay" mechanism
	658	described in section 5.1 (Channel Delay). However, the mechanism is
	659	slightly adapted to fit better.
	660
	661	Servers MUST keep track of all such channels which lose members as
	662	the result of a network split, no matter whether the user is a
	663	"channel operator" or not.
	664
	665	However, these channels do NOT ever become unavailable, it is always
	666	possible to join them even when they are empty.
	667
	668
	669
	670
	671
	672
	673	Kalt Informational [Page 12]
	674
	675	RFC 2811 Internet Relay Chat: Channel Management April 2000
	676
	677
	678	5.2.3 Abuse Window
	679
	680	Because the periodicity is so long, attacks on a particular channel
	681	(name) may only occur once in a very long while. However, with luck
	682	and patience, it is still possible for a user to cause a channel
	683	collision. In order to avoid this, servers MUST "look in the future"
	684	and keep a list of channel names which identifier is about to be used
	685	(in the coming few days for example). Such list should remain small,
	686	not be a burden for servers to maintain and be used to avoid channel
	687	collisions by preventing the re-creation of such channel for a longer
	688	period of time than channel delay does.
	689
	690	Eventually a server MAY choose to extend this procedure to forbid
	691	creation of channels with the same shortname only (then ignoring the
	692	channel identifier).
	693
	694	5.2.4 Preserving Sanity In The Name Space
	695
	696	The combination of the mechanisms described in sections 5.2.2 and
	697	5.2.3 makes it quite difficult for a user to create a channel
	698	collision. However, another type of abuse consists of creating many
	699	channels having the same shortname, but different identifiers. To
	700	prevent this from happening, servers MUST forbid the creation of a
	701	new channel which has the same shortname of a channel currently
	702	existing.
	703
	704	5.2.5 Server Reop Mechanism
	705
	706	When a channel has been opless for longer than the "reop delay"
	707	period and has the channel flag 'r' set (See Section 4.2.7 (Server
	708	Reop Flag)), IRC servers are responsible for giving the channel
	709	operator status randomly to some of the members.
	710
	711	The exact logic used for this mechanism by the current implementation
	712	is described below. Servers MAY use a different logic, but that it
	713	is strongly RECOMMENDED that all servers use the same logic on a
	714	particular IRC network to maintain coherence as well as fairness.
	715	For the same reason, the "reop delay" SHOULD be uniform on all
	716	servers for a given IRC network. As for the "channel delay", the
	717	value of the "reop delay" SHOULD be set considering many factors
	718	among which are the size (user wise) of the IRC network, and the
	719	usual duration of network splits.
	720
	721	a) the reop mechanism is triggered after a random time following the
	722	expiration of the "reop delay". This should limit the eventuality
	723	of the mechanism being triggered at the same time (for the same
	724	channel) on two separate servers.
	725
	726
	727
	728
	729	Kalt Informational [Page 13]
	730
	731	RFC 2811 Internet Relay Chat: Channel Management April 2000
	732
	733
	734	b) If the channel is small (five (5) users or less), and the "channel
	735	delay" for this channel has expired,
	736	Then reop all channel members if at least one member is local to
	737	the server.
	738
	739	c) If the channel is small (five (5) users or less), and the "channel
	740	delay" for this channel has expired, and the "reop delay" has
	741	expired for longer than its value,
	742	Then reop all channel members.
	743
	744	d) For other cases, reop at most one member on the channel, based on
	745	some method build into the server. If you don't reop a member, the
	746	method should be such that another server will probably op
	747	someone. The method SHOULD be the same over the whole network. A
	748	good heuristic could be just random reop.
	749	(The current implementation actually tries to choose a member
	750	local to the server who has not been idle for too long, eventually
	751	postponing action, therefore letting other servers have a chance
	752	to find a "not too idle" member. This is over complicated due to
	753	the fact that servers only know the "idle" time of their local
	754	users)
	755
	756	6. Current problems
	757
	758	There are a number of recognized problems with the way IRC channels
	759	are managed. Some of these can be directly attributed to the rules
	760	defined in this document, while others are the result of the
	761	underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from
	762	RFC 1459 [IRC], this document introduces several novelties in an
	763	attempt to solve some of the known problems.
	764
	765	6.1 Labels
	766
	767	This document defines one of the many labels used by the IRC
	768	protocol. Although there are several distinct namespaces (based on
	769	the channel name prefix), duplicates inside each of these are not
	770	allowed. Currently, it is possible for users on different servers to
	771	pick the label which may result in collisions (with the exception of
	772	channels known to only one server where they can be averted).
	773
	774	6.1.1 Channel Delay
	775
	776	The channel delay mechanism described in section 5.1 (Tracking
	777	Recently Used Channels) and used for channels prefixed with the
	778	character '#' is a simple attempt at preventing collisions from
	779	happening. Experience has shown that, under normal circumstances, it
	780
	781
	782
	783
	784
	785	Kalt Informational [Page 14]
	786
	787	RFC 2811 Internet Relay Chat: Channel Management April 2000
	788
	789
	790	is very efficient; however, it obviously has severe limitations
	791	keeping it from being an adequate solution to the problem discussed
	792	here.
	793
	794	6.1.2 Safe Channels
	795
	796	"Safe channels" described in section 3.2 (Safe Channels) are a better
	797	way to prevent collisions from happening as it prevents users from
	798	having total control over the label they choose. The obvious
	799	drawback for such labels is that they are not user friendly.
	800	However, it is fairly trivial for a client program to improve on
	801	this.
	802
	803	6.2 Mode Propagation Delays
	804
	805	Because of network delays induced by the network, and because each
	806	server on the path is REQUIRED to check the validity of mode changes
	807	(e.g., user exists and has the right privileges), it is not unusual
	808	for a MODE message to only affect part of the network, often creating
	809	a discrepancy between servers on the current state of a channel.
	810
	811	While this may seem easy to fix (by having only the original server
	812	check the validity of mode changes), it was decided not to do so for
	813	various reasons. One concern is that servers cannot trust each
	814	other, and that a misbehaving servers can easily be detected. This
	815	way of doing so also stops wave effects on channels which are out of
	816	synch when mode changes are issued from different directions.
	817
	818	6.3 Collisions And Channel Modes
	819
	820	The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
	821	describes how channel data is exchanged when two servers connect to
	822	each other. Channel collisions (either legitimate or not) are
	823	treated as inclusive events, meaning that the resulting channel has
	824	for members all the users who are members of the channel on either
	825	server prior to the connection.
	826
	827	Similarly, each server sends the channel modes to the other one.
	828	Therefore, each server also receives these channel modes. There are
	829	three types of modes for a given channel: flags, masks, and data.
	830	The first two types are easy to deal with as they are either set or
	831	unset. If such a mode is set on one server, it MUST be set on the
	832	other server as a result of the connection.
	833
	834
	835
	836
	837
	838
	839
	840
	841	Kalt Informational [Page 15]
	842
	843	RFC 2811 Internet Relay Chat: Channel Management April 2000
	844
	845
	846	As topics are not sent as part of this exchange, they are not a
	847	problem. However, channel modes 'l' and 'k' are exchanged, and if
	848	they are set on both servers prior to the connection, there is no
	849	mechanism to decide which of the two values takes precedence. It is
	850	left up to the users to fix the resulting discrepancy.
	851
	852	6.4 Resource Exhaustion
	853
	854	The mode based on masks defined in section 4.3 make the IRC servers
	855	(and network) vulnerable to a simple abuse of the system: a single
	856	channel operator can set as many different masks as possible on a
	857	particular channel. This can easily cause the server to waste
	858	memory, as well as network bandwidth (since the info is propagated to
	859	other servers). For this reason it is RECOMMENDED that a limit be
	860	put on the number of such masks per channels as mentioned in section
	861	4.3.
	862
	863	Moreover, more complex mechanisms MAY be used to avoid having
	864	redundant masks set for the same channel.
	865
	866	7. Security Considerations
	867
	868	7.1 Access Control
	869
	870	One of the main ways to control access to a channel is to use masks
	871	which are based on the username and hostname of the user connections.
	872	This mechanism can only be efficient and safe if the IRC servers have
	873	an accurate way of authenticating user connections, and if users
	874	cannot easily get around it. While it is in theory possible to
	875	implement such a strict authentication mechanism, most IRC networks
	876	(especially public networks) do not have anything like this in place
	877	and provide little guaranty about the accuracy of the username and
	878	hostname for a particular client connection.
	879
	880	Another way to control access is to use a channel key, but since this
	881	key is sent in plaintext, it is vulnerable to traditional man in the
	882	middle attacks.
	883
	884	7.2 Channel Privacy
	885
	886	Because channel collisions are treated as inclusive events (See
	887	Section 6.3), it is possible for users to join a channel overriding
	888	its access control settings. This method has long been used by
	889	individuals to "take over" channels by "illegitimately" gaining
	890	channel operator status on the channel. The same method can be used
	891	to find out the exact list of members of a channel, as well as to
	892	eventually receive some of the messages sent to the channel.
	893
	894
	895
	896
	897	Kalt Informational [Page 16]
	898
	899	RFC 2811 Internet Relay Chat: Channel Management April 2000
	900
	901
	902	7.3 Anonymity
	903
	904	The anonymous channel flag (See Section 4.2.1) can be used to render
	905	all users on such channel "anonymous" by presenting all messages to
	906	the channel as originating from a pseudo user which nickname is
	907	"anonymous". This is done at the client-server level, and no
	908	anonymity is provided at the server-server level.
	909
	910	It should be obvious to readers, that the level of anonymity offered
	911	is quite poor and insecure, and that clients SHOULD display strong
	912	warnings for users joining such channels.
	913
	914	8. Current support and availability
	915
	916	Mailing lists for IRC related discussion:
	917	General discussion: ircd-users@irc.org
	918	Protocol development: ircd-dev@irc.org
	919
	920	Software implementations:
	921	ftp://ftp.irc.org/irc/server
	922	ftp://ftp.funet.fi/pub/unix/irc
	923	ftp://coombs.anu.edu.au/pub/irc
	924
	925	Newsgroup: alt.irc
	926
	927	9. Acknowledgements
	928
	929	Parts of this document were copied from the RFC 1459 [IRC] which
	930	first formally documented the IRC Protocol. It has also benefited
	931	from many rounds of review and comments. In particular, the
	932	following people have made significant contributions to this
	933	document:
	934
	935	Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
	936	Ruokonen, Magnus Tjernstrom, Stefan Zehl.
	937
	938
	939
	940
	941
	942
	943
	944
	945
	946
	947
	948
	949
	950
	951
	952
	953	Kalt Informational [Page 17]
	954
	955	RFC 2811 Internet Relay Chat: Channel Management April 2000
	956
	957
	958	10. References
	959
	960	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	961	Requirement Levels", BCP 14, RFC 2119, March 1997.
	962
	963	[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
	964	Protocol", RFC 1459, May 1993.
	965
	966	[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
	967	April 2000.
	968
	969	[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
	970	2812, April 2000.
	971
	972	[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
	973	2813, April 2000.
	974
	975	11. Author's Address
	976
	977	Christophe Kalt
	978	99 Teaneck Rd, Apt #117
	979	Ridgefield Park, NJ 07660
	980	USA
	981
	982	EMail: kalt@stealth.net
	983
	984
	985
	986
	987
	988
	989
	990
	991
	992
	993
	994
	995
	996
	997
	998
	999
	1000
	1001
	1002
	1003
	1004
	1005
	1006
	1007
	1008
	1009	Kalt Informational [Page 18]
	1010
	1011	RFC 2811 Internet Relay Chat: Channel Management April 2000
	1012
	1013
	1014	12. Full Copyright Statement
	1015
	1016	Copyright (C) The Internet Society (2000). All Rights Reserved.
	1017
	1018	This document and translations of it may be copied and furnished to
	1019	others, and derivative works that comment on or otherwise explain it
	1020	or assist in its implementation may be prepared, copied, published
	1021	and distributed, in whole or in part, without restriction of any
	1022	kind, provided that the above copyright notice and this paragraph are
	1023	included on all such copies and derivative works. However, this
	1024	document itself may not be modified in any way, such as by removing
	1025	the copyright notice or references to the Internet Society or other
	1026	Internet organizations, except as needed for the purpose of
	1027	developing Internet standards in which case the procedures for
	1028	copyrights defined in the Internet Standards process must be
	1029	followed, or as required to translate it into languages other than
	1030	English.
	1031
	1032	The limited permissions granted above are perpetual and will not be
	1033	revoked by the Internet Society or its successors or assigns.
	1034
	1035	This document and the information contained herein is provided on an
	1036	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	1037	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	1038	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	1039	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	1040	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	1041
	1042	Acknowledgement
	1043
	1044	Funding for the RFC Editor function is currently provided by the
	1045	Internet Society.
	1046
	1047
	1048
	1049
	1050
	1051
	1052
	1053
	1054
	1055
	1056
	1057
	1058
	1059
	1060
	1061
	1062
	1063
	1064
	1065	Kalt Informational [Page 19]
	1066

+3531

-0

doc/rfc2812.txt less more

	0
	1
	2
	3
	4
	5
	6	Network Working Group C. Kalt
	7	Request for Comments: 2812 April 2000
	8	Updates: 1459
	9	Category: Informational
	10
	11
	12	Internet Relay Chat: Client Protocol
	13
	14	Status of this Memo
	15
	16	This memo provides information for the Internet community. It does
	17	not specify an Internet standard of any kind. Distribution of this
	18	memo is unlimited.
	19
	20	Copyright Notice
	21
	22	Copyright (C) The Internet Society (2000). All Rights Reserved.
	23
	24	IESG NOTE:
	25
	26	The IRC protocol itself enables several possibilities of transferring
	27	data between clients, and just like with other transfer mechanisms
	28	like email, the receiver of the data has to be careful about how the
	29	data is handled. For more information on security issues with the IRC
	30	protocol, see for example http://www.irchelp.org/irchelp/security/.
	31
	32	Abstract
	33
	34	The IRC (Internet Relay Chat) protocol is for use with text based
	35	conferencing; the simplest client being any socket program capable of
	36	connecting to the server.
	37
	38	This document defines the Client Protocol, and assumes that the
	39	reader is familiar with the IRC Architecture [IRC-ARCH].
	40
	41	Table of Contents
	42
	43	1. Labels ..................................................... 3
	44	1.1 Servers ................................................ 3
	45	1.2 Clients ................................................ 3
	46	1.2.1 Users ............................................. 4
	47	1.2.1.1 Operators .................................... 4
	48	1.2.2 Services .......................................... 4
	49	1.3 Channels ............................................... 4
	50	2. The IRC Client Specification ............................... 5
	51	2.1 Overview ............................................... 5
	52	2.2 Character codes ........................................ 5
	53	2.3 Messages ............................................... 5
	54
	55
	56
	57	Kalt Informational [Page 1]
	58
	59	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	60
	61
	62	2.3.1 Message format in Augmented BNF ................... 6
	63	2.4 Numeric replies ........................................ 8
	64	2.5 Wildcard expressions ................................... 9
	65	3. Message Details ............................................ 9
	66	3.1 Connection Registration ................................ 10
	67	3.1.1 Password message .................................. 10
	68	3.1.2 Nick message ...................................... 10
	69	3.1.3 User message ...................................... 11
	70	3.1.4 Oper message ...................................... 12
	71	3.1.5 User mode message ................................. 12
	72	3.1.6 Service message ................................... 13
	73	3.1.7 Quit .............................................. 14
	74	3.1.8 Squit ............................................. 15
	75	3.2 Channel operations ..................................... 15
	76	3.2.1 Join message ...................................... 16
	77	3.2.2 Part message ...................................... 17
	78	3.2.3 Channel mode message .............................. 18
	79	3.2.4 Topic message ..................................... 19
	80	3.2.5 Names message ..................................... 20
	81	3.2.6 List message ...................................... 21
	82	3.2.7 Invite message .................................... 21
	83	3.2.8 Kick command ...................................... 22
	84	3.3 Sending messages ....................................... 23
	85	3.3.1 Private messages .................................. 23
	86	3.3.2 Notice ............................................ 24
	87	3.4 Server queries and commands ............................ 25
	88	3.4.1 Motd message ...................................... 25
	89	3.4.2 Lusers message .................................... 25
	90	3.4.3 Version message ................................... 26
	91	3.4.4 Stats message ..................................... 26
	92	3.4.5 Links message ..................................... 27
	93	3.4.6 Time message ...................................... 28
	94	3.4.7 Connect message ................................... 28
	95	3.4.8 Trace message ..................................... 29
	96	3.4.9 Admin command ..................................... 30
	97	3.4.10 Info command ...................................... 31
	98	3.5 Service Query and Commands ............................. 31
	99	3.5.1 Servlist message .................................. 31
	100	3.5.2 Squery ............................................ 32
	101	3.6 User based queries ..................................... 32
	102	3.6.1 Who query ......................................... 32
	103	3.6.2 Whois query ....................................... 33
	104	3.6.3 Whowas ............................................ 34
	105	3.7 Miscellaneous messages ................................. 34
	106	3.7.1 Kill message ...................................... 35
	107	3.7.2 Ping message ...................................... 36
	108	3.7.3 Pong message ...................................... 37
	109	3.7.4 Error ............................................. 37
	110
	111
	112
	113	Kalt Informational [Page 2]
	114
	115	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	116
	117
	118	4. Optional features .......................................... 38
	119	4.1 Away ................................................... 38
	120	4.2 Rehash message ......................................... 39
	121	4.3 Die message ............................................ 39
	122	4.4 Restart message ........................................ 40
	123	4.5 Summon message ......................................... 40
	124	4.6 Users .................................................. 41
	125	4.7 Operwall message ....................................... 41
	126	4.8 Userhost message ....................................... 42
	127	4.9 Ison message ........................................... 42
	128	5. Replies .................................................... 43
	129	5.1 Command responses ...................................... 43
	130	5.2 Error Replies .......................................... 53
	131	5.3 Reserved numerics ...................................... 59
	132	6. Current implementations .................................... 60
	133	7. Current problems ........................................... 60
	134	7.1 Nicknames .............................................. 60
	135	7.2 Limitation of wildcards ................................ 61
	136	7.3 Security considerations ................................ 61
	137	8. Current support and availability ........................... 61
	138	9. Acknowledgements ........................................... 61
	139	10. References ................................................ 62
	140	11. Author's Address .......................................... 62
	141	12. Full Copyright Statement .................................. 63
	142
	143	1. Labels
	144
	145	This section defines the identifiers used for the various components
	146	of the IRC protocol.
	147
	148	1.1 Servers
	149
	150	Servers are uniquely identified by their name, which has a maximum
	151	length of sixty three (63) characters. See the protocol grammar
	152	rules (section 2.3.1) for what may and may not be used in a server
	153	name.
	154
	155	1.2 Clients
	156
	157	For each client all servers MUST have the following information: a
	158	netwide unique identifier (whose format depends on the type of
	159	client) and the server which introduced the client.
	160
	161
	162
	163
	164
	165
	166
	167
	168
	169	Kalt Informational [Page 3]
	170
	171	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	172
	173
	174	1.2.1 Users
	175
	176	Each user is distinguished from other users by a unique nickname
	177	having a maximum length of nine (9) characters. See the protocol
	178	grammar rules (section 2.3.1) for what may and may not be used in a
	179	nickname.
	180
	181	While the maximum length is limited to nine characters, clients
	182	SHOULD accept longer strings as they may become used in future
	183	evolutions of the protocol.
	184
	185	1.2.1.1 Operators
	186
	187	To allow a reasonable amount of order to be kept within the IRC
	188	network, a special class of users (operators) is allowed to perform
	189	general maintenance functions on the network. Although the powers
	190	granted to an operator can be considered as 'dangerous', they are
	191	nonetheless often necessary. Operators SHOULD be able to perform
	192	basic network tasks such as disconnecting and reconnecting servers as
	193	needed. In recognition of this need, the protocol discussed herein
	194	provides for operators only to be able to perform such functions.
	195	See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
	196
	197	A more controversial power of operators is the ability to remove a
	198	user from the connected network by 'force', i.e., operators are able
	199	to close the connection between any client and server. The
	200	justification for this is very delicate since its abuse is both
	201	destructive and annoying, and its benefits close to inexistent. For
	202	further details on this type of action, see section 3.7.1 (KILL).
	203
	204	1.2.2 Services
	205
	206	Each service is distinguished from other services by a service name
	207	composed of a nickname and a server name. As for users, the nickname
	208	has a maximum length of nine (9) characters. See the protocol
	209	grammar rules (section 2.3.1) for what may and may not be used in a
	210	nickname.
	211
	212	1.3 Channels
	213
	214	Channels names are strings (beginning with a '&', '#', '+' or '!'
	215	character) of length up to fifty (50) characters. Apart from the
	216	requirement that the first character is either '&', '#', '+' or '!',
	217	the only restriction on a channel name is that it SHALL NOT contain
	218	any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space
	219	is used as parameter separator and command is used as a list item
	220	separator by the protocol). A colon (':') can also be used as a
	221	delimiter for the channel mask. Channel names are case insensitive.
	222
	223
	224
	225	Kalt Informational [Page 4]
	226
	227	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	228
	229
	230	See the protocol grammar rules (section 2.3.1) for the exact syntax
	231	of a channel name.
	232
	233	Each prefix characterizes a different channel type. The definition
	234	of the channel types is not relevant to the client-server protocol
	235	and thus it is beyond the scope of this document. More details can
	236	be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
	237
	238	2. The IRC Client Specification
	239
	240	2.1 Overview
	241
	242	The protocol as described herein is for use only with client to
	243	server connections when the client registers as a user.
	244
	245	2.2 Character codes
	246
	247	No specific character set is specified. The protocol is based on a
	248	set of codes which are composed of eight (8) bits, making up an
	249	octet. Each message may be composed of any number of these octets;
	250	however, some octet values are used for control codes, which act as
	251	message delimiters.
	252
	253	Regardless of being an 8-bit protocol, the delimiters and keywords
	254	are such that protocol is mostly usable from US-ASCII terminal and a
	255	telnet connection.
	256
	257	Because of IRC's Scandinavian origin, the characters {}\|^ are
	258	considered to be the lower case equivalents of the characters []\~,
	259	respectively. This is a critical issue when determining the
	260	equivalence of two nicknames or channel names.
	261
	262	2.3 Messages
	263
	264	Servers and clients send each other messages, which may or may not
	265	generate a reply. If the message contains a valid command, as
	266	described in later sections, the client should expect a reply as
	267	specified but it is not advised to wait forever for the reply; client
	268	to server and server to server communication is essentially
	269	asynchronous by nature.
	270
	271	Each IRC message may consist of up to three main parts: the prefix
	272	(OPTIONAL), the command, and the command parameters (maximum of
	273	fifteen (15)). The prefix, command, and all parameters are separated
	274	by one ASCII space character (0x20) each.
	275
	276
	277
	278
	279
	280
	281	Kalt Informational [Page 5]
	282
	283	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	284
	285
	286	The presence of a prefix is indicated with a single leading ASCII
	287	colon character (':', 0x3b), which MUST be the first character of the
	288	message itself. There MUST be NO gap (whitespace) between the colon
	289	and the prefix. The prefix is used by servers to indicate the true
	290	origin of the message. If the prefix is missing from the message, it
	291	is assumed to have originated from the connection from which it was
	292	received from. Clients SHOULD NOT use a prefix when sending a
	293	message; if they use one, the only valid prefix is the registered
	294	nickname associated with the client.
	295
	296	The command MUST either be a valid IRC command or a three (3) digit
	297	number represented in ASCII text.
	298
	299	IRC messages are always lines of characters terminated with a CR-LF
	300	(Carriage Return - Line Feed) pair, and these messages SHALL NOT
	301	exceed 512 characters in length, counting all characters including
	302	the trailing CR-LF. Thus, there are 510 characters maximum allowed
	303	for the command and its parameters. There is no provision for
	304	continuation of message lines. See section 6 for more details about
	305	current implementations.
	306
	307	2.3.1 Message format in Augmented BNF
	308
	309	The protocol messages must be extracted from the contiguous stream of
	310	octets. The current solution is to designate two characters, CR and
	311	LF, as message separators. Empty messages are silently ignored,
	312	which permits use of the sequence CR-LF between messages without
	313	extra problems.
	314
	315	The extracted message is parsed into the components <prefix>,
	316	<command> and list of parameters (<params>).
	317
	318	The Augmented BNF representation for this is:
	319
	320	message = [ ":" prefix SPACE ] command [ params ] crlf
	321	prefix = servername / ( nickname [ [ "!" user ] "@" host ] )
	322	command = 1*letter / 3digit
	323	params = *14( SPACE middle ) [ SPACE ":" trailing ]
	324	=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
	325
	326	nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
	327	; any octet except NUL, CR, LF, " " and ":"
	328	middle = nospcrlfcl *( ":" / nospcrlfcl )
	329	trailing = *( ":" / " " / nospcrlfcl )
	330
	331	SPACE = %x20 ; space character
	332	crlf = %x0D %x0A ; "carriage return" "linefeed"
	333
	334
	335
	336
	337	Kalt Informational [Page 6]
	338
	339	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	340
	341
	342	NOTES:
	343	1) After extracting the parameter list, all parameters are equal
	344	whether matched by <middle> or <trailing>. <trailing> is just a
	345	syntactic trick to allow SPACE within the parameter.
	346
	347	2) The NUL (%x00) character is not special in message framing, and
	348	basically could end up inside a parameter, but it would cause
	349	extra complexities in normal C string handling. Therefore, NUL
	350	is not allowed within messages.
	351
	352	Most protocol messages specify additional semantics and syntax for
	353	the extracted parameter strings dictated by their position in the
	354	list. For example, many server commands will assume that the first
	355	parameter after the command is the list of targets, which can be
	356	described with:
	357
	358	target = nickname / server
	359	msgtarget = msgto *( "," msgto )
	360	msgto = channel / ( user [ "%" host ] "@" servername )
	361	msgto =/ ( user "%" host ) / targetmask
	362	msgto =/ nickname / ( nickname "!" user "@" host )
	363	channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
	364	[ ":" chanstring ]
	365	servername = hostname
	366	host = hostname / hostaddr
	367	hostname = shortname *( "." shortname )
	368	shortname = ( letter / digit ) *( letter / digit / "-" )
	369	*( letter / digit )
	370	; as specified in RFC 1123 [HNAME]
	371	hostaddr = ip4addr / ip6addr
	372	ip4addr = 13digit "." 13digit "." 13digit "." 13digit
	373	ip6addr = 1hexdigit 7( ":" 1hexdigit )
	374	ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
	375	nickname = ( letter / special ) *8( letter / digit / special / "-" )
	376	targetmask = ( "$" / "#" ) mask
	377	; see details on allowed masks in section 3.3.1
	378	chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
	379	chanstring =/ %x2D-39 / %x3B-FF
	380	; any octet except NUL, BELL, CR, LF, " ", "," and ":"
	381	channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 )
	382
	383
	384
	385
	386
	387
	388
	389
	390
	391
	392
	393	Kalt Informational [Page 7]
	394
	395	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	396
	397
	398	Other parameter syntaxes are:
	399
	400	user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
	401	; any octet except NUL, CR, LF, " " and "@"
	402	key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
	403	; any 7-bit US_ASCII character,
	404	; except NUL, CR, LF, FF, h/v TABs, and " "
	405	letter = %x41-5A / %x61-7A ; A-Z / a-z
	406	digit = %x30-39 ; 0-9
	407	hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F"
	408	special = %x5B-60 / %x7B-7D
	409	; "[", "]", "\", "`", "_", "^", "{", "\|", "}"
	410
	411	NOTES:
	412	1) The <hostaddr> syntax is given here for the sole purpose of
	413	indicating the format to follow for IP addresses. This
	414	reflects the fact that the only available implementations of
	415	this protocol uses TCP/IP as underlying network protocol but is
	416	not meant to prevent other protocols to be used.
	417
	418	2) <hostname> has a maximum length of 63 characters. This is a
	419	limitation of the protocol as internet hostnames (in
	420	particular) can be longer. Such restriction is necessary
	421	because IRC messages are limited to 512 characters in length.
	422	Clients connecting from a host which name is longer than 63
	423	characters are registered using the host (numeric) address
	424	instead of the host name.
	425
	426	3) Some parameters used in the following sections of this
	427	documents are not defined here as there is nothing specific
	428	about them besides the name that is used for convenience.
	429	These parameters follow the general syntax defined for
	430	<params>.
	431
	432	2.4 Numeric replies
	433
	434	Most of the messages sent to the server generate a reply of some
	435	sort. The most common reply is the numeric reply, used for both
	436	errors and normal replies. The numeric reply MUST be sent as one
	437	message consisting of the sender prefix, the three-digit numeric, and
	438	the target of the reply. A numeric reply is not allowed to originate
	439	from a client. In all other respects, a numeric reply is just like a
	440	normal message, except that the keyword is made up of 3 numeric
	441	digits rather than a string of letters. A list of different replies
	442	is supplied in section 5 (Replies).
	443
	444
	445
	446
	447
	448
	449	Kalt Informational [Page 8]
	450
	451	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	452
	453
	454	2.5 Wildcard expressions
	455
	456	When wildcards are allowed in a string, it is referred as a "mask".
	457
	458	For string matching purposes, the protocol allows the use of two
	459	special characters: '?' (%x3F) to match one and only one character,
	460	and '*' (%x2A) to match any number of any characters. These two
	461	characters can be escaped using the character '\' (%x5C).
	462
	463	The Augmented BNF syntax for this is:
	464
	465	mask = *( nowild / noesc wildone / noesc wildmany )
	466	wildone = %x3F
	467	wildmany = %x2A
	468	nowild = %x01-29 / %x2B-3E / %x40-FF
	469	; any octet except NUL, "*", "?"
	470	noesc = %x01-5B / %x5D-FF
	471	; any octet except NUL and "\"
	472	matchone = %x01-FF
	473	; matches wildone
	474	matchmany = *matchone
	475	; matches wildmany
	476
	477	Examples:
	478
	479	a?c ; Matches any string of 3 characters in length starting
	480	with "a" and ending with "c"
	481
	482	a*c ; Matches any string of at least 2 characters in length
	483	starting with "a" and ending with "c"
	484
	485	3. Message Details
	486
	487	On the following pages there are descriptions of each message
	488	recognized by the IRC server and client. All commands described in
	489	this section MUST be implemented by any server for this protocol.
	490
	491	Where the reply ERR_NOSUCHSERVER is returned, it means that the
	492	target of the message could not be found. The server MUST NOT send
	493	any other replies after this error for that command.
	494
	495	The server to which a client is connected is required to parse the
	496	complete message, and return any appropriate errors.
	497
	498	If multiple parameters is presented, then each MUST be checked for
	499	validity and appropriate responses MUST be sent back to the client.
	500	In the case of incorrect messages which use parameter lists with
	501	comma as an item separator, a reply MUST be sent for each item.
	502
	503
	504
	505	Kalt Informational [Page 9]
	506
	507	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	508
	509
	510	3.1 Connection Registration
	511
	512	The commands described here are used to register a connection with an
	513	IRC server as a user as well as to correctly disconnect.
	514
	515	A "PASS" command is not required for a client connection to be
	516	registered, but it MUST precede the latter of the NICK/USER
	517	combination (for a user connection) or the SERVICE command (for a
	518	service connection). The RECOMMENDED order for a client to register
	519	is as follows:
	520
	521	1. Pass message
	522	2. Nick message 2. Service message
	523	3. User message
	524
	525	Upon success, the client will receive an RPL_WELCOME (for users) or
	526	RPL_YOURESERVICE (for services) message indicating that the
	527	connection is now registered and known the to the entire IRC network.
	528	The reply message MUST contain the full client identifier upon which
	529	it was registered.
	530
	531	3.1.1 Password message
	532
	533	Command: PASS
	534	Parameters: <password>
	535
	536	The PASS command is used to set a 'connection password'. The
	537	optional password can and MUST be set before any attempt to register
	538	the connection is made. Currently this requires that user send a
	539	PASS command before sending the NICK/USER combination.
	540
	541	Numeric Replies:
	542
	543	ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
	544
	545	Example:
	546
	547	PASS secretpasswordhere
	548
	549	3.1.2 Nick message
	550
	551
	552	Command: NICK
	553	Parameters: <nickname>
	554
	555	NICK command is used to give user a nickname or change the existing
	556	one.
	557
	558
	559
	560
	561	Kalt Informational [Page 10]
	562
	563	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	564
	565
	566	Numeric Replies:
	567
	568	ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
	569	ERR_NICKNAMEINUSE ERR_NICKCOLLISION
	570	ERR_UNAVAILRESOURCE ERR_RESTRICTED
	571
	572	Examples:
	573
	574	NICK Wiz ; Introducing new nick "Wiz" if session is
	575	still unregistered, or user changing his
	576	nickname to "Wiz"
	577
	578	:WiZ!jto@tolsun.oulu.fi NICK Kilroy
	579	; Server telling that WiZ changed his
	580	nickname to Kilroy.
	581
	582	3.1.3 User message
	583
	584	Command: USER
	585	Parameters: <user> <mode> <unused> <realname>
	586
	587	The USER command is used at the beginning of connection to specify
	588	the username, hostname and realname of a new user.
	589
	590	The <mode> parameter should be a numeric, and can be used to
	591	automatically set user modes when registering with the server. This
	592	parameter is a bitmask, with only 2 bits having any signification: if
	593	the bit 2 is set, the user mode 'w' will be set and if the bit 3 is
	594	set, the user mode 'i' will be set. (See Section 3.1.5 "User
	595	Modes").
	596
	597	The <realname> may contain space characters.
	598
	599	Numeric Replies:
	600
	601	ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
	602
	603	Example:
	604
	605	USER guest 0 * :Ronnie Reagan ; User registering themselves with a
	606	username of "guest" and real name
	607	"Ronnie Reagan".
	608
	609	USER guest 8 * :Ronnie Reagan ; User registering themselves with a
	610	username of "guest" and real name
	611	"Ronnie Reagan", and asking to be set
	612	invisible.
	613
	614
	615
	616
	617	Kalt Informational [Page 11]
	618
	619	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	620
	621
	622	3.1.4 Oper message
	623
	624	Command: OPER
	625	Parameters: <name> <password>
	626
	627	A normal user uses the OPER command to obtain operator privileges.
	628	The combination of <name> and <password> are REQUIRED to gain
	629	Operator privileges. Upon success, the user will receive a MODE
	630	message (see section 3.1.5) indicating the new user modes.
	631
	632	Numeric Replies:
	633
	634	ERR_NEEDMOREPARAMS RPL_YOUREOPER
	635	ERR_NOOPERHOST ERR_PASSWDMISMATCH
	636
	637	Example:
	638
	639	OPER foo bar ; Attempt to register as an operator
	640	using a username of "foo" and "bar"
	641	as the password.
	642
	643	3.1.5 User mode message
	644
	645	Command: MODE
	646	Parameters: <nickname>
	647	( ( "+" / "-" ) ( "i" / "w" / "o" / "O" / "r" ) )
	648
	649	The user MODE's are typically changes which affect either how the
	650	client is seen by others or what 'extra' messages the client is sent.
	651
	652	A user MODE command MUST only be accepted if both the sender of the
	653	message and the nickname given as a parameter are both the same. If
	654	no other parameter is given, then the server will return the current
	655	settings for the nick.
	656
	657	The available modes are as follows:
	658
	659	a - user is flagged as away;
	660	i - marks a users as invisible;
	661	w - user receives wallops;
	662	r - restricted user connection;
	663	o - operator flag;
	664	O - local operator flag;
	665	s - marks a user for receipt of server notices.
	666
	667	Additional modes may be available later on.
	668
	669
	670
	671
	672
	673	Kalt Informational [Page 12]
	674
	675	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	676
	677
	678	The flag 'a' SHALL NOT be toggled by the user using the MODE command,
	679	instead use of the AWAY command is REQUIRED.
	680
	681	If a user attempts to make themselves an operator using the "+o" or
	682	"+O" flag, the attempt SHOULD be ignored as users could bypass the
	683	authentication mechanisms of the OPER command. There is no
	684	restriction, however, on anyone `deopping' themselves (using "-o" or
	685	"-O").
	686
	687	On the other hand, if a user attempts to make themselves unrestricted
	688	using the "-r" flag, the attempt SHOULD be ignored. There is no
	689	restriction, however, on anyone `deopping' themselves (using "+r").
	690	This flag is typically set by the server upon connection for
	691	administrative reasons. While the restrictions imposed are left up
	692	to the implementation, it is typical that a restricted user not be
	693	allowed to change nicknames, nor make use of the channel operator
	694	status on channels.
	695
	696	The flag 's' is obsolete but MAY still be used.
	697
	698	Numeric Replies:
	699
	700	ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH
	701	ERR_UMODEUNKNOWNFLAG RPL_UMODEIS
	702
	703	Examples:
	704
	705	MODE WiZ -w ; Command by WiZ to turn off
	706	reception of WALLOPS messages.
	707
	708	MODE Angel +i ; Command from Angel to make herself
	709	invisible.
	710
	711	MODE WiZ -o ; WiZ 'deopping' (removing operator
	712	status).
	713
	714	3.1.6 Service message
	715
	716	Command: SERVICE
	717	Parameters: <nickname> <reserved> <distribution> <type>
	718	<reserved> <info>
	719
	720	The SERVICE command to register a new service. Command parameters
	721	specify the service nickname, distribution, type and info of a new
	722	service.
	723
	724
	725
	726
	727
	728
	729	Kalt Informational [Page 13]
	730
	731	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	732
	733
	734	The <distribution> parameter is used to specify the visibility of a
	735	service. The service may only be known to servers which have a name
	736	matching the distribution. For a matching server to have knowledge
	737	of the service, the network path between that server and the server
	738	on which the service is connected MUST be composed of servers which
	739	names all match the mask.
	740
	741	The <type> parameter is currently reserved for future usage.
	742
	743	Numeric Replies:
	744
	745	ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
	746	ERR_ERRONEUSNICKNAME
	747	RPL_YOURESERVICE RPL_YOURHOST
	748	RPL_MYINFO
	749
	750	Example:
	751
	752	SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
	753	itself with a name of "dict". This
	754	service will only be available on
	755	servers which name matches "*.fr".
	756
	757	3.1.7 Quit
	758
	759	Command: QUIT
	760	Parameters: [ <Quit Message> ]
	761
	762	A client session is terminated with a quit message. The server
	763	acknowledges this by sending an ERROR message to the client.
	764
	765	Numeric Replies:
	766
	767	None.
	768
	769	Example:
	770
	771	QUIT :Gone to have lunch ; Preferred message format.
	772
	773	:syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
	774	syrk has quit IRC to have lunch.
	775
	776
	777
	778
	779
	780
	781
	782
	783
	784
	785	Kalt Informational [Page 14]
	786
	787	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	788
	789
	790	3.1.8 Squit
	791
	792	Command: SQUIT
	793	Parameters: <server> <comment>
	794
	795	The SQUIT command is available only to operators. It is used to
	796	disconnect server links. Also servers can generate SQUIT messages on
	797	error conditions. A SQUIT message may also target a remote server
	798	connection. In this case, the SQUIT message will simply be sent to
	799	the remote server without affecting the servers in between the
	800	operator and the remote server.
	801
	802	The <comment> SHOULD be supplied by all operators who execute a SQUIT
	803	for a remote server. The server ordered to disconnect its peer
	804	generates a WALLOPS message with <comment> included, so that other
	805	users may be aware of the reason of this action.
	806
	807	Numeric replies:
	808
	809	ERR_NOPRIVILEGES ERR_NOSUCHSERVER
	810	ERR_NEEDMOREPARAMS
	811
	812	Examples:
	813
	814	SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server
	815	tolson.oulu.fi to terminate its
	816	connection with comment "Bad Link".
	817
	818	:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
	819	from Trillian from to disconnect
	820	"cm22.eng.umd.edu" from the net with
	821	comment "Server out of control".
	822
	823	3.2 Channel operations
	824
	825	This group of messages is concerned with manipulating channels, their
	826	properties (channel modes), and their contents (typically users).
	827	For this reason, these messages SHALL NOT be made available to
	828	services.
	829
	830	All of these messages are requests which will or will not be granted
	831	by the server. The server MUST send a reply informing the user
	832	whether the request was granted, denied or generated an error. When
	833	the server grants the request, the message is typically sent back
	834	(eventually reformatted) to the user with the prefix set to the user
	835	itself.
	836
	837
	838
	839
	840
	841	Kalt Informational [Page 15]
	842
	843	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	844
	845
	846	The rules governing how channels are managed are enforced by the
	847	servers. These rules are beyond the scope of this document. More
	848	details are found in "Internet Relay Chat: Channel Management" [IRC-
	849	CHAN].
	850
	851	3.2.1 Join message
	852
	853	Command: JOIN
	854	Parameters: ( <channel> ( "," <channel> ) [ <key> ( "," <key> ) ] )
	855	/ "0"
	856
	857	The JOIN command is used by a user to request to start listening to
	858	the specific channel. Servers MUST be able to parse arguments in the
	859	form of a list of target, but SHOULD NOT use lists when sending JOIN
	860	messages to clients.
	861
	862	Once a user has joined a channel, he receives information about
	863	all commands his server receives affecting the channel. This
	864	includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
	865	This allows channel members to keep track of the other channel
	866	members, as well as channel modes.
	867
	868	If a JOIN is successful, the user receives a JOIN message as
	869	confirmation and is then sent the channel's topic (using RPL_TOPIC) and
	870	the list of users who are on the channel (using RPL_NAMREPLY), which
	871	MUST include the user joining.
	872
	873	Note that this message accepts a special argument ("0"), which is
	874	a special request to leave all channels the user is currently a member
	875	of. The server will process this message as if the user had sent
	876	a PART command (See Section 3.2.2) for each channel he is a member
	877	of.
	878
	879	Numeric Replies:
	880
	881	ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
	882	ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
	883	ERR_CHANNELISFULL ERR_BADCHANMASK
	884	ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
	885	ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
	886	RPL_TOPIC
	887
	888	Examples:
	889
	890	JOIN #foobar ; Command to join channel #foobar.
	891
	892	JOIN &foo fubar ; Command to join channel &foo using
	893	key "fubar".
	894
	895
	896
	897	Kalt Informational [Page 16]
	898
	899	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	900
	901
	902	JOIN #foo,&bar fubar ; Command to join channel #foo using
	903	key "fubar" and &bar using no key.
	904
	905	JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using
	906	key "fubar", and channel #bar using
	907	key "foobar".
	908
	909	JOIN #foo,#bar ; Command to join channels #foo and
	910	#bar.
	911
	912	JOIN 0 ; Leave all currently joined
	913	channels.
	914
	915	:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
	916	on channel #Twilight_zone
	917
	918	3.2.2 Part message
	919
	920	Command: PART
	921	Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
	922
	923	The PART command causes the user sending the message to be removed
	924	from the list of active members for all given channels listed in the
	925	parameter string. If a "Part Message" is given, this will be sent
	926	instead of the default message, the nickname. This request is always
	927	granted by the server.
	928
	929	Servers MUST be able to parse arguments in the form of a list of
	930	target, but SHOULD NOT use lists when sending PART messages to
	931	clients.
	932
	933	Numeric Replies:
	934
	935	ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
	936	ERR_NOTONCHANNEL
	937
	938	Examples:
	939
	940	PART #twilight_zone ; Command to leave channel
	941	"#twilight_zone"
	942
	943	PART #oz-ops,&group5 ; Command to leave both channels
	944	"&group5" and "#oz-ops".
	945
	946	:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
	947	; User WiZ leaving channel
	948	"#playzone" with the message "I
	949	lost".
	950
	951
	952
	953	Kalt Informational [Page 17]
	954
	955	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	956
	957
	958	3.2.3 Channel mode message
	959
	960	Command: MODE
	961	Parameters: <channel> ( ( "-" / "+" ) <modes> *<modeparams> )
	962
	963	The MODE command is provided so that users may query and change the
	964	characteristics of a channel. For more details on available modes
	965	and their uses, see "Internet Relay Chat: Channel Management" [IRC-
	966	CHAN]. Note that there is a maximum limit of three (3) changes per
	967	command for modes that take a parameter.
	968
	969	Numeric Replies:
	970
	971	ERR_NEEDMOREPARAMS ERR_KEYSET
	972	ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED
	973	ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE
	974	RPL_CHANNELMODEIS
	975	RPL_BANLIST RPL_ENDOFBANLIST
	976	RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST
	977	RPL_INVITELIST RPL_ENDOFINVITELIST
	978	RPL_UNIQOPIS
	979
	980	The following examples are given to help understanding the syntax of
	981	the MODE command, but refer to modes defined in "Internet Relay Chat:
	982	Channel Management" [IRC-CHAN].
	983
	984	Examples:
	985
	986	MODE #Finnish +imI !@*.fi ; Command to make #Finnish channel
	987	moderated and 'invite-only' with user
	988	with a hostname matching *.fi
	989	automatically invited.
	990
	991	MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges
	992	to Kilroy on channel #Finnish.
	993
	994	MODE #Finnish +v Wiz ; Command to allow WiZ to speak on
	995	#Finnish.
	996
	997	MODE #Fins -s ; Command to remove 'secret' flag
	998	from channel #Fins.
	999
	1000	MODE #42 +k oulu ; Command to set the channel key to
	1001	"oulu".
	1002
	1003	MODE #42 -k oulu ; Command to remove the "oulu"
	1004	channel key on channel "#42".
	1005
	1006
	1007
	1008
	1009	Kalt Informational [Page 18]
	1010
	1011	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1012
	1013
	1014	MODE #eu-opers +l 10 ; Command to set the limit for the
	1015	number of users on channel
	1016	"#eu-opers" to 10.
	1017
	1018	:WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
	1019	; User "WiZ" removing the limit for
	1020	the number of users on channel "#eu-
	1021	opers".
	1022
	1023	MODE &oulu +b ; Command to list ban masks set for
	1024	the channel "&oulu".
	1025
	1026	MODE &oulu +b !@* ; Command to prevent all users from
	1027	joining.
	1028
	1029	MODE &oulu +b !@.edu +e !@.bu.edu
	1030	; Command to prevent any user from a
	1031	hostname matching *.edu from joining,
	1032	except if matching *.bu.edu
	1033
	1034	MODE #bu +be !@.edu !@.bu.edu
	1035	; Comment to prevent any user from a
	1036	hostname matching *.edu from joining,
	1037	except if matching *.bu.edu
	1038
	1039	MODE #meditation e ; Command to list exception masks set
	1040	for the channel "#meditation".
	1041
	1042	MODE #meditation I ; Command to list invitations masks
	1043	set for the channel "#meditation".
	1044
	1045	MODE !12345ircd O ; Command to ask who the channel
	1046	creator for "!12345ircd" is
	1047
	1048	3.2.4 Topic message
	1049
	1050	Command: TOPIC
	1051	Parameters: <channel> [ <topic> ]
	1052
	1053	The TOPIC command is used to change or view the topic of a channel.
	1054	The topic for channel <channel> is returned if there is no <topic>
	1055	given. If the <topic> parameter is present, the topic for that
	1056	channel will be changed, if this action is allowed for the user
	1057	requesting it. If the <topic> parameter is an empty string, the
	1058	topic for that channel will be removed.
	1059
	1060
	1061
	1062
	1063
	1064
	1065	Kalt Informational [Page 19]
	1066
	1067	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1068
	1069
	1070	Numeric Replies:
	1071
	1072	ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
	1073	RPL_NOTOPIC RPL_TOPIC
	1074	ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES
	1075
	1076	Examples:
	1077
	1078	:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
	1079	topic.
	1080
	1081	TOPIC #test :another topic ; Command to set the topic on #test
	1082	to "another topic".
	1083
	1084	TOPIC #test : ; Command to clear the topic on
	1085	#test.
	1086
	1087	TOPIC #test ; Command to check the topic for
	1088	#test.
	1089
	1090	3.2.5 Names message
	1091
	1092	Command: NAMES
	1093	Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
	1094
	1095	By using the NAMES command, a user can list all nicknames that are
	1096	visible to him. For more details on what is visible and what is not,
	1097	see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The
	1098	<channel> parameter specifies which channel(s) to return information
	1099	about. There is no error reply for bad channel names.
	1100
	1101	If no <channel> parameter is given, a list of all channels and their
	1102	occupants is returned. At the end of this list, a list of users who
	1103	are visible but either not on any channel or not on a visible channel
	1104	are listed as being on `channel' "*".
	1105
	1106	If the <target> parameter is specified, the request is forwarded to
	1107	that server which will generate the reply.
	1108
	1109	Wildcards are allowed in the <target> parameter.
	1110
	1111	Numerics:
	1112
	1113	ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
	1114	RPL_NAMREPLY RPL_ENDOFNAMES
	1115
	1116
	1117
	1118
	1119
	1120
	1121	Kalt Informational [Page 20]
	1122
	1123	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1124
	1125
	1126	Examples:
	1127
	1128	NAMES #twilight_zone,#42 ; Command to list visible users on
	1129	#twilight_zone and #42
	1130
	1131	NAMES ; Command to list all visible
	1132	channels and users
	1133
	1134	3.2.6 List message
	1135
	1136	Command: LIST
	1137	Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
	1138
	1139	The list command is used to list channels and their topics. If the
	1140	<channel> parameter is used, only the status of that channel is
	1141	displayed.
	1142
	1143	If the <target> parameter is specified, the request is forwarded to
	1144	that server which will generate the reply.
	1145
	1146	Wildcards are allowed in the <target> parameter.
	1147
	1148	Numeric Replies:
	1149
	1150	ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
	1151	RPL_LIST RPL_LISTEND
	1152
	1153	Examples:
	1154
	1155	LIST ; Command to list all channels.
	1156
	1157	LIST #twilight_zone,#42 ; Command to list channels
	1158	#twilight_zone and #42
	1159
	1160	3.2.7 Invite message
	1161
	1162	Command: INVITE
	1163	Parameters: <nickname> <channel>
	1164
	1165	The INVITE command is used to invite a user to a channel. The
	1166	parameter <nickname> is the nickname of the person to be invited to
	1167	the target channel <channel>. There is no requirement that the
	1168	channel the target user is being invited to must exist or be a valid
	1169	channel. However, if the channel exists, only members of the channel
	1170	are allowed to invite other users. When the channel has invite-only
	1171	flag set, only channel operators may issue INVITE command.
	1172
	1173
	1174
	1175
	1176
	1177	Kalt Informational [Page 21]
	1178
	1179	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1180
	1181
	1182	Only the user inviting and the user being invited will receive
	1183	notification of the invitation. Other channel members are not
	1184	notified. (This is unlike the MODE changes, and is occasionally the
	1185	source of trouble for users.)
	1186
	1187	Numeric Replies:
	1188
	1189	ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
	1190	ERR_NOTONCHANNEL ERR_USERONCHANNEL
	1191	ERR_CHANOPRIVSNEEDED
	1192	RPL_INVITING RPL_AWAY
	1193
	1194	Examples:
	1195
	1196	:Angel!wings@irc.org INVITE Wiz #Dust
	1197
	1198	; Message to WiZ when he has been
	1199	invited by user Angel to channel
	1200	#Dust
	1201
	1202	INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
	1203	#Twilight_zone
	1204
	1205	3.2.8 Kick command
	1206
	1207	Command: KICK
	1208	Parameters: <channel> ( "," <channel> ) <user> ( "," <user> )
	1209	[<comment>]
	1210
	1211	The KICK command can be used to request the forced removal of a user
	1212	from a channel. It causes the <user> to PART from the <channel> by
	1213	force. For the message to be syntactically correct, there MUST be
	1214	either one channel parameter and multiple user parameter, or as many
	1215	channel parameters as there are user parameters. If a "comment" is
	1216	given, this will be sent instead of the default message, the nickname
	1217	of the user issuing the KICK.
	1218
	1219	The server MUST NOT send KICK messages with multiple channels or
	1220	users to clients. This is necessarily to maintain backward
	1221	compatibility with old client software.
	1222
	1223	Numeric Replies:
	1224
	1225	ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
	1226	ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
	1227	ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL
	1228
	1229
	1230
	1231
	1232
	1233	Kalt Informational [Page 22]
	1234
	1235	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1236
	1237
	1238	Examples:
	1239
	1240	KICK &Melbourne Matthew ; Command to kick Matthew from
	1241	&Melbourne
	1242
	1243	KICK #Finnish John :Speaking English
	1244	; Command to kick John from #Finnish
	1245	using "Speaking English" as the
	1246	reason (comment).
	1247
	1248	:WiZ!jto@tolsun.oulu.fi KICK #Finnish John
	1249	; KICK message on channel #Finnish
	1250	from WiZ to remove John from channel
	1251
	1252	3.3 Sending messages
	1253
	1254	The main purpose of the IRC protocol is to provide a base for clients
	1255	to communicate with each other. PRIVMSG, NOTICE and SQUERY
	1256	(described in Section 3.5 on Service Query and Commands) are the only
	1257	messages available which actually perform delivery of a text message
	1258	from one client to another - the rest just make it possible and try
	1259	to ensure it happens in a reliable and structured manner.
	1260
	1261	3.3.1 Private messages
	1262
	1263	Command: PRIVMSG
	1264	Parameters: <msgtarget> <text to be sent>
	1265
	1266	PRIVMSG is used to send private messages between users, as well as to
	1267	send messages to channels. <msgtarget> is usually the nickname of
	1268	the recipient of the message, or a channel name.
	1269
	1270	The <msgtarget> parameter may also be a host mask (#<mask>) or server
	1271	mask ($<mask>). In both cases the server will only send the PRIVMSG
	1272	to those who have a server or host matching the mask. The mask MUST
	1273	have at least 1 (one) "." in it and no wildcards following the last
	1274	".". This requirement exists to prevent people sending messages to
	1275	"#" or "$", which would broadcast to all users. Wildcards are the
	1276	'*' and '?' characters. This extension to the PRIVMSG command is
	1277	only available to operators.
	1278
	1279	Numeric Replies:
	1280
	1281	ERR_NORECIPIENT ERR_NOTEXTTOSEND
	1282	ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
	1283	ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
	1284	ERR_NOSUCHNICK
	1285	RPL_AWAY
	1286
	1287
	1288
	1289	Kalt Informational [Page 23]
	1290
	1291	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1292
	1293
	1294	Examples:
	1295
	1296	:Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
	1297	; Message from Angel to Wiz.
	1298
	1299	PRIVMSG Angel :yes I'm receiving it !
	1300	; Command to send a message to Angel.
	1301
	1302	PRIVMSG jto@tolsun.oulu.fi :Hello !
	1303	; Command to send a message to a user
	1304	on server tolsun.oulu.fi with
	1305	username of "jto".
	1306
	1307	PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
	1308	; Message to a user on server
	1309	irc.stealth.net with username of
	1310	"kalt", and connected from the host
	1311	millennium.stealth.net.
	1312
	1313	PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
	1314	; Message to a user on the local
	1315	server with username of "kalt", and
	1316	connected from the host
	1317	millennium.stealth.net.
	1318
	1319	PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
	1320	; Message to the user with nickname
	1321	Wiz who is connected from the host
	1322	tolsun.oulu.fi and has the username
	1323	"jto".
	1324
	1325	PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
	1326	; Message to everyone on a server
	1327	which has a name matching *.fi.
	1328
	1329	PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
	1330	; Message to all users who come from
	1331	a host which has a name matching
	1332	*.edu.
	1333
	1334	3.3.2 Notice
	1335
	1336	Command: NOTICE
	1337	Parameters: <msgtarget> <text>
	1338
	1339	The NOTICE command is used similarly to PRIVMSG. The difference
	1340	between NOTICE and PRIVMSG is that automatic replies MUST NEVER be
	1341	sent in response to a NOTICE message. This rule applies to servers
	1342
	1343
	1344
	1345	Kalt Informational [Page 24]
	1346
	1347	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1348
	1349
	1350	too - they MUST NOT send any error reply back to the client on
	1351	receipt of a notice. The object of this rule is to avoid loops
	1352	between clients automatically sending something in response to
	1353	something it received.
	1354
	1355	This command is available to services as well as users.
	1356
	1357	This is typically used by services, and automatons (clients with
	1358	either an AI or other interactive program controlling their actions).
	1359
	1360	See PRIVMSG for more details on replies and examples.
	1361
	1362	3.4 Server queries and commands
	1363
	1364	The server query group of commands has been designed to return
	1365	information about any server which is connected to the network.
	1366
	1367	In these queries, where a parameter appears as <target>, wildcard
	1368	masks are usually valid. For each parameter, however, only one query
	1369	and set of replies is to be generated. In most cases, if a nickname
	1370	is given, it will mean the server to which the user is connected.
	1371
	1372	These messages typically have little value for services, it is
	1373	therefore RECOMMENDED to forbid services from using them.
	1374
	1375	3.4.1 Motd message
	1376
	1377	Command: MOTD
	1378	Parameters: [ <target> ]
	1379
	1380	The MOTD command is used to get the "Message Of The Day" of the given
	1381	server, or current server if <target> is omitted.
	1382
	1383	Wildcards are allowed in the <target> parameter.
	1384
	1385	Numeric Replies:
	1386	RPL_MOTDSTART RPL_MOTD
	1387	RPL_ENDOFMOTD ERR_NOMOTD
	1388
	1389	3.4.2 Lusers message
	1390
	1391	Command: LUSERS
	1392	Parameters: [ <mask> [ <target> ] ]
	1393
	1394	The LUSERS command is used to get statistics about the size of the
	1395	IRC network. If no parameter is given, the reply will be about the
	1396	whole net. If a <mask> is specified, then the reply will only
	1397
	1398
	1399
	1400
	1401	Kalt Informational [Page 25]
	1402
	1403	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1404
	1405
	1406	concern the part of the network formed by the servers matching the
	1407	mask. Finally, if the <target> parameter is specified, the request
	1408	is forwarded to that server which will generate the reply.
	1409
	1410	Wildcards are allowed in the <target> parameter.
	1411
	1412	Numeric Replies:
	1413
	1414	RPL_LUSERCLIENT RPL_LUSEROP
	1415	RPL_LUSERUNKOWN RPL_LUSERCHANNELS
	1416	RPL_LUSERME ERR_NOSUCHSERVER
	1417
	1418	3.4.3 Version message
	1419
	1420	Command: VERSION
	1421	Parameters: [ <target> ]
	1422
	1423	The VERSION command is used to query the version of the server
	1424	program. An optional parameter <target> is used to query the version
	1425	of the server program which a client is not directly connected to.
	1426
	1427	Wildcards are allowed in the <target> parameter.
	1428
	1429	Numeric Replies:
	1430
	1431	ERR_NOSUCHSERVER RPL_VERSION
	1432
	1433	Examples:
	1434
	1435	VERSION tolsun.oulu.fi ; Command to check the version of
	1436	server "tolsun.oulu.fi".
	1437
	1438	3.4.4 Stats message
	1439
	1440	Command: STATS
	1441	Parameters: [ <query> [ <target> ] ]
	1442
	1443	The stats command is used to query statistics of certain server. If
	1444	<query> parameter is omitted, only the end of stats reply is sent
	1445	back.
	1446
	1447	A query may be given for any single letter which is only checked by
	1448	the destination server and is otherwise passed on by intermediate
	1449	servers, ignored and unaltered.
	1450
	1451	Wildcards are allowed in the <target> parameter.
	1452
	1453
	1454
	1455
	1456
	1457	Kalt Informational [Page 26]
	1458
	1459	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1460
	1461
	1462	Except for the ones below, the list of valid queries is
	1463	implementation dependent. The standard queries below SHOULD be
	1464	supported by the server:
	1465
	1466	l - returns a list of the server's connections, showing how
	1467	long each connection has been established and the
	1468	traffic over that connection in Kbytes and messages for
	1469	each direction;
	1470	m - returns the usage count for each of commands supported
	1471	by the server; commands for which the usage count is
	1472	zero MAY be omitted;
	1473	o - returns a list of configured privileged users,
	1474	operators;
	1475	u - returns a string showing how long the server has been
	1476	up.
	1477
	1478	It is also RECOMMENDED that client and server access configuration be
	1479	published this way.
	1480
	1481	Numeric Replies:
	1482
	1483	ERR_NOSUCHSERVER
	1484	RPL_STATSLINKINFO RPL_STATSUPTIME
	1485	RPL_STATSCOMMANDS RPL_STATSOLINE
	1486	RPL_ENDOFSTATS
	1487
	1488	Examples:
	1489
	1490	STATS m ; Command to check the command usage
	1491	for the server you are connected to
	1492
	1493	3.4.5 Links message
	1494
	1495	Command: LINKS
	1496	Parameters: [ [ <remote server> ] <server mask> ]
	1497
	1498	With LINKS, a user can list all servernames, which are known by the
	1499	server answering the query. The returned list of servers MUST match
	1500	the mask, or if no mask is given, the full list is returned.
	1501
	1502	If <remote server> is given in addition to <server mask>, the LINKS
	1503	command is forwarded to the first server found that matches that name
	1504	(if any), and that server is then required to answer the query.
	1505
	1506	Numeric Replies:
	1507
	1508	ERR_NOSUCHSERVER
	1509	RPL_LINKS RPL_ENDOFLINKS
	1510
	1511
	1512
	1513	Kalt Informational [Page 27]
	1514
	1515	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1516
	1517
	1518	Examples:
	1519
	1520	LINKS *.au ; Command to list all servers which
	1521	have a name that matches *.au;
	1522
	1523	LINKS .edu .bu.edu ; Command to list servers matching
	1524	*.bu.edu as seen by the first server
	1525	matching *.edu.
	1526
	1527	3.4.6 Time message
	1528
	1529	Command: TIME
	1530	Parameters: [ <target> ]
	1531
	1532	The time command is used to query local time from the specified
	1533	server. If the <target> parameter is not given, the server receiving
	1534	the command must reply to the query.
	1535
	1536	Wildcards are allowed in the <target> parameter.
	1537
	1538	Numeric Replies:
	1539
	1540	ERR_NOSUCHSERVER RPL_TIME
	1541
	1542	Examples:
	1543	TIME tolsun.oulu.fi ; check the time on the server
	1544	"tolson.oulu.fi"
	1545
	1546	3.4.7 Connect message
	1547
	1548	Command: CONNECT
	1549	Parameters: <target server> <port> [ <remote server> ]
	1550
	1551	The CONNECT command can be used to request a server to try to
	1552	establish a new connection to another server immediately. CONNECT is
	1553	a privileged command and SHOULD be available only to IRC Operators.
	1554	If a <remote server> is given and its mask doesn't match name of the
	1555	parsing server, the CONNECT attempt is sent to the first match of
	1556	remote server. Otherwise the CONNECT attempt is made by the server
	1557	processing the request.
	1558
	1559	The server receiving a remote CONNECT command SHOULD generate a
	1560	WALLOPS message describing the source and target of the request.
	1561
	1562	Numeric Replies:
	1563
	1564	ERR_NOSUCHSERVER ERR_NOPRIVILEGES
	1565	ERR_NEEDMOREPARAMS
	1566
	1567
	1568
	1569	Kalt Informational [Page 28]
	1570
	1571	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1572
	1573
	1574	Examples:
	1575
	1576	CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local
	1577	server to tolsun.oulu.fi on port 6667
	1578
	1579	3.4.8 Trace message
	1580
	1581	Command: TRACE
	1582	Parameters: [ <target> ]
	1583
	1584	TRACE command is used to find the route to specific server and
	1585	information about its peers. Each server that processes this command
	1586	MUST report to the sender about it. The replies from pass-through
	1587	links form a chain, which shows route to destination. After sending
	1588	this reply back, the query MUST be sent to the next server until
	1589	given <target> server is reached.
	1590
	1591	TRACE command is used to find the route to specific server. Each
	1592	server that processes this message MUST tell the sender about it by
	1593	sending a reply indicating it is a pass-through link, forming a chain
	1594	of replies. After sending this reply back, it MUST then send the
	1595	TRACE message to the next server until given server is reached. If
	1596	the <target> parameter is omitted, it is RECOMMENDED that TRACE
	1597	command sends a message to the sender telling which servers the local
	1598	server has direct connection to.
	1599
	1600	If the destination given by <target> is an actual server, the
	1601	destination server is REQUIRED to report all servers, services and
	1602	operators which are connected to it; if the command was issued by an
	1603	operator, the server MAY also report all users which are connected to
	1604	it. If the destination given by <target> is a nickname, then only a
	1605	reply for that nickname is given. If the <target> parameter is
	1606	omitted, it is RECOMMENDED that the TRACE command is parsed as
	1607	targeted to the processing server.
	1608
	1609	Wildcards are allowed in the <target> parameter.
	1610
	1611	Numeric Replies:
	1612
	1613	ERR_NOSUCHSERVER
	1614
	1615	If the TRACE message is destined for another server, all
	1616	intermediate servers must return a RPL_TRACELINK reply to indicate
	1617	that the TRACE passed through it and where it is going next.
	1618
	1619	RPL_TRACELINK
	1620
	1621
	1622
	1623
	1624
	1625	Kalt Informational [Page 29]
	1626
	1627	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1628
	1629
	1630	A TRACE reply may be composed of any number of the following
	1631	numeric replies.
	1632
	1633	RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
	1634	RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
	1635	RPL_TRACEUSER RPL_TRACESERVER
	1636	RPL_TRACESERVICE RPL_TRACENEWTYPE
	1637	RPL_TRACECLASS RPL_TRACELOG
	1638	RPL_TRACEEND
	1639
	1640	Examples:
	1641
	1642	TRACE *.oulu.fi ; TRACE to a server matching
	1643	*.oulu.fi
	1644
	1645	3.4.9 Admin command
	1646
	1647	Command: ADMIN
	1648	Parameters: [ <target> ]
	1649
	1650	The admin command is used to find information about the administrator
	1651	of the given server, or current server if <target> parameter is
	1652	omitted. Each server MUST have the ability to forward ADMIN messages
	1653	to other servers.
	1654
	1655	Wildcards are allowed in the <target> parameter.
	1656
	1657	Numeric Replies:
	1658
	1659	ERR_NOSUCHSERVER
	1660	RPL_ADMINME RPL_ADMINLOC1
	1661	RPL_ADMINLOC2 RPL_ADMINEMAIL
	1662
	1663	Examples:
	1664
	1665	ADMIN tolsun.oulu.fi ; request an ADMIN reply from
	1666	tolsun.oulu.fi
	1667
	1668	ADMIN syrk ; ADMIN request for the server to
	1669	which the user syrk is connected
	1670
	1671
	1672
	1673
	1674
	1675
	1676
	1677
	1678
	1679
	1680
	1681	Kalt Informational [Page 30]
	1682
	1683	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1684
	1685
	1686	3.4.10 Info command
	1687
	1688	Command: INFO
	1689	Parameters: [ <target> ]
	1690
	1691	The INFO command is REQUIRED to return information describing the
	1692	server: its version, when it was compiled, the patchlevel, when it
	1693	was started, and any other miscellaneous information which may be
	1694	considered to be relevant.
	1695
	1696	Wildcards are allowed in the <target> parameter.
	1697
	1698	Numeric Replies:
	1699
	1700	ERR_NOSUCHSERVER
	1701	RPL_INFO RPL_ENDOFINFO
	1702
	1703	Examples:
	1704
	1705	INFO csd.bu.edu ; request an INFO reply from
	1706	csd.bu.edu
	1707
	1708	INFO Angel ; request info from the server that
	1709	Angel is connected to.
	1710
	1711	3.5 Service Query and Commands
	1712
	1713	The service query group of commands has been designed to return
	1714	information about any service which is connected to the network.
	1715
	1716	3.5.1 Servlist message
	1717
	1718	Command: SERVLIST
	1719	Parameters: [ <mask> [ <type> ] ]
	1720
	1721	The SERVLIST command is used to list services currently connected to
	1722	the network and visible to the user issuing the command. The
	1723	optional parameters may be used to restrict the result of the query
	1724	(to matching services names, and services type).
	1725
	1726	Numeric Replies:
	1727
	1728	RPL_SERVLIST RPL_SERVLISTEND
	1729
	1730
	1731
	1732
	1733
	1734
	1735
	1736
	1737	Kalt Informational [Page 31]
	1738
	1739	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1740
	1741
	1742	3.5.2 Squery
	1743
	1744	Command: SQUERY
	1745	Parameters: <servicename> <text>
	1746
	1747	The SQUERY command is used similarly to PRIVMSG. The only difference
	1748	is that the recipient MUST be a service. This is the only way for a
	1749	text message to be delivered to a service.
	1750
	1751	See PRIVMSG for more details on replies and example.
	1752
	1753	Examples:
	1754
	1755	SQUERY irchelp :HELP privmsg
	1756	; Message to the service with
	1757	nickname irchelp.
	1758
	1759	SQUERY dict@irc.fr :fr2en blaireau
	1760	; Message to the service with name
	1761	dict@irc.fr.
	1762
	1763	3.6 User based queries
	1764
	1765	User queries are a group of commands which are primarily concerned
	1766	with finding details on a particular user or group users. When using
	1767	wildcards with any of these commands, if they match, they will only
	1768	return information on users who are 'visible' to you. The visibility
	1769	of a user is determined as a combination of the user's mode and the
	1770	common set of channels you are both on.
	1771
	1772	Although services SHOULD NOT be using this class of message, they are
	1773	allowed to.
	1774
	1775	3.6.1 Who query
	1776
	1777	Command: WHO
	1778	Parameters: [ <mask> [ "o" ] ]
	1779
	1780	The WHO command is used by a client to generate a query which returns
	1781	a list of information which 'matches' the <mask> parameter given by
	1782	the client. In the absence of the <mask> parameter, all visible
	1783	(users who aren't invisible (user mode +i) and who don't have a
	1784	common channel with the requesting client) are listed. The same
	1785	result can be achieved by using a <mask> of "0" or any wildcard which
	1786	will end up matching every visible user.
	1787
	1788	The <mask> passed to WHO is matched against users' host, server, real
	1789	name and nickname if the channel <mask> cannot be found.
	1790
	1791
	1792
	1793	Kalt Informational [Page 32]
	1794
	1795	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1796
	1797
	1798	If the "o" parameter is passed only operators are returned according
	1799	to the <mask> supplied.
	1800
	1801	Numeric Replies:
	1802
	1803	ERR_NOSUCHSERVER
	1804	RPL_WHOREPLY RPL_ENDOFWHO
	1805
	1806	Examples:
	1807
	1808	WHO *.fi ; Command to list all users who match
	1809	against "*.fi".
	1810
	1811	WHO jto* o ; Command to list all users with a
	1812	match against "jto*" if they are an
	1813	operator.
	1814
	1815	3.6.2 Whois query
	1816
	1817	Command: WHOIS
	1818	Parameters: [ <target> ] <mask> *( "," <mask> )
	1819
	1820	This command is used to query information about particular user.
	1821	The server will answer this command with several numeric messages
	1822	indicating different statuses of each user which matches the mask (if
	1823	you are entitled to see them). If no wildcard is present in the
	1824	<mask>, any information about that nick which you are allowed to see
	1825	is presented.
	1826
	1827	If the <target> parameter is specified, it sends the query to a
	1828	specific server. It is useful if you want to know how long the user
	1829	in question has been idle as only local server (i.e., the server the
	1830	user is directly connected to) knows that information, while
	1831	everything else is globally known.
	1832
	1833	Wildcards are allowed in the <target> parameter.
	1834
	1835	Numeric Replies:
	1836
	1837	ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
	1838	RPL_WHOISUSER RPL_WHOISCHANNELS
	1839	RPL_WHOISCHANNELS RPL_WHOISSERVER
	1840	RPL_AWAY RPL_WHOISOPERATOR
	1841	RPL_WHOISIDLE ERR_NOSUCHNICK
	1842	RPL_ENDOFWHOIS
	1843
	1844
	1845
	1846
	1847
	1848
	1849	Kalt Informational [Page 33]
	1850
	1851	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1852
	1853
	1854	Examples:
	1855
	1856	WHOIS wiz ; return available user information
	1857	about nick WiZ
	1858
	1859	WHOIS eff.org trillian ; ask server eff.org for user
	1860	information about trillian
	1861
	1862	3.6.3 Whowas
	1863
	1864	Command: WHOWAS
	1865	Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
	1866
	1867	Whowas asks for information about a nickname which no longer exists.
	1868	This may either be due to a nickname change or the user leaving IRC.
	1869	In response to this query, the server searches through its nickname
	1870	history, looking for any nicks which are lexically the same (no wild
	1871	card matching here). The history is searched backward, returning the
	1872	most recent entry first. If there are multiple entries, up to
	1873	<count> replies will be returned (or all of them if no <count>
	1874	parameter is given). If a non-positive number is passed as being
	1875	<count>, then a full search is done.
	1876
	1877	Wildcards are allowed in the <target> parameter.
	1878
	1879	Numeric Replies:
	1880
	1881	ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
	1882	RPL_WHOWASUSER RPL_WHOISSERVER
	1883	RPL_ENDOFWHOWAS
	1884
	1885	Examples:
	1886
	1887	WHOWAS Wiz ; return all information in the nick
	1888	history about nick "WiZ";
	1889
	1890	WHOWAS Mermaid 9 ; return at most, the 9 most recent
	1891	entries in the nick history for
	1892	"Mermaid";
	1893
	1894	WHOWAS Trillian 1 *.edu ; return the most recent history for
	1895	"Trillian" from the first server
	1896	found to match "*.edu".
	1897
	1898	3.7 Miscellaneous messages
	1899
	1900	Messages in this category do not fit into any of the above categories
	1901	but are nonetheless still a part of and REQUIRED by the protocol.
	1902
	1903
	1904
	1905	Kalt Informational [Page 34]
	1906
	1907	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1908
	1909
	1910	3.7.1 Kill message
	1911
	1912	Command: KILL
	1913	Parameters: <nickname> <comment>
	1914
	1915	The KILL command is used to cause a client-server connection to be
	1916	closed by the server which has the actual connection. Servers
	1917	generate KILL messages on nickname collisions. It MAY also be
	1918	available available to users who have the operator status.
	1919
	1920	Clients which have automatic reconnect algorithms effectively make
	1921	this command useless since the disconnection is only brief. It does
	1922	however break the flow of data and can be used to stop large amounts
	1923	of 'flooding' from abusive users or accidents. Abusive users usually
	1924	don't care as they will reconnect promptly and resume their abusive
	1925	behaviour. To prevent this command from being abused, any user may
	1926	elect to receive KILL messages generated for others to keep an 'eye'
	1927	on would be trouble spots.
	1928
	1929	In an arena where nicknames are REQUIRED to be globally unique at all
	1930	times, KILL messages are sent whenever 'duplicates' are detected
	1931	(that is an attempt to register two users with the same nickname) in
	1932	the hope that both of them will disappear and only 1 reappear.
	1933
	1934	When a client is removed as the result of a KILL message, the server
	1935	SHOULD add the nickname to the list of unavailable nicknames in an
	1936	attempt to avoid clients to reuse this name immediately which is
	1937	usually the pattern of abusive behaviour often leading to useless
	1938	"KILL loops". See the "IRC Server Protocol" document [IRC-SERVER]
	1939	for more information on this procedure.
	1940
	1941	The comment given MUST reflect the actual reason for the KILL. For
	1942	server-generated KILLs it usually is made up of details concerning
	1943	the origins of the two conflicting nicknames. For users it is left
	1944	up to them to provide an adequate reason to satisfy others who see
	1945	it. To prevent/discourage fake KILLs from being generated to hide
	1946	the identify of the KILLer, the comment also shows a 'kill-path'
	1947	which is updated by each server it passes through, each prepending
	1948	its name to the path.
	1949
	1950	Numeric Replies:
	1951
	1952	ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
	1953	ERR_NOSUCHNICK ERR_CANTKILLSERVER
	1954
	1955
	1956
	1957
	1958
	1959
	1960
	1961	Kalt Informational [Page 35]
	1962
	1963	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	1964
	1965
	1966	NOTE:
	1967	It is RECOMMENDED that only Operators be allowed to kill other users
	1968	with KILL command. This command has been the subject of many
	1969	controversies over the years, and along with the above
	1970	recommendation, it is also widely recognized that not even operators
	1971	should be allowed to kill users on remote servers.
	1972
	1973	3.7.2 Ping message
	1974
	1975	Command: PING
	1976	Parameters: <server1> [ <server2> ]
	1977
	1978	The PING command is used to test the presence of an active client or
	1979	server at the other end of the connection. Servers send a PING
	1980	message at regular intervals if no other activity detected coming
	1981	from a connection. If a connection fails to respond to a PING
	1982	message within a set amount of time, that connection is closed. A
	1983	PING message MAY be sent even if the connection is active.
	1984
	1985	When a PING message is received, the appropriate PONG message MUST be
	1986	sent as reply to <server1> (server which sent the PING message out)
	1987	as soon as possible. If the <server2> parameter is specified, it
	1988	represents the target of the ping, and the message gets forwarded
	1989	there.
	1990
	1991	Numeric Replies:
	1992
	1993	ERR_NOORIGIN ERR_NOSUCHSERVER
	1994
	1995	Examples:
	1996
	1997	PING tolsun.oulu.fi ; Command to send a PING message to
	1998	server
	1999
	2000	PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING
	2001	message to server "tolsun.oulu.fi"
	2002
	2003	PING :irc.funet.fi ; Ping message sent by server
	2004	"irc.funet.fi"
	2005
	2006
	2007
	2008
	2009
	2010
	2011
	2012
	2013
	2014
	2015
	2016
	2017	Kalt Informational [Page 36]
	2018
	2019	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2020
	2021
	2022	3.7.3 Pong message
	2023
	2024	Command: PONG
	2025	Parameters: <server> [ <server2> ]
	2026
	2027	PONG message is a reply to ping message. If parameter <server2> is
	2028	given, this message MUST be forwarded to given target. The <server>
	2029	parameter is the name of the entity who has responded to PING message
	2030	and generated this message.
	2031
	2032	Numeric Replies:
	2033
	2034	ERR_NOORIGIN ERR_NOSUCHSERVER
	2035
	2036	Example:
	2037
	2038	PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
	2039	tolsun.oulu.fi
	2040
	2041	3.7.4 Error
	2042
	2043	Command: ERROR
	2044	Parameters: <error message>
	2045
	2046	The ERROR command is for use by servers when reporting a serious or
	2047	fatal error to its peers. It may also be sent from one server to
	2048	another but MUST NOT be accepted from any normal unknown clients.
	2049
	2050	Only an ERROR message SHOULD be used for reporting errors which occur
	2051	with a server-to-server link. An ERROR message is sent to the server
	2052	at the other end (which reports it to appropriate local users and
	2053	logs) and to appropriate local users and logs. It is not to be
	2054	passed onto any other servers by a server if it is received from a
	2055	server.
	2056
	2057	The ERROR message is also used before terminating a client
	2058	connection.
	2059
	2060	When a server sends a received ERROR message to its operators, the
	2061	message SHOULD be encapsulated inside a NOTICE message, indicating
	2062	that the client was not responsible for the error.
	2063
	2064	Numerics:
	2065
	2066	None.
	2067
	2068
	2069
	2070
	2071
	2072
	2073	Kalt Informational [Page 37]
	2074
	2075	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2076
	2077
	2078	Examples:
	2079
	2080	ERROR :Server *.fi already exists ; ERROR message to the other server
	2081	which caused this error.
	2082
	2083	NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
	2084	; Same ERROR message as above but
	2085	sent to user WiZ on the other server.
	2086
	2087	4. Optional features
	2088
	2089	This section describes OPTIONAL messages. They are not required in a
	2090	working server implementation of the protocol described herein. In
	2091	the absence of the feature, an error reply message MUST be generated
	2092	or an unknown command error. If the message is destined for another
	2093	server to answer then it MUST be passed on (elementary parsing
	2094	REQUIRED) The allocated numerics for this are listed with the
	2095	messages below.
	2096
	2097	From this section, only the USERHOST and ISON messages are available
	2098	to services.
	2099
	2100	4.1 Away
	2101
	2102	Command: AWAY
	2103	Parameters: [ <text> ]
	2104
	2105	With the AWAY command, clients can set an automatic reply string for
	2106	any PRIVMSG commands directed at them (not to a channel they are on).
	2107	The server sends an automatic reply to the client sending the PRIVMSG
	2108	command. The only replying server is the one to which the sending
	2109	client is connected to.
	2110
	2111	The AWAY command is used either with one parameter, to set an AWAY
	2112	message, or with no parameters, to remove the AWAY message.
	2113
	2114	Because of its high cost (memory and bandwidth wise), the AWAY
	2115	message SHOULD only be used for client-server communication. A
	2116	server MAY choose to silently ignore AWAY messages received from
	2117	other servers. To update the away status of a client across servers,
	2118	the user mode 'a' SHOULD be used instead. (See Section 3.1.5)
	2119
	2120	Numeric Replies:
	2121
	2122	RPL_UNAWAY RPL_NOWAWAY
	2123
	2124
	2125
	2126
	2127
	2128
	2129	Kalt Informational [Page 38]
	2130
	2131	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2132
	2133
	2134	Example:
	2135
	2136	AWAY :Gone to lunch. Back in 5 ; Command to set away message to
	2137	"Gone to lunch. Back in 5".
	2138
	2139	4.2 Rehash message
	2140
	2141	Command: REHASH
	2142	Parameters: None
	2143
	2144	The rehash command is an administrative command which can be used by
	2145	an operator to force the server to re-read and process its
	2146	configuration file.
	2147
	2148	Numeric Replies:
	2149
	2150	RPL_REHASHING ERR_NOPRIVILEGES
	2151
	2152
	2153	Example:
	2154
	2155	REHASH ; message from user with operator
	2156	status to server asking it to reread
	2157	its configuration file.
	2158
	2159	4.3 Die message
	2160
	2161	Command: DIE
	2162	Parameters: None
	2163
	2164	An operator can use the DIE command to shutdown the server. This
	2165	message is optional since it may be viewed as a risk to allow
	2166	arbitrary people to connect to a server as an operator and execute
	2167	this command.
	2168
	2169	The DIE command MUST always be fully processed by the server to which
	2170	the sending client is connected and MUST NOT be passed onto other
	2171	connected servers.
	2172
	2173	Numeric Replies:
	2174
	2175	ERR_NOPRIVILEGES
	2176
	2177	Example:
	2178
	2179	DIE ; no parameters required.
	2180
	2181
	2182
	2183
	2184
	2185	Kalt Informational [Page 39]
	2186
	2187	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2188
	2189
	2190	4.4 Restart message
	2191
	2192	Command: RESTART
	2193	Parameters: None
	2194
	2195	An operator can use the restart command to force the server to
	2196	restart itself. This message is optional since it may be viewed as a
	2197	risk to allow arbitrary people to connect to a server as an operator
	2198	and execute this command, causing (at least) a disruption to service.
	2199
	2200	The RESTART command MUST always be fully processed by the server to
	2201	which the sending client is connected and MUST NOT be passed onto
	2202	other connected servers.
	2203
	2204	Numeric Replies:
	2205
	2206	ERR_NOPRIVILEGES
	2207
	2208	Example:
	2209
	2210	RESTART ; no parameters required.
	2211
	2212	4.5 Summon message
	2213
	2214	Command: SUMMON
	2215	Parameters: <user> [ <target> [ <channel> ] ]
	2216
	2217	The SUMMON command can be used to give users who are on a host
	2218	running an IRC server a message asking them to please join IRC. This
	2219	message is only sent if the target server (a) has SUMMON enabled, (b)
	2220	the user is logged in and (c) the server process can write to the
	2221	user's tty (or similar).
	2222
	2223	If no <server> parameter is given it tries to summon <user> from the
	2224	server the client is connected to is assumed as the target.
	2225
	2226	If summon is not enabled in a server, it MUST return the
	2227	ERR_SUMMONDISABLED numeric.
	2228
	2229	Numeric Replies:
	2230
	2231	ERR_NORECIPIENT ERR_FILEERROR
	2232	ERR_NOLOGIN ERR_NOSUCHSERVER
	2233	ERR_SUMMONDISABLED RPL_SUMMONING
	2234
	2235
	2236
	2237
	2238
	2239
	2240
	2241	Kalt Informational [Page 40]
	2242
	2243	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2244
	2245
	2246	Examples:
	2247
	2248	SUMMON jto ; summon user jto on the server's
	2249	host
	2250
	2251	SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
	2252	server named "tolsun.oulu.fi" is
	2253	running.
	2254
	2255	4.6 Users
	2256
	2257	Command: USERS
	2258	Parameters: [ <target> ]
	2259
	2260	The USERS command returns a list of users logged into the server in a
	2261	format similar to the UNIX commands who(1), rusers(1) and finger(1).
	2262	If disabled, the correct numeric MUST be returned to indicate this.
	2263
	2264	Because of the security implications of such a command, it SHOULD be
	2265	disabled by default in server implementations. Enabling it SHOULD
	2266	require recompiling the server or some equivalent change rather than
	2267	simply toggling an option and restarting the server. The procedure
	2268	to enable this command SHOULD also include suitable large comments.
	2269
	2270	Numeric Replies:
	2271
	2272	ERR_NOSUCHSERVER ERR_FILEERROR
	2273	RPL_USERSSTART RPL_USERS
	2274	RPL_NOUSERS RPL_ENDOFUSERS
	2275	ERR_USERSDISABLED
	2276
	2277	Disabled Reply:
	2278
	2279	ERR_USERSDISABLED
	2280
	2281	Example:
	2282
	2283	USERS eff.org ; request a list of users logged in
	2284	on server eff.org
	2285
	2286	4.7 Operwall message
	2287
	2288	Command: WALLOPS
	2289	Parameters: <Text to be sent>
	2290
	2291	The WALLOPS command is used to send a message to all currently
	2292	connected users who have set the 'w' user mode for themselves. (See
	2293	Section 3.1.5 "User modes").
	2294
	2295
	2296
	2297	Kalt Informational [Page 41]
	2298
	2299	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2300
	2301
	2302	After implementing WALLOPS as a user command it was found that it was
	2303	often and commonly abused as a means of sending a message to a lot of
	2304	people. Due to this, it is RECOMMENDED that the implementation of
	2305	WALLOPS allows and recognizes only servers as the originators of
	2306	WALLOPS.
	2307
	2308	Numeric Replies:
	2309
	2310	ERR_NEEDMOREPARAMS
	2311
	2312	Example:
	2313
	2314	:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
	2315	message from csd.bu.edu announcing a
	2316	CONNECT message it received from
	2317	Joshua and acted upon.
	2318
	2319	4.8 Userhost message
	2320
	2321	Command: USERHOST
	2322	Parameters: <nickname> *( SPACE <nickname> )
	2323
	2324	The USERHOST command takes a list of up to 5 nicknames, each
	2325	separated by a space character and returns a list of information
	2326	about each nickname that it found. The returned list has each reply
	2327	separated by a space.
	2328
	2329	Numeric Replies:
	2330
	2331	RPL_USERHOST ERR_NEEDMOREPARAMS
	2332
	2333	Example:
	2334
	2335	USERHOST Wiz Michael syrk ; USERHOST request for information on
	2336	nicks "Wiz", "Michael", and "syrk"
	2337
	2338	:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
	2339	; Reply for user syrk
	2340
	2341	4.9 Ison message
	2342
	2343	Command: ISON
	2344	Parameters: <nickname> *( SPACE <nickname> )
	2345
	2346	The ISON command was implemented to provide a quick and efficient
	2347	means to get a response about whether a given nickname was currently
	2348	on IRC. ISON only takes one (1) type of parameter: a space-separated
	2349	list of nicks. For each nickname in the list that is present, the
	2350
	2351
	2352
	2353	Kalt Informational [Page 42]
	2354
	2355	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2356
	2357
	2358	server adds that to its reply string. Thus the reply string may
	2359	return empty (none of the given nicks are present), an exact copy of
	2360	the parameter string (all of them present) or any other subset of the
	2361	set of nicks given in the parameter. The only limit on the number of
	2362	nicks that may be checked is that the combined length MUST NOT be too
	2363	large as to cause the server to chop it off so it fits in 512
	2364	characters.
	2365
	2366	ISON is only processed by the server local to the client sending the
	2367	command and thus not passed onto other servers for further
	2368	processing.
	2369
	2370	Numeric Replies:
	2371
	2372	RPL_ISON ERR_NEEDMOREPARAMS
	2373
	2374	Example:
	2375
	2376	ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
	2377	; Sample ISON request for 7 nicks.
	2378
	2379	5. Replies
	2380
	2381	The following is a list of numeric replies which are generated in
	2382	response to the commands given above. Each numeric is given with its
	2383	number, name and reply string.
	2384
	2385	5.1 Command responses
	2386
	2387	Numerics in the range from 001 to 099 are used for client-server
	2388	connections only and should never travel between servers. Replies
	2389	generated in the response to commands are found in the range from 200
	2390	to 399.
	2391
	2392	001 RPL_WELCOME
	2393	"Welcome to the Internet Relay Network
	2394	<nick>!<user>@<host>"
	2395	002 RPL_YOURHOST
	2396	"Your host is <servername>, running version <ver>"
	2397	003 RPL_CREATED
	2398	"This server was created <date>"
	2399	004 RPL_MYINFO
	2400	"<servername> <version> <available user modes>
	2401	<available channel modes>"
	2402
	2403	- The server sends Replies 001 to 004 to a user upon
	2404	successful registration.
	2405
	2406
	2407
	2408
	2409	Kalt Informational [Page 43]
	2410
	2411	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2412
	2413
	2414	005 RPL_BOUNCE
	2415	"Try server <server name>, port <port number>"
	2416
	2417	- Sent by the server to a user to suggest an alternative
	2418	server. This is often used when the connection is
	2419	refused because the server is already full.
	2420
	2421	302 RPL_USERHOST
	2422	":1<reply> ( " " <reply> )"
	2423
	2424	- Reply format used by USERHOST to list replies to
	2425	the query list. The reply string is composed as
	2426	follows:
	2427
	2428	reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname
	2429
	2430	The '*' indicates whether the client has registered
	2431	as an Operator. The '-' or '+' characters represent
	2432	whether the client has set an AWAY message or not
	2433	respectively.
	2434
	2435	303 RPL_ISON
	2436	":1<nick> ( " " <nick> )"
	2437
	2438	- Reply format used by ISON to list replies to the
	2439	query list.
	2440
	2441	301 RPL_AWAY
	2442	"<nick> :<away message>"
	2443	305 RPL_UNAWAY
	2444	":You are no longer marked as being away"
	2445	306 RPL_NOWAWAY
	2446	":You have been marked as being away"
	2447
	2448	- These replies are used with the AWAY command (if
	2449	allowed). RPL_AWAY is sent to any client sending a
	2450	PRIVMSG to a client which is away. RPL_AWAY is only
	2451	sent by the server to which the client is connected.
	2452	Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
	2453	client removes and sets an AWAY message.
	2454
	2455	311 RPL_WHOISUSER
	2456	"<nick> <user> <host> * :<real name>"
	2457	312 RPL_WHOISSERVER
	2458	"<nick> <server> :<server info>"
	2459	313 RPL_WHOISOPERATOR
	2460	"<nick> :is an IRC operator"
	2461
	2462
	2463
	2464
	2465	Kalt Informational [Page 44]
	2466
	2467	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2468
	2469
	2470	317 RPL_WHOISIDLE
	2471	"<nick> <integer> :seconds idle"
	2472	318 RPL_ENDOFWHOIS
	2473	"<nick> :End of WHOIS list"
	2474	319 RPL_WHOISCHANNELS
	2475	"<nick> :*( ( "@" / "+" ) <channel> " " )"
	2476
	2477	- Replies 311 - 313, 317 - 319 are all replies
	2478	generated in response to a WHOIS message. Given that
	2479	there are enough parameters present, the answering
	2480	server MUST either formulate a reply out of the above
	2481	numerics (if the query nick is found) or return an
	2482	error reply. The '*' in RPL_WHOISUSER is there as
	2483	the literal character and not as a wild card. For
	2484	each reply set, only RPL_WHOISCHANNELS may appear
	2485	more than once (for long lists of channel names).
	2486	The '@' and '+' characters next to the channel name
	2487	indicate whether a client is a channel operator or
	2488	has been granted permission to speak on a moderated
	2489	channel. The RPL_ENDOFWHOIS reply is used to mark
	2490	the end of processing a WHOIS message.
	2491
	2492	314 RPL_WHOWASUSER
	2493	"<nick> <user> <host> * :<real name>"
	2494	369 RPL_ENDOFWHOWAS
	2495	"<nick> :End of WHOWAS"
	2496
	2497	- When replying to a WHOWAS message, a server MUST use
	2498	the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
	2499	ERR_WASNOSUCHNICK for each nickname in the presented
	2500	list. At the end of all reply batches, there MUST
	2501	be RPL_ENDOFWHOWAS (even if there was only one reply
	2502	and it was an error).
	2503
	2504	321 RPL_LISTSTART
	2505	Obsolete. Not used.
	2506
	2507	322 RPL_LIST
	2508	"<channel> <# visible> :<topic>"
	2509	323 RPL_LISTEND
	2510	":End of LIST"
	2511
	2512	- Replies RPL_LIST, RPL_LISTEND mark the actual replies
	2513	with data and end of the server's response to a LIST
	2514	command. If there are no channels available to return,
	2515	only the end reply MUST be sent.
	2516
	2517
	2518
	2519
	2520
	2521	Kalt Informational [Page 45]
	2522
	2523	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2524
	2525
	2526	325 RPL_UNIQOPIS
	2527	"<channel> <nickname>"
	2528
	2529	324 RPL_CHANNELMODEIS
	2530	"<channel> <mode> <mode params>"
	2531
	2532	331 RPL_NOTOPIC
	2533	"<channel> :No topic is set"
	2534	332 RPL_TOPIC
	2535	"<channel> :<topic>"
	2536
	2537	- When sending a TOPIC message to determine the
	2538	channel topic, one of two replies is sent. If
	2539	the topic is set, RPL_TOPIC is sent back else
	2540	RPL_NOTOPIC.
	2541
	2542	341 RPL_INVITING
	2543	"<channel> <nick>"
	2544
	2545	- Returned by the server to indicate that the
	2546	attempted INVITE message was successful and is
	2547	being passed onto the end client.
	2548
	2549	342 RPL_SUMMONING
	2550	"<user> :Summoning user to IRC"
	2551
	2552	- Returned by a server answering a SUMMON message to
	2553	indicate that it is summoning that user.
	2554
	2555	346 RPL_INVITELIST
	2556	"<channel> <invitemask>"
	2557	347 RPL_ENDOFINVITELIST
	2558	"<channel> :End of channel invite list"
	2559
	2560	- When listing the 'invitations masks' for a given channel,
	2561	a server is required to send the list back using the
	2562	RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A
	2563	separate RPL_INVITELIST is sent for each active mask.
	2564	After the masks have been listed (or if none present) a
	2565	RPL_ENDOFINVITELIST MUST be sent.
	2566
	2567	348 RPL_EXCEPTLIST
	2568	"<channel> <exceptionmask>"
	2569	349 RPL_ENDOFEXCEPTLIST
	2570	"<channel> :End of channel exception list"
	2571
	2572
	2573
	2574
	2575
	2576
	2577	Kalt Informational [Page 46]
	2578
	2579	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2580
	2581
	2582	- When listing the 'exception masks' for a given channel,
	2583	a server is required to send the list back using the
	2584	RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A
	2585	separate RPL_EXCEPTLIST is sent for each active mask.
	2586	After the masks have been listed (or if none present)
	2587	a RPL_ENDOFEXCEPTLIST MUST be sent.
	2588
	2589	351 RPL_VERSION
	2590	"<version>.<debuglevel> <server> :<comments>"
	2591
	2592	- Reply by the server showing its version details.
	2593	The <version> is the version of the software being
	2594	used (including any patchlevel revisions) and the
	2595	<debuglevel> is used to indicate if the server is
	2596	running in "debug mode".
	2597
	2598	The "comments" field may contain any comments about
	2599	the version or further version details.
	2600
	2601	352 RPL_WHOREPLY
	2602	"<channel> <user> <host> <server> <nick>
	2603	( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
	2604	:<hopcount> <real name>"
	2605
	2606	315 RPL_ENDOFWHO
	2607	"<name> :End of WHO list"
	2608
	2609	- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
	2610	to answer a WHO message. The RPL_WHOREPLY is only
	2611	sent if there is an appropriate match to the WHO
	2612	query. If there is a list of parameters supplied
	2613	with a WHO message, a RPL_ENDOFWHO MUST be sent
	2614	after processing each list item with <name> being
	2615	the item.
	2616
	2617	353 RPL_NAMREPLY
	2618	"( "=" / "*" / "@" ) <channel>
	2619	:[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
	2620	- "@" is used for secret channels, "*" for private
	2621	channels, and "=" for others (public channels).
	2622
	2623	366 RPL_ENDOFNAMES
	2624	"<channel> :End of NAMES list"
	2625
	2626	- To reply to a NAMES message, a reply pair consisting
	2627	of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
	2628	server back to the client. If there is no channel
	2629	found as in the query, then only RPL_ENDOFNAMES is
	2630
	2631
	2632
	2633	Kalt Informational [Page 47]
	2634
	2635	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2636
	2637
	2638	returned. The exception to this is when a NAMES
	2639	message is sent with no parameters and all visible
	2640	channels and contents are sent back in a series of
	2641	RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
	2642	the end.
	2643
	2644	364 RPL_LINKS
	2645	"<mask> <server> :<hopcount> <server info>"
	2646	365 RPL_ENDOFLINKS
	2647	"<mask> :End of LINKS list"
	2648
	2649	- In replying to the LINKS message, a server MUST send
	2650	replies back using the RPL_LINKS numeric and mark the
	2651	end of the list using an RPL_ENDOFLINKS reply.
	2652
	2653	367 RPL_BANLIST
	2654	"<channel> <banmask>"
	2655	368 RPL_ENDOFBANLIST
	2656	"<channel> :End of channel ban list"
	2657
	2658	- When listing the active 'bans' for a given channel,
	2659	a server is required to send the list back using the
	2660	RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
	2661	RPL_BANLIST is sent for each active banmask. After the
	2662	banmasks have been listed (or if none present) a
	2663	RPL_ENDOFBANLIST MUST be sent.
	2664
	2665	371 RPL_INFO
	2666	":<string>"
	2667	374 RPL_ENDOFINFO
	2668	":End of INFO list"
	2669
	2670	- A server responding to an INFO message is required to
	2671	send all its 'info' in a series of RPL_INFO messages
	2672	with a RPL_ENDOFINFO reply to indicate the end of the
	2673	replies.
	2674
	2675	375 RPL_MOTDSTART
	2676	":- <server> Message of the day - "
	2677	372 RPL_MOTD
	2678	":- <text>"
	2679	376 RPL_ENDOFMOTD
	2680	":End of MOTD command"
	2681
	2682	- When responding to the MOTD message and the MOTD file
	2683	is found, the file is displayed line by line, with
	2684	each line no longer than 80 characters, using
	2685
	2686
	2687
	2688
	2689	Kalt Informational [Page 48]
	2690
	2691	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2692
	2693
	2694	RPL_MOTD format replies. These MUST be surrounded
	2695	by a RPL_MOTDSTART (before the RPL_MOTDs) and an
	2696	RPL_ENDOFMOTD (after).
	2697
	2698	381 RPL_YOUREOPER
	2699	":You are now an IRC operator"
	2700
	2701	- RPL_YOUREOPER is sent back to a client which has
	2702	just successfully issued an OPER message and gained
	2703	operator status.
	2704
	2705	382 RPL_REHASHING
	2706	"<config file> :Rehashing"
	2707
	2708	- If the REHASH option is used and an operator sends
	2709	a REHASH message, an RPL_REHASHING is sent back to
	2710	the operator.
	2711
	2712	383 RPL_YOURESERVICE
	2713	"You are service <servicename>"
	2714
	2715	- Sent by the server to a service upon successful
	2716	registration.
	2717
	2718	391 RPL_TIME
	2719	"<server> :<string showing server's local time>"
	2720
	2721	- When replying to the TIME message, a server MUST send
	2722	the reply using the RPL_TIME format above. The string
	2723	showing the time need only contain the correct day and
	2724	time there. There is no further requirement for the
	2725	time string.
	2726
	2727	392 RPL_USERSSTART
	2728	":UserID Terminal Host"
	2729	393 RPL_USERS
	2730	":<username> <ttyline> <hostname>"
	2731	394 RPL_ENDOFUSERS
	2732	":End of users"
	2733	395 RPL_NOUSERS
	2734	":Nobody logged in"
	2735
	2736	- If the USERS message is handled by a server, the
	2737	replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
	2738	RPL_NOUSERS are used. RPL_USERSSTART MUST be sent
	2739	first, following by either a sequence of RPL_USERS
	2740	or a single RPL_NOUSER. Following this is
	2741	RPL_ENDOFUSERS.
	2742
	2743
	2744
	2745	Kalt Informational [Page 49]
	2746
	2747	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2748
	2749
	2750	200 RPL_TRACELINK
	2751	"Link <version & debug level> <destination>
	2752	<next server> V<protocol version>
	2753	<link uptime in seconds> <backstream sendq>
	2754	<upstream sendq>"
	2755	201 RPL_TRACECONNECTING
	2756	"Try. <class> <server>"
	2757	202 RPL_TRACEHANDSHAKE
	2758	"H.S. <class> <server>"
	2759	203 RPL_TRACEUNKNOWN
	2760	"???? <class> [<client IP address in dot form>]"
	2761	204 RPL_TRACEOPERATOR
	2762	"Oper <class> <nick>"
	2763	205 RPL_TRACEUSER
	2764	"User <class> <nick>"
	2765	206 RPL_TRACESERVER
	2766	"Serv <class> <int>S <int>C <server>
	2767	<nick!user\|!>@<host\|server> V<protocol version>"
	2768	207 RPL_TRACESERVICE
	2769	"Service <class> <name> <type> <active type>"
	2770	208 RPL_TRACENEWTYPE
	2771	"<newtype> 0 <client name>"
	2772	209 RPL_TRACECLASS
	2773	"Class <class> <count>"
	2774	210 RPL_TRACERECONNECT
	2775	Unused.
	2776	261 RPL_TRACELOG
	2777	"File <logfile> <debug level>"
	2778	262 RPL_TRACEEND
	2779	"<server name> <version & debug level> :End of TRACE"
	2780
	2781	- The RPL_TRACE* are all returned by the server in
	2782	response to the TRACE message. How many are
	2783	returned is dependent on the TRACE message and
	2784	whether it was sent by an operator or not. There
	2785	is no predefined order for which occurs first.
	2786	Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
	2787	RPL_TRACEHANDSHAKE are all used for connections
	2788	which have not been fully established and are either
	2789	unknown, still attempting to connect or in the
	2790	process of completing the 'server handshake'.
	2791	RPL_TRACELINK is sent by any server which handles
	2792	a TRACE message and has to pass it on to another
	2793	server. The list of RPL_TRACELINKs sent in
	2794	response to a TRACE command traversing the IRC
	2795	network should reflect the actual connectivity of
	2796	the servers themselves along that path.
	2797
	2798
	2799
	2800
	2801	Kalt Informational [Page 50]
	2802
	2803	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2804
	2805
	2806	RPL_TRACENEWTYPE is to be used for any connection
	2807	which does not fit in the other categories but is
	2808	being displayed anyway.
	2809	RPL_TRACEEND is sent to indicate the end of the list.
	2810
	2811	211 RPL_STATSLINKINFO
	2812	"<linkname> <sendq> <sent messages>
	2813	<sent Kbytes> <received messages>
	2814	<received Kbytes> <time open>"
	2815
	2816	- reports statistics on a connection. <linkname>
	2817	identifies the particular connection, <sendq> is
	2818	the amount of data that is queued and waiting to be
	2819	sent <sent messages> the number of messages sent,
	2820	and <sent Kbytes> the amount of data sent, in
	2821	Kbytes. <received messages> and <received Kbytes>
	2822	are the equivalent of <sent messages> and <sent
	2823	Kbytes> for received data, respectively. <time
	2824	open> indicates how long ago the connection was
	2825	opened, in seconds.
	2826
	2827	212 RPL_STATSCOMMANDS
	2828	"<command> <count> <byte count> <remote count>"
	2829
	2830	- reports statistics on commands usage.
	2831
	2832	219 RPL_ENDOFSTATS
	2833	"<stats letter> :End of STATS report"
	2834
	2835	242 RPL_STATSUPTIME
	2836	":Server Up %d days %d:%02d:%02d"
	2837
	2838	- reports the server uptime.
	2839
	2840	243 RPL_STATSOLINE
	2841	"O <hostmask> * <name>"
	2842
	2843	- reports the allowed hosts from where user may become IRC
	2844	operators.
	2845
	2846	221 RPL_UMODEIS
	2847	"<user mode string>"
	2848
	2849	- To answer a query about a client's own mode,
	2850	RPL_UMODEIS is sent back.
	2851
	2852	234 RPL_SERVLIST
	2853	"<name> <server> <mask> <type> <hopcount> <info>"
	2854
	2855
	2856
	2857	Kalt Informational [Page 51]
	2858
	2859	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2860
	2861
	2862	235 RPL_SERVLISTEND
	2863	"<mask> <type> :End of service listing"
	2864
	2865	- When listing services in reply to a SERVLIST message,
	2866	a server is required to send the list back using the
	2867	RPL_SERVLIST and RPL_SERVLISTEND messages. A separate
	2868	RPL_SERVLIST is sent for each service. After the
	2869	services have been listed (or if none present) a
	2870	RPL_SERVLISTEND MUST be sent.
	2871
	2872	251 RPL_LUSERCLIENT
	2873	":There are <integer> users and <integer>
	2874	services on <integer> servers"
	2875	252 RPL_LUSEROP
	2876	"<integer> :operator(s) online"
	2877	253 RPL_LUSERUNKNOWN
	2878	"<integer> :unknown connection(s)"
	2879	254 RPL_LUSERCHANNELS
	2880	"<integer> :channels formed"
	2881	255 RPL_LUSERME
	2882	":I have <integer> clients and <integer>
	2883	servers"
	2884
	2885	- In processing an LUSERS message, the server
	2886	sends a set of replies from RPL_LUSERCLIENT,
	2887	RPL_LUSEROP, RPL_USERUNKNOWN,
	2888	RPL_LUSERCHANNELS and RPL_LUSERME. When
	2889	replying, a server MUST send back
	2890	RPL_LUSERCLIENT and RPL_LUSERME. The other
	2891	replies are only sent back if a non-zero count
	2892	is found for them.
	2893
	2894	256 RPL_ADMINME
	2895	"<server> :Administrative info"
	2896	257 RPL_ADMINLOC1
	2897	":<admin info>"
	2898	258 RPL_ADMINLOC2
	2899	":<admin info>"
	2900	259 RPL_ADMINEMAIL
	2901	":<admin info>"
	2902
	2903	- When replying to an ADMIN message, a server
	2904	is expected to use replies RPL_ADMINME
	2905	through to RPL_ADMINEMAIL and provide a text
	2906	message with each. For RPL_ADMINLOC1 a
	2907	description of what city, state and country
	2908	the server is in is expected, followed by
	2909	details of the institution (RPL_ADMINLOC2)
	2910
	2911
	2912
	2913	Kalt Informational [Page 52]
	2914
	2915	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2916
	2917
	2918	and finally the administrative contact for the
	2919	server (an email address here is REQUIRED)
	2920	in RPL_ADMINEMAIL.
	2921
	2922	263 RPL_TRYAGAIN
	2923	"<command> :Please wait a while and try again."
	2924
	2925	- When a server drops a command without processing it,
	2926	it MUST use the reply RPL_TRYAGAIN to inform the
	2927	originating client.
	2928
	2929	5.2 Error Replies
	2930
	2931	Error replies are found in the range from 400 to 599.
	2932
	2933	401 ERR_NOSUCHNICK
	2934	"<nickname> :No such nick/channel"
	2935
	2936	- Used to indicate the nickname parameter supplied to a
	2937	command is currently unused.
	2938
	2939	402 ERR_NOSUCHSERVER
	2940	"<server name> :No such server"
	2941
	2942	- Used to indicate the server name given currently
	2943	does not exist.
	2944
	2945	403 ERR_NOSUCHCHANNEL
	2946	"<channel name> :No such channel"
	2947
	2948	- Used to indicate the given channel name is invalid.
	2949
	2950	404 ERR_CANNOTSENDTOCHAN
	2951	"<channel name> :Cannot send to channel"
	2952
	2953	- Sent to a user who is either (a) not on a channel
	2954	which is mode +n or (b) not a chanop (or mode +v) on
	2955	a channel which has mode +m set or where the user is
	2956	banned and is trying to send a PRIVMSG message to
	2957	that channel.
	2958
	2959	405 ERR_TOOMANYCHANNELS
	2960	"<channel name> :You have joined too many channels"
	2961
	2962	- Sent to a user when they have joined the maximum
	2963	number of allowed channels and they try to join
	2964	another channel.
	2965
	2966
	2967
	2968
	2969	Kalt Informational [Page 53]
	2970
	2971	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	2972
	2973
	2974	406 ERR_WASNOSUCHNICK
	2975	"<nickname> :There was no such nickname"
	2976
	2977	- Returned by WHOWAS to indicate there is no history
	2978	information for that nickname.
	2979
	2980	407 ERR_TOOMANYTARGETS
	2981	"<target> :<error code> recipients. <abort message>"
	2982
	2983	- Returned to a client which is attempting to send a
	2984	PRIVMSG/NOTICE using the user@host destination format
	2985	and for a user@host which has several occurrences.
	2986
	2987	- Returned to a client which trying to send a
	2988	PRIVMSG/NOTICE to too many recipients.
	2989
	2990	- Returned to a client which is attempting to JOIN a safe
	2991	channel using the shortname when there are more than one
	2992	such channel.
	2993
	2994	408 ERR_NOSUCHSERVICE
	2995	"<service name> :No such service"
	2996
	2997	- Returned to a client which is attempting to send a SQUERY
	2998	to a service which does not exist.
	2999
	3000	409 ERR_NOORIGIN
	3001	":No origin specified"
	3002
	3003	- PING or PONG message missing the originator parameter.
	3004
	3005	411 ERR_NORECIPIENT
	3006	":No recipient given (<command>)"
	3007	412 ERR_NOTEXTTOSEND
	3008	":No text to send"
	3009	413 ERR_NOTOPLEVEL
	3010	"<mask> :No toplevel domain specified"
	3011	414 ERR_WILDTOPLEVEL
	3012	"<mask> :Wildcard in toplevel domain"
	3013	415 ERR_BADMASK
	3014	"<mask> :Bad Server/host mask"
	3015
	3016	- 412 - 415 are returned by PRIVMSG to indicate that
	3017	the message wasn't delivered for some reason.
	3018	ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
	3019	are returned when an invalid use of
	3020	"PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
	3021
	3022
	3023
	3024
	3025	Kalt Informational [Page 54]
	3026
	3027	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3028
	3029
	3030	421 ERR_UNKNOWNCOMMAND
	3031	"<command> :Unknown command"
	3032
	3033	- Returned to a registered client to indicate that the
	3034	command sent is unknown by the server.
	3035
	3036	422 ERR_NOMOTD
	3037	":MOTD File is missing"
	3038
	3039	- Server's MOTD file could not be opened by the server.
	3040
	3041	423 ERR_NOADMININFO
	3042	"<server> :No administrative info available"
	3043
	3044	- Returned by a server in response to an ADMIN message
	3045	when there is an error in finding the appropriate
	3046	information.
	3047
	3048	424 ERR_FILEERROR
	3049	":File error doing <file op> on <file>"
	3050
	3051	- Generic error message used to report a failed file
	3052	operation during the processing of a message.
	3053
	3054	431 ERR_NONICKNAMEGIVEN
	3055	":No nickname given"
	3056
	3057	- Returned when a nickname parameter expected for a
	3058	command and isn't found.
	3059
	3060	432 ERR_ERRONEUSNICKNAME
	3061	"<nick> :Erroneous nickname"
	3062
	3063	- Returned after receiving a NICK message which contains
	3064	characters which do not fall in the defined set. See
	3065	section 2.3.1 for details on valid nicknames.
	3066
	3067	433 ERR_NICKNAMEINUSE
	3068	"<nick> :Nickname is already in use"
	3069
	3070	- Returned when a NICK message is processed that results
	3071	in an attempt to change to a currently existing
	3072	nickname.
	3073
	3074
	3075
	3076
	3077
	3078
	3079
	3080
	3081	Kalt Informational [Page 55]
	3082
	3083	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3084
	3085
	3086	436 ERR_NICKCOLLISION
	3087	"<nick> :Nickname collision KILL from <user>@<host>"
	3088
	3089	- Returned by a server to a client when it detects a
	3090	nickname collision (registered of a NICK that
	3091	already exists by another server).
	3092
	3093	437 ERR_UNAVAILRESOURCE
	3094	"<nick/channel> :Nick/channel is temporarily unavailable"
	3095
	3096	- Returned by a server to a user trying to join a channel
	3097	currently blocked by the channel delay mechanism.
	3098
	3099	- Returned by a server to a user trying to change nickname
	3100	when the desired nickname is blocked by the nick delay
	3101	mechanism.
	3102
	3103	441 ERR_USERNOTINCHANNEL
	3104	"<nick> <channel> :They aren't on that channel"
	3105
	3106	- Returned by the server to indicate that the target
	3107	user of the command is not on the given channel.
	3108
	3109	442 ERR_NOTONCHANNEL
	3110	"<channel> :You're not on that channel"
	3111
	3112	- Returned by the server whenever a client tries to
	3113	perform a channel affecting command for which the
	3114	client isn't a member.
	3115
	3116	443 ERR_USERONCHANNEL
	3117	"<user> <channel> :is already on channel"
	3118
	3119	- Returned when a client tries to invite a user to a
	3120	channel they are already on.
	3121
	3122	444 ERR_NOLOGIN
	3123	"<user> :User not logged in"
	3124
	3125	- Returned by the summon after a SUMMON command for a
	3126	user was unable to be performed since they were not
	3127	logged in.
	3128
	3129
	3130
	3131
	3132
	3133
	3134
	3135
	3136
	3137	Kalt Informational [Page 56]
	3138
	3139	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3140
	3141
	3142	445 ERR_SUMMONDISABLED
	3143	":SUMMON has been disabled"
	3144
	3145	- Returned as a response to the SUMMON command. MUST be
	3146	returned by any server which doesn't implement it.
	3147
	3148	446 ERR_USERSDISABLED
	3149	":USERS has been disabled"
	3150
	3151	- Returned as a response to the USERS command. MUST be
	3152	returned by any server which does not implement it.
	3153
	3154	451 ERR_NOTREGISTERED
	3155	":You have not registered"
	3156
	3157	- Returned by the server to indicate that the client
	3158	MUST be registered before the server will allow it
	3159	to be parsed in detail.
	3160
	3161	461 ERR_NEEDMOREPARAMS
	3162	"<command> :Not enough parameters"
	3163
	3164	- Returned by the server by numerous commands to
	3165	indicate to the client that it didn't supply enough
	3166	parameters.
	3167
	3168	462 ERR_ALREADYREGISTRED
	3169	":Unauthorized command (already registered)"
	3170
	3171	- Returned by the server to any link which tries to
	3172	change part of the registered details (such as
	3173	password or user details from second USER message).
	3174
	3175	463 ERR_NOPERMFORHOST
	3176	":Your host isn't among the privileged"
	3177
	3178	- Returned to a client which attempts to register with
	3179	a server which does not been setup to allow
	3180	connections from the host the attempted connection
	3181	is tried.
	3182
	3183	464 ERR_PASSWDMISMATCH
	3184	":Password incorrect"
	3185
	3186	- Returned to indicate a failed attempt at registering
	3187	a connection for which a password was required and
	3188	was either not given or incorrect.
	3189
	3190
	3191
	3192
	3193	Kalt Informational [Page 57]
	3194
	3195	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3196
	3197
	3198	465 ERR_YOUREBANNEDCREEP
	3199	":You are banned from this server"
	3200
	3201	- Returned after an attempt to connect and register
	3202	yourself with a server which has been setup to
	3203	explicitly deny connections to you.
	3204
	3205	466 ERR_YOUWILLBEBANNED
	3206
	3207	- Sent by a server to a user to inform that access to the
	3208	server will soon be denied.
	3209
	3210	467 ERR_KEYSET
	3211	"<channel> :Channel key already set"
	3212	471 ERR_CHANNELISFULL
	3213	"<channel> :Cannot join channel (+l)"
	3214	472 ERR_UNKNOWNMODE
	3215	"<char> :is unknown mode char to me for <channel>"
	3216	473 ERR_INVITEONLYCHAN
	3217	"<channel> :Cannot join channel (+i)"
	3218	474 ERR_BANNEDFROMCHAN
	3219	"<channel> :Cannot join channel (+b)"
	3220	475 ERR_BADCHANNELKEY
	3221	"<channel> :Cannot join channel (+k)"
	3222	476 ERR_BADCHANMASK
	3223	"<channel> :Bad Channel Mask"
	3224	477 ERR_NOCHANMODES
	3225	"<channel> :Channel doesn't support modes"
	3226	478 ERR_BANLISTFULL
	3227	"<channel> <char> :Channel list is full"
	3228
	3229	481 ERR_NOPRIVILEGES
	3230	":Permission Denied- You're not an IRC operator"
	3231
	3232	- Any command requiring operator privileges to operate
	3233	MUST return this error to indicate the attempt was
	3234	unsuccessful.
	3235
	3236	482 ERR_CHANOPRIVSNEEDED
	3237	"<channel> :You're not channel operator"
	3238
	3239	- Any command requiring 'chanop' privileges (such as
	3240	MODE messages) MUST return this error if the client
	3241	making the attempt is not a chanop on the specified
	3242	channel.
	3243
	3244
	3245
	3246
	3247
	3248
	3249	Kalt Informational [Page 58]
	3250
	3251	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3252
	3253
	3254	483 ERR_CANTKILLSERVER
	3255	":You can't kill a server!"
	3256
	3257	- Any attempts to use the KILL command on a server
	3258	are to be refused and this error returned directly
	3259	to the client.
	3260
	3261	484 ERR_RESTRICTED
	3262	":Your connection is restricted!"
	3263
	3264	- Sent by the server to a user upon connection to indicate
	3265	the restricted nature of the connection (user mode "+r").
	3266
	3267	485 ERR_UNIQOPPRIVSNEEDED
	3268	":You're not the original channel operator"
	3269
	3270	- Any MODE requiring "channel creator" privileges MUST
	3271	return this error if the client making the attempt is not
	3272	a chanop on the specified channel.
	3273
	3274	491 ERR_NOOPERHOST
	3275	":No O-lines for your host"
	3276
	3277	- If a client sends an OPER message and the server has
	3278	not been configured to allow connections from the
	3279	client's host as an operator, this error MUST be
	3280	returned.
	3281
	3282	501 ERR_UMODEUNKNOWNFLAG
	3283	":Unknown MODE flag"
	3284
	3285	- Returned by the server to indicate that a MODE
	3286	message was sent with a nickname parameter and that
	3287	the a mode flag sent was not recognized.
	3288
	3289	502 ERR_USERSDONTMATCH
	3290	":Cannot change mode for other users"
	3291
	3292	- Error sent to any user trying to view or change the
	3293	user mode for a user other than themselves.
	3294
	3295	5.3 Reserved numerics
	3296
	3297	These numerics are not described above since they fall into one of
	3298	the following categories:
	3299
	3300	1. no longer in use;
	3301
	3302
	3303
	3304
	3305	Kalt Informational [Page 59]
	3306
	3307	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3308
	3309
	3310	2. reserved for future planned use;
	3311
	3312	3. in current use but are part of a non-generic 'feature' of
	3313	the current IRC server.
	3314
	3315	231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
	3316	233 RPL_SERVICE
	3317	300 RPL_NONE 316 RPL_WHOISCHANOP
	3318	361 RPL_KILLDONE 362 RPL_CLOSING
	3319	363 RPL_CLOSEEND 373 RPL_INFOSTART
	3320	384 RPL_MYPORTIS
	3321
	3322	213 RPL_STATSCLINE 214 RPL_STATSNLINE
	3323	215 RPL_STATSILINE 216 RPL_STATSKLINE
	3324	217 RPL_STATSQLINE 218 RPL_STATSYLINE
	3325	240 RPL_STATSVLINE 241 RPL_STATSLLINE
	3326	244 RPL_STATSHLINE 244 RPL_STATSSLINE
	3327	246 RPL_STATSPING 247 RPL_STATSBLINE
	3328	250 RPL_STATSDLINE
	3329
	3330	492 ERR_NOSERVICEHOST
	3331
	3332	6. Current implementations
	3333
	3334	The IRC software, version 2.10 is the only complete implementation of
	3335	the IRC protocol (client and server). Because of the small amount of
	3336	changes in the client protocol since the publication of RFC 1459
	3337	[IRC], implementations that follow it are likely to be compliant with
	3338	this protocol or to require a small amount of changes to reach
	3339	compliance.
	3340
	3341	7. Current problems
	3342
	3343	There are a number of recognized problems with the IRC Client
	3344	Protocol, and more generally with the IRC Server Protocol. In order
	3345	to preserve backward compatibility with old clients, this protocol
	3346	has almost not evolved since the publication of RFC 1459 [IRC].
	3347
	3348	7.1 Nicknames
	3349
	3350	The idea of the nickname on IRC is very convenient for users to use
	3351	when talking to each other outside of a channel, but there is only a
	3352	finite nickname space and being what they are, it's not uncommon for
	3353	several people to want to use the same nick. If a nickname is chosen
	3354	by two people using this protocol, either one will not succeed or
	3355	both will removed by use of a server KILL (See Section 3.7.1).
	3356
	3357
	3358
	3359
	3360
	3361	Kalt Informational [Page 60]
	3362
	3363	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3364
	3365
	3366	7.2 Limitation of wildcards
	3367
	3368	There is no way to escape the escape character "\" (%x5C). While
	3369	this isn't usually a problem, it makes it impossible to form a mask
	3370	with a backslash character ("\") preceding a wildcard.
	3371
	3372	7.3 Security considerations
	3373
	3374	Security issues related to this protocol are discussed in the "IRC
	3375	Server Protocol" [IRC-SERVER] as they are mostly an issue for the
	3376	server side of the connection.
	3377
	3378	8. Current support and availability
	3379
	3380	Mailing lists for IRC related discussion:
	3381	General discussion: ircd-users@irc.org
	3382	Protocol development: ircd-dev@irc.org
	3383
	3384	Software implementations:
	3385	ftp://ftp.irc.org/irc/server
	3386	ftp://ftp.funet.fi/pub/unix/irc
	3387	ftp://ftp.irc.org/irc/clients
	3388
	3389	Newsgroup: alt.irc
	3390
	3391	9. Acknowledgements
	3392
	3393	Parts of this document were copied from the RFC 1459 [IRC] which
	3394	first formally documented the IRC Protocol. It has also benefited
	3395	from many rounds of review and comments. In particular, the
	3396	following people have made significant contributions to this
	3397	document:
	3398
	3399	Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
	3400	Ruokonen, Magnus Tjernstrom, Stefan Zehl.
	3401
	3402
	3403
	3404
	3405
	3406
	3407
	3408
	3409
	3410
	3411
	3412
	3413
	3414
	3415
	3416
	3417	Kalt Informational [Page 61]
	3418
	3419	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3420
	3421
	3422	10. References
	3423
	3424	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	3425	Requirement Levels", BCP 14, RFC 2119, March 1997.
	3426
	3427	[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	3428	Specifications: ABNF", RFC 2234, November 1997.
	3429
	3430	[HNAME] Braden, R., "Requirements for Internet Hosts --
	3431	Application and Support", STD 3, RFC 1123, October 1989.
	3432
	3433	[IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
	3434	RFC 1459, May 1993.
	3435
	3436	[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
	3437	April 2000.
	3438
	3439	[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
	3440	2811, April 2000.
	3441
	3442	[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
	3443	2813, April 2000.
	3444
	3445	11. Author's Address
	3446
	3447	Christophe Kalt
	3448	99 Teaneck Rd, Apt #117
	3449	Ridgefield Park, NJ 07660
	3450	USA
	3451
	3452	EMail: kalt@stealth.net
	3453
	3454
	3455
	3456
	3457
	3458
	3459
	3460
	3461
	3462
	3463
	3464
	3465
	3466
	3467
	3468
	3469
	3470
	3471
	3472
	3473	Kalt Informational [Page 62]
	3474
	3475	RFC 2812 Internet Relay Chat: Client Protocol April 2000
	3476
	3477
	3478	12. Full Copyright Statement
	3479
	3480	Copyright (C) The Internet Society (2000). All Rights Reserved.
	3481
	3482	This document and translations of it may be copied and furnished to
	3483	others, and derivative works that comment on or otherwise explain it
	3484	or assist in its implementation may be prepared, copied, published
	3485	and distributed, in whole or in part, without restriction of any
	3486	kind, provided that the above copyright notice and this paragraph are
	3487	included on all such copies and derivative works. However, this
	3488	document itself may not be modified in any way, such as by removing
	3489	the copyright notice or references to the Internet Society or other
	3490	Internet organizations, except as needed for the purpose of
	3491	developing Internet standards in which case the procedures for
	3492	copyrights defined in the Internet Standards process must be
	3493	followed, or as required to translate it into languages other than
	3494	English.
	3495
	3496	The limited permissions granted above are perpetual and will not be
	3497	revoked by the Internet Society or its successors or assigns.
	3498
	3499	This document and the information contained herein is provided on an
	3500	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	3501	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	3502	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	3503	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	3504	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	3505
	3506	Acknowledgement
	3507
	3508	Funding for the RFC Editor function is currently provided by the
	3509	Internet Society.
	3510
	3511
	3512
	3513
	3514
	3515
	3516
	3517
	3518
	3519
	3520
	3521
	3522
	3523
	3524
	3525
	3526
	3527
	3528
	3529	Kalt Informational [Page 63]
	3530

+3666

-0

doc/unreal32docs.html less more

	0	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	1	<html>
	2	<head>
	3	<title>UnrealIRCd - 3.2 - Official Documentation</title>
	4	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	5	<style type="text/css">
	6	.block_section { font-size: 24; font-weight: bold; }
	7	.block_name { font-size: 24; font-weight: bold; }
	8	.block_required { color: red; font-weight: bold; }
	9	.block_recommended { color: green; font-weight: bold; }
	10	.block_optional { color: blue; font-weight: bold; }
	11	.block_old { font-size: 14; }
	12	.set { font-weight: bold; }
	13	.desc { margin-left: 15px; }
	14	pre { font: "times new roman"; font-style: normal; background-color: #eeeeee;}
	15	</style>
	16	</head>
	17
	18	<!-- $Id: unreal32docs.html,v 1.1.2.144.2.133 2009/12/06 16:52:51 syzop Exp $ -->
	19
	20	<body>
	21	English \|
	22	<a href="unreal32docs.de.html">German</a> \|
	23	<a href="unreal32docs.es.html">Spanish</a> \|
	24	<a href="unreal32docs.hu.html">Hungarian</a> \|
	25	<a href="unreal32docs.fr.html">French</a> \|
	26	<a href="unreal32docs.gr.html">Greek</a> \|
	27	<a href="unreal32docs.nl.html">Dutch</a> \|
	28	<a href="unreal32docs.ru.html">Russian</a> \|
	29	<a href="unreal32docs.tr.html">Turkish</a>
	30	<br><br>
	31	<div align="center"><b><font size="7">UnrealIRCd</font></b><br>
	32	<font size="4"><a href="http://www.unrealircd.com">http://www.unrealircd.com</a></font><br>
	33	<font size="4">Version: 3.2.8</font><br>
	34	<b>Last doc update:</b> 2009-09-14</div>
	35	<br>
	36	<b>Coders:</b> Stskeeps / codemastr / Syzop / Luke / aquanight / WolfSage <br>
	37	<b>Contributors:</b> McSkaf / Zogg / NiQuiL / assyrian / chasm / DrBin / llthangel / Griever / nighthawk<br>
	38	<b>Documentation:</b> CKnight^ / Syzop<br>
	39	<p>To view this documentation you must have a compatible browser, which are listed below. Up to date docs are
	40	available at <a href="http://www.vulnscan.org/UnrealIRCd/unreal32docs.html">http://www.vulnscan.org/UnrealIRCd/unreal32docs.html</a>
	41	and a FAQ at <a href="http://www.vulnscan.org/UnrealIRCd/faq/" TARGET="_blank">http://www.vulnscan.org/UnrealIRCd/faq/</a>.
	42	</p>
	43	<p><b>Compatible Browsers: </b><br>
	44	<ul>
	45	<li>Opera 6.02
	46	<li>Microsoft Internet Explorer 6.X / 5.5
	47	<li>Netscape Navigator 6.X
	48	<li>Mozilla 1.2.X
	49	<li>Lynx (to a point)
	50	</ul>
	51	</p>
	52	<p><font size="+2"><b>INDEX / TABLE OF CONTENTS</b></font><br>
	53	1. <a href="#IntroductionNotes">Introduction & Notes</a><br>
	54	---1.1. <a href="#notesonolder">Notes on upgrading/mixing 3.1.x -> 3.2</a><br>
	55	---1.2. <a href="#notesonupgrade">Notes on upgrading between 3.2 versions</a><br>
	56	2. <a href="#installation">Installation</a><br>
	57	3. <a href="#features">Features</a><br>
	58	-- 3.1. <a href="#feature_cloaking">Cloaking</a><br>
	59	-- 3.2. <a href="#feature_modules">Modules</a><br>
	60	-- 3.3. <a href="#feature_snomasks">Snomasks</a><br>
	61	-- 3.4. <a href="#feature_aliases">Aliases</a><br>
	62	-- 3.5. <a href="#feature_helpop">Helpop</a><br>
	63	-- 3.6. <a href="#feature_operaccesslevels">Oper access levels</a><br>
	64	-- 3.7. <a href="#feature_opercmds">Oper commands</a><br>
	65	-- 3.8. <a href="#feature_ssl">SSL</a><br>
	66	-- 3.9. <a href="#feature_ipv6">IPv6</a><br>
	67	-- 3.10. <a href="#feature_ziplinks">Zip links</a><br>
	68	-- 3.11. <a href="#feature_dyndns">Dynamic DNS/IP linking support</a><br>
	69	-- 3.12. <a href="#feature_antiflood">Anti-flood features</a><br>
	70	-- 3.13. <a href="#feature_bantypes">Ban types</a><br>
	71	-- 3.14. <a href="#feature_spamfilter">Spamfilter</a><br>
	72	-- 3.15. <a href="#feature_cidr">CIDR</a><br>
	73	-- 3.16. <a href="#feature_nickchars">Nick Character Sets</a><br>
	74	-- 3.17. <a href="#feature_cgiirc">CGI:IRC Support</a><br>
	75	-- 3.18. <a href="#feature_timesync">Time Synchronization</a><br>
	76	-- 3.19. <a href="#feature_other">Other features</a><br>
	77	4. <a href="#configuringyourunrealircdconf">Configuring your unrealircd.conf
	78	file</a><br>
	79	---4.1. <a href="#configurationfileexplained">Configuration file explained</a><br>
	80	---4.2. <a href="#meblock"> Me Block -=- (M:Line)</a><br>
	81	---4.3. <a href="#adminblock">Admin Block -=- (A:Line)</a><br>
	82	---4.4. <a href="#classblock">Class Block -=- (Y:Line)</a><br>
	83	---4.5. <a href="#allowblock">Allow Block -=- (I:Line)</a><br>
	84	---4.6. <a href="#listenblock">Listen Block -=- (P:Line)</a><br>
	85	---4.7. <a href="#operblock">Oper Block -=- (O:Line)</a><br>
	86	---4.8. <a href="#drpassblock">DRpass Block -=-(X:Line)</a><br>
	87	---4.9. <a href="#includedirective">Include Directive</a><br>
	88	---4.10. <a href="#loadmoduledirective">Loadmodule Directive</a><br>
	89	---4.11. <a href="#logblock">Log Block</a><br>
	90	---4.12. <a href="#tldblock">TLD Block -=- (T:Line)</a><br>
	91	---4.13. <a href="#bannickblock">Ban Nick Block -=- (Q:Line)</a><br>
	92	---4.14. <a href="#banuserblock">Ban User Block -=- (K:Line)</a><br>
	93	---4.15. <a href="#banipblock">Ban IP Block -=- (Z:Line)</a><br>
	94	---4.16. <a href="#banserverblock">Ban Server Block -=-(q:Line)</a><br>
	95	---4.17. <a href="#banrealnameblock">Ban Realname Block -=- (n:Line)</a><br>
	96	---4.18. <a href="#banversionblock">Ban Version Block</a><br>
	97	---4.19. <a href="#banexceptionblock">Ban Exception Block -=- (E:Line)</a><br>
	98	---4.20. <a href="#tklexceptionblock">TKL Exception Block</a><br>
	99	---4.21. <a href="#throttleexceptionblock">Throttle Exception Block</a><br>
	100	---4.22. <a href="#denydccblock">Deny DCC Block -=- (dccdeny.conf)</a><br>
	101	---4.23. <a href="#denyversionblock">Deny Version Block -=- (V:Line)</a><br>
	102	---4.24. <a href="#denylinkblock">Deny Link Block -=- (D:Line / d:Line)</a><br>
	103	---4.25. <a href="#denychannelblock">Deny Channel Block -=- (chrestrict.conf)</a><br>
	104	---4.26. <a href="#allowchannelblock">Allow Channel Block</a><br>
	105	---4.27. <a href="#allowdccblock">Allow DCC Block</a><br>
	106	---4.28. <a href="#vhostblock">Vhost Block -=- (vhost.conf)</a><br>
	107	---4.29. <a href="#badwordsblock">Badword Block -=- (badwords.conf)</a><br>
	108	---4.30. <a href="#ulinesblock">Uline Block -=- (U:Line)</a><br>
	109	---4.31. <a href="#linkblock">Link Block -=- (C/N/H:Lines)</a><br>
	110	---4.32. <a href="#aliasblock">Alias Block</a><br>
	111	---4.33. <a href="#helpblock">Help Block</a><br>
	112	---4.34. <a href="#officialchannels">Official Channels Block</a><br>
	113	---4.35. <a href="#spamfilter">Spamfilter Block</a><br>
	114	---4.36. <a href="#cgiirc">Cgiirc Block</a><br>
	115	---4.37. <a href="#setblock">Set Block -=- (networks/unrealircd.conf)</a><br>
	116	---4.38. <a href="#filesblock">Files Block</a><br />
	117	5. <a href="#addtlfiles">Additional Files</a><br>
	118	6. <a href="#userchannelmodes">User & Channel Modes</a><br>
	119	7. <a href="#useropercommands">User & Oper Commands</a><br>
	120	8. <a href="#security">Security tips/checklist</a><br>
	121	---8.1. <a href="#secpasswords">Passwords</a><br>
	122	---8.2. <a href="#secnonircd">Non-Ircd related vulnerabilities</a><br>
	123	---8.3. <a href="#secpermissions">Permissions and the configfile</a><br>
	124	---8.4. <a href="#secuser">User-related problems</a><br>
	125	---8.5. <a href="#secsnif">SSL/SSH & sniffing</a><br>
	126	---8.6. <a href="#secDoS">Denial of Service attacks (DoS) [or: how to protect my hub]</a><br>
	127	---8.7. <a href="#secinformation">Information disclosure</a><br>
	128	---8.8. <a href="#secantiexploit">Protecting against exploits</a><br>
	129	---8.9. <a href="#secsummary">Summary</a><br>
	130	9. <a href="http://www.vulnscan.org/UnrealIRCd/faq/" target="_blank">Frequently Asked Questions (FAQ)</a><br>
	131	A. <a href="#regex">Regular Expressions</a><br>
	132	---A.1. <a href="#regexlit">Literals</a><br>
	133	---A.2. <a href="#regexdot">Dot Operator</a><br>
	134	---A.3. <a href="#regexrep">Repetition Operators</a><br>
	135	---A.4. <a href="#regexbracket">Bracket Expressions</a><br>
	136	---A.5. <a href="#regexassert">Assertions</a><br>
	137	---A.6. <a href="#regexalt">Alternation</a><br>
	138	---A.7. <a href="#regexsub">Subexpressions</a><br>
	139	---A.8. <a href="#regexbackref">Back References</a><br>
	140	---A.9. <a href="#regexcase">Case Sensitivity</a><br>
	141	</p>
	142	<p><b><font size="+2">1.0 – Introduction & Notes <a name="IntroductionNotes"></a></font></b><br>
	143	</p><div class="desc">
	144	<p>This document was written for exclusive use with UnrealIRCd. Use of this
	145	document with another software package, or distribution of this document with
	146	another software package is strictly prohibited without the written permission
	147	of the UnrealIRCd Development Team. This document may be copied/printed/reproduced/published
	148	as many times as you like, provided it is for use with UnrealIRCd and it is not
	149	modified in anyway. – Copyright UnrealIRCd Development Team 2002-2006</p>
	150	<p>Please read this manual before asking for help, you also REALLY want to take a look at the
	151	<a href="http://www.vulnscan.org/UnrealIRCd/faq/" target="_blank">FAQ</a> since over 80% of your questions/problems are answered in it. If you still
	152	need help you can ask for support at irc.unrealircd.org (port 6667) channel #unreal-support (note
	153	that we REQUIRE you to read the docs and faq and we only help with UnrealIRCd, not with services!).
	154	If you have a real bug (like a crash) then report it at
	155	<a href="http://bugs.unrealircd.org" TARGET="_blank">http://bugs.unrealircd.org</a>.</p></div>
	156
	157	<p><font size="+2"><b>1.1 – Notes on upgrading/mixing 3.1.x -> 3.2 </b></font><a name="notesonolder"></a><br>
	158	</p>
	159	<div class="desc">
	160	<p>In case you are upgrading from Unreal3.1.x to Unreal3.2 you'll notice the whole config file has changed,
	161	you may find it hard at first, but once you've switched you'll find it much better!</p>
	162	<p>Also don't forget to read section 3 about features, although you know already some of them which are in 3.1.x there are several new features too!</p>
	163	<p>It's best not to mix/link 3.1.x with 3.2, but if you really want to, you need at least 3.1.4, but 3.1.5.1 is strongly recommended.</p></div>
	164
	165	<p><font size="+2"><b>1.2 – Notes on upgrading between 3.2 versions</b></font><a name="notesonupgrade"></a><br>
	166	</p><div class="desc">
	167	<p>The recommended way to upgrade is:<br>
	168	Linux:<br>
	169	<ul>
	170	<li>Rename your old UnrealIRCd directory (or otherwise you'll overwrite it in the next step)
	171	<li>Extract the new UnrealIRCd version and run ./Config and make
	172	<li>Copy your old configuration files to the new directory (unrealircd.conf, motd, rules, server.* [SSL certs], network file, etc)</p></ul>
	173	Windows:<br>
	174	<ul>
	175	<li>Copy all of your configuration files to a temporary location.
	176	<li>Run the uninstaller for any previous versions of Unreal you have installed.
	177	<li>Run the installer for the new version of Unreal.
	178	<li>Copy your old configuration files to the new folder.
	179	</ul>
	180	<p>Please also check .RELEASE.NOTES to see what has been changed.
	181	If you notice any changes (or bugs) between version, BE SURE TO READ THE RELEASE NOTES FIRST before reporting it as a bug!.</p></div>
	182
	183	<p><font size="+2"><b>2.0 - Installation</b></font><a name="installation" id="installation"></a><br><div class="desc">
	184	<br>
	185	<b>Tested & Supported Operating Systems:</b><br>
	186	<ul>
	187	<li><b>*NIX versions:</b>
	188	<ul>
	189	<li>Linux (2.2., 2.4., 2.6.*)
	190	<li>FreeBSD (4., 5., 6.*)
	191	<li>NetBSD (2.*)
	192	<li>OpenBSD (3.7, 3.8, 3.9)
	193	<li>Solaris (9, 10)
	194	</ul>
	195	<li><b>Windows version:</b>
	196	<ul>
	197	<li>Windows 2000 (Pro, Server, Advanced Server)
	198	<li>Windows XP (Home, Pro)
	199	<li>Windows 2003
	200	</ul>
	201	<li><b>Architectures tested:</b>
	202	<ul>
	203	<li>ia32 (i386, i486, i586, i686)
	204	<li>ia64
	205	<li>amd64
	206	<li>alpha
	207	</ul>
	208	</ul>
	209	<br>
	210	If you have Unreal3.2 working correctly under other operating systems, please
	211	send the details to <a href="mailto:coders@lists.unrealircd.org">coders@lists.unrealircd.org<br>
	212	</a> </p>
	213	<p><b>Installation Instructions</b><br>
	214	Linux:<br>
	215	<ol>
	216	<li>gunzip -d Unreal3.2.X.tar.gz
	217	<li>tar xvf Unreal3.2.X.tar
	218	<li>cd Unreal3.2
	219	<li>./Config
	220	<li>Answer these questions to the best of your knowledge. Generally if your not
	221	sure, the default will work just fine!
	222	<li>make
	223	<li>Now create your unrealircd.conf and other configuration files, see section 4.
	224	</ol>
	225	<p>
	226	Windows:<br>
	227	<ol>
	228	<li>Run the Unreal installer
	229	<li>Now create your unrealircd.conf and other configuration files, see section 4.
	230	</ol>
	231	</p>
	232	<p> </p></div>
	233	<p><font size="+2"><b>3.0 - Features</b></font>
	234	<a name="features"></a></p><div class="desc">
	235	<p>Some major/nice features are explained in this section. It provides a general overview,
	236	and sometimes refers to the config file (something which you might know nothing about yet).</p>
	237	<p>You can skip this section, however it's very much suggested to read it before/after installing
	238	because otherwise you will not understand concepts such as 'cloaking', 'snomasks', etc.</p></div>
	239
	240	<p><font size="+2"><b>3.1 - Cloaking</b></font><a name="feature_cloaking"></a></p><div class="desc">
	241	<p>Cloaking is a way to hide the real hostname of users, for example if your real host is <i>d5142341.cable.wanadoo.nl</i>,
	242	it will be shown (in join, part, whois, etc) as <i>rox-2DCA3201.cable.wanadoo.nl</i>.
	243	This feature is useful to prevent users flooding each other since they can't see the real host/IP.</p>
	244	<p>This is controlled by usermode +x (like: /mode yournick +x), admins can also force +x to be enabled
	245	by default, or make it so users can never do -x.</p>
	246	<p>A cloaked host is generated by a cloaking module (you are required to have one loaded), currently there's only 1 module included:<br>
	247	<b>cloak:</b> This is the official cloaking module since 3.2.1, it is much more secure than the old
	248	algorithm, it uses md5 internally and requires you to have 3 set::cloak-keys:: consisting of mixed lowercase (a-z),
	249	uppercase (A-Z) and digit (0-9) charachters [eg: "AopAS6WQH2Os6hfosh4SFJHs"]. See example.conf for an example.<br>
	250	<p>Cloak keys MUST be the same on ALL SERVERS in a network. Also cloak keys should be kept SECRET
	251	because it's possible to decode the original host if you know the keys (which makes umode +x useless).</p>
	252	<p>Hint: If you are on *NIX and have to create new cloak keys, you can run './unreal gencloak'
	253	in your shell, which will output 3 random strings that you can use.</p>
	254	</div>
	255	<p><font size="+2"><b>3.2 - Modules</b></font><a name="feature_modules"></a></p><div class="desc">
	256	<p>UnrealIRCd supports modules which is nice because:<br>
	257	- You can load/reload/unload them while the ircd is running (by /rehash). This allows some bugs to be fixed or new features to be added without requiring a restart!<br>
	258	- Other people can create (3rd party) modules with new commands, usermodes and even channelmodes.<br>
	259	UnrealIRCd only comes with a few modules. Take a look at www.unrealircd.com -> modules
	260	or use google to find 3rd party modules.<br>
	261	<p>You need to load at least 2 modules or else you won't be able to boot!:<br>
	262	- the commands module: commands.so (commands.dll on windows)<br>
	263	- a cloaking module: usually cloak.so (cloak.dll on windows).</p>
	264	</div>
	265
	266	<p><font size="+2"><b>3.3 - Snomasks</b></font><a name="feature_snomasks"></a></p><div class="desc">
	267	<p>Snomasks are server notice masks, it's a special type of usermode that controls which
	268	server notices you will receive (mostly used by opers)</p>
	269	<p>It can be set by: /mode yournick +s SNOMASK, for example: /mode yournick +s +cF<br>
	270	To remove certain snomasks, use something like: /mode yournick +s -c<br>
	271	Or you can remove all snomasks by simply doing: /mode yournick -s</p>
	272	<p>The current available snomasks are:<br>
	273	c - local connects<br>
	274	F - far connects (except from U-lined servers)<br>
	275	f - flood notices<br>
	276	k - kill notices [*]<br>
	277	e - 'eyes' notices<br>
	278	j - 'junk' notices<br>
	279	v - vhost notices<br>
	280	G - gline/shun notices<br>
	281	n - local nick change notices<br>
	282	N - remote nick change notices<br>
	283	q - deny nick (Q:line) rejection notices<br>
	284	s - receives server notices [*]<br>
	285	S - receives spamfilter notices<br>
	286	o - receives oper-up notices<br>
	287	[*: this snomask is also allowed to non-ircops]<br>
	288	</p>
	289	<p>You can control which snomasks you automatically get (set::snomask-on-connect) and which you get
	290	on oper (set::snomask-on-oper, oper::snomask)</p>
	291	<p>By default, if a user simply sets mode +s, certain snomasks are set. For non-opers, snomasks +ks, and for opers, snomasks +kscfvGqo.</p></div>
	292
	293	<p><font size="+2"><b>3.4 - Aliases</b></font><a name="feature_aliases"></a></p><div class="desc">
	294	<p>With aliases you can configure server-side alias commands.
	295	You can for example let "/ns identify blah" be forwarded to nickserv (it will be
	296	translated to: privmsg nickserv identify blah). You can even make more complex aliases such as /register can forward to
	297	ChanServ if the first parameter begins with a # and forwarded to NickServ if it doesn't.</p>
	298	<p>Aliases are configured by <a href="#aliasblock">alias blocks</a> in the configuration file, and you can also include
	299	a file with default aliases for most commonly used services.</p></div>
	300
	301	<p><font size="+2"><b>3.5 - Helpop</b></font><a name="feature_helpop"></a></p><div class="desc">
	302	<p>UnrealIRCd has a built-in help system accessible by /helpop. The /helpop command is completely user configurable via
	303	the help block in the configuration file. Additionally, a help.conf is included which contains some basic help for
	304	all commands.<br>
	305	For example <i>/helpop chmodes</i> gives you a overview of all channel modes UnrealIRCd has.<br>
	306	Remember that if you are an ircop (helpop) you will have to prefix the keyword with a '?' character,
	307	so <i>/helpop</i> becomes <i>/helpop ?</i> and
	308	<i>/helpop chmodes</i> becomes <i>/helpop ?chmodes</i> etc..</p></div>
	309
	310	<p><font size="+2"><b>3.6 - Oper access levels</b></font><a name="feature_operaccesslevels"></a></p><div class="desc">
	311	<p>There are several oper levels in UnrealIRCd and you can add additional rights (like to use /gline) to
	312	each of them, that way you can give each oper the privileges they need.</p>
	313	<p>This is controlled by the oper flags in the oper block, see the oper block for more information.</p></div>
	314
	315	<p><font size="+2"><b>3.7 - Oper commands</b></font><a name="feature_opercmds"></a></p><div class="desc">
	316	<p>UnrealIRCd has a lot of powerful oper commands which are explained in <a href="#useropercommands">User & Oper Commands</a>,
	317	you probably want to read those after installing :).</p></div>
	318
	319	<p><font size="+2"><b>3.8 - SSL</b></font><a name="feature_ssl"></a></p><div class="desc">
	320	<p>SSL stands for Secure Socket Layer, with SSL you can make secure encrypted connections.
	321	It can be used to encrypt server<->server traffic, but client<->server traffic can also be encrypted.
	322	You usually use SSL to protect against sniffing and for authentication.</p>
	323	<p>You need to have your IRC server compiled with SSL support. To setup an SSL port you need to set listen::options::ssl.</p>
	324	<p>You cannot connect normally to a SSL port (so don't make port 6667 ssl!), you need a client or a tunnel
	325	that understands the SSL protocol.</p>
	326	<p>Clients that support SSL: <A HREF="http://www.xchat.org/" TARGET="_blank">XChat</a>,
	327	<A HREF="http://www.irssi.org/" TARGET="_blank">irssi</a>,
	328	<A HREF="http://www.mirc.com/" TARGET="_blank">mIRC</a> (6.14 and up,
	329	also requires some <a href="http://www.mirc.co.uk/ssl.html" target="_blank">additional steps</a>)</p>
	330	<p>For clients which do not support SSL you can use a tunnel like
	331	<A HREF="http://www.stunnel.org/" TARGET="_blank">stunnel</A>, here's a stunnel.conf example (for stunnel 4.x):<br>
	332	<pre>
	333	client = yes
	334	[irc]
	335	accept = 127.0.0.1:6667
	336	connect = irc.myserv.com:6697
	337	</pre>
	338	If you then connect to 127.0.0.1 port 6667, your traffic will be encrypted and forwarded to irc.myserv.com
	339	port 6697 (an SSL port).</p>
	340	<p>You should also validate certificates when you connect to servers and not blindly accept them (like in the stunnel example)
	341	else you are still vulnerable to "active sniffing" attacks (ssl redirects), that's however too offtopic
	342	to explain here (learn about SSL, don't ask us). [mIRC and xchat pop up a window asking you to allow/reject a certificate,
	343	so that's good].</p></div>
	344	<p><font size="+2"><b>3.9 - IPv6</b></font><a name="feature_ipv6"></a></p><div class="desc">
	345	<p>UnrealIRCd supports IPv6, since beta15 it seems to be stable.<br>
	346	Your OS needs to have IPv6 support and you need to enable IPv6 support in UnrealIRCd during ./Config as well.<br>
	347	<p>Although microsoft has an experimental IPv6 implementation for w2k/XP it is not (yet) supported by UnrealIRCd.</p></div>
	348
	349	<p><font size="+2"><b>3.10 - Zip links</b></font><a name="feature_ziplinks"></a></p><div class="desc">
	350	<p>Zip links can be turned on for server<->server links, it compresses the data by using zlib.
	351	It can save 60-80% bandwidth... So it's quite useful for low-bandwidth links or links with
	352	many users, it can help a lot when you are linking since a lot of data is sent about every user/channel/etc.</p>
	353	<p>To compile with zip links support, you need to answer Yes to the zlib question in ./Config and set it in link::options::zip
	354	(on both sides)</p></div>
	355
	356	<p><font size="+2"><b>3.11 - Dynamic DNS/IP linking support</b></font><a name="feature_dyndns"></a></p><div class="desc">
	357	<p>UnrealIRCd has some (new) nice features which helps dynamic IP users using dynamic DNS (like blah.dyndns.org).
	358	If you are linking two dynamic DNS hosts, then set link::options::nodnscache and link::options::nohostcheck.
	359	</p></div>
	360
	361	<p><font size="+2"><b>3.12 - Anti-Flood features</b></font><a name="feature_antiflood"></a></p><div class="desc">
	362	<p>
	363	<b>Throttling</b><br>
	364	Throttling is a method that allows you to limit how fast a user can disconnect and then reconnect to your server.
	365	You can config it in your set::throttle block to allow X connections in YY seconds from the same IP.<br>
	366	<b>Channel modes</b><br>
	367	There are also some channel modes which can be very effective against floods. To name a few:<br>
	368	<b>K</b> = no /knock, <b>N</b> = no nickchanges, <b>C</b> = no CTCPs, <b>M</b> = only registered users can talk, <b>j</b> = join throttling (per-user basis)<br>
	369	As of beta18 there's also a much more advanced channelmode +f...<br>
	370	<b>Channel mode f</b><br>
	371	Instead of using scripts and bots to protect against channel floods it is now build into the ircd.<br>
	372	An example +f mode is: <i>*** Blah sets mode: +f [10j]:15</i><br>
	373	This means 10 joins per 15 seconds are allowed in the channel, if the limit is hit, the channel will be set +i automatically.<br>
	374	The following floodtypes are available:<br>
	375	<table border=1 cellpadding=3 cellspacing=1>
	376	<tr><td>type:</td><td>name:</td><td>default action:</td><td>other avail. actions:</td><td>comments</td></tr>
	377	<tr><td>c</td><td>CTCPs</td><td>auto +C</td><td>m, M</td><td> </td></tr>
	378	<tr><td>j</td><td>joins</td><td>auto +i</td><td>R</td><td> </td></tr>
	379	<tr><td>k</td><td>knocks</td><td>auto +K</td><td> </td><td><font size=-1>(counted for local clients only)</font></td></tr>
	380	<tr><td>m</td><td>messages/notices</td><td>auto +m</td><td>M</td><td> </td></tr>
	381	<tr><td>n</td><td>nickchanges</td><td>auto +N</td><td> </td><td> </td></tr>
	382	<tr><td>t</td><td>text</td><td>kick</td><td>b</td><td>per-user messages/notices like the old +f. Will kick or ban the user.</td></tr>
	383	</table>
	384	<p />
	385	Example:
	386	<pre>
	387	<font color=green>*** ChanOp sets mode: +f [20j,50m,7n]:15</font>
	388	<ChanOp> lalala
	389	<font color=green>*** Evil1 (~fdsdsfddf@Clk-17B4D84B.blah.net) has joined #test
	390	*** Evil2 (~jcvibhcih@Clk-3472A942.xx.someispcom) has joined #test
	391	*** Evil3 (~toijhlihs@Clk-38D374A3.aol.com) has joined #test
	392	*** Evil4 (~eihjifihi@Clk-5387B42F.dfdfd.blablalba.be) has joined #test</font>
	393	-- snip XX lines --
	394	<font color=green>*** Evil21 (~jiovoihew@Clk-48D826C3.e.something.org) has joined #test</font>
	395	<font color=brown>-server1.test.net:#test *** Channel joinflood detected (limit is 20 per 15 seconds), putting +i</font>
	396	<font color=green>*** server1.test.net sets mode: +i</font>
	397	<Evil2> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
	398	<Evil12> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
	399	<Evil15> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
	400	<Evil10> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
	401	<Evil8> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
	402	-- snip XX lines --
	403	<font color=brown>-server1.test.net:#test *** Channel msg/noticeflood detected (limit is 50 per 15 seconds), putting +m</font>
	404	<font color=green>*** server1.test.net sets mode: +m</font>
	405	<font color=green>*** Evil1 is now known as Hmmm1</font>
	406	<font color=green>*** Evil2 is now known as Hmmm2</font>
	407	<font color=green>*** Evil3 is now known as Hmmm3</font>
	408	<font color=green>*** Evil4 is now known as Hmmm4</font>
	409	<font color=green>*** Evil5 is now known as Hmmm5</font>
	410	<font color=green>*** Evil6 is now known as Hmmm6</font>
	411	<font color=green>*** Evil7 is now known as Hmmm7</font>
	412	<font color=green>*** Evil8 is now known as Hmmm8</font>
	413	<font color=brown>-server1.test.net:#test *** Channel nickflood detected (limit is 7 per 15 seconds), putting +N</font>
	414	<font color=green>*** server1.test.net sets mode: +N</font>
	415	</pre>
	416
	417	In fact, it can get even more advanced/complicated:<br>
	418	Instead of the default action, you can for some floodtypes specify another one, for example: <i>+f [20j#R,50m#M]:15</i><br>
	419	This will set the channel +R if the joinlimit is reached (>20 joins in 15 seconds),
	420	and will set the channel +M if the msg limit is reached (>50 messages in 15 seconds).<br>
	421	<br>
	422	There's also a "remove mode after X minutes" feature: <i>+f [20j#R5]:15</i> will set the channel +R if the
	423	limit is reached and will set -R after 5 minutes.<br>
	424	A server can have a default unsettime (set::modef-default-unsettime), so if you type <i>+f [20j]:15</i> it could get
	425	transformed into <i>+f [20j#i10]:15</i>, it's just a default, you can still set [20j#i2]:15 or something like that,
	426	and you can also disable the remove-chanmode completely by doing a +f [20j#i0]:15 (an explicit 0).<br>
	427	<br>
	428	The old +f mode (msgflood per-user) is also still available as 't', +f 10:6 is now called +f [10t]:6 and
	429	+f *20:10 is now +f [20t#b]:10. Currently the ircd will automatically convert old +f mode types to new ones.
	430	Note that there's no unsettime feature available for 't' bans ([20t#b30]:15 does not work).<br>
	431	<br>
	432	What the best +f mode is heavily depends on the channel... how many users does it have? do you have a game that makes users
	433	msg a lot (eg: trivia) or do users often use popups? is it some kind of mainchannel or in auto-join? etc..<br>
	434	There's no perfect channelmode +f that is good for all channels, but to get you started have a look at the next example and modify
	435	it to suit your needs:<br>
	436	+f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15<br>
	437	30 joins per 15 seconds, if limit is reached set channel +i for 10 minutes<br>
	438	40 messages per 15 seconds, if limit is reached set channel +m for 10 minutes<br>
	439	7 ctcps per 15 seconds, if limit is reached set channel +C for 15 minutes<br>
	440	10 nickchanges per 15 seconds, if limit is reached set channel +N for 15 minutes<br>
	441	30 knocks per 15 seconds, if limit is reached set channel +K for 10 minutes<br>
	442
	443	If it's some kind of large user channel (>75 users?) you will want to increase the join sensitivity (to eg: 50) and the
	444	message limit as well (to eg: 60 or 75).<br>
	445	Especially the remove-mode times are a matter of taste.. you should think like.. what if no op is available to handle
	446	the situation, do I want to have the channel locked for like 15 minutes (=not nice for users) or 5 minutes (=likely the flooders
	447	will just wait 5m and flood again). It also depends on the floodtype, users unable to join (+i) or speak (+m) is worse than
	448	having them unable to change their nick (+N) or send ctcps to the channel (+C) so you might want to use different removal times.
	449	<br>
	450	<b>Channel mode j</b><br>
	451	The +f mode includes a feature to prevent join floods, however this feature is "global." For
	452	example, if it is set to 5:10 and 5 <u>different</u> users join in 10 seconds, the flood
	453	protection is triggered. Channel mode +j is different. This mode works on a per-user basis.
	454	Rather than protecting against join floods, it is designed to protect against join-part floods
	455	(revolving door floods). The mode takes a parameter of the form X:Y where X is the number of
	456	joins and Y is the number of seconds. If a user exceeds this limit, he/she will be prevented
	457	from joining the channel.
	458	</p></div>
	459
	460	<p><font size="+2"><b>3.13 - Ban types</b></font><a name="feature_bantypes"></a></p><div class="desc">
	461	<p>
	462	<b>Basic bantypes and cloaked hosts</b><br>
	463	UnrealIRCd supports the basic bantypes like <i>+b nick!user@host</i>.<br>
	464	Also, if a masked host of someone is 'rox-ACB17294.isp.com' and you place a ban !@rox-ACB17294.isp.com,
	465	then if the user sets himself -x (and his hosts becomes for example 'dial-123.isp.com) then the ban
	466	will still match. Bans are always checked against real hosts AND masked hosts.<br>
	467	IP bans are also available (eg: !@128.*) and are also always checked.<br>
	468	<br>
	469	Bans on cloaked IPs require some explanation:<br>
	470	If a user has the IP 1.2.3.4 his cloaked host could be 341C6CEC.8FC6128B.303AEBC6.IP.<br>
	471	If you ban !@341C6CEC.8FC6128B.303AEBC6.IP you would ban !@1.2.3.4 (obvious...)<br>
	472	If you ban !@.8FC6128B.303AEBC6.IP you ban !@1.2.3.<br>
	473	If you ban !@.303AEBC6.IP you ban !@1.2.<br>
	474	This information might be helpful to you when deciding how broad a ban should be.<br>
	475	<br>
	476	<b>Extended bantypes</b><br>
	477	Extended bans look like ~[!]<type>:<stuff>. Currently the following types are available:<br>
	478	<table border=1>
	479	<tr><td>type:</td><td>name</td><td>explanation:</td></tr>
	480	<tr><td>~q</td><td>quiet</td><td>People matching these bans can join but are unable to speak,
	481	unless they have +v or higher. <i>Ex: ~q:!@blah.blah.com</i></td></tr>
	482	<tr><td>~n</td><td>nickchange</td><td>People matching these bans cannot change nicks,
	483	unless they have +v or higher. <i>Ex: ~n:!@*.aol.com</i></td></tr>
	484	<tr><td>~c</td><td>[prefix]channel</td><td>If the user is in this channel then (s)he is unable to join.
	485	A prefix can also be specified (+/%/@/&/~) which means that it will only match if the user has
	486	that rights or higher on the specified channel.
	487	<i>Ex: +b ~c:#lamers, +e ~c:@#trusted </i></td></tr>
	488	<tr><td>~r</td><td>realname</td><td>If the realname of a user matches this then (s)he is unable to join.<br>
	489	<i>Ex: ~r:Stupid_bot_script</i><br>
	490	NOTE: an underscore ('_') matches both a space (' ') and an underscore ('_'), so this ban would match
	491	'Stupid bot script v1.4'.</td></tr>
	492	</table>
	493	These bantypes are also supported in the channel exception list (+e).<br>
	494	Modules can also add other extended ban types.<br>
	495	</p></div>
	496
	497	<p><font size="+2"><b>3.14 - Spamfilter</b></font><a name="feature_spamfilter"></a></p><div class="desc">
	498	<p>Spamfilter is a new system to fight spam, advertising, worms and other things. It works a bit like
	499	the badwords system but has several advantages.</p>
	500	<p>Spamfilters are added via the /spamfilter command which uses the following syntax:<br>
	501	<b>/spamfilter [add\|del\|remove\|+\|-] [type] [action] [tkltime] [reason] [regex]</b><br>
	502	<table border=0>
	503	<tr valign="top"><td><b>[type]</b></td><td> specifies the target type:<br>
	504	<table>
	505	<tr><td><b>Char:</b></td><td><b>Config item:</b></td><td><b>Description:</b></td></tr>
	506	<tr><td>c</td><td>channel</td><td>Channel message</td></tr>
	507	<tr><td>p</td><td>private</td><td>Private message (from user->user)</td></tr>
	508	<tr><td>n</td><td>private-notice</td><td>Private notice</td></tr>
	509	<tr><td>N</td><td>channel-notice</td><td>Channel notice</td></tr>
	510	<tr><td>P</td><td>part</td><td>Part reason</td></tr>
	511	<tr><td>q</td><td>quit</td><td>Quit reason</td></tr>
	512	<tr><td>d</td><td>dcc</td><td>DCC filename</td></tr>
	513	<tr><td>a</td><td>away</td><td>Away message</td></tr>
	514	<tr><td>t</td><td>topic</td><td>Setting a topic</td></tr>
	515	<tr><td>u</td><td>user</td><td>User ban, will be matched against nick!user@host:realname</td></tr>
	516	</table>
	517	You can specify multiple targets, like: cpNn</td></tr>
	518	<tr valign="top"><td><b>[action]</b></td><td> specifies the action to be taken (only 1 action can be specified)<br>
	519	<table>
	520	<tr><td>kill</td><td>kills the user</td></tr>
	521	<tr><td>tempshun</td><td>shuns the current session of the user (if [s]he reconnects the shun is gone)</td></tr>
	522	<tr><td>shun</td><td>puts a shun on the host</td></tr>
	523	<tr><td>kline</td><td>puts a kline on the host</td></tr>
	524	<tr><td>gline</td><td>puts a gline on the host</td></tr>
	525	<tr><td>zline</td><td>puts a zline on the host</td></tr>
	526	<tr><td>gzline</td><td>puts a gzline (global zline) on the host</td></tr>
	527	<tr><td>block</td><td>block the message only</td></tr>
	528	<tr><td>dccblock</td><td>mark the user so (s)he's unable to send any DCCs</td></tr>
	529	<tr valign="top"><td>viruschan</td><td>part all channels, join set::spamfilter::virus-help-channel, disables all commands
	530	except PONG, ADMIN, and msg/notices to set::spamfilter::virus-help-channel</td></tr>
	531	</table></tr></td>
	532	<tr valign="top"><td><b>[tkltime]</b></td><td> The duration of the *line/shun added by the filter, use '-' to use the default or to skip
	533	(eg: if action = 'block')</td></tr>
	534	<tr valign="top"><td><b>[reason]</b></td><td> Block/*line/shun reason.. you CANNOT use spaces in this, but underscores ('_') will be translated
	535	into spaces at runtime. And double underscore ('__') gets an underscore ('_'). Again, use '-' to use the default reason.</td></tr>
	536	<tr valign="top"><td><b>[regex]</b></td><td> this is the actual regex or 'bad word' where we should block on and perform the action at</td></tr>
	537	</table>
	538	<br>
	539	Here's an example: <i>/spamfilter add pc gline - - Come watch me on my webcam</i><br>
	540	If the text <i>come watch me on my webcam</i> is found in either a private msg or a channel msg
	541	then the message will be blocked and a gline will be added immediately.<br>
	542	Another example: <i>/spamfilter add pc block - - come to irc\..+\..+</i><br>
	543	This is a regex that will match on <i>Hi, come to irc.blah.net</i> etc....<br>
	544	And an example with specified time/reason:<br>
	545	<i>/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam</i><br>
	546	If <i>come watch me on my webcam</i> is found in a private msg then the user is glined for 3 hours
	547	with the reason <i>Please go to www.viruscan.xx/nicepage/virus=blah</i>.<br>
	548	<br>
	549	Spamfilters added with /spamfilter are network-wide. They work regardless of whether the user/channel
	550	has mode +G set, only opers and ulines (services) are exempted from filtering.
	551	</p>
	552	<p>You can also add spamfilters in the config file but these will be local spamfilters (not
	553	network-wide, though you could use remote includes for this).
	554	The syntax of these spamfilter { } blocks are explained <a href="#spamfilter">here</a><br>
	555	Example:<br>
	556	<pre>spamfilter {
	557	regex "//write \$decode\(.+\\|.+load -rs";
	558	target { private; channel; };
	559	reason "Generic $decode exploit";
	560	action block;
	561	};</pre></p>
	562
	563	<p><b>set::spamfilter::ban-time</b> allows you to modify the default ban time for *lines/shuns added by spamfilter (default: 1 day)<br>
	564	<b>set::spamfilter::ban-reason</b> allows you to specify a default reason (default: 'Spam/advertising')<br>
	565	<b>set::spamfilter::virus-help-channel</b> allows you to specify the channel to join for action 'viruschan' (default: #help)<br>
	566	<b>set::spamfilter::virus-help-channel-deny</b> allows you to block any normal joins to virus-help-channel (default: no)<br>
	567	</p>
	568	<p>
	569	<font size="+1"><B>Slow Spamfilter Detection</B></font><a name="feature_spamfilter_slow"></a><br>
	570	A spamfilter regex can slow down the IRCd considerably. This really depends
	571	on the regex you use (and how the regex engine handles it), some are very
	572	fast and UnrealIRCd can execute thousands of them per second. Others can be
	573	extremely slow, take several seconds to execute, and could freeze the IRCd.<br>
	574	To help against this, Unreal comes with Slow Spamfilter Detection: For each
	575	spamfilter, Unreal checks, each time it executes, how long it takes to
	576	execute. Once a certain threshold is reached the IRCd will warn or even remove
	577	the spamfilter.<br>
	578	Warning is configured through <b>set::spamfilter::slowdetect-warn</b> (default: 250ms)
	579	and automatic deletion is configured by <b>set::spamfilter::slowdetect-fatal</b> (default: 500ms).
	580	You can set both settings to 0 (zero) to disable slow spamfilter detection.<br>
	581	This feature is currently not available on Windows.<br>
	582	</p>
	583	</div>
	584
	585	<p><font size="+2"><b>3.15 - CIDR</b></font><a name="feature_cidr"></a></p><div class="desc">
	586	<p>UnrealIRCd now has support for CIDR (Classless Interdomain Routing). CIDR allows you to ban
	587	IP ranges. IPs are allocated to ISPs using CIDR, therefore, being able to set a CIDR based ban
	588	allows you to easily ban an ISP. Unreal supports CIDR for both IPv4 and IPv6. CIDR masks may be
	589	used in the allow::ip, oper::from::userhost, ban user::mask, ban ip::mask, except ban::mask,
	590	except throttle::mask, and except tkl::mask (for gzline, gline, and shun). Additionally, CIDR
	591	can be used in /kline, /gline, /zline, /gzline, and /shun. Unreal uses the standard syntax of
	592	IP/bits, e.g., 127.0.0.0/8 (matches 127.0.0.0 - 127.255.255.255), and fe80:0:0:123::/64
	593	(matches fe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff).</p></div>
	594
	595	<p><font size="+2"><b>3.16 - Nick Character Sets</b></font><a name="feature_nickchars"></a></p><div class="desc">
	596	<p>UnrealIRCd now has the ability to specify which charsets/languages should be allowed
	597	in nicknames. You do this in <b>set::allowed-nickchars</b>.<br>
	598	A table of all possible choices:<br>
	599	<table border="1">
	600	<tr><td><b>Name:</b></td><td><b>Description:</b></td><td><b>Character set/encoding:</b></td></tr>
	601	<tr><td>catalan</td><td>Catalan characters</td><td>iso8859-1 (latin1)</td></tr>
	602	<tr><td>danish</td><td>Danish characters</td><td>iso8859-1 (latin1)</td></tr>
	603	<tr><td>dutch</td><td>Dutch characters</td><td>iso8859-1 (latin1)</td></tr>
	604	<tr><td>french</td><td>French characters</td><td>iso8859-1 (latin1)</td></tr>
	605	<tr><td>german</td><td>German characters</td><td>iso8859-1 (latin1)</td></tr>
	606	<tr><td>swiss-german</td><td>Swiss-German characters (no es-zett)</td><td>iso8859-1 (latin1)</td></tr>
	607	<tr><td>icelandic</td><td>Icelandic characters</td><td>iso8859-1 (latin1)</td></tr>
	608	<tr><td>italian</td><td>Italian characters</td><td>iso8859-1 (latin1)</td></tr>
	609	<tr><td>spanish</td><td>Spanish characters</td><td>iso8859-1 (latin1)</td></tr>
	610	<tr><td>swedish</td><td>Swedish characters</td><td>iso8859-1 (latin1)</td></tr>
	611	<tr><td><b>latin1</b></td><td>catalan, danish, dutch, french, german, swiss-german, spanish, icelandic, italian, swedish</td><td>iso8859-1 (latin1)</td></tr>
	612	<tr><td>hungarian</td><td>Hungarian characters</td><td>iso8859-2 (latin2), windows-1250</td></tr>
	613	<tr><td>polish</td><td>Polish characters</td><td>iso8859-2 (latin2)</td></tr>
	614	<tr><td>romanian</td><td>Romanian characters</td><td>iso8859-2 (latin2), windows-1250, iso8859-16</td></tr>
	615	<tr><td><b>latin2</b></td><td>hungarian, polish, romanian</td><td>iso8859-2 (latin2)</td></tr>
	616	<tr><td>polish-w1250</td><td>Polish characters, windows variant (unfortunately more common than iso)</td><td>windows-1250</td></tr>
	617	<tr><td>slovak-w1250</td><td>Slovak characters, windows variant</td><td>windows-1250</td></tr>
	618	<tr><td>czech-w1250</td><td>Czech characters, windows variant</td><td>windows-1250</td></tr>
	619	<tr><td><b>windows-1250</b></td><td>polish-w1250, slovak-w1250, czech-w1250, hungarian, romanian</td><td>windows-1250</td></tr>
	620	<tr><td>greek</td><td>Greek characters</td><td>iso8859-7</td></tr>
	621	<tr><td>turkish</td><td>Turkish characters</td><td>iso8859-9</td></tr>
	622	<tr><td>russian-w1251</td><td>Russian characters</td><td>windows-1251</td></tr>
	623	<tr><td>belarussian-w1251</td><td>Belarussian characters</td><td>windows-1251</td></tr>
	624	<tr><td>ukrainian-w1251</td><td>Ukrainian characters</td><td>windows-1251</td></tr>
	625	<tr><td><b>windows-1251</b></td><td>russian-w1251, belarussian-w1251, ukrainian-w1251</td><td>windows-1251</td></tr>
	626	<tr><td>hebrew</td><td>Hebrew characters</td><td>iso8859-8-I/windows-1255</td></tr>
	627	<tr><td>chinese-simp</td><td>Simplified Chinese</td><td>Multibyte: GBK/GB2312</td></tr>
	628	<tr><td>chinese-trad</td><td>Tradditional Chinese</td><td>Multibyte: GBK</td></tr>
	629	<tr><td>chinese-ja</td><td>Japanese Hiragana/Pinyin</td><td>Multibyte: GBK</td></tr>
	630	<tr><td><b>chinese</b></td><td>chinese-*</td><td>Multibyte: GBK</td></tr>
	631	<tr><td><b>gbk</b></td><td>chinese-*</td><td>Multibyte: GBK</td></tr>
	632	</table>
	633	<p>NOTE 1: Please note that some combinations can cause problems.
	634	For example, combining latin* and chinese-* can not be properly handled by
	635	the IRCd and Unreal will print an error.
	636	Mixing of other charsets might cause display problems, so Unreal will print out
	637	a warning if you try to mix latin1/latin2/greek/other incompatible groups.</p>
	638	<p>NOTE 2: Casemapping (if a certain lowercase character belongs to an upper one) is done according to
	639	US-ASCII, this means that o" and O" are not recognized as 'the same character' and hence someone can
	640	have a nick with B"ar and someone else BA"r at the same time. This is a limitation of the current system
	641	and IRCd standards that cannot be solved anytime soon. People should be aware of this limitation.
	642	Note that this limitation has always also been applied to channels, in which nearly all characters were always
	643	permitted and US-ASCII casemapping was always performed.</p>
	644	<p>NOTE 3: The basic nick characters (a-z A-Z 0-9 [ \ ] ^ _ - { \| }) are always allowed/included.</p>
	645
	646	Example 1, for people of western europe:<br>
	647	<pre>set { allowed-nickchars { latin1; }; };</pre>
	648	Example 2, if you have mainly chinese users and want to allow "normal" chinese characters:<br>
	649	<pre>set { allowed-nickchars { chinese-simp; chinese-trad; }; };</pre>
	650	</p></div>
	651
	652	<p><font size="+2"><b>3.17 - CGI:IRC Support</b></font><a name="feature_cgiirc"></a></p><div class="desc">
	653	<p>UnrealIRCd has support for CGI:IRC host spoofing, which means you can mark specific CGI:IRC
	654	gateways as "trusted" which will cause the IRCd to show the users' real host/ip everywhere on
	655	IRC, instead of the host/ip of the CGI:IRC-gateway.</p>
	656	<p>See the <a href="#cgiirc">cgiirc block</a> for information on how to configure this.</p>
	657	</div>
	658
	659	<p><font size="+2"><b>3.18 - Time Synchronization</b></font><a name="feature_timesync"></a></p><div class="desc">
	660	<p>Having correct time is extremely important for IRC servers. Without correct time, channels can desynch, innocent
	661	users can be killed, channels might not show up properly in /LIST, in short: huge trouble will arrise.</p>
	662	<p>UnrealIRCd has some build-in time synchronization support.
	663	Although not optimal (time can still be off a few seconds), it should get rid of most time differences.
	664	If you can, you are still recommended to run time synchronization software such as ntpd on *NIX or
	665	the time synchronization service on Windows (in that case, you can turn off Unreal's time synchronization, more on that later).</p>
	666	<p>What UnrealIRCd does (by default) is do a one-shot timesync attempt when booting. It sends (by default) a request
	667	to multiple time servers and when it gets the first (fastest) reply, it will adjust the internal ircd clock
	668	(NOT the system clock). If, for some reason, Unreal does not get a reply from the timeserver within 3 seconds,
	669	the IRCd will continue to boot regardlessly (should rarely happen).</p>
	670	<p>Time synchronization is configured (and can be turned off) through the <b>set::timesynch</b> block, see
	671	the <a href="#setblock">set documentation</a> for more information.</p>
	672	</div>
	673
	674	<p><font size="+2"><b>3.19 - Other features</b></font><a name="feature_other"></a></p><div class="desc">
	675	<p>UnrealIRCd has a lot of features so not everything is covered here... You'll find that out by yourself.</p></div>
	676
	677	<p> </p>
	678	<p><font size="+2"><b>4.0 - Configuring your unrealircd.conf</b></font>
	679	<a name="configuringyourunrealircdconf"></a></p><div class="desc">
	680	<p>First of all, creating your first unrealircd.conf will take time (say, 15-60
	681	minutes). Creating a <u>good</u> unrealircd.conf will take even more time.
	682	You should not rush to get the IRCd booted, but rather go through things
	683	step-by-step. If you have any problems, check your syntax, check this manual
	684	and check the <a href="http://www.vulnscan.org/UnrealIRCd/faq/">FAQ</a> before asking for help/reporting a bug.</p></div>
	685	<p><b><font size="+2">4.1 Configuration File Explained</font></b><a name="configurationfileexplained"></a><br><div class="desc">
	686	</p>
	687	<p>The new system uses a block-based format. Each entry, or block, in the new
	688	format has a specific format. The format works like:</p>
	689	<pre>
	690	<block-name> <block-value> {
	691	<block-directive> <directive-value>;
	692	};
	693	</pre></p>
	694	<p><block-name> is the type of block, such as me, or admin. <block-value>
	695	sometimes specifies a value, such as /oper login, but other times it will be
	696	a sub-type such as in ban user.</p>
	697	<p><block-directive> is an individual variable specific to the block, and
	698	<directive-value> is the Associated value. If <directive-value>
	699	contains spaces, or characters that represents a comment it must be contained
	700	in double quotes. If you want to use a quote character inside a quoted string
	701	use \" and it will be understood as a quote character.</p>
	702	<p> A <block-directive> can have directives within it, if that’s the
	703	case it will have it's own set of curly braces surrounding it. Some blocks do
	704	not have directives and are specified just by <block-value>, such as include.
	705	Also note that there is no set format, meaning the whole block can appear on
	706	one line or over multiple lines. The format above is what is normally used (and
	707	what will be used in this file) because it is easy to read. </p>
	708	<p>Note: the configuration file is currently case sensitive so <i>BLOCK-NAME</i> is not
	709	the same as <i>block-name</i>. There is a special notation used to talk about entries
	710	in the config file. For example, to talk about <directive-name> in the
	711	example above, you'd say <block-name>::<block-directive>, and if
	712	that directive has a sub block you want to reverence, you would add another
	713	:: and the name of the sub directive. </p>
	714	<p>To talk about an unnamed directive you would do <block-name>:: which
	715	would in this case mean <block-value>, or it could be an entry in a sub
	716	block that has no name.</p>
	717	<p>Three types of comments are supported:</p>
	718	<p> # One line comment<br>
	719	// One line comment<br>
	720	/* Multi line<br>
	721	comment */<br>
	722	</p>
	723	<p>Now that you know how it works, copy <i>doc/example.conf</i> to your UnrealIRCd
	724	directory (eg: /home/user/Unreal3.2) and rename it to <i>unrealircd.conf</i>
	725	(OR create your <i>unrealircd.conf</i> from scratch).
	726	It's recommended to walk step by step through all block types and
	727	settings in your conf and use this manual as a reference.</p>
	728	<p></p></div>
	729	<p><font class="block_section">4.2 - </font><font class="block_name">Me Block</font>
	730	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the M:Line)</font><a name="meblock"></a><div class="desc">
	731	</p>
	732	<p>Syntax:<br>
	733	<pre>
	734	me {
	735	name <name-of-server>;
	736	info <server-description>;
	737	numeric <server-numeric>;
	738	};
	739	</pre></p>
	740	<p>These values are pretty obvious. The <b>name</b> specifies the name of the server,
	741	<b>info</b> specifies the server's info line, <b>numeric</b> specifies a numeric to
	742	identify the server. This must be a value between 0 and 254 that is UNIQUE to
	743	the server meaning NO other servers on the network may have the same numeric.</p>
	744	<p>Example:<br>
	745	<pre>
	746	me {
	747	name "irc.foonet.com";
	748	info "FooNet Server";
	749	numeric 1;
	750	};
	751	</pre></p></div>
	752	<p></p>
	753	<p><font class="block_section">4.3 - </font><font class="block_name">Admin Block</font>
	754	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the A:Line)</font><a name="adminblock"></a><div class="desc">
	755	</p>
	756	<p>Syntax:<br>
	757	<pre>
	758	admin {
	759	<text-line>;
	760	<text-line>;
	761	};
	762	</pre></p>
	763	<p> </p>
	764	<p>The admin block defines the text displayed in a /admin request. You can specify
	765	as many lines as you want and they can contain whatever information you
	766	choose, but it is standard to include the admins nickname and email address
	767	at a minimum. Other information may include any other contact information you
	768	wish to give.</p>
	769	<p>Example:<br>
	770	<pre>
	771	admin {
	772	"Bob Smith";
	773	"bob";
	774	"widely@used.name";
	775	};
	776	</pre></p></div>
	777	<p></p>
	778	<p><font class="block_section">4.4 - </font><font class="block_name">Class Block</font>
	779	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the Y:Line)</font><a name="classblock"></a><div class="desc">
	780	</p>
	781	<p>Syntax:<br>
	782	<pre>
	783	class <name> {
	784	pingfreq <ping-frequency>;
	785	connfreq <connect-frequency>;
	786	maxclients <maximum-clients>;
	787	sendq <send-queue>;
	788	recvq <recv-queue>;
	789	};
	790	</pre></p>
	791	<p> </p>
	792	<p>Class blocks are classes in which connections will be placed (for example from allow blocks
	793	or servers from link blocks), you generally have multiple class blocks (ex: for servers, clients, opers).</p>
	794	<p><b>name</b> is the descriptive name, like "clients" or "servers", this name is
	795	used for referring to this class from allow/link/oper/etc blocks</p>
	796	<p><b>pingfreq</b> is the number of seconds between PINGs from the server (something between 90 and 180 is recommended).</p>
	797	<p><b>connfreq</b> is used only for servers and is the number of seconds between connection attempts if autoconnect is enabled</p>
	798	<p><b>maxclients</b> specifies the maximum (total) number of clients/servers which can be in this class</p>
	799	<p><b>sendq</b> specifies the amount of data which can be in the send queue (very high for servers with low bandwidth, medium for clients)</p>
	800	<p><b>recvq</b> specifies the amount of data which can be in the receive queue and is used for flood control
	801	(this only applies to normal users, try experimenting with values 3000-8000, 8000 is the default).</p>
	802	<p>Examples:<br>
	803	<pre>
	804	class clients {
	805	pingfreq 90;
	806	maxclients 500;
	807	sendq 100000;
	808	recvq 8000;
	809	};
	810
	811	class servers {
	812	pingfreq 90;
	813	maxclients 10; /* Max servers we can have linked at a time */
	814	sendq 1000000;
	815	connfreq 100; /* How many seconds between each connection attempt */
	816	};
	817	</pre></p>
	818	<p> </p></div>
	819	<p><font class="block_section">4.5 - </font><font class="block_name">Allow Block</font>
	820	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the I:Line)</font><a name="allowblock"></a><div class="desc">
	821	</p>
	822	<p>Syntax:<br>
	823	<pre>
	824	allow {
	825	ip <user@ip-connection-mask>;
	826	hostname <user@host-connection-mask>;
	827	class <connection-class>;
	828	password <connection-password> { <auth-type>; };
	829	maxperip <max-connections-per-ip>;
	830	redirect-server <server-to-forward-to>;
	831	redirect-port <port-to-forward-to>;
	832	options {
	833	<option>;
	834	<option>;
	835	...
	836	};
	837	};
	838	</pre></p>
	839	<p>The allow class is where you specify who may connect to this server, you can have multiple allow blocks.</p>
	840	<p><b>About matching</b><br>
	841	The access control works like this: ip matches OR host matches, so "hostname @"; and "ip *@1.2.3.4"
	842	will mean it will always match. Also the allow blocks are read upside down, so you need specific host/ip allow blocks
	843	AFTER your general @ allow blocks. Additionally, if you want to setup a block that only matches based on IP, then set
	844	the hostname to something invalid, such as "hostname NOBODY;", this will allow the block to only match based on IP.</p>
	845	<p><b>ip</b><br>
	846	The ip mask is in the form user@ip, user is the ident and often set at *, ip is the ipmask.
	847	Some examples: @ (from everywhere), @192.168. (only from addr's starting with 192.168), etc.</p>
	848	<p><b>host</b><br>
	849	Also a user@host hostmask, again.. user is often set at . Some examples: @* (everywhere),
	850	@.wanadoo.fr (only from wanadoo.fr).</p>
	851	<p><b>password</b> (optional)<br>
	852	Require a connect password. You can also specify an password encryption method here.
	853	</p>
	854	<p><b>class</b><br>
	855	Specifies the class name that connections using this allow block will be placed into.
	856	</p>
	857	<p><b>maxperip</b> (optional, but recommended)<br>
	858	Allows you to specify how many connections per IP are allowed to this server (ex: maxperip 4;).
	859	</p>
	860	<p><b>redirect-server</b> (optional)<br>
	861	If the class is full, redirect users to this server (if clients supports it [mIRC 6 does]).</p>
	862	<p><b>redirect-port</b> (optional)<br>
	863	If redirect-server is specified you can set the port here, otherwise 6667 is assumed.</p>
	864	<p><b>options block</b> (optional)<br>
	865	Valid options are:<br>
	866	<b>useip</b> always display IP instead of hostname<br>
	867	<b>noident</b> don't use ident but use username specified by client<br>
	868	<b>ssl</b> only match if this client is connected via SSL<br>
	869	<b>nopasscont</b> continue matching if no password was given (so you can put clients in special classes
	870	if they supply a password).
	871	<p>Examples:<br>
	872	<pre>
	873	allow {
	874	ip *;
	875	hostname *;
	876	class clients;
	877	maxperip 5;
	878	};
	879
	880	allow {
	881	ip @;
	882	hostname @.passworded.ugly.people;
	883	class clients;
	884	password "f00Ness";
	885	maxperip 1;
	886	};
	887	</pre></p></div>
	888	<p> </p>
	889	<p><font class="block_section">4.6 - </font><font class="block_name">Listen Block</font>
	890	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the P:Line)</font><a name="listenblock"></a><div class="desc">
	891	</p>
	892	<p>Syntax:<br>
	893	<pre>
	894	listen <ip:port> {
	895	options {
	896	<option>;
	897	<option>;
	898	...
	899	};
	900	};
	901	</pre></p>
	902	<p> </p>
	903	<p>This block allows you to specify the ports on which the IRCD will listen. If
	904	no options are required, you may specify this without any directives in the
	905	form listen <ip:port>;.</p>
	906	<p><b>ip and port</b><br>
	907	You can set ip to * to bind to all available ips, or specify one to only bind to that ip (usually needed at shell providers).
	908	The port is the port you want to listen on. You can also set the port to a range rather than an individual
	909	value. For example, 6660-6669 would listen on ports 6660 through 6669 (inclusive). IPv6 users, see below.</p>
	910	<p><b>Info for IPv6 users</b><br>
	911	If you have an IPv6 enabled server you need to enclose the IP in brackers.
	912	Like [::1]:6667 (listen at localhost on port 6667). If you are using IPv6 and you
	913	want to listen at a specific IPv4 addr you need to use ::ffff:ipv4ip. For example:
	914	[::ffff:203.123.67.1]:6667 which will listen at 203.123.67.1 on port 6667.
	915	Of course you can also just use *.</p>
	916	<p><b>options block</b> (optional)<br>
	917	You can specify special options for this port if you want, valid options are:<br>
	918	<table border="0">
	919	<TR><TD><center><b>clientsonly</b></center></TD><TD> port is only for clients</TD></TR>
	920	<TR><TD><center><b>serversonly</b></center></TD><TD> port is only for servers</TD></TR>
	921	<TR><TD><center><b>java</b></center></TD><TD> CR javachat support</TD></TR>
	922	<TR><TD><center><b>ssl</b></center></TD><TD> SSL encrypted port</TD></TR>
	923	</table>
	924	</p>
	925
	926	<p>Examples:</p>
	927	<pre>
	928	listen *:6601 {
	929	options {
	930	ssl;
	931	clientsonly;
	932	};
	933	};
	934
	935	</pre></p>
	936	<p>Or if there are no options:</p>
	937	<p>listen *:8067;<br>
	938	listen 213.12.31.126:6667;<br>
	939	listen *:6660-6669;</p></div>
	940	<p><font class="block_section">4.7 - </font><font class="block_name">Oper Block</font>
	941	<font class="block_recommended">RECOMMENDED</font> <font class="block_old">(Previously known as the O:Line)</font><a name="operblock"></a><div class="desc">
	942	</p>
	943	<p>
	944	<pre>oper <name> {
	945	from {
	946	userhost <hostmask>;
	947	userhost <hostmask>;
	948	};
	949	password <password> { <auth-type>; };
	950	class <class-name>;
	951	flags <flags>;
	952	flags {
	953	<flag>;
	954	<flag>;
	955	...
	956	};
	957	swhois <whois info>;
	958	snomask <snomask>;
	959	modes <modes>;
	960	maxlogins <num>;
	961	};
	962	</pre></p>
	963	<p>The oper block allows you to assign IRC Operators for your server. The <b>oper::</b>
	964	specifies the login name for the /oper. The <b>oper::from::userhost</b> is a user@host
	965	mask that the user must match, you can specify more than one hostmask by creating
	966	more than one oper::from::userhost. The <b>oper::password</b> is the password the user
	967	must specify, oper::password:: allows you to specify an authentication method
	968	for this password, valid auth-types are crypt, md5, and sha1, ripemd-160. If
	969	you want to use a plain-text password leave this sub-block out.</p>
	970	<p>Please note that BOTH the login name and password are case sensitive</p>
	971	<p>The <b>oper::class</b> directive specifies the name of a preexisting (appears before
	972	this in the config file) class name that the oper block will use.</p>
	973	<p>The <b>oper::flags</b> directive has two formats. If you wish to use the old style
	974	oper flags i.e., OAa, you use the flags <flags> method, if you want to
	975	use the new style,i.e., services-admin, then you use the flags { <flag>;
	976	} method. Below is a list of all the flags (in both formats) and what they do.</p>
	977	<table width="75%" border="1">
	978	<tr>
	979	<td width="10%"><div align="center"><b>Old Flag</b></div></td>
	980	<td width="16%"><div align="center"><b>New Flag</b></div></td>
	981	<td width="74%"><b>Description</b></td>
	982	</tr>
	983	<tr>
	984	<td height="24"><div align="center">o</div></td>
	985	<td><div align="center">local</div></td>
	986	<td>Makes you a local operator</td>
	987	</tr>
	988	<tr>
	989	<td><div align="center">O</div></td>
	990	<td><div align="center">global</div></td>
	991	<td>Makes you a global operator</td>
	992	</tr>
	993	<tr>
	994	<td><div align="center">C</div></td>
	995	<td><div align="center">coadmin</div></td>
	996	<td>Makes you a coadmin</td>
	997	</tr>
	998	<tr>
	999	<td><div align="center">A</div></td>
	1000	<td><div align="center">admin</div></td>
	1001	<td>Makes you a admin</td>
	1002	</tr>
	1003	<tr>
	1004	<td><div align="center">a</div></td>
	1005	<td><div align="center">services-admin</div></td>
	1006	<td>Makes you a services admin</td>
	1007	</tr>
	1008	<tr>
	1009	<td><div align="center">N</div></td>
	1010	<td><div align="center">netadmin</div></td>
	1011	<td>Makes you a Network Admin</td>
	1012	</tr>
	1013	<tr>
	1014	<td><div align="center">r</div></td>
	1015	<td><div align="center">can_rehash</div></td>
	1016	<td>Oper may use /rehash</td>
	1017	</tr>
	1018	<tr>
	1019	<td><div align="center">D</div></td>
	1020	<td><div align="center">can_die</div></td>
	1021	<td>Oper may use /die</td>
	1022	</tr>
	1023	<tr>
	1024	<td><div align="center">R</div></td>
	1025	<td><div align="center">can_restart</div></td>
	1026	<td>Oper may use /restart</td>
	1027	</tr>
	1028	<tr>
	1029	<td><div align="center">h</div></td>
	1030	<td><div align="center">helpop</div></td>
	1031	<td>Oper receives umode +h (helpop)</td>
	1032	</tr>
	1033	<tr>
	1034	<td><div align="center">w</div></td>
	1035	<td><div align="center">can_wallops</div></td>
	1036	<td>Oper can send /wallops</td>
	1037	</tr>
	1038	<tr>
	1039	<td><div align="center">g</div></td>
	1040	<td><div align="center">can_globops</div></td>
	1041	<td>Oper can send /globops</td>
	1042	</tr>
	1043	<tr>
	1044	<td><div align="center">c</div></td>
	1045	<td><div align="center">can_localroute</div></td>
	1046	<td>Can connect servers locally</td>
	1047	</tr>
	1048	<tr>
	1049	<td><div align="center">L</div></td>
	1050	<td><div align="center">can_globalroute</div></td>
	1051	<td>Can connect servers globally</td>
	1052	</tr>
	1053	<tr>
	1054	<td><div align="center">k</div></td>
	1055	<td><div align="center">can_localkill</div></td>
	1056	<td>Can /kill local users</td>
	1057	</tr>
	1058	<tr>
	1059	<td><div align="center">K</div></td>
	1060	<td><div align="center">can_globalkill</div></td>
	1061	<td>Can /kill global users</td>
	1062	</tr>
	1063	<tr>
	1064	<td><div align="center">b</div></td>
	1065	<td><div align="center">can_kline</div></td>
	1066	<td>Can use /kline</td>
	1067	</tr>
	1068	<tr>
	1069	<td><div align="center">B</div></td>
	1070	<td><div align="center">can_unkline</div></td>
	1071	<td>Can use /kline -u@h</td>
	1072	</tr>
	1073	<tr>
	1074	<td><div align="center">n</div></td>
	1075	<td><div align="center">can_localnotice</div></td>
	1076	<td>Can send local server notices</td>
	1077	</tr>
	1078	<tr>
	1079	<td><div align="center">G</div></td>
	1080	<td><div align="center">can_globalnotice</div></td>
	1081	<td>Can send global server notices</td>
	1082	</tr>
	1083	<tr>
	1084	<td><div align="center">z</div></td>
	1085	<td><div align="center">can_zline</div></td>
	1086	<td>Can use /zline</td>
	1087	</tr>
	1088	<tr>
	1089	<td><div align="center">t</div></td>
	1090	<td><div align="center">can_gkline</div></td>
	1091	<td>Can use /gline, /shun and /spamfilter</td>
	1092	</tr>
	1093	<tr>
	1094	<td><div align="center">Z</div></td>
	1095	<td><div align="center">can_gzline</div></td>
	1096	<td>Can use /gzline</td>
	1097	</tr>
	1098	<tr>
	1099	<td><div align="center">W</div></td>
	1100	<td><div align="center">get_umodew</div></td>
	1101	<td>Sets umode +W when u oper</td>
	1102	</tr>
	1103	<tr>
	1104	<td><div align="center">H</div></td>
	1105	<td><div align="center">get_host</div></td>
	1106	<td>Sets your host to an oper host</td>
	1107	</tr>
	1108	<tr>
	1109	<td><div align="center">v</div></td>
	1110	<td><div align="center">can_override</div></td>
	1111	<td>Can use <a href="#operoverride">OperOverride</a></td>
	1112	</tr>
	1113	<tr>
	1114	<td><div align="center">q</div></td>
	1115	<td><div align="center">can_setq</div></td>
	1116	<td>Can use usermode +q</td>
	1117	</tr>
	1118	<tr>
	1119	<td><div align="center">X</div></td>
	1120	<td><div align="center">can_addline</div></td>
	1121	<td>Can use /addline</td>
	1122	</tr>
	1123	<tr>
	1124	<td><div align="center">d</div></td>
	1125	<td><div align="center">can_dccdeny</div></td>
	1126	<td>Can use /dccdeny and /undccdeny</td>
	1127	</tr>
	1128	</table>
	1129	<p>Certain flags give you other flags by default:</p>
	1130	<table width="59%" border="1">
	1131	<tr>
	1132	<td width="19%"><b>local</b></td>
	1133	<td width="17%"><b>global</b></td>
	1134	<td width="19%"><b>admin/coadmin</b></td>
	1135	<td width="22%"><b>services-admin</b></td>
	1136	<td width="23%"><b>netadmin</b></td>
	1137	</tr>
	1138	<tr>
	1139	<td>can_rehash</td>
	1140	<td>can_rehash</td>
	1141	<td>can_rehash</td>
	1142	<td>can_rehash</td>
	1143	<td>can_rehash</td>
	1144	</tr>
	1145	<tr>
	1146	<td>helpop</td>
	1147	<td>helpop</td>
	1148	<td>helpop</td>
	1149	<td>helpop</td>
	1150	<td>helpop</td>
	1151	</tr>
	1152	<tr>
	1153	<td>can_globops</td>
	1154	<td>can_globops</td>
	1155	<td>can_globops</td>
	1156	<td>can_globops</td>
	1157	<td>can_globops</td>
	1158	</tr>
	1159	<tr>
	1160	<td>can_wallops</td>
	1161	<td>can_wallops</td>
	1162	<td>can_wallops</td>
	1163	<td>can_wallops</td>
	1164	<td>can_wallops</td>
	1165	</tr>
	1166	<tr>
	1167	<td>can_localroute</td>
	1168	<td>can_localroute</td>
	1169	<td>can_localroute</td>
	1170	<td>can_localroute</td>
	1171	<td>can_localroute</td>
	1172	</tr>
	1173	<tr>
	1174	<td>can_localkill</td>
	1175	<td>can_localkill</td>
	1176	<td>can_localkill</td>
	1177	<td>can_localkill</td>
	1178	<td>can_localkill</td>
	1179	</tr>
	1180	<tr>
	1181	<td>can_kline</td>
	1182	<td>can_kline</td>
	1183	<td>can_kline</td>
	1184	<td>can_kline</td>
	1185	<td>can_kline</td>
	1186	</tr>
	1187	<tr>
	1188	<td>can_unkline</td>
	1189	<td>can_unkline</td>
	1190	<td>can_unkline</td>
	1191	<td>can_unkline</td>
	1192	<td>can_unkline</td>
	1193	</tr>
	1194	<tr>
	1195	<td>can_localnotice</td>
	1196	<td>can_localnotice</td>
	1197	<td>can_localnotice</td>
	1198	<td>can_localnotice</td>
	1199	<td>can_localnotice</td>
	1200	</tr>
	1201	<tr>
	1202	<td> </td>
	1203	<td>can_globalroute</td>
	1204	<td>can_globalroute</td>
	1205	<td>can_globalroute</td>
	1206	<td>can_globalroute</td>
	1207	</tr>
	1208	<tr>
	1209	<td> </td>
	1210	<td>can_globalkill</td>
	1211	<td>can_globalkill</td>
	1212	<td>can_globalkill</td>
	1213	<td>can_globalkill</td>
	1214	</tr>
	1215	<tr>
	1216	<td> </td>
	1217	<td>can_globalnotice</td>
	1218	<td>can_globalnotice</td>
	1219	<td>can_globalnotice</td>
	1220	<td>can_globalnotice</td>
	1221	</tr>
	1222	<tr>
	1223	<td> </td>
	1224	<td> </td>
	1225	<td>global</td>
	1226	<td>global</td>
	1227	<td>global</td>
	1228	</tr>
	1229	<tr>
	1230	<td> </td>
	1231	<td> </td>
	1232	<td>can_dccdeny</td>
	1233	<td>can_dccdeny</td>
	1234	<td>can_dccdeny</td>
	1235	</tr>
	1236	<tr>
	1237	<td> </td>
	1238	<td> </td>
	1239	<td> </td>
	1240	<td>can_setq</td>
	1241	<td>can_setq</td>
	1242	</tr>
	1243	<tr>
	1244	<td> </td>
	1245	<td> </td>
	1246	<td> </td>
	1247	<td> </td>
	1248	<td>admin</td>
	1249	</tr>
	1250	<tr>
	1251	<td> </td>
	1252	<td> </td>
	1253	<td> </td>
	1254	<td> </td>
	1255	<td>services-admin</td>
	1256	</tr>
	1257	</table>
	1258	<p>The <b>oper::swhois</b> directive allows you to add an extra line to an opers whois
	1259	information. <font color=blue>[optional]</font></p>
	1260	<p>The <b>oper::snomask</b> directive allows you to preset an oper's server notice mask
	1261	on oper up. For a list of available SNOMASKs, see <a href="#feature_snomasks">Section 3.3</a>
	1262	<font color=blue>[optional]</font></p>
	1263	<p>The <b>oper::modes</b> directive allows you to preset an oper's modes on oper up.
	1264	<font color=blue>[optional]</font></p>
	1265	<p>The <b>oper::maxlogins</b> allows you to restrict the number of concurrent oper logins from this host,
	1266	for example if you set it to 1 then only 1 person can be oper'ed via this block at any time.
	1267	<font color=blue>[optional]</font></p>
	1268
	1269	<p>Example:<br>
	1270	<pre>
	1271	oper bobsmith {
	1272	class clients;
	1273	from {
	1274	userhost bob@smithco.com;
	1275	userhost boblaptop@somedialupisp.com;
	1276	};
	1277	password "f00";
	1278	flags {
	1279	netadmin;
	1280	can_gkline;
	1281	can_gzline;
	1282	can_zline;
	1283	can_restart;
	1284	can_die;
	1285	global;
	1286	};
	1287	swhois "Example of a whois mask";
	1288	snomask frebWqFv;
	1289	};
	1290	</pre></p>
	1291	<a name="operoverride"><b>Some little info about OperOverride:</b><br>
	1292	OperOverride are things like: joining a +ikl channel and going through bans (you need to /invite yourself first however),
	1293	op'ing yourself in a channel, etc.<br>
	1294	The can_override operflag was added as an attempt to stop oper abuse.
	1295	No oper is able to override by default, you would have to give them the can_override flag explicitly.
	1296	<p> </p></div>
	1297	<p><font class="block_section">4.8 - </font><font class="block_name">DRpass Block</font>
	1298	<font class="block_recommended">RECOMMENDED</font> <font class="block_old">(Previously known as the X:Line)</font><a name="drpassblock"></a><div class="desc">
	1299	</p>
	1300	<p>Syntax:<br>
	1301	<pre>
	1302	drpass {
	1303	restart <restart-password> { <auth-type>; };
	1304	die <die-password> { <auth-type>; };
	1305	};</pre></p>
	1306	<p>This block sets the /restart and /die passwords with drpass::restart and drpass::die
	1307	respectively. The drpass::restart:: and drpass::die:: allow you to specify the
	1308	type of authentication used by this item. The currently supported authentication
	1309	types are crypt, md5, and sha1, ripemd-160.</p>
	1310	<p>Example:</p>
	1311	<pre>
	1312	drpass {
	1313	restart "I-love-to-restart";
	1314	die "die-you-stupid";
	1315	};
	1316	</pre></p>
	1317	<p> </p></div>
	1318	<p><font class="block_section">4.9 - </font><font class="block_name">Include Directive</font><a name="includedirective"></a><div class="desc">
	1319	</p>
	1320	<p>Syntax:<br>
	1321	include <file-name>;</p>
	1322	<p>This directive specifies a filename to be loaded as a separate configuration
	1323	file. This file may contain any type of config block and can even include other
	1324	files. Wildcards are supported in the file name to allow you to load multiple
	1325	files at once.</p>
	1326	<p><b>example 1: a network file</b><br>
	1327	<pre>include mynetwork.network;</pre></p>
	1328	<p>That would be the statement to use if you wanted to use a separate network
	1329	file. Separate network files are no longer required; all the network settings
	1330	can be inserted directly into the unrealircd.conf. Or you can put an include
	1331	statement them to load the file.</p>
	1332	<p><b>example 2: aliases</b><br>
	1333	<pre>include aliases/ircservices.conf</pre></p>
	1334	<p>Another example is to use it for including alias blocks, UnrealIRCd comes with
	1335	some files which (should) contain the right aliases for most services:<br>
	1336	<ul>
	1337	<li>aliases/ircservices.conf (IRCServices, Daylight)
	1338	<li>aliases/epona.conf (Epona)
	1339	<li>aliases/anope.conf (Anope)
	1340	<li>aliases/auspice.conf (Auspice)
	1341	<li>aliases/generic.conf (Magick, Sirius, Wrecked)
	1342	<li>aliases/cygnus.conf (Cygnus)
	1343	<li>aliases/operstats.conf (OperStats)
	1344	<li>aliases/genericstats.conf (GeoStats, NeoStats)
	1345	</ul>
	1346	</p>
	1347	<p></p></div>
	1348	<p><font class="block_section">4.10 - </font><font class="block_name">LoadModule Directive</font>
	1349	<font class="block_required">REQUIRED</font><a name="loadmoduledirective"></a><div class="desc">
	1350	</p>
	1351	<p>Syntax:<br>
	1352	loadmodule <file-name>;</p>
	1353	<p>See <a href="#feature_modules">here</a> why modules are nice/useful.</p>
	1354	<p>Modules that come standard with Unreal3.2:</p>
	1355	<p>commands.so / commands.dll - All the / commands (well not all yet, but will eventually be all) <font color="red">REQUIRED</font><br>
	1356	cloak.so / cloak.dll - Cloaking module <font color="red">REQUIRED</font> (or any other cloaking module)</p>
	1357	<p>So you want to be sure to have these loaded:</p>
	1358	<pre>
	1359	loadmodule "src/modules/commands.so";
	1360	loadmodule "src/modules/cloak.so";
	1361	</pre>
	1362	<p>or on windows:</p>
	1363	<pre>
	1364	loadmodule "modules/commands.dll";
	1365	loadmodule "modules/cloak.dll";
	1366	</pre>
	1367	</div>
	1368	<p><font class="block_section">4.11 - </font><font class="block_name">Log Block</font>
	1369	<font class="block_recommended">RECOMMENDED</font><a name="logblock"></a><div class="desc">
	1370	</p>
	1371	<p>Syntax:<br>
	1372	<pre>
	1373	log <file-name> {
	1374	maxsize <max-file-size>;
	1375	flags {
	1376	<flag>;
	1377	<flag>;
	1378	...
	1379	};
	1380	};
	1381	</pre></p>
	1382	<p>The log block allows you to assign different log files for different purposes.
	1383	The <b>log::</b> contains the name of the log file. <b>log::maxsize</b> is an optional directive
	1384	that allows you to specify a size that the log file will be wiped and restarted.
	1385	You can enter this string using MB for megabytes, KB, for kilobytes, GB, for
	1386	gigabytes. The <b>log::flags</b> specifies which types of information will be in this
	1387	log. See the list of available flags below.</p>
	1388	<p>You may also have multiple log blocks, to log different things to different
	1389	log files.</p>
	1390	<p><b>Available Flags:</b><br>
	1391	<table border=0>
	1392	<tr><td>errors</td><td>self explanatory</td></tr>
	1393	<tr><td>kills</td><td>logs /kill notices</td></tr>
	1394	<tr><td>tkl</td><td>logs info on *lines, shuns and spamfilters (adding/removing/expire)</td></tr>
	1395	<tr><td>connects</td><td>logs user connects/disconnects</td></tr>
	1396	<tr><td>server-connects</td><td>logs server connects/squits</td></tr>
	1397	<tr><td>kline</td><td>logs /kline usage</td></tr>
	1398	<tr><td>oper</td><td>logs oper attempts (both failed and successful)</td></tr>
	1399	<tr><td>sadmin-commands</td><td>logs /sa* (samode, sajoin, sapart, etc.) usage</td></tr>
	1400	<tr><td>chg-commands</td><td>logs /chg* (chghost, chgname, chgident, etc.) usage</td></tr>
	1401	<tr><td>oper-override</td><td>logs operoverride usage</td></tr>
	1402	<tr><td>spamfilter</td><td>logs spamfilter matches</td></tr>
	1403	</table>
	1404	</p>
	1405
	1406	<p>Example:</p>
	1407	<pre>
	1408	log ircd.log {
	1409	maxsize 5MB;
	1410	flags {
	1411	errors;
	1412	kills;
	1413	oper;
	1414	kline;
	1415	tkl;
	1416	};
	1417	};
	1418	</pre></p>
	1419	<p></p></div>
	1420	<p><font class="block_section">4.12 - </font><font class="block_name">TLD Block</font>
	1421	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the T:Line)</font><a name="tldblock"></a><div class="desc">
	1422	</p>
	1423	<p>Syntax:<br>
	1424	<pre>
	1425	tld {
	1426	mask <hostmask>;
	1427	motd <motd-file>;
	1428	rules <rules-file>;
	1429	shortmotd <shortmotd-file>;
	1430	opermotd <opermotd-file>;
	1431	botmotd <botmotd-file>;
	1432	channel <channel-name>;
	1433	options {
	1434	ssl;
	1435	};
	1436	};</pre></p>
	1437	<p>The tld block allows you to specify a motd, rules, and channel for a user based
	1438	on their host. This is useful if you want different motds for different languages.
	1439	The <b>tld::mask</b> is a user@host mask that the user's username and hostname must
	1440	match. The <b>tld::motd</b>, <b>tld::shortmotd</b>, <b>tld::opermotd</b>,
	1441	<b>tld::botmotd</b>, and <b>tld::rules</b> specify the motd, shortmotd, opermotd,
	1442	botmotd, and rules file, respectively, to be displayed to this hostmask.
	1443	The tld::shortmotd, tld::opermotd, and tld::botmotd are optional. <b>tld::channel</b>
	1444	is optional as well, it allows you to specify a channel that this user will be forced
	1445	to join on connect. If this exists it will override the default auto join channel.
	1446	The <b>tld::options</b> block allows you to define additional requirements,
	1447	currently only tld::options::ssl which only displays the file for SSL users, and
	1448	tld::options::remote which only displays the file for remote users, exists.</p>
	1449	<p>TLD entries are matched upside down</p>
	1450	<p>Example:<br>
	1451	<pre>
	1452	tld {
	1453	mask @.fr;
	1454	motd "ircd.motd.fr";
	1455	rules "ircd.rules.fr";
	1456	};</pre></p>
	1457	<p></p></div>
	1458	<p><font class="block_section">4.13 - </font><font class="block_name">Ban Nick Block</font>
	1459	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the Q:Line)</font><a name="bannickblock"></a><div class="desc">
	1460	</p>
	1461	<p>Syntax:<br>
	1462	<pre>
	1463	ban nick {<br>
	1464	mask <nickname>;
	1465	reason <reason-for-ban>;
	1466	};</pre></p>
	1467	<p>The ban nick block allows you to disable use of a nickname on the server. The
	1468	ban::mask allows wildcard masks to match multiple nicks, and ban::reason allows
	1469	you to specify the reason for which this ban is placed. Most commonly these
	1470	blocks are used to ban usage of the nicknames commonly used for network services.</p>
	1471	<p>Example:<br>
	1472	<pre>
	1473	ban nick {
	1474	mask "ChanServ*";
	1475	reason "Reserved for Services";
	1476	};</pre></p>
	1477	<p></p></div>
	1478	<p><font class="block_section">4.14 - </font><font class="block_name">Ban User Block</font>
	1479	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the K:Line)</font><a name="banuserblock"></a><div class="desc">
	1480	</p>
	1481	<p>Syntax:<br>
	1482	<pre>
	1483	ban user {
	1484	mask <hostmask>;
	1485	reason <reason-for-ban>;
	1486	};</pre></p>
	1487	<p>This block allows you to ban a user@host mask from connecting to the server.
	1488	The ban::mask is a wildcard string of a user@host to ban, and ban::reason is
	1489	the reason for a ban being placed. Note, this is only a local ban and therefore
	1490	the user may connect to other servers on the network.</p>
	1491	<p>Example:<br>
	1492	<pre>
	1493	ban user {
	1494	mask tirc@.saturn.bbn.com;
	1495	reason "Idiot";
	1496	};</pre></p>
	1497	<p></p></div>
	1498	<p><font class="block_section">4.15 - </font><font class="block_name">Ban IP Block</font>
	1499	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the Z:Line)</font><a name="banipblock"></a><div class="desc">
	1500	</p>
	1501	<p>Syntax:<br>
	1502	<pre>
	1503	ban ip {
	1504	mask <ipmask>;
	1505	reason <reason-for-ban>;
	1506	};</pre></p>
	1507	<p>The ban ip block bans an IP from accessing the server. This includes both users
	1508	and servers attempting to link. The ban::mask parameter is an IP which may contain
	1509	wildcard characters, and ban::reason is the reason why this ban is being placed.
	1510	Since this ban affects servers it should be used very carefully.</p>
	1511	<p>Example:<br>
	1512	<pre>
	1513	ban ip {
	1514	mask 192.168.1.*;
	1515	reason "Get a real ip u lamer!";
	1516	};</pre></p>
	1517	<p> </p></div>
	1518	<p><font class="block_section">4.16 - </font><font class="block_name">Ban Server Block</font>
	1519	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the q:Line)</font><a name="banserverblock"></a><div class="desc">
	1520	</p>
	1521	<p>Syntax:<br>
	1522	<pre>
	1523	ban server {
	1524	mask <server-name>;
	1525	reason <reason-for-ban>;
	1526	};</pre></p>
	1527	<p>This block disables a server's ability to connect to the network. If the server links
	1528	directly to your server, the link is denied. If the server links to a remote server, the
	1529	local server will disconnect from the network. The ban::mask field specifies a wildcard
	1530	mask to match against the server attempting to connect's name, and ban::reason specifies
	1531	the reason for which this ban has been placed.</p>
	1532	<p>Example:<br>
	1533	<pre>
	1534	ban server {
	1535	mask broken.server.my.network.com;
	1536	reason "Its broken!";
	1537	};</pre></p>
	1538	<p> </p></div>
	1539	<p><font class="block_section">4.17 - </font><font class="block_name">Ban RealName Block</font>
	1540	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the n:Line)</font><a name="banrealnameblock"></a><div class="desc">
	1541	</p>
	1542	<p>Syntax:<br>
	1543	<pre>
	1544	ban realname {
	1545	mask <realname-mask>;
	1546	reason <reason-for-ban>;
	1547	};</pre></p>
	1548	<p>The ban realname block allows you to ban a client based on the GECOS (realname)
	1549	field. This is useful to stop clone floods because often clone bots use the
	1550	same realname. The ban::mask specifies the realname which should be banned.
	1551	The mask may contain wildcards. The ban::reason specifies the reason why this
	1552	ban is being placed.</p>
	1553	<p>Example:<br>
	1554	<pre>
	1555	ban realname {
	1556	mask "Bob*";
	1557	reason "Bob sucks!";
	1558	};</pre></p>
	1559	<p></p></div>
	1560	<p><font class="block_section">4.18 - </font><font class="block_name">Ban Version Block</font>
	1561	<font class="block_optional">OPTIONAL</font> <a name="banversionblock"></a><div class="desc">
	1562	</p>
	1563	<p>Syntax:<br>
	1564	<pre>
	1565	ban version {
	1566	mask <version-mask>;
	1567	reason <reason-for-ban>;
	1568	action [kill\|tempshun\|shun\|kline\|zline\|gline\|gzline];
	1569	};</pre></p>
	1570	<p>The ban version block allows you to ban a client based on the IRC client software they use.
	1571	This makes use of the clients CTCP version reply. Therefore if a client does not
	1572	send out a CTCP version, the ban will not work. This feature is intended to allow you to block
	1573	malicious scripts. The <b>ban::mask</b> specifies the version which should be banned.
	1574	The mask may contain wildcards. The <b>ban::reason</b> specifies the reason why this
	1575	ban is being placed. You can also specify <b>ban::action</b>, <i>kill</i> is the default,
	1576	<i>tempshun</i> will shun the specific user connection only and would work very effective against
	1577	zombies/bots at dynamic IPs because it won't affect innocent users. <i>shun/kline/zline/gline/gzline</i>
	1578	will place a ban of that type on the ip (*@IPADDR), the duration of these bans can be configured
	1579	with set::ban-version-tkl-time and defaults to 1 day.</p>
	1580	<p>Example:<br>
	1581	<pre>
	1582	ban version {
	1583	mask "SomeLameScript";
	1584	reason "SomeLameScript contains backdoors";
	1585	};</pre>
	1586	<pre>
	1587	ban version {
	1588	mask "w00tZombie";
	1589	reason "I hate those hundreds of zombies";
	1590	action zline;
	1591	};</pre>
	1592	</p>
	1593	<p></p></div>
	1594	<p><font class="block_section">4.19 - </font><font class="block_name">Ban Exceptions Block</font>
	1595	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the E:Line)</font><a name="banexceptionblock"></a><div class="desc">
	1596	</p>
	1597	<p>Syntax:<br>
	1598	<pre>
	1599	except ban {
	1600	mask <hostmask>;
	1601	};</pre></p>
	1602	<p>The except ban block allows you to specify a user@host that will override a
	1603	ban placed on a broader host. This is useful when you want an ISP banned, but
	1604	still want specific users to be able to connect. The except::mask directive
	1605	specifies the user@host mask of the client who will be allowed to connect.</p>
	1606	<p>Example:<br>
	1607	<pre>
	1608	except ban {
	1609	mask myident@my.isp.com;
	1610	};</pre></p>
	1611	<p></p></div>
	1612	<p><font class="block_section">4.20 - </font><font class="block_name">TKL Exceptions Block</font>
	1613	<font class="block_optional">OPTIONAL</font><a name="tklexceptionblock"></a><div class="desc">
	1614	</p>
	1615	<p>Syntax:<br>
	1616	<pre>
	1617	except tkl {
	1618	mask <hostmask>;
	1619	type <type>;
	1620	type {
	1621	<type>;
	1622	<type>;
	1623	...
	1624	};
	1625	};</pre></p>
	1626	<p>The except tkl block allows you to specify a user@host that will override a
	1627	tkl ban placed on a broader host. This is useful when you want an ISP banned, but
	1628	still want specific users to be able to connect. The except::mask directive
	1629	specifies the user@host mask of the client who will be allowed to connect. The
	1630	except::type specifies which type of ban this should override. Valid types are
	1631	gline, gzline, qline, gqline, and shun, which make an exception from Glines,
	1632	Global Zlines, Qlines, Global Qlines, and shuns. If the type {} format is used,
	1633	multiple types may be specified.</p>
	1634	<p>Example:<br>
	1635	<pre>
	1636	except tkl {
	1637	mask myident@my.isp.com;
	1638	type gline;
	1639	};</pre></p>
	1640	<p></p></div>
	1641	<p><font class="block_section">4.21 - </font><font class="block_name">Throttle Exceptions Block</font>
	1642	<font class="block_optional">OPTIONAL</font> <a name="throttleexceptionblock"></a>
	1643	</p><div class="desc">
	1644	<p>Syntax:<br>
	1645	<pre>
	1646	except throttle {
	1647	mask <ipmask>;
	1648	};</pre></p>
	1649	<p>The except throttle block allows you to specify an IP mask that will override the
	1650	throttling system. This only works if you have chosen to enable throttling. The
	1651	except::mask specifies an IP mask that will not be banned because of throttling.</p>
	1652	<p>Example<br>
	1653	<pre>
	1654	except throttle {
	1655	mask 192.168.1.*;
	1656	};</pre></p>
	1657	<p></p></div>
	1658	<p><font class="block_section">4.22 - </font><font class="block_name">Deny DCC Block</font>
	1659	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as dccdeny.conf)</font><a name="denydccblock"></a>
	1660	</p><div class="desc">
	1661	<p>Syntax:<br>
	1662	<pre>
	1663	deny dcc {
	1664	filename <file-to-block>;
	1665	reason <reason-for-ban>;
	1666	soft [yes\|no];
	1667	};</pre></p>
	1668	<p>The deny dcc block allows you to specify a filename which will not be allowed
	1669	to be sent via DCC over the server. This is very useful in helping stop distribution
	1670	of trojans and viruses. </p>
	1671	<p>The <b>deny::filename</b> parameter specifies a wildcard mask of the filename to reject
	1672	sends of, and <b>deny::reason</b> specifies the reason why this file is blocked.</p>
	1673	<p>There's also a <b>deny::soft</b> option, if set to 'yes' the dcc is blocked
	1674	unless the user explicitly allows it via /DCCALLOW +nickname-trying-to-send.
	1675	See dccallow.conf for a good example configuration for dccallow.</p>
	1676	<p>Example<br>
	1677	<pre>
	1678	deny dcc {
	1679	filename virus.exe;
	1680	reason "This is a GD Virus";
	1681	};
	1682
	1683	deny dcc {
	1684	filename "*.exe";
	1685	reason "Executable content";
	1686	soft yes;
	1687	};</pre>
	1688	</p></div>
	1689	<p></p>
	1690	<p><font class="block_section">4.23 - </font><font class="block_name">Deny Version Block</font>
	1691	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the V:Line)</font><a name="denyversionblock"></a><div class="desc">
	1692	</p>
	1693	<p> Syntax:<br>
	1694	<pre>
	1695	deny version {
	1696	mask <server-name>;
	1697	version <version-number>;
	1698	flags <compile-flags>;
	1699	};</pre></p>
	1700	<p>This block allows you to deny a server from linking based on the version of
	1701	Unreal it is running and what compile time options it has. The format for this
	1702	block is somewhat complex but isn't too hard to figure out. The deny::mask directive
	1703	specifies a wildcard mask of the server name this applies to. The deny::version
	1704	specifies the protocol number of the version this refers to.</p>
	1705	<p>For example, 3.0 is 2301, 3.1.1/3.1.2 is 2302, 3.2 is 2303. The first character
	1706	of this parameter can be one of the following >, <, =, !. This character
	1707	tells the IRCd how to interpret the version. If the first character is a >
	1708	then all version greater than the specified version are denied, if it is a <
	1709	all versions lower are denied, if it is an = only that version is denied, and
	1710	if it is a ! then all versions except the specified are denied. The deny::flags
	1711	directive allows you to specify what compile time flags the server may or may
	1712	not have. The flags are arranged one after the other with no separation between,
	1713	if a character is prefixed by a ! then it means the server may not have this
	1714	flag compiled into it, if it does not have a ! prefix, then it means the server
	1715	must have this flag compiled.</p>
	1716	<p></p></div>
	1717	<p><font class="block_section">4.24 - </font><font class="block_name">Deny Link Block</font>
	1718	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the D/d:Line)</font><a name="denylinkblock"></a><div class="desc">
	1719	</p>
	1720	<p>Syntax:<br>
	1721	<pre>
	1722	deny link {
	1723	mask <server-name>;
	1724	rule <crule-expression>;
	1725	type <type-of-denial>;
	1726	};</pre></p>
	1727	<p>This block allows you to use specific rules to deny a server from linking.
	1728	The deny::mask specifies a wildcard mask of the server name to apply this rule
	1729	to. The deny::rule directive is very complex. A crule expression allows you
	1730	to control the link in great detail, and it is set up like a programming expression.
	1731	Four operators are supported, connected(<servermask>), returns true if
	1732	a server matching servermask is connected, directcon(<servermask>), returns
	1733	true if the server matching servermask is directly connected to this server,
	1734	via(<viamask>,<servermask>), returns true if a server matching servermask
	1735	is connected by a server matching viamask, and directop(), which returns true
	1736	if the operator issuing a /connect is directly connected to this server. These
	1737	operators can be combined using && (and) and \|\| (or), items may also
	1738	be enclosed in parenthesis to allow grouping. In addition, an operator preceded
	1739	with a ! checks if the operator returned false. If the entire expression evaluates
	1740	to true, then the link is denied. The deny::type allows two different values,
	1741	auto (only applies to autoconnects, /connect will still work), and all (applies
	1742	to all connection attempts).</p>
	1743	<p></p></div>
	1744	<p><font class="block_section">4.25 - </font><font class="block_name">Deny Channel Block</font>
	1745	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as chrestrict.conf)</font><a name="denychannelblock"></a>
	1746	</p><div class="desc">
	1747	<p>Syntax:<br>
	1748	<pre>
	1749	deny channel {
	1750	channel "<channel-mask>";
	1751	reason <reason-for-ban>;
	1752	redirect "<channel-name>";
	1753	warn [on\|off];
	1754	};</pre></p>
	1755	<p> </p>
	1756	<p>The deny channel block allows you to disallow users from joining specific channels.
	1757	The <b>deny::channel</b> directive specifies a wildcard mask of channels the users
	1758	may not join, and the <b>deny::reason</b> specifies the reason why the channel may
	1759	not be joined. Additionally, you may specify a <b>deny::redirect</b>. If this is specified,
	1760	when a user tries to join a channel that matches deny::channel, he/she will be redirected
	1761	to deny::redirect. And there's also <b>deny::warn</b> which (if set to on) will send an
	1762	opernotice (to EYES snomask) if the user tries to join.
	1763	</p>
	1764	<p>Example</p>
	1765	<pre>
	1766	deny channel {
	1767	channel "#unrealsucks";
	1768	reason "No it don't!";
	1769	};
	1770
	1771	deny channel {
	1772	channel "#teensex*";
	1773	reason "You == dead";
	1774	warn on;
	1775	};
	1776
	1777	deny channel {
	1778	channel "#operhelp";
	1779	reason "Our network help channel is #help, not #operhelp";
	1780	redirect "#help";
	1781	};</pre></p>
	1782
	1783	<p></p></div>
	1784	<p><font class="block_section">4.26 - </font><font class="block_name">Allow Channel Block</font>
	1785	<font class="block_optional">OPTIONAL</font><a name="allowchannelblock"></a>
	1786	</p><div class="desc">
	1787	<p>Syntax:<br>
	1788	<pre>
	1789	allow channel {
	1790	channel "<channel-mask>";
	1791	};</pre></p>
	1792	<p>The allow channel block allows you to specify specific channels that users
	1793	may join. The allow::channel directive specifies the wildcard mask of the channels
	1794	which may be joined.</p>
	1795	<p>Example:<br>
	1796	<pre>
	1797	allow channel {
	1798	channel "#something";
	1799	};</pre></p>
	1800	<p></p></div>
	1801	<p><font class="block_section">4.27 - </font><font class="block_name">Allow DCC Block</font>
	1802	<font class="block_optional">OPTIONAL</font><a name="allowdccblock"></a>
	1803	</p><div class="desc">
	1804	<p>Syntax:<br>
	1805	<pre>
	1806	allow dcc {
	1807	filename "<filename-mask>";
	1808	soft [yes\|no];
	1809	};</pre></p>
	1810	<p>The allow dcc blocks allows you to specify exceptions over deny dcc blocks, wildcards
	1811	are permitted. If <b>allow dcc::soft</b> is set to 'yes' it applies to 'soft dcc bans' list,
	1812	if set to 'no' it applies to the normal ('hard') dcc bans.</p>
	1813	<p>Example:<br>
	1814	<pre>
	1815	allow dcc {
	1816	filename ".jpg"; / Images are usually safe */
	1817	soft yes;
	1818	};</pre></p>
	1819	<p></p></div>
	1820	<p><font class="block_section">4.28 - </font><font class="block_name">Vhost Block</font>
	1821	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as vhosts.conf)</font><a name="vhostblock"></a>
	1822	</p><div class="desc">
	1823	<p>Syntax:<br>
	1824	<pre>
	1825	vhost {
	1826	vhost <vhost>;
	1827	from {
	1828	userhost <hostmask>;
	1829	userhost <hostmask>;
	1830	...
	1831	};
	1832	login <login-name>;
	1833	password <password> { <auth-type>; };
	1834	swhois "<swhois info>";
	1835	};</pre></p>
	1836	<p>The vhost block allows you to specify a login/password that can be used with
	1837	the /vhost command to obtain a fake hostname. The vhost::vhost parameter can
	1838	be either a user@host or just a host that the user will receive upon successful
	1839	/vhost. The vhost::from::userhost contains a user@host that the user must match
	1840	to be eligible for the vhost. You may specify more than one hostmask. The vhost::login
	1841	in the login name the user must enter and vhost::password is the password that
	1842	must be entered. The vhost::password:: allows you to specify the type of
	1843	authentication used by this item. The currently supported authentication types
	1844	are crypt, md5, and sha1, ripemd-160. Lastly vhost::swhois allows you to add an extra
	1845	line to a users whois, exactly as it does in the Oper Block oper::swhois.</p>
	1846	<p>Example:<br>
	1847	<pre>
	1848	vhost {
	1849	vhost my.own.personal.vhost.com;
	1850	from {
	1851	userhost my@isp.com;
	1852	userhost myother@isp.com;
	1853	};
	1854	login mynick;
	1855	password mypassword;
	1856	swhois "Im Special";
	1857	};</pre></p>
	1858	<p></p></div>
	1859	<p><font class="block_section">4.29 - </font><font class="block_name">Badword Block</font>
	1860	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as badwords.*.conf)</font><a name="badwordsblock"></a>
	1861	</p><div class="desc">
	1862	<p>Syntax:<br>
	1863	<pre>
	1864	badword <type> {
	1865	word <text-to-match>;
	1866	replace <replace-with>;
	1867	action <replace\|block>;
	1868	};</pre></p>
	1869	<p>The badword block allows you to manipulate the list used for user and channel
	1870	mode +G to strip "badwords". The badword:: specifies the type, valid
	1871	types are channel, message, quit, and all. channel is for the channel +G list, message
	1872	is for the user +G list, quit is for quit message censoring, and all adds it to all three lists.
	1873	The badword::word can be a simple word or a regular expression we should search for. The
	1874	badword::replace is what we should replace this match with. If badword::replace
	1875	is left out, the word is replaced with <censored>. The badword::action defines
	1876	what action should be taken if this badword is found. If you specify replace, then the
	1877	badword is replaced, if you specify block, then the entire message is blocked. If you do
	1878	not specify a badword::action, replace is assumed.</p>
	1879	<p>Example:<br>
	1880	<pre>
	1881	badword channel {
	1882	word shit;
	1883	replace shoot;
	1884	};</pre></p>
	1885	<p></p></div>
	1886	<p><font class="block_section">4.30 - </font><font class="block_name">ULines Block</font>
	1887	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the U:Line)</font><a name="ulinesblock"></a><div class="desc">
	1888	</p>
	1889	<p>Syntax:<br>
	1890	<pre>
	1891	ulines {
	1892	<server-name>;
	1893	<server-name>;
	1894	...
	1895	};</pre></p>
	1896	<p>The ulines block lets you define certain servers as having extra abilities.
	1897	This should only be used for servers such as services and stats. This should
	1898	not be set for a normal server. Each entry is the name of the server which will
	1899	receive the extra abilities.</p>
	1900	<p>Example<br>
	1901	<pre>
	1902	ulines {
	1903	services.mynetwork.com;
	1904	stats.mynetwork.com;
	1905	};</pre></p>
	1906	<p></p></div>
	1907	<p><font class="block_section">4.31 - </font><font class="block_name">Link Block</font>
	1908	<font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as C/N/H:Lines)</font><a name="linkblock"></a>
	1909	</p><div class="desc">
	1910	<p>Syntax:<br>
	1911	<pre>
	1912	link <server-name> {
	1913	username <usermask>;
	1914	hostname <ipmask>;
	1915	bind-ip <ip-to-bind-to>;
	1916	port <port-to-connect-on>;
	1917	password-connect <password-to-connect-with>;
	1918	password-receive <password-to-receive> { <auth-type>; };
	1919	hub <hub-mask>;
	1920	leaf <leaf-mask>;
	1921	leafdepth <depth>;
	1922	class <class-name>;
	1923	ciphers <ssl-ciphers>;
	1924	options {
	1925	<option>;
	1926	<option>;
	1927	...
	1928	};
	1929	};</pre></p>
	1930	<p>This is the block you need for linking servers, please take your time to read all
	1931	this because this one of the hardest things to do and users often make errors ;P</p>
	1932	<p>First of all <b>server-name</b> is the name of your remote server, the name the remote
	1933	server has in his me { } block, like hub.blah.com (not the IP and can be different than hostname).</p>
	1934	<p><b>username</b><br>
	1935	You can specify this if you use ident for authentication, normally you will set this to "*".
	1936	</p>
	1937	<p><b>hostname</b><br>
	1938	The remote host or IP of the remote server. This is used for both connecting AND for
	1939	authentication/verification on the incoming side. Some examples:<br>
	1940	<table border="0">
	1941	<tr><td><i>1.2.3.4</i></td><td> normal IP</td></tr>
	1942	<tr><td><i>hub.blah.com</i></td><td> host: only for outgoing, cannot accept _incoming_ connections unless
	1943	link::options::nohostcheck is present</td></tr>
	1944	<tr><td><i>*</i></td><td> cannot connect TO but will allow a server connection (with correct password) from everywhere</td></tr>
	1945	<tr><td><i>::ffff:1.2.3.4</i></td><td> for linking ipv6 to ipv4.</td></tr>
	1946	</table>
	1947	</p>
	1948	<p><b>bind-ip</b> (optional)<br>
	1949	Can be used to bind to a specific IP (ex: 192.168.0.1) from where we should
	1950	connect from, almost never used.
	1951	</p>
	1952	<p><b>port</b><br>
	1953	Port to connect to (at which the remote server is listening).
	1954	</p>
	1955	<p><b>password-connect</b><br>
	1956	The password used for connecting to the remote server, must be plain-text.
	1957	</p>
	1958	<p><b>password-receive</b><br>
	1959	The password used for validating incoming links, can be encrypted (valid methods
	1960	are crypt, md5, sha1, ripemd-160). You can leave the auth-type parameter out to
	1961	just use plain-text. Often this password is the same as your password-connect.
	1962	</p>
	1963	<p><b>hub vs leaf</b><br>
	1964	A hub has multiple servers linked to it, a leaf has only one link... to you.
	1965	A server is a leaf unless it has a hub directive. It is also a leaf if the leaf directive is *, or leafdepth is 1.
	1966	</p>
	1967	<p><b>hub</b> (optional)<br>
	1968	The value is a mask of what servers this hub may connect (ex: *.my.net).
	1969	</p>
	1970	<p><b>leaf</b> (optional)<br>
	1971	The value is a mask of what servers this hub may <b>not</b> connect. Saying * here would be the same as not having a hub directive.
	1972	</p>
	1973	<p><b>leafdepth</b> (optional)<br>
	1974	The value specifies the depth (number of hops) this server may have beneath it. For example, 1 means the server can't have any links under it (a leaf), 2 means it can link servers but those servers can't link anything under them (that is, this hub can only link leaves). A value of 0 means no limit, and is the default.
	1975	</p>
	1976	<p><b>class</b><br>
	1977	The class this server is put into, often a separate server class is used for this.
	1978	</p>
	1979	<p><b>compression-level</b> (optional)<br>
	1980	Specifies the compression level (1-9) for this link. Only used if link::options::zip is set.
	1981	</p>
	1982	<p><b>ciphers</b> (optional)<br>
	1983	Specifies the SSL ciphers to use for this link. To obtain a list of available ciphers, use
	1984	the `openssl ciphers` command. Ciphers should be specified as a : separated list.
	1985	</p>
	1986	<p><b>options block</b><br>
	1987	One or more options used for connecting to the server. Sometimes not needed.<br>
	1988	<table border="0">
	1989	<tr><td><b>ssl</b></td><td> if you are connecting to a SSL port.</td></tr>
	1990	<tr><td><b>autoconnect</b></td><td> server will try to autoconnect, time specified in your class::connfreq
	1991	(it's best to enable this only from one side, like leaf->hub)</td></tr>
	1992	<tr><td><b>zip</b></td><td> if you want compressed links, needs to be compiled in + set at both ends</td></tr>
	1993	<tr><td><b>nodnscache</b></td><td> don't cache IP for outgoing server connection, use this if it's an often
	1994	changing host (like dyndns.org)</td></tr>
	1995	<tr><td><b>nohostcheck</b></td><td> don't validate the remote host (link::hostname), use this if it's an often
	1996	changing host (like dyndns.org)</td></tr>
	1997	<tr><td><b>quarantine</b></td><td> opers on this server cannot get GLOBAL oper privileges
	1998	(they will get killed), used for test links and such</td></tr>
	1999	</table>
	2000	</p>
	2001	<p>Example:</p>
	2002	<pre>
	2003	link hub.mynet.com {
	2004	username *;
	2005	hostname 1.2.3.4;
	2006	bind-ip *;
	2007	port 7029;
	2008	hub *;
	2009	password-connect "LiNk";
	2010	password-receive "LiNk";
	2011	class servers;
	2012	options {
	2013	autoconnect;
	2014	ssl;
	2015	zip;
	2016	};
	2017	};</pre></p>
	2018	<p> </p></div>
	2019	<p><font class="block_section">4.32 - </font><font class="block_name">Alias Block</font>
	2020	<font class="block_optional">OPTIONAL</font><a name="aliasblock"></a>
	2021	</p><div class="desc">
	2022	<p>Syntax [standard alias]:<br>
	2023	<pre>
	2024	alias <name> {
	2025	target <nick-to-forward-to>;
	2026	type <type-of-alias>;
	2027	spamfilter <yes\|no>;
	2028	};</pre></p>
	2029	<p>(Note: also see <a href="#includedirective">here</a> about the standard alias files UnrealIRCd has)</p>
	2030	<p>The alias block [standard alias] allows you to forward a command to a user,
	2031	for example /chanserv sends a message to the user chanserv. The alias:: specifies
	2032	the name of the command that will be the alias (eg: chanserv), alias::target is
	2033	the nickname or channel it will forward to, if the alias:: is the same as the target, it will
	2034	forward to, alias::target can be left out. The alias::type specifies the type
	2035	of alias, valid types are services (the user is on the services server), stats
	2036	(the user is on the stats server), normal (the user is a normal user on
	2037	any server), and channel (the target is a channel name). If alias::spamfilter (optional)
	2038	is set to 'yes', then the spamfilters will be checked (default is 'no').<br>
	2039	The alias block also has another purpose which is explained below.</p>
	2040	<p>Syntax [command alias]:<br>
	2041	<pre>
	2042	alias <name> {
	2043	/* For aliases to be sent to users/channels */
	2044	format <regex-expression> {
	2045	target <nick-to-forward-to>;
	2046	type <type-of-alias>;
	2047	parameters <parameter-string>;
	2048	};
	2049	/* For 'real aliases' */
	2050	format <regex-expression> {
	2051	command <command>;
	2052	type real;
	2053	parameters <parameter-string>;
	2054	};
	2055	/* Etc... You can have as many format blocks as you wish.. */
	2056	format <regex-expression> {
	2057	...
	2058	};
	2059	type command;
	2060	spamfilter <yes\|no>;
	2061	};</pre></p>
	2062	<p>When the alias block is used in this format, it allows you a much broader range
	2063	of usage. For example you can create aliases such as /identify. The alias::
	2064	is the same as above, the name of the alias command. The <b>alias::format</b> specifies
	2065	a regular expression that compares against the text sent to the alias command,
	2066	when matched the sub-entries of that alias::format will be used, you may have
	2067	multiple alias::format's to make the command do different things depending on
	2068	the text sent to it. The <b>alias::format::target</b> is the target to forward this
	2069	alias to, however in case of a "real alias" <b>alias::format::command</b> is used instead.
	2070	The <b>alias::format::type</b> specifies the type of the alias that the
	2071	message should be forwarded to, besides the types mentioned previously in
	2072	"Syntax [standard alias]", we also allow the type "real" here, for "real
	2073	aliases". The <b>alias::format::parameters</b> is what will
	2074	be sent as the parameters to this alias. To specify one of the parameters given
	2075	to the command alias specify % followed by a number, for example, %1 is the
	2076	first parameter. To specify all parameters from a given parameter to the end
	2077	do % followed by the number and a -, for example %2- returns all parameters
	2078	from the second till the last. Additionally, you may specify %n which will be replaced
	2079	by the nickname of the user who executed the command.<br><br>
	2080	For examples of using the alias block in the command format, consult doc/example.conf.</p>
	2081	<p></p></div>
	2082	<p><font class="block_section">4.33 - </font><font class="block_name">Help Block</font>
	2083	<font class="block_optional">OPTIONAL</font><a name="helpblock"></a>
	2084	</p><div class="desc">
	2085	<p>Syntax:<br>
	2086	<pre>
	2087	help <name> {
	2088	<text-line>;
	2089	<text-line>;
	2090	...
	2091	};</pre></p>
	2092	<p>(Note: normally you just include help.conf)</p>
	2093	<p>The help block allows you to create entries for use in /helpop. The help::
	2094	is the value that must be passed to /helpop as a parameter, if the help:: is
	2095	left out, then it will be used when no parameter is passed to /helpop. The entries
	2096	for the help block are the text that will be displayed to the user when requesting
	2097	the /helpop.</p>
	2098	<p></p></div>
	2099
	2100	<p><font class="block_section">4.34 - </font><font class="block_name">Official Channels Block</font>
	2101	<font class="block_optional">OPTIONAL</font><a name="officialchannels"></a>
	2102	</p><div class="desc">
	2103	<p>Syntax:<br>
	2104	<pre>
	2105	official-channels {
	2106	"#channel" { topic "The default topic"; };
	2107	};</pre></p>
	2108	<p>Official channels are shown in /list even if no users are in the channel.
	2109	The <b>topic</b> is optional and is only shown in /list if it has 0 users.
	2110	</p>
	2111
	2112	<p>Example:<br>
	2113	<pre>
	2114	official-channels {
	2115	"#Help" { topic "The official help channel, if nobody is present type /helpop helpme"; };
	2116	"#Home";
	2117	"#Main" { topic "The main channel"; };
	2118	};</pre></p>
	2119	</div>
	2120
	2121	<p><font class="block_section">4.35 - </font><font class="block_name">Spamfilter Block</font>
	2122	<font class="block_optional">OPTIONAL</font><a name="spamfilter"></a>
	2123	</p><div class="desc">
	2124	<p>
	2125	The spamfilter block allows you to add local spamfilters (not network-wide).<br>
	2126	See <a href="#feature_spamfilter">Features - Spamfilter</a> for more information about spamfilters.<br>
	2127	</p>
	2128	<p>Syntax:<br>
	2129	<pre>
	2130	spamfilter {
	2131	regex <word>;
	2132	target { <target(s)> };
	2133	action <action>;
	2134	reason <reason>;
	2135	ban-time <time>;
	2136	};</pre></p>
	2137	<p><b>regex</b> is the regex to be matched.<br>
	2138	<b>target</b> specifies the targets, see <a href="#feature_spamfilter">here</a> for a list of possible types (eg: 'channel').<br>
	2139	<b>action</b> specifies the action to be taken, see <a href="#feature_spamfilter">here</a> for a list of possible actions (eg: 'gline').<br>
	2140	<b>reason</b> optional: specifies the ban or block reason, else the default is used.<br>
	2141	<b>ban-time</b> optional: specifies the duration of a *line ban or shun, else the default is used (1 day).<br>
	2142	</p>
	2143
	2144	<p>Examples:<br>
	2145	<pre>
	2146	spamfilter {
	2147	regex "Come watch me on my webcam";
	2148	target { private; channel; };
	2149	action gline;
	2150	reason "You are infected, please go to www.antivirus.xx/blah/virus=GrrTrojan";
	2151	ban-time 6h;
	2152	};
	2153
	2154	spamfilter {
	2155	regex "come to irc\..+\..+";
	2156	target { private; channel; };
	2157	action gline;
	2158	action gline;
	2159	reason "No spamming allowed";
	2160	};
	2161	</pre></p>
	2162	</div>
	2163
	2164	<p><font class="block_section">4.36 - </font><font class="block_name">Cgiirc Block</font>
	2165	<font class="block_optional">OPTIONAL</font><a name="cgiirc"></a>
	2166	</p><div class="desc">
	2167	<p>
	2168	The cgiirc block allows you to configure host spoofing for CGI:IRC gateways you trust
	2169	(<a href="#feature_cgiirc">more info</a>).</p>
	2170
	2171	<p>Syntax:<br>
	2172	<pre>
	2173	cgiirc {
	2174	type <webirc\|old>;
	2175	username <mask>; /* optional */
	2176	hostname <mask>;
	2177	password <password>; /* only for type webirc */
	2178	};</pre></p>
	2179	<p><b>type</b> is either 'webirc' or 'old'.<br>
	2180	<b>username</b> is matched against the ident (if present). If not specified, "*" is assumed.<br>
	2181	<b>hostname</b> is the hostmask to match against.<br>
	2182	<b>password</b> is the webirc password, only used for type 'webirc'.<br>
	2183	</p>
	2184
	2185	<p><b>How to configure with method 'webirc' (recommended method)</b><br>
	2186	In your CGI:IRC configuration file (cgiirc.conf) you set webirc_password to a good password.<br>
	2187	Then, in your unrealircd.conf you add a cgiirc block to allow this host and password and you set
	2188	cgiirc::type to "webirc".<br>
	2189	<br>
	2190	Example:<br>
	2191	In your CGI:IRC configuration file (cgiirc.conf) you add:
	2192	<pre>webirc_password = LpT4xqPI5</pre>
	2193	Then, in your unrealircd.conf you add a cgiirc block:
	2194	<pre>cgiirc {
	2195	type webirc;
	2196	hostname "1.2.3.4";
	2197	password "LpT4xqPI5";
	2198	};</pre></p>
	2199
	2200	<p><b>How to configure with method 'old'</b><br>
	2201	NOTE: This is not the recommended method since it has two disadvantages:
	2202	this method will send the IP/host to spoof as a server password, meaning you cannot
	2203	specify a server password as a CGI:IRC user. Additionally, access control is only
	2204	IP-based and does not require an extra password like the 'webirc' method. In short,
	2205	you probably should not be using this method unless you have a good reason to do so.<br>
	2206	<br>
	2207	In your CGI:IRC configuration file (cgiirc.conf) you set realhost_as_password to 1.<br>
	2208	Then, in your unrealircd.conf you add a cgiirc block to allow this host.<br>
	2209	<br>
	2210	Example:<br>
	2211	In your CGI:IRC configuration file (cgiirc.conf) you add:
	2212	<pre>realhost_as_password = 1</pre>
	2213	Then, in your unrealircd.conf you add a cgiirc block:
	2214	<pre>cgiirc {
	2215	type old;
	2216	hostname "1.2.3.4";
	2217	};</pre></p>
	2218	</div>
	2219
	2220	<p><font class="block_section">4.37 - </font><font class="block_name">Set Block</font>
	2221	<font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as unrealircd.conf/networks file)</font><a name="setblock"></a>
	2222	</p><div class="desc">
	2223	<p>The set file is what use to be our networks/unrealircd.conf and our networks
	2224	file. On single server networks, rather than having 3 files you can just put all
	2225	the set statements in the unrealircd.conf itself, on multi-server networks, I
	2226	recommend using a seperate networks file.</p>
	2227	<p>Now, if your server is on a network, chances are you will all basically use
	2228	the same Set settings. Therefore it makes more sense to have a network file,
	2229	which is loaded with an <a href="#includedirective">include</a> directive.
	2230	Below you will find all of the set directives available.</p>
	2231	<p>In this doc we refer to settings / directives in the <block-name>::<block-directive>
	2232	format. This format is NOT the format that it can be entered into the configuration
	2233	file. IT MUST be converted to the format listed below. It is presented in the
	2234	format it is to make discussing it simpler.</p>
	2235	<p>Syntax:<br>
	2236	<pre>
	2237	set {
	2238	<entry> <value>;
	2239	<entry> <value>;
	2240	...
	2241	};</pre></p>
	2242	<p>The set block sets options for individual server features. Each entry does
	2243	something different and therefore each will be described below. Some directives
	2244	have sub blocks which will also be described. There are many set statements
	2245	to cover, all of the directives listed below can be included under ONE set statement.
	2246	If a directive has options, they are included within the single set statement
	2247	as well.<br>
	2248	Example:<br>
	2249	<pre>
	2250	set {
	2251	kline-address my@emailaddress.com;
	2252	auto-join #welcome;
	2253	options {
	2254	hide-ulines;
	2255	};
	2256	hosts {
	2257	local LocalOp.MyNet.com;
	2258	global globalop.mynet.com;
	2259	};
	2260	};</pre></p>
	2261	<p>Now if you wanted to make the set statements separate, say you wanted to set
	2262	your options in a single line.<br>
	2263	Example:<br>
	2264	set { options { hide-ulines; no-stealth; }; };<br>
	2265	</p>
	2266	<p><font class="set">set::kline-address <email-address>;</font><br>
	2267	The email address that K:line questions should be sent to. This value must be
	2268	specified.</p>
	2269	<p><font class="set">set::gline-address <email-address>;</font><br>
	2270	The email address that G:line questions should be sent to.</p>
	2271	<p><font class="set">set::modes-on-connect <+modes>;</font><br>
	2272	The modes that will be set on a user at connection.</p>
	2273	<p><font class="set">set::snomask-on-connect <+modes></font><br>
	2274	The snomask that will be set on a user at connection.</p>
	2275	<p><font class="set">set::modes-on-oper <+modes>;</font><br>
	2276	The modes that will be set on a user when they /oper.</p>
	2277	<p><font class="set">set::snomask-on-oper <+modes>;</font><br>
	2278	The snomask that will be set on a user when they /oper.</p>
	2279	<p><font class="set">set::modes-on-join <+modes>;</font><br>
	2280	The modes that will be set on a channel when it is first created. Not all modes can be set using this command. +qaohvbeOAzlLk can NOT be set using this command.</p>
	2281	<p><font class="set">set::level-on-join <none\|voice\|halfop\|op\|protect\|owner>;</font><br>
	2282	The mode that a user will get when he's the first to join a channel. The
	2283	default is 'op' (channel operator).</p>
	2284	<p><font class="set">set::restrict-usermodes <modes></font><br>
	2285	Restrict users to set/unset the modes listed here (don't use + or -).<br>
	2286	For example you can set +G in modes-on-connect and G in restrict-usermodes,
	2287	that way you can force all users to be +G and unable to do -G.</p>
	2288	<p><font class="set">set::restrict-channelmodes <modes></font><br>
	2289	Restrict users to set/unset the channelmodes listed here (don't use + or -).<br>
	2290	For example you can set +G in modes-on-join and G in restrict-channelmodes,
	2291	that way you can force all (new) channels to be +G and unable to do -G.<br>
	2292	NOTE: it may still be possible to use these channelmodes through services
	2293	by using MLOCK. Unfortunately we can't do much about that, you would have
	2294	to ask the services coders to implement a restrict-channelmodes feature too.</p>
	2295	<p><font class="set">set::restrict-extendedbans <types\|*></font><br>
	2296	Don't allow users to use any extended bans ("*") or disallow only certain ones (eg: "qc").</p>
	2297	<p><font class="set">set::auto-join <channels>;</font><br>
	2298	The channel(s) a user will be forced to join at connection. To specify more
	2299	than one channel use a comma separated list.<br>
	2300	[Note: don't forget to add quotes, like: auto-join "#chan";]</p>
	2301	<p><font class="set">set::oper-auto-join <channels>;</font><br>
	2302	The channel(s) a user will be forced to join when they /oper. To specify more
	2303	than one channel use a comma separated list.<br>
	2304	[Note: don't forget to add quotes, like: oper-auto-join "#chan";]</p>
	2305	<p><font class="set">set::anti-spam-quit-message-time <timevalue>;</font><br>
	2306	A time value specifying the length of time a user must be connected for before
	2307	a /quit message will be displayed. Used to prevent spam. A time value is a numeric
	2308	string with d meaning days, h meaning hours, m meaning minutes, and s meaning
	2309	seconds, for example 1d2h3m means 1 day, 2 hours, 3 minutes.</p>
	2310	<p><font class="set">set::prefix-quit <text-to-prefix-quit>;</font><br>
	2311	Sets the text that will be used to prefix a quit message. If this value is set
	2312	to 0 then the standard "Quit:" is used.</p>
	2313	<p><font class="set">set::static-quit <quit message>;</font><br>
	2314	Sets a static quit message that will be sent whenever a client logs off the
	2315	network. This eliminates the need for anti-spam-quit-message-time, as well as
	2316	the set::prefix-quit. It will NOT replace ERRORS with the static-quit message.</p>
	2317	<p><font class="set">set::static-part <no\|yes\|part message>;</font><br>
	2318	A value of 'yes' strips all part comments, a value of 'no' makes part just work
	2319	as usual, anything else will be used as a part comment (eg: static-part "Bye!")
	2320	but this can be quite annoying, so use with care.</p>
	2321	<p><font class="set">set::who-limit <limit>;</font><br>
	2322	Sets the limit for the maximum number of matches that will be returned for a /who.
	2323	If this option is left out, no limit is enforced.</p>
	2324	<p><font class="set">set::silence-limit <limit>;</font><br>
	2325	Sets the limit on the maximum SILENCE list entries. If this directive is not specified,
	2326	a limit of 15 is set.</p>
	2327	<p><font class="set">set::maxbans <limit>;</font><br>
	2328	Sets the limit on the maximum amount of bans (+b) allowed per channel. The default is 60.
	2329	If you change this, be sure to also take a look at maxbanlength (see next)!</p>
	2330	<p><font class="set">set::maxbanlength <limit>;</font><br>
	2331	Similar to above, but sets the maximum amount of characters for all bans added up
	2332	together, so basically this puts up a limit on the (semi-)maximum amount of memory
	2333	all channel bans on a channel can take. The default is 2048 (bytes). With the default
	2334	set::maxbans of 60 this allows 2048:60=34 characters per ban on average.</p>
	2335	<p><font class="set">set::oper-only-stats <stats-list>;</font><br>
	2336	Specifies a list of stats flags with no separators that defines stats flags
	2337	only opers can use. Leave this value out to allow users to use all flags, or
	2338	specify * for users to be able to use no flags. Only short stats flags may be specified
	2339	here.</p>
	2340	<p><font class="set">set::oper-only-stats {<stats-flag>; <stats-flag>;};</font><br>
	2341	Specifies a list of stats flags that can only be used by opers. This only works with long
	2342	stats flags.</p>
	2343	<p><font class="set">set::maxchannelsperuser <amount-of-channels>;</font><br>
	2344	Specifies the number of channels a single user may be in at any one time.</p>
	2345	<p><font class="set">set::maxdccallow <amount-of-entries>;</font><br>
	2346	Specifies the maximum number of entries a user can have on his/her DCCALLOW list.</p>
	2347	<p><font class="set">set::channel-command-prefix <command-prefixes>;</font><br>
	2348	Specifies the prefix characters for services "in channel commands". Messages starting with
	2349	any of the specified characters will still be sent even if the client is +d. The default
	2350	value is "`!.".</p>
	2351	<p><font class="set">set::allowed-nickchars { <list> };</font><br>
	2352	Character sets / languages to allow in nicks, see <a href="#feature_nickchars">Nick Character Sets</a>.</p>
	2353	<p><font class="set">set::allow-userhost-change [never\|always\|not-on-channels\|force-rejoin]</font><br>
	2354	Specifies what happens when the user@host changes (+x/-x/chghost/chgident/setident/vhost/etc).<br>
	2355	<i>never</i> disables all the commands, <i>always</i> does always allow it even when in channels
	2356	(may cause client desyncs) [default], <i>not-on-channels</i> means it's only allowed when the
	2357	user is not on any channel, <i>force-rejoin</i> will force a rejoin in all channels and re-op/voice/etc if needed.</p>
	2358	<p><font class="set">set::options::hide-ulines;</font><br>
	2359	If this is present, Ulined server will be hidden in a /links requested by non-opers.</p>
	2360	<p><font class="set">set::options::flat-map;</font><br>
	2361	If this is present, all servers will appear as directly linked in /map and /links,
	2362	thus you can no longer see which server is linked to which. This is a little help against
	2363	(D)DoS attacks because evil people now no longer can easily see the 'weak points'.</p>
	2364	<p><font class="set">set::options::show-opermotd;</font><br>
	2365	If present the opermotd will be shown to users once they successfully /oper.</p>
	2366	<p><font class="set">set::options::identd-check;</font><br>
	2367	If present the presence of an identd server will be checked and the returned
	2368	value will be used for the username. If no ident request is returned or the
	2369	identd server doesn't exist, the user's specified username will be prefixed
	2370	with a ~. If this value is omitted no such check is made.</p>
	2371	<p><font class="set">set::options::show-connect-info;</font><br>
	2372	If present notices showing "ident request", "hostname lookup",
	2373	etc. will be displayed when a user connects.</p>
	2374	<p><font class="set">set::options::dont-resolve;</font><br>
	2375	If present hosts of incoming users are not resolved, can be useful if many of your
	2376	users don't have a host to speed up connecting.<br>
	2377	Note that since no resolving is done you also can't have host based allow blocks.</p>
	2378	<p><font class="set">set::options::mkpasswd-for-everyone;</font><br>
	2379	Makes it so the /mkpasswd can be used by anyone instead of oper-only, usage of the command
	2380	by non-opers is sent to the EYES snomask.</p>
	2381	<p><font class="set">set::options::allow-part-if-shunned;</font><br>
	2382	Allow shunned user to use /part.</p>
	2383	<p><font class="set">set::options::fail-oper-warn;</font><br>
	2384	If present, a user will be notified that his/her failed /oper attempt has been logged.</p>
	2385	<p><font class="set">set::dns::timeout <timevalue>;</font><br>
	2386	A time value specifying the length of time a DNS server has to respond before
	2387	a timeout. A time value is a numeric string with d meaning days, h meaning hours,
	2388	m meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2
	2389	hours, 3 minutes. (NOT IMPLEMENTED)</p>
	2390	<p><font class="set">set::dns::retries <number-of-retries>;</font><br>
	2391	A numeric value specifying the number of times the DNS lookup will be retried
	2392	if failure occurs. (NOT IMPLEMENTED)</p>
	2393	<p><font class="set">set::dns::nameserver <name-of-dns-server>;</font><br>
	2394	Specifies the hostname of the server that will be used for DNS lookups. (NOT IMPLEMENTED)</p>
	2395	<p><font class="set">set::dns::bind-ip <ip>;</font><br>
	2396	Specifies the IP to bind to for the resolver, rarely ever needed.</p>
	2397	<p><font class="set">set::network-name <name-of-network>;</font><br>
	2398	Specifies the name of the network on which this server is run. This value should
	2399	be exactly the same on all servers on a network.</p>
	2400	<p><font class="set">set::default-server <server-name>;</font><br>
	2401	Defines the name of the default server to tell users to connect to if this server
	2402	is full.</p>
	2403	<p><font class="set">set::services-server <server-name>;</font><br>
	2404	Specifies the name of the server that the services bots are connected to. Required,
	2405	set it to something like services.yournet.com if you don't have services.</p>
	2406	<p><font class="set">set::stats-server <server-name>;</font><br>
	2407	Sets the name of the server on which the stats bot is located. If stats are
	2408	not run this value may be left out.</p>
	2409	<p><font class="set">set::help-channel <network-help-channel>;</font><br>
	2410	Sets the name of the help channel for this network.</p>
	2411	<p><font class="set">set::cloak-keys { "key1"; "key2"; "key3"; };</font><br>
	2412	Sets the keys to be used to generate a +x host. This value must be the same
	2413	on all servers or the servers will not link. Each of the 3 set::cloak-keys::
	2414	must be a string of 5-100 characters (10-20 is fine) consisting of mixed
	2415	lowercase (a-z), uppercase (A-Z) and digits (0-9). Note that depending on which
	2416	cloaking module you have loaded, other rules may apply.</p>
	2417	<p><font class="set">set::hiddenhost-prefix <prefix-value>;</font><br>
	2418	Defines the prefix that will be used on hiddenhosts (+x). This is usually three
	2419	or four letters representing the network name.</p>
	2420	<p><font class="set">set::hosts::local <locop-host-name>;</font><br>
	2421	Defines the hostname that will be assigned to local opers when they set +x. You may
	2422	optionally specify a username@host for this value.</p>
	2423	<p><font class="set">set::hosts::global <globop-host-name>;</font><br>
	2424	Defines the hostname that will be assigned to global operators when they set
	2425	+x. You may optionally specify a username@host for this value.</p>
	2426	<p><font class="set">set::hosts::coadmin <coadmin-host-name>;</font><br>
	2427	Sets the hostname that will be assigned to co-admins when they set +x. You may
	2428	optionally specify a username@host for this value.</p>
	2429	<p><font class="set">set::hosts::admin <admin-host-name>;</font><br>
	2430	Defines the hostname that will be set for admins when they set +x. You may
	2431	optionally specify a username@host for this value.</p>
	2432	<p><font class="set">set::hosts::servicesadmin <servicesadmin-host-name>;</font><br>
	2433	Sets the hostname that will be given to services-admins when they set +x. You may
	2434	optionally specify a username@host for this value.</p>
	2435	<p><font class="set">set::hosts::netadmin <netadmin-host-name>;</font><br>
	2436	Sets the hostname that will be given to netadmins when they set +x. You may
	2437	optionally specify a username@host for this value.</p>
	2438	<p><font class="set">set::hosts::host-on-oper-up <yes/no>;</font><br>
	2439	If set to yes, the H/get_host flag will be honored and +x will be automatically
	2440	set at /oper. If set to no, the user must set +x manually to receive the oper
	2441	host.</p>
	2442	<p><font class="set">set::ssl::egd <filename>;</font><br>
	2443	Specifies that EGD (Entropy Gathering Daemon) support should be enabled. If
	2444	you run OpenSSL 0.9.7 or higher, then /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool,
	2445	and /etc/entropy will be searched by default so no filename is necessary, you
	2446	may simply specify set::ssl::egd with no value. If you are using a version of
	2447	OpenSSL prior to 0.9.7 or you want to use a EGD socket located somewhere other
	2448	than the above listed locations you may specify the filename of the UNIX Domain
	2449	Socket that an EGD is listening on.</p>
	2450	<p><font class="set">set::ssl::certificate <filename>;</font><br>
	2451	Specifies the filename where the server's SSL certificate is located.</p>
	2452	<p><font class="set">set::ssl::key <filename>;</font><br>
	2453	Specifies the filename where the server's SSL private key is located.</p>
	2454	<p><font class="set">set::ssl::trusted-ca-file <filename>;</font><br>
	2455	Specifies the filename where the certificates of the trusted CAs are located.</p>
	2456	<p><font class="set">set::ssl::server-cipher-list <cipherlist>;</font><br>
	2457	Specifies which ciphers to be allowed, by default we leave this up to OpenSSL.
	2458	See <a href="http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT">http://www.openssl.org/docs/apps/ciphers.html</a>
	2459	on how to specify the list of ciphers.</p>
	2460	<p><font class="set">set::ssl::renegotiate-bytes <value>;</font><br>
	2461	Specifies after how many bytes an SSL session should be renegotiated (eg: 20m for 20 megabytes).</p>
	2462	<p><font class="set">set::ssl::renegotiate-timeout <timevalue>;</font><br>
	2463	Specifies after how much time an SSL session should be renegotiated (eg: 1h for 1 hour).</p>
	2464	<p><font class="set">set::ssl::options::fail-if-no-clientcert;</font><br>
	2465	Forces clients that do not have a certificate to be denied.</p>
	2466	<p><font class="set">set::ssl::options::no-self-signed;</font><br>
	2467	Disallows connections from people with self-signed certificates.</p>
	2468	<p><font class="set">set::ssl::options::verify-certificate;</font><br>
	2469	Makes Unreal determine if the SSL certificate is valid before allowing connection.</p>
	2470	<p><font class="set">set::ssl::options::no-starttls;</font><br>
	2471	Disable STARTTLS. STARTTLS allows clients to use SSL on regular (non-SSL) ports.</p>
	2472	<p><font class="set">set::throttle::period <timevalue></font><br>
	2473	How long a user must wait before reconnecting more than set::throttle::connections
	2474	times.</p>
	2475	<p><font class="set">set::throttle::connections <amount>;</font><br>
	2476	How many times a user must connect with the same host to be throttled.</p>
	2477	<p><font class="set">set::ident::connect-timeout <amount>;</font><br>
	2478	Amount of seconds after which to give up connecting to the ident server (default: 10s).</p>
	2479	<p><font class="set">set::ident::read-timeout <amount>;</font><br>
	2480	Amount of seconds after which to give up waiting for a reply (default: 30s).</p>
	2481	<p><font class="set">set::anti-flood::unknown-flood-bantime <timevalue>;</font><br>
	2482	Specifies how long an unknown connection flooder is banned for.</p>
	2483	<p><font class="set">set::anti-flood::unknown-flood-amount <amount>;</font><br>
	2484	Specifies the amount of data (in KiloBytes) that the unknown connection must send
	2485	in order for the user to be killed.</p>
	2486	<p><font class="set">set::anti-flood::away-flood <count>:<period></font><br>
	2487	Away flood protection: limits /away to 'count' changes per 'period' seconds.
	2488	This requires NO_FLOOD_AWAY to be enabled in config.h. Example: <i>away-flood 5:60s;</i>
	2489	means max 5 changes per 60 seconds.</p>
	2490	<p><font class="set">set::anti-flood::nick-flood <count>:<period></font><br>
	2491	Nickflood protection: limits nickchanges to 'count' per 'period' seconds.
	2492	For example <i>nick-flood 4:90</i> means 4 per 90 seconds, the default is 3 per 60.</p>
	2493	<p><font class="set">set::default-bantime <time></font><br>
	2494	Default bantime when doing /kline, /gline, /zline, /shun, etc without time parameter
	2495	(like /gline *@some.nasty.isp), the default is permanent (0). Example: <i>default-bantime 90d;</i></p>
	2496	<p><font class="set">set::modef-default-unsettime <value></font><br>
	2497	For channelmode +f you can specify a default unsettime, if you specify 10 for example then
	2498	+f [5j]:15 will be transformed to [5j#i10]:15. The default is no default unsettime.</p>
	2499	<p><font class="set">set::modef-max-unsettime <value></font><br>
	2500	The maximum amount of minutes for a mode +f unsettime (in +f [5j#i<TIME>]:15), this is a
	2501	value between 0 and 255. The default is 60 (= 1 hour).</p>
	2502	<p><font class="set">set::ban-version-tkl-time <value></font><br>
	2503	If you specify an 'action' like zline/gline/etc in ban version, then you can specify here
	2504	how long the ip should be banned, the default is 86400 (1 day).</p>
	2505	<p><font class="set">set::spamfilter::ban-time <value></font><br>
	2506	Same as above but for *lines/shuns added by spamfilter</p>
	2507	<p><font class="set">set::spamfilter::ban-reason <reason></font><br>
	2508	Reason to be used for entries added by spamfilter</p>
	2509	<p><font class="set">set::spamfilter::virus-help-channel <channel></font><br>
	2510	The channel to use for the 'viruschan' action in spamfilter</p>
	2511	<p><font class="set">set::spamfilter::virus-help-channel-deny <yes\|no></font><br>
	2512	If set to yes (or '1') it replies 'invite only' to any normal users that try to join
	2513	the virus-help-channel. Only opers, people that match spamfilters and people that
	2514	are /invite'd can join.</p>
	2515	<p><font class="set">set::spamfilter::except <target(s)></font><br>
	2516	These targets are exempt from spam filtering (no action will be taken),
	2517	can be single target or comma seperated list.. Ex: except "#help,#spamreport"</p>
	2518	<p><font class="set">set::spamfilter::slowdetect-warn <value></font><br>
	2519	If a spamfilter takes longer than this amount of milliseconds to execute
	2520	(1000ms = 1 second), then a warning notice will be sent to all opers (default: 250).
	2521	See also <a href="#feature_spamfilter_slow">Slow Spamfilter Detection</a>.</p>
	2522	<p><font class="set">set::spamfilter::slowdetect-fatal <value></font><br>
	2523	If a spamfilter takes longer than this amount of milliseconds to execute
	2524	(1000ms = 1 second), then the spamfilter will be removed (default: 500).
	2525	See also <a href="#feature_spamfilter_slow">Slow Spamfilter Detection</a>.</p>
	2526	<p><font class="set">set::check-target-nick-bans <yes\|no></font><br>
	2527	Whenever the user changes his/her nick, check if the NEW nick would be
	2528	banned. If so, do not allow the nickchange. Default is yes.</p>
	2529	<p><font class="set">set::timesynch::enabled <yes\|no></font><br>
	2530	Enable or disable time synchronization on-boot. Default is yes.</p>
	2531	<p><font class="set">set::timesynch::server <IP></font><br>
	2532	Server to synchronize time with. This can be up to 4 IP's seperated by comma's.
	2533	The servers must support NTP protocol version 4. The default is to use 3 time servers (US, EU,
	2534	AU). Requests to these servers are sent in parallel, fastest reply wins.</p>
	2535	<p><font class="set">set::timesynch::timeout <time></font><br>
	2536	Maximum time to wait for a time server reply. This is a value between 1 and 5, more is not possible
	2537	because it causes too much inaccuracy. This setting is 3 by default and there's probably
	2538	no good reason to change it.</p>
	2539	<p><font class="set">set::pingpong-warning <yes\|no></font><br>
	2540	When NOSPOOF is enabled (usually on Windows), send a warning to each user to use
	2541	'/quote pong ..' if they are having problems connecting? The default is no.</p>
	2542	<p><font class="set">set::watch-away-notification <yes\|no></font><br>
	2543	Allows you to enable/disable AWAY notification in WATCH. The default is yes.</p>
	2544	<p></p> </div>
	2545	<p id="filesblock"><font class="block_section">4.38 - </font><font class="block_name">Files Block</font>
	2546	<font class="block_optional">OPTIONAL</font><div class="desc">
	2547	</p>
	2548	<p>
	2549	You don't need to use a <a href="#tldblock">TLD block</a> to specify default locations for your MOTDs and rules files. This block controls default settings for those in addition to the pidfile and irc.tune file. Anything not specified here will default to the value documented in <a href="#addtlfiles">Additional Files</a>.
	2550	</p>
	2551	<p>
	2552	Relative pathnames will be interpreted relative to unrealIRCD's root directory which is normally the directory containing <tt>unrealircd.conf</tt>. This block may be used to facilitate running more than one IRCd out of the same directory/root. In that case, you should at least specify multiple pidfiles and tunefiles—one for each server.
	2553	</p>
	2554	<p>Syntax:<br>
	2555	<pre>
	2556	files {
	2557	motd <motd file>;
	2558	shortmotd <short motd file>;
	2559	opermotd <oper motd file>;
	2560	svsmotd <services motd file>;
	2561	botmotd <bot motd file>;
	2562
	2563	rules <rules file>;
	2564
	2565	tunefile <tune file>;
	2566	pidfile <pid file>;
	2567	};
	2568	</pre></p>
	2569	<p>Example:<br />
	2570	<pre>
	2571	files {
	2572	motd /etc/motd;
	2573
	2574	pidfile /var/lib/run/unrealircd.pid;
	2575	};
	2576	</pre>
	2577	</p>
	2578	<p><b><font size="+2">5 – Additional Files<a name="addtlfiles"></a>
	2579	</font></b></p><div class="desc">
	2580	In addition to the configuration files, Unreal has a few other files, such as MOTD, OperMOTD,
	2581	BotMOTD, and Rules. Listed below are the names of these files and their uses.<br>
	2582	Note that the motd files (all types) and rules files can also be specified in a <a href="#tldblock">tld</a> or <a href="#filesblock">files</a> block,
	2583	these are just the files used by default (and for remote MOTD/RULES's).<p />
	2584	<table width="83%" border="1">
	2585	<tr>
	2586	<td>ircd.motd</td><td>Displayed when a /motd is executed and (if ircd.smotd is not present) when a user connects</td>
	2587	</tr>
	2588	<tr>
	2589	<td>ircd.smotd</td><td>Displayed on connect only (short MOTD)</td>
	2590	</tr>
	2591	<tr>
	2592	<td>ircd.rules</td><td>Displayed when a /rules is executed</td>
	2593	</tr>
	2594	<tr>
	2595	<td>oper.motd</td><td>Displayed when a /opermotd is executed or when you /oper up</td>
	2596	</tr>
	2597	<tr>
	2598	<td>bot.motd</td><td>Displayed when a /botmotd is executed</td>
	2599	</tr>
	2600	</table>
	2601	<p></p></div>
	2602	<p><b><font size="+2">6 – User & Channel Modes<a name="userchannelmodes"></a>
	2603	</font></b></p><div class="desc">
	2604	<table width="83%" border="1">
	2605	<tr>
	2606	<td><div align="center"><b>Mode</b></div></td>
	2607	<td><div align="center"><b>Description</b></div></td>
	2608	</tr>
	2609	<tr>
	2610	<td colspan="2"><div align="center"><b>Channel Modes</b></div></td>
	2611	</tr>
	2612	<tr>
	2613	<td><div align="center">A</div></td>
	2614	<td>Only Administrators may join</td>
	2615	</tr>
	2616	<tr>
	2617	<td><div align="center">a <nick></div></td>
	2618	<td>Makes the user a channel admin</td>
	2619	</tr>
	2620	<tr>
	2621	<td><div align="center">b <nick!user@host><br>
	2622	</div></td>
	2623	<td>Bans the given user from the channel</td>
	2624	</tr>
	2625	<tr>
	2626	<td><div align="center">c</div></td>
	2627	<td>No ANSI color can be sent to the channel</td>
	2628	</tr>
	2629	<tr>
	2630	<td><div align="center">C</div></td>
	2631	<td>No CTCP's allowed in the channel</td>
	2632	</tr>
	2633	<tr>
	2634	<td><div align="center">e <nick!user@host></div></td>
	2635	<td>Exception ban – If someone matches this, they can join a channel
	2636	even if they match an existing ban</td>
	2637	</tr>
	2638	<tr>
	2639	<td><div align="center">f [<number><type>]:<seconds></div></td>
	2640	<td>Channel flood protection. See <a href="#feature_antiflood">section 3.12</a>
	2641	above for an extended description.</td>
	2642	</tr>
	2643	<tr>
	2644	<td><div align="center">G</div></td>
	2645	<td>Makes channel G rated. Checks for words listed in the Badword Blocks,
	2646	and replaces them with the words specified</td>
	2647	</tr>
	2648	<tr>
	2649	<td><div align="center">h <nick></div></td>
	2650	<td>Gives half-op status to the user</td>
	2651	</tr>
	2652	<tr>
	2653	<td><div align="center">i</div></td>
	2654	<td>Invite required</td>
	2655	</tr>
	2656	<tr>
	2657	<td><div align="center">I <nick!user@host><br></div></td>
	2658	<td>Invite exceptions ("invex") - if someone matches this, they can bypass
	2659	+i requirements to enter the channel.</td>
	2660	</tr>
	2661	<tr>
	2662	<td><div align="center">j <joins:seconds></div></td>
	2663	<td>Throttles joins per-user to <i>joins</i> per <i>seconds</i> seconds</td>
	2664	</tr>
	2665	<tr>
	2666	<td><div align="center">K</div></td>
	2667	<td>/knock is not allowed</td>
	2668	</tr>
	2669	<tr>
	2670	<td><div align="center">k <key></div></td>
	2671	<td>Sets a key needed to join</td>
	2672	</tr>
	2673	<tr>
	2674	<td><div align="center">l <##></div></td>
	2675	<td>Sets max number of users</td>
	2676	</tr>
	2677	<tr>
	2678	<td><div align="center">L <Chan></div></td>
	2679	<td>If the amount set by +l has been reached, users will be sent to this channel</td>
	2680	</tr>
	2681	<tr>
	2682	<td><div align="center">M</div></td>
	2683	<td>A registered nickname (+r) is required to talk</td>
	2684	</tr>
	2685	<tr>
	2686	<td><div align="center">m</div></td>
	2687	<td>Moderated channel. Only +v/o/h users may speak</td>
	2688	</tr>
	2689	<tr>
	2690	<td><div align="center">N</div></td>
	2691	<td>No nick name changes permitted</td>
	2692	</tr>
	2693	<tr>
	2694	<td><div align="center">n</div></td>
	2695	<td>No messages from outside channels</td>
	2696	</tr>
	2697	<tr>
	2698	<td><div align="center">O</div></td>
	2699	<td>Only IRCops may join</td>
	2700	</tr>
	2701	<tr>
	2702	<td><div align="center">o <nick></div></td>
	2703	<td>Gives a user channel operator status</td>
	2704	</tr>
	2705	<tr>
	2706	<td><div align="center">p</div></td>
	2707	<td>Makes channel private</td>
	2708	</tr>
	2709	<tr>
	2710	<td><div align="center">q <nick></div></td>
	2711	<td>Sets channel owner</td>
	2712	</tr>
	2713	<tr>
	2714	<td><div align="center">Q</div></td>
	2715	<td>Only U:Lined servers can kick users</td>
	2716	</tr>
	2717	<tr>
	2718	<td><div align="center">R</div></td>
	2719	<td>Requires a registered nickname to join</td>
	2720	</tr>
	2721	<tr>
	2722	<td><div align="center">S</div></td>
	2723	<td>Strips all incoming colors</td>
	2724	</tr>
	2725	<tr>
	2726	<td><div align="center">s</div></td>
	2727	<td>Makes channel secret</td>
	2728	</tr>
	2729	<tr>
	2730	<td><div align="center">t</div></td>
	2731	<td>Only chanops can set topic</td>
	2732	</tr>
	2733	</tr>
	2734	<tr>
	2735	<td><div align="center">T</div></td>
	2736	<td>No NOTICE's allowed in the channel</td>
	2737	</tr>
	2738	<tr>
	2739	<td><div align="center">u</div></td>
	2740	<td>Auditorium – Makes /names and /who #channel only show channel ops</td>
	2741	</tr>
	2742	<tr>
	2743	<td><div align="center">V</div></td>
	2744	<td>/invite is not allowed</td>
	2745	</tr>
	2746	<tr>
	2747	<td><div align="center">v <nick></div></td>
	2748	<td>Gives a voice to users. (May speak in +m channels)</td>
	2749	</tr>
	2750	<tr>
	2751	<td><div align="center">z</div></td>
	2752	<td>Only clients on a Secure (SSL) Connection may join</td>
	2753	</tr>
	2754	</table>
	2755	<p> </p>
	2756	<table width="75%" border="1">
	2757	<tr>
	2758	<td><div align="center"><b>Mode</b></div></td>
	2759	<td><div align="center"><b>Description</b></div></td>
	2760	</tr>
	2761	<tr>
	2762	<td colspan="2"><div align="center"><b>User Modes</b></div></td>
	2763	</tr>
	2764	<tr>
	2765	<td><div align="center">A</div></td>
	2766	<td>Server Admin (Set in Oper Block)</td>
	2767	</tr>
	2768	<tr>
	2769	<td><div align="center">a</div></td>
	2770	<td>Services Admin (Set in Oper Block)</td>
	2771	</tr>
	2772	<tr>
	2773	<td><div align="center">B</div></td>
	2774	<td>Marks you as being a Bot</td>
	2775	</tr>
	2776	<tr>
	2777	<td><div align="center">C</div></td>
	2778	<td>Co-Admin (Set in Oper Block)</td>
	2779	</tr>
	2780	<tr>
	2781	<td><div align="center">d</div></td>
	2782	<td>Makes it so you can not receive channel PRIVMSGs (with the exception
	2783	of text prefixed with certain characters, see set::channel-command-prefix)</td>
	2784	</tr>
	2785	<tr>
	2786	<td><div align="center">G</div></td>
	2787	<td>Filters out all the bad words per configuration</td>
	2788	</tr>
	2789	<tr>
	2790	<td><div align="center">g</div></td>
	2791	<td>Can send & read globops and locops</td>
	2792	</tr>
	2793	<tr>
	2794	<td><div align="center">H</div></td>
	2795	<td>Hide IRCop Status (IRCop Only)</td>
	2796	</tr>
	2797	<tr>
	2798	<td><div align="center">h</div></td>
	2799	<td>Available for help (HelpOp) (Set in OperBlock)</td>
	2800	</tr>
	2801	<tr>
	2802	<td><div align="center">i</div></td>
	2803	<td>Invisible (not shown in /who)</td>
	2804	</tr>
	2805	<tr>
	2806	<td><div align="center">N</div></td>
	2807	<td>Network Administrator (Set in Oper Block)</td>
	2808	</tr>
	2809	<tr>
	2810	<td><div align="center">O</div></td>
	2811	<td>Local IRC Operator (Set in Oper Block)</td>
	2812	</tr>
	2813	<tr>
	2814	<td><div align="center">o</div></td>
	2815	<td>Global IRC Operator (Set in Oper Block)</td>
	2816	</tr>
	2817	<tr>
	2818	<td><div align="center">p</div></td>
	2819	<td>Hides the channels you are in from /whois</td>
	2820	</tr>
	2821	<tr>
	2822	<td><div align="center">q</div></td>
	2823	<td>Only U:Lines can kick you (Services Admins Only)</td>
	2824	</tr>
	2825	<tr>
	2826	<td><div align="center">R</div></td>
	2827	<td>Allows you to only receive PRIVMSGs/NOTICEs from registered (+r) users</td>
	2828	</tr>
	2829	<tr>
	2830	<td><div align="center">r</div></td>
	2831	<td>Identifies the nick as being registered</td>
	2832	</tr>
	2833	<tr>
	2834	<td><div align="center">S</div></td>
	2835	<td>Used to protect Services Daemons</td>
	2836	</tr>
	2837	<tr>
	2838	<td><div align="center">s</div></td>
	2839	<td>Can listen to server notices (see <a href="#feature_snomasks">section 3.3</a> above for more information)</td>
	2840	</tr>
	2841	<tr>
	2842	<td><div align="center">T</div></td>
	2843	<td>Prevents you from receiving CTCPs</td>
	2844	</tr>
	2845	<tr>
	2846	<td><div align="center">t</div></td>
	2847	<td>Says you are using a /vhost</td>
	2848	</tr>
	2849	<tr>
	2850	<td><div align="center">V</div></td>
	2851	<td>Marks you as a WebTV user</td>
	2852	</tr>
	2853	<tr>
	2854	<td><div align="center">v</div></td>
	2855	<td>Receives infected DCC Send Rejection notices</td>
	2856	</tr>
	2857	<tr>
	2858	<td><div align="center">W</div></td>
	2859	<td>Lets you see when people do a /whois on you (IRCops Only)</td>
	2860	</tr>
	2861	<tr>
	2862	<td><div align="center">w</div></td>
	2863	<td>Can listen to wallop messages</td>
	2864	</tr>
	2865	<tr>
	2866	<td><div align="center">x</div></td>
	2867	<td>Gives user a hidden hostname </td>
	2868	</tr>
	2869	<tr>
	2870	<td><div align="center">z</div></td>
	2871	<td>Indicates that you are an SSL client</td>
	2872	</tr>
	2873	</table>
	2874	<p></p></div>
	2875	<p><font size="+2"><b>7 – User & Oper Commands Table<a name="useropercommands" id="useropercommands"></a></b></font></p><div class="desc">
	2876	<p>NOTE: the /helpop documentation is more up to date, use <i>/helpop command</i> (or <i>/helpop ?command</i> if you are oper)
	2877	to get more information on a command.</p>
	2878
	2879	<table width="90%" border="1">
	2880	<tr>
	2881	<td width="33%"><div align="center"><b>Command</b></div></td>
	2882	<td width="57%"><div align="center"><b>Description</b></div></td>
	2883	<td width="10%"><div align="center"><b>Who</b></div></td>
	2884	</tr>
	2885	<tr>
	2886	<td>nick <newnickname></td>
	2887	<td>Changes your online nick name. Alerts others to the change of your nick<br></td>
	2888	<td>All</td>
	2889	</tr>
	2890	<tr>
	2891	<td>whois <nick></td>
	2892	<td>Displays information of user requested. Includes Full Name, Host, Channels
	2893	User is in, and Oper Status<br></td>
	2894	<td>All</td>
	2895	</tr>
	2896	<tr>
	2897	<td height="39">who <mask></td>
	2898	<td>Who allows you to search for users. Masks
	2899	include: nickname, #channel, hostmask (*.attbi.com)<br></td>
	2900	<td>All</td>
	2901	</tr>
	2902	<tr>
	2903	<td height="39">whowas <nick> <maxreplies></td>
	2904	<td>Displays information on a nick that has logged off. The <max replies>
	2905	field is optional, and limits how many records will be returned.<br></td>
	2906	<td>All</td>
	2907	</tr>
	2908	<tr>
	2909	<td height="39">ison <nick1 nick2 nick3 ...></td>
	2910	<td>Allows you to check the online status of a user, or a list of users. Simple
	2911	return, best used for scripts<br></td>
	2912	<td>All</td>
	2913	</tr>
	2914	<tr>
	2915	<td height="39">join <channel1,channel2, ...></td>
	2916	<td>Allows you to join channels. Using the /join #channel1,#channel2,#channel3
	2917	will allow you to join more than one channel at a time. The /join 0 command
	2918	makes you PART all channels.</td>
	2919	<td>All</td>
	2920	</tr>
	2921	<tr>
	2922	<td height="39">cycle <channel1, channel2, ...></td>
	2923	<td>Cycles the given channel(s). This command is equivalent
	2924	to sending a PART then a JOIN command.</td>
	2925	<td>All</td>
	2926	</tr>
	2927	<tr>
	2928	<td height="39">motd <server></td>
	2929	<td>Displays the servers motd. Adding a server name allows you to view motd’s
	2930	on other servers.<br></td>
	2931	<td>All</td>
	2932	</tr>
	2933	<tr>
	2934	<td height="39">rules <server></td>
	2935	<td>Displays the ircd.rules of a server. Adding a server name allows you to
	2936	view rules on other servers</td>
	2937	<td>All</td>
	2938	</tr>
	2939	<tr>
	2940	<td height="39">lusers <server> </td>
	2941	<td>Displays current & max user loads, both global and local. Adding a server name
	2942	allows you to view the statistics from other servers.<br></td>
	2943	<td>All</td>
	2944	</tr>
	2945	<tr>
	2946	<td height="39">map</td>
	2947	<td>Displays a network map</td>
	2948	<td>All</td>
	2949	</tr>
	2950	<tr>
	2951	<td height="39">quit <reason></td>
	2952	<td>Causes you to disconnect from the server. If you include a reason, it
	2953	will be displayed on all channels as you quit</td>
	2954	<td>All</td>
	2955	</tr>
	2956	<tr>
	2957	<td height="39">ping <user></td>
	2958	<td>Sends a PING request to a user. Used for checking connection and lag.
	2959	Servers issue pings on a timed basis to determine if users are still connected.<br></td>
	2960	<td>All</td>
	2961	</tr>
	2962	<tr>
	2963	<td height="39">version <nick></td>
	2964	<td>Sends a CTCP Version request to the user. If configured to do so, their
	2965	client will respond with the client version.<br></td>
	2966	<td>All</td>
	2967	</tr>
	2968	<tr>
	2969	<td height="39">links</td>
	2970	<td>Displays a list of all servers linked to the network</td>
	2971	<td>All</td>
	2972	</tr>
	2973	<tr>
	2974	<td height="39">Admin <server></td>
	2975	<td>Displays the admin info of a server. If a server name is included it will
	2976	display the info of that server.<br></td>
	2977	<td>All</td>
	2978	</tr>
	2979	<tr>
	2980	<td height="39">userhost <nick></td>
	2981	<td>Displays the userhost of the nick given. Generally used for scripts<br></td>
	2982	<td>All</td>
	2983	</tr>
	2984	<tr>
	2985	<td height="39">topic <channel> <topic></td>
	2986	<td>Topic <channel> will display the current topic of the given channel. Topic
	2987	<channel> <topic> will change the topic of the given channel.<br></td>
	2988	<td>All</td>
	2989	</tr>
	2990	<tr>
	2991	<td height="39">invite <nick> <channel></td>
	2992	<td>Invites the given user to the given channel. (Must be a channel Op)<br></td>
	2993	<td>ChanOp</td>
	2994	</tr>
	2995	<tr>
	2996	<td height="39">kick <channel, channel> <user, user> <reason></td>
	2997	<td>Kicks a user or users out of a channel, or channels. A reason may also
	2998	be supplied. <br></td>
	2999	<td>ChanOp</td>
	3000	</tr>
	3001	<tr>
	3002	<td height="39">away <reason></td>
	3003	<td>Marks you as being away. A reason may also be supplied.<br></td>
	3004	<td>All</td>
	3005	</tr>
	3006	<tr>
	3007	<td height="39">Watch +-<nick> +-<nick><br></td>
	3008	<td>Watch is a new notify-type system in UnrealIRCd which is both faster and
	3009	uses less network resources than any old-style notify system. The server
	3010	will send you a message when any nickname in your watch list logs on or
	3011	off. The watch list DOES NOT REMAIN BETWEEN SESSIONS - you (or your script
	3012	or client) must add the nicknames to your watch list every time you connect
	3013	to an IRC server.<br></td>
	3014	<td>All</td>
	3015	</tr>
	3016	<tr>
	3017	<td height="39">helpop ?<topic> or !<topic><br></td>
	3018	<td>HelpOp is a new system of getting IRC Server help. You type either /HELPOP
	3019	? <help system topic> or /HELPOP ! <question> The "?"
	3020	in /HELPOP means query the help system and if you get no response you can
	3021	choose '!' to send it to the Help Operators online. Using neither ? nor !
	3022	will mean the command will be first queried within the help system and if
	3023	no match if found , it will be forwarded to the help operators</td>
	3024	<td>All</td>
	3025	</tr>
	3026	<tr>
	3027	<td height="39">list <search string></td>
	3028	<td>
	3029	If you don't include a search string, the default is to send you the entire
	3030	unfiltered list of channels. Below are the options you can use, and what
	3031	channels LIST will return when you use them.<br> >number List channels
	3032	with more than <number> people.<br> <number List channels with
	3033	less than <number> people.<br>
	3034	C>number List channels created between now and <number> minutes
	3035	ago.<br>
	3036	C<number List channels created earlier than <number> minutes ago.<br>
	3037	T>number List channels whose topics are older than <number> minutes
	3038	(Ie., they have not changed in the last <number> minutes.<br>
	3039	T<number List channels whose topics are newer than <number> minutes.<br>
	3040	mask List channels that match mask<br>
	3041	!mask List channels that do not match mask<br> </td>
	3042	<td>All</td>
	3043	</tr>
	3044	<tr>
	3045	<td height="39">Knock <channel> <message><br></td>
	3046	<td>Allows you to ‘knock’ on an invite only channel and ask for
	3047	access. Will not work if channel has one of the following modes set: +K
	3048	+V. Will also not work if you are banned<br></td>
	3049	<td>All</td>
	3050	</tr>
	3051	<tr>
	3052	<td height="39">setname</td>
	3053	<td>Allows users to change their ‘Real Name’ without reconnecting<br></td>
	3054	<td>All</td>
	3055	</tr>
	3056	<tr>
	3057	<td height="39">vhost <login> <password></td>
	3058	<td>Hides your host name by using a vhost provided by the server. <br></td>
	3059	<td>All</td>
	3060	</tr>
	3061	<tr>
	3062	<td height="39">mode <chan/nick> <mode><br></td>
	3063	<td>Lets you set channel and user modes. See
	3064	<a href="#userchannelmodes">User & Channel Modes</a> for a list.<br></td>
	3065	<td>All</td>
	3066	</tr>
	3067	<tr>
	3068	<td height="39">credits</td>
	3069	<td>Lists credits for everyone that has helped create UnrealIRCd<br></td>
	3070	<td>All</td>
	3071	</tr>
	3072	<tr>
	3073	<td height="39">license</td>
	3074	<td>Displays the GNU License</td>
	3075	<td>All</td>
	3076	</tr>
	3077	<tr>
	3078	<td height="39">time <server></td>
	3079	<td>Displays the servers date and time. Including a server name allows you
	3080	to check other servers.<br></td>
	3081	<td>All</td>
	3082	</tr>
	3083	<tr>
	3084	<td height="39">botmotd <server><br></td>
	3085	<td>Displays the servers bot message of the day. Including a server name allows
	3086	you to check other servers</td>
	3087	<td>All</td>
	3088	</tr>
	3089	<tr>
	3090	<td height="39">identify <password></td>
	3091	<td>Sends your password to the services system to identify to your nick.<br></td>
	3092	<td>All</td>
	3093	</tr>
	3094	<tr>
	3095	<td height="39">identify <channel> <password></td>
	3096	<td>Sends your password to the services system to identify as the founder
	3097	of a channel.<br></td>
	3098	<td>All</td>
	3099	</tr>
	3100	<tr>
	3101	<td height="39">dns <option></td>
	3102	<td>Returns information about the IRC server's DNS cache.
	3103	Note, since most clients have a built-in DNS command,
	3104	you will most likely need to use /raw DNS to use this.
	3105	Opers may specify an l as the first parameter to the command
	3106	to receive a list of entries in the DNS cache.</td>
	3107	<td>All</td>
	3108	</tr>
	3109	<tr>
	3110	<td height="39">userip <nick><br></td>
	3111	<td>Returns the IP address of the user in question.</td>
	3112	<td>All</td>
	3113	</tr>
	3114	<tr>
	3115	<td height="39">oper <userid> <password><br></td>
	3116	<td>Command to give a user operator status if they match an Oper Block<br></td>
	3117	<td>IRCop</td>
	3118	</tr>
	3119	<tr>
	3120	<td height="39">wallops <message></td>
	3121	<td>Sends a message to all users with umode +w</td>
	3122	<td>IRCop</td>
	3123	</tr>
	3124	<tr>
	3125	<td height="39">globops <message></td>
	3126	<td>Sends a message to all global IRCops</td>
	3127	<td>IRCop</td>
	3128	</tr>
	3129	<tr>
	3130	<td height="39">chatops <message></td>
	3131	<td>Sends a message to all IRCops (local and global)</td>
	3132	<td>IRCop</td>
	3133	</tr>
	3134	<tr>
	3135	<td height="39">locops <message></td>
	3136	<td>Sends a message to all local IRCops</td>
	3137	<td>IRCop</td>
	3138	</tr>
	3139	<tr>
	3140	<td height="39">adchat <message></td>
	3141	<td>Sends a message to all Admins</td>
	3142	<td>IRCop</td>
	3143	</tr>
	3144	<tr>
	3145	<td height="39">nachat <message></td>
	3146	<td>Sends a message to all Net Admins</td>
	3147	<td>IRCop</td>
	3148	</tr>
	3149	<tr>
	3150	<td height="39">kill <nick> <reason></td>
	3151	<td>Kills a user from the network</td>
	3152	<td>IRCop</td>
	3153	</tr>
	3154	<tr>
	3155	<td height="39">kline [+\|-]<user@host \| nick> [<time to ban> <reason>]</td>
	3156	<td>Bans the hostmask from the server it is issued on. A kline is not a global ban.<br>
	3157	<b>time to ban</b> is either: a) a value in seconds, b) a time value, like '1d' is 1 day or c) '0' for permanent.
	3158	Time and reason are optional, if unspecified set::default-bantime (default: 0/permanent) and 'no reason' are used.<br>
	3159	To remove a kline use /kline -user@host</td>
	3160	<td>IRCop</td>
	3161	</tr>
	3162	<tr>
	3163	<td height="39">zline [+\|-]<*@ip> [<time to ban> <reason>]</td>
	3164	<td>Bans an IP Address from the local server it is issued on (not global). See kline for more syntax info.
	3165	Use /zline -*@ip to remove.<br></td>
	3166	<td>IRCop</td>
	3167	</tr>
	3168	<tr>
	3169	<td height="39">gline [+\|-]<user@host \| nick> [<time to ban> <reason>]<br></td>
	3170	<td>Adds a global ban to anyone that matches. See kline for more syntax info.
	3171	Use /gline -user@host to remove.<br></td>
	3172	<td>IRCop</td>
	3173	</tr>
	3174	<tr>
	3175	<td height="39">shun [+\|-]<user@host \| nick> [<time to shun> <reason>]<br></td>
	3176	<td>Prevents a user from executing ANY commands and prevents them from speaking.
	3177	Shuns are global (like glines). See kline for more syntax info.
	3178	Use /shun -user@host to remove a shun.
	3179	<br></td>
	3180	<td>IRCop</td>
	3181	</tr>
	3182	<tr>
	3183	<td height="39">gzline [+\|-]<ip> <time to ban> :<reason><br></td>
	3184	<td>Adds a global zline. See kline for more syntax info.
	3185	Use /gzline -*@ip to remove a gzline.<br></td>
	3186	<td>IRCop</td>
	3187	</tr>
	3188	<tr>
	3189	<td height="39">rehash <server> –<flags></td>
	3190	<td>Rehashes the servers config file. Including a server name allows you to
	3191	rehash a remote servers config file. Several flags are also available. They
	3192	Include <br>
	3193	-motd - Only rehash all MOTD and RULES files (including tld {})<br>
	3194	-opermotd - Only rehash the OPERMOTD file<br>
	3195	-botmotd - Only rehash the BOTMOTD file<br>
	3196	-garbage - Force garbage collection<br>
	3197	<td>IRCop</td>
	3198	</tr>
	3199	<tr>
	3200	<td height="39">restart <password> <reason><br></td>
	3201	<td>Restarts the IRCD Process. Password is required if drpass { } is present.
	3202	You may also include a reason.<br></td>
	3203	<td>IRCop</td>
	3204	</tr>
	3205	<tr>
	3206	<td height="39">die <password><br></td>
	3207	<td>Terminates the IRCD Process. Password is required if drpass { } is present.</td>
	3208	<td>IRCop</td>
	3209	</tr>
	3210	<tr>
	3211	<td height="39">lag <server> <br></td>
	3212	<td>This command is like a Sonar or Traceroute for IRC server. You type in
	3213	/LAG irc.fyremoon.net and it will reply from every server it passes with
	3214	time and so on. Useful for looking where lag is and optional TS future/past
	3215	travels<br></td>
	3216	<td>IRCop</td>
	3217	</tr>
	3218	<tr>
	3219	<td height="39">sethost <newhost></td>
	3220	<td>Lets you change your vhost to what ever you want it to be.<br></td>
	3221	<td>IRCop</td>
	3222	</tr>
	3223	<tr>
	3224	<td height="39">setident <newident><br></td>
	3225	<td>Lets you set your ident to what ever you want it to be<br></td>
	3226	<td>IRCop</td>
	3227	</tr>
	3228	<tr>
	3229	<td height="39">chghost <nick> <newhost><br></td>
	3230	<td>Lets you change the host name of a user currently on the system<br></td>
	3231	<td>IRCop</td>
	3232	</tr>
	3233	<tr>
	3234	<td height="39">chgident <nick> <newident><br></td>
	3235	<td>Lets you change the ident of a user currently on the system<br></td>
	3236	<td>IRCop</td>
	3237	</tr>
	3238	<tr>
	3239	<td height="39">chgname <nick> <newname><br></td>
	3240	<td>Lets you change the realname of a user currently on the system<br></td>
	3241	<td>IRCop</td>
	3242	</tr>
	3243	<tr>
	3244	<td height="39">squit <server><br></td>
	3245	<td>Disconnects a server from the network<br></td>
	3246	<td>IRCop</td>
	3247	</tr>
	3248	<tr>
	3249	<td height="39">connect <server> <port> <server></td>
	3250	<td>If only one server is given, it will attempt to connect the server you
	3251	are ON to the given server. If 2 servers are given, it will attempt to connect
	3252	the 2 servers together. Put the leaf server as the first, and the hub server
	3253	as the second.<br></td>
	3254	<td>IRCop</td>
	3255	</tr>
	3256	<tr>
	3257	<td height="39">dccdeny <filemask> <reason><br></td>
	3258	<td>Adds a DCCDENY for that filemask. Preventing that file from being sent.<br></td>
	3259	<td>IRCop</td>
	3260	</tr>
	3261	<tr>
	3262	<td height="39">undccdeny <filemask><br></td>
	3263	<td>Removes a DCCDENY</td>
	3264	<td>IRCop</td>
	3265	</tr>
	3266	<tr>
	3267	<td height="39">sajoin <nick> <channel>, <channel><br></td>
	3268	<td>Forces a user to join a channel(s). Available to services & network
	3269	admins only</td>
	3270	<td>IRCop</td>
	3271	</tr>
	3272	<tr>
	3273	<td height="39">sapart <nick> <channel>, <channel><br></td>
	3274	<td>Forces a user to part a channel(s). Available to services & network
	3275	admins only.<br></td>
	3276	<td>IRCop</td>
	3277	</tr>
	3278	<tr>
	3279	<td height="39">samode <channel> <mode><br></td>
	3280	<td>Allows Network & Services admins to change modes of a channel without
	3281	having ChanOps.<br></td>
	3282	<td>IRCop</td>
	3283	</tr>
	3284	<tr>
	3285	<td height="39">rping <servermask><br></td>
	3286	<td>Will calculate in milliseconds the lag between servers<br></td>
	3287	<td>IRCop</td>
	3288	</tr>
	3289	<tr>
	3290	<td height="39">trace <servermask\|nickname><br></td>
	3291	<td>When used on a user it will give you class and lag info. If you use
	3292	it on a server it gives you class/version/link info.<br></td>
	3293	<td>IRCop</td>
	3294	</tr>
	3295	<tr>
	3296	<td height="39">opermotd <br></td>
	3297	<td>Displays the servers OperMotd File<br></td>
	3298	<td>IRCop</td>
	3299	</tr>
	3300	<tr>
	3301	<td height="39">addmotd :<text><br></td>
	3302	<td>Will add the given text to the end of the Motd<br></td>
	3303	<td>IRCop</td>
	3304	</tr>
	3305	<tr>
	3306	<td height="36">addomotd :<text><br></td>
	3307	<td>Will add the given text to the end of the OperMotd<br></td>
	3308	<td>IRCop</td>
	3309	</tr>
	3310	<tr>
	3311	<td height="36">sdesc <newdescription><br></td>
	3312	<td>Allows server admins to change the description line of their server without
	3313	restarting.<br></td>
	3314	<td>IRCop</td>
	3315	</tr>
	3316	<tr>
	3317	<td height="36">addline <text><br></td>
	3318	<td>Allows you to add lines to the unrealircd.conf<br></td>
	3319	<td>IRCop</td>
	3320	</tr>
	3321	<tr>
	3322	<td height="36">mkpasswd <password><br></td>
	3323	<td>Will encrypt a clear text password to add it to the unrealircd.conf<br></td>
	3324	<td>IRCop</td>
	3325	</tr>
	3326	<tr>
	3327	<td height="36">tsctl offset +/- <time><br></td>
	3328	<td>Adjust the IRCD’s Internal clock (Do NOT use if you do not understand
	3329	EXACTLY what it does)<br></td>
	3330	<td>IRCop</td>
	3331	</tr>
	3332	<tr>
	3333	<td height="36">tsctl time<br></td>
	3334	<td>Will give a TS Report</td>
	3335	<td>IRCop</td>
	3336	</tr>
	3337	<tr>
	3338	<td height="36">tsctl alltime</td>
	3339	<td>Will give a TS Report of ALL servers</td>
	3340	<td>IRCop</td>
	3341	</tr>
	3342	<tr>
	3343	<td height="36">tsctl svstime <timestamp><br></td>
	3344	<td>Sets the TS time of all servers (Do NOT use if you do not understand EXACTLY
	3345	what it does)<br></td>
	3346	<td>IRCop</td>
	3347	</tr>
	3348	<tr>
	3349	<td height="36">htm <option><br></td>
	3350	<td>Controls settings related to high traffic mode. High Traffic Mode (HTM)
	3351	basically disables certain user commands such as: list whois who etc in
	3352	response to extremely high traffic on the server. Options include: <br>
	3353	-ON Forces server into HTM <br>
	3354	-OFF Forces server out of HTM <br>
	3355	-NOISY Sets the server to notify users/admins when in goes in and out of HTM<br>
	3356	-QUIET Sets the server to NOT notify when going in and out of HTM<br>
	3357	-TO <value> Tell HTM at what incoming rate to activate HTM<br> </td>
	3358	<td>IRCop</td>
	3359	</tr>
	3360	<tr>
	3361	<td height="36">stats <option><br></td>
	3362	<td>
	3363	B - banversion - Send the ban version list<br>
	3364	b - badword - Send the badwords list<br>
	3365	C - link - Send the link block list<br>
	3366	d - denylinkauto - Send the deny link (auto) block list<br>
	3367	D - denylinkall - Send the deny link (all) block list<br>
	3368	e - exceptthrottle - Send the except throttle block list<br>
	3369	E - exceptban - Send the except ban and except tkl block list<br>
	3370	f - spamfilter - Send the spamfilter list<br>
	3371	F - denydcc - Send the deny dcc block list<br>
	3372	G - gline - Send the gline and gzline list<br>
	3373	Extended flags: [+/-mrs] [mask] [reason] [setby]<br>
	3374	m Return glines matching/not matching the specified mask<br>
	3375	r Return glines with a reason matching/not matching the specified reason<br>
	3376	s Return glines set by/not set by clients matching the specified name<br>
	3377	I - allow - Send the allow block list<br>
	3378	j - officialchans - Send the offical channels list<br>
	3379	K - kline - Send the ban user/ban ip/except ban block list<br>
	3380	l - linkinfo - Send link information<br>
	3381	L - linkinfoall - Send all link information<br>
	3382	M - command - Send list of how many times each command was used<br>
	3383	n - banrealname - Send the ban realname block list<br>
	3384	O - oper - Send the oper block list<br>
	3385	P - port - Send information about ports<br>
	3386	q - sqline - Send the SQLINE list<br>
	3387	Q - bannick - Send the ban nick block list<br>
	3388	r - chanrestrict - Send the channel deny/allow block list<br>
	3389	R - usage - Send usage information<br>
	3390	S - set - Send the set block list<br>
	3391	s - shun - Send the shun list<br>
	3392	Extended flags: [+/-mrs] [mask] [reason] [setby]<br>
	3393	m Return shuns matching/not matching the specified mask<br>
	3394	r Return shuns with a reason matching/not matching the specified reason<br>
	3395	s Return shuns set by/not set by clients matching the specified name<br>
	3396	t - tld - Send the tld block list<br>
	3397	T - traffic - Send traffic information<br>
	3398	u - uptime - Send the server uptime and connection count<br>
	3399	U - uline - Send the ulines block list<br>
	3400	v - denyver - Send the deny version block list<br>
	3401	V - vhost - Send the vhost block list<br>
	3402	X - notlink - Send the list of servers that are not current linked<br>
	3403	Y - class - Send the class block list<br>
	3404	z - zip - Send compression information about ziplinked servers (if compiled with ziplinks support)<br>
	3405	Z - mem - Send memory usage information<br>
	3406	</td>
	3407	<td>All</td>
	3408	</tr>
	3409	<tr>
	3410	<td height="36">module<br></td>
	3411	<td>
	3412	Lists all loaded modules
	3413	</td>
	3414	<td>All</td>
	3415	</tr>
	3416	<tr>
	3417	<td height="36">close<br></td>
	3418	<td>
	3419	This command will disconnect all unknown connections from the IRC server.
	3420	</td>
	3421	<td>IRCOp</td>
	3422	</tr>
	3423	</table>
	3424
	3425	<p></p></div>
	3426
	3427	<p><font size="+2"><b>8 – Security tips/checklist<a name="security"></a></b></font></p>
	3428	<div class="desc">
	3429	<p>If you are concerned about security (you should be!), this section will help you get an overview
	3430	of the risks that are out there and their risk-level. Alternatively you can use it as a "checklist"
	3431	to walk through your (network) configuration to make things more secure.</p>
	3432	<p>The list is ordered by by popularity/risk level/most-often-used-attack-methods:</p>
	3433	</div></p>
	3434
	3435	<p><b><font size="+2">8.1 Passwords</font></b><a name="secpasswords"></a><br><div class="desc">
	3436	Choose good oper passwords, link passwords, etc:<br>
	3437	- use mixed case and digits ("Whbviwf5") and/or something long ("blaheatsafish", "AlphaBeta555").<br>
	3438	- DO NOT use your link/oper passwords for something else like your mail account, bot password, forums, etc...<br>
	3439	</div></p>
	3440
	3441	<p><b><font size="+2">8.2 Non-Ircd related vulnerabilities</font></b><a name="secnonircd"></a><br><div class="desc">
	3442	There's a far bigger chance a box will get hacked by a non-irc(d) vulnerability than by some bug in UnrealIRCd.
	3443	If you for example run http, dns, smtp and ftp servers on the same box you have a much higher risk.
	3444	Also, if you are on a multi-user box (eg: you bought a shell) there's the risk of local exploits and bad permissions
	3445	(see next). This risk is quite high so be careful when selecting a shell provider.
	3446	</div></p>
	3447
	3448	<p><b><font size="+2">8.3 Permissions and the configfile</font></b><a name="secpermissions"></a><br><div class="desc">
	3449	Always make sure your home directory and UnrealIRCd directory have correct permissions,
	3450	(group/)other shouldn't have read permissions. Otherwise a local user can simply grab
	3451	your configfile and look for passwords... In short: <i>chmod -R go-rwx /path/to/Unreal3.2</i> if you are unsure about this.<br>
	3452	Other things related to this: never put your UnrealIRCd inside the webroot or some other
	3453	kind of shared directory. And for backups, make sure they get the correct permissions too
	3454	(it happens quite frequently everything is secured fine but there's a backup.tar.gz lying
	3455	around readable by everyone).<br>
	3456	<br>
	3457	You also want to use encrypted passwords wherever possible, if you compile with OpenSSL
	3458	support (which you do, since you are concerned with security, right?) then I suggest to
	3459	use <i>sha1</i> or <i>ripemd160</i> password encryption, else use <i>md5</i>. Also if
	3460	you still have encrypted (oper) blocks left from Unreal3.2.1 or before I suggest you to
	3461	re-enrypt these (just re-run /mkpasswd), because 3.2.1 introduced some considerable
	3462	anti-crack improvements (basically a 14x slowdown of active cracks, and making
	3463	stored-plain-ciphertext cracks impossible).<br>
	3464	Still, do note that this is just 'yet another layer of security', since if you have weak
	3465	passwords they can still be cracked relatively easily and if someone manages to get your
	3466	configfile there are usually other interesting things in it that may aid an attacker,
	3467	like link::password-connect.
	3468	</div></p>
	3469
	3470	<p><b><font size="+2">8.4 User-related problems</font></b><a name="secuser"></a><br><div class="desc">
	3471	Just like most of these things, this is not UnrealIRCd-specific, but..<br>
	3472	Always choose your opers and admins wisely. And do remember the concept of weakest-link.
	3473	Even though you are careful and did everything in this doc, maybe your friend which is an
	3474	oper too did something stupid. Like share his harddrive via netbios/kazaa/morpheus/..,
	3475	got a trojan, used an obvious password, etc etc.. Unfortunately, it's not always in your control.<br>
	3476	One thing you could do however is carefuly choose which privileges someone needs (oper::flags).
	3477	</div></p>
	3478
	3479	<p><b><font size="+2">8.5 SSL/SSH & sniffing</font></b><a name="secsnif"></a><br><div class="desc">
	3480	Use SSL connections between servers and as an oper, this will protect you against "sniffing".
	3481	Sniffing is possible if an attacker hacked a box somewhere between you and your ircd server,
	3482	he can then look at ALL network traffic that passes by; watch all conversations, capture all passwords
	3483	(oper logins, nickserv, etc).. For the same reason, always use ssh instead of telnet.
	3484	</div></p>
	3485
	3486	<p><b><font size="+2">8.6 Denial of Service attacks (DoS) [or: how to protect my hub]</font></b><a name="secDoS"></a><br><div class="desc">
	3487	A lot of networks have experienced how much "fun" a flood or (D)DoS attack is, you can however
	3488	do some things to reduce the damage caused by it. Most nets have a hub server, what some people
	3489	seem to forget is that it's quite easy to protect the hub server from getting attacked.<br>
	3490	I'll explain it here:<br>
	3491	1. Set the name of the hub to a hostname that doesn't exist, eg 'hub.yournet.com', but<br>
	3492	don't add a dns record for it. This way an attacker cannot resolve the host and<br>
	3493	cannot flood it either. Then simply link your servers to the hub by specifying the<br>
	3494	IP or another non-public hostname.<br>
	3495	Example 1: <i>link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };</i>.<br>
	3496	Example 2: <i>link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };</i>.<br>
	3497	On a sidenote, for the last example you must be sure your nameservers don't allow zone transfers,
	3498	but that's way too off-topic ;).<br>
	3499	2. Another important step is then to hide '/stats c' and other stats information, otherwise<br>
	3500	attackers can simply list your link blocks. Usually if you are this paranoid (like<br>
	3501	me) you can simply do: set { oper-only-stats "*"; }; to restrict all /stats usage.<br>
	3502	If you don't want that, at least hide "CdDlLXz". More about this in the next section.<br>
	3503	<br>
	3504	Of course those steps are less useful if they are applied afterwards (eg: after a few months)<br>
	3505	instead of at the beginning because the IP's might be already known to some evil guys, still.. it's worth to do.<br>
	3506	Also note that attackers can still flood all non-hub servers, but that requires more effort<br>
	3507	than just attacking 1 or 2 weak points (the hubs), also this way your hubs & services
	3508	will stay alive :).<br>
	3509	</div></p>
	3510
	3511	<p><b><font size="+2">8.7 Information disclosure</font></b><a name="secinformation"></a><br><div class="desc">
	3512	<b>STATS</b><br>
	3513	The /stats command is very informative, you probably want to restrict it's usage as much
	3514	as possible. A question you should ask yourself is "what do I want my users to see?".
	3515	Most big networks choose "nothing", while others prefer their clients to be able to do
	3516	'/stats g' and '/stats k'.<br>
	3517	I suggest you to use <i>set { oper-only-stats "*"; };</i> to deny all /stats for non-opers, but if you don't
	3518	want that, step through the '/stats' list (gives an overview of all available options) and
	3519	block everything except what you want to allow.. (if in doubt, just deny.. why should they
	3520	really need to know all this?).<br>
	3521	To give you a few examples:<br>
	3522	- /stats o: gives you the nicks of opers (with correct case) and hostmasks.<br>
	3523	- /stats c: gives you an idea about serverlinks and which to use as 'backup', etc..<br>
	3524	- /stats g, /stats k: usually used for banning proxies.. so this will simply give attackers
	3525	a list of proxies they can use.<br>
	3526	- /stats E, /stats e: pretty sensitive info, especially if an attacker can use these addresses<br>
	3527	- /stats i, /stats y: might aid an attacker in finding hosts which allow lots of connections.<br>
	3528	- /stats P: helps him find serveronly ports<br>
	3529	etc etc...<br>
	3530	<br>
	3531	<b>MAP / LINKS</b><br>
	3532	Several people have asked if there was some way to disable /map or /links.
	3533	Our position on this is that it's silly and gives a false sense of security, let me explain...
	3534	Hiding servers that are actually used by users is useless since they already know
	3535	about your servers (how else could they get on them in the first place?). For any servers that you
	3536	don't want users on, see section 8.6.<br>
	3537	Now what CAN you do? Since 3.2.1 there's an option called 'flat map' (set::options::flat-map),
	3538	this will make all servers appear as 'directly linked' in /map and /links, thus normal users
	3539	can no longer see which server is linked to which... This can be a nice additional layer
	3540	of protection because this way a kiddie cannot easily spot any 'weak points' with /map or /links.
	3541	So, use of this is recommended. Note that this is not foolproof... If any split happends someone
	3542	can still see which server was linked to which, and this is also true for some other things as well.<br>
	3543	<br>
	3544	<b>NORMAL USERS & SNOMASKS</b><br>
	3545	A feature that isn't widely known is that normal users can also set some limited snomasks,
	3546	namely +s +sk. By this they can see things like rehashes, kills and various other messages.<br>
	3547	To disable this you can use set::restrict-usermodes like this: <i>set { restrict-usermodes "s"; };</i>.<br>
	3548
	3549
	3550	<br><br>
	3551	Of course all of this is "information hiding", so it's not "true" security.
	3552	It will however make it more difficult / increase the effort needed to attack/hack.<br>
	3553	</div></p>
	3554
	3555	<p><b><font size="+2">8.8 Protecting against exploits</font></b><a name="secantiexploit"></a><br><div class="desc">
	3556	There are kernel patches that make it more difficult for stack- and heap-based exploits to
	3557	work. This is nice, but should not be your main focus point, you have a far more bigger risk
	3558	of getting exploited through the other points than this... for various reasons.<br>
	3559	Another option is enabling chrooting (*NIX only), which means upon a succesfull exploit,
	3560	the user is confined to the UnrealIRCd directory and cannot touch any other
	3561	files. This requires root privileges, modifying of include/config.h
	3562	(search for CHROOTDIR, and also set IRC_USER and IRC_GROUP), and a
	3563	recompile.<br>
	3564	<br>
	3565	There's one thing you should definately do, which is to ALWAYS USE THE LATEST VERSION,
	3566	subscribe to the <a href="http://mail1.sourceforge.net/mailman/listinfo/unreal-notify" target="_blank">unreal-notify mailinglist</a>
	3567	right now so you receive the release announcements (unreal-notify is for release announcements only,
	3568	so only 1 mail per X months). Usually it's explicitly mentioned in the release announcement if the
	3569	release contains (high risk) security fixes, but it's good to upgrade anyway.<br>
	3570	</div></p>
	3571
	3572	<p><b><font size="+2">8.9 Summary</font></b><a name="secsummary"></a><br><div class="desc">
	3573	As you now hopefully understand, you can never be 100% secure. You (and us) have to
	3574	find&fix every hole out there, while an attacker only needs to find just 1 server with 1 hole.
	3575	Everything that was explained here DOES however help by minimizing the risks considerably.
	3576	Do take the time to secure your network and educate your opers. A lot of people don't care about
	3577	security until they got hacked, try to avoid that :).
	3578	</div></p>
	3579
	3580
	3581	<p><font size="+2"><b>9 – Frequently Asked Questions (FAQ)<a name="faq"></a></b></font></p>
	3582	<div class="desc"><p>The FAQ is available online <a href="http://www.vulnscan.org/UnrealIRCd/faq/" TARGET="_blank">here</a></p></div>
	3583	<p></p>
	3584
	3585	<p><font size="+2"><b>A Regular Expressions<a name="regex"></a></b></font></p>
	3586	<div class="desc"><p>Regular expressions are used in many places in Unreal, including badwords, spamfilter, and aliases. Regular expressions are a very complex tool used for pattern matching. They are sometimes referred to as "regexp" or "regex." Unreal uses the TRE regular expression library for its regex. This library supports some very complex and advanced expressions that may be confusing. The information below will help you understand how regexps work. If you are interested in more technical and detailed information about the regexp syntax used by Unreal, visit the <a href="http://www.laurikari.net/tre/syntax.html" target="_new">TRE homepage</a>.</p></div>
	3587
	3588	<p><font size="+2"><b>A.1 Literals<a name="regexlit"></a></b></font></p>
	3589	<div class="desc"><p>Literals are the most basic component of a regexp. Basically, they are characters that are treated as plaintext. For example, the pattern "test" consists of the four literals, "t," "e," "s," and "t." In Unreal, literals are treated as case insensitive, so the previous regex would match "test" as well as "TEST." Any character that is not a "meta character" (discussed in the following sections) is treated as a literal. You can also explicitely make a character a literal by using a backslash (\). For example, the dot (.) is a metacharacter. If you wish to include a literal ., simply use \. and Unreal will treat this as a period. It is also possible that you want to check for a character that is not easily typed, say ASCII character 3 (color). Rather than having to deal with using an IRC client to create this character, you can use a special sequence, the \x. If you type \x3, then it is interpretted as being the ASCII character 3. The number after the \x is represented as hexidecimal and can be in the range from \x0 to \xFF.</p></div>
	3590
	3591	<p><font size="+2"><b>A.2 Dot Operator<a name="regexdot"></a></b></font></p>
	3592	<div class="desc"><p>The dot (.) operator is used to match "any character." It matches a single character that has any value. For example, the regex "a.c" will match "abc," "adc," etc. However, it will not match "abd" because the "a" and "c" are literals that must match exactly.</p></div>
	3593
	3594	<p><font size="+2"><b>A.3 Repetition Operators<a name="regexrep"></a></b></font></p>
	3595	<div class="desc"><p>One of the common mistakes people make with regex is assuming that they work just like wildcards. That is, the * and ? characters will match just like in a wildcard. While these characters do have similar meaning in a regex, they are not exactly the same. Additionaly, regular expressions also support other, more advanced methods of repetition.
	3596	<p>
	3597	The most basic repetition operator is the ? operator. This operator matches 0 or 1 of the previous character. This, "of the previous character," is where the ? in regex differs from a wildcard. In a wildcard, the expression, "a?c" matches an "a" followed by any character, followed by a "c". In regex it has a different meaning. It matches 0 or 1 of the letter "a" followed by the letter "c". Basically, the ? is modifying the a by specifying how many a's may be present. To emulate the ? in a wildcard, the . operator is used. The regex "a.c" is equivilent to the previously mentioned wildcard. It matches the letter "a" followed by any character, followed by a "c".
	3598	<p>
	3599	The next repetition operator is the . Again, this operator is similar to a wildcard. It matches 0 or more of the previous character. Note that this "of the previous character" is something that is characteristic of all repetition operators. The regex "ac" matches 0 or more a's followed by a "c". For example, "aaaaaac" matches. Once again, to make this work like a wildcard, you would use "a.c" which will cause the to modify the . (any character) rather than the "a."
	3600	<p>
	3601	The + operator is very similar to the . However, instead of matching 0 or more, it matches 1 or more. Basically, "ac" will match "c" (0 a's followed by a c), where as "a+c" would not. The "a+" states that there must be "at least" 1 a. So "c" does not match but "ac" and "aaaaaaaaac" do.
	3602	<p>
	3603	The most advanced repetition operator is known as a "boundary." A boundary lets you set exact constraints on how many of the previous character must be present. For example, you may want to require exactly 8 a's, or at least 8 a's, or between 3 and 5 a's. The boundary allows you to accomplish all of these. The basic syntax is {M,N} where M is the lower bound, and N is the upper bound. For example, the match between 3 and 5 a's, you would do "a{3,5}". However, you do not have to specify both numbers. If you do "a{8}" it means there must be exactly 8 a's. Therefore, "a{8}" is equivilent to "aaaaaaaa." To specify the "at least" example, you basically create a boundary that only has a lower bound. So for at least 8 a's, you would do "a{8,}".
	3604	<p>
	3605	By default, all of the repetition operators are "greedy." Greediness is a somewhat complex idea. Basically, it means that an operator will match as many characters as it can. This is best explained by an example. <p>Say we have the following text:<br>
	3606	HELLO<br>
	3607	And the following regex:<br>
	3608	.+L<p>
	3609	In this example, you might think that the .+ matches "HE." However, this is incorrect. Because the + is greedy, it matches "HEL." The reason is, it chooses the largest portion of the input text that can be matched while still allowing the entire regex to match. In this example, it chose "HEL" because the only other requirement is that the character after the text matched by .+ must be an "L". Since the text is "HELLO", "HEL" is followed by an "L," and therefore it matches. Sometimes, however, it is useful to make an operator nongreedy. This can be done by adding a ? character after the repetition operator. Modifying the above to, ".+?L" the .+? will now match "HE" rather than "HEL" since it has been placed in a nongreedy state. The ? can be added to any repetition character: ??, *?, +?, {M,N}?.</p></div>
	3610
	3611	<p><font size="+2"><b>A.4 Bracket Expressions<a name="regexbracket"></a></b></font></p>
	3612	<div class="desc">Bracket expressions provide a convenient way to do an "or" operator. For example, if you want to say "match an a or a b." The bracket expression gets its name from the fact that it is enclosed in brackets ([]). The basic syntax is that the expression includes a series of characters. These characters are then treated as though there were an "or" between them. As an example, the expression "[abc]" matches an "a," a "b," or a "c." Therefore, the regexp "a[bd]c" matches "abc" and "adc" but not "acc."
	3613	<p>
	3614	One very common thing to do is to check for things such as, a letter, or a digit. Rather than having to do, for example, "[0123456789]", the bracket operator supports ranges. Ranges work by specifying the beginning and ending point with a - between them. Therefore, a more simplistic way to test for a digit is to simply do "[0-9]". The same thing can be used on letters, or in fact, any range of ASCII values. If you want to match a letter, simply do "[a-z]" since Unreal is case insensitive, this will match all letters. You can also include multiple ranges in the same expression. To match a letter or a number, "[0-9a-z]". One complication that this creates is that the - is a special character in a bracket expression. To have it match a literal -, the easiest way is to place it as either the first or last character in the expression. For example, "[0-9-]" matches a digit or a -.
	3615	<p>
	3616	To make things even more simple, there are several "character classes" that may be used within a bracket expression. These character classes eliminate the need to define certain ranges. Character classes are written by enclosing their name in :'s. For example, "[0-9]" could also be written as "[:isdigit:]". The list below shows all of the available character classes and what they do:
	3617	<ul>
	3618	<li><tt>alnum</tt> - alphanumeric characters</li>
	3619	<li><tt>alpha</tt> - alphabetic characters</li>
	3620	<li><tt>blank</tt> - blank characters</li>
	3621	<li><tt>cntrl</tt> - control characters</li>
	3622	<li><tt>digit</tt> - decimal digits (0 through 9)</li>
	3623	<li><tt>graph</tt> - all printable characters except space</li>
	3624	<li><tt>lower</tt> - lower-case letters</li>
	3625	<li><tt>print</tt> - printable characters including space</li>
	3626	<li><tt>punct</tt> - printable characters not space or alphanumeric</li>
	3627	<li><tt>space</tt> - white-space characters</li>
	3628	<li><tt>upper</tt> - upper case letters</li>
	3629	<li><tt>xdigit</tt> - hexadecimal digits</li>
	3630	</ul>
	3631	One important note about character classes is that they MUST be the only element in the expression. For example, [:isdigit:-] is NOT legal. Instead, you can accomplish this same goal by nesting the expressions, for example, to do the same thing as "[0-9-]" using a character class, you could do "[[:isdigit:]-]".
	3632	<p>
	3633	The last feature of the bracket expression is negation. Sometimes it is useful to say "anything except these characters." For example, if you want to check if the character is "not a letter," it is easier to list a-z and say "not these," than it is to list all the non-letters. Bracket expressions allow you to handle this through negation. You negate the expression by specifying a "^" as the first character. For example, "[^a-z]" would match any non-letter. As with the -, if you want to include a literal ^, do not place it in the first position, "[a-z^]". Also, to negate a character class, you must once again use nesting, "[^[:isdigit:]]" would match any non-digit.</p></div>
	3634	<p><font size="+2"><b>A.5 Assertions<a name="regexassert"></a></b></font></p>
	3635	<div class="desc">Assertions allow you to test for certain conditions that are not representable by character strings, as well as providing shortcuts for some common bracket expressions.
	3636	<p>
	3637	The ^ character is referred to as the "left anchor." This character matches the beginning of a string. If you simply specify a regex such as "test", it will match, for example "this is a test" since that string contains "test." But, sometimes it is useful to ensure that the string actually starts with the pattern. This can be done with ^. For example "^test" means that the text must start with "test." Additionally, the $ character is the "right anchor." This character matches the end of the string. So if you were to do "^test$", then the string must be exactly the word "test."
	3638	<p>
	3639	Similar tests also exist for words. All of the other assertions are specified using a \ followed by a specific character. For example, to test for the beginning and ending of a word, you can use \< and \> respectively.
	3640	<p>
	3641	The remaining assertions all come with two forms, a positive and a negative. These assertions are listed below:
	3642	<ul>
	3643	<li><tt>\b</tt> - Word boundary
	3644	<li><tt>\B</tt> - Non-word boundary
	3645	<li><tt>\d</tt> - Digit character (equivalent to <tt>[[:digit:]]</tt>)</li>
	3646	<li><tt>\D</tt> - Non-digit character (equivalent to <tt>[^[:digit:]]</tt>)</li>
	3647	<li><tt>\s</tt> - Space character (equivalent to <tt>[[:space:]]</tt>)</li>
	3648	<li><tt>\S</tt> - Non-space character (equivalent to <tt>[^[:space:]]</tt>)</li>
	3649	<li><tt>\w</tt> - Word character (equivalent to <tt>[[:alnum:]_]</tt>)</li>
	3650	<li><tt>\W</tt> - Non-word character (equivalent to <tt>[^[:alnum:]_]</tt>)</li>
	3651	</ul>
	3652	</div>
	3653	<p><font size="+2"><b>A.6 Alternation<a name="regexalt"></a></b></font></p>
	3654	<div class="desc">Alternation is a method of saying "or." The alternation operator is the vertical bar (\|). For example, if you wanted to say "a or b" you could do "a\|b". For normal letters, this could be replaced by a bracket expression, but alternation can also be used with subexpressions (discussed in the next section).
	3655	</div>
	3656	<p><font size="+2"><b>A.7 Subexpressions<a name="regexsub"></a></b></font></p>
	3657	<div class="desc">Subexpressions are a portion of of a regex that is treated as a single entity. There are two ways to create a subexpression. The two methods differ with regard to "back references," which will be explained later. To declare a subexpression that uses back references, simply enclose it in parentheses (). To create a subexpression that does not use back references, replace the open-parenthesis with, "(?:". For example, "([a-z])" and "(?:[a-z])". The reason subexpressions are useful is you can then apply operators to the expression. All of the repetition operators, for example, that were mentioned as "X or more of the previous character," can also be used for "X or more of the previous subexpression." For example, if you have a regex of "[0-9][a-z][0-9]", to match a digit, followed by a letter, followed by a digit, and then you decided you wanted to match this sequence twice. Normally, you would do, "[0-9][a-z][0-9][0-9][a-z][0-9]". With subexpressions, however, you can simply do "([0-9][a-z][0-9]){2}".</div>
	3658	<p><font size="+2"><b>A.8 Back References<a name="regexbackref"></a></b></font></p>
	3659	<div class="desc">Back references allow you to reference the string that matched one of the subexpressions of the regexp. You use a back reference by specifying a backslash (\) followed by a number, 0-9, for example \1. \0 is a special back reference that refers to the entire regexp, rather than a subexpression. Back references are useful when you want to match something that contains the same string twice. For example, say you have a nick!user@host. You know that there is a trojan that uses a nickname and username that matches "[0-9][a-z]{5}", and both the nickname and username are the same. Using "[0-9][a-z]{5}![0-9][a-z]{5}@.+" will not work because it would allow the nickname and username to be different. For example, the nickname could be 1abcde and the username 2fghij. Back references allow you to overcome this limitation. Using, "([0-9][a-z]{5})!\1@.+" will work exactly as expected. This searches for the nickname matching the given subexpressions, then it uses a back reference to say that the username must be the same text.
	3660	<p>
	3661	Since you can only have 9 back references, this is the reason why the (?:) notation is useful. It allows you to create a subexpression without wasting a back reference. Additionally, since back reference information does not need to be saved, it is also faster. Because of this, non-back reference subexpressions should be used whenever back references are not needed.</div>
	3662	<p><font size="+2"><b>A.9 Case Sensitivity<a name="regexcase"></a></b></font></p>
	3663	<div class="desc">As was already mentioned, Unreal makes all regexps case insensitive by default. The main reason for this is, there seem to be many more instances where you want case insensitive searching rather than sensitive, for example, if you block the text "www.test.com," you presumably want to block "WWW.TEST.COM" as well. However, there are instances where you may want case sensitivity, for example, matching for certain trojans. Because of this, a method is provided to dynamically turn case insensitivity on/off. To turn it off, simply use "(?-i)" and to turn it on, "(?i)". For example, "(?-i)[a-z](?i)[a-z]" will match a lowercase letter (case insensitivity is off) followed by either an uppercase or lowercase letter (case insensitivity is on). Additionally, rather than having to always remember to turn the flag back on when you are finished, you can also specify that the flag change should only apply to a subexpression, for example, "(?-i:[a-z])[a-z]" is equivilent to the previous regexp because the -i only applies to the given subexpression.
	3664	</body>
	3665	</html>

-0

go.mod less more

0	0	module github.com/fluffle/goirc
1	1
2	2	require (
	3	github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead
3	4	github.com/golang/mock v1.5.0
4	5	golang.org/x/net v0.0.0-20210119194325-5f4716e94777
5	6	)

-1

go.sum less more

	0	github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead h1:fI1Jck0vUrXT8bnphprS1EoVRe2Q5CKCX8iDlpqjQ/Y=
	1	github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead/go.mod h1:iL2twTeMvZnrg54ZoPDNfJaJaqy0xIQFuBdrLsmspwQ=
0	2	github.com/golang/mock v1.5.0 h1:jlYHihg//f7RRwuPfptm04yp4s7O6Kw8EZiVYIGcH0g=
1	3	github.com/golang/mock v1.5.0/go.mod h1:CWnOUgYIOo4TcNZ0wHX3YZCqsaM1I1Jvs6v3mP3KVu8=
2	4	golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
3	5	golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
4	6	golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
5		golang.org/x/net v0.0.0-20180926154720-4dfa2610cdf3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
6	7	golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
7	8	golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
8	9	golang.org/x/net v0.0.0-20210119194325-5f4716e94777 h1:003p0dJM77cxMSyCPFphvZf/Y5/NXf5fzg6ufd1/Oew=