Once again, I take up my campaign for features I would like to see
included in some future version of Listserv.  I understand that they
will not be possible in 1.5m, since the goes into beta this week, but
for the future.
 
- The "Possible rejection" message needs to be enhanced.  I realize that
it will now give a reason.  That was a necessity.  I modified my Listserv
a while ago to give a number reason, which I could then look up.  It was
becoming quite impossible to figure out why on some items without it.
However, the number given in the message is totally useless.  That number
is the spool file number of the spool file as Listserv saw it.  Before it
gives it to you, it repunches it, so it has a different number.  If you are
a remote owner, it sends it over the net, so finding the number is impossible.
Even if it gives the current spool number, it arrives as mail, so Rice-Mail
(Or most mail packages) will snarf it up, losing the spool file number.
Some internal cross reference should be used.
 
 - Life as a remote owner is tough.  There is now easy method for
finding the last time something went through the list, easpecially
if no notebooks are maintained.  Some type of last activity through a list
should be maintained.  Either mail only or mail or files.  When trying
to track down why a user on a remote peer isn't receiving mail,  I don't want
to drag the remote postmaster into solving problems anymore than I have to.
If I can see that the list hasn't had activity in a while, I can spend time
in other areas, without trying to contact the postmaster, waiting for a
response, and then tracking it down.
 
 - The should be sometype of FUI to owners saying that list such and such
is still locked or still held.  With network delays, it is sometimes
difficult to notice such problems.  The should also be a way for an
owner to query the locked and held status, without HOLDing or FREEing,
or GETing the list.
 
 - Due to the number of listservs, and the peering and Distribute(DIST2)
involved and the effect they can have on each other, neighboring listservs
should talk to each other about certain internal files that are not at the
same level, such as BITEARN NODES, PEERS NAMES, etc.  Internal versions
should be used rather than file dates.  This means adding internal
versions to some files.  Incompatibilies should be noted to the respective
postmasters, and maybe even the LCOORDs.  A simple method would be to send
a standardize file to the nearest Listserv neighbor, who would respond.
This could be done once a week, like expirations.  Some listservs would get
more checking, but everyone would be checked by atleast someone.
 
  HArry