POLICY ECHOMAIL FidoNet Zone 2 Region 33 01 Novembre 2019 Release 4.00 --------------------- PROLOGO Questo documento basato sulla Policy Echomail 3.0 redatta il 7 Aprile 1990 da Stefano Pasquini detta le regole e governa tutte le conferenze Echomail e GroupMail nonche' la loro circolazione e distribuzione. Tale Policy riguarda tutte le conferenze Echomail e GroupMail circolanti nella Region 33 e tutte quelle che il singolo moderatore vorra' sottoporvi. Cosi' ad esempio una conferenza Echomail nata sotto FidoNet ed esportata ad altro Network ricadra' sotto questa policy. Altrettanto le conferenze provenienti da altri Network importate in FidoNet. Tutto quanto sancito in questo scritto non e' in nessun punto contrario alle Policy generale Echomail e FidoNet, che compendia ed affianca, ed alle quali si rimanda per ogni carenza di disposizioni. Future modifiche alla Echo Policy potranno essere richieste al REC da una semplice maggioranza di Net Echomail Coordinators (NECs), o da almeno il 25% dei SysOps nella Region; abile a votarle sara' l'intera struttura *Cs (HCs ed, eventuali, HECs esclusi) con voto matrix presso il nodo del REC. Un solo voto per persona e' valido anche se ricopre piu' cariche. L'adozione delle proposte di cambiamento richiedera' la semplice maggioranza dei voti. I NECs effettueranno sondaggi riguardanti le eventuali proposte di variazione alla Echo Policy nei rispettivi Net e ne faranno pervenire i risultati, via Netmail, al nodo del REC, almeno due settimane prima della votazione; di essi si terra' conto per le modifiche da apportare. La menzionata "semplice maggioranza" sta a significare il 50 per cento piu' uno degli aventi diritto al voto. Tutto il possibile dovra' essere fatto sia per far conoscere a tutti, SysOps e potenziali votanti, le necessarie informazioni, sia per avere il piu' alto numero di suffragi. I riferimenti agli *ECs riguardano il Regional Echomail Coordinator, l'Echolist Coordinator ed i Net Echomail Coordinators; quello agli *C oltre ai precedenti si riferisce al FidoNet Regional Coordinator ed i FidoNet Net Coordinators. La procedura di votazione adottata sara' quella relativa all'approvazione della Policy generale FidoNet riportata alla situazione particolare (Policy 4.8 sezione 8 paragrafi da 1 a 6). I. CENNI STORICI L'Echomail consiste nella condivisione di una o piu' basi messaggi, chiamate conferenze, tra vari nodi in uno o piu' Networks. Il concetto parte con una serie di programmi di Jeff Rush. Gia' dall'inizio diversi autori scrissero programmi che evolvevano dall'idea originale (vedi anche il recente GroupMail). L'Echomail ebbe un tale successo che il network rischio', con l'aumento a dismisura di tale flusso, di cadere sotto il suo stesso peso (dato che Echo e Netmail viaggiavano insieme). Risolsero tali problemi la creazione di backbone echo per la distribuzione a qualsiasi livello e l'adozione di software piu' sofisticato. La stella era il metodo piu' usato e quello che garantiva la piu' alta semplicita' d'uso, ma non altrettanta sicurezza nel caso di down prolungato del suo apice. L'evolversi di tale discorso rese necessarie delle norme di regolamentazione, nascevano cosi' i vari livelli di coordinamento e le Policy per governarlo. II. DEFINIZIONI 1. ECHOMAIL & GROUPMAIL: Il processo di condivisione di una base messaggi che parte da un sistema con indirizzo di Net/Node. 2. CONFERENZE ECHOMAIL: Una conferenza Echomail e' una specifica base messaggi distribuita tra un certo gruppo di nodi, con un apposito nome e che riguarda un gruppo di interesse ben definito. 3. CONFERENZA MODERATA: Una conferenza Moderata e' una conferenza Echomail per la quale sia stato nominato un moderatore che ne controlli flusso e contenuti. Tutte le conferenze nazionali DEVONO essere moderate. 4. CONFERENZA PRIVILEGIATA: Una conferenza privilegiata, e'una conferenza per la quale il moderatore o il coordinatore echo competente ha deciso che sia resa disponibile solo a determinate persone, ad esempio solo ai Sysops e non agli utenti. 5. CONFERENZE A DISTRIBUZIONE RISTRETTA: Sono delle conferenze disponibili solo per determinati nodi. Ad esempio la ECHO_COORD, La conferenza nazionale coordinatori echomail. 6. REGIONAL ECHOMAIL COORDINATOR (REC): Responsabile per il coordinamento Echomail nella Region. 7. NET ECHOMAIL COORDINATOR (NEC): Responsabile per il coordinamento Echomail nel singolo Net 8. ECHOMAIL Backbone: Volontari che contribuiscono al servizio di distribuzione nazionale dell'Echomail. I nodi che fanno da Backbones sostengono un grosso volume di traffico echo da garantire ai livelli piu' bassi di distribuzione nella region. 9. NATIONAL ECHOMAIL LIST: Identifica le conferenze nazionali disponibili, i moderatori ed i requisiti della singola conferenza. La sua nomina avviene con la stessa procedura dell'elezione del REC. Tutti i SysOps possono candidarsi. Il REC definisce gli ulteriori compiti del National Echomail List. 10. CENSURA AUTOMATICA: programma che altera il contenuto o rimuove i messaggi automaticamente da una determinata conferenza. 11. FIDONET POLICY: Il documento su cui e' basata FidoNet ed a cui e' sottoposta questa Policy. Si fa qui riferimento alla Policy 4 generale (e successive) ed alla Policy33 italiana. Finche' la Policy FidoNet non la comprendera' questo intende essere un compendio ad essa riguardo l'Echomail. 12. CONFERENZA AD ACCESSO LIBERO: Conferenza aperta a tutti gli utenti che si impegneranno a seguirne le regole. 13. NODO TERMINALE: Nodo che non fa il forward dell'Echomail per altri sistemi. 14. REGIONAL ECHOMAIL WATCHER: Individua eventuali anomalie ed incongruenze delle routes decise (nazionale, di net etc.), e ne da comunicazione agli *ECs via Netmail. Controlla l'andamento generale delle varie aree e lo fa presente ai vari moderatori nazionali; la corretta gestione dei points dal punto di vista echo. Non ha compiti di coordinamento ma di ispezione, ha accesso all'area ECHO_COORD (coordinamento tecnico backbones), puo' immettere periodicamente messaggi di test nelle varie conferenze. Viene nominato dagli *ECs. III. COMPITI DEI COORDINATORI ECHOMAIL 1. IN GENERALE: In generale, e' compito degli *ECs rendere disponibile ad ogni SysOp le conferenze che sono autorizzati a ricevere. Se l'*EC non ha accesso o la disponibilita' di tali conferenze dai normali canali di distribuzione, egli non e' obbligato a farle avere al SysOp che le richiede. Se un *EC rende disponibili a tutti i livelli piu' bassi delle conferenze qualificate o ristrette, senza riguardo alla riservatezza, avra' violato la Policy FidoNet per eccessivo annoying; vi si applicheranno le sanzioni sancite da questa Policy, sara' richiesto l'intervento dei coordinatori FidoNet e potra' essere rimosso dal suo incarico. Nella distribuzione Echo e' possibile attuare una condivisione di costi, che dovra' essere approvata dagli *ECs; se questa non e' utilizzata, tutte le conferenze disponibili sui backbone dovranno essere distribuite liberamente su richiesta (ma con attenzione particolare le conferenze ristrette o qualificate). Un *EC deve assicurarsi che tutti i sottoposti al suo coordinamento 1) Rispettino le Policy Echomail (Questa e quella generale) 2) Sappiano come agganciarsi alle conferenze Echomail 3) Sia loro spiegato il comportamento accettato e quello non accettato nelle conferenze Echomail 4) Non attuino delle route che aumentino il rischio di duplicazione di messaggi. 2. COMPITI DEL REGIONAL ECHOMAIL COORDINATOR: E' compito del REC coordinare la distribuzione di tutte le Regional Echomail Conferences; disegnare la route della Region ed assegnarne i links in modo da eliminare la possibilita' di duplicati; aprire e nominare le nuove aree; inserire aree locali nel circuito nazionale; autorizzare l'importazione di nuove aree internazionali e rendere attuabili sotto la supervisione dello ZEC link tra piu' Region; far rispettare le disposizioni dei documenti di Policy a livello di Region. Egli su richiesta dello ZEC a scadenza quadrimestrale rendera' disponibile in file-request, una relazione sulla situazione Echomail interna alla Region (ECHOSTAT.R33) redatta in base a quelle fornite trimestralmente dai NECs. 3. COMPITI DEL NET ECHOMAIL COORDINATOR: E' compito del NEC coordinare la distribuzione all'interno del singolo Net delle conferenze Echomail; curarne ed organizzarne la route. Il Regional Echomail Coordinator puo' richiedere al NEC di linkare per la distribuzione i nodi indipendenti nella Region. Il NEC manterra' una lista delle conferenze disponibili nel Net, una lista aggiornata e dettagliata dei relativi links, nominera', se lo riterra' opportuno, un moderatore per ogni conferenza di Net (non nazionale), e comunichera' il tutto all'Echolist ed al REC. Egli su richiesta del REC a scadenza trimestrale inviera' una relazione, al REC sotto forma di file, sulla situazione Echomail interna al Net (es. NETST335.001 per il primo trimestre, NETST335.002 per il secondo etc.). Il NEC fa' rispettare le disposizioni dei documenti di Policy a livello di Net. 4. COMPITI DELL'ECHOLIST COORDINATOR: E' compito dell'Echolist Coordinator, compilare e rendere disponibile una lista di tutte le conferenze disponibili siano esse nazionali, internazionali e locali (ECHOLIST.R33). Il formato della lista sara' a discrezione dell Echolist, ma dovra' contenere il nome dell'area (tag), la relativa descrizione, il nome del moderatore, i nodi linkati (fatti pervenire a scadenza regolare dai NEC) lo stato del traffico della conferenza ed i requisiti necessari per esservi ammessi (materiale fornito dai vari moderatori di area). Egli curera', altresi', il database contenente i dati dei SysOps e CoSysOps autorizzati all'accesso all'area SYSOP e dei rappresentanti Echo per singolo nodo, che accedono all'area di servizio Echomail (ECHOSER). 5. COMPITI DEL MODERATORE DI CONFERENZA ECHOMAIL: Sara' compito del Moderatore di Conferenza Echomail metter in atto ogni ragionevole sforzo per non far circolare nella conferenza a lui affidata messaggi che promuovano o incitino attivita' illegali; dovra' fare il possibile perche' ogni messaggio circolante sia proprio della conferenza in questione, per contenuto e per forma. Il Moderatore di Conferenza Echomail riportera' (complain) ogni violazione esplicita e grave delle Policy all'appropriato *EC (a seconda del Net di competenza del violatore); egli porra' mensilmente nella conferenza stessa le norme che la regolano; e' autorizzato a chiedere la sconnessione di utenti dalla conferenza a lui affidata; avvertira' il singolo SysOp della eventuale non attinenza alle policy da parte dei suoi utenti, sara' il solo giudice della conferenza e per le sue decisioni ci si potra' appellare solo al REC. Il Moderatore puo' richiedere direttamente (via Netmail) all' *EC di competenza la disconnessione di un nodo dalla conferenza da lui moderata, ove questi non si adegui, dopo 3 avvertimenti, alle norme pubblicate in area dal moderatore stesso. Ogni SysOp che effettuera' il forward di una conferenza, verso un nodo (o point) fatto sganciare dal moderatore, sara' a sua volta sganciato e verra' inoltrata richiesta, al coordinatore FidoNet competente, di Down nella Nodelist FidoNet per eccessivo annoying. La durata di ogni sospensione sara' decisa dal moderatore stesso in accordo con il competente *EC. Ogni lamentela (complain) riguardante le conferenze Echo, da parte dei SysOps, va spedita al NEC di competenza e, nel caso di nodi indipendenti, direttamente al REC. Il NEC o il REC ricevuto il "complain" prenderanno provvedimenti in base alle Policy Echo. Nel caso di infrazioni molto gravi o di eccessivo annoying il REC o i NEC possono far riferimento alle Policy FidoNet generale e di Region chiedendo l'intervento dei competenti organi di coordinamento. IV. NOMINA ED ELEZIONE DEI COORDINATORI E MODERATORI ECHOMAIL. 1. ELEZIONE DEL REGIONAL ECHOMAIL COORDINATOR: Su base annuale verra' ridiscussa la carica ed analizzato il suo operato. Una eventuale sostituzione potra' essere richiesta dalla maggioranza di NECs, NCs, RC ed Echolist. Se rimosso o dimissionario, il REC sara' eletto come segue: a) al FidoNet Regional Coordinator (RC) saranno fatti pervenire almeno 3 nominativi di candidati all'elezione via Netmail. (possono candidarsi tutti i SysOps nella Region). Egli li comunichera' direttamente allo Zone Echomail Coordinator (ZEC). b) 10 giorni dopo sara' aperta l'elezione direttamente sul nodo dello ZEC in Netmail-crash. Il REC sara' eletto da una semplice maggioranza dei voti dagli NCs NECs RC della Region FidoNet. Chi copre piu' cariche di coordinamento ha diritto ad un solo voto. c) una settimana dopo si chiudera' la consultazione, il FidoNet Regional Coordinator chiedera' i risultati allo Zone Echomail Coordinator e li comunichera', oltre all'eletto via Netmail, in area SYSOP ai SysOps della Region. 2. ELEZIONE DEL NET ECHOMAIL COORDINATOR: Il NEC sara' eletto da tutti i nodi del Network con votazione presso il FidoNet Net Coordinator (NC) con stesso procedimento tenuto per l'elezione del REC. Ove questo non venga eletto entro 30 giorni, verra' nominato dal REC (possono candidarsi tutti i SysOps nel Net). Anche il NEC e' soggetto a verifica su base annuale da parte dei SysOps del suo Net. 3. RIMOZIONE DI UN *EC: Un *EC puo' essere rimosso dal suo incarico dal coordinatore piu' in alto. La maggioranza degli abili a votarne il successore puo' chiederne la rimozione al coordinatore piu' in alto. Ad esempio nel caso di un NEC, la maggioranza dei nodi del Net possono chiederne la rimozione direttamente al REC in Netmail. Un *EC puo' essere richiamato o rimosso solo per inadempienza ai suoi compiti sanciti da Policy, o per non essere membro di FidoNet (inabile a ricevere Netmail-FidoNet). 4. RICONOSCIMENTO DELLE CONFERENZE: Ogni *EC riconosce le conferenze per il suo livello, cosi' il NEC riconosce le conferenze locali e di Net, il REC quelle di Region. 5. RIMOZIONE DI UN MODERATORE DI CONFERENZA ECHOMAIL: Un moderatore di conferenza Echo puo' essere rimosso per dimissioni o per gravi inadempienze. Le eventuali dimissioni devono essere comunicate via Netmail al REC ed all'Echolist Coordinator almeno 20 giorni prima per dar modo di sceglierne il successore. Nel caso di moderatore di area di Net le dimissioni andranno comunicate al NEC competente. Un moderatore puo' essere rimosso con un voto di maggioranza della struttura *EC; tale votazione dovra' essere notificata almeno 10 giorni prima e verra operata congiuntamente sia in Netmail (nodo del REC) che in area COORD. In casi estremi il REC puo' procedere alla rimozione. Ogni variazione riguardante i moderatori va portata a conoscenza dell'Echolist per l'aggiornamento del relativo database. Un Moderatore puo' essere rimosso solo nel caso venga meno ai suoi compiti; contravvenga palesemente od in modo premeditato ai dettami di questa Policy o di quella generale. Se egli si assenta dai suoi compiti per un periodo di 1 mese o piu' senza avvertire o designare un sostituto potra' essere richiamato direttamente dal REC o da un suo delegato. I moderatori possono anche non essere membri FidoNet anche se cio' e' raccomandato. V. DISPOSIZIONI DI POLICY 1. BASI DELLA POLICY ECHOMAIL: Sta alla base della Policy Echomail promuovere la comunicazione nelle conferenze Echo secondo delle regole amichevoli che seguono gli stessi principi generali di FidoNet. 2. ATTIVITA' ILLEGALI: Ogni nodo che consapevolmente distribuisce o permette l'inserimento in Echo di messaggi il cui contenuto tende a promuovere attivita' illegali, od a diffondere informazioni riservate, sara' reo di aver violato oltre a questa, anche la Policy generale FidoNet per comportamento troppo seccante (annoying). "Attivita' illegale" come qui inteso, sta' a significare ogni violazione dei codice civile e penale (scambio password, programmi Copyright etc.) o comportamento criminale che possa arrecare danno ai SysOps in termini legali. 3. CENSURA AUTOMATICA: L'uso della censura automatica nella distribuzione Echomail e' da considerarsi come una violazione della Policy e non sara' tollerata. Le azioni disciplinari potranno riferirsi anche alla Policy FidoNet per la parte concernente il comportamento eccessivamente seccante (annoying) e richieste ai relativi coordinatori. Un eccezione a questa norma sara' la cancellazione (non la censura), di messaggi che potrebbero portare ad azioni legali verso i SysOps. Nessun messaggio Echomail puo' essere modificato in modo tale da renderne possibili duplicati. e' inoltre proibito lanciare copie dello stesso messaggio in piu' aree Echomail. 4. CONFERENZE INTER-NETWORK: Alle conferenze inter-network saranno applicabili tutti i provvedimenti della Policy FidoNet e di questa Policy con l'aggiunta di quelli eventualmente vigenti nel network. 5. SPESE PER LA DISTRIBUZIONE: Ogni entita' che trae profitto dalla distribuzione dell'Echomail (passaggio da sistema a sistema), potra' essere accusato di eccessivo annoying e riportato a quanto previsto nella Policy generale FidoNet. Profitto come inteso in questo paragrafo e' la spesa per la distribuzione dell'Echomail che eccede il costo effettivo nel dato periodo o l'eventuale spesa non autorizzata dalla maggioranza degli *ECs. Il costo dell'equipaggiamento utilizzato per la distribuzione non potra' essere conteggiato. Un SysOp che fara' pagare l'accesso agli utenti del suo BBS NON violera' questo paragrafo. 6. CONFERENZE A DISTRIBUZIONE RISTRETTA: I nodi che partecipano a questo tipo di conferenze dovranno rispettarne il carattere stesso di conferenza ristretta. La violazione di tale restrizione da parte di nodi o points, sara' considerata una violazione di questa Policy Echomail e portera' alla immediata sospensione del link dalla conferenza in questione in accordo con quanto riportato nella sezione riguardante i compiti del Moderatore di Conferenza Echomail. Una conferenza per soli SYSOP sara' disponibile SOLO ai SysOps ed (eventualmente) CoSysOps di FidoNet, o di altro network con il quale tale conferenza e' condivisa. Una violazione delle restrizioni ad una Conferenza a Distribuzione Ristretta sara' violazione di questa Policy se e solo se il moderatore ha posto e specificato le restrizioni che regolano la conferenza stessa. 7. PATH RICHIESTO: La Path-Line originariamente implementata dalla SEA e' obbligatoria. Se lo scanner Echomail supporta la Path-line questa dovra' essere abilitata immediatamente oppure sostituito. Se uno scanner Echomail non supporta la Path-line e non puo' essere sostituito, avra' un periodo di 60 giorni dall'approvazione di questa Policy per eventuali modifiche; dopo tale data gli *ECs dovranno rifiutare di accettare/distribuire echomail ad ogni nodo, con quel software che non supporta path-line. L'indirizzo dei points e' accettato in path-line anche nel formato completo "Net/Node.point". 8. SEEN-BY LINE: Per la stessa concezione attuale di funzionamento dell'Echomail la linea di SEEN-BY e' importantissima per ridurre il pericolo di messaggi duplicati. Non e' permessa l'eliminazione di tale linea se non previa autorizzazione del REC in accordo con lo ZEC (Echogate Inter-Network o International Outbound-Echogate). Per la violazione di tale disposizione, saranno richiesti, ai relativi coordinatori, provvedimenti in riferimento alla Policy Generale FidoNet per la parte relativa all'eccessivo annoying. 9. CONTRAFFAZIONE DI MESSAGGI: Il porre o consapevolmente distribuire messaggi contraffatti o falsificati sara' considerato comportamento eccessivamente seccante (annoying) e perseguito secondo Policy. Per messaggio contraffatto s'intende ogni messaggio immesso con un nome appartenente ad altra persona o indirizzo non appartenente al sistema da cui parte, con il chiaro intento di ingannare coloro che lo riceveranno circa il vero autore. Non saranno ammessi messaggi contraffatti, consapevolmente provocatori, che possano accendere flames, od offensivi per i partecipanti alla conferenza, con il chiaro intento di ingannare gli altri sulla vera identita' dell'autore. 10. RESPONSABILITA' DEL SYSOP: E' compito di ciascun SysOp fare ogni ragionevole sforzo perche' gli utenti del suo sistema adeguino il loro comportamento a quanto sancito in questo documento di policy. Ogni SysOp sara' considerato responsabile per gli atti compiuti dai suoi utenti e points finche' non dimostrera' di aver compiuto ogni ragionevole sforzo per evitare la violazione della Policy. 11. SOFTWARE ECHOMAIL: Lo scambio dell'Echomail puo' avvenire in qualsiasi formato di compressione purche' sia accettato da entrambe le parti. Si raccomanda di non utilizzare software che opera un sort nei pacchetti stessi (es. LHARC, PKXARC), . Ove non esistano accordi diversi verra' utilizzato a default il formato di ARC 5.1 della SEA (no Squashing). L'uso continuativo, di software per l'Echomail, non accettato da entrambe le parti in causa e che rechi danno alla distribuzione stessa, sara' passibile dei provvedimenti disciplinari sanciti in questa Policy. Esempi di software inaccettabile sono ad esempio quelli che creano pacchetti non processabili dai sistemi riceventi, favoriscono messaggi duplicati o ne falliscono il forward ai propri links, eliminano senza autorizzazione (Tiny-Seenby) o nascondono con un ^A la linea di Seen-By. L'uso di software non conforme agli standard minimi dettati dalla FidoNet Technical Standard Committee (FTSC), sara' passibile dei provvedimenti disciplinari previsti in questo documento. 12. HOST-ROUTING DELL'ECHOMAIL: Il passaggio dell'Echomail via Host non e' ammesso se non previo accordo tra gli interessati ed autorizzazione degli organi di coordinamento Echo-FidoNet. Fanno eccezione alcune aree di coordinameto quali la SYSOP.ITA e ECHO_COORD.ITA che per la loro peculiarita' possono considerarsi alla stregua di messaggi Matrix in Carbon Copy e possono, previa autorizzazione dell'RC, essere, tutte o in parte, host-routed insieme alla Netmail durante la Zone Mail Hour. 13. FORWARD DELL'ECHOMAIL DURANTE LA ZONE MAIL HOUR: Il forward dell'Echomail durante la Zone Mail Hour e' passibile di provvedimenti disciplinari per eccessivo annoying. Unica eccezione le aree di coordinamento sopra menzionate che, previa autorizzazione (RC-REC) ed accordo tra i links, possono circolarvi per i motivi sopra esposti. Questa regola non viene presa in considerazione in quanto non essendoci piu' nodi pstn/isdn in italia la ZMH non e' piu' necessaria. 14. CONFERENZE INTER-NETWORKS: La policy generale FidoNet incoraggia le conferenze TRA NETWORKS. E' compito di questa policy regolarne il flusso o la rimozione dei links diversi da FidoNet che possano inficiarne la distribuzione nel suddetto Network. Tali conferenze sono mantenute ed operano in FidoNet in modo da non interferire con le regole Echomail vigenti nell'altro Network. 15. MESSAGGI DIFFAMATORI: Il porre messaggi diffamatori nelle varie conferenze, portera' all'applicazione dei provvedimenti disciplinari previsti in questo documento. Il circostanziare i fatti non e' considerata violazione a questa sezione. 16. AGGIUNTA O RIMOZIONE DI CONFERENZE DAI BACKBONES: Una conferenza puo' essere aggiunta o rimossa dai backbones (sia nazionali che internazionali) su richiesta del relativo Moderatore dopo un analisi sul suo stato di traffico da parte degli *ECs, oppure su richiesta di almeno 2 NECs; puo' essere rimossa anche per mancanza di traffico. Una commissione composta dagli *ECs fara' una analisi dello stato delle conferenze sui backbones ogni 3-4 mesi. Per le aree che non presentino un minimo di 10 messaggi a settimana per almeno 2 mesi sara' chiesto al relativo moderatore un resoconto e di stimolarne traffico e contenuti, se cio' non avra' effetto, la conferenza potra' essere rimossa dal backbone di distribuzione. Ogni operazione di aggiunta o rimozione di conferenze sui backbones, e riguardanti in qualsiasi modo la route nazionale riconosciuta, dovra' essere autorizzata dal REC; cosi' come modifiche sui backbones e routes di Nets saranno autorizzate dai singoli NECs. 17. TOPOLOGIA E MESSAGGI DUPLICATI: La topologia della route echo a livello di Region e' decisa e messa a punto dal REC, dopo consultazione con i vari coordinatori Echomail, in quanto links impropri potrebbero generare messaggi duplicati; quelle di Net verranno messe a punto dai NECs, sentiti i SysOps del Net. Alcune conferenze nazionali tipiche potranno essere esportate con l'autorizzazione dei RECs delle Region interessate e dello ZEC. La route echo terra' conto del piu' basso costo e della massima velocita' correlati tra loro per la massima efficenza. Se il REC ha ragione di ritenere che determinati links possono portare alla generazione di duplicati puo' risolverli immediatamente. Ogni SysOp che si ostini consapevolmente a creare links che potrebbero creare duplicati e si rifiuti di eliminarli nonostante il richiamo del competente NEC o del REC, sara' soggetto alle azioni disciplinari previste in questo documento. 18. STANDARD DEI MESSAGGI: Fino ad eventuale rinnovamento da parte della FidoNet Technical Standards Committee i seguenti standards per i messaggi sono adottati: a) I caratteri ad otto bit (ASCII 128-255) ed i codici non stampabili (ASCII 2-31) sono proibiti, eccetto l'uso di 8dh (carattere soft) per FTS-0004. E' consentito l'utilizzo dell'UTF-8. b) L'Origin-line e' limitata a 79 caratteri comprensivi in fondo del proprio indirizzo di Network nel seguente formato racchiuso da parentesi tonde e con ".Point" opzionale: (Zone:Net/Node.Point). c) La Tear-line e' limitata a 35 caratteri inclusi i trattini e lo spazio "--- ", e' sempre richiesta. Questa puo' contenere SOLO l'identificativo del Packer o dell'Editor usato. Non sono ammessi motti firme o multiple tear-lines. d) Un Extra origin-line e' ammessa solo per i nodi che operano come gate per altri Network. Essa sara' limitata solo alle informazioni essenziali e conterra' la parola "Gateway". Ad esempio: " * Origin D'BridgeNet Gateway (1:1050/22)" e) I SEEN-BY address devono essere in ordine di sort. Non devono contenere gli AKAs a meno di non utilizzare piu' indirizzi per processare la mail, o per un mese successivo ad un cambio di indirizzo. Il nodo 0 non dovra' essere utilizzato per processare Echomail. f) Tutte le specifiche FTSC correnti sono in vigore. g) I messaggi in tutte le aree Echomail non devono MAI aver settato il flag "Private". VI. APPLICAZIONE DELLA POLICY: L'applicazione di questo documento segue le disposizioni della Policy generale FidoNet. Le lamentele (complain) concernenti violazioni Echomail possono essere esposte da colui che le constata, al moderatore della conferenza interessata o ad ogni livello di Echomail coordinator in ordine di competenza. Tutte le lamentele presentate in vigenza di questa policy devono esser presentate entro 60 giorni dalla data dell'infrazione riscontrata ed inviate in Netmail FidoNet; esse saranno analizzate secondo quanto previsto nelle varie Policy. L'applicazione di questa Policy e' immediata. Si invita a rendere conforme ad essa ogni tipo di software entro 60 giorni. Una ulteriore proroga di 30 giorni puo' essere concessa a discrezione del REC se le motivazioni sono chiare e documentate. L'uso, dopo tale periodo, di software non ammesso sara' considerato eccessivamente annoying. VII. ADOZIONE DELLA POLICY 1. ADOZIONE: Questa Policy iniziera' ad aver effetto dopo una ratifica da parte di una semplice maggioranza di chi e' ammesso a votarla. Possono votare RC, REC, NCs, NECs ed Echolist. Un solo voto e' valido da parte di persone che coprono piu' di un ruolo. 2. MODALITA' DI APPLICAZIONE: Entro 30 giorni dall'adozione di questa policy tutte le conferenze Echomail (di Region o di Net) dovranno avere il loro moderatore. I moderatori nazionali saranno nominati dal REC tra gli eventuali volontari. Se volontari non esistono verranno richiesti nell'apposita area di servizio echo (ECHOSER); se nonostante cio' non sara' possibile nominare un moderatore per la conferenza, questa verra' immediatamente ritirata e non sara' piu' possibile utilizarne il nome. Se qualcuno continuera' ad utilizzarlo sara' perseguito per comportamento eccessivamente seccante. I SysOps che non si adegueranno nei tempi stabiliti, o non rispetteranno le disposizioni sancite in questa Policy, saranno sganciati da tutte le conferenze Echomail e saranno loro applicabili i provvedimenti previsti dalla Policy generale FidoNet per l'eccessivo annoying (Down in nodelist FidoNet se i relativi coordinatori lo riterranno opportuno). Chi nonostante le disposizioni dei coordinatori ai vari livelli continuera' a favorire tali SysOps (forward Echo, passaggio di conferenze riservate etc. etc.), sara' anche lui perseguibile sia per questa Policy che per quella generale FidoNet. VIII. STRUTTURA DEI BACKBONES Questa sezione e' solo informativa. Si danno solo alcune indicazioni sulla attuale struttura ed operativita' dei Backbone, che potra' essere cambiata senza modifiche a questo documento, ma verra' riportata in dettaglio su un allegato successivo ed in distribuzione sul nodo del REC (ECHROUTE). In testa al network di distribuzione Echomail italiano ci sono le cosidette "Stelle" che possono essere dedicate anche esclusivamente alla distribuzione Echo. Le Stelle operano a discrezione e sotto la direzione del REC. Attualmente vi sono 2 stelle per la distribuzione Echo su territorio nazionale, seguite da almeno altre 5 stelle riguardanti ognuno dei 5 Nets (consigliate 2 stelle per Net). Ciascuna stella avra' un piano articolato per i backups di sicurezza. Ognuno dei links di Net su uno dei backbones puo' agganciarsi "In Emergenza" sull'altro, ove il primo sia down per un tempo prolungato. Slots e password di link concordati precedentemente, per l'emergenza, ne garantiscono la sicurezza sia rispetto al down che all'eventuale perdita di messaggi. Il REC e' responsabile per la distribuzione su scala nazionale mentre i NEC lo sono per quella relativa a ciascun SysOp nel loro Net. Il REC ed i NECs possono creare degli Hubs echo per facilitare la distribuzione (non necessariamente corrispondenti a quelli FidoNet), ma non possono demandare ad essi i loro compiti e responsabilita'. I Backbones operano in "Mail Only" per tutta la durata degli slot di distribuzione. Questo e' piu' o meno il metodo di distribuzione, anche se non sempre seguito esattamente. Tutti gli *ECs potranno disporre, per aumentarne l'efficenza diminuendo i costi, di modem ad alta velocita', di Hubs con sponsorizzazioni particolari, di reti a pacchetto etc. etc. XI. VARIE 1. CONFERENZE PRIVILEGIATE DI COORDINAMENTO, PECULIARITA': Conferenze privilegiate di coordinamento sono: SYSOP.ITA, ECHO_COORD.ITA e REGCON.EUR. Le suddette, per loro natura, possono (tutte o in parte) essere distribuite secondo una route a se stante diversa da quella di tutte le altre conferenze Echomail; quelle riguardanti la Region 33, vengono moderate di comune accordo dall'RC e dal REC, in linea con quanto eventualmente discusso in conferenza coordinatori; le singole NETSYSOP.33x sono moderate dai corrispondenti NC e NEC del Net interessato. L'accesso alle attuali conferenze privilegiate e' cosi' regolato: COORD = Accesso esclusivo ed individuale (lettura - scrittura) ad RC, REC, NCs, NECs, Echolist (no CoSysOps). Scopo: coordinamento della Region sia dal punto di vista FidoNet che Echomail. SYSOP = Accesso esclusivo (lettura - scrittura) ai presenti, ed attivi in Netmail (ZMH) e nella Nodelist ufficiale FidoNet compilata da IFNA (no Down, no Hold). Puo' esser concesso l'accesso ad un solo CoSysOp per nodo a patto che abbia realmente tale ruolo e livello sul sistema interessato. (stesso livello e privilegi del SysOp) Egli sara' autorizzato personalmente da REC ed RC dopo consultazione dei coordinatori ai vari livelli. La lista dei SysOps e CoSysOps verra' curata dall'Echolist Coordinator. Per l'ammissione all'area SYSOP i CoSysOps dei relativi nodi dovranno farne richiesta via Netmail congiuntamente ai nodi del REC e dell'RC con presentazione da parte del loro SysOp (quello citato in nodelist) ed inviando i loro dati anagrafici reali secondo un modello precedentemente preparato. Tali dati in caso di ammissione verranno comunicati all'Echolist Coordinator che li inserira' in un database disponibile per il File-Request sul proprio nodo e su quello degli *Cs. I SysOps gia' presenti in Nodelist dovranno anche loro nel termine di 60 giorni dall'entrata in vigore di questa Policy inviare i loro dati dettagliati (sempre secondo un database preparato), all'RC al REC ed all'Echolist per l'inserimento nel database dei SysOps e CoSysOps FidoNet, anche quello in File-Request sui nodi dei *Cs. Eccezionalmente, a discrezione di REC ed RC (sentiti i pareri in area coordinatori), se SysOp e CoSysOp ufficiali dovessero assentarsi per un lungo periodo, potra' essere ammesso un CoSysOp-Temporaneo con lo stesso procedimento sopra descritto e con l'eliminazione dello stesso quando le precedenti condizioni vengano ripristinate; nel periodo di permanenza del CoSysOp-Temporaneo, l'altro non potra' accedere all'area. Si invita quindi a scegliere con oculatezza i propri collaboratori. Scopi: tavola rotonda permanente tra SysOps per migliorare il coordinamento delle strutture Fido-Echo. E' obbligatoria per tutti coloro che hanno attive aree Echomail. ECHOSER = Accesso esclusivo in lettura/scrittura ad un solo rappresentante Echo per nodo (SysOp o suo rappresentante Echo), ai vari *Cs, Echolist, REW ed ai moderatori nazionali di area Echo. In sola lettura e' accessibile anche ai moderatori di area sui singoli BBS. Scopi: Area di servizio per tutte le problematiche strettamente Echomail, comunicazioni tra moderatori e coordinatori, nuove disposizioni da parte dei *ECs. E' obbligatoria per chiunque abbia attiva anche una sola area Echomail di qualsiasi genere (sia essa locale, di Net, nazionale, internazionale). Tutte le comunicazioni UFFICIALI vanno poste anche in Netmail al coordinatore competente (apertura nuove aree, candidatura e nomina moderatori, cambiamenti routes, nazionalizzazione aree, cambiamento nome aree, etc. etc.). Il rappresentante Echomail di nodo non dovrebbe, se non in casi di estrema urgenza, inserire in quest'area, messaggi di segnalazione inerenti consigli di comportamento, verso utenti di conferenze non direttamente da lui moderate a livello nazionale; si consiglia di scambiare tali messaggi via Netmail; nei casi di recidivita' palese il moderatore nazionale interviene direttamente in ECHOSER. ECHO_COORD = Accesso esclusivo individuale (no CoSysOps) ad RC, REC, NCs, NECs, Echolist, Regional Echomail Watcher, Backbones Echomail riconosciuti dalla struttura *ECs. Scopi: coordinamento strettamente tecnico dei backbone, testaggio dello stato della route a tutti i livelli, sintesi delle relazioni trimestrali dei NECs sullo stato dell'Echomail di Net, sintesi della relazione quadrimestrale del REC sullo stato dell'Echomail nazionale. EECH = Accesso esclusivo in lettura-scrittura a ZEC Echolist Europe e RECs, puo' esserne, eccezionalmente, concessa la lettura (da parte del REC competente) ai NECs della sua Region ed all'Echolist. Scopi: coordinamento Echomail Zone 2 FidoNet. REGCON = Accesso esclusivo a IC, ZCs e RCs FidoNet. Scopi: coordinamento generale FidoNet. REGCON.EUR = Accesso esclusivo ZC e RCs FidoNet Zone 2. Scopi: coordinamento Zone 2 FidoNet. NETSYSOP.33x = Accesso esclusivo ai SysOps del Net, regolato come gia esposto per l'area SYSOP, sostituendo RC e REC con NC e NEC. Scopi: stessi dell'area SYSOP, ma a livello di singolo Net. 2. SIGN & FIRME: Si raccomanda che i Sign e le firme nei messaggi non siano piu' lunghi di una sola riga (in merito alla lunghezza delle righe questa raccomandazione si riduce ad un consiglio, firme piu' lunge di una riga verranno comunque accettate se non espressamente vietate nella policy della singola conferenza ECHOMAIL), non contengano messaggi pubblicitari od i propri indirizzi sui vari Network (almeno non usare quest' ultimi in modo ripetitivo e costante). Solo l'origin puo' far riferimento ad altri indirizzi nel limite di quanto gia' accennato precedentemente. 3. COMPITI DEL SYSOP: Mettere in atto tutte le misure di 'educazione dell'utenza' codificate, mettere in atto ogni altra misura atta ad incoraggiare l'utenza su tale via, tenere aggiornato il coordinatore Echomail di NetWork sulle Echo Locali, inviargli periodicamente (ad ogni modifica effettuata) l'elenco delle proprie aree echomail e relativi forward agganciati, in formato ASCII. E' suo compito far prendere visione ai nuovi utenti di tutte le norme per il corretto utilizzo delle aree Echo. In particolare va fatta prendere visione di un testo sul tipo di quello riportato nel punto seguente, in modo tale che TUTTI gli utenti (in particolare i nuovi) ne prendano visione. 4. UTENTI: Le Aree Messaggi, che a livello descrittivo riportano la dicitura ECHO sono in comune a piu' BBS. Sono organizzate come 'Conferenze', in modo da avere, sull'argomento specifico che trattano, il contributo fattivo di piu' voci. Tenendo ben presente che ogni messaggio inserito genera MOLTE chiamate telefoniche, quasi tutte interurbane, il loro utilizzo deve necessariamente essere razionale e pertinente. In particolare vanno rispettate le direttive sotto descritte: Evitare tassativamente l'argomento PASSWORDS ! Non offrire ne' cercare SOFTWARE protetto da COPYRIGHT, ossia tutto il software non esplicitamente classificato di pubblico dominio. - In entrambi i casi che precedono si e' sul terreno dell'illegalita'. - Ogni e qualunque attivita' illegale e' ovviamente vietata. Evitare messaggi a contenuto SCURRILE - Per ovvie ragioni di buon gusto ed educazione. Evitare offerte commerciali Non esulare dall'argomento dell'area che e': (ad esempio) CONFERENZA TECNICA SU SISTEMI IBM E COMPATIBILI MS-DOS mettendo tutti gli altri messaggi non pertinenti in aree con tema apposito o NON IN ECHO. - Per non alterare il senso della 'Conferenza' Non inserire messaggi diretti ad altro utente specifico, ovvero NON di pubblico interesse. Non inserire Ringraziamenti. - Si esula anche in questi casi dal senso generale di 'Conferenza' Soltanto attenendovi a quanto sopra potrete sperare di utilizzare a lungo questa rete telematica che rappresenta un bene a disposizione di tutti e che vale la pena di preservare. A tale proposito resta sin d'ora inteso che coloro che non si atterranno alle regole di cui sopra si vedranno, senza ulteriore avviso, ridotto il privilegio di accesso affinche' non possano piu' nuocere. 5. POINTS: Un Point e' un sistema FidoNet compatibile che non e' riportato nella nodelist, ma che comunica con la rete attraverso un nodo definito 'Boss'. Un Point e' generalmente considerato alla pari di UN utente per cui il suo nodo "Boss" e' responsabile della posta originata dal Point. I Points sono indirizzati utilizzando il numero di nodo del Boss: ad esempio un Point con Boss 114/15 potrebbe essere il 114/15.12. I messaggi destinati al Point devono essere inviati al Boss, che provvedera' ad instradarli a destinazione. Per la gestione dei Point, il Boss, in genere, utilizza un numero privato di net che non deve essere visibile al di fuori della relazione Boss-Point o della Path dei messaggi Echo. Sfortunatamente, nel caso il point chiami un altro sistema direttamente (in una file-request, ad esempio) il numero privato appare nell'indirizzo del nodo chiamante. Solo in questo i Point differiscono dagli utenti, in quanto operano sistemi FidoNet compatibili che sono in grado di entrare in contatto con sistemi diversi da quello del Boss. Un Point essendo paragonato ad UN singolo utente, ha UN solo titolare, non puo' effettuare forward di Echomail per sistemi diversi da quello del Boss, non opera come BBS (quindi non accetta utenti in remoto), ne come gateway verso altri Networks. 7. CONFERENZE IN DISTRIBUZIONE: La creazione di nuove conferenze verra' effettuata cercando di porre, il suffisso ".ITA" dopo il nome della conferenza nazionale, mentre quelle di Net avranno un suffisso ".xxx" dove xxx e' il numero del Net di appartenenza (es. CHATTER.335). I tag delle conferenze nazionali attualmente in distribuzione non verranno per il momento modificati senza preventivo preavviso da parte del REC, nelle aree ECHOSER ed ECHO_COORD, almeno 15 giorni prima. E' fatto espresso divieto di importare nella Region conferenze internazionali gia' presenti sui backbones; per quelle non presenti e' possibile l'importazione da altri canali a patto che siano preventivamente riconosciuti ed autorizzati dal REC e portati a conoscenza dello ZEC. Viene di seguito fornita, a livello indicativo, una lista delle conferenze Echo attualmente (01/11/2019) in distribuzione su route nazionale nella Region 33 FidoNet. a) Echo Italiane: AREA DESCRIZIONE ++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++ CHATTER.ITA Echo Area dedicata alle chiacchierate generiche CALCIO.ITA Echo Area dedicata allo sport del calcio COMPUTING.ITA Echo Area dedicata ai computers (PC, SERVER ecc. ecc.) ECHOTEST.ITA Echo Area di Test per la Region 33 ELETTRONICA.ITA Echo Area dedicata all'elettronica in generale e a quella amatoriale FANTASCIENZA.ITA Echo Area dedicata alla Fantascienza, film,libri, serie tv FIDONET.ITA Echo Area per informazioni su Fidonet Italia FIDO_SOFT.ITA Echo Area dedicata ai programmi per il mondo FTN GAMES.ITA Echo Area dedicata ai giochi elettronici moderni HI-FI.ITA Echo Area dedicata all'alta fedelta' moderna e vintage LINUX.ITA Echo Area dedicata al sistema operativo Linux MOTORI.ITA Echo Area dedicata ai motori a 2 e 4 ruote MOTORI_EPOCA.ITA Echo Area dedicata ai motori a 2 e 4 ruote d'epoca MUSICA.ITA Echo Area dedicata alla musica POINTS.ITA Echo Area Points Italiana RADIOAMATORI.ITA Echo Area dedicata ai radio amatori RETROCOMPUTING.ITA Echo Area dedicata al retrocomputing RETROGAMES.ITA Echo Area dedicata ai giochi elettronici vintage e/o abadoware SALUTE.ITA Echo Area dedicata alla salute SPORT.ITA Echo Area dedicata a tutti gli sport tranne il calcio STRUMENTI_MUSICALI.ITA Echo Area dedicata agli strumenti musicali TESTR33.ITA Echo Area di Test per la Region 33 WINDOWS.ITA Echo Area dedicata ai sistemi operativi Microsoft a-bis) Echo Italiane riservate: AREA DESCRIZIONE ++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++ SYSOP.ITA Echo Area riservata ai SysOP Italiani ECHO_COORD Echo Area riservata ai coordinatori ECHO Italiani X. POSTILLA 1. QUESTA POLICY: Per la scrittura di questa Policy, si e' fatto continuo riferimento (alcune parti sono tradotte per intero): alla Policy Generale FidoNet (Policy 3 e 4.8), alla Policy Generale Echomail (Echopol V6.2); alla Policy Echo Zone 1 (Echopol 1); alla Policy FidoNet Region 33; alla Policy Echo Region 33 versione 1.2; al costante contributo dei coordinatori sia FidoNet che Echomail in area COORD; ai pareri dei vari SysOps in aree privilegiate; ad una personale visione della rete amatoriale tesa ad uno scambio di idee e gestita democraticamente. 2. POLICY ROUTE ECHO E BACKBONES: Si ringraziano per gli spunti, le idee e la loro grande disponibilita', tutti i *Cs e Backbones (sia nazionali che di Net), che con una vitalita' del tutto nuova hanno apportato un notevole contributo al buon funzionamento di tutta la Region FidoNet-Echo, favorendo una circolazione continua, fertile e proficua delle idee nelle aree apposite; ringrazio tutti i SysOps che partecipano attivamente alle aree ECHOSER, SYSOP, ECHO_COORD e COORD. Tale documento, per la sua veste di transitorieta' e' modificabile in ogni suo punto, in base a pareri ed aspettative che risulteranno dal sondaggio previsto su tutta la Region a breve scadenza riguardante i temi FidoNet-Echomail, ad eccezione delle basi tratte dalle Policy Generali Fido-Echo consolidate e modificabili solo con altro tipo di procedura. La successiva Policy modificata verra' votata a livello di Net e tale voto sara' quello riportato dai singoli NCs e NECs. Fabio Bizzi FidoNet 2:335/364 REC_Italy ----- ### -----