SEA Technical Memorandum #0305, Adding GroupMail to a Bink/Confmail System
Contributed by: Jack Decker
Last updated: March 7, 1989
Copyright 1989 by System Enhancement Associates, Inc.



             Adding GroupMail to a Binkleyterm/Confmail System


This document is an attempt to give you some solid information on how to 
implement GroupMail on a system that is already successfully running 
BinkleyTerm and confmail.  

This information is going to be presented more or less in "cookbook" 
format.  I am going to make a few assumptions to start with... that you are 
not a "top star" for any conference, that you're not going to feed 
GroupMail conferences to any non-MSDOS systems that can't run the GroupMail 
software, and that you're not going to try and convert any GroupMail 
conference to Echomail or vise-versa.  If any of these assumptions don't 
apply to you, read on anyway, I'll cover one of the exceptions later, and 
the rest of the information will still be useful to you.  

This is NOT a substitute for the GroupMail documentation.  Read it, too!  
Also, please count on this information containing at least one glaring 
error and at least a couple of things that could have been done more easily 
in some other way.  I don't claim to be perfect.  But I would like to know 
of any errors that you do find.  

Here are the changes you will need to make to your system: 

 1) CONFIG.SYS - Group requires some new environment variables to be set.  
    If you haven't already done so, you can reserve extra space for 
    environment variables by inserting the following line into your 
    CONFIG.SYS file: 

         shell=command.com /p /e:512 

 2) AUTOEXEC.BAT - Here is where you add a new line to set a new 
    environment variable that will be used by GroupMail: 

         SET SEADOG=C:\OPUS 

