Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!felix!dhw68k!david From: david@dhw68k.cts.com (David H. Wolfskill) Newsgroups: news.admin Subject: newgroup & rmgroup (was: Re: Cabals, Committees, Voting, ad nauseum) Summary: Beware of control newgroup changing moderation status Message-ID: <22065@dhw68k.cts.com> Date: 13 Apr 89 13:00:51 GMT References: <647@ultb.UUCP> <28784@apple.Apple.COM> Reply-To: david@dhw68k.cts.com (David H. Wolfskill) Organization: Wolfskill & Dowling residence; Anaheim, CA (USA) Lines: 24 In article <28784@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >>newgroup and rmgroup can be disallowed at each site, and reserved for >>root intervention, at compile time. >Newgroups are not generally disabled simply because that's an additive >function, not a desctructive function -- it's a lot easier to come in >and repair the damage that a "newgroup ba.wobegon" does over the >weekend than a "rmgroup comp.sys.unix.wizards" [sic] would do. Although I essentially agree with Chuq, I will also point out that "newgroup" control messages do have a rather destructive potential: that of changing the "moderation status" of a newsgroup. Granted, it (in most cases that I think of, anyway) is not as destructive as an rmgroup targeted at a newsgroup that's important to me; a bogus change in either direction can cause a lot of unpleasantness, though. The above is all the more reason news admins need to pay attention to the "Distribution:" specification for control messages that are intended for their sites. -- David H. Wolfskill uucp: ...{spsd,zardoz,felix}!dhw68k!david InterNet: david@dhw68k.cts.com