PC Online 1996 October

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

/ PC Online 1996 October / PCO_10.ISO / filesbbs / imail175.arj / IMAIL.DOC < prev next >

Wrap

Text File | 1995-10-07 | 291.6 KB | 6,478 lines

█┐ █▀▀▀█┐ █▀▀█┐ █┐ █┐ ▀▀▀█┐ █▀▀█┐ █▀▀▀ █│ █│█┐█│ █│▀█│ █│ █│ ▄▄▄▄ ▄▄▄█│ █▄▄█│ █▄▄▄ █│ █│└┘█│ █│ █│ █│ █│ └───┘ └──█│ █ █│ █ █┐ █│ █│ █│ █│ █│ █│ █▄▄▄ ▄▄▄█│ █▄▄█│ █▄▄█│ └┘ └┘ └┘ └┘ └┘ └┘ └───┘ └───┘ └───┘ └───┘ V e r s i o n 1 . 7 5 Copyright 1992-1995 by Andreas Klein TABLE OF CONTENTS ================== 1 INTRODUCTION 1 2 LICENSE AGREEMENT 1 3 STANDARD DISCLAIMER 2 4 ACKNOWLEDGMENTS 3 4.1 Very special thanks to: ....................................... 3 4.2 Copyrights .................................................... 4 5 GENERAL SECTION 5 5.1 System Requirements ........................................... 5 5.1.1 Hardware ............................................... 5 5.1.2 Software ............................................... 5 5.2 Upgrading from Previous Versions to IMAIL 1.75 ................ 6 5.3 The IMAIL book of records ..................................... 6 5.3.1 Networks, Multitasking and File Sharing ................ 7 5.4 Environment Variables ......................................... 8 5.4.1 IMAIL .................................................. 8 5.4.2 POINTNET ............................................... 8 5.4.3 TASK ................................................... 8 5.4.4 TZ ..................................................... 9 6 IMSETUP 10 6.1 Keymapping, general usage und charset ......................... 10 6.1.1 The most important key: F1 ............................. 10 6.1.2 Keys in the BROWSE mode ................................ 10 6.1.3 Keys in the EDIT mode .................................. 11 6.1.4 The characterset ....................................... 12 6.2 General configuration ......................................... 13 6.2.1 System Addresses ....................................... 13 6.2.2 Domain manager ......................................... 13 6.2.3 suBdirectories ......................................... 14 6.2.4 Log options ............................................ 17 6.2.5 aRealink options ....................................... 18 6.2.6 Unlinked Hudson to passth .............................. 20 6.2.7 Product codes .......................................... 21 6.2.8 no Import .............................................. 21 6.2.9 sysop Names ............................................ 21 6.2.10 dUpe settings ......................................... 21 6.2.11 nodeMgr defaults ...................................... 22 6.2.12 sPace settings ........................................ 23 6.2.13 Toss settings ......................................... 25 6.2.14 System settings ....................................... 26 6.2.15 Miscellaneous ......................................... 28 6.3 Archiver management ........................................... 29 6.3.1 Compression Programs ................................... 30 6.3.2 Decompression Programs ................................. 30 6.4 Area Manager .................................................. 30 6.4.1 Special BROWSE Keys .................................... 31 6.4.2 Flags displayed in the Area Record ..................... 33 6.4.3 The Message Area Record ................................ 34 6.4.4 Special boards ......................................... 41 6.5 Node Manager .................................................. 42 6.5.1 Special BROWSE Keys .................................... 42 6.5.2 The Node Record ........................................ 44 6.6 Group Manager ................................................. 50 6.7 Forward link manager .......................................... 51 6.8 Pack Routing .................................................. 52 - 2 - TABLE OF CONTENTS =========================================================================== 6.9 Import/Export Functions ....................................... 54 6.9.1 Export Areas.Bbs ....................................... 54 6.9.2 Export GoldED Areafile ................................. 54 6.9.3 Export FidoNet.na ...................................... 54 6.9.4 Export TimEd areafile .................................. 54 6.9.5 Import Areas.Bbs ....................................... 54 7 IMAIL - Command line options 56 7.1 TOSS - Toss Incoming Mail ..................................... 56 7.2 SCAN - Scan for Outgoing Mail ................................. 57 7.3 The midnight maintenance ...................................... 58 8 IMCOMP - Compress ARCmail bundles 60 9 IMPACK - Pack Net Mail Messages 61 10 IMALNK 63 10.1 Format of the Request ........................................ 64 10.2 Arealink Replies ............................................. 65 10.3 Meta-Commands ................................................ 65 10.4 The rule support ............................................. 67 10.5 Remote Maintenance ........................................... 68 10.6 Local Maintenance ............................................ 69 11 IMTHINGS 71 11.1 IMPORT (MHS-) Import Net Mail Messages ...................... 71 11.2 EXPORT (----) Export area configuration ..................... 71 11.3 INDEX (-H--) Rebuild index files ........................... 72 11.4 KILL (MHSJ) Delete messages from an area .................. 72 11.5 NETKILL (----) Handle 'deceased' links ....................... 74 11.6 LINK (MHSJ) Link Messages in Message Base ................. 75 11.7 MOVE (MHS-) Move Message Area ............................. 75 11.8 PACK (MHSJ) Compress message base ......................... 76 11.9 POST (MHSJ) Post message in echo area ..................... 78 11.10 RECOVER (-H--) Unerase messages ............................. 78 11.11 SEND (----) Send a file .................................. 79 11.12 SORT (-H--) Sort the Message Base ........................ 81 12 AN OVERVIEW OF ECHOMAIL 82 12.1 What is Echo Mail? ........................................... 82 12.2 How it Works ................................................. 82 12.3 Some notes on Addresses ...................................... 82 12.4 Echo Mail Message Control Information ........................ 83 12.4.1 Area Line ............................................. 83 12.4.2 Tear Line ............................................. 83 12.4.3 Origin Line ........................................... 84 12.4.4 SEEN-BY Lines ......................................... 84 12.4.5 PATH Lines ............................................ 85 12.5 Methods of Sending Echo Mail ................................. 85 12.6 Topology ..................................................... 85 12.7 Why a PATH line? ............................................. 87 12.8 Gating of Echo Mail .......................................... 88 13 KLUDGE LINES and CAPABILITY 89 13.1 A brief explanation of Kludge Lines .......................... 89 13.1.1 EID (Echomail IDentification) ......................... 89 13.1.2 FLAGS ................................................. 89 13.1.3 FMPT (FroM PoinT) ..................................... 90 13.1.4 INTL (INTernationaL/INTerzonaL) ....................... 90 13.1.5 MSGID (MeSsaGe IDentification) ........................ 90 13.1.6 PID (Product IDentification) .......................... 90 TABLE OF CONTENTS - 3 - =========================================================================== 13.1.7 REPLY ................................................. 91 13.1.8 RESCANNED ............................................. 91 13.1.9 TID (Tosser IDentification) ........................... 91 13.1.10 TOPT (TO PoinT) ...................................... 91 13.2 A Note about Capability ...................................... 92 14 HOT HINTS AND INFO 95 14.1 Interrupting IMAIL ........................................... 95 14.2 Use Esc carefully! ........................................... 95 14.3 setting compression \& space settings correctly .............. 96 14.3.1 ''be kind to my downlinks'' ........................... 96 14.3.2 ''be kind to my harddisk'' ............................ 97 14.4 When, how and why run IMAIL programs ......................... 98 14.4.1 ''Something came in and I want it to be processed'' ... 98 14.4.2 ''I wrote something and EVERYONE shall read it :-)'' .. 99 14.4.3 ''I'm not interested in yesterday!'' .................. 99 14.5 Batch file example ........................................... 100 14.6 Defaults for Compression/Decompression ....................... 102 14.6.1 Compression ........................................... 102 14.6.2 Decompression ......................................... 102 14.7 Files Maintained by IMAIL .................................... 103 14.8 Exit Codes and Semaphores .................................... 105 15 IMAIL REGISTRATION SITES 108 15.1 Headquarters ................................................. 108 15.2 Italy ........................................................ 108 15.3 Benelux ...................................................... 108 15.4 Denmark ...................................................... 108 15.5 England ...................................................... 109 15.6 North America/Latin America .................................. 109 15.7 Australia .................................................... 109 1. INTRODUCTION by Bob Snowdon IMAIL is an FTSC-compatible, FidoNet Technology Mail Processor. In other words, it moves incoming messages received by your mailer to a local message base or bases and is also able to forward mail to other systems. This is called TOSSing. Conversely it can search the message base for locally entered messages, creating packets addressed to the other connected systems for later transmission by your mailer. This is the SCAN function. At the moment IMAIL is a DOS based set of utilities but there are plans to migrate to other operating systems in the future. Support for DOS file locking and exit codes, mailer multi-tasking flags and semaphores and it's own control semaphores are important operational features of IMAIL, enabling it's smooth integration into multi-tasking systems. IMAIL is written for those who use any combination of the "Hudson" message base (ProBoard, QuickBBS, SuperBBS, RemoteAccess, or fully compatible), a *.MSG message base (for example Opus), the Squish message base (for example Maximus) or the Jam message base (for example Remote Access and Proboard). It can be used with mailers which implement the file attach method of mail transfer, such as FrontDoor or Intermail, or with systems which use "flow files" such as Binkley or Portal of Power. Support for the D'Bridge Queue system is planned for the future. It also features full Zone and Point support, eliminating the need to use the "fake address" method of sending mail to and from points while, however, still supporting point net addressing. IMAIL offers very powerful message area management facilities which allow it to handle tasks such as automatically creating areas from incoming mail or removing areas that are dead or no longer have down links. These functions, plus the built in remote area manager, make IMAIL well suited for use by major mail hubs with many links but equally, its ease of setting up and maintenance, makes it attractive to end nodes or point systems. If you are new to FidoNet mail processing, I suggest you familiarise yourself with the documentation for the mailer you will be using, and read "An Overview of Echo mail" in chapter 12. . This documentation is also available as LaTeX - DVI at 2:2480/141 I175EDVI.RAR 2. LICENSE AGREEMENT This software and anything enclosed in the original archive are protected by both German and international copyright law and treaty provisions. IMAIL is NOT Public-Domain or Freeware, it is released as Shareware. If you intend to use this program after a trial period of THIRTY (30) days, you must register your copy of IMAIL or stop using it. You are entitled and encouraged to give this program together with its original documentation to anybody, if you do not change the contents of the archive or the program itself. The distribution of modified versions is prohibited. IMAIL has no restricted features, everything can be used with one exception (via lines). But unregistered users will only receive minimal support from the author and support / registration sites. Only registered users will get full support. For registration information contact the registration site closest to you, the addresses can be found in chapter 15., page 108. More specific information and the current registration fees can also be found in the IMAILREG.ARJ supplied in the release archive. Registered users receive a key file with a unique serial number. The key file remains the property of the author Andreas Klein. It must not be hacked, distributed, re-engineered or modified in any way. It is also forbidden to modify, adapt, translate, reverse engineer, decompile and/or disassemble this software. If you violate this agreement, your license expires immediately and legal action may be started against you. IMAIL is in no way a crippled program, nor will it stop working after a certain amount of time. I don't like this concept in ShareWare programs. It will only do a little reminding after a certain amount of time... This software is provided AS IS without any warranty, expressed or implied, including but not limited to fitness for a particular purpose. The author will not be liable for any direct or consequential damages, lost profits or lost savings arising out of the use of this software due to loss of data or any other reason. The person using the software bears all the risks as to the quality and performance of the software. I will however do my best to fix any bugs reported to me, as long as I have enough information to do this. If your local laws do not permit any of the statements made above, or if you do not agree with any of them yourself, then you are not licensed to use this program! 3. STANDARD DISCLAIMER This product is meant for educational purposes only. Any resemblance to real persons, living or dead is purely coincidental. Void where prohibited. Some assembly required. List each check separately by bank number. Batteries not included. Contents may settle during shipment. Use only as directed. No other warranty expressed or implied. Do not use while operating a motor vehicle or heavy equipment. Postage will be paid by addressee. Subject to CAB approval. This is not an offer to sell securities. Apply only to affected area. May be too intense for some viewers. Do not stamp. Use other side for additional listings. For recreational use only. Do not disturb. All models over 18 years of age. If condition persists, consult your physician. No user-serviceable parts inside. Freshest if eaten before date on carton. Subject to change without notice. Times approximate. Simulated picture. No postage necessary if mailed in Antarctica. Breaking seal constitutes acceptance of agreement. For off-road use only. As seen on TV. One size fits all. Many suitcases look alike. Contains a substantial amount of non- tobacco ingredients. Colors may, in time, fade. We have sent the forms which seem to be right for you. Slippery when wet. For office use only. Not affiliated with the Red Cross. Drop in any mailbox. Edited for television. Keep cool; process promptly. Post office will not deliver without postage. List was current at time of printing. Return to sender, no forwarding order on file, unable to forward. Not responsible for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform. At participating locations only. Not the Beatles. Penalty for private use. See label for sequence. Substantial penalty for early withdrawal. Do not write below this line. Falling rock. Lost ticket pays maximum rate. Your cancelled check is your receipt. Add toner. Place stamp here. Avoid contact with skin. Sanitized for your protection. Be sure each item is properly endorsed. Sign here without admitting guilt. Employees and their families are not eligible. Beware of dog. Contestants have been briefed on some questions before the show. Limited time offer, call now to insure prompt delivery. You must be present to win. No passes accepted for this engagement. No purchase necessary. Processed at location stamped in code at top of carton. Shading within a garment may occur. Use only in well-ventilated area. Keep away from fire or flame. Replace with same type. Approved for veterans. Booths for two or more. Check here if tax deductible. Some equipment shown is optional. Price does not include taxes. Not recommended for children. Prerecorded for this time zone. Reproduction strictly prohibited. No solicitors. No alcohol, dogs, or horses. No anchovies unless otherwise specified. Restaurant package, not for resale. List at least two alternate dates. First pull up, then pull down. Call toll free before digging. Driver does not carry cash. Some of the trademarks mentioned in this product appear for identification purposes only. Record additional transactions on back of previous stub. 4. ACKNOWLEDGMENTS IMSETUP makes use of the C eXtended Library (CXL) version 5.2 by Mike Smedley and the Squish MSGAPI by Scott J. Dudley. IMAIL also uses the JAM(mbp) API - Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin. My deepest gratitude to the Beta Testers, who risked seeing their message base grunged by my program, and for having had patience when I released buggy betas. 4.1. Very special thanks to: Fabiano Fabris who started the IMAIL project and worked on it until IMAIL 1.30. Stefan Kaspar, who together with me took over IMAIL from Frank Prade, Fabiano Fabris. Markus Lomb and Stefan Rubner. Henk Heidema, without their support, the IMAIL project Roelof Heuvel, would not have suceeded and a lot of bugs Andy Kreuzer and would not have been found. Bob Snowdon. Klaus Bader who maintains the documentation Frank Koehler who works on the Readme-file - 4 - 4. ACKNOWLEDGMENTS =========================================================================== 4.2. Copyrights The following copyrighted programs are mentioned in this document: Arc System Enhancement Associates Allfix Harald Harms Arj Robert K. Jung Binkley Bit Bucket Software Corp. D 'Bridge Chris Irwin DesqView Quarterdeck Office Systems DR-DOS Novell Inc. (Digital Research Inc.) FrontDoor Joaquim Homrighausen InterMail Continental Software ITRACK Frank Prade Jam Joaquim Homrighausen, Andrew Milner, Mats Birch und Mats Wallin. LANtastic Artisoft Inc. LHarc/LHA Haruyasu Yoshizaki Maximus Scott J. Dudley MS-DOS Microsoft Corporation Novell DOS Novell Inc. Novell Netware Novell Inc. OS/2 IBM Corporation Opus Wynn Wagner III PAK NoGate Consulting PC-DOS IBM Corporation PKZIP PKWARE Inc. PKarc/PKpak PKWARE Inc. Portal of Power The Portal Team ProBoard Philippe Leybaert QEMM Quarterdeck Office Systems QuickBBS Richard Creighton & Steve Grabilowitz RAR Eugene Roshal RemoteAccess Andrew Milner Scottex Toilet Paper Scott Corp. SQZ J. I. Hammarberg Squish SCI Communications SuperBBS Aki Antman & Risto Virkkala TosScan Joaquim Homrighausen UC2 AIP-NL Validate McAfee Associates XRS Mike Ratledge Zoo Rhaul Dhesi If I have forgotten someone, or have made any mistakes, my most sincere apologies! Drop me a line and it will be rectified for the next release. 5. GENERAL SECTION IMAIL is supplied in a single compressed file which should contain the following files: IMAIL.EXE The mail processor IMALNK.EXE The AreaLink IMCOMP.EXE The packet compression program IMCVT.EXE The conversion-tool for previous configs IMPACK.EXE The net mail packer program IMSETUP.EXE The setup program IMSETUP.HLP The online help file for IMSETUP IMTHINGS.EXE The external utilities IMAIL.DOC The documentation IMAIL.GER The german documentation README.1ST Summary of changes since the last release IMAILREG.ARJ Information concerning registration. FTSCPROG.069 The FTS-product code list There may also be a README file which includes last minute information. Please refer to it before installing. Copy all the executable files to the same directory. Set the IMAIL environment variable (see below) to point to a directory where you want your configuration files to be stored (usually the same directory as that in which the program "resides", it is known as the IMAIL "home" directory) and run IMSETUP. 5.1. System Requirements 5.1.1. Hardware IBM PC/AT/386/486, or fully compatible Mono or color display Hard disk keyboard strongly recommended :-) - 6 - 5. GENERAL SECTION =========================================================================== 5.1.2. Software MS-DOS (or PC-DOS) 3.10 or greater An FTSC-0001 compatible mailer One or more compression programs, selected from: ARC by System Enhancement Associates; Arj by Robert K. Jung; LHarc by Haruyasu Yoshizaki; PKARC/PKPAK by PKWARE Inc.; PAK by NoGate Consulting; PKZip by PKWARE Inc.; RAR by Eugene Roshal; SQZ by J. I. Hammarberg; UC2 by Ad Infinitum Programs or ZOO by Rhaul Dhesi. 5.2. Upgrading from Previous Versions to IMAIL 1.75 If you are upgrading IMAIL from a previous version, please read the file README.1ST for information on new features since the last public release. The program IMCVT.EXE will convert your database from version 1.6x to the current format In any case, delete IMAIL.AX and IMAIL.BX or IMAIL.AI and IMAIL.BI and run IMTHINGS PACK /P afterwards, because the index files have changed. Otherwise, you risk a database inconsistency and thus loss of data! If you are still using IMAIL 1.10, 1.20/1.21(a), 1.30/1.35(a), 1.4x or 1.5x, you should contact the next support/registration site where conversion tools should be available. There is one tool for upgrading from 1.10 to 1.20, one from 1.2x to 1.3x, one from 1.3x to 1.4G3, one from 1.4x to 1.51 and at last one from 1.5x to 1.60. 5.3. The IMAIL book of records For the obnoxious kind, here a list of the maximum values of IMAIL: Areas: disk space/2Kb (i.e. not limited at all). Downlinks per area: 200. overall Downlinks: varies from system to system, directly depends on conventional memory, anywhere above 250. Akas: 50 (1 Main + 49 Akas). Domains: 50 (quite logical). Groups: 255. forward Links: 15. compression programs: 11, may be freely configured. decompression prgs: 10 hardcoded, 1 'dealeverything'. no-import-names: 20. sysop names: 20. traceable dupes: 999.999. (should be enough...) maximum PKT size: 9,999 MB. maximum ARCmail size: 99,999 MB. maximum size of a mail: 64 kB. 5.3. THE IMAIL BOOK OF RECORDS - 7 - =========================================================================== maximum hudsonbase size:16 MB. (QBBS-imposed limit) Squish base maximum: approximately 5300 msgs. File selector box: max. 4000 files in one directory. 5.3.1. Networks, Multitasking and File Sharing IMAIL has been extensively tested in the NetWare and LANtastic environments, as well as under DESQview and OS/2 2.x. IMAIL will give up timeslices when running under a multitasker like DESQview, OS/2 or Windows. IMAIL implements file sharing as "expected" by RemoteAccess v1.1x. What this means is that it will open all files in sharing mode, and will lock MSGINFO.BBS just before writing to any of the message base files. If IMAIL encounters the semaphore MBUNLOCK.NOW, before it locks the message base itself, it waits 15 seconds slices and gives control back to give another programs in a multitasking environment enough time to run. When an attempt to lock the Hudson mailbase fails, the MBUNLOCK.NOW is created also. Note that SHARE.EXE MUST be loaded in order for this to work correctly, unless you are using IMAIL in a network environment, which supports the MS-DOS file sharing functions. However, IMTHINGS (besides the LINK function) does NOT make use of RemoteAccess file sharing. It is expected that message base utilities will not be run while a user is online, or while some other program is making use of the message base. Damage can result if you try to use IMTHINGS together with another program. If you are using IMAIL in a multi-tasking or network environment, please set the multitasking flag in IMSETUP (see chapter 6.2., page 27). In this case IMAIL fully supports the multi-tasking and the network capabilities of FrontDoor 2.20, Intermail, Binkley and Portal of Power. IMAIL indicates when it is accessing the ARCmail bundles for a certain system and checks whether a session is currently running to avoid file sharing problems. There are situations where it can be necessary to stop IMAIL or one of the other executables as quickly as possible, for example, detection of a power failure at the network server. Whenever checking for CTRL-C, CTRL-Break or ESC from the keyboard, IMAIL also checks for the semaphore file IMAIL.BRK in the semaphore directory or, of no semahore directory is defined, in its home directory. If this file is found, IMAIL behaves as if the user has pressed CTRL-C. While talking of semaphores: All IMAIL executables use and create 'busy' semaphores, IMAIL.BSY and IMAIL.LCK. If IMAIL.BSY exists at the program startup, the executable will check if the file is older than eight hours or younger that one hour from the current system time. If not, it will abort. Otherwise, it will touch the semaphore and continue just as if the semaphore would not exist. The additional hour into the future should prevent problems with - 8 - 5. GENERAL SECTION =========================================================================== different times within a network, but still allows to recognize outdated flag files. The whole thing should prevent more than one executeable running at the same time and adds reasonable security against remaining flags in case of a sudden system crash. Abort due to an existing flag (locked configuration) will be logged using IMAIL.ERR in the IMAIL home directory. The EXE's will also report errorlevel 237 in this case. When the exes created the flag file themself, they will delete it when they terminate (added to the exit code). If you abort the exes in a way that they cannot perform their normal exit tasks (eg. boot) you have to remove the file yourself. An abort with ESC or CTRL-C does not harm the exit code. IMAIL.LCK is a semaphore mainly for IMSETUP. It prevents IMSETUP from allowing any changes while another executable is running, except IMCOMP. 5.4. Environment Variables 5.4.1. IMAIL An environment variable MUST be set pointing to the directory containing IMAIL's configuration files. This is required! The variable may be set by including an instruction such as the following in your AUTOEXEC.BAT file: SET IMAIL=C:\IMAIL Please note that IMAIL and its companion programs do not make use of any other program's configuration files. 5.4.2. POINTNET If you are a "boss" node and have points running software which cannot handle 4D addressing, you will have assigned them a point net (sometimes called a fakenet) address. You should inform IMAIL of this point net by setting the POINTNET environment variable, so that TOSS and SCAN can remove addresses containing the point net from the SEEN-BYs in echo mail messages. For example, if you were using a point net of 31339, you would set the POINTNET variable with: SET POINTNET=31339 5.4. ENVIRONMENT VARIABLES - 9 - =========================================================================== 5.4.3. TASK This environment variable is needed in a FrontDoor or Intermail network/multitasking environment as it is used for producing the FrontDoor/Intermail CRC semaphore. It should be a unique task number, identifying the IMAIL task and differentuating it from the mailer tasks. SET TASK=5 The variable is used by IMAIL and the mailer to determine which programs are running in a multitasking/network environment. Each task or computer generates an identifying semaphore file in the common semaphore directory that is used to indicate file sharing. If you use the same variable on different computers or tasks, you will DEFINITELY experience problems. 5.4.4. TZ Here's another bit of making IMAIL run everywhere in the world. With the TZ (timezone) - variable, you are able to "tell" IMAIL the difference between UTC (GMT) - time to your local time. UTC (Universal Time Coordinated) is the "standard" time at Greenwich (GMT = Greenwich Mean Time). The army folx use UTC not avoid tackling with daylight saving or similar problems. In FidoNet and compatible nets, it is used maily for the Via-lines. IMAIL also uses it to determine when to execute the midnight maintenance (more on Via-Lines and midnight maintenance a little later on). This variable is also used by a range of other programs, such as FrontDoor or the mindboggingly versatile ITRACK by Frank Prade. If you do NOT set TZ, IMAIL uses the local time. Here are a few examples of how TZ can be set. Local time Time for IMAIL SET TZ=CET-2 14:10 12:10 (valid for most of Europe in summer) SET TZ=GMT+2 14:10 16:10 (somewhere in the Atlantic) SET TZ=GMT 14:10 14:10 (Greenwich's just around the corner) SET TZ=EST+5 14:10 19:10 (backing up in russia...) This should be enough for a start, now let's begin with 'business', the installation of IMAIL... 6. IMSETUP The program IMSETUP is used to configure the various options used by IMAIL. In this chapter, each option will be examined in detail. If any of the options are not clear, or their meaning and use is "obscure", you can generally leave them in their default setting. You can, however, try to figure out what they mean using the context-sensitive help (press F1) or read this doc... You can get help in any of the IMAIL support echos, or by sending net mail to the author or to the support sites listed at the end of this documentation. IMSETUP can be given one or more command line options, selected from the following: /M Force 'mono' color set /C Force 'color' color set /D Force direct screen writes /S Force CGA snow elimination Naturally, /D and /S have exactly opposite effects, so it makes no sense to use them together. Note: Should you wish IMSETUP to create and/or look for the configuration files in a directory which is different from the one in which you ran it, set the IMAIL environment variable to point to this directory. Otherwise, IMSETUP will look for its configuration files in the current working directory, whatever that happens to be. 6.1. Keymapping, general usage und charset The usage of IMSETUP has been standardized so that you" find it easy and user-friendly to use and access to all functions. That's what IMAIL stands for: semi-intuitiveness... 6.1.1. The most important key: F1 Even experienced users of IMAIL will appreciate the implementation of an online help system. Conforming to other programs, it is invoked with the F1-function key. In most cases, the information given there will be the same as in this documentation (hopefully!). - some other notes IMSETUP's managers (i.e. Area-, Node-, Group- and Forward link manager) are divided into two modi operani: An EDIT- and a BROWSE mode. In BROWSE mode, IMSETUP simply displays the contents of the configuration database, sometimes even in tabular form. You can move around and select the entry you want to edit using the cursor keys. Pressing <Enter>, you change to the EDIT mode. Except for the Area- and Node manager, a little window will pop up, displaying the information in a more specific form. 6.1. KEYMAPPING, GENERAL USAGE UND CHARSET - 11 - =========================================================================== 6.1.2. Keys in the BROWSE mode In the BROWSE mode, you have only one dimension of moving, either up/down or next/previous entry. Therefore, the cursor keys <Left> and <Up> result in the same action, <Right> and <Down> likewise. <Home> will move you to the first entry, <End> to the last. In the Area-, Node- and Forward Link manager, you can create a new record by pressing <Ins>. Having finished editing, the new record will be sorted into the order of the manager: alphabetically by areatag in the area manager, ascending by node number in the node manager. Deleting an item or record is almost es easy: Press <Del>. IMSETUP will kindly ask for your confirmation. And if you want to change an entry, press <Enter> and thus change to the EDIT mode. The Area- and Node manager have some special key assignments for the browse mode, see there. (Chapter 6.4., page 31 and chapter 6.5., page 43. 6.1.3. Keys in the EDIT mode Having entered the EDIT mode (this is often indicated by the word 'EDIT' in the upper left corner of the display window), you can move around with the cursor keys. In the Area and Node manager, you can even move horizontally. Jump to the first (upper left) entry by pressing <Home> and to the last (lower right) using <End>. If you want to change an entry, press <Enter>. It depends on the type of field which changes can be done. If you notice that you made a mistake, abort the changes with <Esc>. This is a drawback, too, for one is used to end or close windows using <Esc>. IMSETUP, however, urges you to press <F10> if you want to close the window AND SAVE. - Changing toggle fields (Y/N) The most easy kind of configuration itemd is the switch. IMSETUP uses switches in a Yes/No manner. Press <Enter> or <Space> to toggle a switch. - selecting groups The group selection window, also dubbed 'group manager' is a special kind of Yes/No-Switchboard. If you are to select one group (i.e. for the assignment of an area to a group), just move to the desired group by either using the cursor keys or entering the group number directly. Then press <Enter> to confirm your choice. There is also a flavour of group selection that allows the tagging of more areas (i.e. in the global functions). There, you may tag a group using <Enter> or <Space>. You can as well select all groups pressing <Ins> or deselect all groups with <Del>. Move around with the cursor keys or type the group number directly. - 12 - 6. IMSETUP =========================================================================== - using selection boxes The second type of configuration item are selection boxes. They are used to select out of a limited number of possible choices. If you press <Enter> on such a field (e.g. the Area Type), a little box will open with a list. Choose one using the cursor keys and <Enter>. Leave the window and the field untouched by pressing <Esc>. - using the file selector box When you have to specify a filename (i.e. when entering the rule filename), IMAIL supports you with a file selector box. Use it by hitting - the cursor keys (incl. <page up/down> ) - the first letter of the desired file - <Enter> to make a choice - <Esc> to abort and make no change. You can leave or render the field empty by selecting --SET EMPTY--. If you want to enter a name not displayed (i.e. because you haven't created it yet), select -EDIT MANUAL- to edit the field manually. NOTE: THE FILE SPECIFIED HAS TO BE IN THE DIRECTORY THE FILE SELECTOR BOX SHOWED (THE RULE FILE DIRECTORY OR THE IMAIL HOME DIRECTORY). - changing text fields Text fields are often used for descriptive purposes. Pressing <Enter> on such a field enables a small line editor. When editing a text field, the following editing keys can be used: Cursor left/right okok, easy, move the cursor. Ctrl-left / Ctrl-right move one word to the left/right. Home jump to the beginning of the field. End jump to the end of the field/entered words. Ctrl-T delete the word right to the cursor. Ctrl-Backspace delete the word left to the cursor. Ctrl-R reset the field to the original content. Ctrl-U, Ctrl-Y delete up to the end of the field. Del delete the character "under" the cursor. Ins toggle the insert mode. 6.1.4. The characterset To ensure IMAILs good usage in other countries and continents, IMAIL has been rendered totally 8-bit. That means that you can use any characters and keys except from control keys (that is everything below ASCII 32 (0x20) and the ASCII-key 127 (0x7F)). Because of the arealink commands and wildcards, the following characters are NOT allowed in the areatag: Other characters: '*', '?', '[', ']' and also control chars ( below 0x20 and 0x7F); First character: as above and '-', '+', '&', '~', '#', '%' and '=' 6.1. KEYMAPPING, GENERAL USAGE UND CHARSET - 13 - =========================================================================== Ok, enuf said, let's begin! 6.2. General configuration This options leads to another menu which allows various system- wide parameters to be set. Please read this section carefully! 6.2.1. System Addresses The "System Addresses" menu allows you to define up to 49 network addresses. The first address is known as your primary address. It should be the same as the one defined as your primary in your mailer and/or BBS program. The other addresses given are your system's AKAs (or aliases). Addresses should be given in the form: zone:net/node.point Addresses may be in different zones, and even in different domains (or networks). At least the primary address must be specified. When IMSETUP detects that you made changes to the list of system addresses, the area database, the group database and the domain information will be corrected automatically, but don't forget to check it afterwards. 6.2.2. Domain manager In this menu the domain(s) to which you belong are specified. The word "domain" is used to distinguish between different amateur networks such as SIGnet and FidoNet. Here, you should indicate the domains of which you are a part, the zones belonging to these domains, your AKAs in this domain, and the outbound directory for each domain. You should also specify those domains to which you do not belong, but with which you exchange mail. Up to 50 entries are possible, since there's a maximum of 50 mail addresses in IMAIL. IMAIL uses this information for MSGID kludges when generating net mail messages. More importantly, outbound mail for a specific domain will be placed in the directory you specify here. If you are in doubt of which zone you belong to, or which domain, please contact your nearest Coordinator or Host. Select an entry (select an empty line if you want to add a new one or simply press <Ins>) and press <Enter> to edit it. A small window will pop up which shows the information en detail. You can delete an entry by pressing <Del>. Please bear in mind that when you delete a domain, the index in the node manager will NOT be updated, however and you have to change that yourself! - Domain name Specify the name of the domain. No universally accepted standard seems - 14 - 6. IMSETUP =========================================================================== to exist, but some examples are: FidoNet for zone 1 to 6, IntlNet for zone 56 through 58, and so on. The name must not contain the character '@'; everything before that character and itself will be deleted when you save your configuration. - AKA List When selecting this configuration item, a little sub-window will show the aka's belonging to this domain. Togglemark an address with { Space} or <Enter>. Leave the window with Esc or save it with F10. - Zone List This item shows the zones this domain occupies, separated by commas. Editing this, you enter a window in which you can specify all the zones which belong to this domain. For example, for IntlNet, these would be 56, 57, 58 and 59, FidoNet occupies the zones 1 to 6. - Outbound Directory If you belong to more than one domain, it might be wise to keep the outbound mail for each domain separate. In this case, specify each directory here. In Binkley mode, mail for points will be place "under" these directories. In FrontDoor or Intermail mode, IMSETUP will check the existance of this directory. If this field is left empty, IMAIL will default to the directory specified as Outbound Net Files (see below). 6.2.3. suBdirectories In this menu, specify the paths to the various files IMAIL needs to use during execution. Most of the fields are required and you should NOT use the same physical directories for more than one entry. It's also NOT useful if other programs use the IMAIL temporary directories (especially the FrontDoor packet directory must not be used by IMAIL). When specifying subdirectories, you may omit the trailing backslash. - Hudson message base Specify the path to the Hudson format message base files. These message base files are searched for outgoing messages when you run the IMAIL SCAN function. If you are not using a Hudson message base, this field may be left empty. - Net Mail Messages The path to where your mailer stores its net mail message (*.MSG) files. IMAIL will use this when searching for existing file attaches, when creating new file attach messages, or when it generates outgoing net mail of its own. --- THIS FIELD IS REQUIRED. --- - Secure inbound files This is where your mailer stores inbound compressed mail files and packets from a password protected session. IMAIL will look here when you run the TOSS function. NOTE: PLEASE DO NOT run IMAIL from this directory!} --- THIS FIELD IS REQUIRED. --- 6.2. GENERAL CONFIGURATION - 15 - =========================================================================== - Unsecure inbound files If your mailer knows a seperate inbound directory for unprotected sessions, you can specify it here. IMAIL only accepts uncompressed packets from this directory and any echomail in such packets is automatically moved into the badmail area. - Local inbound If you use other programs that create PKTs, for example a filetosser for it's newfile-announcements, you can use the subdirectory specified here. IMAIL will NOT check the PKT origin address, nor the PKT destination address, but will simply process the PKT, not even caring for security! DO NOT USE THIS DIRECTORY AS INBOUND FOR YOUR MAILER! IF YOU ARE UNSURE HOW TO USE THIS, LEAVE THIS ENTRY EMPTY. - Temp inbound packets This directory is used by IMAIL TOSS to store packets as they are extracted from ARCmail files, and before they are processed. --- THIS FIELD IS REQUIRED. --- - Outbound net files This subdirectory is where your mailer normally looks for outbound compressed files. These files may be generated by all of IMAIL's functions. This CANNOT be the same subdirectory as the Inbound Net Files directory, otherwise IMAIL will process the files as if they were FOR your system. Note that if you are running in a Binkley environment, this will be the subdirectory in which outgoing mail for your PRIMARY zone will be placed. Mail addressed to other zones will be placed in other subdirectories, having the same root name as the one specified in this field, but with a 3-digit hexadecimal extension (the zone of the destination address). For more details, please refer to the Binkley documentation. This subdirectory will be used whenever you do not specify an outgoing subdirectory in the Domains menu (see above). --- THIS FIELD IS REQUIRED. --- - Temp outbound packets This is the directory in which IMAIL and IMPACK will build outbound packets prior to compression into ARCmail files. This directory must NOT be the same as your mailers temporary packet directory, nor may it be the same as IMAIL's Temporary Inbound Packet directory. If omitted, IMAIL will default to the Outbound Net Files directory. --- THIS FIELD IS REQUIRED. --- - Temp dupe data base IMAIL creates two files that comprise its dupe database: IMAIL.DP and IMAIL.DPI. These are stored in IMAILs home directory. When TOSSing, IMAIL loads the index into memory and accesses the other file quite frequently. If you run IMAIL in a network environment, TOSSing will be slowed down due to this. - 16 - 6. IMSETUP =========================================================================== Specifying a RAM-disk or a local harddisk here can speed up things TREMENDOUSLY. IMAIL will copy the dupe database into this directory before TOSSing and move it back afterwards. If the copy at the beginning fails or this field is left empty, IMAIL will use the files in its home directory. - Rules path If you want to use the rules support of IMAIL, please specify here the directory that conains your rules files. - Semaphore directory This directory is used to store and create all semaphores. Also the mailer rescan semaphore as defined below will be created in this directory. For FrontDoor 2.20c.mL, this is the semaphore directory as defined in the FrontDoor setup, for FrontDoor 2.11 this is the directory where the FD environment variable points to. - Netmail semaphore file If IMAIL should tell your mailer that netmails have been created or updated, you should specify the name of the necessary semaphore file here. IMAIL will create it in the semaphore directory if necessary. For FrontDoor this is FDRESCAN.NOW - IMAIL log file name If you wish IMAIL to log its activity to file, you may specify the name of the log file here. If a path is not specified, the file will be written to the current working directory. Here (and ONLY here!), you can also use an environment variable in the name of the file. (e.g. G:\LOG\IMA%task%.LOG) - Echotoss log file name Here you define the name of the echotoss log file which is used by IMAIL to determine Jam, Squish and *.MSG areas where new messages have been entered. Your editor and your bbs should use the same file name for this file. IMAIL will prevent you from entering the same name as in "Log File Name", because this here is something <completely> different! - Path to ECHOMAIL.JAM When having entered mails in Jam areas, many editors and BBSes create a file called ECHOMAIL.JAM. There, the areas with newly entered mails are specified for SCAN. (Kinda the same as 'Echotoss log file name') Enter the path to this file here. (Could well be the home directory of your bbs program.) If SCAN encounteres somehow obscure information in the ECHOMAIL.JAM file, it forces a complete rescan of this single area. This means if for example the echomail.jam file tells that message 7 should be exported but there is either no message 7 or message 7 is not local and not unsent, the whole area is scanned for unsent messages. - Path to user base In the old days, the user base of a BBS was always stored in the same directory as the Hudson mailbase. This is also where IMAIL will search 6.2. GENERAL CONFIGURATION - 17 - =========================================================================== for the user files if you leave this field empty. But if you run a BBS that uses a different directory, you may enter it here. - Areas Action Log In this file, IMAIL stores the following actions: Autoadding of an area ADD Area Request REQUEST Forward link request FWSREQ Unlink request UNLINK Deletion of a dead area DEAD Remote deletion of an area REMOVE Relink of an unlinked area RELINK Tried relinking a dead echo DEADLINK Specify the name of the file and its path. Here is a small batch which allows you to post a notification whenever a new echo has been arrived. %IMAIL% is the IMAIL environment variable. NEWAREAS.LOG is the name as entered in IMSETUP for the areas action areas log. AREA.NEW is used to store the file after posting it -----------[ BEGIN ]---------- REM REM POST A MESSAGE CONTAINING NEW AREA'S ONCE... REM IF NOT EXIST %IMAIL%\NEWAREAS.LOG GOTO NONEWMAINT %IMAIL%\IMTHINGS POST /F%IMAIL%\NEWAREAS.LOG /ALOCAL.SYS /WSysop /SNew\_areas COPY %IMAIL%\AREA.NEW+%IMAIL%\NEWAREAS.LOG %IMAIL%\AREA.NEW DEL %IMAIL%\NEWAREAS.LOG :NONEWMAINT REM -----------[ END ]---------- 6.2.4. Log options If you have specified that IMAIL should create a log file, here you may indicate how much information you wish to be written to the log file. If you set the "DEBUG: All of the above"-switch to 'Y'es, IMAIL will simply log everything, ignoring the switches above. - ! Fatal errors Every error that causes IMAIL to abort or is nearly as severe is logged behind a '!'. Examples are low memory or user break. This errors also lead to an ERRORLEVEL (see chapter 14.8., page 105.) - Other errors If IMAIL encounteres a less severe error, it will log this under "Other errors". Locked or inaccessible message base files are "other errors". If IMCOMP may not compress PKTs because of a running - 18 - 6. IMSETUP =========================================================================== session with this system, this will also be logged with a '?'. - Accounting info The dollar sign will preceed the statistical information IMAIL gives: Messages per second in and out, deleted messages, total size of inbound and outbound messages and overall runtime. - Sent/Rcvd files When this switch is set to 'Y', IMAIL logs the names of inbound and outbound PKTs and their compressed/uncompressed size along with their addressees and origin. This category also includes creating or updating of file attaches. - Brief messages These short notes are mostly created by IMALNK when creating or deleting an area, linking or unlinking a node. If an area has no defined PATH, IMAIL will log this in a brief message. - Trivial messages When enabled, IMAIL will log also less important crap like the amount of free diskspace, the allocated internal buffer size and other things I (author of the doc) did not find yet... - Transaction info Here you can switch on the logentries which show traffic information like number of msgs, number of dupes, etc. - Password errors This one is quite simple for a change. IMAIL will simply log when it encounteres a PKT with a password, but has no PKT password defined for this node. - Security/Dupe info If a message is considered DUPE or BAD, IMAIL will log the number of the message during this run of TOSS, the areatag and the string "Duplicate" or "Security violation". If you check your DUPES and BADMAIL folders regularly and tend to ignore your logfile, you may well turn off this option. - Spawning info If an external program (e.g. a compression program) exits with an errorlevel, IMAIL logs this errorlevel and the complete commandline. - DEBUG: All of the above BE CAREFUL WITH THIS AND ENABLE IT ONLY WHEN YOU REALLY, REALLY MEAN IT! When set to 'Y', IMAIL will not only log everything of the above, but also the number of tossed mails in this run yet, the areatag of the current message and the type of message base for EVERY SINGLE mail! I hope you can understand why I warned you above... 6.2. GENERAL CONFIGURATION - 19 - =========================================================================== 6.2.5. aRealink options The options in this menu regard IMAIL's area manager, called AREALINK. This function will do for IMAIL what AreaFix does for other systems. Your downlinks will be able to request that new areas be sent to them, or that areas no longer be sent. Besides, they may request information on which echos are available to them, and have a list of the echos they are currently receiving. AreaLink can also request areas not available on your system from your uplinks, thus further automating your system. For information on how AreaLink is used, see chapter 10., page 63. - Keep AreaLink Reply If you enable this option (toggle it to 'Y'), then IMAIL will not mark its outgoing messages as KILL/SENT. In other words, the message will remain in your net mail directory for you to see it even after it has been sent out. Note that this is valid only for the messages _generated_ by AreaLink, but not for those it has _processed_. It is the corresponding setting to 'Keep Arealink Request'. - Keep AreaLink Request There are three possible settings for this switch: If you choose ALL, Arealink will not delete incoming requests, they will remain in your net mail directory for you to read them. WITH MSG means that Arealink will leave messages for you that contain a %MSG or some text after a tagline. NONE will cause Arealink to delete all arealink requests. Note that this is valid only for the messages _processed_ by AreaLink, but not for those it has _created_. This is the corresponding setting to 'Keep Arealink Reply'. - Password Expiration Days This allows you to specify that your downlinks should change their AreaLink password after a specified number of days. If set to 0, this feature is disabled. AreaLink will still allow a system to use AreaLink if the deadline has passed, but it will add a warning saying that the password should be changed. A sysop may change their password automatically by using the %PWD meta-command; see chapter 10.3., page 66 for more information on this. - Forward every request If this field is set to yes, IMAIL forwards area requests where the area cannot be found in one of the lists given in the Forward Link Request Manager to the first uplink defined in this manager. - Unlink Requests Here you can specify whether AreaLink should check areas (whenever one user requests to unlink from an echo or pause all echos and at least once per day after midnight during the statistic update) whether you have areas with only one system in the list of linked systems. If this single system is also listed in the forward link requests data section, then IMAIL marks this area unlinked and sends an unlink request to this system. - 20 - 6. IMSETUP =========================================================================== You can specify whether this function should not to be run (NONE), only affect PASSTHROUGH echos or ALL echos. Moreover, you can exclude single areas or groups from this function in the Area or Group Manager by settings the field "Auto Maint" to 'N'. Using this feature you can prevent echos from being tossed into the NUL device and consequently reducing the amount of mail. 6.2.6. Unlinked Hudson to passth This switch allows (when Unlink Requests is set to 'All') to set Hudson areas automatically to passthrough when Hudson areas area unlinked to free the associated board number. - AreaLink Help Text In this field you may specify the name of a text file to send if a user requests help with AreaLink (see chapter 10.3., page 66). If no name is specified or the specified file does not exist, AreaLink will respond with a default helptext. Choose the file containing the help text from a file selector box showing the files in the IMAIL home directory or enter one manually. You can only specify files in the IMAIL directory, sorry. - Remote Maint Help Text In this field you may specify the name of a text file to send if a user requests help with AreaLink (see chapter 10.5., page 68) if this users has remote maintenance rights on your system. If no name is specified, then AreaLink will take the file specified under "AreaLink Help Text". Again choose one from the file selector box or enter manually. The file has to be in the IMAIL home directory. - Allow +* requests This switch prevents somewhat dumb downlinks from requesting +* and thus causing your system to relink lots of unlinked areas. Simply switch to 'N' and your downlinks will have to specify clearly what they want. - Ignore unknown systems If this switch is set to Yes, IMALNK simply ignores ALNK requests from systems not defined in the node manager, setting the mail 'rcvd' and making a logentry. Otherwise it will respond to the requesting system that it has no allowance to do so. - Sort area lists by Arealink normally sorts the link, query and unlinked reports by areatag. When you toggle this switch, Arealink will sort them by group first and then by areatag. - Area-Ignorelist If you want certain echos not to be requested or auto-added at all, create a file which contains the echotags of this echos (one per line) and specify its name here. This can prevent the periodic recreation of previously deleted areas, since downlinks seem to have elephant's memories.... When messages in an ignorelist-area are moved to BADMAIL, the reason for this will be inserted into the messages. 6.2. GENERAL CONFIGURATION - 21 - =========================================================================== 6.2.7. Product codes This small and apparently insignificant menu is really very important. It allows you to indicate programs which produce Type 2+ information in the packet header. (For more information about this and the Capability Word, see chapter 13.2., page 92) With this information, IMAIL TOSS will know how to correctly process incoming mail. If it finds a packet with no capability word, it will scan the list of product codes defined in this menu to see if the packet really contains zone and point information. If the packet was produced by one of the programs whose code is listed here, then it will treat the packet as it is fully Type 2+. Otherwise it will be treated as "Stone Age". IMAIL now also can handle Type 2.2 PKT headers as defined in FSC-0045. Note that the product codes must be entered in hexadecimal. 6.2.8. no Import In this screen, you specify the names of persons (or programs) which IMTHINGS IMPORT should ignore. For example, if you wish messages addressed to AreaLink not to be imported into your net mail area, you would specify AREALINK here (case is not significant). Similarly, if you do not want net mail addressed to you to be imported, specify your name in this menu. If you specify a '*' wildcard at the end of a name, anything starting with that name will not be imported. See chapter 11.1., page 71 for information on IMTHINGS IMPORT. 6.2.9. sysop Names In this screen, you can specify up to 20 names IMAIL TOSS should search for with the PERSMAIL function. When mail for one of these names is found in incoming mail, it is either copied into a separate area, a netmail to the sysop is created, the fact is only logged or it will be ignored altogether. see 'Other Parameters'-'Check for personal mail',6.2., page 25. NOTE: SINCE _every_ INCOMING MESSAGE IS CHECKED AGAINST _every_ SINGLE NAME HEREIN, THIS COULD SLOW DOWN TOSS CONSIDERABLY! 6.2.10. dUpe settings - Number of Dupe Records This field indicates how many dupe records IMAIL will save in the file IMAIL.DP for dupe checking. You can enter a value between 0 and 999.999, but IMAIL will slow down noticeably if set higher than 130.000. If the number is set to zero, no dupe checking will be performed; this will make a bit IMAIL faster, but certainly less secure. - Dupe Ring Handling This option tells IMAIL how to handle echo mail if one of the - 22 - 6. IMSETUP =========================================================================== downlinks is already listed in the SEEN-BYs of this mail. You have four options: None Disable this check. Copy Copy the message to the dupe area. Kill Do not export to this downlink. Kill&Copy Do not export to this downlink and copy the message to the dupe area. For further information on echo mail topology and related problems see the section about echo mail in chapter 12., page 82. - Circular Path Detection Here you can specify whether IMAIL should check also the PATH lines of each message for circular paths. IMAIL then searches the PATH line for your origin address in this echo. If it finds your origin address, it also checks whether the system before and after your address can be found in the export list of this echo. If this is the case, a circular path has been detected. You have the following four options: None Disable this check. Copy Copy the message to the dupe area. Kill Do not export to this downlink. Kill&Copy Do not export to this downlink and copy the message to the dupe area. For further information on echo mail topology and related problems see chapter 12., page 82. 6.2.11. nodeMgr defaults IMAIL offers the possibility to control the size of ARCmail-bundles and their contents individually for each link. The following five options control the defaults for the Node Manager Records. For the first three, it is advisable to have a look at the introduction, chapter 14.3., page 96. - Max Packet Size With this option, you can specify the maximum size of the packet files (*.PKT) that IMAIL will create by default. Use this if your links are short on disk space. The number should indicate a size in kilobytes (maximum value: 9999 kB). If a zero (0) is specified, no limit will be imposed. - Max Arcmail Size Setting this to a non-zero value tells IMCOMP not to add further PKTs to a compressed ARCmail bundle if its size is bigger than specified (in kB). IMCOMP will then create a new bundle. You can limit the size of the ARCmail bundles with this feature, therefore reducing the time which is needed to resend the bundle if a session was interrupted. Maximum value: 65000 kB. - Nr. of PKTs to pack per call Together with 'Max. Arcmail Size', this field controls the size of the outgoing ARCmail bundles. When set to 0, IMCOMP will add ALL pending PKTs to an existing ARCmail bundle or creating one single bundle. The size of the newly created bundle may well be extremely higher than the one specified in 'Max Arcmail Size', because the check 6.2. GENERAL CONFIGURATION - 23 - =========================================================================== is only performed ONCE before packing. Setting this field to a non-zero value (max. 99), IMCOMP will only process this number of PKTs per call, then again check the size of the created ARCmail-bundle. Having found the bundle to be smaller than 'Max Arcmail Size', IMCOMP will add another set of PKTs. - Message status This switch controls the default status of messages from IMALNK IMTHINGS have created to your links. It may be Normal No status. Hold Hold message for pick up. Crash Send message 'crash'. Immediate Set the 'Immediate' flag. Direct Send message directly. Hold Direct The system itself has to pick up the mail. Crash Direct Works around sloppy routing... :-) Immediate Direct kinda foolproof method of getting rid of mail. - Attach status With this switch, you control the default status of the attaches for the ARCmail-bundes to your links. It may be Normal No status. Hold Hold message for pick up. Crash Send message 'crash'. Immediate Set the 'Immediate' flag. Direct Send message directly. Hold Direct The system itself has to pickup the arcmail. Crash Direct works around bugs in routing tables... :-) Immediate Direct you wanna be sure, eh? 6.2.12. sPace settings - Max Message Size Here you can specify the maximum message size of messages generated by IMAIL. The value entered here should be around 10-15 kB. If it is too small, IMAIL will produce lots of mails and if it is too high, some mail processors will get trouble with these mails. This is of course a way of convincing downlinks to switch to IMAIL, but it is not the kindest way possible. ;-) Currently this value is only used by IMALNK and by IMTHINGS POST. - Single Bundle Extract When enabled, IMAIL will extract the packets in a single compressed file before processing, but it will extract ALL the packets. Use this only when diskspace is really tight, because it will really slow down the tossing process. TOSS has to stop its work and call the decompressing programm for every ARCmail bundle. - Max. nr. of files/directory A major problem of DOS is that it becomes slower with the number of files per directory. In a directory with more than 1000 files, the deletion of a single file can take up to 3 seconds! To work around this behaviour, you can specify a maximum number of files IMAIL should create per directory. You can enter values 0 and 50-999. With 0, the number of files will be ignored. Below 50, this feature is useless and above 999, it will make no difference... :-) - 24 - 6. IMSETUP =========================================================================== This only affects the (auto-)creation of Squish or Jam Areas by IMAIL or IMALNK and the path/filename suggestion in the Area Manager. IMAIL will check the number of files in the directory the new echo should be created in according to the group manager. If the number of existing files exceeds the value given here, IMAIL will create a new directory with the same name stem and an ascending extension. Example: If the new echo should be created in ...\FIDO and this directory is 'full', a new directory ...\FIDO.001 will be created. If it already exists and also is 'full', ...\FIDO.002 will be tried, until a directory is found which has less than the specified number of files. - Compress after each Packet This option lets IMAIL calling the compression function whenever a packet has been processed and there is outgoing mail waiting in the Temp Outbound. Also, the option 'Max ARCmail size' will be executed more precisely. But there is another side to the coin: It takes up a great deal of time. Really <lots> of time. A <DISTURBING} lot of time. So use it only on systems where disk space is tight, because it will slow down the execution of the program noticeably. - Diskspace before Unpack This is a kind of emergency break. If you received more mail than your remaining harddisk space can accomodate when unpacked, you can prevent the TOSS operation. This prevents loss of mail due to harddisk overflow. Specify the size in MB, disable the test by entering zero. See also chapter 14.3., page 97. - Diskspace before Toss Together with the previous setting, you can handle tight diskspace intelligently and automatically. After unpacking the received bundles, TOSS checks the diskspace against this value before actually processing the mail. If you want to disable this check, set this field to zero. See also chapter 14.3., page 97. - Diskspace before Compress This field controls how much diskspace TOSS leaves before calling IMCOMP to compress the mail bundles. This value is directly dependant on the value entered in 'Max Arcmail Size'. You should always enter values higher than 'Max Arcmail Size' (best is double that value), so IMCOMP has enough space to save the compressed ARCmail-bundle. See also chapter 14.3., page 97. - Use IMCOMP if less disk-space When IMAIL or IMPACK run into problems with diskspace (even with the values that control diskspace), you can specify 'Y' here, so IMCOMP will be called immediately to compress the waiting PKTs in order to gain diskspace. 6.2. GENERAL CONFIGURATION - 25 - =========================================================================== When this switch is set to 'N', or the call of IMCOMP did not release enough diskspace, IMAIL and IMPACK will abort immediately. This switch is especially useful if your harddisk for 'Temp outbound Packets' is different from your 'Outbound Net Files' -directory. - Stop TOSS after x msgs - Stop TOSS after x netmails These two values are a kind of emergency break for IMAIL and are intended to protect against mailbombs. When TOSSing, IMAIL will count the overall number of netmails processed in all PKTs during this call and the number of msgs in this PKT. If the latter number is exceeded, the PKT is considered a mailbomb. The PKT will be renamed and IMAIL will abort. If the overall number of mails (both echomail and netmail) exceeds the first value, IMAIL will create the semaphore IMAIL.NRM and abort. 6.2.13. Toss settings - Handle PKTs not for us This option tells IMAIL how to handle PKTs which are not for one of "our" akas. You have the following three options: - process these PKTs as if they were addressed to you, simply TOSS them. - move these PKTs to the Temporary Packet Outbound and compress them for their real destination FORWARD. - move them back to the inbound and RENAME them to *.BAD. NOTE THAT IF THIS OPTION IS NOT SET TO FORWARD, IT WILL BECOME IMPOSSIBLE TO ROUTE ECHO MAIL PACKETS, BECAUSE THEY WILL BE PROCESSED BY IMAIL, AND THE MESSAGES WILL PROBABLY END UP IN YOUR BAD MESSAGE BOARD OR WILL BE FORGOTTEN IN YOUR INBOUND... - Check for personal mail While tossing, IMAIL has the capability to check whether there are new messages for the user defined as sysop. You have four options: None Disable this feature. Log Write a log entry if a message was found. Netmail Create a netmail containing the headers of the new messages. Copy Copy each new message to a special area. The last option requires the definition of the special area PERSMAIL in the Area Manager. - Delete empty netmails (TOSS) While extracting netmails from inbound PKTs, IMAIL TOSS checks whether they are empty netmails and deletes them if this option is set to Yes. - Use Crc filenames (Autocreate) This switch determines the way IMAIL assignes a name for a new message base. If you specify "N", IMAIL uses the echotag to create a new message base. The areatag "SYSOPS.GER" may result in an filename-stem like <path>\SYSOPSG.xxx. Setting this switch to "Y", IMAIL will calculate a CRC-32-sum over the areatag and will then use this somehow cryptic figure as filename or pathname (in case - 26 - 6. IMSETUP =========================================================================== of *.MSG). 6.2.14. System settings - Sysop Name This field is required, as it is used by IMAIL for the generation of automatic messages and so on. IMAIL also uses it to validate your registration key. Your ID-card will help you filling out this field, but check it with a mirror... - Environment This field tells IMAIL about the Mailer software you use. If you select FRONTDOOR or INTERMAIL, IMAIL will use file attach messages. This method can be used for other mailers which use file attach messages rather than "flow files" (for example T-Mail in non-binkley-mode). Please note that is important that you distinguish between FrontDoor and Intermail, because these mailers differ in the way they are indicating that they have a session with a system. By selecting BINKLEY (5D), IMAIL will create "flow files" in the outbound directories you defined in the domain manager, according to the domain. The files contain lists of files which the mailer should send. In an MCMAIL (4D) environment, IMAIL will ignore the directories specified in the domain manager. The ARCmail bundles will always be stored in the directory specified in "Outbound Net Files". Use this also for Portals of Power or T-Mail in binkley mode. This setting will also controls the style of the IMAIL log file and moreover the multitasking of IMAIL. - BBS software used When updating the user base while packing or sorting the message base, IMTHINGS needs to know which message base is used by your system or BBS software because Remote Access 2.xx or ProBoard 2.xx use different structures (but still the same file name). Select "Remote Access 2.xx" for this type of BBS software, "Other" for all others. - Swap Options Before calling any external programs, IMAIL and IMPACK will swap most of themselves out of memory, to leave room for the program called. Once the program has completed, IMAIL (or IMPACK) will be reloaded into memory and continue execution. EMS - Expanded Memory. If you specify EMS, IMAIL will try to allocate a certain number of EMS pages to try to swap itself into. If this fails, it will swap to disk. (Note: You will need a custom driver to access your hardware EMS or a memory manager to emulate it from XMS (such as EMM386.EXE or QEMM)). XMS - Extended memory. If you specify this option, IMAIL will try to swap to extended memory. If this fails, it will swap to disk. (Note: You will need a driver such as HIMEM.SYS in order for it to work.) EMS & XMS - Both. This indicates that IMAIL should try both EMS 6.2. GENERAL CONFIGURATION - 27 - =========================================================================== and XMS, in that order. If both fail, swapping to disk will occur. DISK. IMAIL will swap its overlay buffers to disk when needed. This is the default, and also the slowest of the options. - Setup Password You can optionally protect IMSETUP by defining a password here. This password has to be entered twice to avoid typos and can be up to 15 characters long. Then, the switch will flip to 'Y'. The characters of the password are displayed as '*'. If defined, IMSETUP will start up with the red logo and then prompting the user for the password. After that, IMSETUP will behave normally. If a wrong password is entered, IMSETUP does no lockup gismos, but gives another two tries, then simply aborts. To disable the password check, enter the password here again. NOTE: THE PASSWORD ONLY PROTECTS THE IMSETUP PROGRAM, THE CONFIGURATION FILES CAN ACCESSED VIA DOS, THOUGH. - Direct Screen Writing If set to Yes, IMAIL writes direct to the screen memory, otherwise the (slower) BIOS functions are used. Set this to 'N' if you experience problems or to eliminate CGA-"snow". - Multi-Tasking/Network If you are running in a multi-tasking or network environment (i.e. LAN), then set this to Yes. It will force IMAIL to make more checks for locked files; the IMAIL semaphore will only be created if this flag is enabled. In this case it is either necessary that SHARE.EXE is loaded or the network drivers directly support sharing and locking. - Close Graphic Window This option controls whether IMAIL performs the "dead-TV" effect at the end of its run. Just try and see... When you set it to 'Yes', the screen will be cleared, otherwise the screen will remain. - Quiet Packers With this, you can redirect the output of the compression programs to /dev/nul. You will only see the messages of IMCOMP itself, no more progress indicators or similar. - Before Toss This option was included to allow sysops to run a "mail mangler" on extracted packets before IMAIL processes them. It will be called once for every PKT IMAIL is bound to access. If you wish to use this feature, then specify the full path name of the executable program here, including arguments. If you need to give the name of the PKT file, then place a %P on the command line. For example: MY_PROG.EXE %P /ZAP The %P will expand to the name of the packet file. Note that the program called MUST NOT delete the packet file! If you specify a batch file as Before Toss command, IMAIL will automatically call the command processor by using the environment variable COMSPEC (or COMMAND.COM if COMSPEC is undefined). - 28 - 6. IMSETUP =========================================================================== - Before Toss II Unlike 'Before Toss', this program will only be executed ONCE after IMAIL has unpacked the mailbundles. It is designed for programs like PKTSORT, which are only called once before tossing. - Default Origin This is the Origin line which IMAIL will use if one or more of your echo areas have no Origin line defined. You can define an own Origin line for each area in the Area Manager. 6.2.15. Miscellaneous - ARCmail 0.6 Compatibility If this option is set, IMAIL will generate compressed mail bundles that conform to the ARCmail 0.6 naming standard when sending to systems marked in the node manager as "Stone Age", or to systems not listed in the node manager. Systems listed as "Type 2+" will have a special naming scheme. (See chapter 13.2., page 92 for information on the Capability Word). If this is set to "No", then IMAIL will always use its own internal method for the naming of outbound compressed files. When generating ARCmail for point addresses, IMAIL ALWAYS uses its own scheme. - Send Return Receipt If a net mail messages arrives with the "Request Return Receipt" flag set, IMAIL will automatically generate a net mail message to the originating system, stating that the message arrived. Note that the FLAGS RRQ kludge is not supported by IMAIL in the current version. Since the message attribute is defined, I decided to support it. - Use FTSC Product Names This options controls whether or not IMAIL TOSS will display product names when processing inbound packets of mail. If enabled, TOSS will show the name of the program used to create the PKT file; otherwise, it will simply show the program's product code. In order to use this option, you must have a file called FTSCPROD.??? available in the IMAIL home directory; if found, IMAIL will compile this file into IMAIL.PR (after which you may remove the FTSCPROD.??? file). If the file is not available for compilation, IMAIL will behave as if you had set this option to No. The newest version of the FTSC product code list is distributed by the FidoNet Standard Committee, it can be requested at many systems (FTSCPROD.A??). - Delete Squish/Msg/Jam-bases When automatically deleting Squish, *.Msg or Jam areas, IMAIL can also delete the message bases of these areas if you specify 'Yes'. This frees the harddrive of 'forgotten' areas. - Handle sent ARCmail Normally, when ARCmail has been sent by your mailer, the file is truncated (that is, its length is set to zero). This allows IMAIL to generate a new file name if it processes more outbound mail for the same system. If for any reason you want the mailer to delete the file 6.2. GENERAL CONFIGURATION - 29 - =========================================================================== instead of truncating it, set this option to 'D'. HOWEVER, IT IS NOT SUGGESTED THAT THIS BE DONE! USE THIS OPTION WITH CAUTION! - Kill Dead handling This field controls how to handle "dead" echos, i.e. echos that didn't carry mails for a defined amount of time. None The kill dead function will be disabled. Forward Only echos with a pending forward request will be deleted. All All echos will be processed. If you specify 'Forward' or 'All', you can except areas or groups from handling by setting the field 'Auto Maint' in the area/group manager to 'N'. - Deadlink days If a (forward) requested echo is dead for the specified days, IMAIL suspects the link to have failed. This situation (receiver has the echo linked, uplink doesn't) is called 'deadlink'. IMAIL then tries to reattach that echo by requesting it once more at all uplinks having this echo available in their forward lists. If you enter a zero, IMAIL will ignore a detected deadlink. NOTE: THIS CHECK WILL ONLY BE EXECUTED ONCE A DAY DURING THE MIDNIGHT MAINTENANCE. SEE ALSO CHAPTER 7.3., PAGE 58. - Add Via Lines Registered users of IMAIL may disable the insertion of a Via kludge in forwarded net mail by setting this option to None Via lines NOT added. Export Via lines added by IMPACK when pack-routing netmail, Import VIA lines added by IMAIL TOSS when netmail is found in inbound mail-bundles, Always Import and Export enabled (see above). 6.3. Archiver management 6.3.1. Compression Programs In this section, you may specify the programs, along with their parameters, to use in the creation of outbound compressed mail. You will also be prompted for a three-character short name for each program which is used by IMALNK (remote change of compression). When you run IMSETUP for the first time, it will show defaults for the following programs: ARC, Arj, LHarc, PKARC/PKPAK, PAK, PKZip, RAR, SQZ, UC2, ZOO. If you wish, you may add other programs of your own choice, but do not leave any entries empty. Instead, if you do not intend to use one (or more) of the predefined programs, replace it with one that you do use. All of the programs you intend to use must be present somewhere in the - 30 - 6. IMSETUP =========================================================================== DOS path, because IMSETUP does not allow the input of pathnames. The default parameters are listed in chapter 14.6., page 102 You will then select which of these programs to use for mail compression on a per-system basis, in the Node Export Manager (see section 6.2.). If IMAIL needs to compress mail for a system not listed, it will use the first of those given in this menu. 6.3.2. Decompression Programs IMAIL automatically recognizes compressed files created with the following programs: ARC, Arj, LHarc, PKARC/PKPAK, PAK, PKZip, RAR, SQZ, UC2, ZOO. In this menu, you may change the name and parameters which will be executed when compressed mail files are identified. The default parameters "preinstalled" in IMSETUP are listed in chapter 14.6., page 102. It is also possible to define a program which should be invoked if IMAIL is not able to determine the type of compression used to create an ARCmail file. If this entry is not defined, IMAIL will simply ignore the file. Be VERY careful when changing these items, for a mistake might produce very unexpected (and often unwanted) results. Certainly do NOT try to use one program instead of another. A compressed file identified as having been created by LHarc, for example, cannot be decompressed by ARC! (crazed idea of some dudes...) If possible, have _all_ of the decompression programs somewhere in the DOS path, unless you are absolutely certain that you will not be getting mail compressed by one or more of them (and who can be _absolutely_ sure of anything nowadays???). 6.4. Area Manager The Area Manager is one of the most important parts of the program, and also controls most of what IMAIL does. When you first run IMSETUP, no message areas are defined. You will see a screen with many different fields, all empty or set to certain default values. These fields will be explained in a moment, but first the editing keys. 6.4.1. Special BROWSE Keys Here are the special keys you can use while BROWSing through the area manager: - Shift-F1: available function keys Pressing Shift-F1 brings up a little red window with a summary of the function keys in BROWSE mode. - F2: Find Pressing F2 brings up a window in which you may specify an area name. If the area is found, it will be displayed. Wild cards may be used: 6.4. AREA MANAGER - 31 - =========================================================================== '*' expands to 0 or more characters, while '?' will match any single character. The record may then be edited by pressing Enter. Note that a wild card search is slower than one in which the full area name is specified (but sometimes typing the name can be slower than searching with a wildcard, huh?). - F3: Global If you need to make global changes to the area information, pressing F3 will bring up the Global Edit menu. You can change the settings of the areas according to these four submenues (uppercase letters indicate the hotkey): Linked Systems Add node, Delete node, RePlace node (with status) Switches ActiVe, Secure, Hide, Unlinked, auto Maint, mandatOry, Read only, Tiny seens, Import seens, hide sEen-bys, manual onlY, Zone gate, No %pause, Dupecheck, squish Kill, duPe msgid <When you want to toggle one of these, use the cursor keys or PgUp/PgDn in the prompt window>. Text Fields origin Line, Origin address, Seen-bys, Message path. Digit Fields # Days, # Msgs, Kill dead, Read security, Write security, Group (by group), group (by Areaname). In almost every case, the changes will be made on a per- group basis. One or more groups may be specified, and the modifications will be made for all echo areas which belong to the selected group(s). The configuration items are exactly the same as in the normal area record, with three exceptions: "Message path", "Group (by group)" and "Group (by areaname)". - Message path With the first little built-in tool, you can easily move around your message area files. Just enter the old part of the path (that is the part which changed) and the new one. Then choose the groups that this change will affect and IMSETUP will simply substitute the one for the other. - Group (by group) Use "Group (by group)" to switch areas in one or more (!) groups to a (single) new group. Specify the old group(s) (exit with F10), then select the new one (F10) and confirm your choice with 'Y'. - Group (by areaname) The last tool allows you to assign a group number to areas according to a certain name scheme. For example: You want to assign the group 14 to all OS/2-related echoes. Specify *OS2* in the areaname window and chose the group number 14 (exit the window with F10). Confirm with 'Y' and all echos having OS2 anywhere in their echotag will be assigned to the group number 14. To close the Global Edit menu, press ESC; you will be returned to the main Area Manager screen. - F4: Browse the list The 'browse the list' function will allow you to examine a list of all - 32 - 6. IMSETUP =========================================================================== the currently defined areas, and to move to a specific record. The window shows some information about each area. For example, it might read: TEST_ECHO Squish 7 AF D:002 MYPOINT.ECHO Jam 157 RA U SECRETS Hudson 9 HD:005 The first field is the name of the area (the areatag). This is followed by the type of the area and the group to which it belongs. Autoadded areas area indicated with an A in the 'Flags' column. Areas for which a forward request is pending are tagged with F, unlinked areas with a U. If an area has the 'Hidden'-switch on will be listed with an H. The areas which have been 'dead' for some days have a D:nnn in their line, nnn being the days inactive. When a deadlink request has been issued, an R will occur in the list. - F5: Copy Area The F5 key allows you to create a new echo but in unlike <Ins> it carries over some data from the current record (like group, flag settings, downlinks). - Shift-F7: Echo flow statistics Pressing F7 pops up a small window which allows you to check the current echomail flow information for the current area. And that is for today, yesterday, this week, last week, this month, last month, this year and last year. Should be enough, folks! - 'A'-'Z','0'-'9','.','!','-','_': Quick jump If you want to jump to an area quickly, simply begin to type in its areatag. IMSETUP will "follow" you, always displaying the first area that matches what you typed in. The input buffer is displayed in the lower left corner of the display window. Any key outside the range 'A' to 'Z', '0' to '9', dot, exclamation mark, hyphen or underscore will reset the input buffer. The backspace key can be used to correct typos without deletion of the input buffer. - Alt/Ctrl-A - jump between autoadded areas - Alt/Ctrl-D - jump between dead areas - Alt/Ctrl-F - jump between FwdReq pending areas - Alt/Ctrl-U - jump between unlinked areas For enhanced usability (hype word, huh?), you can move around in the area records using Alt-A, bringing you to the next entry with the "[Auto-Added]"-flag. Ctrl-A jumps to the previous entry. Use Alt/Ctrl-D to display the next area with the "[Dead]"-Flag, Alt/Ctrl-F for the "[FwdReq pending]"-Flag and Alt/Ctrl-U for the "[Unlinked]"-Flag. The flags are explained right after this section. 6.4. AREA MANAGER - 33 - =========================================================================== 6.4.2. Flags displayed in the Area Record When displaying the area record, you will find some status information given in square brackets at the margin of the record window. These are: [Auto-Added] This flag indicates that this area has been created automatically. This could be the result of a forward request or a remote creation (see section 6.2. on the node record and chapter 10.5., page 68 on the remote creation). [Dead: nnn] With this flag, IMSETUP informs you that there has been no traffic in this area for 'nnn' days. [Deadlink] This message will occur if the echo has been dead for the days specified in the "Special Parameters" and IMAIL has tried to revive the area by sending a request to the uplink but no mails have yet arrived. [Fwd Req pending] This flag indicates that this area has been requested automatically from your uplink due to a request of one of your downlinks (forward request), but no mail has arrived yet. [Hidden] Hidden areas are quite an unusual thing. Therefore, IMSETUP shows this little flag as a reminder in the upper left part of the screen, right above the areatag. [Inactive] You disactivated an area? You once had good reasons for that. IMSETUP will show this fact in the upper left corner for you not to forget... [Unlinked] When this status message is displayed, this echo has been unlinked automatically from your uplink, because there were no systems (downlinks) this echo was exported to or because it was 'dead' for too long. [Unsecure] When an area is switched to unsecure, this indicator will appear. It shows that IMAIL does for example NOT check if the sender is in the linked systems list. - 34 - 6. IMSETUP =========================================================================== 6.4.3. The Message Area Record What follows is a description of the individual fields of the message area record, and how they are used and changed. All fields are required unless stated otherwise. - Areatag This is the name of the message area, the techno slang for this is "Aretag". The name may be up to 50 characters long; it will be forced into upper case. Control characters ( below 0x20 and 0x7F) and Wildcard characters like '*', '?', '[' and ']' will result in an error. When used as the first character of an areatag, '-', '+', '&', '~', '#', '%' and '=' will be refused. Please be sure of the spelling of the name, since it is used to identify into which area (board or path) an incoming message should be tossed. It is not possible to define two areas with the same area name. IMSETUP will show a warning message, and you will be prompted to correct the name. This is to prevent cross-linked areas. - Comment Here you may enter a brief description of the area. This description is used by AreaLink when generating lists of the areas you have available, and may also help remind you of the topic or purpose of the message area. Note that if the area was auto-added, created due to an automatic creation or forward request by TOSS or AreaLink, the comment will be set to something like "Area autoadded by <node> on <date time>" "Area received from <node> on <date time>" "Area requested from <node> on <date time>" This way, you have an overview of what is going on. IMAIL also tries to determine the description from the forward link request file (if defined). This field is optional. Unfortunately, it often will be left blank or set to the entry given by IMAIL. This forces the downlinks to guess at the purpose of an echo and puts him/her back to "trial and error". Help your downlinks! Try to fill out descriptions as well as you can on a regular basis, especially with autoadded areas. - Rulename Enter the rule filename for this area in this field. Either select it from the area selector box showing the files in the directory you specified (chapter 6.2., page 16) or enter it manually (nevertheless, it has to be in that directory). You will also have an option to let IMSETUP automatically search for the rule (this will work only if the ruleheader conforms with the format developed in Germany). Arealink will send the named file along with IMRULE.HEA to a system which links to this area via netmail. see also chapter 10.4., page 68. 6.4. AREA MANAGER - 35 - =========================================================================== - Origin Here you may specify up to 63 characters which will be used as the origin line for the area if it is an echo area (see chapter 12., page 82 for more information on Origin lines). To this, the string * Origin: will be prefixed and your origin address (see below) will be appended. The total length must not exceed 79 characters. If you forget to define this field, the default origin line will be used (see chapter 6.2., page 28). Note that if the BBS or editor program used to write an echo message already adds an origin line, the one defined here will not be used (kind of 'first come - first served' basis :-) ). - Group This is a number between 1 and 255 which identifies the group to which this message area belongs. The description of the group is displayed after the group number. Groups are used primarily by the AreaLink function to indicate which nodes may request links to which echo areas, request areas from which uplink and generally simplifying their automatic handling. For more information on this, see section 6.6., page 50 and chapter 10., page 63. If the area was auto-added by TOSS or AreaLink, this field will be set to the group specified in the Node Manager's New Area Group field (for the node which created the echo), or to that specified in the Other Parameters menu. If it was created due to a forward request, it will be assigned to the group defined in the Arealink Option's Create Group field or to the one in the Node Manager`s New Area Group field. If neither of these is defined, the group number will be set to '0'. In this case, it should be edited to the correct value as soon as possible. If you change the group of an area, IMSETUP will prompt you if you want to take over the defaults of this group from the Group Manager. - Msgbase Here you indicate the message base (format). Possible choices are Squish, Jam, Hudson, *.MSG or Passthrough. When you switch a Squish, MSG or Jam area to passthrough, IMSETUP will prompt you for the deletion of the related message base. When you switch to Hudson, IMSETUP will suggest a free board number according to the group definition (see also two paragraphs below). Bear in mind that IMSETUP will not allow you to set the Msgbase to 'Hudson' when you don't have defined a path to the Hudson base in the 'subdirectories'-menu. - Type - 36 - 6. IMSETUP =========================================================================== In this field, you will indicate the type of message area. You may specify that an area is Echo, Net or Local This way, you may include ALL of your message areas in IMSETUP. For the purpose of handling echo mail, only those areas which are of type Echo will be considered. Netmail areas are used by the IMPORT function of IMTHINGS. Their areatag has to begin with NETMAIL_. If you specify a JAM-type-area as Netmail, you will be warned by IMSETUP, because this is not yet supported. Please note that you cannot enter the main netmail area (i.e. the one of your mailer and the one IMAIL creates the file attaches in) as a netmail area in IMAIL's area manager, IMSETUP will refuse you. Local areas will be ignored by all IMAIL functions (but not by IMTHINGS), but will ensure that you do not use a board number twice. IMAIL will never import Echomain into a local area. The special boards BADMAIL, DUPES and PERSMAIL are an exception to this rule, they are forced to 'Local' by IMSETUP. - Board If the area is Hudson type, you should specify the board number in this field, corresponding to the message area. The board number may be between 1 and 200 inclusive (the upper limit is imposed by QuickBBS/RA). IMSETUP will not let you use the same board number twice, because you would be cross-linking echo areas. When you edit this field, a list of all unused board numbers will appear and you may move around using the cursor keys, selecting one of it by pressing ENTER. When you switch from another message base type to Hudson, IMSETUP will come up with a suggestion of the next free board number, according to the group definitions (see chapter 6.6., page 50). If you are changing the board number, the highlight bar will be placed on the currently defined board number; ESC will allow you to retain the current definition. TOSS uses this number when importing echo messages, since the QuickBBS / RemoteAccess message bases contain no indication of the area name. Similarly, SCAN uses this to derive the name of an echo area when exporting mail. - Path If the message area is *.MSG-, JAM- or Squish-type, then in this field you should specify the directory or path name of the message base. If the area is of type *.MSG, the directory in which the the messages will be placed should be specified. For Squish- and JAM-type areas, specify the directory and the base file name of the area (ie. directory plus file name without extension). If you change an Area from Hudson or Passthrough to Squish/Jam or MSG, 6.4. AREA MANAGER - 37 - =========================================================================== IMSETUP will automatically create a path and basename according to your settings in the Group Manager and the areatag. If you have no entries in your Group Manager, IMSETUP will not propose anything. If you change the area path of a *.MSG, Squish or JAM area manually, IMSETUP offers the possibility to move the message base to the new path, thus reducing error possibilities. Note that this is only possible if you don't change the type of the area. IMSETUP just moves the files that compromise the area message base, not the messages. - Read sec - Write sec These two settings control, in addition to the group numbers, who may link to an echo and who may write in it. In the node manager, you can specify an Area Security Level for every system. Systems that have a security level below the value given in 'Read Sec' will not be able to link to that echo. For systems with a security level higher or equal than 'Read Sec', but lower than 'Write Sec' the echo will be linked 'Export Only'. That means the system will receive mails in that echo, but messages sent by it will be tossed into BADMAIL. For the benefit of those who use an IMAIL-to-BBS-converter, this functions are also available in local or netmail areas. see also chapter 6.5., 45 for more information. - # Days This item is used by IMTHINGS KILL /U (see chapter 6.2., page 29) to determine which messages to kill: it will mark as deleted any messages older than the number of days specified here. If this field is left at zero, no messages will be killed, unless the "# Msgs" field below is specified. The maximum value which can be entered in this field is 255. If the area is marked as Passthrough, this field has (obviously) no meaning. - # Msgs This is used by IMTHINGS KILL /U (see chapter 6.2., page 29 to determine how many messages to leave in this board. If this field is left at zero, it will be ignored, and no messages will be killed, unless the "# Days" field (see above) is specified. Naturally, if the area is Passthrough, this field has no meaning. - Kill Dead IMAIL allows you to delete echos without traffic after a definable number of days. During the midnight maintenance IMAIL marks echos without traffic. A value of 0 disables this function, the maximum number of days is 256. Single echos can also be excluded by setting the field Auto Maint in the Area Manager to 'N'. Dead echos are also marked in the Area Manager. NOTE: THIS CHECK IS ONLY PERFORMED DURING MIDNIGHT MAINTENANCE (SEE CHAPTER 7.3., PAGE 58); THE AREA MANAGER THEREFORE ONLY SHOWS FULL DAYS. - Read only - 38 - 6. IMSETUP =========================================================================== If this option is enabled, every system linking this area gets an export only flag (which can be removed manually by the sysop). This flag prevents unauthorized downlinks from posting messages in restricted (read only) areas. - Dupecheck This switch can be used to advise IMAIL not to perform dupe checking on an area. This increases the speed of TOSS a little, but increases the risk of dupes noticeably. - Dupe MSGID IMAIL has two ways of checking for Dupes: Either it calculates the crc header sum or it checks the MSGID. Especially in gated echos, dupes may occur with changed headers, but identical MSGID. Normally, no identical MSGIDs should occur, neither in gated nor in crosspostings, but programs happen to be buggy... For these echos, you can set this switch to 'Y'. IMAIL will then check every single incoming Msg in this echo (i.e. IMAIL stores the echotag as well) against the MSGIDs stored in IMAIL.DP. Not finding it there, the header crc will be checked afterwards. CAUTION! USING THIS FUNCTION WILL SLOW DOWN TOSS NOTICEABLY! - Squishkill This switch controls whether or not IMAIL should use the Squish 'kill on the fly'-function on this Area. Of course, this switch will only affect Areas that are set to 'Squish'. It enables a special feature of the squish message base to always keep the msgbase below the given limit of messages. It is quite useful, but will slow down TOSS a bit. - Zonegate This field indicates that IMAIL should strip all information from the SEEN-BY line when exporting to a system which is in a different zone, except for your address and that of the downlink. Currently, zonegating only works with ONE node in the other zone, because the new SEEN-BYs will only contain your own and the destination address. Note that when the message is imported in your message base (if the area is not passthrough) the original SEEN-BY lines will be preserved. - Import SB This switch controls whether the SEEN-BYs are imported into the message base or whether they are stripped. - Hide SB If this switch is set to Yes, IMAIL puts a ^A in front of every SEEN-BY line. This is useful for the BBS software which should not display these hidden SEEN-BYs to the normal users then. - Tiny SB This is somehow similar to the 'Zonegate'-switch (see above). Enable this option if you want to strip all the SEEN-BY information from an incoming echo message before it is re-exported. In this case, the outgoing message will contain only the SEEN-BYs of your downlinks. Note, however, that if the area is not marked as passthrough, and if the Keep-Seens option (below) is active, the message will be IMPORTED with the original SEEN-BY information. 6.4. AREA MANAGER - 39 - =========================================================================== DO NOT USE THIS UNLESS YOU DEFINITELY NEED TO! - Autounlink If this option is set to N the unlink check are disabled for this area, so it will remain linked to your system unaffectedly. - Unlinked Together with "Auto Maint", this field controls the unlink status for the current area. If this field is set to 'Y'es, IMAIL has unlinked this area after the last downlink has unlinked or paused it from your system and the remaining system is listed as uplink in the Forward Link Request Manager. The echo will still appear in your list of available areas and if a system requests this area, IMALNK automatically requests this area from your uplink again. If you receive messages in an unlinked area, this switch will be reset. This causes the next midnight maintenance to unlink it again. - No %PAUSE This setting can be used with important echos. By default, your downlinks can prevent echo mails being exported to them using the %PAUSE meta-command with Arealink (see chapter 10.3., page 66). If you don`t want information in important areas to pass your downlinks, you can inhibit the pausing of an area with this switch. - Manual This switch gives you the total control over the links to this area. With this one set to 'Y'es, the area is visible, but totally unaccessible for IMALNK. You can use this to ensure that only adult links read the x-rated areas or to establish some kind of closed user group. - Active This by default is set to 'Y', which means that the area is active (pretty cool, huh?). If set to 'N', IMAIL will behave as if the area had not been defined. This will allow you to disable an echo area, for any reason you may wish, without having to actually delete it, and later re-enter it. Unlike unlinked or hidden areas, inactive areas are ignored by AreaLink and cannot accessed by any downlink. - Secure If enabled, IMAIL will check the address of the system which sent the message in this area. If it is among the export nodes listed in the Export List (see below), it will be imported and processed; otherwise, it will be tossed into your Bad Message Board. Note that the sender's address will be determined using the PKT-address, not the address stated in the origin line. If this switch is set to N, IMAIL will also ignore the export only flag in the list of linked systems. - Hidden Enable this option if this area should not be displayed in any AreaLink report of available areas. Moreover it cannot be linked with a wildcard request. It can only be linked when explicitly stating the full areatag. - 40 - 6. IMSETUP =========================================================================== - Mandatory If you set this field to yes, no downlink can unlink from this echo using the AreaLink functions. This can only be done manually. This field is useful when you really want an echo to be read. - Origin Address Pressing Enter while this field is highlighted, you can choose the address to use in the Origin line of the message. You will be prompted with a window containing a list of all the addresses defined in the "System Addresses" menu; select one of these. This address will also be used in the PATH line of the echo message, as well as in the list of SEEN-BYs. Note that only the net and node numbers will be placed in the SEEN-BYs and PATH lines; the use of zone and point numbers is not accepted. However, IMAIL is able to parse zone and point information from these lines, if found (cute!). - Seen-bys/Akas This field pops up a window that allows you to choose one or more addresses to add to the SEEN-BY line for that area. If you do not select any addresses, then the one specified as "Origin Address" will be used, without zone and point numbers, just like above. - Linked systems This list may contain up to 200 systems to which this echo will be exported. At least one node must be defined to TOSS or SCAN to/from the area. Editing this entry, you will see a window with a four-digit flag field and the system address in each line. When selecting an entry (pressing <Enter>), another window will pop up, displaying the system address once more, the sysop's name, if defined in the node manager and the flags in expressis verbis. When you select the field <Sysop name>, a selection box will open with all systems defined in your node manager, with system address and name sorted by address. The Flags mean the following: <Export-only> ('E' in the flagfield) means that IMAIL will export mail to this system, but will not accept incoming mail, in this area from this system. This is only valid for "Secure" areas. <Import-Only> ('I') indicates that IMAIL will accept incoming mail from the system, but will never export to it. It is also possible to see whether a node has been marked as <Paused> ('P') (see also chapter 10.3., page 66) or <Denied> ('D') and to toggle these flags. So, what's that "Paused" and "Denied" good for? IMAIL will stop sending echomail to a "paused" system unless it has been explicitly told to. (6.4., page 39). But it will not "forget" which areas this system is linked to. When 6.4. AREA MANAGER - 41 - =========================================================================== the system or you issue a "RESUME"-command, every area is "turned back on". A system which as the "denied" status is somewhat a poorer fellow: - the system will not be able to receive mail in this area, - mail from the system will not be accepted if the area is secure, - the system will not be able to remove himself with that status from the link list of that area (simliar to mandatory but affecting only the system with denied status), - this status will also be shown in Arealink responses. With this status, you are able to deny the access to single areas for single nodes (eg. when they're excluded by a moderator decision or for other reasons). In opposite to mandatory and group/sec level solutions, this status affects only single nodes. It is permanent and independed from granted groups and security levels. Therefore, this switch can ONLY be changed from IMSETUP by the sysop. 6.4.4. Special boards IMAIL uses three special areas for some internal purposes. At least the bad message area should be defined. The dupes area and the personal message area may be set to passthrough. - Bad Messages Messages flagged as "bad" will be tossed into this message area. These include echo mail messages arriving from unlisted systems when "Secure" mode is active for that area, as well as echo mail in unrecognized areas. You should first choose if you want the area to be of type Hudson (H), *.MSG (M), Squish (S) or Jam (J). If you select Hudson, then you must supply a valid board number; otherwise, you should specify a path name. This record is required, the hardcoded areatag is BADMAIL NOTE: ! THIS AREA SHOULD NOT BE USED FOR ANYTHING EXCEPT "BAD" MAIL ! - Dupe Messages This message area is the one into which all messages flagged as duplicates will be tossed. If not defined, dupes will simply be killed (deleted). As with the Bad Message Area, first select the type of the message area (Hudson, *.MSG, Squish or Jam), and then the board or path. The hardcoded areatag for this record is DUPES NOTE: ! THIS AREA SHOULD NOT BE USED FOR ANYTHING EXCEPT DUPLICATE MESSAGES ! - Personal Message Board IMAIL can check the echo mail while tossing for new mail for the person defined as sysop in IMSETUP. If you enable this feature you - 42 - 6. IMSETUP =========================================================================== can select that these mails are copied into a special board, the Personal Message Board. Some mail editors like GoldEd can cope with replying in a personal message board by generating an AREA:-Line corresponding to the area the original message originated. IMAIL will then toss/scan out the answer into the correct board. The hardcoded areatag for this record is PERSMAIL NOTE: ! THIS AREA SHOULD NOT BE USED FOR ANYTHING EXCEPT PERSONAL MESSAGES ! - Netmail Boards You can have IMTHINGS IMPORT importing netmails for each aka you have into a separate Netmail board. Simply create a new area beginning with NETMAIL_ set the msgbase as you like (except for Jam) and set the type to 'Net'. With the Origin Address and the Seen-bys/Aka list, you select the addresses for which netmail should be imported. NOTE THAT YOU HAVE TO SELECT AT LEAST ONE ADDRESS IN "SEEN-BYS/AKAS". 6.5. Node Manager The Node Manager is used to specify information regarding the systems to which you export mail, including which program will be used to compress outbound mail for the system, as well as what type of file attach to generate. 6.5.1. Special BROWSE Keys The following keys will allow you to edit, add, delete or find node records. They are: - Shift-F1: available F-Keys Shift-F1 saves you from fumbling with the doc every time you forgot the keys, it will show a little summary of the allocation of function keys. - F2: Find record Pressing F2 brings up a window in which you may specify a node number. If the address is found, it will be displayed. - F3: Global functions Similar to the Area Manager, this feature enables you to change settings for more than one node at a time. Specify the nodes whose records are to be changed using wildcars. IMSETUP recognizes the following flavours: * Just all of them 2:* everyone in zone 2 2:2480/* everyone in net 2480 2:2480/47.* all Points of 2:2480/47 6.5. NODE MANAGER - 43 - =========================================================================== but also: 2:2480/*.0 all Points in the net 2480 - Groups The "Groups"-menue enables changes to the group assignments: Add one or more groups to the nodes' records, remove one or more, exchange one group number with another, set the group assignments statically and set the autocreate group. If you are unsure how to use the group selection window, have a look at section 6.1. on page 11. - Switches These functions are assigned to the 'Yes/No'-Flags in the node record. Change the setting using the cursor keys, confirm with <Enter> then select the nodes. PLEASE NOTE: YOU CAN ONLY CHANGE ONE SWITCH AT A TIME! - Node Fields The 'Node Fields' are these settings which affect the status and handling of the mail: PKT origin address, Message status, Attach status, Packer, Capability, CW Handling, arealink Name, Domain. - Digit Fields The last one controls the numeric part of the node record: Security level, size of the PKTs and ARCmail-bundles, the number of PKTs to pack per call and the pack priority. - F4: List records The browse function will allow you to examine a list of all the currently defined nodes, and to move quickly to a specific record. The window shows some information about system. For example, an entry might read: 2:2480/28 Roland A. Meier N 2:2480/77 Wolfgang Schmid HD 2:2480/87 Christian Maluck H 80:89/1 Arnulf Bultmann I The letter following the node name indicates the status: H means Hold, C is Crash, I equals Immediate, while N is normal. An additional D means Direct. - F5: Copy record The F5 key allows you to create a new entry but unlike Ins carries over some data from the current record (like groups or flag settings). - F7: Edit/show linked areas This is a GREAT tool! A window will pop up with the area record list. Every area this node is linked to will be highlighted and preceeded by a '+'. If this system is set to "Import only" or "Export only" or if it has set the "paused" flag, this will be indicated by the letters 'I', 'E' and 'P'. But the real treat is that you can edit these values! Press '+' to add the node to the list of linked system for this area, - 44 - 6. IMSETUP =========================================================================== '-' to remove him or her. Hit 'I' to set this link to "Import only", 'E' to set the "Export only" flag and 'P' to pause this system for this area. Hit the space bar to toggle the link status for this area. - Shift-F7: Node statistics Pressing Shif-F7 while browsing through the node records you will be confronted with a small window which informs you about the recent mailflow statistics of this node. 6.5.2. The Node Record Now things really get started. Let's delve into the abyss of editing the node record: - Address Here you specify the address of the system. The Zone, Net and node are required. If no point is specified, it will default to 0. When changing a node's address, IMSETUP will allow to change the nodenumber in the area records, too. - Domain Here, you can specify the domain to which the system belongs. This is very important in multi-domain environments, and when you have different outbound directories for each domain (see chapter 6.2., page 13 for more on this). Select the domain from the list presented. If the system belongs to a domain which is not listed, you should define it in the Domains menu. - Sysop This field allows you to specify the name of the sysop of the system. It is used for purely cosmetic purposes, by AreaLink when generating net mail messages, and so is not required. But as man usually remembers names rather than numbers it is strongly recommended that you fill out this field. - AreaLink Pwd If specified, this will be the password that the system will use when requesting areas or information from Area Link. If no password is specified, the system may not request any areas, even if one or more groups have been enabled. The password will be hidden behind asterisks ('*'), it will only be showed when you edit it. For more information on AreaLink, see chapter 10., page 63. - Pkt Pwd For added security, you may specify that packets to and from this node contain a password. The password may not be longer than 8 characters. This password will ensure that mail from that system cannot be sent by someone else under false pretences. If a PKT without proper PKT password is encountered, the PKT will be renamed and TOSS will notify you with a netmail. - Pkt OrigAddr 6.5. NODE MANAGER - 45 - =========================================================================== Here you can configure one of the system akas as fixed origin address for the packets created for this system. Also the origin address of the area which is exported can be used, which is the default setting. This feature allows to use always the same aka when sending packets to a specific system. Note that the address specified here is only used for the *.PKTs; this has nothing to do with the single mails or the sender of the compressed file (the ARCmail-bundle). - Pkt Routing This feature is implemented for downlinks that can handle multiple akas, but only poll with one. These are FTS-0001, FTS-0006 mailers (e.g. Yuppie! in different FTN-networks) or diskpoll-points. The PKTs for the system you are editing will be sent to the address given here. That is the PKTs will be compressed into the same bundle as the PKTs of the routing system. Enter the address used when polling into this field for all other node records of this downlink. IMCOMP will then pack all PKTs for the defined aka allowing the downlink to pick up all their mail without further problems or measures by you. - Security The value you enter here corresponds directly with the fields "Read Security" and "Write Security" in the area record (see there). Here, you can assign a certain security level to the node which controls which areas he/she can link. Apart from the groups, this is a useful feature to restrict access to areas. - Pack Priority This field controls the order in which the tossed mail is compressed for the nodes. You can specify a value between 0 and 9. Nodes who have a "9" will have their mail compressed first. This is useful for nodes who have a separate computer for TOSSing and whose downlinks use to call immediately after the poll to the uplink. This way, you can compress the mail for the pesters first. - Msg Status Pressing enter while having highlighted this entry will allow you to change the message status for messages created by IMAIL (like AreaLink replies). By default, this is "Normal", but you may select one of: Normal No status Hold Hold message for pick up. Crash Send message 'crash'. Immediate Set Immediate flag. Direct Send this message directly. Hold Direct Only the link itself can pick up this message. Crash Direct a fail-safe variant of 'Crash' to work around the strange behaviour of some mailers. Immediate Direct Possibly the worst method of forcing a mail out... Note that the messages to systems not defined in the Node Manager will be handled along to the defaults in the node manager defaults, chapter 6.2., page 23. - Attach Status The field below allows you to change the file attach status. When creating a new entry, this is set to the defaults given in the node - 46 - 6. IMSETUP =========================================================================== manager defaults, see chapter 6.2., page 23. You may select one of: Normal No status. Hold Hold attach for pick up. Crash Send attach 'crash'. Immediate Send attach immediately. Direct Send attach directly to this link. Hold Direct Hold this attach for pickup by this very system. Crash Direct a fail-safe method of sending the attach at once. (this is not the same as 'Immediate'!). Immediate Direct Ok. Will be sent immediately without questions. In a Binkley environment, there is no need for the 'Direct'-flag, because FLO-files direct by default. It is STRONGLY recommended that echo mail NOT be routed, (pretty safe way to get guys angry) so if the node is your echo mail feed, it is best to mark it as Direct. Note that any systems not defined in the Node Manager will have their mail handled according to the defaults in the general setup (see chapter 6.2., page 23). - Capability The Capability describes the other system's mail processor. Currently, two types are defined: Stone Age Type 2+ You can set this field according to the capability of the remote system's mail processor, if known. If you are unsure, leave the field set to "Stone Age". Note, that it is possible to define as Type 2+ mail processors which are not normally detected as such but which have the zone and point information. This is done in the Product Code menu (see above). For more information on the capability word, refer to the FTSC documents FSC-0039 and FSC-0048. See also FTS-0001. These documents may be available near you; otherwise you should be able to file request them from 1:1/20. Refer also to chapter 13.2., page 92. Note also that IMAIL will always generate "Type 2+" information in the packet header, and identify itself as a Type 2+ mail processor, regardless of the setting of this field. - CW Handling This field allows you to define how IMAIL will use the setting defined in the Capability field when handling inbound mail. If it is set to "Force", IMAIL will always use the setting defined in the Capability field, regardless of what the actual format of the inbound packet(s) might be. If set to "Auto", IMAIL will try to determine the type of packet by examining the Capability Word and its validation copy and/or the product code, and process the file accordingly. Please note that IMAIL cannot correctly handle points which use "Stone Age" mail processors, unless they are using fakenet 6.5. NODE MANAGER - 47 - =========================================================================== addresses. - Program Name This is the name of the AreaLink used by this system. It is used by Arealink when forwarding delete, create or change requests to the systems linked to a certain echo. See next section for details. - Packer If you press Enter while having highlighted this entry, you will be able to select the program to use for mail compression. A list will appear, containing the programs you defined in the "Compression Programs" submenu. If you make no selection, the first program in the list will be used. It is also possible to specify that no compression program shall be used (the last entry in the list). In this case, PKT files addressed to the node being edited will not be compressed, but will simply be attached to the destination system. This allows simple mail processors to receive mail from IMAIL systems without the need of one or more decompression programs available. (You can also test your V42bis throughput with this...) Please note that in this case, the file attach in FrontDoor / Intermail - Environments will ALWAYS be set to KFS (Kill file when sent). - Groups List the Groups to which the system may have access. Up to 255 may be specified. A system must have a Group enabled in order to be able to request a link to any echo area which is part of that group. The window shows the groups currently assigned to that system and allows you to add or remove certain groups very easy. See also section 6.1., page 11. - Notify This flag indicates whether or not the specified node should receive NOTIFY messages. By default, this is set to Yes, indicating that the system will receive a notification message from Arealink when called with wildcards. - Remote Maint IMAIL may allow systems to carry out changes in the links for other systems. These changes may be made via AreaLink, using the %FROM meta-command (see chapter 10.5., page 68 In order to enable a node to make these changes for other systems, this field must be set to 'Y'; the default is 'N'. Remote Maint also allows the system to delete an echo area from your list, or to change the name of an area. It thus allows a lot of control over your system. - Check Pkt pwd You can control the use of the previously specified packet password with the help of this switch. If you set this to "N", outgoing packets (those created by IMAIL) will nevertheless contain the specified password. Setting this switch to "Y", IMAIL will only process packets with matching passwords. - 48 - 6. IMSETUP =========================================================================== - Change packer Here you can control whether this system is allowed to change the packer using the commands of IMALNK. This is useful for systems which are called by you and where you always want to use a very good packer. - ALNKcheck Echo This feature of IMAIL allows to check every message from this system whether it is a message to Arealink (to avoid for example exporting an Arealink request that an unexperienced points has posted in an echo). Use it with care because it requires some time while tossing. - Ext. arcmailname When creating ARCmail-bundles, IMCOMP uses the first two letters of the weekday and a consecutive one-digit number to determine the extension of the file. For example .MO0, .MO1, .MO2, .MO3, ... If IMCOMP has to create an eleventh bundle, it can either continue with 'A' after '9' (up to 'Z') or stop compressing and continue the next day. Some older mailprocessors have problems identifying bundles with letters in the last digit of the extension, switch this toggle to 'N' for theses links. - Rescan OK This flag indicates whether the system is allowed to rescan echo mail from your system with an AreaLink request. Of course, only those echoes to which this node has access will be rescanned. - Forward Requests This flag selects whether this system is allowed to cause Forward Link Requests, so you can prevent downlinks from requesting areas from your uplink (see chapter 6.7., page 51). - Create New Areas If you wish to allow the system to create new echo mail areas on your system, then set this flag to 'Y'. Otherwise, mail in unknown echo areas, originating from this system, will be tossed into the bad message area. The area record created will be marked as Auto-Added; the node which originated the message will be inserted in the export list for the new area, along with the nodes which were set to <'Add to new areas'> - Uplink Together with "Program Name" and "FSC-0057 compatible" these fields are used by the remote functions of AreaLink. If an area is remote created, renamed or deleted, IMAIL informs your links about this. This field selects whether this system is one of your uplinks (see below). - FSC-57 capable This flag specifies whether this system is capable of handling requests according to FSC-57 (which is only required concerning the remote delete, rename and create request). If such a function is executed on your system, all affected downlinks are notified. If they are also FSC-0057 capable and not an uplink, their AreaLink is also notified with a message. The table below shows how AreaLink works in this cases: Remote req FSC-0057 not FSC-0057 6.5. NODE MANAGER - 49 - =========================================================================== delete delete request unlink request create create request link request rename rename request --- nothing --- - Add to new areas If you wish this system to be added to all new areas, then set this field to Yes. Note that the node will only be auto-added if it is in the same domain as the system which "created" the new area. - New Areas Group If you have enabled the Create New option (above), this field will specify the group to be used for echo areas created by the node. Select one from the pop-up window. Please check the Group Manager for the default settings you assigned to this group (if you don't want to be surprised by somewhat old settings) - Max.Pkt Size With this option, you can specify the maximum size of the packet files (*.PKT) that IMAIL will create for this link. Use this if this link is permanently short on disk space. The number should indicate a size in kilobytes. If a zero (0) is specified, no limit will be imposed. For the defaults, see the node manager defaults in chapter 6.2., page 22. - Max. Arc Size Setting this to a non-zero value tells IMCOMP not to add further PKTs to a compressed ARCmail bundle if its size is bigger than specified (in kB). IMCOMP will then create a new bundle. Set the defaults in the 'nodeMgr defaults'-menu, chapter 6.2., page 22. - # Pkts to pack When this field is set to 0, IMCOMP will add ALL pending PKTs to an existing ARCmail bundle or creating one single bundle. Setting this field to a non-zero value (max. 99), IMCOMP will only process this number of PKTs per call, then again check the size of the created ARCmail-bundle. The default value for this field is set in the 'nodeMgr defaults' menu. See chapter 6.2., page 23. - Send Rules When you enable this switch, IMALNK will send the rules of an area to this system when it links an area for the first time (i.e. not on update or resume requests). This IMALNK area rules support function will only work if the global rules path is defined (see 6.2., page 16) and if the file name for the (existing) area rule is also defined in the area record for the area. For further information on this feature see chapter 10.4., page 68. - ALNK with '+' Here you can define whether IMALNK prefixes area link requests with a '+'. As the areafix functions of some programs do not accept a - 50 - 6. IMSETUP =========================================================================== preceeding '+', you can disable this here. 6.6. Group Manager The Group Manager has two functions. It allows you to assign descriptions to the various groups which can be accessed from the Area Manager and from the Node Manager. Moreover you can define the default settings which should be used if a new area arrives and is automatically created by IMAIL. You can assign each system which is allowed to create areas a "New area group". Each area created by this system will get this group and the defaults of this group as defined in the Group Manager. - Description Here you can enter a short description of the group, it is used when you select groups in the Area Manager and in the Node Manager. - Msgbase This feature allows you to control the areatype a new area will get: Passthrough, Hudson, Jam, Squish and *.MSG. If you select Hudson, IMAIL tries to find a free board in IMAIL.AR and assigns this to the new area (be careful that all areas used are defined in IMAIL.AR). If you select Squish, JAM or *.MSG, IMAIL uses the areatag to create a unique filename of the new squish area in the directory specified in "Path" or a new directory under the directory specified in "Path". If an identical name already exists, IMAIL will use another algorithm (be surprised...). If a maximum number of files is specified in 'General' - 'Special Parameters' menu, IMAIL will check the directory before creating the new Squish- or Jambase-files and select a new directory if the number is exceeded. (see page 24). - Boards 0 - 0 These two fields are for people who prefer their Hudson Base to be structured. You can specify a range of board numbers the new area should be assigned to. IMAIL will chose the lowest board possible. If no board can be assigned in the given range, IMAIL will take the first board from the whole base. - Path Specify here the directory or the "stem" of the directories in which IMAIL will create the message base files or *.MSG-directories. The creation of new pathes due to 'overflow' is then handled by IMAIL automatically. - The other settings The following switches only control the default settings of a new entry created by IMAIL. They are described in the Area Manager section: Read Sec, Write Sec, # Days, # Msgs, Kill Dead, Read Only, Dupecheck, Dupe MsgID, Squishkill, Zone Gate, Import SB, Hide SB, Tiny SB, Autounlink, No %PAUSE, Manual, Hidden, Secure, Mandatory, Origin Address and SEEN-BYs. 6.6. GROUP MANAGER - 51 - =========================================================================== 6.7. Forward link manager Forward Link Requests are a method to have IMAIL automatically request areas from your echo uplinks. If AreaLink processes a request for an echo area which is not listed in your configuration, it will search the files you have defined for this area. If found, it will send a request for that area to the system listed. If the area could not be found in the lists, IMAIL will send an unlink request for that area to the requesting system, if a program name is defined (see chapter 6.5., page 47). If no program name is defined for that node, the function will be skipped. NOTE THAT THE REQUESTER AND THE UPLINK HAVE TO BELONG TO THE SAME DOMAIN! You can delete an entry with <Del> and insert a new one by pressing <Ins>. - Uplink In the "Uplink" column, specify the network address of the system to which the request should be sent. IMSETUP will then prompt you if you want to take over the entries for password, arealink name and create group from the node manager. If you don't know the address by heart, leave this empty and proceed with the next entry. - Uplink name You can alternatively select the Uplink from the nodes entered in your node manager. The takeover of the password, arealink name and create group from the node record is possible, too, thus making work easier and ensuring a correct setup... :-) You will then have to enter the filename of the area list and the access group (see below). - Areas file This column indicates the file name of a Fidonet.na- type file containing the list of echo areas available on that system which AreaLink should search. Select the file from a file selector box showing all files in the IMAIL home directory or enter a name manually. (btw: the file positively has to be in this directory). The format of the Fidonet.na file is <AREATAG> <DESCRIPTION> - Send to Enter the name of the program to which the net mail message will be sent, such as for example AREAFIX, AREAMGR or IMAIL. If you are unsure of what to put here, contact your uplink. Note that AreaLink will behave a bit differently if AREAFIX is specified instead of another name. For example, IMAIL will add a tearline to the message which will be omitted when writing to other programs. - Password This column should be self-explanatory, you enter the password the uplink has assigned to your system. You will need to contact your uplink to have one assigned to you or if you forgot yours. :-) - 52 - 6. IMSETUP =========================================================================== - Access Group This column indicates the Group the requester must have access to in order to invoke a forward request. By this, you have another method of dynamically assigning rights to your downlinks. Left empty, every downlink can invoke forward requests. Clear this field using 'Del'. - Create Group With this number, you assign the group the newly requested echo will belong to. When left empty, the new area will be assigned to the group entered in the node manager. The versability of this setting turnes out when you enter different figures: you can tell apart echos which have been sent to you by your uplink (they are assigned to the group entered in the node manager) from those which have been requested from your system (they are assigned to the group entered in this column). This way, you can prevent access to newly created echos. Clear this field with 'Del'. 6.8. Pack Routing In this menu you may specify default routing for IMPACK (see chapter 9., page 61; in other words, you may specify that net mail for one or more systems be compressed in a packet addressed to another system, from which (presumably) the mail will be forwarded on. This can result in a great speedup in the handling of your netmail folder... The menu is composed of two "Route Via" columns, which indicate the nodes via which net mail will be routed. For reasons of space, the routed and excepted nodes are not shown unless the appropriate function key is pressed. If no systems are listed as "Routed Systems", IMPACK will simply look for and compress mail for the "Route Via" address. To edit these entries, position the cursor on the desired row and press ENTER or simply press the character preceding the desired entry. You will then be able to edit the "Route Via" address. Once finished, you may edit the list of "Routed System" by pressing F2. It is also possible to specify one or more "excepted systems" by pressing F3. If you want to insert new entries between existing ones for reasons of clearness, do so by pressing INS, and delete entries (permanently!) by pressing DEL. IMSETUP supports the use of the "*" macro when specifying the "Routed Systems". This macro may be used in place of the net, node or point fields (the zone should always be given). For example: 2:* All net mail messages addressed to systems in Zone 2 2:2480/* All net mail messages addressed to the nodes in Zone 2, Net 246 2:2480/100.* All net mail messages addressed to the points of node 2:246/100. This is equivalent to: 57:4980/100 This is treated as if you had written 57:4980/100.*; in other words, it will act on all messages to the "boss" node and his points. If you wish to indicate only certain points (or 6.8. PACK ROUTING - 53 - =========================================================================== the node itself as .0), you will have to specify them explicitly: 2:246/100.1 This will pack messages for point 1 of the system 2:246/100 via the node specified in the "Route Via" column. If you do not specify the Zone, IMSETUP will use the Zone as defined in your primary address. Routing via itself: If you use the ALL macro '*' as Via System, IMPACK will pack all messages matching this entry via the node itself, for example Route Via: * Routed Systems: 2:2480/55 Routed Systems: 2:2480/48 Routed Systems: 2:2480/37 tells IMPACK to pack the netmail for 2:2480/55 via 2:2480/55, 2:2480/48 via 2:2480/48 and 2:2480/37 via 2:2480/37. Using this feature you can collect several entries to one. If you specify your own aka in "Routed Systems", mail for your points will be packed together with their mail and not packed for you (in exception to the boss-route-scheme). An example might serve to illustrate how this all works. If you have two entries such as the following: Route Via: 2:2480/55 Routed Systems: 2:* Excepted Systems: 2:245/* 2:242/* Route Via: 2:242/53 Routed Systems: 2:* Excepted Systems: (none) Thus all mail addressed to systems in Zone 2 would be routed via 2:2480/55, EXCEPT for mail addressed to systems in net 242 and 245. Since the list is processed top-down, mail for systems in nets 242 and 245 will be pack-routed via 2:242/53. 6.9. Import/Export Functions 6.9.1. Export Areas.Bbs Here you can create a standard Areas.Bbs file, IMSETUP will ask you for the name of the file and the groups to be included. - 54 - 6. IMSETUP =========================================================================== 6.9.2. Export GoldED Areafile This function creates an include file for GoldED and uses already the enhanced format (up from GoldED 2.41). IMSETUP will prompt you to enter the groups you want to export. 6.9.3. Export FidoNet.na This function creates a standard FidoNet.na file which contains the area tag and the description. You have the possibility to select groups prior to export. 6.9.4. Export TimEd areafile With this, you can create an areas-include-file for TimEd. You can select the groups you want to export. 6.9.5. Import Areas.Bbs Here, you can import a standard Areas.Bbs file into your area database. The maximum length of one line is 1024 characters. 7. IMAIL - COMMAND LINE OPTIONS Once you have configured the program via IMSETUP, you are ready to use IMAIL. There are three separate commands or functions "contained" in IMAIL, and they are invoked via the command line. The syntax used to invoke IMAIL is: IMAIL TOSS | SCAN | /? If no command or the switch /? (-? will do the same) is given, IMAIL will display a help screen, and return to the DOS prompt. 7.1. TOSS - Toss Incoming Mail This invokes IMAIL's TOSS function. This will search your inbound files directory for mail, either compressed or in PKT form, and toss it into your message base; net mail messages will end up in the net mail directory, while echo mail will be put into the correct message area. The TOSS function will automatically forward any echo mail to other links, as long as the switch 'Handle PKTs not for us' is set accordingly. If TOSS finds that there is insufficient free space on the working drive while processing, it will can be configured to automatically spawn to IMCOMP which compresses all outgoing mail before going on. This should help prevent disk full errors. Should TOSS encounter an ARCmail file from which it cannot extract the mail packets successfully, it will rename the file to have the extension .BA? so that you can look at it, and so the file will not be processed again. Similar things will happen if TOSS encounters a garbled or unaccessible PKT. The renamed PKT will remain in the temp outbound. In any case, IMAIL will inform you with a netmail which will look like this: From : IMAIL Watchdog To : <Sysop Name> Subj : Bundle renamed ODER PKT renamed ------------------------------------------------------ Old name: <old file name> New name: <new file name> Reason : <short reason> For information on how TOSS handles the Capability Word, refer to chapter 13.2., page 92. Note that IMAIL TOSS will return different errorlevels if an error has occured. It will create various semaphores depending on the kind of mail it has processed. For the full list of ERRORLEVELs returned and semaphores created, see chapter 14.8., page 105. - 56 - 7. IMAIL - COMMAND LINE OPTIONS =========================================================================== - /U Do not unpack ARCmail-Bundles If IMAIL is used to unpack netmail-PKTs, it may be useful to have IMAIL unpack these plain PKTs, but leave compressed ARCmail-bundles untouched for later processing in a timed toss event. - /# Do not import into local msgbase(s) If you don't want incoming mail to be imported into your local message base(s), but only to be tossed for your downlinks, specify '/#' with IMAIL TOSS. With this feature, real care-free holidays are possible. No longer fear the shutdown of your system because the message base-killing tool crashed... :-) - /! - Do not export to downlinks When invoking IMAIL TOSS with a /!, it will process incoming mail and import it into your local message base, but it won't export any mail for your downlinks. CAUTION! USE THIS SWITCH ONLY IF YOU REALLY, REALLY WANT IT! 7.2. SCAN - Scan for Outgoing Mail This invokes the echo/net mail SCAN function. The message base(s) will be searched for outgoing net and echo mail, exporting it to packets. If the messages are echo mail, a packet will be generated for each of the downlinks listed for the area; a net mail message, on the other hand, will be exported to a MSG-style file, and placed in your net mail directory, where it can be pack routed with IMPACK - IMAIL will leave them as they are. Regarding echo mail, SCAN will use the origin address as specified in the IMSETUP Area Manager, rather than trying to extract this information from the message header. To speed up SCAN, the Echomail.Bbs and Netmail.Bbs (for the QBBS message base) and the echotoss-logfile (for the Jam, Squish and *.MSG areas) as specified in IMSETUP are used to determine whether new messages have been entered since the last run of SCAN. Without these files, SCAN does not check the message bases. In such a case, you should use the /F commandline parameter. - /F - Force Complete SCAN If for any reason you suspect that IMAIL has not scanned out all the the mail which should be exported, run it with the /F switch. This will bypass the use of the ECHOMAIL.BBS, NETMAIL.BBS and/or the echotoss log files generated by the BBS and/or message editor and the whole base will be scanned. Nobody's perfect! For this reason, you should use this parameter at least once a day (for example before packing the message bases). - /F<Areatag> - Force Single-Area-Scan Forced SCANning can become quite longish as message bases grow and areatags are subject to inflation. To avoid dumb waiting, it is also possible to explicitly scan a single echo that you suspect of not having been scanned properly. - /H - only Hudson If you wish to have IMAIL process only the Hudson message base 7.2. SCAN - SCAN FOR OUTGOING MAIL - 57 - =========================================================================== (QuickBBS or RemoteAccess), then you may run SCAN with the /H switch. - /S - only Squish With this switch, IMAIL will only process Squish areas. To avoid messages being unsent, IMAIL keeps track of the Echotoss.Log and Echomail.Jam files. - /M - only *.MSG When invoked with /M, IMAIL will only scan *.MSG areas. IMAIL will also keep track of the Echotoss.Log and Echomail.Jam files. - /J - only Jam Having IMAIL SCAN called up with /J, it will only scan Jam-type areas. Needless to say that IMAIL will maintain Echotoss.Log and Echomail.Jam, too. 7.3. The midnight maintenance Once a day, at the first time IMAIL is invoked since midnight, it will perform a maintenance run in which it executes the following functions: - Statistics When running for the first time that day, IMAIL updates the message area statistics you can view in the area manager by pressing <Shift-F7> It also updates the statistics for inactive areas, though. - Killdead IMAIL will issue a request to the uplink to unlink all echos which have been without traffic for a certain number of days. You can specify the period an echo may be without traffic separately for each echo. In "Special Parameters" - "Kill Dead handling" (chapter 6.2., page 29, you can control which echos are affected, either all, only the forward requested echos or no echo at all. Every area which has been dead the last day is marked during the midnight maintenance and only then, so the area record will only show integer numbers of dead days. - Deadlink Nothing is perfect and especially programs are not. It may well happen that a (forward) request is not processed at the uplink's system and your systems considers an echo dead that simply hasn't been linked at all. To avoid this, IMAIL now has the ability to try to relink an area that has been dead for a certain duration (see 6.2., page 29). The (re)link request will be issued at all uplinks in the forward request manager that have the doubtful area(s) in their forward list. In the area action log, this will be logged with DEADLINK. - Unlink requests It may well happen that an area is only linked to one system, when either all downlinks unlink or all downlinks set themselves to %PAUSE. According to the finding that this situation is wasting resources (you will poll for the NUL-device if you don't read the echo yourself!), IMAIL will also consider this echo to be dispensable. If - 58 - 7. IMAIL - COMMAND LINE OPTIONS =========================================================================== you have set the field "Unlink requests" in the "AreaLink Options" to anything other than 'N', the switch "auto maint" in the area record to 'Y' and the uplink is listed in the forward link manager, IMAIL will issue an unlink request to this last system and mark it as "Unlinked". As soon as one of your downlinks requests this echo again or issues a %RESUME, the echo will be relinked at your uplink. IMAIL will then reset the dead-day-counter for that area to avoid an immediate dead-deletion. 8. IMCOMP - COMPRESS ARCMAIL BUNDLES IMCOMP is used to compressed outgoing mail into ARCmail bundles and to generate a file attach message or a binkley style flow file. For this, IMCOMP searches the temp outbound directory for PKTs addressed to a node. The order in which IMCOMP processes the nodes is defined via the pack priority setting in the node manager. In FrontDoor/Intermail-environments, IMCOMP will search the netmail for existing file attaches to the destination nodes. While doing this, IMCOMP deletes all ARCmail attaches for which the associated ARCmail-bundle (i.e. the file) does not exist (anymore). IMCOMP will log this action. In Binkley/McMail-environments, IMCOMP will save the file date/time information of the processed flow files and restores this information after updating the flow file. This way, IMCOMP makes it possible to see when a bundle has been created (many programs don't care, making it impossible to check the creation date of the bundle). Then, IMCOMP will create a directory with unique name (UNIX- timestamp) "under" the temp outbound directory and move all PKTs for this system into it. At last, the compression program is called to compress all PKTs therein into an ARCmail bundle. If the destination system is listed in the Node Manager, the appropriate compression program will be called to compress the packet; otherwise, the first program listed will be used (by default, ARC). IMCOMP is usually called after IMAIL, IMPACK and IMALNK, not after EACH call, but after having called ALL programs needed. This is the reason why IMCOMP has been isolated to an additional program, because now the time-intensive compression job can be done when mail-mangling is finished. When calling IMCOMP with the commandline-parameter /P, PKTs for nodes with a lower pack priority is ignored and not compressed. The following is important when working in a multitasking or network environment: When compressing outgoing mail, IMAIL fully supports the FrontDoor 2.20c and the InterMail 2.21 crc-semaphores and the Binkley BUSY-flags. So IMAIL can work while your mailer is still online. BUT: IMAIL must be used in an environment with a TASK environment variable different from all mailers online. To ensure that things don't go wrong, IMCOMP will use the TASK 255 if no environment variable is defined. Without this support (like under FrontDoor 2.02) you should NOT leave your mailer online while IMAIL is compressing because it may cause file access problems and loss of mail. 9. IMPACK - PACK NET MAIL MESSAGES This is it: IMAIL's taking-the-horror-out-of-routing, it`s space- saver, it's speed-up-your-mailer-tool, the net packer! The IMAIL Netmail Message Directory will be searched for outgoing net mail messages, which will be moved into packets according to the information given on the command line or as specified in IMSETUP (see chapter 6.8., page 53). Later, these PKTs may be compressed using IMCOMP. In the following, 'compressing' means transferring into packets. Note that this command operates only on MSG style messages. Netmail messages in the Hudson/Squish/*.MSG/Jam message areas will be exported by the SCAN command and thereafter treated as normal netmail. The syntax of IMPACK is: IMPACK [/N] [/C] [/D] [/H] [/R] [/?] [address] [[address] [...] VIA address] The elements in square brackets (meaning: everything) are optional. 'address' represents a network address in the usual zone:net/node.point - format, where the point field is optional (see below). {tt /?} again will present a short help text. As with IMSETUP, the net, node and point fields may be replaced with the '*' macro. If you omit the zone field, the zone defined for your primary network address will be used by default. Messages addressed to point systems will be packed along with the mail for its bossnode. Netmail for YOUR points will never be pack routed via another node, unless explicitly forced. IMPACK can only handle 4D-addresses, it ignores 'fakenet'-addresses, so care should be taken that net mail destined to a fakenet address is never pack routed out of your point net. IMPACK will ALWAYS need a 'VIA' system specified, unless you only specify ONE system, then its mail will be compressed and sent to itself. IMPACK * therefore is merely tomfoolery, the '*' wildcard specifies 'various' systems, not only one. IMPACK * VIA 2:2/1 Better. Much better. All mail for your primary zone will be compressed and sent to 2:2/1 (we remember: * will become 2:* if your primary address is in zone 2). IMPACK 2:* 5:* VIA 2:2/1 will send everything for zones 2 and 5 to 2:2/1. When run with commandline arguments, IMPACK will act on them, AFTER which it will process the default routing commands given in IMSETUP, which means that you may override the defaults. If no parameters are given on the command line, IMPACK will simply act on the defaults. - 61 - =========================================================================== Messages marked as Crash, Hold or Direct will only be processed and packed if forced with the /C, /H, /D and/or /R switches (described below). Messages which are file attaches, file requests, update requests, or which have the IMMediate or LOCKed status will NEVER be packed. - /N - No Default Pack Routing If for any reason you wish IMPACK to ignore the defaults given in IMSETUP, suffix the switch /N to the command line. In this case, IMPACK will simply process the command line. Note that the command IMPACK /N effectively tells IMPACK to do NOTHING, except for allocating memory and CPU-time... :-) (/N tells to ignore the defaults and since no routing commands are given, there`s nothing more to do than abort.) - /C - also pack 'Crash' messages - /H - also pack 'Hold' messages - /D - also pack 'Direct' messages If you specify this switch without the switch /R, IMPACK will pack messages which are marked as Direct only to the system itself, the message will be compressed, but will remain to be sent direct. That means that IMPACK 2:all via 2:310/0 /D has no effect on direct mail for 3:310/11. - /R - Pack Route Direct If you specify the /D switch (see above), net mail messages will not be pack routed unless they are being packed to their destination. This behaviour can be overridden with the addition of the /R switch. In this case, IMPACK will pack route net mail marked as Direct as though this flag had not been specified. Use this switch with care, since the Direct flag is NOT stripped from the net mail message, and might cause your uplink considerable grief! Please check with your uplink before using it! Note that if the /D switch is NOT specified, this switch will have no effect. 10. IMALNK AreaLink is a function which allows other systems to request echos from your system without the need for you to manually insert them in the areas' export list. It is similar in function to AreaMgr (which is part of TosScan), or to AreaFix. AreaLink is not fully compliant with FSC-0057 (rev 3), but will implement full compliance with one of the next releases. What happens is this: a system sends a message addressed to IMAIL on your system. Instead of the subject, he places a password. In the body of the message will go the list of areas to which the other system wishes to be linked, or areas which he no longer wishes to receive. The system may also request information from IMAIL by including one or more of the supported meta-commands. The remote maintenance is executed via Arealink requests, too. In order to be able to use AreaLink, a system must be defined in your Node Manager (See section 6.2., page 22). When the request is processed by AreaLink, it will check that the password given on the subject line of the message matches the one defined in the node manager. AreaLink will only allow a system to request areas belonging to one of the groups to which he has access. If an unknown system requests access or a known system uses a wrong or no password at all, IMALNK will notify the sysop by creating a little netmail. Please note that IMALNK will NOT handle kludge lines (i.e. lines in the message beginning with ^A (0x01)). When IMALNK scans the netmail, it will show a little wandering dot on the screen. This way, you can control if IMALNK is still working. This was implemented for some less patient sysops with big netmail folders who suspected IMALNK hung when it simply needed some time to scan all mail... IMALNK is also a handy tool when editing a node's area record. AreaLink creates a netmail for the edited node, notifying him/her about the things that were changed. When allowing rescan requests you should consider that IMALNK only creates the PKTs for the downlink but does not compress them into the ARCmail bundles. You will have to call IMCOMP for that purpose! - 63 - =========================================================================== 10.1. Format of the Request As outlined above, a request to AreaLink takes a specific format. Here is an example: From : John Doe on 2:2480/55 To : IMAIL on 2:2480/47 Subject : <password> [-L] [-A] [-I] [-Q] [-U] [-E] [-P] [-R] +SYSOP = Request to add area +SYSOP,R = Request to add area with rescan +SYSOP,R=10 = Add area with rescan of the last 10 mgs +SYSOP,R-O = Add area read-only +SYSOP,W-O = Add area write-only =NEWS = Request to update area =NEWS,R = Request to update area with rescan =NEWS,R=20 = Request to update area with rescan of the last 20 messages. =NEWS,R-O = change linked area to read-only =NEWS,W-O = change linked area to write-only =NEWS,R-W = switch linked area back to 'normal' (=read and write) -PENPAL = Request to remove area %HELP = Send help on AreaLink usage %INFO = Send general information %LIST = Send available area list %AVAIL = Send forward-request list %QUERY = Send active area list %LINKED = Send active area list %UNLINKED = Send list of unlinked but available areas %LINKCHECK = Request for a message to the sender's Arealink program containing a request of all linked areas. %NOTE = Begin a message to the sysop %PAUSE = Temporarily stop exporting msgs %UNPAUSE = Resume exporting messages %RESUME = Resume exporting messages %RESCAN = Request to rescan new and updated areas %PWD xxxxx = Request for password change %COMPRESS xxx = Change compression program %RULES <ON/OFF> = check, set or reset send rule status %FROM z:n/nd.p = Execute request for <address> ~FRIENDS = Request for remote deletion %DROP FRIENDS = Request for remote deletion &TEST = Request for remote creation %ADD TEST = Request for remote creation #OLD.ECH NEW.ECH = Request for name change %CHANGE OLD.ECH NEW.ECH = Request for name change All names, the password, area names and meta-commands may be given in any combination of upper and lower case. For the commands in the subject line (the ones after the password), a slash ('/') can also be used instead of the hyphen ('-'). They invoke certain AreaLink functions the way the meta commands would (for an explanation see the paragraphs of the corresponding - 64 - 10. IMALNK =========================================================================== meta-commands): '/L' or '-L' equals %LIST '/A' or '-A' equals %AVAIL '/I' or '-I' equals %INFO '/Q' or '-Q' equals %QUERY '/U' or '-U' equals %UNLINKED '/E' or '-E' equals %LINKCHECK '/P' or '-P' equals %PAUSE '/R' or '-R' equals %RESUME As can be seen, in order to request an area to be added, the name of the area may be prefixed with a plus ('+') sign, whereas to have a area removed, it MUST be prefixed with a minus ('-') sign. The plus sign is optional. Wildcards may be specified within area names. AreaLink recognizes and handles the following: * Matches 0 or more characters. For example, IM*L will match IMAIL. ? Matches a single character. So ?MAIL will match IMAIL and FMAIL. [a-d] Matches any character in the range 'a' to 'd' Note that requests may be addressed to any one of: IMAIL , AREALINK , AREAFIX , AREAMGR AreaLink will recognize any of the above "names". Optionally the message may end in a tear line ('---'), followed by any text (usually a message to the sysop). In this case the request will only be deleted if this was specified in the AreaLink options of IMSETUP (see chapter 6.2., page 19). 10.2. Arealink Replies Having processed a request, AreaLink will reply to the sender of the message. This message will contain a list of the areas linked or unlinked and the result of meta-commands. If enabled (see section 6.2., page 20) IMALNK will also respond to 'unknown' systems. Even if IMALNK may not process these requests, it writes a logentry and sets the message to 'rcvd' The message will normally be flagged 'Kill/Sent' unless there is another setting in the AreaLink options of IMSETUP (see chapter 6.2., page 19). The request mail will normally be deleted, too. You can inhibit the deletion in the AreaLink options. 10.3. META-COMMANDS - 65 - =========================================================================== 10.3. Meta-Commands IMAIL supports several meta-commands in AreaLink requests. These are: - %HELP This meta-command will make Arealink send a bestseller: "The cry for help" from Are A. Link. Nominated for the pulizer prize, it containes virtual help for the use of AreaLink. The filename of the help text to be sent may be defined in IMSETUP; a sample text came along with IMAIL. - %INFO This sends some general information (packer used, AreaLink password, attach status,...) to this system. - %LIST The %LIST meta-command will have AreaLink reply with a list of all the areas available to the requesting system on your system. In other words, those which are marked as Active, not Hidden and which belong to a group listed as available for that system. The whole list will be sorted by groupnumber and areatag (in that order). The echos requested via forward request that have not yet arrived will be appended to the end of the list. - %AVAIL Since %LIST does not actually list all areas a system has access to, this meta-command was implemented. %LIST does only send the list of areas contained in your configuration, but it doesn't reveal what areas a system has access to via the forward request. With %AVAIL, the requesting system will get a list compiled from your forward request lists. (see chapter 6.7., page 51). - %QUERY or %LINKED If the message contains this meta-command, AreaLink will reply with a list of currently active echos for the requesting system, sorted by group. - %UNLINKED This meta-command is, in a sense, the complement of %QUERY and %LIST. In other words, it will send a list of all available echos which are NOT currently linked to the requesting system. Of course, this list will also be sorted by groupnumber. - %LINKCHECK With this meta-command, a downlink who suspects any mishaps with their links may request your IMALNK to send a complete link request of the linked areas and a complete unlink request of the unlinked areas to his arealinker. This function is called link check. It will only run if the node has something entered in the "Program Name" of their node record, for otherwise IMALNK does not know which program to address... (see also chapter 6.5., page 47) - %NOTE This meta-command is used to introduce a comment to the sysop. It is equivalent to adding a tear-line in the message body, but the use of %NOTE is preferred. AreaLink requests containing a tear-line or a - 66 - 10. IMALNK =========================================================================== %NOTE will only be deleted once processed if this is explicitly stated in IMSETUP. - %PAUSE If a sysop wishes to temporarily unlink from ALL echos, then he may send a message to AreaLink with the %PAUSE command. This will cause the receiving (your) system to stop exporting echo mail without deleting the node from the export list for the echo areas to which he is linked. - %UNPAUSE or %RESUME That will reverse the effect of a %PAUSE command (see above). It will reactivate the suspended link. - %RESCAN This meta-command will allow a node to request that IMAIL send all old mail in the areas requested. For example, if a system requests to be linked to the SYSOP echo, and places a %RESCAN meta-command in the message text, IMAIL will link the system, and then scan your message base for any messages in this area, and send them to the requesting system. All the exported messages will have the same SEEN-BY lines as they normally would, thus (hopefully) preventing duplicates. However, the messages will be exported only to the system requesting the rescan, not to all linked nodes. In order to prevent the system which requested the rescan from sending the messages out to other systems, AreaLink will insert a special kludge into the message: ^ARESCANNED <addr> where <addr> is the address of the system which requested the rescan. Note that if you have set the "Rescan OK" option in IMSETUP to "no" (see chapter 6.5., page 48), then the rescan request will be ignored. - %PWD <new password> With this meta-command, a sysop can change the password he uses to make AreaLink requests to your system. Note that if no new password is specified, AreaLink will NOT respond with the current password, for reasons of security. - %COMPRESS <program> This allows sysops to request that your system use a different compression program be used to create ARCmail files bound for their system. If no valid compression program is given, AreaLink will respond with a list of the available programs. <program> should be the three character name for a compression program as defined by the sysop in IMSETUP. - %RULES <ON / OFF> Using this meta-command, the remote sysop can check their 'send rule'-status (see next section). Adding a 'ON' can be used to switch the rule support on, \%RULES OFF disables the rules support for this system. 10.4. THE RULE SUPPORT - 67 - =========================================================================== 10.4. The rule support Many if not most (fidonet-)areas are run by a moderator who laid down some rules for "his" echo. Most moderators post their rules once a month or so. Additionally, the rules are often distributed in a filenet. A user who links a new echo either has to wait until the moderator posts their rules or issue a filerequest to their bossnode in order to get the rules. This behaviour is somehow complicated and anachronistic in the age of automatic mail processors. The users who need the rules most are also the ones who are the least likely to wait for the rules... Therefore, IMAIL has a built-in rule support. When you turn on the switch <Send rules> in the node manager (see 6.5., page 50) Arealink will send the rules of the requested area via netmail whenever a system links to an area (even when it is a forward request). An update request, however, will not be answered with rules. You have to ensure the following for the rule support to work correctly: Set the global rules path in IMSETUP (see chapter 6.2., page 16). Then copy all of your rulefiles into that directory. The rule file name has to be set for each area in the areamanager (see 6.4., page 35. IMALNK will add the text header in IMRULE.HEA if that file exists in the IMAIL home directory. If no rule file name is defined or IMALNK did not find the file, IMNORULE.HEA will be sent instead. That file also is expected in the IMAIL home directory. When an area is autocreated and a path to the rules is defined, IMAIL will search the rules for the areatag of the new area (if the rules conform to the rule header used in Germany) and will add the rule name to the area record when a matching rule is found. 10.5. Remote Maintenance AreaLink will allow you to give partial control of your areas configuration to another system: Any system which has Remote Maint (see chapter 6.5., page 48) enabled in the Node Manager will be able to add, delete or rename one or more echo areas from your system. Furthermore, this node may execute AreaLink requests in behalf of other systems. If a node includes commands of the remote maintenance in their AreaLink request although he is not eligible for it, AreaLink will send a reply with a refusal of obey. The commands for remote maintenance are: - %FROM <full node number> The %FROM meta-command will allow another system to make requests "on behalf" of another system. This is particularly useful for remote maintenance of someone else's system. The address must include - 68 - 10. IMALNK =========================================================================== the zone and point fields of the system which will be linked (or unlinked). Note that the password (subject) of the message must be correct for the system SENDING the message, not for the system for which the changes will be made. The generated reply will be sent, again, to the system which sent the request, not to the one for which the changes were made. - %DROP <Areatag> Equivalent to ~<Areatag> This feature is useful if, for example, you wish to allow your boss or host system to automatically delete an area when it has been discontinued. The meta-command %DROP is fully equivalent to the command '~'. When AreaLink processes such a request, it will first send a net mail message to any other systems which are linked to that area, warning them that it has been deleted. It will then flag the area as deleted and inactive, so that any requests to link to it will be ignored. The next time IMSETUP is run, and the Area Manager entered, the area will be removed completely from the list. - %ADD <Areatag> Equivalent to &<Areatag>. This command allows creation of an area remotely (as if the area is sent by a system which is allowed to create areas). - %CHANGE <old areatag> <new areatag> Equivalent to #<old> <new>. A system which has Remote Maint privileges on your system may request a change of area name. What this will do is simply to change the name of the area and advise all other downlinks of this variation by sending them a netmail; no other variations will take place. Place one or more spaces between the old areatag and the new one. The requesting system also has to be linked to this echo. 10.6. Local Maintenance IMAIL also allows 'his' sysop to use AreaLink as if another sysop had sent a request. This can be done by using one or more of the command line switches described below. When run from the command line, AreaLink is designed to mimic its behaviour when it is parsing a request from another system. (For more information on the single meta-commands, see section 10.3. above.) The advantage of using AreaLink to make changes instead of doing it from IMSETUP is that a net mail message will be generated automatically, informing the system of the changes made. Note that each switch may appear only ONCE on the command line. However, the /+ and /- switches may make use of the '*' wild card. For multiple changes, it will be necessary to run AreaLink several times. When specifying the systems with /N, you may replace zone, net node or point number by an asterisk ('*'). Other wildcards are NOT implemented yet. The complete syntax accepted by AreaLink is: IMALNK /N<address> (system to make changes for) 10.6. LOCAL MAINTENANCE - 69 - =========================================================================== /+<area> (link area) /+<Area>,r (link area with rescan) /+<Area>,r=nn (link area with rescan of n msgs) /+<Area>,R-O (link area read-only) /+<Area>,W-O (link area write-only) /-<area> (unlink area) /=<area> (update area) /=<Area>,r (update area with rescan) /=<Area>,r=nn (update area with rescan of n msgs) /H (send helptext) /I (send info) /L (send list of available areas) /A (send list of forward request areas) /Q (send list of linked areas) /U (send list of unlinked areas) /E (relink linked areas = link check) /P (pause export of areas, local %PAUSE) /R (resume sending, local %RESUME) /D<area> (delete area, local %DELETE) /C<old:new> (change areatag, local %CHANGE) If you omit the /N parameter, AreaLink will act on behalf of YOUR system. Thus most of the other switches are meaningless. In particular, that is /+, /-, /=, /H, /I, /L, /Q, /U, /E, /P, /S and /R. If the /N switch is used, a net mail message will be generated for that system, specifying the changes made. If this switch is NOT used, everything but /D, /~, /C, /# will be ignored and a net mail message will be generated to you. Preceeding the letters, you can use a hyphen instead of the slash if you want to, IMALNK will process both. 11. IMTHINGS IMTHINGS is a program containing additional utilities for use with IMAIL. It is used giving it a command and additional parameters, which vary according to the command given. All of the commands give a brief on-line help if followed by the /? switch. To get an overview of the functions of IMTHINGS, give IMTHINGS /?, whereas IMTHINGS SEND /? will briefly explain the options of SEND. In most cases, the commands may be abbreviated to one or two letters; for example IMTHINGS KILL may be given as IMTHINGS K. However, IMTHINGS SORT must be abbreviated to IMTHINGS SO since the SEND command also begins with the letter 'S'. Supported message bases are indicated by a letter, as follows: M =*.MSG H = Hudson (QuickBBS or RemoteAccess) S = Squish J = Jam PLEASE NOTE: The Squish MSGAPI which is used in IMAIL and IMTHINGS has a built-in limit regarding the number of messages it can handle during certain operations. This limit is just over 5300 messages. So it is suggested that you keep each Squish message area under this limit. 11.1. IMPORT (MHS-) Import Net Mail Messages The IMPORT function allows you to import net mail messages from the net mail directory into the net mail area of the message base. This is necessary if you wish to allow the users of your BBS to read net mail addressed to them. It will scan the net mail directory for net mail messages addressed to one of your AKAs, and if found, import (i.e. copy) them into the net mail area which corresponds to that AKA if it is not - a file request - an update-request - addressed to a name in the IMSETUP-No-Import-List. Once imported, the MSG file will be deleted. See chapter 6.2., page 21 on the No-Import-List. - /S - strip crash bit from imported messages 11.2. EXPORT (----) Export area configuration EXPORT can be used to export your Area-Manager configuration on a automated basis for other programs to use or to send it to your downlinks. EXPORT can create the de-facto-standard AREAS.BBS, include-files for the message-editors TimEd and GoldEd, FIDONET.NA-files and Echolists for the point-package YUPPIE!. EXPORT can be invoked with the following parameters: IMTHINGS EXPORT /TA AREAS.BBS /TT TimEd-areafile 11.2. EXPORT (----) EXPORT AREA CONFIGURATION - 71 - =========================================================================== /TG GoldEd-areafile /TF Fidonet.NA-list /TY Yuppie-echolist /SE (only include echomail areas) /SN (only include netmail areas) /SL (only include local areas) /G<groups to include, separated by commas> /F<filename> Let's have a closer look on each parameter: - /TA|T|G|F|Y First of all, you have to specify the flavour of the list. It may be AREAS.BBS, which can be used for re-import into another program, or an Include-File for TimEd or GoldEd (this way you are independend from struct-changes in either program). You can also create a Fidonet.NA list for your downlinks or a Yuppie!-Echolist for automated area-requests by Points using this pointpackage. - /SE|N|L You can create special lists using the /S switch. /E will only export your echomail areas and ignore local or netmail boards, whereas /L will only export your local areas. With /N, you will get a list only containing your Netmail boards. If you omit the /S parameter, EXPORT will include all types of areas. - /G<groups to include> By default, EXPORT will include all groups; but you may as well specify a list of group numbers it shall export. This may well result in a longish commandline... - /F<filename> Finally, you can specify a filename for the export list. EXPORT has the following defaults: /TA: AREAS.BBS /TT: TIM_AREA.INC /TG: GED_AREA.INC /TF: FIDONET.NA /TY: AREALIST.ECO 11.3. INDEX (-H--) Rebuild index files The INDEX command will rebuild the message base index files (MSGIDX.BBS, MSGTOIDX.BBS and MSGINFO.BBS) from the MSGHDR.BBS file. Use this if for any reason you suspect that one or more of these files have somehow become damaged. NOTE THAT INDEX IS RUN AUTOMATICALLY AFTER MOVE AND SORT. - 72 - 11. IMTHINGS =========================================================================== 11.4. KILL (MHSJ) Delete messages from an area The KILL command allows you to mark some or all messages in a specified message area as deleted. Note that KILL does NOT pack the message base, that is actually delete the messages. Use IMTHINGS PACK for this. When you KILLed Hudson messages by mistake, use RECOVER (see below). With a Hudson message base, KILL will normally create a temporary file to which it will write the new MSGHDR.BBS. If it detects that there is not enough disk space, it will overwrite the original file directly; however, this method is MUCH slower. KILL will mark every area in which it deleted messages for PACK. (see there /F) Note that it is advisable to run IMAIL SCAN /F before running this command; this will ensure that all outgoing echo mail messages have been exported. The syntax of the command is: IMTHINGS KILL /A<areaname> /B<board> /D<age of messages in days> /N<number of messages> /! (kill ALL messages) /H (only process Hudson mailbase) /S (only process Squish) /M (only process *.MSG) /J (only process Jam Areas) /U (kill according to IMSETUP) /F (kill msgs with a future date) /O (kill unallocated boards) - /A<areaname> If specified, the /A switch should be followed by the name of one of the echo areas, as given in the Area Manager. If this switch is used, then the /B switch should NOT be given. NOTE: IF YOU SPECIFY THE /U SWITCH, THIS SWITCH WILL BE IGNORED. - /B<board> If specified, the /B switch should be followed by a message board number. In this way, it is possible to "act" on message board not defined in the IMSETUP Area Manager (for example, local message areas). If the /B switch is used, then the /A switch should NOT be given. If you do not specify one of /A or /B, then KILL will act on ALL message boards, unless the /U switch is given (see below). - /! - /D<age of messages in days> - /N<number of messages to be killed> With the /D parameter, you specify that KILL should keep messages younger than the given AGE in number of days. /N keeps the specified NUMBER of messages and marks the rest as deleted. 11.4. KILL (MHSJ) DELETE MESSAGES FROM AN AREA - 73 - =========================================================================== If both switches are specified, KILL will meet BOTH conditions, it may happen that it leaves less than <number> if there were too much old messages. It may also happen that "new" messages are deleted when they exceed the maximum specified in <number>. Invoked with /!, KILL shows its diabolical potency and marks ALL messages in the specified area(s). Omitting both /D and /N and also /U, you will get the same result. When the /U switch is given, /D and /N will be ignored. - /M, /H, /S and /J If you only want the Hudson message base to be processed, you can advise KILL to do so by setting the /H switch. /S will cause KILL to process only the Squish Areas, /M assignes *.MSG areas for KILLing and /J will "doom" Jam-Areas. - /U - Use Default Information from IMSETUP This parameter tells IMTHINGS KILL to use the information given in IMSETUP to determine how many messages to kill. It will operate on all boards defined in the Areas Manager, leaving the given numbers of messages in the board, or deleting all messages older than the given number of days. PLEASE NOTE: IF YOU USE THE /U SWITCH, THE /A, /B, /D AND /N SWITCHES WILL BE IGNORED IF ALSO SPECIFIED. - /F - Delete messages with future date The headline says it all: /F will have KILL 'delete' all messages whose date is somewhat 'above' today's. It will thus kill these messages that make believe that they are to be written in some days... :-) - /O - Delete messages in undefined boards In conjunction with /U this parameters tells KILL to kill all messages which are in hudson boards not defined in the IMAIL Area Manager. PLEASE NOTE: TAKE CARE THAT ALL YOUR LOCAL BBS BOARDS ARE DEFINED IN THE AREA MANAGER OF IMSETUP TO PROTECT THEM FROM BEING DELETED WHEN USING THIS SWITCH. 11.5. NETKILL (----) Handle 'deceased' links Of course, the title of this section is a euphemism. This function is nothing less than brute force. Look and see... - /K<days> This switch allows you to have NETKILL delete old ARCmail files and their respective file attaches. The <days> parameter indicates the age of the message; in other words, ARCmail files which are older than the given number of days will be deleted. If you choose to use this switch, it is recommended that you advise your downlinks, so that they know that should pick up their mail before it is sent into oblivion... This feature works best in FrontDoor- or Intermail environments (or in - 74 - 11. IMTHINGS =========================================================================== any other environment that makes use of the fileattach-method) because NETKILL uses the file attach netmails to get the necessary information. For those who use Binkley or any other mailer using flow-files (.FLO or similar), things are quite different: NETKILL only works if NONE of the programs used on the system touches the timestamp of the flow-files. If the time/date information is updated, NETKILL will always assume that this bundle is quite 'fresh' and things will never work... Unfortunately, only very few programs behave this way, IMAIL is kinda trailblazer for this behaviour. Allfix and the forthcoming release of ITRACK leave the timestamp alone, however. - /P<days since last poll> IMTHINGS offers the possibility to "pause" all systems that have not polled since the period given with /P<days>. These systems have to issue a %RESUME to get mail again. NETKILL will notify your downlinks that they are paused. This again only works flawlessly in FrontDoor/Intermail-environments, for Binkley (or similar) systems, there are the restrictions outlined above. 11.6. LINK (MHSJ) Link Messages in Message Base LINK scans the message base, looks for messages with similar subject lines, and from them, creates links for each message, which point to the previous message in the chain, and the next message. In order to update the links between the messages and their replies, run IMTHINGS LINK after each arrival of echo mail, or at least once a night. Note that the case of the subject line is not significant; thus "Echo mail" and "Echo Mail" will match when creating links. Note however that the search is performed ignoring any leading "RE:" (or anything like it) in the subject line. IMAIL marks Jam/Squish/*.MSG areas when tossing new mails into them which is used by LINK to skip areas without new messages. This can be overridden by using the /F commandline switch. LINK also works with local areas, but you will have to specify the /F-switch to tell IMTHINGS to do so. - /C - Clear subjects This will remove all occurrences of "RE:", "RE^xx:" and "RE:^xx:" (in upper and/or lower case) from the message subject lines. Otherwise, the "RE:" strings will be left in place, but still ignored when the link search is being done. - /F - force complete link of Jam, Squish and *.MSG areas - /M, /H, /S and /J You can specify if only the *.MSG-Areas (/M), the Hudson mailbase (/H), Squish (/S) or Jam (/J)-type areas shall be processed. 11.7. MOVE (MHS-) MOVE MESSAGE AREA - 75 - =========================================================================== 11.7. MOVE (MHS-) Move Message Area The MOVE command allows you to move all the messages from one board or area to another. The syntax of the command allows you to specify the source and destination areas either by area name, by board number or by area path: IMTHINGS MOVE /R<src areatag> |/S<src board> |/F<src path> /T<dst areatag> | /D<dst board> | /P<dst path> You may use only ONE way to specify source or destination, but you might well mix them, for example IMTHINGS /RTEST_ECHO /D150 will be perfectly all right. When using /F and /P, please note that MOVE will test if the destination area is of MSG type (in this case, you specify a path name) or of Squish/Jam (you should give a pathname with the name stem of the areabase then). Please note that all messages moved will have the Outgoing Echo, Outgoing Net and Net mail bits cleared, so that they will not be SCANned out again by mistake, thus creating confusion in the network. 11.8. PACK (MHSJ) Compress message base In Hudson, Jam and Squish message bases, when you delete a message, it is not actually removed from the base, but rather is just marked in a special way. PACK will allow you to remove from the message base those messages marked as deleted, thus recovering unused disk space. In *.MSG message areas, this concept does not exist, since messages are physically deleted; so PACK will simply renumber the message area. For Hudson areas, PACK will normally create temporary files to which it will write the new MSGHDR.BBS and MSGTXT.BBS files. However, if it detects that there is not enough free disk space to do this, it will overwrite the original files; this method is considerably slower. Squish- and Jambase will be handled accordingly. In order to make PACK faster on Hudson areas, it does not try to update the 3 index files; instead of this, it will call IMTHINGS INDEX after having completed. The same is valid for JAM areas, IMTHINGS will automatically reindex it after having completed packing. It also doesn't care about message links, it might be desirable to run IMTHINGS LINK after a PACK. PACK will update the USERS.BBS file (if it is found) as well as LASTREAD.BBS (this file keeps track of the last messages read in each message area) and the appropriate lastread files of the other message base types. It will leave them untouched if the filesize of the userbase does not fit the number of records detected.If this comparison of the userbase with the record size failes, PACK will note it in the logfile. - 76 - 11. IMTHINGS =========================================================================== Note that it is also advisable to run IMAIL SCAN /F before packing the message base. This will ensure that all outgoing echo mail messages have been exported. Optionally, it is also possible to have PACK renumber all net mail messages. - /B - Keep Backups will tell PACK not to delete the backup files which comprised the original message bases - /P - Pack IMAIL.AR causes PACK ONLY to remove deleted or duplicate area records in IMAIL.AR (when an area is deleted, it will only be MARKED as deleted, but will remain in the database). When /P is given in the command line, all switches except /D and /O will be ignored. - /O - Sort sort IMAIL.AR alphabetically when packing it. - /D<days> - Delete unlinked areas When specified together with /P (and only then), IMTHINGS will remove all unlinked areas from the area database while packing it so these areas will no longer appear on your list of linkable echos. If you specify a number after the '/D', IMTHINGS will only delete area records which have been unlinked for at least this number of days. - /M, /H, /S and /J (again) serve to restrict operation of PACK to *.MSG (/M), Hudson (/H), Squish (/S) or Jam (/J) areas. - /R - Renumber Netmail this will have PACK renumber all net mail messages. In FrontDoor / Intermail multiline environments, IMAIL will touch the RESCAN semaphore. CAUTION! PACK DOES NOT CHECK WHETHER THE NETMAILS ARE CURRENTLY ACCESSED BY A / THE MAILER. ENSURE THAT THE NETMAIL FOLDER _can_ BE RENUMBERED SAFELY BEFORE EXECUTING THE RENUMBERING COMMAND. - /F - force packing By default, PACK will only process those areas which have been marked by KILL. This mark will be set if KILL actually deletes messages in an area. That way, you won't let PACK run over areas that have nothing to pack. But for reasons yet unknown, you may wish PACK to process really everything and this is what this switch is for... - /U - Update SqKill-values When you use the Squish-Kill-feature, the value of messages you specified will be written to the squish message base files. If you change that value for an area, it would be updated only when you pack the base(s). Now you can have IMTHINGS to write the new values to the squish bases without packing them all. NOTE: MESSAGE BASE PACKING WILL BE SKIPPED WHEN USING /U ! 11.8. PACK (MHSJ) COMPRESS MESSAGE BASE - 77 - =========================================================================== 11.9. POST (MHSJ) Post message in echo area The POST function will allow you to post a message in an echo area. It is particularly useful for posting echo message statistics, for example. The message will be cut into several pieces if bigger than the maximum message size specified in IMSETUP. The syntax of the command is: IMTHINGS POST /F<filename> /A<areaname> /B<board> /W<to_who> /R<from_who> /S<subject> /1 - /F<filename> The /F switch is used to specify the name of the text file to post as the message. This file should be a simple ASCII file, containing no special control characters. This parameter is required. - /A<areaname> - /B<board> To specify the name of the echo area in which to post the message, use the /A or the /B switch. The name of the area may be given with /A in upper or lower case, or any combination of the two. You can also give the number of the Hudson message board, which is especially useful for boards not entered in the IMSETUP area manager. NOTE: USE ONLY ONE OF THE TWO WAYS TO SPECIFY THE AREA. - /W<to_who> You may optionally specify the name of the person to whom the message is addressed. If this parameter is omitted, the message will be addressed to 'All'. If the /W parameter is used, the name should contain no spaces; replace the spaces with underscores: /WTest_User - /R<from_who> By default, POST will use the name defined in the Sysop field in IMSETUP to indicate the name of the sender of the message. If you want to use another name, specify it after the /R switch. The name should contain no spaces; replace any spaces with an underscore. - /S<subject> You may also specify the subject of the message with the /S switch. If this parameter is omitted, the message subject will be 'News'. If you do use this parameter, the text following the switch should contain no spaces; replace them with underscores. For example: /STest_message_#1 - /1 When invoked with /1, POST will insert the first line of the given textfile also in the subject line. - 78 - 11. IMTHINGS =========================================================================== 11.10. RECOVER (-H--) Unerase messages The RECOVER command will allow you to "undelete" messages in your Hudson message base. Naturally, it will only work if you have not PACKed the base. By default, RECOVER will "undelete" messages found in any message area, prompting you at each message. However, you may specify that it look for messages in a specific area, and that it automatically recover all deleted messages it finds. - /A<areaname> or - /B<board> allows you to indicate the target of your rescue operation. You can EITHER give the areatag (/A) or the board number (/B). Giving the board number allows you more flexibility, since local message areas might not be defined in the Area Manager, and therefore would have no name so the /A switch cannot be used. - /U - Automatic Mode. If this switch is given, RECOVER will not prompt you at each message. Instead, it will "undelete" all messages it finds (if /A or /B are specified, only messages in the specified message area will be recovered). 11.11. SEND (----) Send a file The SEND command invokes the IMAIL Robot. This will allow you to send a file and/or message to another system, much like any other Robot program. The syntax of the SEND command is: IMTHINGSSEND /F<filename> /T<textfile> /A<address> /W<to_who> /C (Crash) or /I (Immediate) or /H (Hold) /D (Direct) /K (Kill/Sent) /E (Erase/Sent) /Y<days> /N<1-49> /! If a file name is given with /F, and the required file is found, a file attach message will be generated in your Net Mail directory. However, it is also possible omit the file name, and simply specify a text file (with /T). In this case, a net mail message will be generated, with no attached file. You can thus send a netmail depending on the age of a certain file (/Y). Note that either a file or a message text (or both) must be specified; if both are omitted, SEND will exit with an error. - /F<filename> Indicates the full pathname of the file to be sent. This parameter is not required if you simply wish to send a net mail message. If the filename contains wildcards, only THE FIRST MATCHING FILE will be sent. If the full path is not supplied, IMTHINGS will use the current drive and path when generating the file attach message. Note 11.11. SEND (----) SEND A FILE - 79 - =========================================================================== that if the file has zero length, it will NOT be sent. - /T<textfile> This switch allows you to specify the name of a text file to be used as the "body" of the file attach message. If omitted, the message will have no text. It may also be used to generate a normal net mail message if the /F parameter is not given. - /A<address> Specifies the destination address of the file.The address should contain the zone, otherwise the zone of your primary address will be used by default. THIS PARAMETER IS REQUIRED. - /W<to_who> You may optionally specify the name of the person to whom the file is being sent. If this parameter is omitted, the message will be addressed to 'Sysop'. If the /W parameter is used, the name should contain no spaces; replace the spaces with underscores: /WTest_User - /C - Mark message w. 'Crash' status. - /I - Mark message w. 'Immediate' status. When you give both /C and /I, the parameter that is given last will override the other one. - /H - Mark message w. 'Hold' status. When you specify /H, it will both override /I and /C, because a 'Hold' flag and a 'Crash' flag together could somehow confuse the mailer (In fact, it's a plain contradiction). - /D - Send message w. 'Direct' status 'Direct' means that this message will in no case be routed via another system. It may be used together with the /C, /I or the /H option. Use this flag only if your mailer supports the FLAGS DIR kludge (see chapter 13.1., page 89). - /K - Kill/Sent Marks the message as Kill/Sent. In other words, once sent, the message will be automatically deleted from your Net Mail directory. Otherwise, it will remain, but be marked as Sent. - /E - Delete/Sent Marks the message as Delete/Sent. This will cause the mailer to delete the file once it has been sent. Use this flag only if your mailer supports the FLAGS KFS kludge (see chapter 13.1., page 89). - /Y<days> - Newer than Indicates that the file must be newer than <days> for it to be sent. This is useful for sending nodelist files, as you can then specify a wildcard in the filename, and indicate that the file be sent only if it is newer than, say, 6 days. - /N<0-49> - Alternate Address or AKA With this switch, you may specify which of your addresses should be used when sending the file. If /N is not specified, SEND will attempt to find an address which best matches that of the destination system. If /N is specified, it may take one of several forms: /N or /N0 - your primary address /Nx - AKA 'x' (with x between 1 and 49) - 80 - 11. IMTHINGS =========================================================================== /N<addr> - where addr is a full network address. - /! - send message without attach This switch allows to create messages without fileattach and realizes a POST function for the netmail. (You will get the same result if you only omit the /F-parameter) 11.12. SORT (-H--) Sort the Message Base The SORT function will sort the Hudson message base by message date. What it does is to read in the MSGHDR.BBS file, saving the message number and time stamp. The list thus created is sorted, and then the MSGHDR.BBS file is rewritten, following the order of the new message numbers. NOTE THAT THE SORT COMMAND DESTROYS THE MESSAGE INDEX FILES, SO IT AUTOMATICALLY CALLED INDEX ONCE FINISHED. SORT also updates USERS.BBS (if found) and LASTREAD.BBS; this may account for the last message number read being suddenly moved; previously "older" messages have a newer date and/or time. SORT comes with two switches: - /L - Link Messages after Sort Since SORT destroys the message links, you may wish to have it call LINK after processing has completed. This can be done by specifying /L on the command line. - /Q - "Quick" Sort The /Q switch forces a "quick" sort. In other words, only those messages numbered higher than the highest lastread pointer will be sorted. The advantage of this is that your users will not have to read old messages again. The disadvantage is that, due to the way certain message editors assign new message numbers, it is possible that a small number of "old" messages will be overwritten. Thus it might be advisable to run IMTHINGS PACK prior to calling SORT with this switch. When invalid lastread.bbs-numbers are encountered, SORT accounts for that by creating a logfile-entry. 12. AN OVERVIEW OF ECHOMAIL Information derived from FTS-0004. 12.1. What is Echo Mail? Echo Mail is a technique which permits several nodes in a network to share messages. All systems sharing a given echo see any messages entered into the echo by any of the participating systems. This can be implemented in such a way as to be totally transparent to the users of a particular system. In fact, they may not even be aware of the network being used to move their messages about from node to node! This has its disadvantages. Users who are not familiar with Echo Mail do not realize that the messages transmitted cost MANY sysops money, not just the local sysop. This is an important consideration in Echo Mail and should not be taken lightly. In an echo with 100 participating systems the transmission costs per message can get quite high. 12.2. How it Works In general, the process is: 1. A message is entered into a designated area (often called "echo") on a FidoNet compatible system. 2. This message is "exported" along with some control information to each system "linked" to the echo through the originating system. 3. Each of the receiving systems "import" the message into the proper Echo Mail area. 4. The receiving systems then "export" these messages, along with additional control information, to each of their links. 5. Return to step 3. The method is quite simple in general. Of course, following the steps literally would mean messages would never stop being exported and transmitted to other systems. This obviously is not desirable as the network would quickly become overburdened. The information contained in the 'control information' section is used to prevent transmitting the same message more than once to a single system. 12.3. Some notes on Addresses In order to send a message from the originating system to the destination, there has to be a method of addressing. You can try names, of course. Ever seen a New York phonebook? Ok, something else. In the world of FidoNet-compatible networks, a so called 4D-address is used. Let's have a look at one: 2:2480/141.42 The punctuation marks divide the address into four parts, these are the four dimensions of an address. That's why it is called 4D-address. The first number indicates the ZONE to which the system belongs. The zone number may be more than one-digit, but trouble is at hand when - 82 - 12. AN OVERVIEW OF ECHOMAIL =========================================================================== you use a zone number higher than 255. The zone number is used to indicate the bigger geographical environment of the system, in our example it's Europe. The second part of the address is the NET. With the net number, you can usually determine the nearer location of this system. In our example, it's southern Bavaria in Germany. Following after the net, there is the NODE. A nodenumber is assigned to an individual system. The last number is the POINT. Points are systems which can not be contacted directly via mailer. Therefore, they hold an address "behind" their node, which is often called "bossnode". Since the 4D-address is a newer development, some mailers cannot handle it. These have to use a "fakenet" to address their points, a small network which only exists between the bossnode and their points. This should be enough for our purposes, you can find more detailed information elswhere! 12.4. Echo Mail Message Control Information There are five items of control information associated with an Echo Mail message. Some are optional, some are not. Normally this information is not entered by the person creating the message, but rather is added by the program which is responsible for the exporting of the original message. The following control fields determine how Echo Mail is handled: 12.4.1. Area Line This is the first line of an echo mail message. Its actual appearance is: AREA:CONFERENCE where CONFERENCE is the name of the echo. This line is added when a conference is being "exported" to another system. It is based upon information found in the configuration file for the designated message area (in the case of IMAIL, this file is IMAIL.AR). This field is REQUIRED by the receiving system to "import " a message into the correct Echo Mail area. Note that IMAIL will not handle echo mail messages which "kludge" this field by putting a ^A character in front of it; these messages will be tossed into your net mail directory. Note also that you may not have two areas defined with the same area name; this would create cross-linked messages, which are a potential source of duplicates. 12.4.2. Tear Line This line is near the end of a message and consists of three dashes (---) followed by an optional program specifier. This is used to show the first program used to add Echo Mail compatible control information to the message. The tear line generated by IMAIL looks like this: --- <a small product-specific banner> 12.4. ECHO MAIL MESSAGE CONTROL INFORMATION - 83 - =========================================================================== This field is optional for most Echo Mail compatible processors. Some systems will place this line in the message when it is first created, but it is normally added when the message is first "exported." 12.4.3. Origin Line This line appears near the bottom of a message and gives a small amount of information about the system where it originated. It looks like this: * Origin: IMAIL Development (2:2480/47) The " * Origin: " part of the line is a constant field. This is followed by a banner which should in some way identify the system which originated the message. This is fiction. Reality is that the origin line is used for everything from aphorisms to political exclamations. But this is not really serious, as long as the first part and the address is correct. The complete network address (2:2480/47 in this case) is added by the program inserting the line. This field is generated at the same time as the tear line, and therefore may either be generated at the time of creation or during the first "export" processing. 12.4.4. SEEN-BY Lines There can be many SEEN-BY lines at the end of Echo Mail messages, and they are the real "meat" of the control information. They are used to determine the systems to receive the exported messages. The format of the line is: SEEN-BY: 132/101 113 136/601 1014/1 The net/node numbers correspond to the net/node numbers of the systems having already received (or "seen") the message. In this way a message is never sent to a system twice. In an Echo with many participants the number of SEEN-BY lines can be very large. This line is added if it is not already a part of the message, or added to if it already exists, each time a message is exported to other systems. This is a REQUIRED field, and IMAIL might not function correctly if this field is not put in place by other Echo Mail compatible programs. IMAIL and other mail processors use this field to check whether one of your downlinks has already seen this message (which normally only occurs due to errors in the distribution topology). Depending on the configuration, IMAIL notifies you and/or does not export this message to this system. - 84 - 12. AN OVERVIEW OF ECHOMAIL =========================================================================== 12.4.5. PATH Lines These are the lastlines in an Echo Mail message. They appear as follows: ^APATH: 132/101 1014/1 where the ^A stands for Control-A (ASCII character 1) and the net/nodes listed correspond to those systems having processed the message before it reached the current system. This is not the same as the SEEN-BY lines, because those lines list all systems the message has been sent to, while the path line contains all systems having actually processed the message. 12.5. Methods of Sending Echo Mail To this point the issue of how Echo Mail is actually sent has been glossed over entirely. The phrase has been, "the message is exported to another system." What exactly does this mean? In principle, the messages could be copied once for each receiving system, then addressed for it, placed in the netmail folder (the AREA:-line identifies them as conference mail) and sent by the mailer. Thus generating a huge number of messages, the mailer would soon be overburdened, and so would the phone bill... Echomail is today sent in so-called ARCmail-bundles. Thom Henderson (from System Enhancement Associates) came up with the original ARCmail program. Having previously written the ARC file archiving and compression program, he knew the savings achievable by having all of the Echo Mail messages placed in .ARC format for transmission. As a by-product, the messages no longer appeared in the net mail area, but were included in a file attached to a single Net Mail message. In this way the tremendous number of messages generated, and the phone bill problems were both solved. When IMAIL sends Echomail, the following happens: The message to be sent is copied once for each system (just like our principle). This copy is placed in a special directory called "Temp Outgoing Packets" and gets a special format called Packet or PKT. If a system receives more than one message, these are also included in one or more PKT. The PKT also includes the sender's and the receiver's address, it is a kind of netmail. Having copied all messages, IMAIL calls a compression programm which turns the PKTs into one ARCmail-bundle. When importing, IMAIL does the same in the ooposite direction. 12.6. Topology The way in which systems link together for a particular Echo is called the "echo topology." It is important to know this structure for two reasons: - it is important to have a topology which is efficient in the transfer of the Echo Mail messages; - it is important to have a topology which will not cause systems to 12.6. TOPOLOGY - 85 - =========================================================================== see the same messages more than once. Efficiency can be measured in a number of ways; least time involved for all systems to receive a message, least cost for all systems to receive a message, and least phone calls required for all systems to receive a message are all valid indications of efficiency. Users of Echo Mail compatible systems have determined (through trial and error) the best measure of efficiency is a combination of all three. Balancing the equation is not easy, but some guidelines can be given: 1. Never have two systems attempting to send Echo Mail to each other at the same time. This results in "collisions" which will cause both systems to fail. To avoid this, one system should be responsible for polling while the other system is holding mail. This arrangement can alternated based upon various criteria, but both systems should never be attempting to call each other at the same time. 2. Have nodes form "stars" for distribution of Echo Mail. This arrangement has several nodes all receiving their Echo Mail from the same system. In general the systems on the "outside" of the star poll the system on the "inside". The system on the "inside" in turn polls other systems to receive the Echo Mail that is being passed on to the "outside" systems. / / B / \ / C----A----F /| / | D E 3. Utilize fully connected polygons with a few vertices. Nodes can be connected in a triangle or a fully connected square (all corners of the square send to all of the other corners). This method is useful for getting Echo Mail messages to each node as quickly as possible. A / \ / \ B-----C All of these efficiency guidelines have to be balanced with the need to prevent the export of duplicate messages. Duplicates will occur in any topology which forms a closed polygon which is not fully connected. Take for example the following configuration: A ---- B | | | | C ---- D This square is a closed polygon that is not fully connected. It is capable of generating duplicates as follows: - 86 - 12. AN OVERVIEW OF ECHOMAIL =========================================================================== 1. A message is entered on node A. 2. Node A exports the message to node B and node C placing the SEEN-BY for A, B, and C in the message as it does so. 3. Node B sees that node D is not listed in the SEEN-BY and exports the message to node D. 4. Node C sees that node D is not listed in the SEEN-BY and exports the message to node D. At this point node D has received the same message twice - a duplicate was generated. Normally a "dupe-ring" will not be as simple as a square. Generally it will be caused by a system on one end of a long chain accidentally connecting to a system on the other end of the chain. This causes the two ends of the chain to become connected, forming a polygon. 12.7. Why a PATH line? The PATH line stores the net/node numbers of each system having actually processed a message. This information is useful in correcting the biggest problem encountered by nodes running an Echo Mail compatible system - the problem of finding the cause of duplicate messages. How does the PATH line help solve this problem? Take the following path line as an example: ^aPATH: 107/6 107/312 107/528 107/312 132/101 This shows the message having been processed by node 107/312 on more than one occasion. Based upon the earlier description of the 'information control' fields in Echo Mail messages, this clearly is an error in processing (see section 12.2. entitled "How it Works"). This further shows node 107/528 as the node which apparently processed the message incorrectly. In this case the path line can be used to quickly locate the source of duplicate messages. The circular path detection of IMAIL recognizes such errors and allows you to stop such duplicate messages. IMAIL checks whether your system is already in the path line. But as the path does not contain zone information (and net/node combinations might be the same in different zones, IMAIL also checks whether the systems before and after your nodenumber are in the list of linked systems of this echo. If this is also true, a circular path has been detected. In an Echo with many participants it becomes almost impossible to determine the exact topology used. In these cases the use of the path line can help a coordinator of the Echo track any possible breakdowns in the overall topology, while not substantially increasing the amount of information transmitted. Having this small amount of information added to the end of each message pays for itself very quickly when it can be used to help detect a topology problem causing duplicate messages to be transmitted to each system. 12.8. GATING OF ECHO MAIL - 87 - =========================================================================== 12.8. Gating of Echo Mail There was a time when the only network which made use of the methods described above was FidoNet. However, new networks have appeared, and the problem of sharing Echo Mail between these networks arose. (To avoid ambiguity, the term "domain" was introduced to distinguish between networks such as FidoNet and SIGnet.) Sharing (or gating) of Echo Mail presents technical problems. Put simply, the network addresses which are valid in one domain may not appear in the messages of another domain. The reason for this is that, if we consider only the net and node fields of a network address (many mail processors are not able to handle the zone and point fields), there is a high possibility that a given address exists in another domain. With net mail, this problem may be solved by enforcing the requirement that inter-domain mail be sent directly to its destination, or at least, to a gateway system. Concerning Echo Mail, the problem is more complex due to the information contained in the SEEN-BY and PATH lines (as described above). These lines contain network addresses, and are needed to prevent duplicate rings. However, a strategy has evolved which will allow Echo Mail to be gated: Above all, only ONE system should be allowed to gate Echo Mail between domains. This may be done on a world-wide or Zone-wide basis. This system will be responsible for receiving the mail from one domain, and feeding it into the other. This is not enough. Due to the possibility of duplicate network addresses, all SEEN-BYs and PATH lines should be removed during the gating process. This explains why only one system should be allowed to gate Echo Mail. 13. KLUDGE LINES AND CAPABILITY 13.1. A brief explanation of Kludge Lines For the more technically minded, find following an explanation of the various kludge lines IMAIL may place in messages. A kludge line is generally defined as any line preceded by a ^A (Control-A) character, and may be found either before the message text itself, or after it. 13.1.1. EID (Echomail IDentification) The EID is used only in Echo Mail messages. IMAIL does NOT add this kludge to echo messages. It was 'invented' mostly for reasons of dupe checking, but IMAIL will use other methods for this purpose. The format of the kludge varies; according to the specification proposed by Jim Nutt, it may be: ^AEID zddd nnnccccc where z is the zone modulo 16, ddd is the net modulo 4096, nnn is the node modulo 4096, and ccccc is a message serial number. The serial number is generated using the low order word of the Unix time stamp shifted left 4 bits, with a nybble counter appended. (confused???) 13.1.2. FLAGS This kludge is present in net mail messages only, and is used by many mailers to give more information on how the message should be treated. It is followed by one of more modifiers; some of the more common ones are listed below. - DIR (DIRect) Indicates that the net mail message should be sent direct to its destination; it will NEVER be routed. IMAIL allows you to specify whether mail should be marked DIRECT or not. See the description of the Node Manager (chapter 6.2., page 22) - IMM (IMMediate) Indicates that a message should be sent immediately. IMAIL will never use this, and will always ignore it. - TFS (Truncate File when Sent) This is found only in file attach messages, and indicates that the file should be truncated when sent. ARCmail file attached generated by IMAIL will have this flag set, it you don't set it up differently. - KFS (Kill File when Sent) Kill File when Sent. This is found only in file attach messages, and means that the mailer will delete the file once sent. - CFM (ConFirMation Receipt Request) This flag is set if the sending system wishes to have an acknowledgement that the message was read. As such, IMAIL does not intercept this flag; it is up to the message editor to handle it. - RRQ (Return Receipt Request) 13.1. A BRIEF EXPLANATION OF KLUDGE LINES - 89 - =========================================================================== This flag is set if the sending system wishes to have an acknowledgement that the message was received by your system. Currently, IMAIL does not recognize this flag, since the message header itself defines a similar bit. If the bit is set, IMAIL will automatically generate a reply to the sending system. 13.1.3. FMPT (FroM PoinT) The FMPT kludge is used in net mail messages only. It is similar to the TOPT kludge, except that it is used to indicate that the message originate from a point system. The format of this kludge is: ^AFMPT <orig point> where <orig point> is the point component of the address of the system originating the message. 13.1.4. INTL (INTernationaL/INTerzonaL) The INTL kludge is used in net mail messages only. It indicates that the message is destined to a zone which is different from the one in which it originated. The format of the INTL kludge is: ^AINTL <dest zone:net/node> <orig zone:net/node> IMAIL will use this kludge to try to determine zone addresses, as well as adding it to net mail messages it generates. Note that in multi-domain environments (ie, systems which belong to more than one domain, and thus more than one zone), IMAIL will put an INTL kludge in ALL net mail messages it generates, even if the destination and origin zones are the same. 13.1.5. MSGID (MeSsaGe IDentification) A MSGID kludge is used in all messages, be they net mail of echo mail messages. They are automatically added by IMAIL when it generates messages (Automatic Reply, AreaLink's messages, etc), and used in duplicate checking. The format of the MSGID follows the specification of FTS-0005 by Jim Nutt, which is: ^AMSGID: zone:net/node[.point]@domain xxxxxxxx where zone, net, node and point are the address of the originating system, and domain is the domain of the originating system (eg. FidoNet, SIGnet, etc). xxxxxxxx is a serial number which is derived from the originating system's address, a Unix time stamp, and an internal counter. IMAIL will automatically supply the domain by attempting to derive it from the list of domains specified in IMSETUP (see chapter 6.2., page 13). If the zone number is not recognized, no domain field will be added. - 90 - 13. KLUDGE LINES AND CAPABILITY =========================================================================== 13.1.6. PID (Product IDentification) The PID (Product ID) is appended by IMAIL to all messages it generates. Following the specifications given by Joaquim Homrighausen, the format of the kludge is: ^APID: <product> <version>[ <serial number>] For example, IMAIL 1.75 would generate the kludge as follows: ^APID: IMAIL 1.75 13.1.7. REPLY The REPLY kludge is simply a copy of the MSGID of the message to which you are replying. IMAIL currently does not generate this kludge. The format is as for MSGIDs: ^AREPLY: zone:net/node[.point]@domain xxxxxxxx 13.1.8. RESCANNED IMAIL inserts this kludge in messages which have been exported in response to a %RESCAN request. This way, when they are processed by TOSS, they will not be exported to other systems thus potentially creating dupe rings. Currently there are only a few mailprocessers which support this kludge, so it is by no means a fail-safe method of preventing dupes. Rescanning echo mail is ALWAYS dangerous, and until some robust and standard method is adopted, it is best to avoid rescanning altogether. The format of this kludge (according to FSC-0057) is: ^ARESCANNED <addr> where addr is the address of the system which requested the rescan. 13.1.9. TID (Tosser IDentification) The TID is appended by IMAIL to all messages when exporting them from the message base. The format of the klugde is the same as with PID. 13.1.10. TOPT (TO PoinT) The TOPT kludge is used in net mail messages only. It is used to indicate that the message is directed to a point system, rather than a "normal" node. The format of this kludge is: ^ATOPT <dest point> where <dest point> is the point component of the address. For example, a message addressed to 2:310/11.22 will have: 13.1. A BRIEF EXPLANATION OF KLUDGE LINES - 91 - =========================================================================== ^ATOPT 22 while the message header will contain the address 310/11. 13.2. A Note about Capability The term Capability, when referring to a mail processor, indicates that program's ability to generate zone and point information in outgoing mail, as well as the ability to recognize and use such information in inbound mail. Currently, IMAIL distinguishes between two forms of capability: "Stone Age" and "Type 2+". "Stone Age" means that the packet contains no zone and/or point information, and thus IMAIL is forced to guess at their value; "Type 2+" indicates that the packet contains zone and point information, and IMAIL knows where to look for them. IMAIL also recognizes "Type 2.2" PKTs and handles them properly. "Type 2+" mail packets are distinguished from the others by means of a Capability Word and a Capability Word Validation Copy (as outlined in the document FSC-0039). However, there are several mail processors which produce valid zone and point information, but do not mark the packets as "Type 2+". In order for IMAIL to correctly extract the zone and point fields from these packets, they must be marked as be marked as Capability : Type 2+ Cap Handling: Forced in the Node Manager (see chapter 6.2., page 22). In other words, you should enquire as to which mail processor the node is using, and set these two fields accordingly. - 92 - 13. KLUDGE LINES AND CAPABILITY =========================================================================== 13.2. A NOTE ABOUT CAPABILITY - 93 - =========================================================================== \ Examples of mail processors which produce Type-2+ information are: Product Product Code ---------------- ----------------- BBCscan CE D'Bridge 1A Fastecho AF Fmail 81 FrontDoor 0C GEcho 61 IMAIL 4B MailLink 9D Qmail 29 RA-Echo 8C ScanToss 82 TosScan 3F ZmailQ 35 Some of these do not (yet) make use of the Capability Word, but it is possible to "tell" IMAIL that a mail processor has Type 2+ Capability by indicating its product code in IMSETUP (see chapter 6.2., page 21). For other mail processors, if your are uncertain of their capability then it is best to set the two capability fields to "Stone Age" / Auto. 14. HOT HINTS AND INFO 14.1. Interrupting IMAIL You can interrupt IMAIL's operation by either - pressing Esc - simultaneously pressing Ctrl and 'C'. - simultaneously pressing Ctrl and Break. - creating a file 'IMAIL.BRK' in the semaphore directory. This affects IMAIL, IMTHINGS, IMALNK, IMPACK and IMCOMP. You can create the IMAIL.BRK file with the DOS command CD.>IMAIL.BRK when you are in the semaphore directory. TOSS, however, will not abort instantaneously, but will finish the PKT being processed; IMTHINGS will finish handling the Hudson base before aborting. Whenever working in IMSETUP: 14.2. Use Esc carefully! We received complaints that inputs are not or not always saved when leaving an input window. This trouble arouses from the fact that IMAIL handles the 'Esc' key literally: It escapes. Thus, it will NOT save anything you have previously entered or changed, in some cases even without asking for your confirmation. Your inputs will only be saved when you press F10. This may differ from your usual procedure, so better check twice to see if your input has really been saved and you did not press Esc before using F10... 14.2. USE ESC CAREFULLY! - 95 - =========================================================================== 14.3. setting compression \& space settings correctly When configured correctly, IMAIL will never fill your harddisk to the last byte nor confront your downlinks with huge ARCmail bundles, nor compress endless PKTs. To ensure this, you have - amongst others - the configuration items Nr. of PKTs to pack per call Max. PKT size (set in the node manager or preset in Max. ARCmail size 'NodeMgr defaults', chapter 6.2., Diskspace before Unpack Diskspace before Toss Diskspace before Compress (set in 'Space settings', chapter 6.2. page 23). 14.3.1. ''be kind to my downlinks'' [...inspired by A. Klein himself...] When creating PKTs and ARCmail bundles (if you are unsure about the technical terms, have a look at, IMAIL and IMCOMP are controlled by three space settings: <Nr. of PKTs to pack per call> <Max. PKT size> controls the size a PKT may have before IMAIL begins a new one. <Nr. of PKTs to pack per call> tells IMCOMP how many PKTs to give over to the compression program at a time. <Max. ARCmail size> at last controls how big an ARCmail bundle may be to have IMCOMP add another set of PKTs. <Max. ARCmail size> does NOT control the overall size of the created bundles, but sets the trigger on which IMCOMP adds further PKTs. As long as the bundle is smaller, IMCOMP will add another { Nr. of PKTs to pack per call} PKTs to the bundle. The resulting size may well be extremely bigger than <Max. ARCmail size>. The following example shows how to configure IMAIL so that ARCmail bundles remain smaller than a certain size. In our example, the bundles shall occupy 400kB in general. The bundles must not exceed 500kB. The compression program has a ratio of 3:1 and the PKTs generated have 200kB. The bundle will grow by 400kB if you compress six PKTs at a time: Growth = 200kB * 6 (PKTs) / 3 = 400kB If you don't want bundles to exceed 500kB, you must subtract the growth from the maximum size: <Max. ARCmail size> = 500kB - 400kB = 100kB In the worst case, a 99kB bundle will grow by 400kB, thus reach, but not exceed the 500kB boundary. The smallest bundle will occupy - 96 - 14. HOT HINTS AND INFO =========================================================================== 100kB. Generally: ARCNORM = normal size of the ARCmail bundle ARCMAX = maximum size of the ARCmail bundle ARCMIN = minimum size of the ARCmail bundle <Max. PKT Size> * <Nr. of PKTs to pack per call> ARCNORM = --------------------------------------------------------- Ratio of the compression program <Max. ARCmail Size> = ARCMAX - ARCNORM = ARCMIN 14.3.2. ''be kind to my harddisk'' If a program writes to the disk until everything bursts, things get bad. If this program runs unattended, things get worse. But if you really need the data now getting lost, things amount to a catastrophe. A tosser normally runs unattended and the data it processes can be vital. Therefore, a tosser should be extremely flexible upon encountering tight diskspace. Of course, I wouldn't write this if IMAIL would not meet this demands. The configuration items needed for this kindness to disk and data are located in the "space settings"-menu. It will be explained in chapter 6.2., page 23. Quite a lot of people get confused by this flexibility, especially by the <Diskspace before ...>-settings. For those of you, here's a little introduction: 1) You have configured IMAIL never to create ARCmail bundles bigger than 750kB (see above). This means that for a short period of time, twice as much space is needed on your harddisk: Most compression programs create a temporary file during their operation and copy them to the final file at completion. If you haven't explicitly configured the compression program to create this temp file on another disk, IMCOMP will need double space (grin): 2 * 750kB = 1.5 MB Generously, you enter a '2' into IMSETUP's <Diskspace before Compress>. This ensures enough free space for IMCOMP to work properly. (Your generousity of course covers up that IMSETUP cannot save floating point numbers...) example. 2) After a normal poll, you handle around 2000 mails with a compressed size of 3 MB. The compression program has a ratio of 3, the additional diskspace needed for the extracted PKTs is 3 MB * 3 = 9 MB <Diskspace before Unpack> should consequently be set to a value higher than 9 to ensure enough free space for IMAIL to unpack the received bundles. When tossing these 2000 mails, you export about 10000 mails to your 14.3. SETTING COMPRESSION \& SPACE SETTINGS CORRECTLY - 97 - =========================================================================== downlinks. This meanst that your export ratio is 10000 / 2000 = 5. TOSS will create five times more outbound mail, meanwhile deleting the inbound PKTs. The space needed can be calculated as following: 3 MB * 3 (ratio) * 5 = 45 MB! To avoid problems when beginning to compress the PKTs created, you have to add the space needed by the compression program, the value entered in <Diskspace before compress>. <Diskspace before Toss> should have a value above 47. Therefore, you give IMAIL enough space to distribute the received mail completely to your downlinks. Here are the generalized equations: MAILIN = size of received ARCmail. EXPORT = ratio of received and exported mails ARCMAX = maximum size of ARCmail bundles (see above) <Diskspace before Compress> = 2 * ARCMAX <Diskspace before Unpack> = MAILIN * RATIO <Diskspace before Toss> = (MAILIN * RATIO) * EXPORT + (2 * ARCMAX) [The brackets are only set for clarity reasons...] After all, these settings only cover the NORMAL course of events. To prevent problems when things aren't quite as usual, set the switch <Use IMCOMP if less disk-space>. Then, IMCOMP will be invoked whenever TOSS encounteres tight disk space to kind of 'clean things up'... 14.4. When, how and why run IMAIL programs Ok, you have decided to run one of the most powerful tossers available but you don't have a clue how to get it to work. We have talked about Echomail, now we will look at how and when IMAIL is used. Later, there will be lots of stuff about the setup of IMAIL and its utility programs, along will an example batch file. Now, I think, it's time to have a word on WHEN to run the IMAIL programs. That means HOW to arrange the programs in order to get things going and WHY. This section is only an overview. If you _do_ understand the 'why' and 'when', but have not fully come to grips with the 'how', don't worry, it will all be explained later on... 14.4.1. ''Something came in and I want it to be processed'' We assume that you just finished a call, either you polled your uplink or have received an incoming call. Anyway, there's something in your inbound, your mailer exits with an errorlevel or indicates in some other way there is incoming mail. In this case, run IMAIL TOSS This is the first program you should run when processing incoming - 98 - 14. HOT HINTS AND INFO =========================================================================== mail. TOSS will decompress the inbound ARCmail-bundles, sort incoming mail packets, import netmail into the mailer's netmail-folder, toss echo mail to the message base and so on. As you now have the new netmail in the netmail area you can check to see the caller sent you an arealink request. The program for this is IMALNK It will find the request message, change your areas database as required, forward the area request(s) if necessary and allowed and will then optionally delete the request. Because you are bothered with all the ARCmail-attaches in your netmail-folder, you have set up your own private area (which could be the same as your BBS-user's one). IMTHINGS IMPORT will move your netmail from the mailer's netmail-folder to your private one. And because you are a sysop who really uses the capabilites of your tosser (besides being troubled by complicated route files and your vast netmail-folder), you decided to compress the in-transit netmail along with the echomail. This task will be performed by IMPACK Every program that creates netmail has to be executed BEFORE IMPACK is run, otherwise netmail may be left uncompressed. By now, nearly everything is done. The somewhat most important program has been left out yet, it's IMCOMP This one compresses all the mail that was created in a temporary directory into ARCmail-bundles and makes them available for your links by creating file-attach messages or flow-files. Without IMCOMP, nothing will ever be exported from your system! 14.4.2. ''I wrote something and EVERYONE shall read it :-)'' After laying your heart into the most vital message you ever wrote, after inventing the final joke, you want your messages to be exported from your system. The first job does IMAIL SCAN It will find your new messages, look in which area it has been posted, determine the systems connected to that area and create the packets for them. IMCOMP will then compress these packets and make them available for your mailer by creating file-attaches or flow files. 14.4. WHEN, HOW AND WHY RUN IMAIL PROGRAMS - 99 - =========================================================================== 14.4.3. ''I'm not interested in yesterday!'' There's nothing more boring than yesterday's news. Especially when they take up diskspace. So, you choose a rather quiet hour of the day and run IMAIL SCAN /F IMCOMP first. It may well happen that IMAIL does not find every new mail written in the first run. The switch /F will force SCAN to check every single message if it's already sent or not. IMCOMP will then do the actual exporting... Then, every innocent new mail is hushed away and the work of IMTHINGS KILL /U can begin. This will advise IMTHINGS to mark mails as 'deleted' by the rules you set in IMSETUP. But note: The messages are only MARKED deleted. They won't bother you any more by appearing in your message reader again and again. But they will continue to consume disk space! So once in a while, say once a week, you should run the brutal exterminator of unseen mail: IMTHINGS PACK It will move every marked mail mercilessly into the oblivion called WOM ('w'rite 'o'nly 'm'emory, sometimes dubbed NUL). Thus generating fresh, sparkling free disk space! 14.5. Batch file example The example given below is designed for systems running SuperBBS, with FrontDoor as a mailer. It should be easy to modify for other setups, but I can only write from my own experience. ECHO Off :START C: CD \FD FD IF ERRORLEVEL 99 GOTO CLEAN IF ERRORLEVEL 60 GOTO SCAN IF ERRORLEVEL 50 GOTO UNPACKMAIL IF ERRORLEVEL 40 GOTO LOCAL IF ERRORLEVEL 30 GOTO LOAD_BBS IF ERRORLEVEL 10 GOTO OUT IF ERRORLEVEL 1 GOTO ERROR GOTO START :LOAD_BBS CALL DOBBS.BAT GOTO START :LOCAL BBS -L -E0 GOTO START - 100 - 14. HOT HINTS AND INFO =========================================================================== :CLEAN REM Message Areas Maintenance IMTHINGS KILL /U IMTHINGS PACK GOTO START :SCAN IMAIL SCAN IMCOMP GOTO START :UNPACKMAIL IMAIL TOSS IMALNK IMPACK IMCOMP GOTO START :ERROR CLS ECHO *** Internal Error *** Programming Error GOTO OUT :OUT ECHO System .... Down! 14.5. BATCH FILE EXAMPLE - 101 - =========================================================================== 14.6. Defaults for Compression/Decompression For reference, below are listed the default parameters for the compression and decompression programs as you would see them when installing IMAIL for the first time. 14.6.1. Compression Arc.Exe mw Arj.Exe m -c -e+ -y -i -jm Lha.Exe m /m2n1t1 Pak.Exe m /WN /ST /P PkArc.Exe -ot m PkZip.Exe -m -ex -o (PkZip Version 1.10) PkZip.Exe -m- -\verb?~? -ex -o (PkZip Version 2.04, default) Rar.Exe mf -ep Sqz.Exe aM -p3 UC.Exe A -F Zoo.Exe aMPh: 14.6.2. Decompression Arc.Exe xw Arj.Exe e -c -i -y Lha.Exe e /c1m2n1 Pak.Exe e /WA PKUnZip.Exe -ed -o PkXArc.Exe -r Rar.Exe e -o+ -y -ep Sqz.Exe e -o1 UC.Exe E -F Zoo.Exe eO - 102 - 14. HOT HINTS AND INFO =========================================================================== 14.7. Files Maintained by IMAIL IMAIL and IMSETUP create and maintain several external data files. Generally it is NOT a good idea to delete these unless you wish to rebuild your configuration from the beginning. Of these files, all those containing IMAIL's configuration information should reside in the directory you have set the IMAIL environment variable to. IMAIL.AR Contains the definitions of the echo areas. If this file is deleted, ALL echo area information will be lost. This file is updated by AreaLink, if necessary, and is usually maintained via IMSETUP. IMAIL.AI Index file of echo area information, according to area name. This file is maintained and updated both by IMSETUP and IMAIL. It may be deleted (in which case you will need to run IMSETUP to recreate it). IMAIL.BI Index file of echo area information, according to Hudson board number. This file is maintained and updated both by IMSETUP and IMAIL. It may be deleted (in which case you will need to run IMSETUP to recreate it). IMAIL.CFM Text file used when IMAIL generates a confirmation receipt request. IMAIL.DP Data base of information used to catch duplicate messages. IMAIL.DPI These files may be deleted, but then you risk missing incoming dupes. If IMAIL.DPI is missing or corrupt, IMAIL will recreate it from the information in IMAIL.DP. IMAIL.GR The Group Database with the names and the default settings for the groups. IMAIL.ND contains the information defined in the Node Manager. IMAIL.NI This one contains the names of the 'no Import' list. IMAIL.PP This file contains the packer definitions used by IMCOMP. IMAIL.PR This is a compiled version of the FTSC product code list (which is usually distributed as FTSCPROD.xxx, where xxx is a decimal number). IMAIL.RO Here, the pack routing for IMPACK is stored. IMAIL.SN The sysop names for the PERSMAIL function. ????????.$I$ A packet file (????????.PKT) that was being processed by TOSS when a system crash occured. In order to process these files, simply rename them to ????????.PKT and run IMAIL TOSS again. If IMAIL finds such files it renames them to ????????.P$$ renamed (????????.$i$) file (see above). 14.7. FILES MAINTAINED BY IMAIL - 103 - =========================================================================== ????????.P$T A packet file (????????.PKT) where IMAIL TOSS found errors while processing it. You should have been notified of this action via netmail. Oops! In the Acknowledgements, I have mentioned a product which was not named so far, so here it is: ...Scottex Toliet paper. - 104 - 14. HOT HINTS AND INFO =========================================================================== 14.8. Exit Codes and Semaphores Should an error occur while IMAIL, IMALNK, IMPACK or IMTHINGS are running, all programs will exit with an error, and set the MS-DOS ERRORLEVEL environment variable. This may be tested in a batch file, and acted upon. Listed below are the ERRORLEVELs: ERRORLEVEL Meaning ------------------- ------------------------------------ 0 No error 237 IMAIL-busy-semaphore detected. 238 Cannot create directory 239 File locking error 240 Error opening IMAIL.AI 241 Error opening IMAIL.BI 242 Index file missing or corrupt 243 IMAIL.CF not found 244 IMAIL.AR not found 245 IMAIL.ND not found 246 Error in IMAIL.CF 247 Bad version of IMAIL.CF 248 Error opening file 249 Error reading file 250 Error writing file 251 Command line parameter error 252 File not found 253 Memory allocation error 254 Disk full 255 Unknown (generic) error 14.8. EXIT CODES AND SEMAPHORES - 105 - =========================================================================== - 106 - 14. HOT HINTS AND INFO =========================================================================== \ When no error has occured, IMAIL will set one or more of the following semaphore files, which then can be used for your own special purposes: IMAIL.NET TOSS/SCAN processed net mail. IMAIL.ECO TOSS/SCAN processed echo mail. IMAIL.BAD TOSS/SCAN processed bad mail. IMAIL.HUD TOSS/SCAN processed QuickBBS areas. IMAIL.MSG TOSS/SCAN processed Msg areas. IMAIL.SQU TOSS/SCAN processed Squish areas. IMAIL.JAM TOSS/SCAN processed JAM areas. IMAIL.PER TOSS found mail to the sysop. IMAIL.NAR TOSS created new area. IMAIL.NRM TOSS found too many msgs in incoming PKTs. IMAIL.BRK IMAIL-executable will abort operation on detection of this file. IMAIL.BSY One of the IMAIL-programs is running in a different task or on a different machine. IMAIL.LCK No changes are possible in IMSETUP due to another IMAIL executable running. 15. IMAIL REGISTRATION SITES 15.1. Headquarters Alpha's Node - IMAIL Development System: FidoNet 2:2480/47, PB-Net 246:6107/0 Internet alpha@alpha.schiele-ct.de Snail Mail: Andreas Klein, Haindlfinger Str. 1, 85354 Freising, Germany 15.2. Italy IMAIL Support & Distribution Italy System: FidoNet 2:332/432 Snail Mail: Alessandro Bonfiglioli, Via G. Mazzini 111/2, 40137 Bologna, Italy 15.3. Benelux IMAIL Support & Distribution Benelux System: FidoNet 2:284/130 Snail Mail: Roelof Heuvel, Postbus 1245, 5900 BE Venlo, The Netherlands 15.4. Denmark IMAIL Support & Distribution Denmark System: FidoNet 2:235/22 Snail Mail: Michael Wolthers Sadelmagerporten 2,329 2650 Hvidovre Denmark - 108 - 15. IMAIL REGISTRATION SITES =========================================================================== 15.5. England IMAIL Support & Distribution England System: FidoNet 2:2502/9 Snail Mail: Peter Hargroves 52 Bridgegate, Howden DN14 75Q England 15.6. North America/Latin America IMAIL Support & Distribution North America/Latin America System: FidoNet 1:10/100 Snail Mail: Pablo Kleinman, 4250 Coldwater Canyon, Suite 203 Studio City, CA 91604-1936, U.S.A 15.7. Australia IMAIL Support & Distribution Australia System: FidoNet 3:632/350 Snail Mail: Bob Snowdon, 17 Witham Drive, Coldstream, Victoria, Australia 3770