FRONTDOOR Administrator Guide FRONTDOOR Administrator Guide Copyright 1998, 1999, 2001 Definite Solutions HB; All rights reserved. All Definite Solutions products and trademarks are trademarks or registered trademarks of Definite Solutions HB; with the exception of FrontDoor which is a registered trademark of Joaquim Homrighausen. Other brands and product names are trademarks or registered trademarks of their respective holders. This publication is protected by international copyright laws and treaty provisions. It may only be distributed and used in accordance with those laws and treaty provisions. DEF-E-FDADMIN-Z-1/2001-EP Produced in Sweden. To the memory of Catharina Frodin and Alva Gardlund. And to Alexander, Janet, Christian, Katja, and Igor. Party on Fred, we miss you. Special thanks to Bruce Bodger for his help with the production of the entire FrontDoor package. Special thanks to Colin Turner for his help with the production of this document. Special thanks to Jim Louvau for his help with the initial development of the communications module for the OS/2 version of FrontDoor. FrontDoor Administrator Guide TABLE OF CONTENTS Table of contents 4 1. Introduction 10 About this document 10 Version notation 10 Executables 10 FDSETUP options 10 2. Programs 11 FD 11 FM 11 FDSETUP 11 FDNC 11 X00 12 3. Hardware/Software 13 Hardware requirements 13 Software requirements 14 Software notes 14 4. Installation 16 Directory structure 16 Removable and volatile media 17 Environment variables 17 CONFIG.SYS 19 5. FDSETUP 21 Running FDSETUP 21 Menu navigation 21 Current task number 22 Multi-user environments 22 File menu 22 Global menu 23 Mailer menu 35 Editor menu 49 Table of contents Page 4 FrontDoor Administrator Guide Terminal menu 58 Modem menu 64 Printer menu 65 Manager menu 69 6. The Nodelist 71 Base components 71 Additional components 72 Addresses 73 Layout 73 Nodelist flags 80 Points 84 7. FDNC 86 FDNODE.CTL 86 PVTLIST and POINTLIST 94 Nodelist groups 94 Command-line use of FDNC 95 Interactive use FDNC 100 The FDNC ASCII file editor 105 The FDNC nodelist editor 105 Exporting entries from the nodelist 110 Importing nodelist source files 113 Creating a new nodelist database 116 8. Mail routing 117 Route file 117 Route commands 121 Order of evaluation 131 Using nodelist flags 131 Route macros 132 Default routing 132 Implied routing and qualification 132 Sample route file 134 9. Events 135 Event manager 135 Mail event behavior 140 External event behavior 144 Overlapping events 145 Table of contents Page 5 FrontDoor Administrator Guide 10. Modem configuration 148 Basic requirements 148 Configuration options 150 Modem manager 162 11. Folders 165 Folder types 165 Configuration 167 Folder separators 173 Lastread 174 12. Mail security 175 Secure vs. unsecure mail sessions 175 Automated distribution 176 The nodelist 177 File and service requests 177 Automatic forwarding of mail 178 Automatic time synchronization 178 FDSERVER 179 Security manager 179 13. Semaphore files 184 FDRESCAN.NOW 190 14. File requests 191 Configuration 191 15. Service requests 201 Definition 201 Security 203 16. FDSERVER 204 FDSERVER requests 204 Enabling FDSERVER 207 17. Scripts 208 Table of contents Page 6 FrontDoor Administrator Guide Commands 208 Labels 221 Node blocks 222 Mnemonics 223 Macros 224 Examples 226 Appendix A: Glossary 231 Appendix B: FOSSIL drivers 239 X00 239 ADF 240 BNU 241 SIO (OS/2) 241 WinFOSSIL (Windows 9x) 242 WinFOSSIL for Windows NT 242 ISDN 242 Other FOSSIL drivers 244 Appendix C: Platforms 245 Local Area Networks 245 DOS 245 OpenDOS 246 DESQview 246 OS/2 247 Windows 9x 248 Windows NT 249 Windows 3.x 249 Appendix D: Message status 250 Status flags 250 Appendix E: .CCL files 256 File format 256 Examples 259 Appendix F: NAMES.FD 260 File format 260 Table of contents Page 7 FrontDoor Administrator Guide Gateway addresses 261 Examples 262 Appendix G: Mail storage 264 .MSG 264 JAM 264 HMB 264 Appendix H: System macros 266 The basics 266 Internal macros 266 Appendix I: Command-line reference 269 General 269 FDSETUP 271 FD 272 FM 282 Appendix J: Environment variables 285 FD 285 TZUTC 285 TASK 286 FDOPT 286 FDUSRLEV 287 FMUSERNAME 287 FMUSERNUM 288 FMUSERPOS 288 FMUSEROFS 289 FDOVR 289 FMOVR 289 FDNCOVR 290 Appendix K: Undialable handler 291 Appendix L: External mail interface 293 OS/2 version-specific notes 294 Appendix M: Batch files 296 Table of contents Page 8 FrontDoor Administrator Guide FDNC 296 FD 298 Appendix N: BBS interface 301 DOS version 301 OS/2 version 307 Appendix O: OS/2 version specifics 312 Sharing SETUP.FD 312 Executing external programs 312 Batch files instead of errorlevels 314 The ABS2PM.DLL file 315 Long filenames 315 Alternative communications driver 315 Appendix P: TZUTC reference 317 Appendix Q: Contact information 318 Index 319 Table of contents Page 9 FrontDoor Administrator Guide 1. INTRODUCTION 1.1 VERSION NOTATION The following notations are used to indicate where features are supported differently by various versions of the software: [ML] Multi-line version; [SL] Single-line version (Shareware); [DOS] DOS version (see below); [!DOS] Any version other than the DOS version (see below); [OS/2] OS/2 version (see below). 1.2 EXECUTABLES Since this document intends to cover all available platform versions of the software, the following should be noted in regards to the name of the program executables: Platform DOS OS/2 Executables FD.EXE FD2.EXE FM.EXE FM2.EXE FDNC.EXE FDNC2.EXE FDSETUP.EXE FDSETUP2.EXE 1.3 FDSETUP OPTIONS Throughout this document, references to options and menus in various FrontDoor programs, are made by using a reference to a menu path. These paths begin with the name of the top-level menu, followed by one or more menus or options, until the final destination has been reached. A few examples follow: Mailer.File requests.Filenames Editor.Display.Screen size If no reference is given to a specific program, FDSETUP is implied. Introduction Page 10 FrontDoor Administrator Guide 2. PROGRAMS This section briefly describes each of the programs in the FrontDoor package. 2.1 FD FD - also referred to as "the mailer" - is the program responsible for handling the actual transfer of mail from and to systems other than your own. In the simplest of definitions, FD is the interface to the outside world; it is primarily intended to run unattended. FD also contains a powerful terminal emulator - also referred to as "the Terminal". The Terminal can be accessed via FD, or as a stand- alone terminal program by loading FD with specific command-line parameters; the Terminal is primarily intended to be used interactively to access remote systems. 2.2 FM FM - also referred to as "the editor" - is the program used to read and write mail (messages). 2.3 FDSETUP FDSETUP is the primary configuration/setup program for the FrontDoor package. 2.4 FDNC FDNC - also referred to as "the nodelist compiler/manager" - is the program used to maintain and update the FrontDoor address directory ("the nodelist"). Programs Page 11 FrontDoor Administrator Guide 2.5 X00 X00 is a FOSSIL driver for use in conjunction with FD. It is primarily intended to run under DOS. A FOSSIL driver is responsible for the communication between FD and the communications hardware (i.e. modem, ISDN card, ASDL equipment, etc). * A FOSSIL driver is only required/used by the DOS version of FD. Programs Page 12 FrontDoor Administrator Guide 3. HARDWARE/SOFTWARE 3.1 HARDWARE REQUIREMENTS The DOS version of FrontDoor will run on most IBM AT compatible hardware. A 80286 or NEC V20 CPU (or compatible) is, however, required. FrontDoor will not operate on an 8086/8088 CPU-based system. It is further a requirement that the hardware is IBM AT-BIOS compatible. For versions other than the DOS version, a machine capable of running the host operating system (such as OS/2) is required. The following hardware is furthermore required to run FrontDoor: Platform DOS OS/2 Available 3 MB 5 MB disk space Memory (RAM) 500 Kb of available RAM At least 16 MB of RAM should be installed in the computer; this is a largely a requirement imposed by the operating system. The following hardware is furthermore required to run FD: o An asynchronous modem or other communications device capable of sending alphanumeric messages such as "CONNECT 33600" * Since the DOS version of FD does not communicate directly with the communications device, it is possible to use a FOSSIL driver that emulates a modem in place of an actual modem. For versions other than the DOS version, FD only issues standard calls to the communications hardware, thus making it possible to write drivers for other types of communications devices. Hardware/Software Page 13 FrontDoor Administrator Guide 3.2 SOFTWARE REQUIREMENTS Platform DOS OS/2 Version MS-DOS 3.10 or PC-DOS 3.10 OS/2 Warp 3 or above. or above (or 100% For OS/2 Warp 4, at compatible). least fixpack #3 must be installed. FOSSIL driver X00, ADF, BNU, cFos, n/a SIO/VX00, WinFOSSIL, DGFossil, COM/IP, or VFD. * The DOS version of FrontDoor can also take advantage of LIM/EMS memory (for overlay handling) as well as LIM/EMS and XMS memory (for program image swapping). While recommended, neither of these are required. 3.3 SOFTWARE NOTES 3.3.1 DOS The DOS version of FrontDoor has been tested in the following DOS and DOS compatible environments: MS and PC DOS 3.10, 3.20, 3.3x, 4.x, 5.x, 6.x, and 7.x. Caldera OpenDOS 7.0x. * It is recommended that SMARTDRV or similar disk caching software be used if FrontDoor is installed in a "pure" DOS environment. 3.3.2 Windows The DOS version of FrontDoor runs under Windows. Due to the limited multi-tasking capabilities of Windows 3.x, it is recommended that Windows 9x, Windows ME, Windows NT, or Windows 2000 be used. Please refer to "Platforms" for specific notes regarding running FrontDoor in the Windows environment. Hardware/Software Page 14 FrontDoor Administrator Guide 3.3.3 OS/2 The DOS version of FrontDoor runs under OS/2 Warp 3, and OS/2 Warp 4. It is recommended that FrontDoor be installed in an OS/2 Warp 3 or OS/2 Warp 4 environment due to the improved performance over OS/2 2.x. The OS/2 version of FrontDoor is a native, 32-bit OS/2 application. For OS/2 Warp 3, no FP (FixPack) is required. For OS/2 Warp 4, FP #3 or above must be installed. Please refer to "Platforms" for specific notes regarding running FrontDoor under OS/2. Hardware/Software Page 15 FrontDoor Administrator Guide 4. INSTALLATION This section contains information about suggested directory structures, location of files, etc. When installing FrontDoor using the accompanying installation program, many issues in this section do not apply. The intended purpose for this section is to explain about various installation related topics in detail. 4.1 DIRECTORY STRUCTURE The following directory structure is recommended, but by no means required: (FrontDoor root) BIN FILES PKT SEM NET NETSEC TMP MSG MSG NET JAM HMB e.g. Installation Page 16 FrontDoor Administrator Guide C:\FD C:\FD\BIN C:\FD\FILES C:\FD\FILES\PKT C:\FD\FILES\SEM C:\FD\FILES\NET C:\FD\FILES\NETSEC C:\FD\MSG C:\FD\MSG\MSG\NET\ C:\FD\MSG\JAM\ C:\FD\MSG\HMB\ * [OS/2] FrontDoor does not require an HPFS partition. Some performance improvements can, however, be made by placing the \FD\MSG structure (above) on such a partition. 4.2 REMOVABLE AND VOLATILE MEDIA It is not recommended that any paths or filenames that use removable or volatile (e.g. RAM disks) media are configured; except where it is otherwise noted. This is in particular important for FD, which is intended to be left running unattended most of the time. 4.3 ENVIRONMENT VARIABLES Certain parameters and options can be specified to FrontDoor by means of environment variables. This section does not list all environment variables used by FrontDoor. Only those that are the minimum recommended settings are mentioned below. Please refer to "Environment variables" in the Appendix section for a complete reference to the environment variables used by FrontDoor. 4.3.1 FD The contents of the FD environment variable is used by FrontDoor to locate its primary configuration file, SETUP.FD. Installation Page 17 FrontDoor Administrator Guide It is highly recommended that this environment variable be properly configured (set) on all machines and in all environments where any FrontDoor program is or will be used. The FD environment variable should typically point to the FrontDoor root directory. In the above structure, the FrontDoor root directory is C:\FD. To set this environment variable, add: SET FD=C:\FD to your AUTOEXEC.BAT (DOS) and/or CONFIG.SYS (OS/2) and other applicable system start-up files. If your FrontDoor root directory is something other than C:\FD, put the complete path (including the drive) after the equal sign. 4.3.2 TZUTC The TZUTC environment variable determines your geographical time zone's offset to UTC (GMT) time. A positive TZUTC setting indicates a geographical location east of UTC0000, a negative TZUTC setting indicates a location west of UTC0000. The format for the TZUTC environment variable is: SET TZUTC=[+|-]hhmm The plus sign is optional and implied unless the minus sign is specified. For Central European Time (CET), the TZUTC setting is 0200 during summer time, and 0100 during winter time. The TZUTC setting is added to messages created by FM and FD, and is also used by FD to aid in automated time synchronization services between systems. A list of the most commonly used time zones and their TZUTC setting equivalents is listed in "TZUTC reference". 4.3.3 TASK [ML] The TASK environment variable is primarily used by FD. It is, however, recommended that it is properly configured (set) on all machines and in all environments where any FrontDoor program is or will be used. The format for the TASK environment variable is: Installation Page 18 FrontDoor Administrator Guide SET TASK= where is 0-255. FD requires that the TASK environment variable is set and that no other running copy of FD is using the same task number. 4.3.4 TMP and TEMP While not internally supported by FrontDoor, these two environment variables can be referred to by means of the internal macros in path and filename definitions throughout the FrontDoor environment. It is recommended that at least TMP is configured, pointing to a directory capable of holding at least one megabyte (1 MB) of data. For example, SET TMP=C:\FD\FILES\TMP would set the TMP environment variable to point to C:\FD\FILES\TMP. Unless used for other purposes, the TMP/TEMP is typically an ideal candidate to be placed on a RAM disk or similar media; it should, however, not point to removable media. 4.4 CONFIG.SYS [DOS] It should be noted that several of the environment variables mentioned above should also be added to CONFIG.SYS in environments such as OS/2 if OS-native FrontDoor applications (utilities) are being used. [OS/2] It should be noted that several of the environment variables mentioned above should also be added to AUTOEXEC.BAT if FrontDoor applications (utilities) written for DOS are being used. Some environments do not make use of CONFIG.SYS, which is a file originating from the DOS environment. CONFIG.SYS is used to specify certain OS configuration options and to load device drivers when the system is started. Installation Page 19 FrontDoor Administrator Guide 4.4.1 FILES= The DOS version of both FM and FD are pushing the "legal limit" (20) on the number of files a DOS application can keep open at any given time. It is important that the FILES= setting in CONFIG.SYS is properly configured to handle this. In a pure DOS environment, with no other programs running, a setting of 25 (or higher) is recommended. If the system is a multi-tasking and/or networking environment, it is normally already configured to handle this, though the setting may need to be increased somewhat. * Note that the setting should be configured to handle the maximum number of running copies of FM and FD at any given time, i.e. if two copies of FD will be running on the same machine (at the same time), a setting of 50 or higher is required. 4.4.2 BUFFERS= For pure DOS environments, a setting of 30 (or higher) is recommended. If a disk cache is used, a lower BUFFERS setting (3-5) is normally sufficient. Installation Page 20 FrontDoor Administrator Guide 5. FDSETUP FDSETUP is the primary configuration tool for FrontDoor. It is used to configure options that affect and control various aspects of all FrontDoor programs. Before FDSETUP is used, the FD environment variable (see "Installation") should be properly configured to point to the directory where SETUP.FD is located (or will be created, in the case of a new installation). 5.1 RUNNING FDSETUP FDSETUP can be invoked in a number of ways. Typically, one of the below listed methods are used: o With the ALT+S (Setup), shortcut in the Programs menu of FD; o By typing FDSETUP and then pressing the ENTER key from an OS command prompt. If FDSETUP can locate and read the primary configuration file, SETUP.FD, it will display the menu system and make the File menu the active menu. If FDSETUP cannot locate the configuration file, it will display the name of the file it has attempted to open, together with a description of why it could not be opened (e.g. Path not found, File not found, etc). FDSETUP will then wait for keyboard input. At this point, the SPACE key can be used to force a new SETUP.FD file to be created; the ESC key will abort FDSETUP. 5.2 MENU NAVIGATION The selection bar in menus is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the topmost field; pressing the END key will move the selection bar to the last field. PGUP and PGDN generally move the selection bar one page up and one page down respectively. If a list or menu contains more entries than will fit on the screen, CTRL+PGUP and CTRL+PGDN can be used to move to the top and bottom, respectively, of the list/menu. FDSETUP Page 21 FrontDoor Administrator Guide To move between the top-level pull-down menus, the LEFT and RIGHT keys are used. The current pull-down menu cannot be changed unless it is the active window (i.e. no sub-menus or sub-options may be displayed). 5.3 CURRENT TASK NUMBER [ML] If the current task number is something other than zero (0), FDSETUP will display the task number in the bottom right-hand corner. FDSETUP will by default fetch the current task number from the TASK environment variable (see "Installation"). By using the /T command-line parameter, FDSETUP can be forced to use a specific task number and ignore the TASK environment variable. For example: FDSETUP /T8 will force FDSETUP to operate as if TASK=8 was present in the environment. 5.4 MULTI-USER ENVIRONMENTS In a multi-user environment such as a LAN, it is generally not recommended that all users have access to FDSETUP. If FDSETUP is available to all users, at least one user (in FDSETUP) with Supervisor status should exist; this user should furthermore have its profile protected by a password (see Global.Users, below). 5.5 FILE MENU The File menu consists of four (4) options: 5.5.1 Write SETUP.FD Writes the current settings to SETUP.FD without terminating FDSETUP. This option is primarily intended for environments where FDSETUP is left running. FDSETUP Page 22 FrontDoor Administrator Guide 5.5.2 Shell to DOS Invokes a temporary OS shell. Typing EXIT and then pressing the ENTER key from the OS command prompt will return to FDSETUP. The temporary OS shell function can be invoked throughout FDSETUP with the ALT+Z shortcut. 5.5.3 Set task number [ML] Allows a different task number to be specified (see "Current task number" above). FDSETUP will default to editing the current task settings for task-specific options. 5.5.4 Exit Terminates FDSETUP. If changes have been made to the configuration, FDSETUP will first prompt if those changes should be saved. Exiting FDSETUP can also be accomplished by pressing the ESC key in any of the top-level menus. 5.5.5 License information [ML] Allows configuration and viewing of the product license information. * It is required that product license information be properly entered before running FM, FD, and FDNC. 5.6 GLOBAL MENU The Global menu consists of four (4) options; all of which, in part or fully, affect the operation of the FrontDoor programs. 5.6.1 Address The Address option contains a number of settings vital to all FrontDoor programs; the Address, and AKA matching settings in particular. Some options specific to FM and FD are also configured here. FDSETUP Page 23 FrontDoor Administrator Guide 5.6.1.1 Address The network addresses used by the system. Each address must be unique within the respective network it belongs to; i.e. no two systems should use the same network address(es). For more information about networks, the nodelist, and addresses, please refer to "The Nodelist". A maximum of 31 addresses can be configured. * With regards to the unique addresses mentioned above, it should be pointed out that "system" in this context does not include multiple copies of FD running with the same configuration files on the same machine or LAN. 5.6.1.2 Site info The settings configured here are presented to remote systems during mail sessions; the settings are only used by FD. Name is the name of the system, e.g. XYZ Corporation HQ. If multiple copies of FD are sharing the same configuration, the $[TASK] macro (see "System macros") can be used to add task/line distinction to the name. Location is the geographical location of the system, e.g. Stockholm, Sweden. Phone# is the telephone number in "raw" (untranslated) format, e.g. +46 8 123456. If a country number is specified, it should be specified with one + (plus) character in front of it. Speed should contain the maximum supported connection speed of the communications device attached to the system. Flags should contain the proper nodelist flags (see "The Nodelist") applicable to this system. BBS name should contain the name of the BBS software (if any) used to handle interactive access the system; alternatively, the text the BBS can be used here. FDSETUP Page 24 FrontDoor Administrator Guide 5.6.1.3 Domains The domain names associated with specific addresses used by the system. This is currently only used when FM and FD creates message addressing information (MSGID); and by FD during EMSI-style session negotiations. Each domain name is linked to a specific zone number (see "The Nodelist"). For example, if zone 300 is used for the XYZ Corporation network, a suitable domain name may be xyznet or xyzcorpnet. 5.6.1.4 AKA matching The AKA matching table is used to match a specific system address to a zone, or a net within a zone. This allows FM to automatically use the correct address when messages are sent to recipients in different zones and/or nets. This table is also used by FD to determine which address it should present (or present first, in the case of certain types of mail sessions) to the remote system. If the system only has one address, no AKA matching needs to be configured. 5.6.2 Filenames The Filenames option contains a number of settings vital to all FrontDoor programs; the System, NetMail, TempPath, and [ML] Semaphore settings in particular. Some options specific to FM and FD respectively are also configured here. 5.6.2.1 System The location of most configuration files for FD, FM, and FDNC. Even though no implied logic enforces this, the System path is often used to store SETUP.FD. The System path should be configured identically for each SETUP.FD in a multi-mailer environment. 5.6.2.2 NetMail The location of the System NetMail folder; to which FD will unpack received messages. FDSETUP Page 25 FrontDoor Administrator Guide * [OS/2] Some performance improvements can be made by placing this directory on an HPFS partition. 5.6.2.3 Files Where inbound (received) files are stored by FD. * It is important that the disk to which this setting points has sufficient available (free) disk space to avoid a disk full condition during a mail session. 5.6.2.4 SecFiles Where inbound (received) files are stored by FD for secure (password protected) mail sessions. If this setting has not been configured, the above path is used for secure and unsecure sessions. * It is important that the disk to which this setting points has sufficient available (free) disk space to avoid a disk full condition during a mail session. 5.6.2.5 Packets Where FD stores temporary files used for mail handling. All files in this directory can be recreated by FD as needed; this makes the directory an ideal candidate to be placed on volatile media such as a RAM disk. The directory should, however, not point to removable media. It is recommended that FD be the only application configured to use this directory. If multiple copies of FD are running, they can safely share this directory. * If a RAM disk is used, it is recommended that a sub-directory is created (e.g. \PACKETS) and used since the number of directory entries in the root of a disk is usually limited to a fairly low number. FDSETUP Page 26 FrontDoor Administrator Guide 5.6.2.6 Log file The log file used by FD to record its activities. A number of settings (Mailer.Log) affect what is written to this file. For [ML], this is also used by the Terminal if such logging has been enabled. * [ML] It should be noted that if several copies of FD are to share the same SETUP.FD configuration file, this configuration option must include the $[TASK] macro (see "System macros") to make the actual filename used unique for each copy/task of FD. 5.6.2.7 Banner The contents of this file are displayed to interactive callers before FD terminates to pass control to the calling program or batch file used to invoke the interactive service; for example BBS software. This setting does not need to be configured for normal operation of FD. 5.6.2.8 Nodelist Where the nodelist database (see "The Nodelist") is stored. FDNC (see "FDNC") expects to find its control file used for creating the nodelist database in this directory. 5.6.2.9 No BBS The contents of this file are displayed to interactive callers when FD has been configured as mail-only (Mailer.Miscellaneous.Mail-only) or the currently active event (see "Events") does not permit interactive access. If this setting has not been configured, FD will display a hardcoded message indicating that interactive access is not permitted as applicable. This setting does not need to be configured for normal operation of FD. FDSETUP Page 27 FrontDoor Administrator Guide 5.6.2.10 Bad BPS The contents of this file are displayed to interactive callers when a connection is established at a speed that does not fall within the minimum required and maximum allowed settings (Mailer.BBS/Errorlevels). If this setting has not been configured, FD will display a hardcoded message indicating that the caller cannot access the system interactively at the current connection speed. This setting does not need to be configured for normal operation of FD. 5.6.2.11 HMB files The directory where FM expects to find the Hudson Message Base (HMB) files: MSGHDR.BBS, MSGTXT.BBS, MSGINFO.BBS, MSGIDX.BBS, MSGTOIDX.BBS, and LASTREAD.BBS. This setting is sometimes referred to as the QuickBBS path or QBBS path in third-party software. This setting does not have to be configured For more information about the various storage types, please refer to "Mail storage". 5.6.2.12 HMB extra The directory where FM creates/updates the ECHOMAIL.BBS file used in conjunction with the other HMB files. If this setting has not been configured, FM uses the HMB files path. For more information about the various storage types, please refer to "Mail storage". 5.6.2.13 JAM extra The directory where FM creates/updates the ECHOMAIL.JAM file used in conjunction with JAM-type folders (see "Folders"). For more information about the various storage types, please refer to "Mail storage". * This setting must be configured if JAM-type folders are used. FDSETUP Page 28 FrontDoor Administrator Guide 5.6.2.14 TempPath Where general files of temporary nature are stored; including swap files (Mailer.Swapping and Editor.Swapping). If a TMP or TEMP environment variable has been defined (see "Environment variables"), it is recommended that this setting be configured as $[TMP] or $[TEMP] respectively. If this setting has not been configured, the SYSTEM path (above) is used. For more information on the use of $[]-style macros, please refer to "System macros". 5.6.2.15 Semaphore [ML] Where semaphore files (see "Semaphore files") are created and looked for by various FrontDoor programs and third-party applications. Most files in this directory can be recreated by the various programs as needed, with the exception of user-created semaphores; this makes the directory an ideal candidate to be placed on volatile media such as a RAM disk. The directory should, however, not point to removable media. * If a RAM disk is used, it is recommended that a sub-directory is created (e.g. \SEMAPHOR) and used since the number of directory entries in the root of a disk is usually limited to a fairly low number. If this setting has not been configured, the SYSTEM path (above) is used. [SL] The SYSTEM path is always used for semaphores and the Semaphore path cannot be configured. 5.6.2.16 MailExit If configured, this file is created by FD when mail has been received that would normally trigger FD to terminate with an errorlevel (indicating that mail has been received). FDSETUP Page 29 FrontDoor Administrator Guide 5.6.3 General The General option contains a number of settings used by all FrontDoor programs; in particular the Your country code, and Extended keyboard settings. 5.6.3.1 Your country code The international country code (as used for telephone numbers) for the country where the system is geographically located (e.g. USA=1, Sweden=46, Germany=49, etc). This setting is used for telephone number translation and must be properly configured. 5.6.3.2 Screen flickers Used to override the default CGA (Color Graphics Adapter) detection. All FrontDoor programs attempt to detect if a CGA card is installed in the machine, and if so, attempts to prevent "snow" which is a common occurrence when these cards are used. The default is No, which should not be changed unless the screen flickers when a FrontDoor program is being used. * This setting is only applicable to the DOS version of FrontDoor. 5.6.3.3 Use "fastkey" Specifies that the DOS versions of FM, FD, FDNC, and the Terminal should modify the typematic rate (BIOS) settings for the keyboard to accelerate input. This can only be done on machines with an IBM AT (or compatible) BIOS. * If other keyboard acceleration utilities are being used, or the typematic rate settings have already been configured in the BIOS setup, this setting should be No. FDSETUP Page 30 FrontDoor Administrator Guide 5.6.3.4 Screen blanking Prevents screen images from "burning in". If a monochrome (phosphor) monitor is being used, data that is displayed in the same position on the screen tends to leave permanent trails. Color monitors and modern monochrome monitors typically do not have this problem. 5.6.3.5 Blackout timer Specifies how many seconds of inactivity should pass before the screen is blanked when FD is running. This setting is only used if Screen blanking (above) has been enabled. The screen will be restored automatically when activity occurs or when a key is pressed on the keyboard. 5.6.3.6 Extended keyboard Specifies that an extended (101 or more keys) keyboard is attached to the system. FDSETUP will attempt to detect the type of keyboard attached to the system. Some machines (BIOS) do not, however, correctly reflect the keyboard type; in which case this setting can be used to override what the machine returns to FDSETUP. * If this setting is No, the FrontDoor programs will not recognize the F11 and F12 keys, as well as some other key combinations such as CTRL+UP and CTRL+DOWN. 5.6.3.7 Date format Specifies the format and separators used when dates are displayed. If set to Auto, the various FrontDoor programs will fetch this information from the operating system. This does not affect the format of the date displayed in the upper right-hand corner of FD's main window. 5.6.3.8 Time format Specifies the format and separators used when time is displayed. If set to Auto, the various FrontDoor programs will fetch this information from the operating system. FDSETUP Page 31 FrontDoor Administrator Guide 5.6.3.9 Monochrome mode Specifies that FDSETUP should use a color set suitable for monochrome, LCD, and B&W monitors. This can also be accomplished by running FDSETUP with the /M command-line parameter; similarly, the /C command-line parameter forces FDSETUP to use colors suitable for color monitors. 5.6.3.10 Enable bright BG Specifies that the FrontDoor programs should enable bright background colors at startup. This allows additional colors to be used as background colors; the side-effect is, however, that blinking text is no longer available (this is a limitation of the video display hardware). It should be noted that this option typically has no effect when the program is running in a window in environments like OS/2 and Windows NT; i.e. it only affects screen output in full-screen sessions. 5.6.3.11 Reset bright BG Specifies that the FrontDoor programs should disable/reset bright background colors when exiting. This restores the availability of blinking text. If Enable bright BG (above) is enabled, this setting should also be enabled. It should be noted that this option typically has no effect when the program is running in a window in environments like OS/2 and Windows NT; i.e. it only affects screen output in full-screen sessions. 5.6.3.12 Semaphore timer Specifies, in seconds, how frequently FM and FD should scan the semaphore directory (Global.Filenames.Semaphore) to detect possible semaphore updates. The setting must be in the range 1 through 255; the default is 20 seconds. FDSETUP Page 32 FrontDoor Administrator Guide * Configuring this setting with a high value will result in a delay in FM and FD detecting that one or more semaphores have been updated. Configuring this setting with a low value will result in increased network traffic in LAN environments. 5.6.4 Users The Users option allows up to ten user profiles (the maximum number of users for one copy of SETUP.FD) to be configured. At least one must exist. To edit an existing user profile, simply press the ENTER key when the desired user name is highlighted. To create a new user profile, position the selection bar on an empty user profile slot and press the ENTER key. 5.6.4.1 Name The name of the user, specified in natural form (e.g. "John Doe"); at the very least, all-uppercase names (e.g. "JOHN DOE") should be avoided. The name specified in the first user profile is presented to remote systems during mail sessions as the primary system operator (SysOp). 5.6.4.2 Access The access level assigned to the user; this is one of Supervisor, Administrator, or User. Users with Supervisor access are not restricted in any way. Users with Administrator access are only restricted in that they may not modify various passwords without first entering the current password; some restrictions also apply to Administrator-type users in Restricted folders (see "Folders"). Users with User access cannot bypass any folder or password settings; furthermore, they can only modify their own password when FDSETUP is invoked. * It should be noted that unless user profiles with Supervisor and Administrator access are configured with a password, nothing stops anyone with physical access to FDSETUP from invoking it and modifying vital system configuration data. FDSETUP Page 33 FrontDoor Administrator Guide 5.6.4.3 UIL The default User Interface Level (UIL) for the profile; this is one of Advanced, Intermediate, or Novice. The UIL setting determines the options available to the user; in particular for FM and the Terminal. 5.6.4.4 Lock UIL Specifies that the user may not change the UIL setting from within the FrontDoor programs. 5.6.4.5 Password The password required to access the user profile. For maximum access control, it is recommended that all users with Supervisor or Administrator access are configured with a password. 5.6.4.6 Address The default network address to use for the profile. 5.6.4.7 UserID The user ID or number used to uniquely identify a user. This is primarily used for JAM-type folders (see "Folders"). 5.6.4.8 UserCRC An automatically calculated CRC (Cyclic Redundancy Check) value, based on the name setting for the profile. If FrontDoor is interfaced with the RemoteAccess BBS software package, or any other package that does not use a unique user ID for JAM folder access, the UserID setting should be identical to the value displayed here. FDSETUP Page 34 FrontDoor Administrator Guide 5.7 MAILER MENU The Mailer menu consists of a number of options; all of which affect the behavior of FD. Some of the options in the Mailer menu also affect the Terminal. 5.7.1 Miscellaneous These options affect general and global behavior of FD. 5.7.1.1 Mail from unlisted systems Determines if FD should accept inbound mail sessions from systems not listed in the nodelist database (see "The Nodelist"). If No, FD will simply terminate the call (hang up) when the remote system has identified itself and FD cannot locate any of its addresses in the nodelist database. 5.7.1.2 Mail from "unprotected" systems [ML] Determines if FD should accept inbound mail sessions from systems for which no session level security (see "Mail security") has been configured. If No, FD will simply terminate the call (hang up) when the remote system has identified itself and FD cannot locate any security configuration settings for the addresses presented by the remote system. 5.7.1.3 Mail from unlisted points Determines if FD should accept inbound mail sessions from point systems (see "The Nodelist") not listed in the nodelist database. If No, FD will simply terminate the call (hang up) when the remote system has identified itself and FD cannot locate any of its addresses in the nodelist database. FD will by default accept incoming mail sessions from unlisted points provided its Server/Boss passes all security checks (as configured above and elsewhere). FDSETUP Page 35 FrontDoor Administrator Guide 5.7.1.4 Terminal-only (no Mail) Specifies that FD should primarily be used as a Terminal; if enabled, FD will launch the Terminal as soon as it is invoked. To override this setting, the /M command-line parameter can be specified when FD is invoked. Alternatively, the Terminal can be invoked automatically by using the /TERM command-line parameter. 5.7.1.5 Mail-only (no BBS) Specifies that no interactive access (e.g. a BBS) should be permitted to the system. When an inbound call is processed and it is not another mail system, FD will simply terminate the call (hang- up). See "BBS interface" for more information about interfacing FD with an external program such as a BBS package to handle interactive calls. 5.7.1.6 BBS-only (no Mail) Specifies that FD is not used to handle mail sessions. As soon as an inbound call is detected, FD will exit with the errorlevel designated for interactive/BBS use (Mailer.BBS/Errorlevels). See "BBS interface" for more information about interfacing FD with an external program such as a BBS package to handle interactive calls. 5.7.1.7 Match remote's zone Specifies that FD should use an additional method to the AKA matching configuration (Global.Address.AKA matching) to determine which address it should present to the remote system. If enabled, and no match could be made in the AKA matching configuration, FD will compare the remote systems address(es) with its system addresses and if an address with a matching zone is found, it will be used. FDSETUP Page 36 FrontDoor Administrator Guide 5.7.1.8 Present all AKAs to remote system Specifies that FD should present all system addresses to the remote system. This setting should be configured as Yes unless there are specific reasons why FD should not present all system addresses to the remote system. 5.7.1.9 Trigger exit upon receipt of NetMail Specifies that FD should set its exit flag when uncompressed mail is received (from a remote system). The exit flag is by default only set when compressed mail is received. If an external program is used to process messages (e.g. to track transit mail), this setting should be configured as Yes to override the default behavior. * Whether or not FD will actually exit is ultimately determined by the Exit when mail is received setting of the current event (see "Events"). 5.7.1.10 Trigger exit upon receipt of ANY file Similar to the Trigger exit upon receipt of NetMail setting above; this setting, however, applies to any file, compressed and uncompressed mail included. 5.7.1.11 Busy retries Specifies the maximum number of attempts FD should make to call a given system during an event if the line is busy or the remote system does not answer. Note that this setting specifies retries; i.e. a setting of one (1) will result in a maximum of two attempts. FD will reset its attempt counters when it rescans the NetMail folder to prepare outbound mail. FDSETUP Page 37 FrontDoor Administrator Guide 5.7.1.12 Resend retries Specifies the maximum number of delivery attempts FD should make to a given system during an event if a session is terminated prematurely or abnormally. This also affects how FD treats a failed session in regards to the Undialable status of a system (see "Undialable handler"). Note that this setting specifies retries; i.e. a setting of one (1) will result in a maximum of two attempts; a setting of zero (0) will result in a maximum of one attempt. FD will reset its attempt counters when it rescans the NetMail folder to prepare outbound mail. 5.7.1.13 Retry delay Specifies the default minimum number of seconds FD should pause (wait) between placing outbound calls; this setting can be explicitly configured on a per-event basis (see "Events"). This setting is used together with a small random timer to avoid two systems calling each other at the same time. 5.7.1.14 Days to keep mail history Specifies the number of days an entry in the mail history database should be retained. FD removes all entries older than this setting from the mail history database during its midnight maintenance. 5.7.1.15 Seconds before passing to BBS Specifies the number of seconds FD will wait before assuming that an inbound call is an interactive call (i.e. not another mail system attempting to deliver or pickup mail); unless FD receives two consecutive escape (ASCII 27) characters, it will attempt to establish a mail session with the caller for the amount of time configured here. The default value is 30 seconds; the minimum and maximum values are 11 and 60 respectively. FDSETUP Page 38 FrontDoor Administrator Guide 5.7.1.16 Minimum undialable cost The minimum cost (as retrieved from the nodelist database) of a call to be processed by the undialable handler (see "Undialable handler"). 5.7.1.17 Allow time synchronization w/o UTC Specifies that FD should allow time synchronization (see "Mail security:TSRC") with a system that does not present valid UTC (GMT) offset information. * It is highly recommended that this setting be configured as No. 5.7.1.18 Default sort order in STQ list Specifies the default sort order for entries when the static queue (STQ) manager is invoked from FD. 5.7.1.19 Bypass scripts in Console services Specifies if FD should ignore the presence of script files (see "Scripts") in the SYSTEM directory when it prompts for parameters in Console Services; script files have the .SCR extension. 5.7.2 NetMail folder These options affect the behavior of FD in regards to the System NetMail folder. 5.7.2.1 Kill empty received messages Specifies that FD should remove messages without visible text; such (empty) messages are sometimes created to force a call to be made (i.e. to pickup mail). This only affects messages, unpacked from mail packets by FD, addressed to the local system. FDSETUP Page 39 FrontDoor Administrator Guide 5.7.2.2 Print received messages [ML]Specifies that FD should print messages that it unpacks from received mail packets. FD will use the configured printer settings (Printer) to print messages; if no printer settings have been configured, FD will not print received messages regardless of this setting. 5.7.2.3 Mail waiting for FrontDoor users only Specifies that FD should only trigger the display of the Mail waiting indicator if an unread message (addressed to the local system) is detected in the System NetMail folder with a recipient listed in the Global.Users configuration. * Unread messages addressed to SysOp (on the local system) will trigger the indicator, regardless of this setting. 5.7.2.4 Honor Return Receipt Requests (RRQ) [ML] Specifies that FD should honor return receipt requests. These requests are typically used to track the delivery of mail. Return receipts indicate that the message has reached its final destination system; it does not indicate that the message has been read by its intended recipient. 5.7.2.5 Force Kill/Sent on receipts [ML] Specifies that FD should force receipts that it generates in response to a return receipt request (see above) to be removed once they have been sent. 5.7.3 Log These options affect the behavior of FD in regards to information written to the log file; [ML] this also applies to the Terminal if logging has been enabled in the Terminal. FDSETUP Page 40 FrontDoor Administrator Guide * It is recommended that at least Fatal errors, Other errors, and Brief messages be enabled. It should also be noted that the Debug setting enables output of some otherwise not generated messages/information. 5.7.4 File requests See separate "File requests" section. 5.7.5 FDServer See separate "FDSERVER" section. 5.7.6 External mail The External mail interface allows external programs to be launched when FD detects a specific sequence in the data received from the communications device. Any data received from the communications device can be used to trigger an exit, including CONNECT messages, Caller ID information, etc. String is the data sequence FD should look for. Control characters and non-printable characters can be entered by holding down the ALT key and entering a one, two, or three digit sequence on the numerical keypad (e.g. ALT+13 will result in a , ASCII 13). InB specifies if the string should be monitored for inbound calls. OutB specifies if the string should be monitored for outbound calls. [DOS] Hot specifies that FD should not deinitialize the communications drivers when it exits. Level specifies the errorlevel with which FD will terminate when the specified sequence is detected. [OS/2] This field is ignored; it must, however, be set to something above thirty (30) for the external mail entry to be considered active. For more information about the external mail interface, see "External mail interface". FDSETUP Page 41 FrontDoor Administrator Guide 5.7.7 Display These options control some of the visual characteristics of FD. 5.7.7.1 Mail waiting blinking Specifies that the Mail waiting indicator should be displayed as blinking text; or with a high-intensity background, if the Global.General.Enable bright BG setting has been configured as Yes. 5.7.7.2 Display timestamp Specifies that the current time should be inserted into messages displayed in the scrolling message section of the main window. 5.7.7.3 Screen size Specifies the screen (text) mode that FD should attempt to use; this is one of 80x25, 80x28 (VGA), 80x33 (VGA), 80x43/50 (EGA/VGA), Auto, or [ML] Custom (DOS version only). It should be noted that some VGA cards do not support the 80x28 and/or 80x33 display modes. The Auto setting specifies that FD should adapt its display to use whatever the current screen (text) mode is; FD will, however, not use more than 80 column to display information. When the Auto setting is used, it is important that no program modifies the screen mode when loaded from FD or from a temporary shell from FD. [ML] The Custom setting specifies that FD should call the BIOS (INT 10H) Set Video Mode function with the specified register values. The Set Custom.. settings are used to set the custom video mode. The Reset Custom.. settings are used to reset the custom video mode to whatever the default video mode is. * The Custom setting is only available in the DOS version. FDSETUP Page 42 FrontDoor Administrator Guide 5.7.8 Colors Allows colors used by FD to be customized to suit personal preferences. These settings also affect menus and windows displayed in the Terminal. A number of preconfigured color settings are included in FDSETUP. 5.7.9 Hidden dial info Allows up to ten strings to be specified. These strings are used to mask (hide) portions of telephone numbers sent to the communications device. This feature is typically used to hide long-distance access codes, credit card information, etc. The actual data sent to the communications device is not affected by this, only what is displayed on the screen and written to the log file. * The "hidden" digits are actually replaced by the text . 5.7.10 Function keys Allows the configuration of up to 20/24 function keys (depending on the type of keyboard attached to the system); F1 through F10 (F12) and SHIFT+F1 through SHIFT+F10 (F12). These can be configured to launch other programs, force FD to exit with a specific errorlevel, etc. To modify the configuration of a specific function key, press the desired key. 5.7.10.1 Title The text displayed by FD when the list of function keys is invoked. This text is also written to the log when the given function key is used. 5.7.10.2 Action The program or command that should be invoked by FD when the function key is used. Multiple commands and programs can be specified (stacking), separated by a semi-colon (;), for example: FDSETUP Page 43 FrontDoor Administrator Guide LIST C:\FD\FD.LOG;DEL C:\FD\FD.LOG would first invoke the program LIST with C:\FD\FD.LOG as the parameter; when the LIST program is terminated, FD would proceed to the next program or command, which is the DEL command in this case (which removes the specified file). See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. To force FD to terminate with a specific errorlevel, the following construct is used: ? where must be in the range 0-255. It should be noted that stacking (use of multiple commands) is not possible when FD is instructed to terminate with a specific errorlevel. [ML] An alternative to the force exit construct described above exists: ?; where must be in the range 0-255; must be a number in the range 0-255 or an asterisk (*). If a number is used, it specifies that FD should, instead of exiting, create the semaphore FDXITNNN.EEE (where eee is the specified errorlevel and nnn is the number specified in ) in the semaphore directory; if an asterisk is used, it specifies that FD should create the semaphore FDXITANY.EEE (where eee is the specified errorlevel) in the semaphore directory. The FDXITNNN.EEE semaphore will cause the specified task (nnn) to exit as soon as possible. The FDXITANY.EEE semaphore will cause the first FD task that detects the semaphore to exit. FDSETUP Page 44 FrontDoor Administrator Guide 5.7.10.3 Pause Specifies that FD should pause, and wait for a key to be pressed, before restoring its window after the specified program(s) and command(s) terminates. The setting of this option is ignored when FD has been told to terminate with a specific errorlevel (see above). 5.7.10.4 Check Specifies that FD should rescan the System NetMail folder; this may be necessary if the invoked program creates new messages but does not create/update the FDRESCAN.NOW semaphore properly. The setting of this option is ignored when FD has been told to terminate with a specific errorlevel (see above). 5.7.10.5 Swap Specifies that the DOS version of FD should swap as much of itself out of memory prior to invoking each program/command; this will leave only a small footprint of FD in memory, and thus make as much memory as possible available to the invoked program/command. The setting of this option is ignored when FD has been told to terminate with a specific errorlevel (see above). 5.7.11 BBS/Errorlevels These options are related to errorlevels, used by FD when terminating under various circumstances, and the interactive access/BBS interface. See "BBS interface" for more information about this interface. FDSETUP Page 45 FrontDoor Administrator Guide 5.7.11.1 Inbound Fax calls Specifies the errorlevel with which FD will terminate when the Fax message (Modem.Connect messages) is received from the communications device. This setting does not require configuration if FD is being used with a fax capable ZyXEL modem and internal fax support has been enabled. Typical use of this setting is to launch an external fax receiver application such as BGFAX. To enable the external fax receiver interface, this option must be configured with a value above thirty (30). See "BBS interface" for more information about this interface. 5.7.11.2 Inbound Voice calls Specifies the errorlevel with which FD will terminate when the Voice message (Modem.Status messages) is received from the communications device during an inbound call. If this setting has been configured to zero (0), the call is simply terminated. Typical use of this setting is to launch an external voice mail application. To enable the external voice mail interface, this option must be configured with a value above thirty (30). See "BBS interface" for more information about this interface. 5.7.11.3 Received mail Specifies the errorlevel with which FD should terminate when an exit condition is triggered by received mail (Mailer.Miscellaneous). * Whether or not FD will actually exit is ultimately determined by the Exit when mail is received setting of the current event (see "Events"). FDSETUP Page 46 FrontDoor Administrator Guide 5.7.11.4 BBS Specifies the errorlevel with which FD will terminate when an inbound interactive/BBS call is detected. This setting need not be configured for mail-only systems. For this setting to be enabled, a value of thirty-one (31) or above must be specified. * Whether or not FD will actually accept interactive/BBS access is ultimately determined by the Allow users during event setting of the current event (see "Events"). 5.7.11.5 Minimum BBS speed Specifies the minimum connection speed at which FD will allow interactive/BBS access. If no minimum speed is required, this setting should be configured to zero (0). 5.7.11.6 Maximum BBS speed Specifies the maximum connection speed at which FD will allow interactive/BBS access. If no maximum speed is required, this setting should be configured to zero (0). 5.7.11.7 Create .BAT file Determines if the DOS version of FD should create the DOBBS*.BAT file when it terminates as the result of an inbound interactive/BBS call being detected. This setting is also used when the DOS version of FD terminates as the result of an inbound fax transmission (not handled by FD internally) being detected (Mailer.BBS/Errorlevels.Inbound Fax calls). See "BBS interface" for more information about this interface. * This setting is only available in the DOS version. FDSETUP Page 47 FrontDoor Administrator Guide 5.7.12 Audio control These options control some of the audible characteristics of FD. The various settings apply to specific events, such as new mail being unpacked, waiting mail, inbound calls, etc. FD can furthermore be configured to only issue audible signals during a specific time of the day (the start and end times are specified in 24-hour notation). 5.7.13 Swapping Determines how FD should behave when it invokes external programs and commands; other than when it terminates with a specific errorlevel. If swapping is enabled, FD will remove as much as possible of itself from memory prior to invoking the external program or command. If Use XMS/EMS is not enabled, or an insufficient amount of XMS/EMS memory is available, FD will swap itself to a disk file, written to the directory specified in Global.Filenames.TempPath. * This setting is only available in the DOS version. 5.7.14 Protection [ML] Allows access to specific options and commands in FD to be protected from unauthorized use. The specified password (case insensitive) will be required by FD before it allows access to any of the checked options and commands. Note that the Recent activity and Active event functions of the Mail menu in FD are not protected. 5.7.15 Fax These options are related to the internal fax reception support in FD. If a fax capable ZyXEL modem is attached to the system, FD can be configured to automatically handle (receive) inbound fax transmissions. FDSETUP Page 48 FrontDoor Administrator Guide RcvdFiles is the directory where the .FAX files should be stored. Recipient is the recipient on the local system to which the fax cover messages created by FD will be addressed. 5.8 EDITOR MENU The Editor menu consists of a number of options; all of which affect the behavior of FM. 5.8.1 Miscellaneous These options affect general and global behavior of FM. 5.8.1.1 Delete original.. These three options specifies how and if FM should prompt the user to delete the original message when replying to messages in the various types of folders. There are two Ask settings, specifying the default response to the Delete original message prompt. * Note that the Yes and No settings will bypass the prompt automatically and possibly delete the original message (Yes). 5.8.1.2 Show hard CRs Determines if the physical end-of-line markers (also known as "Hard CRs" or "Hard Carriage Returns") should be visible by default. It does not affect the actual contents or layout of messages. If this setting is enabled, FM will display Hard CRs as paragraph marks... 5.8.1.3 Margin Specifies the right margin at which FM should automatically wrap text when message text is entered. This setting is also used when replying to messages and selecting to quote the original message. When a message already contains quoted text, FM will use a preset value to better handle the already present quoted text. FDSETUP Page 49 FrontDoor Administrator Guide 5.8.1.4 Honor CFM [ML] Specifies that FM should honor confirmation receipt requests. These requests are typically used to track the delivery of mail. Confirmation receipts indicate that the message has been read by its intended recipient. 5.8.1.5 Force Kill/Sent on receipts [ML] Specifies that FM should force receipts that it generates in response to a confirmation receipt request (see above) to be removed once they have been sent. 5.8.1.6 New mail semaphores Determines if FM should create/update the new mail semaphores, in the semaphore directory, when new mail has been entered. These semaphores can be used for background processing of mail. There are three semaphores, one for each type of mail: FMNEWNET.NNN (NetMail), FMNEWCNF.NNN (Conference Mail), and FMNEWLOC.NNN (Local Mail); .nnn is the task number. * These semaphores are not created by FM until the user changes to a different folder, a temporary shell is invoked, and/or FM terminates. 5.8.1.7 Hide time written Specifies that FM should "hide" the time a message was written. It does this by setting the time field of new messages to contain zero (midnight), on the current day. 5.8.1.8 Suppress tearlines Specifies that FM should not create the optional tearline (three dashes, ---) when it appends Conference Mail information in the form of an Origin line (see "Folders"). FDSETUP Page 50 FrontDoor Administrator Guide 5.8.1.9 Survey delete default Specifies the default response to the Delete selected messages prompt in the Survey function. 5.8.1.10 Case of quote initials Determines how FM inserts the initials of the sender of a message being replied to. 5.8.1.11 Strip "Re:" on replies Specifies that FM should remove all occurrences of Re: that it recognizes from the contents of the Re: (subject) field when a message is being replied to. For Newsgroup-type folders, this is always done, as well as adding one Re: to the contents of the Re: (subject) field. 5.8.1.12 Support "Replied-to" status Specifies that FM should support the "Replied-to" message status. This message status indicates that at least one reply has been made to the message. To do this for certain types of folders, FM has to use a message status indicator intended for other purposes (this does not normally present a problem for FrontDoor or other applications). 5.8.1.13 Force user selection dialog Specifies that FM should display the user selection dialog on startup; forcing the user to select a user profile. FM will always do this if the first user profile has a password configured. 5.8.1.14 Show Survey selection status Specifies that FM should display the text [Selected] on the line dividing the message header from the message text if a message is selected in the Survey list. This adds some overhead, which may not be desirable on slower machines. FDSETUP Page 51 FrontDoor Administrator Guide 5.8.1.15 Highlight new messages in Survey Specifies that FM should highlight new (unread) messages to the current user in the Survey list. If this setting is No, FM will only show an asterisk (*) in the Survey list to indicate new messages to the current user. 5.8.1.16 Highlight user messages in Survey Specifies that FM should highlight messages to and from the current user in the Survey list. 5.8.2 NetMail folder These options affect the behavior of FM in regards to the System NetMail folder. For more information about the various options and settings, please refer to "Folders". 5.8.2.1 Restricted Specifies that the NetMail folder should be restricted. 5.8.2.2 Read-only Specifies that the NetMail folder should be read-only. 5.8.2.3 Export OK Specifies that FM should allow exporting of messages/text from the NetMail folder. 5.8.2.4 Use tables Specifies that FM should enable the translation tables for the NetMail folder. FDSETUP Page 52 FrontDoor Administrator Guide 5.8.2.5 Crash Specifies that FM should add the Crash message status as the default for new messages. 5.8.2.6 Direct Specifies that FM should add the Direct message status as the default for new messages. 5.8.2.7 Private Specifies that FM should add the Private (Pvt) message status as the default for new messages. 5.8.2.8 Kill/Sent Specifies that FM should add the Kill/Sent message status as the default for new messages. 5.8.3 Other folders Please refer to "Folders". 5.8.4 Keyboard macros Allows the configuration of up to 20/24 function keys (depending on the type of keyboard attached to the system); F1 through F10 (F12) and SHIFT+F1 through SHIFT+F10 (F12). These can be configured to insert text into messages, launch other programs, and to automate certain functions while writing messages with FM. All macros begin with the tilde (ASCII 126) character. Applicable $[] macros can also be used in these macros (see "System macros"). * The keyboard macros are only available while writing messages. FDSETUP Page 53 FrontDoor Administrator Guide To modify the configuration of a specific function key, press the desired key. If the current screen mode has more than 42 lines, FDSETUP will display a window containing a brief macro reference; the contents of which is duplicated below: 5.8.4.1 General macros ~~ Literal ~ ~| Literal | | ~B ~> ~< ~^ ~V ~g ~h ~U User name ~u User name (first) ~Z Current AKA (address) ~c Current date and time ~S Save and keep original message ~# Save and delete original message ~W Export message to file without headers ~X Export message to file ~E Execute program ~I Import file to message ~R Import file to message and delete file ~F Reformat paragraph ~L Insert line ~Y Delete line ~} Delete from cursor to EOL (end-of-line) ~T Delete from cursor to EOT (end-of-text) ~G Move cursor to top of message ~H Move cursor to end of message For the E, I, R, X, and W macros, additional data should be specified as: FDSETUP Page 54 FrontDoor Administrator Guide ; where is the file to import/export to, or program to execute. An example follows: ~WC:\FD\Q.BAK;~G~T~EE.EXE C:\FD\Q.BAK;~RC:\FD\Q.BAK; This macro will: o Export the contents of the current message (body) to the file C:\FD\Q.BAK o Move the cursor to the top of the message o Remove all text from the cursor (which is now at the beginning) to the end of the message o Launch the program E.EXE with C:\FD\Q.BAK as the parameter o Import the contents of C:\FD\Q.BAK and thereafter remove the file (C:\FD\Q.BAK) See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 5.8.4.2 Macros inserting data from current message ~m Last name of name in To: field (message recipient) ~n First name of name in To: field (message recipient) ~d Full name of name in To: field (message recipient) ~p Last name of name in By: field (message sender) ~q First name of name in By: field (message sender) ~o Full name of name in By: field (message sender) ~a The contents of the Re: (subject) field 5.8.4.3 Macros inserting data from original message These macros are typically used to insert information from the original message into the reply. FDSETUP Page 55 FrontDoor Administrator Guide ~I Contents of message ID information ~r Contents of reply-to information ~M Last name of name in To: field (message recipient) ~N First name of name in To: field (message recipient) ~D Full name of name in To: field (message recipient) ~P Last name of name in By: field (message sender) ~Q First name of name in By: field (message sender) ~O Full name of name in By: field (message sender) ~A The contents of the Re: (subject) field ~C The contents of the On: (date) field ~J The originating address (from where message originated) ~K The destination address (to where the message was destined) 5.8.5 Origin lines Origin lines are used to identify the origin of messages in Conference Mail-type folders (see "Folders"). This option allows the configuration of up to 20 origin lines that can be used as the default or forced origin line in Conference Mail-type folders. One hardcoded, "empty", origin line exists, which can also be specified as the default or forced origin line for applicable folders. Applicable $[] macros (see "System macros") can be used in origin lines. It is possible to generate random origin lines by configuring one of the origin line slots (1-20) as follows: @ For example: @C:\FD\MUSIC.TXT would instruct FM to read the file C:\FD\MUSIC.TXT and use one of the lines present in that file as the origin line information. The specified file must be a text (ASCII) file with each line terminated by a (ASCII 13, ASCII 10) pair. Comments can be placed behind semi-colons (;) and are ignored by FM. FDSETUP Page 56 FrontDoor Administrator Guide 5.8.6 Display These options control some of the visual characteristics of FM. 5.8.6.1 Screen size Specifies the screen (text) mode that FM should attempt to use; this is one of 80x25, 80x28 (VGA), 80x33 (VGA), 80x43/50 (EGA/VGA), Auto, or [ML] Custom (DOS version only). It should be noted that some VGA cards do not support the 80x28 and/or 80x33 display modes. The Auto setting specifies that FM should adapt its display to use whatever the current screen (text) mode is; FM will use the entire screen area to display information. When the Auto setting is used, it is important that no program modifies the screen mode when loaded from FM or from a temporary shell from FM. [ML] The Custom setting specifies that FM should call the BIOS (INT 10H) Set Video Mode function with the specified register values. The Set Custom.. settings are used to set the custom video mode. The Reset Custom.. settings are used to reset the custom video mode to whatever the default video mode is. * The Custom setting is only available in the DOS version. 5.8.7 Colors Allows colors used by FM to be customized to suit personal preferences. A number of preconfigured color settings are included in FDSETUP. 5.8.8 Xlat.In and Xlat.Out These two options allow the definition of so called translation tables. Translation tables can be used to perform one-to-one character mapping/translation when FM is reading and writing messages. Xlat.In is used when FM reads messages from disk, Xlat.Out is used when FM is writing (saving) messages to disk. FDSETUP Page 57 FrontDoor Administrator Guide 5.8.9 Swapping Determines how FM should behave when it invokes external programs and commands. If swapping is enabled, FM will remove as much as possible of itself from memory prior to invoking the external program or command. If Use XMS/EMS is not enabled, or an insufficient amount of XMS/EMS memory is available, FM will swap itself to a disk file, written to the directory specified in Global.Filenames.TempPath. * This setting is only available in the DOS version. 5.8.10 File viewer Allows the configuration of an external program which can be used from FM to view files attached to messages (file attachments). See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 5.8.11 Fax Allows the configuration of an external program which can be used from FM to view fax documents attached to fax cover messages. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 5.9 TERMINAL MENU The Terminal menu consists of eight options; all of which affect the behavior of the Terminal. 5.9.1 Miscellaneous These options affect general and global behavior of the Terminal. FDSETUP Page 58 FrontDoor Administrator Guide 5.9.1.1 Init Specifies a terminal-specific modem initialization string. When the Terminal is invoked from FD, only this string is transmitted to the communications device. When the Terminal is invoked directly from the command-prompt, this string is transmitted to the communications device after any other device initialization strings have been sent. 5.9.1.2 Protocol The default file-transfer protocol to use when uploading (transmit) and downloading (receive) in the Terminal; the available settings are: Zmodem, Xmodem, Telink, and SEAlink. 5.9.1.3 Emulation The default terminal emulation protocol to use in the Terminal; the available settings are: ANSI, VT-52, VT-100, and TTY. 5.9.1.4 AVATAR/0+ Determines if the Terminal should honor (support) emulation sequences specific to the AVATAR/0+ terminal emulation protocol (AVT/0+). If this setting is configured as No, the Terminal will simply display these sequences as data received from the communications device. * AVATAR/0+ sequences are only supported if the currently used emulation protocol is set to ANSI. 5.9.1.5 Buffer size Determines the size (in Kb) of the scroll back buffer in the Terminal. The scroll back buffer can be used to view and save data that has scrolled off the screen. * This setting is only used by the DOS version. FDSETUP Page 59 FrontDoor Administrator Guide 5.9.1.6 Connect noise Specifies that the Terminal should issue an audible signal when a connection is established. 5.9.1.7 Transfer noise Specifies that the Terminal should issue an audible signal when a file-transfer has been completed. 5.9.1.8 Xlat tables Specifies the default type, if any, of character translation the Terminal should use. If set to Latin1, the Terminal uses a hardcoded table to translate data received from the communications device to suit the local environment; if set to Config, the Terminal will use the Terminal translation table (see below). 5.9.1.9 Auto Zmodem Specifies that the Zmodem file-transfer protocol may enter receive mode automatically upon the receipt of the Zmodem transmit data sequence. 5.9.1.10 Local echo Specifies that the Terminal should "echo" any locally entered data to the screen. Local echo is seldom used as the entered data is typically "echoed" (sent back) by the remote system. 5.9.1.11 Wrap around Specifies that the Terminal should automatically move onto the next line when the current cursor position is equal to the width of the screen and more data is received. FDSETUP Page 60 FrontDoor Administrator Guide 5.9.1.12 Delay The delay, in seconds, between calls that result in no connection being made (BUSY, NO CARRIER, NO ANSWER, etc). This setting is not used when calls initiated manually by typing the dial command directly in the Terminal; e.g. ATDT123456 followed by ENTER. 5.9.1.13 Logging [ML] Determines if the Terminal should output data to the log file (Global.Filenames.Log file). 5.9.1.14 Auto DW mode Specifies that the Terminal should accept the sequences used to indicate that an application should enter/leave Doorway or raw keyboard mode. In Doorway keyboard mode, data generated by local keys being pressed is sent to the remote system in binary form. 5.9.1.15 Timer enabled Specifies that the Terminal should automatically terminate and return to FD after a certain amount of time has passed without activity. Regardless of the configuration of this setting, the Terminal will only automatically return to FD if it was invoked from FD; i.e. it will not exit due to inactivity if it has been invoked directly. 5.9.1.16 Timer Specifies the inactivity timer setting (in seconds) after which the Terminal should return to FD (see above). 5.9.1.17 Scripts in Nodelist dial Specifies that the Terminal should honor the presence of .SCR files in the SYSTEM directory when prompting the user for a network address in the nodelist database (nodelist dial). If scripts are only used with the mailer, this should be configured as No. FDSETUP Page 61 FrontDoor Administrator Guide 5.9.2 Filenames These options determine default paths and filenames used by the Terminal. 5.9.2.1 Download Specifies the default location to store received (downloaded) files. 5.9.2.2 Upload Specifies the default location of files to be transmitted (uploaded). 5.9.2.3 Editor Specifies the name of an external editor which can be invoked from the Terminal. If there is no desire to use an external editor in the Terminal, this option can instead be used to launch an external protocol program or similar. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 5.9.2.4 Capture Specifies the default filename to use for data capturing when the Capture function is used in the Terminal. 5.9.3 Display These options control some of the visual characteristics of the Terminal. FDSETUP Page 62 FrontDoor Administrator Guide 5.9.3.1 Screen size Specifies the screen (text) mode that the Terminal should attempt to use; this is one of 80x25, 80x28 (VGA), 80x33 (VGA), 80x43/50 (EGA/VGA), Auto, or [ML] Custom (DOS version only). It should be noted that some VGA cards do not support the 80x28 and/or 80x33 display modes. The Auto setting specifies that the Terminal should adapt its display to use whatever the current screen (text) mode is; the Terminal will use the entire screen area to display information. When the Auto setting is used, it is important that no program modifies the screen mode when loaded from the Terminal or from a temporary shell from the Terminal. [ML] The Custom setting specifies that the Terminal should call the BIOS (INT 10H) Set Video Mode function with the specified register values. The Set Custom.. settings are used to set the custom video mode. The Reset Custom.. settings are used to reset the custom video mode to whatever the default video mode is. * The Custom setting is only available in the DOS version. 5.9.3.2 Cursor size Specifies the cursor size to use in the Terminal. 5.9.4 Keyboard macros Allows the configuration of up to 20/24 function keys (depending on the type of keyboard attached to the system); SHIFT+F1 through SHIFT+F10 (F12) and CTRL+F1 through CTRL+F10 (F12). These can be configured to transmit text to the remote system or the communications device. To modify the configuration of a specific function key, press the desired key. All macros begin with the tilde (ASCII 126) character. Applicable $[] macros (see "System macros") can also be used in these macros. FDSETUP Page 63 FrontDoor Administrator Guide 5.9.4.1 Macros ~~ Literal ~ ~| Literal | | ~B ~P Current password ~! One second pause 5.9.5 Xlat.In and Xlat.Out These two options allow the definition of so called translation tables. Translation tables can be used to perform one-to-one character mapping/translation when the Terminal is receiving and transmitting characters. Xlat.In is used when the Terminal displays data received from the remote system or communications device, Xlat.Out is used when the Terminal is transmitting local data (keyboard input, macros, etc). * The translation tables are not used when files are sent and received by means of a file-transfer protocol such as Zmodem. 5.9.6 IEMSI Profile Specifies the default IEMSI profile. The IEMSI terminal protocol is discussed in a separate (appendix) section. 5.9.7 VT-100 emulation Specifies options related to the VT-100 terminal emulation protocol. 5.10 MODEM MENU The Modem menu consists of several options related to the configuration of the communication between FD and the attached communications device. This configuration also affects the Terminal. Please refer to "Modem configuration" for further information about these configuration settings. FDSETUP Page 64 FrontDoor Administrator Guide 5.11 PRINTER MENU The Printer menu consists of a number of options related to the configuration of the printer attached to the system (if any). This configuration affects FM and FD. 5.11.1 Hardware Specifies hardware related configuration options for the printer. [OS/2] Only the Disabled and Port settings are available. 5.11.1.1 Disabled Specifies that there is no printer attached to the system, or that the attached printer is not available. If configured to Yes, this setting disables printing in FM and FD. 5.11.1.2 Port 5.11.1.2.1 DOS version Specifies the port on which the printer is attached to the system; this is one of LPT1, LPT2, LPT3, COM1, COM2, COM3, or COM4. For LPT1-LPT3, the programs will use BIOS calls (INT 17H) to output data to the printer; for COM1-COM4, the programs will use the communications driver to output data to the printer. * It should be noted that if serial I/O is to be used (COM1-COM4), the communications driver must be configured to handle at least two ports if printing is to be done from FD. 5.11.1.2.2 OS/2 version Specifies the port on which the printer is attached to the system; this is one of LPT1, LPT2, or LPT3. It is possible to redirect printer output to a serial printer by using the OS/2 SPOOL command. FDSETUP Page 65 FrontDoor Administrator Guide 5.11.1.3 BPS rate Specifies the bits-per-second (BPS) rate at which the programs should communicate with the printer; this is one of 1200, 2400, 4800, 9600, 19200, or 38400 BPS. This is only used when the port has been configured as COM1-COM4. 5.11.1.4 Word length Specifies the word length (in bits); this is one of seven (7) or eight (8). This is only used when the port has been configured as COM1-COM4. 5.11.1.5 Stop bits Specifies the number of stop bits that should be used; this is one of one (1) or two (2). This is only used when the port has been configured as COM1-COM4. 5.11.1.6 Parity Specifies the parity that should be used; this is one of None, Even, or Odd. This is only used when the port has been configured as COM1- COM4. 5.11.2 Page Specifies configuration options related to page-control for data output to the printer. 5.11.2.1 Paper forwarding Specifies the method used for paper forwarding; this is one of Formfeeds, Continuously, or Linefeeds. Formfeeds specifies that the programs should output one (ASCII 12) character to instruct the printer to load a new paper to prepare for printing on a new page. This is supported by most printers and also recommended setting. FDSETUP Page 66 FrontDoor Administrator Guide Linefeeds specifies that the programs should output the (ASCII 10) character to forward the paper until the beginning of the next page has been reached. Continuously specifies that the printer is fitted with continuously running paper. 5.11.2.2 Manual paper feed Specifies that the programs should pause to allow for new paper to be inserted after each page. 5.11.2.3 Suppress ^a info Specifies that extended message information, normally hidden behind a ^a (ASCII 1) character, should remain hidden and not be output to the printer. 5.11.2.4 Page length Specifies the number of printable lines of text that will fit on one page; i.e. the printable length or height. 5.11.2.5 Page width Specifies the number of printable characters that will fit on one line of the paper; i.e. the printable width. 5.11.2.6 Left margin Specifies the number of columns to leave (skip) before printing on each line. 5.11.2.7 Top margin Specifies the number of lines to leave (skip) before printing on each page. FDSETUP Page 67 FrontDoor Administrator Guide 5.11.2.8 Bottom margin Specifies the number of lines to leave (skip) at the end of each page. 5.11.3 Strings Specifies configuration options related to printer initialization and basic type face control for the printer. For all of the below options, it is possible to specify a character using hexadecimal notation as follows: ~HH Where HH is a two-digit hexadecimal number in the range 00 - FF. E.g. ~1b and ~1B both specifies the ASCII 27 () character. 5.11.3.1 Init Specifies the initialization string to send to the printer. This should include page and font setup, as well as clearing any printer options and settings modified by programs previously using the printer. 5.11.3.2 Reset Specifies the reset string to send to the printer. This should reset any specific options and settings configured in the Init string (above) as well as bold and italics typeface settings. 5.11.3.3 Bold on Specifies the string to send to the printer to enable a bold typeface. This should not clear italics typeface. FDSETUP Page 68 FrontDoor Administrator Guide 5.11.3.4 Bold off Specifies the string to send to the printer to disable a bold typeface. This should not clear italics typeface. 5.11.3.5 Italics on Specifies the string to send to the printer to enable italics typeface. This should not clear bold typeface. 5.11.3.6 Italics off Specifies the string to send to the printer to disable italics typeface. This should not clear bold typeface. 5.11.4 Xlat.Out Allows the definition of a so called translation table. The translation table can be used to perform one-to-one character mapping/translation when the programs output data to the printer. 5.11.5 Fax Specifies configuration options related to the printing of fax documents. This requires an external program to create the actual data to be sent to the printer, as well as communicating with the printer to transmit that data. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 5.12 MANAGER MENU The Manager menu consists of three options related to various configuration settings for FD. FDSETUP Page 69 FrontDoor Administrator Guide 5.12.1.1 Events See "Events". 5.12.1.2 Security See "Mail security" 5.12.1.3 Modem See "Modem configuration" FDSETUP Page 70 FrontDoor Administrator Guide 6. THE NODELIST The nodelist is the common term used throughout the FrontDoor documentation to describe a rather complex topic. In the simplest of definitions, the nodelist is very much like a phone directory listing (phone book). But it contains a lot more information than a name and a telephone number, and different programs in the FrontDoor package use different parts of this information. Among the many uses of the nodelist are to allow the user to perform name look-ups when writing messages, to retrieve information about remote systems, to check if a remote system is known to the local system or should be treated as an unlisted system, etc. FD requires that the nodelist be present whereas FM and the Terminal can both be used without one, if so required. 6.1 BASE COMPONENTS The nodelist is a structure similar to an inverted tree. Primarily, the nodelist is divided into one or more Zones, each of which is in turn divided into Region and Net sub-sections. Each net contains the details of one or more individual systems (or Nodes), and finally a Node may have one or more Client/Point sub-systems. 6.1.1 Zone Usually a large geographical area, such as Europe, North America, South America, Africa, Asia, etc. 6.1.2 Region Usually a somewhat smaller geographical area than that denoted by a zone, such as a country or part of a (large) country. A collection of regions make up one zone. The Nodelist Page 71 FrontDoor Administrator Guide 6.1.3 Net Usually a collection of systems local to each other. Typically a city and in some cases including its suburbs. A collection of nets make up one region. The coordinating system of a net is called a Host. Host systems normally act as a default drop-off system for mail that is destined for a system located in the net. 6.1.4 Node A single system within a net. 6.2 ADDITIONAL COMPONENTS Three additional components can exist in a nodelist: 6.2.1 Hub A hub is typically used to consolidate mail at specific pick- up/delivery points in large nets. This is done to make mail distribution within a net more efficient as far as cost and/or delivery time is concerned. 6.2.2 Server/Boss A server - also called Boss - is the term used to describe a system which has one or more clients (see below) attached to it. In terms of logical placement within the nodelist hierarchy, a server/boss is identical to a node (see above). 6.2.3 Client/Point A client - also called Point - is typically an individual user with a unique address. These users can reside at the same geographical location, e.g. an office, or be loosely tied to a geographical location, e.g. distance workers, field staff, etc. The Nodelist Page 72 FrontDoor Administrator Guide 6.3 ADDRESSES Each individual system has a unique identifier called an address. The address is made up of four components: Zone, Net, Node, and Point (see above for an explanation of these components). A complete address is expressed as: Zone:Net/Node.Point, where .Point is often omitted if it has a value of zero (.0). As previously mentioned, these components are normally used to classify different geographical areas such as continents, countries, cities, etc. The primary reason for using these components instead of an arbitrary number is to be able to quickly group a number of systems together. For example, if zone 200 is used for the North American continent, it is easy to see that a system with the address 200:3000/123 is located somewhere on that continent. 6.4 LAYOUT The nodelist's information is primarily contained in ASCII (text) source files. FDNC (see "Programs") is used to create the actual nodelist database from one or more source files. For a small network, FDNC can be used to directly create the nodelist database, without the requirement of source files. Once the nodelist database has been prepared, it is ready to be used by FD, FM, FDNC, and any other program that can directly interface with the FrontDoor nodelist. The optimal layout and structure of your nodelist greatly depends on the number of entries it contains, as well as the method(s) used to deliver mail within the network. For a small network, with just a few systems, it is usually not a requirement that you follow the implied meaning of the base nodelist components (see "Base components", above). A network consisting of five offices in two different cities is outlined below; two different layouts have been used, each with its advantages and disadvantages: The Nodelist Page 73 FrontDoor Administrator Guide 6.4.1 Layout-1 Zone,300,XYZ_Corp_Network,Europe,John_Doe,46-8-8888888,33600,V34,CM Host,1,XYZ_Corp_Sthlm,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,1,XYZ_Corp_Sthlm_City,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,2,XYZ_Corp_Sthlm_East,Sthlm,Amanda_Doe,46-8-7777777,33600,V34,CM ,3,XYZ_Corp_Sthlm_West,Sthlm,Daniel_Doe,46-8-6666666,64000,X75,CM Host,2,XYZ_Corp_Gbg,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,1,XYZ_Corp_Gbg_City,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,2,XYZ_Corp_Gbg_R&D,Gbg,Andrew_Doe,46-31-4444444,33600,V34,CM 6.4.2 Layout-2 Zone,300,XYZ_Corp_Network,Europe,John_Doe,46-8-8888888,33600,V34,CM Host,1,XYZ_Corp_Sthlm,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,1,XYZ_Corp_Sthlm_City,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,2,XYZ_Corp_Sthlm_East,Sthlm,Amanda_Doe,46-8-7777777,33600,V34,CM ,3,XYZ_Corp_Sthlm_West,Sthlm,Daniel_Doe,46-8-6666666,64000,X75,CM ,4,XYZ_Corp_Gbg_City,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,5,XYZ_Corp_Gbg_R&D,Gbg,Andrew_Doe,46-31-4444444,33600,V34,CM Both layouts define five unique systems, all located in zone 300. You will notice that some systems appear to be duplicated - they are. It is common - in most network layouts - that a system which functions as a zone, region, host, or hub system, also has a "normal" (node) entry. This is by no means a requirement, but it simplifies the task of changing the entries with special meaning (zone, region, host, and hub) without having an impact on how mail is delivered throughout the network. Layout-1 defines the following systems: 300:300/0 XYZ Corp Network (also 300:1/0 below) 300:1/0 XYZ Corp Stockholm (also 300:1/1 below) 300:1/1 XYZ Corp Stockholm City 300:1/2 XYZ Corp Stockholm East 300:1/3 XYZ Corp Stockholm West 300:2/0 XYZ Corp Gothenburg (also 300:2/1 below) 300:2/1 XYZ Corp Gothenburg City 300:2/2 XYZ Corp Gothenburg R&D The Nodelist Page 74 FrontDoor Administrator Guide Layout-2 defines the following systems: 300:300/0 XYZ Corp Network (also 300:1/0 below) 300:1/0 XYZ Corp Stockholm (also 300:1/1 below) 300:1/1 XYZ Corp Stockholm City 300:1/2 XYZ Corp Stockholm East 300:1/3 XYZ Corp Stockholm West 300:1/4 XYZ Corp Gothenburg City 300:1/5 XYZ Corp Gothenburg R&D The addresses 300:300/0, 300:1/0, and 300:2/0 are the logical result of using the special entries zone and host. A zone entry automatically generates an address of Zone:Zone/0. A host entry generates an address of Zone:Host/0. In the above two examples, it is quite clear that Layout-2 has less overhead than Layout-1 as far as the number of systems defined. This is primarily due to the missing of the second Host entry. And for a small network, it is unnecessary to overly complicate the network layout. But when applied in a network with some additional offices in each city, some of which cannot be reached during certain times of the day, or offices in additional cities, Layout-1 serves as a good starting point for a well-structured network. It utilizes two Host entries, one for each city, which creates two separate entities that clearly outline the geographical separation of the offices. As far as the duplication of addresses in the above two layouts is concerned, it should be noted that the special purpose entries (zone and host) are typically only used for mail delivery purposes. It is rare that messages are written to a user on a special purpose system if they also have a "normal" (node) entry in the network. 6.4.3 Source file format The required file format for a source file will now be described. The Nodelist Page 75 FrontDoor Administrator Guide Each line in a source file is either a comment or a network entry. Empty lines are ignored but can be used in place of comments to separate lines. Adding empty lines or comments to separate zones, nets (host), etc. makes it easier to read and manage the source file, but does not affect how FDNC interprets the file when it creates the actual nodelist database. All lines must be terminated by a (ASCII 13, ASCII 10) pair, as is typical for most text-file editors. * No field may contain comma (,) or space (ASCII 32) characters; an underscore character (_) is used to represent a space character. The format for a line containing a network entry is: [],,,,,,,[] 6.4.3.1 KeyW Keyword Zone, Region, Host, Hub, Boss, Server, Point, Pvt, Down, Hold, Route, or nothing (empty). The Pvt, Down, and Hold keywords are used to indicate exceptional status of an entry. o Pvt is used for entries without any data in the (telephone number) field, or if the field contains -Unpublished-; the Pvt keyword indicates that the system cannot be called directly. o Down is used to indicate that the system is not operational. o Hold is used to indicate that the system is not operational but that the condition is temporary. Mail is typically sent via the system's hub or host (see above). The Route keyword is used to specify the default routing target for entries following the line containing the Route keyword, until another keyword that modifies the default routing target (Host, Hub, or Route) is encountered. The Route keyword is only processed (honored) if it appears within a net. The Nodelist Page 76 FrontDoor Administrator Guide The format of the Boss/Server and Route keywords differ somewhat from that of other keywords: Route,/ e.g. ROUTE,201/330 Server,:/ e.g. SERVER,2:201/330 * Typically, the addresses of systems with special meaning (Zone, Region, Host, and Hub) are only used for mail delivery purposes. 6.4.3.2 SNum System number A number 1-65535. This field defines the system's number within the current level or branch. The system number cannot be duplicated within the current level, nor can a zone, region, or host entry appear with the same system number within a zone. If the field specifies Zone, Region, or Host, the contents of the field define the zone, region, and net number respectively. Some examples follow: Zone,3,.. defines 3:3/0, the zone entry for zone 3. Region,30,.. defines 30/0 (region) in whatever the current zone is. Host,300,.. defines 300/0 in whatever the current zone and region, if any, is. The Nodelist Page 77 FrontDoor Administrator Guide The actual numbers used for Zone, Region, and Host entries are not important. In most network layouts, however, it makes sense to use some sort of scheme when assigning the numbers. For Zone entries, the order of appearance is often used, e.g. 1, 2, 3, .., 10, and so on. For Region entries, a similar scheme can be applied - using the order of appearance within the current zone. For Host entries, telephone number area codes or country codes are often used. Note that if specifies Zone, the zone number specified after the keyword is used for all entries following the line with the Zone keyword; until another line containing the Zone keyword is encountered. Similarly, if specifies Region or Host, the host (net) or region number specified after the keyword is used for all entries following the line with the Host/Region keyword; until another line containing the Zone, Region, or Host keyword is encountered. 6.4.3.3 SName System name The name of the system. This field should contain a descriptive name of the system; a company name, branch name, etc. Note that spaces (ASCII 32) should be replaced with underscore (_) characters. 6.4.3.4 SLoc System (geographical) location The geographical location of the system. Depending on the layout of the nodelist, it may not be necessary to specify the complete location. If the field for Zone, Region, and Host entries is used to indicate a general description of the geographical area (e.g. North America, Europe, Scandinavia, etc), the field typically contains a description relative to that location for other entries. Note that spaces (ASCII 32) should be replaced with underscore (_) characters. 6.4.3.5 Op System operator The name of the person primarily responsible for maintaining the system (the SysOp) specified as Firstname_Lastname (e.g. John_Doe). Note that spaces (ASCII 32) should be replaced with underscore (_) characters. The Nodelist Page 78 FrontDoor Administrator Guide 6.4.3.6 TelNo Telephone number The telephone number of the system in universal (raw, or untranslated) format. If the field contains Pvt, this field should contain exactly -Unpublished-. This field should be structured to aid automated dial translation (see "FDNC") for programs (such as FD). It is typically divided into two, three, or four numeric sub-fields separated by dashes (-); e.g. 46-8-55630102 (Sweden, Stockholm), 1-800-555-0123 (USA, toll-free number), and so on. The first sub-field should be the country code. If the country in which the system is located uses area codes or city codes, they should be placed in the second sub-field. 6.4.3.7 Speed Maximum speed of modem The maximum speed supported by the modem (or other device) attached to the system when it is communicating with another modem (or device). This field is typically of little use other than to estimate the time it takes to transfer a file to or from the system. It is, however, recommended that it is properly maintained to reflect as close to reality as possible. Valid contents for this field are: 300, 1200, 2400, 4800, 9600, 12000, 14400, 16800, 19200, 21600, 24000, 28800, 31200, 33600, 38400, 57600, 64000, 78600, 115200, 128000, and 256000. 6.4.3.8 Flags Special capabilities indicator This (optional) field is used to indicate special capabilities and restrictions applicable to the system. See "Nodelist flags" below for a more detailed reference to the various flags and their meaning. FD ignores most of these flags, but can be configured to not dial a specific system based on the contents of the flags field. The Nodelist Page 79 FrontDoor Administrator Guide 6.4.3.9 Comments A line with a semi-colon (;) as its first non-space character is a comment. It is ignored by FDNC and other nodelist processing tools. Comments can be used to separate zones and nets, which makes it easier to view and edit the nodelist source file(s). Example of comments: ;This is the XYZ Corporation Network (Zone 300) ; Zone,300,XYZ_Corp_Network,Europe,John_Doe,46-8-8888888,33600,V34,CM ; ;This is the XYZ Corporation Net in Stockholm Sweden (330:1/*) Host,1,XYZ_Corp_Sthlm,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,1,XYZ_Corp_Sthlm_City,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,2,XYZ_Corp_Sthlm_East,Sthlm,Amanda_Doe,46-8-7777777,33600,V34,CM ,3,XYZ_Corp_Sthlm_West,Sthlm,Daniel_Doe,46-8-6666666,64000,X75,CM ; ;This is the XYZ Corporation Net in Gothenburg Sweden (330:2/*) Host,2,XYZ_Corp_Gbg,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,1,XYZ_Corp_Gbg_City,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,2,XYZ_Corp_Gbg_R&D,Gbg,Andrew_Doe,46-31-4444444,33600,V34,CM 6.5 NODELIST FLAGS Below is a list of several nodelist flags and their meaning. Flag CM Description Continuous mail - indicates that the telephone number specified in the nodelist entry is dedicated for mail purposes. When the telephone is answered, it is always answered by mail capable software, such as FD. Flag MO Description Mail only - indicates that the system does not allow interactive (e.g. BBS) access. The Nodelist Page 80 FrontDoor Administrator Guide Flag LO Description Listed only - indicates that the system only accepts mail calls from systems listed in its nodelist database. Flag MN Description No compressed mail - indicates that the system does not handle compressed mail. Flag V32 Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.32 (9600 BPS full duplex) protocol. Flag V32B Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.32bis (14400 BPS full duplex) protocol. Flag V42 Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.42/LAPM error correction protocol. Flag V42B Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.42bis data compression protocol. Flag V34 Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.34 (28800 BPS full duplex) protocol. The Nodelist Page 81 FrontDoor Administrator Guide Flag ZYX Description Device - indicates that the communications device attached to the system is capable of supporting the proprietary ZyXEL protocol. Flag HST Description Device - indicates that the communications device attached to the system is capable of supporting the proprietary HST protocol. Flag FAX Description Device - indicates that the system is capable of receiving fax transmissions. Flag X2C Description Device - indicates that the communications device attached to the system is capable of supporting the USR X2 client protocol. Flag X2S Description Device - indicates that the communications device attached to the system is capable of supporting the USR X2 server protocol. Flag XA Description File requests - indicates that the system honors all types of file requests (all systems using FD and honoring file requests should have this flag present in their nodelist entry). Flag XB, XC, XP, XR, XW, XX Description File requests - indicates that the system honors specific types of file requests (FD can request files from any system with one of these flags in their nodelist entry). The Nodelist Page 82 FrontDoor Administrator Guide Flag X75 Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T X.75 (ISDN) protocol. Flag V110L Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.110 (19200 async "low") protocol. Flag V110H Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.110 (38400 async "high") protocol. Flag V120L Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.120 (57600 async) protocol. Flag V120H Description Device - indicates that the communications device attached to the system is capable of supporting the ITU-T V.120 (64000 async) protocol. Flag ENC Description Encrypted mail - indicates that the system accepts inbound encrypted mail. The Nodelist Page 83 FrontDoor Administrator Guide Flag U... Description User flag - one or more flags not otherwise covered by already defined nodelist flags; the user flag(s) may contain any alphanumeric character except spaces (ASCII 32). The maximum (total) length of user flags is 32 characters. The U (capital u) character should not be repeated. It is recommended that the initial U is immediately followed by a comma and then by one or more user flags, separated by commas. For example: ,U,REC,NEC 6.6 POINTS Adding a definition of one or point addresses in the nodelist database can be accomplished by including separate point lists into the nodelist database (see "FDNC"), or by using the Point keyword as indicated below: ;This is the XYZ Corporation Network (Zone 300) ; Zone,300,XYZ_Corp_Network,Europe,John_Doe,46-8-8888888,33600,V34,CM ; ;This is the XYZ Corporation Net in Stockholm Sweden (330:1/*) Host,1,XYZ_Corp_Sthlm,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,1,XYZ_Corp_Sthlm_City,Sthlm,John_Doe,46-8-8888888,33600,V34,CM ,2,XYZ_Corp_Sthlm_East,Sthlm,Amanda_Doe,46-8-7777777,33600,V34,CM ,3,XYZ_Corp_Sthlm_West,Sthlm,Daniel_Doe,46-8-6666666,64000,X75,CM Point,1,Daniel_at_home,Sthlm,Daniel_Doe,-Unpublished-,33600, ; ;This is the XYZ Corporation Net in Gothenburg Sweden (330:2/*) Host,2,XYZ_Corp_Gbg,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,1,XYZ_Corp_Gbg_City,Gbg,Chris_Doe,46-31-5555555,33600,V34,CM ,2,XYZ_Corp_Gbg_R&D,Gbg,Andrew_Doe,46-31-4444444,33600,V34,CM Note the use of the Point keyword above (Daniel at home); the resulting network address is 300:1/3.1 (point one of 300:1/3). The above points can also be placed in a separate point list as indicated below (note the lack of the Point keyword): The Nodelist Page 84 FrontDoor Administrator Guide ;Points for 300:1/3 Boss,300:1/3 ,1,Daniel_at_home,Sthlm,Daniel_Doe,-Unpublished-,33600, The Nodelist Page 85 FrontDoor Administrator Guide 7. FDNC FDNC is the FrontDoor Nodelist Compiler or Manager used to maintain the FrontDoor nodelist database. FDNC is most frequently used as a command-line utility and invoked from a batch file or another program; it can also be used interactively. When FDNC is run from the command-line to compile the nodelist database, it reads the nodelist configuration from a file called FDNODE.CTL, located in the NODELIST directory. This file contains information about which nodelist source files should be processed, as well as telephone number dial translation, and cost information data. * It should be noted that FDNC will only add entries to the system log file when it is run as a command-line utility. 7.1 FDNODE.CTL This file is located in the NODELIST directory. It is a plain ASCII (text) file containing information which determines how FDNC should compile the nodelist database and its associated files. Each line in FDNODE.CTL is either a comment, command, or data for a command. Empty lines are ignored but can be used in place of comments to separate lines. Adding empty lines or comments to separate commands makes it easier to read and manage the file, but does not affect how FDNC interprets it when it creates the actual nodelist database. All lines must be terminated by a (ASCII 13, ASCII 10) pair. 7.1.1 Comments A line with a semi-colon (;) as its first non-space character is a comment. It is ignored by FDNC and other nodelist processing tools. FDNC Page 86 FrontDoor Administrator Guide 7.1.2 IGNOREBADNL When FDNC is interpreting FDNODE.CTL or a nodelist source file, it performs basic syntax checking in an attempt to detect format errors, etc. When such errors are detected, FDNC will normally stop its processing and terminate with a specific errorlevel to indicate that an input file error has occurred; this may leave the system in an unusable state. To prevent FDNC from performing this syntax checking, the IGNOREBADNL command can be placed on a line by itself, somewhere near the top of the FDNODE.CTL file. 7.1.3 POINTLIST [] This command specifies that FDNC should incorporate the contents of into the nodelist database. If contains a native pointlist (i.e. one without Boss/Server keywords), the field must be used; it should contain the Server/Boss address of the points defined in . When FDNC encounters a POINTLIST command, it copies the contents of into a file called FDPOINT.PVT (the file is created/truncated when the first POINTLIST command is encountered). If the field has been specified, FDNC inserts Boss,
into the file before copying the contents of the file. may contain wildcards, in which case FDNC will use the most recent file of the files matching the specified filemask. 7.1.4 PVTLIST [] This command specifies that FDNC should incorporate the contents of into the nodelist database. If is a nodelist source file without a Zone entry as the first entry, the field must be used; it should contain the zone number to which the systems defined in belong. * Only the first PVTLIST command in FDNODE.CTL may contain the field. FDNC Page 87 FrontDoor Administrator Guide When FDNC encounters a PVTLIST command, it copies the contents of into a file called FDNET.PVT (the file is created/truncated when the first PVTLIST command is encountered). may contain wildcards, in which case FDNC will use the most recent file of the files matching the specified filemask. 7.1.5 SWEPULSE This command should only be used if the following conditions are met: o The system is connected to the Swedish PSTN. o The system is using pulse dialing. o The modem connected to the system cannot handle proper pulse dial translation for Sweden. The SWEPULSE command forces a remapping of digits in telephone numbers so that the correct telephone number is dialed when the above listed conditions are met. This command is typically not needed with modern equipment. 7.1.6 PHONE
This command is used to override a telephone number listed for
in a nodelist source file. When FDNC encounters this command, it copies the nodelist entry for the system specified in the
field to the internal nodelist database and then replaces the telephone number field with the number specified in ; the specified telephone number should follow the same format as telephone numbers in the nodelist source files. If the system specified in
does not exist in the nodelist database, no action is taken by FDNC. FDNC Page 88 FrontDoor Administrator Guide 7.1.7 USE ZONE [ .. / / This command indicates the start of the dial translation table. The table is used to determine how FD dials a particular telephone number. If no national prefix and suffix is required, a single slash (/) should be used. Likewise, if no international prefix and suffix is required, a single slash (/) should be used. These fields determine what, if anything, should be inserted before (Prefix) and after (Suffix) the telephone number when FD calls a system by dialing its number. The Global.General.Country code setting in FDSETUP determines what is considered domestic and international telephone numbers respectively. FDNC considers all lines, from the DIAL command until an END command is encountered, to be part of the dial translation table. The lines following the DIAL command, if any, consist of two fields: a search string, and a replacement string. The translation table fields do not have to contain digits (0-9). They may contain anything supported by the attached communications device; e.g. S25=100 could be used as the suffix part of a field if that sequence is supported by the communications device. FDNC Page 89 FrontDoor Administrator Guide 7.1.8.1 Example 1 (Country code = 46): DIAL / 009 ;Add 009 to intl numbers not matched below 46-8- ;Remove 46-8- if starting with 46-8- (local) 46- 0 ;Remove 46- and add 0 if starting with 46- ;(domestic) END ;;End of dial translation table The above dial translation will translate the following (raw) numbers as listed: 46-8-123456 Dialed as 123456 (local) 46-40-7890123 Dialed as 040-7890123 (domestic) 1-800-555-0123 Dialed as 0091-800-555-0123 (international) FDNC Page 90 FrontDoor Administrator Guide 7.1.8.2 Example 2: DIAL 12345-1- / ;Add 12345-1- to natl numbers not ;matched below END ;End of dial translation table 7.1.8.3 Example 3: DIAL /2222 00/1111 ;Append (suffix) 2222 to all natl ;numbers not matched below. ;Add 00 to all intl numbers not ;matched below ;Append (suffix) 1111 to all intl ;numbers not matched below. END ;End of dial translation table 7.1.8.4 Example 4 (Country code = 46): DIAL / 009 ;Add 009 to intl numbers not matched below 46- ;Remove 46- if starting with 46- 46-8- /391 ;Append (suffix) 391 if starting with ;46-8- (and remove 46-8-) 61- 00961-/X2 ;Translate 61- to 00961- and append ;(suffix) X2 END ;End of dial translation table 7.1.8.5 IP translation A special type of dial translation is indicated by using the Internet keyword in a translation field; this is called IP translation and is used to convert a telephone number to something that resembles an Internet IP address. An example of IP translation follows: FDNC Page 91 FrontDoor Administrator Guide DIAL / 009 ;Add 009 to intl numbers not ;matched below # Internet ;IP translate numbers starting with .#. 0000- Internet/:155 ;IP translate numbers starting with 0000- V Internet# ;IP translate numbers starting with .V. END ;End of dial translation table The above dial translation will translate the following (raw) numbers as listed: #2-2-2-0 dialed as 2.2.2.0 (note that the dashes have been translated to dots) 0000-3-3-3-0 dialed as 3.3.3.0:155 (note the :155 suffix) V4-4-4-0 dialed as #4.4.4.0 7.1.9 COST This command indicates the start of the cost table. The table is used to determine how much it costs to dial a particular telephone number. The cost-to-dial figure can be used to limit which systems FD calls during specific times of the day, and with other call- control options. The two default parameters, and , are required; they determine the default cost for a domestic call, as well as the default cost for an international call. The default values are only used if no match is made in the actual cost table. The Global.General.Country code setting in FDSETUP determines what is considered domestic and international telephone numbers respectively. FDNC considers all lines, from the COST command until an END command is encountered, to be part of the cost table. The lines following the COST command, if any, consist of two fields: the telephone number match criteria, and its associated cost. FDNC Page 92 FrontDoor Administrator Guide 7.1.9.1 Example (Country code = 46): COST 0 100 ;Default domestic cost=0, international cost=100 1- 75 ;Canada and the US 1-800- 0 ;Canada and the US, toll-free numbers 46- 35 ;Sweden (can be replaced by default natl cost) 46-31- 25 ;Sweden, city of Gothenburg END ;End of cost table The above cost table will assign the following costs to the below numbers as listed: 46-8-123456 cost 35 (Sweden) 46-31-7890123 cost 25 (Sweden, city of Gothenburg) 1-315-123-4567 cost 75 (Canada and the US) 1-800-555-0123 cost 0 (Canada and the US, toll-free number) 32-123-4567 cost 100 (no match, default international cost) 7.1.9.2 Cost assignment for IP translated numbers When the special IP translation (see above) has been used to translate a telephone number, a special entry in the cost table must be used to apply cost to the call. If no such entry exist in the cost table, the default international cost will be used. The special entry is created by using the text Internet in the first field, followed by the cost in the second field. This cost will apply to all numbers that have been translated using the IP translation feature. FDNC Page 93 FrontDoor Administrator Guide 7.2 PVTLIST AND POINTLIST As previously mentioned, the PVTLIST and POINTLIST commands in FDNODE.CTL copy the specified source file(s) into FDNET.PVT and FDPOINT.PVT respectively; it is, however, not necessary to use these commands simply to maintain a private nodelist. 7.2.1 FDNET.PVT If no PVTLIST commands are used in FDNODE.CTL, FDNC will not modify the contents of an existing FDNET.PVT file. Thus, if only one local nodelist source file exists, it can be named FDNET.PVT and placed in the NODELIST directory. 7.2.2 FDPOINT.PVT If no POINTLIST commands are used in FDNODE.CTL, FDNC will not modify the contents of an existing FDPOINT.PVT file. Thus, if only one local nodelist source file containing points exists, it can be named FDPOINT.PVT and placed in the NODELIST directory. 7.3 NODELIST GROUPS Nodelist groups can be used to categorize specific systems; FDNC will automatically place entries from specific files into groups as follows: Group 1: Entries from the raw nodelist (typically the file NODELIST.NNN where .nnn is a numerical extension representing the day-of-year number when it was created). Group 2: Entries compiled from FDNET.PVT (which usually contains the combined result of all occurrences of the PVTLIST command). Group 3: Entries compiled from FDPOINT.PVT (which usually contains the combined result of all occurrences of the POINTLIST command). FDNC Page 94 FrontDoor Administrator Guide Groups A through Z are user assigned groups, which can be used when importing lists into the nodelist database and when existing entries in the nodelist database are edited and saved to the internal database. 7.4 COMMAND-LINE USE OF FDNC As previously mentioned, FDNC is mostly used as a command-line utility to compile the nodelist source file(s) into the nodelist database. If FDNC is started without parameters, its interactive interface will be displayed. Please refer to "Batch files" for a list of possible errorlevels returned by FDNC. This section outlines the FDNC command-line parameters and their function. All FDNC command-line parameters can be specified as , , or , e.g. /Parm -Parm Parm are all treated as the same parameter; command-line parameters are case insensitive, unless otherwise noted. If a parameter requires additional data (such as EDITFILE below), it follows the parameter separated by a space (ASCII 32). The order of command-line parameters does not matter, unless otherwise noted. For clarity, all parameters below are prefixed with a single slash (/). 7.4.1 COMPILE Parameter format: /C or /COMPILE FDNC will compile the nodelist source files into the nodelist database if it detects that a source file (or FDNODE.CTL) has been modified since the nodelist database was last compiled. FDNC Page 95 FrontDoor Administrator Guide 7.4.2 FORCECOMPILE Parameter format: /F or /FORCECOMPILE FDNC will unconditionally compile the nodelist source files into the nodelist database. 7.4.3 PHONECOMPILE Parameter format: /P or /PHONECOMPILE Forces FDNC to process COST, DIAL, and PHONE commands in FDNODE.CTL. FDNC will ignore any other command it encounters in FDNODE.CTL. 7.4.4 MISSINGOK Parameter format: /MISSINGOK Forces FDNC to ignore missing nodelist source files specified with the PVTLIST and POINTLIST commands in FDNODE.CTL. FDNC will normally abort with an error message when it cannot find a nodelist source file. This parameter can also be specified in the FDOPT environment variable as MISSINGOK. 7.4.5 EDITFILE Parameter format: /EDITFILE This invokes FDNC's internal text editor to edit an ASCII (text) file. When the editor is closed, FDNC will terminate, unless the /NOEXIT (see below) parameter has also been specified or an error occurs while editing the file. is one of the following: ROUTEFILE The FD source route file (ROUTE*.FD) in the SYSTEM directory. FDNC will suggest the actual filename to be edited; the suggested filename can be used as is or edited before the actual editor is invoked. NAMEMACROS FDNC Page 96 FrontDoor Administrator Guide The file NAMES.FD in the SYSTEM directory. BANNERFILE The file specified in FDSETUP (Global.Filenames.Banner). NOBBSFILE The file specified in FDSETUP (Global.Filenames.No BBS). BADBPSFILE The file specified in FDSETUP (Global.Filenames.Bad BPS). REQLSTFILE The file specified in FDSETUP (Mailer.File requests.Filenames.List). SECREQLSTFILE The file specified in FDSETUP (Mailer.File requests.Filenames.SecList). ALIASFILE The file specified in FDSETUP (Mailer.File requests.Filenames.Alias). SECALIASFILE The file specified in FDSETUP (Mailer.File requests.Filenames.SecAlias). REQMSGFILE The file specified in FDSETUP (Mailer.File requests.Filenames.Message). FDNODECTLFILE The file FDNODE.CTL in the NODELIST directory. OTHERFILE FDNC Page 97 FrontDoor Administrator Guide Another ASCII file, specified after the OTHERFILE parameter (separated by a space). For example: FDNCEDITFILEOTHERFILEC:\AUTOEXEC.BAT would invoke the text editor with C:\AUTOEXEC.BAT as the file to edit. The file specified as the file to edit must not contain wildcards; the file need not exist, in which case FDNC displays a warning that the file could not be found, and then allows a new file to be created. 7.4.6 EXPORT Parameter format: /EXPORT * All parameter must be specified. If the /NOEXIT parameter is used, it must be specified after the parameter. is the equivalent of the Mode option when FDNC is used interactively and is one of: NLIST Nodelist PLIST Pointlist PBOOK Phonebook FDAPX FrontDoor APX ZLIST Zone list ZRLIST Zone+Region list ZRHLIST Zone+Region+Host list is the file to which the exported entries should be written; an existing file will be overwritten. is the group or groups (A-Z, 1-3, or *) to include - use a single asterisk (*) to include all groups. is the group or groups (A-Z, 1-3, or !) to exclude - use a single exclamation mark (!) to specify that no groups should be excluded. FDNC Page 98 FrontDoor Administrator Guide is related to the various options present when using the Nodelist.Export to file function in FDNC interactively. The parameter must contain six characters (1 or Y for Yes, and 0 or N for No). From left to right, the parameter specifies: Points are Pvt "All" are Pvt Exclude Hold Exclude Down Exclude Pvt Exclude Points Please refer to the Export to file function below ("Interactive use FDNC") for more information about the various modes and options. 7.4.7 BROWSE Parameter format: /BROWSE Invokes the nodelist browser which allows browsing of the nodelist database. 7.4.8 NOEXIT Parameter format: /NOEXIT Used in conjunction with EDITFILE, EXPORT, or BROWSE, this command prevents FDNC from closing (terminating) once the specified operation has been completed. 7.4.9 Combining parameters The EDITFILE, EXPORT, BROWSE, COMPILE, and PHONECOMPILE command-line parameters are mutually exclusive; i.e. only one of these parameters may appear on the command-line. FDNC Page 99 FrontDoor Administrator Guide 7.5 INTERACTIVE USE FDNC FDNC can be used interactively to aid in a number of tasks such as manually editing nodelist entries, exporting portions or all of the nodelist to an ASCII file, and importing one or more nodelist source files directly into the compiled nodelist database. To use FDNC interactively, simply invoke it without any parameters. The main screen of FDNC consists of a pull-down menu system, a work area, and a bottom status line. The work area is the space between the menu bar (top) and the bottom status bar. The pull-down menu layout will now be described. 7.5.1 System menu The system menu contains two menu options: 7.5.1.1 DOS shell Invokes a temporary OS shell which allows operations such as copying and moving of files to be performed. 7.5.1.2 Exit Closes (terminates) FDNC and returns to the command-line or calling program (e.g. FD). 7.5.2 Nodelist menu The nodelist menu contains seven menu options: 7.5.2.1 Edit nodelist Allows editing of individual system entries in the nodelist database. FDNC Page 100 FrontDoor Administrator Guide 7.5.2.2 Browse nodelist Invokes the internal nodelist browser which allows browsing of the nodelist database. This is the same browser invoked by the /BROWSE command-line parameter (see "Command-line use of FDNC", above). 7.5.2.3 Export to file Invokes the nodelist export function (see below). 7.5.2.4 Import from file Invokes the nodelist import function (see below). 7.5.2.5 Compile nodelist Invokes the nodelist compiler. This is the equivalent of running FDNC with the /C (or /COMPILE) command-line parameter (see "Command- line use of FDNC", above). 7.5.2.6 Compile FDNODE.CTL Forces FDNC to process COST, DIAL, and PHONE commands in FDNODE.CTL. This is the equivalent of running FDNC with the /P (or /PHONECOMPILE) command-line parameter (see "Command-line use of FDNC", above). 7.5.2.7 Edit control file Invokes the file editor to allow editing of FDNODE.CTL. This is the equivalent of running FDNC with the /EDITFILE FDNODECTLFILE command- line parameters (see "Command-line use of FDNC", above). 7.5.3 Edit menu The edit menu contains several options, all of which allows the editing of files relevant to the configuration of the system: FDNC Page 101 FrontDoor Administrator Guide 7.5.3.1 Routing.. Invokes the file editor to allow editing of ROUTE*.FD (route source file). This is the equivalent of running FDNC with the /EDITFILE ROUTEFILE command-line parameters (see "Command-line use of FDNC", above). 7.5.3.2 Name macros Invokes the file editor to allow editing of NAMES.FD (name macros file). This is the equivalent of running FDNC with the /EDITFILE NAMEMACROS command-line parameters (see "Command-line use of FDNC", above). 7.5.3.3 Banner file Invokes the file editor to allow editing of the file specified in FDSETUP (Filenames.Banner). This is the equivalent of running FDNC with the /EDITFILE BANNERFILE command-line parameters (see "Command- line use of FDNC", above). 7.5.3.4 No BBS Invokes the file editor to allow editing of the file specified in FDSETUP (Filenames.No BBS). This is the equivalent of running FDNC with the /EDITFILE NOBBSFILE command-line parameters (see "Command- line use of FDNC", above). 7.5.3.5 Bad BPS Invokes the file editor to allow editing of the file specified in FDSETUP (Filenames.Bad BPS). This is the equivalent of running FDNC with the /EDITFILE BADBPSFILE command-line parameters (see "Command- line use of FDNC", above). FDNC Page 102 FrontDoor Administrator Guide 7.5.3.6 Request list Invokes the file editor to allow editing of the file specified in FDSETUP (Mailer.File requests.Filenames.List). This is the equivalent of running FDNC with the /EDITFILE REQLST command-line parameters (see "Command-line use of FDNC", above). 7.5.3.7 Secure request list Invokes the file editor to allow editing of the file specified in FDSETUP (Mailer.File requests.Filenames.SecList). This is the equivalent of running FDNC with the /EDITFILE SECREQLST command-line parameters (see "Command-line use of FDNC", above). 7.5.3.8 Alias list Invokes the file editor to allow editing of the file specified in FDSETUP (Mailer.File requests.Filenames.Alias). This is the equivalent of running FDNC with the /EDITFILE ALIASFILE command-line parameters (see "Command-line use of FDNC", above). 7.5.3.9 Secure alias list Invokes the file editor to allow editing of the file specified in FDSETUP (Mailer.File requests.Filenames.SecAlias). This is the equivalent of running FDNC with the /EDITFILE SECALIASFILE command- line parameters (see "Command-line use of FDNC", above). 7.5.3.10 Request message Invokes the file editor to allow editing of the file specified in FDSETUP (Mailer.File requests.Filenames.Message). This is the equivalent of running FDNC with the /EDITFILE REQMSGFILE command- line parameters (see "Command-line use of FDNC", above). FDNC Page 103 FrontDoor Administrator Guide 7.5.3.11 Other.. Invokes the file editor to allow editing of an ASCII (text) file. This is the equivalent of running FDNC with the /EDITFILE OTHERFILE command-line parameters (see "Command-line use of FDNC", above). 7.5.4 Help menu The help menu contains the About menu option, which displays program information and available memory. FDNC Page 104 FrontDoor Administrator Guide 7.6 THE FDNC ASCII FILE EDITOR The FDNC file editor is a general purpose ASCII (text) file editor with some enhancements suitable for the FrontDoor environment. In the DOS version of FDNC, the editor is, however, not suitable for handling the task of editing large files. The maximum file size the editor can handle is [DOS] somewhere around 55 Kb and/or 1500 lines [OS/2] three megabytes and/or 30000 lines; whichever is first reached. Once the editor is active, its menus are accessed by holding down the ALT key and then pressing one of the letters highlighted in the (top) menu bar; for example, to invoke the File menu, hold down the ALT key and press the F key (ALT+F). For keys and functions not found in the menus, a keyboard reference screen can be accessed by pressing F1. Insert (INS) and Overtype (OVR) mode is toggled by pressing the INS (Insert) key. The current input mode is displayed to the right on the bottom status bar of the editor window. 7.7 THE FDNC NODELIST EDITOR The nodelist editor is used to directly manipulate entries in the compiled nodelist database. When an entry is modified with the editor, it is copied from its current location to the internal nodelist database. The reason for this is that the nodelist source file from which the entry is copied does not necessarily have to exist for as long as the internal nodelist database - this is typically the case where updates to the source file are received on a periodic basis, e.g. once a week, once a month, and so on. To invoke the nodelist editor, select the Edit nodelist option from the Nodelist menu. FDNC Page 105 FrontDoor Administrator Guide If FDNC responds by displaying a message with "Nodelist Database: Access Denied", it is an indication that another program (such as FD or FM) is using the database. Programs that access the nodelist database normally open it using a method that allows several applications to read from, but not write to, the database. FDNC requires exclusive access to the nodelist database before it will allow the Edit nodelist function to be invoked. The Browse nodelist function can be used when other programs have opened the nodelist database for read access. If FDNC responds by displaying a message that indicates one or more missing files, it means that one or more files vital to the (compiled) nodelist database are missing. The nodelist editor cannot be used to create a new nodelist database. See "Creating a new nodelist database" for further information about creating a new nodelist database. If FDNC can successfully open the nodelist database, it will locate the first entry in the database and display it. Until you select to: add a new entry; copy an existing entry as the base for a new entry; or edit an entry; the nodelist editor operates in view mode. 7.7.1 Navigating in view mode All navigation functions listed in the Navigate (ALT+N) menu are accessible directly by using the shortcut listed to the right of each menu option. Some time should be spent learning them as they will simplify finding the desired entry without having to invoke the menu each time. The DatRef field at the bottom of the view mode window is primarily supplied for technical support and troubleshooting purposes. * Even though the contents of the nodelist database cannot be modified from View Mode, it should be noted that no other programs will be able to access the nodelist database while it is being held open by the nodelist editor. FDNC Page 106 FrontDoor Administrator Guide 7.7.2 Editing a nodelist entry The nodelist editor is accessed by selecting New entry (INS), Copy entry (F10), or Edit entry (ENTER) from the File menu. The copy function is similar to the new function with the exception that data for the new entry is copied from the currently displayed entry. The edit entry screen will now be explained. For more information about the contents of the fields displayed in the nodelist editor, refer to "The Nodelist:Layout" above. One important difference between the layout of the nodelist and directly editing an entry with the nodelist editor is that an underscore (_) character is not used to represent a space (ASCII 32) character. The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the topmost (of the available) field; pressing the END key will move the selection bar to the last (of the available) field. The first letter of a field description can also be used to move the selection bar to that field. If more than one field description with the same initial letter exist, the selection bar is moved to the first field the first time the letter is pressed, the second field the second time, and so on. 7.7.2.1 Address The address of the system expressed as Zone:Net/Node.Point, where .Point is optional. The Zone and Net components of the address may not be zero. If an address that already exists in the nodelist database is specified, FDNC will not allow the address to be used. The contents of this field cannot be modified when an existing entry is being edited. 7.7.2.2 Site The name and geographical location of the system. This field consists of two sub-fields (name and geographical location). The TAB key is used to move between the two sub-fields. Pressing the ENTER key in the first sub-field also moves to the second sub-field. FDNC Page 107 FrontDoor Administrator Guide 7.7.2.3 SysOp The name of the person primarily responsible for maintaining the system (the "SysOp") specified as Firstname Lastname (e.g. John Doe). 7.7.2.4 Speed The maximum speed supported by the modem (or other device) attached to the system when it is communicating with another modem (or device). This field is typically of little use other than to estimate the time it takes to transfer a file to or from the system. It is, however, recommended that it is properly maintained to reflect as close to reality as possible. 7.7.2.5 Flags This (optional) field is used to indicate special capabilities and restrictions applicable to the system. FDNC does not allow free- style editing of the flags field. The reason for this is that entries added or edited with the nodelist editor are maintained in an internal nodelist database which only supports the most commonly used flags. Please refer to "The Nodelist:Nodelist flags" for a reference to common flags and their meaning. 7.7.2.6 Phone The telephone number of the system in universal (raw, or untranslated) format. If the Status field contains Pvt, this field should contain -Unpublished-. This field should be structured to aid automated dial translation (see "FDNODE.CTL") for programs (such as FD). It is typically divided into two, three, or four numeric sub- fields separated by dashes (-); e.g. 46-8-55630102 (Sweden, Stockholm), 1-800-555-0123 (USA, toll-free number), and so on. The first sub-field should be the country code. If the country in which the system is located uses area codes or city codes, they should be placed in the second sub-field. FDNC Page 108 FrontDoor Administrator Guide 7.7.2.7 Cost The cost-per-minute value is normally calculated by scanning the cost table (see "FDNODE.CTL") for a match against the telephone number of the system. If this field contains anything but a single asterisk (*), the contents specify (override) the cost-per-minute value. 7.7.2.8 Routing The default routing (see "Mail routing") target for mail addressed to this system. The contents of this field cannot be modified for entries with Zone, Region, Hub, or Point status (see below). For Host (net) entries, this field should contain the number of the region to which the net belongs. For all other entries except those with Point status, this field should contain the address of the system's hub (or host, if no applicable hub exists); for entries with Point status, this field should contain the contents of the Address field minus .Point (i.e. the address of the server/boss). To specify that no default routing target should be used, this field should contain 0/0. * Note that the Zone: and .Point components of an address cannot be specified in this field. 7.7.2.9 Status The status (see "The Nodelist") of the system. For entries with an address of Zone:Net/0 where the Zone and Net components have the same value (e.g. 255:255/0), Zone status is required. For entries with Zone:Net/0 where the Zone and Net components are not the same value, Region or Host status is required. For entries with an address where .Point is specified, Point status is required. FDNC Page 109 FrontDoor Administrator Guide 7.7.2.10 Groups The contents of this field can be used to organize user-maintained nodelist entries into groups. An entry can belong to up to three groups. At least one group (A-Z) must be specified. The contents of the groups field can also be used when specifying which systems to export from the nodelist database (see "Exporting entries from the nodelist", below). 7.8 EXPORTING ENTRIES FROM THE NODELIST The nodelist export function is primarily intended for creating nodelist source files suitable for distribution to other systems; which can then incorporate the exported source file(s) into their (local) nodelist database. The export function does, however, also provide for some export selections which are useful for more general network administration tasks. The output from most export selections is suitable for use as nodelist source data; to be used with the PVTLIST and POINTLIST commands (see "FDNODE.CTL"), or to be imported with the nodelist import function (see "Importing nodelist source files", below). To invoke the nodelist export function, select the Export to file option from the Nodelist menu. The export nodelist screen will now be explained. The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the topmost (of the available) field; pressing the END key will move the selection bar to the last (of the available) field. The first letter of a field description can also be used to move the selection bar to that field. If more than one field description with the same initial letter exists, the selection bar is moved to the first field the first time the letter is pressed, the second field the second time, and so on. The Start Export option will not be available for selection until sufficient data has been supplied for the export function to be used. FDNC Page 110 FrontDoor Administrator Guide * It should be noted that the interactive export function is only available in [ML]. Please refer to the EXPORT command-line parameter (above) for [SL]. 7.8.1 Mode The export function has a number of output selections which have specific values pre-set for applicable fields in the export nodelist screen. Nodelist This is the most flexible default output selection. It allows the contents of all fields to be modified to customize the resulting output. Pointlist Creates output including only point systems (and a reference to their respective server/boss). Phonebook Creates output suitable to be used as an address book (i.e. to be used for user and address lookups in FrontDoor). No telephone numbers are exported, and no flags are exported. FrontDoor APX Creates output suitable to be used with FrontDoor APX for Windows (FDAPX/w). The output is what FDAPX/w expects to find in a ABOOKPUB.TXT file. Use of this mode requires that the userlist index (USERLIST.FDX) is present. Zone list Creates nodelist output containing only Zone entries. Zones+Region list Creates nodelist output containing only Zone and Region entries. Zones+Region+Host list FDNC Page 111 FrontDoor Administrator Guide Creates output containing only Zone, Region, and Host entries. 7.8.2 Filename The name of the file to which the resulting output data should be written. If the name of an existing file is specified, FDNC will prompt for the action to take (Append, Overwrite, etc). 7.8.3 Include groups The groups to include in the exported data. The default is to include all (.*.) groups. Up to ten groups can be specified. 7.8.4 Exclude groups The groups to exclude from the exported data. Up to ten groups can be specified. 7.8.5 Points are Pvt Removes the actual telephone number and replaces it with - Unpublished- for all exported points. 7.8.6 "All" are Pvt Removes the actual telephone number and replaces it with - Unpublished- for all exported entries. 7.8.7 Exclude Hold Excludes entries with Hold status from the exported data. 7.8.8 Exclude Pvt Excludes entries with Pvt status (unpublished) from the exported data. FDNC Page 112 FrontDoor Administrator Guide 7.8.9 Exclude Points Excludes points from the exported data. 7.8.10 Start Export Starts the export function with the specified criteria. 7.9 IMPORTING NODELIST SOURCE FILES [ML] The Import from file function is primarily intended for importing fragments and partial nodelist source files into the nodelist database. It is not intended to be a replacement for the PVTLIST command (see above) which is used to incorporate automatically distributed nodelist source files into the nodelist database. Entries imported into the nodelist database with the Import from file function are always imported to the internal database. The entries must be manually deleted by using the Edit nodelist function, or by removing the file FDNODE.FDA from the NODELIST directory and then recompiling the nodelist database. * CAUTION: If the FDNODE.FDA file is removed from the NODELIST directory, all entries that have been copied and added to the internal database will be removed. To invoke the nodelist import function, select the Import from file option from the Nodelist menu. The import nodelist screen will now be explained. The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the topmost (of the available) field; pressing the END key will move the selection bar to the last (of the available) field. The first letter of a field description can also be used to move the selection bar to that field. If more than one field description with the same initial letter exist, the selection bar is moved to the first field the first time the letter is pressed, the second field the second time, and so on. FDNC Page 113 FrontDoor Administrator Guide The Start Import option will not be available for selection until sufficient data has been supplied for the export function to be used. It should be noted that the USE ZONE command (see above) is not honored by FDNC when importing entries with this function. 7.9.1 Filename The name of the file from which FDNC should read the nodelist entries to be imported. The file must contain sufficient information to define the imported systems. placement within the network hierarchy (i.e. a Zone, Region, and/or Host entries). If the file contains only a fragment of a network hierarchy (i.e. individual systems), the Zone, Region, and Net fields (below) must be properly specified. 7.9.2 Zone Specifies the starting zone; this is typically used when importing files that only contain fragments of a network hierarchy. The specified zone will be used until a Zone entry is encountered in the file from which entries are being imported. 7.9.3 Region Specifies the starting region; this is typically used when importing files that only contain fragments of a network hierarchy. The specified region will be used until a Zone entry or a Region entry is encountered in the file from which entries are being imported. 7.9.4 Net Specifies the starting net; this is typically used when importing files that only contain fragments of a network hierarchy. The specified net will be used until a Zone, Region, or Host (net) entry is encountered in the file from which entries are being imported. FDNC Page 114 FrontDoor Administrator Guide 7.9.5 Group Specifies the group assignment (A-Z) for imported entries. Up to three group "tags" (identifiers) can be specified here. The default group is A. 7.9.6 Duplicates Specifies the action FDNC should take when it encounters an entry that already exists in the nodelist database. Replace existing entries with imported entries Forces FDNC to automatically replace existing entries with the imported entries. Do not replace existing entries with imported entries Forces FDNC to automatically skip entries that already exist in the nodelist database. Prompt for action to take for duplicate entries Forces FDNC to prompt for the action to take when a duplicate entry is encountered. 7.9.7 Points are Pvt Specifies that the telephone number of all imported point entries should be set to -Unpublished-. 7.9.8 "All" are Pvt Specifies that the telephone number of all imported entries should be set to -Unpublished-. This is not applicable to imported Zone, Region, or Host (net) entries. 7.9.9 Exclude Hold Specifies that FDNC should not import entries with Hold status. FDNC Page 115 FrontDoor Administrator Guide 7.9.10 Exclude Down Specifies that FDNC should not import entries with Down status. 7.9.11 Exclude Pvt Specifies that FDNC should not import entries with Pvt (unpublished) status. 7.9.12 Exclude Points Specifies that FDNC should not import point entries. 7.9.13 Start Import Starts the import function with the specified criteria. 7.10 CREATING A NEW NODELIST DATABASE When dealing with large nodelists, it is recommended that interactive maintenance of nodelist entries with FDNC is kept to a minimum. The interactive nodelist editor in FDNC is not designed for the purpose of adding a large number of entries, but rather to add entries that do not yet appear in distributed lists, and to correct or update data in nodelist entries. If the nodelist database contents is only made up of interactively added entries, a skeleton (near-empty) nodelist database must be created prior to using the nodelist editor. This can be done by creating a new FDNET.PVT file, in the NODELIST directory, containing only one entry: Zone,65535,Skeleton,Nowhere,Noname,-Unpublished-,300, once the file has been created with the above contents, FDNC should be used to compile the nodelist, either from the command-line (/F) or from the Nodelist menu. FDNC Page 116 FrontDoor Administrator Guide 8. MAIL ROUTING Mail routing is the common term used throughout this Administrator Guide to describe a very complex topic. In the simplest of definitions, mail routing determines how, when, and if mail is delivered or picked-up; mail routing involves defining a set of rules and exceptions to those rules. FD interprets these rules and handles mail accordingly. Mail routing does not apply to the Terminal, nor does it apply to FM; though it may apply to mail (messages) created with FM. Understanding the details of mail routing requires basic knowledge about the nodelist (see "The Nodelist") and events (see "Events"). 8.1 ROUTE FILE Mail routing rules are specified in the ROUTE*.FD file, located in the SYSTEM directory. This is referred to as the route file. The default file, ROUTE.FD, is used if no task-specific file (ROUTENNN.FD where nnn is 1-255) can be found. FD reads the route file and tokenizes its contents to speed up repetitive processing of the file; once FD has tokenized the file, it will use the tokenized copy until a change in the source file is detected. The tokenized version of the route file is named ROUTE*.FD@ and is stored in the Packets directory as specified in FDSETUP (Global.Filenames.Packets). The tokenized file is referred to as the binary route file. Each line in the route file is either a comment, command, or data for a command. Empty lines are ignored but can be used in place of comments to separate lines. Adding empty lines or comments to separate commands makes it easier to read and manage the file, but does not affect how FD interprets it when it creates the binary route file. All lines must be terminated by a (ASCII 13, ASCII 10) pair and may not exceed 255 characters (including the two terminating characters) in length. All commands in the route file are case insensitive; i.e. ROUTE-TO is the same as route-to is the same as Route-To. Mail routing Page 117 FrontDoor Administrator Guide 8.1.1 Route file sections The route file is divided into two primary sections: a global section and one or more local sections. Each local section is tied to a specific event (see "Events"), while the global section applies to all events; the local sections therefore usually contain commands which override certain aspects of the global section for certain events. A local section is referred to as a schedule block. The global section is made up of all commands appearing before the first occurrence of the SCHEDULE word. 8.1.2 Schedule tags As mentioned above, each local section is tied to a specific event. The event is referred to by a schedule tag. A schedule tag is one letter (@, A-Z excluding X) correlating to the event tag. Mail routing Page 118 FrontDoor Administrator Guide 8.1.3 Schedule blocks A schedule block starts with the word SCHEDULE, followed by a space and a one-letter tag (@, A-Z, excluding X). A schedule block ends when another SCHEDULE word or the end of the route file is encountered. The following is an example of two schedule blocks: SCHEDULE A .. .. SCHEDULE B .. .. 8.1.4 Addresses When a command requires one or more addresses (e.g. , below), the constructs listed below are generally supported, unless otherwise noted. Note that an address list can consist of several lines. 255:3046/1 The system with the address 255:3046/1. 255:3046/* All systems in zone 255, net/region 3046; e.g. 255:3046/0, 255:3046/1, .., 255:3046/65535. 255:* All systems in zone 255. * All systems. Mail routing Page 119 FrontDoor Administrator Guide 8.1.5 Short-form addresses Short-form addressing is the term used when partial addressing information is supplied without the use of an asterisk (see above). Short-form addressing can be used for addresses following the first address specified on a given line. An example follows: SCHEDULE A 255:3046/1 2 3 4 5 The above implies 255:3046/1, 255:3046/2, 255:3046/3, 255:3046/4, and 255:3046/5. For a slightly more verbose version of the above example, the following can be used: SCHEDULE A 255:3046/1 3046/2 3046/3 3046/4 3046/5 The above specifies the same addresses as the first example. Short-form addresses are always resolved by copying missing components from the previously (to the left) specified address. * The first address specified on a line must be a complete address unless it contains an asterisk (where applicable). The following is an example of invalid short-form address usage: SCHEDULE A 2 Another example of invalid short-form address usage: Mail routing Page 120 FrontDoor Administrator Guide SCHEDULE A 2:201/300 400 500 600 8.2 ROUTE COMMANDS Route commands are used to modify the default mail routing rules (see "Default routing", below). Most route commands require additional data. All commands in the route file are case insensitive; i.e. ROUTE-TO is the same as route-to is the same as Route-To. 8.2.1 SCHEDULE [] Defines the start of a schedule block. , the schedule tag, must be a letter @, A-Z excluding X. The tag corresponds to the tag of an event (see "Events"). When an event with the specified tag is active, the schedule block is used to define routing rules or override those specified in the global section which is processed for all events. Only one schedule block with a given tag should exist. The optional implies a QUALIFY construct (see below). The schedule block is made up of all commands following the SCHEDULE command until the next SCHEDULE command or the end of the file is encountered. * It should be noted that use of the SCHEDULE command for a given event is not a requirement; i.e. if no special rules need to be defined for an event, no schedule block for that event needs to be defined. 8.2.2 QUALIFY Qualifies the specified systems. FD will only call systems that have been qualified in the global section, and those defined in the active schedule block. Note that a system can also be qualified by means of special message status settings and static queue (STQ) status settings. The QUALIFY command does not affect how mail is routed. Mail routing Page 121 FrontDoor Administrator Guide The QUALIFY command can also be specified in the schedule block header: SCHEDULE @ 255:3046/* is identical to SCHEDULE @ QUALIFY 255:3046/* Another example: SCHEDULE @ 255:3046/* 255:3045/* is identical to SCHEDULE @ QUALIFY 255:3046/* 255:3045/* or SCHEDULE @ QUALIFY 255:3046/* 255:3045/* * Though possible, it is not recommended that the QUALIFY command be used in the global section of the route file. 8.2.3 HOLD Prevents FD from calling the specified systems. Note that FD may ignore this command if a system has been qualified by means of special message or STQ status (see "Implied routing and qualification"). It is only necessary to apply the HOLD command to systems which have been qualified. Mail routing Page 122 FrontDoor Administrator Guide Note that this command, although identical in name, is not the same as the Hold message status (see "Message status"). 8.2.4 UNHOLD Allows FD to call the specified systems (provided they have been qualified). This command is primarily used to override the effect of a HOLD command which was specified for a range of systems, e.g. HOLD 255:3046/* UNHOLD 255:3046/1 255:3046/2 8.2.5 ROUTE-TO Specifies that mail destined for systems in should be delivered to the system specified in . Using this command does not affect the actual contents of the messages that are redirected. The ROUTE-TO command does not affect messages with file attachments (see "ROUTE-FILES", below). Some implied logics are used by FD when interpreting this command. If the address specified in does not contain a .Point component, FD automatically adds .* to the . Furthermore, if an address in the does not contain a .Point component, FD automatically replaces the address to include all points of the address. This construct: ROUTE-TO 255:3046/1 255:3046/2 (route mail destined for 255:3046/2 via 255:3046/1) is expanded to: ROUTE-TO 255:3046/1 255:3046/1.* 255:3046/2.* Mail routing Page 123 FrontDoor Administrator Guide This construct: ROUTE-TO 255:3046/1.0 255:3046/2.0 is not expanded (both the target and the systems listed in have an explicit .0 component). This construct: ROUTE-TO 255:3046/1.0 255:3046/2 is expanded to ROUTE-TO 255:3046/1.0 255:3046/2.* 8.2.6 ROUTE-FILES Similar to the ROUTE-TO command (above), with the difference that the ROUTE-FILES command only affects messages with file attachments. 8.2.7 HUB-ROUTE Similar to the ROUTE-TO command (above) in that it affects how mail for the specified systems should be routed. The primary difference is that no is specified for the HUB-ROUTE command. FD uses information in the nodelist database to determine the by examining the contents of the Routing field (see "FDNC" and ""The Nodelist). The HUB-ROUTE command does not affect messages with file attachments. Mail routing Page 124 FrontDoor Administrator Guide The Routing field normally contains the default routing target for a given system. If a hub exists, the address of the hub is stored in the field, if no hub exists, the address of the host is stored in the field. If FD cannot locate the system stored in the Routing field, the HUB-ROUTE command will be ignored for the specified address and the mail routed directly to its destination (system). 8.2.8 HOST-ROUTE Similar to the HUB-ROUTE command (above) in that it affects how mail for the specified systems should be routed. Unlike the HUB-ROUTE command, using HOST-ROUTE does not instruct FD to read the information from the nodelist database. Instead, FD simply uses the /0 address (i.e. the host) of the specified system and attempts to locate that system in the nodelist database. If FD cannot locate the (host) system, the HOST-ROUTE command will be ignored for the specified address and the mail routed directly to its destination (system). The HOST-ROUTE command does not affect messages with file attachments. 8.2.9 NO-ROUTE The opposite of ROUTE-TO, HUB-ROUTE, and HOST-ROUTE in that it instructs FD not to attempt routing mail for the specified systems through another system. Some implied logics are used by FD when interpreting this command. The NO-ROUTE command means "route as directly as possible", taking the nodelist into consideration. The NO-ROUTE command does not affect messages with file attachments. When the NO-ROUTE command is applied to a Pvt (unpublished) or Hold system, it will result in a final routing target of the system's hub or host as applicable. Special consideration is taken by FD when interpreting the NO-ROUTE command in regards to points. Unless an explicit point address is specified, or if the point cannot be located in the nodelist database, FD attempts to route the mail via the server/boss of the point (i.e. "as directly as possible"). Mail routing Page 125 FrontDoor Administrator Guide 8.2.10 DIRECT The opposite of ROUTE-TO, HUB-ROUTE, and HOST-ROUTE in that it instructs FD not to attempt routing mail for the specified systems through another system. Some implied logics are used by FD when interpreting this command. The DIRECT command does affect messages with file attachments. Special consideration is taken by FD when interpreting the DIRECT command in regards to points. Unless an explicit point address is specified FD routes the mail via the server/boss of the point (i.e. "as directly as possible"). 8.2.11 FORWARD-TO The FORWARD-TO command is used to allow non-local (transit) mail to pass through the system without manual intervention. The destination address of a message is matched against the systems listed in ; if a match is found, FD allows the message to pass through the system. FORWARD-TO does not affect how messages are routed or delivered. The FORWARD-TO command does not affect messages with file attachments (see "FILES-TO", below). * Note that only one of FORWARD-TO, FORWARD-FOR, FILES-TO, or FILES- FOR has to apply for a transit message to be automatically forwarded. 8.2.12 FORWARD-FOR The FORWARD-FOR command is used to allow non-local (transit) mail to pass through the system without manual intervention. The originating address of a message is matched against the systems listed in ; if a match is found, FD allows the message to pass through the system. FORWARD-FOR does not affect how messages are routed or delivered. The FORWARD-FOR command does not affect messages with file attachments (see "FILES-FOR", below). Mail routing Page 126 FrontDoor Administrator Guide * Note that only one of FORWARD-FOR, FORWARD-TO, FILES-TO, or FILES- FOR has to apply for a transit message to be automatically forwarded. 8.2.13 FILES-TO The FILES-TO command is used to allow non-local (transit) mail to pass through the system without manual intervention. The destination address of a message (with at least one file attachment) is matched against the systems listed in ; if a match is found, FD allows the message and its associated file attachments to pass through the system. FILES-TO does not affect how messages are routed or delivered. The FILES-TO command only affects messages with file attachments (see "FORWARD-TO", above). * Note that only one of FILES-TO, FILES-FOR, FORWARD-TO, or FORWARD- FOR has to apply for a transit message to be automatically forwarded. 8.2.14 FILES-FOR The FILES-FOR command is used to allow non-local (transit) mail to pass through the system without manual intervention. The originating address of a message (with at least one file attachment) is matched against the systems listed in ; if a match is found, FD allows the message and its associated file attachments to pass through the system. FILES-FOR does not affect how messages are routed or delivered. The FILES-FOR command only affects messages with file attachments (see "FORWARD-FOR", above). * Note that only one of FORWARD-FOR, FORWARD-TO, FILES-TO, or FILES- FOR has to apply for a transit message to be automatically forwarded. Mail routing Page 127 FrontDoor Administrator Guide 8.2.15 POLL The POLL command is used to force FD to call a given system at a specific time of the day. FD will call the specified system(s) even if there is no mail waiting to be delivered to the system. If there is outbound mail waiting to be delivered, it will only be delivered if the system has also been qualified for the currently used schedule block (see "QUALIFY", above); i.e. using the POLL command does not automatically qualify a system. If the event (see "Events") in which the POLL command has been used is restarted, FD will not call the system if a successful call was previously placed during the event. * Use of the POLL command in the global section is not recommended. 8.2.16 DENY The DENY command prevents another system from picking up mail during an inbound call. The calling system will only be allowed to deliver its mail. This command is primarily used during events (see "Events") dedicated to the calling of specific systems, or to attempt to make the system as available to handle inbound calls as possible. The DENY command can also be used to prevent mail for a specific address from being picked-up (by accident or deliberately) on a permanent basis by placing it in the global section. This is in particular useful when certain addresses are used internally on the system for specific purposes. * Note that if the DENY command applies to a calling system, it will not be able to request files. 8.2.17 SCRIPT The SCRIPT command is used to specify that FD should use an external script file when calling the systems in . Using script files (see "Scripts") enables extremely flexible dial control. Mail routing Page 128 FrontDoor Administrator Guide * The script files used in the route file must be located in the SYSTEM directory. The default extension is .SCR. 8.2.18 NO-SCRIPT The NO-SCRIPT command is the opposite of the SCRIPT command; it is primarily intended to exclude a few systems from a previously used SCRIPT command construct. For example: SCRIPT POLLFTP.SCR 255:3046/* NO-SCRIPT 255:3046/1 255:3046/2 would instruct FD to use the script file POLLFTP.SCR when calling any 255:3046/ system, except 255:3046/1 and 255:3046/2. 8.2.19 EXCEPT The EXCEPT command is used to specify an exception to the previously used ; i.e. to exclude one or more systems from the list. Consider the above example for the NO-SCRIPT command; using the EXCEPT command, it would be written as: SCRIPT POLLFTP.SCR 255:3046/* EXCEPT 255:3046/1 255:3046/2 This would instruct FD to use the script file POLLFTP.SCR when calling any 255:3046/system, except 255:3046/1 and 255:3046/2. It should, however, be noted that EXCEPT is not the equivalent of NO-SCRIPT. Consider the following: Mail routing Page 129 FrontDoor Administrator Guide SCRIPT POLLXTRA.SCR 255:3046/1 255:3046/2 SCRIPT POLLFTP.SCR 255:3046/* EXCEPT 255:3046/1 255:3046/2 This would instruct FD to use the script file POLLFTP.SCR when calling any 255:3046/ system, except 255:3046/1 and 255:3046/2 - for which FD would use POLLXTRA.SCR. Had a NO-SCRIPT been used in place of the EXCEPT command, the result would be that neither of the SCRIPT commands would apply to 255:3046/1 and 255:3046/2. * The EXCEPT command works with the from the previous command, including another EXCEPT command. With all route commands, it is possible to continue the onto as many lines in the route file as is required. It is also possible to repeat the command itself without affecting the meaning of the command, e.g. NO-ROUTE 255:3046/1 255:3046/2 255:3046/3 255:3046/4 NO-ROUTE 255:3046/5 255:3046/6 255:3046/7 255:3046/8 or NO-ROUTE 255:3046/1 255:3046/2 255:3046/3 255:3046/4 255:3046/5 255:3046/6 255:3046/7 255:3046/8 With the EXCEPT command, however, caution has to be taken so that it is not used to affect "itself". Consider the following: NO-ROUTE 255:* EXCEPT 255:3046/1 255:3046/2 255:3046/3 255:3046/4 255:3046/5 255:3046/6 255:3046/7 255:3046/8 This applies NO-ROUTE to all 255: systems, except those 255:3046/ systems listed with the EXCEPT command. Had the above been written like: Mail routing Page 130 FrontDoor Administrator Guide NO-ROUTE 255:* EXCEPT 255:3046/* EXCEPT 255:3046/1 255:3046/2 255:3046/3 255:3046/4 the NO-ROUTE command would be applied to all 255: systems, except those 255:3046/ systems listed with the first EXCEPT command; the NO-ROUTE command would be applied to 255:3046/1, 255:3046/2, 255:3046/3, and 255:3046/4. 8.3 ORDER OF EVALUATION The route file is processed from top to bottom; the last route command to affect a system overrides any previously used route commands, as applicable. This is particularly important to keep in mind when using the EXCEPT command (see above). 8.4 USING NODELIST FLAGS For route commands that require an parameter, nodelist flags (see "The Nodelist:Nodelist flags") can be used in place of, or combined with, addresses. The FORWARD-TO, FORWARD-FOR, FILES-TO, and FILES-FOR commands do not, however, support the use of nodelist flags. When using nodelist flags, they must be prefixed with a single percent (%) sign. For example: HOLD %CM would apply the HOLD route command to all applicable systems with the CM flag in their nodelist entry. It is also possible to specify a negative (not) condition using nodelist flags. This is done by placing an exclamation mark (!) in front of the nodelist flag. For example: HOLD %!CM would apply the HOLD route command to all applicable systems without the CM flag in their nodelist entry. Mail routing Page 131 FrontDoor Administrator Guide Some nodelist flags may appear immediately behind a capital U character. These flags are referred to as user flags and are not directly supported by FD; e.g. the REC user flag may appear as REC and as UREC. To cover both possibilities in a route file, %UREC %REC should be used. 8.5 ROUTE MACROS Only one macro is supported in the route file: $[MYPOINTS]. This macro expands to all local addresses with .* appended. Thus, if the local system was configured with the 255:3046/1 and 255:3046/2 addresses, DIRECT $[MYPOINTS] would expand to DIRECT 255:3046/1.* 255:3046/2.*. 8.6 DEFAULT ROUTING When no commands in the route file affect a system, implicitly or explicitly, FD uses a set of built-in rules, these rules are called default routing. For mail destined for systems outside the net of the local system, the default routing is the equivalent of the HOST-ROUTE command. For mail destined for systems inside the net of the local system, the default routing is the equivalent of the HUB-ROUTE command. * For systems with Down status, no default routing applies. 8.7 IMPLIED ROUTING AND QUALIFICATION The following implied rules apply to mail with certain status and to entries in the STQ: Entries in the STQ are never routed. Messages with file attachments can only be explicitly routed with the ROUTE-FILES command. Messages with File Request (FilReq), Update File Request (UpdReq), Hold, or Force Pickup (FPU) status are never routed. Mail routing Page 132 FrontDoor Administrator Guide Messages with Hold status are never delivered during an outbound call; the destination system must call the local system for such messages to be delivered. Messages with Received (Rcvd), Orphan, Lock, and/or Sent status are ignored by FD. Messages with Direct, Immediate (Imm), and/or Crash status cannot be explicitly routed with route commands (the Direct message status should not be confused with the DIRECT route command); they will automatically be routed "as directly as possible". Messages and STQ entries with Immediate (Imm) status are automatically qualified, whether or not the destination system has been qualified (see "QUALIFY" above). Messages and STQ entries with Immediate (Imm) and/or Crash status cannot be held with the HOLD route command. Immediate (Imm), Crash, Force Pickup (FPU), File Request (FilReq), Update File Request (UpdReq), Direct, and Hold status in a message is ignored if the message is non-local (without Local status). For more information about various message status flags, see "Message status". Mail routing Page 133 FrontDoor Administrator Guide 8.8 SAMPLE ROUTE FILE This is a very simple, yet functional, example of a route file: ; ;ROUTE.FD sample file ; HOLD * ;Hold all mail for pickup NO-ROUTE * ;Do not route any mail ; ;This is the schedule block for the default (@) event ; SCHEDULE @ * ;Qualify all systems (mail will be held) ;end of file "ROUTE.FD" Mail routing Page 134 FrontDoor Administrator Guide 9. EVENTS Events are used to control the operating schedule of FD. Events can be used to perform a number of tasks, but are usually divided into to primary categories: Mail events and External events (also called X-events). An external event forces FD to terminate with a specific errorlevel. A mail event determines which schedule block in the route file (see "Mail routing") FD should consider as the active schedule block. The events are stored in a file named EVENTNNN.FD, located in the SYSTEM directory, this file is called the event file. The default event file is named EVENT.FD which is used if FD cannot find the task-specific file (EVENTNNNN.FD). Events are configured in the Event manager in FDSETUP (Manager.Events). 9.1 EVENT MANAGER If the applicable EVENTNNN.FD file cannot be located in the SYSTEM directory, FDSETUP will ask if it should be created, or if the default event file (EVENT.FD) should be used. Once FDSETUP has created a new event file, or successfully opened an existing event file, the event manager screen is displayed. The title of the primary window contains the name of the event file that is currently being edited. Events are sorted in ascending (low to high) order, based on the time of day they are configured to start; FDSETUP performs the sort when it writes the event file. The event manager screen displays a list of the currently defined events. The list is divided into 11 columns: event number, event tag, day(s) on which the event should be invoked, modifier, start time, length (duration), errorlevel, minimum cost, maximum cost, retry delay, and the last-run date. Some of the information only applies to mail events (those with a tag of @, A-Z, excluding X), and some of the information only applies to external events (those with a tag of X). If an event has been set Inactive, a lowercase i is displayed between the event number and the event tag columns. Events Page 135 FrontDoor Administrator Guide 9.1.1 Navigating The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the first event displayed on screen; pressing the END key will move the selection bar to the last event displayed on screen. The PGUP and PGDN keys can be used to move the selection bar one page up and one page down, respectively. To display the first event in the event file, press CTRL+PGUP; to display the last event in the event file, press CTRL+PGDN. 9.1.2 Adding events New events can be added by pressing the INS (Insert) and F10 keys. If F10 is used, settings for the new event are copied from the event on which the selection bar is positioned. 9.1.3 Modifying events To modify the event on which the selection bar is positioned, press the ENTER key. If you just want to toggle the Inactive flag of an event, simply press F1 when the selection bar is positioned on the selected event. * The @ event cannot be set to Inactive. The SPACE key can be used to display the status settings of an event without first selecting to edit the event. 9.1.4 Deleting events To delete the event on which the selection bar is positioned, press the DEL (Delete) key. This will not physically remove the event from the event file; it will simply mark the event for deletion. When the event file is written (saved), entries marked for deletion will not be saved. Entries marked for deletion are indicated with an asterisk (*) between the event number and the event tag columns. If you change your mind, simply press the DEL key again to remove the deletion marker. Events Page 136 FrontDoor Administrator Guide 9.1.5 The Add/Edit event form This window is displayed if you choose to add a new event or edit an existing event. The window has twelve options. Depending on the type of event (mail event or external event), some options cannot be modified. The keys used to navigate between events (see above) are used to navigate between the various options. The ENTER key is used to modify an option. 9.1.5.1 Tag This is the event tag, a one-letter field which must contain @, A-Z. The X-tag is used to indicate an external event. For mail events, the event tag corresponds to the tag used in schedule blocks (see "Mail routing"). When FDSETUP creates a new event file, one event is automatically created with the tag field set to @, this is called the default event or @-event. Only one default event can exist per event file; it cannot be created manually. The starting time of the default event is called the eventbase. The eventbase can be used to modify the starting time of other events and is a very convenient way to switch between standard time and daylight saving time without having to manually reconfigure all or several events. 9.1.5.2 Days The days on which the event should be started. This cannot be modified for the default event. One or more days of the week - or all days of the week - can be specified. 9.1.5.3 Modifier The setting of this field determines how the eventbase (see "Tag" above) should be interpreted in regards to the starting time (see "Start time" below) of the event. Add eventbase (+) Adds the eventbase to the starting time of the event. This is the default. Events Page 137 FrontDoor Administrator Guide Ignore eventbase (*) Ignores the eventbase. Subtract eventbase (-) Subtracts the eventbase from the starting time of the event. 9.1.5.4 Start time The starting time of the event expressed in 24-hour notation (HH:MM). The start time of the default (@) event is called the eventbase. See "Tag" above for more information about the eventbase. 9.1.5.5 Length The length, or duration, of the event expressed in 24-hour notation (HH:MM). The default length for external events is one minute (00:01). Once an event has lapsed, it will end and FD will return to the underlying event (see "Overlapping events" below); the underlying event is usually the default event. 9.1.5.6 Errorlevel This field must contain a value in the range 31-255 for external events; it determines the errorlevel with which FD will terminate when the external event is started. For mail events, this field must contain zero (0) or a value in the range 31-255; it determines the errorlevel used when FD terminates after having received mail. If zero is specified, the default setting (Mailer.BBS/Errorlevels.Received mail) is used. * Note that this setting does not specify whether or not FD should exit when mail has been received. Events Page 138 FrontDoor Administrator Guide 9.1.5.7 Min.cost This setting is only applicable to mail events, and specifies the minimum cost-per-minute value for FD to allow a system to be qualified during the event. This does not affect systems for which messages with Immediate (Imm) exist. A value of zero (the default) specifies no minimum cost-per-minute. 9.1.5.8 Max.cost This setting is only applicable to mail events, and specifies the maximum cost-per-minute value for FD to allow a system to be qualified during the event. This does not affect systems for which messages with Immediate (Imm) exist. A value of -1 (the default) specifies no maximum cost-per-minute. 9.1.5.9 Behavior See below. 9.1.5.10 Retry delay This setting is only applicable to mail events and is used to override the default retry delay setting (Mailer.Miscellaneous.Retry delay). A value of zero (the default) specifies that the default retry delay setting should be used. 9.1.5.11 Busy retries This setting is only applicable to mail events and is used to override the default busy retries setting (Mailer.Miscellaneous.Busy retries). A value of zero (the default) specifies that the default busy retries setting should be used. Events Page 139 FrontDoor Administrator Guide 9.1.5.12 Completed today This setting is only applicable to external events and indicates if the event has been started (completed, since an external event is considered to have been completed once it has been started) today. Changing this field to No will clear the Last run information from the event; thus making it possible for the event to be started again on the current day as applicable. 9.2 MAIL EVENT BEHAVIOR This section describes the behavior settings for mail events. Mail event behavior settings affects how FD operates for the duration of the event. 9.2.1 Allow users during event This setting determines if FD should allow interactive access while the event is active. If this setting is No and a non-mail call is received, FD will terminate the call (disconnect). 9.2.2 Exit when mail is received This setting determines if FD should trigger an exit when mail is received during the event. A specific errorlevel can be configured for each event (see "Errorlevel", above). 9.2.3 High priority (Crash/IMM) mail only This setting specifies that FD should only process mail with high priority (Crash and Immediate) during the event. Messages without high priority status will be ignored. 9.2.4 Allow file requests This setting specifies if FD should allow remote systems to request files (see "File requests"). Events Page 140 FrontDoor Administrator Guide Note that the DENY route command can also affect how FD reacts to file requests. Please refer to "Mail routing" for more information about this. 9.2.5 Pickup file requests This setting specifies if FD should allow remote systems to request files when the remote system is the called system. This setting is typically set to No since the cost of the call is normally charged to the caller. 9.2.6 Don.t send file requests This setting specifies that FD should prevent (outbound) file requests from being sent during the event. If this setting is Yes, FD will not request any files from a remote system, whether or not FD placed the call. * This does not prevent file requests with Immediate (Imm) status from being sent. 9.2.7 Don.t send non-mail file attachments This setting specifies that FD should prevent non-mail file attachments from being sent during the event. This is typically useful in events where mail delivery is emphasized. * This does not prevent file attachments with Immediate (Imm) status from being sent. 9.2.8 Don.t send mail file attachments This setting specifies that FD should prevent mail file attachments from being sent during the event. This is typically useful in events where non-mail delivery is emphasized. * This does not prevent file attachments with Immediate (Imm) status from being sent. Events Page 141 FrontDoor Administrator Guide 9.2.9 Attempt to pickup waiting mail This setting specifies that FD should attempt to pickup any mail, during outbound calls, that the remote system may have for it. If this setting is No, FD will terminate the call (disconnect) as soon as it has delivered its mail to the remote system. * Note that the Don.t send file requests setting (above) is automatically set to Yes if pickup of waiting mail is disabled. 9.2.10 Allow nodes to pickup waiting mail This setting specifies that FD should allow calling systems to pickup waiting mail. When this setting is No, FD will terminate the call (disconnect) as soon as it has received its mail from the remote system. * Note that the Allow file requests setting (above) is automatically set to No if pickup of waiting mail by remote systems has been disabled. 9.2.11 Prioritize outbound calls This setting specifies that FD should ignore any retry delay settings for the event. This will result in outbound calls being placed very rapidly until all attempts have been exhausted or all mail has been successfully delivered. Note that this can result in the system not being available to handle inbound calls. 9.2.12 Delay before placing first call This setting specifies that FD should delay before placing the first outbound call. FD will normally attempt to place the outbound call as soon as possible. Events Page 142 FrontDoor Administrator Guide 9.2.13 Inbound only This setting specifies that FD should not place any outbound calls during the event. The setting is typically used for events where many remote systems pickup mail. It should be noted that this setting merely forces FD to hold applicable mail by default; the UNHOLD route command can be used to release mail. * This does not prevent messages with Immediate (Imm) status from being sent. 9.2.14 End event when no more mail to send This setting specifies that FD should end the event when no more systems remain to be called. If new mail becomes available after the event has ended (prematurely), the event will be restarted. The setting is typically used when an event places access restrictions on the local system; for interactive or mail access. The setting is also frequently used to configure overlapping events (see below). 9.2.15 Send to CM systems only This setting specifies that FD should only allow systems with the CM flag present in their nodelist entry to be qualified during the event. Messages with Immediate (Imm) status are not affected by this setting. 9.2.16 Send to non-CM systems only This setting specifies that FD should only allow systems without the CM flag present in their nodelist entry to be qualified during the event. Messages with Immediate (Imm) status are not affected by this setting. Events Page 143 FrontDoor Administrator Guide 9.2.17 Send to systems once only This setting specifies that FD should only call a given system once during the event. If this setting is No, FD may place several outbound calls to the same system to deliver mail received during the event. 9.2.18 Answer inbound calls This setting determines how FD should handle inbound RING messages received from the modem. If this setting is No, FD will ignore RING messages received from the modem. Note that for this setting to be effective, the modem must not be configured to automatically answer inbound calls. 9.2.19 Inactive If this setting is Yes, the event is ignored by FD. 9.3 EXTERNAL EVENT BEHAVIOR This section describes the behavior settings for external events. 9.3.1 Allow users during event This setting determines if FD should allow interactive access while the event is active. Practically, this only affects the calculation of the "time until next event (where interactive access is not allowed)" value, which can be communicated to external programs such as BBS packages. 9.3.2 Allow file requests This setting determines if FD should allow file requests while the event is active. Practically, this only affects the calculation of the "time until next event" (where file requests are not allowed) value. This value is used by FD to determine which files, resulting from a file request, can be transmitted; it can also be communicated to external programs such as External Request Processors (ERP). Events Page 144 FrontDoor Administrator Guide 9.3.3 Forced It is possible for FD to skip an external event if FD is started after the event has lapsed (i.e. it is later in the day than the starting time plus the length of thee event). This can occur if another external event or interactive call is taking more time than expected to complete, etc. If this setting is Yes, FD will start the event if it has been "missed". For forced external events, FD uses the completed today/last run information to determine if the event has already been started. Furthermore, the length setting for forced external events is ignored since it is not needed. 9.4 OVERLAPPING EVENTS Overlapping events is the term used to describe two or more events that start at the same time, or while another event (except the default event) is running. Overlapping events are typically used when specific systems have to be called using events that in some way restrict access to the local system. By using overlapping events, the system can be configured to apply such restrictions in the minimum amount of time. * If two (or more) events are set to start at the same time, the same day(s), with the same length, and without the End event when no more mail to send (see above) setting, the behavior of FD is undefined. Below is an example of overlapping events. The first event, with a tag of P, is used to poll a specific system and restrict access to the system to allow the poll to complete as quickly as possible. The second event, with a tag of M, is the event to which FD will fall back as soon as the first event has been completed. Events Page 145 FrontDoor Administrator Guide Event P 03:00-04:00 Allow users during event: No Allow file requests: No Prioritize outbound calls: Yes End event when no more mail to send: Yes Send to systems once only: Yes Event M 03:00-04:00 Allow users during event: Yes Allow file requests: Yes Prioritize outbound calls: No End event when no more mail to send: No Send to systems once only: No Note that the above example also needs the corresponding route file definitions to have any effect. Below is another example of overlapping events. This time, a three hour mail event is interrupted once an hour by an external event; this can be used to perform some sort of activity that generates new outbound mail. Events Page 146 FrontDoor Administrator Guide Event M 03:00-06:00 Event X 04:00-04:01 Allow users during event: No Allow file requests: Yes Forced: Yes Event X 05:00-05:01 Allow users during event: No Allow file requests: Yes Forced: Yes Event X 06:00-06:01 Allow users during event: No Allow file requests: Yes Forced: Yes Events Page 147 FrontDoor Administrator Guide 10. MODEM CONFIGURATION The term modem refers to the device through which FD communicates with the outside world; i.e. the communications device. This can be an asynchronous modem, a device driver emulating a modem (ISDN or LAN FOSSIL driver), an ISDN card, etc. FD performs all communications with the modem through an interface called the FOSSIL. Device drivers that emulate physical modems sometimes implement the FOSSIL specifications in the same driver to minimize overhead; FD requires a response (positive acknowledgement) to its FOSSIL presence check before it will operate. For more information about the FOSSIL interface and FOSSIL drivers, please refer to "FOSSIL drivers". Two sections of FDSETUP deal with most of the modem configuration for FD. One additional setting, used by the Terminal, is found in the Terminal.Miscellaneous section. It should be noted that this chapter makes frequent references to "FOSSIL" and "FOSSIL driver". This applies only to the DOS version of FrontDoor as other versions (such as the OS/2 version) uses standard system calls to access the communications resources. 10.1 BASIC REQUIREMENTS FD can communicate with a number of devices and emulated devices as indicated above. There are, however, some basic requirements that must be met by the device, or driver emulating the device, before FD will be able to use it for its communication with the outside world. Some modem manufacturers have managed to construct modems with reasonable (for FD) default settings, while other modems need additional configuration. 10.1.1 Carrier detect (CD) The modem must indicate the actual state of the carrier detect (CD) signal. Some modems are configured to always report that CD is present; this is not desirable when using the modem with FD since FD uses the carrier detect signal to determine if a call has been established and whether or not the call is active. Modem configuration Page 148 FrontDoor Administrator Guide 10.1.2 Data terminal ready (DTR) The data terminal ready, or DTR, signal is used by FD to control the modem in regards to the termination of a call. Although FD can be configured to use alternative methods to terminate a call, it will fall back to using the DTR signal as a last-resort mechanism when the modem no longer acknowledges commands or is otherwise not responding. It is of the utmost importance that the modem is configured properly in regards to how it reacts to the DTR signal being altered by FD. When FD lowers the DTR signal, the modem must terminate a call in progress. Some modems, including some models from well established manufacturers, have problems honoring the alteration of the DTR signal in specific situations; this is in particular a problem common to calls established for a fax transmission/reception and calls incorrectly established where the two modems have a different opinion of the speed at which the call was established. 10.1.3 Commands FD is ideally used with a modem compatible with the AT-command set. The basic requirement in this regard is that the modem is capable of returning an acknowledgement for a command sent to it by FD; e.g. if FD sends AT, the modem should respond with an acknowledgement in the form of an alphanumeric response, terminated by a (ASCII 13) character. 10.1.4 Connect messages It is furthermore desirable that the modem returns a speed figure in its connect indicator messages; i.e. CONNECT 9600, CONNECT 33600, CONNECT 64000, and so on. Many modems can be configured to return two types, or both combined, of connect messages. These two types are often referred to as the DTE speed and the DCE speed respectively. If at all possible, the modem should be configured to return the DCE speed as part of the connect messages; as this more accurately reflects the speed at which the modems communicate. Modem configuration Page 149 FrontDoor Administrator Guide 10.1.5 Flow-control Flow-control is used to control the flow of data between a physical modem and the machine to which it is attached. This is specifically needed to prevent the machine from sending data to the modem faster than the modem can process the data, and vice versa. Many modems are capable of two basic types of flow-control (as well as no flow-control): XON/XOFF, and CTS/RTS. These are often referred to as software and hardware flow-control respectively. Software flow-control typically uses specific characters (i.e. XON and XOFF) to implement flow-control. If flow-control is used, it must not in any way modify or react to specific data sent to the modem by FD; for a physical modem, this means that software flow-control cannot be used. 10.1.6 Basic device settings It is recommended that the communications device be configured to: o Not echo data sent to it by FD (this is usually accomplished with ATE0) o Return Caller ID information on a separate line (if applicable) o Returns result codes (this is usually accomplished with ATQ0) o Returns verbose rather than numeric result codes (this is usually accomplished with ATV1) 10.2 CONFIGURATION OPTIONS The Modem menu in FDSETUP is where most modem configuration options are accessed from. The Default settings option configures settings stored in SETUP.FD, the [ML] Task specific option allows the configuration of task-specific settings when more than one copy of FD operates from the same SETUP.FD file. Modem configuration Page 150 FrontDoor Administrator Guide [ML] The task-specific options are stored in MDCFGNNN.FD in the SYSTEM directory. If no task-specific file can be located, FD will use options stored in SETUP.FD. It should be noted that if a task- specific file exists for the current task, it can only be modified by using the Task specific option. 10.2.1 Hardware Settings related to the physical communication between FD and the attached modem. 10.2.1.1 Serial port Specifies the port to which the communications device is attached. 10.2.1.1.1 DOS version Although it is common that port numbers are logical in their numbering (1=COM1, 2=COM2, etc.), this setting actually specifies the port plus one. For example, if this setting is configured as one (1), FD attempts to communicate with the FOSSIL driver on port zero (0); if configured as four (4), FD attempts to communicate with the driver on port three (3). 10.2.1.1.2 OS/2 version For the OS/2 version of FrontDoor, this setting is used to construct the device name with which FD will communicate. The number entered here is appended to the word "COM" to make up a device name in the range "COM1" through "COM255". * It should be noted that FD does not make any attempts to prevent other programs or processes from accessing the device. Modem configuration Page 151 FrontDoor Administrator Guide 10.2.1.2 Locked port Specifies that the FOSSIL driver (DOS) or communications driver (non-DOS) has been configured to use a constant speed; the modem must also be configured to use a constant speed (DTE speed) for this to work. Use of constant speeds is practically a defacto standard when FD is used in conjunction with modems capable of communicating at speeds above 2400 BPS. 10.2.1.3 Maximum BPS rate Specifies the default, and maximum, speed (DTE speed) at which FD should communicate with the modem. The FOSSIL interface only allows for a limited number of speeds for the communication between the application (FD) and the modem; this is one of 300, 1200, 2400, 4800, 9600, 19200, or 38400 BPS. One could argue that this setting should allow for 57600 and 115200 BPS in versions other than the DOS version. It is, however, our experience that the communications driver has been locked at the required speed in such situations. * This setting cannot be modified if the Locked port setting is configured as Yes. 10.2.1.4 Reset modem to connect speed Specifies that FD should transmit the Escape code string, set the port speed, and finally transmit the Return on-line string to the modem; when an inbound call at ITU-T V.23 (split speed) is processed. Most modems do not require this procedure to properly handle V.23 connects. Modem configuration Page 152 FrontDoor Administrator Guide 10.2.1.5 Lower DTR when busy Specifies that FD should lower the DTR (data terminal ready) signal when it is not ready to accept an inbound call; this includes the processing of received mail, the launching of other programs, etc. If this setting is configured as Yes, FD will lower the DTR signal, which means that the modem will not answer inbound calls. This has the side-effect of calling systems not getting a BUSY response; instead, a NO ANSWER is most likely the result of a call to the local system when the DTR signal is lowered for a long period of time. If this setting is configured as No, FD will instead transmit the Off-hook string when it is not ready to accept an inbound call. This will typically result in calling systems getting a BUSY message when calling the local system. When FD is once again ready to accept an inbound call, it transmits the On-hook string to the modem. * In some countries, it is illegal to take a modem off-hook without any actual communication taking place or being initiated. 10.2.1.6 Lower DTR to terminate call Specifies that FD should lower the DTR (data terminal ready) signal when it terminates a call. The DTR signal is lowered for a short period of time, and once the CD (carrier detect) signal is no longer present, FD raises the DTR signal. This is the recommended, and the fastest, method of terminating calls. If this setting is configured as No, FD will instead transmit the Escape code string, followed by the On-hook string to terminate a call. 10.2.1.7 Toggle DTR before dialing Specifies that FD should lower the DTR (data terminal ready) signal, pause for a short period of time, and finally raise the DTR signal, before placing outbound calls. While this increases the possibility of an outgoing call colliding with an inbound call, it may be required by some modems to reset properly, etc. Modem configuration Page 153 FrontDoor Administrator Guide * It is highly recommended that this setting is configured as No, unless the modem requires that the DTR signal is altered as described above prior to making outbound calls. 10.2.1.8 Carrier detect mask (CDMASK) [ML] Specifies the bitmask to be used by the DOS version of FD when querying the FOSSIL driver for the state of the CD (carrier detect) signal. This setting should be configured as 128 unless the documentation for the FOSSIL driver states otherwise. * This setting is only available in the DOS version. 10.2.2 Connect messages Settings related to the messages returned by the modem to indicate that a connection has been established. For most environments, it is sufficient to configure the Prefix setting. It should be noted that connect messages are case sensitive; furthermore, only a partial match is required. For example, the string CONNECT matches CONNECT, CONNECTION, CONNECT 9600, CONNECT 64000, etc. 10.2.2.1 Custom.. Allows for up to five custom messages, and the corresponding connect (DCE) speed, to be configured. These are intended for situations where the connect speed cannot be determined by FD, using the Prefix setting. For example, some modems return CONNECT to indicate a connection at 300 BPS. Should that be case, a custom message can be configured as CONNECT| with a corresponding DCE speed setting of 300 BPS. The character following CONNECT is a pipe, or vertical bar, character. 10.2.2.2 Fax Specifies the message returned by the modem when an incoming fax transmission has been established. Modem configuration Page 154 FrontDoor Administrator Guide 10.2.2.3 Prefix Specifies the string appearing as the initial sequence of characters in all other messages indicating that a connection has been established. This should be configured as CONNECT for all but a few modems. 10.2.3 Status messages Settings related to the messages returned by the modem to indicate that a change of status has occurred. It should be noted that status messages are case sensitive; furthermore, only a partial match is required. For example, the string NO DIAL matches NO DIAL, NO DIALTONE, NO DIAL TONE, etc. In addition to the below strings, FD automatically recognizes the RRING, RINGING, CONNECTING, ALERTING, CALL SENT, DIALING, PROTOCOL:, COMPRESSION:, AUTOSTREAM:, and MODULATION: messages returned by some modems to report call progress; i.e. these messages do not need to be taken into consideration as they are automatically handled by FD. 10.2.3.1 Error Specifies the string returned by the modem when an error has been detected in a command string transmitted to it by FD. This should be configured as ERROR for all but a few modems. 10.2.3.2 Busy Specifies the string returned by the modem when an outbound call failed to establish a connection due to the line being busy. This should be configured as BUSY for all but a few modems. Modem configuration Page 155 FrontDoor Administrator Guide 10.2.3.3 No Carrier Specifies the string returned by the modem when an outbound call failed to establish a connection due to a timeout or inability to communicate with the remote modem. This should be configured as NO CARRIER for all but a few modems. 10.2.3.4 Ok Specifies the string returned by the modem to indicate positive acknowledgement of a command string transmitted to it by FD. This should be configured as OK for all but a few modems. 10.2.3.5 Ring Specifies the string returned by the modem to indicate an inbound call. This should be configured as RING for all but a few modems. 10.2.3.6 No Dialtone Specifies the string returned by the modem to indicate that a dial tone could not be detected when FD attempted to place an outbound call; this is typically an indication of an inbound call, or that the modem is not connected to the (telephone) network. This should be configured as NO DIAL for all but a few modems. 10.2.3.7 No Answer Specifies the string returned by the modem when an outbound call failed to establish a connection due to a timeout (no answer). This should be configured as NO ANSWER for all but a few modems. 10.2.3.8 Voice Specifies the string returned by the modem when an outbound or inbound call resulted in a voice call. This should be configured as VOICE for all but a few modems. Modem configuration Page 156 FrontDoor Administrator Guide For inbound calls, FD can be configured to terminate with a specific errorlevel (Mailer.BBS/Errorlevels) when this string is received from the modem. 10.2.4 Command strings Settings related to the commands that FD transmits to the modem at specific times. Certain characters appearing in command strings and answer control strings are interpreted by FD as having special meaning, they are as follows: | (Pipe, or vertical bar, character) v Lower DTR signal (Lowercase V) ^ Raise DTR signal (Caret) ~ Pause for one (1) second (Tilde) ` Pause for half (0.5) a second (Grave accent) 10.2.4.1 Escape code Specifies the escape sequence required by the modem to go from data mode to command mode. This string is used by FD if the Reset modem to connect speed setting is configured as Yes, and/or if the Lower DTR to terminate call setting is configured as No. This should be configured as ~+++~ for all but a few modems. 10.2.4.2 Return on-line Specifies the command sequence required by the modem to go from command mode to data mode when a connection has already been established. This string is used by FD if the Reset modem to connect speed setting is configured as Yes. This should be configured as ~ATO| for all but a few modems. 10.2.4.3 On-hook Specifies the command sequence required by the modem to place the modem on-hook (hang up). This string is used by FD if the Lower DTR when busy and/or the Lower DTR to terminate call settings are configured as No. This should be configured as ^ATM1H0|` for all but a few modems. Modem configuration Page 157 FrontDoor Administrator Guide 10.2.4.4 Off-hook Specifies the command sequence required by the modem to place the modem off-hook. This string is used by FD if the Lower DTR when busy setting is configured as No. This should be configured as ATM0H1|` for all but a few modems. 10.2.4.5 RingingAbort Specifies after how many RRING or RINGING messages FD should abort an outbound call attempt. 10.2.4.6 Dial Specifies the command to transmit to the modem when FD places an outbound call. The sequence of data transmitted by FD is as follows: This should be configured as AT for all but a few modems. 10.2.4.7 Prefix Transmitted after the Dial command (above) but before the number when FD places an outbound call. This should be configured as DT for all but a few modems; alternatively, if pulse dialing must be used, this setting should be configured as DP. 10.2.4.8 Suffix Transmitted after every number when FD places an outbound call. This should be configured as | (the pipe, or vertical bar, character) for all but a few modems. Modem configuration Page 158 FrontDoor Administrator Guide 10.2.4.9 Delay Specifies the delay - in 1/10 second increments - between strings transmitted to the modem by FD. Most modems require this setting to be in the range 4-8; modems capable of handling command data rapidly typically work with a setting of 1-3. For modems that require extreme delays between commands, this setting may need to be configured as high as 10-15. 10.2.4.10 Init.. Specifies up to three modem initialization strings. For modems with NVRAM (non-volatile random access memory) storage, it is recommended that principal modem configuration parameters are stored into NVRAM; and FD being configured to transmit ATZ| in Init-1, followed by minor configuration alterations in Init-2, and possibly Init-3. If FD is configured to handle the answering of inbound calls, it is recommended that the initialization of the modem disables auto- answer mode (typically, ATS0=0 accomplishes this). 10.2.4.11 TermInit Specifies an additional modem initialization string for the Terminal. This string is transmitted after the Init string configured in the Terminal.Miscellaneous section. 10.2.4.12 Down Specifies the commands that FD should transmit to the modem when it terminates with no call in progress. 10.2.4.13 Attention Specifies the shortest possible command sequence for FD to transmit to elicit an OK response (as configured in Status messages.Ok) from the modem. This should be configured as AT| for all but a few modems. Modem configuration Page 159 FrontDoor Administrator Guide 10.2.5 Answer control Settings related to answer control, which includes commands to transmit to the modem to answer an inbound call. Answer control, or manual answer, is the recommended method to handle inbound calls. This ensures that the modem cannot answer an inbound call until FD is ready to handle the call. For this to be effective, the auto-answer mode should be disabled (this is typically accomplished with the ATS0=0 sequence). Certain characters appearing in command strings and answer control strings are interpreted by FD as having special meaning, they are as follows: | (Pipe, or vertical bar, character) v Lower DTR signal (Lowercase V) ^ Raise DTR signal (Caret) ~ Pause for one (1) second (Tilde) ` Pause for half (0.5) a second (Grave accent) 10.2.5.1 Manual answer Specifies if, and how, FD should handle the answering of inbound calls. If this setting is configured as No (not recommended), the auto-answer mode must be enabled for the communications device. If this setting is configured as Yes (counter), FD will transmit the Force answer command.. string(s) when the specified (see below) number of RING messages (as configured in Status messages.Ring) have been received from the communications device. If this setting is configured as Yes (timer), FD will transmit the Force answer command.. string(s) when the specified (see below) time has elapsed since the RING message (as configured in Status messages.Ring) was received from the communications device. 10.2.5.2 Force answer command.. Specifies the commands required to instruct the modem to answer an inbound call. This should be configured as ATA| (Force answer command-1) for all but a few modems. Modem configuration Page 160 FrontDoor Administrator Guide 10.2.5.3 Answer delay/Answer after ring # Specifies the delay (in 1/10 second increments) or number of rings after which FD should transmit the Force answer command.. string(s). 10.2.5.4 Enable LDFRS Specifies that data following the ring signal received from the modem should be logged. This is typically used in environments where Caller ID information is returned by the communications device. This information can be passed on to an external application such as a BBS package (see "BBS interface" for more information). 10.2.5.5 "NO DIALTONE" is "BUSY" Specifies that NO DIALTONE (as configured in Status messages.No Dialtone) should be treated like BUSY (as configured in Status message.Busy) during outbound calls. If this setting is configured as Yes, FD will simply treat the NO DIALTONE message as if BUSY had been received from the modem. If this setting is configured as No, FD will assume that the NO DIALTONE message is an indication of an inbound call (i.e. call collision) and transmit the Force answer command.. string(s). The Manual answer setting must be configured as Yes for this to work. 10.2.5.6 Answer calls during init Specifies that FD should honor and process a RING message (as configured in Status messages.Ring) received from the modem while FD is attempting to initialize it. If this setting is configured as No, FD will simply ignore the RING message(s) while it is attempting to initialize the modem. 10.2.6 Fax Specifies whether or not the internal fax receiver should be activated when an inbound fax transmission is reported by the modem. FD can process inbound fax transmissions only from modems conforming to the ZyXEL fax mode. Modem configuration Page 161 FrontDoor Administrator Guide 10.3 MODEM MANAGER The Manager.Modem option in FDSETUP is used to configure dial control commands. These commands are used to setup the modem with a specific configuration based on the system, or the capabilities of the system, being called. Dial control configuration information is stored in MODEM.FD, located in the SYSTEM directory. Task-specific dial control configuration is stored in MODEMNNN.FD (where nnn is 1-255). If no task-specific dial control configuration can be located, MODEM.FD is used (if it exists). Dial control is in particular useful when FD is being used with multi-capability modems such as ISDN adapters with modem emulation and modems supporting a number of proprietary and non-proprietary communications protocols. Dial control can also be used to prevent FD from calling specific systems. The modem manager screen displays a list of the currently configured dial control strings. The list is divided into three columns: dial control number, string to match, and the string to send/action to take when a match is made. If an entry has been set Inactive, a lowercase i is displayed between the entry number and the string to match columns. 10.3.1 Navigating The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the first event displayed on screen; pressing the END key will move the selection bar to the last event displayed on screen. The PGUP and PGDN keys can be used to move the selection bar one page up and one page down, respectively. To display the first event in the event file, press CTRL+PGUP; to display the last event in the event file, press CTRL+PGDN. Modem configuration Page 162 FrontDoor Administrator Guide 10.3.2 Configuration The INS (Insert) key is used to add an entry to the modem manager list. The default location for a new entry is at the end of the list (i.e. appended). Since FD will process the entries from top to bottom, it is sometimes necessary to move an entry closer to the top of the list; this is accomplished with F2 (Move). 10.3.2.1 String to match The string with which FD attempts to make a match based on the data present in the nodelist database for the system being called. Certain characters allow an entry to match a range of data. If no special characters are used, FD attempts to match the string against the nodelist flags and the address of the system being called. Some examples follow: X75 Systems with the X75 nodelist flag X75 V34 Systems with the X75 and the V34 flags !X75 Systems without the X75 flag !X75 V34 Systems without the X75 flag, but with the V34 flag !X75 !V34 Systems without the X75 and V34 flags =9600 Systems with a (nodelist) speed of 9600 BPS !=9600 Systems without a (nodelist) speed of 9600 BPS >0 Systems with a (nodelist) speed of 0 BPS or higher =2400 ZYX CM Systems with 2400 BPS and the ZYX flag and the CM flag \!MO Systems with the !MO nodelist flag !\!MO Systems without the !MO nodelist flag 255:3046/1 The 255:3046/1 system !255:3046/1 Any system except 255:3046/1 * Note the use of the .\. character, which allows literal use of special characters. Modem configuration Page 163 FrontDoor Administrator Guide 10.3.2.2 String to send/Action Specifies the string that FD should transmit to the modem, or the action to take, when a match is made. If an action is to be specified, the field is simply left empty. Once the entry has been added, the F3 key is used to specify the action to take when a match is made. Action is one of (Do not dial) or (Stop scanning and proceed with call). The second action-type is typically used to force FD to stop scanning the remaining entries once a match has been made. For example: V34 ATB0| V34 (Stop scanning and proceed with call) would transmit ATB0 to the modem and then stop scanning for further matches. Modem configuration Page 164 FrontDoor Administrator Guide 11. FOLDERS Folders are primarily used to store and categorize messages; they can also be used for message archiving purposes. Folders are sometimes referred to as areas. Only one folder must be defined for the FrontDoor programs to work, this is the System NetMail folder. FM is the only FrontDoor program that uses the folder configuration; stored in the file FOLDER.FD, which is located in the SYSTEM directory. 11.1 FOLDER TYPES Three types of folders exist: Conference Mail folders, Local folders, and [ML] NetMail folders. 11.1.1 Conference Mail A Conference folder contains conference mail (conference messages); it is said to "hold a conference". A conference is a distributed forum where one or more topics are discussed. A Conference is a very powerful and flexible way of maintaining communication and exchange of information between groups of people. Conference mail is sometimes referred to as EchoMail. An external application, referred to as a Conference Mail Processor is used in conjunction with FD to distribute conferences. Messages in a Conference folder have two addressing fields in the header: Sender name, and recipient name. Messages in a Conference folder cannot have files attached to them. Messages in a Conference folder cannot have multiple recipients (i.e. carbon copies). They can, however, be addressed to All or *, which is often used in conferences to indicate that the message is intended for anyone with access to the conference. Messages in a Conference folder normally have an ending identification line, called Origin Line. An example of an origin line follows: Folders Page 165 FrontDoor Administrator Guide --- * Origin: Definite Solutions (255:3046/1) The line with the three dashes is called a Tear Line, and is an indication that the end of the message has been reached. The tear line is optional and need not appear in conference messages. The text in the origin line can contain any (or no) text, but it must be followed by the address of the system where the message originated. Some examples of text in an origin line: Definite Solutions - Stockholm, Sweden XYZ Corporation - Green Valley, CA, USA XYZ Corporation - John Doe in the field 11.1.2 Local A Local folder is typically used to access a folder defined in a BBS (Bulletin Board System) as a local-only folder or area. They are useful for administrators who do not want to login to the BBS to read and write messages. They can also be used for conferences in a LAN where all participants of the conference are located on the same LAN. Messages in a Local folder have two addressing fields in the header: Sender name, and recipient name. Messages in a Local folder can have files (such as documents and images) attached to them. Messages in a Local folder cannot have multiple recipients (i.e. carbon copies). 11.1.3 NetMail A NetMail folder typically contains messages that are direct person- to-person correspondence. Folders Page 166 FrontDoor Administrator Guide Messages in a NetMail folder have four addressing fields in the header: Sender name, sender address, recipient name, and recipient address. Messages in a NetMail folder can have files (such as documents and images) attached to them. Messages in a NetMail folder can have multiple recipients (i.e. carbon copies). The System NetMail folder is a NetMail-type folder. 11.2 CONFIGURATION The folder manager is accessed from the Editor.Other folders option in FDSETUP. The folder manager screen displays a list of the currently configured folders. The list is divided into five columns: folder number, folder status, users allowed to access the folder, password protection indicator, and the title or physical location of the messages in the folder. 11.2.1 Navigating The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the first folder displayed on screen; pressing the END key will move the selection bar to the last folder displayed on screen. The PGUP and PGDN keys can be used to move the selection bar one page up and one page down, respectively. To display the first folder in the folder file, press CTRL+PGUP; to display the last folder in the folder file, press CTRL+PGDN. 11.2.2 Adding folders New folders can be added by pressing the INS (Insert) and F10 keys. If F10 is used, settings for the new folder are copied from the folder on which the selection bar is positioned. Folders Page 167 FrontDoor Administrator Guide 11.2.3 Modifying folders To modify the folder on which the selection bar is positioned, press the ENTER key. The SPACE key can be used to display the status settings of a folder without first selecting to edit the folder. 11.2.4 Deleting folders To delete the folder on which the selection bar is positioned, press the DEL (Delete) key. This will not physically remove the folder from the folder file; it will simply mark the folder for deletion. When the folder file is written (saved), entries marked for deletion will not be saved. Entries marked for deletion are indicated with an asterisk (*) between the folder number and the folder status columns. If you change your mind, simply press the DEL key again to remove the deletion marker. * Deleting a folder does not remove any messages stored in the folder. 11.2.5 The Add/Edit folder form This window is displayed if you choose to add a new folder or edit an existing folder. The window has seven options. Depending on the type of folder (see above), some options are not applicable. The keys used to navigate between folder (see above) are used to navigate between the various options. The ENTER key is used to modify an option. 11.2.5.1 Status The status and type of the folder. See below for a description of the available options. Folders Page 168 FrontDoor Administrator Guide 11.2.5.2 Origin Specifies the default origin line (see above) that should be used for messages created locally. This is only applicable to Conference Mail-type folders. FDSETUP allows the configuration of up to 20 origin lines (Editor.Origin lines). 11.2.5.3 Title Specifies the title of the folder; this is displayed when the user chooses to access a new folder in FM. Applicable $[] macros can also be used to specify the title. 11.2.5.4 Path/Board Specifies the physical location of messages in the folder. For the JAM storage type, this specifies the full pathname to the JAM message base, extension excluded; e.g. C:\FD\MSG\JAM\ISDN. Applicable $[] macros can also be used to specify the path. For the .MSG storage type, this specifies the directory where messages are stored for the folder; e.g. C:\FD\MSG\MSG\ISDN\. Applicable $[] macros can also be used to specify the path. For the HMB storage type, this specifies the board number in which messages are stored for the folder; this is a value in the range 1- 200. For more information about the various storage types, please refer to "Mail storage". 11.2.5.5 Users Specifies which of the users, configured in Global.Users, should have access to the folder. For users with User access, a folder will only appear in the folder list (displayed in FM) if they have access to the folder. * Users with Supervisor or Administrator access are not affected by this setting. Folders Page 169 FrontDoor Administrator Guide 11.2.5.6 Password Specifies the password required to access the folder. This forces FM to prompt users with Administrator or User access to enter the specified password before allowing access to the folder. * Users with Supervisor access are not affected by this setting. 11.2.5.7 Use AKA Specifies the default system address that should be used as the originating (sender) address for messages created locally. This is only applicable to Conference Mail-type and NetMail-type folders. For Conference Mail-type folders, this specifies the address that will appear in the origin line (see above). 11.2.6 Folder status The folder status settings determine the type of a folder, how messages are physically stored, various access restrictions and folder defaults. Some settings are cannot be combined, as noted below. 11.2.6.1 Restricted This setting affects users with Administrator or User access. If configured as Yes, FM will only allow access to messages with Private (Pvt) status if the messages are addressed to or from the user. Public messages (messages without Private status) can be read by anyone with access to the folder. If a folder is configured with Restricted status, FM requires that the user has Supervisor access before allowing access to the Survey function. 11.2.6.2 ConfInfo This setting is only applicable for Conference folders and specifies that FM should add an origin line to new messages. Folders Page 170 FrontDoor Administrator Guide 11.2.6.3 Lock ConfInfo Specifies that a user with Administrator or User access should not be able to select the origin line to be used when new messages are created in the folder. 11.2.6.4 Export Ok Specifies that messages may be exported (to a text file, for example) and printed from the folder. * Users with Supervisor access are not affected by this setting. 11.2.6.5 Hudson MsgBase Specifies that the folder uses the Hudson Message Base (HMB) format for physical message storage. This is not supported for NetMail folders. If neither of the JAM MsgBase and Hudson MsgBase settings have been specified, FM assumes that the folder uses the .MSG Message Base format for physical message storage. For more information about the various storage types, please refer to "Mail storage". 11.2.6.6 Translate Specifies that the editor translation tables (Editor.Xlat.In and Editor.Xlat.Out) should by default be enabled for the folder. 11.2.6.7 Private Specifies that FM should by default set the Private (Pvt) status for new messages. This is typically used with Local folders. Folders Page 171 FrontDoor Administrator Guide 11.2.6.8 Read-only Specifies that the folder is read-only; i.e. new messages cannot be created in the folder, nor can existing messages be deleted by means of the Delete message function. * Users with Supervisor access are not affected by this setting. 11.2.6.9 NetMail reply Specifies that replies, using the Reply to Message function, made to messages in the folder should be written as private, or NetMail, replies instead of to the folder in which the original message resides. 11.2.6.10 No check Specifies that FM should skip (not process) the folder when the Folder scan function is used. This is in particular useful for folders that store messages on removable media such as floppy disks. 11.2.6.11 "New" if any Specifies that FM should indicate, after the Folder scan function has completed, that the folder contains new messages if the folder contains any messages. If this setting is configured as No, FM will only indicate that there are new (unread) messages in the folder if it contains messages with a higher number than the lastread (see below) message number. 11.2.6.12 Force CR Specifies that FM should insert a hard line break, i.e. a (ASCII 13), when it performs word wrapping. This is typically used in folders with the Newsgroup status (see below). If this setting is configured as No, FM will not insert a hard line break when it performs word wrapping; which results in paragraphs that can be automatically "reflowed" when the message text is displayed. Folders Page 172 FrontDoor Administrator Guide 11.2.6.13 Conference Specifies that the folder is a Conference folder (see above). 11.2.6.14 Newsgroup Specifies that the folder is a Newsgroup folder. This is only applicable for Conference folders. Messages in Newsgroup folders do not have a specific recipient. This type of folders is typically used in conjunction with an external application that works as a gateway between FrontDoor and the Internet. 11.2.6.15 NetMail [ML] Specifies that the folder is a NetMail folder (see above). 11.2.6.16 Local Specifies that the folder is a Local folder (see above). 11.2.6.17 Separator Specifies that the entry is to be used as a folder separator (see below). 11.3 FOLDER SEPARATORS Folder separators are used to insert separators at specific places in the folder list. When the folder list is sorted, by using the F1 key in the folder manager, FDSETUP will only sort entries between separators. If no separators exist, the entire folder list is sorted in ascending alphabetical order. Although folder separators are configured in the folder manager, they are not folders per se; they cannot be selected as the active folder in FM. Folders Page 173 FrontDoor Administrator Guide A folder entry with Separator status cannot have any other status. The only data used from a folder with Separator status are the Title and Users settings. The Users setting determines to which users the separator should be displayed. The Title contains the actual text displayed to the user when FM displays the list of folders. If the Title is left empty, FM will simply insert a thin line as the separator, stretching horizontally across the entire folder list. If only one character is specified in the Title, FM will use that character instead of a thin line. If the contents of the Title is longer than one character, FM will simply display it as the separator. Two additional characters, however, exist. If the first character is a > (greater than) or < (less than) character, and followed by one or more characters, FM will display the text following the first character, left and right padded respectively, with a thin line, horizontally stretched across the folder list. 11.4 LASTREAD The Lastread message number is the term used to refer to the message that was last accessed by the user in a given folder. For folders configured with JAM MsgBase or Hudson MsgBase status, one lastread message number per user is maintained. For other folders (.MSG message base), only one lastread message number is maintained - this is a limitation enforced by the .MSG message base format, and not a limitation in FM. When the user later returns to a folder, FM will attempt to display the message that was displayed, or "read", the last time the user accessed the folder. For more information about the various storage types, please refer to "Mail storage". Folders Page 174 FrontDoor Administrator Guide 12. MAIL SECURITY This section describes various issues related to mail security and overall system integrity in the FrontDoor environment; in particular as far as interaction with remote systems is concerned. Mail security in the FrontDoor environment primarily involves FD, as it is the application mainly responsible for handling the interaction with remote systems. Seven aspects of mail security will be described: o Secure vs. unsecure mail sessions o Automated distribution (conferences, etc) o The nodelist o File and service requests o Automatic forwarding of mail (messages and files) o Automatic time synchronization o FDSERVER The security manager, used to configure session passwords and various other session-related sessions, is described towards the end of this section. 12.1 SECURE VS. UNSECURE MAIL SESSIONS A secure session is the term used to describe a mail session between two systems that have exchanged some sort of private validation ID, such as a password; i.e. a session password. An unsecure session is, similarly, a mail session between two systems that have not exchanged this validation ID. Mail security Page 175 FrontDoor Administrator Guide A password (validation ID) is typically associated with a specific (system) address. Although it is possible to use the same password for several systems, this is not the recommended approach. In the case of systems with multiple addresses, it is common, and recommended, that the password is associated with all of the addresses presented by the system. Although it is not required that all addresses presented by a remote system be protected with a password, those addresses that are protected must be protected with the same password. It is recommended that files received during secure sessions be separated from files received during unsecure sessions (Global.Filenames.Files and Global.Filenames.SecFiles). This allows special care to be taken before automatically processing data received during unsecure sessions. The above described method of separation also allows for special handling of the directory used during unsecure sessions. In a LAN environment, this directory could for example be limited in the amount of space it is allowed to occupy, thus preventing unknown systems from sending files that could otherwise completely fill up the available storage space. [ML] FD can also be configured to require that all sessions be secure (Mailer.Miscellaneous.Mail from "unprotected" systems). This, in effect, forces FD to disconnect any call that do not result in a secure session before any files and/or messages are exchanged. It should be noted that in all cases except one, session passwords are transmitted "clear text" (i.e. without an attempt to garble or encrypt the password). The only type of session negotiation method that does not exchange passwords "clear text" is the EMSI/MD5 type. 12.2 AUTOMATED DISTRIBUTION The automated distribution of conferences is also affected by the various aspects of mail security. Although the most common use for automated distribution is conferences containing messages, other distribution concepts also exist; such as conferences where files are distributed, etc. Mail security Page 176 FrontDoor Administrator Guide For all types of distribution, it is recommended that systems with which such distribution takes place, are configured with a password. This allows FD to place the relevant files in the directory used for secure sessions and the applications used to handle the processing of distributed data to only process that directory automatically. 12.3 THE NODELIST Mail security applies to the nodelist in two specific aspects. When FD places an outbound call to a system, in order to establish a mail session, it assumes that the nodelist integrity is well maintained and that the telephone number specified for a given system will result in that system being called. FD makes no attempt to validate that the remote system actually presents the address used when placing the outbound call. FD does, however, require that no password errors (mismatch) occurs. It should also be noted that the Mailer.Miscellaneous.Mail from.. settings only affect inbound mail sessions. For inbound sessions, the contents of the nodelist database alone categorize the calling system as listed (known) or unlisted (unknown). Configuring an address with a password in the security manager does not affect the listed/unlisted status of a system. 12.4 FILE AND SERVICE REQUESTS Although inbound file and service requests do not normally present a potential security problem, it is very important that the concepts involved with these two functions are fully understood. File requests handled by FD can be restricted and protected in a number of ways (see "File requests"). The possibility to configure FD to only allow/accept inbound requests during secure sessions, and the ability to protect specific files and directories with an additional password, are two powerful ways to ensure system integrity. Furthermore, files can only be requested from those directories specified in Mailer.File requests.List and Mailer.File requests.SecList (secure sessions) when FD handles inbound file requests. Mail security Page 177 FrontDoor Administrator Guide When an external request processor is used to handle inbound requests, FD does not, however, have any control over the security aspects of file requests. Similarly, when a request is made for a service to be invoked (see "Service requests"), FD does not have any control over the resulting data (if any) transmitted to the remote system. Nor does FD have any control over the actions taken by an external program invoked as a request processor or an external service. 12.5 AUTOMATIC FORWARDING OF MAIL When mail destined for a remote system is received from another system, the mail is called transit (non-local) mail. FD will by default not forward transit mail. The route commands FORWARD-FOR, FORWARD-TO, FILES-FOR, and FILES-TO control to and from which systems FD should forward mail automatically. There is no method by which the contents of mail can be used to determine if it should be forwarded or not; the only distinction that can be made is whether or not a message has one or more file attachments or no file attachments. For more information about the above route commands, please see "Mail routing". 12.6 AUTOMATIC TIME SYNCHRONIZATION FD can be configured to automatically synchronize the local system time with that of another system. This is done after a mail session has completed, provided certain criteria is met (maximum time difference, etc). It is recommended that a remote system not be configured as a time source unless the system is considered to be reliable in all aspects as well as configured with a password in the security manager. Though no or little physical harm to the system could come from the use of an unreliable time source, the operational integrity and reliability of the system could be affected. Mail security Page 178 FrontDoor Administrator Guide 12.7 FDSERVER The FDSERVER interface (see "FDSERVER" section) allows external programs to be invoked to perform certain tasks not directly handled by FD. It should be noted that FD has no control over the programs it invokes through an FDSERVER request. It is possible that such a program will cause the system on which FD is operating to lock-up, or otherwise malfunction. Access to the FDSERVER interface should therefore be strictly limited. * The FDSERVER interface is by default disabled. 12.8 SECURITY MANAGER The Manager.Security option in FDSETUP is used to configure session passwords and other aspects of mail security. Session passwords and other related settings are stored in PASSWORD.FD, located in the SYSTEM directory. This file is used by all tasks (i.e. there are no task-specific files). The security manager screen displays a list of the currently configured passwords and other related settings. The list is divided into a number of columns: session security entry number, system address, and password, followed by several session-related settings. If an entry has been set Inactive, a lowercase i is displayed between the entry number and the system address columns. 12.8.1 Navigating The selection bar is moved with the UP and DOWN keys. Pressing the HOME key will move the selection bar to the first entry displayed on screen; pressing the END key will move the selection bar to the last entry displayed on screen. The PGUP and PGDN keys can be used to move the selection bar one page up and one page down, respectively. To display the first entry in the file, press CTRL+PGUP; to display the last entry in the file, press CTRL+PGDN. Mail security Page 179 FrontDoor Administrator Guide 12.8.2 Adding entries New entries can be added by pressing the INS (Insert) and F10 keys. If F10 is used, settings for the new entry are copied from the entry on which the selection bar is positioned. 12.8.3 Modifying entries To modify the entry on which the selection bar is positioned, press the ENTER key. If you just want to toggle the Inactive flag of an entry, simply press F1 when the selection bar is positioned on the selected entry. 12.8.4 Deleting entries To delete the entry on which the selection bar is positioned, press the DEL (Delete) key. This will not physically remove the entry from the file; it will simply mark the entry for deletion. When the file is written (saved), entries marked for deletion will not be saved. Entries marked for deletion are indicated with an asterisk (*) between the entry number and the system address columns. If you change your mind, simply press the DEL key again to remove the deletion marker. 12.8.5 The security manager fields The various fields (columns) and their meaning will now be described. 12.8.5.1 System Specifies the address of the system for which the following settings apply. Mail security Page 180 FrontDoor Administrator Guide 12.8.5.2 Password Specifies the password required to be presented by the remote system before FD will accept the above (system) address. This password is also presented by FD when it calls the system. It should be noted that FD treats passwords received from remote systems case insensitively. FD will, however, transmit the specified password "as is", without case conversion. It is recommended, but not required, that passwords are limited to printable, seven bit ASCII characters. 12.8.5.3 Mail Specifies that FD should accept inbound sessions from the system listed in the above (system) address field. This does not affect outbound sessions. If this setting is configured as No for a given system, FD will immediately terminate an inbound call (hang up) if the specified address is presented by the calling system. * Configuring this setting to No can be used to prevent sessions, on a permanent basis, with a remote system that presents a specific address (by accident or deliberately). This is in particular useful when certain addresses are used internally on the system for specific purposes. Optionally, the DENY route command (above) can be used with a similar effect. 12.8.5.4 FREQ Specifies that FD should honor/allow inbound file requests from the system listed in the above (system) address. If this setting is configured as No for a given system, FD will under no circumstances allow the remote system to request files. 12.8.5.5 ZZap Specifies that FD should allow the ZedZap (a Zmodem variant) file- transfer protocol to be used during sessions negotiated using the FTS-6 (YooHoo) session protocol. If this setting is configured as No for a given system, FD will only allow DietIFNA file-transfers. Mail security Page 181 FrontDoor Administrator Guide * This setting only affects sessions negotiated using the FTS-6 session protocol. 12.8.5.6 EMSI Specifies that FD should attempt to negotiate an EMSI session with the given system. Some software may have problems to handle inbound sessions from systems wanting to use the EMSI session protocol, in which case this can be disabled on a system-by-system basis. This setting only affects outbound sessions. 12.8.5.7 FTS6 Specifies that FD should attempt to negotiate an FTS-6 session with the given system. FD will first attempt to negotiate an EMSI session before it attempts to negotiate an FTS-6 session, if it is allowed to. This setting only affects outbound sessions. 12.8.5.8 FTS1 Specifies that FD should attempt to negotiate an FTS-1 session with the given system. FD will attempt to negotiate an EMSI session, an FTS-6 session, and finally an FTS-1 session, in that order; as applicable. This setting only affects outbound sessions. 12.8.5.9 TSRC Specifies that the remote system should be used as a time synchronization source, or time source. This allows FD to automatically synchronize the system time to that of the remote. FD will not synchronize the time with a remote system if more than 30 minutes differ between the local time and the time presented by the remote system (i.e. the remote time). Mail security Page 182 FrontDoor Administrator Guide One additional setting, Mailer.Miscellaneous.Allow time synchronization w/o UTC, can also be used to enhance the security of automated time synchronization. 12.8.6 Entry synchronization The Synchronize (TAB) function in the security manager will configure all entries with the same password with the same settings (Mail, FREQ, ZZap, EMSI, FTS6, FTS1, and TSRC). Mail security Page 183 FrontDoor Administrator Guide 13. SEMAPHORE FILES A semaphore is a file that by its presence, or absence, signals an action to be taken by a given program. Semaphores are also used by programs to signal a specific state. Semaphore files are typically of zero-length (zero bytes); zero-length files do not normally occupy any physical disk space, even though they occupy a directory entry in most operating systems. Some semaphores are specific to FD, others to FM; all semaphores are, however, checked for and created in the semaphore directory unless otherwise noted. The semaphore directory is configured in FDSETUP (Global.Filenames.Semaphore) for [ML]. If the semaphore directory has not been specified, and for [SL], the SYSTEM directory is used. To create a zero byte semaphore file from the OS prompt, use: REM> A list of semaphores used and supported by FrontDoor are listed below; nnn text is the task number (0-255 without any padding). For [SL], nnn is always zero (0). File FDALIVE.nnn Versions All Description Indicates that FD is operating and active. This file is touched at least once every 30 seconds by FD, even when it is frozen. The file is removed when FD terminates or a user invokes an external program (including FM and OS shells) from within FD. It is not removed when the Terminal is in use. File FDINTERM.nnn Versions All Description Indicates that FD is currently in Terminal (Emulator) mode. This file is removed once the user leaves the Terminal. Semaphore files Page 184 FrontDoor Administrator Guide File FMALIVE.nnn Versions All Description Indicates that FM is operating and active. This file is touched at least once every 30 seconds by FM, even when it is frozen. The file is removed when FM terminates or a user invokes an external program (including OS shells) from within FM. File FDINSESS.nnn Versions All Description Indicates that FD is currently in a mail session. File FDFREEZE.nnn Versions All Description Forces a specific task to freeze. FD scans for this file periodically and if detected, it closes all open files, except its overlay file, and lowers DTR. The FOSSIL driver is also deinitialized. FD will not honor this file while a mail session is in progress. It will, however, act upon it as soon as it has completed the mail session. This semaphore is not checked for when the Terminal is active. File FDFREEZE.ALL Versions All Description This semaphore has the same function as above, with the exception that it forces all active mailers to freeze instead of a specific mailer. File FDFROZEN.nnn Versions All Description Indicates that a specific mailer is in a frozen state. File FMFREEZE.nnn Versions All Description Same as FDFREEZE.nnn, but affects FM instead of FD. Semaphore files Page 185 FrontDoor Administrator Guide File FMFREEZE.ALL Versions All Description Same as FDFREEZE.ALL, but affects FM instead of FD. File FMFROZEN.nnn Versions All Description Same as FDFROZEN.nnn, but for FM. File FDCANSES.nnn Versions All Description Forces FD to terminate the call/session in progress. If FD is currently sending or receiving a file, the call will not be terminated until the file has been transmitted/received. Once the call has been terminated, this file is removed by FD. File FDRENUM.nnn Versions All Description Indicates that the System NetMail Folder is being renumbered (or otherwise updated) by an application. No applications may modify messages in the System NetMail Folder if this semaphore is present. FM creates this file (FDRENUM.nnn) when it is renumbering the System NetMail Folder. How FD reacts to this semaphore depends on what it is currently doing. If FD is processing the System NetMail Folder, it will act as if the FDFREEZE.nnn semaphore was present. Otherwise, it will prevent any mail sessions from taking place (i.e. ignore inbound calls and not place any outbound calls) as well as any rescans; until the file has been removed. Semaphore files Page 186 FrontDoor Administrator Guide File FDSCAN.nnn Versions All Description Indicates that FD is currently processing the System NetMail Folder. No applications may modify messages in the System NetMail Folder if this semaphore is present unless it is guaranteed that they will not be included by FD in a packet, i.e. Sent, Received, or Locked messages. File FDINEXIT.nnn Versions All Description Indicates that FD has dropped to an external program such as a BBS while a call is in progress. This file is used by FD when it "recycles" and compared with the timestamp of rescan semaphores, etc. to determine if any changes have been made to the System NetMail Folder while the external program was executing. File FDNOEXIT.NOW Versions All Description Prevents FD from triggering an exit when mail has been received. File FDNOUSER.NOW Versions All Description Prevents interactive (non-mail) callers from being passed on to a BBS or similar program, even if FD has been configured to allow interactive access. File FDNOSCAN.NOW Versions All Description Prevents FD from rescanning the System NetMail Folder. File FDRESCAN.NOW Versions All Description Forces FD and FM to rescan the System NetMail Folder (unless FDNOSCAN.NOW is present). See below for additional notes regarding this semaphore. Semaphore files Page 187 FrontDoor Administrator Guide File ROUTEnnn.FD Versions All Description While not a semaphore file per se, FD will monitor the timestamp of the route file and if a change is detected, it has the same effect as if FDRESCAN.NOW would have been updated (see above). Additionally, if a change of the file's timestamp is detected, FD will tokenize it into ROUTEnnn.FD@ (see "Mail routing"). File FDXITnnn.eee Versions All Description Forces FD (with task number NNN) to terminate with an errorlevel indicated by EEE (0-255). If a mail session is in progress, FD will complete it prior to exiting. The semaphore is removed as soon as FD has acted upon it. File FDXITANY.eee Versions All Description Similar to the FDXITnnn.eee semaphore with the exception that no task number is specified. The first mailer to detect this semaphore will act upon it and remove the semaphore once it has done so. File FDINMAIL.NEW Versions All Description Similar to the FDXITANY.eee semaphore with the exception that it does not specify a task number nor errorlevel. The first mailer to detect this semaphore will act as if it has received mail in an inbound session. The semaphore is removed as soon as FD has acted upon it. File FDNOCALL.nnn Versions All Description Prevents FD from placing outbound calls. Semaphore files Page 188 FrontDoor Administrator Guide File FMRESCAN.NOW Versions None Description This is no longer supported (see "FDRESCAN.NOW", below). File FMNEWNET.nnn Versions All Description Indicates that FM has created one or more messages in the System NetMail Folder. File FMNEWLOC.nnn Versions All Description Indicates that FM has created one or more messages in a Folder with Local status. File FMNEWCNF.nnn Versions All Description Indicates that FM has created one or more messages in a Folder with Conference status. File FDQPACK.nnn Versions All Description Indicates that FD is currently packing the static queue (STQ). File FDTIMSNC.nnn Versions All Description Created by FD when it has synchronized the time with a remote system. File FDNCALIV.NOW Versions All Description Indicates that FDNC is currently running. This semaphore is never updated by FDNC while the program is running. If this semaphore exists when FDNC is starting, the program will terminate with an error message. Semaphore files Page 189 FrontDoor Administrator Guide 13.1 FDRESCAN.NOW This semaphore has several purposes and the result of its presence differs depending on its location. If FD detects a change to this semaphore in the semaphore directory, it will rescan the System NetMail Folder, as well as the STQ, and process outbound mail. This semaphore is also used to signal a change in .MSG-type folders. FD will create/update this semaphore in the directory of the System NetMail Folder when new mail has been unpacked after a mail session. If FM detects a change to this semaphore in the folder (.MSG-style) that is currently active, it will rebuild its list of messages. FM does not monitor this file in the semaphore directory. Semaphore files Page 190 FrontDoor Administrator Guide 14. FILE REQUESTS A file request, in the simplest of terms, is a method by which data (typically one or more files) can be fetched from a given system. Inbound file requests is the term used when a remote system sends the local system a request for one or more files; outbound file requests is the term used when the local system sends a remote system a request for one or more files. The file request concept can be extended to running external programs to perform a specific service, this is called service requests (see "Service requests"). Before FD will honor (accept) inbound file requests, it must be configured with a number of options; including which directories should be accessible, during what times inbound requests should be honored, etc. Most of these configuration options are found in FDSETUP (Mailer.File requests). Since service requests are handled through the file request interface, they are also affected by the file request configuration settings. 14.1 CONFIGURATION The File requests option presents four choices, they will now be described, along with the options they, in turn, present. 14.1.1 Filenames These options specify five external files used by FD when processing inbound file requests. The files are plain ASCII (text) files with all lines terminated by a (ASCII 13, ASCII 10) pair. With the exception of the file specified for the Message option, empty lines are ignored, and any text behind a semi-colon (;) is treated like a comment (ignored). 14.1.1.1 List The file specified here contains a list of directories that should be scanned for the requested files. One directory (complete path) per line is expected by FD; this is not a filemask. File requests Page 191 FrontDoor Administrator Guide All files in the specified directories will be available for request by remote systems. No other directories than those specified in this file (and possibly those listed in the file specified for the SecList option, below) will be searched. This file is used for secure and unsecure sessions. An example follows: C:\FD\FILES\FOSSIL\ ;FOSSIL drivers C:\DRIVERS\OS2\ ;OS/2 drivers C:\DRIVERS\LINUX\ ;Linux drivers C:\DRIVERS\WIN\ ;W3x, W95, and WNT drivers C:\FD\FILES\TXT\ ;Text files 14.1.1.2 SecList This file is similar to List (above), with the exception that it is only used for secure sessions. This allows additional directories to be available for file requests made during secure sessions. 14.1.1.3 Alias The alias file is used to define a requested name (file) to result in none or more files being sent to the requesting system. Alias definitions are also referred to as magic files, or magic filenames. The alias file is also used to define service requests (see "Service requests"). One advantage of using alias definitions for a specific file, or a specific set of files, is that the requesting system does not need to know the actual local name of the file(s); another advantage is that the directory in which the files are located do not have to be listed in the List or SecList files (above). * Alias definitions are searched before any directories specified in List and SecList are processed. This file is used for secure and unsecure sessions. An example follows: File requests Page 192 FrontDoor Administrator Guide LatestOS2Driver C:\DRIVERS\OS2\OS2DVR.EXE ;Latest OS/2 driver This would result in C:\FD\FILES\DRIVERS\OS2\OS2DVR.EXE being sent when FD processes an inbound file request for LatestOS2Driver. The alias definition (LatestOS2Driver in the above example) is not treated case sensitively when FD compares it against the requested file(s). A common definition in the Alias list is FILES, resulting in a list of all available files being sent to the requesting system. Another example follows: LatestOS2Driver C:\DRIVERS\OS2\OS2DVR.EXE ;Latest OS/2 driver AllOS2Drivers C:\DRIVERS\OS2\*.* ;All OS/2 drivers AllDrivers C:\DRIVERS\OS2\*.* C:\DRIVERS\WIN\*.* ;All drivers The filename that is transmitted to the remote system can be modified by specifying the name that should be transmitted after the actual filename: News C:\FD\FILES\TXT\NEWS.391,NEWS.TXT ;Latest news This would result in C:\FD\FILE\TXT\NEWS.391 being sent, with the name NEWS.TXT, when FD processes an inbound file request for News. Caution should be taken to use filenames that the remote system can handle; the 8+3 (nnnnnnnn.eee) construct used in DOS should always work. Note that if more than one file is specified (e.g. by using wildcards) in an alias definition, and a specific filename to use is also specified, all files sent to the remote will be sent using the same filename: News C:\FD\FILES\TXT\NEWS.*,NEWS.TXT ;Latest news This would result in all files matching C:\FD\FILES\TXT\NEWS.* being sent, with the name NEWS.TXT, when FD processes an inbound file request for News. File requests Page 193 FrontDoor Administrator Guide An alias definition can also be specified in such a way that FD automatically locates the most recent file matching the given filemask. This allows a generic name to be used without having to manually update the alias definition: LatestOS2Driver +C:\DRIVERS\OS2\*.EXE ;Latest OS/2 driver This would result in the most recent file (note the + character in immediately preceding the filemask) matching C:\DRIVERS\OS2\*.EXE being sent when FD processes an inbound file request for LatestOS2Driver. Another special prefix, the pipe or vertical bar (|) character, can be used to create an empty file. These are typically used as semaphore files (see "Semaphore files"). An example follows: DoRescan |C:\FD\SEM\FDRESCAN.NOW ;Create FDRESCAN.NOW This would "touch" (update) the timestamp of C:\FD\SEM\FDRESCAN.NOW, or create the file if it does not exist, when FD processes an inbound file request for DoRescan. As has been shown (above), more than one file specification can be used for an alias definition. Thus, the following definition: GetData C:\DBASE\NATLIDX.ZIP |C:\DBASE\DIDFREQ.SEM would result in C:\DBASE\NATLIDX.ZIP being sent, and C:\DBASE\DIDFREQ.SEM being updated or created, when FD processes an inbound file request for GetData. This construct could be used by an external application to check if the above file (NATLIDX.ZIP) has been requested, and if so, perform maintenance or removal of the file, etc. File requests Page 194 FrontDoor Administrator Guide 14.1.1.4 SecAlias This file is similar to Alias (above), with the exception that it is only used for secure sessions. This allows additional alias definitions to be available for file requests made during secure sessions. * Alias definitions are searched before any directories specified in List and SecList are processed. 14.1.1.5 Message In the event that FD cannot satisfy an inbound file request for one reason or another, it will return a message to the remote system indicating why the file request(s) could not be satisfied. If a filename has been specified for the Message option, FD will include the contents of the specified file when it creates its failed request message. 14.1.2 Request limits These settings specify restrictions that FD will enforce when processing inbound file requests. Ultimately, the behavior settings of the current event (see "Events") determine if FD will honor inbound file requests. 14.1.2.1 Allowed systems This setting specifies which systems, in general, should be allowed to request files from the local system. The valid options are: Any, None, and Listed in nodelist. The last choice allows only those systems listed in the nodelist database to request files. File requests Page 195 FrontDoor Administrator Guide 14.1.2.2 Stop after 1st match (Exp) This setting specifies if FD should stop searching for (more) matching files after it has found one file matching an explicit request, i.e. a request for a filename without wildcards. If this setting is No, FD will continue searching the directories specified in List and SecList (see above) for further matches. 14.1.2.3 Stop after 1st match (WC) This setting is similar to the above setting but specifies how FD should behave after a match has been made when the requested file contains one or more wildcards. 14.1.2.4 Maximum match (files) This setting specifies the maximum number of (matching) files FD should allow a remote system to request during one session. If a file specified in an alias definition (see above) is requested, it is counted as one file, regardless of the number of files the alias definition actually expands to. If this setting is zero (0), FD will not use it to limit the amount of data that can be requested. 14.1.2.5 Maximum time (minutes) This setting specifies the maximum allowed transfer time of requested files during one session. FD uses the connection speed to estimate the transfer time. If this setting is zero (0), FD will not use it to limit the amount of data that can be requested. 14.1.2.6 Maximum size (Kb) This setting specifies the maximum number of kilobytes (1024 bytes) FD should allow a remote system to request during one session. If this setting is zero (0), FD will not use it to limit the amount of data that can be requested. File requests Page 196 FrontDoor Administrator Guide 14.1.2.7 Minimum speed (BPS) This setting specifies the minimum connection speed for which FD should allow file requests. If the connection speed is less than the value specified here, FD will not allow inbound file requests during the session. 14.1.2.8 Limited request hours This setting specifies that FD should only allow inbound file requests during specific times of the day. 14.1.2.9 Start time If Limited request hours (above) has been enabled (Yes), this setting determines the time at which FD will begin allowing file requests. The start time is expressed in 24-hour notation (HH:MM). 14.1.2.10 End time If Limited request hours (above) has been enabled (Yes), this setting determines the time at which FD will stop allowing file requests. The end time is expressed in 24-hour notation (HH:MM). 14.1.2.11 Days If Limited request hours (above) has been enabled (Yes), this setting determines on which days of the week FD will allow file requests. File requests Page 197 FrontDoor Administrator Guide 14.1.3 Request processor An external request processor (ERP) is basically a drop-in replacement for the internal mechanism used to process inbound file requests. The primary difference is that it is an external program and can thus be easily replaced and updated. Other advantages include being able to access proprietary database formats used by some BBS packages, and to handle searches for files located on media that does not respond well to the file searching approach used by FD (such as CD-ROM). When an external request processor is used, FD will only process service requests (see "Service requests"), and assume that the request processor handles the remaining tasks involved with supporting inbound file requests. 14.1.3.1 Program This is the program, and its parameters, that will be invoked by FD to handle inbound file requests. A number of special parameters can be used to force FD to supply the program with information about requested files, the location of certain system files, etc. The documentation of the external request processor should list the required parameters. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 14.1.3.2 Enabled This setting specifies if the external request processor should be invoked by FD to handle inbound file requests. If this setting is No, FD will handle inbound file requests internally. 14.1.3.3 Swapping This setting specifies if the DOS version of FD should attempt to swap as much of itself out of memory as possible before invoking the external request processor. Unless the external request processor uses very little memory, this setting should typically be Yes. File requests Page 198 FrontDoor Administrator Guide 14.1.4 Request security FD will by default allow any system to request files from the local system, as applicable by the various configuration options above and current event restrictions. FD can, however, be configured to require a specific password to be presented by the remote system before access is given to certain directories and/or files; this allows sensitive files to be made available for file request only to those systems presenting the correct password. The request security option presents a full-screen interface for configuring file request security settings. The Filename/Directory field contains an alias definition, a filename, directory, or unique portion therefor. The Password field is the password FD should require to be presented before it will allow access to the specified file or directory; the password is not case sensitive. Inactive entries are ignored by FD. To protect an alias definition, the name of the alias should be specified in the Filename/Directory field. FD will use the first entry in the request security list matching a requested file; this is only of importance when using incomplete filename specifications or directory names in the Filename/Directory field. Some examples follow: GetData GetDataPassword C:\FD\ PasswordOne C:\FD\SYSTEM\ PasswordTwo this would protect the file or alias GetData with the password GetDataPassword. Any file located in C:\FD\ or a sub-directory thereof is protected by the password PasswordOne. The last entry will be ignored because FD will match any file from C:\FD\ with the second entry. In order for the third entry above to be of any use, the list has to be arranged as follows: File requests Page 199 FrontDoor Administrator Guide GetData GetDataPassword C:\FD\SYSTEM\ PasswordTwo C:\FD\ PasswordOne this would allow a different password to be required for files in C:\FD\SYSTEM\, or a sub-directory thereof. For other files in the C:\FD\ structure, the third entry would be used. When an external request processor is used, it is the responsibility of that program to handle file request security; FD will only handle security issues relevant to service requests in this situation. File requests Page 200 FrontDoor Administrator Guide 15. SERVICE REQUESTS A service request is identical to a file request in all aspects except two: service requests are used to invoke an external program to perform some sort of service, service requests are furthermore handled by FD regardless of if an external request processor is used to handle file requests. 15.1 DEFINITION A service request is defined in the alias list (see "File requests"). To distinguish a service request definition from a normal alias definition, the > (greater than) character is used; much like other special prefixes mentioned above are used to indicate a special alias definition. A service request definition consist of three parts: >[ ^] An example of a very simple service request: FETCHINBOUNDDIR >DIR C:\FILES\NET\*.* >C:\FD\X.BAK ^-C:\FD\X.BAK This would invoke the DIR command with C:\FILES\NET\*.*>C:\FD\X.BAK as the parameter. When the DIR command has completed, FD will transmit C:\FD\X.BAK to the remote system, and then remove the file (C:\FD\X.BAK). Note the > (greater than) character immediately preceding the DIR command, this character is what indicates that FD should handle this as a service request. 15.1.1 Alias The name of the alias - this is what the remote system must request for the service request to be invoked. Service requests Page 201 FrontDoor Administrator Guide 15.1.2 Program The program, and its parameters, that will be invoked when an inbound file request for the specified alias is processed by FD. This field must be prefixed by a > (greater than) character, immediately followed by the name of the program. It is important that an extension is specified if a batch (.BAT FOR DOS AND .CMD FOR OS/2, or .BTM for 4DOS/4NT/4OS2) file is used since it has to be invoked by using the command processor (e.g. COMMAND.COM, CMD.EXE, 4DOS.COM, etc). A number of special parameters can be used to force FD to supply the invoked program with information about requested files, the location of certain system files, etc. The FrontDoor Developer's Kit (FDDEV) contains a detailed explanation of the special parameters available to service requests. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 15.1.3 Action The contents of this field (if present), determines what FD should do when has completed. The use of this field is optional. If it is not specified, FD will not send any files to the remote system when the service request has completed. The field is divided into three sub-fields: . The sub-field determines what FD should do with the files matching . 15.1.3.1 Caret The caret (^) character. 15.1.3.2 DeleteOption One of the - (minus), + (plus), or ? (question mark) characters. Service requests Page 202 FrontDoor Administrator Guide Using a + (plus) character as the specifies that FD should not remove the files matching after they have been sent to the remote system. Using a - (minus) character as the specifies that FD should remove the files, matching after they have been sent to the remote system. If the transfer of the files fails (i.e. the session is prematurely terminated for some reason), FD will still remove the files. Using a ? (question mark) character as the specifies that FD should remove only those files, matching , successfully sent to the remote system. 15.1.3.3 Filemask A filemask specifying which files FD should send to the remote system when processing an inbound file request for the specified alias (i.e. the service request). 15.2 SECURITY Since service requests are closely related to file requests, they are protected by the same security mechanisms as file requests. Service requests should, however, be used with extreme caution, in particular with regards to the integrity of the program invoked when a service request is requested by a remote system. It is very important that these programs terminate properly and do not leave the system in an unstable operational state. Service requests Page 203 FrontDoor Administrator Guide 16. FDSERVER FD supports an external access interface called FDSERVER. This interface is similar in capacity to the service requests interface (see "Service requests"). The FDSERVER function, however, is primarily intended for remote system maintenance. * The FDSERVER function is by default disabled and should only be enabled after it is understood in its entirety. The function is activated by FD when it detects a message addressed to FDSERVER (case insensitive) on the local system that does not have Received (Rcvd) or Lock status. The message can be sent from another system or created locally. It is important to keep in mind, however, that the FDSERVER function can only be activated when FD is not currently in a mail session. 16.1 FDSERVER REQUESTS Messages addressed to FDSERVER on the local system are called FDSERVER requests. An FDSERVER request is best described as a controlled OS shell where external programs and commands can be invoked. 16.1.1 Format All non-empty lines in the body (text section) of the request message are considered to be programs or commands that should be processed by FD. Internal commands (see below) are preceded by a % (percent) character. See "OS/2 version specifics" for more information about how to specify external programs for the OS/2 version of FrontDoor. 16.1.2 Limitations Some limitations are placed on the contents of an FDSERVER request, these will now be described. Programs that require local keyboard input should not be invoked from a request. FDSERVER Page 204 FrontDoor Administrator Guide Batch (.BAT FOR DOS AND .CMD FOR OS/2, and .BTM for 4DOS/4NT/4OS2) file labels are not supported. Programs invoked from a request should never alter the integrity of the system or leave the system in an unstable operational state. 16.1.3 Specific tasks Applicable requests addressed to FDSERVER will be processed by the first FD that detects the request. It is possible to specify which task should handle an FDSERVER request by addressing the message to "FDSERVER " in the message's To: field. For example, a message addressed to FDSERVER 2 on the local system will only be processed by task two (2). * Only one FD can process FDSERVER requests at a given time. 16.1.4 Rescan When all FDSERVER requests have been processed by FD, it will rescan the contents of the System NetMail Folder. 16.1.5 Internal commands All internal commands begin with a % (percent) character and are treated case insensitively. 16.1.5.1 %END Terminate processing of the currently processed request. This is not required unless the message body also contains non-FDSERVER text. 16.1.5.2 %SEMAPHORE Followed by one or more filenames (excluding path), separated by spaces, specifies that FD should create/update the specified semaphores (see "Semaphore files"). The specified filename(s) may not contain wildcards. For example: FDSERVER Page 205 FrontDoor Administrator Guide %SEMAPHORE FDNOCALL.1 FDNOCALL.2 would create/update the two semaphores FDNOCALL.1 and FDNOCALL.2 in the semaphore directory. 16.1.5.3 %CHD Followed by a path, specifies that FD should change the currently active drive and/or directory to the specified drive and/or directory. When FD has completed the processing of the request, the current drive and directory will be restored to its startup path. For example: %CHD M:\MAIL\REPORTS would change the drive to M: and the directory to \MAIL\REPORTS. 16.1.5.4 %DEBUG Followed by ON or OFF, specifies that FD should log (ON) each processed line to its log file. 16.1.5.5 %LOG Followed by a log message, specifies that FD should add the message to its log file; the & (ampersand) log symbol is used. For example: %LOG Running report generator would produce output similar to the below text in the log file: FDSERVER Page 206 FrontDoor Administrator Guide & 11.01.26 Running report generator 16.1.5.6 %KILLMSG Specifies that FD should remove the FDSERVER request (message) once it has been successfully processed. The default is to simply stamp the request with Received (Rcvd) status once it has been processed. If FD encounters a request with an incorrect password, the request will simply be stamped with Rcvd (Received) status. 16.2 ENABLING FDSERVER The FDSERVER function is enabled by specifying an FDSERVER password in FDSETUP (Mailer.FDServer). The password is not case sensitive; the password is specified in the Re: (Subject) field of FDSERVER requests. * Note that the FDServer window will not be automatically closed when a password has been specified. This is to allow the display of the current status of FDSERVER (enabled/disabled). FDSERVER Page 207 FrontDoor Administrator Guide 17. SCRIPTS Scripts provides an alternative method to calling a specific system directly by dialing its telephone number. Scripts can be used in a number of ways; including handling the actual mail session, but are typically used to establish a connection between two systems when simply dialing a telephone number is not sufficient. Scripts can also be used in the Terminal to establish a terminal session with a given service such as an internet service provider (ISP) or dial-up bulletin board system (BBS). In the simplest of definitions, the commands available in the FrontDoor script language is a simple programming language used to control how FD interacts with data that is received from the communications device. Script files by default have an extension of .SCR and are located in the SYSTEM directory. Script files used in the Terminal do not need to be located in the SYSTEM directory. Each line in a script file is either a comment, a command, or data for a command. Text following a semi-colon (;) is considered a comment. Empty lines are ignored but can be used in place of comments. Adding empty lines or comments to separate commands makes it easier to read and manage the file, but does not affect how FD or the Terminal interprets it. Script files are ASCII (text) files with all lines must be terminated by a (ASCII 13, ASCII 10) pair. The script language and its commands are case insensitive unless otherwise noted. 17.1 COMMANDS Following is a list of script commands with their description. The availability information is used to indicate in what versions of FD a specific command is available, and also if the command is available when the script is used in the Terminal. Scripts Page 208 FrontDoor Administrator Guide Command SEND Availability All Description Sends a series of characters to the communications device. Everything following the SEND command on the same line will be sent. Control characters may be specified using mnemonics (see "Mnemonics" below). In addition, the special characters supported for communications device control strings (see "Modem configuration") v ^ ` | and ~ are supported. The string will be sent exactly as specified, with no case conversion. Command SENDNOXLAT Availability All Description Similar to the SEND command (above) with the exception that v ^ ` | and ~ have not special meaning and are sent verbatim ("as is"). Command PROVOKE Availability All Description Sends the specified string, with an interval of one second, until any character is received from the communications device, or until a timeout occurs (see "TIMERSET" below); or until the script is interrupted by the user. Control characters may be specified as with the SEND command (above). Command WAIT Availability All Description Waits for the specified number of seconds before continuing. The maximum value for is 6000 (100 minutes). Scripts Page 209 FrontDoor Administrator Guide Command WAITFOR || Availability All Description Waits until one or more of the specified strings are received, or until a timeout occurs (see "TIMERSET" below). Each string must be separated by a pipe or vertical bar (|) character. Control characters may be specified by using mnemonics (see "Mnemonics" below). Of the specified strings, only the first will signify success; the remaining strings will immediately terminate the script with failed status. The string comparison is case sensitive, and requires and exact match. Scripts Page 210 FrontDoor Administrator Guide Command CASE / ENDCASE Availability All Description Starts and ends a CASE construct, respectively. CASE/ENDCASE is a more flexible variant of the WAITFOR command (see above). Each line after CASE must start with a string of data to expect, followed by a colon and one or more script commands, or a label jump directive (see "Labels" below). The CASE construct is ended when the ENDCASE command is encountered on a separate line. A CASE construct cannot be nested (i.e. a CASE construct cannot contain another CASE construct). When a matching string is received from the communications device, the command on the same line will be executed. If the command consists of a label jump instruction, the script will continue from the specified label position. If it is one or more script commands, they will be executed, and the script will continue from the line following the ENDCASE command, unless the executed command(s) terminates the script. The string comparison is case sensitive, and requires an exact match. A short example follows: CASE ;Comments CONNECT : session ;Connect BUSY : >redial ;Busy, jump to REDIAL ;label "NO CARRIER" : >redial ;Note the use of double ;quotes VOICE : fail ;Nobody we can talk to @NOCARRIER : fail ;Carrier lost @DEFAULT : fail ;Timeout ENDCASE When specifying a string to match containing spaces, it should be enclosed in double-quotes ("); see the example above ("NO CARRIER"). @NOCARRIER is used to test the presence of a carrier signal (CD) in a CASE construct. @DEFAULT is used to specify a default course of action if a timeout occurs in a CASE construct (see TIMERSET command). Scripts Page 211 FrontDoor Administrator Guide Command PURGEIN Availability All Description Purges pending input data not yet processed but received from the communications device. Command PURGEOUT Availability All Description Purges pending output data not yet transmitted to the communications device. Command SETPORT Availability All Description Sets the communications device to the specified parameters. can be any value of 300, 1200, 2400, 4800, 9600, 19200 and 38400; at no time will the baudrate be set to a higher value than the highest supported speed of the called system (as applicable). is seven (7) or eight (8). is one (1) or two (2). is NONE, ODD, or EVEN. In addition, a value of minus one (-1) indicates that the previous setting for the given parameter should be retained. It should be noted that this command has no effect if the communications device has been configured with a constant DTE speed (see "Modem configuration"), as is the case with most high-speed devices in use today. Command LINESPEED Availability [ML] Description Sets the actual connect speed figure used by FD and the Terminal to estimate transfer times, etc. may be any value in the range 75-2000000. Command DIAL Availability All Description Sends , preceded by the dial command specified in the modem section of FDSETUP, to the communications device. Control characters may be entered as with the SEND command. Scripts Page 212 FrontDoor Administrator Guide Command NODEDIAL
Availability [ML] Description Similar to the DIAL command (above) with the exception that instead of specifying a telephone number, a system address is specified. FD will fetch the telephone number from the nodelist database. If the specified address could not be found, or the associated nodelist entry does not have a valid telephone number, the script will terminate. Command TIMERSET Availability All Description Sets the time for fatal timeouts while waiting to receive data from the communications device. The default setting is 120 seconds (two minutes). The maximum value is 3000 seconds (50 minutes); the minimum value is zero (0). When the WAITFOR command is used, the last used TIMERSET command determines the maximum amount of time FD will wait to receive the specified data from the communications device. In the event of a timeout, the script will terminate with failed status. Command RETRYCOUNT Availability All Description Provides a means of incrementing and checking a predefined retry count variable. If the current retry count exceeds , the script is terminated with failed status, otherwise the retry count is incremented with one (1). The retry count does not include the first attempt. Command CLEARCOUNT Availability All Description Clears the predefined retry count variable (see above), resetting it to zero (0). Scripts Page 213 FrontDoor Administrator Guide Command ENDNODE Availability All Description Terminates a node block (see "Node blocks" below). Command SESSION Availability All Description Terminates the script with success status. If the script is used in FD, the result will be that mail session initiation is attempted. It is not necessary to use the SESSION command in a script file used in the Terminal. Command FAIL Availability All Description Terminates the script with failed status. If the script is used in FD, the result will be that no mail session initiation is attempted. Command SESSIONOK Availability [ML], not in Terminal Description Forces FD to act as if it had completed a successful mail session (the successful sessions statistics are updated). If a POLL route command (see "Mail routing") was the reason for the call attempt, the poll is considered a success. This command is typically used in scripts that do not use the SESSION command to signal to FD that it should begin session initiation with the remote system. Command SESSIONFAIL Availability [ML], not in Terminal Description Forces FD to act as if it had completed a failed mail session (the failed sessions statistics are updated). If a POLL route command (see "Mail routing") was the reason for the call attempt, the poll is considered incomplete. This command is typically used in scripts that do not use the SESSION command to signal to FD that it should begin session initiation with the remote system. Scripts Page 214 FrontDoor Administrator Guide Command DISCONNECT Availability [ML] Description Unconditionally terminates a call (if any) from within the script. Script execution will resume as soon as the carrier (CD) signal has been lost; the script lowers the DTR signal to disconnect. Command SENDBREAK Availability [ML] Description Transmits a short BREAK signal to the communications device. Command LONGBREAK Availability [ML] Description Transmits a long BREAK signal to the communications device. Command DEBUG or Availability All Description Sets the state of debug mode. When debug mode is enabled, all characters received from the communications device while waiting for data will be displayed. When debug mode is disabled, FD will only display data that matches one of the strings it is waiting for. Similarly, when debug mode is enabled, all strings sent to the communications device will be displayed; when debug mode is disabled, FD will only display Sending string. See QUIET below for more information on how to affect script progress display. Command QUIET or Availability [ML] Description Used to control if FD displays script progress information such as Sending string, Setting port, etc. See DEBUG above for more information on how to affect script progress display. Scripts Page 215 FrontDoor Administrator Guide Command DISPLAY Availability [ML] Description Displays the specified string on the screen. A pair is always appended to the string. Script mnemonics (see "Mnemonics") are not supported (i.e. they will be displayed without translation). Command CLS Availability [ML] Description Clears the script window. Command NEWMAIL Availability [ML], not in Terminal Description Forces FD to act, once the script has completed, as if it has received compressed mail. This is typically used to force FD to exit to process mail. Command RESETTIMER Availability [ML] Description Resets the on-line timer displayed in the bottom right-hand corner of the script window. Command LOG Availability [ML] Description Adds to the log, using the symbol. For example: LOG + Calling FTP server would produce output similar to the below text in the log file: + 11.01.26 Calling FTP server Scripts Page 216 FrontDoor Administrator Guide Command IFBAD Availability [ML] Description Executes the command(s) listed on (which is the line immediately following the IFBAD command) if an UPLOAD, DOWNLOAD, or UPLOADMAIL (see below) command failed. Command ZMODEM1K Availability [ML] Description Forces the Zmodem transmitter to use a maximum data sub-packet size of 1024 bytes (one kilobyte). This can be used in conjunction with the UPLOAD and UPLOADMAIL commands to limit the maximum Zmodem block size. Command ZMODEM8K Availability [ML] Description Forces the Zmodem transmitter to use a maximum data sub-packet size of 8192 bytes (eight kilobytes). This can be used in conjunction with the UPLOAD and UPLOADMAIL commands to limit the maximum Zmodem block size. The default is to use 1024-byte (one kilobyte) blocks when Zmodem is used to transmit file(s) from within a script. Command ZMODEMBADESC Availability All Description Controls data escaping for the Zmodem file transfer protocol (transmitter). This command is used for troubleshooting purposes only, and should not be used unless suggested by support staff. Scripts Page 217 FrontDoor Administrator Guide Command ZMODEMREALESC Availability All Description Controls data escaping for the Zmodem file transfer protocol (transmitter). This command is used for troubleshooting purposes only, and should not be used unless suggested by support staff. Command DOWNLOAD Availability [ML] Description Receives one or more files from the remote system into the directory specified in , using the protocol specified in which must be one of X, T, S, or Z (Xmodem, Telink, SEAlink, and Zmodem respectively). must contain a complete filename for Xmodem transfers and a valid directory for Zmodem, SEAlink, and Telink transfers. Command UPLOAD Availability [ML] Description Transmits the files matching to the remote system, using the protocol specified in which must be one of X, T, S, or Z (Xmodem, Telink, SEAlink, and Zmodem respectively). may contain wildcards for all protocols. Scripts Page 218 FrontDoor Administrator Guide Command UPLOADMAIL Availability [ML], not in Terminal Description Transmits mail to the remote system, using the protocol specified in which must be one of X, T, S, or Z (Xmodem, Telink, SEAlink, and Zmodem respectively). This will force FD to behave as if it had called the system directly to deliver outbound mail. The command can only be used once within a script, and once used, the effect of using the SESSIONOK, SESSION, and FAIL commands is somewhat altered. The SESSIONOK and SESSION commands will terminate the script with success status and perform post-session processing. The FAIL command will terminate the script with fail status, but will also perform post- session processing. Command UPLOADMAILSKIPOK Availability [ML], not in Terminal Description This command is typically use in conjunction with the SESSIONOK command to replace the use of the UPLOADMAIL command when a script is only used to pickup mail. By using a combination of the UPLOADMAILSKIP and SESSIONOK commands, it is possible to force FD to consider a route-generated POLL (see "Mail routing") as successful when the script is only used to pickup mail. Command SEMAPHORE Availability [ML] Description Specifies that FD should create/update the specified semaphores (see "Semaphore files"). The filename(s) may not contain wildcards and must include complete path specifications (i.e. no directory is assumed). The macro $[SEMPATH] can be used to easily create/update semaphores in the semaphore directory. Scripts Page 219 FrontDoor Administrator Guide Command DELETEFILE Availability [ML] Description Removes the specified file(s) which must be complete filenames without any wildcards. It is not considered an error if one or more of the specified files does not exist. Command IFEXIST