-- ircd.conf Programming --

                        --------------------

       1) ............................. Introduction
       2) ............................. ircd.conf Basics
       3) ............................. ircd.conf Lines
        3.1) .......................... M Lines
        3.2) .......................... A Lines
        3.3) .......................... Y Lines
        3.4) .......................... I Lines
        3.5) .......................... O Lines
        3.6) .......................... C and N Lines
        3.7) .......................... K Lines
        3.8) .......................... Q Lines
        3.9) .......................... L Lines
        3.10) ......................... H Lines
        3.11) ......................... P Lines
        3.12) ......................... V Lines
       4) ............................. Summary

                        --------------------

1) Introduction:

  If you are running, or planning on running an IRC server for DALnet,
 you will need to setup an ircd.conf, your ircd.conf must meet the
 requirements of a linked DALnet server which means it must contain all
 the standard DALnet lines, these will be listed at the bottom of this
 document.

                        --------------------

2) ircd.conf Basics:

  When you compile your server, you must specify the correct paths to
 where you plan on keeping your ircd.conf, for simplicity it is recomended
 that you keep it in the same diretory as your ircd binary and other ircd
 files.
   note: You need only supply full pathnames for DPATH and SPATH, the
 other defines will only point to files under these directories so you
 need not put full path names.
  For security reasons, your ircd.conf should have permissions set to 600,
 if other users on your system gain access to view the file they may be
 able to breach the security of your server and compromise the whole
 network.
  When you have made your ircd.conf you may check it with the program
 `chkconf', this program is supplied with the source code release and will
 be installed into your ircd directory when you run `make install',
 `chkconf' will check your ircd.conf for errors so is a usefull tool for
 beginners to ircd.conf.
  Your ircd.conf will be made up of a series of lines, each line is used
 for a different purpose in the running of your server, some lines are
 mandatory for ircd, so you must enter these lines or your server will not
 start, these lines are listed below.
  You may enter comments in your ircd.conf with the use of a hash mark (#)
 at the beginning of a line, it is recommended that you make full use of
 this to add comments to everything you put in your ircd.conf so you dont
 have any problems later.
   eg: Put a contact email address and the name/nick of the server admin
       above each C/N line pair.
  When ircd reads the ircd.conf file, it does it upside down, so lines with
 higher prefrence should go lower in the file, this will be explained later.

                        --------------------

3) ircd.conf Lines:

  Each type of line in this section will be given a rating of how needed
 it is in the running of the server, the ratings are:

     MANDATORY: you absolutely MUST have this line
     NETWORKED: you must have this line if plan on connecting your server
                to other servers. (note: you can run ircd stand alone)
     SUGGESTED: it is highly suggested that you use this line
      OPTIONAL: it's completely up to you whether to define this or not
   DISCOURAGED: you really really should not use this line if at all
                possible.

 Note that "*" in a field indicates an "unused" field.

                        --------------------

3.1) M Lines: [MANDATORY]

 This line sets your server's name, description, and port number.
 If you are to be a part of DALnet you will be assigned 2 different
 DNS entries for your ircd machine, the 1st is for general public use
 and involves: <servername>.DAL.net
 The second is for use between servers for identification, these take
 the form of: <servername>.[<state>].<country>.DAL.net
 If your server is located in the US or Australia, you will be given
 a `state' field in your server's real name, otherwise your `state', or
 `area' will not be included.
 Most IRC networks default to port 6667 for their client connection's,
 but DALnet uses port 7000 as its standard, you should compile ircd with
 port 7000, not 6667, but you may open up port 6667 (it is recomended
 that you do) with a P line (see later). Your M line's port number
 should be the same as the number you defined in your config.h at compile
 time.

 Syntax:
