home *** CD-ROM | disk | FTP | other *** search
/ Share Gallery 1 / share_gal_1.zip / share_gal_1 / CO / CO003A.ZIP / NETMAIL.ARC / NETMAIL.DOC < prev    next >
Text File  |  1988-04-26  |  66KB  |  1,713 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.                                 GT POWER - 14.00
  14.                  Copyright (c) 1987, 1988: by P & M Software Co.
  15.                             All rights are reserved.
  16.  
  17.  
  18.  
  19.  
  20.                                GT Netmail System
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                              Release 1.00:  9-27-87
  27.                                      1.10: 11-07-87
  28.                                      1.20: 12-14-87
  29.                                      1.30:  1-09-88
  30.                                      1.40:  5-01-88
  31.  
  32.  
  33.                              P & M Software Company
  34.                              9350 Country Creek #30
  35.                              Houston, Texas   77036
  36.                              U.S.A
  37.  
  38.                              Voice Phone: (713) 778-9471
  39.                              Modem Phone: (713) 772-2090
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.                                         1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.                                 Table of Contents
  72.                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  73.  
  74.      An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  75.      Netmail vs. Echomail  . . . . . . . . . . . . . . . . . . . . . . .   3
  76.      The Programs  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  77.           MBAGGER  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  78.           MDIST  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  79.           MDRIVER  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  80.                FILE ATTACH,  FILE REQUEST, & DIRECT XPRESS . . . . . . .  10
  81.                NODELIST.BBS  . . . . . . . . . . . . . . . . . . . . . .  11
  82.                Control Files . . . . . . . . . . . . . . . . . . . . . .  11
  83.                Message Areas . . . . . . . . . . . . . . . . . . . . . .  11
  84.                The Schedule  . . . . . . . . . . . . . . . . . . . . . .  12
  85.                Command Line Usage  . . . . . . . . . . . . . . . . . . .  13
  86.                Stale mail  . . . . . . . . . . . . . . . . . . . . . . .  13
  87.                Additional MDRIVER options  . . . . . . . . . . . . . . .  14
  88.  
  89.      ROUTING.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
  90.           PURSUIT  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
  91.           INBOUND NODES  . . . . . . . . . . . . . . . . . . . . . . . .  16
  92.           LONG DISTANCE  . . . . . . . . . . . . . . . . . . . . . . . .  16
  93.           OUTBOUND NODES . . . . . . . . . . . . . . . . . . . . . . . .  17
  94.           PREFIXES . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
  95.           PICKUP OVERRIDES . . . . . . . . . . . . . . . . . . . . . . .  18
  96.           ROUTING INSTRUCTIONS . . . . . . . . . . . . . . . . . . . . .  19
  97.           REQUEST ECHOMAIL CONFERENCES . . . . . . . . . . . . . . . . .  21
  98.           MESSAGE DISTRIBUTION . . . . . . . . . . . . . . . . . . . . .  22
  99.           ECHOMAIL HOURS . . . . . . . . . . . . . . . . . . . . . . . .  22
  100.           EXCLUDED NODES . . . . . . . . . . . . . . . . . . . . . . . .  23
  101.  
  102.      HINTS FOR ECHOMAIL  . . . . . . . . . . . . . . . . . . . . . . . .  23
  103.           Sample Echomail ROUTING.BBS  . . . . . . . . . . . . . . . . .  23
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.                                         2
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.      An Overview
  138.      ~~~~~~~~~~~
  139.      The GT  Netmail System  is a companion product for GT POWER.  It allows
  140.      GT host mode systems to send messages from one to  another over dial-up
  141.      phone lines,  unattended, in  the middle  of the night.  Alternate long
  142.      distance carriers, such as PC Pursuit, are supported  and used whenever
  143.      possible to control cost.
  144.  
  145.      A  system  of  "hub"  systems  has  begun to grow.  These "hub" systems
  146.      collect and concentrate message traffic, enabling fewer phone  calls to
  147.      be made  and a greater amount of message traffic to be passed with each
  148.      call.  Central hubs, known as "Continental Hubs", have been established
  149.      to facilitate  the flow of message traffic to/from parts of the country
  150.      not reachable via PC Pursuit.  The "Continental Hubs" act  as store and
  151.      forward sites for their designated sections of the country.
  152.  
  153.      The GT  Netmail Coordinator  must be contacted to gain access to the GT
  154.      Netmail System.  One must apply through the GT Netmail  Coordinator (or
  155.      his designated  representative) for  a net/node  number and related CRC
  156.      Identification  Number.    The  CRC  Identification  Number  allows the
  157.      netmail  system  to  tell  the  good  guys  from the bad guys.  The CRC
  158.      Identification Number will not only verify you to the other  members of
  159.      the  network,  but  will  allow separate non-overlapping networks to be
  160.      established, each with their own different  CRC Identification Numbers,
  161.      so we  will be  able to tell the difference between net/node 001/010 in
  162.      network  A   and  net/node   001/010  in   network  B.     Without  the
  163.      identification  number,  it  would  be easy to outsiders to impersonate
  164.      other members of the network.  When you receive your CRC Identification
  165.      Number, it is to be held in the strictest confidence.
  166.  
  167.      +---------------------------------------------------------------------+
  168.      |                                                                     |
  169.      |    To learn the name of the GT Netmail Coordinator (or his          |
  170.      |    designated representative, call P & M Software Co. via voice     |
  171.      |    line at (713) 778-9471.                                          |
  172.      |                                                                     |
  173.      +---------------------------------------------------------------------+
  174.  
  175.  
  176.      Netmail vs. Echomail
  177.      ~~~~~~~~~~~~~~~~~~~~
  178.      Echomail conferences are designated differently than Netmail nodes are,
  179.      but the mechanism is very similar.  Netmail nodes are assigned net/node
  180.      numbers by  the GT  Netmail Coordinator, 001/002 is the net/node number
  181.      for Private  Sector, a  BBS in  Houston.   On the  other hand, Echomail
  182.      conference numbers  are assigned by the Echomail Coordinator and always
  183.      begin with  the letter  "E" to  distinguish them  from Netmail net/node
  184.      numbers.   For example, 001/002 is the sponsoring system for the  Sysop
  185.      Tools Echomail Conference, which is designated E00/033.   If one wished
  186.      to get the Sysop Tools Echomail Conference from 001/002, then a routing
  187.      instruction would have to be coded to tell the system  where to  get it
  188.      (explained below).
  189.  
  190.      Netmail  is  a  mechanism  which  allows  communications to be directly
  191.      addressed to a particular destination system  and person,  which may be
  192.  
  193.                                         3
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.      on the other side of the world.  As such, Netmail is inherently one-to-
  204.      one.  Echomail, on  the other  hand, is  one-to-many.   You may address
  205.      message  to  any  person,  or  to  all  persons,  but  any system which
  206.      "subscribes" to  an  Echomail  conference  will  be  able  to  get your
  207.      message.    In  effect,  Echomail allows the duplication of conferences
  208.      across many systems and is called Echomail, because  of the  action the
  209.      mail takes  upon reaching the "sponsor" system -- it echoes back to all
  210.      the  subscriber  systems!     The  terms   "sponsor",  "subscribe"  and
  211.      "subscriber" are  not used  to indicate monetary exchange.  Echomail is
  212.      provided on request (no money is  involved), the  terms merely describe
  213.      who is  the service  provider and  who is  the service  requestor.  The
  214.      service involved is the storage and distribution of  a Echomail message
  215.      database.
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.                                         4
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.      The Programs
  270.      ~~~~~~~~~~~~
  271.      The GT  Netmail System  is comprised  of three programs (four actually,
  272.      but the fourth is the CRC calculator and it is for network coordinators
  273.      only):
  274.  
  275.                MBAGGER ....... Mail Bagger Program
  276.                MDRIVER ....... Mail Driver Program
  277.                MDIST ......... Mail Distributor Program
  278.  
  279.      MBAGGER
  280.      ~~~~~~~
  281.      The MBAGGER  program is responsible for taking message traffic from the
  282.      GT host system and  preparing  it  for  transmission  over  the netmail
  283.      system.   The process  is called  "bagging".   For each destination you
  284.      have message traffic the  MBAGGER program  will create  a mail  bag.  A
  285.      mail bag  in this  sense is  an ARC file that contains all the messages
  286.      for a particular destination.  Mail bags have a rather interesting file
  287.      naming convention:
  288.  
  289.                 Netmail Bag Naming Convention.
  290.                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  291.                 Position           Description
  292.                 ~~~~~~~~           ~~~~~~~~~~~
  293.                     1              File Id: "B".
  294.                     2              File generation number: 0 - current.
  295.                                                            1 - 1 cycle old.
  296.                                                            2 - 2 cycles old.
  297.                     3-5            Bag number.  Usually "001".
  298.                     6-8            Destination node number.
  299.                     9              "."
  300.                     10-12          Destination net number.
  301.  
  302.  
  303.                 Echomail Bag Naming Convention.
  304.                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  305.                 Position           Description
  306.                 ~~~~~~~~           ~~~~~~~~~~~
  307.                     1              File Id: "E".
  308.                     2-5            Julian  date  of  bag creation. 1-1-87 is
  309.                                    day 0.
  310.                     6-8            Echomail conference number.
  311.                     9              "."
  312.                     10-12          Echomail net number.
  313.  
  314.      NOTE: even though the mail bags do not have the ARC extension, they ARE
  315.      ARC files and you will need a copy of PKARC/PKXARC on your system to be
  316.      able to process mail bags.
  317.  
  318.      The operation of MBAGGER  is semi-automatic.   It  goes through  the GT
  319.      host system  message bases  finding messages that need to be bagged and
  320.      does its thing.  Once a message has been bagged, MBAGGER will  mark the
  321.      message as  (MAILED).  This does not mean that the message has actually
  322.      been sent  or received,  but that  it has  entered into  the GT Netmail
  323.      System.    The  MBAGGER  uses  this  mark to keep from bagging the same
  324.  
  325.                                         5
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.      message over and over again.
  336.  
  337.      The MBAGGER program must be run  at or  before the  start of  a netmail
  338.      session,  to  insure  that  all  outgoing  message  traffic is properly
  339.      prepared for transmission.
  340.  
  341.      The MBAGGER program examines the  ROUTING.BBS  file  or  the designated
  342.      alternate routing  file (designated  via command  line switch) and uses
  343.      several bits  of information  located there  to control  the bagging of
  344.      Echomail.   First, the  necessary ACCEPTs  for Echomail must be present
  345.      and if  your  system  is  to  act  as  the  "sponsor"  for  an Echomail
  346.      conference,  the   ACCEPT  for   your  conference  must  NOT  have  any
  347.      redirection shown.  The system identifies  you as  the "sponsor"  of an
  348.      Echomail conference by the lack of redirection for your conference.
  349.  
  350.      In addition,  the MBAGGER program will examine the MESSAGE DISTRIBUTION
  351.      section of the ROUTING.BBS file.  The MESSAGE DISTRIBUTION section must
  352.      contain entries  for each  Echomail conference  that is present on your
  353.      system,  so MBAGGER will know where to look to get Echomail to bag.
  354.  
  355.      If  the  ACCEPT  statements  or  MESSAGE  DISTRIBUTION  section  of the
  356.      ROUTING.BBS file are incorrect, then MBAGGER cannot successfully do its
  357.      job.
  358.  
  359.      Here are some sample ACCEPT statements:
  360.  
  361.                          ACCEPT E00/033-033 -> 001/002
  362.  
  363.      This statement would indicate to MBAGGER that you were routing Echomail
  364.      for E00/033  (Sysop Tools)  through node  001/002 (Private Sector).  If
  365.      you were  the "sponsor"  of an  Echomail conference,  say E00/020, then
  366.      your  ROUTING.BBS  file  would  contain  the  following ACCEPT for your
  367.      conference:
  368.  
  369.                          ACCEPT E00/020  $xxxx
  370.  
  371.      This shows your system  to  be  the  "sponsor"  of  Echomail conference
  372.      E00/020.   And the  $xxxx is  the Echomail  CRC number  assigned by the
  373.      Echomail Coordinator.
  374.  
  375.      The MBAGGER  program  uses  the  MESSAGE  DISTRIBUTION  section  of the
  376.      ROUTING.BBS file  to find the message areas which contain Echomail.  So
  377.      each Echomail  conference  must  have  a  valid  entry  in  the MESSAGE
  378.      DISTRIBUTION section.  As follows:
  379.  
  380.                          MESSAGE DISTRIBUTION
  381.                             E00/004-004 -> C:\FOOBAR1
  382.                             E00/009-009 -> C:\FOOBAR2
  383.                          END
  384.  
  385.      The idea  here is  to relate  each Echomail conference that you want to
  386.      have on your system listed with a corresponding message area in your GT
  387.      Host system.   The  names FOOBAR1 and FOOBAR2 you will replace with the
  388.      actual directory names you use on  your system.   The  Echomail message
  389.      areas in  the GT Host system are setup as normal message areas, without
  390.  
  391.                                         6
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.      any private mail (use the ^ in the GTMDIR.BBS file).
  402.  
  403.      The MBAGGER program supports several command line options, as follows:
  404.  
  405.           /N ...... This option enables MBAGGER to be run more than once per
  406.                     day.   On the  first run  of MBAGGER, this option is not
  407.                     used, but all subsequent runs on  that day  MUST use the
  408.                     /N command line switch.  /N stands for NEXT RUN.
  409.  
  410.           /Dn ..... This  option  specifies  the  number of days you wish to
  411.                     retain  old  bags  of  Echomail.    These  bags  must be
  412.                     retained  for  awhile  so  that  they  are available for
  413.                     newcomers and for people who miss  a day  or two  of the
  414.                     conference.  The system defaults to 14 days, I would not
  415.                     advise a shorter period, but this mechanism can  be used
  416.                     to  lengthen  the  period.    I use /D31 on my system at
  417.                     001/003, but I have  no  crunch  on  disk  space  at the
  418.                     moment.
  419.  
  420.           /R ...... This option  is used  to specify  an alternative routing
  421.                     file.  If not  specified, the  program will  process the
  422.                     standard ROUTING.BBS,  but with this option, any routing
  423.                     file may be named for input.  For example:
  424.  
  425.                          /R:foo.bar
  426.  
  427.                     In this case, the  routing  instructions  would  be read
  428.                     from the file 'foo.bar'.
  429.  
  430.  
  431.      MDIST
  432.      ~~~~~
  433.      The MDIST  program runs  at the conclusion of a netmail session, taking
  434.      the message traffic received from other  systems and  distributes it to
  435.      the GT  host message base.  This process involves unARCing all the mail
  436.      bags received and taking the resulting messages and  entering them into
  437.      the GT  host message  base system,  thus allowing the BBS users to read
  438.      and respond to the messages.
  439.  
  440.      The operation of this program is semi-automatic.  The program  uses the
  441.      ROUTING.BBS  file,  or  designated  alternate, to determine the MESSAGE
  442.      DISTRIBUTION and the ROUTING  INSTRUCTIONS to  determine which Echomail
  443.      conferences you  might be  sponsoring.  The requirement for the ROUTING
  444.      INSTRUCTIONS is very important  to  MDIST,  since  to  perform properly
  445.      MDIST   must   be   able   to   distinguish  Echomail  "sponsors"  from
  446.      "subscribers".  This is done by  examining the  ACCEPT statments.   For
  447.      example  a   Echomail  "sponsor"  will  show  no  redirection  for  his
  448.      conference:
  449.  
  450.                          ACCEPT E00/001  $xxxx
  451.  
  452.      This would identify your  system  as  the  "sponsor"  for  the Echomail
  453.      conference E00/001  (which of course is sponsored by 001/003, so do not
  454.      do this unless you are an Echomail  "sponsor").      The  $xxxx  is the
  455.      Echomail CRC number assigned by the Echomail Coordinator.
  456.  
  457.                                         7
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.      A Echomail  "subscriber" would  also code an ACCEPT statement, it would
  469.      list the node from which he  obtains the  conference.   For example, if
  470.      you  subscribed  to  E00/003-003,  you would code the following ROUTING
  471.      INSTRUCTION:
  472.  
  473.                          ACCEPT E00/003-003 -> 001/003
  474.  
  475.      Of course, the 001/003 is variable and will be replaced with the actual
  476.      source  of  the  conference  for  you.    You  may  receive an Echomail
  477.      conference from the  sponsor  of  the  conference  or  from  anyone who
  478.      already subscribes to the conference.
  479.  
  480.      Of course,  the MESSAGE  DISTRIBUTION section is extremely important to
  481.      the MDIST program.  It informs MDIST where  to place  messages you have
  482.      received.  Here is the format:
  483.  
  484.                          MESSAGE DISTRIBUTION
  485.                             E00/001-001 -> C:\GT_ECHO
  486.                             E00/002-002 -> C:\RELIGION
  487.                          END
  488.  
  489.      This example  only shows  two lines,  but the  pattern should be clear.
  490.      You must  indicate  which  Echomail  conferences  get  routed  to which
  491.      message bases  on your  system.   NOTE: the Echomail message bases must
  492.      NOT be netmail areas, they are setup as regular message bases.  You may
  493.      also  route  regular  netmail  message  traffic  from specific net/node
  494.      addresses via  this mechanism.   If  regular netmail  traffic is routed
  495.      this way,  then of  course the message areas involved would be setup as
  496.      normal netmail areas.
  497.  
  498.      The MDIST program supports 1  command  line  argument,  the  /R switch.
  499.      This allows  the user  to specify  the use of an alternate routing file
  500.      instead of the standard ROUTING.BBS file.  For example:
  501.  
  502.                          MDIST  /r:hay.stk
  503.  
  504.      In this example, MDIST would  read  the  required  routing instructions
  505.      from the file 'hay.stk', instead of the ROUTING.BBS file.
  506.  
  507.  
  508.      MDRIVER
  509.      ~~~~~~~
  510.      The MDRIVER program is the heart and soul of the GT Netmail System.  It
  511.      receives and transmits mail bags.   It routes  the message  traffic, as
  512.      instructed by  the user, through the various "hub" systems to the final
  513.      destination.  The operation of this program can  be rather  complex, if
  514.      user lets it be.  Remember when setting up this program: "KISS: Keep It
  515.      Simple Stupid".
  516.  
  517.      The system automatically creates a  system  of  sub-directories  on the
  518.      default drive, as follows:
  519.  
  520.           \MAILWORK ........... Usually empty.  Temporary work area.
  521.           \MAILOUT ............ Outgoing mail bags.
  522.  
  523.                                         8
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.           \MAILOUT\FILEOUT .... Outgoing files for use with "File Attach"
  534.                                 and "File Request".
  535.           \MAILOUT\DEADLTR .... Stale mail.  Put here when can't deliver.
  536.           \MAILIN ............. Incoming mail bags.
  537.           \MAILIN\FILEIN ...... Incoming files sent via "File Attach" or
  538.                                 as a result of a "File Request".
  539.  
  540.      When  you  create  a  netmail  message, it can include a "File Attach",
  541.      "File Request" or "Direct Xpress" command within it.  The "File Attach"
  542.      command will  cause the  indicated file to be "bagged" with the message
  543.      and delivered with the message to the indicated destination.  The "File
  544.      Request" command will cause a request for the indicated file to be sent
  545.      with the message to the destination system.   If the  requested file is
  546.      available, it  will be  returned to  the reqesting system.  The "Direct
  547.      Xpress" command will cause the message  to be  routed direct  from your
  548.      system  to  the  addressee's  system,  avoiding  all  intermediate  hub
  549.      systems.
  550.  
  551.      +--------------------------------------------------------------------+
  552.      |                                                                    |
  553.      |        Please note that the FILE REQUEST and FILE ATTACH           |
  554.      |        mechanism should be used with extreme care.  Abuse          |
  555.      |        of these functions will cause degradation of the net-       |
  556.      |        mail system.  Large files should not be attached or         |
  557.      |        requested unless absolutely necessary.                      |
  558.      |                                                                    |
  559.      +--------------------------------------------------------------------+
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.                                         9
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.      FILE ATTACH,  FILE REQUEST, & DIRECT XPRESS
  600.      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  601.      To be "attached" to  a  message,  the  file  must  be  placed  into the
  602.      \MAILOUT\FILEOUT sub-directory.   The  user then places a "dot command"
  603.      into the message referencing this file.  A  "dot command"  is a command
  604.      beginning in the first column of a line with a ".".
  605.  
  606.      Here is an example of a "File Attach" command:
  607.  
  608.      .FA foo.bar
  609.  
  610.      This  would  cause  the  file  "foo.bar"  to be attached to the message
  611.      containing the ".FA" command.
  612.  
  613.      To be "requested" by a message, the file requested must be available on
  614.      the destination system in the \MAILOUT\FILEOUT sub-directory.  The user
  615.      then places a "dot  command" into  the message  referencing the desired
  616.      file.
  617.  
  618.      Here is an example of a "File Request" command:
  619.  
  620.      .FR nodelist.arc
  621.  
  622.      This  would  cause  the  file  "nodelist.arc"  to be requested from the
  623.      destination system when the message  containing  the  ".FR"  command is
  624.      delivered.
  625.  
  626.      Here is an example of a "Direct Xpress" command.
  627.  
  628.      .DX
  629.  
  630.      This  would  cause  the  message  which  contains  the .DX to be routed
  631.      directly to the  addressee's  system,  without  any  store  and forward
  632.      operation.
  633.  
  634.      The  .FR,  .FA  and  .DX  commands  are  not  processed  in an Echomail
  635.      transaction.  They are only applicable to regular Netmail.
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.                                        10
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.      NODELIST.BBS
  666.      ~~~~~~~~~~~~
  667.      The NODELIST.BBS file is  maintained  by  the  GT  Netmail Coordinator.
  668.      Each system  on the netmail system must have a copy of the NODELIST.BBS
  669.      to be able to deliver message traffic over  the network.   Usually, the
  670.      GT Netmail Coordinator has the nodelist available for "File Request" as
  671.      the file NODE????.ARC.   The  format  of  the  nodelist  is  simple, an
  672.      example entry would be:
  673.  
  674.      001/001 713-772-2090 96 Houston "Programmer's Workshop" "Paul Meiners"
  675.  
  676.      The first  column of each line in the nodelist begins with the net/node
  677.      address of the indicated system, in this case net = 001 and node = 001.
  678.      That is  followed by  the phone  number, the maximum baud rate (without
  679.      trailing zeros), the city, the name of the system, and the name  of the
  680.      operator.   One need  not modify  this information, it is maintained by
  681.      the GT Netmail Coordinator.  If any information  in the  nodelist needs
  682.      to be changed, please notify the coordinator.
  683.  
  684.  
  685.      Control Files
  686.      ~~~~~~~~~~~~~
  687.      Various control  files are  built by  the GT Netmail System in the mail
  688.      directories.  These control files are  0 byte  files and  all filenames
  689.      begin with  the letter  "C" and/or "F".  Do not disturb these files, as
  690.      they are 0 byte files, they occupy very little space on your disk.
  691.  
  692.  
  693.      Message Areas
  694.      ~~~~~~~~~~~~~
  695.      At least one message area must  be  designated  to  participate  in the
  696.      netmail system.   This message base is indicated in the GTMDIR.BBS file
  697.      by placing a  ~  before the pathname.  For example:
  698.  
  699.                E  ~C:\GTBBS\GENERAL  The Netmail Message Area.
  700.  
  701.      When MBAGGER runs he will search  for outgoing  messages only  in areas
  702.      marked with  the   ~  character.  When MDIST runs, the incoming message
  703.      traffic will be entered into the  first netmail  message area  found in
  704.      the GTMDIR.BBS file or if an entry is found in the MESSAGE DISTRIBUTION
  705.      section, netmail from specified addresses can  be split  into different
  706.      message areas.
  707.  
  708.      If you  decide to  run Echomail,  you must set aside a message area for
  709.      each Echomail conference you wish to  participate in.   They  should be
  710.      normal message  areas, DO NOT designate them with the ~ as shown above.
  711.      It is recommended that Echomail areas  are totally  public areas, since
  712.      Echomail will ignore any private message left in an Echomail area.  You
  713.      may use the ^ character in  front of  the pathname  to prohibit private
  714.      messages, as follows:
  715.  
  716.                E ^C:\GTBBS\SYS_ECHO  The SYSOP Echomail Conference.
  717.  
  718.  
  719.  
  720.  
  721.                                        11
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.      The Schedule
  732.      ~~~~~~~~~~~~
  733.      The  SCHEDULE.BBS  file  has  several  important entries for the proper
  734.      operation of the netmail programs.  As follows:
  735.  
  736.           NET=xxx             Net number.  Assigned by coordinator.
  737.           NODE=xxx            Node number.  Assigned by coordinator.
  738.           AREA=xxx            Local areacode.  Assigned by phone company.
  739.           CITY=cityname       This city name.  Assigned by city council.
  740.           OFFICE=99:99-99:99  Specifies when  a  caller  can  use  the P)age
  741.                               function.  For example: OFFICE=08:00-17:00
  742.                               The time  is specified  using 24 hour notation
  743.                               and leading zeros are significant.
  744.           NAME=bbsname        This BBS name.  Assigned by sysop.  This name
  745.                               is used to identify the system on the .ORIGIN
  746.                               line by MBAGGER (be creative with it).
  747.  
  748.      These should be the first entries in the  SCHEDULE.BBS file.   The AREA
  749.      entry can  contain multiple local areacodes, if there are more than one
  750.      areacode that is local in an area.  For example:
  751.  
  752.                     AREA=212,718   or   AREA=713
  753.  
  754.      The 1st example indicates that areacode 212 and 718 are local areacodes
  755.      and that  212 is  the primary areacode.  There can be several areacodes
  756.      listed after the primary areacode.   The 2nd  example shows  a simple 1
  757.      areacode situation.
  758.  
  759.      Following the  netmail entries  in the  SCHEDULE.BBS file will come the
  760.      actual schedule entries.  Only one  entry is  required to  run netmail,
  761.      the one that starts the NETMAIL.BAT runstream.  For example:
  762.  
  763.                          04:00-05:00 netmail
  764.  
  765.      Please note  that the midnight hour is 24:00 - 24:59, the hour roles to
  766.      01:00 at 1 a.m.
  767.  
  768.      This would start the NETMAIL.BAT runstream at 4  a.m. local  time.  The
  769.      actual time  to be used is set by the coordinator.  A range of times is
  770.      indicated to start netmail, so that in case the system were to miss the
  771.      exact start  time, then  netmail would  still start  late, but it would
  772.      start.  If your system does not have enough memory  to run  netmail and
  773.      GT  in  memory  at  the  same  time, due to DDOS or other multi-tasking
  774.      software, you can "QUIT  n" from  the scheduler  and exit  GT entirely.
  775.      Then in  the runstream  controlling GT there should appear a command as
  776.      follows:
  777.  
  778.                          IF ERRORLEVEL n NETMAIL
  779.  
  780.      The QUIT command will set the requested ERRORLEVEL  upon exit  from GT.
  781.      For example if one "QUIT 4" then the statement would be:
  782.  
  783.                          IF ERRORLEVEL 4 NETMAIL
  784.  
  785.      Having quit  GT, the  NETMAIL.BAT file  must be  sure to restart the GT
  786.  
  787.                                        12
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.      host system after the  netmail session  is complete.   NOTE:  there are
  798.      sample  batch  file  runstreams  to  look  at in the ARC file that this
  799.      documentation came  from.   Please examine  HOST.BAT, AUTOEXEC.BAT, and
  800.      NETMAIL.BAT.
  801.  
  802.      Command Line Usage
  803.      ~~~~~~~~~~~~~~~~~~
  804.      There  are  several  command  line  parameters for the MDRIVER program.
  805.      They are as follows:
  806.  
  807.      The netmail CRC Identification number.
  808.      The session start time.
  809.      The session end time.
  810.      The latest start time for the session.
  811.  
  812.      These are the basic  parameters  and  must  be  specified  and  must be
  813.      specified in the order listed.  For example:
  814.  
  815.                     MDRIVER  XXXX-YYYY  4   5  0455
  816.  
  817.           The above  example would  run the  Netmail from 4 am to 5 am.  And
  818.           the latest start time would be 4:55 am.
  819.  
  820.                     MDRIVER  AAAA-BBBB  4:30   5:25  5:20
  821.  
  822.           The above example would run the Netmail from  4:30 am  to 5:25 am.
  823.           And the latest start time would be 5:20 am.
  824.  
  825.      In  the  above  examples,  the  XXXX-YYYY  and  AAAA-BBBB  are  the CRC
  826.      Identification Number pairs obtained  from the  GT Netmail Coordinator.
  827.      Without  these  numbers  the  programs  cannot  communicate  with other
  828.      programs on the network.  Call  P &  M Software  Co. via  voice line at
  829.      (713) 778-7481,  to find out who to contact to get a CRC Identification
  830.      Number pair for your node.
  831.  
  832.      In addition to the CRC Identification Number, the start/stop times, and
  833.      the latest  start time,  a 5th  parameter can  be added  to the command
  834.      line.  It is  the  number  of  days  a  message  can  age  before being
  835.      considered "stale  mail".   It goes  on the  command line following the
  836.      scheduled times.  And is in the format "/Dn", where the "n" is a number
  837.      of days.  For example:
  838.  
  839.                     MDRIVER 32ED-5E2C 0400 0500 0455 /D10
  840.  
  841.      This would  indicate that  any bag over 10 days old was to be marked as
  842.      stale.  The bag's name will be changed to begin with the  "X" character
  843.      instead of  the "B"  character, later the MDIST program will dispose of
  844.      the bag.
  845.  
  846.      The MDIST  program will  process the  "X" bags  created as  a result of
  847.      MDRIVER  finding  stale  mail  bags.    These  stale  mail bags will be
  848.      examined by MDIST to determine the system of origin.  If they originate
  849.      on  the  local  system,  they  will  be  moved  to the \MAILOUT\DEADLTR
  850.      directory and a message to the local sysop will be placed in  the first
  851.      netmail message area listed in GTMDIR.BBS, informing the local sysop of
  852.  
  853.                                        13
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.      this fact.  If MDIST determines that the  stale mail  bag originates on
  864.      another  node,  then  it  will  move  the  bag  to the \MAILOUT\FILEOUT
  865.      directory and .FA (file attach) it to a  message going   to  the remote
  866.      destination informing the remote sysop that his mail was  undeliverable
  867.      and hereby returned to him.   The MBAGGER  program will     delete "X0"
  868.      files  from  the  \MAILOUT\FILEOUT  directory,  after  they  have  been
  869.      attached.
  870.      +---------------------------------------------------------------------+
  871.      |                                                                     |
  872.      |     WARNING: this could be dangerous to the heath of your files.    |
  873.      |     DO NOT PUT ANY FILE BEGINNING WITH THE LETTERS X0 INTO THE      |
  874.      |     FILEOUT DIRECTORY.                                              |
  875.      |                                                                     |
  876.      +---------------------------------------------------------------------+
  877.  
  878.  
  879.      Additional MDRIVER options
  880.      ~~~~~~~~~~~~~~~~~~~~~~~~~~
  881.  
  882.           /R        Allows for the use  of alternate  routing files, instead
  883.                     of the standard ROUTING.BBS file.
  884.  
  885.                          /R:some.rte
  886.  
  887.                     The MDRIVER  will get routing instructions from the file
  888.                     'some.rte', instead of ROUTING.BBS.
  889.  
  890.           /H        Allows for the specification of a custom "Human Notice".
  891.                     Instead  of  the  default  notice, you can customize the
  892.                     notice you system uses  to notify  human callers  of the
  893.                     netmail processing in progress.  For example:
  894.  
  895.                          /H:foo.bar
  896.  
  897.                     The file 'foo.bar' will be displayed to human callers.
  898.  
  899.           /Q        Instructs  the  MDRIVER  program  to quit as soon as all
  900.                     outbound calls have been completed.
  901.  
  902.           /E        Allows the user to specify the maximum number  of errors
  903.                     to allow  during a  netmail transfer before aborting the
  904.                     session.  Very useful to keep from wasting time on a bad
  905.                     connection.   Values below  3 are  not recommended.  For
  906.                     example:
  907.  
  908.                          /E3
  909.  
  910.                     This would allow 3  errors to  occur before  the session
  911.                     would terminate.
  912.  
  913.  
  914.      ROUTING.BBS
  915.      ~~~~~~~~~~~
  916.      The  ROUTING.BBS  file  is  the  heart  of the control files for the GT
  917.      Netmail System.  It contains the instructions necessary for the MDRIVER
  918.  
  919.                                        14
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.      program to deliver the mail.
  930.  
  931.      There are 11 sections in the ROUTING.BBS file, as follows:
  932.  
  933.           PURSUIT
  934.                PC Pursuit instructions.
  935.           INBOUND NODES
  936.                Node list not to be called.
  937.           LONG DISTANCE
  938.                Node list defined to be Long Distance.
  939.           OUTBOUND NODES
  940.                Node list to be called.
  941.           PREFIXES
  942.                Phone No. prefixes to used with MDRIVER.
  943.           ROUTING INSTRUCTIONS
  944.                Forwarding instructions.
  945.           PICKUP OVERRIDES
  946.                Tell MDRIVER to pickup Long Distance mail.
  947.           REQUEST ECHO CONFERENCES
  948.                Tell MDRIVER to pickup Echomail conferences.
  949.           MESSAGE DISTRIBUTION
  950.                Tell all programs where messages are to be stored/retrieved.
  951.           ECHOMAIL HOURS
  952.                Tell MDRIVER what the hours are for making Echomail requests.
  953.           EXCLUDED NODES
  954.                Tell MDRIVER to deny access to listed nodes.
  955.  
  956.      None of  these sections is required.  That is, all of these things have
  957.      defaults.   They  need  be  specified  only  if  the  defaults  must be
  958.      overriden.    For  example, the default is not to use PC Pursuit, if PC
  959.      Pursuit should be used,  then include the PURSUIT section.  Here  is an
  960.      explanation of each section:
  961.  
  962.  
  963.      PURSUIT
  964.      ~~~~~~~
  965.      The PURSUIT  section of  the ROUTING.BBS  file has a rigid format.  One
  966.      simply fills in the blanks.  Here is the outline to follow:
  967.  
  968.           PURSUIT
  969.                ACCESS=             The local Telenet access number.
  970.                USERID=             Your PC Pursuit user id code.
  971.                PASSWORD=           Your PC Pursuit password.
  972.                CITIES              The PC Pursuit cities, listed 1 per line.
  973.                     201,NJNEW-Newark
  974.                     216,OHCLV-Cleveland
  975.                     202,DCWAS-Washington     In order  to  be  effective the
  976.                     305,FLMIA-Miami          names must be spelled as in the
  977.                     206,WASEA-Seattle        nodelist.  The codes following
  978.                       .                      the areacode must be as needed
  979.                       .                      by PC Pursuit, i.e. the case
  980.                       .                      *IS* significant!
  981.           END
  982.  
  983.      There  are  thirty-three  odd  PC  Pursuit  cities,  they should all be
  984.  
  985.                                        15
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.      included in this table.  See the sample ROUTING.BBS file for a complete
  996.      list.
  997.  
  998.  
  999.      INBOUND NODES
  1000.      ~~~~~~~~~~~~~
  1001.      The INBOUND  NODES listing  is included in the ROUTING.BBS file so that
  1002.      one can prevent MDRIVER from placing calls to  particular destinations.
  1003.      Usually  this  is  a  cost  control  measure.    If  one has mail for a
  1004.      destination listed in this section, then that system must call  to pick
  1005.      up the mail addressed to it.  The format of the section is:
  1006.  
  1007.                               INBOUND NODES
  1008.                                    001/000-999
  1009.                                    002/010-020
  1010.                               END
  1011.  
  1012.      This example  would inbound  all of  net 001.  The range of nodes after
  1013.      the net number being 000 through 999.    The  line  for  net  002 would
  1014.      inbound nodes  010 through  020 in  that net.   A range of nodes can be
  1015.      listed on each line, but only 1 net can be listed per line.   Up to 200
  1016.      lines can be present in the INBOUND NODES list.  Please note that it is
  1017.      only necessary  to INBOUND  nodes that  you physically  place calls to.
  1018.      For example,  if you  are routing  mail for several destinations thru a
  1019.      hub system and you wish to INBOUND all of this traffic, you  would need
  1020.      to INBOUND  only the hub system, not the individual destinations, since
  1021.      you never call them anyway (so why INBOUND them??).
  1022.  
  1023.  
  1024.      LONG DISTANCE
  1025.      ~~~~~~~~~~~~~
  1026.      The LONG DISTANCE area of the ROUTING.BBS file is used  to override the
  1027.      default rules that the MDRIVER program uses to determine if a number is
  1028.      a local call or long distance.  The cost of  a message  is based  in GT
  1029.      upon the  net number,  i.e. if  the destination  net is  the same a the
  1030.      local net then the call is considered to be free,  if the  local net is
  1031.      different from  the destination net, the call is considered chargeable.
  1032.      The LONG DISTANCE section only controls  the construction  of the modem
  1033.      dialing string,  not the the charge made for the message.  Normally any
  1034.      number which has an areacode matching a local  areacode from  the AREA=
  1035.      list in  the SCHEDULE.BBS file is dialed as a local number.  Any number
  1036.      which has a different  areacode is  dialed as  a long  distance number.
  1037.      Now,  it  is  entirely  possible,  that these rules are not adequate to
  1038.      govern all circumstances.    For  example,  some  long  distance calls,
  1039.      within a  given areacode,  are dialed  as 1 + the 7 digit phone number.
  1040.      To allow MDRIVER to construct a dialing string with 1  + 7  digit phone
  1041.      number, the user must list this node in the LONG DISTANCE section.  The
  1042.      syntax for this section is the  same as  the INBOUND  NODES list above.
  1043.      For example:
  1044.  
  1045.                               LONG DISTANCE
  1046.                                    001/002-005
  1047.                                    002/020-022
  1048.                               END
  1049.  
  1050.  
  1051.                                        16
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.      Up to 100 entries can be placed into the LONG DISTANCE section, each of
  1062.      which can be a range of nodes within 1 net area.
  1063.  
  1064.           Sample dialing strings:
  1065.                ATDT772-2090|            Local call.
  1066.                ATDT1,713-772-2090|      Regular long distance call.
  1067.                ATDT1,772-2090|          LONG DISTANCE: 1 + 7 digit number.
  1068.  
  1069.  
  1070.      OUTBOUND NODES
  1071.      ~~~~~~~~~~~~~~
  1072.      The OUTBOUND NODES list of the ROUTING.BBS file is a list of nodes that
  1073.      the user  wishes MDRIVER  to call  to pickup  mail, even if there is no
  1074.      mail waiting to be sent to  these nodes.   It  is a  very handy  way to
  1075.      force MDRIVER  to call  central hub locations to pickup your mail.  The
  1076.      syntax is the same as for LONG DISTANCE above, except that a  range may
  1077.      not be specified.  For example:
  1078.  
  1079.                               OUTBOUND NODES
  1080.                                    001/000
  1081.                                    005/000 [2,5]
  1082.                                    006/000
  1083.                               END
  1084.  
  1085.      This list  would cause  MDRIVER to  call each  fo the  listed nodes and
  1086.      pickup any mail awaiting delivery to  your node.   On  the 3rd example,
  1087.      where 005/000 is listed, you will notice the "[2,5]" listed on the line
  1088.      after the node number.   This  is a  day schedule  for the  OUTBOUND to
  1089.      become active.  The numbers are days of the week, for example 1=Sunday,
  1090.      2=Monday, etc.  This command indicates that the OUTBOUND for 005/000 is
  1091.      done on Monday and Thursday only.  If a OUTBOUND is scheduled for a day
  1092.      of the week, it may be INBOUNDed -- that is, the schedule will override
  1093.      the INBOUND.  This will allow you to accumulate mail for a destination,
  1094.      then force the call to be made on a specific day of the week.   Here is
  1095.      an example:
  1096.  
  1097.                               OUTBOUND NODES
  1098.                                    001/000 [1]
  1099.                                    005/000 [3]
  1100.                                    006/000 [2]
  1101.                               END
  1102.                               INBOUND NODES
  1103.                                    001/000
  1104.                                    005/000
  1105.                                    006/000
  1106.                               END
  1107.  
  1108.      This coding will cause mail to be accumulated for the 3 nodes: 001/000,
  1109.      005/000 and 006/000, since they are all INBOUNDed.  On  Monday, 001/000
  1110.      will be called to deliver and pickup mail.  On Tuesday, 006/000 will be
  1111.      called to deliver and pickup  mail.    On  Wednesday,  005/000  will be
  1112.      called  to  deliver  and  pickup  mail.   You will not need to change a
  1113.      thing, the INBOUNDs will be automatically overridden when the scheduled
  1114.      day arrives.
  1115.  
  1116.  
  1117.                                        17
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.      There can be 100 entries in the OUTBOUND NODES list.
  1128.  
  1129.  
  1130.      PREFIXES
  1131.      ~~~~~~~~
  1132.      The PREFIXES  allow the MDRIVER user to specify prefixes and postfixes
  1133.      for use both with local and long distance calls.  This enables  the use
  1134.      of  alternate  long  distance  carriers  and  supports  PBX usage.  The
  1135.      syntax is simple:
  1136.  
  1137.                     PREFIXES  LOCAL(xx,xx)   DISTANT(xx,xx)
  1138.  
  1139.      Within the (...) the first two characters are the prefix characters the
  1140.      two characters  after the  comma are  the postfixes.   Two prefixes and
  1141.      postfixes may be given for  local  and  long  distance.    The possible
  1142.      prefix/postfix characters  are the -/+/*/! characters, the same used in
  1143.      GT.  MDRIVER will get the  prefixes from  the GT.CNF  file.   An actual
  1144.      example might be:
  1145.  
  1146.                     PREFIXES  LOCAL(-)  DISTANT(*,+!)
  1147.  
  1148.                           Where:   -  .....  9,
  1149.                                    *  .....  9,1
  1150.                                    +  .....  W
  1151.                                    !  .....  PASS
  1152.  
  1153.      NOTE: if  a prefix  for long  distance is  specified, then  GT will not
  1154.      automatically insert the "1," in the dialing string, the user  must put
  1155.      that into his prefix.
  1156.  
  1157.  
  1158.      PICKUP OVERRIDES
  1159.      ~~~~~~~~~~~~~~~~
  1160.      Normally when  MDRIVER places  a out-of-net call to deliver mail, using
  1161.      non PC Pursuit means, mail will be delivered but no pickup of mail will
  1162.      be done.   The  PICKUP OVERRIDES  listing provides a way to defeat this
  1163.      procedure and force MDRIVER to pickup your mail on out-of-net calles to
  1164.      specific destinations.   The  syntax for  the list  is exactly like the
  1165.      LONG DISTANCE list shown above.  For example:
  1166.  
  1167.                               PICKUP OVERRIDES
  1168.                                    002/001-001
  1169.                                    005/000-001
  1170.                               END
  1171.  
  1172.      If you were in net 001 and had these lines in your PICKUP OVERRIDES you
  1173.      would force  MDRIVER to  pickup your  mail whenever delivering mail the
  1174.      Net/Node 002/001, 005/000, 005/001.    Listing  a  node  in  the PICKUP
  1175.      OVERRIDES list  DOES NOT  force a  call to be placed, a message must be
  1176.      entered or the node must be in the OUTBOUND NODES list for a call to be
  1177.      placed.  But once in contact with the listed nodes, any mail present on
  1178.      the listed nodes for you will be collected.
  1179.  
  1180.      There can be 200 entries in the PICKUP OVERRIDES list.
  1181.  
  1182.  
  1183.                                        18
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.      ROUTING INSTRUCTIONS
  1195.      ~~~~~~~~~~~~~~~~~~~~
  1196.      Probably the simplest, yet the most complex of  all the  options in the
  1197.      ROUTING.BBS file.  An example first:
  1198.  
  1199.                     ROUTING INSTRUCTIONS
  1200.                          FORWARD  001/001-999 -> 001/010,001/000
  1201.                          ACCEPT   002/001-999 -> 002/000
  1202.                          ACCEPT   002/000
  1203.                          ACCEPT   001/000
  1204.                     END
  1205.  
  1206.      The FORWARD  command specifies  that any  message addressed to nodes in
  1207.      the range 1-999 of net 001 will be forwarded to  Net/Node 001/010, with
  1208.      001/000 as an alternate destination.
  1209.  
  1210.      +--------------------------------------------------------------------+
  1211.      |                                                                    |
  1212.      |    Nodes 001/010, 001/000 and 002/000 must have complimentary      |
  1213.      |     ACCEPTs in their ROUTING.BBS files, or the forward will not be  |
  1214.      |    done.                                                            |
  1215.      |                                                                    |
  1216.      +--------------------------------------------------------------------+
  1217.  
  1218.      NOTE: Please do not attempt to forward mail unless you are sure that
  1219.            the intermediate node is setup to accept mail for
  1220.            forwarding to the final destination.
  1221.  
  1222.      The ACCEPT  acts as permission to accept mail to be passed thru and may
  1223.      also indicate further forwarding that may be necessary.
  1224.  
  1225.      The first ACCEPT command  (previous page)  specifies that  mail will be
  1226.      accepted  for  the  nodes  in  the  range 1-999 for net 002 and will be
  1227.      forwarded to Net/Node 002/000.
  1228.  
  1229.      The final two ACCEPT commands (previous  page) indicate  that mail will
  1230.      be  accepted  for  Net/Node  002/000  and  001/000.   Mail will be sent
  1231.      directly to these nodes without intermediate steps.
  1232.  
  1233.      Most users of the netmail system need not worry about these FORWARD and
  1234.      ACCEPT commands.   They  need only specify that message traffic be sent
  1235.      through  their  local  hub.    For  example,  I  have  in   my  ROUTING
  1236.      INSTRUCTIONS the following:
  1237.  
  1238.                     FORWARD  001/002-002 -> 001/000
  1239.                     FORWARD  001/004-999 -> 001/000
  1240.                     FORWARD  002/000-999 -> 001/000
  1241.                     FORWARD  003/000-999 -> 001/000
  1242.                     .
  1243.                     . etc
  1244.  
  1245.      In effect,  I have  routed all my message traffic through my local hub,
  1246.      001/000.  Simple.  Since I do not run a  hub system,  I have  no ACCEPT
  1247.      statements at  all.   One interesting  thing to  notice, you should not
  1248.  
  1249.                                        19
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.      FORWARD mail for yourself to  someone  else.    My  net/node  number is
  1260.      001/001, so  you can  see above  that I have not redirected traffic for
  1261.      001/001 to the hub system.  Also, it  is important  not to  include any
  1262.      address on both sides of the redirection symbol, "->".  For example:
  1263.  
  1264.                     FORWARD 001/000-999 -> 001/000
  1265.  
  1266.      Would be WRONG, WRONG, WRONG!  The right way would be:
  1267.  
  1268.                     FORWARD 001/001-999 -> 001/000
  1269.  
  1270.      Which would  insure that 001/000 was not listed on the left side of the
  1271.      redirection symbol.
  1272.  
  1273.      For operators of hub systems: the ACCEPT works  like a  FORWARD and you
  1274.      need *not*  have ACCEPT  and FORWARD statements for the same addresses.
  1275.      Either ACCEPT or FORWARD will do the job.   The  ACCEPT is  used on hub
  1276.      systems since  they are expected to accept message traffic for delivery
  1277.      to others.  The ACCEPT grants  permission to  do this,  if MDRIVER does
  1278.      not  have   permission  to  accept  message  traffic  for  a  requested
  1279.      destination, then the traffic will  be  denied  and  messages  will not
  1280.      flow.
  1281.  
  1282.      It is  important to  note that  the ACCEPT  does not always require the
  1283.      redirection symbol.  In other words, if you ACCEPT message  traffic for
  1284.      direct  delivery  to  the  final destination without further forwarding
  1285.      through 3rd parties, the ACCEPT should be coded without the redirection
  1286.      symbol.  For example:
  1287.  
  1288.                               ACCEPT  001/000
  1289.  
  1290.      This command would allow the hub to accept message traffic for delivery
  1291.      to 001/000.  The traffic would not be re-routed to an intermediate, but
  1292.      would be directly delivered to 001/000.
  1293.  
  1294.      It is  possible to  specify ranges  for the net numbers, in addition to
  1295.      the ranges for node numbers, shown above.  Here is an example:
  1296.  
  1297.                          ACCEPT 001-005/000-999 -> 001/010
  1298.  
  1299.      With this single routing instruction, all mail for nets 001 thru 005 is
  1300.      routed thru  the hub  at 001/010.  Please note that net ranges can only
  1301.      be used with routing instructions for netmail.
  1302.  
  1303.      There is an additional function for  ACCEPT  statments.    They  play a
  1304.      critical  role  in  the  processing  and  routing  of Echomail.  On the
  1305.      sponsor system for an Echomail conference, there must  appear an ACCEPT
  1306.      statement  for   the  sponsored   conference  without  any  redirection
  1307.      indicated:
  1308.  
  1309.                               ACCEPT E00/002  $xxxx
  1310.  
  1311.      Would indicate that  the  system  was  the  sponsoring  system  for the
  1312.      E00/002 Echomail  conference.   And that  the $xxxx is the Echomail CRC
  1313.      number assigned by the Echomail Coordinator.
  1314.  
  1315.                                        20
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.      On the system of subscribers  to  an  Echomail  conference,  there must
  1327.      appear ACCEPT statments for each Echomail conference subscribed to:
  1328.  
  1329.                          ACCEPT E00/004-004 -> 001/003
  1330.                          ACCEPT E00/033-033 -> 001/002
  1331.  
  1332.      These ACCEPTs must show redirection (to distinguish between sponsor and
  1333.      subscriber).  The redirection should point  to the  system where  it is
  1334.      intended to  pickup the  Echomail conference.   NOTE: you can pickup an
  1335.      Echomail  conference  from  virtually  any  system   that  carries  the
  1336.      conference you  are interested  in.   If you  are already  picking up a
  1337.      conference, be  careful when  changing your  pickup point  -- make sure
  1338.      that  the  person  you  get  it  from  is  not  calling  you to get the
  1339.      conference (if he does then you will have  a closed  loop which doesn't
  1340.      include the sponsoring system, hence you will get nothing).
  1341.  
  1342.      Alternate  destinations  may  be  listed  on  either  ACCEPT or FORWARD
  1343.      statements.  The listing of an alternate destination allows the MDRIVER
  1344.      program to  let some other node pickup the mail.  This is useful if the
  1345.      primary node is out-of-service for some reason.  Then if  the alternate
  1346.      calls,  the  system  will  pass  the  mail along to him.  Note that the
  1347.      alternate destination is *not* automatically called.  So if you want to
  1348.      insure that  the mail  is passed,  it would  be appropriate to list the
  1349.      alternate  destination  in  the  OUTBOUND  NODES  section.    Alternate
  1350.      destinations are  listed on the ACCEPT/FORWARD statements following the
  1351.      primary destination separated by commas, for example:
  1352.  
  1353.                ACCEPT 001/001-999 -> 001/000,001/003,001/008
  1354.  
  1355.      In the above example, 001/000 is  the primary  destination, 001/003 and
  1356.      001/008 are  alternate destinations.  This routing would allow the mail
  1357.      for net 001 to move to any of three destinations, whichever calls first
  1358.      will get the mail.
  1359.  
  1360.  
  1361.      REQUEST ECHOMAIL CONFERENCES
  1362.      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1363.      This section  should be  filled out  when you  decide to carry Echomail
  1364.      conferences sponsored by another  node.   Listing the  conference ID in
  1365.      this section  alerts MDRIVER to pickup the conference whenever in comes
  1366.      in contact with the node designated in the ACCEPT for the conference.
  1367.      For example:
  1368.  
  1369.                          REQUEST ECHOMAIL CONFERENCES
  1370.                               E00/001
  1371.                               E00/006
  1372.                          END
  1373.  
  1374.      Would cause MDRIVER to pickup  echo  conferences  E00/001  and E00/006.
  1375.      The  MDRIVER  program  would  call  the  listed  destinations for these
  1376.      conferences, as shown in the routing instructions.  For example, if the
  1377.      routing instructions were:
  1378.  
  1379.                          ROUTING INSTRUCTIONS
  1380.  
  1381.                                        21
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.                               ACCEPT E00/001 -> 006/001
  1392.                               ACCEPT E00/006 -> 001/003
  1393.                          END
  1394.  
  1395.      Then  calls  to  pickup  echomail  would be placed to nodes 006/001 and
  1396.      001/003.  If you wished to suppress those calls, you should INBOUND the
  1397.      destination  nodes,  006/001  and  001/003  (in which case, the MDRIVER
  1398.      program would pickup the conference  when  006/001  and  001/003 called
  1399.      you).   Unfortunately, most of the time, you will have to make the call
  1400.      to pickup, you will not be lucky enough to be able to wait for  a call,
  1401.      if you want a timely conference input.
  1402.  
  1403.      In many  respects, the  REQUEST ECHOMAIL  CONFERENCES section acts like
  1404.      the  OUTBOUND  NODES  section.    For  instance,  the  REQUEST Echomail
  1405.      CONFERENCES can  be scheduled  for a  particular day  of the week, just
  1406.      like the  OUTBOUND  NODES.    One  may  consider  the  REQUEST Echomail
  1407.      CONFERENCES to  be an  extension of  the OUTBOUND NODES section that is
  1408.      dealing with echomail conferences, instead of node addresses.
  1409.  
  1410.  
  1411.      MESSAGE DISTRIBUTION
  1412.      ~~~~~~~~~~~~~~~~~~~~
  1413.      The MESSAGE DISTRIBUTION section is used  to tell  the netmail programs
  1414.      where you  wish to  have message  stored/retrieved.  It is primarily of
  1415.      interest to folks who use Echomail,  but  can  be  used  by  anyone who
  1416.      wishes to have multiple netmail areas.  Here is an example:
  1417.  
  1418.                          MESSAGE DISTRIBUTION
  1419.                               E00/000-000 -> C:\GTPOWER
  1420.                               E00/001-001 -> C:\RELIGION
  1421.                               007/000-999 -> C:\PACNW
  1422.                          END
  1423.  
  1424.      The  entry  in  the  MESSAGE  DISTRIBUTION  equates Echomail or netmail
  1425.      addresses to physical pathnames on your  disk system.   Notice  how net
  1426.      007  is  redirected  to  C:\PACNW,  all other network addresses will be
  1427.      directed  to  the  primary  (first)  netmail  area  encountered  in the
  1428.      GTMDIR.BBS file.   Echomail conferences MUST be listed in this section,
  1429.      otherwise the MDIST program will not know where to store  them, and the
  1430.      MBAGGER  program  will  not  know  where  to  pickup the latest message
  1431.      traffic for delivery to the Echomail sponsor.
  1432.  
  1433.  
  1434.      ECHOMAIL HOURS
  1435.      ~~~~~~~~~~~~~~
  1436.      The purpose of the ECHOMAIL HOURS section is to limit  the placement of
  1437.      outgoing Echomail  calls, i.e.  so that  they do not interfere with the
  1438.      processing of normal netmail.  If there was no way  to govern Echomail,
  1439.      it would  soon leave no time for regular netmail to be processed.  This
  1440.      section is simply one line, as follows:
  1441.  
  1442.                          ECHOMAIL HOURS 0400-0500
  1443.  
  1444.      The times are listed with  a  dash  between.    It  is  permissible for
  1445.      netmail  to  occur  during  the  Echomail hours, but the reverse is not
  1446.  
  1447.                                        22
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.      authorized.
  1458.  
  1459.  
  1460.      EXCLUDED NODES
  1461.      ~~~~~~~~~~~~~~
  1462.      The EXCLUDED NODES section  may be  used to  keep designated  nodes (of
  1463.      your choice)  from calling  your system.  This is another SYSOP tool to
  1464.      guard his system against unauthorized usage.  The banned nodes  are put
  1465.      in a simple list, one node per line, as follows:
  1466.  
  1467.                          EXCLUDED NODES
  1468.                               001/534
  1469.                               002/467
  1470.                          END
  1471.  
  1472.      It is  not good  practice to  exclude a  node from  your netmail system
  1473.      without reason.  Normally, one would have no  need for  this section at
  1474.      all.   But certain  circumstances, for  example a person who has abused
  1475.      your system, may require complete banning.  This section will  give you
  1476.      the flexibility to completely lock out anyone of your choice.  NOTE: Do
  1477.      not use this section  lightly or  in jest.   This  is very  serious and
  1478.      potentially damaging to the network.
  1479.  
  1480.  
  1481.      HINTS FOR ECHOMAIL
  1482.      ~~~~~~~~~~~~~~~~~~
  1483.      When  setting  up  Echomail,  the  user  will  notice  that  it will be
  1484.      necessary to have two or more ROUTING.BBS files.  One  to use  for each
  1485.      scheduled  Echomail  event  and  another  to use with the Netmail hour.
  1486.      These ROUTING.BBS files should be  nearly  identical  in  every aspect,
  1487.      except for two areas: INBOUND NODES and ECHOMAIL HOURS.
  1488.  
  1489.      The INBOUND NODES should be used to control which calls you do not want
  1490.      to be placed during certain sessions.  For example, your normal netmail
  1491.      destinations should be INBOUNDed during an Echomail session (if needed)
  1492.      so that you do not  place  netmail  calls  to  systems  which  might be
  1493.      running BBS software instead of the netmail software at that hour.  The
  1494.      ECHOMAIL HOURS section should  contain the  appropriate hours  for each
  1495.      session  of  Echomail,  and  should  not  overlap the time reserved for
  1496.      netmail.  For example,  if the  netmail time  period is  0400-0500 then
  1497.      during that  time period,  the ECHOMAIL HOURS should be something else,
  1498.      for instance  0300-0400.   If in  addition, 0300-0400  was reserved for
  1499.      Echomail on  your system, then the ROUTING.BBS file in use at that time
  1500.      should contain the following statement:
  1501.  
  1502.                          ECHOMAIL HOURS 0300-0400
  1503.  
  1504.  
  1505.  
  1506.      Sample Echomail ROUTING.BBS
  1507.      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1508.      PURSUIT
  1509.         ACCESS=227-1018
  1510.         USERID=YUYP2422
  1511.         PASSWORD=6324RWBG
  1512.  
  1513.                                        23
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.         CITIES
  1524.            201,NJNEW-Newark
  1525.            216,OHCLV-Cleveland
  1526.            202,DCWAS-Washington
  1527.            305,FLMIA-Miami
  1528.            206,WASEA-Seattle
  1529.            408,CASJO-San_Jose
  1530.            212,NYNYO-New_York
  1531.            718,NYNYO+New_York
  1532.            414,WIMIL-Milwaukee
  1533.            213,CALAN-Los_Angeles
  1534.            503,ORPOR-Portland
  1535.            214,TXDAL-Dallas
  1536.            602,AZPHO-Phoenix
  1537.            215,PAPHI-Philadelphia
  1538.            612,MNMIN-Minneapolis
  1539.            303,CODEN-Denver
  1540.            801,UTSLC-Salt_Lake
  1541.            312,ILCHI-Chicago
  1542.            813,FLTAM-Tampa
  1543.            313,MIDET-Detroit
  1544.            818,CAGLE-Glendale
  1545.            404,GAATL-Atlanta
  1546.            415,CASFA-San_Fransisco
  1547.            713,TXHOU-Houston
  1548.            617,MABOS-Boston
  1549.      END
  1550.      REQUEST ECHOMAIL CONFERENCES
  1551.         E00/002
  1552.         E00/003
  1553.         E00/004
  1554.         E00/005
  1555.         E00/006
  1556.         E00/007
  1557.         E00/008
  1558.         E00/009
  1559.         E00/010
  1560.      END
  1561.      INBOUND NODES
  1562.         001/001
  1563.         001/002
  1564.         001/008
  1565.         002/000
  1566.         005/000
  1567.         006/000
  1568.         006/001
  1569.         008/000
  1570.         010/000
  1571.         016/000
  1572.         024/000
  1573.         026/000
  1574.      END
  1575.      ROUTING INSTRUCTIONS
  1576.         ACCEPT 001/000-001
  1577.         ACCEPT 001/002-002 -> 001/000
  1578.  
  1579.                                        24
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.         ACCEPT 001/004-007 -> 001/000
  1590.         ACCEPT 001/008-008
  1591.         ACCEPT 001/009-009 -> 001/000
  1592.         ACCEPT 001/010-010
  1593.         ACCEPT 001/011-999 -> 001/000
  1594.         ACCEPT 002/000-000 -> 001/008
  1595.         ACCEPT 002/001-999 -> 001/008,002/000
  1596.         ACCEPT 003/000-000 -> 001/008
  1597.         ACCEPT 003/001-999 -> 001/008,003/000
  1598.         ACCEPT 004-005/000-999 -> 001/010
  1599.         ACCEPT 006/000-000 -> 008/000,008/001
  1600.         ACCEPT 006/001-999 -> 008/000,008/001,006/000
  1601.         ACCEPT 007/000-000 -> 001/010
  1602.         ACCEPT 007/001-999 -> 001/010,007/000
  1603.         ACCEPT 008/000-000
  1604.         ACCEPT 008/001-001 -> 008/000
  1605.         ACCEPT 008/002-999 -> 008/000,008/001
  1606.         ACCEPT 009/000-000 -> 001/010
  1607.         ACCEPT 009/001-999 -> 001/010,009/000
  1608.         ACCEPT 010/000-000 -> 008/000,008/001
  1609.         ACCEPT 010/001-999 -> 008/000,008/001,010/000
  1610.         ACCEPT 011/000-000 -> 008/000,008/001
  1611.         ACCEPT 011/001-999 -> 008/000,008/001,011/000
  1612.         ACCEPT 012/000-999 -> 008/000,008/001
  1613.         ACCEPT 013/000-000 -> 001/008
  1614.         ACCEPT 013/001-999 -> 001/008,013/000
  1615.         ACCEPT 014/000-000 -> 001/010,007/000
  1616.         ACCEPT 014/001-999 -> 001/010,007/000,014/000
  1617.         ACCEPT 015/000-000 -> 001/008,002/000
  1618.         ACCEPT 015/001-999 -> 001/008,002/000,015/000
  1619.         ACCEPT 016/000-000
  1620.         ACCEPT 016/001-999 -> 016/000
  1621.         ACCEPT 017/000-000 -> 001/008
  1622.         ACCEPT 017/001-999 -> 001/008,017/000
  1623.         ACCEPT 018/000-000 -> 001/010,007/000
  1624.         ACCEPT 018/001-999 -> 001/010,007/000,018/000
  1625.         ACCEPT 019/000-000 -> 001/010,007/000
  1626.         ACCEPT 019/001-999 -> 001/010,007/000,019/000
  1627.         ACCEPT 020/000-000 -> 001/010,007/000
  1628.         ACCEPT 020/001-999 -> 001/010,007/000,020/000
  1629.         ACCEPT 021/000-000 -> 001/010
  1630.         ACCEPT 021/001-999 -> 001/010,021/000
  1631.         ACCEPT 022/000-000 -> 008/000,008/001
  1632.         ACCEPT 022/001-999 -> 008/000,008/001,022/000
  1633.         ACCEPT 023/000-000 -> 001/010
  1634.         ACCEPT 023/001-999 -> 001/010,023/000
  1635.         ACCEPT 024/000-000
  1636.         ACCEPT 024/001-999 -> 024/000
  1637.         ACCEPT 025/000-000 -> 008/000,008/001
  1638.         ACCEPT 025/001-000 -> 008/000,008/001,025/000
  1639.         ACCEPT 026/000-000
  1640.         ACCEPT 026/001-999 -> 026/000
  1641.         ACCEPT 027/000-000 -> 001/010,007/000
  1642.         ACCEPT 027/001-999 -> 001/010,007/000,027/000
  1643.         ACCEPT 028/000-000 -> 001/010
  1644.  
  1645.                                        25
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.         ACCEPT 028/001-999 -> 001/010,028/000
  1656.         ACCEPT 800/000-000 -> 001/008,013/000
  1657.         ACCEPT 800/001-999 -> 001/008,013/000,800/000
  1658.         ACCEPT 801/000-000 -> 001/008,013/000
  1659.         ACCEPT 801/001-999 -> 001/008,013/000,801/000
  1660.         ACCEPT E00/001-001  $xxxx
  1661.         ACCEPT E00/002-002 -> 001/019
  1662.         ACCEPT E00/003-003 -> 001/000
  1663.         ACCEPT E00/004-004 -> 006/001
  1664.         ACCEPT E00/005-005 -> 005/000
  1665.         ACCEPT E00/006-006 -> 002/000
  1666.         ACCEPT E00/007-007 -> 001/010
  1667.         ACCEPT E00/008-008 -> 001/008
  1668.         ACCEPT E00/009-009 -> 001/002
  1669.         ACCEPT E00/010-010 -> 002/000
  1670.      END
  1671.      MESSAGE DISTRIBUTION
  1672.         E00/001-001 -> D:\GT_ECHO
  1673.         E00/002-002 -> D:\RELIGION
  1674.         E00/003-003 -> D:\FINANCE
  1675.         E00/004-004 -> D:\TRADIN
  1676.         E00/005-005 -> D:\DOORS
  1677.         E00/006-006 -> D:\SYSOP
  1678.         E00/007-007 -> D:\GENEALGY
  1679.         E00/008-008 -> D:\SAT_TV
  1680.         E00/009-009 -> D:\SOFTECH
  1681.         E00/010-010 -> D:\DOCTORS
  1682.      END
  1683.      ECHOMAIL HOURS 0100-0400
  1684.  
  1685.  
  1686.      The sample  ROUTING.BBS file  above shows  how all  the regular netmail
  1687.      destinations are INBOUNDed.  Since this is the ROUTING.BBS file for the
  1688.      sponsor of E00/001, there is no  request for  that Echomail conference.
  1689.      There are  ACCEPT statements  for all  nodes in the network, since this
  1690.      came from one of the Continental  Hub systems  -- notice  the extensive
  1691.      use of  alternate routing  to help  move the  mail along.  All Echomail
  1692.      conferences that are carried have  ACCEPT  statements,  and  the ACCEPT
  1693.      statement for  E00/001 has  no redirection indicated, since this is the
  1694.      sponsoring hub for that conference.   Note the  OUTBOUNDed nodes, these
  1695.      are present  so that calls to these hub systems will be forced, if need
  1696.      be during this session (care should be taken  here, that  these systems
  1697.      must be  operating in  netmail mode  during this time period, otherwise
  1698.      these calls might be wasted).  During this period, calls to pick-up the
  1699.      following conferences will be made: E00/002,E00/003,E00/007.
  1700.  
  1701.  
  1702.                                     [ fini ]
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.                                        26
  1712.  
  1713.