Things to probably do:

**	Add ability to create command aliases in conf file (e.g. REG->REGISTER)
	    [Stanislav Zahariev <sofit@proshe.bg>]
CS	Make DROP work like NickServ: require password for regular users,
		have separate DROPCHAN command for servadmins
**	Rate-limit message floods (e.g. botnet autokill expiration)
OS	AKILL/etc. DEL ALL (or CLEAR?)
NS/MS	Add a separate mail address field for memo forwarding
CS	Add a modules.conf option to set the default channel mlock
	    [<us44ever@hotmail.com>]
NS	Flags for LIST[EMAIL] to match against only nick or only usermask/email
CS	When moving to a new ircd, graceful handling for modelocked modes
		not available in the new ircd
	    [Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>]
OS	Change KILLCLONES to AKILLNICK or similar
	    [Mark Hetherington <mark@ctcp.net>]
NS	Option to prevent certain domains from being used in mail addresses
CS	Send message sender to KICK callback
	    [Georges Berscheid <georges@berscheid.lu>]
CS	Clearer message when CLEAR used with bad "what" parameter
	    [Craig McLure <Craig@chatspike.net>]
**	Allow switching encryption methods for databases (i.e. none->MD5)
	    [Rayford Pomeroy <rayfordp@mhonline.net>]
OS	Allow multiple parameters for KILLCLONES
	    [Ian Justman <ianj@esper.net>]
NS	Allow LISTCHANS on other users for servadmins
	    [Alistair Jamieson <ajamieson@student.ccgs.wa.edu.au>]
NS/CS	Allow "/ns list +21 *.foo.com" and the like (is this syntax good?)
	    [Michael D. Smith <msmith@acmecorp.org>]
CS	Return XOP instead of numbers for STATUS when appropriate
	    [Jollino <jollino@sogno.net>]
NS	Optionally send memo to newly registered nicks
	    [Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>]
OS	Allow wildcard/regex kills of nicks
	    [Guy Antony Halse <guy@rucus.ru.ac.za>]
NS	Add a SETNICK command to replace servadmin "SET nick option ..."
MS	Add memo forwarding for channel memos as well
**	Allow including of configuration files
	    [Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>]
NS	Disallow registration/linking of SQLINEd nicks
httpd	Add indicators for noexpire/forbidden/suspended to nick/channel lists
**	Log servadmin use of NS/CS/MS commands for other nicks/channels
	    [last 2: Mark Hetherington <mark@ctcp.net>]
httpd	Add custom 404 pages, especially for redirect module
news	Don't send news to users reconnecting after a split
	    [<v13@it.teithe.gr>]
CS	Incremental change for SET MLOCK
	    [Ekim Engin <EEngin@t-online.de>]
OS	Option to send notice to akilled user explaining akill
	    [Finny Merrill <griever@t2n.org>]
**	Faster netburst processing
NS	Numbered access list

--------

Things to think about:

CS	Better integration of channel keys with ChanServ
CS	Option to autokill users entering a forbidden channel (botnets)
	    [<noddie_x@shadowfire.org>]
NS	"Online as linked nick" field in INFO? eg "Online as SomeNick[away]"
	    [Craig McLure <Craig@chatspike.net>]
NS	Allow masks for "unregisterable-but-usable" nicks
	    [Mark Hetherington <mark@ctcp.net>]
CS	Allow autokick exceptions
	    [Dionisios K. <Admin@vonitsanet.gr>]
CS	Specify (in conf file) modes that users are not allowed to change
	    [Medice <medice@gmx.at>]
CS	ChanServ LINK, like NickServ but for channels
	    [Craig McLure <Craig@chatspike.net>]
NS	Require E-mail address regged with nick for SENDPASS
	    [playa <playa6@sbcglobal.net>]
NS	Replace "may not be registered or used" with "is forbidden" in
		messages to servopers/admins for forbidden nicks?
OS	Notify autokilled users of autokill expiration upon kill
OS	Make news memo-like: separate command to read, and notice of new
		news at logon
	    [last 2: <saturn@jetirc.net>]
OS	Allow regex autokills/exceptions/slines
	    [Aragon Gouveia <aragon@phat.za.net>]
NS/CS	Reason for FORBID
**	Option/module to log all WALLOPS/GLOBOPS
	    [Andrew Kempe <andrewk@isdial.net>]
CS	VERBOSE option: like OPNOTICE but for everything (ACCESS etc.)
	    [Martin <martin@e-tech.us>]
MS	Remove discrepancy between nick and channel memo handling with
		non-SECURE nicks (can't read the former without IDENTIFY,
		but can read the latter)?
	    [<pteryx@adelphia.net>]