M:hostname:bind IP:Description Of Your Server:7000
 The 1st field should be the `real' name of your server, not the short
 name.
 The 2nd field is a server bind IP. This IP is used in server to server
 connections and should be set if you have multihomed machine.
 The 3rd field is your server's description, it is up to you what you
 put in this field, but a short description of its geographic location
 is recomended.
 The 4th field is the port number that is used in server to server
 connections. Client are not accepted throught this port.

 Example:
M:disney.us.dal.net:*:Walt's DALnet Server:7000

                        --------------------

3.2) A Lines: [MANDATORY]

 This line sets your server's administrative information.
 Whenever a user types /admin on your server (or /admin <servername>)
 they will recieve the information you put here.
 This line has no set information, so you may put arbitrary text if you
 like, but it is recomended that you at least put your nick and email
 address so users may contact you if need be.

 Syntax:
A:A little info about your server:Admin's nick/real name:contact address
 There is no fixed standard, so you may put whatever you like in each
 field, but you should put enough information for users to contact someone
 responsible for the server.

 Example:
A:Disney's DALnet IRC Server:Admin - Walt Disney:walt@RIP.org

                        --------------------

3.3) Y Lines: [SUGGESTED]

 These lines define connection classes. They allow you to fine-tune
 your incomming and outgoing connections, both server and client types.
 These classes are for use with C, N, I and O lines, more on this in later
 sections. DALnet has a set of Y lines that each server must use for their
 server connections, these are listed below and again at the bottom of this
 document. Client connection classes are your responsibility, you must
 make up your own set of Y lines for client connections based on your own
 situation (netwise location, machine, etc).
 Connection classes define a number of parameters for connections, these
 include:
  o Ping frequency of a silent connection.
  o Connect frequency (servers)
  o Maximum number of links allowed on the specific connection class.
  o Maximum sendq allowed for the connection before it is dropped.
  o Maximum number of connections from one host
  o Maximum number of connections from one user@host
 - Ping frequency: When a connection is silent for this period of time
 the server will send a PING to the connection, if the client/server
 on the connection does not reply after a set period of time, the
 connection will be dropped. A value in this field will override the
 ping frequency defined at compile time in your config.h. For server
 connection classes, you should have the same ping frequency on both ends
 of the link, so you should stick with the standard DALnet classes.
 - Connect frequency: Since clients connect to servers and NOT the other
 way around, only server connection classes need to have a connect
 frequency. Client classes should have this field set to 0. When a server
 listed in the server's ircd.conf (see C/N lines) is missing and belongs
 on a conenction class that is holding less connections that defined by
 the max links field, the server will keep on trying to connect to
 the missing server. The ammount time between connection attempts is what
 you define in this field.
  example:
   server1 and server2 are listed in server0's ircd.conf but the only
   visible server to server0 is server1, both server1 and server2 are
   in server0's ircd.conf on the same connection class that allows for `2'
   links, server0 will go looking for server2 and try to connect to
   it each `connect frequency' seconds until the server becomes visible
   again, either by direct connection to server0, or by connection to server1
 - Maximum number of links: Each Y line should have a restriction on the number
 of connections allowed on the class. For client connections, when the limit
 is reached on a particular class, connecting clients trying to connect
 through this class are rejected. A server connecting on a `full' connection
 class will be allowed as this number on server connection classes is used for
 auto-connect purposes. As shown in the above example, when a missing server
 is listed for a particular connection class, and the class is not `full',
 your server will try and connect to this server untill it becomes visible
 again. Servers being connected manually on a `full' connection class via the
 /connect command will be allowed as long as you compiled with MAXIMUM_LINKS
 high enough to accomidate all of your server connections. (you must compile
 as a HUB if you wish to hold more than one server connection, also see H
 lines later in this document).
 - Maximum sendq: SendQ defines the queue of data waiting to be sent to the
 client/server on the other end of the connection. SendQ's will build up if
 the client requests more data than the link can handle, say if they issue the
 /list command on a network with a lot of channels and they are only on a
 14.4K link, their sendq on the server will build up as all the data cannot
 be sent at once, the sendq size will decrease as the data is sent, and
 increase as more data is requested. Clients will normally sit with a sendq of
 0, it is `abnormal' for a sendq to be high for a client for a long period
 of time. When 2 servers connect, they must send their own data to
 eachother, this data includes: all the users on the server and already
 connected servers, channels, user modes, channel modes, topics (DALnet only)
 etc. When there are many clients on a particular side of the connection, a
 sendq will build up, especially if the link is slow, or already congested
 (example: the link from Australia to the US). When the sendq built up reaches
 the max sendq defined in the connection class for the particular
 client/server, the connection will be dropped. If max sendq's are
 particularly high, it will allow clients/server to take up excess memory on
 the ircd machine so a limit should be placed, especially on client connection
 classes. (IMPORTANT!) If any value of max sendq defined in a connection
 class exceeds the value defined at compile time in your config.h, the sendq
 value will default back to the compile time sendq. If your sendq field in
 a Y line is empty, the class will use the default defined in your config.h
 SendQ's for all connections on your server can be viewed with the
  /stats l <servername>
 command, this will show information for all your server's current links.
 You should have a set of standard server connection classes, at least one
 client connection class, and an Operator class. (see relevant parts of this
 document for notes on each of these)
 - Maximum number of connections from one host: Can be used to limit number of
 connecting clones. Value 0 means no checking.
 - Maximum number of connections from one host@host: Can be used to limit
 number of connecting clones from same ident and host.

 Syntax:
Y:#:Ping freq:Connection freq:Max links:Max sendq:Max per host:Max per user

 Examples:
Y:1:90:0:20:10000:3:0
 Clients may only idle for 90 seconds before being pinged by the server.
 The number of clients allowed to use this class is 20.
 Number of connections from one host is limited to 3.
 Clients may only build up a sendq on the server of 10000 bytes.

 These are the standard server Y lines used on DALnet:

# Connecting a hub to a hub
Y:20:10:300:1:3000000:0:0
# Connecting a US hub to a US leaf
Y:30:45:0:0:2000000:0:0
# Connecting a US leaf to a US hub
Y:35:45:20:1:2000000:0:0
# Connecting a US hub to an EU leaf
Y:40:60:0:0:2200000:0:0
# Connecting an EU leaf to a US hub
Y:45:60:20:1:2200000:0:0
# Connecting a US hub to an AU leaf
Y:42:240:0:0:2200000:0:0
# Connecting an AU leaf to a US hub
Y:43:240:60:1:2200000:0:0

                        --------------------

3.4) I Lines: [MANDATORY]

 These lines are the ones initially responsible for letting clients connect
 to your server. So called `client-authorization' lines, they define who
 may connect, and which connection class they will connect through.
 I lines, like C, N and O lines refer back to Y lines, as they allow
 connections, and each connection to ircd needs to be assigned to a
 connection class. If you dont provide a connection class, the connection
 will be governed by the defaults set at compile time in your config.h.
 When a client connects to the server, it gives its own information,
 this information includes username, nick and can include a password, the
 server then goes through its client-authorization rules (I lines) to see
 if the client fits any of the connection criteria.
 The rules for connection on the I lines are read from right to left, so
 if a connection is made, it is made on the right most rule it matches on
 the line. Also, since the ircd.conf is read upside down, the server will
 put the client on the lowest I line matching the client information. This
 means that if the 1st rule the client can connect on matches a connection
 class (Y line) that is `full' (see above), the client will be rejected,
 even if there is a line further up in the file that the client matches on
 that uses a connection class that has room for more clients. This means
 that I lines may be used in much the same fashion as K lines (see later)
 to block certain clients. It also means that you may place certain clients
 on many different connection classes. (examples later)

 Syntax:
I:IP-address-mask:optional password:host/domain-mask::connection class (opt)
 Wildcards (`*') may be used in the mask fields (1 and 3) to allow for
 very broad connection rules. Also in field 1 you can use x.x.x.x/n where
 n is netmask (from 0 to 32). Ident (for more information on this, see
 rfc1413) can also be used by placing an `@' in the mask fields in the
 appropriate positions. If you don't want to use ident, only give the
 host/IP part of the connecting addresses, if you add a @ (usually used
 as *@), ircd will try and use ident to check the real username of the
 client, any connecting clients on host's that are running ident that
 give usernames that dont match those found by ircd will be rejected by
 the server. If the host is not running ident, a `~' will be placed in
 front of the username of the connecting client to show that the its
 host isnt running ident.

 Examples:

I:*@*:foobar:*@*::1
 This line will allow anyone from any host that uses the password
 "foobar" to connect through connection class 1 (Y line 1), the server
 will also try and use ident to verify the username of the client.
 Placed at the top of the I lines in your ircd.conf, this line may serve
 as a fall-through for connecting clients, any client that does not match
 any other I line but gives the password "foobar" will be able to connect
 through this line (If Y line 1 has space).

I:212.67.16.0/20::::1
 This allow connect users from specific ISP address range from 212.67.16.0 to
 212.67.31.255.

I:205.133.*::*.toledolink.com::1
 This is a standard vanilla I: line which will permit anyone with an IP
 address starting with 205.133 OR with a hostname ending in
 .toledolink.com to connect to the server. remember, ircd uses the
 right-most match, so if I connect as rmiller@glass.toledolink.com
 (which is rmiller@205.133.127.8) I will show up on irc as
 rmiller@glass.toledolink.com since that is the first match it found.
 (Even though the second match is valid). Any clients comming through
 on this line will use connection class 1.

 Bulk example:
I:::*::1
I:::*.fr::2
I:::*.de::3
I:::*.se::4
I:::*.au::5
I:129.180.*::*.une.edu.au::6
 In this example, conencting clients will 1st be matched against the mask
 *.une.edu.au, if they match they will be placed on connection class 6
 (note: if 6 is full, they will be rejected, they wont be passed on to the
 next I line), then tried against the IP 129.180.*, if they match, they will
 be placed on class 6. If the client dosen't match either of these masks, they
 will be tried against the mask *.au, so if they are from Australia, but are
 not from *.une.edu.au they will be placed on class 5. This goes on through
 the other lines, being placed on the various connection classes if they match
 any of the indicated host masks, if the client is not from the IP 129.180.*,
 Australia, Sweden, Germany or France, they will be connected through the
 final (top) I line as it serves as a fall-through, so these clients will be
 put on class 1.

                        --------------------