The SEADOG variable should point to the directory that you normally run 
BinkleyTerm from.  

 3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc.  Here are 
    the changes you need to make: 

    a) If you test for the existence of mail bundles in your net files area 
       before running ConfMail Import, either delete these tests (you don't 
       really need them anyway) or add tests for the GroupMail bundles you 
       expect to receive.  GroupMail bundles are named with the area name 
       (up to eight characters) plus an unpredictable three-character 
       extension.  So, for example, if you are expecting to receive 
       GroupMail bundles for the COOKING area, you could test for files 
       named COOKING.* (or COOKING.???) in your net files area.  I again 
       emphasize that such tests are normally not necessary, but some 
       people like to use them to shave a few seconds off of batch file 
       processing time.  

    b) your line that calls ConfMail Import should *NOT* include the -M 
       option, but *SHOULD* include the -K option.  I use the following 
       line: 

            confmail import areas.bbs -K -N -F confmail.out 

       Now a bit of explanation... if you really want to use the -M option, 
       you can probably do so as long as you are not converting any 
       GroupMail bundles to echomail prior to passing them downstream.  I 
       suggest removing the -M option now (if you have been using it) 
       because sooner or later you may wish to convert a GroupMail 
       conference to echomail, and it won't work if -M is set.  

       The -K option will automatically kill all the null file attach 
       messages that your GroupMail feed generates.  If you don't mind 
       skipping through all the null file attach messages when you read 
       your netmail (you WILL mind eventually), leave out the -K.  

    c) You should place the following line immediately AFTER your call to 
       ConfMail Import, BEFORE you do anything else: 

            GROUP IN /L 

       This does two things... first, it unpacks any GroupMail bundles you 
       may have received, and second, it scans your netmail area for any 
       GroupMail messages that need to be readdressed to your uplink.  That 
       is why it needs to be run AFTER ConfMail Import... if you run it 
       BEFORE ConfMail Import, any messages you've received from your 
       downstream nodes may not get properly forwarded to the Top Star via 
       your GroupMail feeds.  And you need to run Group In BEFORE running 
       ReMapper, oMMM, or any other program that may change the headers of 
       those messages.  So play it safe, and run Group In right AFTER 
       ConfMail Import.  

       By the way, the /L tells GROUP to relink the message threads.  It 
       does basically the same thing for GroupMail conferences that 
       ReplyLnk (or ConfMail Maint in older versions of ConfMail) does for 
       your echomail conferences.  

    d) Just prior to calling oMMM, you should place the following line: 

            GROUP OUT 

       This will check all your GroupMail areas for new messages, and send 
       out anything you have waiting.  

    Now, if you have read the GroupMail documentation, you may be a little 
    confused at this point, since the docs tell you to run GROUP on certain 
    schedules (GROUP OUT in the evening before your mail hours, and GROUP 
    IN in the morning after all mail has been received).  But keep in mind 
    that the folks writing the documentation are using SEADOG, which runs 
    on schedules.  You probably aren't running schedules in that way.  If 
    by chance you do run ConfMail Import only at certain specified times, 
    just do GROUP IN immediately afterward.  But, if like most of us, you 
    run ConfMail Import every time mail is received, you should run GROUP 
    IN immediately afterward.  If you then do a ConfMail Export, you should 
    run GROUP OUT prior to calling oMMM.  GROUP runs very fast (faster than 
    ConfMail when tossing messages, in my opinion) so you needn't worry 
    about it consuming an inordinate amount of time while executing on your 
    system.  

 4) AREAS.BBS - There are two important considerations here.  First, if you 
    are using a BAD_MSGS area, GET RID OF IT NOW!!!!  This is *EXTREMELY* 
    important.  If you don't do this, some or all of the GroupMail messages 
    originating on your system (or on systems that you feed) will be tossed 
    to the BAD_MSGS area by ConfMail, and will never leave your system.  
    Second, make sure you don't have any echo area names that duplicate 
    GroupMail areas, for the same reason (ConfMail will toss any messages 
    that are supposed to go to your uplinks to those areas instead.  The 
    exception to this is if you're converting a GroupMail conference to 
    Echomail, but right now we're assuming you aren't doing that, 
    remember?).  

    Of course, someone will say that if you are VERY careful about how you 
    write your batch file, you can get around these problems.  That may be 
    true (although I have my doubts!), but in any event I don't feel like 
    giving a short course in writing batch files here.  I'm simply taking 
    the safe road by saying "don't do these things." 

 5) CONFIG.DOG - You need one of these, even though the GroupMail 
    documentation says that a Mail.Sys file will do (it won't, at least not 
    with GroupMail versions through 2.04).  Fortunately, a Config.Dog file 
    is simple to make... you just use any text editor.  Mine looks like 
    this: 

         name Jack Decker
         node 1:154/8
         aka 77:1011/8
         aka 8:70/8
         mail C:\MSG\NET
         files C:\FILE\NET

    "Name" is the name of the Sysop, "Node" is your primary address, "Aka" 
    lines contain any other addresses you use (in the same net or in other 
    nets), "Mail" is the path to your netmail area, and "Files" is the path 
    to your incoming net files area (which is what GROUP can't find if you 
    only have a Mail.Sys file).  

 6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your system).  Be 
    sure to put a poll statement in for each system you pick up GroupMail 
    from (unless you are using some other method for doing polls, or your 
    feed is calling you).  

 7) DELIVER.GRP - You need this file if you are feeding GroupMail to any 
    other BinkleyTerm systems, or any other system that can't generate File 
    Update Requests.  Note that future versions of BinkleyTerm will 
    supposedly include the capability to do File Update Requests, but 
    present versions of Binkley do not.  DELIVER.GRP is simply a list of 
    systems that are to receive any given GroupMail area from you.  I quote 
    from SEA Technical Memorandum #0302: 

    "The GroupMail conferencing system is, by design, a pickup system 
    instead of a delivery system.  If at all possible, it should be used as 
    such, because that is how GroupMail avoids the bulk of the technical 
    problems with echomail.  

    "However, at least one popular network mailer is not capable of 
    properly negotiating a file update request, which is the mechanism by 
    which GroupMail functions.  Until that can be rectified, GROUP requires 
    some sort of delivery mechanism in order to link such systems into 
    GroupMail.  

    "If a file named 'DELIVER.GRP' is placed in the SEAdog directory, then 
    GROUP 2.03 will use it as a delivery list, and create file attach 
    messages for each new GroupMail archive as it is posted by GROUP PACK 
    (for a top star) or GROUP IN (by a middle star).  The format of the 
    DELIVER.GRP file will look very familiar to those acquainted with 
    echomail.  

    "The DELIVER.GRP file is a normal ASCII text file.  Each line begins 
    with the name of a group conference, with the remainder of the line 
    being a list of network addresses to which it should be delivered.  A 
    conference may be listed more than once, in which case it is addative.  

    "For example, a possible DELIVER.GRP file might be: 

        BLATZ 520/1015 107/528
        GNORF 107/528


    "By adding support of a delivery mechanism, we open the door to all the 
    troubles echomail is heir to.  However, the door is open only a tiny 
    crack at this time.  The single biggest problem with a delivery system 
    is that of faulty topologies that cause duplicate messages.  This is 
    largely avoided from the start because all duplicate GroupMail archives 
    have the same name.  The remaining opportunities for duplicate messages 
    to be generated are avoided because GROUP 2.03 refrains from unpacking 
    any GroupMail archive that is older than the 'update marker' for that 
    conference." 

    [end quote] 

    Two notes about DELIVER.GRP... first, you DON'T put the node number of 
    YOUR feed in it, only of those systems that are fed BY YOU (this 
    differs from an AREAS.BBS file, which must contain the node number of 
    your feed and of those system that you feed).  Second, if you aren't 
    feeding a particular GroupMail conference to anyone else, it doesn't 
    have to be listed at all.  

 8) OKFILE.LST - Your "requestable files" list for BinkleyTerm.  Add the 
    following line: 

         C:\GRPHOLD\*.* 

    (or whatever path you specified for your GRPHOLD directory in the SET 
    command in AUTOEXEC.BAT).  I'm assuming that you already have such a 
    list.  If not, you'll also need to uncomment the following line in your 
    Binkley.Cfg file: 

         Okfile     c:\opus\okfile.lst 

    (of course you should change the path if the subdirectory you're 
    running Binkley out of is not called OPUS).  

    This should allow other systems to obtain any GroupMail areas that you 
    carry on your system.  

 9) \GROUP\ORIGIN - A file called "Origin" that sits in your GROUP 
    directory.  For starters, this can be the same as the first line of 
    your "AREAS.BBS" file up to the exclamation point.  You can use custom 
    origin lines for individual conferences by creating a file called 
    "Origin" in individual Group areas, in the same manner in which you 
    create custom origin lines for individual message areas using ConfMail.  
    See the GroupMail documentation for more information.  

