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