3.5) O Lines: [OPTIONAL]

 These lines provide rules as to who may gain Operator status on your server.
 O lines are much like I lines in their operation and syntax.
 Servers need not have any Operators as ircd, given well defined connection's
 can perform all of its functions automatically. Server admins have the
 ability to `kill -HUP' the server's PID to rehash the config file, removing
 the need to use the /rehash command. However, a well running network such as
 DALnet needs operators to oversee the users of the server, and make sure
 users actually enjoy their time on IRC without being continually harrased
 etc by troublematers.
 O lines come in two forms, normal `O' lines, and Local Operator `o' lines.
 Normal O lines give users power over the whole network, to use commands
 such as /kill, local Operators only have power on their local server, that
 is, the server where they can use the /oper command to make themselves +o.
 Abilities of Operators and Local Operators can be defined in your config.h.
 When a user issues the /oper command to the server, the server will search
 through all listed O lines for a match of the user's mask, much the same way
 as I lines. As with I lines, you may specify the use of ident by placing an
 `@' in the appropriate positions.

 Syntax:

O:hostname:password:nickname:flags:class
 See I lines for rules about the hostname and using ident.
 If you use ident, a client matching the hostname must have ident running on
 their host to be able to +o themselves.
 If you compiled defining oper passwords to be crypted, you must 1st crypt
 the plaintext using mkpasswd, a program supplied with the ircd distribution.
 See src/crypt/README for more information on this.
 The nickname is the nickname they must pass with the /oper command
  ie:
   /oper <nickname> <password>
 The class is the connection class to be used when the user /oper's using
 the O line, they connect using the standard I -- Y lines, but when they
 /oper succusfully they are passed across to the new Y line.
 Available flags:
   * a  - Server Administrator
   * o  - IRC Operator
   * O  - Local Operator
 Server Administrator can RESTART and DIE server.
 IRC Operator can do all other tasks.
 Local Operator can do same as IRC Operator, but only for his server.

 Examples:

O:rip.org:waltspass:Walt:ao:10
 This line will allow anyone on the host RIP.org (running ident or not) to
 issue the command `/oper Walt waltspass', at which point they will be moved
 over to class 10 and be made usermode +o.

                        --------------------

