OS/2 Shareware BBS: 2 BBS/02-BBS.zip/ntmgrg2.zip/NETMGR.DOC

Text File | 1995-12-22 | 88KB | 2,523 lines

 ===================================================================

            NetMgr - "The Swiss Army Knife for Netmail"

        Copy, move, delete, file, change and bounce netmail..

          (c) 1992,93,94,95  Gerard van Essen (2:281/527)

 ===================================================================


 !  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.g2
 Last update of this document : december 22, 1995

 Throughout the documentation, you will see items that are marked with a
 'plus' sign, like this: {+}.
 This indicates 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 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
 h = message is locked
 z = 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 Frodo 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  : [e-mail], 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: [e-mail]

 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.g2

 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 following variables are available:

 from       - Name in the 'from' field of current message.
 to         -             'to'
 subject    -             'subject'
 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 the only 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-'94  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 Frodo 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.0.

 * 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 (see support.txt).
 It's also on the American Backbone!


 Gerard van Essen
 FidoNet: 2:281/527
 Contrast BBS, 31-70-3234903 (V34+, V32bis, V32Terbo, V.FC, HST 16k8)
 Internet: [e-mail]


 Have fun.