POLICY ECHOMAIL FidoNet Zone 2 Region 33 13 Luglio 1998 Release 4.01 --------------------- 1. PROLOGO 2. DEFINIZIONI 2.1 Echomail 2.2 Conferenza Echomail (Area) 2.3 Conferenza Moderata 2.4 Conferenza Privilegiata e Conferenza ad accesso libero 2.5 Conferenza Backbone-Routed (BB/Routed) 2.6 Conferenze "*EC-owned" e "Mod-owned" 2.7 Regional Echomail Coordinator (REC) 2.8 Net Echomail Coordinator (NEC) 2.9 Echolist Keeper 2.10 Collegio Echomail 2.11 Echomail Backbone 2.12 Nodo terminale 2.13 Censura automatica 2.14 Gateway 2.15 Cosysop 2.16 Echofile 3. COMPITI DEI COORDINATORI ECHOMAIL 3.1 Compiti generali di REC e NEC 3.2 Compiti del REC 3.3 Compiti del NEC 3.4 Compiti dell'Echolist keeper 3.5 Compiti del moderatore di conferenza Echomail 3.6 Compiti del Backbone Echomail 3.7 Compiti di sysop e cosysop 4. PROCEDURE DI ELEZIONE, NOMINA E RIMOZIONE DI COORDINATORI E MODERATORI 4.1 Norme generali per i coordinatori echomail 4.2 Elezione del REC 4.3 Elezione del NEC 4.4 Elezione dell'Echolist 4.5 Nomina di un moderatore 4.6 Rimozione di un moderatore 5. PROCEDURE VARIE PER LA GESTIONE DELL'ECHOMAIL 5.1 Immissione sul Backbone nazionale di un'area non BB/Routed 5.2 Rimozione dal Backbone nazionale di un'area 5.3 Chiusura di un'area *EC-owned 5.4 Apertura di un'area direttamente sul Backbone 5.5 Provvedimenti dei moderatori 5.6 Ricorsi contro i moderatori 6. REGOLAMENTAZIONE DELL'ECHOMAIL 6.1 Regole di base 6.2 Standard dei messaggi 6.3 Proprieta' dei messaggi 6.4 Gateway 7. MISCELLANEA 7.1 Conferenze riservate 7.1.1 SYSOP.033, (NET)SYSOP.33x 7.1.2 ECHOSER.033, ECHOSER.33x 7.1.3 ECHO_COORD.033 7.1.4 COORD.033 7.1.5 RC&REC_NEWS.033 7.1.6 PING.033 7.1.7 MODERATORI.033 7.1.8 ECHO_ADS.033 7.2 Come riconoscere i coordinatori 7.3 Nomi standard dei documenti 7.4 Modifica di questa policy 7.5 Disposizioni transitorie 7.6 Ringraziamenti 1 PROLOGO ========= Questo documento detta le regole per la distribuzione e la gestione delle conferenze echomail all'interno della region 2:33 (Italia). Viene applicato a tutte le conferenze BB/Routed della Region e a tutte le conferenze non BB/Routed in cui il moderatore decida di applicarlo. Tale documento non e' in contrasto con la Policy Generale Fidonet, della quale vuole essere invece un'estensione. In questo documento, la dicitura "maggioranza semplice" in una votazione indica il 50%+1 dei votanti. Il 50% e' calcolato per difetto, quindi, ad esempio, la maggioranza semplice di 5 e' 3, quella di 6 e' 4. Inoltre in tutte le votazioni vale il principio per cui un coordinatore che ricopre piu' cariche puo' esprimere comunque un solo voto. 2 DEFINIZIONI ============= Vengono date in questa sezione alcune definizioni. Non verranno ripetute qui le definizioni date nella Policy Generale Fidonet. 2.1 Echomail ~~~~~~~~~~~~ Il processo di condivisione fra nodi di una o piu' basi messaggi; tali messaggi hanno la caratteristica di poter essere letti da tutti i partecipanti (in contrapposizione alla netmail, i cui messaggi sono indirizzati e visibili unicamente al destinatario, fatte salve le eccezioni di policy). 2.2 Conferenza Echomail (o Area) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Una specifica base messaggi distribuita fra un certo gruppo di nodi. Ogni conferenza e' identificata da un nome unico e da uno specifico campo di interesse dei messaggi (topic). Comunemente una conferenza e' detta anche area. 2.3 Conferenza Moderata ~~~~~~~~~~~~~~~~~~~~~~~ Una conferenza per cui sia stato nominato un moderatore che ne controlli flusso e contenuti. 2.4 Conferenza Privilegiata e Conferenza ad accesso libero ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Una conferenza privilegiata e' una conferenza il cui moderatore o questa policy stabiliscono restrizioni di accesso. Al contrario, una conferenza ad accesso libero e' una conferenza per la quale non esistono restrizioni di accesso. 2.5 Conferenza Backbone-Routed (BB/Routed) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Una conferenza per la quale e' obbligatoria la distribuzione sui backbone. Tutte le conferenze BB/Routed devono rispettare questa echopolicy e la Policy Generale Fidonet e DEVONO essere moderate. Le conferenze BB/Routed sono tutte e sole quelle presenti nel file FIDOITA.SE disponibile in file request sul nodo dell'Echolist e inviato via echofile nel pacchetto ADM-*. 2.6 Conferenze "*EC-owned" e "Mod-owned" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Una conferenza si definisce *EC-owned quando il *EC competente (ossia il REC se l'area e' nazionale o il NEC se e' di net) e' garante dell'operato del moderatore dell'area. In tali aree il *EC nomina il moderatore, stabilisce la policy (o approva quella proposta dal moderatore) e riceve eventuali contestazioni nei suoi confronti, prendendo, ove lo ritenesse opportuno, eventuali provvedimenti, sino alla rimozione del moderatore stesso. Una conferenza si definisce invece mod-owned quando il *EC non e' competente sul suo moderatore. Per queste aree il *EC puo' solo disporre la rimozione dal Bacbkone (facendola quindi diventare conferenza non BB/Routed) o, viceversa, su richiesta del moderatore, l'attivazione sul Bacbkone (facendola quindi diventare BB/Routed). 2.7 Regional Echomail Coordinator (REC) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Coordinatore Echomail della Region. 2.8 Net Echomail Coordinator (NEC) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Coordinatore Echomail di un Net. 2.9 Echolist Keeper ~~~~~~~~~~~~~~~~~~~ Incaricato della manutenzione degli archivi amministrativi Echomail della region. Normalmente abbreviato in Echolist, talvolta detto National Echomail List (NEL). 2.10 Collegio Echomail ~~~~~~~~~~~~~~~~~~~~~~ La struttura composta dai NEC e dal REC. 2.11 Echomail Backbone ~~~~~~~~~~~~~~~~~~~~~~ Volontario che contribuisce alla distribuzione dell'echomail, prelevando a livello piu' alto tutte le conferenze BB/Routed per renderle poi disponibili a livello piu' basso. Gli echomail backbone distribuiscono inoltre i file amministrativi echomail (IPA, ADM, BOF, FAQ). 2.12 Nodo terminale ~~~~~~~~~~~~~~~~~~~ Un nodo che non smista messaggi verso altri nodi Fidonet. 2.13 Censura automatica ~~~~~~~~~~~~~~~~~~~~~~~ Procedura effettuata mediante un programma che, automaticamente, altera il contenuto dei messaggi o li rimuove da una determinata conferenza. 2.14 Gateway ~~~~~~~~~~~~ Un sistema che mette in condivisione delle conferenze tra Fidonet ed altre reti. 2.15 Cosysop ~~~~~~~~~~~~ Utente di un nodo delegato dal sysop a gestirlo in sua assenza. Il cosysop deve avere lo stesso ruolo del sysop (stessi privilegi e accessi) in modo da poterlo sostituire in tutto e per tutto. Un nodo multilinea ha comunque diritto ad un solo cosysop. 2.16 Echofile ~~~~~~~~~~~~~ Sistema di distribuzione di file (generalmente non contenenti messaggi) tra nodi, il cui schema di propagazione e' simile a quello della Echomail. 3 COMPITI DEI COORDINATORI ECHOMAIL =================================== 3.1 Compiti generali di REC e NEC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E' compito fondamentale di NEC e REC coordinare la distribuzione dell'echomail, controllando che essa avvenga in modo ottimale, senza generare cicli (loop) e messaggi duplicati (dupes). Ogni *EC ha inoltre il compito di nominare i moderatori delle aree *EC-owned del suo livello, sovraintendere al loro lavoro, ricevendo eventuali contestazioni sul loro operato e comportandosi di conseguenza. Ha inoltre la facolta' di commutare in mod-owned tali aree. Ogni *EC deve partecipare attivamente alle conferenze di coordinamento. Qualora un *EC per piu' di un mese si assentasse senza giustificato motivo dalle votazioni e dalle discussioni in area di coordinamento potra' essere rimosso. Il collegio dei NEC e' inoltre garante dell'operato del REC; viceversa, il REC e' garante dell'operato di ciascun NEC. 3.2 Compiti del REC ~~~~~~~~~~~~~~~~~~~ E' compito del REC coordinare tutte le procedure del collegio echomail e verificare che le elezioni e le verifiche annuali dei NEC si svolgano secondo la policy. Il REC riconosce le aree BB/Routed, ne gestisce la nomina dei moderatori (nel caso di aree REC-owned) e ne dispone l'attivazione o la rimozione dai backbone nazionali, il tutto in base alle procedure stilate in questo documento. Coordina inoltre la nomina dei Backbone nazionali ed internazionali di Region. 3.3 Compiti del NEC ~~~~~~~~~~~~~~~~~~~ Il NEC deve: - verificare la congruenza del routing echomail nel proprio net; - curare una mappa dei link del proprio net, in modo da poter subito verificare eventuali loop; - assicurarsi che nel proprio net vi sia almeno un backbone; - eseguire eventuali provvedimenti richiesti da un moderatore nei confronti dei nodi del proprio net; - curare eventuali nodi indipendenti nella Region per i quali il REC abbia disposto la sua competenza. Ogni NEC deve inoltre approvare ogni link non standard nel net di sua competenza, dove per "link standard" s'intende uno dei seguenti: - il link di un nodo col suo HC; - il link di un nodo con un altro nodo del suo hub, qualora il primo non abbia un link diretto con l'HC; - il link di un HC con l'NC; - il link di un HC con il Backbone di Net. Qualora il link riguardi nodi di due net diversi ci vorra' l'approvazione di entrambi i NEC. 3.4 Compiti dell'Echolist keeper ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All'Echolist sono demandati i seguenti compiti: - tenere costantemente aggiornata la lista delle aree BB/Routed nazionali e di net, con nome e indirizzo Fido dei singoli moderatori; per le aree non BB/Routed, tiene la lista solo delle aree per le quali il moderatore abbia fatto esplicita richiesta in tal senso e che si conformano a questa policy e alla Policy Generale Fidonet; - tenere costantemente aggiornato l'archivio delle policy d'area e quello dei cosysop; - gestire gli archivi di BestOf (BOF) e Frequently Asked Questions (FAQ); - verificare la raggiungibilita' Fidonet dei diversi moderatori; - coordinare l'invio in rete (hatch) gli archivi amministrativi, BOF e FAQ; - coordinare le votazioni per l'apertura di aree, come da paragrafo 5.4. Il REC puo' inoltre delegare all'Echolist ulteriori compiti di gestione dell'Echomail. Qualora l'Echolist utilizzi un software per archiviare le policy, ha la facolta' di chiedere ai moderatori la scrittura delle policy in un formato compatibile col software utilizzato; tale formato dovra' comunque essere una semplice formattazione ASCII, in modo che le policy possano essere postate cosi' come sono in area. Ha inoltre la facolta' di decidere i dettagli tecnici degli incarichi che gli sono assegnati, tipo il nome degli archivi BOF e FAQ. 3.5 Compiti del moderatore di conferenza Echomail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Spetta al moderatore di conferenza Echomail fare in modo che il traffico nella sua area si mantenga nel topic ad essa assegnata e sia conforme a questa Policy ed alla Policy Generale Fidonet. A tal fine dovra' mettere in atto ogni ragionevole sforzo perche' gli utenti siano a conoscenza delle policy e le rispettino. Ha inoltre la facolta' di richiedere motivata sconnessione di un partecipante alla conferenza secondo le procedure stabilite in questo documento (capitolo 5.5). Dovra' postare periodicamente in area la policy (in genere mensilmente) ed informare tempestivamente l'Echolist di eventuali variazioni di indirizzo. Il moderatore (o suo eventuale sostituto), dovra' seguire con costanza le aree ECHOSER.033 (ECHOSER.33x se moderatore di area di net) e MODERATORI.033. Dovra' inoltre leggere l'area RC&REC_NEWS.033. 3.6 Compiti del Backbone echomail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I Backbone hanno l'obbligo di veicolare tutte le conferenze BB/Routed e le echofile BFQ-R33 e ECHO-R33. Al fine di evitare confusione, si raccomanda a tutti i backbone di creare due gruppi separati, uno per le conferenze BB/Routed e uno per le conferenze non BB/Routed. Il Backbone echomail ha inoltre il dovere di provvedere immediatamente ad eventuali richieste di sconnessione di nodi da parte di un moderatore o del *EC competente. 3.7 Compiti di sysop e cosysop ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il sysop e' responsabile dei messaggi in uscita dal proprio nodo. E' compito del sysop verificare che la posta originata dal suo nodo sia conforme agli standard tecnici Fidonet. Ha inoltre il compito di assicurarsi che gli utenti del suo sistema (includendo in questo termine il sysop stesso) tengano un comportamento conforme alle policy Fidonet. Dovra' rendere disponibili ai propri utenti le ultime versioni della Policy Generale Fidonet, di quest'Echopolicy e delle varie policy d'area; i file dovranno essere disponibili in file request e/o download libero con gli stessi nomi ed alias definiti in questo documento (paragrafo 7.3). Se il sysop e' intenzionato a sconnettere una conferenza e fra i suoi utenti (o fra gli utenti dei suoi downlink) vi e' il moderatore di tale area, e' obbligato a preavvisarlo sette giorni prima per dargli modo di trovare un altro uplink. Ha infine il dovere di rispondere tempestivamente alle richieste di intervento da parte dei moderatori e di provvedere immediatamente ad eventuali richieste di sconnessione di suoi downlink (o utenti) da parte di un moderatore o del *EC competente. Qualora non possa seguire il proprio nodo, il sysop ha la facolta' di nominare uno e un solo cosysop che lo rappresentera' in tutto e per tutto (i nodi con AKA multiplo hanno sempre diritto a un solo cosysop). Il cosysop dovra' avere effettivamente tale ruolo sul suo sistema e dovra' quindi essere in grado di far fronte a tutte le richieste che provengano dai moderatori o dai coordinatori echomail. RC e REC potranno rifiutarsi di riconoscere un cosysop che non abbia effettivamente tale ruolo; potranno inoltre rifiutare di riconoscere un cosysop qualora il sysop si alterni al suo cosysop per periodi a loro discrezione troppo brevi. Il sysop (o, in sua vece, il cosysop) dovra' seguire con costanza le aree SYSOP.033, ECHOSER.033 e dovra' leggere la RC&REC_NEWS.033. 4 PROCEDURE DI ELEZIONE, NOMINA E RIMOZIONE DI COORDINATORI E MODERATORI ======================================================================== 4.1 Norme generali per i coordinatori echomail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ogni coordinatore echomail ha la facolta' di rimuovere un coordinatore di livello inferiore nel caso in cui questi violi le policy. Analogamente, il collegio di coloro che possono votare nell'elezione di un coordinatore ha la facolta' di votare per la sua rimozione. Annualmente ogni coordinatore sara' sottoposto a verifica da parte di coloro che lo hanno eletto; la verifica del REC sara' coordinata dall'RC, mentre la verifica dei NEC sara' coordinata dagli NC su procedura definita dal REC. Il fallimento di una verifica (maggioranza semplice degli aventi diritto al voto contrari all'operato del coordinatore) implichera' l'automatica rimozione del coordinatore in questione. In tutte le votazioni si fa riferimento, per le candidature e per i votanti, ai nodi attivi (quindi non Down ne' Hold) del segmento di region 33 valido il giorno precedente il primo giorno utile per la presentazione delle candidature. 4.2 Elezione del REC ~~~~~~~~~~~~~~~~~~~~ L'elezione del REC avviene secondo la seguente procedura: - il Region Coordinator (RC) indice le elezioni in collaborazione con lo ZEC, specificando la durata dei vari periodi secondo quanto qui stabilito; la votazione e' formalmente indetta dall'RC: in questa policy l'unico ruolo dello ZEC e' solo quello di fungere da collettore di voti e da arbitro per eventuali contestazioni durante le elezioni del REC; - nel periodo di candidatura (della durata minima di dieci giorni) verranno fatte pervenire all'RC le candidature, via Netmail. Sono candidabili tutti i sysop listati alla region di cui al punto 4.1; ogni candidato dovra' presentare (pena annullamento della candidatura) un programma e discuterlo in area SYSOP; sono necessarie almeno tre candidature: nel caso in cui non si raggiungessero le tre candidature e' facolta' dello ZEC prolungare il periodo di candidatura, annullare le elezioni o autorizzarne il proseguimento anche con meno di tre candidati. - sara' quindi indetto un "periodo di discussione" (della durata minima di dieci giorni) in cui i candidati discuteranno dei propri programmi; in tale periodo NC e NEC potranno sondare il parere del proprio net prima di votare, sebbene non siano tenuti a votare secondo tale indicazione; - la votazione effettiva verra' effettuata da NC, NEC e RC in Crashmail sul nodo dello ZEC; il periodo di votazione sara' di sette giorni; - concluso il periodo di votazione, lo ZEC postera' (tramite l'RC) la lista dei votanti e i risultati delle elezioni; nei successivi sette giorni ci sara' la possibilita' di effettuare, presso il nodo dello ZEC, eventuali contestazioni. Trascorso tale periodo, se non ci saranno contestazioni pendenti, lo ZEC ratifichera' la nomina. Laddove le elezioni del REC si svolgano in assenza di ZEC, l'RC ne assume le funzioni. La nomina verra' effettuata dall'RC, per poi essere ratificata all'atto della nomina del nuovo ZEC. Il mandato del REC e' di due anni, ed e' protratto finche' non e' terminata la procedura di elezione del suo successore. In caso di assenza o problemi, lo ZEC puo' nominare un REC pro tempore. 4.3 Elezione del NEC ~~~~~~~~~~~~~~~~~~~~ L'elezione del NEC avviene secondo le stesse procedure della votazione del REC, ma con le seguenti differenze: - votano i sysop del net al posto di NC, NEC e RC; puo' candidarsi ogni sysop abilitato a votare; - l'NC adempie agli stessi compiti che vengono svolti dall'RC nell'elezione del REC; - la votazione avviene sul nodo dell'NC o sul nodo di un fiduciario nominato da NC e REC; - il REC ricevera' eventuali proteste nel periodo ad esse dedicato ed ufficializzera' la nomina. Il mandato del NEC e' di due anni, ed e' protratto finche' non e' terminata la procedura di elezione del suo successore. In caso di assenza o problemi, il REC puo' nominare un NEC pro tempore. 4.4 Elezione dell'Echolist ~~~~~~~~~~~~~~~~~~~~~~~~~~ L'Echolist viene proposto dal REC e confermato dal collegio dei NEC. L'Echolist decade quando viene nominato il successore del REC che lo aveva proposto, salvo ulteriore rielezione. 4.5 Nomina di un moderatore ~~~~~~~~~~~~~~~~~~~~~~~~~~~ I moderatori di conferenza echomail possono essere nominati in due modi. Se l'area e' di tipo mod-owned, il moderatore puo', all'atto delle dimissioni, scegliere il suo successore (e' comunque utile, nella scelta, consigliarsi col REC); il moderatore puo' anche decidere in qualsiasi momento di commutare la sua area in *EC-owned. Qualora il moderatore si assentasse per venti giorni senza nominare un sostituto, l'area verra' automaticamente commutata in *EC-owned. Se l'area e' di tipo *EC-owned, il moderatore sara' nominato dal *EC competente sulla base delle candidature, del parere del moderatore uscente e di tutti i pareri che il *EC riterra' opportuno di voler valutare. Il *EC ha la facolta' di nominare dei "moderatori in prova", il cui operato sara' sottoposto a valutazione dopo un periodo scelto dal *EC all'atto della nomina, e "moderatori temporanei" durante il periodo di scelta del moderatore ufficiale. Un moderatore non potra' nominare un sostituto, ma dovra' quindi dimettersi, se deve assentarsi per un periodo superiore ai due mesi. 4.6 Rimozione di un moderatore ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il moderatore di un'area mod-owned non puo' essere rimosso. Per quanto riguarda i moderatori di aree *EC-owned, il REC ha facolta' di rimuoverli solo nei seguenti casi: - dimissioni dell'interessato, che si prega di rassegnare venti giorni prima per dar modo di scegliere il suo successore; - assenza prolungata senza nomina di un sostituto o mancata raggiungibilita' via Fidonet; - inadempienze o manifesta incapacita' di moderatori in prova; - grave violazione delle policy; in quest'ultimo caso si tratta di sospensione in attesa di un'immediata votazione secondo la procedura indicata. In tutti gli altri casi, la rimozione va votata a maggioranza semplice dal collegio echomail (in caso di parita' il voto del REC vale doppio). Sono abilitati a richiedere una rimozione un NEC e il REC su parere personale o su parere degli utenti dell'area. Se la verifica dovesse fallire, coloro che la hanno proposta non potranno avanzare un'ulteriore richiesta entro sei mesi. Fa eccezione il REC quando valuta il parere degli utenti dell'area, ma anche qui il parere dello stesso utente non potra' essere riconsiderato prima di sei mesi. 5 PROCEDURE VARIE PER LA GESTIONE DELL'ECHOMAIL =============================================== 5.1 Immissione sul Backbone nazionale di un'area non BB/Routed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Affinche' un'area non backbone sia immessa sul backbone, devono essere soddisfatti i seguenti requisiti: - l'area deve avere un nome che ne rispecchi il topic e che sia univoco nelle liste delle conferenze echomail (sia di Region che di Zona); - l'area deve essere moderata e dotata di policy; tale policy deve essere conforme sia alla Policy Generale Fidonet che a questa Echopolicy; - l'area deve avere un traffico minimo di cinque messaggi su base settimanale; il REC puo' tuttavia autorizzare eccezionalmente aree con traffico inferiore o ammettere aree con traffico inferiore imponendo che entro un periodo stabilito il traffico si stabilizzi. L'immissione di un'area sul BB e' decisa dal REC, sentito il parere del collegio echomail. L'area e' immessa come mod-owned, a meno che il collegio echomail non ne voti, motivandone le ragioni, la messa su backbone come area REC-owned: in tal caso, tuttavia, il moderatore ha la facolta' di annullare la richiesta di immissione su Backbone. 5.2 Rimozione dal Backbone nazionale di un'area ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il moderatore di un'area mod-owned ha la facolta' di decidere autonomamente la rimozione della sua area dal Backbone. Il REC puo' decidere la rimozione di un'area dal backbone nei seguenti casi: - scarso traffico; tale opzione dovra' comunque essere preceduta da un esplicito invito al moderatore a tentare di risollevare le sorti dell'area (il tempo concesso e' a discrezione del REC, in genere un mese); - impossibilita' di reperire un moderatore. Il REC puo' decidere la sospensione di un'area dal Backbone quando in essa vengano continuamente postati messaggi che violino questa policy o le leggi italiane. La sospensione e' provvisoria e va immediatamente seguita da una votazione del collegio echomail, che ne decidera' la rimozione o il reinserimento su backbone. In tutti gli altri casi, la rimozione va messa ai voti. Le votazioni si svolgeranno sul nodo del REC, e richiederanno la maggioranza semplice del collegio echomail; in caso di parita' il voto del REC vale doppio. 5.3 Chiusura di un'area *EC-owned ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Per la chiusura di un'area *EC-owned si applicano le stesse procedure applicate per la rimozione dal backbone. 5.4 Apertura di un'area direttamente sul Backbone ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sebbene la procedura consigliata sia quella di far partire le aree come non-BB/Routed e quindi di portarle su Backbone, e' tuttavia possibile chiedere l'apertura di un'area direttamente allo stato di BB/Routed. Per far cio', e' necessario avviare una discussione sulla policy d'area e sul topic nell'area ECHO_ADS.033. Una volta raggiunto un accordo sulla policy e sul topic, il REC verifichera' la corrispondenza di quest'ultima con la Policy Generale Fidonet e con quest'Echopolicy e indirra' una votazione sul nodo dell'Echolist. Possono votare tutti, ed e' necessario raggiungere venti adesioni in quattordici giorni; in caso di raggiungimento del quorum prima della scadenza, la votazione potra' essere interrotta. Le adesioni dovranno provenire da venti nodi diversi appartenenti ad almeno due net. 5.5 Provvedimenti dei moderatori ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Qualora il moderatore ravvisasse un'infrazione alla policy da parte di un utente, lo avvisera' pacatamente del suo comportamento, sottolineando in dettaglio il tipo di infrazione e chiedendogli bonariamente di attenersi alle policy. Si raccomanda un occhio di riguardo per i nuovi utenti e si ricorda che le soluzioni bonarie sono sempre da preferirsi ai provvedimenti disciplinari. Qualora l'utente continui a non conformarsi alle policy, il moderatore avvisera' il sysop del nodo da cui e' partita l'infrazione, chiedendo la sua mediazione per risolvere il contenzioso. Qualora, nonostante l'intervento del sysop, l'utente non si conformi a queste policy, il moderatore potra' richiederne la sconnessione dalla conferenza. Il sysop e' tenuto a eseguire il provvedimento di sconnessione richiesto dal moderatore; un suo eventuale rifiuto in proposito portera' automaticamente alla sconnessione di tutte le conferenze echomail dal suo nodo: tale richiesta va inoltrata al NEC del net cui appartiene il sysop. Qualora l'utente commetta una grave violazione della policy, il moderatore puo' richiedere direttamente la sconnessione dell'utente interessato. Il REC si riserva invece la facolta' di chiedere la sconnessione da TUTTE le conferenze echomail per eventuali soggetti che commettessero deliberatamente violazioni della policy in diverse aree. 5.6 Ricorsi contro i moderatori ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Per come e' inteso il sistema di moderazione Fidonet si dovrebbe cercare di non arrivare mai ad un ricorso contro un moderatore senza aver avuto prima modo di discutere col moderatore stesso sul problema in questione (in netmail). Tuttavia e' sempre possibile presentare al *EC di competenza (REC per aree nazionali, NEC per aree di net) ricorso contro l'operato di un moderatore. In tale ricorso, il *EC avra' prima di tutto il compito di tentare una mediazione fra le due posizioni e prendera' posizione solo se la situazione risultera' davvero inconciliabile. Sono abilitati a presentare un ricorso al REC i soli sysop, sebbene e' lasciata al REC la facolta' di accettare anche segnalazioni informali presentate dagli utenti. Tutti i ricorsi contro i moderatori vanno effettuati una volta eseguiti i provvedimenti disciplinari da loro richiesti. L'abuso di ricorsi contro i moderatori e' da considerarsi comportamento seccante. 6 REGOLAMENTAZIONE DELL'ECHOMAIL ================================ 6.1 Regole di base ~~~~~~~~~~~~~~~~~~ Per avere accesso alla Echomail, un utente DEVE avere accesso, in lettura e scrittura alla Netmail: di cio' e' responsabile il sysop che gli concede l'accesso. Questa e' una regola fondamentale, in quanto il mancato accesso alla Netmail impedisce il contatto fra utente e moderatore. E' consigliata anche la lettura dell'area RC&REC_NEWS.033 (obbligatoria per sysop e moderatori). Ogni nodo che riceve l'echomail dovra' ricevere obbligatoriamente le aree ECHOSER.*, (NET)SYSOP.*, RC&REC_NEWS.033, PING.033 e la echofile ECHO-R33. Sono assolutamente vietati i messaggi di carattere commerciale o di propaganda politica, eccetto in quelle aree dove sono stati espressamente autorizzati dal REC o dal collegio echomail. Sono vietati, in area, gli annunci e i post di file UU o Mime encoded senza la preventiva autorizzazione del moderatore; alcune aree possono, nella loro policy, ammettere determinati tipi di annunci o UU/Mime Encoding senza il preventivo consenso del moderatore. La crittazione dei messaggi e' vietata. Attaccare in area il moderatore, sostituirsi ad esso o rispondere in area ad un messaggio di moderazione e' da considerarsi comportamento estremamente seccante, e come tale passibile di provvedimenti. Non sono ammessi messaggi contraffatti, dal tono volutamente provocatorio, contenenti bestemmie, insulti o offese a chicchessia, linguaggio scurrile o espressioni razziste, messaggi che incitino ad attivita' illegali (tipo scambio di password), e, in genere, qualunque comportamento contrario alla legge italiana e alla buona educazione. I messaggi di prova vanno postati in aree locali; sono da evitare i messaggi del tipo "So di essere Off-Topics, ma..." e tutto il traffico privo di contenuti. Scrivere in maiuscolo equivale a parlare ad alta voce: cosi' come nella vita normale e' considerato comportamento da maleducato parlare ad alta voce, cosi' l'utilizzo eccessivo di messaggi in maiuscolo e' considerato comportamento seccante. L'uso di alias e' ammesso, ma non incoraggiato. Nessun moderatore potra' vietare gli alias nella propria policy d'area. Il forward di un messaggio da una conferenza privilegiata ad un'area ad accesso pubblico (o non Fidonet) e' considerata grave violazione della policy. Analogamente e' considerata grave violazione il reply in un'area ad accesso pubblico di un messaggio originariamente posto in una conferenza riservata (o il forward di tale messaggio in matrix a chi non sia autorizzato a leggerlo), a meno che i partecipanti alla discussione non si fossero messi d'accordo in tal senso o che il moderatore non avesse fatto esplicita richiesta di cambiare area. 6.2 Standard dei messaggi ~~~~~~~~~~~~~~~~~~~~~~~~~ I messaggi echomail devono essere dotati di Origin. La dimensione massima dell'Origin e' di 79 caratteri, ed e' preceduta dalla stringa " * Origin: " e seguita dall'indirizzo Fidonet 3D o 4D del Nodo/Point che ha generato il messaggio racchiuso fra parentesi tonde: "(zona:net/nodo.point)". Stringa ed indirizzo sono conteggiati nei 79 caratteri. Una extra origin line e' ammessa per i nodi che fungono da gateway, sara' limitata ai soli dati essenziali e conterra' la parola "Gateway". La tearline e' opzionale, preceduta dalla stringa "--- " e lunga massimo 35 caratteri, inclusi i tre trattini e lo spazio. Se presente, dovra' contenere indicazioni sul software usato e non potra' contenere motti o frasi. I SEEN-BY address devono essere in ordine di sort. Ogni nodo non puo' inserire piu' di un indirizzo nei SEEN-BY, a meno che non usi piu' indirizzi per processare l'echomail. I nodi 0 non devono essere utilizzati per processare l'echomail. Ai nodi non terminali e' vietato tagliare (strip) i SEEN-BY. La tagline (frase di fantasia preceduta da tre punti, posta fra firma e tearline) e' permessa, ma non incoraggiata. La sua lunghezza massima e' di 80 caratteri. La tagline NON fa parte della firma. La firma deve essere limitata a 120 caratteri (inclusi i CR). Le intestazioni di inizio messaggio non devono superare, in media, i 120 caratteri, tutto incluso. Il testo non dovra' inoltre contenere formattazioni. Il quote (riporto di spezzoni del messaggio originale) deve essere limitato al minimo indispensabile. Il carattere standard utilizzato per il quoting e' il simbolo ">" (maggiore di). Sono ammessi solo i Kludge (linee precedute dal carattere ASCII 1) essenziali per il normale funzionamento della rete. Sono normalmente ammessi i soli caratteri ASCII che vanno da 32 (spazio) a 126 (~ = tilde), quindi sono escluse le lettere accentate (per le quali si suggerisce l'uso della vocale seguita dall'apostrofo) e dei simboli semigrafici. Tuttavia il REC puo' autorizzare alcune conferenze ad utilizzare charset estesi. I nodi non possono alterare i messaggi in transito, se non per le variazioni a PATH e SEEN-BY consentite dagli standard FTSC in vigore. La censura automatica e' vietata e porta alla scomunica immediata del nodo che l'ha deliberatamente attuata; fanno eccezione i gateway, come descritto al punto 6.4. Sono in vigore tutti gli standard FTSC. 6.3 Proprieta' dei messaggi ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il diritto d'autore di ogni messaggio e' di chi lo scrive. E' implicito il permesso di distribuzione mediante Fidonet o qualsiasi gateway ad essa collegato, purche' non se ne alteri il contenuto e se ne specifichi la paternita'. Per la distribuzione di singoli messaggi al di fuori di questi ambiti e' necessario il consenso dell'autore del messaggio e dell'eventuale autore di spezzoni di quote; per la distribuzione di un insieme di messaggi e' necessaria, in aggiunta all'autorizzazione dei singoli autori, anche quella del coordinamento Fido. Ricadono in questa definizione anche i BOF e le FAQ d'area. 6.4 Gateway ~~~~~~~~~~~ Le policy delle aree in gateway fra due reti vanno stilate in modo che non siano in contrasto ne' con le policy di Fidonet ne' con quelle della rete in gate. Vanno inoltre stilate tenendo conto degli standard tecnici di entrambe le reti. I gateway devono essere autorizzati dal REC e dall'RC, ciascuno per la propria parte di competenze, devono essere bidirezionali e permettere anche il transito della matrix. I gateway, sotto autorizzazione del REC, possono effettuare alcuni tipi di censura automatica (antispam) sulla sola posta in gate. 7 MISCELLANEA ============= 7.1 Conferenze riservate ~~~~~~~~~~~~~~~~~~~~~~~~ Le seguenti conferenze sono riservate alla gestione di Fidonet e non potranno mai essere chiuse o rimosse dai backbone. A queste aree vanno aggiunte tutte le aree internazionali riservate dalla policy o dai coordinatori di zona. 7.1.1 SYSOP.033, (NET)SYSOP.33x (dove 33x e' il net di appartenenza) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Aree dedicate alla discussione fra sysop sui problemi relativi alla rete Fidonet. Hanno accesso a quest'area tutti i sysop listati in region ed eventuali cosysop. Ogni nodo ha diritto ad uno ed un solo accesso in scrittura: la presenza del cosysop esclude la possibilita' del sysop di scrivere in area (la lettura e' ammessa), salvo deleghe particolari dell'*C competente. Moderatore permanente: l'RC in carica (NC per aree di net). 7.1.2 ECHOSER.033, ECHOSER.33x (dove 33x e' il net di appartenenza) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Aree dedicate alla discussione fra sysop e moderatori su problemi relativi alla gestione echomail, escluse discussioni sulle moderazioni. Hanno accesso a quest'area i moderatori di aree nazionali BB/Routed, coloro che hanno accesso alla SYSOP.033 ed altre persone autorizzate dal *EC (quest'ultima ipotesi riveste pero' carattere di eccezionalita'). Moderatore permanente: il REC in carica (NEC per aree di net). 7.1.3 ECHO_COORD.033 ~~~~~~~~~~~~~~~~~~~~ Conferenza destinata al coordinamento strettamente tecnico della distribuzione echomail. Hanno accesso a quest'area RC, NC, REC, NEC, Echolist, Backbone echomail nazionali, di net e di hub. Moderatore permanente: il REC in carica. 7.1.4 COORD.033 ~~~~~~~~~~~~~~~ Conferenza destinata al coordinamento di Fidonet. Hanno accesso a quest'area RC, NC, REC, NEC ed Echolist. Moderatore permanente: l'RC in carica. 7.1.5 RC&REC_NEWS.033 ~~~~~~~~~~~~~~~~~~~~~ Conferenza dedicata alla diffusione di comunicati da parte di RC e REC e delle liste di competenza dell'Echolist. Accesso: lettura/scrittura a RC, REC ed Echolist, lettura a tutti. 7.1.6 PING.033 ~~~~~~~~~~~~~~ Area tecnica in cui il backbone nazionale inserisce ogni giorno un messaggio con numerazione progressiva, al fine di controllare che ad ogni livello non vengano persi pacchetti. Accesso: lettura/scrittura al backbone autorizzato dal REC e lettura a tutti. E' area obbligatoria per tutti i sysop. 7.1.7 MODERATORI.033 ~~~~~~~~~~~~~~~~~~~~ Conferenza destinata alla discussione delle problematiche del ruolo di moderatore e alla discussione fra i moderatori stessi. Vi hanno accesso tutti coloro che hanno accesso alla ECHOSER.033 piu' i moderatori di aree di net riconosciute dal NEC competente. 7.1.8 ECHO_ADS.033 ~~~~~~~~~~~~~~~~~~ Area in cui vengono postate e discusse eventuali proposte per la creazione di nuove aree. Accesso libero a tutti. 7.2 Come riconoscere i coordinatori ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Il REC e' facilmente individuabile dalla Region, cercando il nodo cui e' assegnato il flag [,U],REC. Esempio: ,244,The_HobBIT,Napoli,Lelio_della_Pietra,39-81-5563352,9600,XA,CM,V34,VFC, V32T,U,X75,V110H,V110L,V120L,REC Analogamente i NEC sono coloro cui e' assegnato il flag [,U],NEC. L'echolist non dispone invece di alcun flag. Il nodo dell'echolist e' l'unico in region nel cui nome compaia la parola "Echolist". Sara' compito degli NC fare in modo che non vengano assegnati nodi ad altri sistemi in cui compaia questa dicitura. 7.3 Nomi standard dei documenti ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I sysop sono tenuti a rendere disponibili le ultime versioni dei seguenti file: Descrizione File Magic di F/R Policy Generale Fidonet POLICY.ZIP POLICY Echopolicy Fidonet EPOLICY.ZIP EPOLICY Nodelist region 033 REGION33.Z?? REGION Archivio policy d'area IPA-????.ZIP IPA-LAST Archivio file amministrativi echomail ADM-????.ZIP ADM-LAST La sequenza ???? va sostituita con quattro cifre, le prime due delle quali indicanti il numero di settimana (0-52) e le ultime due l'anno di rilascio del file. 7.4 Modifica di questa policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Questa policy potra' essere modificata e sostituita dalla semplice maggioranza di RC, REC, NC e NEC. Ai sensi della policy generale, i coordinatori dovranno votare secondo l'indicazione del loro network. Pertanto la votazione dovra' essere preceduta da una consultazione (anche informale) di almeno due settimane dei coordinatori con i sysop del proprio net. Future proposte di modifica potranno essere avanzate dal REC, da due NEC o dal 25% dei sysop della region. 7.5 Disposizioni transitorie ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sono dati trenta giorni al coordinamento, ai moderatori e ai sysop affinche' vengano attuate tutte le disposizioni tecniche contenute in questa policy. Le aree attualmente su Backbone vengono tutte commutate in REC-owned. I *EC eventualmente in carica da piu' di due anni resteranno in carica sino alla successiva verifica, che verra' invece sostituita con normali elezioni. I moderatori che si sono fatti sostituire da piu' di due mesi verranno rimossi. 7.6 Ringraziamenti ~~~~~~~~~~~~~~~~~~ Si ringraziano le seguenti persone, che hanno collaborato alla stesura e alla revisione di questa policy: Denis McMahon, dalla cui bozza di policy sono stati presi interessanti spunti; Mario Mure', Giuseppe Semeraro, Happy Betty, Marcello Ardini, Antonio Locati, Marco Venturini Autieri, Raffaele Fiume e tutto il coordinamento in vigore all'atto della redazione di questa policy per le varie correzioni; tutti coloro che hanno a suo tempo partecipato alla discussione in EP.033. Lelio della Pietra, REC 2:33