3.6) N and C Lines [NETWORKED]

 These lines are always used in pairs, one will not work without the other.
 C lines define who your server may connect to, while N lines define what
 servers may connect to you.
 When two servers connect, they both send eachother the `SERVER' command,
 this command contains the server name and server info (set by M lines)
 along with this command is sent a password with the PASS command, C and N
 lines provide a set of rules governing the connection between servers
 given the details of the server and pass command's.
 When one a server initiates the connection, the other server will check
 the details of the incomming server against its N lines, if a match is
 found, the server will return the server and pass command's to the
 initiating server, which will also check its N lines for a match.
 For a server to initiate a connection, it must have a C line. C lines
 tell the server where to go to make the connection and what to send for
 the pass command.
 What this all means is that for two servers to make a complete connection,
 they must have both C and N lines to refer to for the other server.

 Syntax:
N:remote server's IP:password:remote server's name::class
C:remote server's IP:password:remote server's name:port:class
 For now in C/N 1st field you can only use IP. You can put here wildcards or
 even x.x.x.x/b mask if you want (see I-Lines for more specific info).
 The remote server's IP should be the location on the internet that
 the server can be found. IP addresses are prefered as they are more secure,
 and can be a little quicker for the server. As with I and O lines, ident
 can be used with this 1st field to specify the username the ircd on the
 remote server is running from (if the remote server is running ident), to
 use ident with C/N lines, place the username with an @ before the hostname.
 The password should be crypted if you compile ircd specifying that link
 passwords should be crypted. Your link passwords should be very secure, as
 they provide more power, if hacked, than Operator passwords do. However
 crypted link passwords can be very akward to keep track of.
 Your C line password is the password used in the pass command, while your
 N line password will be used to check against the pass command used by
 incomming servers. So, your C line password should match the listed
 server's N line password, and your N line password should match their C
 line password.
 If you compile your ircd specifying crypted link passwords, you only need
 to crypt your N line passwords, use the same method as with O line
 passwords. If you crypt your C line passwords, your link will not work!
 Crypted passwords are a one sided affair, because one server crypts its
 N line passwords does not mean the connecting servers must crypt their
 C line passwords for that server.
 For the 3rd field, the remote servers `name' should be used, this name is
 the one given in that servers M line (see above). This name will be sent
 with the SERVER command, so it must match the one given. The C and N line
 pair should have the same name for this field.
 The 4th field of C lines may contain the remote servers connection port.
 Even though DALnet runs all its servers with a standard port 7000 open,
 server -- server connections should be taken place through port 7325. It is
 not mandatory that you place a port number in this field. If you don't give
 a port number, the server will not try and autoconnect to the listed
 server. If you do give a port number, the server will only try and
 autoconnect to the listed server if there is enough room on the connection
 class listed at the end of the C line (connection classes are covered in
 more detail above, under Y lines), and the listed server is not visible
 (ie: it is not connected to the network). If you don't give a port number,
 any /connect commands for this C line will use the default port specified
 in your config.h unless a port is given with the command. If you do put a
 port number, any /connect command's will use this port unless another port
 number is given with the command.
 The 5th (last) field of both C and N lines gives the connection class to
 place the connection on. If your C line has a 42 in this field, and your
 server initiates a connection through this line, the connection will be
 placed on class 42, however, if You have a 42 in your C line and a 43 in
 your N line and an incomming server initiates a connection via this N
 line, the server connection will be placed on class 43.

 Examples:
N:212.127.*:password:our.lan.server::35
C:212.127.*:password:our.lan.server::35
 This is great for in-dial servers ;) In C and N line you must specify
 range of possible IPs.

N:212.127.0.0/16:password:our.lan.server::35
C:212.127.0.0/16:password:our.lan.server::35
 Same as above but using x.x.x.x/b masking.

N:143.53.233.32:yourpass:somewhere.fr.dal.net::35
C:143.53.233.32:mypass:somewhere.fr.dal.net:7325:35
 This set will allow a server named somewhere.fr.dal.net to connect to your
 server if it has the IP address of 143.53.233.32 and gives a password of
 `yourpass'. This connection will be governed by connection class 35.
 If your server recieves the command /connect somewhere.*, it will try and
 connect to the IP 143.53.233.32 through port 7325 and give the password
 `mypass'.

                        --------------------

3.7) K Lines [OPTIONAL]

 These lines restric access to certain users to your server based on
 user@host matches and time of the day.
 K lines can come in 3 forms, only one of which you can specify in your
 ircd.conf, this type will show up as K on /stats k, the other other types
 are `AutoKill' which will show up as A on /stats k, and `kline' which will
 show up as k on /stats k. AutoKill's are set by U lined servers (see
 above), they act in the same way as K lines except that they are set
 remotly and are usually set on all servers, they dissapear when you
 /rehash or restart your server. klines are set via the /kline command,
 they operate more like AutoKill's than K lines because they also dissapear
 when you /rehash, or restart the server. The /kline command can be used on
 nicknames that appear on IRC, or you can use a user@host mask. If the
 /kline is done on an existing nickname, a kline will be set with that users
 mask and they will be killed off the server.

 Syntax:
