> 1) You don't have to screw with any of the gateway software already in place.
> The WISCVM stuff is screwey enough *without* having to worry about
> repackaging some files, maybe, if it's needed...
That's right Valdis. Agreed on this one.
 
> 2) You know beforehand who is on the list.  All I'd have to do is get LISTSERV
> to not run  lists flagged as being  in a certain class  (junk mail, off-node,
> whatever). (Hint - this is a mod request... :-)
> If all else  fails, I can always  just run those lists off  a second LISTSERV
> which would get AUTOLOGGED late at night.
Or you could have VMUTIL issue HOLD  and FREE commands for the lists at schedu-
led hours. This is not much of a problem.
 
> 3) You don't have  to worry about the  digest at the other end  making up the
> distribute list. I know for a fact that  this could get VERY hairy at the ARPA
> end, as currently the digesters mail one  copy to each person on the list. It
> would require that for DISTRIBUTE, the digester program flag all BitNet users
> and lump them for special processing. With  a mailing list, they just have to
> add the one  address to their target  table, and remove all  the .BITNET user
> addresses.  No hassle.
Sorry Val.  In my original  idea the gateway  creates the DISTRIBUTE  job. That
means the ARPA people  have nothing to do at all -- the  BITNET people get sent
to the gateway in a single BSMTP envelope as usual.
 
> 4) LISTSERV will make  a user subscribe to the appropriate  server. Just have
> the digest lists at a fair number of places, with open subscription.
This one  is irrelevant. DISTRIBUTE would  route their copy of  the mailfile to
the appropriate server, automatically.
 
> 5) With a mailing  list, control is back  in the hands of  the postmaster, as
> some sites have requested.
Yes, *but* you have only one-tenth  of the servers participating since creating
distribution lists  for ARPA digest  is a real  pain considering the  number of
lists. It also takes  up space on the LISTSERV disk, by the  way. About 5 sites
currently redistribute ARPA lists  on a total of 41 servers.  That would not be
a major reduction...
Some people,  a lot  of people,  might be willing  to take  on ARPA  redist but
might not  have the  time to create  30 lists. I'm  thinking about  the central
nodes whose CPU is (partly) dedicated to  the network but who have a very limi-
ted staff.
 
> 6) With a mailing list, we can fix it  so that MAIL can read it, and probably
> also fix the Reply-To:  to point back at the master list on  the ARPA side so
> that their reply gets put into the digest rather than floating around Bitnet.
> This is currently  a flake with the  Unix-Wizards digest, where a  lot of the
> postings arrive  seperately, because  they did not  go through  the digester.
Yeah, *but*: I keep getting complaints from  at least five people that my LIST-
SERV munges the nice, sweet  "Received:" headers that are soooooooooo important
(those people are still  a minority of course). Since I don't  see any real use
for the "Received:" tag FOR BITNET ORIGINS, except to waste space on your disk,
I don't  listen to these  people. However,  in the case  of an ARPA  address it
might help locating  the guy. Don't flame  me on this, Valdis,  better send the
flame to these people directly ;-)
 
  Another technical  point about DISTRIBUTE:  let's assume you are  node xEARN,
the central node of country X. You're receiving a 1000-lines DISTRIBUTE on your
LISTSERV for, say,  four people of your country, and  you're concerned with the
amount of resources it will eat. Basically LISTSERV eats:
 
- Spool space
- CPU time
- Network resources
 
  With DISTRIBUTE four files are sent out (or less if there is another LISTSERV
down the path) and one is received.  Without it, the files go through your node
anyway, four  are sent out, four  are received. It obviously  eats more network
resources.
 
  The spool  use is  the same  since in both  cases, four  files are  sent out.
 
  LISTSERV would  eat about 15  seconds CPU to  process the DISTRIBUTE  job. 15
wasted seconds. However your RSCS will have  received only 1 file instead of 4.
That's about 5  seconds CPU saved. So  on the average you'll have  paid 10 secs
CPU to save yourself 3000 lines input.  Note that other people will have wasted
some of their  CPU for you too. It's  like RSCS, it works both  ways. You don't
have any control over DISTRIBUTE, but you  don't have any more control on RSCS.
If RSCS was intelligent enough  to automatically 'fork' files, DISTRIBUTE would
not even be required! :-)
 
  Eric