home *** CD-ROM | disk | FTP | other *** search
/ Media Share 9 / MEDIASHARE_09.ISO / mail / mplus351.zip / NETINFO.DOC < prev    next >
Text File  |  1994-01-24  |  35KB  |  705 lines

  1. NETINFO.DOC - set up instructions for QWK networking features of Mail
  2.               Manager +Plus+.
  3.  
  4.   We have included three files in this package that are related to QWK
  5.   networking:
  6.  
  7.    - MUSER.EXE is the user file editor for Mail Manager's internal users
  8.                  file, MAILMGR.USR.  Use this to add a username, net status
  9.                  capability for a particular username, etc.  All options on
  10.                  the HOST end of the line are taken care of via this utility.
  11.  
  12.    - MNET.EXE is the QWK->REP conversion utility for the NODE end of the
  13.                  line.  The host does not need this utility.
  14.  
  15.    - SAMPLE.CFG is a sample MNET configuration file (again, for the NODE end
  16.                  of the line) based on what we're about to talk about.
  17.  
  18.   Mail Manager +Plus+ can produce MarkMail-compatible mail packets for
  19.   specific usernames on your system.  Said mail packets can be processed with
  20.   any number of QWK network utilities from other authors such as TNET, RNET,
  21.   et al, as well as Mail Manager's own MNET utility (included in this
  22.   package).  Therefore, Mail Manager +Plus+ network-capable mail packets can
  23.   easily be used by sysops of ANY bulletin board type that has a supporting
  24.   QWK network utility!
  25.  
  26.   Also, the MNET utility was written to be completely generic.  Therefore,
  27.   all sysops who have a QWK mail door capable of generating and handling
  28.   network packets can use the MNET utility for their file conversion, without
  29.   resorting to an external processor.
  30.  
  31.   QWK networking is intended as an alternative to Fido-style mail transfer.
  32.   You do not need to completely reconfigure your BBS to get into QWK network
  33.   mail transfer.  The sysop acting as the "node" must get into some serious
  34.   file conversion, however (all of which Mail Manager +Plus+, and
  35.   accompanying utilities can handle for you).
  36.  
  37.   QWK and Fido network mail transfer do not mix well.  It is strongly
  38.   recommended that you keep your QWK and Fido network message bases SEPARATE
  39.   FROM EACH OTHER, and do not try to transfer the same conference via both
  40.   methods.
  41.  
  42.   A QWK-format net system is complex enough that explaining how to set it up
  43.   gets rather involved, so let's take it in stages:
  44.  
  45. -------------------------------------------------------------------------
  46.                       PHASE I : GENERAL OVERVIEW
  47. -------------------------------------------------------------------------
  48.  
  49.   The scenario works like this:
  50.  
  51.      You have a conference or two that you would like to share with a few
  52.      other interested sysops.  This means that you are acting as the "host",
  53.      and the people calling in to receive this conference from you are acting
  54.      as nodes.  They would call up your system with a username which you have
  55.      set up to have "net status".  They would then load up the Mail Manager
  56.      +Plus+ door, and download their mail packet:
  57.  
  58.            Your BBS                     Their BBS
  59.           ===========      download    ===========
  60.           YOURBBS.QWK ---------------> YOURBBS.QWK (downloaded from you)
  61.                                            |
  62.                                        Tossed into into their mail door
  63.                                        via any of several means, depending
  64.                                        on system.
  65.                                            |
  66.                                        New messages from them are extracted
  67.                                        via any of several means, depending
  68.                                        on system, to produce:
  69.                          upload            |
  70.           YOURBBS.REP <--------------- YOURBBS.REP
  71.               |
  72.           Uploaded into your mail door,
  73.           and processed by your system.
  74.  
  75.      As you can see, it is real easy to become a "host" in this operation.
  76.      All you have to do is grant the user "net status" and configure which
  77.      conferences to allow the user net access to.  All of the dirty work
  78.      (file conversion) is done on the "node" end of the line.
  79.  
  80.      Now, if the REVERSE is true, (another sysop has a conference that
  81.      YOU are interested in), you would do exactly the reverse.  You
  82.      would call their system, extract and download their QWK packet, and
  83.      do the necessary conversion on your end of the line.  You would then
  84.      call their BBS back up, and send up any replies destined for them.
  85.      Again, this would work like so:
  86.  
  87.            Your BBS                              Their BBS
  88.           ===========      download            ============
  89.           THEIRBBS.QWK <---------------------- THEIRBBS.QWK
  90.               |
  91.           (use MNET util to
  92.           convert to:)
  93.               |
  94.           YOURBBS.REP
  95.               |
  96.           (upload into your MAILMGR+
  97.           door. New outgoing messages
  98.           are extracted into:)
  99.               |
  100.           YOURBBS.QWK.
  101.               |
  102.           (use MNET util to
  103.           convert to:)
  104.               |                    upload
  105.           THEIRBBS.REP  ---------------------> THEIRBBS.REP
  106.                                                    |
  107.                                                Uploaded into their mail
  108.                                                door, and processed.
  109.  
  110.      Now, you would probably embellish this to make the call that does
  111.      all of this at once (IE - Send up THEIRBBS.REP and download
  112.      THEIRBBS.QWK in the same session).  By the same token, the guy
  113.      who is calling *YOU* (with you acting as the host) would probably
  114.      do the same thing in reverse.
  115.  
  116.  
  117. ------------------------------------------------------------------------------
  118.                        PHASE II:  SETTING UP AS HOST
  119. ------------------------------------------------------------------------------
  120.  
  121.     A suggestion, hint, or whatever: 
  122.     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  123.       Before we go into the details of how to set up a host board, we would
  124.       like to suggest you consider setting up a second copy of MAILMGR+ to
  125.       use for your net activities, if you have the disk space for it.  You
  126.       can completely isolate your net activities from your normal user
  127.       activities this way, and can configure the net door for only those
  128.       conferences that you wish to have available for net transfer.  Both
  129.       copies of the door can access the same RBBS message and user files, but
  130.       they will need to be set up in separate directories, and have their own
  131.       MAILMGR.USR files.  It is a good idea to give this second copy of the
  132.       door a different packet name from that used in your user door, so the
  133.       QWK and REP packets don't get mixed up.
  134.  
  135.       This can all be done with a single door, but a net user who is also a
  136.       personal user of the board will be forced to make two calls - one under
  137.       his "net" name and one under his real name.
  138.  
  139.       With a separate copy of the door for net activities, it will not be 
  140.       necessary to create bogus user names for your net node callers - they
  141.       can call in under their normal names, do net transfers from your net
  142.       door, and still be able to do "personal" QWK/REP activity in your user
  143.       door, plus carry out any other normal activities on your board all in
  144.       the same call.  One of the first boards to beta test the net 
  145.       capabilities of MMGR set up a separate door for net activity, and it 
  146.       has been quite satisfactory.
  147.  
  148.     Now on with the show ...
  149.  
  150.     Installing/configuring for Host Operation:
  151.     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  152.     This has to be done first, before any QWK net mail transfer can take
  153.     place.  Let's pick a random example of how you might want to start
  154.     something like this in the first place... filenames listed below for
  155.     NODE and HOST are just for clarity:
  156.  
  157.           HOST's mail packets are named HOST.QWK, and he expects HOST.REP to 
  158.           be uploaded into his Mail Manager +Plus+ door.
  159.  
  160.           The host wants to allow a particular user to network his message
  161.           area named SPECIAL.  (This would be SPECIALM.DEF and SPECIALU.DEF
  162.           for RBBS message and user files).
  163.  
  164.           The person who is to be calling in to download mail and upload 
  165.           replies is "JOHN DOE".  On the bbs that John Doe runs, his QWK door
  166.           uses mail packets named NODE.QWK and NODE.REP.
  167.  
  168.           (If you are NOT setting up a separate door for net use, John will
  169.           need a special username to pick up his network mail, so that we can
  170.           keep track of last message read and so forth without screwing up
  171.           John's own "real" logon sessions to your board.  You decide to give
  172.           John a fake name of "NODE MAIL" for network mail purposes.)
  173.  
  174.  
  175.     OK.  With that in mind, here is what you would do:
  176.  
  177.     (Written for a single door setup, using a dummy name for the user.  If 
  178.     you are going to have a separate door for net activity, the instructions 
  179.     are the same except you would skip steps 1 and 2, and use the user's real
  180.     name)
  181.  
  182.        1) Create a user name on your system of "NODE MAIL".  Give him a
  183.           password, and a standard security level that you would give anyone
  184.           else.  (He doesn't need any elevated security).  Say you made his
  185.           password "QWKMAIL".
  186.  
  187.        2) Inform John Doe that his username and password for mail purposes is
  188.           "NODE MAIL", with the password "QWKMAIL".
  189.  
  190.        3) Run the MUSER.EXE utility, and add "NODE MAIL" to the file, using
  191.           option 2 from the MUSER edit screen.
  192.  
  193.        4) Using MUSER.EXE, set up the user's options for net access.  Based
  194.           on what we have discussed above, the screen would look something
  195.           like this:
  196.  
  197. ---> start screen capture
  198.  
  199. MUSER - Utility to edit MAIL MANAGER +PLUS+ User Files.
  200. Version 3.11  Copyright (C) 1992, Makai Software.  All rights reserved.
  201. ═══════════════════════════════════════════════════════════════════════════════
  202. A) USER:  NODE MAIL                                              RECORD:     5
  203. ───────────────────────────────────────────────────────────────────────────────
  204. B) Packet type:         QWK                  L) Abort if no msgs:    Yes
  205. C) Update pointer:      Yes                  M) Ask before send:     No
  206. D) Xfer protocol:       Z                    N) Default msg select:  All msgs
  207. E) Msg to ALL as pers:  No                   O) Turbokey:            On
  208. F) Display Menu:        No                   P) Net Status:          Net node
  209. G) Archive choice:      ZIP                  Q) Net identification:  NODE
  210. H) Last-on (YYMMDD):    921102               R) .MSG Date (YYMMDD):  800101
  211. I) Send own msgs:       No                   S) .MSG Time (HHMMSS):  000000
  212. J) Send bulletins:      No                   T) .MSG Length:         0
  213. K) Send new file info:  No
  214. ═══════════════════════════════════════════════════════════════════════════════
  215.         TO SELECT USER: Press , , PgUp, PgDn.  (<ESC> to QUIT)
  216.  
  217.         OPTIONS:                   EDIT USER SHOWN:
  218.         1) Find User Name          A-T) Edit data above
  219.         2) Add new user            4)   Edit conf data
  220.         3) Purge User Records      5)   Delete user
  221. ═══════════════════════════════════════════════════════════════════════════════
  222.  
  223. ---> end screen capture
  224.  
  225.   Most important of the above are the following options:
  226.  
  227.     P) Net Status         = Net node
  228.     Q) Net identification = NODE
  229.  
  230.   The other options he can set for himself the first time he logs on, or are
  231.   handled automatically by the door.  Net status and net identification he
  232.   CANNOT set up himself, however.
  233.  
  234.   The net identification field is used by Mail Manager +Plus+ to keep track
  235.   of which messages originally came from that "net status" user, to prevent
  236.   him from receiving these same messages back in subsequent QWK packets.
  237.   The identifier can be any combination of (up to 8) characters which will
  238.   uniquely identify this user to your system.  We suggest that a convenient
  239.   identifier might be the QWK/REP base packet name used at HIS end of the
  240.   line.  (In our example here, the node uses NODE.REP and NODE.QWK at his
  241.   end of the line, so we used NODE as the indentifier.)
  242.  
  243.   Once you have set these options, the last thing to do is to flag which 
  244.   conferences you would like him to be able to pick up.  Do this by punching
  245.   option 4 from the above menu (MUSER takes you there automatically when
  246.   setting up a new net user).  You'll get a screen that looks like this:
  247.  
  248. ---> Start screen capture
  249.  
  250. MUSER - Utility to edit MAIL MANAGER +PLUS+ User Files.
  251. Version 3.11 Copyright (C) 1992, Makai Software.  All rights reserved.
  252. ═══════════════════════════════════════════════════════════════════════════════
  253. A) USER:  NODE MAIL                                              RECORD:     7
  254. ───────────────────────────────────────────────────────────────────────────────
  255.    1 ---         11 ---         21 ---         31 ---         41 ---
  256.    2 ---         12 ---         22 ---         32 ---         42 ---
  257. >  3 NET all-A   13 ---         23 ---         33 ---         43 ---
  258.    4 ---         14 ---         24 ---         34 ---         44 ---
  259.    5 ---         15 ---         25 ---         35 ---         45 ---
  260.    6 ---         16 ---         26 ---         36 ---         46 ---
  261.    7 ---         17 ---         27 ---         37 ---         47 ---
  262.    8 ---         18 ---         28 ---         38 ---         48 ---
  263.    9 ---         19 ---         29 ---         39 ---         49 ---
  264.   10 ---         20 ---         30 ---         40 ---         50 ---
  265. ═══════════════════════════════════════════════════════════════════════════════
  266.          SELECT CONFERENCE via Cursor keys (Press <Esc> to exit conf info)
  267.  
  268.     Choose:  1) Active net - all msg           3) Inactive net - all msg
  269.              2) Active net - pub msg only      4) Inactive net - pub msg only
  270.                                  5) Prohibit net access
  271. ---> end screen capture
  272.  
  273.   Now - as you can see, all you get are conference numbers at this stage of 
  274.   the game.  So, be sure you know which conference numbers correspond to 
  275.   which conferences within Mail Manager.  In the above example, the SPECIAL
  276.   conference is conference #3.  We moved the flashing pointer down to there,
  277.   and punched "1" to give the user net access to all messages in that area,
  278.   and to activate this conference.
  279.  
  280.   Here's what the five options do:
  281.  
  282.      1) Active net - all msg:  Sets user to be able to receive all messages
  283.         in the conference, and turns this conference "on" as though the user
  284.         had seleted it in his own configuration when online.
  285.  
  286.      2) Active net - pub msg only:  Sets user to be able to receive only
  287.         public messages in the conference, and turns this conference "on" as
  288.         though the user had seleted it in his own configuration when online.
  289.  
  290.      3) Inactive net - all msg:  Similar to option 1) but does not turn the
  291.         conference "on".  With this option you give the net user the
  292.         POTENTIAL to participate in this conference, if he chooses to
  293.         activate it.
  294.  
  295.      4) Inactive net - pub msg only:  Similar to option 2) but does not turn
  296.         the conference "on".  With this option you give the net user the 
  297.         POTENTIAL to participate in this conference, if he chooses to 
  298.         activate it.
  299.  
  300.      5) Prohibit net access:  A user given "net status" will only be able to 
  301.         extract messages from, or upload message to, message bases in which 
  302.         you have specifically granted him net access.  If you want to deny 
  303.         net status to that conference entirely, hit option "5".  (Default, if
  304.         you do nothing, is to deny net access.)
  305.  
  306.     **********************************************************************
  307.     * IMPORTANT NOTE:  Many established networks, such as FIDONet,       *
  308.     * RBBSNet, and RIME do not permit unauthorized distribution of their *
  309.     * message bases.  ** DO NOT ** grant net access to such conferences  *
  310.     * without first obtaining permission from proper authorities.        *
  311.     **********************************************************************
  312.  
  313.   When you've granted net access to the conferences you'd like, you're
  314.   done.  Hit [Esc] twice to get out of MUSER, and you will be back at the
  315.   DOS prompt.  You just set up "NODE MAIL" for net status to your "SPECIAL"
  316.   conference.
  317.  
  318.   From this point on, all of the dirty work is done on "NODE MAIL"'s end of
  319.   the line, and you as the host are FINISHED!  Just be sure that ole' NODE
  320.   MAIL can join your "SPECIAL" conference via either RBBS or Mail Manager
  321.   itself (or you can add NODE MAIL to the conference user file manually),
  322.   or the whole purpose of all of this will be defeated.
  323.  
  324.   NODE MAIL will now be able to extract special "net status" packets from
  325.   the conferences you've set up for him.  He will also be able to upload
  326.   REP messages to those same conferences, regardless of the name found in
  327.   the "from" field of the message headers.  Also, MAIL MANAGER +PLUS+ will
  328.   keep track of which messages originally came from NODE MAIL's system, and
  329.   will not allow him to extract those same messages in subsequent QWK
  330.   packets, thus preventing annoying duplication of messages.
  331.  
  332. ------------------------------------------------------------------------------
  333.                        PHASE III:  SETTING UP THE NODE
  334. ------------------------------------------------------------------------------
  335.  
  336.   You lucky dog you... you get to do all the file conversion!
  337.  
  338.   OK - let's just use the names we mentioned above for setting up the
  339.   host here, to avoid confusion.  In this case, here is your scenario:
  340.  
  341.     - You are John Doe, who logs onto the host's board and downloads a "net
  342.       status" packet called "HOST.QWK".
  343.  
  344.     - You are networking his "SPECIAL" conference, which is area #3 on
  345.       his system.
  346.  
  347.     - The REP packets that you send up to him will be named "HOST.REP".
  348.  
  349.   Now, time to make some assumptions about your own system.  Again, let
  350.   us stress that these are just example names for the purposes of creating
  351.   a scenario for helping you set this up.
  352.  
  353.     - Your board uses the filenames "NODE.QWK" and "NODE.REP" for qwk and
  354.       rep packets transferred.
  355.  
  356.     - The networked "SPECIAL" conference is area #15 on your system.
  357.  
  358.   If you are already using some other type of utility, or are not running
  359.   RBBS-PC, it is UP TO YOU to perform the magic.  The following instructions
  360.   pertain to RBBS-PC, and Mail Manager +Plus+.
  361.  
  362.   A quick aside - why RBBS sysops might want to use MNET and MMGR+ for node
  363.   importing/exporting instead of other options:
  364.  
  365.      1) By importing/exporting via an established QWK door, the door can
  366.         keep track of message pointers.  Using external utilities generally
  367.         means they have to keep their own message pointers, and any message
  368.         base renumbering that takes place must also renumber these external
  369.         pointers for proper operation.  MMGR+ uses the same user records RBBS
  370.         does to keep track of message pointers, eliminating the need for any
  371.         separate updating of pointers.
  372.  
  373.      2) MMGR+ will automatically keep track of which messages came from which 
  374.         host.  When extracting a later QWK for export to the host, MMGR+
  375.         knows to not extract these messages, thus preventing annoying
  376.         duplicate messages from being exported.  As a result, you don't have
  377.         to reset your message pointers after uploading a new REP, thus
  378.         eliminating the possibility of skipping messages that were entered
  379.         locally just prior to uploading the REP.
  380.  
  381.      3) If you have any conferences set up to support aliases, MMGR+ will
  382.         extend this support to "netted" messages.
  383.  
  384.   Now back to how to set this beast up...
  385.  
  386.   The MNET.EXE utility will do all of the QWK -> REP conversion for you.
  387.   Before we talk about how to use it, we had best lay out your scenario:
  388.  
  389.       - When you export messages, you generate HOST.REP which contains any 
  390.         messages you wish to send to the host.  You call up the host board, 
  391.         using whatever "net status" name has been established for you on the 
  392.         host board, send up any waiting HOST.REP from your board and download 
  393.         a new HOST.QWK.  You then log off the host.  Now back at your end,
  394.         you import any new messages from the host into your system.
  395.  
  396.       All the fun part of pulling this off is on your end:
  397.  
  398.       1) You fire up Mail Manager +Plus+ locally using a special name and
  399.          password that you've configured to handle mail to/from "HOST", and
  400.          extract NODE.QWK.
  401.  
  402.       2) The host system can't do anything with NODE.QWK, so you use our MNET 
  403.          utility to convert it to HOST.REP.
  404.  
  405.       3) Call up the HOST board, extract and download a new HOST.QWK and
  406.          upload your HOST.REP reply packet.
  407.  
  408.       4) Convert the HOST.QWK that you received to NODE.REP via MNET.
  409.  
  410.       5) Go back into Mail Manager +Plus+ again using that same special
  411.          user name, and upload the new messages from the host as NODE.REP.
  412.  
  413.   .. and you are ready for the next cycle.
  414.  
  415.   First thing in setting this up is to create a special user name you will
  416.   use on your system for handling net mail to/from the host.  For this
  417.   example, we'll use the name HOST MAIL.  If you do not do this, Mail Manager
  418.   +Plus+ will not be able to keep track of which messages were imported to
  419.   your system from the host, and will not be able to prevent these messages
  420.   from being extracted and sent back to the host as duplicate messages in
  421.   subsequent QWKs.
  422.  
  423.   If you participate in more than one net, you'll need to set up a separate
  424.   name for each net.
  425.  
  426.   You use the MUSER utility to do this, and the process is nearly identical
  427.   to that used when setting a user up as a "net status" node caller to your
  428.   system.  The ONLY difference in what you do to set it up is that, instead
  429.   of telling MUSER that this special user name is a "net node", you should
  430.   tell MUSER that this name is a "net host".  In operation, Mail Manager
  431.   +Plus+ does not add "net status" information when it extracts a QWK for a
  432.   "net host" user.  Please see the discussion on setting up a host system,
  433.   above.
  434.  
  435.   Now for setting yourself up to use the MNET utility.  The MNET command
  436.   line is like so:
  437.  
  438.        MNET <HOSTNAME> <I> <O>
  439.  
  440.             hostname = up to 8 characters for what you will be receiving
  441.                        from and sending to your host.  Example: "HOST"
  442.                        would mean HOST.QWK and HOST.REP.
  443.  
  444.             I = Input.  Convert incoming HOST.QWK to NODE.REP.
  445.  
  446.             O = Output.  Convert outgoing NODE.QWK to HOST.REP.
  447.  
  448.    You will need a configuration file for each "HOSTNAME" that you
  449.    intend to set up with MNET.  If your host's QWK's will be named
  450.    HOST.QWK, you would set up a file named "HOST.CFG", and call MNET
  451.    like so:
  452.  
  453.        MNET HOST I            (convert HOST.QWK to NODE.REP)
  454.        MNET HOST O            (convert NODE.QWK to HOST.REP)
  455.  
  456.    That's it.  Based on all of the examples we have mentioned here,
  457.    here is an example HOST.CFG file:
  458.  
  459.                         ----------------------
  460.  
  461. ;Sample MNET configuration file
  462.  
  463. NODE                                                   ; NODE PACKET NAME
  464. JOHN DOE                                               ; NODE SYSOP
  465. HOST SYSOPNAME                                         ; HOST SYSOP
  466. d:\mmgr\plus\                                          ; NODE PACKET DIRECTORY
  467. d:\mmgr\plus\                                          ; HOST PACKET DIRECTORY
  468. Origin: Node BBS (123) 456-7890                        ; NODE TAGLINE
  469. Origin: Host BBS (098) 765-4321                        ; HOST TAGLINE
  470. PKZIP [FILE]                                           ; PACK COMMAND LINE
  471. PKUNZIP [FILE]                                         ; UNPACK COMMAND LINE
  472.  
  473. ; ALL REMAINING LINES CONSIST OF THREE TO FIVE PARAMETERS, SEPARATED
  474. ; BY COMMAS, ALL ON ONE LINE:
  475. ;
  476. ;   NODE CONFERENCE NUMBER,
  477. ;   HOST CONFERENCE NUMBER,
  478. ;   PRIVATE ALLOWED (Y = Yes, N = No, C = Convert private to public),
  479. ;   NODE CONFERENCE TAGLINE (optional),
  480. ;   HOST CONFERENCE TAGLINE (optional)
  481.  
  482. 15, 3, Y, Node Conf 15 Tagline, Host Conf 3 Tagline
  483.  
  484.                         ------------------------
  485.  
  486. That's it.  Here's what all of these options mean to MNET:
  487.  
  488. Line 1  = NODE PACKET NAME.  (up to 8 characters, NO EXTENSION!)
  489.  
  490.               This is whatever your QWK and REP packets are named on your
  491.               end of the line.  The example shown above would mean NODE.REP
  492.               and NODE.QWK.
  493.  
  494. Line 2 = NODE SYSOP NAME.  (Your name as you are known to your users).
  495.  
  496.               MNET will convert all messages to and from "SYSOP" to your
  497.               true name before they go out the door.
  498.  
  499. Line 3 = HOST SYSOP NAME.  (The sysop's name of the HOST board).
  500.  
  501.               MNET will convert all incoming messages to and from "SYSOP"
  502.               to the name entered here.
  503.  
  504. Line 4 = NODE PACKET DIRECTORY.  (Where YOUR QWK's and REP's are stored).
  505. Line 5 = HOST PACKET DIRECTORY.  (Where "HOST"'s incoming QWK's and outgoing
  506.                                  REP's are stored on your system).
  507.  
  508. Line 6 = NODE TAGLINE. (Tagline to append to outgoing messages)
  509. Line 7 = HOST TAGLINE. (Tagline to append to incoming messages)
  510.  
  511. Line 8 = PACK COMMAND LINE.   (Archiver of your choice to create *.QWK/REP)
  512. Line 9 = UNPACK COMMAND LINE. (Archiver of your choice to extract from *.QWK)
  513.  
  514. Note the use of "[FILE]" in the pack and unpack strings.  Enter it exactly as
  515. shown (brackets and all), and MNET will replace "[FILE]" with the appropriate
  516. file name.
  517.  
  518. All remaining lines = NodeConf#, HostConf#, PrivateHandling, NodeConfTag,
  519.                           HostConfTag
  520.  
  521.    NodeConf# = The conference number as it appears on YOUR end.
  522.  
  523.    HostConf# = The conference number as it appears on HOST's end.
  524.  
  525.    PrivateHandling = "Y", "N", or "C".
  526.       Y = Yes, allow private messages - pass them thru unchanged
  527.       N = No, ignore private messages - don't even pass them thru
  528.       C = Convert private messages to public.
  529.  
  530.    NodeConfTag = Any specialized tagline you wish to append to outgoing
  531.       messages from this conference.  If you don't need separate
  532.       taglines for each conference, you can leave this blank, and MNET
  533.       will append the default node tagline defined earlier.
  534.  
  535.    HostConfTag = Any specialized tagline you wish to append to incoming
  536.       messages to this conference.  If you don't need separate taglines
  537.       for each conference, you can leave this blank, and MNET will
  538.       append the default host tagline defined earlier.
  539.  
  540.    So, as we stated earlier, "SPECIAL" conference is #15 on your end and #3
  541.    on the host end of the line.  You want to allow private msgs.  If you
  542.    don't want to define separate conference taglines, your line would
  543.    look like:
  544.  
  545.          15, 3, Y
  546.  
  547.    This is the simplest possible line configuration.  All three of these
  548.    parameters are REQUIRED.
  549.  
  550.    If you want an outgoing node conference tagline, but don't want to
  551.    define an incoming conference tagline, your line would look like:
  552.  
  553.          15, 3, Y, Node conference 15 Tagline
  554.  
  555.    If you don't want to define a node conference tagline, but do want to
  556.    define a host conference tagline:
  557.  
  558.          15, 3, Y, , Host conference 3 Tagline
  559.  
  560.    (Note the two commas before the host tag, to indicate no node tagline
  561.    being defined.)
  562.  
  563.    And, finally, if you want to define conference taglines both for node
  564.    and host:
  565.  
  566.          15, 3, Y, Node conf 15 Tagline, Host conf 3 Tagline
  567.  
  568.    Add additional lines for additional conferences.
  569.  
  570. That should be about it.  Now, for an example batch file <gasp> that
  571. would attempt to automate all of this for you.  Here's your scenario:
  572.  
  573.    1) You would physically call up your host and transfer any QWK's
  574.       and/or REP's.  We leave it up to *YOU* as for how to automate
  575.       this end for your particular comm software and commands needed
  576.       for your host, and have assumed that the batch file you use for
  577.       this is called MAILRUN.BAT.  If you aren't doing this via batch file,
  578.       you would have to perform these steps manually.
  579.  
  580.    2) Now, you will want to perform the conversion, and ready any packets
  581.       for "HOST" at the same time.  You have already created HOST.CFG for
  582.       the MNET utility, so now you will need to create a special DORINFOx.DEF
  583.       file for Mail Manager +Plus+ to operate automatically in local mode.
  584.  
  585.       For purposes of illustration:
  586.  
  587.         - We'll continue to use the name HOST MAIL.
  588.  
  589.         - We will say for the sake of argument that you have already logged
  590.           onto Mail Manager +Plus+ as "HOST MAIL", and set all of your
  591.           options the way you want them.
  592.  
  593.         - You will be using an unused node number on your system for Mail
  594.           Manager +Plus+ to do this in local mode.  (If you've ever
  595.           wondered how to log onto Mail Manager in local mode with a
  596.           different name than is shown for local mode in MAILCFG, this
  597.           is how you do it.)  Let's say you picked node "5" for this.
  598.  
  599. With all of that in mind, you would create a DORINFO5.DEF in your
  600. Mail Manager directory that looks like this:
  601.  
  602. NODE BBSNAME            ; Whatever your BBS name is.
  603. NODESYSOPFIRST          ; Your first name
  604. NODESYSOPLAST           ; Your last name
  605. COM0                    ; COM0 means local mode
  606. 19200 BAUD,N,8,1        ; Baud rate doesn't matter.
  607.  0                      ; Network type. 0=DOS, 4=DV, 6=NetBIOS
  608. HOST                    ; Your "special" first name.
  609. MAIL                    ; Your "special" last name.
  610. ANYTOWN, USA            ; Whatever City/State you want to use (doesn't matter)
  611.  2                      ; Graphics to use (0=none, 1=ascii, 2=ansi)
  612.  30                     ; Security level for this user.
  613.  180                    ; # of minutes available for local MMGR session
  614. -1                      ; Fossil active (doesn't matter... 0 or -1)
  615.  
  616. You would just copy one of your own existing DORINFOx.DEF files here,
  617. and edit it accordingly.  The comments shown above should NOT be there,
  618. of course.
  619.  
  620. Now - assuming (we have to do lots of assuming here...) that your mail
  621. manager directory is C:\MAILMGR, you would set your HOST.CFG to point to
  622. C:\MAILMGR\NODE5\ for the "node" packet directory.  Set the "host"
  623. packet directory for wherever your HOST.QWK's will be received.  Since
  624. this batch file runs MNET from the \MAILMGR directory, HOST.CFG would
  625. have to be in the \MAILMGR directory also:
  626.  
  627. Batch file time:
  628.  
  629. c:               ; Change to Mail Manager drive,
  630. cd\mailmgr       ; Change to Mail Manager directory.
  631. mailmgr 5 /o     ; Run MMGR in automatic Output mode.  Create NODE.QWK.
  632. mnet host o      ; Read HOST.CFG, and convert "NODE.QWK" to "HOST.REP".
  633. call mailrun.bat ; Batch file you have written to call your host, upload
  634.                  ;   your HOST.REP and download a new HOST.QWK.  Use CALL
  635.                  ;   so that control is returned to this batch file when
  636.                  ;   finished.  Otherwise, processing will end here.
  637. mnet host i      ; Read HOST.CFG, and convert "HOST.QWK" to "NODE.REP".
  638. mailmgr 5 /i     ; Run MMGR in automatic Input mode.  Upload NODE.QWK.
  639.  
  640. And that is it.  You may want to embellish this, to delete old QWK or REP
  641. files when they are no longer needed, etc., but these are the basic
  642. requirements.
  643.  
  644.   Whew!  That's a lot of work.  Wouldn't you rather be a host?
  645.  
  646. -----------------------------------------------------------------------------
  647.                    WHAT IS THIS "NET STATUS" STUFF, ANYWAY?
  648. -----------------------------------------------------------------------------
  649.  
  650. Most QWK-based mail networks utilize "net status" information which is added
  651. to the contents of the QWK packets produced by the host bbs.  This
  652. information tells the receiving system which conferences have been authorized
  653. for net distribution, and takes the form of additional data appended to the
  654. end of the MESSAGES.DAT file in the QWK, and/or an additional file in the QWK
  655. called NETFLAGS.DAT.  MNET will not import messages from a host packet unless
  656. it contains data which says the message's conference has been authorized for
  657. net distribution.  So if the board at the other end of the line does not
  658. produce packets which contain net status information, you have two choices on
  659. how to set this up:
  660.  
  661.   - either YOU act as the host, since your MAIL MANAGER +PLUS+ door DOES
  662.     create net status packets, or
  663.  
  664.   - you act as the node, but use separate .cfg files for the transfer in each
  665.     direction.
  666.  
  667.     For outbound messages FROM your board, you would set up HOST.CFG as
  668.     described above, and run MNET in "outbound" mode to convert from NODE.QWK
  669.     to HOST.REP (command MNET HOST O).
  670.  
  671.     For inbound messages TO your board, you would set up a separate NODE.CFG
  672.     file, and again run MNET in "outbound" mode to convert from HOST.QWK to
  673.     NODE.REP (command MNET NODE O).  When setting up to do this, it is
  674.     probably easiest to imagine that you were the sysop of the OTHER board,
  675.     and you were configuring to process outbound messages to a host.  Don't
  676.     forget to swap the sysop names, taglines, and most importantly, reverse
  677.     the order of the conference numbers ("15, 3, Y" in HOST.CFG becomes "3,
  678.     15, Y" in NODE.CFG).
  679.  
  680. ------------------------------------------------------------------------------
  681.                             FINAL THOUGHTS
  682. ------------------------------------------------------------------------------
  683.  
  684.        We know these docs are a bit on the rough side, but we THINK you'll
  685.        find everything you need here.
  686.  
  687.        WE REALLY HOPE THAT THIS MAKES SOME TYPE OF SENSE!!!!!! <g>
  688.  
  689.        Any suggestions for improving this document will be GRATEFULLY
  690.        received.
  691.  
  692.                Best,
  693.  
  694.                   Doug Wilson
  695.                   Makai Software
  696.  
  697. P.S.  --- Acknowledgements ---
  698.  
  699.     The addition of "net status" capability to Mail Manager has been one of
  700.     the MOST requested featured since day 1.  Unfortunately, for a long time,
  701.     nobody was able to provide any information on what this entailed.  Many
  702.     thanks go out to Marion Royal of The Royal Flush RBBS, who took it upon
  703.     himself to bird dog this information and provide it to us here at Makai
  704.     Software.  Thanks, Marion, "this Bud's for you".  <grin>
  705.