K:hostmask:comment:username
 The hostmask is the host that the user will have on IRC, this may be an
 IP address or a standard host name. The comment field may either
 contain nothing or a comment.
 The username will be the username that shows up on IRC.
 Wildcards (`*', `?') may be used with K lines in both the hostmask and
 username fields. Also in 1st field you can use x.x.x.x/b masking.

 Examples:
K:RIP.org::walt
 This will reject any user who appears as `walt@RIP.org'.

K:217.78.80.0/20::*
 This will reject any user from specified IP range.

K:*::*rad
 This K line will reject anyone with the username `rad', or anything ending
 in `rad'. This ban will dissalow anyone using `rad' running ident or not.
 You must always take into account the ident character (`~') that is placed
 infront of usernames when their host is not running ident. If you place a
 K line on a username `rad' the user will be banned only if they are running
 ident, but if this user can turn off ident they can appear as ~rad, this
 will allow them to bypass any ban of username `rad'. So, wildcards should
 be used with usernames to take into account the ability to turn ident on
 and off. (The ability to change usernames can only be tackled with a `*'
 in the username field)

                        --------------------

3.8) Q lines (nickname form) [OPTIONAL]

 Nickname form Q lines have the ability to deny certain nicknames to users.
 If a nickname is Q lined, the only people allowed to use those nicknames
 are Operators. Q lines, like most other things in your ircd.conf, are local
 only, for a nickname to be Q lined on a whole network all servers must have
 a Q line for that nick. Q lines may also contain comments, these comments
 are given to the user when they attempt to use the nickname and are asked
 to choose another.

 Syntax:
Q:*:reason why nick is quarantined:nickname
 The 1st field is currently unused. The 2nd field is the comment sent to any
 user attempting to use the nickname. Unlike K lines, you may use spaces.
 The last field is the nickname to be quarantined, this nickname may contain
 wildcards.

 Examples:
Q::No nicknames on MY server!:*
 This Q line will dissalow any nicknames on the server giving the reason:
  No nicknames on MY server!
 Only Operators will be allowed to use any nicknames, but since you must be
 a user before you can be +o, you will effectivly ban everyone from your
 server.

Q::Do not use the Lords name in vain!:God
 Anyone attempting to use the nickname `God' on your server will be told
 that they must find a new nickname and will be given the reason:
  Do not use the Lords name in vain!

 DALnet has a set of standard Q lines that should be in place on all
 server's. They are as follows:

Q::Reserved for services:*Chan*S*rv*
Q::Reserved for services:*Nick*S*rv*
Q::Reserved for services:*Memo*S*rv
Q::Reserved for services:*Oper*S*rv*
Q::Reserved for services:*Help*S*rv*
Q::Reserved for operators:DALnet
Q::Reserved for operators:IRC*op*
Q::Causes problems with mIRC:Status

                        --------------------

3.9) L Lines [OPTIONAL/NETWORKED]

 These lines specify which servers are to behave as leaves, that is,
 servers that may not have any other servers connected to them.
 They will only be usefull if your server is a non-leaf (hub) server.
 Not only can you limit servers to leaves, but you can also specify
 what tree depth may appear after certain servers. If a server connects
 but tells your server that it has a larger tree depth behind it than is
 allowed via your L line for the server, the server will be rejected.
 A limit of `0' will mean the server may only be a leaf. A limit of `1'
 will mean that only leaf servers may be connected to the L lined server
 when it is connected to your server.
 You may also use L lines to restrict what servers may connect to certain
 servers while they are connected to your server.

 Syntax:
L:hostmask of disallowed servers:*:server name:depth
 The 1st field defines the limitations on servers allowed to connect to
 the L lined server by hostmask. If any server connects to the L lined
 server while it is connected to your server, and it's name matches the
 hostmask given here, it will be rejected. Wildcards are allowed. You do not
 need to put a value in this field.
 The 2nd field is currently unused and should be left blank.
 The 3rd field is the name of the server to be L lined, when this server
 connects to your server, the restrictions defined by the L line are placed
 on this server. Wildcards are allowed.
 The 4th field defines the depth of servers allowed to be connected behind
 the L lined server.

 Examples:
L:::leaf.de.dal.net
 This line will allow a server named `leaf.de.dal.net' to connect only as
 a leaf. So this server may not connect any other servers behind it.

L:::semi-hub.sg.dal.net:1
 This line will force the server named `semi-hub.sg.dal.net' to allow only
 leaf servers to connect behind it. ie: to have a tree depth of 1.

L:*.us.dal.net::*.au.dal.net
L:*.eu.dal.net::*.au.dal.net
 These lines will make sure that any server with a name matching
 *.au.dal.net will not introduce any servers matching *.us.dal.net or
 *.eu.dal.net. This can be usefull for stopping certain hubs from letting
 its autoconnects route the network badly.

                        --------------------

