============================================================================= Idefix.man - the manual for Idefix 0.5 (public pre-release) ============================================================================= COPYRIGHT, DISTRIBUTION, AND LICENSE ==================================== Idefix is copyrighted © 1994,1995 by Metin Savignano, all rights reserved. This program is copyrighted software. It is brought to you under the concept of shareware. This means that it may be freely spread (copied), provided that the original archive is maintained, and no file thereof, or part of it, is removed, especially this manual. If, after a test period of at most 30 days, you find this program useful, you have to register it. To do so, fill out the registration form included as REGISTER.TXT and send it to me in a mail. The shareware fee is currently set to DM 20 or US$ 15, but I reserve the right to change that when new versions are being released. Idefix currently requires no key file, but this may change in future versions. If so, registered users will be sent their key file. Registered users will also be notified of new releases via routed netmail. Please support the shareware concept! What is Idefix? =============== Idefix is a little white dog that lived some 2,000 years ago. His most prominent feature was his love for trees. In addition to this, Idefix also is an Areafix program for TrapToss which in return is a Fido mail tosser by René Hexel. Idefix relies on being used together with TrapToss, and will not work with any other tosser. However, this might change in the future, should there be any interest for it. Why Idefix? =========== I have started writing Idefix because no other Areafix program for TrapToss that I found was able to suit my needs, or my personal taste, whatever. ;-) I therefore started writing Idefix which I hope will be the Areafix program of choice for some other TrapToss users, too. Idefix has been written with greatest comfort in mind. This applies to both the sysop and the point. However, keep in mind that this is still a pre-release version. Several features I have in mind are still missing. But I am working on it. Features currently available: - Works tightly and comfortably with TrapToss. - Well beta-tested on several Amiga systems. - Optionally backs up your TrapToss.cfg before any modifications are done. - LIST, QUERY, UNLINKED, and HELP may be requested either as % commands, or as subject shortcuts. - Remote maintenance using %FROM supported. - Supports area access restrictions. - Supports areas that downlinks MUST subscribe to. - Automatically forwards requests for areas that you do not yet carry to the appropriate feed, and adds them to your config as pass-thru. - Automatically detaches pass-thru areas from your feed, if the last downlink detaches from them. - Supports both, separate configuration files, or the global configuration file concept (GCF), as in fido.cfg. - Obtains as much information as possible from TrapToss's config file, keeping you from configuring the same stuff in a dozen different files. - Designed with hardly any built-in limit, all resources are dynamically requested, if and when they are required. - Automatically uses your appriopriate AKA for the reply. - Remote maintenance for other downlinks using %FROM. - And some more features. Idefix will not do a filefix job. I am not sure, if and when this will be implemented. Please let me know your opinion on this. Requirements ============ In order to use Idefix you need - AmigaOS 2.0 or higher (if you're still using 1.3, you're a hopeless case! :) - TrapToss 1.50 or higher - At least one downlink :-) Installation ============ Installation is easy. Simply CD to MAIL: and unpack the archive. Everything should be in its place, if you use the directory structure provided by TrapDoor and TrapToss. If you don't, just copy Idefix to your favourite directory. Next, you will have to setup Idefix's configuration file, as well as put some additional lines in that of TrapToss. Security ======== Before I start describing the keywords, I will have to give you an idea on how the access checking is intended to work. Access to a certain area, as well as access by a certain system, is defined by a so-called access string. This is a string (in quotes) that contains several, or one, or no, access words. A system requesting an attach to or detach from a certain area needs to have all access words in its access string that appear in the area's access string. An example will make it clearer: say, a system is defined with an access string of "LOCAL FIDO AMYNET". The area it wants to attach to is defined with an access string of "LOCAL AMYNET". Now, since all words in the area's access string are contained in the system's access string, this system will be granted access to the area. If however, the same system would want to attach to an area that had an access string of "AMYNET SYSOP", no access would be possible, as the system is missing the SYSOP access word. Thus, an area with an empty (or no) access string, will be available to anyone. A system with an empty (or no) access string will be able to access no area except those that have an empty (or no) access string, too. All access strings are case-insensitive. Additionally, each message from any system will require the session password in the subject field, of course, as given by using SetPasswd or setup in TrapList's config (obtained from traplist.library). Global keywords =============== The following keywords will be searched for in the global section of the GCF, or in TrapToss.cfg. For more information on them, please refer to TrapToss.man. Note: Whenever "TrapToss.cfg" is mentioned, any other configuration file name may be used. If you are using the GCF (usually named "fido.cfg"), using the file name "TrapToss.cfg" implies referring to the TrapToss section of the GCF. NETMAIL Used to obtain the netmail directory. Required. No default. ZONE Used to obtain the default zone. Probably subject to change! Optional. Defaults to the zone in NODE. Required if NODE contains none. NODE Used to obtain your system's main address. Probably subject to change! Required. No default. POINTNET Used to obtain your node's pointnet (fakenet). Required, if some of your points use a pointnet. However, forcing their reader to always use INTL is preferable, since if a fakenet is used in netmails, Idefix is unable to determine the correct domain and will fall back to your default domain and address. No default. AKA Used to obtain your AKAs, i.e. the addresses your are known under as well. Optional. No default. DOMAIN Used to obtain the address(es) you are known under in other nets. Optional. No default. SYSOP Used to obtain the name under which requests are to be forwarded, and to which sysop copies will be sent. Optional. Defaults to "Sysop". NODELISTPATH Used to obtain the directory your nodelist is in. Required. No default. These keywords may be overridden by putting them into Idefix.cfg, too. However, I can see absolutely no use in this, except, perhaps, for tests. Most of the time, TrapToss and Idefix working with different config files will rather cause strange problems to occur. So, use this feature only if you know what you are doing. TrapList section only keywords ============================== The following keyword is taken solely from TrapToss.cfg. There is no way to override it in Idefix.cfg. This is because both programs have to operate in the same mode, so configuring them differently would cause nothing but misinterpretation of message header fields, thus leading to strange effects. (NO)4DMSGHEADER Used to obtain TrapToss' way of interpreting and creating message headers. If set, Idefix will both rely on incoming messages containing full FTS-1 compliant 4D message header information (including zone and point), and create 4D message headers itself. Otherwise, the old-style date-stamped message headers will be expected and created. However, INTL kludges will always override message header information. (The latter possibly being subject to change.) Optional. Defaults to NO4DMSGHEADER. Of course, AREA is searched for in TrapToss's config file. After all, that's what Idefix is for. However, there are some additional keywords that you need to put after your AREA keywords which will be explained now. Note: Put these keywords after all TrapToss area keywords, otherwise TrapToss might not be able to recognize its own keywords anymore. DESCRIPTION or DESC DESC "" gives a description for this area which the users will be sent, if they request area lists (using LIST or QUERY). Optional. Defaults to "No description given.". ACCESS ACCESS "" gives the access required to attach to or detach from this area. Optional. Defaults to "" (granting access to any system). DEFAULTACCESS "" That's a nice one! :-) Most of the time, your areas will be in a certain order in your TrapToss.cfg, as are they in mine. Most of the times, they are grouped like: first local areas, second FidoNet area, next AmyNet areas, and so forth. This means that you usually have a bunch of areas that would get the same access. Therefore, you can use DEFAULTACCESS to specify an access string to all areas that follow AND do not have an ACCESS keyword. In other words, this is the access string that areas without one default to. With a little luck, you can setup your access security with three or four DEFAULTACCESS keywords. Now, isn't that nice? Invented by a lazy sysop! ;-) Example: DEFAULTACCESS "FidoNet" AREA AMIGA MAIL:AMIGA 2:246/2248 2:246/2200 DESC "Amiga international" AREA AMIGA_LC MAIL:AMIGA_LC 2:246/2248 2:246/2200 DESC "Amiga C programming and Lattice C" AREA AMIGA_SYSOP MAIL:AMIGA_SYSOP 2:246/2248 2:246/2200 DESC "Amiga SysOps" ACCESS "FidoNet SysOp" AREA AMIGA_VIDEO MAIL:AMIGA 2:246/2248 2:246/2200 DESC "Amiga and Video" As you can see, a default access is given once at the start, and is valid for all areas that follow. For AMIGA_SYSOP however, the default string was overridden by another one. Nevertheless, the default string is valid again for AMIGA_VIDEO, the area that comes next. For more information on the meaning of the access strings, please refer to the section on "Security". Idefix only keywords ==================== The following keywords are solely of use to Idefix. There are therefore taken from either Idefix.cfg (or whatever you prefer to name it), or from the Idefix section of your GCF. LOGFILE Used to specify a file where Idefix is to log actions and errors in. Since Idefix uses the same format as TrapToss, you can use the same logfile for both of them, since they should never run at the same time anyway. Optional. Defaults to no logging. LOGLEVEL Used to specify how detailed the logging should be. Valid loglevels are: 0 - no logging at all (not recommended) 1 - only severe errors are logged (not recommended) 2 - all errors are logged 3 - request failures are logged 4 - request forwards are logged 5 - all requests are logged in summarized way 6 - all requests are logged in detail (recommended for testing) 7 - additional debugging info logged 8 and 9 is really annoying debugging (meant mostly for myself) Optional. Defaults to 5 (medium logging). TOSSERCONFIG "" Used to obtain the name of the configuration file of TrapToss. Required. No default (may be subject to change). LINESIZE Used to set the line size when creating new lines (unmodified lines won't be changed), or adding to existing lines. This is the maximum line length allowed, Idefix will always try to create lines that are not longer. Optional. Defaults to 80. (NO)CONDENSED Used to set how Idefix is to write back the export-to list of modified areas. NOCONDENSED means that all nodes are written as 4D addresses, while CONDENSED supports TrapToss's ability to understand condensed lists where the missing parts of the address default to those of the previously listed address (see TrapToss.man for more details). Optional. Defaults to CONDENSED. AREAFIXNAME Name under which Idefix will be known by your users. This is the name that has to appear in the To field in order to make Idefix react to the message. You can make Idefix react to more than one name by using AmigaDOS patterns like "(Areafix|Idefix)", or even "*FIX". Note: the use of the asterisk "*" instead of "#?" requires that you have enabled its use on your system. There are several public domain utilities for that purpose, like SetStar, WildStar and so on. Optional. Defaults to "Areafix". HELPFILE "" File containing a (hopefully) helpful text that will be sent to your users, if they request help from Idefix. Optional. Defaults to "MAIL:Docs/Idefix.help". The default is probably subject to change, so don't rely on it! PASSTHRUDIR "" You may optionally give a directory name to use when creating new areas on automatic forwards. This is merely a cosmetic thing, since it is used only to create the new AREA line in TrapToss.cfg. TrapToss itself does not even require the directory to exist, as it tosses pass thru echoes "on the fly". Optional. Defaults to "MAIL:THRU". (NO)SYSOPCOPY Controls if or if not a copy of each reply to any requests is to be sent to the sysop. The copy will be marked as such. No copy will be send, if the message was from a system qualified as having SYSOPACCESS. Optional. Defaults to NOSYSOPCOPY. (NO)QUIET Used to reduce console output. However, console output is only reduced with this keyword, not fully suppressed. Redirect to NIL:, if you want no output at all. Optional. Defaults to NOQUIET. (NO)BACKUP Switch telling Idefix to backup TrapToss.cfg before any modifications are made. The backup file will be named like the original file, extended by "_BACKUP". A backup will be done only, if no backup exists yet. This is done to prevent Idefix from backing up a broken file. Optional. Defaults to NOBACKUP. (NO)USEHIMARK Switch telling Idefix (not) to use the high water mark from the 1.msg file created and updated by TrapToss. If you use Idefix as proposed, i.e. if you execute it each time after a TOSS and before the SCAN, this will be fine. Otherwise you might need to switch this option off, causing Idefix to check the high water mark by itself which is, of course, a little bit slower. See also (NO)RESCAN and (NO)SKIPRECEIVED. Optional. Defaults to USEHIMARK. (NO)SKIPRECEIVED Switch telling Idefix whether or not to process messages that have their "Received" flag set. Idefix itself sets the "Received" flag on each message it has processed, and, when scanning the netmail directory, skips messages with this flag set by default. This helps to avoid duplicate processing of a message. If, however, you want to re-process messages for some reason, you will need to switch this feature off. Good for testing also. Optional. Defaults to SKIPRECEIVED. (NO)RESCAN Switch telling Idefix to rescan the whole netmail directory for messages, not only the messages above the high water mark. This may be useful, if you do not (for what reason ever) run Idefix between each TOSS and SCAN as proposed, but rather prefer to run it manually every now and then. It will then scan the complete netmail directory, processing all messages it finds. In order to avoid duplicate processing with RESCAN, using SKIPRECEIVED is strongly recommended (also being the default). Optional. Defaults to NORESCAN. (NO)ENVSWITCH A feature that allows Idefix to automatically determin, if new messages have arrived. It makes Idefix check the global environment variable "Idefix" before it starts parsing TrapToss's configuration file (which takes some time). If the environment variable exists, Idefix will continue to parse the config, and eventually to scan the netmail directory for new messages. Otherwise, it will immediately terminate. If you set up a MSGFILTER "Areafix" env:Idefix "quit 5" you can execute Idefix after each TOSS without Idefix spending a lot of time parsing configs that won't be needed since no new messages have arrived. Optional. Defaults to NOENVSWITCH. (NO)(UN)ATTENDED or NOREQ Switch telling Idefix to suppress any requesters. Also, processing continues even if minor errors occur. Optional. Defaults to ATTENDED. (NO)AUTOATTACH Switch telling Idefix to automatically forward requests for areas that you do not carry, but one of your feeds does. A pass-thru area will be created, and a request will be sent to the appropriate feed requesting the area. The user will be told that his request has been forwarded. Optional. Defaults to NOAUTOATTACH. (NO)AUTODETACH Switch telling Idefix to automatically request your feed to detach you from an area, if the last downlink has detached from it on your own system. This applies only to pass-thru areas. The area will be removed from TrapToss.cfg, and a request will be sent to the appropriate feed requesting to detach your system from the area. Optional. Defaults to NOAUTODETACH. AREACREATECMD "" Provided AUTOATTACH is set, Idefix will execute the given command each time it is about to forward the request and create the new area. The following environment variables are set to the appropriate values when the command is executed: $Idefix - Idefix current version $AreaTag - The name of the requested area $AreaDesc - The description of the area $Node - The address of the requesting user $User - The full name of the requesting user $Feed - The address of the feed that carries the area $Aka - The appropriate AKA the request was sent to All addresses are 4D, i.e. including zone and point. The return-code from the command will control what Idefix does afterwards. A return-code of zero makes Idefix continue and create the area, as well as request it from the feed. A return-code of 5 (actually a non-zero return-code) will prevent Idefix from creating and requesting the area. Instead, Idefix will reply "not available" to the requesting user. This feature may be used for automatic announcements of new areas (as long as Idefix cannot do that on its own). Also, if you don't want automatic forwards, you may set AUTOATTACH anyway and use this feature to log the requests to a "wish list" for example: AREACREATECMD "execute MAIL:scripts/arearequest" ; AreaRequest script: echo "$User would like to read area $AreaTag ($AreaDesc)!" >>ram:wishlist quit 5 You could then check the list every now and then and decide what to do. AREADELETECMD "" Provided AUTODETACH is set, Idefix will execute the given command each time it is about to remove an area completely from the config. This happens only, if an area is pass-thru, and the last downlink has just detached from it. The same environment variables are available as in AREACREATECMD. The return-code from the command will control, if or if not the area is actually removed. A return-code of 0 will allow deletion of the area, a return-code of 5 will prevent this. The detaching downlink will be removed anyway, of course. All the above keywords may be overridden by stating them as command line arguments when executing Idefix. In addition to these keywords, there is one more that can (for quite obvious reasons) be only stated in the command line: CONFIG Can be used to tell Idefix where to find its configuration file. Optional. By default, Idefix searches for a file called "Idefix.cfg" in the current directory, then for "MAIL:Idefix.cfg", and last for "MAIL:Fido.cfg". Keywords for defining downlinks =============================== A downlink is defined as a system that has Areafix access on your system. The same system can be defined as a downlink and as an uplink (feed). However, it is usually not sensible to allow a feed of an area to detach from that area! SYSTEM All systems that you want to be able to use your Areafix need to be defined in Idefix.cfg, using the SYSTEM keyword which can be followed by an ACCESS keyword, or preceeded by a DEFAULTACCESS keyword. The same rules apply as described in the AREA keyword. (See also "Security".) Required (for each system that you want to have access). No defaults at all. SYSOPACCESS This is a keyword switch that allows the system to use %FROM in messages to Idefix. Otherwise, attempts to use %FROM will be rejected as "not authorized". Optional. No default. PASSWORD Defines the password required in the subject field to request any mutations from Idefix. Usually, there is no reason to specify a password in Idefix.cfg, as Idefix will automatically use the password stored in fidonet.extra by SetPasswd or TrapList (see TrapList.man for details), protecting you from redundant information in various configuration files. However, you may not use a nodelist (really?), or you may want to override the session password default for some reason. Optional. Defaults to the session password. ACCESS "" Defines the access that a system has. Note that this keyword must appear on a separate line (probably subject to change). Optional. Defaults to "" (or DEFAULTACCESS, if given). DEFAULTACCESS "" Defines an access string that all following systems default to, if they have none given. Valid until the next occurrance of DEFAULTACCESS. Optional. Defaults to "". Keywords for defining uplinks ============================= An uplink is defined as a system that feeds you echo areas. The same system may be a downlink and an uplink at the same time, but usually not for the same areas. Uplinks need only be defined in Idefix.cfg, if you want to use the automatic request forward feature (see AUTOATTACH and/or AUTODETACH). FEED If an area is requested that you do not carry, the feeds that you defined will be searched for this area. Similiarly, if one of your downlinks detaches from an area, and he or she is the last but one attached to this area, the last system attached will be compared to the feeds you defined. If, and only if, it is thus recognized as a feed, the area will be removed and the feed will be requested to remove you from its export-to list. Each FEED keyword may be followed by the keywords AREALIST, FORWARDACCESS, and NEWACCESS. AREALIST is required, if you want attach forwarding. Optional. No default. AREALIST "" Defines a file that containes a list of areas available at this feed. Each area takes one line, followed by its description. You may use the fidonet.na files that can be obtained via Fidonet, but most Areafix lists from your feed should work as well. If you have several files for one feed, you may define the same feed multiple times (probably subject to change). This area list will be searched for an area requested but not available on yur system, in order to determine, if the area tag is valid, and where to obtain it from. Optional. No default. FORWARDACCESS or FWDACCESS "" Defines what access is required in order to make Idefix forward requests to this feed. Optional. Defaults to "" (i.e. no access requirements). NEWACCESS "" Defines what access a newly created pass-thru area requested from this feed will have. Optional. Defaults to "" (i.e. no access requirements). MAIN
Defines which of your AKAs to use as main address when creating a new pass-thru area from this feed. Optional. Defaults to your main address given in NODE. Remote maintenance feature ========================== It is possible to request mutations for other systems in a message. To do so, a separate line containing %FROM
must precede the requests for adding or removing areas.
is the address of the system the requests are for. The password in the subject must still be the one of the sender, though. Several %FROM may be used in the same message, each of which is valid for the lines following it, (until another %FROM is found). Subject shortcuts will apply globally. The systems for which requests are made will be notified. In order to be able to use %FROM, a system must be defined as having SYSOPACCESS. If %FROM is to be used in local messages, you have to define your own node in a SYSTEM statement with SYSOPACCESS. How and when to run it with TrapToss ==================================== Idefix is not designed to be used with TrapToss's MSGFILTER. It must rather be run separately after each tossing. The recommended way to run it, is to write a little batch script like: ; Example script on when and how to invoke Idefix TrapToss TOSS Idefix TrapToss SCAN MAXTRIXONLY ; export the replies and forwards ; end of script This should be executed from your aftersession script. See also (NO)ENVSWITCH for a trick to reduce overhead. Caveats ======= Idefix is still in pre-release stage. This doesn't mean it's very unstable, but it means that it misses a lot options that are planned. One of them is domain checking. IDEFIX DOES NOT YET DO ANY DOMAIN CHECKING! In order to keep systems from other domains attaching, I strongly recommend to use an access word for each domain - the simplest way to do that, is to use the domain itself, of course. Therefore, define all your FidoNet areas with one of the access words being "FidoNet", and define all your FidoNet downlinks with one of their access words being "FidoNet" as well. If you define your AmigaNet aeas and system using "AmigaNet", and so on, nothing should go wrong. Support ======= You can reach me via - Fidonet as Metin Savignano at 2:246/2248 - AmigaNet as Metin Savignano at 39:173/115 - InterNet as metin@stepout.tynet.sub.org Support in zone 3 may also be provided by Peter Deane (3:622/401). If you report any problems, please use the BUGREPORT.TXT form provided in the distribution archive. Be sure to provide as much information as necessary to reproduce the problem. You may also post your question in the TRAPDOOR echo which I use to read regularly. I promise to fix any bug as soon as possible, but remember that I am programming this in my free time. Also, I will be glad to receive any enhancement proposals which I promise to seriously consider. However, if or if not they will be implemented depends on a lot of things, so I cannot promise anything beforehand. The most current version can be requested under the magic IDEFIX. Thanks ====== Thanks to Matt Dillon for his Dice, to René Hexel for his TrapToss, to Thomas Georg, Peter Deane, and the other beta testers for their help, and to Karin Zimmermann for her understanding. :-) ============================================================================= Idefix.man - the manual for Idefix 0.5 (public pre-release) =============================================================================