RPGBoard Administrators' FAQ

The latest version of this FAQ can be found here.  If this FAQ doesn't answer your question, go ahead and e-mail me or the question crew.  If this FAQ does answer your question, please don't bother me!

Administrators (as opposed to superusers) should look through section 4 for useful information.

  1. Installation
    1. How do I start?
    2. Will this work on NT?
    3. What's this thing about Apache, SSIs, and the "xbithack" option?
    4. How do I know what software and OS my web server uses?
    5. What's this about chmod?
    6. What's a CGI-BIN?
  2. Configuration
    1. How exactly does the user moderation work and when should I use it?
    2. How exactly do the auto maintenance features work?
    3. What's this about merging together a forum with a mailing list?
    4. How do I enable RPGBoard to work with multiple language files?
  3. Migrating to RPGBoard
    1. How do I migrate from WWWBoard/RPGBoard 1.*?
    2. How do I migrate from a gamma version of RPGBoard 2.00?
    3. How do I migrate to RPGBoard 2.04?
    4. How do I migrate to RPGBoard 2.20?
  4. Administrating RPGBoard
    1. What power does an admin have?
    2. How do I delete multiple messages at once?
    3. How do I ban a user?
    4. How do the passwords work?
    5. What's the best way to administrate my message board?
  5. Troubleshooting
    1. I get a Error 500 when I try to run config.cgi!  What gives?
    2. When I'm about to post a test message, I don't see any fields!  What's wrong?
    3. The configurator can't create any directories!  What's the problem?
    4. Why can't I create/remove any of the message tags?
    5. The SpellCheck doesn't work and I'm getting a gzip error.  What's wrong?
    6. Users are forced to hit reload on everything.  How do I change this behavior?
    7. My server times out when RPGBoard is trying to preform a yearly archive.  How can I do this manually?
    8. It looks like anybody can delete anybody else's messages!  What's wrong?
  6. Features that I won't add
    1. Why don't you put in an "Edit Message" function?
    2. How about putting in the "Re: [Subject]" in the subject line?
    3. I want to have a special [background/text font/whatever] just for admins.  Can you put that in?
    4. Can you put a "NEW" tag on new messages?
    5. What about an "e-mail password" option for users that forget their password?
    6. Why are you so picky about what features get put in the script?