3.10) H Lines [OPTIONAL/NETWORKED]

 These lines are similar to L lines, except that they define what servers
 may act as a hub while connected to you. That is, which servers may
 introduce other servers behind them.
 You may limit what servers may be connected behind the H lined server.

 Syntax:
H:servers which are allowed behind the hub:*:hub servername
 The 1st field defines what servernames the H lined server is allowed to
 introduce. Wildcards are allowed.
 The 2nd field is currently unused and should be left blank.
 The 3rd field should be the exact name of the server allowed to be a hub
 while connected to you. You may not use wildcards with this field unless
 the server's name includes a `*' (See N lines for host masking).

 Examples:
H:*::dal-hub.us.dal.net
 This line will allow the server with the name `dal-hub.us.dal.net' to act
 as a hub server while you are connected to it, there are no restrictions
 on the names of the servers it may introduce.

H:*.us.dal.net::usa-hub.us.dal.net
 This line will allow the server named `usa-hub.us.dal.net' to act as a hub
 while your server is connected to it, but it is limited to introducing
 servers with names matching `*.us.dal.net', so any servers trying to
 connect to `usa-hub.us.dal.net' with a name such as `bad-link.nz.dal.net'
 will be rejected by your server.

                        --------------------

3.11) P lines [OPTIONAL]

 These lines will open up ports other than the port you specified in your
 config.h when you compiled your ircd.
 Using internet domain ports below 1024 mean that you must run ircd from
 inetd. ircd can listen to ports in the UNIX domain as well as the internet
 domain. With UNIX domain ports you must give a unix socket file, you must
 also compile ircd with UNIXPORT defined in your config.h.
 You may limit usage of ports in the internet domain to certain hostmasks.
 You do not need to provide a P line for the default port you defined in
 your config.h, only extra ports you wish to open. You should compile ircd
 to run from port 7000, but it is recomended that you add a P line for port
 6667 as most IRC clients default to this port when connecting. If you are
 connected to DALnet, you should have a P line for port 7325, this is the
 standard server connection port for all DALnet servers.

 Syntax:
P:IP or UNIX socket file:*:*:port number
 The 1st field should either specify a path to a UNIX socket file, or give
 a hostmask to match against connecting clients on this port. Clients not
 matching this mask will be rejected.
 The 2nd and 3rd field's are currently unused, and should be left blank.
 The last field is the port number to open up and listen to for connections.

 Examples:
P:*:::7325
 This will open up the DALnet server connection port and wait for
 connections. This line is mandatory if you run a server connected to DALnet

P:143.53.233.32:::6665
 This line will open up port 6665 at 143.53.233.32 and wait for connections.

P:/tmp/.ircd:*:*:6666
 This line will open up the port 6666 in the UNIX domain, with a socket file
 of: /tmp/.ircd.

                        --------------------

3.12) V lines [OPTIONAL]

 These lines can be used to spoof HOSTNAMEs. But not only. V lines can be
 used like nice DNS resolver for IRCd.

 Syntax:
V:ip:first part of hostname:rest of hostname
 The 1st field should be exacly IP (a.b.c.d) or last part can be wildcard
 (a.b.c.*). Other choice is to use x.x.x.x/b masking that can specify very
 wide IP range.
 The 2nd field should be empty if you are using exact IP matching, otherwise
 you can put here part of hostname. If you leave this field empty, server
 automaticly add "pc" to domain.
 The 3rd field contain full hostname (if exact IP mathcing) or rest of
 hostname.

 Examples:
V:192.168.0.4::borg88.lan
 This line changes hostname to borg88.lan of user connected from
 192.168.0.4 host.

V:192.168.1.*::lan
 This line changes hostnames to pc<last ip>.lan of users matching this IP
 mask. eg: (192.168.0.3 -> pc3.lan)

V:192.168.1.*:comp:lan
 Same as above but word "pc" is changed to "comp"

V:192.168.0.0/16::corp.lan
 This change hostname for entire LAN IP range.

                        --------------------

4) Summary:

 Well, thats it for the lines you may use in your ircd.conf. Remember that
ircd.conf is an art, just like any other type of programming. Some parts
are particularly easy, but other's, like Y lines, can take a while to get
used to. Given a little time experementing with lines on a network of
servers, you will become well versed in ircd.conf programming.

Good luck!

                        --------------------