+<div align="justify">
+<h3><a name="Overview_"></a>Overview</h3>
+<p>Citadel, when installed properly, will do most of its maintenance
+by itself. It is intended to be run unattended for extended periods of
+time, and most installations do just that without any software failures.</p>
+<p>The system has seven access levels. Most users are at the bottom and
+have
+no special privileges. Aides are selected people who have special
+access within
+the Citadel program. Room Aides only have this access in a certain
+room. Preferred users can be selected by Aides for access to preferred
+only rooms. A sysop is anyone who has access to the various sysop
+utilities - these
+are in their own executable files, which should have their permissions
+set
+to allow only sysops to run them. You should either create a sysops
+group
+in /etc/group, or use some other existing group for this purpose.</p>
+<p>Aides have access to EVERY room on the system, public and private
+(all types). They also have access to commands starting with <tt>.<b>A</b>ide</tt>
+in addition to being able to delete and move messages. The system room,
+<tt>Aide></tt>, is accessible only by those users designated as
+Aides.</p>
+<h3><a name="Aide_commands"></a>Aide commands</h3>
+<p>Aides have the following commands available to them that are not
+available to normal users. They are:</p>
+<table>
+ <tbody>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>K</b>ill this room </tt></td>
+ <td> Deletes the current room from the system. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>E</b>dit this room </tt></td>
+ <td> Allows editing of the properties of the current room. This
+is explained in greater detail below. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>W</b>ho knows room </tt></td>
+ <td> For private rooms with access controls, or mailbox rooms,
+this command displays a list of users who have access to the current
+room. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide edit <b>U</b>ser </tt></td>
+ <td> Allows editing of the properties of any user account
+on the system. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>V</b>alidate new users </tt></td>
+ <td> For public access systems, this command reviews all new user
+registrations and allows you to set each new user's access level (or
+simply delete the accounts). </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide enter <b>I</b>nfo file </tt></td>
+ <td> Each room may contain a short textual description of
+its purpose, which is displayed to users upon entering the room for the
+first time (or in the room banner, for users of the Web client). This
+command allows you to enter or edit that description. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>R</b>oom <b>I</b>nvite
+user </tt></td>
+ <td> Access control command to grant any specific user access to
+a private room. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>R</b>oom <b>K</b>ick
+out user </tt></td>
+ <td> Access control command to revoke any specifc user's access
+to the current room. This works regardless of whether the room is
+public or private. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>F</b>ile <b>D</b>elete </tt></td>
+ <td> If the current room has an associated file directory, this
+command may be used to delete files from it. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>F</b>ile <b>S</b>end
+over net </tt></td>
+ <td> If the current room has an associated file directory, this
+command may be used to transmit a copy of any file in that directory to
+another node on a Citadel network. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>F</b>ile <b>M</b>ove </tt></td>
+ <td> If the current room has an associated file directory, this
+command may be used to move any file in that directory to another room.
+The target room must also have an associated file directory. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>M</b>essage edit </tt></td>
+ <td> This command allows editing of any of the various system
+banners and messages which are displayed to users. Type the name of
+the banner or message you wish to edit. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>P</b>ost </tt></td>
+ <td> This is the functional equivalent of the <tt><b>E</b>nter
+message</tt> command available to all users, except that it allows you
+to post using any user name. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>S</b>ystem configuration <b>G</b>eneral
+ </tt></td>
+ <td> This command allows configuration of a large number of
+global settings for your Citadel system. These settings will be
+explained in greater detail below. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>S</b>ystem configuration <b>I</b>nternet
+ </tt></td>
+ <td> This command allows configuration of settings which affect
+how your Citadel system sends and receives messages on the Internet. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>S</b>ystem configuration
+check <b>M</b>essage base </tt></td>
+ <td> Perform a consistency check on your message store. This is a
+very time-consuming operation which should not be performed unless you
+have reason to believe there is trouble with your database. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>S</b>ystem configuration <b>N</b>etwork
+ </tt></td>
+ <td> Configure networking (e-mail, room sharing, etc.) with other
+Citadel nodes. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>S</b>ystem configuration
+network <b>F</b>ilter list </tt></td>
+ <td> If you are on a large public or semi-public network of
+Citadel nodes and you find content from certain systems or individuals
+objectionable, you can use this command to define a rule set to
+automatically reject those messages when they arrive on your system. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>T</b>erminate server <b>N</b>ow
+ </tt></td>
+ <td> Immediately shut down the Citadel service, disconnecting any
+users who are logged in. Please keep in mind that it will start
+right back up again if you are running the service from <tt>/etc/inittab</tt>,
+so in practice this command will probably not get much use. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>T</b>erminate server <b>S</b>cheduled
+ </tt></td>
+ <td> Shut down the Citadel service the next time there are zero
+users connected. This allows you to automatically wait until all users
+are logged out. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide mailing <b>L</b>ist recipients
+ </tt></td>
+ <td> Any room may be made into a mailing list. Enter this command
+to open an editor window containing the list of Internet e-mail
+addresses to which every message posted in the room will be sent. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide mailing list <b>D</b>igest
+recipients </tt></td>
+ <td> Similar to the regular mailing list command, except the
+messages will be sent out in 'digest' form -- recipients will see
+messages from the address of the room itself rather than the address of
+the author of each message, and a digest may contain more than one
+message. Each room may have any combination of List and Digest
+recipients. </td>
+ </tr>
+ <tr>
+ <td width="30%"><tt> .<b>A</b>ide <b>N</b>etwork room sharing </tt></td>
+ <td> Configures the sharing of the current room's contents with
+other Citadel nodes. Messages posted in this room on any Citadel system
+will automatically be replicated to other Citadel systems carrying the
+room. </td>
+ </tr>
+ </tbody>
+</table>
+<br>
+<br>
+<h3><a name="Editing_rooms"></a>Editing rooms</h3>
+<p>This command allows any aide to change the parameters of a room. Go
+to the room you wish to edit and enter the <tt><b>.A</b>ide <b>E</b>dit
+room</tt> command. A series of prompts will be displayed. The existing
+parameters will be displayed in brackets; simply press return if you
+want
+to leave any or all of them unchanged.</p>
+<pre> <br>Room name [IG's Fun Room]:<br></pre>
+<p>...the name of the room.</p>
+<pre>Private room [Yes]? <br></pre>
+<p>...enter Yes if you wish to restrict access to the room, or no if
+the room
+is to be accessible by all users. Note that Citadel doesn't bother
+users
+about access to rooms every time they need to access the room. Once a
+user
+gains access to a private room, it then behaves like a public room to
+them.
+The following four questions will only be asked if you selected
+Private...</p>
+<pre>Accessible by guessing room name [No]?<br></pre>
+<p>...if you enter Yes, the room will not show up in users' <tt><b>K</b>nown
+rooms</tt> listing, but if they <tt><b>.G</b>oto</tt> the room (typing
+the room's full name), they will gain access to the room.</p>
+<pre>Accessible by entering a password [No]?<br>Room password [mypasswd]: <br></pre>
+<p>...this adds an additional layer of security to the room, prompting
+users for a password before they can gain access to the room.</p>
+<p>If you did not select guessname or passworded, then the only way
+users can access the room is if an Aide explicitly invites them to the
+room using the <tt><b>.A</b>ide <b>R</b>oom <b>I</b>nvite user</tt>
+command.</p>
+<pre>Cause current users to forget room [No] ? No<br></pre>
+<p>Enter Yes if you wish to kick out anyone who currently has access to
+the room.</p>
+<pre>Preferred users only [No]? No<br></pre>
+<p>Enter Yes if you wish to restrict the room to only users who have
+level 5 (Preferred User) status (and Aides too, of course). You should
+make the room public if you intend to do this, otherwise the two
+restrictions will be COMBINED.</p>
+<pre>Read-only room [No]? No<br></pre>
+<p>If you set a room to Read-Only, then normal users will not be
+allowed to
+post messages in it. Messages may only be posted by Aides, and by
+utility programs such as the networker and the "aidepost" utility. This
+is
+useful in situations where a room is used exclusively for important
+announcements, or if you've set up a room to receive an Internet
+mailing
+list and posting wouldn't make sense. Other uses will, of course,
+become
+apparent as the need arises.</p>
+<p>Now for a few other attributes...</p>
+<pre>Directory room [Yes]? Yes<br></pre>
+<p>...enter Yes if you wish to associate a directory with this room.
+This can be used as a small file repository for files relevant to the
+topic of the room. If you enter Yes, you will also be prompted with the
+following four questions:</p>
+<pre>Directory name [mydirname]: <br></pre>
+<p>...the name of the subdirectory to put this room's files in. The
+name of the directory created will be <tt><i><your Citadel
+directory></i>/files/<i><room dir name></i></tt>.</p>
+<pre>Uploading allowed [Yes]? Yes<br></pre>
+<p>...enter Yes if users are allowed to upload to this room.</p>
+<pre>Downloading allowed [Yes]? Yes<br></pre>
+<p>...enter Yes if users are allowed to download from this room.</p>
+<pre>Visible directory [Yes]? Yes<br></pre>
+<p>...enter Yes if users can read the directory of this room.</p>
+<pre>Network shared room [No]? No<br></pre>
+<p>...you can share a room over a network without setting this flag,
+and
+vice versa, but what this flag does is twofold: </p>
+<ul>
+ <li>It prevents people with no network access from entering messages
+here </li>
+ <li>Messages are displayed with the name of their originating
+system in the header. </li>
+</ul>
+<pre>Permanent room [No]? No<br></pre>
+<p>Citadel contains an 'auto purger' which is capable of removing rooms
+which have not been posted in for a pre-defined period of time (by
+default
+this is set to two weeks). If you wish to keep this from happening to
+a particular room, you can set this option. (Keep in mind that <tt>Lobby></tt>,
+<tt>Aide></tt>, any private mailbox rooms, any network shared rooms,
+and any rooms with a file directory are automatically permanent.)</p>
+<pre>Anonymous messages [No]? No<br>Ask users whether to make messages anonymous [No]? No<br></pre>
+<p>...you can have rooms in which all messages are automatically
+anonymous, and you can have rooms in which users are prompted whether
+to make a
+message anonymous when they enter it. The real identity of the author
+of each message is still revealed to the Room Aide for this room, as
+well
+as any system-wide Aides.</p>
+<pre>Room aide [Joe Responsible]: <br></pre>
+<p>...on larger systems, it helps to designate a person to be
+responsible for a room. Room Aides have access to a restricted set of
+Aide commands, ONLY when they are in the room in which they have this
+privilege. They can edit the room, delete the room, delete and move
+messages, and invite or kick out users (if it is a private room), but
+they cannot perform aide commands that are not room-related (such as
+changing users access levels).</p>
+<pre>Listing order [64]: <br></pre>
+<p>This is just a simple way to try to control the order rooms are
+listed in when users call up a <tt><b>K</b>nown Rooms</tt> listing.
+Rooms with a lower listing order are displayed prior to rooms with a
+higher listing order. It has no other effect. For users who list rooms
+in floor order, the display will sort first by floor, then by listing
+order.</p>
+<pre>Message expire policy (? for list) [0]:<br></pre>
+<p>This provides you with the opportunity to select how long each
+message will remain in a room before automatically being deleted. Press
+<tt><b>?</b></tt> for a list of options. You can choose to keep
+messages around forever (or until they are manually deleted), until
+they become a certain number of days old, or until a certain number of
+additional messages are posted in the room, at which time the oldest
+ones will scroll out.</p>
+<p>When a new Citadel system is first installed, the default
+system-wide
+expire policy is set to 'manual' -- no automatic purging of messages
+takes place anywhere. For public message boards, you will probably want
+to set some sort of automatic expire policy, in order to prevent your
+message base from growing forever.</p>
+<p>You will notice that you can also fall back to the default expire
+policy for the floor upon which the room resides. This is the default
+setting. You can change the floor's default with the <tt><b>;A</b>ide <b>E</b>dit
+floor</tt> command. The default setting for the floor default, in turn,
+is the system default setting, which can be changed using the <tt><b>.A</b>ide
+<b>S</b>ystem configuration <b>G</b>eneral</tt> command.</p>
+<pre>Save changes (y/n)? Yes<br></pre>
+<p>...this gives you an opportunity to back out, if you feel you really
+messed things up while editing.<br>
+<br>
+</p>
+<h3><a name="File_directories"></a>File directories</h3>
+<p>If you have created any directory rooms, you can attach file
+descriptions to the filenames through a special file called <tt>filedir</tt>.
+Each line contains the name of a file in the directory, followed by a
+space and then a description of the file, such as:</p>
+<pre>myfile.txt This is a description of my file.<br>phluff A phile phull of phluff!<br></pre>
+<p>...this would create file descriptions for the files <tt>myfile.txt</tt>
+and <tt>phluff</tt> which would be displayed along with the directory.
+It should also be noted that when users upload files to your system,
+they will be prompted for file descriptions, which will be added to the
+<tt>filedir</tt> file. If one does not exist, it will be created.<br>
+<br>
+</p>
+<h3><a name="Creating_and_editing_user_accounts"></a>Creating and
+editing user accounts</h3>
+<p>Anyone with Aide level access may use the <tt><b>.A</b>ide edit <b>U</b>ser</tt>
+command to create and/or edit user accounts. There are several
+parameters which can be set here.</p>
+<p>To create a user:</p>
+<pre>Lobby> . Aide edit User <br>User name: New User Name<br>No such user.<br>Do you want to create this user? Yes<br></pre>
+<p>At this point, the new user account has been created, and the
+command will
+continue as if you were editing an existing account. Therefore the
+remainder
+of this procedure is the same for creating and editing:</p>
+<pre>Lobby> . Aide edit User <br>User name: person of significance<br>User #70 - Person of Significance PW: <br><br>,<br><br>Current access level: 4 (Network User)<br></pre>
+<p>The blank lines are the user's 'registration' information --
+personal
+information such as full name, address, telephone number, etc. This
+information
+will comprise the user's vCard in both their user profile and in the
+Global
+Address Book.</p>
+<pre>Change password [No]: No<br></pre>
+<p>...answer Yes to set or change the password for this account.</p>
+<pre>Access level [4]: <br></pre>
+<p>...this allows you to set or change the access level for this
+account. The access levels available are as follows: </p>
+<ul>
+ <li>0 - Deleted. (This immediately deletes the account.) </li>
+ <li>1 - New, unvalidated user </li>
+ <li>2 - Problem user (severely restricts account - use for
+probationary access) </li>
+ <li>3 - User with no network privileges. Same access as a normal user
+except cannot post messages in rooms shared on a network. </li>
+ <li>4 - Normal user </li>
+ <li>5 - Preferred user (access is granted to privileged rooms) </li>
+ <li>6 - Aide (administrative access to the whole system) </li>
+</ul>
+<pre>Permission to send/receive Internet mail [ No]? No<br></pre>
+<p>If your system is configured to only allow Internet mail privileges
+to certain users, this is where you can grant or revoke that privilege.</p>
+<pre>Ask user to register again [Yes]: Yes<br></pre>
+<p>If you answer Yes to this question, the user will be presented with
+a
+'registration' screen or set of prompts, the next time they log in
+using
+a Citadel client. This will prompt them for their full name, address,
+telephone
+number, etc.</p>
+<pre>Times called [0]: <br>Messages posted [0]: <br></pre>
+<p>These statistics are available for informational purposes only, so
+there is normally no need to change them.</p>
+<pre>Set last call to now [No]: No<br>Purge time (in days, 0 for system default [0]: <br></pre>
+<p>Citadel contains an auto-purger which is capable of automatically
+deleting accounts which have not been accessed in a predefined period
+of time. If you choose to perform this operation, you can 'touch' the
+account
+of a wayward user by setting their 'last call' time to 'now'. You can
+also adjust, on a per-user basis, the amount of time which must pass
+before
+their account is purged by the system. This time is set in days. You
+can also specify 0 days to indicate that you wish to use the system
+default
+setting.<br>
+<br>
+</p>
+<h3><a name="Deleting_and_moving_messages"></a>Deleting and moving
+messages</h3>
+<p>Aides and Room Aides have the ability to delete and move messages.
+After each message, the normal prompt appears:</p>
+<pre>(8) <B>ack <A>gain <Q>uote <R>eply <N>ext <S>top m<Y> next <?>help -><br></pre>
+<p>Entering <tt><b>D</b>elete</tt> will delete the message. A <tt>(y/n)</tt>
+prompt will appear to confirm that you really want to delete the
+message. Entering <tt><b>M</b>ove</tt> will prompt for a room to which
+the message should be moved.<br>
+<br>
+</p>
+<h3><a name="Customizing_the_help_files"></a>Customizing the help files</h3>
+<p>The subdirectory called <tt>help</tt> contains your system's help
+files. There's nothing hard-coded into the system that dictates what
+files
+should be there. Whenever a user types the command <tt><b>.H</b>elp</tt>
+followed by the name of a help file, it displays the contents of that
+help file.</p>
+<p>The help files that come with the system, of course, are enough to
+guide a user through its operation. But you can add, change, or remove
+help files to suit whatever is appropriate for your system.</p>
+<p>There are several strings that you can put in help files that will
+be automatically
+substituted with other strings. They are:</p>
+<pre> <br> ^nodename = The node name of your system on a Citadel network<br> ^humannode = Human-readable node name (also your node name on C86Net)<br> ^fqdn = Your system's fully-qualified domain name<br> ^username = The name of the user reading the help file<br> ^usernum = The user number of the user reading the help file<br> ^sysadm = The name of the system administraor (i.e., you)<br> ^variantname = The name of the software you're running<br> ^bbsdir = The directory on the host system in which you have<br> installed the Citadel system.<br></pre>
+<p>So, for example, you could create a help file which looked like:</p>
+<pre> "Lots of help, of course, is available right here on ^humannode. Of<br>course, if you still have trouble, you could always bug ^sysadm about it!"<br><br></pre>
+<h3><a name="Site_configuration"></a>Site configuration</h3>
+<p>Once your Citadel server is up and running, the first thing you'll
+want to do is customize and tune it. This can be done from the
+text-based client with the <tt><b>.A</b>ide <b>S</b>ystem
+configuration <b>G</b>eneral</tt> command, or from WebCit (if you have
+it installed) by clicking 'Advanced Options' followed by 'Edit
+site-wide configuration.' Either method will offer the same
+configuration options. This document shows the text mode client being
+used.</p>
+<p>The first set of options deal with the identification of your system.</p>
+<pre>Lobby> . Aide System configuration General<br>Node name [uncnsrd]: <br>Fully qualified domain name [uncensored.citadel.org]: <br>Human readable node name [Uncensored]: <br>Modem dialup number [US 914 999 9999]: <br>Geographic location of this system [Mount Kisco, NY]: <br>Name of system administrator [IGnatius T Foobar]: <br>Paginator prompt [<jinkies
+ !="" more="" text="" on="" the="" next="" screen="">]: <br></jinkies></pre>
+<p>'Node name' refers to the short, unqualified node name by which your
+system is known on a Citadel network. Generally it will be the same as
+the unqualified host name of your computer; this is, in fact, the
+default setting.</p>
+<p>Then enter the fully-qualified domain name (FQDN) of your system. If
+you
+are not on the Internet, you can simply set it to the same as your
+unqualified host name. Otherwise you should set this value to the host
+name by which your system is most commonly known.</p>
+<p>The field called 'Human-readable node name' (also known as the 'node
+title' or 'organization name' in other software) is used solely for
+display purposes. Set it to the actual name of your system as you want
+it to appear in
+banners, messages, etc.</p>
+<p>If you have a modem or bank of modems answering data calls for your
+system, enter it in the field marked 'Modem dialup number.' Otherwise
+you may leave it blank.</p>
+<p>'Geographic location of this system' is another display field. Enter
+a city and state, or city and country. </p>
+<p>'Name of system administrator' is important! Any user who logs on
+with the name you enter here will automatically be granted Aide
+privileges. This is one of two ways for the system administrator to
+grant himself/herself Aide access to the system when initially setting
+it up. (The other is simply to have the first account created on a new
+installation.)</p>
+<p>The next set of options are your system's security settings. Before
+delving into the actual options, we should review the various access
+levels available on the system. Citadel has seven access levels:</p>
+<ul>
+ <li>0 (Deleted). A user whose access level is set to 0 will
+automatically be deleted by the system. </li>
+ <li>1 (New User). Users at this level may only read messages.
+Entering messages is prohibited, except in the <tt>Mail></tt> room,
+where a message to 'sysop' may be entered. </li>
+ <li>2 (Problem User). Also known as 'Twit.' </li>
+ <li>3 (Local User). May enter messages, except in rooms shared on a
+Citadel network. </li>
+ <li>4 (Network User). May enter messages in every accessible
+room. </li>
+ <li>5 (Preferred User). Use of this level is up to the whim of the
+system administrator. </li>
+ <li>6 (Aide). Access is granted to the administrative functions of
+the system. (This access level may also be granted to a user only for a
+specific room, please see 'Room Aide' for more information.) </li>
+</ul>
+<pre>Require registration for new users [No]: No<br>Disable self-service user account creation [No]: No<br>Initial access level for new users [4]:<br>Access level required to create rooms [4]: <br>Automatically give room aide privs to a user who creates a private room [No]: No<br><br>Automatically move problem user messages to twit room [Yes]: Yes<br>Name of twit room [Trashcan]: <br>Restrict Internet mail to only those with that privilege [No]: No<br>Allow Aides to Zap (forget) rooms [Yes]: Yes<br>Log all pages [No]: No<br></pre>
+<p>'Registration' refers to the process of a user entering various
+personal contact information (real name, address, telephone number,
+etc.) into the system. When enabled, this information is stored as a
+vCard object on the system in two places: the user's <tt>My Citadel
+Config></tt>
+room, and in the <tt>Global Address Book></tt> room. (Note: the
+latter
+should be made private on publicly-accessible systems, for obvious
+reasons.)</p>
+<p>If you answer Yes to 'Require registration for new users' then each
+new user, upon creating a new account, will immediately be entered into
+the registration process. On the other hand, if you answer Yes to
+'Disable self-service user account creation' then new users will not be
+able to
+log in at all -- all accounts must be created by an Aide.</p>
+<p>'Initial access level for new users' should be set to 1 (New User)
+if you would like to review each new user's registration info before
+granting them higher access. This would be done periodically with the <tt><b>.A</b>ide
+<b>V</b>alidate new users</tt> command. If you do not require
+registration, you should set the initial access level to 4 (Network
+User).</p>
+<p>Given the above options, it then becomes clear that there are
+generally two ways you can set up your Citadel system, depending on its
+purpose:</p>
+<ul>
+ <li><b>A public access BBS or message board</b> - since you do
+not know who might want to log in, self-service account creation needs
+to
+stay enabled. If you want to be strict about users identifying
+themselves,
+then you should also require users to register (just remember to post a
+privacy policy if you're going to collect personal information) -- then
+set
+the initial access level to 1 (New User), so new users cannot post
+messages
+until after you've validated them. For a more lax environment, you can
+remove the registration requirement and grant new accounts level 4
+(Normal
+User) access on the first visit. </li>
+ <li><b>A private email/groupware system for your organization</b> -
+in this case, disable self-service account creation; you don't want
+strangers welcoming themselves to your system. You'll probably also
+want
+to disable registration, because you or some other site administrator
+will be entering users' contact info when you create their accounts.
+Since this is also how you assign their Internet e-mail addresses, it's
+probably a good idea to do it yourself instead of expecting them to do
+it. </li>
+</ul>
+<p>'Access level required to create rooms' is up to you. You might wish
+to
+restrict the creation of new rooms only to Aides, or you might wish to
+allow
+anyone to create a room. The latter is one of the Citadel culture's
+most
+long-standing traditions; the former may be appropriate if users are
+abusing
+this privilege.</p>
+<p>You have the ability to 'Automatically give room aide privs to a
+user who creates a private room.' If you answer Yes, then any user who
+creates a
+guess-name, passworded, or invitation-only room will automatically
+become the room aide, and will have access to a subset of the <tt><b>.A</b>ide</tt>
+command set while in that room. If you would rather grant this
+permission manually, answer No.</p>
+<p>Another tradition in the Citadel culture is to refrain from deleting
+problem users, but instead to 'twit' them (reduce their access level to
+2
+[Problem User]). You can then 'Automatically move problem user messages
+to twit room' (answer Yes, then specify 'Name of twit room' and
+remember
+to create that room). If you employ this logic, any user with level 2
+(Problem
+User) access will continue to have access to the same set of rooms, but
+all
+messages posted will automatically be routed to the Trashcan (or
+whatever
+you call your twit room).</p>
+<p>If you have Internet mail configured, you have the option of
+restricting its use on a user-by-user basis. If you wish to do this,
+answer Yes to 'Restrict Internet mail to only those with that
+privilege.' Obviously this makes no sense for an internal e-mail
+system, but for a public BBS it
+might be appropriate.</p>
+<p>Normally, Aides have access to every room, public or private.
+They are also forbidden from <tt><b>Z</b>ap</tt>ping
+rooms, because the review of content is considered one of their roles.
+If you wish to change these policies, the next two options allow you
+to. You may 'Allow Aides to Zap (forget) rooms', in which case they may
+use the <tt><b>Z</b>ap</tt> command just like any other user.
+Aides may also <tt><b>.G</b>oto</tt> any private mailbox belonging to
+any
+user, using a special room name format.</p>
+<p>If your local security and/or privacy policy dictates that you keep
+a
+log of all pages (instant messages) that go through the system, then
+answer
+Yes to 'Log all pages'. If you answer Yes, you will be prompted for the
+name of a room to which all pages will be logged. If you answer No,
+then
+only the sender and recipient of each individual message will receive a
+copy.</p>
+<p>The next set of options deals with the tuning of your system. It is
+usually safe to leave these untouched.</p>
+<pre>Server connection idle timeout (in seconds) [900]: <br>Maximum concurrent sessions [20]: <br>Maximum message length [10000000]: <br>Minimum number of worker threads [5]: <br>Maximum number of worker threads [256]: <br>Automatically delete committed database logs [Yes]:<br></pre>
+<p>The 'Server connection idle timeout' is for the connection between
+client and server software. It is <b>not</b> an idle timer for the
+user interface. 900 seconds (15 minutes) is the default and a sane
+setting.</p>
+<p>'Maximum concurrent sessions' is the highest number of user sessions
+you wish to allow on your system at any given time. Citadel can scale
+to hundreds of concurrent users, but if you have limited hardware or
+(more likely) limited bandwidth, you might wish to set a maximum. You
+can also set it to zero for no limit.</p>
+<p>'Maximum message length' is just that. This could be a good way to
+prevent enormous multimedia files from finding their way into your
+message base. This maximum is enforced in all protocols and is also
+advertised by the ESMTP service.</p>
+<p>The minimum and maximum number of worker threads can be tuned to
+your liking. Citadel will attempt to keep one worker thread running per
+session, within these constraints. You should be aware that due to the use of
+the worker thread model, Citadel can handle a large number of concurrent
+sessions with a much smaller thread pool. If you don't know the programming
+theory behind multithreaded servers, you should leave these parameters alone.<br>
+</p>
+<p>'Automatically delete committed database logs' is a <span
+ style="font-style: italic;">crucial</span> setting which affects your
+system's disk utilization and backup recoverability. Please refer
+to the <a href="#Database_maintenance">database maintenance</a>
+section of this document to learn how the presence or absence of
+database logs affect your ability to reliably backup your Citadel
+system.<br>
+</p>
+<p>The next set of options affect how Citadel behaves on a network.</p>
+<pre>Server IP address (0.0.0.0 for 'any') [0.0.0.0]:<br>POP3 server port (-1 to disable) [110]:<br>POP3S server port (-1 to disable) [995]:<br>IMAP server port (-1 to disable) [143]:<br>IMAPS server port (-1 to disable) [993]:<br>SMTP MTA server port (-1 to disable) [25]:<br>SMTP MSA server port (-1 to disable) [587]:<br>SMTPS server port (-1 to disable) [465]:<br>Correct forged From: lines during authenticated SMTP [Yes]:<br>Allow unauthenticated SMTP clients to spoof my domains [No]: No<br>Instantly expunge deleted IMAP messages [No]: Yes<br></pre>
+<p>"Server IP address" refers to the IP address on <span
+ style="font-style: italic;">your server</span> to which Citadel's
+protocol services should be bound. Normally you will leave this
+set to 0.0.0.0, which will cause Citadel to listen on all of your
+server's interfaces. However, if you are running multiple
+Citadels on a server with multiple IP addresses, this is where you
+would specify which one to bind this instance of Citadel to.</p>
+<p>Then you can specify TCP port numbers for the SMTP, POP3, and IMAP
+services. For a system being used primarily for Internet e-mail, these
+are essential, so you'll want to specify the standard port numbers: 25,
+110, and 143. If Citadel is running alongside some other mail system,
+though, then you might want to choose other, unused port numbers, or
+enter -1 for any protocol
+to disable it entirely.</p>
+<p>You'll also notice that you can specify two port numbers for SMTP:
+one
+for MTA (Mail Transport Agent) and one for MSA (Mail Submission Agent).
+The
+traditional ports to use for these purposes are 25 and 587. If you are
+running an external MTA, such as Postfix (which submits mail to Citadel
+using
+LMTP) or Sendmail (which submits mail to Citadel using the 'citmail'
+delivery agent), that external MTA will be running on port 25, and you
+should
+specify "-1" for the Citadel MTA port to disable it. The MSA port
+(again,
+usually 587) would be the port used by end-user mail client programs
+such as
+Aethera, Thunderbird, Eudora, or Outlook, to submit mail into the
+system.
+All connections to the MSA port <b>must</b> use Authenticated SMTP.<br>
+</p>
+<p>The protocols ending in "S" (POP3S, IMAPS, and SMTPS) are
+SSL-encrypted. Although all of these protocols support the
+STARTTLS command, older client software sometimes requires connecting
+to "always encrypted" server ports. Usually when you are looking
+at a client program that gives you a choice of "SSL or TLS," the SSL
+option will connect to one of these dedicated ports, while the TLS
+option will connect to the unencrypted port and then issue a STARTTLS
+command to begin encryption. (It is worth noting that this is <span
+ style="font-style: italic;">not</span> the proper use of the acronyms
+SSL and TLS, but that's how they're usually used in many client
+programs.)<br>
+</p>
+<p>All of the default port numbers, including the encrypted ones, are
+the standard ones.<br>
+</p>
+<p>The question about correcting forged From: lines affects how Citadel
+behaves with authenticated SMTP clients. Citadel does not ever allow
+third-party SMTP relaying from unauthenticated clients -- any incoming
+messages must be
+addressed to a user on the system or somewhere in a Citadel network. To
+use Citadel with SMTP client software such as Netscape, Outlook,
+Eudora, or
+whatever, users must log in with a username and password. In order to
+prevent
+message forgeries, Citadel discards the <tt>From:</tt> line in any
+message
+entered by an authenticated user, and replaces it with a <tt>From:</tt>
+line
+containing the user's genuine name and e-mail address. Technically,
+this
+violates RFC822, because headers are never supposed to be altered, but
+common
+sense dictates that this is a good idea. Nevertheless, if you want to
+suppress
+this behavior, answer 'No' at the prompt (the default is 'Yes') and the
+headers
+will never be altered.</p>
+<p>"Instant expunge" affects what happens when IMAP users delete
+messages. As you may already know, messages are not <i>truly</i> deleted
+when an IMAP client sends a delete command; they are only <i>marked for
+deletion</i>. The IMAP client must also send an "expunge" command
+to actually delete the message. The Citadel server automatically expunges
+messages when the client logs out or selects a different folder, but if you
+select the Instant Expunge option, an expunge operation will automatically
+follow any delete operation (and the client will be notified, preventing any
+mailbox state problems). This is a good option to select, for example, if you
+have users who leave their IMAP client software open all the time and are
+wondering why their deleted messages show up again when they log in from a
+different location (such as WebCit).</p>
+<p>"Allow spoofing" refers to the security level applied to
+non-authenticated SMTP clients. Normally, when another host connects to
+Citadel via SMTP to deliver mail, Citadel will reject any attempt to send
+mail whose sender (From) address matches one of your host's own domains. This
+forces your legitimate users to authenticate properly, and prevents foreign
+hosts (such as spammers) from forging mail from your domains. If, however,
+this behavior is creating a problem for you, you can select this option to
+bypass this particular security check.<br>
+<span style="font-family: monospace;"><br>
+Connect this Citadel to an LDAP directory [No]: No</span><br>
+</p>
+<p>The LDAP configuration options are discussed elsewhere in this
+document.<br>
+</p>
+<p>The final set of options configures system-wide defaults for the
+auto-purger:</p>
+<pre>Default user purge time (days) [120]: <br>Default room purge time (days) [30]: <br>System default message expire policy (? for list) [0]: <br>Keep how many messages online? [150]:<br>Mailbox default message expire policy (? for list) [0]:<br>How often to run network jobs (in seconds) [1800]:<br>Enable full text search index (warning: resource intensive) [Yes]: Yes<br>Hour to run purges (0-23) [4]:<br>
+Perform journaling of email messages [No]:<br>Perform journaling of non-email messages [No]:<br>Email destination of journalized messages [example@example.com]:<br></pre>
+<p>Any user who does not log in for the period specified in 'Default
+user purge time' will be deleted the next time a purge is run. This
+setting may be modified on a per-user basis.</p>
+<p>'Default room purge time' behaves the same way, and may also be
+modified on a per-room basis.</p>
+<p>'System default message expire policy' defines the way in which old
+messages are expired (purged) off the system. You can specify any of:</p>
+<ul>
+ <li>Purge by age (specify in days) </li>
+ <li>Purge by message count in the room (specify number of messages) </li>
+ <li>Do not purge at all </li>
+</ul>
+<p>Again, this setting may be overridden on a per-floor basis, and the
+floor setting may be overridden on a per-room basis. You'll also notice
+that you can set a <i>different</i> default for mailbox rooms if you
+want
+to. This can allow you, for example, to set a policy under which old
+messages scroll out of public rooms, but private mail stays online
+indefinitely
+until deleted by the mailbox owners.<br>
+</p>
+<p>"How often to run network jobs" refers to the sharing of content on
+a
+Citadel network. If your system is on a Citadel network, this
+configuration
+item dictates how often the Citadel server will contact other Citadel
+servers to send and receive messages. In reality, this will happen more
+frequently than you specify, because other Citadel servers will be
+contacting yours at regular intervals as well.<br>
+</p>
+<p>"Hour to run purges" determines when expired and/or deleted objects
+are purged from the database. These purge operations are
+typically run overnight and automatically, sometime during whatever
+hour you specify. If your site is much busier at night than
+during the day, you may choose to have the auto-purger run during the
+day.</p>
+<p>"Enable full text search index," if enabled, instructs the server to
+build and maintain a searchable index of all messages on the
+system. This is a time and resource intensive process -- it could
+take days to build the index if you enable it on a large
+database. It is also fairly memory intensive; we do not recommend
+that you enable the index unless your host system has at least 512 MB
+of memory. Once enabled, however, it will be updated
+incrementally
+and will not have any noticeable impact on the interactive response
+time of your system. The full text index is currently only
+searchable when using IMAP clients; other search facilities will be
+made available in the near future.</p>
+<p>The "Perform journaling..." options allow you to configure
+your Citadel server to send an extra copy of every message, along with
+recipient information if applicable, to the email address of your choice.
+The journaling destination address may be an account on the local Citadel
+server, an account on another Citadel server on your network, or an Internet
+email address. These options, used in conjunction with an archiving service,
+allow you to build an archive of all messages which flow through your Citadel
+system. This is typically used for regulatory compliance in industries which
+require such things. Please refer to the <a href="journaling.html">journaling
+guide</a> for more details on this subject.</p>
+<p><span style="font-family: monospace;">Save this configuration? No</span><br>
+</p>
+<p>When you're done, enter 'Yes' to confirm the changes, or 'No' to
+discard the changes.</p>
+</div>
+<hr size="2" width="100%">
+<h2 align="center"><a name="Configuring_Citadel_for_Internet_e-mail"></a>Configuring
+Citadel for Internet e-mail</h2>
+<div align="justify">
+<h3><a name="Introduction"></a>Introduction</h3>
+As you know by now, Citadel is a completely self-contained,
+full-featured Internet e-mail system. When you run Citadel you do
+not need any other mail software on your host system. This
+eliminates the need for tedious mucking about with sendmail, qmail,
+postfix, Cyrus, the UW IMAP
+server, or any of countless other needlessly complex programs that lead
+some people to the false assumption that Unix systems are difficult to
+administer.<br>
+<br>
+Some of the many features supported by Citadel are:<br>
+<ul>
+ <li>Built-in SMTP and ESMTP service, for delivering and receiving
+e-mail on the Internet</li>
+ <li>Built-in POP3 service, for remote fetching of messages</li>
+ <li>Built-in IMAP service, for access to mail using any standard mail
+client program</li>
+ <li>Web mail (implemented using the "WebCit" middleware, which is
+installed separately)</li>
+ <li>Support for mailing lists, in both "individual message" and
+"digest" formats</li>
+ <li>Multiple/virtual domain support</li>
+ <li>Any user may have multiple Internet e-mail addresses, in multiple
+domains</li>
+ <li>Global address book (Users with addresses in a domain may be
+spread out across many servers on a Citadel network)</li>
+ <li>Easy-to-configure integration with <a
+ href="http://www.spamassassin.org/">SpamAssassin</a> can block spam <i>before</i>
+it enters the mail system</li>
+ <li>Easy-to-configure integration with most Realtime Blackhole
+Lists (RBL) provide further defense against spammers</li>
+</ul>
+This section of the documentation will demonstrate how to configure
+these features.<br>
+<br>
+<h3><a name="Basic_site_configuration"></a>Basic site configuration</h3>
+<p>Basic configuration of your Citadel system for Internet e-mail
+begins with
+the <tt><b>.A</b>ide <b>S</b>ystem configuration <b>I</b>nternet</tt>
+command:</p>
+<pre>Lobby> <b>.A</b>ide <b>S</b>ystem configuration <b>I</b>nternet<br><br>### Host or domain Record type<br>--- -------------------------------------------------- --------------------<br> 1<br><A>dd <D>elete <S>ave <Q>uit -><br></pre>
+<p>This is a "clean" setup. For a simple, standalone e-mail system you
+simply have to enter the <tt><b>A</b>dd</tt> command:</p>
+<pre><A>dd <D>elete <S>ave <Q>uit -> <b>A</b>dd<br><br>Enter host name: schmeep.splorph.com<br> (1) localhost (Alias for this computer)<br> (2) gateway domain (Domain for all Citadel systems)<br> (3) smart-host (Forward all outbound mail to this host)<br> (4) directory (Consult the Global Address Book)<br> (5) SpamAssassin (Address of SpamAssassin server)<br> (6) RBL (domain suffix of spam hunting RBL)<br><br>Which one [1]:<br></pre>
+<p><b>localhost:</b> Basically what you're doing here is telling
+Citadel
+what any aliases for your machine are. If your machine were <tt>schmeep.splorph.com</tt>
+and you also had a DNS entry set up for <tt>blah.com</tt>, you might
+want to enter '1' and enter <tt>blah.com</tt> as your alias, so that
+e-mail
+sent to that address won't bounce.</p>
+<p><i>Important tip:</i> if your system is known by one name and <i>only</i>
+one domain, you might not even need to do this at all. You will recall
+that you entered your system's fully qualified domain name earlier when
+you went through the <tt><b>.A</b>ide <b>S</b>ystem configuration <b>G</b>eneral</tt>
+command. The domain name you entered there is automatically considered
+by Citadel to be a 'localhost' entry in your Internet mail
+configuration. It does not hurt to enter it in both locations, though.</p>
+<p><b>gateway domain:</b> this is a simple way of mapping various
+Citadel hosts in an Internet domain. For example, if you enter <tt>bar.com</tt>
+as a gateway domain, then mail to users at <tt>foo.bar.com</tt> will
+be forwarded to the host called <tt>foo</tt> on a Citadel network,
+mail to users
+at <tt>kunst.bar.com</tt> will be delivered to the Citadel server
+called
+<tt>kunst</tt>, etc. This feature has limited usefulness; if you are
+operating
+a network of Citadel servers, it is more likely that you will use the
+'directory'
+feature, explained below.</p>
+<p><b>smart-host:</b> Normally, Citadel sends outbound Internet e-mail
+directly to its destination. This may not be appropriate for some
+sites; you may require (due to local convention, security policy, or
+whatever) that all outbound mail be sent to an SMTP relay or forwarder.
+To configure this
+functionality, simply enter the domain name or IP address of your relay
+as a 'smart-host' entry.</p>
+<p>If your relay server is running on a port other
+than the standard SMTP port 25, you can also specify the port number
+using "host:port" syntax; i.e. <tt>relay99.myisp.com:2525</tt></p>
+<p>Furthermore, if your relay server requires authentication, you can
+specify it using username:password@host or username:password@host:port
+syntax; i.e. <tt>jsmith:pass123@relay99.myisp.com:25</tt></p>
+<p><b>directory:</b> a domain for which you are participating in
+directory services across any number of Citadel nodes. For example, if
+users who have addresses in the domain <tt>citadel.org</tt> are spread
+out across multiple Citadel servers on your network, then enter <tt>citadel.org</tt>
+as a 'directory' entry. <i>For this to work, all Citadel servers
+participating in directory service <b>must</b> carry and share the <tt>Global
+Address Book></tt> room.</i></p>
+<p><b>spamassassin:</b> if you are running a <a
+ href="http://www.spamassassin.org">SpamAssassin</a> service anywhere
+on your
+<b>local</b> network, enter its name or IP address as a 'spamassassin'
+entry. This may be (and, in fact, will usually be) <tt>127.0.0.1</tt>
+to specify
+that the service is running on the same host computer as the Citadel
+server.</p>
+<p>Please install SpamAssassin as per its own documentation. You will
+want to run SpamAssassin in client/server mode, where a <tt>spamd</tt>
+daemon is always running on your computer. Citadel does not utilize the
+<tt>spamc</tt> client; instead, it implements SpamAssassin's protocol
+on its own.</p>
+<p>Connecting to a SpamAssassin service across a wide area network is
+strongly discouraged. In order to determine whether an incoming e-mail
+is spam, Citadel must feed the <i>entire message</i> to the
+SpamAssassin service. Doing this over a wide area network would consume
+time and bandwidth,
+which would affect performance.</p>
+<p>Citadel invokes the SpamAssassin service when incoming messages are
+arriving via SMTP. Before a message is accepted, it is submitted to
+SpamAssassin. If SpamAssassin determines that the message is spam, the
+Citadel SMTP
+service <i>rejects the message,</i> causing a delivery failure on the
+sending
+host. This is superior to software which files away spam in a separate
+folder, because delivery failures will cause some spammers to assume
+the
+address is invalid and remove it from their mailing lists.</p>
+<p><b>RBL:</b> Realtime Blackhole Lists (RBL's) provide defense against
+spammers based on their source IP address. There are many such lists
+available on the Internet, some of which may be utilized free of
+charge. Since they are DNS based, the lists do not require storage on
+your server -- they are queried during the SMTP conversation.</p>
+<p>Citadel can utilize any RBL that uses the <tt>z.y.x.w.nameoflist.org</tt>
+syntax, where <tt>w.x.y.z</tt> is the source IP address which is
+attempting to deliver mail to your server. For example, <a
+ href="http://www.spamcop.net">SpamCop</a> would use the query <tt>2.0.0.127.bl.spamcop.net</tt>
+to determine whether the host at <tt>127.0.0.2</tt> is a known spammer
+or open relay. In this case, you simply select option '6' to add an RBL
+entry, and provide it with the domain suffix of <tt>bl.spamcop.net</tt>
+(the IP address
+and extra dot will be automatically prepended for each query).</p>
+<p>Now select <tt><b>S</b>ave</tt> and you are just about ready for
+Internet e-mail.</p>
+<h3><a name="Enabling_the_Internet_mail_protocols"></a>Enabling the
+Internet mail protocols</h3>
+<p>As previously mentioned, Citadel contains its own SMTP, POP3, and
+IMAP services. Enabling them is simple.</p>
+<p>Check for the existance of a current MTA (sendmail, qmail, etc.) by
+connecting to port 25 on your host. If you see something similar to the
+following
+you're running an MTA already and you'll need to shut it down:</p>
+<pre>smw @ pixel % telnet localhost 25<br>Trying 127.0.0.1...<br>Connected to localhost.<br>Escape character is '^]'.<br>220 pixel.citadel.org ESMTP Sendmail 8.9.3/8.9.3; Wed, 15 Mar 2000 19:00:53 -0500<br></pre>
+<p>In the above example, we see that the host already has Sendmail
+listening on port 25. Before Citadel can use port 25, Sendmail must be
+shut off. Please consult the documentation for your operating system
+for instructions on how to do this. (On a Red Hat Linux system, for
+example, you can run the <tt>ntsysv</tt> utility, un-checking <tt>sendmail</tt>
+to disable it at
+the next reboot; then, run <tt>service sendmail stop</tt> to shut off
+the
+currently running service.)</p>
+<p>If you get a 'connection refused' message when you telnet to port 25
+there's nothing running and you should be able to continue. You might
+also want to turn off POP (try the above test substituting 110 for 25)
+and IMAP (port 143) and use Citadel's POP and IMAP services.</p>
+<p>Citadel will look for an existing pop/smtp server on startup. If
+they
+don't exist (and you've configured them properly) then Citadel should
+enable
+them at startup. You can check your logs to be sure, or you can start
+the
+server from a shell and watch it load. It might look something like
+this:</p>
+<font size="-2"> </font>
+<pre><font size="-2">smw @ pixel % ./citserver<br><br>Multithreaded message server for Citadel<br>Copyright (C) 1987-2006 by the Citadel development team.<br>Citadel is open source, covered by the GNU General Public License, and<br>you are welcome to change it and/or distribute copies of it under certain<br>conditions. There is absolutely no warranty for this software. Please<br>read the 'COPYING.txt' file for details.<br><br>Loading citadel.config<br>Opening databases<br>This is GDBM version 1.8.0, as of May 19, 1999.<br>Checking floor reference counts<br>Creating base rooms (if necessary)<br>Registered a new service (TCP port 504)<br>Registered a new service (TCP port 0)<br>Initializing loadable modules<br>Registered server command CHAT (Begin real-time chat)<br>Registered server command PEXP (Poll for instant messages)<br>Registered server command GEXP (Get instant messages)<br>Registered server command SEXP (Send an instant message)<br>Registered server command DEXP (Disable instant messages)<br>Registered a new session function (type 0)<br>Registered a new x-msg function (priority 0)<br>Loaded module: $Id$<br>Registered a new session function (type 1)<br>Registered a new message function (type 201)<br>Registered a new message function (type 202)<br>Registered server command REGI (Enter registration info)<br>Registered server command GREG (Get registration info)<br>Registered a new user function (type 100)<br>Loaded module: $Id$<br>Server-hosted upgrade level is 5.62<br>Loaded module: $Id$<br>Registered server command EXPI (Expire old system objects)<br>Registered server command FSCK (Check message ref counts)<br>Loaded module: $Id$<br><b>citserver: Can't bind: Address already in use<br>ERROR: could not bind to TCP port 25.</b><br>Registered a new service (TCP port 0)<br>Registered a new session function (type 50)<br>Loaded module: $Id$<br><b>citserver: Can't bind: Address already in use<br>ERROR: could not bind to TCP port 110.</b><br>Registered a new session function (type 0)<br>Loaded module: $Id$<br>Registered a new message function (type 202)Loaded module: $Id$<br>Registered server command RWHO (Display who is online)<br>Registered server command HCHG (Masquerade hostname)<br>Registered server command RCHG (Masquerade roomname)<br>Registered server command UCHG (Masquerade username)<br>Registered server command STEL (Enter/exit stealth mode)<br>Loaded module: $Id$<br>Changing uid to 513<br>Starting housekeeper thread<br></font></pre>
+<p>The lines emphasized in boldface in the above log output tell you
+that Citadel "can't bind" to various ports. The error 'address already
+in use' generally means that something else is already running on the
+requested port. Make SURE you've followed the above steps to remove
+sendmail/pop and start your Citadel server again.</p>
+<h3><a name="citmail"></a>Using Citadel in conjunction with another MTA</h3>
+<p>Occationally it is not practical to remove a non-Citadel MTA on your
+host system. For example, you might have multiple groups of users, some
+of
+which are using Citadel and some of which are using a legacy Unix mail
+spool. This type of configuration is discouraged, but two tools are
+provided
+to allow it.</p>
+<p>The tool is called <tt>citmail</tt> and it is, quite simply, a
+local MDA (Mail Delivery Agent) which you can configure into your MTA
+for final delivery of incoming messages to Citadel users. A full
+discussion of the finer points of complex Sendmail configurations is
+beyond the scope of this document; however, you might want to visit <a
+ href="http://pixel.citadel.org/citadel/docs/">Pixel BBS</a> where some
+useful HOWTO documents are provided.<br>
+</p>
+<p>The other tool is an <a href="http://www.faqs.org/rfcs/rfc2033.html">RFC2033</a>
+compliant LMTP service running on a local socket. If you're
+running a mailer that speaks LMTP (such as <a
+ href="http://www.postfix.org/">Postfix</a>), you can simply point your
+mailer at the socket called <span style="font-family: monospace;">citadel.socket</span>
+in your Citadel directory. For example, in Postfix you might put
+the following line into <span style="font-family: monospace;">main.cf</span>
+in order to tell it to use Citadel to deliver mail to local recipients:<br>
+</p>
+<pre>local_transport = lmtp:unix:/usr/local/citadel/lmtp.socket<br></pre>
+<p>Postfix also has something called a "fallback transport" which can
+be used to implement Citadel as a "secondary" mail system on your
+server, while keeping the existing Unix mailboxes intact.
+However, it is beyond the scope of this document to detail the finer
+points of the configuration of Postfix or any other mailer, so refer to
+the documentation to those programs and keep in mind that Citadel has
+LMTP support.<span style="font-family: monospace;"></span></p>
+<p>There are actually <i>two</i> LMTP sockets. One is called
+<tt>lmtp.socket</tt> and the other is called <tt>lmtp-unfiltered.socket</tt>
+(both are found in your Citadel directory). The difference should be
+obvious: messages submitted via <tt>lmtp.socket</tt> are subject to
+any
+spam filtering you may have configured (such as SpamAssassin), while
+messages
+submitted via <tt>lmtp-unfiltered.socket</tt> will bypass the filters.
+You
+would use the filtered socket when receiving mail from an external MTA
+such
+as Postfix, but you might want to use the unfiltered socket with
+utilities
+such as fetchmail.</p>
+<br>
+<p>For outbound mail, you
+can either allow Citadel to perform
+deliveries directly
+(this won't affect your other mail system because outbound mail doesn't
+tie
+up port 25) or enter <tt>127.0.0.1</tt> as your smart-host, which will
+tell
+Citadel to forward all of its outbound mail to your other mail system.</p>
+<h3><a name="Hosting_an_Internet_mailing_list"></a>Hosting an Internet
+mailing list</h3>
+<p>Citadel has built in mailing list service (known in Internet
+vernacular as "listserv") functionality. You can turn any room
+into a mailing list. Users can then choose how they participate
+-- by logging on to your Citadel server directly, or by having the
+room's contents mailed to
+them somewhere else. Configuring this is easy.</p>
+<p>Citadel supports two modes of mailing list delivery: </p>
+<ul>
+ <li>"List mode" -- each individual message is delivered as a single
+e-mail to each list mode recipient. The "From:" header will
+display the address of the message's original author.</li>
+ <li>"Digest mode" -- groups of one or more messages are delivered
+to digest mode recipients. The number of messages in the group
+depends on how many new messages arrived since the last batch was
+delivered. The "From:" header will display the address of the
+room itself, which allows replies to be posted back to the room.</li>
+</ul>
+A room may have any combination of list mode and digest mode
+recipients.
+<p>As alluded to above, every room on your Citadel system has an
+Internet e-mail address of its own. Messages sent to that address
+will be
+posted in the room (and sent back out to mailing list recipients, as
+well
+as to any other Citadels you share the room with). The address
+format
+is <tt>room_</tt> plus the name of the room, with any spaces replaced
+by
+underscores, followed by <tt>@</tt> and your hostname. For example, if
+your
+system is known as <tt>phlargmalb.orc.org</tt> on the Internet, and
+you have
+a room called <tt>Bubblegum Collectors</tt>, you can post to that room
+from
+anywhere on the Internet simply by sending an e-mail to <tt>room_bubblegum_collectors@phlargmalb.orc.org</tt>.
+When the message arrives, it's automatically posted in that room.</p>
+<p>To manually edit the list of "list mode" recipients, simply enter
+the <tt><b>.A</b>ide
+mailing <b>L</b>ist management</tt> command. Your text editor will
+open
+up and you will be able to create or edit a list of recipients, one per
+line. Lines beginning with a hash (<tt>#</tt>) are comments.</p>
+<p>To manually edit the list of "digest mode" recipients, enter the <tt><b>.A</b>ide
+mailing list <b>D</b>igest recipients</tt> command. As with the
+previous command, the text editor will open up and you can edit the
+list of digest mode recipients, one per line.</p>
+<p>Citadel also has a facility which allows users to subscribe or
+unsubscribe to mailing lists using a web browser. In order to do this,
+WebCit must also be running on your server in addition to Citadel.
+WebCit is obtained and installed separately from the rest of the
+Citadel system.</p>
+<p>In order to prevent "just anyone" from subscribing to any room on
+your system, there is a setting in the <tt><b>.A</b>ide <b>E</b>dit
+room</tt> command:</p>
+<pre>CitaNews} . Aide Edit this room<br>
+Room name [CitaNews]:<br>
+<br>
+<i>(lots of other stuff omitted for brevity...)</i><br>
+<br>
+Self-service list subscribe/unsubscribe [No]: Yes<br></pre>
+<p>When you answer "Yes" to self-service list subscribe/unsubscribe,
+you are
+enabling that feature. Now, all you have to do is tell the world about
+the
+web page they need to visit. It looks like this:</p>
+<center><tt>http://foobar.baz.org:2000/listsub</tt></center>
+<p>In this example, the server is called <tt>foobar.baz.org</tt> and
+WebCit is running on port 2000. Edit appropriately.</p>
+<p>Citadel offers a subscribe/unsubscribe facility that is more
+intuitive than other listservs. With most systems, sending commands to
+the listserv requires that you e-mail it commands in a special format.
+It's easy to get it wrong. Citadel simply uses your web browser. You
+select the list you want to subscribe or unsubscribe (hint: it's the
+list of rooms you've enabled self-service for), select whether you want
+list mode or digest mode, and enter your e-mail address. For security
+purposes, a confirmation message is sent to the address you enter. But
+you don't have to reply to the message in a weird format, either: the
+confirmation contains another URL which
+you simply click on (or paste into your browser if you can't click on
+URL's
+in your e-mail software) and the confirmation is automatically
+completed.</p>
+<hr size="2" width="100%">
+<center>
+<h2><a name="Building_or_joining_a_Citadel_network"></a>Building or
+joining a Citadel network</h2>
+</center>
+<h3><a name="Overview__"></a>Overview</h3>
+<p>If you are running Citadel as a BBS or other forum type of
+application, one way to 'keep the conversation going' is to share rooms
+with other Citadel systems. In a shared room, a message posted to the
+room is automatically
+propagated to every system on the network. It's kind of like a UseNet
+newsgroup, but without the spam.</p>
+<p>If you are using Citadel as the e-mail and groupware platform for a
+large organization, you can use its networking features to build a
+large network of Citadel servers which share content (think of rooms as
+public folders), redistribute e-mail throughout the organization, and
+integrate the global address book. It might make sense, for
+example, in a large corporation to give each department or location its
+own Citadel server. Thanks
+to Citadel's global address book features, you could still have all of
+the users share a single e-mail domain.</p>
+<p>Obviously, the first thing you have to do is find another Citadel to
+share rooms with, and make arrangements with them. The following
+Citadels are a good place to start:</p>
+<ul>
+ <li>UNCENSORED! - <a href="http://uncensored.citadel.org">uncensored.citadel.org</a>
+ </li>
+ <li>The Dog Pound II - <a href="http://dogpound2.citadel.org">dogpound2.citadel.org</a>
+ </li>
+</ul>
+<p>You don't have to be a part of the citadel.org domain to participate
+in the public Citadel network, but the DNS service is provided free of
+charge by the Citadel community if you wish to do this.</p>
+<h3><a name="Conventions_and_etiquette_when"></a>Conventions and
+etiquette when connecting to the public Citadel network</h3>
+<p>Before we get into the technical nitty gritty, there are two points
+of etiquette to keep in mind. The first thing to keep in mind is that
+the operator of any particular Citadel may not be willing to share some
+of his/her rooms. Some sites are proud to offer exclusive content in
+certain areas. Chances are, if a room is already being shared on the
+network, it's available for anyone to share; if not, it can't hurt to
+ask -- but take care not to demand it of them. Ask if you may share the
+room instead of telling them that you wish to share the room. When
+looking at a <tt><b>K</b></tt>nown rooms list, network rooms are the
+ones ending in parentheses instead of angle brackets. For example, <tt>Gateway)</tt>
+would be a network room, <tt>Lobby></tt> would not.</p>
+<p>The other point of etiquette to remember is that you should be
+making
+the arrangements in advance, and then set it up. It is extremely rude
+to
+simply begin networking with another Citadel, or unilaterally start
+sharing
+a new room, without first obtaining permission from its operator.
+Always
+ask first. Most Citadel operators are more than happy to network with
+you. Also, if later on you decide to take your system down, please take
+the time
+to notify the operators of any other Citadels you network with, so they
+can
+unconfigure their end.</p>
+<h3><a name="Getting_ready_to_join_the_network"></a>Getting ready to
+join the network</h3>
+<p>Ok, first things first. On a Citadel room sharing network, the first
+thing you need to know is your own system's node name. Presumably you
+set
+this up during installation, but if you want to change it you can do so
+using
+the <tt><b>.A</b>ide <b>S</b>ysconfig <b>G</b>eneral</tt> command:</p>
+<pre>Lobby> . Aide System configuration General<br>Node name [uncnsrd]:<br>Fully qualified domain name [uncensored.citadel.org]:<br>Human readable node name [Uncensored]:<br></pre>
+<p>The "node name" is important, it's how the network identifies
+messages coming from your system. The "human readable node name" is
+simply a label; it shows up in messages coming from your system. "Fully
+qualified domain name" is your DNS name; it's used for routing messages
+on the Internet. In the above example, the node name is "uncnsrd".</p>
+<h3><a name="Defining_neighbor_nodes"></a>Defining neighbor nodes</h3>
+<p>The next thing you need to do is configure your neighbor node(s).
+You need to do this for each node you network with. Let's say you
+wanted
+to talk to a Citadel system called "frobozz". Use the <tt><b>.A</b>ide
+<b>S</b>ysconfig <b>N</b>etwork</tt> command:</p>
+<pre>Lobby> . Aide System configuration Network<br>### Node Secret Host or IP Port#<br>--- ---------------- ---------------- -------------------------------- -----<br><A>dd <D>elete <S>ave <Q>uit -> Add<br><br>Enter node name : frobozz<br>Enter shared secret: frotz<br>Enter host or IP : frobozz.magick.org<br>Enter port number : [504]: 504<br><br>### Node Secret Host or IP Port#<br>--- ---------------- ---------------- -------------------------------- -----<br> 1 frobozz frotz frobozz.magick.org 504<br><A>dd <D>elete <S>ave <Q>uit -> Save<br><br>Lobby><br></pre>
+<p>As you can see in the above example, you have to enter the Citadel
+node name, the DNS name or IP address of the server, and the port
+number the Citadel service is running on. The "shared secret" is a
+password to allow the two Citadel nodes to connect to each other to
+exchange network data. The password must be <i>identical</i> on both
+ends of the connection -- when the operator of the other Citadel node
+sets up the connection with
+your system, he/she must use the same password.</p>
+<h3><a name="Sharing_rooms"></a>Sharing rooms</h3>
+<p>Now you're ready to share rooms. You have to do this for each room
+you want to share, and you have to do it from BOTH ENDS -- again, when
+you
+share a room with another Citadel, they must share it with you as well.
+Let's say you have a room called "Quiche Recipes>" and you want to
+share
+it with the node you set up above. First, edit the room and flag it as
+a
+network room:</p>
+<pre>Quiche Recipes> . Aide Edit this room<br>Room name [Quiche Recipes]:<br>Private room [No]: No<br>Preferred users only [No]: No<br>Read-only room [No]: No<br>Directory room [No]: No<br>Permanent room [No]: No<br>Network shared room [No]: Yes<br>Automatically make all messages anonymous [No]: No<br>Ask users whether to make messages anonymous [No]: No<br>Listing order [64]:<br>Room aide (or 'none') [none]:<br>Message expire policy (? for list) [0]:<br>Save changes (y/n)? Yes<br>Ok<br><br>Quiche Recipes)<br></pre>
+<p>Notice how the prompt changed? It was > before, but it's ) now.
+That means it's a network room. Now you can tell Citadel that you want
+to
+share the room with frobozz. Enter this command:</p>
+<pre>Quiche Recipes) . Aide Network room sharing<br></pre>
+<p>Your text editor will pop up (you <i>did</i> configure Citadel to
+use
+your favorite text editor, right?) with a screen that looks like this:</p>
+<pre># Configuration for room: Quiche Recipes<br># Nodes with which we share this room<br># Specify one per line.<br></pre>
+<p>All you have to do is enter the name of the other Citadel node (i.e.
+"frobozz" in our example) on a line by itself. As usual, lines starting
+with a "#" are comments. Just go to the end of the file, type "frobozz"
+(without the quotes), save the file... and you're done!</p>
+<p>At this point, you just sit back and enjoy. Your Citadel and the
+other one will begin polling each other at regular intervals (once per
+hour by default) and sharing messages.</p>
+<h3><a name="Sending_mail"></a>Sending mail</h3>
+<p>You can send mail to any user on any node of your Citadel network.
+It may take a little while for your system to learn the entire node
+list, though, as this is done by watching incoming messages on the
+network and learning which nodes are out there.</p>
+<p>To send a private message, just enter <tt>user @ host</tt> as the
+recipient:</p>
+<pre>Mail> Enter message <br>Enter recipient: Some other user @ frobozz<br> Feb 11 2003 11:36pm from I. M. Me to Some other user @ frobozz<br>type message here...<br><br>Entry command (? for options) -><br><br></pre>
+<h3><a name="Changing_the_polling_interval"></a>Changing the polling
+interval</h3>
+<p>As previously mentioned, Citadel will poll other Citadel nodes for
+messages once per hour. If this is not an acceptable interval, you can
+change it using the <tt><b>.A</b>ide <b>S</b>ystem configuration <b>G</b>eneral</tt>
+command. Enter this command and look for the option:</p>
+<pre>How often to run network jobs (in seconds) [3600]:<br></pre>
+<p>Change it to whatever you like. For example, 15 minutes is 900
+seconds. So if you changed the default value to 900, network polling
+would occur every 15 minutes.</p>
+<hr>
+<h2 align="center"><a name="Database_maintenance"></a>Database
+maintenance</h2>
+<h3><a name="Introduction_"></a>Introduction</h3>
+The data store used by Citadel is reliable and self-maintaining.
+ It requires very little maintenance. This is primarily due
+to its use of the <a href="http://www.sleepycat.com">Berkeley DB</a>
+record manager. It is robust, high-performance, and transactional.<br>
+<br>
+A few small data files are kept in your main Citadel directory, but the
+databases are in the <tt>data/</tt> subdirectory. The files with
+names that begin with "cdb" are the databases themselves; the files
+with names that begin with "log" are the logs (sometimes referred to as
+"journals"). Log files will continue to appear as you use your
+system; each will grow to approximately 10 megabytes in size before a
+new one is started. There is a system configuration setting
+(found in <span style="font-family: monospace;"><span
+ style="font-weight: bold;">.A</span>ide <span
+ style="font-weight: bold;">S</span>ystem-configuration <span
+ style="font-weight: bold;">G</span>eneral</span> in the text mode
+client, or in <span style="font-family: monospace;">Administration
+--> Edit site-wide configuration --> Tuning</span> in the WebCit
+client) which specifies "Automatically delete committed database
+logs." If you have this option enabled, Citadel will
+automatically delete any log files whose contents have been fully
+committed to the database files.<br>
+<br>
+For more insight into how the database and log files work, you may wish
+to read the <a
+ href="http://www.sleepycat.com/docs/ref/transapp/archival.html">Berkeley
+DB documentation</a> on this subject.<br>
+<br>
+<h3><a name="Backing_up_your_Citadel_database"></a>Backing up your
+Citadel database</h3>
+<span style="font-weight: bold;">Please read this section carefully.</span><br>
+<br>
+There are two backup strategies you can use, depending on your site's
+availability requirements and disk space availability.<br>
+<h5>Strategy #1: Standard backup</h5>
+The standard (or "offline") backup is used when your Citadel server is
+configured to automatically delete committed database logs. The
+backup procedure is as follows:<br>
+<ol>
+ <li>Shut down the Citadel server.</li>
+ <li>Back up all files (database files, log files, etc.) to tape or
+some other backup media.</li>
+ <li>Start the Citadel server.</li>
+</ol>
+<span style="font-style: italic;">Advantage:</span> very little disk
+space is consumed by the logs.<br>
+<span style="font-style: italic;">Disadvantage:</span> Citadel is not
+available during backups.<br>
+<br>
+<h5>Strategy #2: "Hot" backup</h5>
+The "hot backup" procedure is used when your Citadel server is
+configured <span style="font-weight: bold;">not</span> to
+automatically delete committed database logs. The backup
+procedure is as follows:<br>
+<ol>
+ <li>Back up all files. Make sure the database files (<span
+ style="font-family: monospace;">cdb.*</span>) are backed up <span
+ style="font-style: italic;">before</span> the log files (<span
+ style="font-family: monospace;">log.*</span>). This will usually
+be the case, because the database files tend to appear first in both
+alphabetical and on-disk ordering of the <span
+ style="font-family: monospace;">data/</span> directory.</li>
+ <li>After verifying that your backup completed successfully, delete
+the committed log files with a command like this:</li>
+</ol>
+<span style="font-family: monospace;">/usr/local/citadel/sendcommand
+"CULL"</span><br>
+<br>
+<span style="font-style: italic;">Advantage:</span> Citadel continues
+to run normally during backups.<span style="font-style: italic;"><br>
+Disadvantage:</span> Much disk space is consumed by the log files,
+particularly if the full text indexer is turned on.<br>
+<br>
+<br>
+It is up to you to decide which backup strategy to use. <span
+ style="font-weight: bold;">Warning: if you configure Citadel to
+automatically delete committed database logs, and do not shut the
+Citadel service down during backups, there is no guarantee that your
+backups will be usable!</span><br>
+<br>
+<h3><a name="Database_repair"></a>Database repair</h3>
+Although Citadel's data store is quite reliable, database corruption
+can occur in rare instances. External factors such as an
+operating
+system crash or an unexpected loss of power might leave the database in
+an unknown state. A utility is provided which may be able to
+repair
+your database if this occurs. If you find that your Citadel
+server
+is not running, and reading the logs shows that it is crashing because
+of
+an inability to validate a database, follow these steps:<br>
+<ol>
+ <li>Edit <tt>/etc/inittab</tt> and switch the Citadel service from
+"respawn" to "off." Type <tt>init q</tt> to make this setting
+permanent.</li>
+ <li><b>Make a backup of your data.</b> Either write it out to
+tape or copy it to another directory, or a tarball.<br>
+ </li>
+ <li><tt>cd</tt> to your Citadel directory and type <tt>./database_cleanup.sh</tt></li>
+ <li>Let the cleanup script run. <b>Do not interrupt this
+process for any reason.</b><br>
+ </li>
+ <li>Edit <tt>/etc/inittab</tt> and switch the Citadel service from
+"off" to "respawn". Type <tt>init q</tt> to activate your
+changes.</li>
+</ol>
+If this procedure does not work, you must restore from your most recent
+backup.<br>
+<br>
+<h3><a name="ImportingExporting_your_Citadel"></a>Importing/Exporting
+your Citadel database<br>
+</h3>
+<p>Citadel contains an importer/exporter module, affectionately
+known as the "Art Vandelay" module (a not-so-obscure Seinfeld
+reference). It
+allows you to export the entire contents of your Citadel databases to a
+flat file, which may then be imported on another system. (This
+procedure
+is also known as "dump and load" to database gurus.)</p>
+<p>Why would you want to do this? Here are some scenarios: </p>
+<ul>
+ <li>You are moving a Citadel installation to another computer, which
+uses a different CPU. Since Citadel stores data in an
+architecture-dependent format, the data files wouldn't work on the new
+computer as-is. </li>
+ <li>Your computer crashed, lost power, etc. and you suspect that your
+databases have become corrupted. </li>
+ <li>You want to switch to a different back-end data store. (For
+example, from GDBM to Berkeley DB) </li>
+</ul>
+<p>So ... how do we work this magic? Follow these steps <i>exactly</i>
+as documented and you should be able to do it all with very little
+trouble.</p>
+<ol>
+ <li>This should be obvious, but it's still worth mentioning: <b>Make
+sure you have a backup of everything before you start this! </b>
+You're performing a major operation here. Don't risk it. </li>
+ <li>First, get all the users logged off from your system. Disconnect
+it from the network if possible. You don't want anyone logging in while
+you're doing this. </li>
+ <li>Log on as root, or some other user that has read/write access to
+all relevant files. </li>
+ <li>Go to the directory that Citadel is installed in. For example,
+issue a command like <tt>cd /usr/local/citadel</tt> </li>
+ <li>Export the databases with the following command:<br>
+ <br>
+ <tt>./sendcommand "ARTV export" >exported.dat</tt><br>
+ <br>
+This command may run for a while. On a very large system it could take
+an hour or more. Please be patient! </li>
+ <li>When the export completes, check to make sure that <tt>exported.dat</tt>
+exists and has some data in it. (Type "ls -l exported.dat") </li>
+ <li>Shut down the Citadel server. If you have a line in <tt>/etc/inittab</tt>
+that reads like this:<br>
+ <br>
+ <tt>c1:2345:respawn:/usr/local/citadel/citserver
+-h/usr/local/citadel</tt> <br>
+...then you should change the <tt>respawn</tt> to <tt>off</tt> and
+then type <tt>/sbin/init q</tt> to make the changes take effect. </li>
+ <li>Now it's time to delete your current binary databases. Type:<br>
+ <br>
+ <tt>rm -f citadel.config citadel.control data/*</tt> </li>
+ <li>If you're moving Citadel to another computer, you should move the
+ <i>entire</i> directory over at this time. <tt>exported.dat</tt>
+only contains the information that was in the binary databases.
+Information which was stored in portable formats doesn't need to be
+exported/imported, so
+you must bring it all over in its current form. </li>
+ <li>Now get Citadel running on the new computer (or whatever). Run <tt>setup</tt>
+and turn the service back on (from <tt>/etc/inittab</tt>) but DO NOT
+log in. </li>
+ <li>As root, run the import command:<br>
+ <br>
+ <tt>./sendcommand "ARTV import" <exported.dat</tt><br>
+ <br>
+This will import your databases. Again, it may run for a long time. </li>
+ <li>Restart the Citadel server. You can do this any way you like.
+From the command line, you can do it with a command like:<br>
+ <br>
+ <tt>./sendcommand "DOWN"</tt> <br>
+ </li>
+ <li>Now you're finished. Log in and test everything. You may delete
+exported.dat at this time, or you might want to save it somewhere as a
+sort of pseudo-backup. </li>
+</ol>
+<hr>
+<center>
+<h2><a name="crypto"></a>Cryptography support (TLS/SSL)</h2>
+</center>
+<h3><a name="crypto_intro"></a>Overview</h3>
+<p>Citadel provides built-in support for encryption using Transport
+Layer Security (TLS) for ESMTP, IMAP, POP3, and the Citadel client
+protocol.
+A simple cryptographic configuration is installed automatically when
+you
+bring the system online. The remainder of this section describes how
+this
+configuration is built, and what you can do to make changes to it.</p>
+<p>Encryption files are kept in the <tt>keys/</tt> directory. The
+three
+files used by Citadel are:</p>
+<ul>
+ <li><tt>citadel.key</tt> - Contains your system's RSA private key.
+Citadel
+generates a new key automatically if one is not found. </li>
+ <li><tt>citadel.csr</tt> - Contains a Certificate Signing Request
+(CSR)
+for your system. Citadel generates a new CSR automatically, using your
+private key, if one is not found. </li>
+ <li><tt>citadel.cer</tt> - Contains the public certificate for your
+system. The public key in the certificate <b>must</b> correspond with
+the
+private key in <tt>citadel.key</tt>, otherwise encryption will not
+function properly. Citadel will generate a self-signed certificate,
+again
+using your private key, if a certificate is not found. </li>
+</ul>
+<h3><a name="real_cert"></a>Generating and installing a Trusted
+Certificate</h3>
+<p>If you wish to interact with 3rd party clients
+that have hard coded lists of acceptable Certificate Authorities, and
+you
+do not want annoying dialog boxes popping up for the user on the first
+(or
+all) connections, then you will have to have your key signed by a valid
+Certificate Authority.</p>
+<p>It is beyond the scope of this document to provide a complete
+tutorial
+on SSL certificates. Here are the general rules to follow:</p>
+<ul>
+ <li>Generally, the Certificate Signing Requeste which is
+automatically
+generated by Citadel will not contain enough information for any
+Certificate
+Authority to sign it. Generate a new CSR with the following commands:<br>
+ <br>
+ <tt>cd keys</tt><br>
+ <tt>openssl req -new -key citadel.key -out citadel.csr</tt><br>
+ <br>
+Answer all questions (your geographic location, organization name,
+etc.)
+and then send the new <tt>citadel.csr</tt> to your Certificate
+Authority
+when you order the certificate. </li>
+ <li>When the certificate is received, simply save it as <tt>citadel.cer</tt>
+and restart the Citadel server. </li>
+ <li>If your certificate authority delivers a 'chained' certificate
+(one
+with intermediate certificate authorities), simply append the
+intermediate
+certificate after your server's own certificate in the <tt>citadel.cer</tt>
+file.</li>
+</ul>
+<br>
+<hr style="width: 100%; height: 2px;">
+<div style="text-align: center;">
+<h2><a name="LDAP_Directory_Support"></a>LDAP (Directory) Support</h2>
+<div style="text-align: justify;">
+<h3><a name="Introduction_ldap"></a>Introduction</h3>
+LDAP (Lightweight Directory Access Protocol) has become the open
+standard protocol for directory access. There are many client
+programs which are capable of making use of an LDAP directory
+service. Therefore it may be beneficial for some sites to have a
+directory available which is populated with Citadel user information.<br>
+<br>
+Citadel does not contain its own LDAP service, because that would
+eliminate its ability to coexist with any existing directory you may
+already have in place at your organization. Instead, we provide
+the LDAP Connector for Citadel, which allows the Citadel service to
+populate an external LDAP directory. If you do not already have
+an LDAP directory in place, you can use the OpenLDAP server, which is
+probably already present in your operating system, or at least can be
+loaded from the installation CD's. The supplied configuration
+file <tt>citadel-slapd.conf</tt> can be used as a starting
+point to get your LDAP server running.<br>
+<br>
+<h3><a name="Preparing_your_LDAP_server_for_Citadel"></a>Preparing your
+LDAP server for Citadel connections</h3>
+It is difficult to find a commonly accepted LDAP scheme. It seems, most
+real life LDAP installations go for the domain oriented apporach
+and lay out the structure after an existing domain/subdomain structure.
+<p> The most widely accepted and standardized object for storing
+personal data clearly is "inetOrgPerson". Citadel therefore extends this
+standard schema with an object class called "citadelInetOrgPerson".</p>
+<p>If you are using OpenLDAP as your directory server, you should
+choose options similar to the following:</p>
+<pre>
+include /etc/openldap/schema/core.schema
+include /etc/openldap/schema/cosine.schema
+include /etc/openldap/schema/inetorgperson.schema
+include /etc/openldap/schema/rfc2739.schema
+include /etc/openldap/schema/citadel.schema