geoff@desint.UUCP (06/14/87)
I just finished skipping over the fourth or fifth comp.soources.misc
posting from someone who thought their judgement justified posting a
childish opinion in a group that was supposed to be for sources. So much
for automatic archiving systems.
It used to be that we could count on peoples' good sense to keep them from
posting in moderated groups, even though it's been obvious for years that
it was possible to forge a posting (see, for example, the great April Fools'
posting in mod.announce this year). Apparently, as the net expands and
the lower life forms (:-) join in, this system will no longer work.
Although I am of mixed feelings regarding the net.sources/comp.sources.misc
controversy, in general I like the moderation system and don't want it
to break down because of an irresponsible few.
I'd like to suggest a new, password-based form of moderation approval. I
envision a backwards-compatible system based on encryption. I'm not a
real crypto whiz, so I'm not sure of the best method, but my thought
is to make the "Approved: " line into a message-ID-based password which
would be compared with a list of legal moderators from a /usr/lib/news file.
Ideally, the moderator would be specified in the newgroup message and checked
by checkgroups. If a lot of the backbone sites ran software that rejected
moderated articles with improper passwords, then at least they would be
limited to a small part of the net.
All you knee-jerk types out there please take note that this is *not* a
call for net.fascism, nor for further moderation of unmoderated groups.
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoffwoods@hao.UUCP (06/14/87)
In article <687@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >in general I like the moderation system and don't want it >to break down because of an irresponsible few. Neither do we, and thanks for coming up with a suggestion. However.... >I'd like to suggest a new, password-based form of moderation approval. A nice idea, really, but in practice this will be very difficult to implement and can also probably be gotten around (albeit with a bit more difficulty than the current method). >is to make the "Approved: " line into a message-ID-based password which >would be compared with a list of legal moderators from a /usr/lib/news file. This is the bad part of your idea. The reason that it is bad is that it requires system administrators at EVERY NET SITE to keep that list of moderators up to date. In the past, they did not do so, which is why we decided to change the way moderated groups work in 2.11 (in 2.11, moderated group postings are mailed to the nearest backbone site!name-of-group (with dots changed to dashes to keep sendmail happy). Then, only the backbone sites need to keep their moderators list up to date. It might be possible to implement the checking only at the backbone sites, but this then requires the backbone sites to run a slightly different version of the news software than everyone else does. I think that might cause more problems than it solves. It is becoming increasingly clear that the only solution to this problem, which only seems to be occurring in one group, is to make comp.sources.misc unmoderated again. This will happen soon, so you can all put your flames away now. Speaking of flames, I'd like to point out that people out there who insult us and flame us in public make it MUCH harder to admit when a mistake has been made than it would otherwise be. Please think about that the next time you disagree with a decision made by the backbone. This doesn't mean that you shouldn't express your disagreement, but at least try to do it in a civilized manner, and stop accusing us of being "dictators", "power-hungry" or of creating/deleting groups based on our own personal preferences. None of us get paid for any of the work we do to support USENET except by our employers, who are in turn generous enough to donate money, disk space, peripheral devices, CPU cycles and some of our time to the effort. Since they pay us, it is THEIR interests that we primarily look out for. We also do things that we feel will benefit the net as a whole. Sometimes we are wrong. It appears that trying to keep non-source postings out of the source group by moderating it was one of those times. If comp.sources.misc does indeed go unmoderated, which now appears almost certain after our meeting at USENIX this last week, then we will simply have to put up with non-source postings there. Other than moderation, there isn't any way to keep them out, and even that has failed, so I suggest that if you MUST flame someone who does put non-source postings there, do it by mail, because your flame is in turn another non-source posting. --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.ucar.edu
dca@kesmai.COM (David C. Albrecht) (06/17/87)
In article <687@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) writes: > I just finished skipping over the fourth or fifth comp.soources.misc > posting from someone who thought their judgement justified posting a > childish opinion in a group that was supposed to be for sources. So much > for automatic archiving systems. > Any form of password scheme is unlikely to work because the user has access to the received news files and can simply extract it. Only if the posting programs prevent him from entering the appropriate line would you have marginal success. I think probably a better idea is to have a list of valid moderators somewhere and their base machines. Check the transmission route of submissions on moderated groups and block those that aren't originating from the right machine. Not foolproof, but it would be closer to doing the job with a minimum disturbance in the force. There is validity on both sides of this net.sources vs. comp.sources argument but despite the tendency for the adolescent to resort to anarchy I think that this will hardly be constructive in the long run. This net is based on cooperation and arousing antagonism will only cause more restrictive administration. I think that getting rid of net.sources was a bad idea. The dependence on a single moderator who can get sick, not have time, be switching jobs, be too picky about what goes where, makes sources throughput a major problem. It would have been much better to upgrade the posting programs to make it more difficult to post non-sources to net.sources. They ('vnews...') could disallow followups to sources groups and postnews could ask 20 questions when posting to sources groups: 'Is this source code?' (If not yes give the usual this group is for sources only use .d for discussion ...) 'What language?' 'What machines does it run on?' 'OS?' 'You get the idea' And maybe even get some useful information in the process. My two cents worth. David Albrecht
allbery@ncoast.UUCP (Brandon Allbery) (06/22/87)
As quoted from <131@kesmai.COM> by dca@kesmai.COM (David C. Albrecht): +--------------- | I think that getting rid of net.sources was a bad idea. The dependence | on a single moderator who can get sick, not have time, be switching jobs, | be too picky about what goes where, makes sources throughput a major problem. +--------------- The "pickiness" was part of an experiment (heck, comp.sources.misc is an experiment). I have since ended it; comp.sources.unix is too unreliable for me to try to bounce sources in that direction. (That's twice in the past six months that it has disappeared, folks!) Ncoast has two feeds that can be used to send things out at present, and three to receive them (hal and necntc are incoming/outgoing, hoptoad is incoming only); soon that may be a third in/out and possibly an alternative site if ncoast should become unavailable for some reason. I am also arranging for other trusted users on ncoast to handle comp.sources.misc should it become necessary; most of it is automated due to the loose requirements. (I consider it unlikely that I would become unavailable, but only a fool would make plans under that assumption.) Also, if it were absolutely necessary I could make the submissions address a "loopback" into the net, which would get stuff out at the expense of not removing non-source postings, were some{body,machine} to become unavailable for an extended period of time. I don't think anyone has to worry about throughput. If comp.sources.misc were a fully moderated newsgroup then there would be cause for worry, but as it is there are too many alternate arrangements possible for it to be a problem. ++Brandon -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
greg@xios.XIOS.UUCP (Greg Franks) (06/30/87)
In article <131@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: >It would have been much better to upgrade the posting programs to make it >more difficult to post non-sources to net.sources. They ('vnews...') >could disallow followups to sources groups and postnews could ask 20 >questions when posting to sources groups: How about running 'file' on the article and automagically rerouting all non-source to *.d :-)? By the way, Brandon is getting articles through. I have had source posted with about a 1.5 to 2 week turn around time - and I live at one of the far ends of the net. -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)