Re: how to restrict postings from a particular email
In article <v03130313b8ea0172f0a5@[192.168.123.10]>, Charlie Summers <charlie@lofcom.com> writes:
At 1:42 PM -0400 4/22/02, Tim Pierce is rumored to have typed:
This patch to rc.submit should make SmartList use the reject file to screen list postings.
Again, it seems a lot of unnecessary work, since (at least on every list I know about) if someone is consistantly sending unwanted posts, and refuses to stop after being asked to do so by the listmaster, that address is summarily unsubscribed. (And if you're determined to leave a specific address subscribed and ignore postings from them, a simple /dev/null drop in rc.local.s00 makes more sense than worrying about scoring from the reject file.)
We have found this feature useful for many reasons. Many list managers want to have something between allowing people to post whatever they want and unsubscribing them completely. For example, they may be posting lists of lightbulb jokes and chain letters, or they may be usually reasonable people who fly off the handle whenever a particular person or subject comes up, or they may be carrying on a temporary flamewar with one other person. While it may be reasonable to unsubscribe the offender, depending on the severity of the offense, some list managers prefer to leave them on the list but unable to post. I do not personally agree that a "simple" addition to rc.local.s00 makes more sense than using the reject file. There are several reasons, but one of the most compelling was that I found our list admins were already putting addresses of people they didn't want to post into the reject file, then reporting it as a bug when their posts were not rejected. They were showing me pretty clearly what the most user-friendly implementation of this feature would be. No one is required to make this change, of course, and I certainly do not expect Charlie's views to agree with mine. :-) But, since the subject of rejecting posts from individual subscribers, I am sharing the solution that we found to work to this problem.
participants (1)
-
Tim Pierce