PC Online 1997 April

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

/ PC Online 1997 April / PCO_04_97.ISO / filesbbs / os2 / net100p.arj / NETMGR.DOC < prev next >

Wrap

Text File | 1996-11-17 | 86.7 KB | 2,528 lines

=================================================================== NetMgr - "The Swiss Army Knife for Netmail" Copy, move, delete, file, change and bounce netmail.. (c) 1992,93,94,95,96 Gerard van Essen (2:280/408) =================================================================== ! NetMgr uses the Squish MSGAPI by Scott Dudley. ! Squish is a trademark of Scott J. Dudley ! JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin. ALL RIGHTS RESERVED. NetMgr version : 1.00 Last update of this document : Nov 8, 1996 Throughout the documentation, you will see items that are marked with a 'plus' sign, like this: {+}. This indicated that the described feature is only available for registered users of NetMgr. ┌──────────────┬───────────────────────────────────────────────── │ Introduction │ └──────────────┘ NetMgr is a program that will scan the messages in one or more NETMAIL area(s), and analyse the headers of those messages. The messages can be stored in *.MSG, Hudson, Squish or JAM format. NetMgr only scans NETMAIL areas, _not_ echomail areas. You can try to run NetMgr on echomail areas, but unpredictable things can (and will) happen, so don't do it! NetMgr will check if any of the headers meet the criteria specified in the configuration file (a 'mask'), created by the user. If any of those headers are found, NetMgr can perform several actions on that message, like moving or copying it to another message area, deleting it, changing it etc. ┌─────────────────────────────────────┬───────────────────────────── │ Copyright, license and disclaimer.. │ └─────────────────────────────────────┘ * "NetMgr" refers to the executables and documentation in the original distribution archive. NetMgr is copyrighted material by Gerard van Essen. It may only be used in agreement with the conditions set out in this license agreement. * You are entitled and encouraged to copy and distribute NetMgr, provided you do not change the contents of the NetMgr archive or the program itself, and no money or any other compensation is asked or accepted for NetMgr (without written permission from the author). Distribution of modified or incomplete archives is prohibited. * Although care has been taken to write and test a program that does what this document states, the program is provided as is, without warranty or guarantee of any kind, either expressed or implied, as to the quality or performance of this program, except that it will occupy disk space. * The author, Gerard van Essen, will not be held liable to you or anyone for (but not limited to) any direct, indirect, incidental or consequential damages, including any lost profits, lost savings which may result from the use or inability to use this program. Gerard van Essen is in no way obligated to provide future versions of, or support for this software. Your use of the program constitutes your agreement to this license and disclaimer and your release of the author from any form of liability or litigation. * COMMERCIAL use of the program: you are a commercial user if you make a profit from running NetMgr, or if you use NetMgr in a commercial environment (i.e.. business, governmental organization, association, school, foundation, or any other form of juridical person). In case of doubt, contact the author. * For NON-COMMERCIAL use, it is REQUIRED that you register the program. However, if you really cannot afford to register (mainly a concern to 'eastern block' countries, the former USSR etc.), permission is hereby granted to use an unregistered version. Remember, if you register, you are paying for something that you already have! Registration does not mean you can force me to implement new features that you like. * For COMMERCIAL use of the program, you should always register the program. You are, however, granted an evaluation period of 30 days. After these 30 days, you must either register the program, or stop using it. Using an unregistered version of NetMgr in a commercial environment for more than 30 days is prohibited! * You only have to register once. Your registration will also be valid for all future releases of NetMgr. * Registration is valid for all versions of NetMgr. At this moment, there are DOS and OS/2 versions of the program available. Registering NetMgr entitles you to run the DOS version, the OS/2 version, or both :-) * A registration is PERSONAL. It cannot be transferred to other parties. It could, however, be used in different places (but: by the same PERSON). Think of it as a book in this regard: you can take the book from your home to the office (and read it there). * Versions of NetMgr prior to version beta 0.97 were freeware and could not be registered. You may continue to use THESE OLDER VERSIONS without registration, even in a commercial environment. * The author reserves the right to change this license without prior notice, for newer versions of the program. ┌────────────────────────────────────┬───────────────────────────── │ A 'MASK', NetMgr's driving force.. │ └────────────────────────────────────┘ As mentioned in the short introduction, NetMgr will scan the headers of all messages in a netmail area to see if a header meets the criteria that are set by the user in NetMgr's configuration file. These criteria are specified in a 'mask'. A 'mask' consists of six parts: fromname, fromaddress, toname, toaddress, subject, attributes (1) (2) (3) (4) (5) (6) So 6 parts, separated by a comma. In the config file you use the keyword MASK to specify a mask: MASK fromname, fromaddress, toname, toaddress, subject, attributes NAME : fromname, toname ─────────────────────── A 'name' is just a string, leading and trailing spaces found in the config file are stripped, spaces *within* a string are allowed. So writing " Gerard van Essen " will be the same as "Gerard van Essen". (Note that leading and trailing spaces are stripped, while the space between "Gerard" and "van" is still there...) NetMgr will do a compare that is NOT case sensitive. In other words: as far as NetMgr is concerned, "GERARD van ESSEN" is the same as "gerard VAN essen" and the same as "GeRaRd VaN eSsEn". A name can start with a tilde (~). This indicates that you are not looking for an exact match of the string, but that you are looking for a substring. As long as the string you specify is located somewhere in the name, it will be a match. So, if you specify '~essen' as a name, it will be a match if the name is 'Gerard van Essen', and also if it is 'Art van Essen' etc. A name can also start with an exclamation mark (!). This indicates that you are looking for a string that does NOT match what you specify. So if you specify '!Gerard van Essen', NetMgr will work on messages where the string is NOT 'Gerard van Essen'. You can also combine the '~' and '!' tokens. The '!' MUST be always the first token if you do that! For example: !~essen will look for string that do NOT contain 'essen' anywhere in the string. In that case 'Gerard van Essen' will not be a match, 'Art van Essen' will not be a match, but 'Nick Wirth' will be a match. SUBJECT ─────── A subject is just a string, exactly like a 'name'. Everything that applies to a 'name' also applies to a 'subject'. See the paragraph above.. ADDRESS: fromaddress, toaddress ─────────────────────────────── An address is *always* full 4D (4 dimensions: zone, net, node, point), write a '*' for any part you don't care about: 60:*/*.* - all messages coming from zone 60 2:281/527.* - msg from any point from 281/527, or .0 *:500/*.* - all messages from nodes/points in a net 500, any zone 2:281/527.0 - only messages from 2:281/527.0 Just one exception (to the "always 4D" rule): specifying just a '*' only for the address is allowed (strictly speaking, it is not full 4D :-), and is the same as *:*/*.*. An address can also start with an exclamation mark. That indicates that you are looking for messages where the address does NOT match what you are specifying here. For example: !2:*/*.* will let NetMgr work on all addresses that are NOT zone 2. And !2:281/527.0 will let NetMgr work on all addresses that are NOT 2:281/527. ATTRIBUTES ────────── Attributes can be one or more of the following: p = private c = crash r = received s = sent a = attach i = forward/intransit o = orphan k = kill l = local h = hold f = file request n = scaNned d = Direct u = Update request q = return receipt reQuest y = return receipt m = iMmediate t = TFS e = KFS (erase) z = Archive sent 2 = XX2, officially unused/reserved b = is return receipt g = confirm receipt request $ = message is locked % = JAM, zonegate bit x = message is a FAX cover Special attributes to support nodelist lookups of node numbers: @ = Check destination address. # = Check origination address. These two special attributes will be explained later. ■ Important note: Several of these extra attributes can only be represented in the '^AFLAGS' kludge (that is NOT supported by Squish, but is by Frontdoor and several other programs), in some message base formats (like *.MSG and Squish). If you do NOT want to use this FLAGS kludge (because you use Squish in a Binkley environment), you can put the keyword 'NOFLAGS' in your config. This gives you the ability to use 'direct' (in the peculiar way that Squish supports it). You can NOT use: IMM, TFS, KFS or Archive Sent in this ('NOFLAGS') mode for Squish and *.MSG areas! NetMgr will NOT write out a FLAGS kludge in this ('NOFLAGS') mode, so rewriting a message that has these FLAGS will make these FLAGS disappear!! The JAM message base format supports ALL attributes without any kludges. Every attribute must have a '+' or a '-' in front of it. A '+' means: must be present. A '-' means: must *not* be present. An example: +l+p A message only matches this, if the L)ocal bit, and the P)rivate bits are set. The other (possible) attributes are not important. -f+l A message matches this, if it is *not* a F)ile request, and the L)ocal bit is present. +c+l+p-s A message matches this, if the C)rash bit is set, the L)ocal bit is set and the P)rivate bit is set. Apart the that, the message must *not* be S)ent already.. The special nodelist 'attributes'. ---------------------------------- NetMgr also supports two special attributes that can check whether a certain address is in the nodelist or not. The following two tokens represent these special attributes: @ = Check destination address. # = Check origination address. Just like the other attributes, a '+' or a '-' must be used in front of these attributes: +@ means the destination address must be listed. -@ means the destination address must NOT be listed. +# means the origination address must be listed. -# means the origination address must NOT be listed. * Note: if the message originates from, or is destined for a point address, NetMgr will try to locate the Boss of this point in the nodelist. If the Boss is listed, the point address is also assumed to be listed. Checking whether or not a node is in the nodelist can be quite useful. Sending out a message to a node that is unlisted is bound to fail, so it may be useful to bounce such a message, or at least give a warning about this situation. Similarly, if you receive a message FROM a node that is unlisted, you may be warned that returning a reply to that address may fail because of this situation. The special nodelist attributes can be simply combined with other attributes: +l+p-@ A message matches these attributes, if the L)ocal bit, and the P)rivate bits are set. Additionally, the message must be addressed to a node that is not listed in the nodelist. +p-@-# A message matches these attributes, if the P)rivate bit is set, the message is addressed to a node that is not listed in the nodelist, and the message originates from a node that is not listed either. -@+# A message matches these attributes, if it originates from a listed node, but is addressed to an unlisted node. In order to use these special attributes, you must also specify what type of nodelist you use, and where it is located. NetMgr supports the Version 7 nodelist (used by for example Binkley), the FrontDoor nodelist (used by FrontDoor and Intermail) and the GIGO nodelist (a compiler to generate a GIGO nodelist is supplied with NetMgr). The keywords that can be used to specify the nodelist are presented later in this document. Some examples of a complete 'MASK'. ─────────────────────────────────── Mask Gerard van Essen, *, *, *, *, +s All messages, coming from "Gerard van Essen" on any address (*), written TO: anyone (*) on any address (*), with any subject, that are already flagged as S)ent. IE: all messages written by me that have already been packed/sent. -- Mask *, 2:281/527.*, uucp, 2:281/527.0, *, +l-h-p-k Message written by anyone (any name: '*'), on node 2:281/527 (.* so it can be the NODE 2:281/527 or any of its points, like 2:281/527.40). Written TO: a guy named "UUCP" on node 2:281/527. The L)ocal bit must be set, and the H)old, P)rivate and K)ill bits must *not* be set. The subject doesn't matter. -- Mask *, 2:281/527.*, postmaster, 2:281/527.0, *, * Message written by anyone (any name: '*'), on node 2:281/527 (.* so it can be the NODE 2:281/527 or any of its points, like 2:281/527.40). Written TO: a guy named "Postmaster" on node 2:281/527. The subject and message attributes that are (not) present are not important. -- Mask *, *, raid, 2:281/527.0, *, * All messages, coming from anyone on any address, but addressed to RAID on 2:281/527. The subject & message attributes don't matter. -- Mask *, *, ~essen, 2:281/527.0, ~timed, * All messages, addressed to a name that contains the string 'essen', on node 2:281/527, that have the string 'timed' somewhere in the subject. -- Mask ~gerard, !2:281/527.0, *, *, *, * All messages, coming from someone whose name contains 'gerard', but whose address is NOT 2:281/527. So it will be from someone with a nice name, but it won't be from me :-) -- Mask *, *, !~essen, 2:281/527.0, *, * All messages with node 2:281/527 as their destination, but not addressed to anyone who has the string 'essen' in his/her name. So messages addressed to my system, but not for me personally (most likely a message for one of my BBS users). -- Mask *, !2:281/527.0, *, *, *, -@-l All messages that are not originating from node 2:281/527, have a destination address that is unlisted in the nodelist and do not have the 'local' bit present. -- Mask *, *, *, *, *, -# Any message that originates from an unlisted system. NetMgr also offers another type of Masks: eXtended Masks (XMASKs), with much more capabilities than standard masks. These will be explained later in this document. First we will take a look at what NetMgr can actually do when it find a message that matches a certain mask. ┌────────────────────────┬───────────────────────────────────────────── │ MASK's partner: ACTION │ └────────────────────────┘ A MASK is never alone, it is always accompanied by one or more ACTION statements. This ACTION statement tells NetMgr what should be done with messages that match a certain MASK. In the ACTIONs mentioned below, <destination area> can be any for the following formats: *.MSG : give the path of the *.MSG area (c:\fd\rcvd\). Squish : give the path + basename of this area, and put a '$' in front of it, to indicate Squish format ($c:\squish\netmail). JAM : give the path + basename of this area, and put a '!' in front of it, to indicate JAM format (!c:\fe\msgs\saved). Hudson : give the board number of this area, and put a '#' in front of it, to indicate Hudson format (#102). The following ACTIONs are valid: ■ COPY <destination area> ────────────────────────── Copy a message to another area. This HAS TO BE a netmail area. It can be a *.MSG, JAM, Squish or Hudson area (see above). The original message will be left alone, NetMgr will simply make a copy. An example: Action Copy c:\fd\netmail This will copy a message to the *.MSG area c:\fd\netmail (there is no leading '#', '$' or '!' so it is a *.MSG area. Action Copy #13 This will copy a message to a Hudson area (because of the leading '#') with board number 13. ■ MOVE <destination area> ────────────────────────── Move a message to another area. This HAS TO BE a netmail area. It can be a *.MSG, JAM, Squish or Hudson area (see above). The original message will be deleted after a copy is placed in the destination area. An example: Action Move !e:\msgbases\artware This will move a message to the JAM style area (because of the leading '!') e:\msgbases\artware. ■ DELETE ──────── Delete a message. This action has no parameters. The message will be deleted. ■ DELETEATTACH ────────────── This action will not only delete the message, but it will also look at any attached files. When the 'Truncate when sent' flag is present on the message, the file(s) will be truncated. When the 'Kill file when sent' flag is present, the attached file(s) will be deleted. ■ FILE <output text file> ────────────────────────── Write the message to a text file. NetMgr will write out the message (header + body) to a plain (ASCII) text file. The original message will be left alone. The body of the message will be formatted with a right margin of 80. If the file does not exist, it will be created. If it exists already, the message will be appended at the end of the file. Example: Action FILE d:\output\msgtext.txt This will add the message to the textfile d:\output\msgtext.txt. ■ HDRFILE <output text file> ───────────────────────────── Write message header to a textfile. NetMgr will write out the message (header only) to a plain (ASCII) text file. The original message will be left alone. If the file does not exist, it will be created. If it exists already, the message will be appended at the end of the file. Example: Action FILE d:\output\msgtext.txt This will add the header of message to the textfile d:\output\msgtext.txt. ■ SEMAPHORE <path+filename> ─────────────────────────── Generate/touch a semaphore. A semaphore is a 0 byte file, that is often used as a simple way to communicate between different programs. Different courses of action can be taken based on the existence of a semaphore. This can be easily accomplished in batch files, by using the 'if exist ..' and 'if not exist' commands. If the semaphore file does not exist, it will be created. If it already exists, it will be 'touched': the date and time of the file will be set to the current date and time. ■ REWRITE <mask> ───────────────── Rewrite (change) the header. This action takes a full 'mask' as parameter. A rewrite mask may contain the wildcard token ('*') as well. All fields where a '*' is specified will be left unchanged. This allows you to change only a certain field in the header without changing any of the other fields. Some examples: Action Rewrite *, *, Gerard van Essen, *, *, * This will change the TO: name in 'Gerard van Essen', but will not change anything else in the header (or body, for that matter) of the message. Only the contents of the TO: name field is changed. Action Rewrite *, *, *, 2:281/527.0, *, * This will change (only) the destination address of the message. It will be set to 2:281/527.0. All other fields will be left unchanged. Action Rewrite *, *, *, 2:*/*.*, *, * This will change (only) zone of the destination address of the message. It will be set to zone 2. The rest of the address is not changed. So a message originally to 1:100/1.0 will be changed to 2:100/1.0, while a message originally to 70:256/123.0 will be changed to 2:256/123.0. All other fields will be left unchanged. Action Rewrite *, 2:281/527.0, *, *, Interesting subject, * This will change the origination address of the message. It will be set to 2:281/527.0. Additionally, the subject will be set to 'Interesting subject'. The other fields will be left unchanged. Action Rewrite *, *, *, *, Interesting subject, -c+h This will set the subject to 'Interesting subject'. Additionally, the 'hold' attribute will be added to the message (+h) and the 'crash' attribute will be stripped (-c). The other fields will be left unchanged. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. ■ UUCPREWRITE <mask> ──────────────────── Rewrite header and add the contents of the 'TO: name' field to the body, at the top of the message. This can be useful for Internet <-> FidoNet gates. UUCPrewrite works exactly like a 'normal' rewrite, but will also add the TO: name to the body of the message. An example: Action UUCPrewrite *, *, uucp, 2:281/999.999, *, -c+l A message like this: From: Pietje Puk, 2:281/0 To : art@cnh.wlink.nl, 2:281/527 Subj: test ------------- Hello! . . Will be rewritten to: From: Pietje Puk, 2:281/0 To : uucp, 2:281.999.999 Subj: test -------------- TO: art@cnh.wlink.nl Hello! . . ■ BOUNCE <address> <bounce text file> ────────────────────────────────────── Return message to the sender, and add bounce text at the top. This action returns a copy of the entire message, including the header information. The address used as origination address (in the origination address, MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this needs to be a full 4D address. You *must* specify this item (it may not be '*'), because NetMgr needs to know a valid origination address to use. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. The original message is left untouched. If you want to send back the message *and* get rid of the original message, you must first have an 'Action Bounce' and then an 'Action Delete' line for a certain mask. Otherwise the original message will just stay there, and might trigger an 'Action Bounce' on the next run of NetMgr. If the original message contains the REPLYTO/REPLYADDR kludges (as specified in FSC-0035), NetMgr will properly bounce this message back to the other network (most likely internet), with a correct TO: line at the top of the message. {+} You can use variables in the textfiles that can be inserted at the top of the message. These variables will be expanded using the contents of the message header of the message you are bouncing. This gives you the opportunity to make the messages a bit more 'personal'. In the file, the use of the following variables is now allowed: %to : The full name of the person that the the original message was addressed to. %fto : As %to, but only the first name of that person. %from : The full name of the person who wrote the original message. %ffrom : As %from, but only the first name of that person. %subj : Subject of the original message. %orig : Address of the sender of the message (like 2:281/527) %dest : Address of the recipient of the message (like 2:281/527) %time : Time the message was written (like 01:25) %year : The year the message was written (like 1993) %mon : The month the message was written (like jan, feb etc) %day : The day of the month msg was written (a number) %dow : The 'day of week' msg was written (like mon, tue, wed etc) So, the contents of the bounce file could be: -=- Hello %ffrom! You sent a message to %to (%dest), dated %mon %day, %year. The subject was: "%subj". -=- These variables can only be used by registered users of NetMgr. ■ EMPTYBOUNCE <address> <bounce text file> ─────────────────────────────────────────── Return message to the sender, add bounce text at the top. This action returns nothing, apart from the 'bouncetext', there will be no information in the message body. The address used as origination address (in the origination address, MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this needs to be a full 4D address. You *must* specify this item (it may not be '*'), because NetMgr needs to know a valid origination address to use. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. The original message is left untouched. If you want to send back the message *and* get rid of the original message, you must first have an 'Action EmptyBounce' and then an 'Action Delete' line for a certain mask. Otherwise the original message will just stay there, and might trigger an 'Action EmptyBounce' on the next run of NetMgr. If the original message contains the REPLYTO/REPLYADDR kludges (as specified in FSC-0035), NetMgr will properly bounce this message back to the other network (most likely internet), with a correct TO: line at the top of the message. {+} You can use variables in the textfiles that can be inserted at the top of the message. See the action 'bounce' for more information on this. ■ HDRBOUNCE <address> <bounce text file> ───────────────────────────────────────── Return message to the sender, add bounce text at the top. This action returns the message header, in addition to the 'bouncetext'. The body of the original message will not be sent back, however. The address used as origination address (in the origination address, MSGID) is the first item you specify. As all addresses in Netmgr.cfg, this needs to be a full 4D address. You *must* specify this item (it may not be '*'), because NetMgr needs to know a valid origination address to use. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. The original message is left untouched. If you want to send back the message *and* get rid of the original message, you must first have an 'Action HdrBounce' and then an 'Action Delete' line for a certain mask. Otherwise the original message will just stay there, and might trigger an 'Action HdrBounce' on the next run of NetMgr. If the original message contains the REPLYTO/REPLYADDR kludges (as specified in FSC-0035), NetMgr will properly bounce this message back to the other network (most likely internet), with a correct TO: line at the top of the message. {+} You can use variables in the textfiles that can be inserted at the top of the message. See the action 'bounce' for more information on this. ■ XBOUNCE {+} ■ XHDRBOUNCE {+} ■ XEMPTYBOUNCE {+} ────────────────── The BOUNCE, HDRBOUNCE and EMPTYBOUNCE Actions have 'extended' counterparts: XBOUNCE, XHDRBOUNCE and XEMPTYBOUNCE. The format: XBOUNCE <textfile for bouncetext> <full mask to use> The first parameter is the textfile to add at the top of the bounce message. The second parameter is the mask to use for the bounce message. You can specify a "*" for the fields where you want the default to be used. By default, NetMgr generates a full 'reply header' with the to: and from: names and addresses reversed (compared to the original message) and the same attributes and subject. For example, for this message: From: Gerard, 1:1/1 To : SysOp, 1:138/211 Subj: Test! Attr: Pvt Cra ---------------------------------- The standard reply header is: From: SysOp, 1:138/211 To : Gerard, 1:1/1 Subj: Test! Attr: Pvt Cra ---------------------------------- And that will be the result if you specify a mask like: Action XBounce c:\txt\bounce.txt *, *, *, *, *, * However, if you make it: Action XBounce c:\txt\bounce.txt The Bodyguard, 2:281/527.0, *, *, *, +l The result would be: From: The Bodyguard, 2:281/527 To : Gerard, 1:1/1 Subj: Test! Attr: Loc ---------------------------------- {+} You can use variables in the textfiles that can be inserted at the top of the message. See the action 'bounce' for more information on this. The extended bounce actions are only available to registered users. ■ ADDNOTE <textfile> ──────────────────── This will add the text from <textfile> at the top of the message. You could use this to send a message through with a note ('please do not reply through this system, the originating system is unlisted'). The message is not changed in any other way. ■ FORWARD <mask> ──────────────── This action will forward the message (showing both header and body, like 'bounce' does) to someone else. The header of the message will be constructed using the mask you specify. However, the header (that is: from, to, subject, destination address, origination address and attributes) will be initialized with the contents of the original message. Putting a '*' in fields of the masks will, as a result, produce the contents of the header of the original message. Example: An example: Action Forward *, *, Kasper Kwant, 2:500/144.0, *, +l+c A message like this: From: Gerard, 2:281/527 To : SysOp, 1:138/211 Subj: Test! Attr: - ---------------------------------- Will produce a message like this: From: Gerard, 2:281/527 To : Kasper Kwant, 2:500/144 Subj: Test! Attr: Loc, Cra ---------------------------------- * Forwarded by NetMgr+ 1.00 Original message: From: To : <--- header of original message. Subj: ---------------- Bla, bla <--- body of original message. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. ■ MAKEMSG <file for body> <mask> ──────────────────────────────── This will generate a new message, using the Mask you specify as the header, and the contents of a file you specify as the body. However, the header (that is: from, to, subject, destination address, origination address and attributes) will be initialized with the contents of the original message. Putting a '*' in fields of the masks will, as a result, produce the contents of the header of the original message. Example: Action MakeMsg c:\body.txt Art, 2:281/527.0, SysOp, 1:138/211.0, Poll!, +l This will generate a message to SysOp on 1:138/211, with body.txt as the body of the message. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. ■ BOUNCEIN ■ HDRBOUNCEIN ■ EMPTYBOUNCEIN ■ XBOUNCEIN {+} ■ XHDRBOUNCEIN {+} ■ XEMPTYBOUNCEIN {+} ■ FORWARDIN ■ MAKEMSGIN ──────────────────── Several actions have a similar counterpart, that can place the resulting message in another area. The actions concerned are: the Bounce and XBounce 'family', Forward and MakeMsg. In order to place the resulting message in another area, add 'IN' to the action name (to make BOUNCEIN, XBOUNCEIN, XEMPTYBOUNCEIN, FORWARDIN etc), and add the path/name of the area to put the message in. Some examples: Action XBOUNCEIN $d:\msg\net bounce.txt The Bouncer, @myaka, *, *, *, +l This will create a bounce message in the Squish area d:\msg\net. Action FORWARDIN !c:\msgbase\netmail *, *, Pietje Puk, 2:2/2.0, *, +l This will forward a message to 'Pietje Puk (2:2/0)' in the JAM style area c:\msgbase\netmail. ■ CHANGEPATH <new path> ─────────────────────── This action replaces the path of files found in the subject line. It makes sense to only use this for file attach messages, as you will get a terribly messed up subject line otherwise :-) Example: Action ChangePath c:\frodo\infiles In the above example, the subject line: Subj: c:\tmp\myfile.txt d:\outfiles\test.txt will be rewritten to: Subj: c:\frodo\infiles\myfile.txt c:\frodo\infiles\test.txt If a file does not have a path at all, the defined path will be added: Subj: test.txt will get: Subj: c:\frodo\infiles\test.txt If the defined change will lead to a subject line that is too long (the new path is longer than the old one, and the subject would get longer than 71 chars) the message will not be changed. Note that the actual file is left untouched. NetMgr only works on the subject line of the message. No actual files are moved. ■ CHANGEPATHMOVE <new path> ─────────────────────────── This works exactly like 'ChangePath', but it also moves the attached file(s) to the new directory. ■ ECHOCOPY <address> <area> <seenby> ──────────────────────────────────── Copy a netmail message to an echomail area. Add an origin and (optionally) a SEEN-BY: line. The address used as origination address (in the origin, MSGID) is the first item( <address>). As all addresses in Netmgr.cfg, this needs to be a full 4D address. You *must* specify an address here, because NetMgr needs this information to generate a correct Origin line. Specifying a '*' is not allowed. Leave SEEN-BY: info out if you don't want it. The text put here is just duplicated in the SEEN-BY line, so you can put more than one address here. Take care what you specify: the text is simply copied verbatim. If you specify an illegal address or format, NetMgr will simply copy it, making the message invalid. If the original message already contained a tear- or origin line, NetMgr will strip it and replace it with a newly generated, correct tear/origin line. This makes sure the correct address is used in the origin line and that the message is a valid echomail message (with an origin line). NetMgr also adds or replaces the MSGID with a newly generated, correct (ie: using the correct address) MSGID. The result of all this should be a valid, fresh echomail message, that has the same header and body as the original message. The original message will be left untouched. An example: Action EchoCopy 2:281/527.0 $c:\msgs\maillist This will take a message and generate an echomail message out of it, using 2:281/527 as Origin address. The echomail message will be generated in the Squish area (because of the leading '$' that denotes a Squish style area) c:\msgs\maillist. No SEEN-BY will be added. Action EchoCopy 2:281/527.0 !c:\msgs\maillist 281/528 This will take a message and generate an echomail message out of it, using 2:281/527 as Origin address. The echomail message will be generated in the JAM area (because of the leading '!' that denotes a JAM style area) c:\msgs\maillist. The string '281/528' will be added to the SEEN-BY. Action EchoCopy 2:281/527.0 !c:\msgs\maillist 281/528 529 This will take a message and generate an echomail message out of it, using 2:281/527 as Origin address. The echomail message will be generated in the JAM area (because of the leading '!' that denotes a JAM style area) c:\msgs\maillist. The string '281/528 529' will be added to the SEEN-BY. Action EchoCopy 2:281/527.0 #13 pietje puk This will take a message and generate an echomail message out of it, using 2:281/527 as Origin address. The echomail message will be generated in the Hudson board (because of the leading '#' that denotes a Hudson style area) number 13. The string 'pietje puk' will be added to the SEEN-BY. This will generate an invalid message and you will definitely be in trouble because of this! ■ ECHOMOVE <address> <area> <seenby> ──────────────────────────────────── Move a netmail message to an echomail area and add an origin and optionally a SEEN-BY. The address used as origination address (in the origin, MSGID) is the first item( <address>). As all addresses in Netmgr.cfg, this needs to be a full 4D address. You *must* specify an address here, because NetMgr needs this information to generate a correct Origin line. Specifying a '*' is not allowed. Leave SEEN-BY: info out if you don't want it. The text put here is just duplicated in the SEEN-BY line, so you can put more than one address here. Take care what you specify: the text is simply copied verbatim. If you specify an illegal address or format, NetMgr will simply copy it, making the message invalid. If the original message already contained a tear- or origin line, NetMgr will strip it and replace it with a newly generated, correct tear/origin line. This makes sure the correct address is used in the origin line and that the message is a valid echomail message (with an origin line). NetMgr also adds or replaces the MSGID with a newly generated, correct (ie: using the correct address) MSGID. The result of all this should be a valid, fresh echomail message, that has the same header and body as the original message. The original message in the netmail area will be deleted. ■ IGNORE ──────── This action does absolutely nothing, but is it a 'match', so scanning for a matching mask will stop after this. For example: Mask *, 2:281/527.0, *, *, *, * Mask *, 2:281/528.0, *, *, *, * Mask *, 2:281/529.0, *, *, *, * Action Ignore Mask *, *, *, *, *, * Action Delete This will make sure the 'delete' action is never reached for messages originating from 281/527, 281/528 or 281/529. ■ PACKMAIL <origination address> <destination address> [<password>] ─────────────────────────────────────────────────────────────────── This action keyword activates NetMgr netmail packing capabilities. NetMgr will take the message and place it in a mailpacket in a Binkley style outbound area (these mailpackets are always called '*.?UT). The mailpacket header will contain the addresses you specify here. So the mailpacket will be from <origination address> to <destination address>. Please note that this is only in the PACKET HEADER, not the individual messages that are inside the packet. Those individual message (obviously) have the origination and destination addresses that were present in the message itself when it was found in your netmail area. The origination address *must* always be a fully specified 4D address, using '*' is not allowed (NetMgr needs an address to use as origination address). In the destination address, however, you are allowed to use '*'. The destination address of the mailpacket will then be the same as the destination address of the individual message that is being packed. Making clever use of '*' for (parts of) the address will allow you to do routing of messages. The third parameter is optional and, when used, specifies the packet password to use when creating the mailpacket. Currently, NetMgr will properly: - Request files (make a *.REQ file in the outbound). - Attach files (make an *.?LO file). FLAGS KFS (Kill file after it is sent) & TFS (truncate file after it is sent) are supported. - Pack (bundle and put in outbound, not compress) messages (make and/or add to *.?UT files in outbound). - Strip paths from subject lines of 'file attach' messages. - Handle update requests. - Handle (update) requests with passwords. - Generate and check for busy (*.BSY) flags in the outbound. The packing is dumb. NetMgr will happily pack messages to yourself, for example. Or route files to an overseas system, even if they are not coming from your system. Or route file requests. Like all other commands, NetMgr simply scans headers and does what it's told, the logic of it's actions has to come from YOU. The only 'intelligence' of the packmail function: ■ It will not pack messages that are 'sent' or 'locked'. ■ It will automatically set the 'sent' bit after sending. ■ If the message is 'kill/sent', it will delete the message after it is successfully added to the mailpacket in the outbound area. Here are the four main forms will most likely be used for the PackMail action: PackMail <address> * : Send/Route messages to the destination address found in message header (even if it's a point!). This would be applicable for 'hold' mail to/for points. PackMail <address> <address b> : Send/Route messages to address b. All messages, regardless of their destination address, will be routed to <address b>. This would be applicable for normal flavour mails, that can be routed to a Boss or HUB node. PackMail <address> *:*/*.0 : Send/Route messages to the second address, with the pointnumber always set to 0 (in other words: do Bossrouting for this entry). This would be applicable for 'crash' mail for points. Most points do not run a continuous mail system (usually you don't even know a phonenumber), so a crashmail for a point would usually have to be delivered at the point's Bossnode. PackMail <address> *:*/0.0 : Send/Route messages to node 0 in the net of the destination address found in the header (HostRouting). You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. ■ MOVEMAIL <orig> <dest> <dir> [<password>] ─────────────────────────────────────────── <orig> : origination address to use (in mailpacket header). <dest> : destination address to use (in mailpacket header). <dir> : output directory for packet. <password> : packet password to use for the mailpacket (optional). This will create a mailpacket, not in Binkley's outbound but in the <dir> you specify. The packetname will be a unique name created by NetMgr (it is an uncompressed packet, so the extension will be .PKT). The packet will be from <orig> and addressed to <dest>. You can also use '@myaka' instead of 'address' as the origination address. This will let NetMgr pick the most appropriate AKA automatically. See the special section about AKAmatching later in the documentation. Using '*' for <dest> is not allowed here (I don't think it is useful - it can be added though). If a file is attached to the message, it will be copied to <dir> as well. The FLAGS KFS & TFS are respected; after the file is copied it will be deleted or truncated if one of these flags is set. The 'sent' bit is set after the message is added to the mailpacket, or the message is killed (when a message was marked kill/sent). Messages that are either Sent or Locked will not be processed. Possible uses: mail delivery through a LAN, maybe also sending mail to gateways on your system. ■ RUNEXTERNAL <program to use> <parameters> ─────────────────────────────────────────── This action allows you to run an external program from NetMgr. Before running the external program, NetMgr will swap most of itself out of memory (DOS version), leaving plenty of room for other programs to run. In the <parameters> part, you can make use of several 'variables', whose value depends on the contents of the header of the message that triggered the action. The variables should always be enclosed by square brackets. The following variables are available: [from] - Name in the 'from' field of current message. [to] - Name in the 'to' field of current message. [subject] - Name in the 'subject' field of current message. [orig] - Origination address of current message (like 2:281/527). [dest] - Destination address of current message (like 2:281/527). [areadir] - Directory or base name of current area, board number if Hudson. This is in the format that is also used in NetMgr.cfg, so $<path+basename> for a Squish area, !<path+basename> for a JAM area etc. [msgno] - Message number of current message ('relative' number for Squish and Hudson) [realmsgno] - Real message number, for Squish (UMSGID) and Hudson (real number in Hudson base, not the relative number in the area). For JAM and *.MSG, this is always equal to msgno. [file] - Name of the file that contains the body of the message. [newfile] - Name of a new file to create if you want to replace the body of the message with new text. [repfile] - Name of the file that should be created if you want to send a message back to the sender of the message. (See below). [attach] - Files attached to this message (list of files). [request] - Files requested in this message (list of files [!passwords]). Before running the external program, NetMgr will write the body of the message to a file. This file (and other files) will be created in the directory where NetMgr found it's config file. The path+name of this file is available through the variable [file]. It will be: "<path to config file>\netmsg.msg". NetMgr will then run the external program, and afterwards check for the existence of two files: ■ "<path to config file>\netmsg.new" : if this file exists, NetMgr will replace the body of the message with the contents of this file. The path+name of this variable is available through the variable [newfile]. ■ "<path to config file>\netmsg.rep": if this file exists, NetMgr will send a message back to the sender of the message that triggered this action. What is actually done, is an XEMPTYBOUNCE action. For this action, the netmsg.rep file is used as the body (where the variables like [from], [to] etc. can be used), but where the first line of this .rep file is used as the 'mask' for the reply header. Because it actually _is_ an XEMPTYBOUNCE, it also follows the same conventions as the XEMPTYBOUNCE action, so it initializes the fields with a standard reply header, which makes it possible to use a simple '*, *, *, *, *, *' mask (see XEMPTYBOUNCE action for more info). The path+name of this variable is available through the variable [repfile]. An example: Action RUNEXTERNAL pgp.exe +batchmode -sta -u art -o [newfile] -z pass [file] could expand to: 'pgp.exe +batchmode -sta -u art -o c:\net\netmsg.new -z pass c:\netmgr\net.msg' This would run PGP on the message, and sign the text. The body of the message will be replaced with a signed version of the text. An example of usage of a .rep file could be: Action RUNEXTERNAL reply.cmd [repfile] And the contents of 'reply.cmd' could be: @echo off echo Automatic Reply, @myaka, *, *, Response to your message, * >> %1 echo Hello %%ffrom! >> %1 echo. >> %1 echo This is an automatic reply! >> %1 echo. >> %1 echo Greetings! >> %1 For DOS users, 'reply.cmd' should of course be 'reply.bat'. This would create a netmsg.rep file, and NetMgr would send back a small message to the sender of the original message. ■ Display <line to display> ─────────────────────────── This one will display a line of text on the screen and in the logfile. You can use this to add details about certain actions to the logfile. Example: Mask *, *, Pietje Puk, *, *, * Action Display Deleted message to Pietje Puk! Action Delete Whenever this action is executed, the line 'Deleted message to Pietje Puk!' will be shown on the screen and added to the logfile. Leading and trailing spaces are not touched, the line is displayed exactly as found in the config (The first space, between 'Display' and 'Deleted' in this case, *does* of course get stripped..). Please note that some actions prevent NetMgr from looking for more actions to perform. Delete is one of them: after a message is deleted, there is nothing that can be done with that message anymore and NetMgr stops scanning for more actions. (Echo-)move is another example. Of course, 'Display' is something that *can* be done even after a message is deleted, it is an exception to this. But NetMgr is not that smart, so keep it in mind and do the 'display' first. So this: Mask *, *, Pietje Puk, *, *, * Action Delete Action Display Deleted message to Pietje Puk! Doesn't work, because NetMgr will never get to the 'Display' action. Some other examples of Action statements. ========================================= -- Action Delete Delete the message -- Action Move $c:\bink\msgs\net2 Move a message to the Squish style (leading $) area c:\bink\msgs\net2. -- Action Move c:\msgs\rec_msg Move a message to the *.MSG style (no leading $, ! or #) area c:\msgs\rec_msg\. -- Action Copy !c:\jammsgs\saved Copy a message to the JAM style (leading '!') area c:\jammsgs\saved. -- Action Rewrite *, *:*/*.0, *, *, *, * Change a message header. Any field that has a '*' will be left untouched (in this case the Fromname, the fromaddress zone, net and node parts), the toname, the toaddress and the attributes. So, to be more precise: only the point number of the message sender will be changed. Messages coming from 2:281/527.40, for example, will be changed to a message coming from 2:281/527.0. -- Action ReWrite *, *, Pietje Puk, *, *, * This will rewrite the 'toname' part of a message, it will put "Pietje Puk" in the TO: name-field. -- You can also tell NetMgr to change the attributes of a message. Again, any attributes must be preceded by a '+' or '-'. A '+' in this case means: set this bit. A '-' in this case means: turn this bit off. so.. +p+l+k-c-f .. will turn ON the P)rivate, L)ocal and K)ill bits, and turn OFF the C)rash and F)ile request bits. Other attributes are left untouched. Examples: Action Rewrite *, *, *, *, *, -c+p Turn off the crash bit for that message. Turn ON the P)rivate bit. Action Rewrite *, *, *, *, *, -c-a-f-d-m-t-e-z+h+p+k Turn off the crash, attach, request, direct, immediate, Truncate file sent, Kill file sent and Archive file sent bits for that message. Turn ON the P)rivate bit, K)ill bit and H)old bit. This could be used to strip all 'dangerous' bits off a message an make sure it is a private message that will be put on hold for pickup. It might be useful to perform an action like this on all message that you are routing for someone else, for example. -- Action Bounce 2:281/527.0 nojoe.txt This will write a bounce-message (a message that is addressed to the sender of that message), the message body will contain the header and body of the original message. The address 2:281/527.0 is used as origination address for this message. Also, NetMgr will add the contents of a textfile at the top of the body. In this case the contents of the file 'nojoe.txt' will be added. The contents could be: -=- <begin> -=- Sorry, but Joe's modem had a heart attack, so he is currently not available. The message you wrote will remain 'on hold' until he has a new modem. The original text of your message: :::: -=- <end> -=- And that will be added at the top. The original message will NOT be deleted. If that is what you want, you must add the another ACTION for that MASK, to DELETE the message. NetMgr accepts more than one 'ACTION' for a certain mask. You can also, for example, first rewrite a message, and then move it, etc. -- Action EchoCopy 2:281/527.0 #57 281/527 528 This will copy a message to the Hudson style area, board number 57, and add 281/527 528 to the SEEN-BY. The text listed will be copied literally, so be VERY CAREFUL what you specify here! Test it thoroughly (together with any downlinks) before using it!! The newly created echomail message will show 2:281/527 as its origination address in the origin. -- Action File c:\msgs\netmsgs.txt This will write out a message to the file c:\msgs\netmsgs.txt. If the file doesn't exist, it will be created. If it does exist, the message will be appended to the file. -- Action UUCPrewrite *, *, postmaster, 2:281/527.0, *, +p+k+l This will take the name from the TO: field, and add it at the top of the message body (TO: <toname>). The message itself will be readdressed to postmaster at 2:281/527, and have the attributes p)rivate, k)ill and l)ocal added. This can be useful for people who gate messages to internet. -- Action Semaphore c:\frodo\sems\areafix.sem This will create (or touch) a semaphore called areafix.sem. You may use this to create semaphores that will start Areafix only when a message to areafix was actually encountered by NetMgr (as opposed to running areafix after every mailtoss). ┌───────────────────────────────┬─────────────────────────────────────── │ MASK and ACTION in NetMgr.cfg │ └───────────────────────────────┘ A MASK must *always* have one or more corresponding ACTION(s) in netmgr.cfg. NetMgr will NOT run if anything is wrong in the config. Whenever you make any changes to the configuration file, please give it a test run to see if any syntax errors pop up. There are always 'pairs': Mask *, *, Harry Twit, *, *, * Action Delete Any message that matches the MASK will be deleted. -- Mask *, *, *, 60:*/*.*, *, * Action Move !c:\bink\msgs\net2 Any message addressed to a zone 60 address will be moved to the specified JAM area. -- Mask *, *, *, *, *, +r Mask Move $c:\msgs\received All received messages will be moved to the specified Squish area. -- Mask *, 2:281/527.0, *, *, *, +f Action Packmail 2:281/527.0 * This takes all file request messages, generated by 2:281/527, and properly generates a request out of it. The request will be addressed to the system that is also found in the 'destination address' field of the message (that makes sense) :-) Mask *, 2:281/527.0, *, 1:*/*.*, *, +l Action Packmail 2:281/527.0 1:138/211.0 This will take all messages from 281/527, addressed to any zone 1 system, and pack them in a mailpacket addressed to 1:138/211. Mask *, 2:281/527.99, *, *, *, +l-c-h-d-a-f-u Action Packmail 2:281/527.99 2:281/527.0 This will take all messages that originate from 2:281/527.99, that have the local bit set, and that are NOT crash, hold, direct, file attach, file request or update request. In other words: all 'normal' messages. These message are packed in a packet addressed to 2:281/527.0. In effect, all 'normal' messages would be routed to 2:281/527.0. And considering that 2:281/527.99 is a point off of 2:281/527, that makes sense: all normal messages are routed through the Boss node. File requests, crash messages and such are not: they need to be sent directly to the destination. That could be done with the following Mask/Action lines: Mask *, 2:281/527.99, *, *, *, +l Action Packmail 2:281/527.99 *:*/*.0 If the above line would be placed in NetMgr.cfg *below* the Mask we just saw, we would only get to this mask if the message is indeed crash or file request and the like: otherwise they would already have been packed with the previous Mask/Action. This mask takes all message originating from 2:281/527.99 with the local flag set, and routes them to the Bossnode of the system found in the destination address of the message. For file requests, crash messages and comparable types of messages, this is usually the correct action: requests have to be dropped at the system directly in order to get the files. Crash messages are usually not routed (because you want to deliver them ASAP). And because points usually don't have a system online at all times, the messages are routed to the Bossnode (that often is online at all times) of that point. It is also possible to specify SEVERAL actions for one mask: Mask *, *, Pietje Puk, 2:281/527.0, *, * Action Bounce 2:281/527.0, c:\txt\newaddr.txt Action File c:\msgs\pietje.txt Action Forward Art, 2:281/527.0, Pietje Puk, 2:300/1.0, Readdressed mail, +l Action Delete Take a while to check this out. What it does is this: Whenever a mail addressed to 'Pietje Puk' on 2:281/527 is encountered, this message will be bounced back to the sender. The contents of the file 'c:\txt\newaddr.txt' will be added at the top of the message (possibly explaining that Pietje now has a new email address). Then, the contents of the message will be written to a file (pietje.txt). The message will also be forwarded to 'Pietje Puk' on '2:300/1', which is Pietje's new netmail address (so he gets his message anyway). And finally, the original message is deleted. You can also use more than one Mask, and combine it with one or more actions! For example: Mask Gerard van Essen, 2:281/527.0, *, *, *, +s Mask *, *, Gerard van Essen, 2:281/527.0, *, +r Action Move $c:\fastecho\rcvdsent This will take all messages FROM Gerard van Essen (2:281/527) that are 'sent', and also all message TO Gerard van Essen (2:281/527) that are received and moves these to a Squish message area (rcvdsent). In other words: all received and sent netmail is moved out of my primary netmail area. This means, that either the first Mask has to match, OR the second mask has to match. If either of them matches, he action will be performed. This is known to confuse users, if you also use 'NOT' in a certain mask. Some examples will hopefully clear this up a bit: Mask Gerard van Essen, *, *, *, *, * Action Delete This will delete a message if it is written by Gerard van Essen. Mask !Gerard van Essen, *, *, *, *, * Action Delete This will delete a message if it is NOT written by Gerard van Essen. Mask Gerard van Essen, *, *, *, *, * Mask Pietje Puk, *, *, *, *, * Action Delete This will delete a message if it is written by Gerard van Essen, OR if it is written by Pietje Puk. If any of the two masks match, the action will be performed. Mask !Gerard van Essen, *, *, *, *, * Mask Pietje Puk, *, *, *, *, * Action Delete This will delete a message is it is NOT written by Gerard van Essen, OR if it is written by Pietje Puk. If any of the two masks match, the action will be performed. In this case, a message written by 'Gerard van Essen' does not match the first mask (that one matches only messages that are NOT written by Gerard van Essen), nor does it match the second mask (that one only matches messages written by Pietje Puk). The 'Action Delete' will not be performed. A message written by 'Jos Verstappen' does match the first Mask (Jos Verstappen is 'NOT Gerard van Essen' so that is a match with the first mask. The 'Action Delete' is performed. Mask !Gerard van Essen, *, *, *, *, * Mask !Pietje Puk, *, *, *, *, * Action Delete This will delete a message if it is NOT written by Gerard van Essen, OR if it is NOT written by Pietje Puk. If any of the two masks match, the action will be performed. In this case, a message written by 'Gerard van Essen' does not match the first mask (that one matches only messages that are NOT written by Gerard van Essen), but it does it match the second mask (that one matches messages NOT written by Pietje Puk). And since 'Gerard van Essen' is 'NOT Pietje Puk', it matches the second Mask. The 'Action Delete' will be performed. A message written by 'Jos Verstappen' does match the first Mask (Jos Verstappen is 'NOT Gerard van Essen' so that is a match. The 'Action Delete' is performed. As you can see, ANY message matches one of the above masks! If a message is written by "gerard van essen", it will match the second mask. If a message is written by "pietje puk", it will match the first mask. If a message is written by anyone else, it will match either of the masks. So a message always matches at least one of the masks. With the above example, all messages in the netmail area would be deleted. Finally, you can also combine several masks with several actions. Mask Gerard van Essen, 2:281/527.0, *, *, *, +s Mask *, *, Gerard van Essen, 2:281/527.0, *, +r Action File c:\msgs\oldmail.txt Action Delete This will write all received and sent netmail to a file, and then delete it. ┌─────────────────────────┬──────────────────────────────────────────── │ NetMgr's scanning logic │ └─────────────────────────┘ For each message found in the netmail area, NetMgr will scan the defined masks (for a certain 'ScanDir', see below) and check whether any of them matches. As soon as a match is found, all 'Actions' for that 'Mask' are performed (you can have more than one action for each Mask, as you now know). After all these Actions are performed, NetMgr will *not* scan for any more matching masks. It will simply go to the next message in the netmail area and start scanning for a match for that next message again. This means, that if you have TWO masks that actually match a certain message, only the first one that is encountered will be found (and as a result only the actions that belong to that first mask will be performed). As an example, take these two mask/action combinations: Mask *, *, Pietje Puk, *, *, * Action Copy c:\fd\netmail Mask *, *, *, *, *, +c Action ReWrite *, *, *, *, *, -c Clearly, the user wants to reset all 'crash' bits with the second mask/Action combination. However, whenever a message to 'Pietje Puk' is encountered, NetMgr will perform the action for that mask (and copy the message to c:\fd\netmail) and then stop scanning. So in that case, the second mask will never be evaluated. Even if it does match (a crashmail message), the action for the second Mask will never be performed. If a message to Pietje Puk is marked as 'crash', it will be copied to the netmail area with the crash bit set. If you want to reset the crash bit, even for message to Pietje Puk, you can simply add the rewrite to the first mask as well, like this: Mask *, *, Pietje Puk, *, *, * Action ReWrite *, *, *, *, *, -c Action Copy c:\fd\netmail Mask *, *, *, *, *, +c Action ReWrite *, *, *, *, *, -c In this case, even messages to Pietje Puk will have their crash bit reset. Using this technique, anything you want can still be done. Just copy the Action statement and add them to the other masks as well. ┌────────────────────────┬────────────────────────────────────────────── │ eXtended Masks (XMASK) │ └────────────────────────┘ NetMgr offers another kind of mask: the eXtended mask (XMASK). As the name implies, these masks offer more than a standard mask. Xmasks allow the user to specify more criteria for the search. If this is the first time you are looking into NetMgr, it might be a good idea to either skip this section, or just glance through it a bit to see what is possible. You can do a lot with just standard masks, and it might be wise to play around with them a bit before going a step further and dive into extended masks as well. XMASKS take a bit more room than a standard mask. They can be used together with standard masks (even mixed within the same config). To define an extended mask, use the XMASK keyword. An XMASK definition always starts with this keyword, and always ends with a line with only 'End' on it. Between these two lines, search criteria are defined. An example: Xmask from Gerard van Essen End This defines an XMASK, that looks for messages that are FROM: 'Gerard van Essen'. You can specify more than one criterion. The number of criteria allowed for a mask is only limited by available memory. For a message to be a match, it must satisfy _all_ requirements that are defined. So, if you have: Xmask from Gerard van Essen to pietje puk End A message is only a match when it is from 'Gerard van Essen' _and_ to 'pietje puk'. The following keywords can be used in an XMASK: from - who the message is from to - who the message is to subject - the subject of the message attr - attributes of a message (like +a-p etc, like a standard mask) kludge - a search text to be found in the kludges of a message body - a search text to be found in the body of a message bodybytes <n> - how many bytes of the message body must be searched to find the string(s) specified to find in the body. bodylines <n> - how many lines of the body to search, or actually paragraphs, separated by a CR (ASCII 13, '\r'). orig - origination address of the message (like 2:281/527.0 - always 4D) dest - destination address of the message (like 2:281/527.0 - always 4D) olderwritten <n> - 'Date written' of the message must be older than n days. olderprocessed <n> - 'Date processed' of the message must be older than n days (JAM, Squish, SDM). olderread <n> - 'Date msg read by recipient' of the message must be older than n days (JAM only). When searching for a string (from, to, subject, body, kludges), you can also enclose a string in either single or double quotes. This gives you the opportunity to search for trailing and/or leading spaces. Even when quotes are used, the ~ (substring) and ! (NOT search) tokens are still supported, just like in normal MASKs. These tokens must be entered inside the quote, so "~gerard" will look for the substring 'gerard' to be present anywhere. AND and OR searches. -------------------- Specifying a certain keyword more than once, gives you an AND search. As mentioned before, _all_ requirements that are defined must be met. So specifying ... Xmask body "gerard" body "timed" End ... will look for messages that have 'gerard' AND 'timed' in the body. However, you can also do an OR search, by specifying more than one element on the same line, always enclosed in quotes and separated by the OR keyword, like this: Xmask body "gerard" OR "timed" End This will look for messages that have 'gerard' in the body, OR that have 'timed' in the body. You can also do a similar thing with addresses: Xmask orig 2:*/*.* OR 1:*/*.* End This will look for message originating from either zone 2 or zone 1. You can also do an AND search with addresses: Xmask orig 2:*/*.* orig !2:281/527.* End This will look for messages originating from zone 2, and NOT from node 2:281/527 or any of its points. NetMgr also allows the OR construction for attributes. So something like this is also possible: XMASK From Gerard van Essen Orig 2:281/527.0 Attr +c OR +a+l OR +f-c END This mask will match all messages that are flavoured crash, or are flavoured 'attach' and 'local', or flavoured 'request' but NOT crash. Please note that this construction is not valid for the attributes that need to search the nodelist (# and @). You can specify these attributes like this, but they are checked once, separately from the other attributes. So you cannot specify: Attr +c-@ OR -c+@ or something similar. You can only specify these attributes once and they will then be carried over to all other attribute masks. In other words, specifying this: Attr +c-@ OR +l will actually be expanded to: Attr +c-@ OR +l-@ Using files as input for a search item. --------------------------------------- Finally, for from, to, subject, kludges, body, orig and dest, you can also specify a filename as input. The filename must be preceded by a '<', like this: to <c:\data\names.txt The file itself should consist of a number of lines, all with one string/address to look for. If any of the strings/addresses are found, this will be considered a match (so that is an 'OR' search). In the case of the example with names.txt above, the file could look like this: -=- Areafix Areamgr SQafix -=- Any message addressed to 'Areafix', OR 'Areamgr' OR 'SQafix' will be a match. Leading and trailing spaces on a line in the file will be stripped. Quotes are not allowed. However, use of the '~' and '!' tokens _is_ allowed. Using an XMASK. --------------- One or more XMASKs must be combined with one or more actions (they are just like a standard MASK in this respect): XMASK from Gerard van Essen End Action Delete So apart from the fact that an XMASK is spread over more than one line, using it a the same as a standard MASK. You can also define an XMASK, give it a name, and use it later on in the .cfg file. To define an XMASK, use the 'DefineXmask' keyword: DefineXmask <mask name> ... <mask criteria> ... End Like this: DefineXmask personal to "Gerard van Essen" OR "gerard van.essen" OR "art" OR "Geer art" End Later on, you can then use the XMASK named personal again: XMASK personal Action Move $c:\mail\personal This gives you the opportunity to make the Mask/Action combination a bit more compact and (hopefully) clear. The ability to define XMASKs without a directly connected action is also exploited to allow posting messages from the command line (see special section about this). ┌────────────────────────────────────┬───────────────────────────────── │ Areas to scan: the ScanDir keyword │ └────────────────────────────────────┘ There's one more important keyword in NetMgr.cfg, and that's the ScanDir keyword. This will give NetMgr an area to Scan for messages that match a Mask. Example: ScanDir c:\fd\netmsgs The default is a *.MSG area, but: A '$' in front of an area indicates a Squish style area. A '!' in front of an area indicates a JAM style area. A '#' in front of an area indicates a Hudson style area. You can have as many of these as you like, NetMgr will scan each and every one of them. But, just as a certain action is related to a certain mask, certain action/mask combinations are related to a ScanDir statement. When a ScanDir statement is found in NetMgr.cfg, all Mask/Action combinations following that ScanDir up to the next ScanDir statement will (only) be valid for that particular ScanDir. ScanDir c:\fd\netmail Mask A Action .. Action .. Mask B Action .. Mask C Action .. ScanDir c:\fd\usenet Mask D Action .. In the above example, c:\fd\netmail will be scanned for Mask A, B and C, but not for Mask D. c:\fd\usenet will (only) be scanned for Mask D. You can also specify more than one ScanDir, followed by one or more Masks. All ScanDirs will be scanned for those masks. ScanDir c:\fd\usenet ScanDir $c:\fd\netmail Mask E Action In the above example, both c:\fd\usenet and $c:\fd\netmail will be scanned for mask E. Renumbering *.MSG areas. ------------------------ For *.MSG areas, you can specify the optional 'renum' keyword when you define the area using the 'ScanDir' keyword.. After scanning the area, NetMgr will then renumber the area (and adjust the lastread pointer when necessary). Example of such a definition: ScanDir c:\fd\netmail renum ┌───────────────────────┬─────────────────────────────────────────── │ Automatic AKAmatching │ └───────────────────────┘ NetMgr has AKAmatching capabilities, that can be used in several places. In order to let NetMgr do this, add all the addresses you might want to use to NetMgr.cfg (multiple 'homeaddress' statements are allowed). By default, NetMgr can do the matching for you without any further info. This option is interesting if you have more than 1 address. NetMgr can then be ordered to find the most appropriate address to use when writing a message. Say, for example, that you have two addresses: 2:281/527 and 60:100/112. If you write a messages to 2:500/133, you probably want to use your 2:281/527 address. If you write a message to 60:100/1, you probably want to use your 60:100/112 address. In this case, NetMgr would try to find the address (AKA) that 'matches' the destination address best. It first looks for a matching zone, and if more than one match is found, it'll try to find an address where both 'zone' and 'net' match. If there is still more than one match after that, it will just take the first match. If you want to make exceptions to these matching rules, or if you want to do AKAmatching _within_ a certain net, you can force NetMgr to use certain AKA by using the AKAFORCE keyword in NetMgr.cfg. Where does it work? First of all, NetMgr can pick the correct AKA to use when generating a new message using one of the BOUNCE, XBOUNCE, MakeMsg or Forward actions. In order to let NetMgr pick an appropriate address, use '@myaka' instead of a 4D address. For example: Action Bounce @myaka c:\txt\bounce.txt Or: Action Xbounce c:\txt\bounce.txt The Bouncer, @myaka, *, *, Go away!, * You can also use the AKA matching with REWRITE. This is probably only useful when you are currently using NetMgr already to do AKAmatching with several masks. You may now be able to do it with one mask/action: Mask Gerard van Essen, *, *, *, *, +l Action Rewrite *, @myaka, *, *, *, * Finally, you can also use it for the PackMail and MoveMail actions, for the origination address: Action PackMail @myaka * This will pack all mail directly to their destination, and use a matching AKA in the packet header as origination address. Please note that this (obviously!) does not have any effect on the addresses used within the packed messages! Only the packet header is affected by this! ┌──────────────────────────────┬──────────────────────────────────── │ Other keywords in netmgr.cfg │ └──────────────────────────────┘ HOME ==== Example: Home 2:281/527.0 Your address. The zone is used as a default value for 'zoneless' messages (only *.MSG style areas). It is also used for Binkley style netmail packing: netmail for the zone of the 'home' address is placed in the directory defined with the 'OutBound' keyword in NetMgr.cfg. It is allowed to put in this statement more than once. This can be useful if you want to use NetMgr's AKAmatching capabilities (see special section on AKAmatching elsewhere in this document). ORIGIN ====== Origin NetMgr, (c) 1992-'96 Gerard van Essen An origin line, will be used for EchoCopy and EchoMove. INTLFORCE ========= If you add this to your NetMgr.cfg, timEd will _force_ an INTL kludge on any netmail it somehow writes (this includes messages touched through a REWRITE, COPY/MOVE etc). AKAFORCE ======== Format: AKAFORCE <mask> <address to use> With this statement, you can influence NetMgr's AKAmatching capabilities. In several places, you can let NetMgr do AKAmatching automatically. However, in some cases the automatic matching might not come up with the address you wanted. With AKAforce, you can force NetMgr to use a certain address in certain situations. example: AKAFORCE 50:*/*.* 49:500/1 This means: always use 49:500/1 as address when mail is sent to any zone 50 address. This forcing will take precedence over 'automatic' akamatching. LOG === Log c:\tc\netmgr\netmgr.log The location and name of your logfile. Leave this keyword out if you don't want a logfile. FRODOLOG ======== If the keyword 'Frodolog' is included in NetMgr.cfg, NetMgr will generate a logfile that looks like the logfile that FrontDoor generates. If you leave this keyword out, NetMgr will generate a Binkley style logfile. JAMLOG ====== For JAM areas, NetMgr now write NETMAIL/ECHOMAIL.JAM. Add the keyword 'JAMLOG' to NetMgr.cfg and give the directory to put the files in. Example: JamLog c:\fd\msgbase\ HUDSONPATH ========== The location of your Hudson message base. Use this only if you actually have a Hudson base. Hudsonpath C:\Tosser\Msgbase NODELIST ======== This gives the path to the Version7 nodelist. You may need this keyword if you want to use the special nodelist attributes ('@' and '#') that NetMgr supports to check whether an address is listed in the nodelist or not. Leave this out if you do not have a Version 7 nodelist. FDNODELIST ========== This gives the path to the Frontdoor or Intermail nodelist. You may need this keyword if you want to use the special nodelist attributes ('@' and '#') that NetMgr supports to check whether an address is listed in the nodelist or not. Leave this out if you do not have a FrontDoor or Intermail nodelist. GIGONODELIST ============ This gives the path to the GIGO nodelist index. You may need this keyword if you want to use the special nodelist attributes ('@' and '#') that NetMgr supports to check whether an address is listed in the nodelist or not. Leave this out if you do not have a GIGO nodelist. NetMgr includes a special compiler made by Jason Fesler (1:203/7707) to generate GIGO indexes. The GIGO index is pretty small (less than 100 kB for the current world nodelist), so if you do not have a Version7 nodelist nor a Frontdoor nodelist, you might want to make one. NODELISTCACHE ============= To speed up nodelist access to regularly checked nodes, there is a simple cache system for the nodelist checking: the last few nodes that were checked in the nodelist will be cached in a small file that is saved to disk at exit. For a new run, NetMgr will read this file and keep it in memory to check it before actually doing a lookup in the nodelist on disk. The number of nodes that are 'remembered' in such a way is configurable with the keyword 'CacheSize' (see below). The 'NodeListCache' keyword gives a path (not a filename, just the path) to store this 'cache file' with nodes. The name of this file will always be 'nodes.buf'. * Important: When you update/recompile your nodelist, erase the 'cache file', as the data that is cached may be invalid after the nodelist update! A node that is marked as 'unlisted' in the cache, may actually be listed after the nodelist is updated, and v.v.! CACHESIZE ========= With this keyword you can define the number of nodes to keep in the nodelist cache. If you usually have mail to 100 different addresses in your netmail area, set it to at least 100. Example: CacheSize 250 OUTBOUND ======== This has to point to your Binkley style primary outbound directory. It is required if you want to use the netmail packing capabilities that NetMgr offers (PackMail action). NetMgr can create names for outbound directories other than the default zone (names like: C:\BT\OUT.006) itself, so one 'OutBound' statement is all you need to specify in order to send mail to all zones. Domains are not supported. Example: OutBound c:\bt\out If my the zone of my primary address (as specified in the Home keyword in NetMgr.cfg) is for example 2:, this will put all mail for zone 2: in the directory "c:\bt\out". Mail for zone 1 will be put in "c:\bt\out.001" etc. ┌──────────────────────────────────────────────────┬─────────────────────── │ Posting files as a message from the command line │ └──────────────────────────────────────────────────┘ In order to post a file as a message, use the POST command on the commandline. To do a post, you first need to define an XMASK with DefineXMask in NetMgr.cfg. In that mask, specify "from", "to", "subject", and "orig" for echomail messages. For netmail messages, you need to add "dest" as well. Adding 'attr' is allowed, but not required. If you don't specify any attributes, NetMgr will default to (only) the 'local' attribute. When generating the message, NetMgr will use the info in this XMASK to generate the header for the message. On the command line, you specify which xmask to use, what file to use as body, the area to post in, and whether or not the area is an echomail area. To do this, the following command line options are available: -x : specify XMASK to use -a : specify area to use (use leading !, # or $ to indicate msgbase format) -e : specified area is an echomail area -f : ASCII file to use as body for the message Full example: Provided the following XMASK is defined in NetMgr.cfg: DefineXmask netpost from Gerard van Essen to NetMgr User subject Answer to your query orig 2:281/527.0 dest 2:2/0.0 End The following command line... NetMgr POST -xnetpost -a$c:\fd\netmail -fc:\txt\canned.rep ... would generate a new netmail message in the Squish style area 'c:\fd\netmail', with the header specified (i.e.: to 'NetMgr User', from 'Gerard van Essen' etc), and with the textfile 'c:\txt\canned.rep' as the body. NetMgr will start up, read the config, open the area, post the message, and then exit immediately (without scanning the netmail area as is normally done). When the -e command line parameter is used, NetMgr will add tear- and origin lines as well. Provided the following XMASK is defined in NetMgr.cfg: DefineXmask rules from Moderator to All subject The monthly rules orig 2:281/527.0 End The following command line... NetMgr POST -xrules -a!c:\echo\artware -fc:\txt\artware.rul -e ... would generate a new echomail message in the JAM style area 'c:\echo\artware', with the header specified (i.e.: to 'All', from 'Moderator' etc), and with the textfile 'c:\txt\artware.rul' as the body. ┌───────────────────────────────────┬───────────────────────────────────── │ Binkley style outbound management │ └───────────────────────────────────┘ NetMgr also offers some outbound management capabilities, usable from the command line. You can use one of the following commands on the command line: ■ POLL : create a poll packet for a certain node. ■ GET : create a filerequest for a certain node. ■ UPDATE : create an update request for a certain node. ■ SEND : create a file attach for a certain node. ■ CHANGE : change mail status for mail waiting for a certain node. To support this, the following command line options are used: -s : Status (also called 'flavour') of request/attach. -n : New status for mail (used for 'CHANGE'). -p : Password to use for file request. -# : Node address of node to request files from / send files to. -f : File to send/request. The 'POLL' command needs: -# and -s. The 'GET' command needs: -#, -f and -s (optional: -p). The 'UPDATE' command needs: -#, -f and -s (optional: -p). The 'SEND' command needs: -#, -f and -s. The 'CHANGE' command needs: -#, -s and -n. For the '-s' and '-n' options, the following flavours can be used: normal, crash, imm, hold, dir. Examples: NetMgr POLL -#2:281/527 -scrash Poll node 2:281/527, crash status. NetMgr GET -#2:500/133 -fnewfiles -shold -psecret Request from node 2:500/133, with 'hold' status, the file 'NEWFILES' and use 'secret' as password for this request. NetMgr SEND -fc:\autoexec.bat -simm -#1:138/211 Attach the file c:\autoexec.bat, with 'immediate' status, to 1:138/211. NetMgr CHANGE -snormal -ncrash -#2:281/527.5 Change the flavour of all mail destined for 2:281/527.5 flavoured 'normal' to a new flavour of 'crash'. For any of the above to work, you need to have the 'OutBound' keyword defined in NetMgr.cfg. ┌───────────────────────────────┬───────────────────────────── │ Other Command line parameters │ └───────────────────────────────┘ There are three other command line parameters: -D For 'debugging' purposes you can start netmgr with the -d command line switch. This will send NetMgr's interpretation of your config file to stdout. While scanning your netmail area, it will also send some info about the headers of the messages to stdout. You can easily redirect it to a file (netmgr -d > debug.txt) for inspection. In case of any problems with NetMgr, use this switch to determine what exactly is the problem! -- -C Here you can specify the name of an alternative Config file. For example: NetMgr -Cc:\netmgr\mycfg.txt -- -Q Enables 'quiet' mode. Hardly anything is written to the screen in this case. This speeds up processing a bit. ┌─────────────┬───────────────────────────────────────────────────────── │ Errorlevels │ └─────────────┘ Three possibilities: 0 : No errors, no work done. 1 : No errors, something done (move, copy, bounce or whatever. Anything.) 254 : Error occurred (out of memory, config error etc). Some bits and pieces..: * NetMgr was compiled using Watcom C/C++ v10.5. * NetMgr source code is not and will not be available. The author can be reached... The best thing is to hook into the ARTWARE support echo. I give support for my products there. It can be found in several places. It's also on the American Backbone! Gerard van Essen FidoNet: 2:280/408 Contrast BBS, 31-20-6889386 (V34+, V32bis, V32Terbo, V.FC, HST 16k8). Internet: art@users.toolnet.org Have fun.