10) System files.  You'll need to provide your BBS program and/or message 
    reader/editor with the paths to your GroupMail areas.  Ditto with your 
    message cleanup routine (that calls RENUM or some other message 
    renumberer).  This will vary from system to system, but should not be 
    too difficult to figure out.  

11) GROUP.EXE - The central program of GroupMail, and the one that does 
    most of the work for you.  If you've set up echomail conferences in the 
    past, you'll appreciate the ease with which GROUP takes care of many of 
    the little details of adding or deleting conferences for you.  For 
    example, it creates all necessary subdirectories for you, creates and 
    maintains the AREAS.DOG file for you, etc.  



Now, if you are not a Top Star, you can basically get by using only three 
basic GroupMail commands (quoted from the GroupMail documentation): 

GROUP ADD <conference> <description> ;<uplink> 

     This is the command you use to add a new conference.  Suppose, for 
     example, that you would like to get the BLATZ conference from 520/542.  
     You would type: 

         GROUP ADD BLATZ Gzorniblatz forum ;520/542 

     GROUP will take care of the details, like creating the proper 
     directories and updating your AREAS.DOG file.  If you run a BBS and 
     you want the conference to be available on your system you will need 
     to add the directory to your message areas.  The message directory 
     that GROUP creates will (by default, see later) be a subdirectory of 
     the GROUP subdirectory, or in this case it would be "GROUP\BLATZ".  

     If you are running a mailer other than SEAdog, then you may need to 
     add the directory to your areas list also.  In any event, DO NOT 
     delete the AREAS.DOG file, as that is used by GROUP to keep track of 
     your conferences.  

     If you want to import GroupMail into a BBS that uses a different 
     message base format, you'll need to do a bit more work.  See the 
     section on this below.  

