New Upstream Release - golang-github-fluffle-goirc
Ready changes
Summary
Merged new upstream version: 1.3.0+ds (was: 1.1.1+ds).
Resulting package
Built on 2022-12-18T04:11 (took 7m35s)
The resulting binary packages can be installed (if you have the apt repository enabled) by running one of:
apt install -t fresh-releases golang-github-fluffle-goirc-dev
Diff
diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index 1cbcab5..0000000
--- a/.gitignore
+++ /dev/null
@@ -1,8 +0,0 @@
-/gobot
-*.[568]
-_obj/
-_test/
-*.swp
-*~
-*.out
-/.gitconfig
diff --git a/.travis.yml b/.travis.yml
index aaef0bd..0b5d58e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -2,8 +2,10 @@
language: go
go:
- - 1.16.2
- - 1.15.10
+ - 1.18
+ - 1.17.8
+ - 1.16.15
+ - 1.15.15
sudo : false
diff --git a/README.md b/README.md
index 6d7c8ea..5c1108c 100644
--- a/README.md
+++ b/README.md
@@ -82,6 +82,11 @@ and `DisableStateTracking()` respectively. Doing this while connected to an IRC
server will probably result in an inconsistent state and a lot of warnings to
STDERR ;-)
+### Projects using GoIRC
+
+- [xdcc-cli](https://github.com/ostafen/xdcc-cli): A command line tool for searching and downloading files from the IRC network.
+
+
### Misc.
Sorry the documentation is crap. Use the source, Luke.
@@ -92,7 +97,7 @@ indebted to Matt Gruen for his work on
the re-organisation and channel-based communication structure of `*Conn.send()`
and `*Conn.recv()`. I'm sure things could be more asynchronous, still.
-This code is (c) 2009-15 Alex Bramley, and released under the same licence terms
+This code is (c) 2009-23 Alex Bramley, and released under the same licence terms
as Go itself.
Contributions gratefully received from:
@@ -110,6 +115,8 @@ Contributions gratefully received from:
- [jakebailey](https://github.com/jakebailey)
- [stapelberg](https://github.com/stapelberg)
- [shammash](https://github.com/shammash)
+ - [ostafen](https://github.com/ostafen)
+ - [supertassu](https://github.com/supertassu)
And thanks to the following for minor doc/fix PRs:
diff --git a/client/commands.go b/client/commands.go
index 101c7d3..f5d4c58 100644
--- a/client/commands.go
+++ b/client/commands.go
@@ -10,6 +10,7 @@ const (
CONNECTED = "CONNECTED"
DISCONNECTED = "DISCONNECTED"
ACTION = "ACTION"
+ AUTHENTICATE = "AUTHENTICATE"
AWAY = "AWAY"
CAP = "CAP"
CTCP = "CTCP"
@@ -84,6 +85,23 @@ func splitMessage(msg string, splitLen int) (msgs []string) {
return append(msgs, msg)
}
+func splitArgs(args []string, maxLen int) []string {
+ res := make([]string, 0)
+
+ i := 0
+ for i < len(args) {
+ currArg := args[i]
+ i++
+
+ for i < len(args) && len(currArg)+len(args[i])+1 < maxLen {
+ currArg += " " + args[i]
+ i++
+ }
+ res = append(res, currArg)
+ }
+ return res
+}
+
// Raw sends a raw line to the server, should really only be used for
// debugging purposes but may well come in handy.
func (conn *Conn) Raw(rawline string) {
@@ -299,6 +317,14 @@ func (conn *Conn) Cap(subcommmand string, capabilities ...string) {
if len(capabilities) == 0 {
conn.Raw(CAP + " " + subcommmand)
} else {
- conn.Raw(CAP + " " + subcommmand + " :" + strings.Join(capabilities, " "))
+ cmdPrefix := CAP + " " + subcommmand + " :"
+ for _, args := range splitArgs(capabilities, defaultSplit-len(cmdPrefix)) {
+ conn.Raw(cmdPrefix + args)
+ }
}
}
+
+// Authenticate send an AUTHENTICATE command to the server.
+func (conn *Conn) Authenticate(message string) {
+ conn.Raw(AUTHENTICATE + " " + message)
+}
diff --git a/client/commands_test.go b/client/commands_test.go
index 15a8a05..25af371 100644
--- a/client/commands_test.go
+++ b/client/commands_test.go
@@ -2,6 +2,8 @@ package client
import (
"reflect"
+ "strconv"
+ "strings"
"testing"
)
@@ -203,3 +205,20 @@ func TestClientCommands(t *testing.T) {
c.VHost("user", "pass")
s.nc.Expect("VHOST user pass")
}
+
+func TestSplitCommand(t *testing.T) {
+ nArgs := 100
+
+ args := make([]string, 0)
+ for i := 0; i < nArgs; i++ {
+ args = append(args, "arg"+strconv.Itoa(i))
+ }
+
+ for maxLen := 1; maxLen <= defaultSplit; maxLen *= 2 {
+ for _, argStr := range splitArgs(args, maxLen) {
+ if len(argStr) > maxLen && len(strings.Split(argStr, " ")) > 1 {
+ t.Errorf("maxLen = %d, but len(cmd) = %d", maxLen, len(argStr))
+ }
+ }
+ }
+}
diff --git a/client/connection.go b/client/connection.go
index 43bcc24..aa9f2f5 100644
--- a/client/connection.go
+++ b/client/connection.go
@@ -13,6 +13,7 @@ import (
"sync"
"time"
+ "github.com/emersion/go-sasl"
"github.com/fluffle/goirc/logging"
"github.com/fluffle/goirc/state"
"golang.org/x/net/proxy"
@@ -45,6 +46,15 @@ type Conn struct {
out chan string
connected bool
+ // Capabilities supported by the server
+ supportedCaps *capSet
+
+ // Capabilites currently enabled
+ currCaps *capSet
+
+ // SASL internals
+ saslRemainingData []byte
+
// CancelFunc and WaitGroup for goroutines
die context.CancelFunc
wg sync.WaitGroup
@@ -89,6 +99,15 @@ type Config struct {
// Passed through to https://golang.org/pkg/net/#Dialer
DualStack bool
+ // Enable IRCv3 capability negotiation.
+ EnableCapabilityNegotiation bool
+
+ // A list of capabilities to request to the server during registration.
+ Capabilites []string
+
+ // SASL configuration to use to authenticate the connection.
+ Sasl sasl.Client
+
// Replaceable function to customise the 433 handler's new nick.
// By default an underscore "_" is appended to the current nick.
NewNick func(string) string
@@ -125,12 +144,13 @@ type Config struct {
// name, but these are optional.
func NewConfig(nick string, args ...string) *Config {
cfg := &Config{
- Me: &state.Nick{Nick: nick},
- PingFreq: 3 * time.Minute,
- NewNick: DefaultNewNick,
- Recover: (*Conn).LogPanic, // in dispatch.go
- SplitLen: defaultSplit,
- Timeout: 60 * time.Second,
+ Me: &state.Nick{Nick: nick},
+ PingFreq: 3 * time.Minute,
+ NewNick: DefaultNewNick,
+ Recover: (*Conn).LogPanic, // in dispatch.go
+ SplitLen: defaultSplit,
+ Timeout: 60 * time.Second,
+ EnableCapabilityNegotiation: false,
}
cfg.Me.Ident = "goirc"
if len(args) > 0 && args[0] != "" {
@@ -203,14 +223,22 @@ func Client(cfg *Config) *Conn {
}
}
+ if cfg.Sasl != nil && !cfg.EnableCapabilityNegotiation {
+ logging.Warn("Enabling capability negotiation as it's required for SASL")
+ cfg.EnableCapabilityNegotiation = true
+ }
+
conn := &Conn{
- cfg: cfg,
- dialer: dialer,
- intHandlers: handlerSet(),
- fgHandlers: handlerSet(),
- bgHandlers: handlerSet(),
- stRemovers: make([]Remover, 0, len(stHandlers)),
- lastsent: time.Now(),
+ cfg: cfg,
+ dialer: dialer,
+ intHandlers: handlerSet(),
+ fgHandlers: handlerSet(),
+ bgHandlers: handlerSet(),
+ stRemovers: make([]Remover, 0, len(stHandlers)),
+ lastsent: time.Now(),
+ supportedCaps: capabilitySet(),
+ currCaps: capabilitySet(),
+ saslRemainingData: nil,
}
conn.addIntHandlers()
return conn
@@ -230,10 +258,9 @@ func (conn *Conn) Connected() bool {
// affect client behaviour. To disable flood protection temporarily,
// for example, a handler could do:
//
-// conn.Config().Flood = true
-// // Send many lines to the IRC server, risking "excess flood"
-// conn.Config().Flood = false
-//
+// conn.Config().Flood = true
+// // Send many lines to the IRC server, risking "excess flood"
+// conn.Config().Flood = false
func (conn *Conn) Config() *Config {
return conn.cfg
}
@@ -289,6 +316,16 @@ func (conn *Conn) DisableStateTracking() {
}
}
+// SupportsCapability returns true if the server supports the given capability.
+func (conn *Conn) SupportsCapability(cap string) bool {
+ return conn.supportedCaps.Has(cap)
+}
+
+// HasCapability returns true if the given capability has been acked by the server during negotiation.
+func (conn *Conn) HasCapability(cap string) bool {
+ return conn.currCaps.Has(cap)
+}
+
// Per-connection state initialisation.
func (conn *Conn) initialise() {
conn.io = nil
diff --git a/client/handlers.go b/client/handlers.go
index 24165ad..3920c02 100644
--- a/client/handlers.go
+++ b/client/handlers.go
@@ -4,22 +4,37 @@ package client
// to manage tracking an irc connection etc.
import (
+ "sort"
"strings"
+ "sync"
"time"
+ "encoding/base64"
"github.com/fluffle/goirc/logging"
)
+// saslCap is the IRCv3 capability used for SASL authentication.
+const saslCap = "sasl"
+
// sets up the internal event handlers to do essential IRC protocol things
var intHandlers = map[string]HandlerFunc{
- REGISTER: (*Conn).h_REGISTER,
- "001": (*Conn).h_001,
- "433": (*Conn).h_433,
- CTCP: (*Conn).h_CTCP,
- NICK: (*Conn).h_NICK,
- PING: (*Conn).h_PING,
+ REGISTER: (*Conn).h_REGISTER,
+ "001": (*Conn).h_001,
+ "433": (*Conn).h_433,
+ CTCP: (*Conn).h_CTCP,
+ NICK: (*Conn).h_NICK,
+ PING: (*Conn).h_PING,
+ CAP: (*Conn).h_CAP,
+ "410": (*Conn).h_410,
+ AUTHENTICATE: (*Conn).h_AUTHENTICATE,
+ "903": (*Conn).h_903,
+ "904": (*Conn).h_904,
+ "908": (*Conn).h_908,
}
+// set up the ircv3 capabilities supported by this client which will be requested by default to the server.
+var defaultCaps = []string{}
+
func (conn *Conn) addIntHandlers() {
for n, h := range intHandlers {
// internal handlers are essential for the IRC client
@@ -35,6 +50,10 @@ func (conn *Conn) h_PING(line *Line) {
// Handler for initial registration with server once tcp connection is made.
func (conn *Conn) h_REGISTER(line *Line) {
+ if conn.cfg.EnableCapabilityNegotiation {
+ conn.Cap(CAP_LS)
+ }
+
if conn.cfg.Pass != "" {
conn.Pass(conn.cfg.Pass)
}
@@ -42,6 +61,214 @@ func (conn *Conn) h_REGISTER(line *Line) {
conn.User(conn.cfg.Me.Ident, conn.cfg.Me.Name)
}
+func (conn *Conn) getRequestCapabilities() *capSet {
+ s := capabilitySet()
+
+ // add capabilites supported by the client
+ s.Add(defaultCaps...)
+
+ if conn.cfg.Sasl != nil {
+ // add the SASL cap if enabled
+ s.Add(saslCap)
+ }
+
+ // add capabilites requested by the user
+ s.Add(conn.cfg.Capabilites...)
+
+ return s
+}
+
+func (conn *Conn) negotiateCapabilities(supportedCaps []string) {
+ conn.supportedCaps.Add(supportedCaps...)
+
+ reqCaps := conn.getRequestCapabilities()
+ reqCaps.Intersect(conn.supportedCaps)
+
+ if reqCaps.Size() > 0 {
+ conn.Cap(CAP_REQ, reqCaps.Slice()...)
+ } else {
+ conn.Cap(CAP_END)
+ }
+}
+
+func (conn *Conn) handleCapAck(caps []string) {
+ gotSasl := false
+ for _, cap := range caps {
+ conn.currCaps.Add(cap)
+
+ if conn.cfg.Sasl != nil && cap == saslCap {
+ mech, ir, err := conn.cfg.Sasl.Start()
+
+ if err != nil {
+ logging.Warn("SASL authentication failed: %v", err)
+ continue
+ }
+
+ // TODO: when IRC 3.2 capability negotiation is supported, ensure the
+ // capability value is used to match the chosen mechanism
+
+ gotSasl = true
+ conn.saslRemainingData = ir
+
+ conn.Authenticate(mech)
+ }
+ }
+
+ if !gotSasl {
+ conn.Cap(CAP_END)
+ }
+}
+
+func (conn *Conn) handleCapNak(caps []string) {
+ conn.Cap(CAP_END)
+}
+
+const (
+ CAP_LS = "LS"
+ CAP_REQ = "REQ"
+ CAP_ACK = "ACK"
+ CAP_NAK = "NAK"
+ CAP_END = "END"
+)
+
+type capSet struct {
+ caps map[string]bool
+ mu sync.RWMutex
+}
+
+func capabilitySet() *capSet {
+ return &capSet{
+ caps: make(map[string]bool),
+ }
+}
+
+func (c *capSet) Add(caps ...string) {
+ c.mu.Lock()
+ for _, cap := range caps {
+ if strings.HasPrefix(cap, "-") {
+ c.caps[cap[1:]] = false
+ } else {
+ c.caps[cap] = true
+ }
+ }
+ c.mu.Unlock()
+}
+
+func (c *capSet) Has(cap string) bool {
+ c.mu.RLock()
+ defer c.mu.RUnlock()
+ return c.caps[cap]
+}
+
+// Intersect computes the intersection of two sets.
+func (c *capSet) Intersect(other *capSet) {
+ c.mu.Lock()
+
+ for cap := range c.caps {
+ if !other.Has(cap) {
+ delete(c.caps, cap)
+ }
+ }
+
+ c.mu.Unlock()
+}
+
+func (c *capSet) Slice() []string {
+ c.mu.RLock()
+ defer c.mu.RUnlock()
+
+ capSlice := make([]string, 0, len(c.caps))
+ for cap := range c.caps {
+ capSlice = append(capSlice, cap)
+ }
+
+ // make output predictable for testing
+ sort.Strings(capSlice)
+ return capSlice
+}
+
+func (c *capSet) Size() int {
+ c.mu.RLock()
+ defer c.mu.RUnlock()
+ return len(c.caps)
+}
+
+// This handler is triggered when an invalid cap command is received by the server.
+func (conn *Conn) h_410(line *Line) {
+ logging.Warn("Invalid cap subcommand: ", line.Args[1])
+}
+
+// Handler for capability negotiation commands.
+// Note that even if multiple CAP_END commands may be sent to the server during negotiation,
+// only the first will be considered.
+func (conn *Conn) h_CAP(line *Line) {
+ subcommand := line.Args[1]
+
+ caps := strings.Fields(line.Text())
+ switch subcommand {
+ case CAP_LS:
+ conn.negotiateCapabilities(caps)
+ case CAP_ACK:
+ conn.handleCapAck(caps)
+ case CAP_NAK:
+ conn.handleCapNak(caps)
+ }
+}
+
+// Handler for SASL authentication
+func (conn *Conn) h_AUTHENTICATE(line *Line) {
+ if conn.cfg.Sasl == nil {
+ return
+ }
+
+ if conn.saslRemainingData != nil {
+ data := "+" // plus sign representing empty data
+ if len(conn.saslRemainingData) > 0 {
+ data = base64.StdEncoding.EncodeToString(conn.saslRemainingData)
+ }
+
+ // TODO: batch data into chunks of 400 bytes per the spec
+
+ conn.Authenticate(data)
+ conn.saslRemainingData = nil
+ return
+ }
+
+ // TODO: handle data over 400 bytes long (which will be chunked into multiple messages per the spec)
+ challenge, err := base64.StdEncoding.DecodeString(line.Args[0])
+ if err != nil {
+ logging.Error("Failed to decode SASL challenge: %v", err)
+ return
+ }
+
+ response, err := conn.cfg.Sasl.Next(challenge)
+ if err != nil {
+ logging.Error("Failed to generate response for SASL challenge: %v", err)
+ return
+ }
+
+ // TODO: batch data into chunks of 400 bytes per the spec
+ data := base64.StdEncoding.EncodeToString(response)
+ conn.Authenticate(data)
+}
+
+// Handler for RPL_SASLSUCCESS.
+func (conn *Conn) h_903(line *Line) {
+ conn.Cap(CAP_END)
+}
+
+// Handler for RPL_SASLFAILURE.
+func (conn *Conn) h_904(line *Line) {
+ logging.Warn("SASL authentication failed")
+ conn.Cap(CAP_END)
+}
+
+// Handler for RPL_SASLMECHS.
+func (conn *Conn) h_908(line *Line) {
+ logging.Warn("SASL mechanism not supported, supported mechanisms are: %v", line.Args[1])
+ conn.Cap(CAP_END)
+}
+
// Handler to trigger a CONNECTED event on receipt of numeric 001
// :<server> 001 <nick> :Welcome message <nick>!<user>@<host>
func (conn *Conn) h_001(line *Line) {
diff --git a/client/handlers_test.go b/client/handlers_test.go
index 171e5c9..1e374d5 100644
--- a/client/handlers_test.go
+++ b/client/handlers_test.go
@@ -456,3 +456,54 @@ func Test671(t *testing.T) {
s.st.EXPECT().GetNick("user2").Return(nil)
c.h_671(ParseLine(":irc.server.org 671 test user2 :some ignored text"))
}
+
+func TestCap(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().EnableCapabilityNegotiation = true
+ c.Config().Capabilites = []string{"cap1", "cap2", "cap3", "cap4"}
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+
+ // Ensure that capabilities not supported by the server are not requested
+ s.nc.Send("CAP * LS :cap2 cap4")
+ s.nc.Expect("CAP REQ :cap2 cap4")
+
+ s.nc.Send("CAP * ACK :cap2 cap4")
+ s.nc.Expect("CAP END")
+
+ for _, cap := range []string{"cap2", "cap4"} {
+ if !c.SupportsCapability(cap) {
+ t.Fail()
+ }
+
+ if !c.HasCapability(cap) {
+ t.Fail()
+ }
+ }
+
+ for _, cap := range []string{"cap1", "cap3"} {
+ if c.HasCapability(cap) {
+ t.Fail()
+ }
+ }
+
+ // test disable capability after registration
+ s.c.Cap("REQ", "-cap4")
+ s.nc.Expect("CAP REQ :-cap4")
+
+ s.nc.Send("CAP * ACK :-cap4")
+ s.nc.Expect("CAP END")
+
+ if !c.HasCapability("cap2") {
+ t.Fail()
+ }
+
+ if c.HasCapability("cap4") {
+ t.Fail()
+ }
+}
diff --git a/client/sasl_test.go b/client/sasl_test.go
new file mode 100644
index 0000000..073a074
--- /dev/null
+++ b/client/sasl_test.go
@@ -0,0 +1,103 @@
+package client
+
+import (
+ "github.com/emersion/go-sasl"
+ "testing"
+)
+
+func TestSaslPlainSuccessWorkflow(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
+ c.Config().EnableCapabilityNegotiation = true
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+ s.nc.Send("CAP * LS :sasl foobar")
+ s.nc.Expect("CAP REQ :sasl")
+ s.nc.Send("CAP * ACK :sasl")
+ s.nc.Expect("AUTHENTICATE PLAIN")
+ s.nc.Send("AUTHENTICATE +")
+ s.nc.Expect("AUTHENTICATE AGV4YW1wbGUAcGFzc3dvcmQ=")
+ s.nc.Send("904 test :SASL authentication successful")
+ s.nc.Expect("CAP END")
+}
+
+func TestSaslPlainWrongPassword(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
+ c.Config().EnableCapabilityNegotiation = true
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+ s.nc.Send("CAP * LS :sasl foobar")
+ s.nc.Expect("CAP REQ :sasl")
+ s.nc.Send("CAP * ACK :sasl")
+ s.nc.Expect("AUTHENTICATE PLAIN")
+ s.nc.Send("AUTHENTICATE +")
+ s.nc.Expect("AUTHENTICATE AGV4YW1wbGUAcGFzc3dvcmQ=")
+ s.nc.Send("904 test :SASL authentication failed")
+ s.nc.Expect("CAP END")
+}
+
+func TestSaslExternalSuccessWorkflow(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().Sasl = sasl.NewExternalClient("")
+ c.Config().EnableCapabilityNegotiation = true
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+ s.nc.Send("CAP * LS :sasl foobar")
+ s.nc.Expect("CAP REQ :sasl")
+ s.nc.Send("CAP * ACK :sasl")
+ s.nc.Expect("AUTHENTICATE EXTERNAL")
+ s.nc.Send("AUTHENTICATE +")
+ s.nc.Expect("AUTHENTICATE +")
+ s.nc.Send("904 test :SASL authentication successful")
+ s.nc.Expect("CAP END")
+}
+
+func TestSaslNoSaslCap(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
+ c.Config().EnableCapabilityNegotiation = true
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+ s.nc.Send("CAP * LS :foobar")
+ s.nc.Expect("CAP END")
+}
+
+func TestSaslUnsupportedMechanism(t *testing.T) {
+ c, s := setUp(t)
+ defer s.tearDown()
+
+ c.Config().Sasl = sasl.NewPlainClient("", "example", "password")
+ c.Config().EnableCapabilityNegotiation = true
+
+ c.h_REGISTER(&Line{Cmd: REGISTER})
+ s.nc.Expect("CAP LS")
+ s.nc.Expect("NICK test")
+ s.nc.Expect("USER test 12 * :Testing IRC")
+ s.nc.Send("CAP * LS :sasl foobar")
+ s.nc.Expect("CAP REQ :sasl")
+ s.nc.Send("CAP * ACK :sasl")
+ s.nc.Expect("AUTHENTICATE PLAIN")
+ s.nc.Send("908 test external :are available SASL mechanisms")
+ s.nc.Expect("CAP END")
+}
diff --git a/debian/changelog b/debian/changelog
index f3468c9..f8b9aed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-fluffle-goirc (1.3.0+ds-1) UNRELEASED; urgency=low
+
+ * New upstream release.
+
+ -- Debian Janitor <janitor@jelmer.uk> Sun, 18 Dec 2022 04:05:11 -0000
+
golang-github-fluffle-goirc (1.1.1+ds-2) unstable; urgency=medium
[ Debian Janitor ]
diff --git a/doc/rfc2811.txt b/doc/rfc2811.txt
new file mode 100644
index 0000000..7c2c4ea
--- /dev/null
+++ b/doc/rfc2811.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group C. Kalt
+Request for Comments: 2811 April 2000
+Updates: 1459
+Category: Informational
+
+
+ Internet Relay Chat: Channel Management
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ One of the most notable characteristics of the IRC (Internet Relay
+ Chat) protocol is to allow for users to be grouped in forums, called
+ channels, providing a mean for multiple users to communicate
+ together.
+
+ There was originally a unique type of channels, but with the years,
+ new types appeared either as a response to a need, or for
+ experimental purposes.
+
+ This document specifies how channels, their characteristics and
+ properties are managed by IRC servers.
+
+Table of Contents
+
+ 1. Introduction ............................................... 2
+ 2. Channel Characteristics .................................... 3
+ 2.1 Namespace .............................................. 3
+ 2.2 Channel Scope .......................................... 3
+ 2.3 Channel Properties ..................................... 4
+ 2.4 Privileged Channel Members ............................. 4
+ 2.4.1 Channel Operators ................................. 5
+ 2.4.2 Channel Creator ................................... 5
+ 3. Channel lifetime ........................................... 5
+ 3.1 Standard channels ...................................... 5
+ 3.2 Safe Channels .......................................... 6
+ 4. Channel Modes .............................................. 7
+ 4.1 Member Status .......................................... 7
+ 4.1.1 "Channel Creator" Status .......................... 7
+
+
+
+Kalt Informational [Page 1]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 4.1.2 Channel Operator Status ........................... 8
+ 4.1.3 Voice Privilege ................................... 8
+ 4.2 Channel Flags .......................................... 8
+ 4.2.1 Anonymous Flag .................................... 8
+ 4.2.2 Invite Only Flag .................................. 8
+ 4.2.3 Moderated Channel Flag ............................ 9
+ 4.2.4 No Messages To Channel From Clients On The Outside 9
+ 4.2.5 Quiet Channel ..................................... 9
+ 4.2.6 Private and Secret Channels ....................... 9
+ 4.2.7 Server Reop Flag .................................. 10
+ 4.2.8 Topic ............................................. 10
+ 4.2.9 User Limit ........................................ 10
+ 4.2.10 Channel Key ...................................... 10
+ 4.3 Channel Access Control ................................. 10
+ 4.3.1 Channel Ban and Exception ......................... 11
+ 4.3.2 Channel Invitation ................................ 11
+ 5. Current Implementations .................................... 11
+ 5.1 Tracking Recently Used Channels ........................ 11
+ 5.2 Safe Channels .......................................... 12
+ 5.2.1 Channel Identifier ................................ 12
+ 5.2.2 Channel Delay ..................................... 12
+ 5.2.3 Abuse Window ...................................... 13
+ 5.2.4 Preserving Sanity In The Name Space ............... 13
+ 5.2.5 Server Reop Mechanism ............................. 13
+ 6. Current problems ........................................... 14
+ 6.1 Labels ................................................. 14
+ 6.1.1 Channel Delay ..................................... 14
+ 6.1.2 Safe Channels ..................................... 15
+ 6.2 Mode Propagation Delays ................................ 15
+ 6.3 Collisions And Channel Modes ........................... 15
+ 6.4 Resource Exhaustion .................................... 16
+ 7. Security Considerations .................................... 16
+ 7.1 Access Control ......................................... 16
+ 7.2 Channel Privacy ........................................ 16
+ 7.3 Anonymity ............................................... 17
+ 8. Current support and availability ........................... 17
+ 9. Acknowledgements ........................................... 17
+ 10. References ................................................ 18
+ 11. Author's Address .......................................... 18
+ 12. Full Copyright Statement ................................... 19
+
+1. Introduction
+
+ This document defines in detail on how channels are managed by the
+ IRC servers and will be mostly useful to people working on
+ implementing an IRC server.
+
+
+
+
+
+Kalt Informational [Page 2]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ While the concepts defined here are an important part of IRC, they
+ remain non essential for implementing clients. While the trend seems
+ to be towards more and more complex and "intelligent" clients which
+ are able to take advantage of knowing the internal workings of
+ channels to provide the users with a more friendly interface, simple
+ clients can be implemented without reading this document.
+
+ Many of the concepts defined here were designed with the IRC
+ architecture [IRC-ARCH] in mind and mostly make sense in this
+ context. However, many others could be applied to other
+ architectures in order to provide forums for a conferencing system.
+
+ Finally, it is to be noted that IRC users may find some of the
+ following sections of interest, in particular sections 2 (Channel
+ Characteristics) and 4 (Channel Modes).
+
+2. Channel Characteristics
+
+ A channel is a named group of one or more users which will all
+ receive messages addressed to that channel. A channel is
+ characterized by its name, properties and current members.
+
+2.1 Namespace
+
+ Channels names are strings (beginning with a '&', '#', '+' or '!'
+ character) of length up to fifty (50) characters. Channel names are
+ case insensitive.
+
+ Apart from the the requirement that the first character being either
+ '&', '#', '+' or '!' (hereafter called "channel prefix"). The only
+ restriction on a channel name is that it SHALL NOT contain any spaces
+ (' '), a control G (^G or ASCII 7), a comma (',' which is used as a
+ list item separator by the protocol). Also, a colon (':') is used as
+ a delimiter for the channel mask. The exact syntax of a channel name
+ is defined in "IRC Server Protocol" [IRC-SERVER].
+
+ The use of different prefixes effectively creates four (4) distinct
+ namespaces for channel names. This is important because of the
+ protocol limitations regarding namespaces (in general). See section
+ 6.1 (Labels) for more details on these limitations.
+
+2.2 Channel Scope
+
+ A channel entity is known by one or more servers on the IRC network.
+ A user can only become member of a channel known by the server to
+ which the user is directly connected. The list of servers which know
+
+
+
+
+
+Kalt Informational [Page 3]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ of the existence of a particular channel MUST be a contiguous part of
+ the IRC network, in order for the messages addressed to the channel
+ to be sent to all the channel members.
+
+ Channels with '&' as prefix are local to the server where they are
+ created.
+
+ Other channels are known to one (1) or more servers that are
+ connected to the network, depending on the channel mask:
+
+ If there is no channel mask, then the channel is known to all
+ the servers.
+
+ If there is a channel mask, then the channel MUST only be known
+ to servers which has a local user on the channel, and to its
+ neighbours if the mask matches both the local and neighbouring
+ server names. Since other servers have absolutely no knowledge of
+ the existence of such a channel, the area formed by the servers
+ having a name matching the mask has to be contiguous for the
+ channel to be known by all these servers. Channel masks are best
+ used in conjunction with server hostmasking [IRC-SERVER].
+
+2.3 Channel Properties
+
+ Each channel has its own properties, which are defined by channel
+ modes. Channel modes can be manipulated by the channel members. The
+ modes affect the way servers manage the channels.
+
+ Channels with '+' as prefix do not support channel modes. This means
+ that all the modes are unset, with the exception of the 't' channel
+ flag which is set.
+
+2.4 Privileged Channel Members
+
+ In order for the channel members to keep some control over a channel,
+ and some kind of sanity, some channel members are privileged. Only
+ these members are allowed to perform the following actions on the
+ channel:
+
+ INVITE - Invite a client to an invite-only channel (mode +i)
+ KICK - Eject a client from the channel
+ MODE - Change the channel's mode, as well as
+ members' privileges
+ PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
+ TOPIC - Change the channel topic in a mode +t channel
+
+
+
+
+
+
+Kalt Informational [Page 4]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+2.4.1 Channel Operators
+
+ The channel operators (also referred to as a "chop" or "chanop") on a
+ given channel are considered to 'own' that channel. Ownership of a
+ channel is shared among channel operators.
+
+ Channel operators are identified by the '@' symbol next to their
+ nickname whenever it is associated with a channel (i.e., replies to
+ the NAMES, WHO and WHOIS commands).
+
+ Since channels starting with the character '+' as prefix do not
+ support channel modes, no member can therefore have the status of
+ channel operator.
+
+2.4.2 Channel Creator
+
+ A user who creates a channel with the character '!' as prefix is
+ identified as the "channel creator". Upon creation of the channel,
+ this user is also given channel operator status.
+
+ In recognition of this status, the channel creators are endowed with
+ the ability to toggle certain modes of the channel which channel
+ operators may not manipulate.
+
+ A "channel creator" can be distinguished from a channel operator by
+ issuing the proper MODE command. See the "IRC Client Protocol"
+ [IRC-CLIENT] for more information on this topic.
+
+3. Channel lifetime
+
+ In regard to the lifetime of a channel, there are typically two
+ groups of channels: standard channels which prefix is either '&', '#'
+ or '+', and "safe channels" which prefix is '!'.
+
+3.1 Standard channels
+
+ These channels are created implicitly when the first user joins it,
+ and cease to exist when the last user leaves it. While the channel
+ exists, any client can reference the channel using the name of the
+ channel.
+
+ The user creating a channel automatically becomes channel operator
+ with the notable exception of channels which name is prefixed by the
+ character '+', see section 4 (Channel modes). See section 2.4.1
+ (Channel Operators) for more details on this title.
+
+
+
+
+
+
+Kalt Informational [Page 5]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ In order to avoid the creation of duplicate channels (typically when
+ the IRC network becomes disjoint because of a split between two
+ servers), channel names SHOULD NOT be allowed to be reused by a user
+ if a channel operator (See Section 2.4.1 (Channel Operators)) has
+ recently left the channel because of a network split. If this
+ happens, the channel name is temporarily unavailable. The duration
+ while a channel remains unavailable should be tuned on a per IRC
+ network basis. It is important to note that this prevents local
+ users from creating a channel using the same name, but does not
+ prevent the channel to be recreated by a remote user. The latter
+ typically happens when the IRC network rejoins. Obviously, this
+ mechanism only makes sense for channels which name begins with the
+ character '#', but MAY be used for channels which name begins with
+ the character '+'. This mechanism is commonly known as "Channel
+ Delay".
+
+3.2 Safe Channels
+
+ Unlike other channels, "safe channels" are not implicitly created. A
+ user wishing to create such a channel MUST request the creation by
+ sending a special JOIN command to the server in which the channel
+ identifier (then unknown) is replaced by the character '!'. The
+ creation process for this type of channel is strictly controlled.
+ The user only chooses part of the channel name (known as the channel
+ "short name"), the server automatically prepends the user provided
+ name with a channel identifier consisting of five (5) characters.
+ The channel name resulting from the combination of these two elements
+ is unique, making the channel safe from abuses based on network
+ splits.
+
+ The user who creates such a channel automatically becomes "channel
+ creator". See section 2.4.2 (Channel Creator) for more details on
+ this title.
+
+ A server MUST NOT allow the creation of a new channel if another
+ channel with the same short name exists; or if another channel with
+ the same short name existed recently AND any of its member(s) left
+ because of a network split. Such channel ceases to exist after last
+ user leaves AND no other member recently left the channel because of
+ a network split.
+
+ Unlike the mechanism described in section 5.2.2 (Channel Delay), in
+ this case, channel names do not become unavailable: these channels
+ may continue to exist after the last user left. Only the user
+ creating the channel becomes "channel creator", users joining an
+ existing empty channel do not automatically become "channel creator"
+ nor "channel operator".
+
+
+
+
+Kalt Informational [Page 6]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ To ensure the uniqueness of the channel names, the channel identifier
+ created by the server MUST follow specific rules. For more details
+ on this, see section 5.2.1 (Channel Identifier).
+
+4. Channel Modes
+
+ The various modes available for channels are as follows:
+
+ O - give "channel creator" status;
+ o - give/take channel operator privilege;
+ v - give/take the voice privilege;
+
+ a - toggle the anonymous channel flag;
+ i - toggle the invite-only channel flag;
+ m - toggle the moderated channel;
+ n - toggle the no messages to channel from clients on the
+ outside;
+ q - toggle the quiet channel flag;
+ p - toggle the private channel flag;
+ s - toggle the secret channel flag;
+ r - toggle the server reop channel flag;
+ t - toggle the topic settable by channel operator only flag;
+
+ k - set/remove the channel key (password);
+ l - set/remove the user limit to channel;
+
+ b - set/remove ban mask to keep users out;
+ e - set/remove an exception mask to override a ban mask;
+ I - set/remove an invitation mask to automatically override
+ the invite-only flag;
+
+ Unless mentioned otherwise below, all these modes can be manipulated
+ by "channel operators" by using the MODE command defined in "IRC
+ Client Protocol" [IRC-CLIENT].
+
+4.1 Member Status
+
+ The modes in this category take a channel member nickname as argument
+ and affect the privileges given to this user.
+
+4.1.1 "Channel Creator" Status
+
+ The mode 'O' is only used in conjunction with "safe channels" and
+ SHALL NOT be manipulated by users. Servers use it to give the user
+ creating the channel the status of "channel creator".
+
+
+
+
+
+
+Kalt Informational [Page 7]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+4.1.2 Channel Operator Status
+
+ The mode 'o' is used to toggle the operator status of a channel
+ member.
+
+4.1.3 Voice Privilege
+
+ The mode 'v' is used to give and take voice privilege to/from a
+ channel member. Users with this privilege can talk on moderated
+ channels. (See section 4.2.3 (Moderated Channel Flag).
+
+4.2 Channel Flags
+
+ The modes in this category are used to define properties which
+ affects how channels operate.
+
+4.2.1 Anonymous Flag
+
+ The channel flag 'a' defines an anonymous channel. This means that
+ when a message sent to the channel is sent by the server to users,
+ and the origin is a user, then it MUST be masked. To mask the
+ message, the origin is changed to "anonymous!anonymous@anonymous."
+ (e.g., a user with the nickname "anonymous", the username "anonymous"
+ and from a host called "anonymous."). Because of this, servers MUST
+ forbid users from using the nickname "anonymous". Servers MUST also
+ NOT send QUIT messages for users leaving such channels to the other
+ channel members but generate a PART message instead.
+
+ On channels with the character '&' as prefix, this flag MAY be
+ toggled by channel operators, but on channels with the character '!'
+ as prefix, this flag can be set (but SHALL NOT be unset) by the
+ "channel creator" only. This flag MUST NOT be made available on
+ other types of channels.
+
+ Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
+ presence of other users on channels for which the anonymous flag is
+ set.
+
+4.2.2 Invite Only Flag
+
+ When the channel flag 'i' is set, new members are only accepted if
+ their mask matches Invite-list (See section 4.3.2) or they have been
+ invited by a channel operator. This flag also restricts the usage of
+ the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
+ channel operators.
+
+
+
+
+
+
+Kalt Informational [Page 8]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+4.2.3 Moderated Channel Flag
+
+ The channel flag 'm' is used to control who may speak on a channel.
+ When it is set, only channel operators, and members who have been
+ given the voice privilege may send messages to the channel.
+
+ This flag only affects users.
+
+4.2.4 No Messages To Channel From Clients On The Outside
+
+ When the channel flag 'n' is set, only channel members MAY send
+ messages to the channel.
+
+ This flag only affects users.
+
+4.2.5 Quiet Channel
+
+ The channel flag 'q' is for use by servers only. When set, it
+ restricts the type of data sent to users about the channel
+ operations: other user joins, parts and nick changes are not sent.
+ From a user's point of view, the channel contains only one user.
+
+ This is typically used to create special local channels on which the
+ server sends notices related to its operations. This was used as a
+ more efficient and flexible way to replace the user mode 's' defined
+ in RFC 1459 [IRC].
+
+4.2.6 Private and Secret Channels
+
+ The channel flag 'p' is used to mark a channel "private" and the
+ channel flag 's' to mark a channel "secret". Both properties are
+ similar and conceal the existence of the channel from other users.
+
+ This means that there is no way of getting this channel's name from
+ the server without being a member. In other words, these channels
+ MUST be omitted from replies to queries like the WHOIS command.
+
+ When a channel is "secret", in addition to the restriction above, the
+ server will act as if the channel does not exist for queries like the
+ TOPIC, LIST, NAMES commands. Note that there is one exception to
+ this rule: servers will correctly reply to the MODE command.
+ Finally, secret channels are not accounted for in the reply to the
+ LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
+ CLIENT]) when the <mask> parameter is specified.
+
+
+
+
+
+
+
+Kalt Informational [Page 9]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ The channel flags 'p' and 's' MUST NOT both be set at the same time.
+ If a MODE message originating from a server sets the flag 'p' and the
+ flag 's' is already set for the channel, the change is silently
+ ignored. This should only happen during a split healing phase
+ (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
+
+4.2.7 Server Reop Flag
+
+ The channel flag 'r' is only available on channels which name begins
+ with the character '!' and MAY only be toggled by the "channel
+ creator".
+
+ This flag is used to prevent a channel from having no channel
+ operator for an extended period of time. When this flag is set, any
+ channel that has lost all its channel operators for longer than the
+ "reop delay" period triggers a mechanism in servers to reop some or
+ all of the channel inhabitants. This mechanism is described more in
+ detail in section 5.2.4 (Channel Reop Mechanism).
+
+4.2.8 Topic
+
+ The channel flag 't' is used to restrict the usage of the TOPIC
+ command to channel operators.
+
+4.2.9 User Limit
+
+ A user limit may be set on channels by using the channel flag 'l'.
+ When the limit is reached, servers MUST forbid their local users to
+ join the channel.
+
+ The value of the limit MUST only be made available to the channel
+ members in the reply sent by the server to a MODE query.
+
+4.2.10 Channel Key
+
+ When a channel key is set (by using the mode 'k'), servers MUST
+ reject their local users request to join the channel unless this key
+ is given.
+
+ The channel key MUST only be made visible to the channel members in
+ the reply sent by the server to a MODE query.
+
+4.3 Channel Access Control
+
+ The last category of modes is used to control access to the channel,
+ they take a mask as argument.
+
+
+
+
+
+Kalt Informational [Page 10]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ In order to reduce the size of the global database for control access
+ modes set for channels, servers MAY put a maximum limit on the number
+ of such modes set for a particular channel. If such restriction is
+ imposed, it MUST only affect user requests. The limit SHOULD be
+ homogeneous on a per IRC network basis.
+
+4.3.1 Channel Ban and Exception
+
+ When a user requests to join a channel, his local server checks if
+ the user's address matches any of the ban masks set for the channel.
+ If a match is found, the user request is denied unless the address
+ also matches an exception mask set for the channel.
+
+ Servers MUST NOT allow a channel member who is banned from the
+ channel to speak on the channel, unless this member is a channel
+ operator or has voice privilege. (See Section 4.1.3 (Voice
+ Privilege)).
+
+ A user who is banned from a channel and who carries an invitation
+ sent by a channel operator is allowed to join the channel.
+
+4.3.2 Channel Invitation
+
+ For channels which have the invite-only flag set (See Section 4.2.2
+ (Invite Only Flag)), users whose address matches an invitation mask
+ set for the channel are allowed to join the channel without any
+ invitation.
+
+5. Current Implementations
+
+ The only current implementation of these rules as part of the IRC
+ protocol is the IRC server, version 2.10.
+
+ The rest of this section deals with issues that are mostly of
+ importance to those who wish to implement a server but some parts may
+ also be of interest for client writers.
+
+5.1 Tracking Recently Used Channels
+
+ This mechanism is commonly known as "Channel Delay" and generally
+ only applies to channels which names is prefixed with the character
+ '#' (See Section 3.1 "Standard channels").
+
+ When a network split occurs, servers SHOULD keep track of which
+ channels lost a "channel operator" as the result of the break. These
+ channels are then in a special state which lasts for a certain period
+ of time. In this particular state, the channels cannot cease to
+
+
+
+
+Kalt Informational [Page 11]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ exist. If all the channel members leave the channel, the channel
+ becomes unavailable: the server local clients cannot join the channel
+ as long as it is empty.
+
+ Once a channel is unavailable, it will become available again either
+ because a remote user has joined the channel (most likely because the
+ network is healing), or because the delay period has expired (in
+ which case the channel ceases to exist and may be re-created).
+
+ The duration for which a channel death is delayed SHOULD be set
+ considering many factors among which are the size (user wise) of the
+ IRC network, and the usual duration of network splits. It SHOULD be
+ uniform on all servers for a given IRC network.
+
+5.2 Safe Channels
+
+ This document introduces the notion of "safe channels". These
+ channels have a name prefixed with the character '!' and great effort
+ is made to avoid collisions in this name space. Collisions are not
+ impossible, however they are very unlikely.
+
+5.2.1 Channel Identifier
+
+ The channel identifier is a function of the time. The current time
+ (as defined under UNIX by the number of seconds elapsed since
+ 00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
+ characters using the following base:
+ "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
+ value starting from 0 for 'A' to 35 for '0').
+
+ The channel identifier therefore has a periodicity of 36^5 seconds
+ (about 700 days).
+
+5.2.2 Channel Delay
+
+ These channels MUST be subject to the "channel delay" mechanism
+ described in section 5.1 (Channel Delay). However, the mechanism is
+ slightly adapted to fit better.
+
+ Servers MUST keep track of all such channels which lose members as
+ the result of a network split, no matter whether the user is a
+ "channel operator" or not.
+
+ However, these channels do NOT ever become unavailable, it is always
+ possible to join them even when they are empty.
+
+
+
+
+
+
+Kalt Informational [Page 12]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+5.2.3 Abuse Window
+
+ Because the periodicity is so long, attacks on a particular channel
+ (name) may only occur once in a very long while. However, with luck
+ and patience, it is still possible for a user to cause a channel
+ collision. In order to avoid this, servers MUST "look in the future"
+ and keep a list of channel names which identifier is about to be used
+ (in the coming few days for example). Such list should remain small,
+ not be a burden for servers to maintain and be used to avoid channel
+ collisions by preventing the re-creation of such channel for a longer
+ period of time than channel delay does.
+
+ Eventually a server MAY choose to extend this procedure to forbid
+ creation of channels with the same shortname only (then ignoring the
+ channel identifier).
+
+5.2.4 Preserving Sanity In The Name Space
+
+ The combination of the mechanisms described in sections 5.2.2 and
+ 5.2.3 makes it quite difficult for a user to create a channel
+ collision. However, another type of abuse consists of creating many
+ channels having the same shortname, but different identifiers. To
+ prevent this from happening, servers MUST forbid the creation of a
+ new channel which has the same shortname of a channel currently
+ existing.
+
+5.2.5 Server Reop Mechanism
+
+ When a channel has been opless for longer than the "reop delay"
+ period and has the channel flag 'r' set (See Section 4.2.7 (Server
+ Reop Flag)), IRC servers are responsible for giving the channel
+ operator status randomly to some of the members.
+
+ The exact logic used for this mechanism by the current implementation
+ is described below. Servers MAY use a different logic, but that it
+ is strongly RECOMMENDED that all servers use the same logic on a
+ particular IRC network to maintain coherence as well as fairness.
+ For the same reason, the "reop delay" SHOULD be uniform on all
+ servers for a given IRC network. As for the "channel delay", the
+ value of the "reop delay" SHOULD be set considering many factors
+ among which are the size (user wise) of the IRC network, and the
+ usual duration of network splits.
+
+ a) the reop mechanism is triggered after a random time following the
+ expiration of the "reop delay". This should limit the eventuality
+ of the mechanism being triggered at the same time (for the same
+ channel) on two separate servers.
+
+
+
+
+Kalt Informational [Page 13]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ b) If the channel is small (five (5) users or less), and the "channel
+ delay" for this channel has expired,
+ Then reop all channel members if at least one member is local to
+ the server.
+
+ c) If the channel is small (five (5) users or less), and the "channel
+ delay" for this channel has expired, and the "reop delay" has
+ expired for longer than its value,
+ Then reop all channel members.
+
+ d) For other cases, reop at most one member on the channel, based on
+ some method build into the server. If you don't reop a member, the
+ method should be such that another server will probably op
+ someone. The method SHOULD be the same over the whole network. A
+ good heuristic could be just random reop.
+ (The current implementation actually tries to choose a member
+ local to the server who has not been idle for too long, eventually
+ postponing action, therefore letting other servers have a chance
+ to find a "not too idle" member. This is over complicated due to
+ the fact that servers only know the "idle" time of their local
+ users)
+
+6. Current problems
+
+ There are a number of recognized problems with the way IRC channels
+ are managed. Some of these can be directly attributed to the rules
+ defined in this document, while others are the result of the
+ underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from
+ RFC 1459 [IRC], this document introduces several novelties in an
+ attempt to solve some of the known problems.
+
+6.1 Labels
+
+ This document defines one of the many labels used by the IRC
+ protocol. Although there are several distinct namespaces (based on
+ the channel name prefix), duplicates inside each of these are not
+ allowed. Currently, it is possible for users on different servers to
+ pick the label which may result in collisions (with the exception of
+ channels known to only one server where they can be averted).
+
+6.1.1 Channel Delay
+
+ The channel delay mechanism described in section 5.1 (Tracking
+ Recently Used Channels) and used for channels prefixed with the
+ character '#' is a simple attempt at preventing collisions from
+ happening. Experience has shown that, under normal circumstances, it
+
+
+
+
+
+Kalt Informational [Page 14]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ is very efficient; however, it obviously has severe limitations
+ keeping it from being an adequate solution to the problem discussed
+ here.
+
+6.1.2 Safe Channels
+
+ "Safe channels" described in section 3.2 (Safe Channels) are a better
+ way to prevent collisions from happening as it prevents users from
+ having total control over the label they choose. The obvious
+ drawback for such labels is that they are not user friendly.
+ However, it is fairly trivial for a client program to improve on
+ this.
+
+6.2 Mode Propagation Delays
+
+ Because of network delays induced by the network, and because each
+ server on the path is REQUIRED to check the validity of mode changes
+ (e.g., user exists and has the right privileges), it is not unusual
+ for a MODE message to only affect part of the network, often creating
+ a discrepancy between servers on the current state of a channel.
+
+ While this may seem easy to fix (by having only the original server
+ check the validity of mode changes), it was decided not to do so for
+ various reasons. One concern is that servers cannot trust each
+ other, and that a misbehaving servers can easily be detected. This
+ way of doing so also stops wave effects on channels which are out of
+ synch when mode changes are issued from different directions.
+
+6.3 Collisions And Channel Modes
+
+ The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
+ describes how channel data is exchanged when two servers connect to
+ each other. Channel collisions (either legitimate or not) are
+ treated as inclusive events, meaning that the resulting channel has
+ for members all the users who are members of the channel on either
+ server prior to the connection.
+
+ Similarly, each server sends the channel modes to the other one.
+ Therefore, each server also receives these channel modes. There are
+ three types of modes for a given channel: flags, masks, and data.
+ The first two types are easy to deal with as they are either set or
+ unset. If such a mode is set on one server, it MUST be set on the
+ other server as a result of the connection.
+
+
+
+
+
+
+
+
+Kalt Informational [Page 15]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ As topics are not sent as part of this exchange, they are not a
+ problem. However, channel modes 'l' and 'k' are exchanged, and if
+ they are set on both servers prior to the connection, there is no
+ mechanism to decide which of the two values takes precedence. It is
+ left up to the users to fix the resulting discrepancy.
+
+6.4 Resource Exhaustion
+
+ The mode based on masks defined in section 4.3 make the IRC servers
+ (and network) vulnerable to a simple abuse of the system: a single
+ channel operator can set as many different masks as possible on a
+ particular channel. This can easily cause the server to waste
+ memory, as well as network bandwidth (since the info is propagated to
+ other servers). For this reason it is RECOMMENDED that a limit be
+ put on the number of such masks per channels as mentioned in section
+ 4.3.
+
+ Moreover, more complex mechanisms MAY be used to avoid having
+ redundant masks set for the same channel.
+
+7. Security Considerations
+
+7.1 Access Control
+
+ One of the main ways to control access to a channel is to use masks
+ which are based on the username and hostname of the user connections.
+ This mechanism can only be efficient and safe if the IRC servers have
+ an accurate way of authenticating user connections, and if users
+ cannot easily get around it. While it is in theory possible to
+ implement such a strict authentication mechanism, most IRC networks
+ (especially public networks) do not have anything like this in place
+ and provide little guaranty about the accuracy of the username and
+ hostname for a particular client connection.
+
+ Another way to control access is to use a channel key, but since this
+ key is sent in plaintext, it is vulnerable to traditional man in the
+ middle attacks.
+
+7.2 Channel Privacy
+
+ Because channel collisions are treated as inclusive events (See
+ Section 6.3), it is possible for users to join a channel overriding
+ its access control settings. This method has long been used by
+ individuals to "take over" channels by "illegitimately" gaining
+ channel operator status on the channel. The same method can be used
+ to find out the exact list of members of a channel, as well as to
+ eventually receive some of the messages sent to the channel.
+
+
+
+
+Kalt Informational [Page 16]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+7.3 Anonymity
+
+ The anonymous channel flag (See Section 4.2.1) can be used to render
+ all users on such channel "anonymous" by presenting all messages to
+ the channel as originating from a pseudo user which nickname is
+ "anonymous". This is done at the client-server level, and no
+ anonymity is provided at the server-server level.
+
+ It should be obvious to readers, that the level of anonymity offered
+ is quite poor and insecure, and that clients SHOULD display strong
+ warnings for users joining such channels.
+
+8. Current support and availability
+
+ Mailing lists for IRC related discussion:
+ General discussion: ircd-users@irc.org
+ Protocol development: ircd-dev@irc.org
+
+ Software implementations:
+ ftp://ftp.irc.org/irc/server
+ ftp://ftp.funet.fi/pub/unix/irc
+ ftp://coombs.anu.edu.au/pub/irc
+
+ Newsgroup: alt.irc
+
+9. Acknowledgements
+
+ Parts of this document were copied from the RFC 1459 [IRC] which
+ first formally documented the IRC Protocol. It has also benefited
+ from many rounds of review and comments. In particular, the
+ following people have made significant contributions to this
+ document:
+
+ Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
+ Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 17]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+10. References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
+ Protocol", RFC 1459, May 1993.
+
+ [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+ [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+ [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+11. Author's Address
+
+ Christophe Kalt
+ 99 Teaneck Rd, Apt #117
+ Ridgefield Park, NJ 07660
+ USA
+
+ EMail: kalt@stealth.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 18]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 19]
+
diff --git a/doc/rfc2812.txt b/doc/rfc2812.txt
new file mode 100644
index 0000000..7f1b162
--- /dev/null
+++ b/doc/rfc2812.txt
@@ -0,0 +1,3531 @@
+
+
+
+
+
+
+Network Working Group C. Kalt
+Request for Comments: 2812 April 2000
+Updates: 1459
+Category: Informational
+
+
+ Internet Relay Chat: Client Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+IESG NOTE:
+
+ The IRC protocol itself enables several possibilities of transferring
+ data between clients, and just like with other transfer mechanisms
+ like email, the receiver of the data has to be careful about how the
+ data is handled. For more information on security issues with the IRC
+ protocol, see for example http://www.irchelp.org/irchelp/security/.
+
+Abstract
+
+ The IRC (Internet Relay Chat) protocol is for use with text based
+ conferencing; the simplest client being any socket program capable of
+ connecting to the server.
+
+ This document defines the Client Protocol, and assumes that the
+ reader is familiar with the IRC Architecture [IRC-ARCH].
+
+Table of Contents
+
+ 1. Labels ..................................................... 3
+ 1.1 Servers ................................................ 3
+ 1.2 Clients ................................................ 3
+ 1.2.1 Users ............................................. 4
+ 1.2.1.1 Operators .................................... 4
+ 1.2.2 Services .......................................... 4
+ 1.3 Channels ............................................... 4
+ 2. The IRC Client Specification ............................... 5
+ 2.1 Overview ............................................... 5
+ 2.2 Character codes ........................................ 5
+ 2.3 Messages ............................................... 5
+
+
+
+Kalt Informational [Page 1]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 2.3.1 Message format in Augmented BNF ................... 6
+ 2.4 Numeric replies ........................................ 8
+ 2.5 Wildcard expressions ................................... 9
+ 3. Message Details ............................................ 9
+ 3.1 Connection Registration ................................ 10
+ 3.1.1 Password message .................................. 10
+ 3.1.2 Nick message ...................................... 10
+ 3.1.3 User message ...................................... 11
+ 3.1.4 Oper message ...................................... 12
+ 3.1.5 User mode message ................................. 12
+ 3.1.6 Service message ................................... 13
+ 3.1.7 Quit .............................................. 14
+ 3.1.8 Squit ............................................. 15
+ 3.2 Channel operations ..................................... 15
+ 3.2.1 Join message ...................................... 16
+ 3.2.2 Part message ...................................... 17
+ 3.2.3 Channel mode message .............................. 18
+ 3.2.4 Topic message ..................................... 19
+ 3.2.5 Names message ..................................... 20
+ 3.2.6 List message ...................................... 21
+ 3.2.7 Invite message .................................... 21
+ 3.2.8 Kick command ...................................... 22
+ 3.3 Sending messages ....................................... 23
+ 3.3.1 Private messages .................................. 23
+ 3.3.2 Notice ............................................ 24
+ 3.4 Server queries and commands ............................ 25
+ 3.4.1 Motd message ...................................... 25
+ 3.4.2 Lusers message .................................... 25
+ 3.4.3 Version message ................................... 26
+ 3.4.4 Stats message ..................................... 26
+ 3.4.5 Links message ..................................... 27
+ 3.4.6 Time message ...................................... 28
+ 3.4.7 Connect message ................................... 28
+ 3.4.8 Trace message ..................................... 29
+ 3.4.9 Admin command ..................................... 30
+ 3.4.10 Info command ...................................... 31
+ 3.5 Service Query and Commands ............................. 31
+ 3.5.1 Servlist message .................................. 31
+ 3.5.2 Squery ............................................ 32
+ 3.6 User based queries ..................................... 32
+ 3.6.1 Who query ......................................... 32
+ 3.6.2 Whois query ....................................... 33
+ 3.6.3 Whowas ............................................ 34
+ 3.7 Miscellaneous messages ................................. 34
+ 3.7.1 Kill message ...................................... 35
+ 3.7.2 Ping message ...................................... 36
+ 3.7.3 Pong message ...................................... 37
+ 3.7.4 Error ............................................. 37
+
+
+
+Kalt Informational [Page 2]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 4. Optional features .......................................... 38
+ 4.1 Away ................................................... 38
+ 4.2 Rehash message ......................................... 39
+ 4.3 Die message ............................................ 39
+ 4.4 Restart message ........................................ 40
+ 4.5 Summon message ......................................... 40
+ 4.6 Users .................................................. 41
+ 4.7 Operwall message ....................................... 41
+ 4.8 Userhost message ....................................... 42
+ 4.9 Ison message ........................................... 42
+ 5. Replies .................................................... 43
+ 5.1 Command responses ...................................... 43
+ 5.2 Error Replies .......................................... 53
+ 5.3 Reserved numerics ...................................... 59
+ 6. Current implementations .................................... 60
+ 7. Current problems ........................................... 60
+ 7.1 Nicknames .............................................. 60
+ 7.2 Limitation of wildcards ................................ 61
+ 7.3 Security considerations ................................ 61
+ 8. Current support and availability ........................... 61
+ 9. Acknowledgements ........................................... 61
+ 10. References ................................................ 62
+ 11. Author's Address .......................................... 62
+ 12. Full Copyright Statement .................................. 63
+
+1. Labels
+
+ This section defines the identifiers used for the various components
+ of the IRC protocol.
+
+1.1 Servers
+
+ Servers are uniquely identified by their name, which has a maximum
+ length of sixty three (63) characters. See the protocol grammar
+ rules (section 2.3.1) for what may and may not be used in a server
+ name.
+
+1.2 Clients
+
+ For each client all servers MUST have the following information: a
+ netwide unique identifier (whose format depends on the type of
+ client) and the server which introduced the client.
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 3]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+1.2.1 Users
+
+ Each user is distinguished from other users by a unique nickname
+ having a maximum length of nine (9) characters. See the protocol
+ grammar rules (section 2.3.1) for what may and may not be used in a
+ nickname.
+
+ While the maximum length is limited to nine characters, clients
+ SHOULD accept longer strings as they may become used in future
+ evolutions of the protocol.
+
+1.2.1.1 Operators
+
+ To allow a reasonable amount of order to be kept within the IRC
+ network, a special class of users (operators) is allowed to perform
+ general maintenance functions on the network. Although the powers
+ granted to an operator can be considered as 'dangerous', they are
+ nonetheless often necessary. Operators SHOULD be able to perform
+ basic network tasks such as disconnecting and reconnecting servers as
+ needed. In recognition of this need, the protocol discussed herein
+ provides for operators only to be able to perform such functions.
+ See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
+
+ A more controversial power of operators is the ability to remove a
+ user from the connected network by 'force', i.e., operators are able
+ to close the connection between any client and server. The
+ justification for this is very delicate since its abuse is both
+ destructive and annoying, and its benefits close to inexistent. For
+ further details on this type of action, see section 3.7.1 (KILL).
+
+1.2.2 Services
+
+ Each service is distinguished from other services by a service name
+ composed of a nickname and a server name. As for users, the nickname
+ has a maximum length of nine (9) characters. See the protocol
+ grammar rules (section 2.3.1) for what may and may not be used in a
+ nickname.
+
+1.3 Channels
+
+ Channels names are strings (beginning with a '&', '#', '+' or '!'
+ character) of length up to fifty (50) characters. Apart from the
+ requirement that the first character is either '&', '#', '+' or '!',
+ the only restriction on a channel name is that it SHALL NOT contain
+ any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space
+ is used as parameter separator and command is used as a list item
+ separator by the protocol). A colon (':') can also be used as a
+ delimiter for the channel mask. Channel names are case insensitive.
+
+
+
+Kalt Informational [Page 4]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ See the protocol grammar rules (section 2.3.1) for the exact syntax
+ of a channel name.
+
+ Each prefix characterizes a different channel type. The definition
+ of the channel types is not relevant to the client-server protocol
+ and thus it is beyond the scope of this document. More details can
+ be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+2. The IRC Client Specification
+
+2.1 Overview
+
+ The protocol as described herein is for use only with client to
+ server connections when the client registers as a user.
+
+2.2 Character codes
+
+ No specific character set is specified. The protocol is based on a
+ set of codes which are composed of eight (8) bits, making up an
+ octet. Each message may be composed of any number of these octets;
+ however, some octet values are used for control codes, which act as
+ message delimiters.
+
+ Regardless of being an 8-bit protocol, the delimiters and keywords
+ are such that protocol is mostly usable from US-ASCII terminal and a
+ telnet connection.
+
+ Because of IRC's Scandinavian origin, the characters {}|^ are
+ considered to be the lower case equivalents of the characters []\~,
+ respectively. This is a critical issue when determining the
+ equivalence of two nicknames or channel names.
+
+2.3 Messages
+
+ Servers and clients send each other messages, which may or may not
+ generate a reply. If the message contains a valid command, as
+ described in later sections, the client should expect a reply as
+ specified but it is not advised to wait forever for the reply; client
+ to server and server to server communication is essentially
+ asynchronous by nature.
+
+ Each IRC message may consist of up to three main parts: the prefix
+ (OPTIONAL), the command, and the command parameters (maximum of
+ fifteen (15)). The prefix, command, and all parameters are separated
+ by one ASCII space character (0x20) each.
+
+
+
+
+
+
+Kalt Informational [Page 5]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ The presence of a prefix is indicated with a single leading ASCII
+ colon character (':', 0x3b), which MUST be the first character of the
+ message itself. There MUST be NO gap (whitespace) between the colon
+ and the prefix. The prefix is used by servers to indicate the true
+ origin of the message. If the prefix is missing from the message, it
+ is assumed to have originated from the connection from which it was
+ received from. Clients SHOULD NOT use a prefix when sending a
+ message; if they use one, the only valid prefix is the registered
+ nickname associated with the client.
+
+ The command MUST either be a valid IRC command or a three (3) digit
+ number represented in ASCII text.
+
+ IRC messages are always lines of characters terminated with a CR-LF
+ (Carriage Return - Line Feed) pair, and these messages SHALL NOT
+ exceed 512 characters in length, counting all characters including
+ the trailing CR-LF. Thus, there are 510 characters maximum allowed
+ for the command and its parameters. There is no provision for
+ continuation of message lines. See section 6 for more details about
+ current implementations.
+
+2.3.1 Message format in Augmented BNF
+
+ The protocol messages must be extracted from the contiguous stream of
+ octets. The current solution is to designate two characters, CR and
+ LF, as message separators. Empty messages are silently ignored,
+ which permits use of the sequence CR-LF between messages without
+ extra problems.
+
+ The extracted message is parsed into the components <prefix>,
+ <command> and list of parameters (<params>).
+
+ The Augmented BNF representation for this is:
+
+ message = [ ":" prefix SPACE ] command [ params ] crlf
+ prefix = servername / ( nickname [ [ "!" user ] "@" host ] )
+ command = 1*letter / 3digit
+ params = *14( SPACE middle ) [ SPACE ":" trailing ]
+ =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
+
+ nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
+ ; any octet except NUL, CR, LF, " " and ":"
+ middle = nospcrlfcl *( ":" / nospcrlfcl )
+ trailing = *( ":" / " " / nospcrlfcl )
+
+ SPACE = %x20 ; space character
+ crlf = %x0D %x0A ; "carriage return" "linefeed"
+
+
+
+
+Kalt Informational [Page 6]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ NOTES:
+ 1) After extracting the parameter list, all parameters are equal
+ whether matched by <middle> or <trailing>. <trailing> is just a
+ syntactic trick to allow SPACE within the parameter.
+
+ 2) The NUL (%x00) character is not special in message framing, and
+ basically could end up inside a parameter, but it would cause
+ extra complexities in normal C string handling. Therefore, NUL
+ is not allowed within messages.
+
+ Most protocol messages specify additional semantics and syntax for
+ the extracted parameter strings dictated by their position in the
+ list. For example, many server commands will assume that the first
+ parameter after the command is the list of targets, which can be
+ described with:
+
+ target = nickname / server
+ msgtarget = msgto *( "," msgto )
+ msgto = channel / ( user [ "%" host ] "@" servername )
+ msgto =/ ( user "%" host ) / targetmask
+ msgto =/ nickname / ( nickname "!" user "@" host )
+ channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
+ [ ":" chanstring ]
+ servername = hostname
+ host = hostname / hostaddr
+ hostname = shortname *( "." shortname )
+ shortname = ( letter / digit ) *( letter / digit / "-" )
+ *( letter / digit )
+ ; as specified in RFC 1123 [HNAME]
+ hostaddr = ip4addr / ip6addr
+ ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
+ ip6addr = 1*hexdigit 7( ":" 1*hexdigit )
+ ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
+ nickname = ( letter / special ) *8( letter / digit / special / "-" )
+ targetmask = ( "$" / "#" ) mask
+ ; see details on allowed masks in section 3.3.1
+ chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
+ chanstring =/ %x2D-39 / %x3B-FF
+ ; any octet except NUL, BELL, CR, LF, " ", "," and ":"
+ channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 )
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 7]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Other parameter syntaxes are:
+
+ user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
+ ; any octet except NUL, CR, LF, " " and "@"
+ key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
+ ; any 7-bit US_ASCII character,
+ ; except NUL, CR, LF, FF, h/v TABs, and " "
+ letter = %x41-5A / %x61-7A ; A-Z / a-z
+ digit = %x30-39 ; 0-9
+ hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F"
+ special = %x5B-60 / %x7B-7D
+ ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
+
+ NOTES:
+ 1) The <hostaddr> syntax is given here for the sole purpose of
+ indicating the format to follow for IP addresses. This
+ reflects the fact that the only available implementations of
+ this protocol uses TCP/IP as underlying network protocol but is
+ not meant to prevent other protocols to be used.
+
+ 2) <hostname> has a maximum length of 63 characters. This is a
+ limitation of the protocol as internet hostnames (in
+ particular) can be longer. Such restriction is necessary
+ because IRC messages are limited to 512 characters in length.
+ Clients connecting from a host which name is longer than 63
+ characters are registered using the host (numeric) address
+ instead of the host name.
+
+ 3) Some parameters used in the following sections of this
+ documents are not defined here as there is nothing specific
+ about them besides the name that is used for convenience.
+ These parameters follow the general syntax defined for
+ <params>.
+
+2.4 Numeric replies
+
+ Most of the messages sent to the server generate a reply of some
+ sort. The most common reply is the numeric reply, used for both
+ errors and normal replies. The numeric reply MUST be sent as one
+ message consisting of the sender prefix, the three-digit numeric, and
+ the target of the reply. A numeric reply is not allowed to originate
+ from a client. In all other respects, a numeric reply is just like a
+ normal message, except that the keyword is made up of 3 numeric
+ digits rather than a string of letters. A list of different replies
+ is supplied in section 5 (Replies).
+
+
+
+
+
+
+Kalt Informational [Page 8]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+2.5 Wildcard expressions
+
+ When wildcards are allowed in a string, it is referred as a "mask".
+
+ For string matching purposes, the protocol allows the use of two
+ special characters: '?' (%x3F) to match one and only one character,
+ and '*' (%x2A) to match any number of any characters. These two
+ characters can be escaped using the character '\' (%x5C).
+
+ The Augmented BNF syntax for this is:
+
+ mask = *( nowild / noesc wildone / noesc wildmany )
+ wildone = %x3F
+ wildmany = %x2A
+ nowild = %x01-29 / %x2B-3E / %x40-FF
+ ; any octet except NUL, "*", "?"
+ noesc = %x01-5B / %x5D-FF
+ ; any octet except NUL and "\"
+ matchone = %x01-FF
+ ; matches wildone
+ matchmany = *matchone
+ ; matches wildmany
+
+ Examples:
+
+ a?c ; Matches any string of 3 characters in length starting
+ with "a" and ending with "c"
+
+ a*c ; Matches any string of at least 2 characters in length
+ starting with "a" and ending with "c"
+
+3. Message Details
+
+ On the following pages there are descriptions of each message
+ recognized by the IRC server and client. All commands described in
+ this section MUST be implemented by any server for this protocol.
+
+ Where the reply ERR_NOSUCHSERVER is returned, it means that the
+ target of the message could not be found. The server MUST NOT send
+ any other replies after this error for that command.
+
+ The server to which a client is connected is required to parse the
+ complete message, and return any appropriate errors.
+
+ If multiple parameters is presented, then each MUST be checked for
+ validity and appropriate responses MUST be sent back to the client.
+ In the case of incorrect messages which use parameter lists with
+ comma as an item separator, a reply MUST be sent for each item.
+
+
+
+Kalt Informational [Page 9]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.1 Connection Registration
+
+ The commands described here are used to register a connection with an
+ IRC server as a user as well as to correctly disconnect.
+
+ A "PASS" command is not required for a client connection to be
+ registered, but it MUST precede the latter of the NICK/USER
+ combination (for a user connection) or the SERVICE command (for a
+ service connection). The RECOMMENDED order for a client to register
+ is as follows:
+
+ 1. Pass message
+ 2. Nick message 2. Service message
+ 3. User message
+
+ Upon success, the client will receive an RPL_WELCOME (for users) or
+ RPL_YOURESERVICE (for services) message indicating that the
+ connection is now registered and known the to the entire IRC network.
+ The reply message MUST contain the full client identifier upon which
+ it was registered.
+
+3.1.1 Password message
+
+ Command: PASS
+ Parameters: <password>
+
+ The PASS command is used to set a 'connection password'. The
+ optional password can and MUST be set before any attempt to register
+ the connection is made. Currently this requires that user send a
+ PASS command before sending the NICK/USER combination.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Example:
+
+ PASS secretpasswordhere
+
+3.1.2 Nick message
+
+
+ Command: NICK
+ Parameters: <nickname>
+
+ NICK command is used to give user a nickname or change the existing
+ one.
+
+
+
+
+Kalt Informational [Page 10]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Numeric Replies:
+
+ ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
+ ERR_NICKNAMEINUSE ERR_NICKCOLLISION
+ ERR_UNAVAILRESOURCE ERR_RESTRICTED
+
+ Examples:
+
+ NICK Wiz ; Introducing new nick "Wiz" if session is
+ still unregistered, or user changing his
+ nickname to "Wiz"
+
+ :WiZ!jto@tolsun.oulu.fi NICK Kilroy
+ ; Server telling that WiZ changed his
+ nickname to Kilroy.
+
+3.1.3 User message
+
+ Command: USER
+ Parameters: <user> <mode> <unused> <realname>
+
+ The USER command is used at the beginning of connection to specify
+ the username, hostname and realname of a new user.
+
+ The <mode> parameter should be a numeric, and can be used to
+ automatically set user modes when registering with the server. This
+ parameter is a bitmask, with only 2 bits having any signification: if
+ the bit 2 is set, the user mode 'w' will be set and if the bit 3 is
+ set, the user mode 'i' will be set. (See Section 3.1.5 "User
+ Modes").
+
+ The <realname> may contain space characters.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Example:
+
+ USER guest 0 * :Ronnie Reagan ; User registering themselves with a
+ username of "guest" and real name
+ "Ronnie Reagan".
+
+ USER guest 8 * :Ronnie Reagan ; User registering themselves with a
+ username of "guest" and real name
+ "Ronnie Reagan", and asking to be set
+ invisible.
+
+
+
+
+Kalt Informational [Page 11]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.1.4 Oper message
+
+ Command: OPER
+ Parameters: <name> <password>
+
+ A normal user uses the OPER command to obtain operator privileges.
+ The combination of <name> and <password> are REQUIRED to gain
+ Operator privileges. Upon success, the user will receive a MODE
+ message (see section 3.1.5) indicating the new user modes.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS RPL_YOUREOPER
+ ERR_NOOPERHOST ERR_PASSWDMISMATCH
+
+ Example:
+
+ OPER foo bar ; Attempt to register as an operator
+ using a username of "foo" and "bar"
+ as the password.
+
+3.1.5 User mode message
+
+ Command: MODE
+ Parameters: <nickname>
+ *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
+
+ The user MODE's are typically changes which affect either how the
+ client is seen by others or what 'extra' messages the client is sent.
+
+ A user MODE command MUST only be accepted if both the sender of the
+ message and the nickname given as a parameter are both the same. If
+ no other parameter is given, then the server will return the current
+ settings for the nick.
+
+ The available modes are as follows:
+
+ a - user is flagged as away;
+ i - marks a users as invisible;
+ w - user receives wallops;
+ r - restricted user connection;
+ o - operator flag;
+ O - local operator flag;
+ s - marks a user for receipt of server notices.
+
+ Additional modes may be available later on.
+
+
+
+
+
+Kalt Informational [Page 12]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ The flag 'a' SHALL NOT be toggled by the user using the MODE command,
+ instead use of the AWAY command is REQUIRED.
+
+ If a user attempts to make themselves an operator using the "+o" or
+ "+O" flag, the attempt SHOULD be ignored as users could bypass the
+ authentication mechanisms of the OPER command. There is no
+ restriction, however, on anyone `deopping' themselves (using "-o" or
+ "-O").
+
+ On the other hand, if a user attempts to make themselves unrestricted
+ using the "-r" flag, the attempt SHOULD be ignored. There is no
+ restriction, however, on anyone `deopping' themselves (using "+r").
+ This flag is typically set by the server upon connection for
+ administrative reasons. While the restrictions imposed are left up
+ to the implementation, it is typical that a restricted user not be
+ allowed to change nicknames, nor make use of the channel operator
+ status on channels.
+
+ The flag 's' is obsolete but MAY still be used.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH
+ ERR_UMODEUNKNOWNFLAG RPL_UMODEIS
+
+ Examples:
+
+ MODE WiZ -w ; Command by WiZ to turn off
+ reception of WALLOPS messages.
+
+ MODE Angel +i ; Command from Angel to make herself
+ invisible.
+
+ MODE WiZ -o ; WiZ 'deopping' (removing operator
+ status).
+
+3.1.6 Service message
+
+ Command: SERVICE
+ Parameters: <nickname> <reserved> <distribution> <type>
+ <reserved> <info>
+
+ The SERVICE command to register a new service. Command parameters
+ specify the service nickname, distribution, type and info of a new
+ service.
+
+
+
+
+
+
+Kalt Informational [Page 13]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ The <distribution> parameter is used to specify the visibility of a
+ service. The service may only be known to servers which have a name
+ matching the distribution. For a matching server to have knowledge
+ of the service, the network path between that server and the server
+ on which the service is connected MUST be composed of servers which
+ names all match the mask.
+
+ The <type> parameter is currently reserved for future usage.
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
+ ERR_ERRONEUSNICKNAME
+ RPL_YOURESERVICE RPL_YOURHOST
+ RPL_MYINFO
+
+ Example:
+
+ SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
+ itself with a name of "dict". This
+ service will only be available on
+ servers which name matches "*.fr".
+
+3.1.7 Quit
+
+ Command: QUIT
+ Parameters: [ <Quit Message> ]
+
+ A client session is terminated with a quit message. The server
+ acknowledges this by sending an ERROR message to the client.
+
+ Numeric Replies:
+
+ None.
+
+ Example:
+
+ QUIT :Gone to have lunch ; Preferred message format.
+
+ :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
+ syrk has quit IRC to have lunch.
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 14]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.1.8 Squit
+
+ Command: SQUIT
+ Parameters: <server> <comment>
+
+ The SQUIT command is available only to operators. It is used to
+ disconnect server links. Also servers can generate SQUIT messages on
+ error conditions. A SQUIT message may also target a remote server
+ connection. In this case, the SQUIT message will simply be sent to
+ the remote server without affecting the servers in between the
+ operator and the remote server.
+
+ The <comment> SHOULD be supplied by all operators who execute a SQUIT
+ for a remote server. The server ordered to disconnect its peer
+ generates a WALLOPS message with <comment> included, so that other
+ users may be aware of the reason of this action.
+
+ Numeric replies:
+
+ ERR_NOPRIVILEGES ERR_NOSUCHSERVER
+ ERR_NEEDMOREPARAMS
+
+ Examples:
+
+ SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server
+ tolson.oulu.fi to terminate its
+ connection with comment "Bad Link".
+
+ :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
+ from Trillian from to disconnect
+ "cm22.eng.umd.edu" from the net with
+ comment "Server out of control".
+
+3.2 Channel operations
+
+ This group of messages is concerned with manipulating channels, their
+ properties (channel modes), and their contents (typically users).
+ For this reason, these messages SHALL NOT be made available to
+ services.
+
+ All of these messages are requests which will or will not be granted
+ by the server. The server MUST send a reply informing the user
+ whether the request was granted, denied or generated an error. When
+ the server grants the request, the message is typically sent back
+ (eventually reformatted) to the user with the prefix set to the user
+ itself.
+
+
+
+
+
+Kalt Informational [Page 15]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ The rules governing how channels are managed are enforced by the
+ servers. These rules are beyond the scope of this document. More
+ details are found in "Internet Relay Chat: Channel Management" [IRC-
+ CHAN].
+
+3.2.1 Join message
+
+ Command: JOIN
+ Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
+ / "0"
+
+ The JOIN command is used by a user to request to start listening to
+ the specific channel. Servers MUST be able to parse arguments in the
+ form of a list of target, but SHOULD NOT use lists when sending JOIN
+ messages to clients.
+
+ Once a user has joined a channel, he receives information about
+ all commands his server receives affecting the channel. This
+ includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
+ This allows channel members to keep track of the other channel
+ members, as well as channel modes.
+
+ If a JOIN is successful, the user receives a JOIN message as
+ confirmation and is then sent the channel's topic (using RPL_TOPIC) and
+ the list of users who are on the channel (using RPL_NAMREPLY), which
+ MUST include the user joining.
+
+ Note that this message accepts a special argument ("0"), which is
+ a special request to leave all channels the user is currently a member
+ of. The server will process this message as if the user had sent
+ a PART command (See Section 3.2.2) for each channel he is a member
+ of.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
+ ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
+ ERR_CHANNELISFULL ERR_BADCHANMASK
+ ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
+ ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
+ RPL_TOPIC
+
+ Examples:
+
+ JOIN #foobar ; Command to join channel #foobar.
+
+ JOIN &foo fubar ; Command to join channel &foo using
+ key "fubar".
+
+
+
+Kalt Informational [Page 16]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ JOIN #foo,&bar fubar ; Command to join channel #foo using
+ key "fubar" and &bar using no key.
+
+ JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using
+ key "fubar", and channel #bar using
+ key "foobar".
+
+ JOIN #foo,#bar ; Command to join channels #foo and
+ #bar.
+
+ JOIN 0 ; Leave all currently joined
+ channels.
+
+ :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
+ on channel #Twilight_zone
+
+3.2.2 Part message
+
+ Command: PART
+ Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
+
+ The PART command causes the user sending the message to be removed
+ from the list of active members for all given channels listed in the
+ parameter string. If a "Part Message" is given, this will be sent
+ instead of the default message, the nickname. This request is always
+ granted by the server.
+
+ Servers MUST be able to parse arguments in the form of a list of
+ target, but SHOULD NOT use lists when sending PART messages to
+ clients.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
+ ERR_NOTONCHANNEL
+
+ Examples:
+
+ PART #twilight_zone ; Command to leave channel
+ "#twilight_zone"
+
+ PART #oz-ops,&group5 ; Command to leave both channels
+ "&group5" and "#oz-ops".
+
+ :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
+ ; User WiZ leaving channel
+ "#playzone" with the message "I
+ lost".
+
+
+
+Kalt Informational [Page 17]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.2.3 Channel mode message
+
+ Command: MODE
+ Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
+
+ The MODE command is provided so that users may query and change the
+ characteristics of a channel. For more details on available modes
+ and their uses, see "Internet Relay Chat: Channel Management" [IRC-
+ CHAN]. Note that there is a maximum limit of three (3) changes per
+ command for modes that take a parameter.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_KEYSET
+ ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED
+ ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE
+ RPL_CHANNELMODEIS
+ RPL_BANLIST RPL_ENDOFBANLIST
+ RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST
+ RPL_INVITELIST RPL_ENDOFINVITELIST
+ RPL_UNIQOPIS
+
+ The following examples are given to help understanding the syntax of
+ the MODE command, but refer to modes defined in "Internet Relay Chat:
+ Channel Management" [IRC-CHAN].
+
+ Examples:
+
+ MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel
+ moderated and 'invite-only' with user
+ with a hostname matching *.fi
+ automatically invited.
+
+ MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges
+ to Kilroy on channel #Finnish.
+
+ MODE #Finnish +v Wiz ; Command to allow WiZ to speak on
+ #Finnish.
+
+ MODE #Fins -s ; Command to remove 'secret' flag
+ from channel #Fins.
+
+ MODE #42 +k oulu ; Command to set the channel key to
+ "oulu".
+
+ MODE #42 -k oulu ; Command to remove the "oulu"
+ channel key on channel "#42".
+
+
+
+
+Kalt Informational [Page 18]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ MODE #eu-opers +l 10 ; Command to set the limit for the
+ number of users on channel
+ "#eu-opers" to 10.
+
+ :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
+ ; User "WiZ" removing the limit for
+ the number of users on channel "#eu-
+ opers".
+
+ MODE &oulu +b ; Command to list ban masks set for
+ the channel "&oulu".
+
+ MODE &oulu +b *!*@* ; Command to prevent all users from
+ joining.
+
+ MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
+ ; Command to prevent any user from a
+ hostname matching *.edu from joining,
+ except if matching *.bu.edu
+
+ MODE #bu +be *!*@*.edu *!*@*.bu.edu
+ ; Comment to prevent any user from a
+ hostname matching *.edu from joining,
+ except if matching *.bu.edu
+
+ MODE #meditation e ; Command to list exception masks set
+ for the channel "#meditation".
+
+ MODE #meditation I ; Command to list invitations masks
+ set for the channel "#meditation".
+
+ MODE !12345ircd O ; Command to ask who the channel
+ creator for "!12345ircd" is
+
+3.2.4 Topic message
+
+ Command: TOPIC
+ Parameters: <channel> [ <topic> ]
+
+ The TOPIC command is used to change or view the topic of a channel.
+ The topic for channel <channel> is returned if there is no <topic>
+ given. If the <topic> parameter is present, the topic for that
+ channel will be changed, if this action is allowed for the user
+ requesting it. If the <topic> parameter is an empty string, the
+ topic for that channel will be removed.
+
+
+
+
+
+
+Kalt Informational [Page 19]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
+ RPL_NOTOPIC RPL_TOPIC
+ ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES
+
+ Examples:
+
+ :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
+ topic.
+
+ TOPIC #test :another topic ; Command to set the topic on #test
+ to "another topic".
+
+ TOPIC #test : ; Command to clear the topic on
+ #test.
+
+ TOPIC #test ; Command to check the topic for
+ #test.
+
+3.2.5 Names message
+
+ Command: NAMES
+ Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+ By using the NAMES command, a user can list all nicknames that are
+ visible to him. For more details on what is visible and what is not,
+ see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The
+ <channel> parameter specifies which channel(s) to return information
+ about. There is no error reply for bad channel names.
+
+ If no <channel> parameter is given, a list of all channels and their
+ occupants is returned. At the end of this list, a list of users who
+ are visible but either not on any channel or not on a visible channel
+ are listed as being on `channel' "*".
+
+ If the <target> parameter is specified, the request is forwarded to
+ that server which will generate the reply.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numerics:
+
+ ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
+ RPL_NAMREPLY RPL_ENDOFNAMES
+
+
+
+
+
+
+Kalt Informational [Page 20]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ NAMES #twilight_zone,#42 ; Command to list visible users on
+ #twilight_zone and #42
+
+ NAMES ; Command to list all visible
+ channels and users
+
+3.2.6 List message
+
+ Command: LIST
+ Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+ The list command is used to list channels and their topics. If the
+ <channel> parameter is used, only the status of that channel is
+ displayed.
+
+ If the <target> parameter is specified, the request is forwarded to
+ that server which will generate the reply.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
+ RPL_LIST RPL_LISTEND
+
+ Examples:
+
+ LIST ; Command to list all channels.
+
+ LIST #twilight_zone,#42 ; Command to list channels
+ #twilight_zone and #42
+
+3.2.7 Invite message
+
+ Command: INVITE
+ Parameters: <nickname> <channel>
+
+ The INVITE command is used to invite a user to a channel. The
+ parameter <nickname> is the nickname of the person to be invited to
+ the target channel <channel>. There is no requirement that the
+ channel the target user is being invited to must exist or be a valid
+ channel. However, if the channel exists, only members of the channel
+ are allowed to invite other users. When the channel has invite-only
+ flag set, only channel operators may issue INVITE command.
+
+
+
+
+
+Kalt Informational [Page 21]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Only the user inviting and the user being invited will receive
+ notification of the invitation. Other channel members are not
+ notified. (This is unlike the MODE changes, and is occasionally the
+ source of trouble for users.)
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
+ ERR_NOTONCHANNEL ERR_USERONCHANNEL
+ ERR_CHANOPRIVSNEEDED
+ RPL_INVITING RPL_AWAY
+
+ Examples:
+
+ :Angel!wings@irc.org INVITE Wiz #Dust
+
+ ; Message to WiZ when he has been
+ invited by user Angel to channel
+ #Dust
+
+ INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
+ #Twilight_zone
+
+3.2.8 Kick command
+
+ Command: KICK
+ Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
+ [<comment>]
+
+ The KICK command can be used to request the forced removal of a user
+ from a channel. It causes the <user> to PART from the <channel> by
+ force. For the message to be syntactically correct, there MUST be
+ either one channel parameter and multiple user parameter, or as many
+ channel parameters as there are user parameters. If a "comment" is
+ given, this will be sent instead of the default message, the nickname
+ of the user issuing the KICK.
+
+ The server MUST NOT send KICK messages with multiple channels or
+ users to clients. This is necessarily to maintain backward
+ compatibility with old client software.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
+ ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
+ ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL
+
+
+
+
+
+Kalt Informational [Page 22]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ KICK &Melbourne Matthew ; Command to kick Matthew from
+ &Melbourne
+
+ KICK #Finnish John :Speaking English
+ ; Command to kick John from #Finnish
+ using "Speaking English" as the
+ reason (comment).
+
+ :WiZ!jto@tolsun.oulu.fi KICK #Finnish John
+ ; KICK message on channel #Finnish
+ from WiZ to remove John from channel
+
+3.3 Sending messages
+
+ The main purpose of the IRC protocol is to provide a base for clients
+ to communicate with each other. PRIVMSG, NOTICE and SQUERY
+ (described in Section 3.5 on Service Query and Commands) are the only
+ messages available which actually perform delivery of a text message
+ from one client to another - the rest just make it possible and try
+ to ensure it happens in a reliable and structured manner.
+
+3.3.1 Private messages
+
+ Command: PRIVMSG
+ Parameters: <msgtarget> <text to be sent>
+
+ PRIVMSG is used to send private messages between users, as well as to
+ send messages to channels. <msgtarget> is usually the nickname of
+ the recipient of the message, or a channel name.
+
+ The <msgtarget> parameter may also be a host mask (#<mask>) or server
+ mask ($<mask>). In both cases the server will only send the PRIVMSG
+ to those who have a server or host matching the mask. The mask MUST
+ have at least 1 (one) "." in it and no wildcards following the last
+ ".". This requirement exists to prevent people sending messages to
+ "#*" or "$*", which would broadcast to all users. Wildcards are the
+ '*' and '?' characters. This extension to the PRIVMSG command is
+ only available to operators.
+
+ Numeric Replies:
+
+ ERR_NORECIPIENT ERR_NOTEXTTOSEND
+ ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
+ ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
+ ERR_NOSUCHNICK
+ RPL_AWAY
+
+
+
+Kalt Informational [Page 23]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
+ ; Message from Angel to Wiz.
+
+ PRIVMSG Angel :yes I'm receiving it !
+ ; Command to send a message to Angel.
+
+ PRIVMSG jto@tolsun.oulu.fi :Hello !
+ ; Command to send a message to a user
+ on server tolsun.oulu.fi with
+ username of "jto".
+
+ PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
+ ; Message to a user on server
+ irc.stealth.net with username of
+ "kalt", and connected from the host
+ millennium.stealth.net.
+
+ PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
+ ; Message to a user on the local
+ server with username of "kalt", and
+ connected from the host
+ millennium.stealth.net.
+
+ PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
+ ; Message to the user with nickname
+ Wiz who is connected from the host
+ tolsun.oulu.fi and has the username
+ "jto".
+
+ PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
+ ; Message to everyone on a server
+ which has a name matching *.fi.
+
+ PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
+ ; Message to all users who come from
+ a host which has a name matching
+ *.edu.
+
+3.3.2 Notice
+
+ Command: NOTICE
+ Parameters: <msgtarget> <text>
+
+ The NOTICE command is used similarly to PRIVMSG. The difference
+ between NOTICE and PRIVMSG is that automatic replies MUST NEVER be
+ sent in response to a NOTICE message. This rule applies to servers
+
+
+
+Kalt Informational [Page 24]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ too - they MUST NOT send any error reply back to the client on
+ receipt of a notice. The object of this rule is to avoid loops
+ between clients automatically sending something in response to
+ something it received.
+
+ This command is available to services as well as users.
+
+ This is typically used by services, and automatons (clients with
+ either an AI or other interactive program controlling their actions).
+
+ See PRIVMSG for more details on replies and examples.
+
+3.4 Server queries and commands
+
+ The server query group of commands has been designed to return
+ information about any server which is connected to the network.
+
+ In these queries, where a parameter appears as <target>, wildcard
+ masks are usually valid. For each parameter, however, only one query
+ and set of replies is to be generated. In most cases, if a nickname
+ is given, it will mean the server to which the user is connected.
+
+ These messages typically have little value for services, it is
+ therefore RECOMMENDED to forbid services from using them.
+
+3.4.1 Motd message
+
+ Command: MOTD
+ Parameters: [ <target> ]
+
+ The MOTD command is used to get the "Message Of The Day" of the given
+ server, or current server if <target> is omitted.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+ RPL_MOTDSTART RPL_MOTD
+ RPL_ENDOFMOTD ERR_NOMOTD
+
+3.4.2 Lusers message
+
+ Command: LUSERS
+ Parameters: [ <mask> [ <target> ] ]
+
+ The LUSERS command is used to get statistics about the size of the
+ IRC network. If no parameter is given, the reply will be about the
+ whole net. If a <mask> is specified, then the reply will only
+
+
+
+
+Kalt Informational [Page 25]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ concern the part of the network formed by the servers matching the
+ mask. Finally, if the <target> parameter is specified, the request
+ is forwarded to that server which will generate the reply.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ RPL_LUSERCLIENT RPL_LUSEROP
+ RPL_LUSERUNKOWN RPL_LUSERCHANNELS
+ RPL_LUSERME ERR_NOSUCHSERVER
+
+3.4.3 Version message
+
+ Command: VERSION
+ Parameters: [ <target> ]
+
+ The VERSION command is used to query the version of the server
+ program. An optional parameter <target> is used to query the version
+ of the server program which a client is not directly connected to.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER RPL_VERSION
+
+ Examples:
+
+ VERSION tolsun.oulu.fi ; Command to check the version of
+ server "tolsun.oulu.fi".
+
+3.4.4 Stats message
+
+ Command: STATS
+ Parameters: [ <query> [ <target> ] ]
+
+ The stats command is used to query statistics of certain server. If
+ <query> parameter is omitted, only the end of stats reply is sent
+ back.
+
+ A query may be given for any single letter which is only checked by
+ the destination server and is otherwise passed on by intermediate
+ servers, ignored and unaltered.
+
+ Wildcards are allowed in the <target> parameter.
+
+
+
+
+
+Kalt Informational [Page 26]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Except for the ones below, the list of valid queries is
+ implementation dependent. The standard queries below SHOULD be
+ supported by the server:
+
+ l - returns a list of the server's connections, showing how
+ long each connection has been established and the
+ traffic over that connection in Kbytes and messages for
+ each direction;
+ m - returns the usage count for each of commands supported
+ by the server; commands for which the usage count is
+ zero MAY be omitted;
+ o - returns a list of configured privileged users,
+ operators;
+ u - returns a string showing how long the server has been
+ up.
+
+ It is also RECOMMENDED that client and server access configuration be
+ published this way.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_STATSLINKINFO RPL_STATSUPTIME
+ RPL_STATSCOMMANDS RPL_STATSOLINE
+ RPL_ENDOFSTATS
+
+ Examples:
+
+ STATS m ; Command to check the command usage
+ for the server you are connected to
+
+3.4.5 Links message
+
+ Command: LINKS
+ Parameters: [ [ <remote server> ] <server mask> ]
+
+ With LINKS, a user can list all servernames, which are known by the
+ server answering the query. The returned list of servers MUST match
+ the mask, or if no mask is given, the full list is returned.
+
+ If <remote server> is given in addition to <server mask>, the LINKS
+ command is forwarded to the first server found that matches that name
+ (if any), and that server is then required to answer the query.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_LINKS RPL_ENDOFLINKS
+
+
+
+Kalt Informational [Page 27]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ LINKS *.au ; Command to list all servers which
+ have a name that matches *.au;
+
+ LINKS *.edu *.bu.edu ; Command to list servers matching
+ *.bu.edu as seen by the first server
+ matching *.edu.
+
+3.4.6 Time message
+
+ Command: TIME
+ Parameters: [ <target> ]
+
+ The time command is used to query local time from the specified
+ server. If the <target> parameter is not given, the server receiving
+ the command must reply to the query.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER RPL_TIME
+
+ Examples:
+ TIME tolsun.oulu.fi ; check the time on the server
+ "tolson.oulu.fi"
+
+3.4.7 Connect message
+
+ Command: CONNECT
+ Parameters: <target server> <port> [ <remote server> ]
+
+ The CONNECT command can be used to request a server to try to
+ establish a new connection to another server immediately. CONNECT is
+ a privileged command and SHOULD be available only to IRC Operators.
+ If a <remote server> is given and its mask doesn't match name of the
+ parsing server, the CONNECT attempt is sent to the first match of
+ remote server. Otherwise the CONNECT attempt is made by the server
+ processing the request.
+
+ The server receiving a remote CONNECT command SHOULD generate a
+ WALLOPS message describing the source and target of the request.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_NOPRIVILEGES
+ ERR_NEEDMOREPARAMS
+
+
+
+Kalt Informational [Page 28]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local
+ server to tolsun.oulu.fi on port 6667
+
+3.4.8 Trace message
+
+ Command: TRACE
+ Parameters: [ <target> ]
+
+ TRACE command is used to find the route to specific server and
+ information about its peers. Each server that processes this command
+ MUST report to the sender about it. The replies from pass-through
+ links form a chain, which shows route to destination. After sending
+ this reply back, the query MUST be sent to the next server until
+ given <target> server is reached.
+
+ TRACE command is used to find the route to specific server. Each
+ server that processes this message MUST tell the sender about it by
+ sending a reply indicating it is a pass-through link, forming a chain
+ of replies. After sending this reply back, it MUST then send the
+ TRACE message to the next server until given server is reached. If
+ the <target> parameter is omitted, it is RECOMMENDED that TRACE
+ command sends a message to the sender telling which servers the local
+ server has direct connection to.
+
+ If the destination given by <target> is an actual server, the
+ destination server is REQUIRED to report all servers, services and
+ operators which are connected to it; if the command was issued by an
+ operator, the server MAY also report all users which are connected to
+ it. If the destination given by <target> is a nickname, then only a
+ reply for that nickname is given. If the <target> parameter is
+ omitted, it is RECOMMENDED that the TRACE command is parsed as
+ targeted to the processing server.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+
+ If the TRACE message is destined for another server, all
+ intermediate servers must return a RPL_TRACELINK reply to indicate
+ that the TRACE passed through it and where it is going next.
+
+ RPL_TRACELINK
+
+
+
+
+
+Kalt Informational [Page 29]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ A TRACE reply may be composed of any number of the following
+ numeric replies.
+
+ RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
+ RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
+ RPL_TRACEUSER RPL_TRACESERVER
+ RPL_TRACESERVICE RPL_TRACENEWTYPE
+ RPL_TRACECLASS RPL_TRACELOG
+ RPL_TRACEEND
+
+ Examples:
+
+ TRACE *.oulu.fi ; TRACE to a server matching
+ *.oulu.fi
+
+3.4.9 Admin command
+
+ Command: ADMIN
+ Parameters: [ <target> ]
+
+ The admin command is used to find information about the administrator
+ of the given server, or current server if <target> parameter is
+ omitted. Each server MUST have the ability to forward ADMIN messages
+ to other servers.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_ADMINME RPL_ADMINLOC1
+ RPL_ADMINLOC2 RPL_ADMINEMAIL
+
+ Examples:
+
+ ADMIN tolsun.oulu.fi ; request an ADMIN reply from
+ tolsun.oulu.fi
+
+ ADMIN syrk ; ADMIN request for the server to
+ which the user syrk is connected
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 30]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.4.10 Info command
+
+ Command: INFO
+ Parameters: [ <target> ]
+
+ The INFO command is REQUIRED to return information describing the
+ server: its version, when it was compiled, the patchlevel, when it
+ was started, and any other miscellaneous information which may be
+ considered to be relevant.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_INFO RPL_ENDOFINFO
+
+ Examples:
+
+ INFO csd.bu.edu ; request an INFO reply from
+ csd.bu.edu
+
+ INFO Angel ; request info from the server that
+ Angel is connected to.
+
+3.5 Service Query and Commands
+
+ The service query group of commands has been designed to return
+ information about any service which is connected to the network.
+
+3.5.1 Servlist message
+
+ Command: SERVLIST
+ Parameters: [ <mask> [ <type> ] ]
+
+ The SERVLIST command is used to list services currently connected to
+ the network and visible to the user issuing the command. The
+ optional parameters may be used to restrict the result of the query
+ (to matching services names, and services type).
+
+ Numeric Replies:
+
+ RPL_SERVLIST RPL_SERVLISTEND
+
+
+
+
+
+
+
+
+Kalt Informational [Page 31]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.5.2 Squery
+
+ Command: SQUERY
+ Parameters: <servicename> <text>
+
+ The SQUERY command is used similarly to PRIVMSG. The only difference
+ is that the recipient MUST be a service. This is the only way for a
+ text message to be delivered to a service.
+
+ See PRIVMSG for more details on replies and example.
+
+ Examples:
+
+ SQUERY irchelp :HELP privmsg
+ ; Message to the service with
+ nickname irchelp.
+
+ SQUERY dict@irc.fr :fr2en blaireau
+ ; Message to the service with name
+ dict@irc.fr.
+
+3.6 User based queries
+
+ User queries are a group of commands which are primarily concerned
+ with finding details on a particular user or group users. When using
+ wildcards with any of these commands, if they match, they will only
+ return information on users who are 'visible' to you. The visibility
+ of a user is determined as a combination of the user's mode and the
+ common set of channels you are both on.
+
+ Although services SHOULD NOT be using this class of message, they are
+ allowed to.
+
+3.6.1 Who query
+
+ Command: WHO
+ Parameters: [ <mask> [ "o" ] ]
+
+ The WHO command is used by a client to generate a query which returns
+ a list of information which 'matches' the <mask> parameter given by
+ the client. In the absence of the <mask> parameter, all visible
+ (users who aren't invisible (user mode +i) and who don't have a
+ common channel with the requesting client) are listed. The same
+ result can be achieved by using a <mask> of "0" or any wildcard which
+ will end up matching every visible user.
+
+ The <mask> passed to WHO is matched against users' host, server, real
+ name and nickname if the channel <mask> cannot be found.
+
+
+
+Kalt Informational [Page 32]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ If the "o" parameter is passed only operators are returned according
+ to the <mask> supplied.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_WHOREPLY RPL_ENDOFWHO
+
+ Examples:
+
+ WHO *.fi ; Command to list all users who match
+ against "*.fi".
+
+ WHO jto* o ; Command to list all users with a
+ match against "jto*" if they are an
+ operator.
+
+3.6.2 Whois query
+
+ Command: WHOIS
+ Parameters: [ <target> ] <mask> *( "," <mask> )
+
+ This command is used to query information about particular user.
+ The server will answer this command with several numeric messages
+ indicating different statuses of each user which matches the mask (if
+ you are entitled to see them). If no wildcard is present in the
+ <mask>, any information about that nick which you are allowed to see
+ is presented.
+
+ If the <target> parameter is specified, it sends the query to a
+ specific server. It is useful if you want to know how long the user
+ in question has been idle as only local server (i.e., the server the
+ user is directly connected to) knows that information, while
+ everything else is globally known.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
+ RPL_WHOISUSER RPL_WHOISCHANNELS
+ RPL_WHOISCHANNELS RPL_WHOISSERVER
+ RPL_AWAY RPL_WHOISOPERATOR
+ RPL_WHOISIDLE ERR_NOSUCHNICK
+ RPL_ENDOFWHOIS
+
+
+
+
+
+
+Kalt Informational [Page 33]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ WHOIS wiz ; return available user information
+ about nick WiZ
+
+ WHOIS eff.org trillian ; ask server eff.org for user
+ information about trillian
+
+3.6.3 Whowas
+
+ Command: WHOWAS
+ Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
+
+ Whowas asks for information about a nickname which no longer exists.
+ This may either be due to a nickname change or the user leaving IRC.
+ In response to this query, the server searches through its nickname
+ history, looking for any nicks which are lexically the same (no wild
+ card matching here). The history is searched backward, returning the
+ most recent entry first. If there are multiple entries, up to
+ <count> replies will be returned (or all of them if no <count>
+ parameter is given). If a non-positive number is passed as being
+ <count>, then a full search is done.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
+ RPL_WHOWASUSER RPL_WHOISSERVER
+ RPL_ENDOFWHOWAS
+
+ Examples:
+
+ WHOWAS Wiz ; return all information in the nick
+ history about nick "WiZ";
+
+ WHOWAS Mermaid 9 ; return at most, the 9 most recent
+ entries in the nick history for
+ "Mermaid";
+
+ WHOWAS Trillian 1 *.edu ; return the most recent history for
+ "Trillian" from the first server
+ found to match "*.edu".
+
+3.7 Miscellaneous messages
+
+ Messages in this category do not fit into any of the above categories
+ but are nonetheless still a part of and REQUIRED by the protocol.
+
+
+
+Kalt Informational [Page 34]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.7.1 Kill message
+
+ Command: KILL
+ Parameters: <nickname> <comment>
+
+ The KILL command is used to cause a client-server connection to be
+ closed by the server which has the actual connection. Servers
+ generate KILL messages on nickname collisions. It MAY also be
+ available available to users who have the operator status.
+
+ Clients which have automatic reconnect algorithms effectively make
+ this command useless since the disconnection is only brief. It does
+ however break the flow of data and can be used to stop large amounts
+ of 'flooding' from abusive users or accidents. Abusive users usually
+ don't care as they will reconnect promptly and resume their abusive
+ behaviour. To prevent this command from being abused, any user may
+ elect to receive KILL messages generated for others to keep an 'eye'
+ on would be trouble spots.
+
+ In an arena where nicknames are REQUIRED to be globally unique at all
+ times, KILL messages are sent whenever 'duplicates' are detected
+ (that is an attempt to register two users with the same nickname) in
+ the hope that both of them will disappear and only 1 reappear.
+
+ When a client is removed as the result of a KILL message, the server
+ SHOULD add the nickname to the list of unavailable nicknames in an
+ attempt to avoid clients to reuse this name immediately which is
+ usually the pattern of abusive behaviour often leading to useless
+ "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER]
+ for more information on this procedure.
+
+ The comment given MUST reflect the actual reason for the KILL. For
+ server-generated KILLs it usually is made up of details concerning
+ the origins of the two conflicting nicknames. For users it is left
+ up to them to provide an adequate reason to satisfy others who see
+ it. To prevent/discourage fake KILLs from being generated to hide
+ the identify of the KILLer, the comment also shows a 'kill-path'
+ which is updated by each server it passes through, each prepending
+ its name to the path.
+
+ Numeric Replies:
+
+ ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
+ ERR_NOSUCHNICK ERR_CANTKILLSERVER
+
+
+
+
+
+
+
+Kalt Informational [Page 35]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ NOTE:
+ It is RECOMMENDED that only Operators be allowed to kill other users
+ with KILL command. This command has been the subject of many
+ controversies over the years, and along with the above
+ recommendation, it is also widely recognized that not even operators
+ should be allowed to kill users on remote servers.
+
+3.7.2 Ping message
+
+ Command: PING
+ Parameters: <server1> [ <server2> ]
+
+ The PING command is used to test the presence of an active client or
+ server at the other end of the connection. Servers send a PING
+ message at regular intervals if no other activity detected coming
+ from a connection. If a connection fails to respond to a PING
+ message within a set amount of time, that connection is closed. A
+ PING message MAY be sent even if the connection is active.
+
+ When a PING message is received, the appropriate PONG message MUST be
+ sent as reply to <server1> (server which sent the PING message out)
+ as soon as possible. If the <server2> parameter is specified, it
+ represents the target of the ping, and the message gets forwarded
+ there.
+
+ Numeric Replies:
+
+ ERR_NOORIGIN ERR_NOSUCHSERVER
+
+ Examples:
+
+ PING tolsun.oulu.fi ; Command to send a PING message to
+ server
+
+ PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING
+ message to server "tolsun.oulu.fi"
+
+ PING :irc.funet.fi ; Ping message sent by server
+ "irc.funet.fi"
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 36]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+3.7.3 Pong message
+
+ Command: PONG
+ Parameters: <server> [ <server2> ]
+
+ PONG message is a reply to ping message. If parameter <server2> is
+ given, this message MUST be forwarded to given target. The <server>
+ parameter is the name of the entity who has responded to PING message
+ and generated this message.
+
+ Numeric Replies:
+
+ ERR_NOORIGIN ERR_NOSUCHSERVER
+
+ Example:
+
+ PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
+ tolsun.oulu.fi
+
+3.7.4 Error
+
+ Command: ERROR
+ Parameters: <error message>
+
+ The ERROR command is for use by servers when reporting a serious or
+ fatal error to its peers. It may also be sent from one server to
+ another but MUST NOT be accepted from any normal unknown clients.
+
+ Only an ERROR message SHOULD be used for reporting errors which occur
+ with a server-to-server link. An ERROR message is sent to the server
+ at the other end (which reports it to appropriate local users and
+ logs) and to appropriate local users and logs. It is not to be
+ passed onto any other servers by a server if it is received from a
+ server.
+
+ The ERROR message is also used before terminating a client
+ connection.
+
+ When a server sends a received ERROR message to its operators, the
+ message SHOULD be encapsulated inside a NOTICE message, indicating
+ that the client was not responsible for the error.
+
+ Numerics:
+
+ None.
+
+
+
+
+
+
+Kalt Informational [Page 37]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ ERROR :Server *.fi already exists ; ERROR message to the other server
+ which caused this error.
+
+ NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
+ ; Same ERROR message as above but
+ sent to user WiZ on the other server.
+
+4. Optional features
+
+ This section describes OPTIONAL messages. They are not required in a
+ working server implementation of the protocol described herein. In
+ the absence of the feature, an error reply message MUST be generated
+ or an unknown command error. If the message is destined for another
+ server to answer then it MUST be passed on (elementary parsing
+ REQUIRED) The allocated numerics for this are listed with the
+ messages below.
+
+ From this section, only the USERHOST and ISON messages are available
+ to services.
+
+4.1 Away
+
+ Command: AWAY
+ Parameters: [ <text> ]
+
+ With the AWAY command, clients can set an automatic reply string for
+ any PRIVMSG commands directed at them (not to a channel they are on).
+ The server sends an automatic reply to the client sending the PRIVMSG
+ command. The only replying server is the one to which the sending
+ client is connected to.
+
+ The AWAY command is used either with one parameter, to set an AWAY
+ message, or with no parameters, to remove the AWAY message.
+
+ Because of its high cost (memory and bandwidth wise), the AWAY
+ message SHOULD only be used for client-server communication. A
+ server MAY choose to silently ignore AWAY messages received from
+ other servers. To update the away status of a client across servers,
+ the user mode 'a' SHOULD be used instead. (See Section 3.1.5)
+
+ Numeric Replies:
+
+ RPL_UNAWAY RPL_NOWAWAY
+
+
+
+
+
+
+Kalt Informational [Page 38]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Example:
+
+ AWAY :Gone to lunch. Back in 5 ; Command to set away message to
+ "Gone to lunch. Back in 5".
+
+4.2 Rehash message
+
+ Command: REHASH
+ Parameters: None
+
+ The rehash command is an administrative command which can be used by
+ an operator to force the server to re-read and process its
+ configuration file.
+
+ Numeric Replies:
+
+ RPL_REHASHING ERR_NOPRIVILEGES
+
+
+ Example:
+
+ REHASH ; message from user with operator
+ status to server asking it to reread
+ its configuration file.
+
+4.3 Die message
+
+ Command: DIE
+ Parameters: None
+
+ An operator can use the DIE command to shutdown the server. This
+ message is optional since it may be viewed as a risk to allow
+ arbitrary people to connect to a server as an operator and execute
+ this command.
+
+ The DIE command MUST always be fully processed by the server to which
+ the sending client is connected and MUST NOT be passed onto other
+ connected servers.
+
+ Numeric Replies:
+
+ ERR_NOPRIVILEGES
+
+ Example:
+
+ DIE ; no parameters required.
+
+
+
+
+
+Kalt Informational [Page 39]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+4.4 Restart message
+
+ Command: RESTART
+ Parameters: None
+
+ An operator can use the restart command to force the server to
+ restart itself. This message is optional since it may be viewed as a
+ risk to allow arbitrary people to connect to a server as an operator
+ and execute this command, causing (at least) a disruption to service.
+
+ The RESTART command MUST always be fully processed by the server to
+ which the sending client is connected and MUST NOT be passed onto
+ other connected servers.
+
+ Numeric Replies:
+
+ ERR_NOPRIVILEGES
+
+ Example:
+
+ RESTART ; no parameters required.
+
+4.5 Summon message
+
+ Command: SUMMON
+ Parameters: <user> [ <target> [ <channel> ] ]
+
+ The SUMMON command can be used to give users who are on a host
+ running an IRC server a message asking them to please join IRC. This
+ message is only sent if the target server (a) has SUMMON enabled, (b)
+ the user is logged in and (c) the server process can write to the
+ user's tty (or similar).
+
+ If no <server> parameter is given it tries to summon <user> from the
+ server the client is connected to is assumed as the target.
+
+ If summon is not enabled in a server, it MUST return the
+ ERR_SUMMONDISABLED numeric.
+
+ Numeric Replies:
+
+ ERR_NORECIPIENT ERR_FILEERROR
+ ERR_NOLOGIN ERR_NOSUCHSERVER
+ ERR_SUMMONDISABLED RPL_SUMMONING
+
+
+
+
+
+
+
+Kalt Informational [Page 40]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ Examples:
+
+ SUMMON jto ; summon user jto on the server's
+ host
+
+ SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
+ server named "tolsun.oulu.fi" is
+ running.
+
+4.6 Users
+
+ Command: USERS
+ Parameters: [ <target> ]
+
+ The USERS command returns a list of users logged into the server in a
+ format similar to the UNIX commands who(1), rusers(1) and finger(1).
+ If disabled, the correct numeric MUST be returned to indicate this.
+
+ Because of the security implications of such a command, it SHOULD be
+ disabled by default in server implementations. Enabling it SHOULD
+ require recompiling the server or some equivalent change rather than
+ simply toggling an option and restarting the server. The procedure
+ to enable this command SHOULD also include suitable large comments.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_FILEERROR
+ RPL_USERSSTART RPL_USERS
+ RPL_NOUSERS RPL_ENDOFUSERS
+ ERR_USERSDISABLED
+
+ Disabled Reply:
+
+ ERR_USERSDISABLED
+
+ Example:
+
+ USERS eff.org ; request a list of users logged in
+ on server eff.org
+
+4.7 Operwall message
+
+ Command: WALLOPS
+ Parameters: <Text to be sent>
+
+ The WALLOPS command is used to send a message to all currently
+ connected users who have set the 'w' user mode for themselves. (See
+ Section 3.1.5 "User modes").
+
+
+
+Kalt Informational [Page 41]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ After implementing WALLOPS as a user command it was found that it was
+ often and commonly abused as a means of sending a message to a lot of
+ people. Due to this, it is RECOMMENDED that the implementation of
+ WALLOPS allows and recognizes only servers as the originators of
+ WALLOPS.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS
+
+ Example:
+
+ :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
+ message from csd.bu.edu announcing a
+ CONNECT message it received from
+ Joshua and acted upon.
+
+4.8 Userhost message
+
+ Command: USERHOST
+ Parameters: <nickname> *( SPACE <nickname> )
+
+ The USERHOST command takes a list of up to 5 nicknames, each
+ separated by a space character and returns a list of information
+ about each nickname that it found. The returned list has each reply
+ separated by a space.
+
+ Numeric Replies:
+
+ RPL_USERHOST ERR_NEEDMOREPARAMS
+
+ Example:
+
+ USERHOST Wiz Michael syrk ; USERHOST request for information on
+ nicks "Wiz", "Michael", and "syrk"
+
+ :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
+ ; Reply for user syrk
+
+4.9 Ison message
+
+ Command: ISON
+ Parameters: <nickname> *( SPACE <nickname> )
+
+ The ISON command was implemented to provide a quick and efficient
+ means to get a response about whether a given nickname was currently
+ on IRC. ISON only takes one (1) type of parameter: a space-separated
+ list of nicks. For each nickname in the list that is present, the
+
+
+
+Kalt Informational [Page 42]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ server adds that to its reply string. Thus the reply string may
+ return empty (none of the given nicks are present), an exact copy of
+ the parameter string (all of them present) or any other subset of the
+ set of nicks given in the parameter. The only limit on the number of
+ nicks that may be checked is that the combined length MUST NOT be too
+ large as to cause the server to chop it off so it fits in 512
+ characters.
+
+ ISON is only processed by the server local to the client sending the
+ command and thus not passed onto other servers for further
+ processing.
+
+ Numeric Replies:
+
+ RPL_ISON ERR_NEEDMOREPARAMS
+
+ Example:
+
+ ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
+ ; Sample ISON request for 7 nicks.
+
+5. Replies
+
+ The following is a list of numeric replies which are generated in
+ response to the commands given above. Each numeric is given with its
+ number, name and reply string.
+
+5.1 Command responses
+
+ Numerics in the range from 001 to 099 are used for client-server
+ connections only and should never travel between servers. Replies
+ generated in the response to commands are found in the range from 200
+ to 399.
+
+ 001 RPL_WELCOME
+ "Welcome to the Internet Relay Network
+ <nick>!<user>@<host>"
+ 002 RPL_YOURHOST
+ "Your host is <servername>, running version <ver>"
+ 003 RPL_CREATED
+ "This server was created <date>"
+ 004 RPL_MYINFO
+ "<servername> <version> <available user modes>
+ <available channel modes>"
+
+ - The server sends Replies 001 to 004 to a user upon
+ successful registration.
+
+
+
+
+Kalt Informational [Page 43]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 005 RPL_BOUNCE
+ "Try server <server name>, port <port number>"
+
+ - Sent by the server to a user to suggest an alternative
+ server. This is often used when the connection is
+ refused because the server is already full.
+
+ 302 RPL_USERHOST
+ ":*1<reply> *( " " <reply> )"
+
+ - Reply format used by USERHOST to list replies to
+ the query list. The reply string is composed as
+ follows:
+
+ reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname
+
+ The '*' indicates whether the client has registered
+ as an Operator. The '-' or '+' characters represent
+ whether the client has set an AWAY message or not
+ respectively.
+
+ 303 RPL_ISON
+ ":*1<nick> *( " " <nick> )"
+
+ - Reply format used by ISON to list replies to the
+ query list.
+
+ 301 RPL_AWAY
+ "<nick> :<away message>"
+ 305 RPL_UNAWAY
+ ":You are no longer marked as being away"
+ 306 RPL_NOWAWAY
+ ":You have been marked as being away"
+
+ - These replies are used with the AWAY command (if
+ allowed). RPL_AWAY is sent to any client sending a
+ PRIVMSG to a client which is away. RPL_AWAY is only
+ sent by the server to which the client is connected.
+ Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
+ client removes and sets an AWAY message.
+
+ 311 RPL_WHOISUSER
+ "<nick> <user> <host> * :<real name>"
+ 312 RPL_WHOISSERVER
+ "<nick> <server> :<server info>"
+ 313 RPL_WHOISOPERATOR
+ "<nick> :is an IRC operator"
+
+
+
+
+Kalt Informational [Page 44]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 317 RPL_WHOISIDLE
+ "<nick> <integer> :seconds idle"
+ 318 RPL_ENDOFWHOIS
+ "<nick> :End of WHOIS list"
+ 319 RPL_WHOISCHANNELS
+ "<nick> :*( ( "@" / "+" ) <channel> " " )"
+
+ - Replies 311 - 313, 317 - 319 are all replies
+ generated in response to a WHOIS message. Given that
+ there are enough parameters present, the answering
+ server MUST either formulate a reply out of the above
+ numerics (if the query nick is found) or return an
+ error reply. The '*' in RPL_WHOISUSER is there as
+ the literal character and not as a wild card. For
+ each reply set, only RPL_WHOISCHANNELS may appear
+ more than once (for long lists of channel names).
+ The '@' and '+' characters next to the channel name
+ indicate whether a client is a channel operator or
+ has been granted permission to speak on a moderated
+ channel. The RPL_ENDOFWHOIS reply is used to mark
+ the end of processing a WHOIS message.
+
+ 314 RPL_WHOWASUSER
+ "<nick> <user> <host> * :<real name>"
+ 369 RPL_ENDOFWHOWAS
+ "<nick> :End of WHOWAS"
+
+ - When replying to a WHOWAS message, a server MUST use
+ the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
+ ERR_WASNOSUCHNICK for each nickname in the presented
+ list. At the end of all reply batches, there MUST
+ be RPL_ENDOFWHOWAS (even if there was only one reply
+ and it was an error).
+
+ 321 RPL_LISTSTART
+ Obsolete. Not used.
+
+ 322 RPL_LIST
+ "<channel> <# visible> :<topic>"
+ 323 RPL_LISTEND
+ ":End of LIST"
+
+ - Replies RPL_LIST, RPL_LISTEND mark the actual replies
+ with data and end of the server's response to a LIST
+ command. If there are no channels available to return,
+ only the end reply MUST be sent.
+
+
+
+
+
+Kalt Informational [Page 45]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 325 RPL_UNIQOPIS
+ "<channel> <nickname>"
+
+ 324 RPL_CHANNELMODEIS
+ "<channel> <mode> <mode params>"
+
+ 331 RPL_NOTOPIC
+ "<channel> :No topic is set"
+ 332 RPL_TOPIC
+ "<channel> :<topic>"
+
+ - When sending a TOPIC message to determine the
+ channel topic, one of two replies is sent. If
+ the topic is set, RPL_TOPIC is sent back else
+ RPL_NOTOPIC.
+
+ 341 RPL_INVITING
+ "<channel> <nick>"
+
+ - Returned by the server to indicate that the
+ attempted INVITE message was successful and is
+ being passed onto the end client.
+
+ 342 RPL_SUMMONING
+ "<user> :Summoning user to IRC"
+
+ - Returned by a server answering a SUMMON message to
+ indicate that it is summoning that user.
+
+ 346 RPL_INVITELIST
+ "<channel> <invitemask>"
+ 347 RPL_ENDOFINVITELIST
+ "<channel> :End of channel invite list"
+
+ - When listing the 'invitations masks' for a given channel,
+ a server is required to send the list back using the
+ RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A
+ separate RPL_INVITELIST is sent for each active mask.
+ After the masks have been listed (or if none present) a
+ RPL_ENDOFINVITELIST MUST be sent.
+
+ 348 RPL_EXCEPTLIST
+ "<channel> <exceptionmask>"
+ 349 RPL_ENDOFEXCEPTLIST
+ "<channel> :End of channel exception list"
+
+
+
+
+
+
+Kalt Informational [Page 46]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ - When listing the 'exception masks' for a given channel,
+ a server is required to send the list back using the
+ RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A
+ separate RPL_EXCEPTLIST is sent for each active mask.
+ After the masks have been listed (or if none present)
+ a RPL_ENDOFEXCEPTLIST MUST be sent.
+
+ 351 RPL_VERSION
+ "<version>.<debuglevel> <server> :<comments>"
+
+ - Reply by the server showing its version details.
+ The <version> is the version of the software being
+ used (including any patchlevel revisions) and the
+ <debuglevel> is used to indicate if the server is
+ running in "debug mode".
+
+ The "comments" field may contain any comments about
+ the version or further version details.
+
+ 352 RPL_WHOREPLY
+ "<channel> <user> <host> <server> <nick>
+ ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
+ :<hopcount> <real name>"
+
+ 315 RPL_ENDOFWHO
+ "<name> :End of WHO list"
+
+ - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
+ to answer a WHO message. The RPL_WHOREPLY is only
+ sent if there is an appropriate match to the WHO
+ query. If there is a list of parameters supplied
+ with a WHO message, a RPL_ENDOFWHO MUST be sent
+ after processing each list item with <name> being
+ the item.
+
+ 353 RPL_NAMREPLY
+ "( "=" / "*" / "@" ) <channel>
+ :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
+ - "@" is used for secret channels, "*" for private
+ channels, and "=" for others (public channels).
+
+ 366 RPL_ENDOFNAMES
+ "<channel> :End of NAMES list"
+
+ - To reply to a NAMES message, a reply pair consisting
+ of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
+ server back to the client. If there is no channel
+ found as in the query, then only RPL_ENDOFNAMES is
+
+
+
+Kalt Informational [Page 47]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ returned. The exception to this is when a NAMES
+ message is sent with no parameters and all visible
+ channels and contents are sent back in a series of
+ RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
+ the end.
+
+ 364 RPL_LINKS
+ "<mask> <server> :<hopcount> <server info>"
+ 365 RPL_ENDOFLINKS
+ "<mask> :End of LINKS list"
+
+ - In replying to the LINKS message, a server MUST send
+ replies back using the RPL_LINKS numeric and mark the
+ end of the list using an RPL_ENDOFLINKS reply.
+
+ 367 RPL_BANLIST
+ "<channel> <banmask>"
+ 368 RPL_ENDOFBANLIST
+ "<channel> :End of channel ban list"
+
+ - When listing the active 'bans' for a given channel,
+ a server is required to send the list back using the
+ RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
+ RPL_BANLIST is sent for each active banmask. After the
+ banmasks have been listed (or if none present) a
+ RPL_ENDOFBANLIST MUST be sent.
+
+ 371 RPL_INFO
+ ":<string>"
+ 374 RPL_ENDOFINFO
+ ":End of INFO list"
+
+ - A server responding to an INFO message is required to
+ send all its 'info' in a series of RPL_INFO messages
+ with a RPL_ENDOFINFO reply to indicate the end of the
+ replies.
+
+ 375 RPL_MOTDSTART
+ ":- <server> Message of the day - "
+ 372 RPL_MOTD
+ ":- <text>"
+ 376 RPL_ENDOFMOTD
+ ":End of MOTD command"
+
+ - When responding to the MOTD message and the MOTD file
+ is found, the file is displayed line by line, with
+ each line no longer than 80 characters, using
+
+
+
+
+Kalt Informational [Page 48]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ RPL_MOTD format replies. These MUST be surrounded
+ by a RPL_MOTDSTART (before the RPL_MOTDs) and an
+ RPL_ENDOFMOTD (after).
+
+ 381 RPL_YOUREOPER
+ ":You are now an IRC operator"
+
+ - RPL_YOUREOPER is sent back to a client which has
+ just successfully issued an OPER message and gained
+ operator status.
+
+ 382 RPL_REHASHING
+ "<config file> :Rehashing"
+
+ - If the REHASH option is used and an operator sends
+ a REHASH message, an RPL_REHASHING is sent back to
+ the operator.
+
+ 383 RPL_YOURESERVICE
+ "You are service <servicename>"
+
+ - Sent by the server to a service upon successful
+ registration.
+
+ 391 RPL_TIME
+ "<server> :<string showing server's local time>"
+
+ - When replying to the TIME message, a server MUST send
+ the reply using the RPL_TIME format above. The string
+ showing the time need only contain the correct day and
+ time there. There is no further requirement for the
+ time string.
+
+ 392 RPL_USERSSTART
+ ":UserID Terminal Host"
+ 393 RPL_USERS
+ ":<username> <ttyline> <hostname>"
+ 394 RPL_ENDOFUSERS
+ ":End of users"
+ 395 RPL_NOUSERS
+ ":Nobody logged in"
+
+ - If the USERS message is handled by a server, the
+ replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
+ RPL_NOUSERS are used. RPL_USERSSTART MUST be sent
+ first, following by either a sequence of RPL_USERS
+ or a single RPL_NOUSER. Following this is
+ RPL_ENDOFUSERS.
+
+
+
+Kalt Informational [Page 49]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 200 RPL_TRACELINK
+ "Link <version & debug level> <destination>
+ <next server> V<protocol version>
+ <link uptime in seconds> <backstream sendq>
+ <upstream sendq>"
+ 201 RPL_TRACECONNECTING
+ "Try. <class> <server>"
+ 202 RPL_TRACEHANDSHAKE
+ "H.S. <class> <server>"
+ 203 RPL_TRACEUNKNOWN
+ "???? <class> [<client IP address in dot form>]"
+ 204 RPL_TRACEOPERATOR
+ "Oper <class> <nick>"
+ 205 RPL_TRACEUSER
+ "User <class> <nick>"
+ 206 RPL_TRACESERVER
+ "Serv <class> <int>S <int>C <server>
+ <nick!user|*!*>@<host|server> V<protocol version>"
+ 207 RPL_TRACESERVICE
+ "Service <class> <name> <type> <active type>"
+ 208 RPL_TRACENEWTYPE
+ "<newtype> 0 <client name>"
+ 209 RPL_TRACECLASS
+ "Class <class> <count>"
+ 210 RPL_TRACERECONNECT
+ Unused.
+ 261 RPL_TRACELOG
+ "File <logfile> <debug level>"
+ 262 RPL_TRACEEND
+ "<server name> <version & debug level> :End of TRACE"
+
+ - The RPL_TRACE* are all returned by the server in
+ response to the TRACE message. How many are
+ returned is dependent on the TRACE message and
+ whether it was sent by an operator or not. There
+ is no predefined order for which occurs first.
+ Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
+ RPL_TRACEHANDSHAKE are all used for connections
+ which have not been fully established and are either
+ unknown, still attempting to connect or in the
+ process of completing the 'server handshake'.
+ RPL_TRACELINK is sent by any server which handles
+ a TRACE message and has to pass it on to another
+ server. The list of RPL_TRACELINKs sent in
+ response to a TRACE command traversing the IRC
+ network should reflect the actual connectivity of
+ the servers themselves along that path.
+
+
+
+
+Kalt Informational [Page 50]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ RPL_TRACENEWTYPE is to be used for any connection
+ which does not fit in the other categories but is
+ being displayed anyway.
+ RPL_TRACEEND is sent to indicate the end of the list.
+
+ 211 RPL_STATSLINKINFO
+ "<linkname> <sendq> <sent messages>
+ <sent Kbytes> <received messages>
+ <received Kbytes> <time open>"
+
+ - reports statistics on a connection. <linkname>
+ identifies the particular connection, <sendq> is
+ the amount of data that is queued and waiting to be
+ sent <sent messages> the number of messages sent,
+ and <sent Kbytes> the amount of data sent, in
+ Kbytes. <received messages> and <received Kbytes>
+ are the equivalent of <sent messages> and <sent
+ Kbytes> for received data, respectively. <time
+ open> indicates how long ago the connection was
+ opened, in seconds.
+
+ 212 RPL_STATSCOMMANDS
+ "<command> <count> <byte count> <remote count>"
+
+ - reports statistics on commands usage.
+
+ 219 RPL_ENDOFSTATS
+ "<stats letter> :End of STATS report"
+
+ 242 RPL_STATSUPTIME
+ ":Server Up %d days %d:%02d:%02d"
+
+ - reports the server uptime.
+
+ 243 RPL_STATSOLINE
+ "O <hostmask> * <name>"
+
+ - reports the allowed hosts from where user may become IRC
+ operators.
+
+ 221 RPL_UMODEIS
+ "<user mode string>"
+
+ - To answer a query about a client's own mode,
+ RPL_UMODEIS is sent back.
+
+ 234 RPL_SERVLIST
+ "<name> <server> <mask> <type> <hopcount> <info>"
+
+
+
+Kalt Informational [Page 51]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 235 RPL_SERVLISTEND
+ "<mask> <type> :End of service listing"
+
+ - When listing services in reply to a SERVLIST message,
+ a server is required to send the list back using the
+ RPL_SERVLIST and RPL_SERVLISTEND messages. A separate
+ RPL_SERVLIST is sent for each service. After the
+ services have been listed (or if none present) a
+ RPL_SERVLISTEND MUST be sent.
+
+ 251 RPL_LUSERCLIENT
+ ":There are <integer> users and <integer>
+ services on <integer> servers"
+ 252 RPL_LUSEROP
+ "<integer> :operator(s) online"
+ 253 RPL_LUSERUNKNOWN
+ "<integer> :unknown connection(s)"
+ 254 RPL_LUSERCHANNELS
+ "<integer> :channels formed"
+ 255 RPL_LUSERME
+ ":I have <integer> clients and <integer>
+ servers"
+
+ - In processing an LUSERS message, the server
+ sends a set of replies from RPL_LUSERCLIENT,
+ RPL_LUSEROP, RPL_USERUNKNOWN,
+ RPL_LUSERCHANNELS and RPL_LUSERME. When
+ replying, a server MUST send back
+ RPL_LUSERCLIENT and RPL_LUSERME. The other
+ replies are only sent back if a non-zero count
+ is found for them.
+
+ 256 RPL_ADMINME
+ "<server> :Administrative info"
+ 257 RPL_ADMINLOC1
+ ":<admin info>"
+ 258 RPL_ADMINLOC2
+ ":<admin info>"
+ 259 RPL_ADMINEMAIL
+ ":<admin info>"
+
+ - When replying to an ADMIN message, a server
+ is expected to use replies RPL_ADMINME
+ through to RPL_ADMINEMAIL and provide a text
+ message with each. For RPL_ADMINLOC1 a
+ description of what city, state and country
+ the server is in is expected, followed by
+ details of the institution (RPL_ADMINLOC2)
+
+
+
+Kalt Informational [Page 52]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ and finally the administrative contact for the
+ server (an email address here is REQUIRED)
+ in RPL_ADMINEMAIL.
+
+ 263 RPL_TRYAGAIN
+ "<command> :Please wait a while and try again."
+
+ - When a server drops a command without processing it,
+ it MUST use the reply RPL_TRYAGAIN to inform the
+ originating client.
+
+5.2 Error Replies
+
+ Error replies are found in the range from 400 to 599.
+
+ 401 ERR_NOSUCHNICK
+ "<nickname> :No such nick/channel"
+
+ - Used to indicate the nickname parameter supplied to a
+ command is currently unused.
+
+ 402 ERR_NOSUCHSERVER
+ "<server name> :No such server"
+
+ - Used to indicate the server name given currently
+ does not exist.
+
+ 403 ERR_NOSUCHCHANNEL
+ "<channel name> :No such channel"
+
+ - Used to indicate the given channel name is invalid.
+
+ 404 ERR_CANNOTSENDTOCHAN
+ "<channel name> :Cannot send to channel"
+
+ - Sent to a user who is either (a) not on a channel
+ which is mode +n or (b) not a chanop (or mode +v) on
+ a channel which has mode +m set or where the user is
+ banned and is trying to send a PRIVMSG message to
+ that channel.
+
+ 405 ERR_TOOMANYCHANNELS
+ "<channel name> :You have joined too many channels"
+
+ - Sent to a user when they have joined the maximum
+ number of allowed channels and they try to join
+ another channel.
+
+
+
+
+Kalt Informational [Page 53]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 406 ERR_WASNOSUCHNICK
+ "<nickname> :There was no such nickname"
+
+ - Returned by WHOWAS to indicate there is no history
+ information for that nickname.
+
+ 407 ERR_TOOMANYTARGETS
+ "<target> :<error code> recipients. <abort message>"
+
+ - Returned to a client which is attempting to send a
+ PRIVMSG/NOTICE using the user@host destination format
+ and for a user@host which has several occurrences.
+
+ - Returned to a client which trying to send a
+ PRIVMSG/NOTICE to too many recipients.
+
+ - Returned to a client which is attempting to JOIN a safe
+ channel using the shortname when there are more than one
+ such channel.
+
+ 408 ERR_NOSUCHSERVICE
+ "<service name> :No such service"
+
+ - Returned to a client which is attempting to send a SQUERY
+ to a service which does not exist.
+
+ 409 ERR_NOORIGIN
+ ":No origin specified"
+
+ - PING or PONG message missing the originator parameter.
+
+ 411 ERR_NORECIPIENT
+ ":No recipient given (<command>)"
+ 412 ERR_NOTEXTTOSEND
+ ":No text to send"
+ 413 ERR_NOTOPLEVEL
+ "<mask> :No toplevel domain specified"
+ 414 ERR_WILDTOPLEVEL
+ "<mask> :Wildcard in toplevel domain"
+ 415 ERR_BADMASK
+ "<mask> :Bad Server/host mask"
+
+ - 412 - 415 are returned by PRIVMSG to indicate that
+ the message wasn't delivered for some reason.
+ ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
+ are returned when an invalid use of
+ "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
+
+
+
+
+Kalt Informational [Page 54]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 421 ERR_UNKNOWNCOMMAND
+ "<command> :Unknown command"
+
+ - Returned to a registered client to indicate that the
+ command sent is unknown by the server.
+
+ 422 ERR_NOMOTD
+ ":MOTD File is missing"
+
+ - Server's MOTD file could not be opened by the server.
+
+ 423 ERR_NOADMININFO
+ "<server> :No administrative info available"
+
+ - Returned by a server in response to an ADMIN message
+ when there is an error in finding the appropriate
+ information.
+
+ 424 ERR_FILEERROR
+ ":File error doing <file op> on <file>"
+
+ - Generic error message used to report a failed file
+ operation during the processing of a message.
+
+ 431 ERR_NONICKNAMEGIVEN
+ ":No nickname given"
+
+ - Returned when a nickname parameter expected for a
+ command and isn't found.
+
+ 432 ERR_ERRONEUSNICKNAME
+ "<nick> :Erroneous nickname"
+
+ - Returned after receiving a NICK message which contains
+ characters which do not fall in the defined set. See
+ section 2.3.1 for details on valid nicknames.
+
+ 433 ERR_NICKNAMEINUSE
+ "<nick> :Nickname is already in use"
+
+ - Returned when a NICK message is processed that results
+ in an attempt to change to a currently existing
+ nickname.
+
+
+
+
+
+
+
+
+Kalt Informational [Page 55]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 436 ERR_NICKCOLLISION
+ "<nick> :Nickname collision KILL from <user>@<host>"
+
+ - Returned by a server to a client when it detects a
+ nickname collision (registered of a NICK that
+ already exists by another server).
+
+ 437 ERR_UNAVAILRESOURCE
+ "<nick/channel> :Nick/channel is temporarily unavailable"
+
+ - Returned by a server to a user trying to join a channel
+ currently blocked by the channel delay mechanism.
+
+ - Returned by a server to a user trying to change nickname
+ when the desired nickname is blocked by the nick delay
+ mechanism.
+
+ 441 ERR_USERNOTINCHANNEL
+ "<nick> <channel> :They aren't on that channel"
+
+ - Returned by the server to indicate that the target
+ user of the command is not on the given channel.
+
+ 442 ERR_NOTONCHANNEL
+ "<channel> :You're not on that channel"
+
+ - Returned by the server whenever a client tries to
+ perform a channel affecting command for which the
+ client isn't a member.
+
+ 443 ERR_USERONCHANNEL
+ "<user> <channel> :is already on channel"
+
+ - Returned when a client tries to invite a user to a
+ channel they are already on.
+
+ 444 ERR_NOLOGIN
+ "<user> :User not logged in"
+
+ - Returned by the summon after a SUMMON command for a
+ user was unable to be performed since they were not
+ logged in.
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 56]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 445 ERR_SUMMONDISABLED
+ ":SUMMON has been disabled"
+
+ - Returned as a response to the SUMMON command. MUST be
+ returned by any server which doesn't implement it.
+
+ 446 ERR_USERSDISABLED
+ ":USERS has been disabled"
+
+ - Returned as a response to the USERS command. MUST be
+ returned by any server which does not implement it.
+
+ 451 ERR_NOTREGISTERED
+ ":You have not registered"
+
+ - Returned by the server to indicate that the client
+ MUST be registered before the server will allow it
+ to be parsed in detail.
+
+ 461 ERR_NEEDMOREPARAMS
+ "<command> :Not enough parameters"
+
+ - Returned by the server by numerous commands to
+ indicate to the client that it didn't supply enough
+ parameters.
+
+ 462 ERR_ALREADYREGISTRED
+ ":Unauthorized command (already registered)"
+
+ - Returned by the server to any link which tries to
+ change part of the registered details (such as
+ password or user details from second USER message).
+
+ 463 ERR_NOPERMFORHOST
+ ":Your host isn't among the privileged"
+
+ - Returned to a client which attempts to register with
+ a server which does not been setup to allow
+ connections from the host the attempted connection
+ is tried.
+
+ 464 ERR_PASSWDMISMATCH
+ ":Password incorrect"
+
+ - Returned to indicate a failed attempt at registering
+ a connection for which a password was required and
+ was either not given or incorrect.
+
+
+
+
+Kalt Informational [Page 57]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 465 ERR_YOUREBANNEDCREEP
+ ":You are banned from this server"
+
+ - Returned after an attempt to connect and register
+ yourself with a server which has been setup to
+ explicitly deny connections to you.
+
+ 466 ERR_YOUWILLBEBANNED
+
+ - Sent by a server to a user to inform that access to the
+ server will soon be denied.
+
+ 467 ERR_KEYSET
+ "<channel> :Channel key already set"
+ 471 ERR_CHANNELISFULL
+ "<channel> :Cannot join channel (+l)"
+ 472 ERR_UNKNOWNMODE
+ "<char> :is unknown mode char to me for <channel>"
+ 473 ERR_INVITEONLYCHAN
+ "<channel> :Cannot join channel (+i)"
+ 474 ERR_BANNEDFROMCHAN
+ "<channel> :Cannot join channel (+b)"
+ 475 ERR_BADCHANNELKEY
+ "<channel> :Cannot join channel (+k)"
+ 476 ERR_BADCHANMASK
+ "<channel> :Bad Channel Mask"
+ 477 ERR_NOCHANMODES
+ "<channel> :Channel doesn't support modes"
+ 478 ERR_BANLISTFULL
+ "<channel> <char> :Channel list is full"
+
+ 481 ERR_NOPRIVILEGES
+ ":Permission Denied- You're not an IRC operator"
+
+ - Any command requiring operator privileges to operate
+ MUST return this error to indicate the attempt was
+ unsuccessful.
+
+ 482 ERR_CHANOPRIVSNEEDED
+ "<channel> :You're not channel operator"
+
+ - Any command requiring 'chanop' privileges (such as
+ MODE messages) MUST return this error if the client
+ making the attempt is not a chanop on the specified
+ channel.
+
+
+
+
+
+
+Kalt Informational [Page 58]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 483 ERR_CANTKILLSERVER
+ ":You can't kill a server!"
+
+ - Any attempts to use the KILL command on a server
+ are to be refused and this error returned directly
+ to the client.
+
+ 484 ERR_RESTRICTED
+ ":Your connection is restricted!"
+
+ - Sent by the server to a user upon connection to indicate
+ the restricted nature of the connection (user mode "+r").
+
+ 485 ERR_UNIQOPPRIVSNEEDED
+ ":You're not the original channel operator"
+
+ - Any MODE requiring "channel creator" privileges MUST
+ return this error if the client making the attempt is not
+ a chanop on the specified channel.
+
+ 491 ERR_NOOPERHOST
+ ":No O-lines for your host"
+
+ - If a client sends an OPER message and the server has
+ not been configured to allow connections from the
+ client's host as an operator, this error MUST be
+ returned.
+
+ 501 ERR_UMODEUNKNOWNFLAG
+ ":Unknown MODE flag"
+
+ - Returned by the server to indicate that a MODE
+ message was sent with a nickname parameter and that
+ the a mode flag sent was not recognized.
+
+ 502 ERR_USERSDONTMATCH
+ ":Cannot change mode for other users"
+
+ - Error sent to any user trying to view or change the
+ user mode for a user other than themselves.
+
+5.3 Reserved numerics
+
+ These numerics are not described above since they fall into one of
+ the following categories:
+
+ 1. no longer in use;
+
+
+
+
+Kalt Informational [Page 59]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+ 2. reserved for future planned use;
+
+ 3. in current use but are part of a non-generic 'feature' of
+ the current IRC server.
+
+ 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
+ 233 RPL_SERVICE
+ 300 RPL_NONE 316 RPL_WHOISCHANOP
+ 361 RPL_KILLDONE 362 RPL_CLOSING
+ 363 RPL_CLOSEEND 373 RPL_INFOSTART
+ 384 RPL_MYPORTIS
+
+ 213 RPL_STATSCLINE 214 RPL_STATSNLINE
+ 215 RPL_STATSILINE 216 RPL_STATSKLINE
+ 217 RPL_STATSQLINE 218 RPL_STATSYLINE
+ 240 RPL_STATSVLINE 241 RPL_STATSLLINE
+ 244 RPL_STATSHLINE 244 RPL_STATSSLINE
+ 246 RPL_STATSPING 247 RPL_STATSBLINE
+ 250 RPL_STATSDLINE
+
+ 492 ERR_NOSERVICEHOST
+
+6. Current implementations
+
+ The IRC software, version 2.10 is the only complete implementation of
+ the IRC protocol (client and server). Because of the small amount of
+ changes in the client protocol since the publication of RFC 1459
+ [IRC], implementations that follow it are likely to be compliant with
+ this protocol or to require a small amount of changes to reach
+ compliance.
+
+7. Current problems
+
+ There are a number of recognized problems with the IRC Client
+ Protocol, and more generally with the IRC Server Protocol. In order
+ to preserve backward compatibility with old clients, this protocol
+ has almost not evolved since the publication of RFC 1459 [IRC].
+
+7.1 Nicknames
+
+ The idea of the nickname on IRC is very convenient for users to use
+ when talking to each other outside of a channel, but there is only a
+ finite nickname space and being what they are, it's not uncommon for
+ several people to want to use the same nick. If a nickname is chosen
+ by two people using this protocol, either one will not succeed or
+ both will removed by use of a server KILL (See Section 3.7.1).
+
+
+
+
+
+Kalt Informational [Page 60]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+7.2 Limitation of wildcards
+
+ There is no way to escape the escape character "\" (%x5C). While
+ this isn't usually a problem, it makes it impossible to form a mask
+ with a backslash character ("\") preceding a wildcard.
+
+7.3 Security considerations
+
+ Security issues related to this protocol are discussed in the "IRC
+ Server Protocol" [IRC-SERVER] as they are mostly an issue for the
+ server side of the connection.
+
+8. Current support and availability
+
+ Mailing lists for IRC related discussion:
+ General discussion: ircd-users@irc.org
+ Protocol development: ircd-dev@irc.org
+
+ Software implementations:
+ ftp://ftp.irc.org/irc/server
+ ftp://ftp.funet.fi/pub/unix/irc
+ ftp://ftp.irc.org/irc/clients
+
+ Newsgroup: alt.irc
+
+9. Acknowledgements
+
+ Parts of this document were copied from the RFC 1459 [IRC] which
+ first formally documented the IRC Protocol. It has also benefited
+ from many rounds of review and comments. In particular, the
+ following people have made significant contributions to this
+ document:
+
+ Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
+ Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 61]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+10. References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [HNAME] Braden, R., "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+ [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+ [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+ [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+11. Author's Address
+
+ Christophe Kalt
+ 99 Teaneck Rd, Apt #117
+ Ridgefield Park, NJ 07660
+ USA
+
+ EMail: kalt@stealth.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 62]
+
+RFC 2812 Internet Relay Chat: Client Protocol April 2000
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 63]
+
diff --git a/doc/unreal32docs.html b/doc/unreal32docs.html
new file mode 100644
index 0000000..98ca1e2
--- /dev/null
+++ b/doc/unreal32docs.html
@@ -0,0 +1,3666 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<title>UnrealIRCd - 3.2 - Official Documentation</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<style type="text/css">
+ .block_section { font-size: 24; font-weight: bold; }
+ .block_name { font-size: 24; font-weight: bold; }
+ .block_required { color: red; font-weight: bold; }
+ .block_recommended { color: green; font-weight: bold; }
+ .block_optional { color: blue; font-weight: bold; }
+ .block_old { font-size: 14; }
+ .set { font-weight: bold; }
+ .desc { margin-left: 15px; }
+ pre { font: "times new roman"; font-style: normal; background-color: #eeeeee;}
+</style>
+</head>
+
+<!-- $Id: unreal32docs.html,v 1.1.2.144.2.133 2009/12/06 16:52:51 syzop Exp $ -->
+
+<body>
+English |
+<a href="unreal32docs.de.html">German</a> |
+<a href="unreal32docs.es.html">Spanish</a> |
+<a href="unreal32docs.hu.html">Hungarian</a> |
+<a href="unreal32docs.fr.html">French</a> |
+<a href="unreal32docs.gr.html">Greek</a> |
+<a href="unreal32docs.nl.html">Dutch</a> |
+<a href="unreal32docs.ru.html">Russian</a> |
+<a href="unreal32docs.tr.html">Turkish</a>
+<br><br>
+<div align="center"><b><font size="7">UnrealIRCd</font></b><br>
+ <font size="4"><a href="http://www.unrealircd.com">http://www.unrealircd.com</a></font><br>
+ <font size="4">Version: 3.2.8</font><br>
+ <b>Last doc update:</b> 2009-09-14</div>
+<br>
+ <b>Coders:</b> Stskeeps / codemastr / Syzop / Luke / aquanight / WolfSage <br>
+ <b>Contributors:</b> McSkaf / Zogg / NiQuiL / assyrian / chasm / DrBin / llthangel / Griever / nighthawk<br>
+ <b>Documentation:</b> CKnight^ / Syzop<br>
+<p>To view this documentation you must have a compatible browser, which are listed below. Up to date docs are
+ available at <a href="http://www.vulnscan.org/UnrealIRCd/unreal32docs.html">http://www.vulnscan.org/UnrealIRCd/unreal32docs.html</a>
+ and a FAQ at <a href="http://www.vulnscan.org/UnrealIRCd/faq/" TARGET="_blank">http://www.vulnscan.org/UnrealIRCd/faq/</a>.
+</p>
+<p><b>Compatible Browsers: </b><br>
+<ul>
+<li>Opera 6.02
+<li>Microsoft Internet Explorer 6.X / 5.5
+<li>Netscape Navigator 6.X
+<li>Mozilla 1.2.X
+<li>Lynx (to a point)
+</ul>
+</p>
+<p><font size="+2"><b>INDEX / TABLE OF CONTENTS</b></font><br>
+ 1. <a href="#IntroductionNotes">Introduction & Notes</a><br>
+ ---1.1. <a href="#notesonolder">Notes on upgrading/mixing 3.1.x -> 3.2</a><br>
+ ---1.2. <a href="#notesonupgrade">Notes on upgrading between 3.2 versions</a><br>
+ 2. <a href="#installation">Installation</a><br>
+ 3. <a href="#features">Features</a><br>
+ -- 3.1. <a href="#feature_cloaking">Cloaking</a><br>
+ -- 3.2. <a href="#feature_modules">Modules</a><br>
+ -- 3.3. <a href="#feature_snomasks">Snomasks</a><br>
+ -- 3.4. <a href="#feature_aliases">Aliases</a><br>
+ -- 3.5. <a href="#feature_helpop">Helpop</a><br>
+ -- 3.6. <a href="#feature_operaccesslevels">Oper access levels</a><br>
+ -- 3.7. <a href="#feature_opercmds">Oper commands</a><br>
+ -- 3.8. <a href="#feature_ssl">SSL</a><br>
+ -- 3.9. <a href="#feature_ipv6">IPv6</a><br>
+ -- 3.10. <a href="#feature_ziplinks">Zip links</a><br>
+ -- 3.11. <a href="#feature_dyndns">Dynamic DNS/IP linking support</a><br>
+ -- 3.12. <a href="#feature_antiflood">Anti-flood features</a><br>
+ -- 3.13. <a href="#feature_bantypes">Ban types</a><br>
+ -- 3.14. <a href="#feature_spamfilter">Spamfilter</a><br>
+ -- 3.15. <a href="#feature_cidr">CIDR</a><br>
+ -- 3.16. <a href="#feature_nickchars">Nick Character Sets</a><br>
+ -- 3.17. <a href="#feature_cgiirc">CGI:IRC Support</a><br>
+ -- 3.18. <a href="#feature_timesync">Time Synchronization</a><br>
+ -- 3.19. <a href="#feature_other">Other features</a><br>
+ 4. <a href="#configuringyourunrealircdconf">Configuring your unrealircd.conf
+ file</a><br>
+ ---4.1. <a href="#configurationfileexplained">Configuration file explained</a><br>
+ ---4.2. <a href="#meblock"> Me Block -=- (M:Line)</a><br>
+ ---4.3. <a href="#adminblock">Admin Block -=- (A:Line)</a><br>
+ ---4.4. <a href="#classblock">Class Block -=- (Y:Line)</a><br>
+ ---4.5. <a href="#allowblock">Allow Block -=- (I:Line)</a><br>
+ ---4.6. <a href="#listenblock">Listen Block -=- (P:Line)</a><br>
+ ---4.7. <a href="#operblock">Oper Block -=- (O:Line)</a><br>
+ ---4.8. <a href="#drpassblock">DRpass Block -=-(X:Line)</a><br>
+ ---4.9. <a href="#includedirective">Include Directive</a><br>
+ ---4.10. <a href="#loadmoduledirective">Loadmodule Directive</a><br>
+ ---4.11. <a href="#logblock">Log Block</a><br>
+ ---4.12. <a href="#tldblock">TLD Block -=- (T:Line)</a><br>
+ ---4.13. <a href="#bannickblock">Ban Nick Block -=- (Q:Line)</a><br>
+ ---4.14. <a href="#banuserblock">Ban User Block -=- (K:Line)</a><br>
+ ---4.15. <a href="#banipblock">Ban IP Block -=- (Z:Line)</a><br>
+ ---4.16. <a href="#banserverblock">Ban Server Block -=-(q:Line)</a><br>
+ ---4.17. <a href="#banrealnameblock">Ban Realname Block -=- (n:Line)</a><br>
+ ---4.18. <a href="#banversionblock">Ban Version Block</a><br>
+ ---4.19. <a href="#banexceptionblock">Ban Exception Block -=- (E:Line)</a><br>
+ ---4.20. <a href="#tklexceptionblock">TKL Exception Block</a><br>
+ ---4.21. <a href="#throttleexceptionblock">Throttle Exception Block</a><br>
+ ---4.22. <a href="#denydccblock">Deny DCC Block -=- (dccdeny.conf)</a><br>
+ ---4.23. <a href="#denyversionblock">Deny Version Block -=- (V:Line)</a><br>
+ ---4.24. <a href="#denylinkblock">Deny Link Block -=- (D:Line / d:Line)</a><br>
+ ---4.25. <a href="#denychannelblock">Deny Channel Block -=- (chrestrict.conf)</a><br>
+ ---4.26. <a href="#allowchannelblock">Allow Channel Block</a><br>
+ ---4.27. <a href="#allowdccblock">Allow DCC Block</a><br>
+ ---4.28. <a href="#vhostblock">Vhost Block -=- (vhost.conf)</a><br>
+ ---4.29. <a href="#badwordsblock">Badword Block -=- (badwords.conf)</a><br>
+ ---4.30. <a href="#ulinesblock">Uline Block -=- (U:Line)</a><br>
+ ---4.31. <a href="#linkblock">Link Block -=- (C/N/H:Lines)</a><br>
+ ---4.32. <a href="#aliasblock">Alias Block</a><br>
+ ---4.33. <a href="#helpblock">Help Block</a><br>
+ ---4.34. <a href="#officialchannels">Official Channels Block</a><br>
+ ---4.35. <a href="#spamfilter">Spamfilter Block</a><br>
+ ---4.36. <a href="#cgiirc">Cgiirc Block</a><br>
+ ---4.37. <a href="#setblock">Set Block -=- (networks/unrealircd.conf)</a><br>
+ ---4.38. <a href="#filesblock">Files Block</a><br />
+ 5. <a href="#addtlfiles">Additional Files</a><br>
+ 6. <a href="#userchannelmodes">User & Channel Modes</a><br>
+ 7. <a href="#useropercommands">User & Oper Commands</a><br>
+ 8. <a href="#security">Security tips/checklist</a><br>
+ ---8.1. <a href="#secpasswords">Passwords</a><br>
+ ---8.2. <a href="#secnonircd">Non-Ircd related vulnerabilities</a><br>
+ ---8.3. <a href="#secpermissions">Permissions and the configfile</a><br>
+ ---8.4. <a href="#secuser">User-related problems</a><br>
+ ---8.5. <a href="#secsnif">SSL/SSH & sniffing</a><br>
+ ---8.6. <a href="#secDoS">Denial of Service attacks (DoS) [or: how to protect my hub]</a><br>
+ ---8.7. <a href="#secinformation">Information disclosure</a><br>
+ ---8.8. <a href="#secantiexploit">Protecting against exploits</a><br>
+ ---8.9. <a href="#secsummary">Summary</a><br>
+ 9. <a href="http://www.vulnscan.org/UnrealIRCd/faq/" target="_blank">Frequently Asked Questions (FAQ)</a><br>
+ A. <a href="#regex">Regular Expressions</a><br>
+ ---A.1. <a href="#regexlit">Literals</a><br>
+ ---A.2. <a href="#regexdot">Dot Operator</a><br>
+ ---A.3. <a href="#regexrep">Repetition Operators</a><br>
+ ---A.4. <a href="#regexbracket">Bracket Expressions</a><br>
+ ---A.5. <a href="#regexassert">Assertions</a><br>
+ ---A.6. <a href="#regexalt">Alternation</a><br>
+ ---A.7. <a href="#regexsub">Subexpressions</a><br>
+ ---A.8. <a href="#regexbackref">Back References</a><br>
+ ---A.9. <a href="#regexcase">Case Sensitivity</a><br>
+</p>
+<p><b><font size="+2">1.0 – Introduction & Notes <a name="IntroductionNotes"></a></font></b><br>
+</p><div class="desc">
+<p>This document was written for exclusive use with UnrealIRCd. Use of this
+ document with another software package, or distribution of this document with
+ another software package is strictly prohibited without the written permission
+ of the UnrealIRCd Development Team. This document may be copied/printed/reproduced/published
+ as many times as you like, provided it is for use with UnrealIRCd and it is not
+ modified in anyway. – Copyright UnrealIRCd Development Team 2002-2006</p>
+<p>Please read this manual before asking for help, you also REALLY want to take a look at the
+ <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
+ need help you can ask for support at irc.unrealircd.org (port 6667) channel #unreal-support (note
+ that we REQUIRE you to read the docs and faq and we only help with UnrealIRCd, not with services!).
+ If you have a real bug (like a crash) then report it at
+ <a href="http://bugs.unrealircd.org" TARGET="_blank">http://bugs.unrealircd.org</a>.</p></div>
+
+<p><font size="+2"><b>1.1 – Notes on upgrading/mixing 3.1.x -> 3.2 </b></font><a name="notesonolder"></a><br>
+</p>
+<div class="desc">
+<p>In case you are upgrading from Unreal3.1.x to Unreal3.2 you'll notice the whole config file has changed,
+ you may find it hard at first, but once you've switched you'll find it much better!</p>
+<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>
+<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>
+
+<p><font size="+2"><b>1.2 – Notes on upgrading between 3.2 versions</b></font><a name="notesonupgrade"></a><br>
+</p><div class="desc">
+<p>The recommended way to upgrade is:<br>
+Linux:<br>
+<ul>
+<li>Rename your old UnrealIRCd directory (or otherwise you'll overwrite it in the next step)
+<li>Extract the new UnrealIRCd version and run ./Config and make
+<li>Copy your old configuration files to the new directory (unrealircd.conf, motd, rules, server.* [SSL certs], network file, etc)</p></ul>
+Windows:<br>
+<ul>
+<li>Copy all of your configuration files to a temporary location.
+<li>Run the uninstaller for any previous versions of Unreal you have installed.
+<li>Run the installer for the new version of Unreal.
+<li>Copy your old configuration files to the new folder.
+</ul>
+<p>Please also check .RELEASE.NOTES to see what has been changed.
+ 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>
+
+<p><font size="+2"><b>2.0 - Installation</b></font><a name="installation" id="installation"></a><br><div class="desc">
+ <br>
+ <b>Tested & Supported Operating Systems:</b><br>
+<ul>
+<li><b>*NIX versions:</b>
+<ul>
+<li>Linux (2.2.*, 2.4.*, 2.6.*)
+<li>FreeBSD (4.*, 5.*, 6.*)
+<li>NetBSD (2.*)
+<li>OpenBSD (3.7, 3.8, 3.9)
+<li>Solaris (9, 10)
+</ul>
+<li><b>Windows version:</b>
+<ul>
+<li>Windows 2000 (Pro, Server, Advanced Server)
+<li>Windows XP (Home, Pro)
+<li>Windows 2003
+</ul>
+<li><b>Architectures tested:</b>
+<ul>
+<li>ia32 (i386, i486, i586, i686)
+<li>ia64
+<li>amd64
+<li>alpha
+</ul>
+</ul>
+ <br>
+ If you have Unreal3.2 working correctly under other operating systems, please
+ send the details to <a href="mailto:coders@lists.unrealircd.org">coders@lists.unrealircd.org<br>
+ </a> </p>
+<p><b>Installation Instructions</b><br>
+Linux:<br>
+<ol>
+<li>gunzip -d Unreal3.2.X.tar.gz
+<li>tar xvf Unreal3.2.X.tar
+<li>cd Unreal3.2
+<li>./Config
+<li>Answer these questions to the best of your knowledge. Generally if your not
+ sure, the default will work just fine!
+<li>make
+<li>Now create your unrealircd.conf and other configuration files, see section 4.
+</ol>
+<p>
+Windows:<br>
+<ol>
+<li>Run the Unreal installer
+<li>Now create your unrealircd.conf and other configuration files, see section 4.
+</ol>
+</p>
+<p> </p></div>
+<p><font size="+2"><b>3.0 - Features</b></font>
+ <a name="features"></a></p><div class="desc">
+<p>Some major/nice features are explained in this section. It provides a general overview,
+ and sometimes refers to the config file (something which you might know nothing about yet).</p>
+<p>You can skip this section, however it's very much suggested to read it before/after installing
+because otherwise you will not understand concepts such as 'cloaking', 'snomasks', etc.</p></div>
+
+<p><font size="+2"><b>3.1 - Cloaking</b></font><a name="feature_cloaking"></a></p><div class="desc">
+<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>,
+ it will be shown (in join, part, whois, etc) as <i>rox-2DCA3201.cable.wanadoo.nl</i>.
+ This feature is useful to prevent users flooding each other since they can't see the real host/IP.</p>
+<p>This is controlled by usermode +x (like: /mode yournick +x), admins can also force +x to be enabled
+ by default, or make it so users can never do -x.</p>
+<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>
+ <b>cloak:</b> This is the official cloaking module since 3.2.1, it is much more secure than the old
+ algorithm, it uses md5 internally and requires you to have 3 set::cloak-keys:: consisting of mixed lowercase (a-z),
+ uppercase (A-Z) and digit (0-9) charachters [eg: "AopAS6WQH2Os6hfosh4SFJHs"]. See example.conf for an example.<br>
+<p>Cloak keys MUST be the same on ALL SERVERS in a network. Also cloak keys should be kept SECRET
+ because it's possible to decode the original host if you know the keys (which makes umode +x useless).</p>
+<p>Hint: If you are on *NIX and have to create new cloak keys, you can run './unreal gencloak'
+ in your shell, which will output 3 random strings that you can use.</p>
+</div>
+<p><font size="+2"><b>3.2 - Modules</b></font><a name="feature_modules"></a></p><div class="desc">
+<p>UnrealIRCd supports modules which is nice because:<br>
+ - 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>
+ - Other people can create (3rd party) modules with new commands, usermodes and even channelmodes.<br>
+ UnrealIRCd only comes with a few modules. Take a look at www.unrealircd.com -> modules
+ or use google to find 3rd party modules.<br>
+<p>You need to load at least 2 modules or else you won't be able to boot!:<br>
+ - the commands module: commands.so (commands.dll on windows)<br>
+ - a cloaking module: usually cloak.so (cloak.dll on windows).</p>
+</div>
+
+<p><font size="+2"><b>3.3 - Snomasks</b></font><a name="feature_snomasks"></a></p><div class="desc">
+<p>Snomasks are server notice masks, it's a special type of usermode that controls which
+ server notices you will receive (mostly used by opers)</p>
+<p>It can be set by: /mode yournick +s SNOMASK, for example: /mode yournick +s +cF<br>
+ To remove certain snomasks, use something like: /mode yournick +s -c<br>
+ Or you can remove all snomasks by simply doing: /mode yournick -s</p>
+<p>The current available snomasks are:<br>
+ c - local connects<br>
+ F - far connects (except from U-lined servers)<br>
+ f - flood notices<br>
+ k - kill notices [*]<br>
+ e - 'eyes' notices<br>
+ j - 'junk' notices<br>
+ v - vhost notices<br>
+ G - gline/shun notices<br>
+ n - local nick change notices<br>
+ N - remote nick change notices<br>
+ q - deny nick (Q:line) rejection notices<br>
+ s - receives server notices [*]<br>
+ S - receives spamfilter notices<br>
+ o - receives oper-up notices<br>
+ [*: this snomask is also allowed to non-ircops]<br>
+ </p>
+<p>You can control which snomasks you automatically get (set::snomask-on-connect) and which you get
+ on oper (set::snomask-on-oper, oper::snomask)</p>
+<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>
+
+<p><font size="+2"><b>3.4 - Aliases</b></font><a name="feature_aliases"></a></p><div class="desc">
+<p>With aliases you can configure server-side alias commands.
+ You can for example let "/ns identify blah" be forwarded to nickserv (it will be
+ translated to: privmsg nickserv identify blah). You can even make more complex aliases such as /register can forward to
+ ChanServ if the first parameter begins with a # and forwarded to NickServ if it doesn't.</p>
+<p>Aliases are configured by <a href="#aliasblock">alias blocks</a> in the configuration file, and you can also include
+ a file with default aliases for most commonly used services.</p></div>
+
+<p><font size="+2"><b>3.5 - Helpop</b></font><a name="feature_helpop"></a></p><div class="desc">
+<p>UnrealIRCd has a built-in help system accessible by /helpop. The /helpop command is completely user configurable via
+ the help block in the configuration file. Additionally, a help.conf is included which contains some basic help for
+ all commands.<br>
+ For example <i>/helpop chmodes</i> gives you a overview of all channel modes UnrealIRCd has.<br>
+ Remember that if you are an ircop (helpop) you will have to prefix the keyword with a '?' character,
+ so <i>/helpop</i> becomes <i>/helpop ?</i> and
+ <i>/helpop chmodes</i> becomes <i>/helpop ?chmodes</i> etc..</p></div>
+
+<p><font size="+2"><b>3.6 - Oper access levels</b></font><a name="feature_operaccesslevels"></a></p><div class="desc">
+<p>There are several oper levels in UnrealIRCd and you can add additional rights (like to use /gline) to
+ each of them, that way you can give each oper the privileges they need.</p>
+<p>This is controlled by the oper flags in the oper block, see the oper block for more information.</p></div>
+
+<p><font size="+2"><b>3.7 - Oper commands</b></font><a name="feature_opercmds"></a></p><div class="desc">
+<p>UnrealIRCd has a lot of powerful oper commands which are explained in <a href="#useropercommands">User & Oper Commands</a>,
+ you probably want to read those after installing :).</p></div>
+
+<p><font size="+2"><b>3.8 - SSL</b></font><a name="feature_ssl"></a></p><div class="desc">
+<p>SSL stands for Secure Socket Layer, with SSL you can make secure encrypted connections.
+ It can be used to encrypt server<->server traffic, but client<->server traffic can also be encrypted.
+ You usually use SSL to protect against sniffing and for authentication.</p>
+<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>
+<p>You cannot connect normally to a SSL port (so don't make port 6667 ssl!), you need a client or a tunnel
+ that understands the SSL protocol.</p>
+<p>Clients that support SSL: <A HREF="http://www.xchat.org/" TARGET="_blank">XChat</a>,
+ <A HREF="http://www.irssi.org/" TARGET="_blank">irssi</a>,
+ <A HREF="http://www.mirc.com/" TARGET="_blank">mIRC</a> (6.14 and up,
+ also requires some <a href="http://www.mirc.co.uk/ssl.html" target="_blank">additional steps</a>)</p>
+<p>For clients which do not support SSL you can use a tunnel like
+ <A HREF="http://www.stunnel.org/" TARGET="_blank">stunnel</A>, here's a stunnel.conf example (for stunnel 4.x):<br>
+ <pre>
+ client = yes
+ [irc]
+ accept = 127.0.0.1:6667
+ connect = irc.myserv.com:6697
+</pre>
+ If you then connect to 127.0.0.1 port 6667, your traffic will be encrypted and forwarded to irc.myserv.com
+ port 6697 (an SSL port).</p>
+<p>You should also validate certificates when you connect to servers and not blindly accept them (like in the stunnel example)
+ else you are still vulnerable to "active sniffing" attacks (ssl redirects), that's however too offtopic
+ to explain here (learn about SSL, don't ask us). [mIRC and xchat pop up a window asking you to allow/reject a certificate,
+ so that's good].</p></div>
+<p><font size="+2"><b>3.9 - IPv6</b></font><a name="feature_ipv6"></a></p><div class="desc">
+<p>UnrealIRCd supports IPv6, since beta15 it seems to be stable.<br>
+ Your OS needs to have IPv6 support and you need to enable IPv6 support in UnrealIRCd during ./Config as well.<br>
+<p>Although microsoft has an experimental IPv6 implementation for w2k/XP it is not (yet) supported by UnrealIRCd.</p></div>
+
+<p><font size="+2"><b>3.10 - Zip links</b></font><a name="feature_ziplinks"></a></p><div class="desc">
+<p>Zip links can be turned on for server<->server links, it compresses the data by using zlib.
+ It can save 60-80% bandwidth... So it's quite useful for low-bandwidth links or links with
+ many users, it can help a lot when you are linking since a lot of data is sent about every user/channel/etc.</p>
+<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
+ (on both sides)</p></div>
+
+<p><font size="+2"><b>3.11 - Dynamic DNS/IP linking support</b></font><a name="feature_dyndns"></a></p><div class="desc">
+<p>UnrealIRCd has some (new) nice features which helps dynamic IP users using dynamic DNS (like blah.dyndns.org).
+ If you are linking two dynamic DNS hosts, then set link::options::nodnscache and link::options::nohostcheck.
+</p></div>
+
+<p><font size="+2"><b>3.12 - Anti-Flood features</b></font><a name="feature_antiflood"></a></p><div class="desc">
+<p>
+<b>Throttling</b><br>
+Throttling is a method that allows you to limit how fast a user can disconnect and then reconnect to your server.
+ You can config it in your set::throttle block to allow X connections in YY seconds from the same IP.<br>
+<b>Channel modes</b><br>
+There are also some channel modes which can be very effective against floods. To name a few:<br>
+<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>
+As of beta18 there's also a much more advanced channelmode +f...<br>
+<b>Channel mode f</b><br>
+Instead of using scripts and bots to protect against channel floods it is now build into the ircd.<br>
+An example +f mode is: <i>*** Blah sets mode: +f [10j]:15</i><br>
+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>
+The following floodtypes are available:<br>
+<table border=1 cellpadding=3 cellspacing=1>
+<tr><td>type:</td><td>name:</td><td>default action:</td><td>other avail. actions:</td><td>comments</td></tr>
+<tr><td>c</td><td>CTCPs</td><td>auto +C</td><td>m, M</td><td> </td></tr>
+<tr><td>j</td><td>joins</td><td>auto +i</td><td>R</td><td> </td></tr>
+<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>
+<tr><td>m</td><td>messages/notices</td><td>auto +m</td><td>M</td><td> </td></tr>
+<tr><td>n</td><td>nickchanges</td><td>auto +N</td><td> </td><td> </td></tr>
+<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>
+</table>
+<p />
+Example:
+<pre>
+<font color=green>*** ChanOp sets mode: +f [20j,50m,7n]:15</font>
+<ChanOp> lalala
+<font color=green>*** Evil1 (~fdsdsfddf@Clk-17B4D84B.blah.net) has joined #test
+*** Evil2 (~jcvibhcih@Clk-3472A942.xx.someispcom) has joined #test
+*** Evil3 (~toijhlihs@Clk-38D374A3.aol.com) has joined #test
+*** Evil4 (~eihjifihi@Clk-5387B42F.dfdfd.blablalba.be) has joined #test</font>
+-- snip XX lines --
+<font color=green>*** Evil21 (~jiovoihew@Clk-48D826C3.e.something.org) has joined #test</font>
+<font color=brown>-server1.test.net:#test *** Channel joinflood detected (limit is 20 per 15 seconds), putting +i</font>
+<font color=green>*** server1.test.net sets mode: +i</font>
+<Evil2> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
+<Evil12> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
+<Evil15> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
+<Evil10> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
+<Evil8> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
+-- snip XX lines --
+<font color=brown>-server1.test.net:#test *** Channel msg/noticeflood detected (limit is 50 per 15 seconds), putting +m</font>
+<font color=green>*** server1.test.net sets mode: +m</font>
+<font color=green>*** Evil1 is now known as Hmmm1</font>
+<font color=green>*** Evil2 is now known as Hmmm2</font>
+<font color=green>*** Evil3 is now known as Hmmm3</font>
+<font color=green>*** Evil4 is now known as Hmmm4</font>
+<font color=green>*** Evil5 is now known as Hmmm5</font>
+<font color=green>*** Evil6 is now known as Hmmm6</font>
+<font color=green>*** Evil7 is now known as Hmmm7</font>
+<font color=green>*** Evil8 is now known as Hmmm8</font>
+<font color=brown>-server1.test.net:#test *** Channel nickflood detected (limit is 7 per 15 seconds), putting +N</font>
+<font color=green>*** server1.test.net sets mode: +N</font>
+</pre>
+
+In fact, it can get even more advanced/complicated:<br>
+Instead of the default action, you can for some floodtypes specify another one, for example: <i>+f [20j#R,50m#M]:15</i><br>
+This will set the channel +R if the joinlimit is reached (>20 joins in 15 seconds),
+and will set the channel +M if the msg limit is reached (>50 messages in 15 seconds).<br>
+<br>
+There's also a "remove mode after X minutes" feature: <i>+f [20j#R5]:15</i> will set the channel +R if the
+limit is reached and will set -R after 5 minutes.<br>
+A server can have a default unsettime (set::modef-default-unsettime), so if you type <i>+f [20j]:15</i> it could get
+transformed into <i>+f [20j#i10]:15</i>, it's just a default, you can still set [20j#i2]:15 or something like that,
+and you can also disable the remove-chanmode completely by doing a +f [20j#i0]:15 (an explicit 0).<br>
+<br>
+The old +f mode (msgflood per-user) is also still available as 't', +f 10:6 is now called +f [10t]:6 and
++f *20:10 is now +f [20t#b]:10. Currently the ircd will automatically convert old +f mode types to new ones.
+Note that there's no unsettime feature available for 't' bans ([20t#b30]:15 does not work).<br>
+<br>
+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
+msg a lot (eg: trivia) or do users often use popups? is it some kind of mainchannel or in auto-join? etc..<br>
+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
+it to suit your needs:<br>
++f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15<br>
+30 joins per 15 seconds, if limit is reached set channel +i for 10 minutes<br>
+40 messages per 15 seconds, if limit is reached set channel +m for 10 minutes<br>
+7 ctcps per 15 seconds, if limit is reached set channel +C for 15 minutes<br>
+10 nickchanges per 15 seconds, if limit is reached set channel +N for 15 minutes<br>
+30 knocks per 15 seconds, if limit is reached set channel +K for 10 minutes<br>
+
+If it's some kind of large user channel (>75 users?) you will want to increase the join sensitivity (to eg: 50) and the
+message limit as well (to eg: 60 or 75).<br>
+Especially the remove-mode times are a matter of taste.. you should think like.. what if no op is available to handle
+the situation, do I want to have the channel locked for like 15 minutes (=not nice for users) or 5 minutes (=likely the flooders
+will just wait 5m and flood again). It also depends on the floodtype, users unable to join (+i) or speak (+m) is worse than
+having them unable to change their nick (+N) or send ctcps to the channel (+C) so you might want to use different removal times.
+<br>
+<b>Channel mode j</b><br>
+The +f mode includes a feature to prevent join floods, however this feature is "global." For
+example, if it is set to 5:10 and 5 <u>different</u> users join in 10 seconds, the flood
+protection is triggered. Channel mode +j is different. This mode works on a per-user basis.
+Rather than protecting against join floods, it is designed to protect against join-part floods
+(revolving door floods). The mode takes a parameter of the form X:Y where X is the number of
+joins and Y is the number of seconds. If a user exceeds this limit, he/she will be prevented
+from joining the channel.
+</p></div>
+
+<p><font size="+2"><b>3.13 - Ban types</b></font><a name="feature_bantypes"></a></p><div class="desc">
+<p>
+<b>Basic bantypes and cloaked hosts</b><br>
+UnrealIRCd supports the basic bantypes like <i>+b nick!user@host</i>.<br>
+Also, if a masked host of someone is 'rox-ACB17294.isp.com' and you place a ban *!*@rox-ACB17294.isp.com,
+then if the user sets himself -x (and his hosts becomes for example 'dial-123.isp.com) then the ban
+will still match. Bans are always checked against real hosts AND masked hosts.<br>
+IP bans are also available (eg: *!*@128.*) and are also always checked.<br>
+<br>
+Bans on cloaked IPs require some explanation:<br>
+If a user has the IP 1.2.3.4 his cloaked host could be 341C6CEC.8FC6128B.303AEBC6.IP.<br>
+If you ban *!*@341C6CEC.8FC6128B.303AEBC6.IP you would ban *!*@1.2.3.4 (obvious...)<br>
+If you ban *!*@*.8FC6128B.303AEBC6.IP you ban *!*@1.2.3.*<br>
+If you ban *!*@*.303AEBC6.IP you ban *!*@1.2.*<br>
+This information might be helpful to you when deciding how broad a ban should be.<br>
+<br>
+<b>Extended bantypes</b><br>
+Extended bans look like ~[!]<type>:<stuff>. Currently the following types are available:<br>
+<table border=1>
+<tr><td>type:</td><td>name</td><td>explanation:</td></tr>
+<tr><td>~q</td><td>quiet</td><td>People matching these bans can join but are unable to speak,
+ unless they have +v or higher. <i>Ex: ~q:*!*@blah.blah.com</i></td></tr>
+<tr><td>~n</td><td>nickchange</td><td>People matching these bans cannot change nicks,
+ unless they have +v or higher. <i>Ex: ~n:*!*@*.aol.com</i></td></tr>
+<tr><td>~c</td><td>[prefix]channel</td><td>If the user is in this channel then (s)he is unable to join.
+ A prefix can also be specified (+/%/@/&/~) which means that it will only match if the user has
+ that rights or higher on the specified channel.
+<i>Ex: +b ~c:#lamers, +e ~c:@#trusted </i></td></tr>
+<tr><td>~r</td><td>realname</td><td>If the realname of a user matches this then (s)he is unable to join.<br>
+ <i>Ex: ~r:*Stupid_bot_script*</i><br>
+ NOTE: an underscore ('_') matches both a space (' ') and an underscore ('_'), so this ban would match
+ 'Stupid bot script v1.4'.</td></tr>
+</table>
+These bantypes are also supported in the channel exception list (+e).<br>
+Modules can also add other extended ban types.<br>
+</p></div>
+
+<p><font size="+2"><b>3.14 - Spamfilter</b></font><a name="feature_spamfilter"></a></p><div class="desc">
+<p>Spamfilter is a new system to fight spam, advertising, worms and other things. It works a bit like
+ the badwords system but has several advantages.</p>
+<p>Spamfilters are added via the /spamfilter command which uses the following syntax:<br>
+ <b>/spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [reason] [regex]</b><br>
+ <table border=0>
+ <tr valign="top"><td><b>[type]</b></td><td> specifies the target type:<br>
+ <table>
+ <tr><td><b>Char:</b></td><td><b>Config item:</b></td><td><b>Description:</b></td></tr>
+ <tr><td>c</td><td>channel</td><td>Channel message</td></tr>
+ <tr><td>p</td><td>private</td><td>Private message (from user->user)</td></tr>
+ <tr><td>n</td><td>private-notice</td><td>Private notice</td></tr>
+ <tr><td>N</td><td>channel-notice</td><td>Channel notice</td></tr>
+ <tr><td>P</td><td>part</td><td>Part reason</td></tr>
+ <tr><td>q</td><td>quit</td><td>Quit reason</td></tr>
+ <tr><td>d</td><td>dcc</td><td>DCC filename</td></tr>
+ <tr><td>a</td><td>away</td><td>Away message</td></tr>
+ <tr><td>t</td><td>topic</td><td>Setting a topic</td></tr>
+ <tr><td>u</td><td>user</td><td>User ban, will be matched against nick!user@host:realname</td></tr>
+ </table>
+ You can specify multiple targets, like: cpNn</td></tr>
+ <tr valign="top"><td><b>[action]</b></td><td> specifies the action to be taken (only 1 action can be specified)<br>
+<table>
+<tr><td>kill</td><td>kills the user</td></tr>
+<tr><td>tempshun</td><td>shuns the current session of the user (if [s]he reconnects the shun is gone)</td></tr>
+<tr><td>shun</td><td>puts a shun on the host</td></tr>
+<tr><td>kline</td><td>puts a kline on the host</td></tr>
+<tr><td>gline</td><td>puts a gline on the host</td></tr>
+<tr><td>zline</td><td>puts a zline on the host</td></tr>
+<tr><td>gzline</td><td>puts a gzline (global zline) on the host</td></tr>
+<tr><td>block</td><td>block the message only</td></tr>
+<tr><td>dccblock</td><td>mark the user so (s)he's unable to send any DCCs</td></tr>
+<tr valign="top"><td>viruschan</td><td>part all channels, join set::spamfilter::virus-help-channel, disables all commands
+ except PONG, ADMIN, and msg/notices to set::spamfilter::virus-help-channel</td></tr>
+</table></tr></td>
+ <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
+ (eg: if action = 'block')</td></tr>
+ <tr valign="top"><td><b>[reason]</b></td><td> Block/*line/shun reason.. you CANNOT use spaces in this, but underscores ('_') will be translated
+into spaces at runtime. And double underscore ('__') gets an underscore ('_'). Again, use '-' to use the default reason.</td></tr>
+ <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>
+ </table>
+ <br>
+ Here's an example: <i>/spamfilter add pc gline - - Come watch me on my webcam</i><br>
+ If the text <i>come watch me on my webcam</i> is found in either a private msg or a channel msg
+ then the message will be blocked and a gline will be added immediately.<br>
+ Another example: <i>/spamfilter add pc block - - come to irc\..+\..+</i><br>
+ This is a regex that will match on <i>Hi, come to irc.blah.net</i> etc....<br>
+ And an example with specified time/reason:<br>
+ <i>/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam</i><br>
+ If <i>come watch me on my webcam</i> is found in a private msg then the user is glined for 3 hours
+ with the reason <i>Please go to www.viruscan.xx/nicepage/virus=blah</i>.<br>
+ <br>
+ Spamfilters added with /spamfilter are network-wide. They work regardless of whether the user/channel
+ has mode +G set, only opers and ulines (services) are exempted from filtering.
+</p>
+<p>You can also add spamfilters in the config file but these will be local spamfilters (not
+ network-wide, though you could use remote includes for this).
+ The syntax of these spamfilter { } blocks are explained <a href="#spamfilter">here</a><br>
+ Example:<br>
+ <pre>spamfilter {
+ regex "//write \$decode\(.+\|.+load -rs";
+ target { private; channel; };
+ reason "Generic $decode exploit";
+ action block;
+};</pre></p>
+
+<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>
+ <b>set::spamfilter::ban-reason</b> allows you to specify a default reason (default: 'Spam/advertising')<br>
+ <b>set::spamfilter::virus-help-channel</b> allows you to specify the channel to join for action 'viruschan' (default: #help)<br>
+ <b>set::spamfilter::virus-help-channel-deny</b> allows you to block any normal joins to virus-help-channel (default: no)<br>
+</p>
+<p>
+<font size="+1"><B>Slow Spamfilter Detection</B></font><a name="feature_spamfilter_slow"></a><br>
+A spamfilter regex can slow down the IRCd considerably. This really depends
+on the regex you use (and how the regex engine handles it), some are very
+fast and UnrealIRCd can execute thousands of them per second. Others can be
+extremely slow, take several seconds to execute, and could freeze the IRCd.<br>
+To help against this, Unreal comes with Slow Spamfilter Detection: For each
+spamfilter, Unreal checks, each time it executes, how long it takes to
+execute. Once a certain threshold is reached the IRCd will warn or even remove
+the spamfilter.<br>
+Warning is configured through <b>set::spamfilter::slowdetect-warn</b> (default: 250ms)
+and automatic deletion is configured by <b>set::spamfilter::slowdetect-fatal</b> (default: 500ms).
+You can set both settings to 0 (zero) to disable slow spamfilter detection.<br>
+This feature is currently not available on Windows.<br>
+</p>
+</div>
+
+<p><font size="+2"><b>3.15 - CIDR</b></font><a name="feature_cidr"></a></p><div class="desc">
+<p>UnrealIRCd now has support for CIDR (Classless Interdomain Routing). CIDR allows you to ban
+IP ranges. IPs are allocated to ISPs using CIDR, therefore, being able to set a CIDR based ban
+allows you to easily ban an ISP. Unreal supports CIDR for both IPv4 and IPv6. CIDR masks may be
+used in the allow::ip, oper::from::userhost, ban user::mask, ban ip::mask, except ban::mask,
+except throttle::mask, and except tkl::mask (for gzline, gline, and shun). Additionally, CIDR
+can be used in /kline, /gline, /zline, /gzline, and /shun. Unreal uses the standard syntax of
+IP/bits, e.g., 127.0.0.0/8 (matches 127.0.0.0 - 127.255.255.255), and fe80:0:0:123::/64
+(matches fe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff).</p></div>
+
+<p><font size="+2"><b>3.16 - Nick Character Sets</b></font><a name="feature_nickchars"></a></p><div class="desc">
+<p>UnrealIRCd now has the ability to specify which charsets/languages should be allowed
+in nicknames. You do this in <b>set::allowed-nickchars</b>.<br>
+A table of all possible choices:<br>
+<table border="1">
+<tr><td><b>Name:</b></td><td><b>Description:</b></td><td><b>Character set/encoding:</b></td></tr>
+<tr><td>catalan</td><td>Catalan characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>danish</td><td>Danish characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>dutch</td><td>Dutch characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>french</td><td>French characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>german</td><td>German characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>swiss-german</td><td>Swiss-German characters (no es-zett)</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>icelandic</td><td>Icelandic characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>italian</td><td>Italian characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>spanish</td><td>Spanish characters</td><td>iso8859-1 (latin1)</td></tr>
+<tr><td>swedish</td><td>Swedish characters</td><td>iso8859-1 (latin1)</td></tr>
+<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>
+<tr><td>hungarian</td><td>Hungarian characters</td><td>iso8859-2 (latin2), windows-1250</td></tr>
+<tr><td>polish</td><td>Polish characters</td><td>iso8859-2 (latin2)</td></tr>
+<tr><td>romanian</td><td>Romanian characters</td><td>iso8859-2 (latin2), windows-1250, iso8859-16</td></tr>
+<tr><td><b>latin2</b></td><td>hungarian, polish, romanian</td><td>iso8859-2 (latin2)</td></tr>
+<tr><td>polish-w1250</td><td>Polish characters, windows variant (unfortunately more common than iso)</td><td>windows-1250</td></tr>
+<tr><td>slovak-w1250</td><td>Slovak characters, windows variant</td><td>windows-1250</td></tr>
+<tr><td>czech-w1250</td><td>Czech characters, windows variant</td><td>windows-1250</td></tr>
+<tr><td><b>windows-1250</b></td><td>polish-w1250, slovak-w1250, czech-w1250, hungarian, romanian</td><td>windows-1250</td></tr>
+<tr><td>greek</td><td>Greek characters</td><td>iso8859-7</td></tr>
+<tr><td>turkish</td><td>Turkish characters</td><td>iso8859-9</td></tr>
+<tr><td>russian-w1251</td><td>Russian characters</td><td>windows-1251</td></tr>
+<tr><td>belarussian-w1251</td><td>Belarussian characters</td><td>windows-1251</td></tr>
+<tr><td>ukrainian-w1251</td><td>Ukrainian characters</td><td>windows-1251</td></tr>
+<tr><td><b>windows-1251</b></td><td>russian-w1251, belarussian-w1251, ukrainian-w1251</td><td>windows-1251</td></tr>
+<tr><td>hebrew</td><td>Hebrew characters</td><td>iso8859-8-I/windows-1255</td></tr>
+<tr><td>chinese-simp</td><td>Simplified Chinese</td><td>Multibyte: GBK/GB2312</td></tr>
+<tr><td>chinese-trad</td><td>Tradditional Chinese</td><td>Multibyte: GBK</td></tr>
+<tr><td>chinese-ja</td><td>Japanese Hiragana/Pinyin</td><td>Multibyte: GBK</td></tr>
+<tr><td><b>chinese</b></td><td>chinese-*</td><td>Multibyte: GBK</td></tr>
+<tr><td><b>gbk</b></td><td>chinese-*</td><td>Multibyte: GBK</td></tr>
+</table>
+<p>NOTE 1: Please note that some combinations can cause problems.
+For example, combining latin* and chinese-* can not be properly handled by
+the IRCd and Unreal will print an error.
+Mixing of other charsets might cause display problems, so Unreal will print out
+a warning if you try to mix latin1/latin2/greek/other incompatible groups.</p>
+<p>NOTE 2: Casemapping (if a certain lowercase character belongs to an upper one) is done according to
+US-ASCII, this means that o" and O" are not recognized as 'the same character' and hence someone can
+have a nick with B"ar and someone else BA"r at the same time. This is a limitation of the current system
+and IRCd standards that cannot be solved anytime soon. People should be aware of this limitation.
+Note that this limitation has always also been applied to channels, in which nearly all characters were always
+permitted and US-ASCII casemapping was always performed.</p>
+<p>NOTE 3: The basic nick characters (a-z A-Z 0-9 [ \ ] ^ _ - { | }) are always allowed/included.</p>
+
+Example 1, for people of western europe:<br>
+<pre>set { allowed-nickchars { latin1; }; };</pre>
+Example 2, if you have mainly chinese users and want to allow "normal" chinese characters:<br>
+<pre>set { allowed-nickchars { chinese-simp; chinese-trad; }; };</pre>
+</p></div>
+
+<p><font size="+2"><b>3.17 - CGI:IRC Support</b></font><a name="feature_cgiirc"></a></p><div class="desc">
+<p>UnrealIRCd has support for CGI:IRC host spoofing, which means you can mark specific CGI:IRC
+gateways as "trusted" which will cause the IRCd to show the users' real host/ip everywhere on
+IRC, instead of the host/ip of the CGI:IRC-gateway.</p>
+<p>See the <a href="#cgiirc">cgiirc block</a> for information on how to configure this.</p>
+</div>
+
+<p><font size="+2"><b>3.18 - Time Synchronization</b></font><a name="feature_timesync"></a></p><div class="desc">
+<p>Having correct time is extremely important for IRC servers. Without correct time, channels can desynch, innocent
+users can be killed, channels might not show up properly in /LIST, in short: huge trouble will arrise.</p>
+<p>UnrealIRCd has some build-in time synchronization support.
+Although not optimal (time can still be off a few seconds), it should get rid of most time differences.
+If you can, you are still recommended to run time synchronization software such as ntpd on *NIX or
+the time synchronization service on Windows (in that case, you can turn off Unreal's time synchronization, more on that later).</p>
+<p>What UnrealIRCd does (by default) is do a one-shot timesync attempt when booting. It sends (by default) a request
+to multiple time servers and when it gets the first (fastest) reply, it will adjust the internal ircd clock
+(NOT the system clock). If, for some reason, Unreal does not get a reply from the timeserver within 3 seconds,
+the IRCd will continue to boot regardlessly (should rarely happen).</p>
+<p>Time synchronization is configured (and can be turned off) through the <b>set::timesynch</b> block, see
+ the <a href="#setblock">set documentation</a> for more information.</p>
+</div>
+
+<p><font size="+2"><b>3.19 - Other features</b></font><a name="feature_other"></a></p><div class="desc">
+<p>UnrealIRCd has a lot of features so not everything is covered here... You'll find that out by yourself.</p></div>
+
+<p> </p>
+<p><font size="+2"><b>4.0 - Configuring your unrealircd.conf</b></font>
+ <a name="configuringyourunrealircdconf"></a></p><div class="desc">
+<p>First of all, creating your first unrealircd.conf will take time (say, 15-60
+minutes). Creating a <u>good</u> unrealircd.conf will take even more time.
+You should not rush to get the IRCd booted, but rather go through things
+step-by-step. If you have any problems, check your syntax, check this manual
+and check the <a href="http://www.vulnscan.org/UnrealIRCd/faq/">FAQ</a> before asking for help/reporting a bug.</p></div>
+<p><b><font size="+2">4.1 Configuration File Explained</font></b><a name="configurationfileexplained"></a><br><div class="desc">
+</p>
+<p>The new system uses a block-based format. Each entry, or block, in the new
+ format has a specific format. The format works like:</p>
+<pre>
+<block-name> <block-value> {
+ <block-directive> <directive-value>;
+};
+</pre></p>
+<p><block-name> is the type of block, such as me, or admin. <block-value>
+ sometimes specifies a value, such as /oper login, but other times it will be
+ a sub-type such as in ban user.</p>
+<p><block-directive> is an individual variable specific to the block, and
+ <directive-value> is the Associated value. If <directive-value>
+ contains spaces, or characters that represents a comment it must be contained
+ in double quotes. If you want to use a quote character inside a quoted string
+ use \" and it will be understood as a quote character.</p>
+<p> A <block-directive> can have directives within it, if that’s the
+ case it will have it's own set of curly braces surrounding it. Some blocks do
+ not have directives and are specified just by <block-value>, such as include.
+ Also note that there is no set format, meaning the whole block can appear on
+ one line or over multiple lines. The format above is what is normally used (and
+ what will be used in this file) because it is easy to read. </p>
+<p>Note: the configuration file is currently case sensitive so <i>BLOCK-NAME</i> is not
+ the same as <i>block-name</i>. There is a special notation used to talk about entries
+ in the config file. For example, to talk about <directive-name> in the
+ example above, you'd say <block-name>::<block-directive>, and if
+ that directive has a sub block you want to reverence, you would add another
+ :: and the name of the sub directive. </p>
+<p>To talk about an unnamed directive you would do <block-name>:: which
+ would in this case mean <block-value>, or it could be an entry in a sub
+ block that has no name.</p>
+<p>Three types of comments are supported:</p>
+<p> # One line comment<br>
+ // One line comment<br>
+ /* Multi line<br>
+ comment */<br>
+ </p>
+<p>Now that you know how it works, copy <i>doc/example.conf</i> to your UnrealIRCd
+ directory (eg: /home/user/Unreal3.2) and rename it to <i>unrealircd.conf</i>
+ (OR create your <i>unrealircd.conf</i> from scratch).
+ It's recommended to walk step by step through all block types and
+ settings in your conf and use this manual as a reference.</p>
+<p></p></div>
+<p><font class="block_section">4.2 - </font><font class="block_name">Me Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the M:Line)</font><a name="meblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+me {
+ name <name-of-server>;
+ info <server-description>;
+ numeric <server-numeric>;
+};
+</pre></p>
+<p>These values are pretty obvious. The <b>name</b> specifies the name of the server,
+ <b>info</b> specifies the server's info line, <b>numeric</b> specifies a numeric to
+ identify the server. This must be a value between 0 and 254 that is UNIQUE to
+ the server meaning NO other servers on the network may have the same numeric.</p>
+<p>Example:<br>
+<pre>
+me {
+ name "irc.foonet.com";
+ info "FooNet Server";
+ numeric 1;
+};
+</pre></p></div>
+<p></p>
+<p><font class="block_section">4.3 - </font><font class="block_name">Admin Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the A:Line)</font><a name="adminblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+admin {
+ <text-line>;
+ <text-line>;
+};
+</pre></p>
+<p> </p>
+<p>The admin block defines the text displayed in a /admin request. You can specify
+ as many lines as you want and they can contain whatever information you
+ choose, but it is standard to include the admins nickname and email address
+ at a minimum. Other information may include any other contact information you
+ wish to give.</p>
+<p>Example:<br>
+<pre>
+admin {
+ "Bob Smith";
+ "bob";
+ "widely@used.name";
+};
+</pre></p></div>
+<p></p>
+<p><font class="block_section">4.4 - </font><font class="block_name">Class Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the Y:Line)</font><a name="classblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+class <name> {
+ pingfreq <ping-frequency>;
+ connfreq <connect-frequency>;
+ maxclients <maximum-clients>;
+ sendq <send-queue>;
+ recvq <recv-queue>;
+};
+</pre></p>
+<p> </p>
+<p>Class blocks are classes in which connections will be placed (for example from allow blocks
+ or servers from link blocks), you generally have multiple class blocks (ex: for servers, clients, opers).</p>
+<p><b>name</b> is the descriptive name, like "clients" or "servers", this name is
+ used for referring to this class from allow/link/oper/etc blocks</p>
+<p><b>pingfreq</b> is the number of seconds between PINGs from the server (something between 90 and 180 is recommended).</p>
+<p><b>connfreq</b> is used only for servers and is the number of seconds between connection attempts if autoconnect is enabled</p>
+<p><b>maxclients</b> specifies the maximum (total) number of clients/servers which can be in this class</p>
+<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>
+<p><b>recvq</b> specifies the amount of data which can be in the receive queue and is used for flood control
+ (this only applies to normal users, try experimenting with values 3000-8000, 8000 is the default).</p>
+<p>Examples:<br>
+<pre>
+class clients {
+ pingfreq 90;
+ maxclients 500;
+ sendq 100000;
+ recvq 8000;
+};
+
+class servers {
+ pingfreq 90;
+ maxclients 10; /* Max servers we can have linked at a time */
+ sendq 1000000;
+ connfreq 100; /* How many seconds between each connection attempt */
+};
+</pre></p>
+<p> </p></div>
+<p><font class="block_section">4.5 - </font><font class="block_name">Allow Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the I:Line)</font><a name="allowblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+allow {
+ ip <user@ip-connection-mask>;
+ hostname <user@host-connection-mask>;
+ class <connection-class>;
+ password <connection-password> { <auth-type>; };
+ maxperip <max-connections-per-ip>;
+ redirect-server <server-to-forward-to>;
+ redirect-port <port-to-forward-to>;
+ options {
+ <option>;
+ <option>;
+ ...
+ };
+};
+</pre></p>
+<p>The allow class is where you specify who may connect to this server, you can have multiple allow blocks.</p>
+<p><b>About matching</b><br>
+ The access control works like this: ip matches OR host matches, so "hostname *@*"; and "ip *@1.2.3.4"
+ will mean it will always match. Also the allow blocks are read upside down, so you need specific host/ip allow blocks
+ AFTER your general *@* allow blocks. Additionally, if you want to setup a block that only matches based on IP, then set
+ the hostname to something invalid, such as "hostname NOBODY;", this will allow the block to only match based on IP.</p>
+<p><b>ip</b><br>
+ The ip mask is in the form user@ip, user is the ident and often set at *, ip is the ipmask.
+ Some examples: *@* (from everywhere), *@192.168.* (only from addr's starting with 192.168), etc.</p>
+<p><b>host</b><br>
+ Also a user@host hostmask, again.. user is often set at *. Some examples: *@* (everywhere),
+ *@*.wanadoo.fr (only from wanadoo.fr).</p>
+<p><b>password</b> (optional)<br>
+ Require a connect password. You can also specify an password encryption method here.
+</p>
+<p><b>class</b><br>
+ Specifies the class name that connections using this allow block will be placed into.
+</p>
+<p><b>maxperip</b> (optional, but recommended)<br>
+ Allows you to specify how many connections per IP are allowed to this server (ex: maxperip 4;).
+</p>
+<p><b>redirect-server</b> (optional)<br>
+ If the class is full, redirect users to this server (if clients supports it [mIRC 6 does]).</p>
+<p><b>redirect-port</b> (optional)<br>
+ If redirect-server is specified you can set the port here, otherwise 6667 is assumed.</p>
+<p><b>options block</b> (optional)<br>
+ Valid options are:<br>
+ <b>useip</b> always display IP instead of hostname<br>
+ <b>noident</b> don't use ident but use username specified by client<br>
+ <b>ssl</b> only match if this client is connected via SSL<br>
+ <b>nopasscont</b> continue matching if no password was given (so you can put clients in special classes
+if they supply a password).
+<p>Examples:<br>
+<pre>
+allow {
+ ip *;
+ hostname *;
+ class clients;
+ maxperip 5;
+};
+
+allow {
+ ip *@*;
+ hostname *@*.passworded.ugly.people;
+ class clients;
+ password "f00Ness";
+ maxperip 1;
+};
+</pre></p></div>
+<p> </p>
+<p><font class="block_section">4.6 - </font><font class="block_name">Listen Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as the P:Line)</font><a name="listenblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+listen <ip:port> {
+ options {
+ <option>;
+ <option>;
+ ...
+ };
+};
+</pre></p>
+<p> </p>
+<p>This block allows you to specify the ports on which the IRCD will listen. If
+ no options are required, you may specify this without any directives in the
+ form listen <ip:port>;.</p>
+<p><b>ip and port</b><br>
+ 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).
+ The port is the port you want to listen on. You can also set the port to a range rather than an individual
+ value. For example, 6660-6669 would listen on ports 6660 through 6669 (inclusive). IPv6 users, see below.</p>
+<p><b>Info for IPv6 users</b><br>
+ If you have an IPv6 enabled server you need to enclose the IP in brackers.
+ Like [::1]:6667 (listen at localhost on port 6667). If you are using IPv6 and you
+ want to listen at a specific IPv4 addr you need to use ::ffff:ipv4ip. For example:
+ [::ffff:203.123.67.1]:6667 which will listen at 203.123.67.1 on port 6667.
+ Of course you can also just use *.</p>
+<p><b>options block</b> (optional)<br>
+ You can specify special options for this port if you want, valid options are:<br>
+<table border="0">
+<TR><TD><center><b>clientsonly</b></center></TD><TD> port is only for clients</TD></TR>
+<TR><TD><center><b>serversonly</b></center></TD><TD> port is only for servers</TD></TR>
+<TR><TD><center><b>java</b></center></TD><TD> CR javachat support</TD></TR>
+<TR><TD><center><b>ssl</b></center></TD><TD> SSL encrypted port</TD></TR>
+</table>
+</p>
+
+<p>Examples:</p>
+<pre>
+listen *:6601 {
+ options {
+ ssl;
+ clientsonly;
+ };
+};
+
+</pre></p>
+<p>Or if there are no options:</p>
+<p>listen *:8067;<br>
+ listen 213.12.31.126:6667;<br>
+ listen *:6660-6669;</p></div>
+<p><font class="block_section">4.7 - </font><font class="block_name">Oper Block</font>
+ <font class="block_recommended">RECOMMENDED</font> <font class="block_old">(Previously known as the O:Line)</font><a name="operblock"></a><div class="desc">
+</p>
+<p>
+<pre>oper <name> {
+ from {
+ userhost <hostmask>;
+ userhost <hostmask>;
+ };
+ password <password> { <auth-type>; };
+ class <class-name>;
+ flags <flags>;
+ flags {
+ <flag>;
+ <flag>;
+ ...
+ };
+ swhois <whois info>;
+ snomask <snomask>;
+ modes <modes>;
+ maxlogins <num>;
+};
+</pre></p>
+<p>The oper block allows you to assign IRC Operators for your server. The <b>oper::</b>
+ specifies the login name for the /oper. The <b>oper::from::userhost</b> is a user@host
+ mask that the user must match, you can specify more than one hostmask by creating
+ more than one oper::from::userhost. The <b>oper::password</b> is the password the user
+ must specify, oper::password:: allows you to specify an authentication method
+ for this password, valid auth-types are crypt, md5, and sha1, ripemd-160. If
+ you want to use a plain-text password leave this sub-block out.</p>
+<p>Please note that BOTH the login name and password are case sensitive</p>
+<p>The <b>oper::class</b> directive specifies the name of a preexisting (appears before
+ this in the config file) class name that the oper block will use.</p>
+<p>The <b>oper::flags</b> directive has two formats. If you wish to use the old style
+ oper flags i.e., OAa, you use the flags <flags> method, if you want to
+ use the new style,i.e., services-admin, then you use the flags { <flag>;
+ } method. Below is a list of all the flags (in both formats) and what they do.</p>
+<table width="75%" border="1">
+ <tr>
+ <td width="10%"><div align="center"><b>Old Flag</b></div></td>
+ <td width="16%"><div align="center"><b>New Flag</b></div></td>
+ <td width="74%"><b>Description</b></td>
+ </tr>
+ <tr>
+ <td height="24"><div align="center">o</div></td>
+ <td><div align="center">local</div></td>
+ <td>Makes you a local operator</td>
+ </tr>
+ <tr>
+ <td><div align="center">O</div></td>
+ <td><div align="center">global</div></td>
+ <td>Makes you a global operator</td>
+ </tr>
+ <tr>
+ <td><div align="center">C</div></td>
+ <td><div align="center">coadmin</div></td>
+ <td>Makes you a coadmin</td>
+ </tr>
+ <tr>
+ <td><div align="center">A</div></td>
+ <td><div align="center">admin</div></td>
+ <td>Makes you a admin</td>
+ </tr>
+ <tr>
+ <td><div align="center">a</div></td>
+ <td><div align="center">services-admin</div></td>
+ <td>Makes you a services admin</td>
+ </tr>
+ <tr>
+ <td><div align="center">N</div></td>
+ <td><div align="center">netadmin</div></td>
+ <td>Makes you a Network Admin</td>
+ </tr>
+ <tr>
+ <td><div align="center">r</div></td>
+ <td><div align="center">can_rehash</div></td>
+ <td>Oper may use /rehash</td>
+ </tr>
+ <tr>
+ <td><div align="center">D</div></td>
+ <td><div align="center">can_die</div></td>
+ <td>Oper may use /die</td>
+ </tr>
+ <tr>
+ <td><div align="center">R</div></td>
+ <td><div align="center">can_restart</div></td>
+ <td>Oper may use /restart</td>
+ </tr>
+ <tr>
+ <td><div align="center">h</div></td>
+ <td><div align="center">helpop</div></td>
+ <td>Oper receives umode +h (helpop)</td>
+ </tr>
+ <tr>
+ <td><div align="center">w</div></td>
+ <td><div align="center">can_wallops</div></td>
+ <td>Oper can send /wallops</td>
+ </tr>
+ <tr>
+ <td><div align="center">g</div></td>
+ <td><div align="center">can_globops</div></td>
+ <td>Oper can send /globops</td>
+ </tr>
+ <tr>
+ <td><div align="center">c</div></td>
+ <td><div align="center">can_localroute</div></td>
+ <td>Can connect servers locally</td>
+ </tr>
+ <tr>
+ <td><div align="center">L</div></td>
+ <td><div align="center">can_globalroute</div></td>
+ <td>Can connect servers globally</td>
+ </tr>
+ <tr>
+ <td><div align="center">k</div></td>
+ <td><div align="center">can_localkill</div></td>
+ <td>Can /kill local users</td>
+ </tr>
+ <tr>
+ <td><div align="center">K</div></td>
+ <td><div align="center">can_globalkill</div></td>
+ <td>Can /kill global users</td>
+ </tr>
+ <tr>
+ <td><div align="center">b</div></td>
+ <td><div align="center">can_kline</div></td>
+ <td>Can use /kline</td>
+ </tr>
+ <tr>
+ <td><div align="center">B</div></td>
+ <td><div align="center">can_unkline</div></td>
+ <td>Can use /kline -u@h</td>
+ </tr>
+ <tr>
+ <td><div align="center">n</div></td>
+ <td><div align="center">can_localnotice</div></td>
+ <td>Can send local server notices</td>
+ </tr>
+ <tr>
+ <td><div align="center">G</div></td>
+ <td><div align="center">can_globalnotice</div></td>
+ <td>Can send global server notices</td>
+ </tr>
+ <tr>
+ <td><div align="center">z</div></td>
+ <td><div align="center">can_zline</div></td>
+ <td>Can use /zline</td>
+ </tr>
+ <tr>
+ <td><div align="center">t</div></td>
+ <td><div align="center">can_gkline</div></td>
+ <td>Can use /gline, /shun and /spamfilter</td>
+ </tr>
+ <tr>
+ <td><div align="center">Z</div></td>
+ <td><div align="center">can_gzline</div></td>
+ <td>Can use /gzline</td>
+ </tr>
+ <tr>
+ <td><div align="center">W</div></td>
+ <td><div align="center">get_umodew</div></td>
+ <td>Sets umode +W when u oper</td>
+ </tr>
+ <tr>
+ <td><div align="center">H</div></td>
+ <td><div align="center">get_host</div></td>
+ <td>Sets your host to an oper host</td>
+ </tr>
+ <tr>
+ <td><div align="center">v</div></td>
+ <td><div align="center">can_override</div></td>
+ <td>Can use <a href="#operoverride">OperOverride</a></td>
+ </tr>
+ <tr>
+ <td><div align="center">q</div></td>
+ <td><div align="center">can_setq</div></td>
+ <td>Can use usermode +q</td>
+ </tr>
+ <tr>
+ <td><div align="center">X</div></td>
+ <td><div align="center">can_addline</div></td>
+ <td>Can use /addline</td>
+ </tr>
+ <tr>
+ <td><div align="center">d</div></td>
+ <td><div align="center">can_dccdeny</div></td>
+ <td>Can use /dccdeny and /undccdeny</td>
+ </tr>
+</table>
+<p>Certain flags give you other flags by default:</p>
+<table width="59%" border="1">
+ <tr>
+ <td width="19%"><b>local</b></td>
+ <td width="17%"><b>global</b></td>
+ <td width="19%"><b>admin/coadmin</b></td>
+ <td width="22%"><b>services-admin</b></td>
+ <td width="23%"><b>netadmin</b></td>
+ </tr>
+ <tr>
+ <td>can_rehash</td>
+ <td>can_rehash</td>
+ <td>can_rehash</td>
+ <td>can_rehash</td>
+ <td>can_rehash</td>
+ </tr>
+ <tr>
+ <td>helpop</td>
+ <td>helpop</td>
+ <td>helpop</td>
+ <td>helpop</td>
+ <td>helpop</td>
+ </tr>
+ <tr>
+ <td>can_globops</td>
+ <td>can_globops</td>
+ <td>can_globops</td>
+ <td>can_globops</td>
+ <td>can_globops</td>
+ </tr>
+ <tr>
+ <td>can_wallops</td>
+ <td>can_wallops</td>
+ <td>can_wallops</td>
+ <td>can_wallops</td>
+ <td>can_wallops</td>
+ </tr>
+ <tr>
+ <td>can_localroute</td>
+ <td>can_localroute</td>
+ <td>can_localroute</td>
+ <td>can_localroute</td>
+ <td>can_localroute</td>
+ </tr>
+ <tr>
+ <td>can_localkill</td>
+ <td>can_localkill</td>
+ <td>can_localkill</td>
+ <td>can_localkill</td>
+ <td>can_localkill</td>
+ </tr>
+ <tr>
+ <td>can_kline</td>
+ <td>can_kline</td>
+ <td>can_kline</td>
+ <td>can_kline</td>
+ <td>can_kline</td>
+ </tr>
+ <tr>
+ <td>can_unkline</td>
+ <td>can_unkline</td>
+ <td>can_unkline</td>
+ <td>can_unkline</td>
+ <td>can_unkline</td>
+ </tr>
+ <tr>
+ <td>can_localnotice</td>
+ <td>can_localnotice</td>
+ <td>can_localnotice</td>
+ <td>can_localnotice</td>
+ <td>can_localnotice</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td>can_globalroute</td>
+ <td>can_globalroute</td>
+ <td>can_globalroute</td>
+ <td>can_globalroute</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td>can_globalkill</td>
+ <td>can_globalkill</td>
+ <td>can_globalkill</td>
+ <td>can_globalkill</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td>can_globalnotice</td>
+ <td>can_globalnotice</td>
+ <td>can_globalnotice</td>
+ <td>can_globalnotice</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td> </td>
+ <td>global</td>
+ <td>global</td>
+ <td>global</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td> </td>
+ <td>can_dccdeny</td>
+ <td>can_dccdeny</td>
+ <td>can_dccdeny</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td> </td>
+ <td> </td>
+ <td>can_setq</td>
+ <td>can_setq</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td> </td>
+ <td> </td>
+ <td> </td>
+ <td>admin</td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td> </td>
+ <td> </td>
+ <td> </td>
+ <td>services-admin</td>
+ </tr>
+</table>
+<p>The <b>oper::swhois</b> directive allows you to add an extra line to an opers whois
+ information. <font color=blue>[optional]</font></p>
+<p>The <b>oper::snomask</b> directive allows you to preset an oper's server notice mask
+ on oper up. For a list of available SNOMASKs, see <a href="#feature_snomasks">Section 3.3</a>
+ <font color=blue>[optional]</font></p>
+<p>The <b>oper::modes</b> directive allows you to preset an oper's modes on oper up.
+ <font color=blue>[optional]</font></p>
+<p>The <b>oper::maxlogins</b> allows you to restrict the number of concurrent oper logins from this host,
+ for example if you set it to 1 then only 1 person can be oper'ed via this block at any time.
+ <font color=blue>[optional]</font></p>
+
+<p>Example:<br>
+<pre>
+oper bobsmith {
+ class clients;
+ from {
+ userhost bob@smithco.com;
+ userhost boblaptop@somedialupisp.com;
+ };
+ password "f00";
+ flags {
+ netadmin;
+ can_gkline;
+ can_gzline;
+ can_zline;
+ can_restart;
+ can_die;
+ global;
+ };
+ swhois "Example of a whois mask";
+ snomask frebWqFv;
+};
+</pre></p>
+<a name="operoverride"><b>Some little info about OperOverride:</b><br>
+OperOverride are things like: joining a +ikl channel and going through bans (you need to /invite yourself first however),
+op'ing yourself in a channel, etc.<br>
+The can_override operflag was added as an attempt to stop oper abuse.
+No oper is able to override by default, you would have to give them the can_override flag explicitly.
+<p> </p></div>
+<p><font class="block_section">4.8 - </font><font class="block_name">DRpass Block</font>
+ <font class="block_recommended">RECOMMENDED</font> <font class="block_old">(Previously known as the X:Line)</font><a name="drpassblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+drpass {
+ restart <restart-password> { <auth-type>; };
+ die <die-password> { <auth-type>; };
+};</pre></p>
+<p>This block sets the /restart and /die passwords with drpass::restart and drpass::die
+ respectively. The drpass::restart:: and drpass::die:: allow you to specify the
+ type of authentication used by this item. The currently supported authentication
+ types are crypt, md5, and sha1, ripemd-160.</p>
+<p>Example:</p>
+<pre>
+drpass {
+ restart "I-love-to-restart";
+ die "die-you-stupid";
+};
+</pre></p>
+<p> </p></div>
+<p><font class="block_section">4.9 - </font><font class="block_name">Include Directive</font><a name="includedirective"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+ include <file-name>;</p>
+<p>This directive specifies a filename to be loaded as a separate configuration
+ file. This file may contain any type of config block and can even include other
+ files. Wildcards are supported in the file name to allow you to load multiple
+ files at once.</p>
+<p><b>example 1: a network file</b><br>
+ <pre>include mynetwork.network;</pre></p>
+<p>That would be the statement to use if you wanted to use a separate network
+ file. Separate network files are no longer required; all the network settings
+ can be inserted directly into the unrealircd.conf. Or you can put an include
+ statement them to load the file.</p>
+<p><b>example 2: aliases</b><br>
+ <pre>include aliases/ircservices.conf</pre></p>
+<p>Another example is to use it for including alias blocks, UnrealIRCd comes with
+ some files which (should) contain the right aliases for most services:<br>
+<ul>
+<li>aliases/ircservices.conf (IRCServices, Daylight)
+<li>aliases/epona.conf (Epona)
+<li>aliases/anope.conf (Anope)
+<li>aliases/auspice.conf (Auspice)
+<li>aliases/generic.conf (Magick, Sirius, Wrecked)
+<li>aliases/cygnus.conf (Cygnus)
+<li>aliases/operstats.conf (OperStats)
+<li>aliases/genericstats.conf (GeoStats, NeoStats)
+</ul>
+</p>
+<p></p></div>
+<p><font class="block_section">4.10 - </font><font class="block_name">LoadModule Directive</font>
+ <font class="block_required">REQUIRED</font><a name="loadmoduledirective"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+ loadmodule <file-name>;</p>
+<p>See <a href="#feature_modules">here</a> why modules are nice/useful.</p>
+<p>Modules that come standard with Unreal3.2:</p>
+<p>commands.so / commands.dll - All the / commands (well not all yet, but will eventually be all) <font color="red">REQUIRED</font><br>
+ cloak.so / cloak.dll - Cloaking module <font color="red">REQUIRED</font> (or any other cloaking module)</p>
+<p>So you want to be sure to have these loaded:</p>
+<pre>
+loadmodule "src/modules/commands.so";
+loadmodule "src/modules/cloak.so";
+</pre>
+<p>or on windows:</p>
+<pre>
+loadmodule "modules/commands.dll";
+loadmodule "modules/cloak.dll";
+</pre>
+</div>
+<p><font class="block_section">4.11 - </font><font class="block_name">Log Block</font>
+ <font class="block_recommended">RECOMMENDED</font><a name="logblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+log <file-name> {
+ maxsize <max-file-size>;
+ flags {
+ <flag>;
+ <flag>;
+ ...
+ };
+};
+</pre></p>
+<p>The log block allows you to assign different log files for different purposes.
+ The <b>log::</b> contains the name of the log file. <b>log::maxsize</b> is an optional directive
+ that allows you to specify a size that the log file will be wiped and restarted.
+ You can enter this string using MB for megabytes, KB, for kilobytes, GB, for
+ gigabytes. The <b>log::flags</b> specifies which types of information will be in this
+ log. See the list of available flags below.</p>
+<p>You may also have multiple log blocks, to log different things to different
+ log files.</p>
+<p><b>Available Flags:</b><br>
+ <table border=0>
+ <tr><td>errors</td><td>self explanatory</td></tr>
+ <tr><td>kills</td><td>logs /kill notices</td></tr>
+ <tr><td>tkl</td><td>logs info on *lines, shuns and spamfilters (adding/removing/expire)</td></tr>
+ <tr><td>connects</td><td>logs user connects/disconnects</td></tr>
+ <tr><td>server-connects</td><td>logs server connects/squits</td></tr>
+ <tr><td>kline</td><td>logs /kline usage</td></tr>
+ <tr><td>oper</td><td>logs oper attempts (both failed and successful)</td></tr>
+ <tr><td>sadmin-commands</td><td>logs /sa* (samode, sajoin, sapart, etc.) usage</td></tr>
+ <tr><td>chg-commands</td><td>logs /chg* (chghost, chgname, chgident, etc.) usage</td></tr>
+ <tr><td>oper-override</td><td>logs operoverride usage</td></tr>
+ <tr><td>spamfilter</td><td>logs spamfilter matches</td></tr>
+ </table>
+</p>
+
+<p>Example:</p>
+<pre>
+log ircd.log {
+ maxsize 5MB;
+ flags {
+ errors;
+ kills;
+ oper;
+ kline;
+ tkl;
+ };
+};
+</pre></p>
+<p></p></div>
+<p><font class="block_section">4.12 - </font><font class="block_name">TLD Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the T:Line)</font><a name="tldblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+tld {
+ mask <hostmask>;
+ motd <motd-file>;
+ rules <rules-file>;
+ shortmotd <shortmotd-file>;
+ opermotd <opermotd-file>;
+ botmotd <botmotd-file>;
+ channel <channel-name>;
+ options {
+ ssl;
+ };
+};</pre></p>
+<p>The tld block allows you to specify a motd, rules, and channel for a user based
+ on their host. This is useful if you want different motds for different languages.
+ The <b>tld::mask</b> is a user@host mask that the user's username and hostname must
+ match. The <b>tld::motd</b>, <b>tld::shortmotd</b>, <b>tld::opermotd</b>,
+ <b>tld::botmotd</b>, and <b>tld::rules</b> specify the motd, shortmotd, opermotd,
+ botmotd, and rules file, respectively, to be displayed to this hostmask.
+ The tld::shortmotd, tld::opermotd, and tld::botmotd are optional. <b>tld::channel</b>
+ is optional as well, it allows you to specify a channel that this user will be forced
+ to join on connect. If this exists it will override the default auto join channel.
+ The <b>tld::options</b> block allows you to define additional requirements,
+ currently only tld::options::ssl which only displays the file for SSL users, and
+ tld::options::remote which only displays the file for remote users, exists.</p>
+<p>TLD entries are matched upside down</p>
+<p>Example:<br>
+<pre>
+tld {
+ mask *@*.fr;
+ motd "ircd.motd.fr";
+ rules "ircd.rules.fr";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.13 - </font><font class="block_name">Ban Nick Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the Q:Line)</font><a name="bannickblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban nick {<br>
+ mask <nickname>;
+ reason <reason-for-ban>;
+};</pre></p>
+<p>The ban nick block allows you to disable use of a nickname on the server. The
+ ban::mask allows wildcard masks to match multiple nicks, and ban::reason allows
+ you to specify the reason for which this ban is placed. Most commonly these
+ blocks are used to ban usage of the nicknames commonly used for network services.</p>
+<p>Example:<br>
+<pre>
+ban nick {
+ mask "*C*h*a*n*S*e*r*v*";
+ reason "Reserved for Services";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.14 - </font><font class="block_name">Ban User Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the K:Line)</font><a name="banuserblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban user {
+ mask <hostmask>;
+ reason <reason-for-ban>;
+};</pre></p>
+<p>This block allows you to ban a user@host mask from connecting to the server.
+ The ban::mask is a wildcard string of a user@host to ban, and ban::reason is
+ the reason for a ban being placed. Note, this is only a local ban and therefore
+ the user may connect to other servers on the network.</p>
+<p>Example:<br>
+<pre>
+ban user {
+ mask *tirc@*.saturn.bbn.com;
+ reason "Idiot";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.15 - </font><font class="block_name">Ban IP Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the Z:Line)</font><a name="banipblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban ip {
+ mask <ipmask>;
+ reason <reason-for-ban>;
+};</pre></p>
+<p>The ban ip block bans an IP from accessing the server. This includes both users
+ and servers attempting to link. The ban::mask parameter is an IP which may contain
+ wildcard characters, and ban::reason is the reason why this ban is being placed.
+ Since this ban affects servers it should be used very carefully.</p>
+<p>Example:<br>
+<pre>
+ban ip {
+ mask 192.168.1.*;
+ reason "Get a real ip u lamer!";
+};</pre></p>
+<p> </p></div>
+<p><font class="block_section">4.16 - </font><font class="block_name">Ban Server Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the q:Line)</font><a name="banserverblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban server {
+ mask <server-name>;
+ reason <reason-for-ban>;
+};</pre></p>
+<p>This block disables a server's ability to connect to the network. If the server links
+ directly to your server, the link is denied. If the server links to a remote server, the
+ local server will disconnect from the network. The ban::mask field specifies a wildcard
+ mask to match against the server attempting to connect's name, and ban::reason specifies
+ the reason for which this ban has been placed.</p>
+<p>Example:<br>
+<pre>
+ban server {
+ mask broken.server.my.network.com;
+ reason "Its broken!";
+};</pre></p>
+<p> </p></div>
+<p><font class="block_section">4.17 - </font><font class="block_name">Ban RealName Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the n:Line)</font><a name="banrealnameblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban realname {
+ mask <realname-mask>;
+ reason <reason-for-ban>;
+};</pre></p>
+<p>The ban realname block allows you to ban a client based on the GECOS (realname)
+ field. This is useful to stop clone floods because often clone bots use the
+ same realname. The ban::mask specifies the realname which should be banned.
+ The mask may contain wildcards. The ban::reason specifies the reason why this
+ ban is being placed.</p>
+<p>Example:<br>
+<pre>
+ban realname {
+ mask "Bob*";
+ reason "Bob sucks!";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.18 - </font><font class="block_name">Ban Version Block</font>
+ <font class="block_optional">OPTIONAL</font> <a name="banversionblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ban version {
+ mask <version-mask>;
+ reason <reason-for-ban>;
+ action [kill|tempshun|shun|kline|zline|gline|gzline];
+};</pre></p>
+<p>The ban version block allows you to ban a client based on the IRC client software they use.
+ This makes use of the clients CTCP version reply. Therefore if a client does not
+ send out a CTCP version, the ban will not work. This feature is intended to allow you to block
+ malicious scripts. The <b>ban::mask</b> specifies the version which should be banned.
+ The mask may contain wildcards. The <b>ban::reason</b> specifies the reason why this
+ ban is being placed. You can also specify <b>ban::action</b>, <i>kill</i> is the default,
+ <i>tempshun</i> will shun the specific user connection only and would work very effective against
+ zombies/bots at dynamic IPs because it won't affect innocent users. <i>shun/kline/zline/gline/gzline</i>
+ will place a ban of that type on the ip (*@IPADDR), the duration of these bans can be configured
+ with set::ban-version-tkl-time and defaults to 1 day.</p>
+<p>Example:<br>
+<pre>
+ban version {
+ mask "*SomeLameScript*";
+ reason "SomeLameScript contains backdoors";
+};</pre>
+<pre>
+ban version {
+ mask "*w00tZombie*";
+ reason "I hate those hundreds of zombies";
+ action zline;
+};</pre>
+</p>
+<p></p></div>
+<p><font class="block_section">4.19 - </font><font class="block_name">Ban Exceptions Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the E:Line)</font><a name="banexceptionblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+except ban {
+ mask <hostmask>;
+};</pre></p>
+<p>The except ban block allows you to specify a user@host that will override a
+ ban placed on a broader host. This is useful when you want an ISP banned, but
+ still want specific users to be able to connect. The except::mask directive
+ specifies the user@host mask of the client who will be allowed to connect.</p>
+<p>Example:<br>
+<pre>
+except ban {
+ mask myident@my.isp.com;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.20 - </font><font class="block_name">TKL Exceptions Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="tklexceptionblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+except tkl {
+ mask <hostmask>;
+ type <type>;
+ type {
+ <type>;
+ <type>;
+ ...
+ };
+};</pre></p>
+<p>The except tkl block allows you to specify a user@host that will override a
+ tkl ban placed on a broader host. This is useful when you want an ISP banned, but
+ still want specific users to be able to connect. The except::mask directive
+ specifies the user@host mask of the client who will be allowed to connect. The
+ except::type specifies which type of ban this should override. Valid types are
+ gline, gzline, qline, gqline, and shun, which make an exception from Glines,
+ Global Zlines, Qlines, Global Qlines, and shuns. If the type {} format is used,
+ multiple types may be specified.</p>
+<p>Example:<br>
+<pre>
+except tkl {
+ mask myident@my.isp.com;
+ type gline;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.21 - </font><font class="block_name">Throttle Exceptions Block</font>
+ <font class="block_optional">OPTIONAL</font> <a name="throttleexceptionblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+except throttle {
+ mask <ipmask>;
+};</pre></p>
+<p>The except throttle block allows you to specify an IP mask that will override the
+ throttling system. This only works if you have chosen to enable throttling. The
+ except::mask specifies an IP mask that will not be banned because of throttling.</p>
+<p>Example<br>
+<pre>
+except throttle {
+ mask 192.168.1.*;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.22 - </font><font class="block_name">Deny DCC Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as dccdeny.conf)</font><a name="denydccblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+deny dcc {
+ filename <file-to-block>;
+ reason <reason-for-ban>;
+ soft [yes|no];
+};</pre></p>
+<p>The deny dcc block allows you to specify a filename which will not be allowed
+ to be sent via DCC over the server. This is very useful in helping stop distribution
+ of trojans and viruses. </p>
+<p>The <b>deny::filename</b> parameter specifies a wildcard mask of the filename to reject
+ sends of, and <b>deny::reason</b> specifies the reason why this file is blocked.</p>
+<p>There's also a <b>deny::soft</b> option, if set to 'yes' the dcc is blocked
+ unless the user explicitly allows it via /DCCALLOW +nickname-trying-to-send.
+ See dccallow.conf for a good example configuration for dccallow.</p>
+<p>Example<br>
+<pre>
+deny dcc {
+ filename virus.exe;
+ reason "This is a GD Virus";
+};
+
+deny dcc {
+ filename "*.exe";
+ reason "Executable content";
+ soft yes;
+};</pre>
+</p></div>
+<p></p>
+<p><font class="block_section">4.23 - </font><font class="block_name">Deny Version Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the V:Line)</font><a name="denyversionblock"></a><div class="desc">
+</p>
+<p> Syntax:<br>
+<pre>
+deny version {
+ mask <server-name>;
+ version <version-number>;
+ flags <compile-flags>;
+};</pre></p>
+<p>This block allows you to deny a server from linking based on the version of
+ Unreal it is running and what compile time options it has. The format for this
+ block is somewhat complex but isn't too hard to figure out. The deny::mask directive
+ specifies a wildcard mask of the server name this applies to. The deny::version
+ specifies the protocol number of the version this refers to.</p>
+<p>For example, 3.0 is 2301, 3.1.1/3.1.2 is 2302, 3.2 is 2303. The first character
+ of this parameter can be one of the following >, <, =, !. This character
+ tells the IRCd how to interpret the version. If the first character is a >
+ then all version greater than the specified version are denied, if it is a <
+ all versions lower are denied, if it is an = only that version is denied, and
+ if it is a ! then all versions except the specified are denied. The deny::flags
+ directive allows you to specify what compile time flags the server may or may
+ not have. The flags are arranged one after the other with no separation between,
+ if a character is prefixed by a ! then it means the server may not have this
+ flag compiled into it, if it does not have a ! prefix, then it means the server
+ must have this flag compiled.</p>
+<p></p></div>
+<p><font class="block_section">4.24 - </font><font class="block_name">Deny Link Block</font>
+ <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">
+</p>
+<p>Syntax:<br>
+<pre>
+deny link {
+ mask <server-name>;
+ rule <crule-expression>;
+ type <type-of-denial>;
+};</pre></p>
+<p>This block allows you to use specific rules to deny a server from linking.
+ The deny::mask specifies a wildcard mask of the server name to apply this rule
+ to. The deny::rule directive is very complex. A crule expression allows you
+ to control the link in great detail, and it is set up like a programming expression.
+ Four operators are supported, connected(<servermask>), returns true if
+ a server matching servermask is connected, directcon(<servermask>), returns
+ true if the server matching servermask is directly connected to this server,
+ via(<viamask>,<servermask>), returns true if a server matching servermask
+ is connected by a server matching viamask, and directop(), which returns true
+ if the operator issuing a /connect is directly connected to this server. These
+ operators can be combined using && (and) and || (or), items may also
+ be enclosed in parenthesis to allow grouping. In addition, an operator preceded
+ with a ! checks if the operator returned false. If the entire expression evaluates
+ to true, then the link is denied. The deny::type allows two different values,
+ auto (only applies to autoconnects, /connect will still work), and all (applies
+ to all connection attempts).</p>
+<p></p></div>
+<p><font class="block_section">4.25 - </font><font class="block_name">Deny Channel Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as chrestrict.conf)</font><a name="denychannelblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+deny channel {
+ channel "<channel-mask>";
+ reason <reason-for-ban>;
+ redirect "<channel-name>";
+ warn [on|off];
+};</pre></p>
+<p> </p>
+<p>The deny channel block allows you to disallow users from joining specific channels.
+ The <b>deny::channel</b> directive specifies a wildcard mask of channels the users
+ may not join, and the <b>deny::reason</b> specifies the reason why the channel may
+ not be joined. Additionally, you may specify a <b>deny::redirect</b>. If this is specified,
+ when a user tries to join a channel that matches deny::channel, he/she will be redirected
+ to deny::redirect. And there's also <b>deny::warn</b> which (if set to on) will send an
+ opernotice (to EYES snomask) if the user tries to join.
+</p>
+<p>Example</p>
+<pre>
+deny channel {
+ channel "#unrealsucks";
+ reason "No it don't!";
+};
+
+deny channel {
+ channel "#*teen*sex*";
+ reason "You == dead";
+ warn on;
+};
+
+deny channel {
+ channel "#operhelp";
+ reason "Our network help channel is #help, not #operhelp";
+ redirect "#help";
+};</pre></p>
+
+<p></p></div>
+<p><font class="block_section">4.26 - </font><font class="block_name">Allow Channel Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="allowchannelblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+allow channel {
+ channel "<channel-mask>";
+};</pre></p>
+<p>The allow channel block allows you to specify specific channels that users
+ may join. The allow::channel directive specifies the wildcard mask of the channels
+ which may be joined.</p>
+<p>Example:<br>
+<pre>
+allow channel {
+ channel "#something";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.27 - </font><font class="block_name">Allow DCC Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="allowdccblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+allow dcc {
+ filename "<filename-mask>";
+ soft [yes|no];
+};</pre></p>
+<p>The allow dcc blocks allows you to specify exceptions over deny dcc blocks, wildcards
+ are permitted. If <b>allow dcc::soft</b> is set to 'yes' it applies to 'soft dcc bans' list,
+ if set to 'no' it applies to the normal ('hard') dcc bans.</p>
+<p>Example:<br>
+<pre>
+allow dcc {
+ filename "*.jpg"; /* Images are usually safe */
+ soft yes;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.28 - </font><font class="block_name">Vhost Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as vhosts.conf)</font><a name="vhostblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+vhost {
+ vhost <vhost>;
+ from {
+ userhost <hostmask>;
+ userhost <hostmask>;
+ ...
+ };
+ login <login-name>;
+ password <password> { <auth-type>; };
+ swhois "<swhois info>";
+};</pre></p>
+<p>The vhost block allows you to specify a login/password that can be used with
+ the /vhost command to obtain a fake hostname. The vhost::vhost parameter can
+ be either a user@host or just a host that the user will receive upon successful
+ /vhost. The vhost::from::userhost contains a user@host that the user must match
+ to be eligible for the vhost. You may specify more than one hostmask. The vhost::login
+ in the login name the user must enter and vhost::password is the password that
+ must be entered. The vhost::password:: allows you to specify the type of
+ authentication used by this item. The currently supported authentication types
+ are crypt, md5, and sha1, ripemd-160. Lastly vhost::swhois allows you to add an extra
+ line to a users whois, exactly as it does in the Oper Block oper::swhois.</p>
+<p>Example:<br>
+<pre>
+vhost {
+ vhost my.own.personal.vhost.com;
+ from {
+ userhost my@isp.com;
+ userhost myother@isp.com;
+ };
+ login mynick;
+ password mypassword;
+ swhois "Im Special";
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.29 - </font><font class="block_name">Badword Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as badwords.*.conf)</font><a name="badwordsblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+badword <type> {
+ word <text-to-match>;
+ replace <replace-with>;
+ action <replace|block>;
+};</pre></p>
+<p>The badword block allows you to manipulate the list used for user and channel
+ mode +G to strip "badwords". The badword:: specifies the type, valid
+ types are channel, message, quit, and all. channel is for the channel +G list, message
+ is for the user +G list, quit is for quit message censoring, and all adds it to all three lists.
+ The badword::word can be a simple word or a regular expression we should search for. The
+ badword::replace is what we should replace this match with. If badword::replace
+ is left out, the word is replaced with <censored>. The badword::action defines
+ what action should be taken if this badword is found. If you specify replace, then the
+ badword is replaced, if you specify block, then the entire message is blocked. If you do
+ not specify a badword::action, replace is assumed.</p>
+<p>Example:<br>
+<pre>
+badword channel {
+ word shit;
+ replace shoot;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.30 - </font><font class="block_name">ULines Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as the U:Line)</font><a name="ulinesblock"></a><div class="desc">
+</p>
+<p>Syntax:<br>
+<pre>
+ulines {
+ <server-name>;
+ <server-name>;
+ ...
+};</pre></p>
+<p>The ulines block lets you define certain servers as having extra abilities.
+ This should only be used for servers such as services and stats. This should
+ not be set for a normal server. Each entry is the name of the server which will
+ receive the extra abilities.</p>
+<p>Example<br>
+<pre>
+ulines {
+ services.mynetwork.com;
+ stats.mynetwork.com;
+};</pre></p>
+<p></p></div>
+<p><font class="block_section">4.31 - </font><font class="block_name">Link Block</font>
+ <font class="block_optional">OPTIONAL</font> <font class="block_old">(Previously known as C/N/H:Lines)</font><a name="linkblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+link <server-name> {
+ username <usermask>;
+ hostname <ipmask>;
+ bind-ip <ip-to-bind-to>;
+ port <port-to-connect-on>;
+ password-connect <password-to-connect-with>;
+ password-receive <password-to-receive> { <auth-type>; };
+ hub <hub-mask>;
+ leaf <leaf-mask>;
+ leafdepth <depth>;
+ class <class-name>;
+ ciphers <ssl-ciphers>;
+ options {
+ <option>;
+ <option>;
+ ...
+ };
+};</pre></p>
+<p>This is the block you need for linking servers, please take your time to read all
+ this because this one of the hardest things to do and users often make errors ;P</p>
+<p>First of all <b>server-name</b> is the name of your remote server, the name the remote
+ server has in his me { } block, like hub.blah.com (not the IP and can be different than hostname).</p>
+<p><b>username</b><br>
+ You can specify this if you use ident for authentication, normally you will set this to "*".
+</p>
+<p><b>hostname</b><br>
+ The remote host or IP of the remote server. This is used for both connecting AND for
+ authentication/verification on the incoming side. Some examples:<br>
+ <table border="0">
+ <tr><td><i>1.2.3.4</i></td><td> normal IP</td></tr>
+ <tr><td><i>hub.blah.com</i></td><td> host: only for outgoing, cannot accept _incoming_ connections unless
+ link::options::nohostcheck is present</td></tr>
+ <tr><td><i>*</i></td><td> cannot connect TO but will allow a server connection (with correct password) from everywhere</td></tr>
+ <tr><td><i>::ffff:1.2.3.4</i></td><td> for linking ipv6 to ipv4.</td></tr>
+ </table>
+</p>
+<p><b>bind-ip</b> (optional)<br>
+ Can be used to bind to a specific IP (ex: 192.168.0.1) from where we should
+ connect from, almost never used.
+ </p>
+<p><b>port</b><br>
+ Port to connect to (at which the remote server is listening).
+ </p>
+<p><b>password-connect</b><br>
+ The password used for connecting to the remote server, must be plain-text.
+ </p>
+<p><b>password-receive</b><br>
+ The password used for validating incoming links, can be encrypted (valid methods
+ are crypt, md5, sha1, ripemd-160). You can leave the auth-type parameter out to
+ just use plain-text. Often this password is the same as your password-connect.
+</p>
+<p><b>hub vs leaf</b><br>
+ A hub has multiple servers linked to it, a leaf has only one link... to you.
+ 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.
+</p>
+<p><b>hub</b> (optional)<br>
+ The value is a mask of what servers this hub may connect (ex: *.my.net).
+</p>
+<p><b>leaf</b> (optional)<br>
+ 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.
+</p>
+<p><b>leafdepth</b> (optional)<br>
+ 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.
+</p>
+<p><b>class</b><br>
+ The class this server is put into, often a separate server class is used for this.
+</p>
+<p><b>compression-level</b> (optional)<br>
+ Specifies the compression level (1-9) for this link. Only used if link::options::zip is set.
+</p>
+<p><b>ciphers</b> (optional)<br>
+ Specifies the SSL ciphers to use for this link. To obtain a list of available ciphers, use
+ the `openssl ciphers` command. Ciphers should be specified as a : separated list.
+</p>
+<p><b>options block</b><br>
+ One or more options used for connecting to the server. Sometimes not needed.<br>
+<table border="0">
+<tr><td><b>ssl</b></td><td> if you are connecting to a SSL port.</td></tr>
+<tr><td><b>autoconnect</b></td><td> server will try to autoconnect, time specified in your class::connfreq
+ (it's best to enable this only from one side, like leaf->hub)</td></tr>
+<tr><td><b>zip</b></td><td> if you want compressed links, needs to be compiled in + set at both ends</td></tr>
+<tr><td><b>nodnscache</b></td><td> don't cache IP for outgoing server connection, use this if it's an often
+ changing host (like dyndns.org)</td></tr>
+<tr><td><b>nohostcheck</b></td><td> don't validate the remote host (link::hostname), use this if it's an often
+ changing host (like dyndns.org)</td></tr>
+<tr><td><b>quarantine</b></td><td> opers on this server cannot get GLOBAL oper privileges
+(they will get killed), used for test links and such</td></tr>
+</table>
+</p>
+<p>Example:</p>
+<pre>
+link hub.mynet.com {
+ username *;
+ hostname 1.2.3.4;
+ bind-ip *;
+ port 7029;
+ hub *;
+ password-connect "LiNk";
+ password-receive "LiNk";
+ class servers;
+ options {
+ autoconnect;
+ ssl;
+ zip;
+ };
+};</pre></p>
+<p> </p></div>
+<p><font class="block_section">4.32 - </font><font class="block_name">Alias Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="aliasblock"></a>
+</p><div class="desc">
+<p>Syntax [standard alias]:<br>
+<pre>
+alias <name> {
+ target <nick-to-forward-to>;
+ type <type-of-alias>;
+ spamfilter <yes|no>;
+};</pre></p>
+<p>(Note: also see <a href="#includedirective">here</a> about the standard alias files UnrealIRCd has)</p>
+<p>The alias block [standard alias] allows you to forward a command to a user,
+ for example /chanserv sends a message to the user chanserv. The alias:: specifies
+ the name of the command that will be the alias (eg: chanserv), alias::target is
+ the nickname or channel it will forward to, if the alias:: is the same as the target, it will
+ forward to, alias::target can be left out. The alias::type specifies the type
+ of alias, valid types are services (the user is on the services server), stats
+ (the user is on the stats server), normal (the user is a normal user on
+ any server), and channel (the target is a channel name). If alias::spamfilter (optional)
+ is set to 'yes', then the spamfilters will be checked (default is 'no').<br>
+ The alias block also has another purpose which is explained below.</p>
+<p>Syntax [command alias]:<br>
+<pre>
+alias <name> {
+ /* For aliases to be sent to users/channels */
+ format <regex-expression> {
+ target <nick-to-forward-to>;
+ type <type-of-alias>;
+ parameters <parameter-string>;
+ };
+ /* For 'real aliases' */
+ format <regex-expression> {
+ command <command>;
+ type real;
+ parameters <parameter-string>;
+ };
+ /* Etc... You can have as many format blocks as you wish.. */
+ format <regex-expression> {
+ ...
+ };
+ type command;
+ spamfilter <yes|no>;
+};</pre></p>
+<p>When the alias block is used in this format, it allows you a much broader range
+ of usage. For example you can create aliases such as /identify. The alias::
+ is the same as above, the name of the alias command. The <b>alias::format</b> specifies
+ a regular expression that compares against the text sent to the alias command,
+ when matched the sub-entries of that alias::format will be used, you may have
+ multiple alias::format's to make the command do different things depending on
+ the text sent to it. The <b>alias::format::target</b> is the target to forward this
+ alias to, however in case of a "real alias" <b>alias::format::command</b> is used instead.
+ The <b>alias::format::type</b> specifies the type of the alias that the
+ message should be forwarded to, besides the types mentioned previously in
+"Syntax [standard alias]", we also allow the type "real" here, for "real
+aliases". The <b>alias::format::parameters</b> is what will
+ be sent as the parameters to this alias. To specify one of the parameters given
+ to the command alias specify % followed by a number, for example, %1 is the
+ first parameter. To specify all parameters from a given parameter to the end
+ do % followed by the number and a -, for example %2- returns all parameters
+ from the second till the last. Additionally, you may specify %n which will be replaced
+ by the nickname of the user who executed the command.<br><br>
+ For examples of using the alias block in the command format, consult doc/example.conf.</p>
+<p></p></div>
+<p><font class="block_section">4.33 - </font><font class="block_name">Help Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="helpblock"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+help <name> {
+ <text-line>;
+ <text-line>;
+ ...
+};</pre></p>
+<p>(Note: normally you just include help.conf)</p>
+<p>The help block allows you to create entries for use in /helpop. The help::
+ is the value that must be passed to /helpop as a parameter, if the help:: is
+ left out, then it will be used when no parameter is passed to /helpop. The entries
+ for the help block are the text that will be displayed to the user when requesting
+ the /helpop.</p>
+<p></p></div>
+
+<p><font class="block_section">4.34 - </font><font class="block_name">Official Channels Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="officialchannels"></a>
+</p><div class="desc">
+<p>Syntax:<br>
+<pre>
+official-channels {
+ "#channel" { topic "The default topic"; };
+};</pre></p>
+<p>Official channels are shown in /list even if no users are in the channel.
+ The <b>topic</b> is optional and is only shown in /list if it has 0 users.
+</p>
+
+<p>Example:<br>
+<pre>
+official-channels {
+ "#Help" { topic "The official help channel, if nobody is present type /helpop helpme"; };
+ "#Home";
+ "#Main" { topic "The main channel"; };
+};</pre></p>
+</div>
+
+<p><font class="block_section">4.35 - </font><font class="block_name">Spamfilter Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="spamfilter"></a>
+</p><div class="desc">
+<p>
+The spamfilter block allows you to add local spamfilters (not network-wide).<br>
+See <a href="#feature_spamfilter">Features - Spamfilter</a> for more information about spamfilters.<br>
+</p>
+<p>Syntax:<br>
+<pre>
+spamfilter {
+ regex <word>;
+ target { <target(s)> };
+ action <action>;
+ reason <reason>;
+ ban-time <time>;
+};</pre></p>
+<p><b>regex</b> is the regex to be matched.<br>
+ <b>target</b> specifies the targets, see <a href="#feature_spamfilter">here</a> for a list of possible types (eg: 'channel').<br>
+ <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>
+ <b>reason</b> optional: specifies the ban or block reason, else the default is used.<br>
+ <b>ban-time</b> optional: specifies the duration of a *line ban or shun, else the default is used (1 day).<br>
+</p>
+
+<p>Examples:<br>
+<pre>
+spamfilter {
+ regex "Come watch me on my webcam";
+ target { private; channel; };
+ action gline;
+ reason "You are infected, please go to www.antivirus.xx/blah/virus=GrrTrojan";
+ ban-time 6h;
+};
+
+spamfilter {
+ regex "come to irc\..+\..+";
+ target { private; channel; };
+ action gline;
+ action gline;
+ reason "No spamming allowed";
+};
+</pre></p>
+</div>
+
+<p><font class="block_section">4.36 - </font><font class="block_name">Cgiirc Block</font>
+ <font class="block_optional">OPTIONAL</font><a name="cgiirc"></a>
+</p><div class="desc">
+<p>
+The cgiirc block allows you to configure host spoofing for CGI:IRC gateways you trust
+(<a href="#feature_cgiirc">more info</a>).</p>
+
+<p>Syntax:<br>
+<pre>
+cgiirc {
+ type <webirc|old>;
+ username <mask>; /* optional */
+ hostname <mask>;
+ password <password>; /* only for type webirc */
+};</pre></p>
+<p><b>type</b> is either 'webirc' or 'old'.<br>
+ <b>username</b> is matched against the ident (if present). If not specified, "*" is assumed.<br>
+ <b>hostname</b> is the hostmask to match against.<br>
+ <b>password</b> is the webirc password, only used for type 'webirc'.<br>
+</p>
+
+<p><b>How to configure with method 'webirc' (recommended method)</b><br>
+In your CGI:IRC configuration file (cgiirc.conf) you set webirc_password to a good password.<br>
+Then, in your unrealircd.conf you add a cgiirc block to allow this host and password and you set
+cgiirc::type to "webirc".<br>
+<br>
+Example:<br>
+In your CGI:IRC configuration file (cgiirc.conf) you add:
+<pre>webirc_password = LpT4xqPI5</pre>
+Then, in your unrealircd.conf you add a cgiirc block:
+<pre>cgiirc {
+ type webirc;
+ hostname "1.2.3.4";
+ password "LpT4xqPI5";
+};</pre></p>
+
+<p><b>How to configure with method 'old'</b><br>
+NOTE: This is not the recommended method since it has two disadvantages:
+this method will send the IP/host to spoof as a server password, meaning you cannot
+specify a server password as a CGI:IRC user. Additionally, access control is only
+IP-based and does not require an extra password like the 'webirc' method. In short,
+you probably should not be using this method unless you have a good reason to do so.<br>
+<br>
+In your CGI:IRC configuration file (cgiirc.conf) you set realhost_as_password to 1.<br>
+Then, in your unrealircd.conf you add a cgiirc block to allow this host.<br>
+<br>
+Example:<br>
+In your CGI:IRC configuration file (cgiirc.conf) you add:
+<pre>realhost_as_password = 1</pre>
+Then, in your unrealircd.conf you add a cgiirc block:
+<pre>cgiirc {
+ type old;
+ hostname "1.2.3.4";
+};</pre></p>
+</div>
+
+<p><font class="block_section">4.37 - </font><font class="block_name">Set Block</font>
+ <font class="block_required">REQUIRED</font> <font class="block_old">(Previously known as unrealircd.conf/networks file)</font><a name="setblock"></a>
+</p><div class="desc">
+<p>The set file is what use to be our networks/unrealircd.conf and our networks
+ file. On single server networks, rather than having 3 files you can just put all
+ the set statements in the unrealircd.conf itself, on multi-server networks, I
+ recommend using a seperate networks file.</p>
+ <p>Now, if your server is on a network, chances are you will all basically use
+ the same Set settings. Therefore it makes more sense to have a network file,
+ which is loaded with an <a href="#includedirective">include</a> directive.
+ Below you will find all of the set directives available.</p>
+<p>In this doc we refer to settings / directives in the <block-name>::<block-directive>
+ format. This format is NOT the format that it can be entered into the configuration
+ file. IT MUST be converted to the format listed below. It is presented in the
+ format it is to make discussing it simpler.</p>
+<p>Syntax:<br>
+<pre>
+set {
+ <entry> <value>;
+ <entry> <value>;
+ ...
+};</pre></p>
+<p>The set block sets options for individual server features. Each entry does
+ something different and therefore each will be described below. Some directives
+ have sub blocks which will also be described. There are many set statements
+ to cover, all of the directives listed below can be included under ONE set statement.
+ If a directive has options, they are included within the single set statement
+ as well.<br>
+ Example:<br>
+<pre>
+set {
+ kline-address my@emailaddress.com;
+ auto-join #welcome;
+ options {
+ hide-ulines;
+ };
+ hosts {
+ local LocalOp.MyNet.com;
+ global globalop.mynet.com;
+ };
+};</pre></p>
+<p>Now if you wanted to make the set statements separate, say you wanted to set
+ your options in a single line.<br>
+ Example:<br>
+ set { options { hide-ulines; no-stealth; }; };<br>
+</p>
+<p><font class="set">set::kline-address <email-address>;</font><br>
+ The email address that K:line questions should be sent to. This value must be
+ specified.</p>
+<p><font class="set">set::gline-address <email-address>;</font><br>
+ The email address that G:line questions should be sent to.</p>
+<p><font class="set">set::modes-on-connect <+modes>;</font><br>
+ The modes that will be set on a user at connection.</p>
+<p><font class="set">set::snomask-on-connect <+modes></font><br>
+ The snomask that will be set on a user at connection.</p>
+<p><font class="set">set::modes-on-oper <+modes>;</font><br>
+ The modes that will be set on a user when they /oper.</p>
+<p><font class="set">set::snomask-on-oper <+modes>;</font><br>
+ The snomask that will be set on a user when they /oper.</p>
+<p><font class="set">set::modes-on-join <+modes>;</font><br>
+ 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>
+<p><font class="set">set::level-on-join <none|voice|halfop|op|protect|owner>;</font><br>
+ The mode that a user will get when he's the first to join a channel. The
+ default is 'op' (channel operator).</p>
+<p><font class="set">set::restrict-usermodes <modes></font><br>
+ Restrict users to set/unset the modes listed here (don't use + or -).<br>
+ For example you can set +G in modes-on-connect and G in restrict-usermodes,
+ that way you can force all users to be +G and unable to do -G.</p>
+<p><font class="set">set::restrict-channelmodes <modes></font><br>
+ Restrict users to set/unset the channelmodes listed here (don't use + or -).<br>
+ For example you can set +G in modes-on-join and G in restrict-channelmodes,
+ that way you can force all (new) channels to be +G and unable to do -G.<br>
+ NOTE: it may still be possible to use these channelmodes through services
+ by using MLOCK. Unfortunately we can't do much about that, you would have
+ to ask the services coders to implement a restrict-channelmodes feature too.</p>
+<p><font class="set">set::restrict-extendedbans <types|*></font><br>
+ Don't allow users to use any extended bans ("*") or disallow only certain ones (eg: "qc").</p>
+<p><font class="set">set::auto-join <channels>;</font><br>
+ The channel(s) a user will be forced to join at connection. To specify more
+ than one channel use a comma separated list.<br>
+ [Note: don't forget to add quotes, like: auto-join "#chan";]</p>
+<p><font class="set">set::oper-auto-join <channels>;</font><br>
+ The channel(s) a user will be forced to join when they /oper. To specify more
+ than one channel use a comma separated list.<br>
+ [Note: don't forget to add quotes, like: oper-auto-join "#chan";]</p>
+<p><font class="set">set::anti-spam-quit-message-time <timevalue>;</font><br>
+ A time value specifying the length of time a user must be connected for before
+ a /quit message will be displayed. Used to prevent spam. A time value is a numeric
+ string with d meaning days, h meaning hours, m meaning minutes, and s meaning
+ seconds, for example 1d2h3m means 1 day, 2 hours, 3 minutes.</p>
+<p><font class="set">set::prefix-quit <text-to-prefix-quit>;</font><br>
+ Sets the text that will be used to prefix a quit message. If this value is set
+ to 0 then the standard "Quit:" is used.</p>
+<p><font class="set">set::static-quit <quit message>;</font><br>
+ Sets a static quit message that will be sent whenever a client logs off the
+ network. This eliminates the need for anti-spam-quit-message-time, as well as
+ the set::prefix-quit. It will NOT replace ERRORS with the static-quit message.</p>
+<p><font class="set">set::static-part <no|yes|part message>;</font><br>
+ A value of 'yes' strips all part comments, a value of 'no' makes part just work
+ as usual, anything else will be used as a part comment (eg: static-part "Bye!")
+ but this can be quite annoying, so use with care.</p>
+<p><font class="set">set::who-limit <limit>;</font><br>
+ Sets the limit for the maximum number of matches that will be returned for a /who.
+ If this option is left out, no limit is enforced.</p>
+<p><font class="set">set::silence-limit <limit>;</font><br>
+ Sets the limit on the maximum SILENCE list entries. If this directive is not specified,
+ a limit of 15 is set.</p>
+<p><font class="set">set::maxbans <limit>;</font><br>
+ Sets the limit on the maximum amount of bans (+b) allowed per channel. The default is 60.
+ If you change this, be sure to also take a look at maxbanlength (see next)!</p>
+<p><font class="set">set::maxbanlength <limit>;</font><br>
+ Similar to above, but sets the maximum amount of characters for all bans added up
+ together, so basically this puts up a limit on the (semi-)maximum amount of memory
+ all channel bans on a channel can take. The default is 2048 (bytes). With the default
+ set::maxbans of 60 this allows 2048:60=34 characters per ban on average.</p>
+<p><font class="set">set::oper-only-stats <stats-list>;</font><br>
+ Specifies a list of stats flags with no separators that defines stats flags
+ only opers can use. Leave this value out to allow users to use all flags, or
+ specify * for users to be able to use no flags. Only short stats flags may be specified
+ here.</p>
+<p><font class="set">set::oper-only-stats {<stats-flag>; <stats-flag>;};</font><br>
+ Specifies a list of stats flags that can only be used by opers. This only works with long
+ stats flags.</p>
+<p><font class="set">set::maxchannelsperuser <amount-of-channels>;</font><br>
+ Specifies the number of channels a single user may be in at any one time.</p>
+<p><font class="set">set::maxdccallow <amount-of-entries>;</font><br>
+ Specifies the maximum number of entries a user can have on his/her DCCALLOW list.</p>
+<p><font class="set">set::channel-command-prefix <command-prefixes>;</font><br>
+ Specifies the prefix characters for services "in channel commands". Messages starting with
+ any of the specified characters will still be sent even if the client is +d. The default
+ value is "`!.".</p>
+<p><font class="set">set::allowed-nickchars { <list> };</font><br>
+ Character sets / languages to allow in nicks, see <a href="#feature_nickchars">Nick Character Sets</a>.</p>
+<p><font class="set">set::allow-userhost-change [never|always|not-on-channels|force-rejoin]</font><br>
+ Specifies what happens when the user@host changes (+x/-x/chghost/chgident/setident/vhost/etc).<br>
+ <i>never</i> disables all the commands, <i>always</i> does always allow it even when in channels
+ (may cause client desyncs) [default], <i>not-on-channels</i> means it's only allowed when the
+ 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>
+<p><font class="set">set::options::hide-ulines;</font><br>
+ If this is present, Ulined server will be hidden in a /links requested by non-opers.</p>
+<p><font class="set">set::options::flat-map;</font><br>
+ If this is present, all servers will appear as directly linked in /map and /links,
+ thus you can no longer see which server is linked to which. This is a little help against
+ (D)DoS attacks because evil people now no longer can easily see the 'weak points'.</p>
+<p><font class="set">set::options::show-opermotd;</font><br>
+ If present the opermotd will be shown to users once they successfully /oper.</p>
+<p><font class="set">set::options::identd-check;</font><br>
+ If present the presence of an identd server will be checked and the returned
+ value will be used for the username. If no ident request is returned or the
+ identd server doesn't exist, the user's specified username will be prefixed
+ with a ~. If this value is omitted no such check is made.</p>
+<p><font class="set">set::options::show-connect-info;</font><br>
+ If present notices showing "ident request", "hostname lookup",
+ etc. will be displayed when a user connects.</p>
+<p><font class="set">set::options::dont-resolve;</font><br>
+ If present hosts of incoming users are not resolved, can be useful if many of your
+ users don't have a host to speed up connecting.<br>
+ Note that since no resolving is done you also can't have host based allow blocks.</p>
+<p><font class="set">set::options::mkpasswd-for-everyone;</font><br>
+ Makes it so the /mkpasswd can be used by anyone instead of oper-only, usage of the command
+ by non-opers is sent to the EYES snomask.</p>
+<p><font class="set">set::options::allow-part-if-shunned;</font><br>
+ Allow shunned user to use /part.</p>
+<p><font class="set">set::options::fail-oper-warn;</font><br>
+ If present, a user will be notified that his/her failed /oper attempt has been logged.</p>
+<p><font class="set">set::dns::timeout <timevalue>;</font><br>
+ A time value specifying the length of time a DNS server has to respond before
+ a timeout. A time value is a numeric string with d meaning days, h meaning hours,
+ m meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2
+ hours, 3 minutes. (NOT IMPLEMENTED)</p>
+<p><font class="set">set::dns::retries <number-of-retries>;</font><br>
+ A numeric value specifying the number of times the DNS lookup will be retried
+ if failure occurs. (NOT IMPLEMENTED)</p>
+<p><font class="set">set::dns::nameserver <name-of-dns-server>;</font><br>
+ Specifies the hostname of the server that will be used for DNS lookups. (NOT IMPLEMENTED)</p>
+<p><font class="set">set::dns::bind-ip <ip>;</font><br>
+ Specifies the IP to bind to for the resolver, rarely ever needed.</p>
+<p><font class="set">set::network-name <name-of-network>;</font><br>
+ Specifies the name of the network on which this server is run. This value should
+ be exactly the same on all servers on a network.</p>
+<p><font class="set">set::default-server <server-name>;</font><br>
+ Defines the name of the default server to tell users to connect to if this server
+ is full.</p>
+<p><font class="set">set::services-server <server-name>;</font><br>
+ Specifies the name of the server that the services bots are connected to. Required,
+ set it to something like services.yournet.com if you don't have services.</p>
+<p><font class="set">set::stats-server <server-name>;</font><br>
+ Sets the name of the server on which the stats bot is located. If stats are
+ not run this value may be left out.</p>
+<p><font class="set">set::help-channel <network-help-channel>;</font><br>
+ Sets the name of the help channel for this network.</p>
+<p><font class="set">set::cloak-keys { "key1"; "key2"; "key3"; };</font><br>
+ Sets the keys to be used to generate a +x host. This value must be the same
+ on all servers or the servers will not link. Each of the 3 set::cloak-keys::
+ must be a string of 5-100 characters (10-20 is fine) consisting of mixed
+ lowercase (a-z), uppercase (A-Z) and digits (0-9). Note that depending on which
+ cloaking module you have loaded, other rules may apply.</p>
+<p><font class="set">set::hiddenhost-prefix <prefix-value>;</font><br>
+ Defines the prefix that will be used on hiddenhosts (+x). This is usually three
+ or four letters representing the network name.</p>
+<p><font class="set">set::hosts::local <locop-host-name>;</font><br>
+ Defines the hostname that will be assigned to local opers when they set +x. You may
+ optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::global <globop-host-name>;</font><br>
+ Defines the hostname that will be assigned to global operators when they set
+ +x. You may optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::coadmin <coadmin-host-name>;</font><br>
+ Sets the hostname that will be assigned to co-admins when they set +x. You may
+ optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::admin <admin-host-name>;</font><br>
+ Defines the hostname that will be set for admins when they set +x. You may
+ optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::servicesadmin <servicesadmin-host-name>;</font><br>
+ Sets the hostname that will be given to services-admins when they set +x. You may
+ optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::netadmin <netadmin-host-name>;</font><br>
+ Sets the hostname that will be given to netadmins when they set +x. You may
+ optionally specify a username@host for this value.</p>
+<p><font class="set">set::hosts::host-on-oper-up <yes/no>;</font><br>
+ If set to yes, the H/get_host flag will be honored and +x will be automatically
+ set at /oper. If set to no, the user must set +x manually to receive the oper
+ host.</p>
+<p><font class="set">set::ssl::egd <filename>;</font><br>
+ Specifies that EGD (Entropy Gathering Daemon) support should be enabled. If
+ you run OpenSSL 0.9.7 or higher, then /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool,
+ and /etc/entropy will be searched by default so no filename is necessary, you
+ may simply specify set::ssl::egd with no value. If you are using a version of
+ OpenSSL prior to 0.9.7 or you want to use a EGD socket located somewhere other
+ than the above listed locations you may specify the filename of the UNIX Domain
+ Socket that an EGD is listening on.</p>
+<p><font class="set">set::ssl::certificate <filename>;</font><br>
+ Specifies the filename where the server's SSL certificate is located.</p>
+<p><font class="set">set::ssl::key <filename>;</font><br>
+ Specifies the filename where the server's SSL private key is located.</p>
+<p><font class="set">set::ssl::trusted-ca-file <filename>;</font><br>
+ Specifies the filename where the certificates of the trusted CAs are located.</p>
+<p><font class="set">set::ssl::server-cipher-list <cipherlist>;</font><br>
+ Specifies which ciphers to be allowed, by default we leave this up to OpenSSL.
+ See <a href="http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT">http://www.openssl.org/docs/apps/ciphers.html</a>
+ on how to specify the list of ciphers.</p>
+<p><font class="set">set::ssl::renegotiate-bytes <value>;</font><br>
+ Specifies after how many bytes an SSL session should be renegotiated (eg: 20m for 20 megabytes).</p>
+<p><font class="set">set::ssl::renegotiate-timeout <timevalue>;</font><br>
+ Specifies after how much time an SSL session should be renegotiated (eg: 1h for 1 hour).</p>
+<p><font class="set">set::ssl::options::fail-if-no-clientcert;</font><br>
+ Forces clients that do not have a certificate to be denied.</p>
+<p><font class="set">set::ssl::options::no-self-signed;</font><br>
+ Disallows connections from people with self-signed certificates.</p>
+<p><font class="set">set::ssl::options::verify-certificate;</font><br>
+ Makes Unreal determine if the SSL certificate is valid before allowing connection.</p>
+<p><font class="set">set::ssl::options::no-starttls;</font><br>
+ Disable STARTTLS. STARTTLS allows clients to use SSL on regular (non-SSL) ports.</p>
+<p><font class="set">set::throttle::period <timevalue></font><br>
+ How long a user must wait before reconnecting more than set::throttle::connections
+ times.</p>
+<p><font class="set">set::throttle::connections <amount>;</font><br>
+ How many times a user must connect with the same host to be throttled.</p>
+<p><font class="set">set::ident::connect-timeout <amount>;</font><br>
+ Amount of seconds after which to give up connecting to the ident server (default: 10s).</p>
+<p><font class="set">set::ident::read-timeout <amount>;</font><br>
+ Amount of seconds after which to give up waiting for a reply (default: 30s).</p>
+<p><font class="set">set::anti-flood::unknown-flood-bantime <timevalue>;</font><br>
+ Specifies how long an unknown connection flooder is banned for.</p>
+ <p><font class="set">set::anti-flood::unknown-flood-amount <amount>;</font><br>
+ Specifies the amount of data (in KiloBytes) that the unknown connection must send
+ in order for the user to be killed.</p>
+ <p><font class="set">set::anti-flood::away-flood <count>:<period></font><br>
+ Away flood protection: limits /away to 'count' changes per 'period' seconds.
+ This requires NO_FLOOD_AWAY to be enabled in config.h. Example: <i>away-flood 5:60s;</i>
+ means max 5 changes per 60 seconds.</p>
+ <p><font class="set">set::anti-flood::nick-flood <count>:<period></font><br>
+ Nickflood protection: limits nickchanges to 'count' per 'period' seconds.
+ For example <i>nick-flood 4:90</i> means 4 per 90 seconds, the default is 3 per 60.</p>
+ <p><font class="set">set::default-bantime <time></font><br>
+ Default bantime when doing /kline, /gline, /zline, /shun, etc without time parameter
+ (like /gline *@some.nasty.isp), the default is permanent (0). Example: <i>default-bantime 90d;</i></p>
+ <p><font class="set">set::modef-default-unsettime <value></font><br>
+ For channelmode +f you can specify a default unsettime, if you specify 10 for example then
+ +f [5j]:15 will be transformed to [5j#i10]:15. The default is no default unsettime.</p>
+ <p><font class="set">set::modef-max-unsettime <value></font><br>
+ The maximum amount of minutes for a mode +f unsettime (in +f [5j#i<TIME>]:15), this is a
+ value between 0 and 255. The default is 60 (= 1 hour).</p>
+ <p><font class="set">set::ban-version-tkl-time <value></font><br>
+ If you specify an 'action' like zline/gline/etc in ban version, then you can specify here
+ how long the ip should be banned, the default is 86400 (1 day).</p>
+ <p><font class="set">set::spamfilter::ban-time <value></font><br>
+ Same as above but for *lines/shuns added by spamfilter</p>
+ <p><font class="set">set::spamfilter::ban-reason <reason></font><br>
+ Reason to be used for entries added by spamfilter</p>
+ <p><font class="set">set::spamfilter::virus-help-channel <channel></font><br>
+ The channel to use for the 'viruschan' action in spamfilter</p>
+ <p><font class="set">set::spamfilter::virus-help-channel-deny <yes|no></font><br>
+ If set to yes (or '1') it replies 'invite only' to any normal users that try to join
+ the virus-help-channel. Only opers, people that match spamfilters and people that
+ are /invite'd can join.</p>
+ <p><font class="set">set::spamfilter::except <target(s)></font><br>
+ These targets are exempt from spam filtering (no action will be taken),
+ can be single target or comma seperated list.. Ex: except "#help,#spamreport"</p>
+ <p><font class="set">set::spamfilter::slowdetect-warn <value></font><br>
+ If a spamfilter takes longer than this amount of milliseconds to execute
+ (1000ms = 1 second), then a warning notice will be sent to all opers (default: 250).
+ See also <a href="#feature_spamfilter_slow">Slow Spamfilter Detection</a>.</p>
+ <p><font class="set">set::spamfilter::slowdetect-fatal <value></font><br>
+ If a spamfilter takes longer than this amount of milliseconds to execute
+ (1000ms = 1 second), then the spamfilter will be removed (default: 500).
+ See also <a href="#feature_spamfilter_slow">Slow Spamfilter Detection</a>.</p>
+ <p><font class="set">set::check-target-nick-bans <yes|no></font><br>
+ Whenever the user changes his/her nick, check if the NEW nick would be
+ banned. If so, do not allow the nickchange. Default is yes.</p>
+ <p><font class="set">set::timesynch::enabled <yes|no></font><br>
+ Enable or disable time synchronization on-boot. Default is yes.</p>
+ <p><font class="set">set::timesynch::server <IP></font><br>
+ Server to synchronize time with. This can be up to 4 IP's seperated by comma's.
+ The servers must support NTP protocol version 4. The default is to use 3 time servers (US, EU,
+AU). Requests to these servers are sent in parallel, fastest reply wins.</p>
+ <p><font class="set">set::timesynch::timeout <time></font><br>
+ Maximum time to wait for a time server reply. This is a value between 1 and 5, more is not possible
+ because it causes too much inaccuracy. This setting is 3 by default and there's probably
+ no good reason to change it.</p>
+ <p><font class="set">set::pingpong-warning <yes|no></font><br>
+ When NOSPOOF is enabled (usually on Windows), send a warning to each user to use
+ '/quote pong ..' if they are having problems connecting? The default is no.</p>
+ <p><font class="set">set::watch-away-notification <yes|no></font><br>
+ Allows you to enable/disable AWAY notification in WATCH. The default is yes.</p>
+<p></p> </div>
+<p id="filesblock"><font class="block_section">4.38 - </font><font class="block_name">Files Block</font>
+ <font class="block_optional">OPTIONAL</font><div class="desc">
+</p>
+<p>
+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>.
+</p>
+<p>
+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.
+</p>
+<p>Syntax:<br>
+<pre>
+files {
+ motd <motd file>;
+ shortmotd <short motd file>;
+ opermotd <oper motd file>;
+ svsmotd <services motd file>;
+ botmotd <bot motd file>;
+
+ rules <rules file>;
+
+ tunefile <tune file>;
+ pidfile <pid file>;
+};
+</pre></p>
+<p>Example:<br />
+<pre>
+files {
+ motd /etc/motd;
+
+ pidfile /var/lib/run/unrealircd.pid;
+};
+</pre>
+</p>
+<p><b><font size="+2">5 – Additional Files<a name="addtlfiles"></a>
+ </font></b></p><div class="desc">
+ In addition to the configuration files, Unreal has a few other files, such as MOTD, OperMOTD,
+ BotMOTD, and Rules. Listed below are the names of these files and their uses.<br>
+ 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,
+ these are just the files used by default (and for remote MOTD/RULES's).<p />
+<table width="83%" border="1">
+ <tr>
+ <td>ircd.motd</td><td>Displayed when a /motd is executed and (if ircd.smotd is not present) when a user connects</td>
+ </tr>
+ <tr>
+ <td>ircd.smotd</td><td>Displayed on connect only (short MOTD)</td>
+ </tr>
+ <tr>
+ <td>ircd.rules</td><td>Displayed when a /rules is executed</td>
+ </tr>
+ <tr>
+ <td>oper.motd</td><td>Displayed when a /opermotd is executed or when you /oper up</td>
+ </tr>
+ <tr>
+ <td>bot.motd</td><td>Displayed when a /botmotd is executed</td>
+ </tr>
+</table>
+<p></p></div>
+<p><b><font size="+2">6 – User & Channel Modes<a name="userchannelmodes"></a>
+ </font></b></p><div class="desc">
+<table width="83%" border="1">
+ <tr>
+ <td><div align="center"><b>Mode</b></div></td>
+ <td><div align="center"><b>Description</b></div></td>
+ </tr>
+ <tr>
+ <td colspan="2"><div align="center"><b>Channel Modes</b></div></td>
+ </tr>
+ <tr>
+ <td><div align="center">A</div></td>
+ <td>Only Administrators may join</td>
+ </tr>
+ <tr>
+ <td><div align="center">a <nick></div></td>
+ <td>Makes the user a channel admin</td>
+ </tr>
+ <tr>
+ <td><div align="center">b <nick!user@host><br>
+ </div></td>
+ <td>Bans the given user from the channel</td>
+ </tr>
+ <tr>
+ <td><div align="center">c</div></td>
+ <td>No ANSI color can be sent to the channel</td>
+ </tr>
+ <tr>
+ <td><div align="center">C</div></td>
+ <td>No CTCP's allowed in the channel</td>
+ </tr>
+ <tr>
+ <td><div align="center">e <nick!user@host></div></td>
+ <td>Exception ban – If someone matches this, they can join a channel
+ even if they match an existing ban</td>
+ </tr>
+ <tr>
+ <td><div align="center">f [<number><type>]:<seconds></div></td>
+ <td>Channel flood protection. See <a href="#feature_antiflood">section 3.12</a>
+ above for an extended description.</td>
+ </tr>
+ <tr>
+ <td><div align="center">G</div></td>
+ <td>Makes channel G rated. Checks for words listed in the Badword Blocks,
+ and replaces them with the words specified</td>
+ </tr>
+ <tr>
+ <td><div align="center">h <nick></div></td>
+ <td>Gives half-op status to the user</td>
+ </tr>
+ <tr>
+ <td><div align="center">i</div></td>
+ <td>Invite required</td>
+ </tr>
+ <tr>
+ <td><div align="center">I <nick!user@host><br></div></td>
+ <td>Invite exceptions ("invex") - if someone matches this, they can bypass
+ +i requirements to enter the channel.</td>
+ </tr>
+ <tr>
+ <td><div align="center">j <joins:seconds></div></td>
+ <td>Throttles joins per-user to <i>joins</i> per <i>seconds</i> seconds</td>
+ </tr>
+ <tr>
+ <td><div align="center">K</div></td>
+ <td>/knock is not allowed</td>
+ </tr>
+ <tr>
+ <td><div align="center">k <key></div></td>
+ <td>Sets a key needed to join</td>
+ </tr>
+ <tr>
+ <td><div align="center">l <##></div></td>
+ <td>Sets max number of users</td>
+ </tr>
+ <tr>
+ <td><div align="center">L <Chan></div></td>
+ <td>If the amount set by +l has been reached, users will be sent to this channel</td>
+ </tr>
+ <tr>
+ <td><div align="center">M</div></td>
+ <td>A registered nickname (+r) is required to talk</td>
+ </tr>
+ <tr>
+ <td><div align="center">m</div></td>
+ <td>Moderated channel. Only +v/o/h users may speak</td>
+ </tr>
+ <tr>
+ <td><div align="center">N</div></td>
+ <td>No nick name changes permitted</td>
+ </tr>
+ <tr>
+ <td><div align="center">n</div></td>
+ <td>No messages from outside channels</td>
+ </tr>
+ <tr>
+ <td><div align="center">O</div></td>
+ <td>Only IRCops may join</td>
+ </tr>
+ <tr>
+ <td><div align="center">o <nick></div></td>
+ <td>Gives a user channel operator status</td>
+ </tr>
+ <tr>
+ <td><div align="center">p</div></td>
+ <td>Makes channel private</td>
+ </tr>
+ <tr>
+ <td><div align="center">q <nick></div></td>
+ <td>Sets channel owner</td>
+ </tr>
+ <tr>
+ <td><div align="center">Q</div></td>
+ <td>Only U:Lined servers can kick users</td>
+ </tr>
+ <tr>
+ <td><div align="center">R</div></td>
+ <td>Requires a registered nickname to join</td>
+ </tr>
+ <tr>
+ <td><div align="center">S</div></td>
+ <td>Strips all incoming colors</td>
+ </tr>
+ <tr>
+ <td><div align="center">s</div></td>
+ <td>Makes channel secret</td>
+ </tr>
+ <tr>
+ <td><div align="center">t</div></td>
+ <td>Only chanops can set topic</td>
+ </tr>
+ </tr>
+ <tr>
+ <td><div align="center">T</div></td>
+ <td>No NOTICE's allowed in the channel</td>
+ </tr>
+ <tr>
+ <td><div align="center">u</div></td>
+ <td>Auditorium – Makes /names and /who #channel only show channel ops</td>
+ </tr>
+ <tr>
+ <td><div align="center">V</div></td>
+ <td>/invite is not allowed</td>
+ </tr>
+ <tr>
+ <td><div align="center">v <nick></div></td>
+ <td>Gives a voice to users. (May speak in +m channels)</td>
+ </tr>
+ <tr>
+ <td><div align="center">z</div></td>
+ <td>Only clients on a Secure (SSL) Connection may join</td>
+ </tr>
+</table>
+<p> </p>
+<table width="75%" border="1">
+ <tr>
+ <td><div align="center"><b>Mode</b></div></td>
+ <td><div align="center"><b>Description</b></div></td>
+ </tr>
+ <tr>
+ <td colspan="2"><div align="center"><b>User Modes</b></div></td>
+ </tr>
+ <tr>
+ <td><div align="center">A</div></td>
+ <td>Server Admin (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">a</div></td>
+ <td>Services Admin (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">B</div></td>
+ <td>Marks you as being a Bot</td>
+ </tr>
+ <tr>
+ <td><div align="center">C</div></td>
+ <td>Co-Admin (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">d</div></td>
+ <td>Makes it so you can not receive channel PRIVMSGs (with the exception
+ of text prefixed with certain characters, see set::channel-command-prefix)</td>
+ </tr>
+ <tr>
+ <td><div align="center">G</div></td>
+ <td>Filters out all the bad words per configuration</td>
+ </tr>
+ <tr>
+ <td><div align="center">g</div></td>
+ <td>Can send & read globops and locops</td>
+ </tr>
+ <tr>
+ <td><div align="center">H</div></td>
+ <td>Hide IRCop Status (IRCop Only)</td>
+ </tr>
+ <tr>
+ <td><div align="center">h</div></td>
+ <td>Available for help (HelpOp) (Set in OperBlock)</td>
+ </tr>
+ <tr>
+ <td><div align="center">i</div></td>
+ <td>Invisible (not shown in /who)</td>
+ </tr>
+ <tr>
+ <td><div align="center">N</div></td>
+ <td>Network Administrator (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">O</div></td>
+ <td>Local IRC Operator (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">o</div></td>
+ <td>Global IRC Operator (Set in Oper Block)</td>
+ </tr>
+ <tr>
+ <td><div align="center">p</div></td>
+ <td>Hides the channels you are in from /whois</td>
+ </tr>
+ <tr>
+ <td><div align="center">q</div></td>
+ <td>Only U:Lines can kick you (Services Admins Only)</td>
+ </tr>
+ <tr>
+ <td><div align="center">R</div></td>
+ <td>Allows you to only receive PRIVMSGs/NOTICEs from registered (+r) users</td>
+ </tr>
+ <tr>
+ <td><div align="center">r</div></td>
+ <td>Identifies the nick as being registered</td>
+ </tr>
+ <tr>
+ <td><div align="center">S</div></td>
+ <td>Used to protect Services Daemons</td>
+ </tr>
+ <tr>
+ <td><div align="center">s</div></td>
+ <td>Can listen to server notices (see <a href="#feature_snomasks">section 3.3</a> above for more information)</td>
+ </tr>
+ <tr>
+ <td><div align="center">T</div></td>
+ <td>Prevents you from receiving CTCPs</td>
+ </tr>
+ <tr>
+ <td><div align="center">t</div></td>
+ <td>Says you are using a /vhost</td>
+ </tr>
+ <tr>
+ <td><div align="center">V</div></td>
+ <td>Marks you as a WebTV user</td>
+ </tr>
+ <tr>
+ <td><div align="center">v</div></td>
+ <td>Receives infected DCC Send Rejection notices</td>
+ </tr>
+ <tr>
+ <td><div align="center">W</div></td>
+ <td>Lets you see when people do a /whois on you (IRCops Only)</td>
+ </tr>
+ <tr>
+ <td><div align="center">w</div></td>
+ <td>Can listen to wallop messages</td>
+ </tr>
+ <tr>
+ <td><div align="center">x</div></td>
+ <td>Gives user a hidden hostname </td>
+ </tr>
+ <tr>
+ <td><div align="center">z</div></td>
+ <td>Indicates that you are an SSL client</td>
+ </tr>
+</table>
+<p></p></div>
+<p><font size="+2"><b>7 – User & Oper Commands Table<a name="useropercommands" id="useropercommands"></a></b></font></p><div class="desc">
+<p>NOTE: the /helpop documentation is more up to date, use <i>/helpop command</i> (or <i>/helpop ?command</i> if you are oper)
+to get more information on a command.</p>
+
+<table width="90%" border="1">
+ <tr>
+ <td width="33%"><div align="center"><b>Command</b></div></td>
+ <td width="57%"><div align="center"><b>Description</b></div></td>
+ <td width="10%"><div align="center"><b>Who</b></div></td>
+ </tr>
+ <tr>
+ <td>nick <newnickname></td>
+ <td>Changes your online nick name. Alerts others to the change of your nick<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td>whois <nick></td>
+ <td>Displays information of user requested. Includes Full Name, Host, Channels
+ User is in, and Oper Status<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">who <mask></td>
+ <td>Who allows you to search for users. Masks
+ include: nickname, #channel, hostmask (*.attbi.com)<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">whowas <nick> <maxreplies></td>
+ <td>Displays information on a nick that has logged off. The <max replies>
+ field is optional, and limits how many records will be returned.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">ison <nick1 nick2 nick3 ...></td>
+ <td>Allows you to check the online status of a user, or a list of users. Simple
+ return, best used for scripts<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">join <channel1,channel2, ...></td>
+ <td>Allows you to join channels. Using the /join #channel1,#channel2,#channel3
+ will allow you to join more than one channel at a time. The /join 0 command
+ makes you PART all channels.</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">cycle <channel1, channel2, ...></td>
+ <td>Cycles the given channel(s). This command is equivalent
+ to sending a PART then a JOIN command.</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">motd <server></td>
+ <td>Displays the servers motd. Adding a server name allows you to view motd’s
+ on other servers.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">rules <server></td>
+ <td>Displays the ircd.rules of a server. Adding a server name allows you to
+ view rules on other servers</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">lusers <server> </td>
+ <td>Displays current & max user loads, both global and local. Adding a server name
+ allows you to view the statistics from other servers.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">map</td>
+ <td>Displays a network map</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">quit <reason></td>
+ <td>Causes you to disconnect from the server. If you include a reason, it
+ will be displayed on all channels as you quit</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">ping <user></td>
+ <td>Sends a PING request to a user. Used for checking connection and lag.
+ Servers issue pings on a timed basis to determine if users are still connected.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">version <nick></td>
+ <td>Sends a CTCP Version request to the user. If configured to do so, their
+ client will respond with the client version.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">links</td>
+ <td>Displays a list of all servers linked to the network</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">Admin <server></td>
+ <td>Displays the admin info of a server. If a server name is included it will
+ display the info of that server.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">userhost <nick></td>
+ <td>Displays the userhost of the nick given. Generally used for scripts<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">topic <channel> <topic></td>
+ <td>Topic <channel> will display the current topic of the given channel. Topic
+ <channel> <topic> will change the topic of the given channel.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">invite <nick> <channel></td>
+ <td>Invites the given user to the given channel. (Must be a channel Op)<br></td>
+ <td>ChanOp</td>
+ </tr>
+ <tr>
+ <td height="39">kick <channel, channel> <user, user> <reason></td>
+ <td>Kicks a user or users out of a channel, or channels. A reason may also
+ be supplied. <br></td>
+ <td>ChanOp</td>
+ </tr>
+ <tr>
+ <td height="39">away <reason></td>
+ <td>Marks you as being away. A reason may also be supplied.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">Watch +-<nick> +-<nick><br></td>
+ <td>Watch is a new notify-type system in UnrealIRCd which is both faster and
+ uses less network resources than any old-style notify system. The server
+ will send you a message when any nickname in your watch list logs on or
+ off. The watch list DOES NOT REMAIN BETWEEN SESSIONS - you (or your script
+ or client) must add the nicknames to your watch list every time you connect
+ to an IRC server.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">helpop ?<topic> or !<topic><br></td>
+ <td>HelpOp is a new system of getting IRC Server help. You type either /HELPOP
+ ? <help system topic> or /HELPOP ! <question> The "?"
+ in /HELPOP means query the help system and if you get no response you can
+ choose '!' to send it to the Help Operators online. Using neither ? nor !
+ will mean the command will be first queried within the help system and if
+ no match if found , it will be forwarded to the help operators</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">list <search string></td>
+ <td>
+ If you don't include a search string, the default is to send you the entire
+ unfiltered list of channels. Below are the options you can use, and what
+ channels LIST will return when you use them.<br> >number List channels
+ with more than <number> people.<br> <number List channels with
+ less than <number> people.<br>
+ C>number List channels created between now and <number> minutes
+ ago.<br>
+ C<number List channels created earlier than <number> minutes ago.<br>
+ T>number List channels whose topics are older than <number> minutes
+ (Ie., they have not changed in the last <number> minutes.<br>
+ T<number List channels whose topics are newer than <number> minutes.<br>
+ *mask* List channels that match *mask*<br>
+ !*mask* List channels that do not match *mask*<br> </td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">Knock <channel> <message><br></td>
+ <td>Allows you to ‘knock’ on an invite only channel and ask for
+ access. Will not work if channel has one of the following modes set: +K
+ +V. Will also not work if you are banned<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">setname</td>
+ <td>Allows users to change their ‘Real Name’ without reconnecting<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">vhost <login> <password></td>
+ <td>Hides your host name by using a vhost provided by the server. <br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">mode <chan/nick> <mode><br></td>
+ <td>Lets you set channel and user modes. See
+ <a href="#userchannelmodes">User & Channel Modes</a> for a list.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">credits</td>
+ <td>Lists credits for everyone that has helped create UnrealIRCd<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">license</td>
+ <td>Displays the GNU License</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">time <server></td>
+ <td>Displays the servers date and time. Including a server name allows you
+ to check other servers.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">botmotd <server><br></td>
+ <td>Displays the servers bot message of the day. Including a server name allows
+ you to check other servers</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">identify <password></td>
+ <td>Sends your password to the services system to identify to your nick.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">identify <channel> <password></td>
+ <td>Sends your password to the services system to identify as the founder
+ of a channel.<br></td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">dns <option></td>
+ <td>Returns information about the IRC server's DNS cache.
+ Note, since most clients have a built-in DNS command,
+ you will most likely need to use /raw DNS to use this.
+ Opers may specify an l as the first parameter to the command
+ to receive a list of entries in the DNS cache.</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">userip <nick><br></td>
+ <td>Returns the IP address of the user in question.</td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="39">oper <userid> <password><br></td>
+ <td>Command to give a user operator status if they match an Oper Block<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">wallops <message></td>
+ <td>Sends a message to all users with umode +w</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">globops <message></td>
+ <td>Sends a message to all global IRCops</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">chatops <message></td>
+ <td>Sends a message to all IRCops (local and global)</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">locops <message></td>
+ <td>Sends a message to all local IRCops</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">adchat <message></td>
+ <td>Sends a message to all Admins</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">nachat <message></td>
+ <td>Sends a message to all Net Admins</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">kill <nick> <reason></td>
+ <td>Kills a user from the network</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">kline [+|-]<user@host | nick> [<time to ban> <reason>]</td>
+ <td>Bans the hostmask from the server it is issued on. A kline is not a global ban.<br>
+ <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.
+ Time and reason are optional, if unspecified set::default-bantime (default: 0/permanent) and 'no reason' are used.<br>
+ To remove a kline use /kline -user@host</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">zline [+|-]<*@ip> [<time to ban> <reason>]</td>
+ <td>Bans an IP Address from the local server it is issued on (not global). See kline for more syntax info.
+ Use /zline -*@ip to remove.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">gline [+|-]<user@host | nick> [<time to ban> <reason>]<br></td>
+ <td>Adds a global ban to anyone that matches. See kline for more syntax info.
+ Use /gline -user@host to remove.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">shun [+|-]<user@host | nick> [<time to shun> <reason>]<br></td>
+ <td>Prevents a user from executing ANY commands and prevents them from speaking.
+ Shuns are global (like glines). See kline for more syntax info.
+ Use /shun -user@host to remove a shun.
+ <br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">gzline [+|-]<ip> <time to ban> :<reason><br></td>
+ <td>Adds a global zline. See kline for more syntax info.
+ Use /gzline -*@ip to remove a gzline.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">rehash <server> –<flags></td>
+ <td>Rehashes the servers config file. Including a server name allows you to
+ rehash a remote servers config file. Several flags are also available. They
+ Include <br>
+ -motd - Only rehash all MOTD and RULES files (including tld {})<br>
+ -opermotd - Only rehash the OPERMOTD file<br>
+ -botmotd - Only rehash the BOTMOTD file<br>
+ -garbage - Force garbage collection<br>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">restart <password> <reason><br></td>
+ <td>Restarts the IRCD Process. Password is required if drpass { } is present.
+ You may also include a reason.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">die <password><br></td>
+ <td>Terminates the IRCD Process. Password is required if drpass { } is present.</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">lag <server> <br></td>
+ <td>This command is like a Sonar or Traceroute for IRC server. You type in
+ /LAG irc.fyremoon.net and it will reply from every server it passes with
+ time and so on. Useful for looking where lag is and optional TS future/past
+ travels<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">sethost <newhost></td>
+ <td>Lets you change your vhost to what ever you want it to be.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">setident <newident><br></td>
+ <td>Lets you set your ident to what ever you want it to be<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">chghost <nick> <newhost><br></td>
+ <td>Lets you change the host name of a user currently on the system<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">chgident <nick> <newident><br></td>
+ <td>Lets you change the ident of a user currently on the system<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">chgname <nick> <newname><br></td>
+ <td>Lets you change the realname of a user currently on the system<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">squit <server><br></td>
+ <td>Disconnects a server from the network<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">connect <server> <port> <server></td>
+ <td>If only one server is given, it will attempt to connect the server you
+ are ON to the given server. If 2 servers are given, it will attempt to connect
+ the 2 servers together. Put the leaf server as the first, and the hub server
+ as the second.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">dccdeny <filemask> <reason><br></td>
+ <td>Adds a DCCDENY for that filemask. Preventing that file from being sent.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">undccdeny <filemask><br></td>
+ <td>Removes a DCCDENY</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">sajoin <nick> <channel>, <channel><br></td>
+ <td>Forces a user to join a channel(s). Available to services & network
+ admins only</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">sapart <nick> <channel>, <channel><br></td>
+ <td>Forces a user to part a channel(s). Available to services & network
+ admins only.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">samode <channel> <mode><br></td>
+ <td>Allows Network & Services admins to change modes of a channel without
+ having ChanOps.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">rping <servermask><br></td>
+ <td>Will calculate in milliseconds the lag between servers<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">trace <servermask|nickname><br></td>
+ <td>When used on a user it will give you class and lag info. If you use
+ it on a server it gives you class/version/link info.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">opermotd <br></td>
+ <td>Displays the servers OperMotd File<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="39">addmotd :<text><br></td>
+ <td>Will add the given text to the end of the Motd<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">addomotd :<text><br></td>
+ <td>Will add the given text to the end of the OperMotd<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">sdesc <newdescription><br></td>
+ <td>Allows server admins to change the description line of their server without
+ restarting.<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">addline <text><br></td>
+ <td>Allows you to add lines to the unrealircd.conf<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">mkpasswd <password><br></td>
+ <td>Will encrypt a clear text password to add it to the unrealircd.conf<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">tsctl offset +/- <time><br></td>
+ <td>Adjust the IRCD’s Internal clock (Do NOT use if you do not understand
+ EXACTLY what it does)<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">tsctl time<br></td>
+ <td>Will give a TS Report</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">tsctl alltime</td>
+ <td>Will give a TS Report of ALL servers</td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">tsctl svstime <timestamp><br></td>
+ <td>Sets the TS time of all servers (Do NOT use if you do not understand EXACTLY
+ what it does)<br></td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">htm <option><br></td>
+ <td>Controls settings related to high traffic mode. High Traffic Mode (HTM)
+ basically disables certain user commands such as: list whois who etc in
+ response to extremely high traffic on the server. Options include: <br>
+ -ON Forces server into HTM <br>
+ -OFF Forces server out of HTM <br>
+ -NOISY Sets the server to notify users/admins when in goes in and out of HTM<br>
+ -QUIET Sets the server to NOT notify when going in and out of HTM<br>
+ -TO <value> Tell HTM at what incoming rate to activate HTM<br> </td>
+ <td>IRCop</td>
+ </tr>
+ <tr>
+ <td height="36">stats <option><br></td>
+ <td>
+ B - banversion - Send the ban version list<br>
+ b - badword - Send the badwords list<br>
+ C - link - Send the link block list<br>
+ d - denylinkauto - Send the deny link (auto) block list<br>
+ D - denylinkall - Send the deny link (all) block list<br>
+ e - exceptthrottle - Send the except throttle block list<br>
+ E - exceptban - Send the except ban and except tkl block list<br>
+ f - spamfilter - Send the spamfilter list<br>
+ F - denydcc - Send the deny dcc block list<br>
+ G - gline - Send the gline and gzline list<br>
+ Extended flags: [+/-mrs] [mask] [reason] [setby]<br>
+ m Return glines matching/not matching the specified mask<br>
+ r Return glines with a reason matching/not matching the specified reason<br>
+ s Return glines set by/not set by clients matching the specified name<br>
+ I - allow - Send the allow block list<br>
+ j - officialchans - Send the offical channels list<br>
+ K - kline - Send the ban user/ban ip/except ban block list<br>
+ l - linkinfo - Send link information<br>
+ L - linkinfoall - Send all link information<br>
+ M - command - Send list of how many times each command was used<br>
+ n - banrealname - Send the ban realname block list<br>
+ O - oper - Send the oper block list<br>
+ P - port - Send information about ports<br>
+ q - sqline - Send the SQLINE list<br>
+ Q - bannick - Send the ban nick block list<br>
+ r - chanrestrict - Send the channel deny/allow block list<br>
+ R - usage - Send usage information<br>
+ S - set - Send the set block list<br>
+ s - shun - Send the shun list<br>
+ Extended flags: [+/-mrs] [mask] [reason] [setby]<br>
+ m Return shuns matching/not matching the specified mask<br>
+ r Return shuns with a reason matching/not matching the specified reason<br>
+ s Return shuns set by/not set by clients matching the specified name<br>
+ t - tld - Send the tld block list<br>
+ T - traffic - Send traffic information<br>
+ u - uptime - Send the server uptime and connection count<br>
+ U - uline - Send the ulines block list<br>
+ v - denyver - Send the deny version block list<br>
+ V - vhost - Send the vhost block list<br>
+ X - notlink - Send the list of servers that are not current linked<br>
+ Y - class - Send the class block list<br>
+ z - zip - Send compression information about ziplinked servers (if compiled with ziplinks support)<br>
+ Z - mem - Send memory usage information<br>
+ </td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="36">module<br></td>
+ <td>
+ Lists all loaded modules
+ </td>
+ <td>All</td>
+ </tr>
+ <tr>
+ <td height="36">close<br></td>
+ <td>
+ This command will disconnect all unknown connections from the IRC server.
+ </td>
+ <td>IRCOp</td>
+ </tr>
+</table>
+
+<p></p></div>
+
+<p><font size="+2"><b>8 – Security tips/checklist<a name="security"></a></b></font></p>
+<div class="desc">
+<p>If you are concerned about security (you should be!), this section will help you get an overview
+of the risks that are out there and their risk-level. Alternatively you can use it as a "checklist"
+to walk through your (network) configuration to make things more secure.</p>
+<p>The list is ordered by by popularity/risk level/most-often-used-attack-methods:</p>
+</div></p>
+
+<p><b><font size="+2">8.1 Passwords</font></b><a name="secpasswords"></a><br><div class="desc">
+Choose good oper passwords, link passwords, etc:<br>
+- use mixed case and digits ("Whbviwf5") and/or something long ("blaheatsafish", "AlphaBeta555").<br>
+- DO NOT use your link/oper passwords for something else like your mail account, bot password, forums, etc...<br>
+</div></p>
+
+<p><b><font size="+2">8.2 Non-Ircd related vulnerabilities</font></b><a name="secnonircd"></a><br><div class="desc">
+There's a far bigger chance a box will get hacked by a non-irc(d) vulnerability than by some bug in UnrealIRCd.
+If you for example run http, dns, smtp and ftp servers on the same box you have a much higher risk.
+Also, if you are on a multi-user box (eg: you bought a shell) there's the risk of local exploits and bad permissions
+(see next). This risk is quite high so be careful when selecting a shell provider.
+</div></p>
+
+<p><b><font size="+2">8.3 Permissions and the configfile</font></b><a name="secpermissions"></a><br><div class="desc">
+Always make sure your home directory and UnrealIRCd directory have correct permissions,
+(group/)other shouldn't have read permissions. Otherwise a local user can simply grab
+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>
+Other things related to this: never put your UnrealIRCd inside the webroot or some other
+kind of shared directory. And for backups, make sure they get the correct permissions too
+(it happens quite frequently everything is secured fine but there's a backup.tar.gz lying
+around readable by everyone).<br>
+<br>
+You also want to use encrypted passwords wherever possible, if you compile with OpenSSL
+support (which you do, since you are concerned with security, right?) then I suggest to
+use <i>sha1</i> or <i>ripemd160</i> password encryption, else use <i>md5</i>. Also if
+you still have encrypted (oper) blocks left from Unreal3.2.1 or before I suggest you to
+re-enrypt these (just re-run /mkpasswd), because 3.2.1 introduced some considerable
+anti-crack improvements (basically a 14x slowdown of active cracks, and making
+stored-plain-ciphertext cracks impossible).<br>
+Still, do note that this is just 'yet another layer of security', since if you have weak
+passwords they can still be cracked relatively easily and if someone manages to get your
+configfile there are usually other interesting things in it that may aid an attacker,
+like link::password-connect.
+</div></p>
+
+<p><b><font size="+2">8.4 User-related problems</font></b><a name="secuser"></a><br><div class="desc">
+Just like most of these things, this is not UnrealIRCd-specific, but..<br>
+Always choose your opers and admins wisely. And do remember the concept of weakest-link.
+Even though you are careful and did everything in this doc, maybe your friend which is an
+oper too did something stupid. Like share his harddrive via netbios/kazaa/morpheus/..,
+got a trojan, used an obvious password, etc etc.. Unfortunately, it's not always in your control.<br>
+One thing you could do however is carefuly choose which privileges someone needs (oper::flags).
+</div></p>
+
+<p><b><font size="+2">8.5 SSL/SSH & sniffing</font></b><a name="secsnif"></a><br><div class="desc">
+Use SSL connections between servers and as an oper, this will protect you against "sniffing".
+Sniffing is possible if an attacker hacked a box somewhere between you and your ircd server,
+he can then look at ALL network traffic that passes by; watch all conversations, capture all passwords
+(oper logins, nickserv, etc).. For the same reason, always use ssh instead of telnet.
+</div></p>
+
+<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">
+A lot of networks have experienced how much "fun" a flood or (D)DoS attack is, you can however
+do some things to reduce the damage caused by it. Most nets have a hub server, what some people
+seem to forget is that it's quite easy to protect the hub server from getting attacked.<br>
+I'll explain it here:<br>
+1. Set the name of the hub to a hostname that doesn't exist, eg 'hub.yournet.com', but<br>
+ don't add a dns record for it. This way an attacker cannot resolve the host and<br>
+ cannot flood it either. Then simply link your servers to the hub by specifying the<br>
+ IP or another non-public hostname.<br>
+ Example 1: <i>link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };</i>.<br>
+ Example 2: <i>link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };</i>.<br>
+ On a sidenote, for the last example you must be sure your nameservers don't allow zone transfers,
+ but that's way too off-topic ;).<br>
+2. Another important step is then to hide '/stats c' and other stats information, otherwise<br>
+ attackers can simply list your link blocks. Usually if you are this paranoid (like<br>
+ me) you can simply do: set { oper-only-stats "*"; }; to restrict all /stats usage.<br>
+ If you don't want that, at least hide "CdDlLXz". More about this in the next section.<br>
+<br>
+Of course those steps are less useful if they are applied afterwards (eg: after a few months)<br>
+instead of at the beginning because the IP's might be already known to some evil guys, still.. it's worth to do.<br>
+Also note that attackers can still flood all non-hub servers, but that requires more effort<br>
+than just attacking 1 or 2 weak points (the hubs), also this way your hubs & services
+will stay alive :).<br>
+</div></p>
+
+<p><b><font size="+2">8.7 Information disclosure</font></b><a name="secinformation"></a><br><div class="desc">
+<b>STATS</b><br>
+The /stats command is very informative, you probably want to restrict it's usage as much
+as possible. A question you should ask yourself is "what do I want my users to see?".
+Most big networks choose "nothing", while others prefer their clients to be able to do
+'/stats g' and '/stats k'.<br>
+I suggest you to use <i>set { oper-only-stats "*"; };</i> to deny all /stats for non-opers, but if you don't
+want that, step through the '/stats' list (gives an overview of all available options) and
+block everything except what you want to allow.. (if in doubt, just deny.. why should they
+really need to know all this?).<br>
+To give you a few examples:<br>
+- /stats o: gives you the nicks of opers (with correct case) and hostmasks.<br>
+- /stats c: gives you an idea about serverlinks and which to use as 'backup', etc..<br>
+- /stats g, /stats k: usually used for banning proxies.. so this will simply give attackers
+ a list of proxies they can use.<br>
+- /stats E, /stats e: pretty sensitive info, especially if an attacker can use these addresses<br>
+- /stats i, /stats y: might aid an attacker in finding hosts which allow lots of connections.<br>
+- /stats P: helps him find serveronly ports<br>
+etc etc...<br>
+<br>
+<b>MAP / LINKS</b><br>
+Several people have asked if there was some way to disable /map or /links.
+Our position on this is that it's silly and gives a false sense of security, let me explain...
+Hiding servers that are actually used by users is useless since they already know
+about your servers (how else could they get on them in the first place?). For any servers that you
+don't want users on, see section 8.6.<br>
+Now what CAN you do? Since 3.2.1 there's an option called 'flat map' (set::options::flat-map),
+this will make all servers appear as 'directly linked' in /map and /links, thus normal users
+can no longer see which server is linked to which... This can be a nice additional layer
+of protection because this way a kiddie cannot easily spot any 'weak points' with /map or /links.
+So, use of this is recommended. Note that this is not foolproof... If any split happends someone
+can still see which server was linked to which, and this is also true for some other things as well.<br>
+<br>
+<b>NORMAL USERS & SNOMASKS</b><br>
+A feature that isn't widely known is that normal users can also set some limited snomasks,
+namely +s +sk. By this they can see things like rehashes, kills and various other messages.<br>
+To disable this you can use set::restrict-usermodes like this: <i>set { restrict-usermodes "s"; };</i>.<br>
+
+
+<br><br>
+Of course all of this is "information hiding", so it's not "true" security.
+It will however make it more difficult / increase the effort needed to attack/hack.<br>
+</div></p>
+
+<p><b><font size="+2">8.8 Protecting against exploits</font></b><a name="secantiexploit"></a><br><div class="desc">
+There are kernel patches that make it more difficult for stack- and heap-based exploits to
+work. This is nice, but should not be your main focus point, you have a far more bigger risk
+of getting exploited through the other points than this... for various reasons.<br>
+Another option is enabling chrooting (*NIX only), which means upon a succesfull exploit,
+the user is confined to the UnrealIRCd directory and cannot touch any other
+files. This requires root privileges, modifying of include/config.h
+(search for CHROOTDIR, and also set IRC_USER and IRC_GROUP), and a
+recompile.<br>
+<br>
+There's one thing you should definately do, which is to ALWAYS USE THE LATEST VERSION,
+subscribe to the <a href="http://mail1.sourceforge.net/mailman/listinfo/unreal-notify" target="_blank">unreal-notify mailinglist</a>
+right now so you receive the release announcements (unreal-notify is for release announcements only,
+so only 1 mail per X months). Usually it's explicitly mentioned in the release announcement if the
+release contains (high risk) security fixes, but it's good to upgrade anyway.<br>
+</div></p>
+
+<p><b><font size="+2">8.9 Summary</font></b><a name="secsummary"></a><br><div class="desc">
+As you now hopefully understand, you can never be 100% secure. You (and us) have to
+find&fix every hole out there, while an attacker only needs to find just 1 server with 1 hole.
+Everything that was explained here DOES however help by minimizing the risks considerably.
+Do take the time to secure your network and educate your opers. A lot of people don't care about
+security until they got hacked, try to avoid that :).
+</div></p>
+
+
+<p><font size="+2"><b>9 – Frequently Asked Questions (FAQ)<a name="faq"></a></b></font></p>
+<div class="desc"><p>The FAQ is available online <a href="http://www.vulnscan.org/UnrealIRCd/faq/" TARGET="_blank">here</a></p></div>
+<p></p>
+
+<p><font size="+2"><b>A Regular Expressions<a name="regex"></a></b></font></p>
+<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>
+
+<p><font size="+2"><b>A.1 Literals<a name="regexlit"></a></b></font></p>
+<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>
+
+<p><font size="+2"><b>A.2 Dot Operator<a name="regexdot"></a></b></font></p>
+<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>
+
+<p><font size="+2"><b>A.3 Repetition Operators<a name="regexrep"></a></b></font></p>
+<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.
+<p>
+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".
+<p>
+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 "a*c" 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."
+<p>
+The + operator is very similar to the *. However, instead of matching 0 or more, it matches 1 or more. Basically, "a*c" 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.
+<p>
+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,}".
+<p>
+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>
+HELLO<br>
+And the following regex:<br>
+.+L<p>
+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>
+
+<p><font size="+2"><b>A.4 Bracket Expressions<a name="regexbracket"></a></b></font></p>
+<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."
+<p>
+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 -.
+<p>
+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:
+<ul>
+<li><tt>alnum</tt> - alphanumeric characters</li>
+<li><tt>alpha</tt> - alphabetic characters</li>
+<li><tt>blank</tt> - blank characters</li>
+<li><tt>cntrl</tt> - control characters</li>
+<li><tt>digit</tt> - decimal digits (0 through 9)</li>
+<li><tt>graph</tt> - all printable characters except space</li>
+<li><tt>lower</tt> - lower-case letters</li>
+<li><tt>print</tt> - printable characters including space</li>
+<li><tt>punct</tt> - printable characters not space or alphanumeric</li>
+<li><tt>space</tt> - white-space characters</li>
+<li><tt>upper</tt> - upper case letters</li>
+<li><tt>xdigit</tt> - hexadecimal digits</li>
+</ul>
+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:]-]".
+<p>
+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>
+<p><font size="+2"><b>A.5 Assertions<a name="regexassert"></a></b></font></p>
+<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.
+<p>
+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."
+<p>
+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.
+<p>
+The remaining assertions all come with two forms, a positive and a negative. These assertions are listed below:
+<ul>
+<li><tt>\b</tt> - Word boundary
+<li><tt>\B</tt> - Non-word boundary
+<li><tt>\d</tt> - Digit character (equivalent to <tt>[[:digit:]]</tt>)</li>
+<li><tt>\D</tt> - Non-digit character (equivalent to <tt>[^[:digit:]]</tt>)</li>
+<li><tt>\s</tt> - Space character (equivalent to <tt>[[:space:]]</tt>)</li>
+<li><tt>\S</tt> - Non-space character (equivalent to <tt>[^[:space:]]</tt>)</li>
+<li><tt>\w</tt> - Word character (equivalent to <tt>[[:alnum:]_]</tt>)</li>
+<li><tt>\W</tt> - Non-word character (equivalent to <tt>[^[:alnum:]_]</tt>)</li>
+</ul>
+</div>
+<p><font size="+2"><b>A.6 Alternation<a name="regexalt"></a></b></font></p>
+<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).
+</div>
+<p><font size="+2"><b>A.7 Subexpressions<a name="regexsub"></a></b></font></p>
+<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>
+<p><font size="+2"><b>A.8 Back References<a name="regexbackref"></a></b></font></p>
+<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.
+<p>
+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>
+<p><font size="+2"><b>A.9 Case Sensitivity<a name="regexcase"></a></b></font></p>
+<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.
+</body>
+</html>
diff --git a/go.mod b/go.mod
index c9d6b80..5c388bb 100644
--- a/go.mod
+++ b/go.mod
@@ -1,6 +1,7 @@
module github.com/fluffle/goirc
require (
+ github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead
github.com/golang/mock v1.5.0
golang.org/x/net v0.0.0-20210119194325-5f4716e94777
)
diff --git a/go.sum b/go.sum
index 4a29870..d8b7012 100644
--- a/go.sum
+++ b/go.sum
@@ -1,9 +1,10 @@
+github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead h1:fI1Jck0vUrXT8bnphprS1EoVRe2Q5CKCX8iDlpqjQ/Y=
+github.com/emersion/go-sasl v0.0.0-20220912192320-0145f2c60ead/go.mod h1:iL2twTeMvZnrg54ZoPDNfJaJaqy0xIQFuBdrLsmspwQ=
github.com/golang/mock v1.5.0 h1:jlYHihg//f7RRwuPfptm04yp4s7O6Kw8EZiVYIGcH0g=
github.com/golang/mock v1.5.0/go.mod h1:CWnOUgYIOo4TcNZ0wHX3YZCqsaM1I1Jvs6v3mP3KVu8=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
-golang.org/x/net v0.0.0-20180926154720-4dfa2610cdf3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
golang.org/x/net v0.0.0-20210119194325-5f4716e94777 h1:003p0dJM77cxMSyCPFphvZf/Y5/NXf5fzg6ufd1/Oew=
Debdiff
[The following lists of changes regard files as different if they have different names, permissions or owners.]
Files in second set of .debs but not in first
-rw-r--r-- root/root /usr/share/gocode/src/github.com/fluffle/goirc/client/sasl_test.go
No differences were encountered in the control files