Here is my proposed solution to the problem.
 
  * When a user performs an action that may be refused by
    LISTSERV, the returning job will have a footer explaining
    "access control violations" and how one needs to subscribe to
    the list to search it, and that they can set NOMAIL if they
    like (this is written in normal user-speak, however).
 
  * I'll send a message to list owners with PUBLIC lists but
    PRIVATE notebooks, make my case, and ask them to change their
    settings.  If they do, they'll be more likely to get better
    subscribers, since people will much better know what they're
    getting into - AND it will be easier for those good
    subscribers to find the list.  If they don't, they'll miss an
    opportunity for good subscribers, and get false sub/signoff
    messages from users just taking a peek at the list.  I'm
    trying to argue why it's in the list owner's interest to make
    the change.
 
Re: "nagging" - no, I certainly didn't mean that I was going to
try to be a nuissance.  However, my guess is that some people
will find my emailed suggestion to make their notebooks private a
"nag," and be annoyed that I'm prying into their business.
However, Eric's point about LSTOWN-L reaching a very small
portion of list owners is a good one.  I plan to take whatever
consensus is reached here and let the other list owners out there
know about it (that'll be part of my argument).
 
I want to quote this message, because I think it probably
reflects the majority of cases: "(2a) - list-owners who
mistakenly believe that, because their list is public, and have
not explicitly specified any restriction on their notebooks, that
therefore their archives are public (instead of the default of
private)."  I don't run a LISTSERV, so I may be wrong, but I
_think_ that "notebooks={blank}" in the list header means that it
is private, and that "notebooks=PUBLIC" must be explicitely
written in there to make a notebook public.  Right?
 
You should all know and be reassured that this LISTSERV gui has
been developed with great help from L-Soft's Eric Thomas and Jim
Jones.  It has been Logika's intention from the very beginning to
involve users in all aspects of design, and to work closely with
L-Soft throughout.  Currently, there is no public list devoted to
this product.  EARN runs a private list, and they have been
giving us great feedback and ideas.  When the product ships, a
list will be created, and I'll announce it here.  I'll also
announce the product and varied information about it - cheap plug
:-)
 
As stated before, the LISTSERV gui will be shipping in July for
windows.  The cross-platform version will ship in early fall
(sept-oct).  Pricing and machine requirements are available by
writing [log in to unmask]  Evaluation copies will be available at
a discounted price, and there will also be promotional copies
available.
 
A few responses inquired how our software works with email: does
it read incoming mail, does it sort mail by LISTSERV groups, etc.
The answer is that our software provides outbound mailing only.
It does not read your mail, sift through it, or provide you with
mechanism to read it.  There were privacy and security issues,
worries about mucking with people's email, and implementation
problems, such as how to read mail from Window's myriad
incompatible packages.
 
Instead, we can send email via SMTP if the user has TCP/IP on
their machine, or we can use VIM/MAPI compatible windows email
packages (ie: we don't require an internet connection). Thus, our
software cannot be used to read incoming LISTSERV mail, nor can
it do things such as CONFIRM subscriptions automatically, etc.
We believe that people are usually attached to their particular
email program, and we didn't have a compelling reason to make
them use yet another.  However, we will be offering a Lotus notes
database which can neatly organize incoming LISTSERV mail into
groups and message threads.
 
Someone asked about features for list owners.  The first version
will focus on the needs of end-users.  We have plans for a list
administrators version, with features for smart handling of
bounces, etc, but have not started working it.  It probably makes
more sense to wait until LISTSERV can talk directly to a client
(a la archie, or ftp) so that we can put some real power into it.
 
John Buckman
[log in to unmask]