[You might imply from the above that you should add GroupMail areas to your 
AREAS.BBS file.  That is NOT the case, however, unless you are converting a 
GroupMail conference to echomail, which we're assuming that you're not 
doing right now!] 


GROUP DEL <conference> . . .  

     This is used to remove one or more conferences.  For example, if you 
     wanted to remove the BLATZ conference you would type: 

         GROUP DEL BLATZ 

     If you wanted to remove both the BLATZ conference and the GNORF 
     conference, you would type: 

         GROUP DEL BLATZ GNORF 

     Again, GROUP will take care of the housekeeping details, such as 
     deleting any messages and removing the subdirectory.  



GROUP EDIT <conference> <description> ;<uplink> 

     This is used to change an existing conference.  For example, if you 
     wanted to change your uplink on the BLATZ conference to 440/1, you 
     would type: 

         GROUP EDIT BLATZ Gzorniblatz forum ;440/1 

     As always, GROUP takes care of any housekeeping details.  


[end of quoted material] 

Since Binkley can't do File Update Requests, you do NOT use the GROUP ASK 
command.  We've already covered the use of GROUP IN and GROUP OUT in the 
batch file.  You don't use GROUP PACK unless you're a top star for a 
conference.  

There are several option switches that you can use to modify how GROUP 
works, and most are described in the GROUP documentation.  The one that you 
will probably want to use is the /R switch: 

/R<x>  Retention;  This tells GROUP that any GroupMail archives that you 
       are holding (if you are a star) should be deleted after <x> days 
       (default is 30 days).  For example, you would use "/R5" to retain 
       archives for five days.  

For example, if you wanted to add the BLATZ conference with yourself as a 
middle star retaining GroupMail archives for three days, you would type: 

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3 

Also, because Binkley cannot generate File Update Requests, you'll want to 
use the /X switch when adding new conferences, as described in SEA 
Technical Memorandum #0302: 


/X   In ADD or EDIT only.  This switch indicates that the designated 
     conference should not be requested.  The GROUP ASK command will not 
     generate an update request for any conference that carries this 
     switch.  This is intended mainly for use with conferences which are 
     delivered or which are obtained via a GROUP GET (see above).  

The bottom line is that when you add a new GroupMail conference, your GROUP 
ADD line will most likely appear something like this: 

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7 

(assuming you want to retain conference archives for seven days in this 
case).  

If you are a leaf node (that is, you don't hold a particular conference for 
anyone else to pick up), omit the asterisk and the /r7 in the above line.  
In this case, the GroupMail bundle will be deleted after it has been 
tossed.  The command line would then look like this: 

    GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X 

When you use the GROUP EDIT command, it should be in exactly the same 
format as the GROUP ADD command.  In other words, if you are adding 
switches, you must also re-enter all of the original switches.  The word 
EDIT simply tells Group that you are modifying the particulars of an 
existing conference, rather than creating a new one.  


EXCEPTIONS AND SPECIAL CIRCUMSTANCES 

