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]