From: Charles Lindsey (firstname.lastname@example.org)
Date: Tue Jul 14 1998 - 09:38:17 CDT
In <email@example.com> Brad Templeton <firstname.lastname@example.org> writes:
>For example, at first usenet tools were designed with a "moderators" file
>where people put in the address of every moderator. It quickly became
>impossible to change the address of a moderator, without leaving aliases
>behind at the old address.
>Later, people moved to just forwarding everything to the default at
>moderators.uu.net. Doing it the other way is not just too much work for
>the admin, it's not a flexible enough system.
Good. That problem was solved (too bad Tale's FAQ still devotes too much
verbiage to the old way :-( ). Actually, I believe it is
>Imagine, once everybody has programmed say, Dave Lawrence in as the person
>who can do a newgroup, having to change him. People would reconfigure
>slowly, slowly -- it would take years, I suspect. Not because they
>don't want to change, let's presume, but just because they don't have time,
>or aren't aware.
Yes, the net is going to have a serious problem when Dave hangs up his
keyboard, but that is inevitable. In the meantime, there is a much simpler
solution which we have adopted in uk.*. The 'newgroup' authority is
email@example.com. That identity can continue to exist indefinitely,
but its identity can be changed at the drop of a hat (this week, it just
happens to be me, because the regular guy is away).
>We're talking about authenticating:
And all the cases you cite presently have acceptable solutions.
> Who can newgroup, different people for different hierarchies
firstname.lastname@example.org, supported by pgpverify, or similar
> Who can approve -- for every moderated group
moderators.uu.net, supported by pgpmoose or similar
> Who can rmgroup, checkgroups, etc.
> Who can 3rd party cancel
I would rather there was NO central authority for this.
> Who can post a named article with an faq, topics lists, policy
> sheet, etc.
In an unmoderated group, anybody. In a moderated group, the moderator
> Who can cancel on behalf of a site
email@example.com. Cancel locks can eventually make this more secure.
>You simply can't do this by having each admin maintain their own private
>lists of these vast numbers of keys. Certificates are a good invention,
>we would be crazy not to use them.
The problem with certificates is that they presume the existence of a
Cabal or Cabals to oversee the whole thing. TINC.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: firstname.lastname@example.org Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5