The GroupMail manual tells you how to import GroupMail into non-compatible 
message base formats (such as QuickBBS or TBBS).  In this case you use the 
/N flag in your GROUP ADD statement.  Since most such systems don't use 
ConfMail, this type of setup is a bit beyond our discussion.  I would only 
caution you to be careful about the sequence in which you run you mail 
import routine and GROUP IN.  You may have to run your import routine 
twice... once to toss incoming mail, then GROUP IN to toss incoming 
GroupMail bundles to the netmail area (and to readdress any GroupMail 
messages destined for your uplinks), and once more to import any GroupMail 
messages tossed to your netmail area by GROUP.  This is just guessing on my 
part, since I don't have any actual experience with such systems.  

However, a similar technique is used to convert GroupMail to Echomail.  You 
might want to do this if you are receiving a GroupMail conference and want 
to pass it on to another system that cannot run the GroupMail software.  

Now, I would suggest that you DON'T do this unless absolutely necessary.  
If it's just a case of one of the nodes you feed objecting to having to put 
up the GroupMail software (although they are perfectly capable of doing 
so), I would invite them to seek a feed elsewhere.  Converting a conference 
from GroupMail to Echomail introduces several possible headaches, not the 
least of which is that you could be the source of duplicate messages 
entering the conference.  

On the other hand, it's not something that's terribly difficult to do if 
you have to.  SEA Technical Memorandum #0303 describes the process, but I 
will give a couple of examples specifically for BinkleyTerm/ConfMail users.  

The assumption here is that you are a middle star that is receiving the 
conference in question as GroupMail, and feeding it to some other nodes as 
GroupMail while feeding still other nodes as Echomail.  

Your GROUP ADD line would be the same as usual, with the addition of the /N 
switch.  For example: 

    GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7 

If you are not sending the conference to any other nodes AS GROUPMAIL, you 
can omit the asterisk and the "/r7" switch.  

Next, you ADD this area to your AREAS.BBS file, just like you would any 
normal echo.  On your system, you will treat this conference as an echomail 
area rather than a GroupMail area.  The /N option that you used in your 
GROUP ADD statement causes GROUP to add an "AREA:" field and a "SEEN-BY:" 
field listing the address of the uplink to any conference that you're 
converting to echomail.  

In your batch file, you will probably want to run ConfMail Import (WITH the 
-M option), THEN Group In, and THEN a second run of ConfMail Import 
(WITHOUT the -M option).  This will make sure that any GroupMail received 
from your downstream nodes gets properly readdressed to your uplinks, and 
that any Group conferences that GroupMail tosses to your netmail area get 
properly tossed (by ConfMail) to the Echomail area you've set up for that 
conference.  For example: 

     confmail import areas.bbs -M -N -F confmail.out
     group in /L
     confmail import areas.bbs -K -N -F confmail.out

The only other items you have to worry about are how the area is defined in 
your DELIVER.GRP and AREAS.BBS files.  As usual, your DELIVER.GRP file 
should contain ONLY a list of nodes receiving the conference from you AS 
GROUPMAIL.  Your AREAS.BBS entry for the conference in question should 
contain a list of the nodes receiving the conference from you AS ECHOMAIL, 
plus YOUR FEED of the conference.  The reason for including your feed is so 
that any messages entered on your system, or sent to you by your downstream 
links, will be exported to your upstream feed.  

You may wonder what will happen to an echomail message sent upstream in 
such a manner to your GroupMail feed.  If he is running that area strictly 
as GroupMail, the message will be tossed into his netmail area (so long as 
he does not have a BAD_MSGS area... this is why you CANNOT use a BAD_MSGS 
area with GroupMail!!!), where (hopefully) GROUP IN will find it and 
readdress it to his uplink, and so on.  If he is also operating the area as 
both echomail and GroupMail, the message will get tossed into the echo area 
on his system, and then exported to his upstream feed, and so on.  

Anyway, that's all there is to it... BUT again I ask, "do you REALLY want 
to convert echomail to GroupMail?"  If you are only feeding one or two 
nodes that cannot accept GroupMail, there may be a better way: 