**	Allow limiting usable languages (e.g. only allow EN/PT)
	    [Mauritz Antunes <mauritz@brasnet.org>]
NS	Use highest access level of all identified nicks for user's acclev
	    [Alexander Janssens <alex@cyga.net>]
CS	Option to kill/autokill users who join a forbidden channel
	    [<Ganja51@lcirc.net>]
NS	Show successor channels in LISTCHANS
	    [Marc-Andre A. Fuentes <nothing@psychopat.org>]
OS	For AKILL/SLINE/EXCEPTION ADD, set expiration time to given time
		instead of erroring out
	    [<RT.Mail@verizon.net>]
CS	GETKEY command to get the key of a +k channel for privileged users
	    [Dennis Sela <Schutzgeist@uni.de>]
**	Add a way to clear one or more databases (currently done by rm *.db)
	    [<RealCFC@chatfirst.com>]
SS	# users per domain on each server
	    [Ali Sor <alisor@softhome.net>]
NS/auth	Do MX lookup on REGISTER/SET EMAIL address before sending AUTH message
	    [Brian <n1uro@n1uro.com>]
CS	Look up channels by E-mail address
	    [Finny Merrill <griever@t2n.org>]
NS	Show Services admin/oper status in INFO
	    [Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>]
NS	Make GHOST obey NSForceNickChange to prevent users killing other users
	    [Mark Hetherington <mark@ctcp.net>]
MS	Expand ignore list to have an "only these and no others" mode
httpd	Network status page, possibly with graphs (cf. netsplit.de, also
	    http://rc5proxy.dhs.org/cgi-bin/irccounter.cgi{,?log=irc})
CS	More intelligent handling of missing "#" on channel name for REGISTER
	    [last 2: Jollino <jollino@sogno.net>]
NS	NOOP option for nicks
	    [Jon Dingman <Jon@ftel.net>]
CS	Allow CS ACCESS LIST by level (e.g. all entries with levels 5-10)
	    [Gustavo <guga-2@brasnet.org>]
CS	Use a better system than "auto-opped users" for channel last-used time
NS	Warn users via E-mail when nick is about to expire (optionally)
	    [Hans v Steenbergen <thebeast@xs4all.nl>]
MS	Add a way to find out whether users sent to another memo were read
	    [Craig Wood <frostycoolslug@hotmail.com>]
	    ("notify-when-recv'd" setting [Strider <strider@chatcircuit.com>])
NS	Allow changing vhost to E-mail address
OS	Command to autokill all users in a channel (anti-DDOS)
	    [Samual Graenacher <sam@breakfree.com>]
**	Autokill on repeated bad password kills
	    [Jonathan Morton <chromi@cyberspace.org>]
**	Reconnect on server disconnect
NS	Include nick in response when setting options for other nicks
	    [<Coolkill121@aol.com>]
NS	Show access level in LISTCHANS
	    [Bryan <GrimZ@fidnet.com>]
NS	Allow servadmins to modify access list
	    [Mauritz Antunes <mauritz@americasnet.com.br>]
SS	Stats for # of joins/kicks/connects/etc. for users/channels
	    [<Georges@Berscheid.lu>]
SS	Should we save server quit time/message between restarts?
MS	Command to delete last sent memo if recipient hasn't logged on since
	    [Stefan Funke <bundy@bundynet.de>]
**	Use an easily-parsable log format (eg: <time> CS REG #chan Founder)
		(also option to select what to log?)
MS	Notification for channel memos (on send, on logon?)
CS	Setter for access entries
	    [Dennis Sela <Schutzgeist@uni.de>]
CS	Last used time for access entries
	    [<fabulous@brasnet.org>]
CS	Notice about NickServ IDENTIFY required for secure privs
**	Add SYS_LANGUAGE and language-ify strings for wallops/kills/etc.
OS	Should CLEARMODES obey regged channels' mode locks?
**	Add a way to send OperServ (and other?) commands from the shell
**	Services log channel

--------

Things NOT to do:

CS	Channel/conffile setting to make ChanServ join channels ("BotServ")
	    This has been discussed many, many times, and will not be
	    reconsidered; see question Z.6 in the FAQ.
NS/CS	Allow SENDPASS without mail authentication (FAQ D.3)
NS	Allow DROP or SET EMAIL if registered with a wrong E-mail address
	    This would allow users to send mailbombs using Services.  If a
	    wrong address is given in a REGISTER or SET EMAIL command, a
	    Services administrator will need to manually intervene and
	    either reset the address or drop the nick.
CS	Automatically set/clear op/voice/etc. on channel access list change
	    Access list changes are typically one-time events, and don't
	    warrant the added complexity of such a feature; it's easy
	    enough to manually op/voice the user.
