'''FAQ sull'amministrazione delle gerarchie Usenet'''

'''di Russ Allbery <rra@stanford.edu>'''

'''Ultima modifica 1 febbraio 2003 (revisione 1.5)'''

[''Liberamente tradotto da MarinaM dal testo originale in inglese reperibile presso [http://www.eyrie.org/~eagle/faqs/usenet-hier.html] con note esplicative di Self:CarloFusco.'']

----

Questa FAQ tenta di offrire aiuto agli amministratori delle gerarchie Usenet, ovvero coloro che cercano di gestire le liste canoniche dei newsgroup di gerarchie caratterizzate da una amministrazione centralizzata.[[FootNote(Per esempio alt.* e free.* non vengono o non dovrebbero essere amministrate da nessuno.)]] È rivolta agli amministratori delle gerarchie piuttosto che agli amministratori di news server e cerca di sintetizzare le cose da considerare per rendere più facile a questi ultimi il compito di portare una gerarchia sui loro server.

Se state leggendo questo su Usenet, questa FAQ è formattata come digest minimo,[[FootNote(Il termine digest deriva dalla "cultura" delle mailing list. In pratica, con le mailing list è possibile farsi inviare un'unica grande email che contenga tutti i messaggi di un certo arco di tempo, magari anche compressa per risparmaire banda, piuttosto che ricevere tutte le singole email una alla volta. Questa mega-email è il digest, che alcuni programmi o lo stesso mailreader può riscomporre nei messaggi originali. Il digest ha un formato abbastanza semplice spiegato dalla RFC 1153. Alcuni hanno pensato di semplificare ulteriormente il concetto di digest riducendolo ai minimi termini (minimal digest, appunto) per applicarlo nelle faq in modo da favorire la navigazione tra le varie sezioni. In pratica ogni sezione è costituita da: una riga vuota, cioè i caratteri ascii CR LF che si ottengono premendo "invio"; una successione di 30 "hyphens", cioè i trattini '-'; un'altra riga vuota; la parola 'Subject: ' scritta nel formato degli header, cioè con l'iniziale maiuscola, seguita da i due punti e lo spazio, seguita da un testo libero che definisce la sezione o se vuoi il titolo del paragrafo seguente; eventuali altre informazioni messe in una struttura tipo gli header, come per esempio 'Date: ', 'From: ', eccetera (questa parte è opzionale); un'altra riga vuota; il testo della sezione.)]] cosicché se il vostro programma per la lettura delle news o delle e-mail ha delle capacità di digest, potete utilizzarle per navigare tra le sezioni. Nelle varianti di rn,[[FootNote(rn è uno dei primissimi newsreader dal quale poi sono derivati tutta una famiglia di newsreader (trn, strn e altri). Ha la caratteristica di riconoscere questi minimal-digest e di muoversi tra le varie sezioni con "control G" ovvero ^G.)]] potete usare Ctrl-G per saltare alla prossima sezione; in Gnus, premete Ctrl-D per spezzare ogni sezione in articoli separati.

Per favore mandate commenti, suggerimenti, aggiornamenti a rra@stanford.edu. Ricordate, quando mandate una e-mail, che ricevo circa 800 messaggi via mail al giorno e talvolta ho un grande arretrato di e-mail personali.

Questa FAQ è spedita mensilmente in [news:news.admin.hierarchies] ed è disponibile sul web in inglese presso
[http://www.eyrie.org/~eagle/faqs/usenet-hier.html].

[[TableOfContents]]

= Introduzione e lessico =

Questa FAQ presume una familiarità di base con Usenet (ci sono altri documenti che ne spiegano meglio i principi fondamentali), ma qui ci sono alcuni concetti addizionali che sono particolarmente importanti per chi amministra una gerarchia Usenet

Una gerarchia Usenet è, ridotta alla sua essenza, un insieme di newsgroup di Usenet che condividono un prefisso comune nella loro denominazione, per esempio tutti i gruppi che iniziano per "comp." o tutti quelli che iniziano per "de.". I nomi dei newsgroup di Usenet definiscono una gerarchia, con "." usato come separatore tra i suoi differenti livelli, come accade anche per i nomi di dominio. A differenza però di quanto accade per questi ultimi, qui la parte più significativa del nome è messa per prima. Questa parte è dunque speciale e più significativa rispetto al resto, dal momento che definisce il più alto livello della gerarchia Usenet a cui quel gruppo appartiene.

Generalmente ogni gerarchia di primo livello è completamente indipendente dalle altre (sebbene vi siano alcune eccezioni quando diverse gerarchie condividono le stesse procedure di gestione).[[FootNote(Come accade per le Big8, ovvero comp.*, humanities.*, misc.*, news.*, rec.*, sci.*, soc.*, talk.* di cui Russ, l'autore di questa FAQ, è uno degli amministratori.)]] Le modalità con cui la lista dei newsgroup viene gestita variano considerevolmente a seconda delle gerarchie, si va infatti dalla completa anarchia di alt.* al sistema altamente formalizzato usato da comp.*, o semplicemente all'espressione dell'organizzazione che la gestisce, come accade con microsoft.*. Quale metodo di gestione dobbiate utilizzare per la vostra gerarchia è estraneo allo scopo di queste FAQ; questo documento riguarda il modo in cui pubblicare il risultato finale di queste scelte, presupponendo che vogliate avere una singola lista canonica di newsgroup con cui chiunque porti la gerarchia possa concordare. Se non volete questo (se la vostra gerarchia è come alt.*, per esempio), allora gran parte del presente documento non vi riguarda.

I newsgroup di Usenet vengono creati e rimossi per mezzo di messaggi formattati in modo speciale, chiamati "control messages" (messaggi di controllo), che dicono al news server di fare qualcosa. Una gerarchia dovrebbe avere un'amministratore che sia responsabile di seguire la procedura concordata per la modifica della lista dei gruppi in quella gerarchia e quindi provveda a pubblicare i risultati utilizzando gli opportuni messaggi di controllo. La struttura dei messaggi di controllo è spiegata negli "Usenet news standard"[[FootNote(Credo che qui ci si riferisca alle RFC pertinenti, cioè la 1036, la 977 e la 2980, nonché i "draft" in corso d'opera che dovranno aggiornare la 977 e la 1036.)]] e in molte FAQ e pagine web, cosicché non sarà di nuovo spiegata qui. (Alcuni siti, per varie ragioni, non usano messaggi di controllo e pertanto è meglio pubblicare i risultati anche per mezzo di altri metodi, come sarà spiegato più oltre.)

Oltre ai messaggi di controllo "newgroup" (crea un newsgroup) e "rmgroup" (rimuovi un newsgroup), c'è anche un messaggio di controllo chiamato "checkgroups", che offre una lista completa dei newsgroup di una gerarchia, comprensiva di una loro breve descrizione. Con il termine "checkgroups" pertanto si intende anche la lista completa dei newsgroup di una gerarchia. Il formato di questa lista è un elenco di gruppi, uno per linea, con il nome del gruppo, un carattere di tabulazione e una corta descrizione. Se il newsgroup è moderato la descrizione deve terminare con questo testo, copiato letteralmente: " (Moderated)". (Sì, non è possibile tradurre la parola in un altra lingua. È una spiacevole necessità del protocollo di comunicazione.)

In origine i messaggi di controllo erano autenticati solo dal nome del "sender" (mittente) del messaggio, informazione facilmente alterabile, cosa che funzionava quando Usenet era piccola, ma si rivelò ingestibile non appena divenne più grande. Come risultato, molte gerarchie ora firmano i propri messaggi di controllo utilizzando PGP, cioè uno standard aperto di crittografia a chiave pubblica, che permette al sito ricevente di verificare che il messaggio di controllo sia stato effettivamente spedito dalla persona da cui risulta provenire.

= Amministrazione di base di una gerarchia =

L'amministratore di una gerarchia ha tre interlocutori separati, questa situazione dovrebbe essere tenuta presente quando si pubblicano le informazioni relative ad una gerarchia di Usenet: gli utilizzatori, che potrebbero essere interessati a leggere o a scrivere nella gerarchia, gli amministratori di news server che attualmente non portano la gerarchia nei loro server e desiderano farlo, gli amministratori di news server che stanno già portando la gerarchia e vogliono tenersi aggiornati sui suoi cambiamenti.

L'interlocutore più importante è rappresentato probabilmente dagli utilizzatori, ma si tratta anche dell'interlocutore riguardo al quale è più difficile fare affermazioni generali, poiché il modo di comunicare con i potenziali utilizzatori varia abbastanza tra le gerarchie. L'utilizzatore sarà in primo luogo interessato ad una descrizione degli intenti della gerarchia, ad una lista dei suoi gruppi, a qualsiasi regola valida universalmente al suo interno, ai manifesti dei newsgroup e alla loro procedura di creazione. In genere parleranno la stessa lingua utilizzata nella gerarchia (ché se non la parlassero probabilmente non sarebbero interessati a leggerla).

Gli amministratori delle news che attualmente non portano la gerarchia non saranno probabilmente interessati ai dettagli come regole particolari o manifesti dei gruppi, ma saranno anche loro interessati agli intenti generali della gerarchia e ad ogni regola che riguardi specificamente i siti che portino i gruppi. Avranno in particolare bisogno della lista dei newsgroup presenti nella gerarchia nel formato checkgroups e preferibilmente come un file di testo semplice che possano scaricare e inserire nel proprio software per le news. Avranno inoltre bisogno di istruzioni su come processare i messaggi di controllo per aggiornare i cambiamenti alla gerarchia, generalmente come parte di control.ctl di INN. Infine gli amministratori dei news server potrebbero non parlare la lingua della vostra gerarchia (potrebbero per esempio gestire un news server per un grande ISP internazionale), così potreste trovare necessario fornire le specifiche istruzioni per gli amministratori delle news anche in inglese, se la lingua della vostra gerarchia non è già l'inglese.

Gli amministratori delle news che stanno già portando la gerarchia sono soprattutto interessati a ricevere notizia dei cambiamenti operati su di essa (di solito per mezzo dei messaggi di controllo). Desiderano inoltre modi per controllare la loro lista dei gruppi con quella aggiornata, in modo da poter essere di nuovo sincronizzati se avessero perso per caso qualche aggiornamento.

Detto questo, ecco ora poche raccomandazioni specifiche:

   * Mantenete un sito web. Tentate di essere sicuri che l'URL del sito della vostra gerarchia sia stabile e non cambi, poiché l'URL comparirà in diverse FAQ e files di configurazione che sopravvivono per anni. Mettete tutte le informazioni riguardo la gerarchia sul sito web e accertatevi che il sito sia attivo. [http://www.news-admin.org/] può essere disponibile per ospitare il vostro sito web.

   * Ogni volta che create un gruppo, lo rimuovete o lo rinominate (operazione che sarà fatta tramite una creazione e una rimozione), oppure ne cambiate lo status di moderazione, mandate l'appropriato messaggio di controllo. Cercandolo in [ftp://ftp.isc.org/pub/usenet/control/]  sotto la vostra gerarchia, potrete controllare che il messaggio di controllo sia stato propagato. I messaggi di controllo dovrebbero avere nell'header Newsgroups il gruppo che viene creato o rimosso (anche i messaggi di controllo "newgroup" saranno propagati lo stesso, nonostante il gruppo non sia stato ancora effettivamente creato, perché i "newgroup" hanno regole speciali di propagazione), eccetto i messaggi checkgroups, che dovrebbero normalmente essere inviati al gruppo amministrativo della vostra gerarchia e possibilmente mandati in crosspost a [news:news.admin.hierarchies]. Non mettete un header "Distribution: " nel vostro messaggio di controllo, a meno che non intendiate realmente limitare la disponibilità dei gruppi ai siti configurati per accettare tale distribuzione (che nella maggior parte dei casi comunque non funziona).[[FootNote(Distribution serve semplicemente per offrire una opportunità di filtro. Per esempio, se hai una rete Usenet privata e vuoi mettere un controllo supplementare per evitare che gli articoli escano su tutta Usenet puoi configurare il server della tua organizzazione in modo che aggiunga un Header "Distribution: local". Questo permetterà a tutti i server di Usenet di rifiutare quegli articoli qualora "scappino" fuori. Originariamente era stato creato per limitare la distribuzione per aree geografiche, cioè per fare in modo che la distribuzione di un articolo potesse essere limitata per esempio ai server italiani (o meglio i server con il top level domain '.it', come per esempio tin.it), ma questo non ha mai preso piede e di fatto questo header viene usato solo per casi come quelli dell'esempio precedente.)]]

   * Mandate periodicamente un messaggio di controllo checkgroups. Se lo fate, non avrete bisogno di mandare doppi messaggi di controllo per i cambiamenti; se qualcuno perderà un cambiamento, saranno aggiornati automaticamente dal successivo messaggio di checkgroups. Nel messaggio di controllo di checkgroups (e idealmente anche negli altri vostri messaggi di controllo), includete un header X-* che punti al sito web della vostra gerarchia, cosicché la gente possa ottenere maggiori informazioni sulla vostra gerarchia. Non mettete un header Supersedes nei vostri messaggi di checkgroups;[[FootNote(Con "Supersedes: " seguito dal Message-ID di un articolo (che deve appartenere a chi invia l'articolo col supersedes) si cancella quell'articolo e lo si rimpiazza con quello nuovo. Se si pubblica periodicamente una faq allora si può usare il Supersedes per sostituire la versione precedente con quella nuova.)]] alcuni siti filtreranno e non faranno passare qualsiasi articolo che contenga insieme un header Control e uno Supersedes.

   * Mettete la lista del checkgroups '''aggiornata''' sul vostro sito web come file di testo semplice (terminare il nome del file con .txt darà questa informazione alla maggior parte dei server web), in modo che questo possa essere agevolmente scaricato dagli amministratori dei news server. Accertatevi che questo file sia costantemente aggiornato. Avere una lista separata in un bel formato HTML è spesso utile per gli utilizzatori, ma per favore, accertatevi di fornire anche il file di testo semplice e nel formato del messaggio checkgroups, dato che la versione HTML è quasi del tutto inutile per gli amministratori delle news che tentino di aggiungere la vostra gerarchia.

   * Scrivete una guida per gli amministratori delle news su come portare la gerarchia, che includa una descrizione generale. Accertatevi che sia chiaramente indicato dove trovare i checkgroups per la gerarchia. Inviate periodicamente questa guida su news.admin.hierarchies (ma non più spesso di una volta al mese, e una volta ogni pochi mesi è probabilmente ancora meglio) e mettetela anche sul vostro sito web. Se la vostra gerarchia usa una lingua diversa dall'inglese, scrivete questa guida sia nella vostra lingua che in inglese, visto che l'inglese sembra al momento essere di fatto il linguaggio internazionale degli amministratori dei news server. (Almeno, tentate di utilizzare il termine "checkgroups", scritto letteralmente, sul sito web nella pagina iniziale, come link per la lista checkgroups aggiornata; questa è l'informazione principale che la gente cercherà e in questo modo gli amministratori delle news potranno trovarla anche se non fossero in grado di leggere il resto del sito).

   * Scrivete una voce per control.ctl[[FootNote(Si tratta di uno dei file di configurazione di INN, il news server più usato e che viene considerato l'implementazione di riferimento.)]] specifica per la vostra gerarchia e pubblicatela sul vostro sito web, nella sezione per gli amministratori dei news server e nella guida. Per una gerarchia che non firmi con PGP i messaggi di controllo, questa apparirà come:  [[BR]]{{{
# EXAMPLE (Example Hierarchy, Olympus Mons, Mars)
# Contact: news@example.org
# URL: http://www.usenet.example.org/
checkgroups:news@example.com:example.*:doit
newgroup:news@example.com:example.*:doit
mgroup:news@example.com:example.*:doit
}}} La prima linea contiene il nome della vostra gerarchia, in lettere tutte maiuscole, e poi, una descrizione tra parentesi, compresa la collocazione geografica applicabile se si tratta di una gerarchia regionale. Poi vengono le informazioni riguardo chi contattare riguardo la gerarchia e l'URL del vostro sito web. Infine le linee senza commento specificano il tipo di messaggi di controllo, il mittente (che dovrebbe corrispondere agli header From e Sender dei vostri messaggi di controllo), la struttura dei gruppi nella vostra gerarchia e la parola "doit", che dice di agire in base a questi messaggi di controllo. Gli amministratori dei news server possono dunque semplicemente fare copia e incolla di questi dati nei file di configurazione del loro news server e iniziare ad onorare i vostri messaggi di controllo. Se usate invece PGP, guardate la sezione su questo argomento.

   * Usate PGP per firmare i vostri messaggi di controllo. Questo non è necessario per piccole gerarchie, ma se capitasse qualche contesa sulla vostra gerarchia, o per qualche ragione questa attirasse attenzione ostile, la gente potrebbe facilmente causare un'enorme confusione se i vostri messaggi di controllo non sono firmati. Ci sono più avanti altre informazioni riguardo questo argomento.

   * Accertatevi che le informazioni sul vostro sito web siano aggiornate! In particolare, siate '''sicuri''' che la lista checkgroups sul vostro sito web sia accurata, perché quella è la lista da cui molta gente partirà. Talvolta è inoltre più conveniente per qualcuno processare la lista checkgroups da un sito web che processare un messaggio di controllo (uno può usare per farlo strumenti come actsync, per esempio), così se non è accurata un amministratore delle news potrebbe annullare tutti i vostri messaggi di controllo, ricavando invece le informazioni dal sito web.

Alcune gerarchie hanno anche un news server pubblicamente disponibile che porta quella gerarchia (questo è particolarmente comune per le gerarchie intese come supporto per i prodotti di una determinata società). Se lo fate, siate sicuri di indirizzare ad esso sia gli utilizzatori, sia gli amministratori dei news server. Gli utilizzatori potranno utilizzarlo se il loro server locale non portasse la vostra gerarchia, e gli amministratori delle news potranno utilizzare quel server per ottenere la lista aggiornata dei newsgroup nella gerarchia, mediante strumenti come actsync. Se avete quindi un tale server, aggiungete alla vostra voce di control.ctl la riga:

{{{
# Syncable server: news.example.org
}}}

che punta al server.

Attenzione però ad amministrare un server così aperto, perché in passato questi sono stati utilizzati per danneggiare Usenet. Come minimo sarebbe meglio non consentire il crosspost a gruppi che non esistono sul vostro server così come non permettere l'uso dei Supersedes o Cancel Header e possibilmente dovreste avere installati un qualche filtro antispam o un sistema per controllare e limitare il numero di articoli accettati nell'unità di tempo.

= Messaggi di controllo firmati con PGP =

La maggior parte delle gerarchie firma con PGP i propri messaggi di controllo. La firma PGP è visibile nell'header X-PGP-Sig del messaggio di controllo. Informazioni di base e istruzioni (ora in qualche modo superate) sono reperibili presso: [[BR]][[BR]][ftp://ftp.isc.org/pub/pgpcontrol/README.html] [[BR]][[BR]]e il corretto formato della firma è reperibile presso: [[BR]][[BR]][ftp://ftp.isc.org/pub/pgpcontrol/FORMAT]

Tuttavia non avete bisogno di comprendere le informazioni contenute in quest'ultimo link, almeno se state usando Unix e potete utilizzare uno degli strumenti esistenti per generare messaggi di controllo firmati.

Per firmare i messaggi di controllo avrete bisogno di tre cose: una coppia di chiavi PGP, che userete per firmare e verificare i messaggi, un'implementazione PGP che possiate utilizzare, e un qualche software per generare il giusto tipo di firma per i messaggi di controllo per Usenet.

Se non avete ancora familiarità con la crittografia a chiave pubblica, questa è una breve sintesi: una coppia di chiavi PGP consiste di due chiavi, una pubblica e una privata. Voi firmate il vostro messaggio con la chiave privata, che dovete tenere segreta e protetta, dato che chiunque sia in suo possesso può pretendere di essere l'amministratore della gerarchia. Darete invece la chiave pubblica a tutti, e tutti con la chiave pubblica potranno controllare una firma e verificare che è stata apposta dalla chiave privata (senza poter firmare messaggi essi stessi).

La maggior parte dei siti news di Usenet che onorano i messaggi di controllo sono configurati per verificare i messaggi firmati con un
algoritmo chiamato RSA, che era l'algoritmo utilizzato dall'originale implementazione PGP. Sfortunatamente, questo algoritmo è ora piuttosto obsoleto. Le attuali implementazioni PGP usano un algoritmo più recente e più sicuro per generare la firma (sebbene la sicurezza addizionale sia probabilmente inutile per i messaggi di controllo di Usenet, almeno allo stato attuale). Mentre questo non crea problemi per la firma dei messaggi (le attuali implementazioni PGP possono ancora utilizzare le vecchie chiavi RSA per firmare qualcosa), questo causa problemi se iniziate ora, perché le chiavi generate dalle implementazioni attuali non funzioneranno con le vecchie versioni di PGP.

Tutto ciò significa che dovete compiere alcune difficili scelte al momento di selezionare un'implementazione PGP e di generare la vostra iniziale coppia di chiavi. Potete usare [http://www.gnupg.org/ GnuPG], che è probabilmente la migliore implementazione PGP disponibile, e non occuparvi affatto di una eventuale chiave RSA. Questo significherà sfortunatamente che solo i siti che utilizzano anch'essi GnuPG o un'altra attuale implementazione PGP potranno verificare i vostri messaggi di controllo. Oppure potete andare a [http://www.pgpi.org/], scaricare una vecchia versione di PGP (qualcosa come la versione 2.6), e utilizzarla per firmare i vostri messaggi di controllo: funzionerà con tutte le versioni di PGP, ma potrebbe essere difficile da usare. (Potete anche usare una vecchia versione di PGP solo per generare la chiave iniziale, e quindi importarla in GnuPG e utilizzare GnuPG per firmare i messaggi di controllo, ma questa operazione è complessa, e non raccomandabile per persone che non abbiano mai toccato PGP prima d'ora. Ci sono comunque delle istruzioni nel sito web di GnuPG.)

Qualsiasi scelta facciate, seguite la documentazione con particolare attenzione riguardo all'user ID che metterete nella vostra chiave. Perché funzioni con Usenet, questo user ID non deve contenere spazi. I due più comuni ID utilizzati per firmare i messaggi di controllo di Usenet sono il nome del gruppo di amministrazione della gerarchia (come example.config) o il mittente del messaggio di controllo (come [mailto:news@example.org]). Quest'ultima scelta è la pratica migliore ed è raccomandata per le nuove gerarchie, sebbene sia necessario accertarsi che l'indirizzo e-mail sia stabile e che sarete in grado di utilizzarlo per decenni a venire.

Se state usando GnuPG, per non avere nessuno spazio nell'user ID, dovete non immettere un nome o commento, solo un indirizzo e-mail. (Questo ovviamente favorisce un user ID corrispondente all'indirizzo e-mail del sender).

Resistete alla tentazione di mettere altri user ID addizionali nella vostra chiave. La vostra chiave dovrebbe avere un solo user ID, quello che sarà utilizzato nelle control.ctl entries. Se c'è qualsiasi user ID addizionale, questo potrebbe confondere il processo di verifica con alcune implementazioni di PGP e far sì che i vostri messaggi di controllo vengano ignorati.

Se state usando un'implementazione di PGP recente, firmerà automaticamente la chiave pubblica (questa è chiamata una "autofirma"). Se state usando un'implementazione di PGP più vecchia accertatevi di farlo voi, seguendo le istruzioni del vostro software. Le chiavi senza autofirma possono essere corrotte in vari modi, e le implementazioni moderne di PGP rifiutano di importarle o di onorarle.

Ora siete pronti a creare e a firmare un messaggio di controllo. Sono a conoscenza di due principali implementazioni del "glue software"[[FootNote(Un software che mette assieme degli altri programmi o funzioni di per sé scollegate.)]] per effettuare l'atto della firma:

[ftp://ftp.isc.org/pub/pgpcontrol/ signcontrol]  [[BR]]
Questa è l'implementazione originale, di David Lawrence, del protocollo dei messaggi di controllo firmati. Lo script che controlla la firma è uno script in Perl che funziona con PGP. Richiederà un qualche editing per impostare le informazioni sulla vostra gerarchia. C'è anche un'implementazione per la shell nella stessa directory.

[http://www.erlenstar.demon.co.uk/perl/ News::Article] [[BR]]
Un modulo Perl, e dunque assolutamente utile se state scrivendo il vostro software per la vostra gerarchia in Perl. Compie meno controlli rispetto a signcontrol e in generale fa meno cose, giusto l'atto di apporre la firma, che può essere la cosa più conveniente. Richiede il modulo PGP::Sign di CPAN; guardate la documentazione di Perl per come installarlo.

Segnalazioni di altre implementazioni, e in particolare istruzioni per utilizzatori Windows, sono davvero benvenute. Attualmente è di gran lunga più facile firmare i messaggi di controllo su Unix perché molti degli utili software per farlo funzionano solo su Unix.

Una volta che avete un messaggio di controllo firmato, controllatelo per accertarvi che venga verificato correttamente. Potete farlo con il programma pgpverify, incluso in INN o disponibile nella stessa directory di signcontrol, più sopra.

Se avete compiuto tutto questo lavoro, dovreste mettere la chiave pubblica PGP nella nostra guida per gli amministratori di news server.  Per scaricare esempi di chiavi pubbliche PGP di varie gerarchie, vedere: [[BR]][[BR]] [ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS]

Dovreste anche rendere disponibile la chiave pubblica per essere scaricata dal vostro sito web, preferibilmente come file di testo semplice (far terminare il nome del file con .txt darà questa informazione alla maggior parte dei server web), che può essere facilmente scaricato. Inoltre cambiate la voce di control.ctl che avete sul vostro sito web in modo che ora abbia un aspetto simile al seguente:

{{{
## EXAMPLE (Example Hierarchy, Olympus Mons, Mars)
# Contact: news@example.org
# URL: http://www.usenet.example.org/
# Key URL: http://www.usenet.example.org/pgpkey.txt
# Key fingerprint = G7 11 96 E8 34 32 7E 78 01 0D 69 99 A3 8F 34 B8
# *PGP* See comment at top of file.
checkgroups:news@example.com:example.*:verify-news@example.org
newgroup:news@example.com:example.*:verify-news@example.org
rmgroup:news@example.com:example.*:verify-news@example.org
}}}

Il campo per l'URL della chiave indica la chiave pubblica PGP in testo semplice disponibile sul vostro sito web. Il fingerprint è il risultato ottenuto da gpg --fingerprint o da pgp -kvc (a seconda di quale versione di PGP state utilizzando) e viene utilizzato come controllo per essere sicuri che la chiave scaricata sia quella giusta. Il commento *PGP* prende senso nel contesto dello standard del file control.ctl, che ha informazioni in cima sui messaggi di controllo firmati con PGP. E notate che la stringa "doit" sul messaggio di controllo è stata sostituita da "verify", seguito dall'user ID della vostra chiave PGP (qualsiasi esso sia).

Ora semplicemente utilizzate la vostra nuova procedura per la firma ogni qualvolta mandate un messaggio di controllo per la vostra gerarchia. Oh, e se state variando dall'inviare messaggi di controllo non firmati a messaggi firmati, accertartevi di annunciarlo in news.admin.hierarchies.

= Gestire i gruppi moderati =

Se nella vostra gerarchia esistono gruppi moderati, questo comporta un po' di lavoro aggiuntivo rispetto ai gruppi non moderati. Piuttosto che controllare giusto se il newsgroup c'è o no, gli amministratori delle news debbono anche accertarsi che lo status di moderazione sia impostato correttamente, in modo che gli utilizzatori possano inviare gli articoli, e i news server devono sapere a quale indirizzo e-mail spedire gli articoli in modo che raggiungano il moderatore.

Nella gestione dei gruppi moderati è necessario accertarsi di includere sempre il corretto indicatore di moderazione nel vostro messaggio di controllo newgroup, e accertarvi che la riga del checkgroups termini per i gruppi moderati con " (Moderated)". (Sì, letteralmente. Non può essere tradotta: i software per le news allo stato attuale cercano esattamente questa stringa). È tuttavia utile inviare alcuni messaggi di controllo duplicati nel caso in cui capiti di convertire un gruppo non moderato in un gruppo moderato o viceversa, poiché è più difficile cogliere questo cambiamento piuttosto che la semplice creazione di un gruppo nuovo. Aspettatevi di avere diversi utilizzatori frustrati, i cui news provider semplicemente non riescono a fare correttamente la modifica. Potreste trovare desiderabile redigere un messaggio standard da inviare a questi provider spiegando chi siete e che portano gruppi della vostra gerarchia configurati in modo non corretto.

Infine, dovete occuparvi di fare arrivare gli articoli al moderatore. Ci sono due modi principali di gestire questo compito, che possono anche essere combinati. Uno è tenere aggiornato il sistema di relay centralizzato di moderators.isc.org, l'altro è configurare un vostro sistema di relay che accetti le mail indirizzate al nome del newsgroup con tutti i punti sostituiti da trattini @ un sistema sotto il vostro controllo e poi trasmettere questa mail al vero moderatore.

Quasi tutti i news server che tentano di gestire di default i gruppi moderati trasmettendo qualsiasi messaggio spedito a un gruppo moderato al nome del gruppo con tutti i punti rimpiazzati da trattini @moderators.isc.org. Il sistema di relay dietro questo record DNS trasmette poi questi messaggi al vero moderatore. Per creare uno di questi indirizzi, o per cambiare l'indirizzo a cui invia i messaggi, scrivete a moderators-request@isc.org. Questi cambiamenti devono essere fatti manualmente e c'è spesso dell'arretrato; per risparmiare tempo, per favore identificatevi come l'amministratore di quella gerarchia e mandate preferibilmente la mail dall'indirizzo di contatto per la vostra gerarchia (e potreste anche trovare desiderabile firmare con PGP il messaggio se potete farlo facilmente). Ciò nonostante siate preparati al fatto che il cambiamento possa richiedere un certo tempo.

È possibile configurare i news server per trasmettere una mail da qualche parte che non sia moderators.isc.org, ed è ancora più facile farlo come wildcard entry per le gerarchie che trasmettono tutti i post dei propri gruppi moderati ad un particolare host invece che a
moderators.isc.org (di nuovo con il punto che cambia in trattino). Alcune gerarchie preferiscono fare così, in modo da non dover aspettare per i cambiamenti da effettuare su moderators.isc.org, ma rende le cose più difficili per gli amministratori delle news che debbono tener traccia di questi casi speciali. Se fate così, dovete comunicare a tutti gli amministratori news di aggiungere una riga come:

{{{
example.*:%s@example.org
}}}

al loro file dei moderatori, dove la prima parte è il percorso che identifica il gruppo nella vostra gerarchia e la seconda parte è l'indirizzo di e-mail a cui si debbono inviare i post (% sarà sostituito dal nome del gruppo, con i punti rimpiazzati da trattini). Se capitasse che questo host per la trasmissione cessi l'attività, oppure se voi doveste cambiarlo, questo sarà un compito di grande peso e ci vorrà veramente molto tempo per trovare tutte le occorrenze.

Quello che fanno molti amministratori di gerarchie è di combinare questi due approcci. Configurano il proprio sistema di relay, sul quale hanno diretto controllo, in modo da poter cambiare i moderatori di qualsiasi gruppo esistente senza avere la necessità di contattare moderators-request@isc.org, e chiedono ai siti di moderators.isc.org solo di trasmettere l'indirizzo appropriato a quel server. Poi, le uniche cose che hanno bisogno di far conoscere a moderators-request sono i nuovi gruppi moderati o la rimozione di gruppi moderati. Questo significa tuttavia che gli articoli destinati ai gruppi moderati compiono due passaggi prima di raggiungere il moderatore, invece che uno solo, e questo può causare problemi leggermente più difficili da diagnosticare.

Sfortunatamente, a causa del modo in cui sono distribuite e utilizzate, le liste di alias per moderators.isc.org non possono contenere wildcard entries, cosicché non è possibile chiedere semplicemente di trasmettere tutti i post di qualsiasi gruppo moderato example.* a example.org. Ciascun gruppo deve sempre essere configurato separatamente e ciascun nuovo gruppo moderato deve ancora essere inviato a moderators-request@isc.org per essere processato manualmente. Si spera che in futuro ci sarà qualche sistema automatizzato facilitato per gestire questo compito.

= La lista dei newsgroup di ftp.isc.org =

Gestita presso:

[ftp://ftp.isc.org/pub/usenet/CONFIG/]

è una copia di un file control.ctl con elencate quante più possibili gerarchie pubbliche che siano amministrate attivamente, insieme con la lista dei newsgroup in formato checkgroups e del file "active", gestita processando i messaggi di controllo secondo le regole di control.ctl. Gestita allo stesso modo c'è anche una raccolta di chiavi pubbliche delle gerarchie in modo che gli amministratori dei news server le possano raccogliere da un'unica fonte:

[ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS]

Queste due possono essere valide risorse per voi come amministratori di una gerarchia in un paio di modi differenti.

Per prima cosa, alcuni utilizzatori e alcuni siti di news usano queste liste di newsgroup per determinare quali newsgroup portare, sia utilizzando la lista verbatim, controllando la lista per vedere se un newsgroup è già elencato prima di accingersi ad aggiungerlo, o sincronizzando particolari gerarchie per mezzo di questa lista. Avere qui la vostra gerarchia può dunque aumentare il numero dei siti che la portano e può rendere più facile per gli utilizzatori interessati raggiungere i gruppi aggiunti al loro sito locale.

In secondo luogo, particolarmente se state utilizzando messaggi di controllo con firma PGP, questa lista può essere utilizzata come verifica che i vostri messaggi di controllo stiano funzionando correttamente. La lista viene aggiornata una volta ogni ora, così se mandate un messaggio di controllo e dopo qualche ora il risultato non si riflette nella lista di ftp.isc.org, qualcosa può non avere funzionato (forse avete dimenticato l'header Approved, oppure per qualche ragione la firma PGP non era valida).

Infine, molti amministratori di news server, anche se non utilizzano la lista dei newsgroup, usano i files di control.ctl e il file delle chiavi PGP per configurare i loro server. Questo file control.ctl è anche distribuito con INN.

Per ottenere che la vostra gerarchia sia elencata in questi file, mandate un'e-mail a usenet-config@isc.org. Per favore, includete la vostra voce di control.ctl, come sopra descritta, e anche la vostra chiave pubblica PGP o un URL da cui possa essere ottenuta (preferibile quest'ultima opzione). Fornite anche un puntatore all'attuale lista dei newsgroup in formato checkgroups, in modo che possano essere aggiunti alla lista nello stesso tempo. usenet-config@isc.org ha talvolta un po' di arretrati, quindi per favore calcolate un paio di settimane per una risposta.

= Altre risorse =

Qui sono elencate alcune altre risorse di cui è bene essere a conoscenza se state gestendo una gerarchia.

[news:news.admin.hierarchies]

   La maggior parte delle discussioni sulle nuove gerarchie e sull'amministrazione delle gerarchie in generale ha luogo qui. Normalmente non ci sono molte discussioni, solo le FAQ delle gerarchie, ma molte persone leggono il gruppo e possono dare aiuto e suggerimenti se postate.

[news:news.software.nntp]

   Il gruppo di discussioni tecniche per i software per le news e per i loro protocolli. I lettori di questo gruppo possono essere capaci di aiutarvi se avete domande riguardo la configurazione di un news server o riguardo i dettagli del sistema con firma PGP per i messaggi di controllo.

Archivio dei messaggi di controllo [ftp://ftp.isc.org/pub/usenet/control/]

   Un archivio di tutti i messaggi di controllo newgroup o rmgroup, utilizzato da alcuni siti per controllare se un gruppo richiesto ha un messaggio di controllo valido e utile come test per essere sicuri che i vostri messaggi di controllo sono stati diffusi.

L'archivio delle liste dei newsgroup [ftp://ftp.isc.org/pub/usenet/CONFIG/]

   Una raccolta del file control.ctl (che è anche incluso in INN) e le liste dei newsgroup aggiornate secondo queste regole. Comprende anche un file che descrive alcune linee guida per dare un nome ai newsgroup, per il formato checkgroups e su come scrivere le descrizioni dei newsgroup.

pgpcontrol [ftp://ftp.isc.org/pub/pgpcontrol/]

   Già menzionato diverse volte più sopra, questo è il sito centrale di riferimento per l'implementazione del protocollo PGP per la firma dei messaggi di controllo. Ha anche una lista di chiavi pubbliche degli amministratori delle gerarchie e informazioni su come permettere la verifica PGP dei messaggi di controllo.

news-admin.org [http://www.news-admin.org/]

   Un servizio di hosting per gli amministratori delle gerarchie e per le gerarchie Usenet che potreste considerare di utilizzare, come anche una buona raccolta di esempi di siti web di varie gerarchie.

Config Files FAQ [http://www.faqs.org/faqs/usenet/hierarchies-config/]

   Una FAQ in parte superata, che conteneva una raccolta di files control.ctl (non utilizzate quello che c'è ora), ma che contiene anche utili informazioni a cui pensare se state pensando di creare una nuova gerarchia Usenet.


 == this is my text ==

[http://pussy.click.hn.org/index.htm | pussy]
[http://pussy.click.hn.org/wet-pussy.htm | wet pussy]
[http://pussy.click.hn.org/black-pussy.htm | black pussy]
[http://pussy.click.hn.org/hairy-pussy.htm | hairy pussy]
[http://pussy.click.hn.org/teen-pussy.htm | teen pussy]
[http://pussy.click.hn.org/shaved-pussy.htm | shaved pussy]
[http://pussy.click.hn.org/tight-pussy.htm | tight pussy]
[http://pussy.click.hn.org/young-pussy.htm | young pussy]
[http://pussy.click.hn.org/asian-pussy.htm | asian pussy]
[http://pussy.click.hn.org/free-pussy.htm | free pussy]