SENDING GROUPMAIL TO NON-MSDOS SYSTEMS

The following information should be considered HIGHLY experimental.  If it 
works for you, GREAT!  If it doesn't, well, you can always convert your 
GroupMail conferences to echomail.  

Let's say that you're feeding a point system that's running on a Commodore 
Amiga (coincidentally, this is what Steve Palm, a point operator off of my 
system is using).  He has a version of ConfMail and BinkleyTerm that's been 
ported to the Amiga, as well as a message reader/editor, but there is no 
way he can run the GroupMail software.  

But, he is a leaf node.  That means he doesn't have to worry about 
forwarding the conference to anyone else.  All he needs to be able to do is 
to read the messages he receives, and send replies.  

We already know (from the above discussion) that if he creates an echo area 
with the same name as a GroupMail area on my system, and puts my node in 
his AREAS.BBS list, that any messages he enters in that area will be 
exported to my system, where GROUP IN will find them and readdress them to 
my feed for the conference.  So as long as he can send me messages with the 
proper AREA tag (which will be automatically affixed when ConfMail exports 
the message from the echo area he's created), he will be able to enter 
messages in a GroupMail conference.  So, if he can figure out some way to 
process an incoming GroupMail bundle (so that he can read incoming 
messages), I can just put his node in my DELIVER.GRP file and treat him 
like any other GroupMail delivery point (which means I don't HAVE to 
convert the GroupMail conference to Echomail!) 

The question is, can he unpack a GroupMail bundle?  Well, it turns out that 
there IS a way this can be done.  Once you extract a GroupMail packet from 
its archive, the extracted mail packet has roughly the same format as an 
Echomail packet, except that it's addressed to -1/0.  At least, it's close 
enough that ConfMail will unpack and toss it if it thinks it's running on 
node -1/0 

So, in his CONFIG.DOG file, Steve inserts the address -1/0 as an AKA 
address.  Then, in his batch file, he has to put a command to look for and 
unARC any GroupMail bundles he might receive.  For example, if he's getting 
COOKING and SHORTWAV from me, he'd put in the following lines (note these 
are MS-DOS batch file lines for illustrative purposes only, not what Steve 
is actually using on his Amiga): 

     ARCE \FILE\NET\COOKING.*
     DEL \FILE\NET\COOKING.*
     ARCE \FILE\NET\SHORTWAV.*
     DEL \FILE\NET\SHORTWAV.*
     CONFMAIL IMPORT AREAS.BBS -N -A ARCE 

ConfMail will find the bundles (addressed to -1/0, but the AKA takes care 
of that) and unpack them.  Next... and this is important... he must do a 
CONFMAIL EXPORT using an alternate AREAS.BBS format file that contains the 
following: 

     Origin Line ! Sysop Name
     \MSG\COOKING COOKING -1/0
     \MSG\SHORTWAV SHORTWAV -1/0

Why are we exporting to -1/0?  Well, since GroupMail uses that address, I 
thought I would, too... actually, we could export to ANY phony node, but 
the idea is to make ConfMail do an export operation on the newly-imported 
GroupMail messages.  Why?  Well, keep in mind that GroupMail messages don't 
have an origin or SEEN-BY lines.  Thus, if we simply allow them to be 
rescanned in the normal manner, we've created an instant dupe loop, since 
they will all get sent back to the source.  So, we do a "dummy" export 
operation in order to reset the "high water mark" past the last new message 
that we have just received in the area.  This may create an unwanted ".OUT" 
file for -1/0, but we can always delete that as the next operation in the 
batch file 

So, the complete batch file segment would look something like this: 

     ARCE \FILE\NET\COOKING.*
     DEL \FILE\NET\COOKING.*
     ARCE \FILE\NET\SHORTWAV.*
     DEL \FILE\NET\SHORTWAV.*
     CONFMAIL IMPORT AREAS.BBS -N -A ARCE
     CONFMAIL EXPORT ALTAREAS.BBS {options}
     DEL \OUTBOUND\FFFF0000.OUT