1 Installation
1.1 How do I start?
If you have any problems, please look through this FAQ, especially the troubleshooting section, before e-mailing me.  I'm serious!
  1. Create a directory in your CGI-BIN called "rpgboard".
  2. Put all of the scripts (*.cgi) and include files (*.h) into this directory.  UPLOAD IN ASCII!!!
  3. Make the scripts (*.cgi) executable by chmoding them 755 in your RPGBoard directory.
  4. Make rpgvariables.h writable by chmoding it 666.  (If you know how your server's security works, you might want to chmod it to 600 or 644 and change ownership accordingly.)
  5. Apache users: Edit (or create) your .htaccess file and add xbithack on to it.  The option forces the server to check any HTML file for server-side includes, if the exec bit is set (not just *.shtml files).  Put this file in your root WWW directory (or message directory, if you want).
  6. Create a directory where the message board will go.  (Let's say "/mb".)  Do not put this directory in your CGI-BIN!  (BTW, this is considered to be your base directory.)
  7. Create a directory called "messages" in your MB directory (like "/mb/messages").
  8. Chmod both of these directories to 777.
  9. Put the *.html and *.gif files into a "docs" directory (like "/mb/docs")
  10. Throw the dictionary file in your MB directory, if you are going to use it.
  11. Fire up your favorite browser and go to the config.cgi on your site.
  12. Enter in password on the password prompt.
  13. Configure the basic information.  (Don't forget to change your password!)
  14. After you submit the information, a bunch of warnings will get displayed.  This is normal.  Be sure to read through them all and check the indented actions, too.
  15. Go to the main screen and configure all of the sections.  Don't stop until you don't see any more warnings.  (For now, only configure one forum.)
  16. Special note when creating forums: Use small names for your forums.  Don't name everything "[insert topic here] Discussion Board".  It's repetive, esp. when your MB's collective name is "[something] Discussion Board".  Instead, just call it your topic.  Not only does it look nicer, but the default directory name isn't nearly as long.  ("Foobar Discussion Board" turns into "foobardiscussionboard/".)
  17. Go to defaults.html on your MB directory and use !!default as the name and password as the password.
  18. This is the default defaults for people who aren't registered.  Change everything that you want to, including the password.
  19. Now, test the board by going to http://www.yoursite.com/yourmb/yourforum/.  If you see the "Display messages from" option on the page, you're OK.  If not, you may not be running Apache and/or your SSIs may not be working.
  20. Try posting a message and see if it shows up.  Test all of the other functions, too.
  21. You'll need to make a index.html in your MB directory as a entrance page.  Also, changing the pre-made HTML files ([defaults/backgrounds/index/post].html) would be nice, too.  (Please don't remove the SSI comments, ok?)
1.2 Will this work on NT?
Yes!  It works fairly well with NT, as long as you have the latest version of Perl.  The copy that came with the server isn't enough.  You should grab yourself the latest copy of ActivePerl.

However, as a program originally intented for UNIX systems, RPGBoard has a few features which will not work on NT.  These are the auto-compression system (no GZip), e-mail functions (no sendmail), and using nslookup to check an IP name (no nslookup).  You should disable the first two in the toggle menu of the configurator.  (RPGBoard won't use nslookup if it can't find it.)

(BTW, unzip the dictionary since you can't use GZip.)

1.3 What's this thing about Apache, SSIs, and the "xbithack" option?
Here.  There's also a good article on the .htaccess file here.
1.4 How do I know what software and OS my web server uses?
Go to Netcraft's "What's that site running?" page and type in your domain name.  Apache and a UNIX OS is an ideal system for RPGBoard.
1.5 What's this about chmod?
The chmod command is used change permissions on files and directories.  There are several ways you can change permissions:
  1. Using telnet and running the command on the files (like "chmod 755 *.cgi").
  2. Using an FTP client that supports a "change permissions" or "CHMOD" function.  Usually, this is accessible by right-clicking on the file.
  3. Using the QUOTE command from a FTP client (like "QUOTE SITE CHMOD 755 post.cgi")
The numbers are bits that are added together: 4=read, 2=write, 1=execute.  So, all of the combinations are:
  • 0 = no permissions
  • 1 = execute only
  • 2 = write only
  • 3 = write/execute
  • 4 = read only
  • 5 = read/execute
  • 6 = read/write
  • 7 = read/write/execute (full permissions)
The three positions are owner, group, and world permissions.  For example, 755 means full permissions for the owner and read/execute permissions for everybody else.  Use this guide if your FTP client doesn't use the number system.

If you are on an NT system, you don't need to worry about it.  NT systems don't have a way of remotely changing the permissions of a file or directory, so your WHS has made sure there is no way of encountering permission problems.

1.6 What's a CGI-BIN?
You should already know the answer to that, otherwise you have no business using this script.  Most web pages that come with your dial-in account DON'T include a CGI-BIN.  This includes free web pages, such as GeoCities and Tripod.  Most web pages that you pay for (usually called virtual domains) and college accounts come with a CGI-BIN.

Basically, a CGI-BIN is the place where you put your WWW progams.  Anything that interacts with the internet on the server end goes there.  If you don't have one, you can't run any *.cgi, *.pl, *.py, etc. scripts/programs via a browser, including this script.  (Sorry!)

2 Configuration
2.1 How exactly does the user moderation work and when should I use it?
Most boards shouldn't need user moderation.  It was implemented for those really big boards that have problems keeping up with standard administration.  (Though it doesn't hurt to turn it on if you want to experiment with it.)  Both the ignore list and user moderation are ways of giving the users some power over administration.

More information on user moderation can be found on question 4.6 in the Posters' FAQ.

2.2 How exactly do the auto maintenance features work?
All messages are stored in data files, sorted by date.  Any new message gets put into the yyyymmdd.* files.  This date is based off of the current date/time in GMT, so any time past 7 PM EST is considered to be a "new day".

When the first post of the new day hits the script, it starts the auto maintenance processes: deleting, archiving, and compression.  The daily maintenance routine will first delete any old data files from the forum directory.  Then it will run the archiving.

The archive process involves taking all of the yyyymmdd (daily) files and merging them into a yyyymm (monthly) file, and taking all of the yyyymm (monthly) files and putting them into yyyy (yearly) file.  While it's doing this, it will purge any messages marked for deletion, and fix any corruption in the data files (as best as it can).  There is no change in the readability of the messages, merely the way the files are organized.

After the archiving is completed, it will compress any data files with gzip or bzip2, if you have either.  Note that messages can still be read from a compressed database, though it might be slightly slower, due to uncompression overhead.

2.3 What's this about merging together a forum with a mailing list?
The capability to have messages e-mailed through a ML has always existed with the "E-Mail all posts to" option on the configurator.  New in version 2.20 is the ML-to-forum bridge.  It allows you to go in the other direction, and have posts on a ML get put into a forum.  With this, you can have two interfaces to communicate through, as well as have a public archive of your ML.

Setting up the bridge is somewhat easy, but it requires several steps.  First of all, you'll need to reserve a forum for this purpose.  The bridge works on both threaded and non-threaded/flat modes.  (Hybrid and semi-threaded modes might work, but it's not recommended, due to its strange results.)

Go into the directory/file locations and set your ML mailbox file, such as "/var/spool/mail/foobar", or /home/foobar/mailbox".  This is the mailbox file that the bridge will scan for ML messages.  If you leave it blank, the bridge will look for standard input for messages.  This is useful if you're going to use something like procmail to activate the bridge.  (On a side note, the bridge automatically dumps the contents of standard input to standard output for easy piping.)

After this is done, you have to setup the ML forum variables.  First, turn on the switch next to the ML subject search option to turn on the bridge for that forum.  The ML subject search is the phrase usually found on the beginning of all messages like "(foobar)" or "[Foo Bar]".  This phrase is important because RPGBoard will extracted it out of the subjectline, as well as use it for e-mail posts for that forum.  (If you don't have such a phrase, leave it blank.)  The ML to/cc/bcc search is the list of addresses that can be used to post a ML message.  It will search both this list and the subjectline (logical OR) for messages to post.  (If both are blank, it will accept all messages.)  If you want all forum messages to get sent to the ML, fill in the "E-Mail all posts to" option.

Now, you need to setup your system to run the ml2forum.pl program every time you get e-mail.  Recommendations would be either a crontab entry or something in your procmail file.  (No, I'm not going to give you help on either of these details.  Read a man page.)  One thing to note: the ml2forum.pl MUST be in the RPGBoard directory.  Also, the bridge will NOT delete mail for you.  You have to do that yourself to prevent dupes.

2.4 How do I enable RPGBoard to work with multiple language files?
RPGBoard starts out with an English language file.  There are plenty of translations available for RPGBoard, including language files.  These files are named langage_<lang code>.h.  You can either rename it to language.h or leave the filename intact.  The filename is important because the configurator looks for any language files in your RPGBoard directory.  The langage.h is the default language file.  You can keep English as the default language, or you can replace it with another language file, as long as the filename is language.h.  You can also rename the English language file to language_en.h and use another language as language.h, which would make English the second language (instead of the default).

For example, you have the following files in your /cgi-bin/rpgboard directory:

language.h (English)
language_he.h (Hebrew)
language_de.h (German)

In this case, English will be your default language and Hebrew/German will be your secondary languages.  To active these languages, go into your configurator and hit "Check Warnings" or change one of your settings.

3 Migrating to RPGBoard
3.1 How do I migrate from WWWBoard/RPGBoard 1.*?
Forget it!  There are too many differences between RPGBoard v1 and v2, and there's more differences in WWWBoard than I care to list.  Just start a new message board and try to model off of your old one.  It's worth the effort.
3.2 How do I migrate from a previous version of RPGBoard 2?
Just grab all of the latest files and replace your old ones, except variables.h.  It's important that you leave that intact because it contains your forum data.  (Also, don't forget to replace these FAQs, as they get updated all the time.)  You should go into your configurator and check all of the options to see if there is any new features that you want to use.
3.3 How do I migrate from a version before 2.04?
All of the docs go into a "docs" directory now.  Delete your old faq.html and put all of the *.html and *.gif files in the docs directory (which should be created in your MB directory).  Browse to the configurator and change the FAQ location to reflect this change.  (The usual upgrade instructions apply to the *.cgi and *.h files.)
3.4 How do I migrate from a version before 2.20?
There are three major changes to RPGBoard in this version:
  1. All of the files have been renamed.  As such, you'll have to hand edit your index.html and post.html files, as well as your defaults.html.  The following are the name changes you should fix:

    rpgadmin.cgi --> admin.cgi
    rpgbio.cgi --> bio.cgi
    rpgboard.cgi --> post.cgi
    rpgconfig.cgi --> config.cgi
    rpgdefaults.cgi --> defaults.cgi
    rpgheaders.cgi --> viewer.cgi
    rpgmessage.cgi --> viewer.cgi
    rpgsearch.cgi --> search.cgi
    rpgstats.cgi --> stats.cgi

    Remove the following files from your /cgi-bin/rpgboard directory:


    Rename your rpgvariables.h to variables.h.  After all this is done, go into your configurator and change the locations of all of the CGI files.

  2. The post.html SSIs are slightly different.  Change the following:

    <form method=POST action="/cgi-bin/rpgboard/post.cgi?forum">
    <!--#include virtual="/cgi-bin/rpgboard/post.cgi"-->


    <!--#include virtual="/cgi-bin/rpgboard/post.cgi?forum"-->

  3. RPGBoard now uses CSS for its fonts.  As such, you'll need to change a few things in your index.html and post.html files.  For both of them, you'll need to add the following SSI in-between the ending HEAD tag and beginning BODY tag:

    UNIX systems: <!--#include virtual="/cgi-bin/rpgboard/post.cgi?@@CSS@@"-->
    Windows systems: <!--#exec cgi="/cgi-bin/rpgboard/post.cgi?@@CSS@@"-->

You should definately check all of the sections of the configurator for any new options to change screen.
4 Administrating RPGBoard
4.1 What power does an admin have?
There are six types of users:
  • Unregistered users can:
    • Post messages
  • Registered users can:
    • Post messages
    • Change his/her message defaults
    • Delete his/her messages
  • Forum members can:
    • Do anything a registered user can
    • (Technically nothing else, except having higher availability access on the forum s/he's limited to)
  • Forum administrators can:
    • Do anything a registered user can
    • Delete or undelete anybody's messages (including multiple deletions), on the forum s/he's limited to
    • Change the score on a message to anything (between -X and X*2; where X is the default score)
    • Spoof as another user on protected boards, on the forum s/he's limited to (not very useful, but...)
  • MB administrators can:
    • Do anything a forum admin can, except on all of the forums
    • Change anybody's message defaults (including passwords)
    • Change the default message defaults (using the name "!!default"), including the MB admin password
  • Superusers can:
    • Do anything an MB admin can
    • Change the configuration of the MB, including the forum and superuser passwords
    • Edit the ban list
    • Add new forums/backgrounds/etc.
The type of user depends on the password you enter or the password cookies.  (You did remember to change the admin/superuser passwords, didn't you?)
4.2 How do I delete multiple messages at once?
That's what the admin program is for.  To access it, just directly browse to admin.cgi.
4.3 How do I ban a user?
Banning is done on an IP-address basis.  This is the only real way to ban users because names and e-mail addresses can be spoofed.  The ban list is accessable through the configurator.  It's composed of an IP address/number and an optional comment.  A star (*) can be used as a wildcard.  For example:

*.foobar.com          Some loser spamming the board
193.168.*             Mr. Flamer

4.4 How do the passwords work?
There are several different types of passwords:
  • Normal passwords:
    • Changable though the defaults
    • Normal users, MB admins, and superusers can change the password
    • Used to grant normal access for a registered nick
  • Forum member passwords (optional):
    • Changable though the Forum section of the configurator
    • Only superusers can change these passwords
    • Used to grant forum user access for a specific forum
  • Forum admin passwords (optional):
    • Changable though the Forum section of the configurator
    • Only superusers can change these passwords
    • Used to grant admin access for a specific forum
  • MB admin (or master default) password:
    • Changable though the defaults by using the name "!!default"
    • Only superusers and MB admins can change the password
    • Used to grant admin access for an entire MB
  • Superuser (or configurator) password:
    • Changable though the Basic Information section of the configurator
    • Only superusers can change the password
    • Used to grant superuser access for an entire MB

Except for the normal passwords, none of the passwords have any username attached to them.  So, if you want to grant admin access to somebody, all you have to do is give them the password, and tell them to test it somewhere.  (Deleting and undeleting a message is a good test.)  This will store the password cookie, so that they can be reconized as an admin on future visits.

If you're using forum passwords, you might end up with a lot of passwords to deal with.  As the passwords themselves are encrypted, you can't use them as a reference.  The best thing to do is to keep record (in a safe and secure place, mind you) of the passwords and who uses them, because while this script makes managing large MBs much easier, there's still a few things you need to keep track of.

4.5 What's the best way to administrate my message board?
There are a lot of different factors involved in adminstrating a message board, and as a MB admin since 1997, I know what I'm talking about.  The most important factor, however, is popularity.  A message board is not going to get popular if it's too "spacey", and a popular message board just plain isn't going to survive with only one forum.  Here are some general rules to follow, based on popularity:
  • Very small (small group of friends, etc.):
    • Definately only one forum, possibly even a forum set to flat mode.  Administration shouldn't be much of a problem.

  • Small (start-up MB):
    • You should only start with one forum and one admin.  If you start with too many forums, the message population hits the floor and nobody visits the MB.  Instead, start with a "General" forum, and work from there.  Eventually, you'll see the need for a forum split, and your MB will become popular at its own rate.

  • Medium (3-5 forums):
    • Here is where message scanning might become a problem for one user.  The best solution is to find another trusted regular that tends to visit different forums that you do, and give him MB admin access.  Forum admins might be another option, but they aren't really required at this point.

  • Large (7-10 forums, start-up MB for popular sites):
    • Forum admins tend to be helpful at this point, as there are certain people that favor a peticular forum.  Find these people out (through the stats program, if you have to), and figure out which ones should be forum admins.  Generally, one person will handle one or two forums, and they'll do it without really trying, because they frequent that forum anyway.

      A second MB admin might be a good idea, too.  Thus, you would have yourself (a superuser), two MB admins, and your forum admins.  At this point, keeping track of admin/forum passwords is a good idea.

  • Very large (12+ forums):
    • While forum admins can potentially protect an infinate number of forums, you might run the risk of too much power given to too many people, and having too much to keep track of.  For a MB of this scale, you could either ditch the forum administration system entirely in favor of user moderation, or add user moderation as an alternative administration tool for the regulars to use.  The configuration options for moderation are important: about 25% of your regulars should be moderators, and the default score should reflect the total number of moderators.  (Again, use your stats program.)

Forum splits are a tricky thing.  They can make or break the life of a forum.  However, they are basically the only way to create new forums.  The general rule is this: if a forum gets overpopulated with messages of a certain type, it's time for a forum split.  Overpopulation depends on the forum subject, but it's generally when the expire time hits the "2 days ago" mark consistantly (if the forum expire time is set to automatic).  Of course, a chatty forum might have a bunch of small threads, while a more intellectual forum would contain three or four dense threads at a time (this is called "thread density"), so use your best judgment.  Overall, don't be afraid to kill off a new forum if it's not working out, especially if both forums are too slow because of the split.

Enforcement of forum topics should be somewhat strict, especially right after a forum split.  Yes, people may complain, but if you don't do your job, the forums might become unbalanced and cluttered with off-topic messages.  (If it becomes too bad, some people may stop visiting the forums, due to an overabundance of off-topic subjects that they don't care about.)

You should also consider the audience of your forums.  Don't rely on one forum having the same audience as another forum, even if they were the product of a forum split.  Some people might visit your MB exclusively for one forum.  Others might visit one forum for different reasons than you might think.  Therefore, when you split a forum, remember that you may be dealing with a slightly different audience on both forums.

5 Troubleshooting
5.1 I get a Error 500 when I try to run config.cgi!  What gives?
First of all, UPLOAD IN ASCII!!!  I cannot stress this enough because so many people screw up that simple instruction!  Do not, I repeat, DO NOT trust the Auto function on your FTP client!  Manually upload it as ASCII!

Another cause of this problem is that your Perl program may be located in a different location than "/usr/bin/perl".  Try telnetting into the site and type "which perl".  Jot that path down and change the first line of all of the script files (*.cgi) to match it.  For example, if your Perl is located at "/usr/local/bin/perl", you would change the first line to say:


Also, did you forget to chmod your config.cgi?

5.2 When I'm about to post a test message, I don't see any fields!  What's wrong?
Your SSIs aren't working.  Either you forgot to include that .htaccess file (see step #5 on question 1.1) or you can't use the XBitHack option, in which case, you should rename the index.html and post.html files to index.shtml and post.shtml.  If that still doesn't work, you may not be able to use SSIs.  Contact your web hosting service to make sure.

If you have root access to your web server, you may want to check a few Apache config options make your that your SSIs are turned on.  Check your httpd.conf (or other config files, if you have an older version of Apache) for:

AddHandler server-parsed .shtml
AddType text/html shtml

(Of course, this is not a requirement for people using the XBitHack option.)

Also, you should check for Options Include in your <Directory /www/foo/bar/myweb> section.  After all, it isn't going to do anything if the SSIs aren't turned on :)

5.3 The configurator can't create any directories!  What's the problem?
Recheck steps #6-8 on question 1.1.
5.4 Why can't I create/remove any of the message tags?
You need to make sure you add or remove the tag IDs from the tag order field.  If you want to remove the message tags completely, disable the feature on the toggles section.
5.5 The SpellCheck doesn't work and I'm getting a gzip error.  What's wrong?
You probably either grabbed the dictionary file as a text file or uploaded it as text.  If you have WinZIP or gzip, check to see if you can read the file.
5.6 Users are forced to hit reload on everything.  How do I change this behavior?
There are two different things using caches: the HTML files and the CGI scripts.  The HTML files have a couple of META tags in them to keep the browsers from loading the page every single time it's accessed.  (The server normally tells the browser to never cache the page if it has SSIs, but these tags fix that.)  In other words, the page usually won't refresh unless the browser forces a reload, either by hitting reload button or telling the browser to always compare the cache with the server.

This behavior is both good and bad.  It's good because it cuts down on bandwidth by a lot.  It's bad because your users might get a stale copy and would usually have to do a reload to get a fresh one.  If you want to fix this, remove those META tags.  However, doing this would raise your bandwidth usage because people will never use a cached copy of the page.

The CGI scripts (specifically, viewer.cgi) will cache all messages for 15 minutes.  After that period, the browser will re-request the message again.  I feel that 15 minutes is an good period of time to prevent reloads on already-fresh messages, but if you want a way to change this time frame or disable it altogether, let me know and I'll add that as an option on the next RPGBoard.

5.7 My server times out when RPGBoard is trying to preform a yearly archive.  How can I do this manually?
Most web servers have a 30-60 second timeout on connections and this may not be enough time to finish a yearly archive for a large forum.  Because of this, I've included the ability to start the archive process via telnet. You'll need to write a short program as follows:

$cl_archive = 1;
$ENV{'QUERY_STRING'} = "[forum id here]";
do "post.cgi";

Fill in the correct forum ID on the second line.  Save this file (say, "archive.pl") and put it in the cgi-bin/rpgboard directory.  Telnet into your box, enter the cgi-bin/rpgboard directory, and type "perl [filename]" (like "perl archive.pl").  (As a precaution, you may want to disable the exec bit on all of the RPGBoard files temporarily to prevent any damage from users.)

5.8 It looks like anybody can delete anybody else's messages!  What's wrong?
This is caused by a common misconception on how passwords work.  The chances are good that security is fine and it's just the way you are testing security which is wrong.

As an admin, you have an admin password cookie stored on your browser.  Because of this, you can do anything without any need for a user password.  If you type in a incorrect password and one of your password cookies is correct, the cookie will override the bad password.  Therefore, you can look into anybody's defaults, post with anybody's nick, delete anybody's messages, etc., etc.

Everybody else, however, can't do all of those things.  Before asking any other problems involving password security, test it with a regular poster first.  Testing password security as an admin is rather futile.  (Further information about password security is located in question 4.4 of this FAQ.)

6 Features that I won't add
6.1 Why don't you put in an "Edit Message" function?
I put some thought into adding an edit function in the messages.  However, I ran into some problems, both technical and logical.  First of all, people shouldn't be able to edit a message with replies to it.  If they did, they could change the text to suit the argument.  (Similar reasoning for limiting the user delete function to single messages only.)  Two, there is a preview function for the messages.  If you think you need to inspect your message for errors, inspect it before you post, not afterwards.  If you don't think you need to, then other people probably wouldn't care about your typos anyway.  Three, the system is made to add messages as fast as possible by appending to the message and location data files.  (The index file is a different matter, but it's fairly small compared to the message data file.)  So, editing messages would mean either rewriting the entire message data file every time or deleting and adding a new message entry (which would lead to a space-wasting security hole).
6.2 How about putting in the "Re: [Subject]" in the subject line?
No thanks.  I've seen boards with the function on.  It's not pretty.  People are too lazy to change the subject, so it stays as "Re: [Subject]" most of the time.  What's worse is the unchangable subject option on WWWBoard.  It completely defeats the purpose of a threaded message board!  The subject line might as well be useless.
6.3 I want to have a special [background/text font/whatever] just for admins.  Can you put that in?
Nah.  I had a special inverse background for myself coded in the very first release of RPGBoard a while back, but I decided to just go ahead and add the background selection feature in the next one.  If you want to "stand out" as the admin, use a name like "Admin".
6.4 Can you put a "NEW" tag on new messages?
Does anybody ever notice the date color stamping, or is it just me?
6.5 What about an "e-mail password" option for users that forget their password?
That's a great idea, but since the passwords are encrypted, there's no way to decrypt them.  See, all UNIX encryption techniques (including the crypt function on Perl) use a one-way encryption method.  In order to check passwords, the response is encrypted and compared with the encrypted password.  So, no I can't code the script to check and see what password you use.  Not even admins know that information (unless they change it themselves).

However, the password cookies make things easier so you don't have to enter in your password every time.  Yes, you're more likely to forgot your password because of that, but hey...nobody's perfect!

6.6 Why are you so picky about what features get put in the script?
Really I'm not.  In fact, I'm glad to add almost any feature you suggest.  But, I have to force some quality control to make sure it doesn't become bloated with useless features.  At this point, I'm really searching for things to put in the script because I think they are all there :)