Beijing Paradise BBS Backup

home *** CD-ROM | disk | FTP | other *** search

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / ACIDO100.RAR / ACID.DOC next >

Wrap

Text File | 1995-04-13 | 74.3 KB | 1,612 lines

┌───┐ ┌──── ──┌── ┌───┐ ┌│──┐│ ┌│─── ──┌│─ ├│──┐│ ││ ││ ││ ││ ││ ││ ││ ││ ││ ││ ││ ││ │├──┤│ ││ ││ ││ ││ │┴ │┴ │└──── ──┘── │├───┘ ┴ ┴ └──── ──┘── └───┘ ACID - The (A)dapatable (C)alller (I)dentification (D)oor Version 1.00 Documentation for DOS and OS/2 versions By Paul Sidorsky Copyright 1994, 1995 - ISMWare =============================================================================== Table of Contents =============================================================================== 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 What ACID Does . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Why I Wrote ACID . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 DOS And OS/2 Versions . . . . . . . . . . . . . . . . . . . . . 1 1.4 Shareware Notice . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Using This Manual + Quick Install . . . . . . . . . . . . . . . 2 1.6 Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 2 2.0 Explanation Of Terms Used In This Manual . . . . . . . . . . . . . 4 2.1 Caller ID Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 BBS Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Phone Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Verification Terms . . . . . . . . . . . . . . . . . . . . . . 5 3.0 Installation & Configuration . . . . . . . . . . . . . . . . . . . 7 3.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Unpacking ACID . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Configuring ACID . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Installing ACID Into Your BBS . . . . . . . . . . . . . . . . . 9 3.5 Command Line Parameters . . . . . . . . . . . . . . . . . . . . 10 3.6 Errorlevels . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.0 Example Uses For ACID . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Simple CID Protection . . . . . . . . . . . . . . . . . . . . . 13 4.2 Using ACID As A "Sentry" . . . . . . . . . . . . . . . . . . . 15 4.3 Using ACID To Emulate A CBV . . . . . . . . . . . . . . . . . . 16 4.4 The Author's Setup . . . . . . . . . . . . . . . . . . . . . . 18 4.5 Uses For Certain Features . . . . . . . . . . . . . . . . . . . 20 5.0 External Support Files . . . . . . . . . . . . . . . . . . . . . . 22 5.1 ASCII, ANSI, AVATAR, And RIP Files . . . . . . . . . . . . . . 22 5.2 Other External Files . . . . . . . . . . . . . . . . . . . . . 23 6.0 Final Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1 Plans For Future Versions . . . . . . . . . . . . . . . . . . . 25 6.2 How To Contact The Author . . . . . . . . . . . . . . . . . . . 25 6.3 Where To Get ACID . . . . . . . . . . . . . . . . . . . . . . . 25 6.4 Credits And Acknowledgements . . . . . . . . . . . . . . . . . 26 =============================================================================== 1.0 - Introduction =============================================================================== Security is an important concern for most, if not all, BBS sysops. Up until recently, Call Back Verifiers (CBVs) were the only means available to verify a user. Unfortunately, CBVs aren't reliable. Anybody who wants to bypass one can do so with ease. So, sysops are seeking new, more reliable means of verifying their users. Somewhat recently, the phone companies have been introducing services like Call Display, which let you see who's calling you before you even answer the phone. This lead to the development of Caller ID (CID) modems, which can take this information and send it to your computer, just like a modem result code. Caller ID is the ultimate BBS user verification tool. Since the CID information is usually dumped into a log (for example, by a mailer like BinkleyTerm), sysops can maintain a complete trace log of who calls their system, and when. 1.1 - What ACID Does ACID takes the information from this log and uses it to regulate access to your system. You can use it every time a caller logs on to verify the person using the account is the "right" person, or you can just use it for new users to upgrade their access. Either way, you maintain complete control over who accesses your system. 1.2 - Why I Wrote ACID A few months ago, a user I knew shockingly demonstrated to me how easily he could bypass a CBV. Fortunately for me, I was about to purchase a new modem with Caller ID, so I didn't have to worry for too long about security breaches. Once I got this modem and was hooked up to my phone company's Call Display service, I looked around for Caller ID software, but nothing suited my needs. So, I wrote ACID. I'm releasing it as shareware in the hope that others will find it as useful as I do. 1.3 - DOS And OS/2 Versions ACID comes in two versions: DOS and OS/2. The DOS version works with BBS systems running under DOS. The OS/2 version will work with OS/2-based BBS systems, or with DOS-based BBS systems running under OS/2. It is recommended that if you are running a DOS-based system under OS/2 that you use the OS/2 version of ACID, because the OS/2 version is faster and more friendly to your system. However, you can use the DOS version under OS/2 without problems, if you wish. In this manual, where differences between versions exist, they will be referred to specifically. The DOS version will be referred to as ACID/DOS, and the OS/2 version as ACID/2. Otherwise (if the version isn't specified), the information applies to both versions. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 1 1.4 - Shareware Notice ACID is a shareware program. You are permitted to use it for a 30 day trial-period without charge. After this period, you are required to register your copy with the author. For more information on registration and how to register, see the file named REGISTER.DOC that came in the ACID archive. The complete shareware licence, along with distribution restrictions, can be found in LICENCE.DOC. Please be sure to read this files so you do not inadvertantly break the licence. Remember, though shareware programs are usually freely distributable, you must still follow the guidelines set forth by the program author. 1.5 - Using This Manual + Quick Install This manual is written with a "top-down" approach, which means that the easiest way to read it is to start at the top and read every section in order until you get to the end. Doing this will give you an intimate knowledge of all of ACID's uses, features, and operation requirements. However, that is not the only way to use this manual. The reading of certain key sections will give you enough knowledge to install ACID successfully and effectively into your system. If you're in a hurry and don't want to read this entire manual, it is recommended you read/skim the following parts of this manual, in the order listed: 1) The entire chapter called "Explanation Of Terms Used In This Manual" so you know what certain terms mean. 2) The entire chapter entitled "Installation And Configuration". 3) The example section called "Simple CID Protection". 4) The entire chapter entitled "External Support Files". If you are having problems with ACID, please consult this manual before contacting the author. Though I will answer questions no matter how common or redundant they are, I don't take kindly to people not reading things before asking, so please check the manual first. Besides, the more informed you are about ACID, the easier solving problems will be. 1.6 - Compatibility Issues ACID was written and tested using RemoteAccess 2.02+, BinkleyTerm 2.59a, a SupraFAXModem 288e, and Caller ID services provided by AGT in Calgary, Alberta, Canada. Unfortunately, because Caller ID in the BBS world is relatively new, it is hard to obtain information on how various modem manufacturers implement the reporting of Caller ID information to the computer. So, I've done the most logical thing. I went ahead and wrote ACID with the information I have, and made it as configurable as possible to allow for possible minor diffferences. However, it's possible ACID may still not be compatible with some modems, and this is something I want to fix ASAP. So if you find ACID won't work for you as it is now, _PLEASE_ tell me so I can remedy this! If you report incompatibility issues to me, I will likely be able to correct them WITHIN A =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 2 FEW __HOURS__! I'm not afraid to release three or four updates right off the bat to resolve these kinds of problems, so please tell me about them rather than giving up on ACID. The most likely incompatibility will be that a certain modem does not displaying information in the predicted way. ACID expects to find one item of CID info on each line, and expects each item to be prefixed by a header, like this: DATE = 0327 TIME = 1234 NAME = SIDORSKY PAUL NMBR = 4036860449 The actual CID information is not important, but the way it is identified is. For example, ACID would not work with a modem that provided the CID information all on one line. If you find a problem like this, or any other problem that you can't solve by changing the configuration settings, please contact me using one of the means described in the section called "How To Contact The Author". As I said above, I can probably correct the problem within hours and release a new version the same day. I'll also send you the new release at my own expense as a thank you for reporting the problem (sorry, no free registrations though...<grin>). Naturally, suggestions and comments are also welcome. Please send them to me as described above. I'm especially interested to hear if you have successfully implemented ACID with modems or phone companies other than the ones I've been able to test ACID with (as described above), and how you did it. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 3 =============================================================================== 2.0 - Explanation Of Terms Used In This Manual =============================================================================== In order to make both reading this manual and setting up ACID easier, this manual frequently refers to certain terms. This chapter defines these terms. In addition, it also tells what ACID does in relation to these terms, to make the context of their use more apparent. Think of this chapter as a glossary. NOTE: Although in this chapter, the terms appear in quotation marks for clarity, the do not appear in quotation marks throughout the rest of this manual. 2.1 - Caller ID Terms "Caller ID", "CID" - Stands for "Caller IDentification". This is what a modem or phone reads between the first and second rings of a phone call, and tells you or the modem who is calling. "CID Information", "CID Info." - This refers to the text that your modem sends to the computer one it has detected and read the Caller ID. Usually, this text shows up in a log file generated by your mailer or BBS software. In fact, ACID currently needs this information to be in a log file in order for it to work properly. "CID Date", "CID Time", "CID Name", "CID Number", "CID Message(s)" - These terms all refer to the various information given by the CID Info. "CID Date" and "CID Time" are the date and time that the call was registered, respectively. "CID Name" is the name of the person calling as given by the CID Information. "CID Number" is the phone number of the person calling, as given by the CID Info. A "CID Message" is a part of the CID Info. which your modem cannot parse, so it is passed directly to the computer. My modem calls these "Messages", hence their name in this manual. "CID Log" - The log file that ACID reads to find the CID Info. Not to be confused with ACIDCID.LOG, which is the file that ACID uses to log all of the CID Info. after it has been read. 2.2 - BBS Terms "BBS Door", "Door" - A seperate program not part of the BBS software, which must be run within a "shell". ACID is a BBS Door. "Drop File" - This is a file that your BBS software writes to tell external doors, such as ACID, information about the user currently logged on. Examples include DORINFOx.DEF and DOOR.SYS. "Local Mode", "Run(ning) Locally" - Not to be confused with a "Local Call". These terms refer to ACID being run either using COM0 or a 0bps rate. This always occurs when, say, you or somebody else is logged on locally and is typing into the computer from which the BBS is run off of. Since no phone call occurs in "Local Mode", ACID simply displays a message and exits without =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 4 performing any kind of verification. 2.3 - Phone Terms "Area Code" - A phone code that designates the area you are calling from. This is three digits in North America, and has variable lengths elsewhere. "Phone Number", "Number" - A user's phone number. Usually this refers to a phone number PLUS the "Area Code", but this is not always so. When just the phone number is being referred to, this will be mentioned in the appropriate section. "Local Call(er)", "Calling Locally", "Local" - Not to be confused with "Local Mode". These terms refer to a caller who is calling from inside the geographical "Local Calling Area". That is, the area to which you can dial calls from your BBS's number(s) without paying any extra charges. The opposite of a "Local Call", is, of course, a "Long Distance" call. Note that the term "Local" on its own is only used when it is clear that the call type is being discussed. "Long Distance Call(er)", "LD Call(er)", "LD" - These terms refer to a caller who is calling from outside your local calling area, i.e. somebody calling outside of your "Local Calling Area". Often, this caller will not have the same area code as yourself, but this is not always the case. 2.4 - Verification Terms "Action" - This term refers to the action that is performed by ACID in a certain situation. The configuration keywords that end in Action control these "Actions". "Good Call(er)", "Okay Call(er)" - These terms refer to when a caller passes the verification process. If the caller's name and/or number is not "Duplicate", "Bad", or "Mismatched", the caller is presumed to be "Good" or "Okay". Unless "Local" or "Long Distance" calls are mentioned specifically, these terms refer to both types of calls. The words "Good" and "Okay" may also be applied to the user's name or phone number, which means that the specific item has passed verification as described above. "Unknown Call(er)" - This term refers to when ACID cannot get the phone number from the CID Info. but the CID Info. is already present. Usually this means that the area the person from calling from does not yet have CID service. This manual will also refer to "Unknown Name" and the "Unknown Message". Both mean that the name or message (respectively) is unknown. Note that for "Unknown Message", this does not mean a message ACID doesn't recognize, but instead means the message that signifies an Unknown Name. However, only callers with an "Unknown Number" will be treated as "Unknown". "Private Call(er)" - This term is similar to "Unknown Call(er)", but instead means that ACID has got the CID info. and found certain parts to be private, or "blocked". As with "Unknown", only a "Private Number" will actually mean the call will be treated as "Private". "Mismatched Call(er)", "Mismatch" - These terms mean that the CID Number did not match one of the phone numbers listed in the user's account =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 5 information. This is only applicable if the drop file you are using can pass this information to ACID. "Duplicate Call(er)", "Duplicate Number", "Dupe" - This term refers to when ACID encounters a duplicate caller. A duplicate caller, or "Dupe" for short, is a caller who has a "Duplicate Number". Duplicate numbers are detected by matching the phone number in the CID Info. to the numbers contained in ACID.DUP. If a match occurs, the caller is considered a dupe. Dupe callers are also detected by looking through ACIDUSER.DAT. If a number occurs in more than one user record, the caller is considered a dupe. "Bad Call(er)", "Bad Name", "Bad Number", "Bad" - This term means that ACID has determined the caller to be "Bad", i.e. the caller has failed verification. Detection of either a "Bad Name" or "Bad Number" means that the caller will be considered "Bad". A "Bad Name" is detected by matching both the CID Name and the user's login name to the info. in ACIDNAME.BAD. If a string in ACIDNAME.BAD occurs in either of the above names, the caller has a "Bad Name". "Bad Numbers" work the same way, but use ACIDNMBR.BAD for detection instead. Also, only the CID Number will be used when checking for a "Bad Number". "Good After" - This term occurs either in "Good After Bad" or "Good After Mismatch". It refers to a user who's last call was either "Bad" or a "Mismatch", but is now "Good", i.e. has now passed verification. Note that if the Action for a "Good After" call is defined a certain way, the "Goodness" of the current call may be cancelled out, which is handy if you don't want people to be able to call after having either a Bad or Mismatched call. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 6 =============================================================================== 3.0 - Installation & Configuration =============================================================================== Installation of ACID consists of three steps: 1) Unpacking the archive. 2) Configuration. 3) Installation in your BBS. The following sections will guide you through these steps. 3.1 - System Requirements To use ACID, you will require the following: Hardware: - An 8086 or compatible computer. - A hard drive, and about 256kB of free hard drive space. - A modem capable of processing Caller ID information. Software: - If you're running ACID/DOS, you need an operating system fully compatible with MS-DOS 3.3 or higher, such as MS-DOS, PC-DOS, or OS/2. Your BBS software must run under DOS. - If you're running ACID/2, you need OS/2 version 2.0 or above. Your BBS software can run under OS/2 in native mode, _OR_ under DOS in an OS/2 VDM session. - BBS software capable of producing one of the following drop files: DORINFOx.DEF, DOOR.SYS, EXITINFO.BBS, CALLINFO.BBS, SFDOORS.DAT, CHAIN.TXT. If you want to use ACID's security alteration capability, the BBS must be able to reread one of the above drop files (except for DORINFOx.DEF or CALLINFO.BBS, which are _NOT_ updated by ACID). - A working BBS that can capture Caller ID information in a log file. Many BBS programs capture and log input from the modem. If your BBS does not do this, most front-end mailers do. - ACID/DOS requires a FOSSIL driver for communication with the modem. Most DOS BBS programs use a FOSSIL driver already, so this should not be a problem. For those that don't, FOSSILs can usually be run temporary inside a shell from the BBS. Consult the FOSSIL documentation for more details. - If you wish to run ACID/2 in conjunction with a DOS BBS, you need a program called OS2EXEC. This program is available from the author's system, as well as many many other systems with OS/2 files. Other: - You will also need a Caller ID compliant service from your phone company. In my area this service is called Call Display, but it may have different names elsewhere. If you're in doubt, check with your phone company about =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 7 a service that lets your phone display who's calling before you answer the phone. 3.2 - Unpacking ACID The first step to installing ACID is to unpack the ACID archive. You've probably already done this, but in case you haven't, here's how: 1) Create a new directory for ACID. 2) Change to this directory. 3) Unpack the ACID archive, which is named ACIDD100.* for ACID/DOS and ACIDO100.* for ACID/2. The extension will be different depending on which archiver ACID has been compressed with. For unpacking instructions, see the documentation for the required archiver. ACID does not _need_ its own directory, but having one is recommended. If you don't wish to do this, however, you can unpack ACID*.* from the ACID archive to whatever directory you wish. Then if you ever want to uninstall ACID, all you need to do is delete ACID*.*. Users of ACID/DOS can move onto the next step now. Users of ACID/2, however, have one additional small step. Copy DRS2V2B3.DLL to a directory on your OS/2 LIBPATH. The recommended directory is \OS2\DLL. DRS2V2B3.DLL is the Doors/2 Dynamic Link Library, which ACID/2 uses for its communications, keyboard input, and screen output. Doors/2 is a multithreaded, 32-bit library, so execution speed is lightning fast. The reason for copying DRS2V2B3.DLL to \OS2\DLL is so that other doors which may need the Doors/2 DLL can find it automatically. There are an increasing number of OS/2 doors written with Doors/2, so it is very likely that a door you get in the future will need this DLL. By using a DLL, we door authors don't need to include the door code in our executable files, which means you save lots of space because you only have one copy of the door code on your hard drive. For every Doors/2 door you run, you save between 100 and 200 kilobytes. If you're running ten Doors/2 doors, then that's over a megabyte (and as much as 2MB) of space saved! For information on how to get other doors written using Doors/2, see the section entitled "Where To Get ACID". 3.3 - Configuring ACID First of all, rename the file called SAMPLE.CFG (which is distributed in the ACID archive) to ACID.CFG. This is the configuration file that ACID uses. It will be referred to as ACID.CFG from this point on. The reason the file is distributed as SAMPLE.CFG is so people upgrading to new versions of ACID will not accidentally overwrite their configuration files, which is something the author has had happen a few times with other programs. <grin> To configure ACID, load ACID.CFG into an ordinary text editor. DOS's EDIT.EXE or OS/2's E.EXE will work fine. Once this file is loaded, edit the keyword settings to suit your needs. The settings described in ACID.CFG are fully commented (self-documented), and you should have no problem with them. However, you might wish to read the chapter entitled "Example Uses For ACID" to get an idea of how to set ACID up to perform certain tasks. If you know what your verification needs are, though, then this isn't neccessary. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 8 For those who prefer configuration programs to ASCII configuration files, please bear with me for this release. I don't like ASCII config. files either, and an editor will be included in a future release. A configuration editor is in the works, but I have to register the toolkit that I'm using to help create it before I distribute it, otherwise I could run into legal trouble. <grin> In the meantime, don't let the size of ACID.CFG scare you. There is not very much to actually configure (most of it is just descriptions), and many of the keywords have the same possible settings. There is one optional (but highly recommended) step to configuring ACID, and that is editing the External Support Files. You will almost certainly want to edit the files that ACID displays to the user. Instructions for doing this is described in the section entitled "ASCII, ANSI, AVATAR, And RIP Files" which appears in chapter four of this manual. Information on the other external files and whether you should edit them appears in the section called "Other External Files", also in chapter four of this manual. 3.4 - Installing ACID Into Your BBS !!!BEFORE YOU BEGIN!!! - If you are running ACID/2, BE SURE TO READ THE INFORMATION IN THE LAST TWO PARAGRAPHS OF THE SECTION CALLED "Unpacking ACID"! If you don't do this, ACID may fail to work correctly! For the most part, you install ACID into your BBS like you would any other door. However, consider these things when deciding where and how to run ACID: 1) ACID looks for its configuration and data files in the same directory that ACID.EXE is located in, and will look for door drop files in the current working directory. For this reason, you need only to call ACID directly from your menus, like so: \RA\PROGS\ACID\ACID.EXE \RA\PROGS\ACID is the directory that you unpacked ACID to. Also, if you're using ACID/2, change ACID.EXE to ACID2.EXE, and be sure to read the section entitled "Command Line Parameters" for further !!!IMPORTANT!!! installation information. People using ACID/2 with DOS-based BBS programs should consult the documentation for OS2EXEC to find out what modifications are needed to the command line that runs ACID/2. No batch file is needed unless you wish to use one. If you do, you're on your own, though the batch file you use for ACID probably won't be much different than one you use for any other door. 2) If you are running a BBS that can _reread_ one of the drop files listed below upon returning from a door shell, and wish to use ACID's user verificiation capabilities, you need to make sure that ACID is not prevented from rewriting the drop file. ACID will rewrite the drop file in the same place that it reads it from (using the same name), so usually this will not be a problem. You must also make sure that the rewritten version of the drop file is placed (either directly by ACID or by a COPY command) in the right location, i.e. the path your BBS expects to find it in. If this is not =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 9 the case, your BBS may fail to recognize any changes made by ACID, and verification will be useless! The drop files that ACID will write upon exit (for rereading by your BBS) are: DOOR.SYS, EXITINFO.BBS (QBBS 2.6x and 2.7x, and RA 1.xx and 2.xx versions), SFDOORS.DAT, and CHAIN.TXT. 3) Nearly all of the time, you'll want ACID to run automatically, rather than have the user press a key to activate ACID. This gives the maximum amount of security because there is no way the user can avoid going through verification. However, this is not a requirement, and whether or not you run ACID automatically depends on how you want to use it. You also need to decide whether you'll be running ACID each time a user calls, only when new users call, or somewhere else to suit your individual needs. This will affect which menu(s) you run ACID from, and is important in getting ACID to work properly. The example uses, described in the chapter called "Example Uses For ACID", will guide you in deciding where and how to run ACID. Finally, be sure to consult the section entitled "Command Line Parameters" so you know what to put on the command line. As mentioned above, THIS IS OF PARAMOUNT IMPORTANCE IF YOU ARE RUNNING ACID/2!! 3.5 - Command Line Parameters This section describes the command line parameters than can be passed to ACID. There are different parameters for ACID/DOS and ACID/2, as well as some common parameters used by both versions. Both versions of ACID support this parameter: /NODExx This parameter is used to set the node number. Replace xx with the actual node number, and do not put a space between /NODE and the number. You need this parameter if you are running a multinode system, and are using a drop file that does not contain the node number, such as DORINFOx.DEF. It is optional on single-node systems, and on multinode systems that use drop files with the node number in them. This is the only special requirement for multinode operation. ACID/DOS will automatically detect if SHARE.EXE is in use, and use file sharing if SHARE compatibility is found. ACID/2 will always use file sharing, because OS/2 has it built in. ACID/DOS has no additional command line parameters. If you are running ACID/2, there are three additional command line parameters that you may or may not need to use, depending on your system requirements. These are described below. The case (upper or lower) of these parameters is unimportant, as is the order that they appear in. /PORT The /PORT parameter is used to tell ACID/2 to expect a comport number, rather than a communications handle (which ACID/2 expects by default). Maximus/2 is the only system I am aware of that =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 10 passes a comm handle, so you will most likely need this parameter. Consult your BBS manual for more details. NOTE: If you are running a DOS-based BBS and using ACID/2, BE SURE TO INCLUDE THIS PARAMETER! /NICE ACID/2 can use one of three different priorities: Nice, Normal, and Nasty. The Normal priority is used by default, and should suit most systems. The /NICE parameter invokes Nice (low) priority, which will suit any system that uses all-OS/2 software and is not strained heavily (by you doing other work in the foreground, etc.). Nasty mode is described along with the /NASTY parameter below. /NASTY This parameter invokes Nasty (high) priority. If you run a lot of CPU-hogging software, you may need the /NASTY parameter. DOS doors are notorious for hogging the CPU, as are applications that do a lot of computations or disk I/O. 3.6 - Errorlevels ACID exits with certain errorlevels, depending on the situation it encountered. This allows you to react to what ACID read from the CID informatiomn in a batch file, and respond to it with other programs and such. The errorlevels ACID uses are as follows: Errorlevel | Meaning ------------+-------------------------------------------------------------- 0 | No action taken. Should only occur if ACID is run locally. * 1 | The CID info was not found. Appropriate action was taken. * 2 | Caller was local and passed verification. * 3 | Caller was long distance and passed verification. * 4 | Caller was local and treated as unknown. * 5 | Caller was long distance and treated as unknown. * 6 | Caller was local and treated as private. * 7 | Caller was long distance and treated as private. * 8 | Caller had a dupe. number and was under the max. dupe limit. * 9 | Caller had a dupe. number and the dupe limit was reached. * 10 | Caller was a bad caller and no maximums have been reached. * 11 | Caller was bad and the consec. bad call limit was reached. * 12 | Caller was bad and the total bad call limit was reached. * 13 | Caller had a number mismatch and no maximums were reached. * 14 | Caller had a number mismatch & the consec. limit was reached. * 15 | Caller had a number mismatch and the total limit was reached. * 16 | Caller passed verification after a previous bad call. * 17 | Caller passed verification after a previous number mismatch. 100 | ERROR - Can't create/load user record. 101 | ERROR - Can't react to the situation. 102 | ERROR - Can't open a needed file. 200 | User hung up. Normal verification was still completed. 201 | Sysop hung up the user with Alt-H. Verification was done. 202 | User ran out of time. Normal verification was still done. 203 | User was inactive too long. Verification was still done. 204 | Sysop ejected user with Alt-D. Verification was done. 255 | Critical door error (no drop file, etc.) =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 11 * These errorlevels correspond directly to the Action keywords in ACID.CFG. The LAST action performed determines the errorlevel that will be used. See ACID.CFG itself for more information on these keywords. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 12 =============================================================================== 4.0 - Example Uses For ACID =============================================================================== This chapter details some example uses for ACID in real-life situations. You can duplicate the examples exactly as explained here, or use them as guidelines for your own system's needs. In the examples to follow, the following security levels are used/assumed: 5 - "Twit" (bad) user. Can only leave a message to sysop or logoff. 10 - New user. The level granted to users when they sign up. 25 - Limited access user. Limited access to file areas and some other unimportant BBS functions (configuration menu, etc.). 50 - Fully verified user. For all of the examples, it is also assumed that you do NOT allow users to change their phone numbers (via a BBS menu). This decreases the chances of users being able to bypass some of ACID's actions by altering their phone numbers. While this isn't necessary to run ACID, it is HIGHLY recommended. All of the sample configurations can be copied directly and used as ACID.CFG. You will obviously have to make minor changes to the securities and paths so suit your needs, but not much more. 4.1 - Simple CID Protection This example shows how to use ACID in a simple, effective way. It deals fairly leniently with all callers, and upgrades good callers. The sample .ASC files included with ACID are to complement this example setup. The SAMPLE.CFG file (also included with ACID) contains the settings listed in this section. Since this example uses user security altering, you need to have a BBS capable of rereading its drop files. More information on this is described above in the section called "Installing ACID Into Your BBS". To use this example effectively, you need to run ACID every time a user calls your system. The CID strings use work with a SupraFAXModem 288e, and the mailer used is BinkleyTerm 2.59a, though the mailer does not matter very much, as it only affects the first two settings. The BBS used is RemoteAccess. The ACID.CFG settings for simple CID protection are as follows: ACIDPath D:\RA\PROGS\ACID\ CIDLog D:\RA\BINKLEY.LOG CIDLogScanBytes 275 CIDChangeUnderscores Yes CIDStartString DATE_=_ CIDAreaCodeLength 3 CIDPhoneNumberLength 7 CIDYourAreaCode 403 CIDDateString DATE_=_ CIDTimeString TIME_=_ =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 13 CIDNameString NAME_=_ CIDNumberString NMBR_=_ CIDMessageString MESG_=_ CIDNameUnknown Unknown_Caller CIDNamePrivate Private_Caller CIDNumberUnknown O CIDNumberPrivate P CIDMessageUnknown 08014F CIDMessagePrivate 080150 CIDMessageLongDist 06014C MandatoryInfoItems Date Time Number InfoNotFoundAction HangUp OkayAction Security>50 LDOkayAction Security>50 UnknownAction Security=25 LDUnknownAction Security=25 PrivateAction Security=25 LDPrivateAction Security=25 MaxDupeCallers 1 MaxDupeAction Security=25 MaxConsecBadCalls 3 MaxTotalBadCalls 5 MaxConsecMismatchCalls 5 MaxTotalMismatchCalls 100 FirstBadCallAction Security=25 MaxBadCallAction Security=5 FirstMismatchCallAction None MaxMismatchCallAction Security=25 Force GoodAfterBadAction Security=25 Force GoodAfterMismatchAction Restore AddAllNumbersToLogs Yes StorePhoneNumbers Data Voice This example has the following characteristics: - The CID info is in BinkleyTerm's log. - CID strings for the SupraFAXModem 288e. - The phone number lengths used are for the North American format. - Standard user security upgrading if the verification is good. Because ACID is run with every call in this setup, the security is not changed if it is higher than 50. Otherwise, callers with special access would lose this access each time they call! - Unknown and Private callers get limited access, presumably until you can verify them more thoroughly. - Two callers from each number are allowed. This allows for, say, a brother and sister to call from the same number without hassle. - Further duplicates get limited access so you can deal with their situation on a case-by-case basis. - Bad callers are given limited access (so they can "plead their case") for a short time, then are downgraded to Twit access. - Mismatches are not considered a major offence. Five consecutive mismatches are tolerated, after which a user's access will be lowered, just in case. Good calls after a mismatch restore the user's security to what it was. - Good calls after a Bad call will be granted limited access. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 14 - Data & Voice phone numbers are stored for dupe detection. The CID number is not stored for simplicity's sake. This setup should work for most leisure BBSs where problem users are rare and verification is little more than a formality or form of insurance. It is pretty straightforward (after reading the keyword descriptions in ACID.CFG), and can be easily modified in many ways to suit your needs. 4.2 - Using ACID As A "Sentry" This setup shows how to use ACID if your BBS can't reread drop files (as described under "Installing ACID Into Your BBS"), or if you don't need ACID's user security manipulation features and just want something to guard against bad callers. It is probably the easiest type of setup, because many of the settings can be ignored entirely. In this setup, ACID should be run every time a user calls, but _can_ be run just once (for new users) using the same settings. The CID strings used are again for a SupraFAXModem 288e. BinkleyTerm 2.59a is again the mailer, and RemoteAccess is the BBS software. This setup should work with nearly any BBS/mailer combination, though, because it does not need any complicated drop file information, and does not need to have the BBS reread the drop file. The settings for "sentry" mode are: ACIDPath D:\RA\PROGS\ACID\ CIDLog D:\RA\BINKLEY.LOG CIDLogScanBytes 275 CIDChangeUnderscores Yes CIDStartString DATE_=_ CIDAreaCodeLength 3 CIDPhoneNumberLength 7 CIDYourAreaCode 403 CIDDateString DATE_=_ CIDTimeString TIME_=_ CIDNameString NAME_=_ CIDNumberString NMBR_=_ CIDMessageString MESG_=_ CIDNameUnknown Unknown_Caller CIDNamePrivate Private_Caller CIDNumberUnknown O CIDNumberPrivate P CIDMessageUnknown 08014F CIDMessagePrivate 080150 CIDMessageLongDist 06014C MandatoryInfoItems Date Time Number InfoNotFoundAction HangUp OkayAction None LDOkayAction None UnknownAction None LDUnknownAction None PrivateAction HangUp LDPrivateAction HangUp MaxDupeCallers 9999 =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 15 MaxDupeAction None MaxConsecBadCalls 1 MaxTotalBadCalls 1 MaxConsecMismatchCalls 9999 MaxTotalMismatchCalls 9999 FirstBadCallAction HangUp MaxBadCallAction HangUp FirstMismatchCallAction None MaxMismatchCallAction None GoodAfterBadAction None GoodAfterMismatchAction None AddAllNumbersToLogs Yes StorePhoneNumbers All This example has the following characteristics: - The CID info is in BinkleyTerm's log. - CID strings for the SupraFAXModem 288e. - The phone number lengths used are for the North American format. - Okay and Unknown callers are considered harmless and allowed. - Private callers are considered unwanted and hung up on. - Duplicate callers are permitted gratuitously. - Bad callers are immediately dumped off the system. - Mismatches are a non-issue, because it's assumed that the phone number is not available in the drop file. - Good callers are always allowed, even if the user was previously calling from a bad number. - All numbers are stored. This is done simply for your own convenience, as duplicate callers are not an issue here. This example is obviously extremely lenient, but still very effective, because it completely shuts down unwanted users. There are many ways to modify this setup to be more "tough". For example, duplicate users could be protected against. Also, if your BBS can write a drop file that contains phone number(s), you can use ACID's mismatch detection features. DOOR.SYS is one of the more popular drop files that has phone numbers in it. You can also deal with Unknown and Long Distance callers differently if you need to. The possibilities are many, and this isn't even using ACID to it's full potential! 4.3 - Using ACID To Emulate A CBV ACID can emulate a CBV (CallBack Verifier) with regard to how it behaves. CBVs, as you probably know, are a one-time method of verifying a new user. Most CBVs also have support for Bad User and Dupe User detection, but do not do much more than toss them off the system or deny them verification. This setup will make ACID behave more-or-less like a CBV, which is handy if you just want to use ACID as a drop-in replacement for your CBV. You will natually need to be able to upgrade the user's security, so be sure your BBS can reread its drop file, as described in the section called "Installing ACID Into Your BBS". Again, because it's the only CID modem I have access to, the CID strings are for a SupraFAXModem 288e. The mailer used is BinkleyTerm 2.59a, though that really doesn't matter very much. With this setup, ACID should only be run =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 16 once, typically from a new user menu. You can choose to run ACID automatically, or have the user select "Verification" from a menu and run ACID from there. Here are the settings to use to mimic a CBV: ACIDPath D:\RA\PROGS\ACID\ CIDLog D:\RA\BINKLEY.LOG CIDLogScanBytes 275 CIDChangeUnderscores Yes CIDStartString DATE_=_ CIDAreaCodeLength 3 CIDPhoneNumberLength 7 CIDYourAreaCode 403 CIDDateString DATE_=_ CIDTimeString TIME_=_ CIDNameString NAME_=_ CIDNumberString NMBR_=_ CIDMessageString MESG_=_ CIDNameUnknown Unknown_Caller CIDNamePrivate Private_Caller CIDNumberUnknown O CIDNumberPrivate P CIDMessageUnknown 08014F CIDMessagePrivate 080150 CIDMessageLongDist 06014C MandatoryInfoItems Date Time Number InfoNotFoundAction HangUp OkayAction Security=50 Log LDOkayAction Security=50 Log UnknownAction HangUp LDUnknownAction HangUp PrivateAction HangUp LDPrivateAction HangUp MaxDupeCallers 0 MaxDupeAction HangUp MaxConsecBadCalls 1 MaxTotalBadCalls 1 MaxConsecMismatchCalls 3 MaxTotalMismatchCalls 10 FirstBadCallAction HangUp MaxBadCallAction HangUp FirstMismatchCallAction HangUp Force MaxMismatchCallAction HangUp Force GoodAfterBadAction None GoodAfterMismatchAction None AddAllNumbersToLogs No StorePhoneNumbers None This example has the following characteristics: - The CID info is in BinkleyTerm's log. - CID strings for the SupraFAXModem 288e. - The phone number lengths used are for the North American format. - Standard user upgrading is granted if the verification is good. ACID is =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 17 only run once with this setup, so the security level is forced to 50, which is what most CBVs do. - Unknown, Private, Duplicate, Bad, and Mismatch callers are treated as failed verifications and hung up. Most CBVs do not downgrade users, so no security alteration is performed. - Only the verified number is logged, which is what most CBVs do. No phone numbers are stored in the user file, because ACID.DUP is a simpler way of detecting dupes. Remember, this example is intended more to duplicate a CBV, and not for optimum security. Furthermore, it does not take very much advantage of ACID's features. Because of this, however, it is VERY simple to set ACID up this way. All you will probably need to do is copy the above settings into ACID.CFG and make slight alterations to your existing CBV batch file. I recommend this setup if you don't have much time and want to take immediate advantage of CID verification in the simplest and fastest way. You can always come back later and modify the settings to take advantage of ACID's more advanced features. 4.4 - The Author's Setup This is the exact setup that I myself use on my BBS, and thus it's naturally the one I recommend using. It provides maximum security against blacklisted callers. It also grants limited access to Long Distance callers so they can download files (like) that I distribute for myself and other authors. The modem I use is a SupraFAXModem 288e, and the mailer I use is BinkleyTerm 2.59a. My BBS software is RemoteAccess, so ACID will detect and use EXITINFO.BBS, and RA will read it back, thus allowing the security changes to take effect. I run ACID automatically when each caller logs on, right before the Main Menu is displayed. I suggest you run it even earlier if you can, right after the user enters his/her password if possible. The Main Menu is just the easiest place for me to run it, so I have it there instead. Here are the configuration settings I use: ACIDPath D:\RA\PROGS\ACID\ CIDLog D:\RA\BINKLEY.LOG CIDLogScanBytes 275 CIDChangeUnderscores Yes CIDStartString DATE_=_ CIDAreaCodeLength 3 CIDPhoneNumberLength 7 CIDYourAreaCode 403 CIDDateString DATE_=_ CIDTimeString TIME_=_ CIDNameString NAME_=_ CIDNumberString NMBR_=_ CIDMessageString MESG_=_ CIDNameUnknown Unknown_Caller CIDNamePrivate Private_Caller CIDNumberUnknown O CIDNumberPrivate P CIDMessageUnknown 08014F =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 18 CIDMessagePrivate 080150 CIDMessageLongDist 06014C MandatoryInfoItems Date Time Number InfoNotFoundAction Hangup OkayAction Security>50 LDOkayAction Security>50 UnknownAction Security<25 LDUnknownAction Security<25 PrivateAction Security=5 Hangup LDPrivateAction Security<25 MaxDupeCallers 0 MaxDupeAction Security=25 MaxConsecBadCalls 1 MaxTotalBadCalls 1 MaxConsecMismatchCalls 3 MaxTotalMismatchCalls 10 FirstBadCallAction Security=5 Hangup MaxBadCallAction Security=5 Hangup FirstMismatchCallAction Security=25 Force MaxMismatchCallAction Security=25 Force GoodAfterBadAction Security=5 Hangup Force GoodAfterMismatchAction Restore AddAllNumbersToLogs Yes StorePhoneNumbers Data Voice This example has the following characteristics: - The CID info is in my BinkleyTerm log. - CID strings for a SupraFAXModem 288e. - The phone number lengths used are for the North American format. - Standard user security upgrading if the verification is good. Because ACID is run with every call in this setup, the security is not changed if it is higher than 50. Otherwise, callers with special access would lose this access each time they call! - Unknown callers are given limited access until I can verify them further, or so they can download the files I distribute. The exception is if the user already has Twit access (level 5), in which case they retain the Twit level. - Local private callers are given no access and LD private callers are given limited access, unless they already have Twit access (5). - No duplicate callers are allowed, though they are given limited access until they can be verified further. - Zero tolerance for bad callers. If they get on my blacklist, they're off the system for good, even if they call from a different location later. - A few mismatch calls are allowed, but not many. I stress to my users that if they call from two different places a lot that I will change their user record so they can call from both places (RA supports two different phone numbers in the user record). Full access is restored after a mismatch call. - Data & Voice phone numbers are stored for dupe detection. The CID number is not stored for simplicity's sake. I suspect most people will consider this approach a little too harsh, but you can always modify the parts you don't like. There is little doubt that this method is extremely secure. However, it could be made even more secure by =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 19 restricting Mismatch callers and Duplicate callers even more. 4.5 - Uses For Certain Features Some of ACID's features may seem a little obscure, so this section will describe what the intended use of these features are for. If, while reading this manual or the descriptions in ACID.CFG, you found yourself asking "What the heck is _THAT_ for?!?!?", this is the place to look! The features are referred to by the keyword(s) used in ACID.CFG, so look there if you need further information after reading this section. CIDChangeUnderscores The reason for use of this keyword is described in ACID.CFG. MaxDupeCallers Every once in a while, you might get two people MaxDupeAction from the same family, or roommates, who want to use your BBS. Or, if your BBS doesn't support handles "naturally", you might want to allow each user to have two accounts - one using a handle, and one with their real name. Either way, these keywords let you allow multiple callers/accounts from the same number without causing both them and yourself big headaches. The user(s) is/are spared the hassle of waiting, and you are spared the hassle of having to verify people in situations of this type. This feature should, however, be used with care, and you should monitor ACID's logs for Dupe callers just to be on the safe side. MaxConsecBadCalls The features controlled by these keywords allow MaxTotalBadCalls you to allow a bad caller to call a few times FirstBadCallAction before you take more drastic action. Why? MaxBadCallAction Because you're probably not a cold person, and want to give people a chance to defend themselves. Or, you might want a user to be able to read an explanation of why they were kicked off before dispensing with them entirely. These keywords will let you do that. Furthermore, they are a great way to outsmart hackers, who may call once and think they can get on their system (to try and break into it, for example), then call back again and find themselves being continuously dumped off. MaxConsecMismatchCalls The features controlled be these keywords let you MaxTotalMismatchCalls control where a user calls from, and for how long. FirstMismatchCallAction Chances are that a user will occaisionally call MaxMismatchCallAction from a location other than the one they normally call from, and when this happens you don't want to inconvenience this users. When this starts to become a more frequent occurence, it may signal a hacker, or more than one person using an account (which many sysops do not like). Once it becomes a more frequent occurence, you can have ACID automatically do something about it until you can check on the situation. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 20 GoodAfterBadAction In the ever-changing world of computers, nothing GoodAfterMismatchAction is permanent. This is true with user situations, as well, so these keywords let you "forget the past". In the case of bad users, a situation may be resolved, and/or you may decide to give a user another chance. With mismatch callers, you may not want them to have full access unless they're calling from the "right" place. These keywords can be used to grant a user higher/total access if one of the above cases occurs. They are also useful in outsmart hackers. By lowering a user's access (or blocking a user entirely) when something isn't right, there is NO CHANCE that the "wrong" person can get into an account, unless they're calling from the same place as the person who normally uses the account anyhow! AddAllNumbersToLogs Many BBS systems allow users to enter both a voice CIDPhoneNumberLength and data phone number. Because of this, it helps CIDAreaCodeLength to be able to treat both numbers as a single entity. For example, once a user is verified at a number, their number can be stored in ACID.DUP to prevent duplicate accounts from the same number. But if the user has two different numbers in the user file, they can simply switch phone lines and get themselves another account! Not if the "Add All Numbers" setting is turned on, though. When this setting is on, _all_ numbers in the user's account will be logged when a "Log" action is used. Note that because the numbers used are not always numbers from CID information, a user could ban one or several users if they have entered "wrong" or "garbage" phone numbers in their account. Imagine if a user entered "0" as a phone number, and this was logged to ACIDNMBR.BAD. Everybody with a "0" in their phone number would be considered a bad user! Fortunately, ACID has internal logic which helps verify that a number is a real phone number, so that kind of thing cannot happen. The two "length" keywords assist ACID in determining a valid phone number. With this logic, the worst that could ever happen is that a user will enter the same number as another user, and this is easily fixed with a one-time edit of ACIDNMBR.BAD or ACID.DUP. All of the other features are (hopefully) self-explanatory, with the assistance of the descriptions in ACID.CFG. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 21 =============================================================================== 5.0 - External Support Files =============================================================================== ACID uses several external files, which may be created by yourself prior to running ACID, or created by ACID when it runs, or both. This chapter lists those files and describes what they are used for. 5.1 - ASCII, ANSI, AVATAR, And RIP Files Most of the external files ACID uses are ASCII, ANSI, AVATAR, and RIP files. These files should be created prior to running ACID, and can be changed any time as necessary. None of the files listed have to exist. If a file is not found, ACID will simply display nothing. Before listing this files, you should understand how they are searched for and used. Users of RA and similar systems will be well familiar with this method. There can exist up to four variations of each listed file. These variations are distinguished by their file extensions. .ASC is used for ASCII files, .ANS is used for ANSI files, .AVT is used for AVATAR files, and .RIP is used for RIP files. If a user has ANSI, AVATAR, or RIP capability, that type of file will be searched for first. The precedence of the graphics modes is as follows: RIP, AVATAR, ANSI. For example, say a user has both RIP and ANSI capability, which is a common occurence. ACID will look for the .RIP file first, and if it can't find it, it will then look for the .ANS file. If the user also has AVATAR capability (in addition to ANSI and RIP), the order will be .RIP, .AVT, then .ANS. If the user's terminal does not support any of the above graphics modes, or if the files for all supported graphics modes do not exist, ACID will use the ASCII file (.ASC). If the .ASC file doesn't exist either, ACID will display nothing. ACID will look for all of the files listed in this section in the directory specified by the ANSIPath configuration keyword. If this keyword is not specified, the directory where ACID.EXE or ACID2.EXE is located will be used. All of these files work in conjunction with the ACID Action keywords (xxxxAction) in the configuration file ACID.CFG. For this reason, to save space and keep things simple, only the base file name and corresponding keyword will be listed. To get a further idea of what each file is used for, see the description of the associated keyword in ACID.CFG. Also, looking at the example .ASC files provided in the ACID archive may prove beneficial. These example files work well with the example described in the section called "Simple CID Protection". The file extensions are not listed; their usage is described above. BaseName | Associated ACID.CFG Keyword ----------+----------------------------- BAD1ST | FirstBadCallAction BADCMAX | MaxBadCallAction BADTMAX | MaxBadCallAction =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 22 DUPE1ST | MaxDupeAction DUPEMAX | MaxDupeAction GOODAFTB | GoodAfterBadAction GOODAFTM | GoodAfterMismatchAction LDOKAY | LDOkayAction LDPRIV | LDPrivateAction LDUNKNOW | LDUnknownAction MIS1ST | FirstMismatchCallAction MISCMAX | MaxMismatchCallAction MISTMAX | MaxMismatchCallAction NOINFO | InfoNotFoundAction OKAY | OkayAction PRIVATE | PrivateAction UNKNOWN | UnknownAction There is also one other file with a BaseName of LOCAL which is displayed to local callers. Unless you have a lot of people log on from the local console, you probably don't need to worry about changing this, as it is merely to inform you that the call is local and verification is being skipped. 5.2 - Other External Files There are some other external support files used by ACID. These are described below. All of the files listed here can be created and edited by yourself before running ACID needed, except when noted. All of these files will be created by ACID if they don't exist, though it may take some time for some of them to show up, since they are only used in certain situations. ACIDNAME.BAD Contains a list of bad names or name parts, one per line. Like ACID.CFG, lines beginning with a semi-colon (;) are considered comment lines and ignored. ACID will compare the information in this file to both the user's account name and handle (as passed by the drop file), as well as the name given in the Caller ID information, if supported by the phone company. If one of the bad names in this file is found, ACID will flag the call as "bad". The case of the user's name, the name in the CID info., and the name parts in this file are all unimportant. Be sure to use this file carefully, or you may inadvertantly ban users you don't wish to. For example, placing the word "pee" on a line in this file will also block out people with the names Peers, Peeters, etc. Furthermore, this is not a very effective means of locking out a user unless you have Name ID service. I recommend using ACIDNMBR.BAD instead. ACID will write to this file as noted in ACID.CFG, so you should not delete this file once it is created in order to preserve previous user lockouts. ACIDNMBR.BAD This file is very similar to ACIDNAME.BAD, but uses phone numbers instead. The phone number from the CID information will be compared with the information in this file. If there is a match, the call will be flagged as "bad". As with ACIDNAME.BAD, be sure to use this file carefully, or you can end up locking out users unintentionally. For example, if you put "000" in this file, anybody with "000" =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 23 in their phone number (403-555-0004, 403-500-0999, etc.) or will be flagged as bad! All punctuation (hyphens, etc.) is stripped from both the CID number and the information in this file. NOTE: If you wish to, for example, mark all private callers as "bad", don't do it with this file. Instead, use one of the "DoXxxx" keywords for the Bad Caller actions in ACID.CFG. ACID will write to this file as described in ACID.CFG, so you should not delete this file once it is created in order to preserve previous user lockouts. ACID.DUP This file functions exactly like ACIDNMBR.BAD, but instead of flagging calls as "bad", they will be flagged as "duplicate". Other than that, everything else in the description for ACIDNMBR.BAD applies to this file as well. ACIDUSER.DAT This file is the binary user data file created by ACID, and should never be edited or played with. ACID creates this file when it is first run and uses it to store things such as a user's name, security, phone numbers, bad call counts, etc. ACID uses this file to run a cross-account scan for duplicate phone numbers, and also uses it to store a user's original security for use with the Restore action. You should not delete this file unless you want to wipe clean the statuses of every user who has passed through ACID. Editing this file is not recommended, but if you find that you have to, use a hex editor and not a text editor. ACIDCID.LOG This is a complete transcript of all Caller ID info, as it is read and used by ACID, as well as the name and some other information about the user who called with it. ACID writes to this file each time it is run. Though this file is purely for your own information and can be deleted at will, you should keep this around in case problems with users arise. If you're low on drive space, consider archiving this file every so often and storing the archives on disk. You never know when they may come in handy... ACID.LOG This is a normal, FrontDoor style log file that notes all of the major actions performed by ACID. It is very similar to your BBS log files, and the logs created by many other doors. Use it to track down problems with ACID itself. This file is written to each time ACID is run, and can be deleted whenever you like, though you should skim over it before deleting it in case any unforseen errors have occured recently. =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 24 =============================================================================== 6.0 - Final Words =============================================================================== 6.1 - Plans For Future Versions If response to ACID is encouraging, I have _MANY_ more ideas planned. Many of them are so original and unprecedented that I'm not going to reveal them, but there are some other important features that you can look forward to in upcoming versions: - Configuration File and User Record Editors. - Support for "raw" Caller ID information. This is information that isn't formatted in any way, and is simply one continuous string of characters. - Support for a CBV-style "valid phone exchange list" to further help detect LD callers. - More configuration keywords to offer you EVEN MORE control over situations. - Ability to read and write back to ANY type of drop file (or user file), opening up ACID's security verification to ANY BBS type! - Ability to post messages to yourself or the user as an action option! That's just a small sampling of what I have planned for ACID. The cost of ACID will go up as more features are added, so register early and save! All upgrades are FREE! 6.2 - How To Contact The Author You can contact the author using one of the following methods: FidoNet Netmail - 1:134/31 (Routed Netmail or CrashMail) Internet Email - paul.sidorsky@t8000.com (Primary, stable) psidorsk@freenet.calgary.ab.ca (Secondary, stable) paulsid@f31.cambo.cuug.ab.ca (Tertiary, semi-stable) BBS - (403)686-0449 (Press . from menu to leave feedback) Canada Post - 1414 45th Street SW (SLOW!) Calgary, Alberta (SLOW!) CANADA T3C 2C2 (SLOW!) Address all correspondence to Paul Sidorsky. 6.3 - Where To Get ACID The latest version of ACID can always be freqed from FidoNet node 1:134/31 at any time but Zone Mail Hour, speeds up to 28800bps. Use the magic name of ACID (for ACID/DOS) or ACID2 (for ACID/2). NOTE: The files are compressed =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 25 with a newer archiver called RAR. If you cannot find RAR in your area, freq the magic name UNRAR as well (it's a small, 40k file). Alternatively, call my BBS at (403)686-0449 and download the latest versions from the ISMWare File Area. You'll be granted access on your first call, because, if you didn't already guess, my system runs ACID. :-) You can also FTP ACID/2 _ONLY_ from ftp.cts.com, in the /pub/joeld directory. This is the Doors/2 FTP site (which was mentioned earlier in the "Unpacking ACID" section earlier in this manual), and features OS/2 native doors. This is why only ACID/2 may be obtained from here. You can also call the Doors/2 support BBS if you're interested in OS/2 doors, including ACID/2. The phone number is (619)462-8406, and the FidoNet node is 1:202/704. 6.4 - Credits And Acknowledgements I wish to thank the following people who helped make ACID possible: - Borland International, for their excellent DOS and OS/2 C compilers. - Brian Pirie, who gave us OpenDoors, the door kit used for ACID/DOS. OpenDoors is by far the best C door kit around IMHO. - Joel Downer, for Doors/2, the door kit used for ACID/2. He painstakingly ported OpenDoors to OS/2 to give all of us OS/2-using BBS sysops hope for the future, and made it multithreaded on top of that! He is also the provider of the FTP site for ACID/2. - Matthew Mastracci, for his Manual Compiler, which was used to make this manual. An excellent idea that was long overdue! - My mom, Ellen, for her financial support, which mostly came in the form of many bottles of Diet Coke. I suppose I should thank Coca-Cola here as well. <grin> =============================================================================== ACID v1.00 Documentation <-+-> Copyright 1994, 1995 <-+-> Page 26 This manual compiled using MC v1.04 by Matthew Mastracci