where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy -1/0 net/node 
numbers, and FFFF0000.OUT is the name of the mail packet (for -1/0) created 
by the dummy export operation.  

Of course, when messages are entered using the message reader/editor, we 
have to run ConfMail Export using the "real" AREAS.BBS file that contains 
the same entries, but with the real net/node numbers for the GroupMail 
feed(s) from which the conferences are received: 

     Origin Line ! Sysop Name
     \MSG\COOKING COOKING 154/8
     \MSG\SHORTWAV SHORTWAV 154/8

Now, all of the above will work BUT there is one MAJOR problem.  It turns 
out that while each GroupMail bundle has a unique filename, two or more 
GroupMail bundles for the same conference can contain .PKT files that have 
exactly the SAME names.  Thus, there is a very good chance that the above 
batch file segment would fail whenever more than one mail bundle is 
received for the SAME GroupMail area in the same transmission (it would 
most likely stop and ask the user whether to overwrite the the .PKT file 
from the first mail bundle with the .PKT file from the second... or on some 
systems, it might just go ahead and overwrite the file without asking, an 
even less desirable situation!).  On an MSDOS machine, you could use a FOR-
DO loop in the batch file to unarc each GroupMail bundle and then have 
ConfMail toss (import) the contents of that mail bundle before unarcing and 
tossing the next GroupMail bundle (but then, on an MSDOS machine you could 
just run the GroupMail software).  There are probably ways to accomplish 
the same thing on other systems, but the actual method would depend on the 
commands available in the batch file language, and/or the availability of 
external utilities that might aid in the process.  Or, you could just run 
the batch file manually (when an operator is present to watch and resolve 
any such conflicts that might occur)... that might be the most expiditious 
method at present for point system operators.  Note to the developers of 
GroupMail:  It would sure be nice if future versions did not create 
duplicate .PKT names within different mail bundles for the same GroupMail 
conference.  

The method I've shown for preventing the imported GroupMail messages from 
being rescanned back to the GroupMail feed is not real elegant, and begs 
for a simple utility that would either a) reset the "high water mark" (the 
number of the last message scanned by ConfMail Export) to that of the 
highest message in the area, or b) append an Origin line and SEEN-BY lines 
to any messages that don't already have them in the specified area, and 
place the net/node number of the feed for the area in all messages 
currently in that area.  Such a utility could be run every time messages 
have been tossed to the specified area, and would eliminate the need for 
the dummy ConfMail Export operation.  Yet another (better) option would be 
to forget the alternate AREAS.BBS file and the dummy ConfMail Export 
option, but instead use only the regular AREAS.BBS file with NO net/node 
number following the Group conference area names, so that messages in Group 
areas would NEVER be exported by ConfMail.  Then use a separate utility 
that would search through Group conference areas for locally-originated 
messages (messages containing the node's primary net/node number in the 
FROM field of the message header) and move those TO the netmail area, at 
the same time readdressing them to the feed for the GroupMail conference 
and flagging them as Kill/Sent.  Such a utility would be relatively easy to 
create, and would allow non-MSDOS systems to handle GroupMail in a way that 
more closely resembles the way GroupMail is supposed to operate (that is, a 
locally-entered message disappears from your BBS until such time as it 
comes back as part of a GroupMail packet).  

But, at this point, the fact that a non-MSDOS system can import and process 
GroupMail is a bit akin to the dancing bear... the wonder is not how well 
it's done, but that it can be done at all.  

I hope that these hints prove helpful to you in setting up GroupMail on 
BinkleyTerm/ConfMail and other types of systems.  Please let me know if you 
find any glaring errors in the above information, or if you can add 
anything that might simplify the process or make it more understandable.  
