




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 1

                                  INTRODUCTION
                                  ------------

          MTMAIL is a rudimentary FIDO echomail/netmail processor for
     Mutant BBS.  I wrote this program for a couple of reasons.  One,
     Mutant is a new BBS and it would not have any Fidonet support
     available.  Second, I do not have a job and what better to do with my
     time than write this program.

     NOTE: For the examples, I assume you running as either the boss or a
     point of 1:264/715 in this documentation as that is the address as I
     used while I was in college.

     Requirements
     ------------

          1) MS-DOS 3.0 or later.
          2) At least 384K of memory.  More is required if you are
             processing large messages, may echomail areas and/or many
             nodes per area.
          3) Mutant BBS v1.1.

     Exit Codes
     ----------

          Once MTMAIL has finished running, it will exit with the following
     errorlevels

          Errorlevel     Description
             0           Everything went fine.
             1           DOS/Memory error
             2-9         C generated errors
             10          Configuration/Command line error
             11          Echo/Netmail was imported into Mutant
             12          Echo mail was sent to other nodes
             13          Net Mail was sent to other nodes
             14          Both Echo&Netmail was sent
             15-255      Undefined error, should be ignored.

     As MTMAIL does not support routing, you may wish to run MTMAIL in a
     batch file to call a routing program or other processing utility after
     Echo/Netmail was output.

                                  INSTALLATION
                                  ------------

          MTMAIL can be run from any directory.  However, the logfile,
     duplicate message info and other MTMAIL files need to be found easily.
          MTMAIL will look for the environment variable "MTMAIL=path" and




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 2

     use the path specified.  If you do not set the environment variable
     and are running DOS 3.3+, MTMAIL will assume it's files are present in
     the directory where MTMAIL.EXE is found.  Otherwise, the current
     directory is used.

     MTMAIL.CFG
     ----------
          This contains the configuration information MTMAIL needs in order
     to run.  This is a text file you can create with your text editor. 
     The maximum line length is 254 characters.  You may use a ';' to
     insert comments.

     NODE

            This defines your node address and any AKA's you may use.  The
          first address is considered to be your primary address. The
          format of the Node statement is:

          NODE [Zone:]Net/Node[.PvtNet/Point].

          Unless stated, MTMAIL will assume that the first address is in
          Zone 1.  Specifying NODE 911/100 would be the same as NODE
          1:911/100.  If you use an address not in zone one, you must
          specify it.  For example, NODE 2:234/2.

          MTMAIL uses your best address depending on where the message is
          going.  For example, if you have NODE 1:911/100 2:234/2 and you
          send a message to zone 2, MTMAIL will use the 2:234/2 address for
          the message.  This also works in the net address also.  Say you
          have NODE 200/100 300/5 and send a message to 310/2, MTMAIL will
          use the 300/5 address.

          When set-up as part of a point system, you MUST specify your
          private net address.  For example, NODE 264/715.32050/3 would
          specify that you are point 3 off of Node 1:264/715, but any mail
          within the point system should be addressed as 1:32050/3.  If you
          do not have a private net address, you CAN NOT use MTMAIL for
          points.

          If you are not a point system, do not specify ".0" as part of the
          address or MTMAIL will NOT work properly. 

          Upon transition between points to the real world, or between
          zones, SEEN-BY and PATH lines are stripped.  For example, you are
          the boss and have the statement 

             NODE 1:264/715.32050/0

          Any mail sent to 264/700 would only contain 264/700 715 in the




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 3

          seen-bys and 264/715 in the path.  Any mail sent to point 3 would
          contain 32050/0 3 in the seen-bys and 32050/0 in the path. 
          Another example,

             NODE 1:264/715 2:234/5

          Mail sent to 2:200/10 would contain 200/10 234/5 in the seen-bys
          and 234/5 in the paths.  If you didn't have a node in zone 2 and
          sent mail to zone 2, you would not have an address in the seen-
          bys or the paths.

     DUPPATH

            This is where duplicate echomail messages will be stored in
          .MSG format.  If you do not specify this path, duplicate messages
          will be ignored (deleted).

          Example: DUPPATH C:\MAIL\DUPS

     MAIL

            This is where Netmail/Echomail inbound/outbound .MSG files are
          placed.  This is important if you are using a mailer program such
          as FrontDoor or need to route your mail.  Mailer's such as
          BinkleyTerm never use this directory.

          Example: MAIL C:\MAIL

     INBOUND

            This is where your mailer places any received packets or
          archived packets.

          Example: INBOUND C:\MAIL\INBOUND

     OUTBOUND

            This is where MTMAIL places outbound packets or archived
          packets.  This should not contain an extension.  For inter-zone
          setups, you will need to create subdirectories for any other
          zones then the zone specified in your primary address with the
          zone in hexadecimal as the extension.

          Example:

             OUTBOUND C:\MAIL\OUTBOUND

          if you were not running multizones, you would only create
          "C:\MAIL\OUTBOUND".  However, if you specified NODE 1:264/715 and




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 4

          created packets for Zone 16, you will need to create
          "C:\MAIL\OUTBOUND" and "C:\MAIL\OUTBOUND.010".

     BBSCONFIG

            This is the name and path of your configuration file for Mutant
          BBS.  MTMAIL uses the Message Base and File Attach paths from
          this file.

          Example: BBSCONFIG C:\MUTANT\CONFIG.DAT

     BADPATH

            This is where MTMAIL will place any bad echo mail messages.  If
          this is not specified, bad echo mail messages will be ignored.

          Example: BADPATH C:\MAIL\BAD

     ARCPATH

            This specifies a working directory where MTMAIL will create its
          temporary packets before putting them in the outbound path.  I
          recommend that this not be RAM drive in case of a power failure
          since MTMAIL will reuse this temporary packets the next time it
          outputs echomail. If this is not specified, MTMAIL uses the
          outbound path.

          Example: ARCPATH C:\OUT

     UNARCPATH

            This specifies where MTMAIL will unarchive packets.  As
          mentioned above, a RAM drive should not be specified as MTMAIL
          will look in this path the next time it processes incoming
          echomail.

          Example: UNARCPATH C:\IN

     SWAP

            This specifies where MTMAIL will swap itself to when it runs
          archive utilities.  MTMAIL only uses this if there is not enough
          EMS available to swap out itself. This could be a RAM drive or
          even Mutant's temporary directory.

          Example: SWAP C:\MTNTEMP

     ARCCOMMAND




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 5

             This specifies the command used to archive packets.

          Format: ARCCOMMAND name path\exe options
             name is a short (5 character) name for the archiver.
             path\exe is the program to run.
             options is the options for the archiver. This can contain "%A"
             for the archive filename and "%F" for the file to archive. 

          Example: ARCCOMMAND ZIP C:\UTIL\PKZIP.EXE -a %A %F

     UNZIP

            MTMAIL autodetects the type of compression used on incoming
          packets.  This specifies the program to run when ZIP is used.

          Format: UNZIP path\exe options
            path\exe is the program to run.
            options are command line options.
               "%A" - archive name
               "%F" - directory with ending backslash.

          Example: UNZIP C:\UTIL\PKUNZIP.EXE %A %F

     OMMM

            This specifies that you are running a mailer such as
          BinkleyTerm.  This essentially tells MTMAIL to create unarchived
          packets as .?UT or create file attach .?LO files.

     NETMAILAREA

            This specifies the Mutant area in which you wish to save
          netmail messages.  You MUST include this in the configuration in
          order for MTMAIL to run.

     NOSEENBY

            If this is specified, seen-bys will not be imported into
          Mutant's message base.  If specified, it also renders Mutant's
          display Seen-by option as useless.

     NOPATH

            If specified, path lines will not be imported into Mutant's
          message base.  Specify this and/or the noseenby option if you
          processing echo mail for many nodes.

     LOGLEVEL




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 6

            This specifies a default logging level.

          Level     Meaning
            0       MTMAIL begins/ends, out of memory errors
            1       File error
            2       Configuration Error
            3,4     Undefined at this time
            5       Processing information
            6       Detailed Processing information such as
                    movement/archiving of packets.
            7       Debugging info.  This displays the entire configuration
                    upon startup and memory statistics.

          The default loglevel is 5.

     MULTINODE

            If specified, MTMAIL will use DOS's file-sharing open flags
          when opening files.  If you running a Multi-node setup in Mutant,
          you should use this option.

     ARCNODES

            Specifies which archiving program to use for certain nodes.

          Format: ARCNODES name node

          Example: ARCNODES ZIP 1:264/715.5 200/5 6 7
             This would use the ARCCOMMAND whose name is "ZIP" and when
             sending mail to point 5, 200/5, 200/6 and 200/7.

     UNLZH

            Specifies the command to unlzh files.

          Example: UNLZH C:\UTIL\LHARC e %A %F

     UNZOO

            Specifies the command to unzoo files.

          Example: UNZOO C:\UTIL\ZOO -extract %A %F

     UNARJ

            Specifies the command to unarj files.

          Example: UNARJ C:\UTIL\ARJ e %A %F




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 7

     UNARC

            This is a bit different than the other archive formats as
          different ARC programs support different levels of compression.

          Format: UNARC max_type path\exe options

             max_type is the maximum compression type this utility
             supports.  The last value I heard was 10 with PAK v2.10.

          Example: UNARC 10 C:\UTIL\PAK e %A %F

     PASSFILE

            This specifies a filename where packet passwords are stored. 
          The format of this file is:

          node 7-character password

          You should only specify passwords for nodes you know support
          passwords at offset 1A (hex) in the packet header).  An example
          entry would be 1:264/715.5 FEEDME.

     AUTOCREATE

            This is the "lazy-man's" option.  I got tired of having to
          define stuff in AREAS.BBS and then create a message base for it
          in Mutant.  If you specify this option, and MTMAIL tries to toss
          an echomail message into a base that has not been created, MTMAIL
          will automatically create the specified base with what I consider
          standard echo mail defaults.  If this is not specified, an error
          would occur and MTMAIL would exit.

     DEFARC

            This specifies the default archive name to use if a node is not
          found in ARCNODES.  You could use this in place of ARCNODES if
          your network only supports one type of archive. You still need to
          specify an ARCCOMMAND.

          Example: DEFARC ZIP

     RETAIN

            This specifies the number of days to keep duplicate information
          for a message.  This can optionally can contain an area tag which
          would specify the retention period for that area.  The default is
          30 days if this option is not used.




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 8

          Examples: RETAIN 20
                    RETAIN 5 BUSYECHO

     STRIPSOFTCR

            Specifying this option tells MTMAIL to not write any Soft CR's
          (ASCII 141) to Mutant's message base.  As Mutant treats these as
          printable characters and other BBS programs treat it as a Soft
          CR, you will more than likely need to specify this option.  This
          option should not effect outbound messages so that messages can
          be passed to other BBSs.  If you find that MTMAIL is stripping
          soft CR's on outbound messages, it is a bug and should be
          reported.

     NORELINK
           Normally MTMAIL will relink Mutant's reply tree after importing
          all messages.  If you expect MTMAIL to import many messages per
          run or keep many messages in Mutant's message base, you may wish
          to disable this feature, by specifying this command, as it could
          take many minutes to execute.




          --- MTMAIL v.2 Documentation by Tom Johnson ---       Page 9

                          LIST OF ECHOMAIL CONFERENCES
                          ----------------------------

          This is usually called AREAS.BBS unless otherwise specified by
     the AREALIST config option or the FA command line option.  It consists
     of a Mutant message area, an area tag and the list of nodes that you
     may receive from or send to echomail.  The first line of this file is
     ignored and may be used as comment line.  All other lines can be up to
     254 characters in length.  The general format of the line is:

          [# or P] tag [*][C or H or N]node [node...]

             If you specify 'P' before the tag, the conference is
          considered to be passed through your system and won't be imported
          into Mutant.
             Specifying the number specifies a Mutant message base (1-999)
          that messages will be imported/exported.  NOTE: specifying more
          than one tag for a Mutant area will cause inbound echomail to
          processed properly, but outbound echomail will only be sent as
          the first tag.
             If this is a space, it signifies that it is a continuation of
          the previous line.
             The tag is the name of the conference.  I limited this to 25
          characters which seemed sufficient.

          '*' specifies that any mail sent to the node should be exported
          as a .MSG in the MAIL directory.

          'C' specifies that any mail sent to the node should be sent with
          crash priority.

          'H' specifies that any mail sent to the node should be marked as
          hold for pickup.

          'N' specifies to send as normal mail overriding a PC or PH
          command line option.

          node is as defined before.  If you want to send to a point of you
          system, you DO NOT need to specify the private network address
          since MTMAIL already knows about it in the NODE option.

     Examples:

     5 TEST_ECHO 264/715.5
     6 OTHER_ZONE *33:5/6 7 8 10/100
     7 MANY_NODES 100/6 7 8 9 10 11 12 13 14 15 16 17...
      200/5 6 7 8 9 10
     P PASS_THROUGH 264/715.5 5/10




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 10

     Assuming NODE 1:264/715.32050/0, TEST_ECHO would be sent to/received
     from 32050/3. OTHER_ZONE would be exported as .MSG files in the MAIL
     directory to zone 33.  MANY_NODES is sent to 100/x and 200/x. 
     PASS_THROUGH goes to 32050/5 and 5/10 but is never imported into
     Mutant.




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 11

                              COMMAND LINE OPTIONS
                              --------------------

          You will typically run MTMAIL from a packet event in Mutant or as
     an errorlevel option in MAILER.CFG.  You can save time by specifying
     only necessary command line options needed for a particular run.  You
     can specify these options in the configuration or on the command line. 
     With options that do not have a paramter, the option is toggled each
     time it is encountered (i.e. MTMAIl EE EE is the same as MTMAIL).


     General Options

     C (Clean)
             MTMAIL will clean the duplicate information file by removing
          any information older than the retention period or undefined echo
          area.  I recommend this be performed at least once a week, or
          once a day if you are handling large amounts of echomail.

     S (Scan)
             MTMAIL will look at .MSG files in the BAD message directory
          and try to process them.  This is useful if you had not yet
          declared an area tag in AREAS.BBS.  You should use this with
          other options so that it can be processed for other nodes
          properly.

     Tfilename (Traffic)

             MTMAIL will generate an echomail traffic report for all areas
          by appending the information to the specified file. This contains
          some information you may find useful.

          Name -    Area Tag as defined in AREAS.BBS
          Active -  The number of days since first message was processed in
                    this area.
          Messages- The total number of messages processed in this area.
          Msgs/day- Messages/Active
          Dupes   - The total number of duplicate messages for the current
                    information on file.
          Signs.  - The number of messages that MTMAIL currently has
                    information for.

     QSx (Screen level)
             This specifies what information is displayed to the screen. 
          These numbers correspond to loglevels as defined above.

     File Commands

     FAfilename




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 12

             Defines the Echomail conference listing filename if you do not
          wish to use AREAS.BBS.

     FCfilename
             Defines the configuration filename instead of MTMAIL.CFG.

     FLfilename
             If defined, MTMAIL will append to this file a list of ECHO
          areas in which MTMAIL sent outgoing echomail.

     Packet Commands

     PU (Packet Unarc)
             This tells MTMAIL to look for *.MO?, *.TU?, *.WE?, *.TH?,
          *.FR?, *.SA?, *.SU? files in the inbound directory and try to
          unarchive them.

     PI (Packet Import)
             This tells MTMAIL to look for any packets in the inbound or
          unarc directory and process them.

     PF (Packet Forward)
             If the packet header is not addressed to this node, MTMAIL
          will toss the entire packet as a normal temporary packet for
          later processing.  This overrides the Packet security option
          defined below.

     PS (Packet security)
              If the packet header is not addressed to this node or if
          you've defined a password for the origin node and the password
          does not match, MTMAIL will rename this packet to BADPKT.*.

     PA (Packet archive)
             Tells MTMAIL to archive any packets created during this
          session.

     PC (Packet Crash)
             Tells MTMAIL to mark any outbound packets with crash priority.

     PH (Packet Hold)
             Tells MTMAIL to mark any outbound packets as hold for pick-up
          by the destination node.

     EI (Echomail Import)
             If specified, Mtmail will import any inbound echomail.  If the
          message does not contain a valid tags the message will be tossed
          into the bad messages directory.  If you do not specify this
          option all inbound echomail with valid tags will be tossed to the
          mail directory.




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 13

     ES (Echomail Security)
             This causes MTMAIL to check the origin of the echomail message
          against the AREAS.BBS nodes.  If the origin is not toseed, the
          message is tossed into the bad messages directory.

     EF (Echomail Forward)
             If specified, any echomail not generated on this BBS will be
          sent to other nodes listing in AREAS.BBS.  If you are the end of
          a mail chain, you can save processing time by not specifying this
          option.

     EE (Echomail Export)
             Mtmail will search all Mutant message bases defined in
          AREAS.BBS and export any non-exported messages.

     EP (Echomail packet)
             If specified, any outbound echomail will be put into packets. 
          If not specified, any outbound echomail will be tossed into the
          mail directory.

     NI (Netmail import)
             Tells MTMAIL to import netmail to this BBS into your netmail
          message base.  If this is not specified, the mail is tossed into
          the mail directory.

     NF (Netmail Forward)
             If specified, any netmail found in packets not addressed to
          this BBS will be sent out to the destination node.  If not
          specified, the mail is tossed into the bad messages directory. 
          If files are attached to the message, MTMAIL marks them as hold
          for pickup and sends the message with a line saying the files are
          being held at this node.

     NS (Netmail security)
             If specified, MTMAIL will not scan the mail directory for
          messages.  If not specified, MTMAIL will search the mail
          directory for mail addressed to this BBS and import them if
          requested.

     NE (Netmail export)
             Instructs MTMAIL to search your Netmail base for any outgoing
          messages.  The messages are extracted and processed.

     NP (Netmail packet)
             If specified, MTMAIL will place netmail in packets addressed
          to the destination node.  If not specified, all netmail is tossed
          to the mail directory.  NOTE: you can not route any netmail that
          is packeted.  Also, non-OMMM systems usually do not have netmail
          packeted.




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 14




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 15


                               Execution Examples
                               ------------------

     Below are some common for running MTMAIL which should work for most
     systems:

     Import

     MTMAIL PI PU PA EI EP EF NI NF
          This command will process any packets, unpack packets, archive
     any packets created during the run, import echomail, packet any
     outgoing echomail, send echomail to other nodes, import incoming
     netmail and forward any netmail not to this node.

     Export

     MTMAIL EE EP PA NS NE

          This will search Mutant's message base for new echomail messages,
     packet the outgoing echomail and netmail, archive the packets, and not
     scan the mail directory for incoming messages.  This is a great line
     to be used as a Echo/Net Posted event in Mutant.




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 16


                                  Netmail Notes
                                  -------------

          I am still not sure how to handle file attaches and other FIDO
     attributes, so I will describe MTMAIL's support for it.

          1. Any incoming netmail message with bits Mutant does not support
             (HoldForPickup,FileRequest,ReturnReceiptRequest, etc.) are not
             imported into Mutant's message base regardless of the NI
             option.
          2. An incoming message with files attached is imported providing
             the file(s) attached are found and are not packets or arcmail
             bundles.  If the file attaches are valid, MTMAIL moves them
             into a directory associated with the message (Attach
             directory).  If the attaches are not valid and the message
             does not contain any lines, the message is ignored.
          3. If files are attached in an outgoing message and the netmail
             is to be packeted and you are running Ommm, MTMAIL will
             generate the *.?LO file and send the message.  Otherwise the
             message is tossed into the mail directory.
          4. When sending arcmail/packets and not running an OMMM system, a
             file attach message for the arcmail/packet is created in the
             mail directory.  This message is not put into a packet
             regardless of the NP option.  If running OMMM, MTMAIL
             generates the *.?LO file for arcmail or renames the packet to
             .?UT.

                          Duplicate Message information
                          -----------------------------

          MTMAIL creates a file called MTMAIL.DUP which contains
     information about any echomail processed by the system.  As you
     probably don't need the format of it, I prefer to list it anyway.  The
     file consists of records about 20 bytes in length.

          offset    length    Description
             0         4      Flag=1, 32-bit CRC of the following:
                              1.   The origin line without the first 11
                                   characters that define the origin line.
                              2.   The first two words of the From field.
                              3.   The first two words of the To field.
                              4.   The first 25 characters of the subject
                                   ignoring the first "RE: " if found.
                              Flag=0, the total messages ever processed in
                              this area.

             4         4      Flag=1, the number of times this message has
                              been duplicated. Flag=0, not used.




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 17

             8         4      32-bit CRC of the area tag.
            12         4      Flag=1, the time in Unix/C format of the
                              message. Flag=0, the time of the first
                              message processed in this area.
            16         2      Tag Length.  I figure with a 32-bit and the
                              tag the tag length, the odds of a duplicate
                              tag are small which allows using 6 bytes
                              instead of 26 bytes to store the tag.
            18         2      Flag, 0-area information, 1-a message
                              signature.

                                   Final Notes
                                   -----------

     1)   I wrote this on the basis of what I knew from running Echomail in
          a point system and as of this writing have not tested this in
          real life.

     2)   To test this, I had a small RemoteAccess BBS set-up and used
          ZmailH by PROZ software to process RA's echomail. By switching
          the inbound/outbound directories, MTMAIL could then process the
          mail.  My apologies to PROZ software for the similarity between
          our two products.  I liked the way ZmailH worked and decided to
          use its options.

     3)   MTMAIL does not do any extensive checking of free memory, free
          disk space so make sure you have plenty of both before you run
          MTMAIL to process mail.

     4)   I had an old copy of an echomail listing with information about
          each area and which nodes saw the area.  I took this and made
          tags and nodes from the seen-bys. This contained about 300 areas
          and on average 15 nodes per area, some less, some much
          more(especially TELIX and ZMODEM).  After loading the entire
          AREAS.BBS, MTMAIl had about 220k free.  Therefore, providing you
          are not a major hub for echomail, you should have no memory
          constraints.

     5)   If you're available RAM falls below 64k when MTMAIL starts
          processing an Echo-Mail message, MTMAIL will free-up the area
          listing and reload it after processing is done (very slow).

     6)   On my computer, a 386SX-16, it took MTMAIL about one minute and
          thirty seconds to send one message to 360 nodes.

     7)   You can distribute MTMAIL as long as there is no charge for
          distribution.

     8)   I will provide MTMAIL source code if you send me about five




          --- MTMAIL v.2 Documentation by Tom Johnson ---      Page 18

          dollars to cover a diskette and shipping.

     9)   If MTMAIL does not work for you, hopefully, someone will write
          something better who knows more about Fidonet.
