Create branch unreal33.

Reported by fbi (#0004030).

.CHANGES.NEW

@@ -7,7 +7,7 @@
  \___/|_| |_|_|  \___|\__,_|_|\___/\_| \_| \____/\__,_|
 
                                Configuration Program
-                                for Unreal3.2.9-RC1
+                                for Unreal3.2.9-RC2
                                     
 This program will help you to compile your IRC server, and ask you
 questions regarding the compile-time settings of it during the process. 

.RELEASE.NOTES

@@ -1,4 +1,4 @@
-Unreal3.2.9-RC1 Release Notes
+Unreal3.2.9-RC2 Release Notes
 ============================
 
 ==[ GENERAL INFORMATION ]==
@@ -15,6 +15,8 @@ Unreal3.2.9-RC1 Release Notes
   of the changes in this release. There have been 160+ changes, twice as much
   as usual for a release, hence this summary is a bit long too.
   For the FULL list of changes, see the Changelog.
+- If you previously used CVS to access the development version of UnrealIRCd,
+  you now need to use Mercurial, see see http://www.unrealircd.com/hgmove
 
 ==[ NEW ]==
 - Extban ~j: this only prevents a user from joining, once in he can speak freely.

.cvsignore

@@ -1,10 +0,0 @@
-src/ssl.rnd
-src/win32/devel/StackTrace.lib
-src/win32/gnu_regex.lib
-
-Makefile
-config.log
-config.status
-config.settings
-ssl.rnd
-unreal

.hgeol

@@ -0,0 +1,16 @@
+[repository]
+native = LF
+
+[patterns]
+.RELEASE.NOTES = native
+README = native
+Unreal.nfo = native
+makefile.win32 = native
+Changes = native
+**.c = native
+**.h = native
+**.conf = native
+**.html = native
+**.txt = native
+**.bat = native
+**.iss = native

.hgignore

@@ -0,0 +1,22 @@
+syntax: regexp
+
+# particular targets
+^ircdcron/ircdchk$
+^ircdcron/ircd\.cron$
+^src/ircd$
+^src/include$
+^src/version\.c$
+^unreal$
+
+# General
+\.(o|so|orig|rej)$
+~$
+
+# autotools
+^config\.(status|log)$
+
+# not quite autotools
+^config\.settings$
+^include/setup\.h$
+^Makefile$
+^src/modules/Makefile$

Changes

@@ -2274,3 +2274,36 @@
 - Module coders: Added HOOKTYPE_HANDSHAKE which is called before the client
   handshake, IOTW: as soon as the connection is established. This can be used
   to do things prior to accepting any commands, such as sending some text.
+- Moved from cvs to hg (thanks binki!), this means cvs from this point in
+  time should no longer be used (the lastest CVS version will not compile,
+  this has been done on-purpose).
+  The new way to access the development version of UnrealIRCd is:
+  hg clone http://hg.unrealircd.org/unreal
+  If you get something like 'hg: command not found' then you need to
+  install mercurial. Most *NIX systems have such a 'mercurial' package,
+  but if you don't, or you are on Windows or Mac OS X, then grab it at
+  http://mercurial.selenic.com/
+- Updated doc/compiling_win32.txt a bit.
+- The unreal32docs translations in Greek, Spanish and Dutch are marked as
+  out of date.
+- CRLF conversion of unreal32docs.gr.html
+- Zip links: once a link was zipped, the error message when closing the
+  connection was never actually sent (due to buffering). Hence, things like
+  the /SQUIT reason was never seen on the other side (just 'server closed
+  the connection'). This has now been fixed.
+- Fix compile failure introduced by last change when zip links are
+  disabled.
+- Check that the automatically-generated cloak keys fit unrealircd's
+  own criteria before printing them out. (#4017)
+- Added aliases/atheme.conf, provided by katsklaw (#0003990).
+- Support installing the ircd binary for people who set
+  --with-spath=<dpath>/bin/ircd.
+- Add missing quotation to doc/help.fr.conf (#4026 by MewT).
+- Remove temporary message (Unreal3.2.1) regarding cloaking modules.
+- Add a self-documented and commented files {} block to example.conf.
+- Another fix-for-fix of zip links buffering from a few weeks ago.
+  Reported by fbi (#0004030).
+- Win32: fix rehash from the command line not working, reported by Platzii
+  (#0004028).
+- Update curl-ca-bundle.crt
+** 3.2.9-rc2 release **

Donation

@@ -1,10 +1,10 @@
 UnrealIRCd is a free program, but we do put a lot of time, effort, and money
-into creating and maintaining Unreal. To make it easier for user's to show their
+into creating and maintaining Unreal. To make it easier for users to show their
 appreciation, the Unreal team has decided to accept donations through PayPal. If
 you like Unreal, and you'd like to see it continue to exist, please consider making
 a donation. We're not asking for anything huge, whatever you can afford is fine.
 
-PayPal Donation Link: http://www.unrealircd.com/donate
+PayPal Donation Link: http://unrealircd.com/donate.php
 
 If you don't want to use PayPal, or you want to donate something other than money,
 contact Syzop (syzop@unrealircd.com).
@@ -16,5 +16,3 @@ Please check the website for details.
 
 Thank you for your support,
 The UnrealIRCd Team
-
-[ $Id$ ]

Makefile.in

@@ -206,7 +206,7 @@ depend:
 
 install: all
 	$(INSTALL) -m 0700 -d $(IRCDDIR)
-	$(INSTALL) -m 0700 src/ircd $(BINDIR)
+	$(INSTALL) -m 0700 src/ircd $(BINDIR) 2>/dev/null || { $(INSTALL) -m 0700 -d "$$(dirname '$(BINDIR)')"; $(INSTALL) -m 0700 src/ircd $(BINDIR); }
 	$(INSTALL) -m 0700 -d $(IRCDDIR)/networks
 	$(INSTALL) -m 0600 networks/*.network $(IRCDDIR)/networks
 	$(INSTALL) -m 0700 networks/makenet $(IRCDDIR)/networks

Unreal.nfo

@@ -1,5 +1,5 @@
 ===============================================
-=            UnrealIRCd v3.2.9-RC1            =
+=            UnrealIRCd v3.2.9-RC2            =
 ===============================================
  This release was brought to you by:
 
@@ -20,7 +20,7 @@
 
   RC Testers:
   ===========
-  __THIS_NEEDS_TO_BE_UPDATED_BEFORE_3.2.9_RELEASE__
+  LqidSkin, goldenwolf, katsklaw, nph, selten, Simplicity
 
   Previous coders:
   ================
@@ -29,21 +29,11 @@
   * Many more..
 
   Internet Presence:
-  * http://unrealircd.com/
+  * http://www.unrealircd.com/
  
- CVS
- ====
- To get anonymous access: (read only)
- "cvs -d :pserver:anonymous@cvs.unrealircd.com:/cvs login"
-
- press enter when asked for password
- Then, choose the appropiate branch you want:
-
- latest 3.2 release ("stable"):
- "cvs -z3 -d :pserver:anonymous@cvs.unrealircd.com:/cvs checkout -r stable -d Unreal-stable unreal"
-
- latest 3.2 fixes / development ("unreal3_2_fixes"):
- "cvs -z3 -d :pserver:anonymous@cvs.unrealircd.com:/cvs checkout -r unreal3_2_fixes -d Unreal-stable unreal"
+ UnrealIRCd Bugtracker (Where to report bugs, make suggestions, and submit patches)
+ ===================================================================================
+ http://bugs.unrealircd.org/
 
  To get support
  ================
@@ -62,10 +52,23 @@
 	  are humans like you. We sometimes just need some peace.]
  * Forum: http://forums.unrealircd.com/
 
- UnrealIRCd Bugtracker (Where to report bugs, make suggestions, and submit patches)
- ==================================================================
- http://bugs.unrealircd.org/
+ Development version
+ ====================
+ To access the latest development version of UnrealIRCd you need to use mercurial (hg).
+ Note that because you are accessing a development version it may not compile, the
+ server may crash, or other problems can occur since the code is likely to be only
+ lightly tested (or not at all). On the other hand, using the development version may
+ help you to get rid of that single nasty bug that is haunting you, plus if you test
+ it and give us feedback (report bugs) then you actually help us with developing Unreal.
+
+ The command to grab the development version is:
+ hg clone http://hg.unrealircd.org/unreal
+
+ If you get something like 'hg: command not found' then you need to install mercurial.
+ Most *NIX systems have such a 'mercurial' package, but if you don't, or you are on
+ Windows or Mac OS X, then see http://mercurial.selenic.com/
 
  Want to discuss, chat, etc?
  =============================
  * IRC: /server irc.unrealircd.com 6667 - /join #chat
+   (NOT for support! If you want support then use #unreal-support instead!)

aliases/atheme.conf

@@ -0,0 +1,26 @@
+/* Atheme Aliases */
+
+alias nickserv { type services; };
+alias ns { target nickserv; type services; };
+alias chanserv { type services; };
+alias cs { target chanserv; type services; };
+alias memoserv { type services; spamfilter yes; };
+alias ms { target memoserv; type services; spamfilter yes; };
+alias operserv { type services; };
+alias os { target operserv; type services; };
+alias helpserv { type services; };
+alias botserv { type services; };
+alias bs { target botserv; type services; };
+alias hostserv { type services; };
+alias hs { target hostserv; type services; };
+alias saslserv { type services; };
+alias sss { target saslserv; type services; };
+alias gameserv { type services; };
+alias gms { target gameserv; type services; };
+alias groupserv { type services; };
+alias grs { target groupserv; type services; };
+alias alis { type services; };
+alias ls { target alis; type services; };
+
+include "aliases/aliases.conf";
+

autoconf/.cvsignore

@@ -1 +0,0 @@
-autom4te.cache

doc/coding-guidelines

@@ -1,142 +1,141 @@
-Rules about patches & modifications to UnrealIRCd
-
-1. When making a change, always add a small description in Changes, in the
-   BOTTOM. Don't forget to mention the bug# and credit the reporter (if any).
-
-2. If new files are made, it must contain proper copyright headers,
-   and a $Id$ somewhere.
-
-3. If you want to submit patches (f.e. if you don't have CVS write access)
-   then submit them to http://bugs.unrealircd.org/ (shortly called bugs*)
-   using "cvs diff -u > patchname". A submission must contain description of
-   what it does, etc.
-
-4. Each bug or feature should have a bug# so people can have a discussion
-   about it. This has a few implications (read!!):
-   * People must report bugs/feature requests to bugs* and not on
-     IRC, e-mail, etc.
-   * That means other people can see the bug# and comment on it. This means
-     discussion is easy to read back for each issue and not spread between
-     several IRC logs.
-     Furthermore, by using the bugtracker instead of directly committing,
-     people could point out that there might be a better way to do things
-     than you originally thought, or it might be that other devs don't like
-     it at all.
-   * If a head coder has 'acknowledged' or 'confirmed' the bug or stated in
-     a comment that it's OK to implement, then a dev may take the issue.
-     The dev should change the status to 'assigned' and work on it, then
-     commit and change it to 'resolved', set 'fixed in version' to next
-     release, and add a comment pasting the relevant Changelog item and the
-     releaseid (.XYZ).
-     Of course other guidelines, like #7 and #8 still apply.
-
-5. Do not commit changes that do not have an associated bug# and have not
-   had any discussion.
-   Small/tiny bugfixes that do not change any functionality, are very
-   unlikely to break anything and definitely don't require any prior
-   discussion may be exempted.
-
-6. Regarding reidenting, restructuring or other code cleanups: please
-   discuss before doing so. The other devs might not agree with you on the
-   particular cleanup you have in mind which would result in another
-   clean-up-the-cleanup commit.
-   You may, however reindent and clean up individual sections when you are
-   working on fixing a particular bug# or implementing a new feature. In fact
-   you're encouraged to do so if the code is confusing without it. However,
-   obey the style of Unreal's code (mostly outlined in this document)
-   and do not introduce yet another (new) style. Also, be careful with doing
-   any cleanup: if you're unsure in any way about the use of something,
-   or something that looks redundant on first sight, then look more
-   carefully... it might indeed be useless and/or redundant, but it might
-   also be a subtle thing that can create great bugs when 'cleaned up'.
-
-7. Prior to a release: be very careful with any restructuring of a subsystem
-   or doing any major commits that may break things. Stuff like this can be
-   perfectly fine if there are many months to go, but are not good to do a
-   month before release. The head coder may impose additional restrictions
-   during such a period.
-
-8. During the Release Candidate stage (from RC1 until the final release)
-   only the head coder may commit directly, all others should ask and
-   present their patch before committing. Yes, even if you are changing only
-   1 line of code or text.
-
-9. UnrealIRCd should compile on all supported operating systems and
-   platforms, using GCC 3 or higher on *NIX, and Visual Studio 2008 or
-   higher on Windows. This means you cannot blindly use all C99 extensions.
-
-10. Coders should test their code before committing.
-
-11. /*  
-     * These kind of comments
-     */
- 
-   NOT
- 
-   // These kind of comments
-
-12. 	if (something == 1) 
-   	{
-		moo; /* comment */
-		/* This does what what what */
-		cow(go(moo));
-	}
-	
-	NOT 
-	
-	if (something == 1) {
-	}
-	
-13. Do not touch version.c.SH or version.h, unless you are a head coder
-    if you need a credit in, contact us
-   
-14. Protocol changes must be discussed before making patches for it.
-
-15. We do NOT rip people off. If we use other people's code, it MUST be
-    properly credited.
-
-16. We generally use tabsize 4 and 8. In any case, use tabs and NOT spaces.
-    Some code is old and horrible and has a mix of tabs and spaces used for
-    spacing, that's something we do not want to have ;)
-
-17. Be careful about overflows. As you know a line from a user can never be longer
-    than 511 (510?) characters, sometimes you can use this knowledge to your
-    advantage. Whenever it's not safe or when you don't know what input size you
-    can expect, use strlcpy instead of strcpy. Do not ever use strncpy, this is
-    older, slower, and does not add proper zero termination.
-    For the same reason, use snprintf if really needed. Note though, that using
-    ircsprintf with a bigger buffer (eg: 1024 bytes) is MUCH faster, so preferably
-    use that instead of snprintf. The same can be true for strcpy vs strlcpy in
-    some circumstances as well.
-
-18. Speed.  When optimizing or writing code, keep in mind that readability and
-    stability comes FIRST, and after that comes speed. So we'd rather prefer some
-    readable code (even if difficult) over some odd highly optimized routine which
-    nobody understands, is difficult to extend, and might have several bugs.
-    As mentioned earlier: use ircsprintf, not sprintf (this is because ircsprintf
-    is optimized for simple strings like the ones we use).
-    Prefer ircsprintf with a bigger buffer over the use of snprintf, since
-    ircsprintf is much faster.
-
-19. Initialize your structs and use the proper memory calls.
-    In UnrealIRCd we use MyMalloc, MyMallocEx and MyFree (so not malloc/free).
-    MyMalloc usually maps to malloc, and MyMallocEx is a malloc plus filling
-    the memory area (eg: the struct) with zero's (a la calloc).
-    Use of MyMallocEx is suggested. In general you should not be using MyMalloc.
-    "But MyMalloc is faster!" you might say. This is true, but using MyMallocEx
-    has very little speed impact and enormous benefits: people tend to forget
-    to set certain fields in the struct to NULL, or much more common: when
-    someone later on (eg: 1 year later) adds a field to a struct, there could
-    be several places he/she needs to update to make sure x->something is NULL
-    after allocating a new struct. Bad idea.
-    Little speed impact, huge stability benefits, easy decision ;).
-
-20. Comment your code! This should speak for itself...
-    Put comments wherever you think they are needed, to aid any further coders
-    with reading your code.. and, in fact, it will aid yourself as well if you
-    would look back at your code 2 years later.
-    If there's some obscure pitfall, do mention it! Don't just "hope" a next
-    author will see it like you did.
-
-21. Use enums whenever possible, rather than #define constants. Besides making
-    things more clean, it also aids debugging.
+Rules about patches & modifications to UnrealIRCd
+
+1. When making a change, always add a small description in Changes, in the
+   BOTTOM. Don't forget to mention the bug# and credit the reporter (if any).
+
+2. If new files are made, it must contain proper copyright headers.
+
+3. If you want to submit patches (f.e. if you don't have CVS write access)
+   then submit them to http://bugs.unrealircd.org/ (shortly called bugs*)
+   using "cvs diff -u > patchname". A submission must contain description of
+   what it does, etc.
+
+4. Each bug or feature should have a bug# so people can have a discussion
+   about it. This has a few implications (read!!):
+   * People must report bugs/feature requests to bugs* and not on
+     IRC, e-mail, etc.
+   * That means other people can see the bug# and comment on it. This means
+     discussion is easy to read back for each issue and not spread between
+     several IRC logs.
+     Furthermore, by using the bugtracker instead of directly committing,
+     people could point out that there might be a better way to do things
+     than you originally thought, or it might be that other devs don't like
+     it at all.
+   * If a head coder has 'acknowledged' or 'confirmed' the bug or stated in
+     a comment that it's OK to implement, then a dev may take the issue.
+     The dev should change the status to 'assigned' and work on it, then
+     commit and change it to 'resolved', set 'fixed in version' to next
+     release, and add a comment pasting the relevant Changelog item and the
+     releaseid (.XYZ).
+     Of course other guidelines, like #7 and #8 still apply.
+
+5. Do not commit changes that do not have an associated bug# and have not
+   had any discussion.
+   Small/tiny bugfixes that do not change any functionality, are very
+   unlikely to break anything and definitely don't require any prior
+   discussion may be exempted.
+
+6. Regarding reidenting, restructuring or other code cleanups: please
+   discuss before doing so. The other devs might not agree with you on the
+   particular cleanup you have in mind which would result in another
+   clean-up-the-cleanup commit.
+   You may, however reindent and clean up individual sections when you are
+   working on fixing a particular bug# or implementing a new feature. In fact
+   you're encouraged to do so if the code is confusing without it. However,
+   obey the style of Unreal's code (mostly outlined in this document)
+   and do not introduce yet another (new) style. Also, be careful with doing
+   any cleanup: if you're unsure in any way about the use of something,
+   or something that looks redundant on first sight, then look more
+   carefully... it might indeed be useless and/or redundant, but it might
+   also be a subtle thing that can create great bugs when 'cleaned up'.
+
+7. Prior to a release: be very careful with any restructuring of a subsystem
+   or doing any major commits that may break things. Stuff like this can be
+   perfectly fine if there are many months to go, but are not good to do a
+   month before release. The head coder may impose additional restrictions
+   during such a period.
+
+8. During the Release Candidate stage (from RC1 until the final release)
+   only the head coder may commit directly, all others should ask and
+   present their patch before committing. Yes, even if you are changing only
+   1 line of code or text.
+
+9. UnrealIRCd should compile on all supported operating systems and
+   platforms, using GCC 3 or higher on *NIX, and Visual Studio 2008 or
+   higher on Windows. This means you cannot blindly use all C99 extensions.
+
+10. Coders should test their code before committing.
+
+11. /*  
+     * These kind of comments
+     */
+ 
+   NOT
+ 
+   // These kind of comments
+
+12. 	if (something == 1) 
+   	{
+		moo; /* comment */
+		/* This does what what what */
+		cow(go(moo));
+	}
+	
+	NOT 
+	
+	if (something == 1) {
+	}
+	
+13. Do not touch version.c.SH or version.h, unless you are a head coder
+    if you need a credit in, contact us
+   
+14. Protocol changes must be discussed before making patches for it.
+
+15. We do NOT rip people off. If we use other people's code, it MUST be
+    properly credited.
+
+16. We generally use tabsize 4 and 8. In any case, use tabs and NOT spaces.
+    Some code is old and horrible and has a mix of tabs and spaces used for
+    spacing, that's something we do not want to have ;)
+
+17. Be careful about overflows. As you know a line from a user can never be longer
+    than 511 (510?) characters, sometimes you can use this knowledge to your
+    advantage. Whenever it's not safe or when you don't know what input size you
+    can expect, use strlcpy instead of strcpy. Do not ever use strncpy, this is
+    older, slower, and does not add proper zero termination.
+    For the same reason, use snprintf if really needed. Note though, that using
+    ircsprintf with a bigger buffer (eg: 1024 bytes) is MUCH faster, so preferably
+    use that instead of snprintf. The same can be true for strcpy vs strlcpy in
+    some circumstances as well.
+
+18. Speed.  When optimizing or writing code, keep in mind that readability and
+    stability comes FIRST, and after that comes speed. So we'd rather prefer some
+    readable code (even if difficult) over some odd highly optimized routine which
+    nobody understands, is difficult to extend, and might have several bugs.
+    As mentioned earlier: use ircsprintf, not sprintf (this is because ircsprintf
+    is optimized for simple strings like the ones we use).
+    Prefer ircsprintf with a bigger buffer over the use of snprintf, since
+    ircsprintf is much faster.
+
+19. Initialize your structs and use the proper memory calls.
+    In UnrealIRCd we use MyMalloc, MyMallocEx and MyFree (so not malloc/free).
+    MyMalloc usually maps to malloc, and MyMallocEx is a malloc plus filling
+    the memory area (eg: the struct) with zero's (a la calloc).
+    Use of MyMallocEx is suggested. In general you should not be using MyMalloc.
+    "But MyMalloc is faster!" you might say. This is true, but using MyMallocEx
+    has very little speed impact and enormous benefits: people tend to forget
+    to set certain fields in the struct to NULL, or much more common: when
+    someone later on (eg: 1 year later) adds a field to a struct, there could
+    be several places he/she needs to update to make sure x->something is NULL
+    after allocating a new struct. Bad idea.
+    Little speed impact, huge stability benefits, easy decision ;).
+
+20. Comment your code! This should speak for itself...
+    Put comments wherever you think they are needed, to aid any further coders
+    with reading your code.. and, in fact, it will aid yourself as well if you
+    would look back at your code 2 years later.
+    If there's some obscure pitfall, do mention it! Don't just "hope" a next
+    author will see it like you did.
+
+21. Use enums whenever possible, rather than #define constants. Besides making
+    things more clean, it also aids debugging.

doc/compiling_win32.txt

@@ -23,6 +23,9 @@ use the FREE development kit available for Windows 7 explained below:
    Start Menu under Microsoft Windows SDK v7.0). Users on x64 environment will have
    to change their environment to x86 by typing 'SETENV /x86'.    
 
+3. Download http://www.vulnscan.org/tmp/dlltool.exe and put the file somewhere
+   in your path (eg: put it in c:\windows\system32).
+
 ==[ EXTERNAL LIBRARIES ]==
 Fetch the external libraries (c-ares, tre, openssl, zlib, curl) from:
 http://www.vulnscan.org/unrealwin32dev/
@@ -32,7 +35,7 @@ http://www.vulnscan.org/unrealwin32dev/
 2. Go to your UnrealIRCd dir (like: cd \dev\unreal3.2)
 3. Have a look at 'makefile.win32' to look at what parameters you need to
    use, this depends on what libraries you want to link in and their location.
-4. Two options, use either one (B is preferred):
+4. Two options, use either one (B is preferred), and read step 5 too:
    A. Edit makefile.win32 directly to reflect your configuration and run
       'nmake -f makefile.win32'
    B. Don't edit makefile.win32 but instead create a one-line command (which
@@ -46,7 +49,17 @@ http://www.vulnscan.org/unrealwin32dev/
       CARES_INC_DIR="C:\dev\c-ares" CARESLIB="cares.lib"
       TRE_LIB_DIR="C:\dev\tre\win32\release" TRE_INC_DIR="C:\dev\tre"
       TRELIB="tre.lib"
-5. Your compile is now done, you can package unreal if you have InnoSetup,
+5. You are likely to encounter an error like
+   M_OPER.obj : error LNK2019: unresolved external symbol _sendto_snomask_global
+   referenced in function _m_oper
+   (the exact name and symbol will differ!!)
+   In that case you need to generate a symbols file:
+   nmake -f makefile.win32 SYMBOLFILE
+   And after that simply re-run your nmake -f makefile.win32 [options]
+   command, the same command you ran before the error occured.
+   You should not get any unresolved external symbol error again.
+   If you still do, then something is wrong.
+6. Your compile is now done, you can package unreal if you have InnoSetup,
    in that case check out src\win32\unrealinst.iss
    Otherwise, manually copy over the necessary files (and the dll files
    from the external libraries).

doc/example.conf

@@ -517,7 +517,55 @@ alias "glinebot" {
 	type command;
 };
 
+/*
+ * NEW: files {}
+ * OLD: include/config.h
+ *
+ * This block overrides the IRCd's default paths for loading things
+ * like the MOTD, saving its PID, or writing/loading its tunefile. The
+ * existence of this block allows one UnrealIRCd installation to
+ * support multiple running instances when combined with the -c
+ * commandline option.
+ *
+ * As usual, relative paths are interpreted relative to the directory
+ * where UnrealIRCd would find unrealircd.conf if -c is _not_
+ * specified on the commandline.
+ */
+files
+{
+	/* The Message Of The Day shown to users who log in: */
+	/* motd ircd.motd; */
 
+	/*
+	 * A short MOTD. If this file exists, it will be displayed to
+	 * the user in place of the MOTD. Users can still view the
+	 * full MOTD by using the /MOTD command.
+	 */
+	/* shortmotd ircd.smotd; */
+
+	/* Shown when an operator /OPERs up */
+	/* opermotd oper.motd; */
+
+	/* Services MOTD append. */
+	/* svsmotd ircd.svsmotd; */
+
+	/* Bot MOTD */
+	/* botmotd bot.motd; */
+
+	/* Shown upon /RULES */
+	/* rules ircd.rules; */
+
+	/*
+	 * Where the IRCd stores and loads a few values which should
+	 * be persistent across server restarts. Must point to an
+	 * existing file which the IRCd has permission to alter or to
+	 * a file in a folder within which the IRCd may create files.
+	 */
+	/* tunefile ircd.tune; */
+
+	/* Where to save the IRCd's pid. Should be writable by the IRCd. */
+	/* pidfile ircd.pid; */
+};
 
 /*
  * NEW: tld {}

doc/help.fr.conf

@@ -919,7 +919,7 @@ help Rehash {
 	" Si ni <nom du serveur> ni [flag] n'est spécifié, ceci rechargera le fichier";
 	" unrealircd.conf et tous les fichiers MOTD, BOTMOTD, OPERMOTD et RULES.";
 	" Si <nom du serveur> est spécifié, ceci rechargera le serveur distant.";
-	" Si -global est spécifié, alors tous les serveurs sur le réseau seront rehashés.
+	" Si -global est spécifié, alors tous les serveurs sur le réseau seront rehashés.";
 	" Seuls les NetAdmins peuvent spécifier un nom de serveur ou -global.";
 	" -";
 	" Les flags sont utilisés pour recharger d'autres fichiers de configuration.";

doc/help.tr.conf

@@ -6,7 +6,7 @@
 * Unreal3.2 ve üzeri versionları kapsanmıştır. 8/24/02 (Beta12)
 *
 * Türkçe Çeviri: Diablo - (Serkan Sepetçi)
-* İletişim: diablo@unrealircd.org - http://www.ircforumlari.net/
+* İletişim: diablo@unrealircd.org
 */
 
 help {

doc/technical/serverprotocol.html

@@ -1,467 +1,467 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<!-- $Id$ -->
-<html>
-	<head>
-		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
-		<title>Unreal 3.2 Protocol Documentation</title>
-	</head>
-	<body>
-		<h1 style="text-align: center;">Unreal 3.2 Protocol Documentation</h1>
-		<h3 style="text-align: center;">Last update: 29 November 2006</h3>
-		<h1>Table of Contents</h1>
-		<p><a href="#S1">1 Introduction</a></p>
-		<p><a href="#S2">2 Server Negotiation</a></p>
-		<blockquote><p><a href="#S2_1">2.1 PASS - Connection Password</a></p></blockquote>
-		<blockquote><p><a href="#S2_2">2.2 PROTOCTL - Server Protocol Negotiation</a></p></blockquote>
-		<blockquote><p><a href="#S2_3">2.3 SERVER - Server Negotiation</a></p></blockquote>
-		<blockquote><p><a href="#S2_4">2.4 EOS - End Of Synch</a></p></blockquote>
-		<blockquote><p><a href="#S2_5">2.5 NETINFO - Network Information</a></p></blockquote>
-		<p><a href="#S3">3 User Operations</a></p>
-		<blockquote><p><a href="#S3_1">3.1 NICK - User Introduction and Nick Change</a></p></blockquote>
-		<blockquote><blockquote><p><a href="#S3_1_1">3.1.1 Nick Collisions</a></p></blockquote></blockquote>
-		<blockquote><p><a href="#S3_2">3.2 MODE, UMODE2 - User Mode Change</a></p></blockquote>
-		<blockquote><p><a href="#S3_3">3.3 QUIT - User Disconnect</a></p></blockquote>
-		<blockquote><p><a href="#S3_4">3.4 KILL - Force Disconnect</a></p></blockquote>
-		<blockquote><p><a href="#S3_5">3.5 SETHOST/CHGHOST - Change virtual host</a></p></blockquote>
-		<blockquote><p><a href="#S3_6">3.6 SETIDENT/CHGIDENT - Change a user's username</a></p></blockquote>
-		<blockquote><p><a href="#S3_7">3.7 SETNAME/CHGNAME - Change a user's realname</a></p></blockquote>
-		<blockquote><p><a href="#S3_8">3.8 WHOIS - User Information</a></p></blockquote>
-		<p><a href="#S1">4 Server Operations</a></p>
-		<blockquote><p><a href="#S4_1">4.1 SERVER - Server Introduction</a></p></blockquote>
-		<blockquote><p><a href="#S4_2">4.2 SQUIT - Server Removal</a></p></blockquote>
-		<blockquote><p><a href="#S4_3">4.3 SDESC - Server Description</a></p></blockquote>
-		<blockquote><p><a href="#S4_4">4.4 PING - Live Connection Query</a></p></blockquote>
-		<blockquote><p><a href="#S4_5">4.5 PONG - Live Connection Reply</a></p></blockquote>
-		<blockquote><p><a href="#S4_6">4.6 STATS - Server Stats</a></p></blockquote>
-		<p><a href="#S5">5 Channel Operations</a></p>
-		<blockquote><p><a href="#S5_1">5.1 SJOIN - Channel Burst</a></p></blockquote>
-		<blockquote><p><a href="#S5_2">5.2 JOIN - Channel Join</a></p></blockquote>
-		<blockquote><p><a href="#S5_3">5.3 PART - Channel Part</a></p></blockquote>
-		<blockquote><p><a href="#S5_4">5.4 KICK - Channel Kick</a></p></blockquote>
-		<blockquote><p><a href="#S5_5">5.5 MODE - Channel Mode</a></p></blockquote>
-		<blockquote><p><a href="#S5_6">5.6 INVITE - Invite a user to a channel</a></p></blockquote>
-		<blockquote><p><a href="#S5_7">5.7 SAJOIN - Channel Force Join</a></p></blockquote>
-		<blockquote><p><a href="#S5_8">5.8 SAPART - Channel Force Part</a></p></blockquote>
-		<blockquote><p><a href="#S5_9">5.9 SAMODE - Channel Force Mode</a></p></blockquote>
-		<blockquote><p><a href="#S5_10">5.10 TOPIC - Chanel Topic</a></p></blockquote>
-		<p><a href="#S6">6 Services Commands</a></p>
-		<blockquote><p><a href="#S6_1">6.1 SVSKILL - Force Disconnect by Service</a></p></blockquote>
-		<blockquote><p><a href="#S6_2">6.2 SVSMODE, SVS2MODE - Force User Mode Change</a></p></blockquote>
-		<blockquote><p><a href="#S6_3">6.3 SVSSNO, SVS2SNO - Forced SNomask Change</a></p></blockquote>
-		<blockquote><p><a href="#S6_4">6.4 SVSNICK - Forced Nick Change</a></p></blockquote>
-		<blockquote><p><a href="#S6_5">6.5 SVSJOIN - Forced Join</a></p></blockquote>
-		<blockquote><p><a href="#S6_6">6.6 SVSPART - Forced Part</a></p></blockquote>
-		<blockquote><p><a href="#S6_7">6.7 SVSO - Oper Permissions</a></p></blockquote>
-		<blockquote><p><a href="#S6_8">6.8 SVSNOOP - Oper Lockdown</a></p></blockquote>
-		<blockquote><p><a href="#S6_9">6.9 SVSNLINE - RealName Ban</a></p></blockquote>
-		<blockquote><p><a href="#S6_10">6.10 SVSFLINE - File Ban</a></p></blockquote>
-		<p><a href="#S7">7 Messaging</a></p>
-		<blockquote><p><a href="#S7_1">7.1 PRIVMSG, NOTICE - Simple Message Transmission</a></p></blockquote>
-		<blockquote><p><a href="#S7_2">7.2 SENDUMODE, SMO - Usermode-based Delivery</a></p></blockquote>
-		<blockquote><p><a href="#S7_3">7.3 SENDSNO - SNomask-based Delivery</a></p></blockquote>
-		<blockquote><p><a href="#S7_4">7.4 CHATOPS - IRCop Chat</a></p></blockquote>
-		<blockquote><p><a href="#S7_5">7.5 WALLOPS - Wallop Chat</a></p></blockquote>
-		<blockquote><p><a href="#S7_6">7.6 GLOBOPS - FailOp Chat</a></p></blockquote>
-		<blockquote><p><a href="#S7_7">7.7 ADCHAT - Admin Chat</a></p></blockquote>
-		<blockquote><p><a href="#S7_8">7.8 NACHAT - NetAdmin Chat</a></p></blockquote>
-		<p><a href="#S8">8 Ban Control</a></p>
-		<blockquote><p><a href="#S8_1">8.1 TKL - Master Ban Control</a></p></blockquote>
-		<blockquote><blockquote><p><a href="#S8_1_1">8.1.1 GLINE - Network-wide user@host ban</a></p></blockquote></blockquote>
-		<blockquote><blockquote><p><a href="#S8_1_2">8.1.2 GZLINE - Network-wide IP ban</a></p></blockquote></blockquote>
-		<blockquote><blockquote><p><a href="#S8_1_3">8.1.3 SQLINE, UNSQLINE - Network-wide Nickname ban</a></p></blockquote></blockquote>
-		<blockquote><blockquote><p><a href="#S8_1_4">8.1.4 SPAMFILTER - Message Spam Filtration System</a></p></blockquote></blockquote>
-		<p><a href="#S9">9 Base64 Tables</a></p>
-		<blockquote><p><a href="#S9_1">9.1 Table for SJB64 (NICK and SJOIN).</a></p></blockquote>
-		<blockquote><p><a href="#S9_2">9.2 Table for NICKIP.</a></p></blockquote>
-		<hr/>
-		<h1><a name="S1"></a>1 Introduction</h1>
-		<p>This document describes the UnrealIRCd server-to-server protocol as of protocol 2307 (Unreal 3.2.4). 
-		It is currently slightly out of date, as the current protocol is 2310, but that should not matter much.</p>
-		<h2>A word about clocks.</h2>
-		<p>Unreal is very time-dependant. Users and channels, for example, are timestamped, and if server clocks are not synchronized properly, things can go very wrong very fast. See <a href="http://vulnscan.org/UnrealIrcd/faq/#67">http://vulnscan.org/UnrealIrcd/faq/#67</a> for more information on this. Note that there is a slight difference between server time and what is actually reported by the UNIX date command or by the C time() function. Unreal can apply an offset to the real time to create the server time, allowing servers to be virtually synchronized when synchronizing the real clocks is not possible (such as on shell servers).
-			I should make it quite clear that GMT time is used for everything. To be specific, timestamps in unreal are 32-bit integer values (actually, however many bits the time_t type is, which is 32 on 32-bit systems such as x86). This integer value is the number of seconds that have elapsed since Midnight January 1, 1970 GMT (can be referred to as Epoch time in the UNIX world). This means that timezones are no problem, nor is daylight savings time (or whatever your country of choice calls it).</p>
-		<hr/>
-		<h1><a name="S2"></a>2 Server Negotiation</h1>
-		<p>The first step to establish a server-to-server communication is to negotiate the connection as a server. Negotiation is done using standard IRC commands - no PROTOCTL options are in force until the link is established. The first step is to open a TCP/IP connection to the target server. The target port must be one described by a listen {} block in the remote server's configuration, and that listen block must not have the clientsonly option. After the connection is open, you will be treated as any other connection and be greeted with the "Looking up your hostname..." and "Checking identd..." notices as you would for a client. As these are NOTICE messages and your session as a server isn't established, they should simply be ignored. Use the commands below to introduce a server connection.</p>
-		<h2><a name="S2_1"></a>2.1 PASS - Connection Password</h2>
-		<p><b>Syntax:</b> <tt>PASS :<i>link password</i></tt></p>
-		<p>The PASS command is used to transmit the password required for a server link. It must match the password specified in the remote server's link::password-receive (which can be crypted), otherwise the link will be rejected. This should be the first message sent.</p>
-		<h2><a name="S2_2"></a>2.2 PROTOCTL - Server Protocol Negotiation</h2>
-		<p><b>Syntax:</b> <tt>PROTOCTL <i>protocol options</i></tt></p>
-		<p>The PROTOCTL command sets several protocol options. The tokens supported are listed below.</p>
-		<ul>
-			<li>NOQUIT : When a netsplit occurs, only send a SQUIT message for each server lost. This server will assume that clients on these servers were also lost and will send the appropriate QUIT messages to local clients and to any non-NOQUIT servers.</li>
-			<li>TOKEN : Use tokenized commands. Tokens are case-sensitive, shortened versions of command names. Tokens will be usually one or two characters.</li>
-			<li>NICKv2 : Use extended NICK message for introducing users. See the NICK command for information about this.</li>
-			<li>VHP : When introducing a user, send his cloaked host as if it were a vhost. Usually used for services to avoid having duplicate code.</li>
-			<li>SJOIN : Supports SJOIN version 1 which is no longer in use. Use with SJ3.</li>
-			<li>SJOIN2 : Supports SJOIN version 2 which is no longer in use. Use with SJ3.</li>
-			<li>UMODE2 : Supports the UMODE2 command, which is a shortened version of MODE for usermode changes.</li>
-			<li>VL : Supports V:Line information. Extends the SERVER message to include version information used in deny version{} blocks. Note that this is assumed - unreal will always send its own version information.</li>
-			<li>SJ3 : Supports SJOIN version 3.</li>
-			<li>NS : Supports server numerics which provides a shorthand for server names. In any circumstance where a :server.name is permitted (the server is the message's real source), @servernumeric may be used instead. In addition, the server.name parameter in the NICK message may be simply the server's numeric. Requires VL support.</li>
-			<li>SJB64 : Timestamps in NICK and SJOIN are expressed in base64 rather than base10.</li>
-			<li>TKLEXT : Supports exntended TKL messages for spamfilter support.</li>
-			<li>NICKIP : Adds an IP parameter to the NICK message, which is the base64 encoding of the user's ip address (in network byte order). Requires NICKv2.</li>
-			<li>NICKCHARS : Indicates the set of enabled nickchar options (see the regular documention for info about this).</li>
-			<li>CHANMODES : (Not required to be sent) This is the same as the CHANMODES value in the 005 for client connections. Useful for autodetecting things like what modes are valid for ChanServ MLOCK, for example.</li>
-			<li>CLK : Supports an extra field in NICK for sending the cloaked host (not vhost).</li>
-		</ul>
-		<p>The syntax examples here follow the conventions for TOKEN and also NS in cases of server-only messages.</p>
-		<h2><a name="S2_3"></a>2.3 SERVER - Server Negotiation</h2>
-		<p><b>Note:</b> This message is also used for introducing additional servers, the format of this message in those cases is described later.</p>
-		<p><b>Syntax (normal):</b> <tt>SERVER <i>server.name</i> 1 :<i>server description</i></tt></p>
-		<p><b>Syntax (with VL):</b> <tt>SERVER <i>server.name</i> 1 :U<i>protocolversion</i>-<i>protocolflags</i> <i>server description</i></tt></p>
-		<p><b>Syntax (with VL and NS):</b> <tt>SERVER <i>server.name</i> 1 :U<i>protocolversion</i>-<i>protocolflags</i>-<i>servernumeric</i> <i>server description</i></tt></p>
-		<p>The literal 1 in the parameter list is the hopcount parameter. Since you are a direct link, your own hopcount will be 1.</p>
-		<p>The server.name is the same as that in the remote server's link:: block. When received from unreal servers, this will be the value of that server's me::name. The protocol version is the numeric protocol version (2306 for example), and the protocol flags are the server's compilation flags (described below). These two fields are checked against the deny version {} blocks in the remote server's configuration. A value of 0 for either field prevents deny version{} checking for that field. The server description can be anything. When received from unreal servers, it'll be the value of me::description.</p>
-		<p>The following version numbers have been used previously:</p>
-		<ul>
-			<li>2310 - Unreal 3.2.9</li>
-			<li>2309 - Unreal 3.2.6, 3.2.7, 3.2.8</li>
-			<li>2308 - Unreal 3.2.5</li>
-			<li>2307 - Unreal 3.2.4</li>
-			<li>2306 - Unreal 3.2.3</li>
-			<li>2305 - Unreal 3.2.2</li>
-			<li>2304 - Unreal 3.2.1</li>
-			<li>2303 - Unreal 3.2beta* through 3.2 Release</li>
-			<li>2302 - Unreal 3.1.1 through 3.1.4</li>
-			<li>2301 - Unreal 3.1 Release</li>
-			<li>2300 - Unreal 3.0 Release</li>
-		</ul>
-		<p>The compile flags as specified in protocol flags are:</p>
-		<ul>
-			<li>c : Server is chrooted (#define CHROOTDIR).</li>
-			<li>C : Server has command line config (-f option) enabled (#define CMDLINE_CONFIG).</li>
-			<li>D : Server is in debugmode (#define DEBUGMODE).</li>
-			<li>F : Using filedescriptor lists.</li>
-			<li>h : Server is compiled with hub support (#define HUB or answer "Hub" to relevant ./Config prompt).</li>
-			<li>i : Server shows invisible users in /TRACE.</li>
-			<li>n : NOSPOOF (pingcookies) is enabled (#define NOSPOOF or answer "Yes" to relevant ./Config prompt).</li>
-			<li>V : Server is using valloc().</li>
-			<li>W : Windows IRCd.</li>
-			<li>Y : Syslog logging enabled.</li>
-			<li>6 : Server has IPv6 support (#define INET6 or answer "yes" to relevant ./Config prompt).</li>
-			<li>X : Server has badword stripping (user and channel modes +G) (#define STRIPBADWORDS).</li>
-			<li>P : Server is using poll().</li>
-			<li>e : Server has SSL Support (#define USE_SSL or answer "yes" (and have ssl libraries installed) to relevant ./Config prompt).</li>
-			<li>O : Server has OperOverride enabled (#undef NO_OPEROVERRIDE or answer "no" to relevant ./Config prompt).</li>
-			<li>o : Server has disabled Oper verify (#undef OPEROVERRIDE_VERIFY or answer "no" to relevant ./Config prompt).</li>
-			<li>Z : Server has ziplink support (#define ZIP_LINKS or answer "yes" to relevant ./Config prompt AND have the zlib dev libraries).</li>
-			<li>E : Server has extended channel mode support.</li>
-			<li>3 : 3rd party modules are loaded or some system libraries are wonky.</li>
-			<li>m : Private message handling is 'tainted' (one or modules registered a USERMSG hook).</li>
-			<li>M : Channel message handling is 'tainted' (one or modules registered a CHANMSG hook).</li>
-			<li>Additional Version flags can be added by 3rd-party modules.</li>
-		</ul>
-		<h2><a name="S2_4"></a>2.4 EOS - End Of Synch (TOKEN: ES)</h2>
-		<p><b>Syntax:</b> ES</p>
-		<p>Marks the end of the synching process. This is really optional, but it might be a good idea to send it anyway when you really are done synching. Once you send this, unreal will announce &quot;Client connecting&quot; or &quot;Client exiting&quot; notices (to those with snomask +F) for users (unless your server is U:Lined), and joins will be counted toward channel flood controls (chanmode +f).</p>
-		<p>Sending EOS only marks your server as synched, but does not do so for servers behind you. EOS would need to be sent on those servers' behalf as well.</p>
-		<h2><a name="S2_5"></a>2.5 NETINFO - Network Information (TOKEN: AO)</h2>
-		<p><b>Syntax:</b> AO <i>maxglobal</i> <i>currenttime</i> <i>protocolversion</i> <i>cloakhash</i> 0 0 0 :<i>networkname</i></p>
-		<p>This tells the other server your current network configuration. The max global is the highest number of concurrent users network-wide that this server has seen. The current time is a timestamp value. Protocolversion is the same as that in the SERVER command. Cloakhash is a hash representing the configured cloak keys. It may be a * if you are implementing services. The network name is that specified in set::network-name. The cloak-prefix is currently not sent here (and thus unreal won't generate warning for mismatching cloak prefixes, but they should be the same anyway).</p>
-		<p>It is NETINFO, not EOS, that triggers the &quot;Link bla bla bla is now synched&quot; notices, but NETINFO does not imply synching is actually complete (see EOS).</p>
-		<hr/>
-		<h1><a name="S3"></a>3 User Operations</h1>
-		<p>One important function of servers is it must notify all other servers about all of the users behind it. These commands represent the operations that can result in the change of a user's global state.</p>
-		<h2><a name="S3_1"></a>3.1 NICK - User Introduction and Nick Change (TOKEN: &amp;)</h2>
-		<p><b>Syntax (nick change):</b> <tt>:<i>oldnick</i> &amp; <i>newnick</i> :<i>timestamp</i></tt></p>
-		<p>This format of the NICK message indicates an existing user is changing his or her nickname. If a collision occurs, see the section on Nick Collisions below. The timestamp is the new nickname's timestamp.</p>
-		<p><b>Syntax (normal):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> :<i>realname</i></tt></p>
-		<p><b>Syntax (NICKv2):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> :<i>realname</i></tt></p>
-		<p><b>Syntax (NICKv2+CLK):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> :<i>realname</i></tt>
-		<p><b>Syntax (NICKv2+NICKIP):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>nickipaddr</i> :<i>realname</i></tt></p>
-		<p><b>Syntax (NICKv2+NICKIP+CLK):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> <i>nickipaddr</i> :<i>realname</i></tt>
-		<p><b>Note:</b> Because each server normally does its own cloak generation, Unreal does not expect to receive NICK messages with the CLK info, so do not send it. It will send this info to a server it has received a PROTOCTL CLK from however.</p>
-		<p>This format of the NICK message introduces a new user to the network. If PROTOCTL VHP is enabled, the user's cloaked host is put in the virtualhost field, otherwise it'll be * unless the user is +t. With the addition of CLK, VHP is no longer necessary for determining the cloak host.</p>
-		<h3><a name="S3_1_1"></a>3.1.1 Nick Collisions</h3>
-		<p>A nick collision occurs when a server receives a NICK message (or &amp; token) introducing a user that the server already sees on the network. When a collision occurs, one or both of the colliding clients must be disconnected. The timestamp is examined to determine which client loses. The client with the earlier timestamp remains. If both clients have equal timestamps, both are removed. Currently, Unreal handles NICK collisions both passively and agressively:</p>
-		<ul>
-			<li><b>Aggressive Handling:</b> The server actively sends a KILL message back across the link to terminate that end's client.</li>
-			<li><b>Passive Handling:</b> Upon receipt of a NICK message that should "win", the server simply silently exits it's own client.</li>
-		</ul>
-		<h2><a name="S3_2"></a>3.2 MODE, UMODE2 - User Mode Change (TOKEN: G or |)</h2>
-		<p><b>Syntax (MODE):</b> <tt>:<i>user</i> G <i>user</i> <i>modechange</i></tt></p>
-		<p><b>Syntax (UMODE2):</b> <tt>:<i>user</i> | <i>modechange</i></tt></p>
-		<p>This indicates a usermode change. The modechange can consist of zero or more strings of characters, each prefixed with either a + or -; the only delimiter between them being said + or -. If no + or - is at the beginning of the mode string, a + should be implied.</p>
-		<p>Some user modes are never sent between servers. Specifically, usermode +s and +O are not sent between servers. Modules can define additional usermodes that also might not be sent between servers. The UMODE2 saves bandwidth by not including the redundant target field for usermode changes, so use it when possible.</p>
-		<h2><a name="S3_3"></a>3.3 QUIT - User Disconnect (TOKEN: ,)</h2>
-		<p><b>Syntax:</b> <tt>:<i>user</i> , :<i>reason</i></tt></p>
-		<p>This command indicates that a user has disconnected. The reason field is filled in with the reason the user disconnected, which will be any of: quit message provided by the user in a /quit command, kill message for local operator kills, "Client exited" if the user does a brutal quit (clean (by TCP's definition) disconnect without sending a QUIT message), or a socket error message if present.</p>
-		<p>The QUIT message must NOT be prefixed when passing on to other servers. Only local user quit messages are affected by set::prefix-quit.</p>
-		<h2><a name="S3_4"></a>3.4 KILL - Force Disconnect (TOKEN: .)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> . <i>target</i> :<i>killpath</i>!<i>source</i> (<i>reason</i>)</tt></p>
-		<p>Used to indicate that an operator has used KILL on a user not on the same server. Anything beyond the last ! in the kill path is used as the reason. The source (reason) part is simply a standard used by Unreal. As each server passes on a KILL message, it usually prepends the bottommost part (up to the first .) of it's name followed by a ! character. When unreal receives a KILL from a directly connected irc operator, it will usually add that oper's vhost (or realhost if -x) as the first hop in the kill path, then follow with it's own name as mentioned before if it is passing to another server.</p>
-		<p>A server can also send KILLs on it's own. This is done in cases involving nickname collisions, fake senders, bad direction, and other cases of protocol errors. Usually, in these cases, the server puts it's own name as the source, and also prefixes with <i>bottompart</i>! like for any other ircop on that server. For example: @3 . someone :irc!irc.example.com (Nick collision)</p>
-		<h2><a name="S3_5"></a>3.5 SETHOST/CHGHOST - Change virtual host (TOKEN: AA or AL)</h2>
-		<p><b>Syntax (SETHOST):</b> <tt>:<i>source</i> AA <i>newvhost</i></tt></p>
-		<p><b>Syntax (CHGHOST):</b> <tt>:<i>source</i> AL <i>target</i> <i>newvhost</i></tt></p>
-		<p>Indicates the change of a user's virtual host. Currently, servers are expected to assume UMODE2 +xt on the target user in both commands. (In the case of SETHOST, the target is the sender.) Servers using PROTOCTL VHP will receive the cloaked host in a SETHOST message when a user activates his cloaked host. A server can also send CHGHOST (from one of it's opered clients) to change a user's hostname. This is generally used by HostServ implementations. To disable a cloaked host, use CHGHOST to set the user's virtual host equal to his real host, or use SVSMODE -xt, but the latter requires services.</p>
-		<h2><a name="S3_6"></a>3.6 SETIDENT/CHGIDENT - Change a user's username (TOKEN: AD or AZ)</h2>
-		<p><b>Syntax (SETIDENT):</b> <tt>:<i>source</i> AD <i>newusername</i></tt></p>
-		<p><b>Syntax (CHGIDENT):</b> <tt>:<i>source</i> AZ <i>target</i> <i>newusername</i></tt></p>
-		<p>Indicates the change of a user's username. No usermode change is associated with this. Unreal does not use a distinguished virtual username, so servers should only keep the original username (from the NICK message) if they intend to allow the user to reset the original username. Servers can use CHGIDENT to change a user's username.</p>
-		<h2><a name="S3_7"></a>3.7 SETNAME/CHGNAME - Change a user's realname (TOKEN: AE or BK)</h2>
-		<p><b>Syntax (SETNAME):</b> <tt>:<i>source</i> AE :<i>newrealname</i></tt></p>
-		<p><b>Syntax (CHGNAME):</b> <tt>:<i>source</i> BK <i>target</i> :<i>newrealname</i></tt></p>
-		<p>Indicates the change of a user's realname. No usermode change is associated with this. Unreal does not use a distinguished virtual realname, so servers should only keep the original realname (from the NICK message) if they intend to allow the user to reset the original realname. Servers can use CHGNAME to change a user's username. Note that servers must NOT check that the sender be an IRCop in SETNAME - normal users are permitted to use SETNAME.</p>
-		<h2><a name="#S3_8"></a>3.8 WHOIS - User Information (TOKEN: #)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> # [<i>from-server</i> ]<i>nick</i></tt></p>
-		<p>Requests the information on a user. This works exactly like the user /whois command - in fact, the source parameter must be a user, or the command will do nothing. <i>from-server</i> is the server to request the information from; if a server recives a WHOIS message without this parameter, it should return its own information on the user, otherwise it should pass the message to the given server. Note that <i>from-server</i> may name a user instead of a server (such as when a user uses /whois nick nick), in which case the the nick should be interpreted as naming the server that user is on. <i>nick</i> may be several users seperated by commas, but may not contain wildcards.</p>
-		<p>The reply to a WHOIS message uses the same numeric replies as the user command.</p>
-		<hr/>
-		<h1><a name="S4"></a>4 Server Operations</h1>
-		<p>This is different from server negotiation. Negotiation is when you are first connecting. Server introduction is used for introducing additional servers behind an existing server (aka hubbing). Hubbing is limited as specified by the hub, leaf, and leafdepth parameters in the link block and attempted violation of a hub restriction results in termination of the link. If no hub or leaf directive is given your server is a leaf by default, so any introduction of any server behind you would be an automatic drop. U:Lines don't matter here; services must be configured as a hub in the link block. The reason is U:Line is a permission rule, but hub privilege is a network structure rule.</p>
-		<h2><a name="S4_1"></a>4.1 SERVER - Server Introduction (TOKEN: ')</h2>
-		<p><b>Note: This command is also used for negotiation. Be warned that the token for this command is NOT VALID at that time! See section 2.3 for the syntax for negotiation.</b></p>
-		<p><b>Syntax (without PROTOCTL NS):</b> <tt>:<i>source</i> SERVER <i>new.server</i> <i>hopcount</i> :<i>description</i></tt></p>
-		<p><b>Syntax (with PROTOCTL NS):</b> <tt>@<i>sourcenumeric</i> SERVER <i>new.server</i> <i>hopcount</i> <i>numeric</i> :<i>description</i></tt></p>
-		<p>The command indicates that the server named new.server is being introduced by the source (the source is the server which new.server is directly linked to). The hopcount will be the number of links the receiving server would have to cross to reach new.server. In other words, new.server introduced itself with a hopcount of 1, and as the SERVER message is passed along, hopcount is incremented.</p>
-		<p>As an example, a services server faking a SERVER message for JUPE functionality would use a hopcount of 2.</p>
-		<h2><a name="S4_2"></a>4.2 SQUIT - Server Removal (TOKEN: -)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> SQUIT <i>server.name</i> <i>:reason</i></tt></p>
-		<p>From an IRCop or when server.name is not behind the source, this command requests the removal of the specified server.name. The command in this case is treated very much like KILL in the respect that the message is broadcasted to all servers, except server.name and any servers behind it. When the SQUIT reaches server.name's uplink, that server closes the link to server.name (which would then generate it's own SQUIT on behalf of it's uplink for the servers behind it).</p>
-		<p>A server can also use SQUIT in the same manner as QUIT to note the removal of a server behind it, or that it itself is quitting. In the former case, server.name is behind source, and the message is forward on to all other servers. In the latter case, source and server.name are equal, the receiving server closes the link and forwards the SQUIT message.</p>
-		<p>Unreal closes a direct link by simply sending an ERROR message and then closing the TCP connection. This typically causes the other end to generate an SQUIT bearing the message "Client exited" or similar, however, the ERROR will usually cause the server to send a message to all IRCops.</p>
-		<h2><a name="S4_3"></a>4.3 SDESC - Server Description (TOKEN: AG)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> AG :<i>newdesc</i></tt></p>
-		<p>The server to which source is connected to should have it's description updated to newdesc. This does NOT include the VL inforamtion.</p>
-		<h2><a name="S4_4">4.4 PING - Live Connection Query (TOKEN: 8)</a></h2>
-		<p><b>Syntax:</b> <tt>8 <i>source</i>[ :<i>destination</i>]</tt></p>
-		<p>Used to check if a connection is still live if it has been &quot;quiet&quot; for a certain amount of time. Typically, unreal will send PING requests at intervals determined by the class::pingfreq setting. PINGs originating from the direct uplink will use the token, but it seems PINGs originating from a distant server will not.</p>
-		<p>The response to a PING is sent with the <a href="#S4_5">PONG</a> command.</p>
-		<p>When receiving a two-parameter PING, the second parameter is the target. If the target isn't you, you can either reply on behalf of that target (using its name instead of yours), or if there is a real connection representing the target, forward the PING to the target.</p>
-		<h2><a name="S4_5">4.5 PONG - Live Connection Reply (TOKEN: 9)</a></h2>
-		<p><b>Syntax:</b> <tt>9 <i>source</i>[ :<i>destination</i>]</tt></p>
-		<p>Used to respond to a <a href="#S4_4">PING</a> query.</p>
-		<p><b>Responding to a ping:</b> Once a PING is received, you usually have an amount of time to respond equal to your class::pingfreq. The correct response will always have two parameters. If you received one parameter, then the received parameter becomes the second parameter of your response, and the first parameter is your server name. If you received two parameters, the response returns both parameters in reverse order.</p>
-		<p>For example, the response to <tt>8 uplink.server</tt> is <tt>9 my.name uplink.server</tt>, while the response to <tt>PING distant.server your.server</tt> is <tt>9 your.server distant.server</tt>. Unreal typically includes a : prior to the last parameter. This isn't required if that parameter contains no spaces, but it is especially important to not include the colon when reversing the parameters, or else Unreal mistake it for a single-parameter PONG.
-		<p>If a two-parameter PONG is received, the second parameter names the target. If the target is not you, and a real connection represents that target, you should forward the PONG message via that connection.</p>
-		<h2><a name="#S4_6"></a>4.6 STATS - Server Stats (TOKEN: 2)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> 2 [<i>type</i> [<i>server</i>] [<i>extended-params</i>]]</tt></p>
-		<p>Requests statistics or configuration information from a server. This command is used to transport cross-server STATS requests from users (eg: /stats o other.server), and should only be sent from a user (not a server). With no parameters, this will cause unreal to simply dump its help output. <i>type</i> is the type of stats to request, <i>server</i> names a server (or a user on that server) to request stats from, and <i>extended-params</i> is used to filter output from STATS G, etc. When received, it is up to the receiver to determine what stats to support and how to reply, but generally numeric replies are used. For the list of unreal's stats types, type /stats in a client for the helptext dump.</p>
-		<p><b>Note:</b> Stats set as oper-only (see set::oper-only-stats) will be refused from a server. In this case, it will be necessary to send the stats request from a psuedo-oper (such as a services agent, etc) for services/stats/etc.</p>
-		<hr/>
-		<h1><a name="S5"></a>5 Channel Operations</h1>
-		<p>These commands deal with the state of channels across the network. Unreal only supports Network Channels, where the first character is a # character.</p>
-		<h2><a name="S5_1"></a>5.1 SJOIN - Channel Burst (TOKEN: ~)</h2>
-		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> ~ <i>timestamp</i> <i>channel</i> +<i>modes</i>[ <i>modeparams</i>] :<i>memberlist</i> <i>&amp;ban</i> <i>"exempt</i> <i>'invex</i></tt></p>
-		<p>Timestamp is the channel timestamp and can be !b64 as defined by PROTOCTL SJB64. Modes should only include those in the last three mode sets listed in CHANMODES. Modeparams is one parameter for each mode character that requires one. Memberlist is a series of users (all of which must at least be behind the server sending the SJOIN), each user is prefixed with one or more characters indicating their status. Owners (+q) are prefixed with *, admins (+a) ~, ops (+o) @, halfops (+h) %, voices (+v) +. Normal users are not prefixed with anything. Ban, ban exception, and invite exception masks are also included, with bans prefixed with &amp;, ban exceptions prefixed with ", and invite exceptions with '. Note that when a &amp;, " or ' is encountered as the first character, further processing of ~, *, @, %, or + characters must not continue because ban, exempt, and invite masks can contain any of those characters. (Plus it's just not right for a ban mask to be marked as a channel admin...)</p>
-		<p>If the channel didn't already exist it is created with the information given in the SJOIN. Otherwise the timestamp is used to determine how the SJOIN information is handled. As a given, all members are joined into the channel, regardless. The mode information (modes, modeparams, memberlist prefixes, bans, exempts, and invites) is subject to the timestamp rules:</p>
-		<ul>
-			<li>If the channel's current timestamp is equal to the timestamp in SJOIN, then the mode information is merged.</li>
-			<li>If the channel's current timestamp is less than the SJOIN timestamp, then the mode information is ignored.</li>
-			<li>If the channel's current timestamp is greater than the SJOIN timestamp, then the channel's existing mode information is cleared (for example, deop, etc all local clients), and the SJOIN mode information is added.</li>
-		</ul>
-		<p>When merging modes, conflicting modes (including +p vs +s, differing +l limits or +k keys, etc) are handled as follows:</p>
-		<ul>
-			<li><b>Private (+p) vs. Secret (+s):</b> Secret (+s) is preferred. Private (+p) is removed. (Note: there is a <a href="http://bugs.unrealircd.org/view.php?id=2391">bug</a> in Unreal versions prior to 3.2.3 in which a desynch will occur in which one side is +p and the other is +s. Update to Unreal 3.2.4 if you have problems with this.)</li>
-			<li><b>Strip Color (+S) vs. Block Color (+c):</b> Block (+c) is preferred. Strip (+S) is removed. (Note: Bug for +p vs. +s in prior unreal versions apply here as well.)</li>
-			<li><b>Channel Limit:</b> Numericly larger limit is preferred (for example, +l 30 versus +l 15 : +l 30 wins).</li>
-			<li><b>Channel Key:</b> &quot;Larger&quot; key (as defined by strcmp) is preferred (for example, +k moo versus +k meow : +k moo wins).</li>
-			<li><b>Channel Link:</b> &quot;Larger&quot; link name (as defined by stricmp - not case sensitive) is preferred (for example, +L #moo versus +L #meow : +L #moo wins, but +L #Meow versus +L #meow : values are equal).</li>
-			<li><b>Flood String:</b> Not really sure on this. I think larger value in each component wins.</li>
-			<li><b>Join-Throttle:</b> Highest of time period wins, if equal, highest of join amount wins (so +j 3:40 beats +j 5:20 but +j 5:20 beats +j 3:20).</li>
-			<li>Parameterized modes in third party modules will define their own conflict resolution formula.</li>
-		</ul>
-		<h2><a name="S5_2"></a>5.2 JOIN - Channel Join (TOKEN: C)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> C <i>#channel</i></tt></p>
-		<p>Indicates a user has joined a channel. Only one channel is sent this way, and the key is not sent even if the user gave one one joining. If the channel parameter is the special "0" case, the server must interpret the message as a PART for all channels the user is on.</p>
-		<h2><a name="S5_3"></a>5.3 PART - Channel Part (TOKEN: D)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> D <i>#channel</i>[ :<i>reason</i></tt>]</p>
-		<p>Indicates a user has left a channel. Only one channel is sent this way. The reason parameter may be left out if no reason was given.</p>
-		<h2><a name="S5_4"></a>5.4 KICK - Channel Kick (TOKEN: H)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> H <i>#channel</i> <i>user</i> :<i>reason</i></tt></p>
-		<p>Orders the forced removal of user from #channel with the given reason. When updating state for this command, it should be the same as if :user PART #channel had been received - the user is removed from #channel's memberlist.</p>
-		<h2><a name="S5_5"></a>5.5 MODE - Channel Mode (TOKEN: G)</h2>
-		<p><b>Note:</b> This is the same command as that used for usermode changes.</p>
-		<p><b>Syntax:</b> <tt>:<i>source</i> G <i>#channel</i> <i>modechange</i> <i>modeparams</i>[ <i>timestamp</i>]</tt></p>
-		<p>Changes the specified modes on the given channel. If the source is a server and the last parameter is numeric, it is interpreted as timestamp (although it can also be consumed as a parameter for modes. For example: :server.name MODE #channel +l 4 &lt;-- 4 will be a timestamp and the +l parameter). When a mode change is timestamped in this way, the mode is treated as it is with SJOIN: the MODE message is ignored if the timestamp is greater than the channel timestamp. (If the timestamp is equal, the mode is simply added replacing any conflicting modes already in place.)</p>
-		<p>A services implementation can easily clear all entries in a list mode such as bans with SVSMODE (see below).</p>
-		<h2><a name="S5_6"></a>5.6 INVITE - Invite a user to a channel (TOKEN: *)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> * <i>target</i> <i>#channel</i></tt></p>
-		<p>Sends to target an invitation to join #channel. If the source is a channel operator on #channel, or a U:Lined server, the invitation grants the user the temporary ability to join the channel regardless of any bans or some restricting channel modes (not +O or +A).</p>
-		<h2><a name="S5_7"></a>5.7 SAJOIN - Channel Force Join (TOKEN: AX)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> AX <i>targetuser</i> <i>#channel</i></tt></p>
-		<p>This requests the forced join of targetuser to #channel. This type of forced join overrides bans, and most modes. The server to which targetuser is connected to must actually acknowledge the join for it to occur. Service implementations may ignore this command, as they would only ever receive it if an SAJOIN was targeted at a service client, in which case it should be ignored...</p>
-		<h2><a name="S5_8"></a>5.8 SAPART - Channel Force Part (TOKEN: AY)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> AY <i>targetuser</i> <i>#channel</i>[ :<i>reason</i>]</tt></p>
-		<p>This requests the forced part of targetuser from #channel. This is slightly different from a KICK in that the user's removal is announced with PART. The server to which targetuser is connected to must actually acknowledge the part for it to occur. Service implementations may ignore this command, as they would only ever receive it if an SAPART was targeted at a service client, in which case it should be ignored...</p>
-		<p>The reason field is optional. If provided the acknowledging PART message should prefix the message with &quot;SAPart:&quot;.</p>
-		<h2><a name="S5_9"></a>5.9 SAMODE - Channel Force Mode (TOKEN: o)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> o <i>#channel</i> <i>modechange</i> <i>modeparams</i></tt></p>
-		<p>This has the same parameters as for MODE. The only difference is that servers probably will never receive this (but is best to document just in case), and that absolutely NO permission checking is done on anything.</p>
-		<h2><a name="S5_10"></a>5.10 TOPIC - Channel Topic (TOKEN: ) )</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> ) <i>#channel</i> <i>nick</i> <i>timestamp</i> :<i>topic</i></tt></p>
-		<p>Changes the channel topic information. This format is used when synching, as well as when a topic is changed normally. Nick is the user who changed the topic (depending on compile options, it can be just nick or a full nick!user@host), timestamp is when the change occured, and topic is the new topic text. Normally, only a newer timestamp will actually change the topic, but a U:Lined server can use an older timestamp as well (such as for TOPICLOCK).
-		<hr/>
-		<h1><a name="S6"></a>6 Services Commands</h1>
-		<p>These are commands typically employed by a service implementation, in addition to some of the normal commands. All of the commands listed here require the sender to be correctly U:Lined. This means that the services server name must appear within a ulines {} block in the unrealircd.conf configuration for ALL servers in the network. All servers and clients behind a U:Lined server are themselves U:Lined.</p>
-		<h2><a name="S6_1"></a>6.1 SVSKILL - Force Disconnect by Service (TOKEN: h)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> h <i>target</i> :<i>reason</i></tt></p>
-		<p>This command is similar to KILL but differs in several ways. First of all: there is no mutilation of the reason value. The reason given is the exact reason used to generate QUIT messages sent to users. Second, it is silent; no server notice is generated in response to this command. Third, it can only be used by a U:Lined server or client (such as services).</p>
-		<p>Because this command can be dangerous in the hands of an abusive person, service implementations should avoid granting humans control over the reason parameter. In cases of commands where a person has control over such parameter, either use a regular KILL instead, or otherwise modify the reason so that operators can be held accountable if necessary.</p>
-		<h2><a name="S6_2"></a>6.2 SVSMODE, SVS2MODE - Force User Mode Change (TOKEN: n or v)</h2>
-		<p><b>Syntax (SVSMODE):</b> <tt>:<i>source</i> n <i>target</i> +<i>usermodes</i></tt></p>
-		<p><b>Syntax (SVS2MODE):</b> <tt>:<i>source</i> v <i>target</i> +<i>usermodes</i></tt></p>
-		<p>Judging by these commands alone, you'd think they are identical. Both commands force a usermode change to occur. This is typically used by services to set +r on a user who has successfully identified. They differ in that SVS2MODE also sends the mode change to the user, while SVSMODE does not (hidden mode change).</p>
-		<p>SVSMODE and SVS2MODE also give special treatment to usermode +d. Rather than setting the deaf mode like you might expect, SVS(2)MODE +d allows services to change a user's services stamp (which is given in the NICK message). This could allow services to set the service stamp to an easily identifiable value that could then be used to say "hey, this person identified already". The syntax of this is: +d <i>newservicestamp</i> and can be combined with setting other usermodes as well. The deaf mode <b>can</b> be set by using +d without the service stamp parameter; however, in this case you <b>cannot</b> set the service stamp in the same SVS(2)MODE message.</p>
-		<p><b>Note:</b> Do <b>NOT</b> use SVSMODE to remove IRCop status from a user. Use the SVSO command for that instead.</p>
-		<p>Alternatively, target can name a channel. In this case, the mode change parameter can consist of a - character, followed by any or all of: b, e, I, q, a, o, h, or v. These characters cause the corresponding lists to be cleared of all entries. For example: SVSMODE #channel -b removes ALL bans from #channel, and SVSMODE #channel -qaohv turns ALL users on #channel into normal users (removes all owner, admin, op, halfop, and voice status). In this case, the uplink will acknowledge with a MODE listing the bans, etc that were removed.</p>
-		<p>To completely clear a channel of all modes: MODE #channel -cfijklmnprstzACGMKLNOQRSTVu (plus any added by third-party module) followed by SVSMODE #channel -beIqaohv.</p>
-		<h2><a name="S6_3"></a>6.3 SVSSNO, SVS2SNO - Forced SNomask Change (TOKEN: BV or BW)</h2>
-		<p><b>Syntax (SVSSNO):</b> <tt>:<i>source</i> BV <i>target</i> +<i>snomasks</i></tt></p>
-		<p><b>Syntax (SVS2SNO):</b> <tt>:<i>source</i> BW <i>target</i> +<i>snomask</i></tt></p>
-		<p>Changes a user's snomasks. The difference between SVSSNO and SVS2SNO is the same as with SVSMODE versus SVS2MODE. If the user is not +s, you must add it via SVSMODE +s. For example:</p>
-		<pre>:OperServ v someuser +s
-:OperServ BW someuser +ks</pre>
-		<h2><a name="S6_4"></a>6.4 SVSNICK - Forced Nick Change (TOKEN: e)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> e <i>target</i> <i>newnick</i> :<i>newtimestamp</i></tt></p>
-		<p>Forces the specified user to change his nick to newnick and also sets the nick timestamp to newtimestamp (so, for example, services could protect identified users from a nick collision by simply setting the nick timestamp to something way less than "now" - though currently this requires actually changing the nick too). SVSNICK requires the server to which the target is connected to acknowledge the nick change. If the user specified by newnick already exists, then target will be disconnected (even if it's something like a case-change).</p>
-		<h2><a name="S6_5"></a>6.5 SVSJOIN - Forced Join (TOKEN: BX)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> BX <i>target</i> <i>#channel</i></tt></p>
-		<p>This is identical to SAJOIN with a few exceptions: 1) It is U:Line-only. 2) No opernotice on use. 3) Bans and restricting modes are respected, a prior INVITE message must be sent to cause bans to be ignored.</p>
-		<h2><a name="S6_6"></a>6.6 SVSPART - Forced Part (TOKEN: BT)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> BT <i>target</i> <i>#channel</i> :<i>reason</i></tt></p>
-		<p>Also identical to SAPART with a few exceptions: no static prefix on the optional part reason, and no global notice, and requires a U:Line. Usage recommendation of SVSPART versus KICK is the same as for SVSKILL versus KILL.</p>
-		<h2><a name="S6_7"></a>6.7 SVSO - Oper Permissions (TOKEN: BB)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> BB <i>target</i> <i>flagchanges</i></tt></p>
-		<p>This allows a service to add or remove IRCop permission flags for a user. Flagchanges is formatted similar to that of MODE with the exception that operflags are used instead of usermodes. If the change string consists only of -, then all oper permissions, usermodes, and snomasks are removed (as if the user had himself typed MODE nick -Oo).</p>
-		<p>If you are granting IRCop permissions to a user who is not currently an IRCop, you should follow up with an SVSMODE +o or SVSMODE +O as appropriate. For example:</p>
-<pre>:OperServ BB somenick +o
-:OperServ BW somenick +cefknoqsSv
-:OperServ AL somenick local.oper.somethinghere.net
-:OperServ v somenick +Ohs </pre>
-		<h2><a name="S6_8"></a>6.8 SVSNOOP - Oper Lockdown (TOKEN: f)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> f <i>(op)</i><i>server.name</i></tt></p>
-		<p>The (op) parameter is either a + or - indicating if NOOP mode should be activated (+) or deactivated (-). When NOOP mode is activated, all IRCops on the server are deopered (including local operators) and the /oper command is disabled. IRCop privileges can still be granted through use of SVSO. On UnrealIRCd, it is not necessary to masskill all IRCops on the nooped server, as they are deopered automatically.</p>
-		<h2><a name="S6_9"></a>6.9 SVSNLINE - RealName Ban (TOKEN: BR)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> BR <i>op</i> <i>reason</i> :<i>realname mask</i></tt></p>
-		<p>Op is either + (add) or - (remove). In the case of +, reason is a space-escaped string (all space chars are encoded as _). If -, reason is ignored.</p>
-		<h2><a name="S6_10"></a>6.10 SVSFLINE - File Ban (TOKEN: BC)</h2>
-		<p><b>Syntax (add):</b> <tt>:<i>source</i> BC + <i>filemask</i> :<i>reason</i></tt></p>
-		<p><b>Syntax (remove):</b> <tt>:<i>source</i> BC - <i>filemask</i></tt></p>
-		<p><b>Syntax (clear):</b> <tt>:<i>source</i> BC *</tt></p>
-		<p>Adds or removes a DCCDENY item for the specified filemask on all servers. These DCCDENYs are hard dccdenies - the /dccallow command cannot override it. The last form removes all dccdenies added via SVSFLINE.</p>
-		<hr/>
-		<h1><a name="S7"></a>7 Messaging</h1>
-		<p>What good is Internet Relay <b>CHAT</b> if users cannot <b>CHAT</b>? This section addresses the commands through which arbitrary user messages are sent.</p>
-		<h2><a name="S7_1"></a>7.1 PRIVMSG, NOTICE - Simple Message Transmission (Token: ! or B)</h2>
-		<p><b>PRIVMSG Syntax:</b> <tt>:<i>source</i> ! <i>target</i> :<i>message</i></tt></p>
-		<p><b>NOTICE Syntax:</b> <tt>:<i>source</i> B <i>target</i> :<i>message</i></tt></p>
-		<p>Sends a messages to the given target. The target either names a single client, or identifies a list of clients in which the message is to be sent to. The available targets include:</p>
-		<ul>
-			<li><i>nickname</i>: Names a single user to whom the message is delivered.</li>
-			<li><i>nickname</i>@<i>servermask</i>: Also names a single user, but the message will only be delivered if the user is connected to a server matching the specified servermask. This is typically used for sending messages to services. The target must not be changed at any point along the path it must travel for delivery, even up to the final receipt of the message by the target. This allows the target to know it has been sent a message in this way.</li>
-			<li>#<i>channelname</i>: Sends a message to all users on the specified channel (except when channel is a moderated auditorium (+mu), in which case the wierd +mu sending behavior goes off).</li>
-			<li><i>modeprefix</i>#<i>channelname</i>: Sends a message to all users on the given channel having the given status or higher. For example: + means all voices, halfops, etc.</li>
-			<li>$<i>servermask</i>: Sends a message to ALL users on all servers matching the specified servermask (known as a server broadcast message). The RFC requirements of having a TLD with no wildcards is not applied to U:Lined clients.</li>
-		</ul>
-		<p>Unreal does not support the #hostmask format.</p>
-		<h2><a name="S7_2"></a>7.2 SENDUMODE, SMO - Usermode-based Delivery (TOKEN: AP or AU)</h2>
-		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> AU <i>umode</i> :<i>message</i></tt></p>
-		<p>Sends the specified message to all users with the given mode. Only one usermode may be given. This is a server-only command if you can't tell from the sender prefix :) .</p>
-		<p>The message will be displayed as coming from the receiving client's own server. It may be appropriate to add a &quot;*** Notice (or other leader here) -- from blah:&quot; if you wish to clarify where the message is from.</p>
-		<h2><a name="S7_3"></a>7.3 SENDSNO - SNomask-based Delivery (TOKEN: Ss)</h2>
-		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> Ss <i>snomask</i> :<i>message</i></tt></p>
-		<p>Sends the specified message to all users with the given snomask. Only one snomask may be given. This is a server-only command if you can't tell from the sender prefix :) .</p>
-		<p>The message will be displayed as coming from the receiving client's own server. It may be appropriate to add a &quot;*** Notice (or other leader here) -- from blah:&quot; if you wish to clarify where the message is from.</p>
-		<h2><a name="S7_4"></a>7.4 CHATOPS - IRCop Chat (TOKEN: p)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> p :<i>message</i></tt></p>
-		<p>Sends the message to all IRCops on all servers.</p>
-		<h2><a name="S7_5"></a>7.5 WALLOPS - Wallop Chat (TOKEN: =)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> = :<i>message</i></tt></p>
-		<p>Sends the message to all users with usermode +w, whether they are ircops or not.</p>
-		<h2><a name="S7_6"></a>7.6 GLOBOPS - FailOp Chat (TOKEN: ])</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> ] :<i>message</i></tt></p>
-		<p>Send the message to all IRCops with usermode +g.</p>
-		<h2><a name="S7_7"></a>7.7 ADCHAT - Admin Chat (TOKEN: x)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> x :<i>message</i></tt></p>
-		<p>Send the message to all Server and Network Admins (usermode +A).</p>
-		<h2><a name="S7_8"></a>7.8 NACHAT - NetAdmin Chat (TOKEN: AC)</h2>
-		<p><b>Syntax:</b> <tt>:<i>source</i> AC :<i>message</i></tt></p>
-		<p>Send the message to all Network Admins (usermode +N).</p>
-		<hr/>
-		<h1><a name="S8"></a>8 Ban Control</h1>
-		<p>Sometimes, you have the misfortune of encountering a user who has no purpose but to serve as an annoyance to your server or network. These commands transmit network-wide ban information amongst each other.</p>
-		<h2><a name="S8_1"></a>8.1 TKL - Master Ban Control (TOKEN: BD)</h2>
-		<p>The TKL command seems to have one oddity about it: the real ban source is included in the TKL command rather than in the sender prefix. Most likely this is done for synching reasons (so that the *line ban can be credited to the proper person even if he/she is offline). For this reason, the command syntax is given without any sender prefix at all. It is still permissible to use one, however.</p>
-		<h3><a name="S8_1_1"></a>8.1.1 GLINE - Network-wide user@host ban</h3>
-		<p><b>Add Syntax (TKL):</b> <tt>BD + G <i>userpart</i> <i>hostpart</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
-		<p><b>Remove Syntax (TKL):</b> <tt>BD - G <i>userpart</i> <i>hostpart</i> <i>source</i></tt></p>
-		<p>Adds and Removes Network-wide user@host bans, known as G:Lines. The GLINE command itself must not be used. The userpart and hostpart are the user portion and hostname portion of the ban mask. The expiretimestamp is 0 if the G:Line should not expire, otherwise it will expire at the given time. It is an absolute time, not relative, thus it's imperitive to have reasonably synchrnoized clocks or bans may be removed too early or even immediately!</p>
-		<h3><a name="S8_1_2"></a>8.1.2 GZLINE - Network-wide IP ban</h3>
-		<p><b>Add Syntax (TKL):</b> <tt>BD + Z * <i>ipmask</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
-		<p><b>Remove Syntax (TKL):</b> <tt>BD - Z * <i>ipmask</i> <i>source</i></tt></p>
-		<p>Adds and Removes Network-wide IP bans, known as Global Z:Lines. The GZLINE command itself must not be used. Ipmask permits CIDR notation as well as wildcard masks.</p>
-		<h3><a name="S8_1_3"></a>8.1.3 SQLINE, UNSQLINE - Network-wide Nickname ban (TOKEN: c or d)</h3>
-		<p><b>Add Syntax (TKL):</b> <tt>BD + Q <i>hold</i> <i>nickmask</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
-		<p><b>Add Syntax (SQLINE):</b> <tt>:<i>source</i> c <i>nickmask</i> :<i>reason</i></tt></p>
-		<p><b>Remove Syntax (TKL):</b> <tt>BD - Q <i>hold</i> <i>nickmask</i> <i>source</i></tt></p>
-		<p><b>Remove Syntax (UNSQLINE):</b> <tt>:<i>source</i> d <i>nickmask</i></tt></p>
-		<p>In the TKL syntax, the hold parameter is either a * to mark the qline as a nick ban, or an H to mark it as a services hold. A services hold does not trigger qline rejection notice, and is typically used by NickServ to reserve registered nicks until they are released by the owner. The (UN)SQLINE syntax can only be used by a server, but any user can be used as the source for the TKL syntax. Unlike G and GZ lines, Q:Lines do not cause existing matching users to be disconnected or otherwise affected.</p>
-		<p>The TKL syntax is preferred, since it is more flexible, but (UN)SQLINE is permitted for compatibility.</p>
-		<h3><a name="S8_1_4"></a>8.1.4 SPAMFILTER - Message Spam Filtration System</h3>
-		<p>Proper use of spamfilter in TKL commands requires use of PROTOCTL TKLEXT, which increases the number of parameters allowed in TKL.</p>
-		<p><b>Add Syntax (TKL):</b> <tt>BD + F <i>target(s)</i> <i>action</i> <i>source</i> 0 <i>settimestamp</i> <i>tklduration</i> <i>tklreason</i> :<i>regex</i></tt></p>
-		<p><b>Remove Syntax (TKL):</b> <tt>BD - F <i>target(s)</i> <i>action</i> <i>source</i> 0 <i>settimestap</i> :<i>regex</i></tt></p>
-		<p>Adds and Removes network-wide spamfilters. The SPAMFILTER command itself must not be used. See <a href="http://vulnscan.org/UnrealIrcd/unreal32docs.html#feature_spamfilter">http://vulnscan.org/UnrealIrcd/unreal32docs.html#feature_spamfilter</a> for a list of valid targets. For actions, a single character is used to identify the action to be taken:</p>
-		<ul>
-			<li>K (kill) - The user is simply disconnected, with the reason given.</li>
-			<li>S (tempshun) - A temporary shun is placed on the user. This shun is applied only to that user, and disappears if the user reconnects.</li>
-			<li>s (shun) - A regular shun on the user's IP address is added. This causes all users with the same hostname to be shunned, but they will also stay shunned if they reconnect.</li>
-			<li>k (kline) - A K:Line is added on the user's IP address.</li>
-			<li>z (zline) - A Z:Line is added on the user's IP address.</li>
-			<li>g (gline) - A G:Line is added on the user's IP address.</li>
-			<li>Z (gzline) - A Global Z:Line is added on the user's IP address.</li>
-			<li>b (block) - Messages (or users!) matching the filter are simply blocked.</li>
-			<li>d (dccblock) - The user is prevented from sending files using DCC for the remainder of his session (in other words, until he quits).</li>
-			<li>v (viruschan) - User is removed from all channels, joined to the viruschan as defined in conf, and cannot message anything but that channel.</li>
-			<li>w (warn) - No action on the user is taken. Only the Spamfilter notice is sent to opers with snomask +S.</li>
-		</ul>
-		<h1><a name="S9">9 Base64 Tables</a></h1>
-		<p>Unreal uses base64 encoding to allow saving bandwidth by encoding numbers in a more compact format. Unreal uses two different variations of base64, one used for the SJB64 PROTOCTL option (in NICK and SJOIN), and one used for NICKIP.</p>
-		<h2><a name="S9_1">9.1 Table for SJB64 (NICK and SJOIN).</a></h2>
-		<p>In NICK and SJOIN, remember that the timestamp will be prefixed with ! to signal a base64 timestamp.</p>
-		<p>Just like in base10, the least significant &quot;digit&quot; is last.</p>
-		<pre> 0 0            17 H            34 Y            51 p
- 1 1            18 I            35 Z            52 q
- 2 2            19 J            36 a            53 r
- 3 3            20 K            37 b            54 s
- 4 4            21 L            38 c            55 t
- 5 5            22 M            39 d            56 u
- 6 6            23 N            40 e            57 v
- 7 7            24 O            41 f            58 w
- 8 8            25 P            42 g            59 x
- 9 9            26 Q            43 h            60 y
-10 A            27 R            44 i            61 z
-11 B            28 S            45 j            62 {
-12 C            29 T            46 k            63 }
-13 D            30 U            47 l
-14 E            31 V            48 m
-15 F            32 W            49 n
-16 G            33 X            50 o</pre>
-		<h2><a name="S9_2">9.2 Table for NICKIP.</a></h2>
-		<p>In this table, the IP is encoded in network byte order. In terms of IPs, this means the first byte of the address really is first. Each &quot;digit&quot; in the base64 encoded IP corresponds to 6 bits of the IP address.</p>
-		<p>An IPv4 address is 32 bits, so 6 base64 &quot;digits&quot; are needed. Since base64 requires values to come in multiples of 4 &quot;digits&quot;, padding characters (=) need to be added if a value comes up short. In the case of IPv4 addresses, two are needed.</p>
-		<p>IPv6 addresses are 128-bit. They therefore need 22 base64 &quot;digits&quot; plus 2 pad characters.</p>
-		<pre> 0 A            17 R            34 i            51 z
- 1 B            18 S            35 j            52 0
- 2 C            19 T            36 k            53 1
- 3 D            20 U            37 l            54 2
- 4 E            21 V            38 m            55 3
- 5 F            22 W            39 n            56 4
- 6 G            23 X            40 o            57 5
- 7 H            24 Y            41 p            58 6
- 8 I            25 Z            42 q            59 7
- 9 J            26 a            43 r            60 8
-10 K            27 b            44 s            61 9
-11 L            28 c            45 t            62 +
-12 M            29 d            46 u            63 /
-13 N            30 e            47 v
-14 O            31 f            48 w         (pad) =
-15 P            32 g            49 x
-16 Q            33 h            50 y</pre>
-	</body>
-</html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<!-- $Id$ -->
+<html>
+	<head>
+		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
+		<title>Unreal 3.2 Protocol Documentation</title>
+	</head>
+	<body>
+		<h1 style="text-align: center;">Unreal 3.2 Protocol Documentation</h1>
+		<h3 style="text-align: center;">Last update: 29 November 2006</h3>
+		<h1>Table of Contents</h1>
+		<p><a href="#S1">1 Introduction</a></p>
+		<p><a href="#S2">2 Server Negotiation</a></p>
+		<blockquote><p><a href="#S2_1">2.1 PASS - Connection Password</a></p></blockquote>
+		<blockquote><p><a href="#S2_2">2.2 PROTOCTL - Server Protocol Negotiation</a></p></blockquote>
+		<blockquote><p><a href="#S2_3">2.3 SERVER - Server Negotiation</a></p></blockquote>
+		<blockquote><p><a href="#S2_4">2.4 EOS - End Of Synch</a></p></blockquote>
+		<blockquote><p><a href="#S2_5">2.5 NETINFO - Network Information</a></p></blockquote>
+		<p><a href="#S3">3 User Operations</a></p>
+		<blockquote><p><a href="#S3_1">3.1 NICK - User Introduction and Nick Change</a></p></blockquote>
+		<blockquote><blockquote><p><a href="#S3_1_1">3.1.1 Nick Collisions</a></p></blockquote></blockquote>
+		<blockquote><p><a href="#S3_2">3.2 MODE, UMODE2 - User Mode Change</a></p></blockquote>
+		<blockquote><p><a href="#S3_3">3.3 QUIT - User Disconnect</a></p></blockquote>
+		<blockquote><p><a href="#S3_4">3.4 KILL - Force Disconnect</a></p></blockquote>
+		<blockquote><p><a href="#S3_5">3.5 SETHOST/CHGHOST - Change virtual host</a></p></blockquote>
+		<blockquote><p><a href="#S3_6">3.6 SETIDENT/CHGIDENT - Change a user's username</a></p></blockquote>
+		<blockquote><p><a href="#S3_7">3.7 SETNAME/CHGNAME - Change a user's realname</a></p></blockquote>
+		<blockquote><p><a href="#S3_8">3.8 WHOIS - User Information</a></p></blockquote>
+		<p><a href="#S1">4 Server Operations</a></p>
+		<blockquote><p><a href="#S4_1">4.1 SERVER - Server Introduction</a></p></blockquote>
+		<blockquote><p><a href="#S4_2">4.2 SQUIT - Server Removal</a></p></blockquote>
+		<blockquote><p><a href="#S4_3">4.3 SDESC - Server Description</a></p></blockquote>
+		<blockquote><p><a href="#S4_4">4.4 PING - Live Connection Query</a></p></blockquote>
+		<blockquote><p><a href="#S4_5">4.5 PONG - Live Connection Reply</a></p></blockquote>
+		<blockquote><p><a href="#S4_6">4.6 STATS - Server Stats</a></p></blockquote>
+		<p><a href="#S5">5 Channel Operations</a></p>
+		<blockquote><p><a href="#S5_1">5.1 SJOIN - Channel Burst</a></p></blockquote>
+		<blockquote><p><a href="#S5_2">5.2 JOIN - Channel Join</a></p></blockquote>
+		<blockquote><p><a href="#S5_3">5.3 PART - Channel Part</a></p></blockquote>
+		<blockquote><p><a href="#S5_4">5.4 KICK - Channel Kick</a></p></blockquote>
+		<blockquote><p><a href="#S5_5">5.5 MODE - Channel Mode</a></p></blockquote>
+		<blockquote><p><a href="#S5_6">5.6 INVITE - Invite a user to a channel</a></p></blockquote>
+		<blockquote><p><a href="#S5_7">5.7 SAJOIN - Channel Force Join</a></p></blockquote>
+		<blockquote><p><a href="#S5_8">5.8 SAPART - Channel Force Part</a></p></blockquote>
+		<blockquote><p><a href="#S5_9">5.9 SAMODE - Channel Force Mode</a></p></blockquote>
+		<blockquote><p><a href="#S5_10">5.10 TOPIC - Chanel Topic</a></p></blockquote>
+		<p><a href="#S6">6 Services Commands</a></p>
+		<blockquote><p><a href="#S6_1">6.1 SVSKILL - Force Disconnect by Service</a></p></blockquote>
+		<blockquote><p><a href="#S6_2">6.2 SVSMODE, SVS2MODE - Force User Mode Change</a></p></blockquote>
+		<blockquote><p><a href="#S6_3">6.3 SVSSNO, SVS2SNO - Forced SNomask Change</a></p></blockquote>
+		<blockquote><p><a href="#S6_4">6.4 SVSNICK - Forced Nick Change</a></p></blockquote>
+		<blockquote><p><a href="#S6_5">6.5 SVSJOIN - Forced Join</a></p></blockquote>
+		<blockquote><p><a href="#S6_6">6.6 SVSPART - Forced Part</a></p></blockquote>
+		<blockquote><p><a href="#S6_7">6.7 SVSO - Oper Permissions</a></p></blockquote>
+		<blockquote><p><a href="#S6_8">6.8 SVSNOOP - Oper Lockdown</a></p></blockquote>
+		<blockquote><p><a href="#S6_9">6.9 SVSNLINE - RealName Ban</a></p></blockquote>
+		<blockquote><p><a href="#S6_10">6.10 SVSFLINE - File Ban</a></p></blockquote>
+		<p><a href="#S7">7 Messaging</a></p>
+		<blockquote><p><a href="#S7_1">7.1 PRIVMSG, NOTICE - Simple Message Transmission</a></p></blockquote>
+		<blockquote><p><a href="#S7_2">7.2 SENDUMODE, SMO - Usermode-based Delivery</a></p></blockquote>
+		<blockquote><p><a href="#S7_3">7.3 SENDSNO - SNomask-based Delivery</a></p></blockquote>
+		<blockquote><p><a href="#S7_4">7.4 CHATOPS - IRCop Chat</a></p></blockquote>
+		<blockquote><p><a href="#S7_5">7.5 WALLOPS - Wallop Chat</a></p></blockquote>
+		<blockquote><p><a href="#S7_6">7.6 GLOBOPS - FailOp Chat</a></p></blockquote>
+		<blockquote><p><a href="#S7_7">7.7 ADCHAT - Admin Chat</a></p></blockquote>
+		<blockquote><p><a href="#S7_8">7.8 NACHAT - NetAdmin Chat</a></p></blockquote>
+		<p><a href="#S8">8 Ban Control</a></p>
+		<blockquote><p><a href="#S8_1">8.1 TKL - Master Ban Control</a></p></blockquote>
+		<blockquote><blockquote><p><a href="#S8_1_1">8.1.1 GLINE - Network-wide user@host ban</a></p></blockquote></blockquote>
+		<blockquote><blockquote><p><a href="#S8_1_2">8.1.2 GZLINE - Network-wide IP ban</a></p></blockquote></blockquote>
+		<blockquote><blockquote><p><a href="#S8_1_3">8.1.3 SQLINE, UNSQLINE - Network-wide Nickname ban</a></p></blockquote></blockquote>
+		<blockquote><blockquote><p><a href="#S8_1_4">8.1.4 SPAMFILTER - Message Spam Filtration System</a></p></blockquote></blockquote>
+		<p><a href="#S9">9 Base64 Tables</a></p>
+		<blockquote><p><a href="#S9_1">9.1 Table for SJB64 (NICK and SJOIN).</a></p></blockquote>
+		<blockquote><p><a href="#S9_2">9.2 Table for NICKIP.</a></p></blockquote>
+		<hr/>
+		<h1><a name="S1"></a>1 Introduction</h1>
+		<p>This document describes the UnrealIRCd server-to-server protocol as of protocol 2307 (Unreal 3.2.4). 
+		It is currently slightly out of date, as the current protocol is 2310, but that should not matter much.</p>
+		<h2>A word about clocks.</h2>
+		<p>Unreal is very time-dependant. Users and channels, for example, are timestamped, and if server clocks are not synchronized properly, things can go very wrong very fast. See <a href="http://vulnscan.org/UnrealIrcd/faq/#67">http://vulnscan.org/UnrealIrcd/faq/#67</a> for more information on this. Note that there is a slight difference between server time and what is actually reported by the UNIX date command or by the C time() function. Unreal can apply an offset to the real time to create the server time, allowing servers to be virtually synchronized when synchronizing the real clocks is not possible (such as on shell servers).
+			I should make it quite clear that GMT time is used for everything. To be specific, timestamps in unreal are 32-bit integer values (actually, however many bits the time_t type is, which is 32 on 32-bit systems such as x86). This integer value is the number of seconds that have elapsed since Midnight January 1, 1970 GMT (can be referred to as Epoch time in the UNIX world). This means that timezones are no problem, nor is daylight savings time (or whatever your country of choice calls it).</p>
+		<hr/>
+		<h1><a name="S2"></a>2 Server Negotiation</h1>
+		<p>The first step to establish a server-to-server communication is to negotiate the connection as a server. Negotiation is done using standard IRC commands - no PROTOCTL options are in force until the link is established. The first step is to open a TCP/IP connection to the target server. The target port must be one described by a listen {} block in the remote server's configuration, and that listen block must not have the clientsonly option. After the connection is open, you will be treated as any other connection and be greeted with the "Looking up your hostname..." and "Checking identd..." notices as you would for a client. As these are NOTICE messages and your session as a server isn't established, they should simply be ignored. Use the commands below to introduce a server connection.</p>
+		<h2><a name="S2_1"></a>2.1 PASS - Connection Password</h2>
+		<p><b>Syntax:</b> <tt>PASS :<i>link password</i></tt></p>
+		<p>The PASS command is used to transmit the password required for a server link. It must match the password specified in the remote server's link::password-receive (which can be crypted), otherwise the link will be rejected. This should be the first message sent.</p>
+		<h2><a name="S2_2"></a>2.2 PROTOCTL - Server Protocol Negotiation</h2>
+		<p><b>Syntax:</b> <tt>PROTOCTL <i>protocol options</i></tt></p>
+		<p>The PROTOCTL command sets several protocol options. The tokens supported are listed below.</p>
+		<ul>
+			<li>NOQUIT : When a netsplit occurs, only send a SQUIT message for each server lost. This server will assume that clients on these servers were also lost and will send the appropriate QUIT messages to local clients and to any non-NOQUIT servers.</li>
+			<li>TOKEN : Use tokenized commands. Tokens are case-sensitive, shortened versions of command names. Tokens will be usually one or two characters.</li>
+			<li>NICKv2 : Use extended NICK message for introducing users. See the NICK command for information about this.</li>
+			<li>VHP : When introducing a user, send his cloaked host as if it were a vhost. Usually used for services to avoid having duplicate code.</li>
+			<li>SJOIN : Supports SJOIN version 1 which is no longer in use. Use with SJ3.</li>
+			<li>SJOIN2 : Supports SJOIN version 2 which is no longer in use. Use with SJ3.</li>
+			<li>UMODE2 : Supports the UMODE2 command, which is a shortened version of MODE for usermode changes.</li>
+			<li>VL : Supports V:Line information. Extends the SERVER message to include version information used in deny version{} blocks. Note that this is assumed - unreal will always send its own version information.</li>
+			<li>SJ3 : Supports SJOIN version 3.</li>
+			<li>NS : Supports server numerics which provides a shorthand for server names. In any circumstance where a :server.name is permitted (the server is the message's real source), @servernumeric may be used instead. In addition, the server.name parameter in the NICK message may be simply the server's numeric. Requires VL support.</li>
+			<li>SJB64 : Timestamps in NICK and SJOIN are expressed in base64 rather than base10.</li>
+			<li>TKLEXT : Supports exntended TKL messages for spamfilter support.</li>
+			<li>NICKIP : Adds an IP parameter to the NICK message, which is the base64 encoding of the user's ip address (in network byte order). Requires NICKv2.</li>
+			<li>NICKCHARS : Indicates the set of enabled nickchar options (see the regular documention for info about this).</li>
+			<li>CHANMODES : (Not required to be sent) This is the same as the CHANMODES value in the 005 for client connections. Useful for autodetecting things like what modes are valid for ChanServ MLOCK, for example.</li>
+			<li>CLK : Supports an extra field in NICK for sending the cloaked host (not vhost).</li>
+		</ul>
+		<p>The syntax examples here follow the conventions for TOKEN and also NS in cases of server-only messages.</p>
+		<h2><a name="S2_3"></a>2.3 SERVER - Server Negotiation</h2>
+		<p><b>Note:</b> This message is also used for introducing additional servers, the format of this message in those cases is described later.</p>
+		<p><b>Syntax (normal):</b> <tt>SERVER <i>server.name</i> 1 :<i>server description</i></tt></p>
+		<p><b>Syntax (with VL):</b> <tt>SERVER <i>server.name</i> 1 :U<i>protocolversion</i>-<i>protocolflags</i> <i>server description</i></tt></p>
+		<p><b>Syntax (with VL and NS):</b> <tt>SERVER <i>server.name</i> 1 :U<i>protocolversion</i>-<i>protocolflags</i>-<i>servernumeric</i> <i>server description</i></tt></p>
+		<p>The literal 1 in the parameter list is the hopcount parameter. Since you are a direct link, your own hopcount will be 1.</p>
+		<p>The server.name is the same as that in the remote server's link:: block. When received from unreal servers, this will be the value of that server's me::name. The protocol version is the numeric protocol version (2306 for example), and the protocol flags are the server's compilation flags (described below). These two fields are checked against the deny version {} blocks in the remote server's configuration. A value of 0 for either field prevents deny version{} checking for that field. The server description can be anything. When received from unreal servers, it'll be the value of me::description.</p>
+		<p>The following version numbers have been used previously:</p>
+		<ul>
+			<li>2310 - Unreal 3.2.9</li>
+			<li>2309 - Unreal 3.2.6, 3.2.7, 3.2.8</li>
+			<li>2308 - Unreal 3.2.5</li>
+			<li>2307 - Unreal 3.2.4</li>
+			<li>2306 - Unreal 3.2.3</li>
+			<li>2305 - Unreal 3.2.2</li>
+			<li>2304 - Unreal 3.2.1</li>
+			<li>2303 - Unreal 3.2beta* through 3.2 Release</li>
+			<li>2302 - Unreal 3.1.1 through 3.1.4</li>
+			<li>2301 - Unreal 3.1 Release</li>
+			<li>2300 - Unreal 3.0 Release</li>
+		</ul>
+		<p>The compile flags as specified in protocol flags are:</p>
+		<ul>
+			<li>c : Server is chrooted (#define CHROOTDIR).</li>
+			<li>C : Server has command line config (-f option) enabled (#define CMDLINE_CONFIG).</li>
+			<li>D : Server is in debugmode (#define DEBUGMODE).</li>
+			<li>F : Using filedescriptor lists.</li>
+			<li>h : Server is compiled with hub support (#define HUB or answer "Hub" to relevant ./Config prompt).</li>
+			<li>i : Server shows invisible users in /TRACE.</li>
+			<li>n : NOSPOOF (pingcookies) is enabled (#define NOSPOOF or answer "Yes" to relevant ./Config prompt).</li>
+			<li>V : Server is using valloc().</li>
+			<li>W : Windows IRCd.</li>
+			<li>Y : Syslog logging enabled.</li>
+			<li>6 : Server has IPv6 support (#define INET6 or answer "yes" to relevant ./Config prompt).</li>
+			<li>X : Server has badword stripping (user and channel modes +G) (#define STRIPBADWORDS).</li>
+			<li>P : Server is using poll().</li>
+			<li>e : Server has SSL Support (#define USE_SSL or answer "yes" (and have ssl libraries installed) to relevant ./Config prompt).</li>
+			<li>O : Server has OperOverride enabled (#undef NO_OPEROVERRIDE or answer "no" to relevant ./Config prompt).</li>
+			<li>o : Server has disabled Oper verify (#undef OPEROVERRIDE_VERIFY or answer "no" to relevant ./Config prompt).</li>
+			<li>Z : Server has ziplink support (#define ZIP_LINKS or answer "yes" to relevant ./Config prompt AND have the zlib dev libraries).</li>
+			<li>E : Server has extended channel mode support.</li>
+			<li>3 : 3rd party modules are loaded or some system libraries are wonky.</li>
+			<li>m : Private message handling is 'tainted' (one or modules registered a USERMSG hook).</li>
+			<li>M : Channel message handling is 'tainted' (one or modules registered a CHANMSG hook).</li>
+			<li>Additional Version flags can be added by 3rd-party modules.</li>
+		</ul>
+		<h2><a name="S2_4"></a>2.4 EOS - End Of Synch (TOKEN: ES)</h2>
+		<p><b>Syntax:</b> ES</p>
+		<p>Marks the end of the synching process. This is really optional, but it might be a good idea to send it anyway when you really are done synching. Once you send this, unreal will announce &quot;Client connecting&quot; or &quot;Client exiting&quot; notices (to those with snomask +F) for users (unless your server is U:Lined), and joins will be counted toward channel flood controls (chanmode +f).</p>
+		<p>Sending EOS only marks your server as synched, but does not do so for servers behind you. EOS would need to be sent on those servers' behalf as well.</p>
+		<h2><a name="S2_5"></a>2.5 NETINFO - Network Information (TOKEN: AO)</h2>
+		<p><b>Syntax:</b> AO <i>maxglobal</i> <i>currenttime</i> <i>protocolversion</i> <i>cloakhash</i> 0 0 0 :<i>networkname</i></p>
+		<p>This tells the other server your current network configuration. The max global is the highest number of concurrent users network-wide that this server has seen. The current time is a timestamp value. Protocolversion is the same as that in the SERVER command. Cloakhash is a hash representing the configured cloak keys. It may be a * if you are implementing services. The network name is that specified in set::network-name. The cloak-prefix is currently not sent here (and thus unreal won't generate warning for mismatching cloak prefixes, but they should be the same anyway).</p>
+		<p>It is NETINFO, not EOS, that triggers the &quot;Link bla bla bla is now synched&quot; notices, but NETINFO does not imply synching is actually complete (see EOS).</p>
+		<hr/>
+		<h1><a name="S3"></a>3 User Operations</h1>
+		<p>One important function of servers is it must notify all other servers about all of the users behind it. These commands represent the operations that can result in the change of a user's global state.</p>
+		<h2><a name="S3_1"></a>3.1 NICK - User Introduction and Nick Change (TOKEN: &amp;)</h2>
+		<p><b>Syntax (nick change):</b> <tt>:<i>oldnick</i> &amp; <i>newnick</i> :<i>timestamp</i></tt></p>
+		<p>This format of the NICK message indicates an existing user is changing his or her nickname. If a collision occurs, see the section on Nick Collisions below. The timestamp is the new nickname's timestamp.</p>
+		<p><b>Syntax (normal):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> :<i>realname</i></tt></p>
+		<p><b>Syntax (NICKv2):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> :<i>realname</i></tt></p>
+		<p><b>Syntax (NICKv2+CLK):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> :<i>realname</i></tt>
+		<p><b>Syntax (NICKv2+NICKIP):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>nickipaddr</i> :<i>realname</i></tt></p>
+		<p><b>Syntax (NICKv2+NICKIP+CLK):</b> <tt>&amp; <i>nick</i> <i>hopcount</i> <i>timestamp</i>	<i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> <i>nickipaddr</i> :<i>realname</i></tt>
+		<p><b>Note:</b> Because each server normally does its own cloak generation, Unreal does not expect to receive NICK messages with the CLK info, so do not send it. It will send this info to a server it has received a PROTOCTL CLK from however.</p>
+		<p>This format of the NICK message introduces a new user to the network. If PROTOCTL VHP is enabled, the user's cloaked host is put in the virtualhost field, otherwise it'll be * unless the user is +t. With the addition of CLK, VHP is no longer necessary for determining the cloak host.</p>
+		<h3><a name="S3_1_1"></a>3.1.1 Nick Collisions</h3>
+		<p>A nick collision occurs when a server receives a NICK message (or &amp; token) introducing a user that the server already sees on the network. When a collision occurs, one or both of the colliding clients must be disconnected. The timestamp is examined to determine which client loses. The client with the earlier timestamp remains. If both clients have equal timestamps, both are removed. Currently, Unreal handles NICK collisions both passively and agressively:</p>
+		<ul>
+			<li><b>Aggressive Handling:</b> The server actively sends a KILL message back across the link to terminate that end's client.</li>
+			<li><b>Passive Handling:</b> Upon receipt of a NICK message that should "win", the server simply silently exits it's own client.</li>
+		</ul>
+		<h2><a name="S3_2"></a>3.2 MODE, UMODE2 - User Mode Change (TOKEN: G or |)</h2>
+		<p><b>Syntax (MODE):</b> <tt>:<i>user</i> G <i>user</i> <i>modechange</i></tt></p>
+		<p><b>Syntax (UMODE2):</b> <tt>:<i>user</i> | <i>modechange</i></tt></p>
+		<p>This indicates a usermode change. The modechange can consist of zero or more strings of characters, each prefixed with either a + or -; the only delimiter between them being said + or -. If no + or - is at the beginning of the mode string, a + should be implied.</p>
+		<p>Some user modes are never sent between servers. Specifically, usermode +s and +O are not sent between servers. Modules can define additional usermodes that also might not be sent between servers. The UMODE2 saves bandwidth by not including the redundant target field for usermode changes, so use it when possible.</p>
+		<h2><a name="S3_3"></a>3.3 QUIT - User Disconnect (TOKEN: ,)</h2>
+		<p><b>Syntax:</b> <tt>:<i>user</i> , :<i>reason</i></tt></p>
+		<p>This command indicates that a user has disconnected. The reason field is filled in with the reason the user disconnected, which will be any of: quit message provided by the user in a /quit command, kill message for local operator kills, "Client exited" if the user does a brutal quit (clean (by TCP's definition) disconnect without sending a QUIT message), or a socket error message if present.</p>
+		<p>The QUIT message must NOT be prefixed when passing on to other servers. Only local user quit messages are affected by set::prefix-quit.</p>
+		<h2><a name="S3_4"></a>3.4 KILL - Force Disconnect (TOKEN: .)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> . <i>target</i> :<i>killpath</i>!<i>source</i> (<i>reason</i>)</tt></p>
+		<p>Used to indicate that an operator has used KILL on a user not on the same server. Anything beyond the last ! in the kill path is used as the reason. The source (reason) part is simply a standard used by Unreal. As each server passes on a KILL message, it usually prepends the bottommost part (up to the first .) of it's name followed by a ! character. When unreal receives a KILL from a directly connected irc operator, it will usually add that oper's vhost (or realhost if -x) as the first hop in the kill path, then follow with it's own name as mentioned before if it is passing to another server.</p>
+		<p>A server can also send KILLs on it's own. This is done in cases involving nickname collisions, fake senders, bad direction, and other cases of protocol errors. Usually, in these cases, the server puts it's own name as the source, and also prefixes with <i>bottompart</i>! like for any other ircop on that server. For example: @3 . someone :irc!irc.example.com (Nick collision)</p>
+		<h2><a name="S3_5"></a>3.5 SETHOST/CHGHOST - Change virtual host (TOKEN: AA or AL)</h2>
+		<p><b>Syntax (SETHOST):</b> <tt>:<i>source</i> AA <i>newvhost</i></tt></p>
+		<p><b>Syntax (CHGHOST):</b> <tt>:<i>source</i> AL <i>target</i> <i>newvhost</i></tt></p>
+		<p>Indicates the change of a user's virtual host. Currently, servers are expected to assume UMODE2 +xt on the target user in both commands. (In the case of SETHOST, the target is the sender.) Servers using PROTOCTL VHP will receive the cloaked host in a SETHOST message when a user activates his cloaked host. A server can also send CHGHOST (from one of it's opered clients) to change a user's hostname. This is generally used by HostServ implementations. To disable a cloaked host, use CHGHOST to set the user's virtual host equal to his real host, or use SVSMODE -xt, but the latter requires services.</p>
+		<h2><a name="S3_6"></a>3.6 SETIDENT/CHGIDENT - Change a user's username (TOKEN: AD or AZ)</h2>
+		<p><b>Syntax (SETIDENT):</b> <tt>:<i>source</i> AD <i>newusername</i></tt></p>
+		<p><b>Syntax (CHGIDENT):</b> <tt>:<i>source</i> AZ <i>target</i> <i>newusername</i></tt></p>
+		<p>Indicates the change of a user's username. No usermode change is associated with this. Unreal does not use a distinguished virtual username, so servers should only keep the original username (from the NICK message) if they intend to allow the user to reset the original username. Servers can use CHGIDENT to change a user's username.</p>
+		<h2><a name="S3_7"></a>3.7 SETNAME/CHGNAME - Change a user's realname (TOKEN: AE or BK)</h2>
+		<p><b>Syntax (SETNAME):</b> <tt>:<i>source</i> AE :<i>newrealname</i></tt></p>
+		<p><b>Syntax (CHGNAME):</b> <tt>:<i>source</i> BK <i>target</i> :<i>newrealname</i></tt></p>
+		<p>Indicates the change of a user's realname. No usermode change is associated with this. Unreal does not use a distinguished virtual realname, so servers should only keep the original realname (from the NICK message) if they intend to allow the user to reset the original realname. Servers can use CHGNAME to change a user's username. Note that servers must NOT check that the sender be an IRCop in SETNAME - normal users are permitted to use SETNAME.</p>
+		<h2><a name="#S3_8"></a>3.8 WHOIS - User Information (TOKEN: #)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> # [<i>from-server</i> ]<i>nick</i></tt></p>
+		<p>Requests the information on a user. This works exactly like the user /whois command - in fact, the source parameter must be a user, or the command will do nothing. <i>from-server</i> is the server to request the information from; if a server recives a WHOIS message without this parameter, it should return its own information on the user, otherwise it should pass the message to the given server. Note that <i>from-server</i> may name a user instead of a server (such as when a user uses /whois nick nick), in which case the the nick should be interpreted as naming the server that user is on. <i>nick</i> may be several users seperated by commas, but may not contain wildcards.</p>
+		<p>The reply to a WHOIS message uses the same numeric replies as the user command.</p>
+		<hr/>
+		<h1><a name="S4"></a>4 Server Operations</h1>
+		<p>This is different from server negotiation. Negotiation is when you are first connecting. Server introduction is used for introducing additional servers behind an existing server (aka hubbing). Hubbing is limited as specified by the hub, leaf, and leafdepth parameters in the link block and attempted violation of a hub restriction results in termination of the link. If no hub or leaf directive is given your server is a leaf by default, so any introduction of any server behind you would be an automatic drop. U:Lines don't matter here; services must be configured as a hub in the link block. The reason is U:Line is a permission rule, but hub privilege is a network structure rule.</p>
+		<h2><a name="S4_1"></a>4.1 SERVER - Server Introduction (TOKEN: ')</h2>
+		<p><b>Note: This command is also used for negotiation. Be warned that the token for this command is NOT VALID at that time! See section 2.3 for the syntax for negotiation.</b></p>
+		<p><b>Syntax (without PROTOCTL NS):</b> <tt>:<i>source</i> SERVER <i>new.server</i> <i>hopcount</i> :<i>description</i></tt></p>
+		<p><b>Syntax (with PROTOCTL NS):</b> <tt>@<i>sourcenumeric</i> SERVER <i>new.server</i> <i>hopcount</i> <i>numeric</i> :<i>description</i></tt></p>
+		<p>The command indicates that the server named new.server is being introduced by the source (the source is the server which new.server is directly linked to). The hopcount will be the number of links the receiving server would have to cross to reach new.server. In other words, new.server introduced itself with a hopcount of 1, and as the SERVER message is passed along, hopcount is incremented.</p>
+		<p>As an example, a services server faking a SERVER message for JUPE functionality would use a hopcount of 2.</p>
+		<h2><a name="S4_2"></a>4.2 SQUIT - Server Removal (TOKEN: -)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> SQUIT <i>server.name</i> <i>:reason</i></tt></p>
+		<p>From an IRCop or when server.name is not behind the source, this command requests the removal of the specified server.name. The command in this case is treated very much like KILL in the respect that the message is broadcasted to all servers, except server.name and any servers behind it. When the SQUIT reaches server.name's uplink, that server closes the link to server.name (which would then generate it's own SQUIT on behalf of it's uplink for the servers behind it).</p>
+		<p>A server can also use SQUIT in the same manner as QUIT to note the removal of a server behind it, or that it itself is quitting. In the former case, server.name is behind source, and the message is forward on to all other servers. In the latter case, source and server.name are equal, the receiving server closes the link and forwards the SQUIT message.</p>
+		<p>Unreal closes a direct link by simply sending an ERROR message and then closing the TCP connection. This typically causes the other end to generate an SQUIT bearing the message "Client exited" or similar, however, the ERROR will usually cause the server to send a message to all IRCops.</p>
+		<h2><a name="S4_3"></a>4.3 SDESC - Server Description (TOKEN: AG)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> AG :<i>newdesc</i></tt></p>
+		<p>The server to which source is connected to should have it's description updated to newdesc. This does NOT include the VL inforamtion.</p>
+		<h2><a name="S4_4">4.4 PING - Live Connection Query (TOKEN: 8)</a></h2>
+		<p><b>Syntax:</b> <tt>8 <i>source</i>[ :<i>destination</i>]</tt></p>
+		<p>Used to check if a connection is still live if it has been &quot;quiet&quot; for a certain amount of time. Typically, unreal will send PING requests at intervals determined by the class::pingfreq setting. PINGs originating from the direct uplink will use the token, but it seems PINGs originating from a distant server will not.</p>
+		<p>The response to a PING is sent with the <a href="#S4_5">PONG</a> command.</p>
+		<p>When receiving a two-parameter PING, the second parameter is the target. If the target isn't you, you can either reply on behalf of that target (using its name instead of yours), or if there is a real connection representing the target, forward the PING to the target.</p>
+		<h2><a name="S4_5">4.5 PONG - Live Connection Reply (TOKEN: 9)</a></h2>
+		<p><b>Syntax:</b> <tt>9 <i>source</i>[ :<i>destination</i>]</tt></p>
+		<p>Used to respond to a <a href="#S4_4">PING</a> query.</p>
+		<p><b>Responding to a ping:</b> Once a PING is received, you usually have an amount of time to respond equal to your class::pingfreq. The correct response will always have two parameters. If you received one parameter, then the received parameter becomes the second parameter of your response, and the first parameter is your server name. If you received two parameters, the response returns both parameters in reverse order.</p>
+		<p>For example, the response to <tt>8 uplink.server</tt> is <tt>9 my.name uplink.server</tt>, while the response to <tt>PING distant.server your.server</tt> is <tt>9 your.server distant.server</tt>. Unreal typically includes a : prior to the last parameter. This isn't required if that parameter contains no spaces, but it is especially important to not include the colon when reversing the parameters, or else Unreal mistake it for a single-parameter PONG.
+		<p>If a two-parameter PONG is received, the second parameter names the target. If the target is not you, and a real connection represents that target, you should forward the PONG message via that connection.</p>
+		<h2><a name="#S4_6"></a>4.6 STATS - Server Stats (TOKEN: 2)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> 2 [<i>type</i> [<i>server</i>] [<i>extended-params</i>]]</tt></p>
+		<p>Requests statistics or configuration information from a server. This command is used to transport cross-server STATS requests from users (eg: /stats o other.server), and should only be sent from a user (not a server). With no parameters, this will cause unreal to simply dump its help output. <i>type</i> is the type of stats to request, <i>server</i> names a server (or a user on that server) to request stats from, and <i>extended-params</i> is used to filter output from STATS G, etc. When received, it is up to the receiver to determine what stats to support and how to reply, but generally numeric replies are used. For the list of unreal's stats types, type /stats in a client for the helptext dump.</p>
+		<p><b>Note:</b> Stats set as oper-only (see set::oper-only-stats) will be refused from a server. In this case, it will be necessary to send the stats request from a psuedo-oper (such as a services agent, etc) for services/stats/etc.</p>
+		<hr/>
+		<h1><a name="S5"></a>5 Channel Operations</h1>
+		<p>These commands deal with the state of channels across the network. Unreal only supports Network Channels, where the first character is a # character.</p>
+		<h2><a name="S5_1"></a>5.1 SJOIN - Channel Burst (TOKEN: ~)</h2>
+		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> ~ <i>timestamp</i> <i>channel</i> +<i>modes</i>[ <i>modeparams</i>] :<i>memberlist</i> <i>&amp;ban</i> <i>"exempt</i> <i>'invex</i></tt></p>
+		<p>Timestamp is the channel timestamp and can be !b64 as defined by PROTOCTL SJB64. Modes should only include those in the last three mode sets listed in CHANMODES. Modeparams is one parameter for each mode character that requires one. Memberlist is a series of users (all of which must at least be behind the server sending the SJOIN), each user is prefixed with one or more characters indicating their status. Owners (+q) are prefixed with *, admins (+a) ~, ops (+o) @, halfops (+h) %, voices (+v) +. Normal users are not prefixed with anything. Ban, ban exception, and invite exception masks are also included, with bans prefixed with &amp;, ban exceptions prefixed with ", and invite exceptions with '. Note that when a &amp;, " or ' is encountered as the first character, further processing of ~, *, @, %, or + characters must not continue because ban, exempt, and invite masks can contain any of those characters. (Plus it's just not right for a ban mask to be marked as a channel admin...)</p>
+		<p>If the channel didn't already exist it is created with the information given in the SJOIN. Otherwise the timestamp is used to determine how the SJOIN information is handled. As a given, all members are joined into the channel, regardless. The mode information (modes, modeparams, memberlist prefixes, bans, exempts, and invites) is subject to the timestamp rules:</p>
+		<ul>
+			<li>If the channel's current timestamp is equal to the timestamp in SJOIN, then the mode information is merged.</li>
+			<li>If the channel's current timestamp is less than the SJOIN timestamp, then the mode information is ignored.</li>
+			<li>If the channel's current timestamp is greater than the SJOIN timestamp, then the channel's existing mode information is cleared (for example, deop, etc all local clients), and the SJOIN mode information is added.</li>
+		</ul>
+		<p>When merging modes, conflicting modes (including +p vs +s, differing +l limits or +k keys, etc) are handled as follows:</p>
+		<ul>
+			<li><b>Private (+p) vs. Secret (+s):</b> Secret (+s) is preferred. Private (+p) is removed. (Note: there is a <a href="http://bugs.unrealircd.org/view.php?id=2391">bug</a> in Unreal versions prior to 3.2.3 in which a desynch will occur in which one side is +p and the other is +s. Update to Unreal 3.2.4 if you have problems with this.)</li>
+			<li><b>Strip Color (+S) vs. Block Color (+c):</b> Block (+c) is preferred. Strip (+S) is removed. (Note: Bug for +p vs. +s in prior unreal versions apply here as well.)</li>
+			<li><b>Channel Limit:</b> Numericly larger limit is preferred (for example, +l 30 versus +l 15 : +l 30 wins).</li>
+			<li><b>Channel Key:</b> &quot;Larger&quot; key (as defined by strcmp) is preferred (for example, +k moo versus +k meow : +k moo wins).</li>
+			<li><b>Channel Link:</b> &quot;Larger&quot; link name (as defined by stricmp - not case sensitive) is preferred (for example, +L #moo versus +L #meow : +L #moo wins, but +L #Meow versus +L #meow : values are equal).</li>
+			<li><b>Flood String:</b> Not really sure on this. I think larger value in each component wins.</li>
+			<li><b>Join-Throttle:</b> Highest of time period wins, if equal, highest of join amount wins (so +j 3:40 beats +j 5:20 but +j 5:20 beats +j 3:20).</li>
+			<li>Parameterized modes in third party modules will define their own conflict resolution formula.</li>
+		</ul>
+		<h2><a name="S5_2"></a>5.2 JOIN - Channel Join (TOKEN: C)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> C <i>#channel</i></tt></p>
+		<p>Indicates a user has joined a channel. Only one channel is sent this way, and the key is not sent even if the user gave one one joining. If the channel parameter is the special "0" case, the server must interpret the message as a PART for all channels the user is on.</p>
+		<h2><a name="S5_3"></a>5.3 PART - Channel Part (TOKEN: D)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> D <i>#channel</i>[ :<i>reason</i></tt>]</p>
+		<p>Indicates a user has left a channel. Only one channel is sent this way. The reason parameter may be left out if no reason was given.</p>
+		<h2><a name="S5_4"></a>5.4 KICK - Channel Kick (TOKEN: H)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> H <i>#channel</i> <i>user</i> :<i>reason</i></tt></p>
+		<p>Orders the forced removal of user from #channel with the given reason. When updating state for this command, it should be the same as if :user PART #channel had been received - the user is removed from #channel's memberlist.</p>
+		<h2><a name="S5_5"></a>5.5 MODE - Channel Mode (TOKEN: G)</h2>
+		<p><b>Note:</b> This is the same command as that used for usermode changes.</p>
+		<p><b>Syntax:</b> <tt>:<i>source</i> G <i>#channel</i> <i>modechange</i> <i>modeparams</i>[ <i>timestamp</i>]</tt></p>
+		<p>Changes the specified modes on the given channel. If the source is a server and the last parameter is numeric, it is interpreted as timestamp (although it can also be consumed as a parameter for modes. For example: :server.name MODE #channel +l 4 &lt;-- 4 will be a timestamp and the +l parameter). When a mode change is timestamped in this way, the mode is treated as it is with SJOIN: the MODE message is ignored if the timestamp is greater than the channel timestamp. (If the timestamp is equal, the mode is simply added replacing any conflicting modes already in place.)</p>
+		<p>A services implementation can easily clear all entries in a list mode such as bans with SVSMODE (see below).</p>
+		<h2><a name="S5_6"></a>5.6 INVITE - Invite a user to a channel (TOKEN: *)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> * <i>target</i> <i>#channel</i></tt></p>
+		<p>Sends to target an invitation to join #channel. If the source is a channel operator on #channel, or a U:Lined server, the invitation grants the user the temporary ability to join the channel regardless of any bans or some restricting channel modes (not +O or +A).</p>
+		<h2><a name="S5_7"></a>5.7 SAJOIN - Channel Force Join (TOKEN: AX)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> AX <i>targetuser</i> <i>#channel</i></tt></p>
+		<p>This requests the forced join of targetuser to #channel. This type of forced join overrides bans, and most modes. The server to which targetuser is connected to must actually acknowledge the join for it to occur. Service implementations may ignore this command, as they would only ever receive it if an SAJOIN was targeted at a service client, in which case it should be ignored...</p>
+		<h2><a name="S5_8"></a>5.8 SAPART - Channel Force Part (TOKEN: AY)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> AY <i>targetuser</i> <i>#channel</i>[ :<i>reason</i>]</tt></p>
+		<p>This requests the forced part of targetuser from #channel. This is slightly different from a KICK in that the user's removal is announced with PART. The server to which targetuser is connected to must actually acknowledge the part for it to occur. Service implementations may ignore this command, as they would only ever receive it if an SAPART was targeted at a service client, in which case it should be ignored...</p>
+		<p>The reason field is optional. If provided the acknowledging PART message should prefix the message with &quot;SAPart:&quot;.</p>
+		<h2><a name="S5_9"></a>5.9 SAMODE - Channel Force Mode (TOKEN: o)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> o <i>#channel</i> <i>modechange</i> <i>modeparams</i></tt></p>
+		<p>This has the same parameters as for MODE. The only difference is that servers probably will never receive this (but is best to document just in case), and that absolutely NO permission checking is done on anything.</p>
+		<h2><a name="S5_10"></a>5.10 TOPIC - Channel Topic (TOKEN: ) )</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> ) <i>#channel</i> <i>nick</i> <i>timestamp</i> :<i>topic</i></tt></p>
+		<p>Changes the channel topic information. This format is used when synching, as well as when a topic is changed normally. Nick is the user who changed the topic (depending on compile options, it can be just nick or a full nick!user@host), timestamp is when the change occured, and topic is the new topic text. Normally, only a newer timestamp will actually change the topic, but a U:Lined server can use an older timestamp as well (such as for TOPICLOCK).
+		<hr/>
+		<h1><a name="S6"></a>6 Services Commands</h1>
+		<p>These are commands typically employed by a service implementation, in addition to some of the normal commands. All of the commands listed here require the sender to be correctly U:Lined. This means that the services server name must appear within a ulines {} block in the unrealircd.conf configuration for ALL servers in the network. All servers and clients behind a U:Lined server are themselves U:Lined.</p>
+		<h2><a name="S6_1"></a>6.1 SVSKILL - Force Disconnect by Service (TOKEN: h)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> h <i>target</i> :<i>reason</i></tt></p>
+		<p>This command is similar to KILL but differs in several ways. First of all: there is no mutilation of the reason value. The reason given is the exact reason used to generate QUIT messages sent to users. Second, it is silent; no server notice is generated in response to this command. Third, it can only be used by a U:Lined server or client (such as services).</p>
+		<p>Because this command can be dangerous in the hands of an abusive person, service implementations should avoid granting humans control over the reason parameter. In cases of commands where a person has control over such parameter, either use a regular KILL instead, or otherwise modify the reason so that operators can be held accountable if necessary.</p>
+		<h2><a name="S6_2"></a>6.2 SVSMODE, SVS2MODE - Force User Mode Change (TOKEN: n or v)</h2>
+		<p><b>Syntax (SVSMODE):</b> <tt>:<i>source</i> n <i>target</i> +<i>usermodes</i></tt></p>
+		<p><b>Syntax (SVS2MODE):</b> <tt>:<i>source</i> v <i>target</i> +<i>usermodes</i></tt></p>
+		<p>Judging by these commands alone, you'd think they are identical. Both commands force a usermode change to occur. This is typically used by services to set +r on a user who has successfully identified. They differ in that SVS2MODE also sends the mode change to the user, while SVSMODE does not (hidden mode change).</p>
+		<p>SVSMODE and SVS2MODE also give special treatment to usermode +d. Rather than setting the deaf mode like you might expect, SVS(2)MODE +d allows services to change a user's services stamp (which is given in the NICK message). This could allow services to set the service stamp to an easily identifiable value that could then be used to say "hey, this person identified already". The syntax of this is: +d <i>newservicestamp</i> and can be combined with setting other usermodes as well. The deaf mode <b>can</b> be set by using +d without the service stamp parameter; however, in this case you <b>cannot</b> set the service stamp in the same SVS(2)MODE message.</p>
+		<p><b>Note:</b> Do <b>NOT</b> use SVSMODE to remove IRCop status from a user. Use the SVSO command for that instead.</p>
+		<p>Alternatively, target can name a channel. In this case, the mode change parameter can consist of a - character, followed by any or all of: b, e, I, q, a, o, h, or v. These characters cause the corresponding lists to be cleared of all entries. For example: SVSMODE #channel -b removes ALL bans from #channel, and SVSMODE #channel -qaohv turns ALL users on #channel into normal users (removes all owner, admin, op, halfop, and voice status). In this case, the uplink will acknowledge with a MODE listing the bans, etc that were removed.</p>
+		<p>To completely clear a channel of all modes: MODE #channel -cfijklmnprstzACGMKLNOQRSTVu (plus any added by third-party module) followed by SVSMODE #channel -beIqaohv.</p>
+		<h2><a name="S6_3"></a>6.3 SVSSNO, SVS2SNO - Forced SNomask Change (TOKEN: BV or BW)</h2>
+		<p><b>Syntax (SVSSNO):</b> <tt>:<i>source</i> BV <i>target</i> +<i>snomasks</i></tt></p>
+		<p><b>Syntax (SVS2SNO):</b> <tt>:<i>source</i> BW <i>target</i> +<i>snomask</i></tt></p>
+		<p>Changes a user's snomasks. The difference between SVSSNO and SVS2SNO is the same as with SVSMODE versus SVS2MODE. If the user is not +s, you must add it via SVSMODE +s. For example:</p>
+		<pre>:OperServ v someuser +s
+:OperServ BW someuser +ks</pre>
+		<h2><a name="S6_4"></a>6.4 SVSNICK - Forced Nick Change (TOKEN: e)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> e <i>target</i> <i>newnick</i> :<i>newtimestamp</i></tt></p>
+		<p>Forces the specified user to change his nick to newnick and also sets the nick timestamp to newtimestamp (so, for example, services could protect identified users from a nick collision by simply setting the nick timestamp to something way less than "now" - though currently this requires actually changing the nick too). SVSNICK requires the server to which the target is connected to acknowledge the nick change. If the user specified by newnick already exists, then target will be disconnected (even if it's something like a case-change).</p>
+		<h2><a name="S6_5"></a>6.5 SVSJOIN - Forced Join (TOKEN: BX)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> BX <i>target</i> <i>#channel</i></tt></p>
+		<p>This is identical to SAJOIN with a few exceptions: 1) It is U:Line-only. 2) No opernotice on use. 3) Bans and restricting modes are respected, a prior INVITE message must be sent to cause bans to be ignored.</p>
+		<h2><a name="S6_6"></a>6.6 SVSPART - Forced Part (TOKEN: BT)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> BT <i>target</i> <i>#channel</i> :<i>reason</i></tt></p>
+		<p>Also identical to SAPART with a few exceptions: no static prefix on the optional part reason, and no global notice, and requires a U:Line. Usage recommendation of SVSPART versus KICK is the same as for SVSKILL versus KILL.</p>
+		<h2><a name="S6_7"></a>6.7 SVSO - Oper Permissions (TOKEN: BB)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> BB <i>target</i> <i>flagchanges</i></tt></p>
+		<p>This allows a service to add or remove IRCop permission flags for a user. Flagchanges is formatted similar to that of MODE with the exception that operflags are used instead of usermodes. If the change string consists only of -, then all oper permissions, usermodes, and snomasks are removed (as if the user had himself typed MODE nick -Oo).</p>
+		<p>If you are granting IRCop permissions to a user who is not currently an IRCop, you should follow up with an SVSMODE +o or SVSMODE +O as appropriate. For example:</p>
+<pre>:OperServ BB somenick +o
+:OperServ BW somenick +cefknoqsSv
+:OperServ AL somenick local.oper.somethinghere.net
+:OperServ v somenick +Ohs </pre>
+		<h2><a name="S6_8"></a>6.8 SVSNOOP - Oper Lockdown (TOKEN: f)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> f <i>(op)</i><i>server.name</i></tt></p>
+		<p>The (op) parameter is either a + or - indicating if NOOP mode should be activated (+) or deactivated (-). When NOOP mode is activated, all IRCops on the server are deopered (including local operators) and the /oper command is disabled. IRCop privileges can still be granted through use of SVSO. On UnrealIRCd, it is not necessary to masskill all IRCops on the nooped server, as they are deopered automatically.</p>
+		<h2><a name="S6_9"></a>6.9 SVSNLINE - RealName Ban (TOKEN: BR)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> BR <i>op</i> <i>reason</i> :<i>realname mask</i></tt></p>
+		<p>Op is either + (add) or - (remove). In the case of +, reason is a space-escaped string (all space chars are encoded as _). If -, reason is ignored.</p>
+		<h2><a name="S6_10"></a>6.10 SVSFLINE - File Ban (TOKEN: BC)</h2>
+		<p><b>Syntax (add):</b> <tt>:<i>source</i> BC + <i>filemask</i> :<i>reason</i></tt></p>
+		<p><b>Syntax (remove):</b> <tt>:<i>source</i> BC - <i>filemask</i></tt></p>
+		<p><b>Syntax (clear):</b> <tt>:<i>source</i> BC *</tt></p>
+		<p>Adds or removes a DCCDENY item for the specified filemask on all servers. These DCCDENYs are hard dccdenies - the /dccallow command cannot override it. The last form removes all dccdenies added via SVSFLINE.</p>
+		<hr/>
+		<h1><a name="S7"></a>7 Messaging</h1>
+		<p>What good is Internet Relay <b>CHAT</b> if users cannot <b>CHAT</b>? This section addresses the commands through which arbitrary user messages are sent.</p>
+		<h2><a name="S7_1"></a>7.1 PRIVMSG, NOTICE - Simple Message Transmission (Token: ! or B)</h2>
+		<p><b>PRIVMSG Syntax:</b> <tt>:<i>source</i> ! <i>target</i> :<i>message</i></tt></p>
+		<p><b>NOTICE Syntax:</b> <tt>:<i>source</i> B <i>target</i> :<i>message</i></tt></p>
+		<p>Sends a messages to the given target. The target either names a single client, or identifies a list of clients in which the message is to be sent to. The available targets include:</p>
+		<ul>
+			<li><i>nickname</i>: Names a single user to whom the message is delivered.</li>
+			<li><i>nickname</i>@<i>servermask</i>: Also names a single user, but the message will only be delivered if the user is connected to a server matching the specified servermask. This is typically used for sending messages to services. The target must not be changed at any point along the path it must travel for delivery, even up to the final receipt of the message by the target. This allows the target to know it has been sent a message in this way.</li>
+			<li>#<i>channelname</i>: Sends a message to all users on the specified channel (except when channel is a moderated auditorium (+mu), in which case the wierd +mu sending behavior goes off).</li>
+			<li><i>modeprefix</i>#<i>channelname</i>: Sends a message to all users on the given channel having the given status or higher. For example: + means all voices, halfops, etc.</li>
+			<li>$<i>servermask</i>: Sends a message to ALL users on all servers matching the specified servermask (known as a server broadcast message). The RFC requirements of having a TLD with no wildcards is not applied to U:Lined clients.</li>
+		</ul>
+		<p>Unreal does not support the #hostmask format.</p>
+		<h2><a name="S7_2"></a>7.2 SENDUMODE, SMO - Usermode-based Delivery (TOKEN: AP or AU)</h2>
+		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> AU <i>umode</i> :<i>message</i></tt></p>
+		<p>Sends the specified message to all users with the given mode. Only one usermode may be given. This is a server-only command if you can't tell from the sender prefix :) .</p>
+		<p>The message will be displayed as coming from the receiving client's own server. It may be appropriate to add a &quot;*** Notice (or other leader here) -- from blah:&quot; if you wish to clarify where the message is from.</p>
+		<h2><a name="S7_3"></a>7.3 SENDSNO - SNomask-based Delivery (TOKEN: Ss)</h2>
+		<p><b>Syntax:</b> <tt>@<i>servernumeric</i> Ss <i>snomask</i> :<i>message</i></tt></p>
+		<p>Sends the specified message to all users with the given snomask. Only one snomask may be given. This is a server-only command if you can't tell from the sender prefix :) .</p>
+		<p>The message will be displayed as coming from the receiving client's own server. It may be appropriate to add a &quot;*** Notice (or other leader here) -- from blah:&quot; if you wish to clarify where the message is from.</p>
+		<h2><a name="S7_4"></a>7.4 CHATOPS - IRCop Chat (TOKEN: p)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> p :<i>message</i></tt></p>
+		<p>Sends the message to all IRCops on all servers.</p>
+		<h2><a name="S7_5"></a>7.5 WALLOPS - Wallop Chat (TOKEN: =)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> = :<i>message</i></tt></p>
+		<p>Sends the message to all users with usermode +w, whether they are ircops or not.</p>
+		<h2><a name="S7_6"></a>7.6 GLOBOPS - FailOp Chat (TOKEN: ])</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> ] :<i>message</i></tt></p>
+		<p>Send the message to all IRCops with usermode +g.</p>
+		<h2><a name="S7_7"></a>7.7 ADCHAT - Admin Chat (TOKEN: x)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> x :<i>message</i></tt></p>
+		<p>Send the message to all Server and Network Admins (usermode +A).</p>
+		<h2><a name="S7_8"></a>7.8 NACHAT - NetAdmin Chat (TOKEN: AC)</h2>
+		<p><b>Syntax:</b> <tt>:<i>source</i> AC :<i>message</i></tt></p>
+		<p>Send the message to all Network Admins (usermode +N).</p>
+		<hr/>
+		<h1><a name="S8"></a>8 Ban Control</h1>
+		<p>Sometimes, you have the misfortune of encountering a user who has no purpose but to serve as an annoyance to your server or network. These commands transmit network-wide ban information amongst each other.</p>
+		<h2><a name="S8_1"></a>8.1 TKL - Master Ban Control (TOKEN: BD)</h2>
+		<p>The TKL command seems to have one oddity about it: the real ban source is included in the TKL command rather than in the sender prefix. Most likely this is done for synching reasons (so that the *line ban can be credited to the proper person even if he/she is offline). For this reason, the command syntax is given without any sender prefix at all. It is still permissible to use one, however.</p>
+		<h3><a name="S8_1_1"></a>8.1.1 GLINE - Network-wide user@host ban</h3>
+		<p><b>Add Syntax (TKL):</b> <tt>BD + G <i>userpart</i> <i>hostpart</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
+		<p><b>Remove Syntax (TKL):</b> <tt>BD - G <i>userpart</i> <i>hostpart</i> <i>source</i></tt></p>
+		<p>Adds and Removes Network-wide user@host bans, known as G:Lines. The GLINE command itself must not be used. The userpart and hostpart are the user portion and hostname portion of the ban mask. The expiretimestamp is 0 if the G:Line should not expire, otherwise it will expire at the given time. It is an absolute time, not relative, thus it's imperitive to have reasonably synchrnoized clocks or bans may be removed too early or even immediately!</p>
+		<h3><a name="S8_1_2"></a>8.1.2 GZLINE - Network-wide IP ban</h3>
+		<p><b>Add Syntax (TKL):</b> <tt>BD + Z * <i>ipmask</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
+		<p><b>Remove Syntax (TKL):</b> <tt>BD - Z * <i>ipmask</i> <i>source</i></tt></p>
+		<p>Adds and Removes Network-wide IP bans, known as Global Z:Lines. The GZLINE command itself must not be used. Ipmask permits CIDR notation as well as wildcard masks.</p>
+		<h3><a name="S8_1_3"></a>8.1.3 SQLINE, UNSQLINE - Network-wide Nickname ban (TOKEN: c or d)</h3>
+		<p><b>Add Syntax (TKL):</b> <tt>BD + Q <i>hold</i> <i>nickmask</i> <i>source</i> <i>expiretimestamp</i> <i>settimestamp</i> :<i>reason</i></tt></p>
+		<p><b>Add Syntax (SQLINE):</b> <tt>:<i>source</i> c <i>nickmask</i> :<i>reason</i></tt></p>
+		<p><b>Remove Syntax (TKL):</b> <tt>BD - Q <i>hold</i> <i>nickmask</i> <i>source</i></tt></p>
+		<p><b>Remove Syntax (UNSQLINE):</b> <tt>:<i>source</i> d <i>nickmask</i></tt></p>
+		<p>In the TKL syntax, the hold parameter is either a * to mark the qline as a nick ban, or an H to mark it as a services hold. A services hold does not trigger qline rejection notice, and is typically used by NickServ to reserve registered nicks until they are released by the owner. The (UN)SQLINE syntax can only be used by a server, but any user can be used as the source for the TKL syntax. Unlike G and GZ lines, Q:Lines do not cause existing matching users to be disconnected or otherwise affected.</p>
+		<p>The TKL syntax is preferred, since it is more flexible, but (UN)SQLINE is permitted for compatibility.</p>
+		<h3><a name="S8_1_4"></a>8.1.4 SPAMFILTER - Message Spam Filtration System</h3>
+		<p>Proper use of spamfilter in TKL commands requires use of PROTOCTL TKLEXT, which increases the number of parameters allowed in TKL.</p>
+		<p><b>Add Syntax (TKL):</b> <tt>BD + F <i>target(s)</i> <i>action</i> <i>source</i> 0 <i>settimestamp</i> <i>tklduration</i> <i>tklreason</i> :<i>regex</i></tt></p>
+		<p><b>Remove Syntax (TKL):</b> <tt>BD - F <i>target(s)</i> <i>action</i> <i>source</i> 0 <i>settimestap</i> :<i>regex</i></tt></p>
+		<p>Adds and Removes network-wide spamfilters. The SPAMFILTER command itself must not be used. See <a href="http://vulnscan.org/UnrealIrcd/unreal32docs.html#feature_spamfilter">http://vulnscan.org/UnrealIrcd/unreal32docs.html#feature_spamfilter</a> for a list of valid targets. For actions, a single character is used to identify the action to be taken:</p>
+		<ul>
+			<li>K (kill) - The user is simply disconnected, with the reason given.</li>
+			<li>S (tempshun) - A temporary shun is placed on the user. This shun is applied only to that user, and disappears if the user reconnects.</li>
+			<li>s (shun) - A regular shun on the user's IP address is added. This causes all users with the same hostname to be shunned, but they will also stay shunned if they reconnect.</li>
+			<li>k (kline) - A K:Line is added on the user's IP address.</li>
+			<li>z (zline) - A Z:Line is added on the user's IP address.</li>
+			<li>g (gline) - A G:Line is added on the user's IP address.</li>
+			<li>Z (gzline) - A Global Z:Line is added on the user's IP address.</li>
+			<li>b (block) - Messages (or users!) matching the filter are simply blocked.</li>
+			<li>d (dccblock) - The user is prevented from sending files using DCC for the remainder of his session (in other words, until he quits).</li>
+			<li>v (viruschan) - User is removed from all channels, joined to the viruschan as defined in conf, and cannot message anything but that channel.</li>
+			<li>w (warn) - No action on the user is taken. Only the Spamfilter notice is sent to opers with snomask +S.</li>
+		</ul>
+		<h1><a name="S9">9 Base64 Tables</a></h1>
+		<p>Unreal uses base64 encoding to allow saving bandwidth by encoding numbers in a more compact format. Unreal uses two different variations of base64, one used for the SJB64 PROTOCTL option (in NICK and SJOIN), and one used for NICKIP.</p>
+		<h2><a name="S9_1">9.1 Table for SJB64 (NICK and SJOIN).</a></h2>
+		<p>In NICK and SJOIN, remember that the timestamp will be prefixed with ! to signal a base64 timestamp.</p>
+		<p>Just like in base10, the least significant &quot;digit&quot; is last.</p>
+		<pre> 0 0            17 H            34 Y            51 p
+ 1 1            18 I            35 Z            52 q
+ 2 2            19 J            36 a            53 r
+ 3 3            20 K            37 b            54 s
+ 4 4            21 L            38 c            55 t
+ 5 5            22 M            39 d            56 u
+ 6 6            23 N            40 e            57 v
+ 7 7            24 O            41 f            58 w
+ 8 8            25 P            42 g            59 x
+ 9 9            26 Q            43 h            60 y
+10 A            27 R            44 i            61 z
+11 B            28 S            45 j            62 {
+12 C            29 T            46 k            63 }
+13 D            30 U            47 l
+14 E            31 V            48 m
+15 F            32 W            49 n
+16 G            33 X            50 o</pre>
+		<h2><a name="S9_2">9.2 Table for NICKIP.</a></h2>
+		<p>In this table, the IP is encoded in network byte order. In terms of IPs, this means the first byte of the address really is first. Each &quot;digit&quot; in the base64 encoded IP corresponds to 6 bits of the IP address.</p>
+		<p>An IPv4 address is 32 bits, so 6 base64 &quot;digits&quot; are needed. Since base64 requires values to come in multiples of 4 &quot;digits&quot;, padding characters (=) need to be added if a value comes up short. In the case of IPv4 addresses, two are needed.</p>
+		<p>IPv6 addresses are 128-bit. They therefore need 22 base64 &quot;digits&quot; plus 2 pad characters.</p>
+		<pre> 0 A            17 R            34 i            51 z
+ 1 B            18 S            35 j            52 0
+ 2 C            19 T            36 k            53 1
+ 3 D            20 U            37 l            54 2
+ 4 E            21 V            38 m            55 3
+ 5 F            22 W            39 n            56 4
+ 6 G            23 X            40 o            57 5
+ 7 H            24 Y            41 p            58 6
+ 8 I            25 Z            42 q            59 7
+ 9 J            26 a            43 r            60 8
+10 K            27 b            44 s            61 9
+11 L            28 c            45 t            62 +
+12 M            29 d            46 u            63 /
+13 N            30 e            47 v
+14 O            31 f            48 w         (pad) =
+15 P            32 g            49 x
+16 Q            33 h            50 y</pre>
+	</body>
+</html>

doc/translations.txt

@@ -1,4 +1,4 @@
-==[ Translations ]============================================================
+==[ Translations ]===========================================================
 
 Starting with the release of Unreal 3.2 we have begun accepting translated
 documentation files. For now, only translations of unreal32docs.html and
@@ -42,4 +42,4 @@ to translate to.. You will then receive an email back saying you can
 go ahead (or not). This is mainly to avoid multiple persons working 
 on the same translation.
 
-==============================================================================
+=============================================================================

doc/unreal32docs.de.html

@@ -29,7 +29,7 @@
 
 <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.9-RC1</font><br>
+  <font size="4">Version: 3.2.9-RC2</font><br>
   <b>Letztes Update dieses Handbuchs:</b>                    2009-12-24</div>
   <b>Head Coders:</b> Stskeeps / codemastr / Syzop / Luke<font face="Helvetica,Arial" size="-1">/
 aquanight / WolfSage</font><br>

doc/unreal32docs.es.html

@@ -31,7 +31,7 @@ Spanish |
 <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">Versi&oacute;n: 3.2.9-RC1</font><br>
+  <font size="4">Versi&oacute;n: 3.2.9-RC2</font><br>
   <b>&Uacute;ltima actualizaci&oacute;n del documento:</b> 22-12-2006</div>
 <br>
   <b>Programadores:</b> Stskeeps / codemastr / Syzop / Luke<br>

doc/unreal32docs.fr.html

@@ -39,7 +39,7 @@
 		<div style="text-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.9-RC1</font><br>
+  			<font size="4">Version: 3.2.9-RC2</font><br>
   			<b>Derni&egrave;re mise &agrave; jour de la documentation:</b> 2010-09-19
 		</div>
 

doc/unreal32docs.html

@@ -32,7 +32,7 @@ English |
 <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.9-RC1</font><br>
+  <font size="4">Version: 3.2.9-RC2</font><br>
   <b>Last doc update:</b> 2010-11-15</div>
 <br>
   <b>Head coder/maintainer:</b> Syzop<br>

doc/unreal32docs.hu.html

@@ -31,7 +31,7 @@ Hungarian |
 <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">Verzió: 3.2.9-RC1</font><br>
+  <font size="4">Verzió: 3.2.9-RC2</font><br>
   <b>Utolsó dokumentáció frissítés:</b> 2010-11-15</div>
 <br>
   <b>Fõ fejlesztõ/karbantartó:</b> Syzop<br>

doc/unreal32docs.nl.html

@@ -29,7 +29,7 @@ Dutch |
 <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.9-RC1</font><br>
+  <font size="4">Version: 3.2.9-RC2</font><br>
   <b>Laatste documentatie wijziging:</b> 2009-01-03</div>
 
 <br>
@@ -42,6 +42,7 @@ Dutch |
  http://www.vulnscan.org/UnrealIRCd/unreal32docs.html</a> en een FAQ staat op
  <a href="http://www.vulnscan.org/UnrealIRCd/faq/" TARGET="_blank">http://www.vulnscan.org/UnrealIRCd/faq/</a>.
 </p>
+<p><font color="red">WARNING: The translation of this document is not up to date, the English version is more recent.</font></p>
 
 <p><b>Geschikte browsers: </b><br>
 <ul>

doc/unreal32docs.ru.html

@@ -26,7 +26,7 @@
 		<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">Âåðñèÿ: 3.2.9-RC1</font><br>
+			<font size="4">Âåðñèÿ: 3.2.9-RC2</font><br>
 			<b>Ïîñëåäíåå îáíîâëåíèå:</b> 2010-05-17</div>
 		<br>
 		<b>Ãëàâíûå ïðîãðàììèñòû</b> Syzop<br>

doc/unreal32docs.tr.html

@@ -51,7 +51,7 @@ Turkish
 <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.9-RC1</FONT><BR><B>En Son Güncelleme:</B>
+size=4>Version: 3.2.9-RC2</FONT><BR><B>En Son Güncelleme:</B>
 2010-11-15</DIV><BR>
 <B>Baş Kodlayıcı/Devam Ettiren:</b> Syzop<br>
 <b>Kodlayıcılar:</b> binki<br>
@@ -60,7 +60,7 @@ WolfSage, McSkaf, Zogg,
 NiQuiL,  assyrian,  chasm,  DrBin,  llthangel, Griever,  nighthawk<br>
 <b><strong>Belgeleme</strong>:</b> CKnight^ (ilk belgeleyen), Syzop (yeniden yazan), codemastr, ve daha çok katkıda bulunanlar<br>
 <B>Önceki Çevirmenler:</B> oepidus (tt`), Strathmore (Timaeus) - irc.trsohbet.com<br>
-<B>Türkçe Çeviri:</B> <a href="mailto:diablo@unrealircd.org">Diablo</a> & <a href="irc://irc.sohbetalem.net">irc.chat.com.tr</a><br>
+<B>Türkçe Çeviri:</B> <a href="mailto:diablo@unrealircd.org">Diablo</a><br>
 <P>Bu dökümanı görüntüleyebilmeniz için aşağıda listelenmiş olan
 tarayıcılardan birine sahip olmanız gerekir. Güncellenmiş dökümanlara <A
 href="http://www.vulnscan.org/UnrealIRCd/unreal32docs.tr.html">http://www.vulnscan.org/UnrealIRCd/unreal32docs.tr.html</A>

include/.cvsignore

@@ -1 +0,0 @@
-setup.h

include/version.h

@@ -52,7 +52,7 @@
 #define PATCH1  		"3"
 #define PATCH2  		".2"
 #define PATCH3  		".9"
-#define PATCH4  		"-rc1"
+#define PATCH4  		"-rc2"
 #define PATCH5  		""
 #define PATCH6  		""
 #define PATCH7  		""

ircdcron/.cvsignore

@@ -1 +0,0 @@
-ircdchk

src/.cvsignore

@@ -1,2 +0,0 @@
-ircd
-version.c

src/ircd.c

@@ -1003,18 +1003,26 @@ struct ThrottlingBucket z = { NULL, NULL, {0}, 0, 0};
 static void generate_cloakkeys()
 {
 	/* Generate 3 cloak keys */
-#define GENERATE_CLOAKKEY_MINLEN 10
-#define GENERATE_CLOAKKEY_MAXLEN 20 /* Length of cloak keys to generate. */
+#define GENERATE_CLOAKKEY_MINLEN 16
+#define GENERATE_CLOAKKEY_MAXLEN 32 /* Length of cloak keys to generate. */
 	char keyBuf[GENERATE_CLOAKKEY_MAXLEN + 1];
 	int keyNum;
 	int keyLen;
 	int charIndex;
 	int value;
 
+	short has_upper;
+	short has_lower;
+	short has_num;
+
 	fprintf(stderr, "Here are 3 random cloak keys:\n");
 
 	for (keyNum = 0; keyNum < 3; ++keyNum)
 	{
+		has_upper = 0;
+		has_lower = 0;
+		has_num = 0;
+
 		keyLen = (getrandom8() % (GENERATE_CLOAKKEY_MAXLEN - GENERATE_CLOAKKEY_MINLEN + 1)) + GENERATE_CLOAKKEY_MINLEN;
 		for (charIndex = 0; charIndex < keyLen; ++charIndex)
 		{
@@ -1022,17 +1030,25 @@ static void generate_cloakkeys()
 			{
 				case 0: /* Uppercase. */
 					keyBuf[charIndex] = (char)('A' + (getrandom8() % ('Z' - 'A')));
+					has_upper = 1;
 					break;
 				case 1: /* Lowercase. */
 					keyBuf[charIndex] = (char)('a' + (getrandom8() % ('z' - 'a')));
+					has_lower = 1;
 					break;
 				case 2: /* Digit. */
 					keyBuf[charIndex] = (char)('0' + (getrandom8() % ('9' - '0')));
+					has_num = 1;
 					break;
 			}
 		}
 		keyBuf[keyLen] = '\0';
-		(void)fprintf(stderr, "%s\n", keyBuf);
+
+		if (has_upper && has_lower && has_num)
+			(void)fprintf(stderr, "%s\n", keyBuf);
+		else
+			/* Try again. For this reason, keyNum must be signed. */
+			keyNum--;
 	}
 }
 #endif

src/modules.c

@@ -1637,9 +1637,6 @@ int i;
 #else
 		config_error("ERROR: No cloaking module loaded. (hint: you probably want to load modules\\cloak.dll)");
 #endif
-		/* TEMPORARY! */
-		config_error("If you are upgrading from 3.2 (or any older version), be sure to read the release notes "
-		             "or www.vulnscan.org/tmp/newcloak.txt regarding the cloaking change!");
 		return -1;
 	}
 

src/modules/.cvsignore

@@ -1,2 +0,0 @@
-Makefile
-*.dSYM

src/send.c

@@ -120,11 +120,19 @@ void flush_connections(aClient* cptr)
 	{
 		for (i = LastSlot; i >= 0; i--)
 			if ((acptr = local[i]) && !(acptr->flags & FLAGS_BLOCKED)
-			    && DBufLength(&acptr->sendQ) > 0)
+			    && ((DBufLength(&acptr->sendQ) > 0)
+#ifdef ZIP_LINKS
+				|| (IsZipped(acptr) && acptr->zip->outcount)
+#endif /* ZIP_LINKS */
+				) )
 				send_queued(acptr);
 	}
 	else if (cptr->fd >= 0 && !(cptr->flags & FLAGS_BLOCKED)
-	    && DBufLength(&cptr->sendQ) > 0)
+	    && ((DBufLength(&cptr->sendQ) > 0)
+#ifdef ZIP_LINKS
+		|| (IsZipped(cptr) && cptr->zip->outcount)
+#endif /* ZIP_LINKS */
+		) )
 		send_queued(cptr);
 
 }

src/version.c.SH

@@ -127,7 +127,6 @@ char *unrealcredits[] =
 	"Current hosters:",
 	"http://www.vulnscan.org/  All WWW sites",
 	"http://FTCNetworks.com/   IRCd shell",
-	"warg/andrew               VPS for IRCd",
 	"Below are people who have donated hosting in the past:",
 	"Phil Veale - email@phillipveale.com - http://www.tiefighter.org",
 	"- Donating webhosting for the project amongst other things",

src/win32/service.c

@@ -87,7 +87,10 @@ VOID WINAPI IRCDCtrlHandler(DWORD opcode)
 	}
 	/* Rehash */
 	else if (opcode == IRCD_SERVICE_CONTROL_REHASH) 
+	{
 		rehash(&me,&me,0);
+		reread_motdsandrules();
+	}
 
 	SetServiceStatus(IRCDStatusHandle, &IRCDStatus);
 } 

src/win32/unrealinst.iss

@@ -11,7 +11,7 @@
 
 [Setup]
 AppName=UnrealIRCd
-AppVerName=UnrealIRCd3.2.9.1-RC1
+AppVerName=UnrealIRCd3.2.9.1-RC2
 AppPublisher=UnrealIRCd Team
 AppPublisherURL=http://www.unrealircd.com
 AppSupportURL=http://www.unrealircd.com