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
|