On Wed, 17 Mar 1993 11:03:39 EST CS Listserv Manager said: >Sometimes the various mechanisms to stop unwanted postings are >inapproriate for a list, or a royal pain. (I have occasionally >gotten around addressing problems affecting some subscribers ability >to post to a send=PRIVATE list by setting SEND=PUBLIC. Setting such >a list back to private is not possible unless the original problem >has gone away) In case some of you haven't run into problems like this, here's what typically happens. You have a "private" list, meaning only the people on the list can submit postings, and people that are receiving mail from the list just fine, can't post. In all the times this has happened to me, I've only seen three reasons. - Some poorly configured "cluster" of politically correct workstations send out mail with a different host name depending on which seat you choose in a lab. That is, if you use workstation #1 it might go out as <[log in to unmask]> and if I use workstation #2 it might go out as <[log in to unmask]>. Of course, no matter which address you *send* to, I can read it from any workstation. So, the subscription might be <[log in to unmask]>, meaning I can only send mail from workstation #3, or even worse <[log in to unmask]> so that *no* workstation can send mail. While this is *not* a LISTSERV problem, there are workarounds available to you. If the number of workstations is small enough, you can add all the possible forms of the address to the list, and "set list nomail" for all but one of them. It's ugly, and it requires that you, as the list, owner fix a problem that you didn't create, but it works. For what it's worth, "clustered" system can act rationally. :) We have a bunch of Indigos that all send out mail with the same address. - Some routing information (which can vary each time the user sends mail) is put into the mail headers by a gateway. This happens very rarely these days, and there's not a good solution to the problem. If a limited number of routes seem possible, then the same solution used for the "cluster" mess could be employed. Otherwise the best solution is probably to set-up a second list, configured Send=Public, and make it a "peer" of the private list. The "problem" user would have to send to the public list. - A "friendly" mail system that supports full-name aliases for users is in place, and the user can somehow send mail out with his/her real login address. That is, maybe the subscription on the mailing list is <[log in to unmask]> but either all the time, or under some circumstances, I send mail as <[log in to unmask]>. If the user can't figure out how to send mail with the "nice" name all the time, then subscribe both and "nomail" one of them. My point in posting this is to show that there are options available to resolve these problems without resorting to making the list public. At least in some cases you can work around the problems. -jj