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 <CR> 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
----- ### -----
