*Da BBS a POP InterNet: l'evoluzione possibile*

Alessandro Falaschi
Associazione Culturale IperAudio
alef@ddns.org


*Introduzione*

Le *BBS* (#Bulletin Board Systems#) hanno costituito negli ultimi venti anni il simbolo della telematica "fatta in casa" e per questo libera da condizionamenti commerciali e di altra natura. E' sufficiente configurare alcuni software sul proprio Pc, per consentire ad altri l'accesso via modem, scambiarsi messaggi, condividere files; ognuno di questi nodi fa parte di una rete (#Fidonet#) che, mediante periodici collegamenti punto-punto su linea commutata, diffonde i messaggi su scala mondiale. Oggi, questo libero universo di comunicazione elettronica ed autogestita si e' quasi del tutto estinto, schiacciato dalla evidente superiorita di internet; e sembra che l'unico mediatore delle proprie comunicazioni debba necessariamente essere un provider.  Questo articolo mostra come invece, grazie alla completa dotazione di software per *Linux*, ed all'uso oculato di alcune risorse di rete, ognuno puo' configurare il proprio computer come quello di un piccolo provider, e replicare lo spirito delle BBS adottando protocolli TCP/IP di diffusione molto piu' ampia. Tutte le interazioni tra utenti e *POP* (#Point of Presence#) possono avvenire mediante l'interfaccia grafica costituita dal browser internet.  


*Requisiti*

Per realizzare un *POP* Internet, occorre chiaramente disporre di una macchina Linux su cui provvediamo a montare un modem (o due nel caso si desideri offrire possibilita' di navigazione). Nel corso dell'articolo tratteremo dei problemi di configurazione e di interdipendenza di alcuni software necessari alla realizzazione del POP, senza pretese di completezza, rimandando in ogni caso agli How-To ed alle FAQ esistenti per tutte le problematiche trattate, nonche' a qualche buon libro come ad esempio [1]. Ci riferiremo quindi a #named, pppd, mgetty, apache, ftpd, innd, pop3d, sendmail, majordomo, squid, ipfwadmin#. La distribuzione utilizzata per realizzare le configurazioni descritte e' una RedHat, ma le modalita' di configurazione esposte sono di natura generale. Inoltre, gli script realizzati per espletare particolari funzioni sono reperibili presso [20].


*Definire l'IntraNet*

Una #IntraNet# e' una #rete locale privata# in cui sono utilizzati i protocolli di InterNet, ma che non fa parte di InterNet, ovvero esattamente il nostro caso, in cui un utente si collega al nostro PC opera come con un provider. Il primo passo e' quello di definire una serie di indirizzi *IP* per la nostra macchina e per chi vi si collega, da scegliere tra quelli previsti per le reti private, cosi' identificati in quanto i router impediscono la propagazione dei pacchetti da/per questi IP, permettendone il ri-uso. Un gruppo di tali indirizzi e' quello della serie 192.168.#xxx.yyy# in cui (nel caso di rete in classe C) #xxx# e' parte del numero di rete ed #yyy# e' il numero di nodo. Non illustriamo qui come assegnare l'IP alla nostra macchina, che d'ora in poi chiameremo #host#; una buona fonte di informazioni e' [2].
 
Occorre ora associare ad ogni IP un mome simbolico, del tipo #nodo.dominio#: e' consigliabile in questo caso scegliere come #dominio# un nome di fantasia che non esista anche come "vero" dominio internet, in modo da rendere esplicito che si tratta di una intranet. Il campo #nodo# corrispondera' ad uno tra diversi nomi: ne occorre infatti uno per la nostra macchina, ed uno per ogni profilo di utente che vogliamo poter attribuire a chi si collega.

Le associazioni create tra IP e nodo sono utilizzate nel processo di risoluzione dei nomi, che avviene per mezzo delle risorse indicate nel file #/etc/nsswitch.conf#, ed in cui e' consigliabile definire una sequenza di interrogazione del tipo files/dns/nis/, che significa cercare prima in #/etc/hosts/# [2], interrogare poi il #DNS# [3] e per ultimo provare con #NIS# [4]. L'indirizzo del DNS utilizzato e' definito nel file #/etc/resolv.conf#, e puo' vantaggiosamente indicare proprio il nostro host, che offrira' il servizio per mezzo del programma #named#. In questo caso, il nostro dominio privato "esiste", purche' si inserisca la tabella delle associazioni tra nomi ed IP dell'intranet nel file di zona #/var/named/named.hosts# [5], che viene letto all'avvio da named, assieme agli altri files menzionati in #/etc/named.boot#. In quest'ultimo file e' poi possibile, mediante la primitiva #forwarders#, specificare un diverso DNS (tipicamente quello presente presso il provider) da interrogare per risolvere i nomi non presenti nei files della zona locale.

E' da sottolineare il fatto che la risoluzione di nomi esterni ha senso solo quando la nostra macchina e' collegata al provider; in caso contrario infatti possono verificarsi ritardi nella esecuzione di comandi dovuto all'attesa del timeout del DNS remoto che non risponde. Per risolvere questo problema si possono prevedere due diversi files #named.boot#, ed eseguire un reload di named quando ci si connette/sconnette dal provider; in questo secondo caso, oltre a non prevedere forwarders, conviene anche indicare un file di cache vuoto, in modo da evitare qualsiasi tipo di richiesta impossibile (e relativa attesa di timeout) da parte della #resolver library#. Alcune persone utilizzano unicamente il DNS del provider, e risolvono i nomi locali mediante il file /etc/hosts. Il vantaggio di usare il proprio named risiede nella sua funzione di caching, che consiste nel "ricordare" le associazioni tra i nomi e gli IP ricevuti dal forwarder, ed utilizzarle direttamente nelle successive istanze, anziche' chiederle ogni volta, velocizzando cosi' il processo di risoluzione degli indirizzi IP.
  
Avendo definito gli IP della nostra macchina e di chi si collega, siamo in grado di controllare l'uso dei servizi presenti nella nostra macchina mediante i files #/etc/hosts.allow# ed #/etc/hosts.deny# [2], che consentono di specificare quali IP possono utilizzare quali programmi. Ad esempio, potremo disabilitare la possibilita' di #telnet# (e quindi l'accesso alla shell dei comandi della nostra macchina) da parte delle richieste provenienti da IP remoti: cosa assolutamente consigliabile, altrimenti si rischia di essere "invasi" durante i collegamenti ad internet. Come vedremo nel seguito, l'uso di una autenticazione *PAP* o *CHAP* permettera' di assegnare diversi IP agli utenti, a cui potranno essere attribuiti maggiori o minori privilegi di utilizzo dei servizi locali.

Per terminare questa prima sezione, si ricorda l'utilita' dei file di log, in cui sono riportati i risultati del'esecuzione delle procedure, e la cui analisi e' fondamentale per la risoluzione dei problemi: Linux conserva queste informazioni nella directory #/var/log/#, in cui si trovano i files definiti in #/etc/syslog.conf#; mediante quest'ultimo, e' possibile richiedere diversi livelli di dettaglio per i log prodotti da programmi differenti. Infine, con il file #/etc/logrotate.conf# si definisce la frequenza con la quale i files di log sono cancellati e/o archiviati. 


*Uscire su InterNet*

Il collegamento ad internet mediante il proprio provider consiste nell'esecuzione di uno script che esegue #pppd#, con le dovute opzioni, delegando ad un ulteriore programma (#chat#) il colloquio con il modem e con l'eventuale sessione di login del provider [6]. Alcune distribuzioni di Linux forniscono una interfaccia di configurazione del ppp, per cui non ci dilunghiamo su questo argomento, se non per far notare che una particolare opzione, #defaultroute#, e' quella che permette di inoltrare tutti i pacchetti per le destinazioni esterne alla nostra intranet, verso il provider.

Un passo intermedio necessario a fornire servizi di navigazione ai nostri utenti sara' quello di predisporre due semplici script, eseguibili da linea di comando, per effettuare la connessione e la disconnessione verso internet mediante comandi creati ad hoc. In alcune circostanze puo' essere utile un programma di nome #diald#, che provvede a collegarsi ad internet in modo automatico ogni volta che se ne verifichi la necessita'; la soluzione qui proposta invece comporta l'esplicita volonta' di connettersi, e come vedremo consente il controllo dell'identita' e dello status del richiedente.

Ogni volta che viene creata/terminata una connessione di rete, Linux provvede ad eseguire rispettivamente uno dei due script #ip-up# e #ip-down#, che svolgono le operazioni di manutenzione da effettuare nei due casi. E' proprio in questi due script che, come anticipato, si effettua il restart di named con uno tra due diversi file di boot.


*Accettare Utenti*

I collegamenti via modem alla nostra macchina sono permessi dall'uso di #pppd# in qualita' di #server#. Per questo utilizziamo un secondo modem [7], ed editiamo il file #/etc/inittab# in modo che il processo che gestisce la porta (ad esempio #ttySx# con #x# = numero della porta seriale) a cui e' connesso il modem sia in grado di eseguire le operazioni necessarie. A questo scopo si possono seguire due strade.

La prima e' quella di far gestire le chiamate da #uugetty#, a cui si comunica la velocita' della porta, la locazione di un file di configurazione (tipicamente #/etc/conf.uugetty.ttySx#), ed una etichetta simbolica da usare come chiave in #/etc/gettydefs#, ulteriore file in cui e' specificato il programma che effettua il dialogo di autenticazione per le connessioni sulle porte con quell'etichetta. A questo punto il chiamante puo' immettere un nome di utente e relativa password, provocando l'esecuzione della shell prevista (nel file #/etc/passwd#) per quell'utente . Pertanto, sara' sufficiente prevedere l'esistenza di un utente (ad esempio l'utente ppp), che abbia #pppd# come shell, per mandare in esecuzione il protocollo (con i parametri descritti in #/home/ppp/.ppprc#). Dopo l'autenticazione in una finestra terminale quindi, il chiamante lancia a sua volta il ppp e si connette.

La seconda strada prevede di configurare #/etc/inittab# per l'uso, anziche' di uugetty, di #mgetty# [8], che e' espressamente concepito per la gestione dei modem, e prevede molte funzioni utili: in particolare, e' in grado di rilevare la presenza di pacchetti *LCP* di richiesta-configurazione usati dall'accesso remoto delle macchine *MS* al posto del dialogo in finestra terminale. In questo caso, mgetty stesso provvede a lanciare pppd, in modo da consentire la connessione senza necessita' di una interazione (umana o tramite script). La configurazione di mgetty avviene mediante il file #/etc/mgetty/login.config#, in cui si specificano i parametri (e/o il file che li descrive) con cui eseguire pppd in risposta ai pacchetti LCP suddetti; nello stesso file si definiscono le azioni da compiere nel caso in cui la connessione provenga invece da una BBS FidoNet oppure da un nodo UUCP.

Tra i parametri [9] che descrivono il comportamento del pppd in modalita' server, e' importante inserire #proxyarp#, necessario per far rispondere il nostro host, al posto dell'utente connesso, alle richieste ARP a lui indirizzate. Inoltre, e' preferibile richiedere per l'utente una autenticazione *PAP*, che ha luogo durante la fase di inizializzazione del PPP, e permette (in base ad una coppia utente-password memorizzata in #/etc/ppp/pap-secrets#) di assegnare al chiamante un particolare indirizzo IP. In realta', in questo caso non e' esatto dire che l'IP e' assegnato dall'host; piuttosto, viene rivendicato dall'utente, a cui viene concesso in base alla sua corretta identificazione. I diversi IP richiedibili potranno quindi essere usati per controllare i diritti di esecuzione dei servizi locali mediante i files /etc/hosts.allow e .deny.


*Pagine locali e CGI*

Ora che finalmente possiamo essere raggiunti via modem, ci si puo' dedicare alla redazione di pagine html da presentare ai nostri utenti. Perche' cio' sia possibile, questi ultimi devono configurare il proprio DNS con in nostro indirizzo IP intranet, e quindi inserire l'indirizzo #nome.dominio# che abbiamo dato al nostro host nel proprio browser. Le pagine vengono inviate mediante il server *HTTP*, che nella grande maggioranza dei casi e' #Apache# [10], la cui configurazione omettiamo qui di descrivere.

Nelle pagine che prepareremo, oltre ad informazioni di aiuto per l'utente, e links ai servizi come *FTP* e #Newsgroup# che descriviamo in seguito, occorre prevedere collegamenti a pagine interattive necessarie sia per raccogliere richieste, che per fornire informazioni sullo stato dell'host. In entrambi i casi occorre disporre di programmi chiamati *CGI* (#Common Gateway Interface#) [11] che non sono altro che script (ad esempio in #bash, tcl# o #perl#) che vengono eseguiti da Apache in corrispondenza a determinate *URL* (ad esempio #http://nome.dominio/cgi-bin/eseguimi.tcl#).
L'output di tali script viene quindi inviato ad Apache e da questo presentato all'utente come una normale pagina; occorre quindi che sia conforme ai formati previsti per le pagine #html#.

Il server HTTP comunica con il CGI in diverse maniere; la piu' semplice e' quella del metodo #GET# che rende visibili al CGI un insieme di variabili d'ambiente, contenenti ad esempio i dati immessi dall'utente in una form. In particolare, occorrera' prevedere un form con cui l'utente possa richiedere un alias di posta elettronica, ed una password per guadagnare l'accesso a CGI corrispondenti a caratteristiche "speciali" come la connessione al provider. I dati inseriti nella richiesta possono essere inviati per e-mail, a chi ne mantiene traccia, dal CGI che gestisce la form.

Qualora il file #/etc/httpd/conf/access.conf# prescriva per le URL associate ai CGI una forma di autenticazione, il browser dell'utente presentera' allo stesso una finestra in cui si richiede di immettere nome utente e password, la cui esattezza e' verificata da Apache in base all'esame del file di password specificato in #access.conf#; in caso negativo il CGI non e' eseguito. Il formato "piu' semplice" del file di password e' del tutto simile a quello di #/etc/passwd#; la sua manutenzione avverra' solamente qualora si debba aggiungere o rimuovere un utente, in base ai dati da lui stesso inseriti. Dopo aver verificato la password, Apache controlla anche che l'utente sia presente in un secondo file (indicato ancora in access.conf), che identifica chi puo' accedere alla pagina protetta. E' quindi possibile definire gruppi differenti per funzionalita' diverse.

Nel caso in cui l'autenticazione abbia successo, l'identita' del richiedente e' passata al CGI tramite una variabile di ambiente, che puo' essere usata ad esempio come chiave in una tabella di crediti attribuiti a ciascun utente, in modo da realizzare un controllo ulteriore sull'uso di servizi da considerare a pagamento, come ad esempio la richiesta di navigazione tramite il secondo modem presente. A tale scopo sara' necessario prevedere uno script di aggiornamento della tabella dei crediti, mediante il quale decrementare i crediti (per l'utente in questione) in base ad una misura di utilizzo, come ad esempio un tempo di connessione.

Altri CGI necessari potranno essere di tipo informativo, come ad esempio il report sull'ammontare dei crediti residui, lo stato della coda di posta, o lo stato del routing, utile quest'ultimo per verificare la presenza di una connessione verso il provider mediante il secondo modem. In linea di principio, il risultato di qualsiasi comando eseguibile da una finestra terminale di Linux puo' essere inviato all'utente remoto, mediante un CGI che semplicemente compone gli header html ed invoca il comando. E' da notare che tutti i CGI eseguiti da Apache sono lanciati dall'utente #nobody#, e quindi occorre prestare attenzione ai privilegi accordati a quest'ultimo. Infine, tutti gli errori che si verificano nell'esecuzione dei CGI non compaiono a video, ma possono essere rintracciati nell'ambito del file #/var/log/httpd/error_log#.


*FTP, Newsgroup ed E-Mail*

In questa sezione ci occupiamo brevemente di quei servizi del tutto analoghi a quelli offerti da una BBS "tradizionale". I programmi necessari sono tutti pienamente disponibili con Linux, e sono rispettivamente #ftpd#, #innd# e #sendmail#.

Per mettere a disposizione files per il download, occorre creare le directory sotto #/home/ftp/pub# come leggibili da tutti, accertarsi che #inetd.conf# faccia partire #ftpd#, e che sia definito un utente ftp con password disabilitata [2]. Puo' essere opportuno configurare #/etc/ftpaccess# per limitare i rischi di sicurezza legati all'attivazione dell'FTP anonimo.

Le #newsgroup#, accessibili con i browser web o con i reader appositi, sono gestite da #innd# [12]; durante l'editing dei files di configurazione di quest'ultimo, occorre porre attenzione a mantenerne i privilegi di accesso inalterati, in quanto innd e' eseguito dall'utente #news#, e tale dovra' mantenersi la proprieta' dei file; inoltre e' necessario re-dirigere la posta per l'utente news verso il nostro acount di manutenzione, dato che e' per questa via che innd resoconta le proprie attivita'. La manutenzione delle news avviene per mezzo del programma #ctlinnd#, che prevede comandi per la creazione e cancellazione di newsgroup, di singoli messaggi, la definizione di gruppi moderati, e svariati altri comandi che interagiscono direttamente con il server. Il browser dell'utente remoto in realta' dispone unicamente del protocollo #nnrp#, e pertanto occorre definire in #/etc/news/nnrp.access# quali indirizzi possano accedere (ed in che modo) ai diversi newsgroup; queste impostazioni possono avvalersi di meccanismi di wildcard, e prevedere differenti diritti di accesso per i diversi IP assegnati mediante autenticazione PAP.
Altri files di configurazione per #innd# riguardano la configurazione di altri newsserver con cui scambiare news, utile anche nel caso in cui si voglia realizzare un gateway con una BBS tradizionale (ad esempio usando #GIGO# [13] od #ifmail# [14]); inoltre, e' presente la definizione della durata di permanenza dei messaggi nei diversi gruppi (#/etc/news/expire.ctl#) e la descrizione dei moderatori per i gruppi moderati (nel qual caso i messaggi postati vengono inviati appunto al moderatore che ha il compito di approvarli). Quest'ultima caratteristica permette la creazione, in modo piuttosto agevole, di #gateway# tra newsgroup ed indirizzi e-mail [15], ad esempio associati a Mailing Lists. In quest'ultimo caso, alla mailing list verra' iscritto un alias di email (vedi sotto) che corrisponde al programma che effettua l'operazione di approvazione.

L'uso della #email#, lasciato per ultimo di questa sezione, risulta il piu' delicato, a causa della natura stessa di Internet. A livello locale, cioe' nell'ambito dei nostri utenti, ognuno puo' configurare i server *SMTP*  e *POP3* con l'indirizzo del nostro host per inviare e prelevare la propria posta. Agendo sul file #/etc/aliases# possono essere definiti ulteriori "utenti", da associare ad altri indirizzi email (locali o remoti), ad un programma (che riceve il contenuto del messaggio) od a gruppi di indirizzi (a tutti i componenti del quale e' inviata una copia del messaggio). Anche l'invio verso l'esterno funziona perfettamente. Il programma che se ne occupa e' #sendmail# [16], in base alle indicazioni che si trovano in #/etc/sendmail.cf#; anche se questo file e' solo il prodotto finale della "compilazione" di un ulteriore file di configurazione, e' perfettamente possibile modificarlo direttamente senza troppo sforzo. In particolare, e' opportuno definire l'opzione #Delivery Mode=background# per evitare i tempi di attesa dovuti ai tentativi di risoluzione di indirizzi remoti quando non si e' connessi al provider, ed un timeout per i warning di eccessiva giacenza dei messaggi nella coda di uscita, di durata superiore all'intervallo tra connessioni con il provider. Quando ci si collega ad internet (possibilmente mediante uno script che viene eseguito periodicamente mediante cron) si provvede a svuotare la coda di posta (inserendo in #ip-up# il comando #sendmail -q#); a tale riguardo puo' essere opportuno configurare come #smart relay host# (opzione #DS# di sendmail.cf) un server SMTP situato presso il provider, in modo da consegnarli tutta la posta e delegargli cosi' l'invio agli indirizzi di destinazione, evitando i ritardi dovuti a destinatari lontani, lenti, o mal configurati.

Il problema della email nasce dal fatto che ... non puo' arrivare ! Infatti, a parte il caso banale di recuperare la nostra posta personale che giace presso un provider, il #nome.dominio# che ci siamo scelti e' valido solo nella nostra intranet (e' risolto solo dal nostro DNS), e non esiste su internet, e quindi i nostri utenti che hanno la mailbox presso di noi... non esistono. Anche se nel momento in cui ci connettiamo al provider acquisiamo un IP (e relativo indirizzo) valido, con cui in linea teorica potremmo ricevere posta, quest'IP e' differente per ogni connessione (per questo si chiama #dinamico#) e dunque serve a poco. A meno che ... non si operi come descritto all'ultima sezione !

Non resta infine che segnalare la disponibilita' di un elevato numero di software per la gestione dei servizi di comunicazione elettronica, come ad esempio #Majordomo# [17], per la gestione di mailing lists.  


*Navigazione Off-Line*

Questo capitolo espone una caratteristica peculiare della configurazione che andiamo proponendo, e cioe' la possibilita' di catturare pagine od interi siti da internet, e rendere le stesse disponibili alla navigazione per i nostri utenti anche senza attivare una connessione ad internet. Questo concetto amplia e potenzia il concetto di BBS: e' possibile infatti #costruire# il proprio nodo telematico utilizzando materiale gia' perfettamente redatto ed impaginato da estensori competenti e capaci.

Per realizzare la cosa occorre installare sul proprio host un #server proxy#, ad esempio #squid# [18]. La sua configurazione e' veramente molto facile, e si basa sull'editing del file #squid.conf#, in cui si assegnano ad esempio le quantita' di disco e di memoria fisica da riservare per il suo uso. Altri parametri da modificare sono le parti di URL che individuano pagine da non memorizzare, che nel nostro caso conviene siano in numero piu' ridotto possibile; e' inoltre opportuno lanciare squid con l'opzione -D per evitare il ritardo dovuto al DNS lookup iniziale. Infine, occorre abilitare l'accesso al proxy da parte degli IP della nostra intranet. 


*Navigazione On-Line*

Disponendo di due modem, mentre un utente e' connesso sul primo, il secondo puo' connettersi al provider, consentendo cosi' all'utente di navigare su internet. Dal nostro punto di vista, occorrera' addebitare all'utente quantomeno il costo della telefonata uscente, e facendo qualche conto ci si accorge che tale costo e' superiore a quello richiesto dai "normali" provider; pertanto, la funzione di navigazione e' da ritenersi accessoria, anche se sicuramente molto interessante e valida.

Il prerequisito necessario a far navigare i nostri utenti e' l'abilitazione del #Masquerading# [19], una caratteristica di Linux ottenibile specificando le opportune opzioni nella compilazione del kernel, e che effettua una conversione tra l'indirizzo IP intranet dell'utente connesso in PPP, ed i numeri di porta utilizzati nel collegamento ad internet. Infatti, come abbiamo visto, gli IP intranet non oltrepassano i router, e dunque sarebbe impossibile accedere a servizi esterni. Specificando le opportune opzioni al comando #ipfwadm#, invece, l'host che effettua il Masquerading intercetta il pacchetto dell'utente che richiede il servizio, sostituisce il proprio IP (ossia l'IP dinamico ricevuto dal provider) al posto di quello dell'utente, e lo invia al server destinatario utilizzando un socket TCP/IP non standard. I pacchetti di ritorno fanno riferimento allo stesso socket, che l'host riconosce corrispondere alla richiesta dell'utente, al quale consegna il pacchetto ricevuto dopo avere sostituito all'IP di destinazione quello dell'utente al posto del proprio (il server remoto infatti immagina di dialogare solo con il nostro host).

La richiesta di navigazione da parte dell'utente avviene mediante accesso ad un CGI (con #autentificazione#) [10], che come gia' descritto consente di mantenere aggiornata una tabella di crediti per utente. Il CGI provvede quindi a richiedere un collegamento al provider, a memorizzare l'istante di inizio della connessione e l'identita' del richiedente; ogni volta che ci si collega ad internet, #ip-up# provvede a far partire la posta giacente e riconfigura il DNS. La sconnessione dal provider puo' essere richiesta esplicitamente dall'utente, oppure prodotta automaticamente quando quest'ultimo a sua volta si scollega. In questo secondo caso, #ip-down# rivela che l'utente e' uscito e provvede a chiudere il collegamento al provider; quest'ultimo evento causa quindi un nuovo reset del DNS e l'aggiornamento dei crediti per l'utente che ha iniziato la navigazione.

L'uso del #proxy server# da parte dell'utente anche durante la navigazione On-Line, permette di ritrovare le pagine visitate anche nei successivi collegamenti, senza bisogno di connettersi ad internet. L'invio automatico della posta in uscita ad ogni connessione al provider costituisce un elemento di cooperazione e mutualita' tra gli utenti del nostro host, in quanto ad esempio la connessione richiesta da Tizio per far partire la propria posta urgente permette la partenza anche della posta di Caio e di Sempronio.


*Ricezione della Posta*

Quasi ovunque si puo' trovare l'affermazione che per ricevere la e-mail occorre disporre di un IP statico, ovvero il nostro provider deve assegnarci sempre lo stesso IP ad ogni collegamento, a cui associare stabilmente il dominio internet, verso cui indirizzare la posta. Se l'IP invece cambia ogni volta, questa associazione non e' possibile, a meno che... non la si effettui di volta in volta ! ... peccato pero' che nessun DNS accetti questo genere di configurazioni, tranne ... un DNS scritto apposta.  Ed infatti esistono delle iniziative in rete in tal senso; in questa sede prendiamo come esempio il servizio offerto da una realta' telematica con sede a Singapore, #www.ddns.org#, anche a titolo gratuito.

Il DNS dinamico (*DDNS*), quando e' chiamato a rispondere alle interrogazioni relative all'IP per un host di indirizzo *.ddns.org, non utilizza i dati letti da un file al suo avvio, ma effettua ogni volta una interrogazione ad un database. Quest'ultimo e' mantenuto aggiornato mediante un protocollo definito ad hoc, che consente ad un host remoto di specificare (con le dovute password di autentificazione) un nuovo IP per un nome appartenente ad *.ddns.org. Chiaramente, l'IP specificato e' quello appena ricevuto dal provider, ed una transazione diversa, prima di scollegarsi da internet, comunica al DDNS l'abbandono del proprio IP. Ogni volta che un host di internet richiede il nostro IP, perche' ad esempio vuole consegnarci della posta o prelevare delle pagine dal nostro Apache, il DDNS rispondera' con l'IP dinamico (e dunque l'host remoto potra' connettersi a noi) oppure con un IP non in uso, confermando la nostra esistenza ma... spenti. Gli IP restituiti dal DDNS hanno una "data di scadenza" (il #Time To Live#, *TTL*) di soli due minuti, trascorsi i quali la risposta ricevuta dall'host remoto non e' piu' valida; questa viene quindi rimossa dalla memoria, e viene richiesta al DDNS una nuova risoluzione, in modo che "la rete" percepisca il nostro essere On- ed Off-Line con non piu' di 2 minuti di ritardo. Il protocollo con cui comunicare il nuovo IP o la sconnessione dal provider avviene per mezzo di due programmi client da eseguire all'interno di #ip-up# e prima della sconnessione.

Sorge ora pero' un nuovo problema: la posta a noi destinata giace all'interno di qualche nodo *MX* (#Mail Exchanger#) che periodicamente prova ad inviarcela, riuscendovi solo quando riceve l'IP valido. Pertanto, occorrerebbe rimanere collegati per tutto il tempo che intercorre tra due tentativi, che puo' essere anche di un'ora. Sembrerebbe un problema insormontabile e costoso. Invece, e' possibile limitare quest'attesa al massimo al TTL (2 minuti), configurando come nostro MX un computer in rete il cui *SMTP* server sia in grado di accettare il comando *ETRN* [#RFC 1985#]. Questo comando, introdotto recentemente, permette di "risvegliare" l'MX, chiedendogli di inviare al piu' presto la posta per un particolare host (il nostro), evitando cosi' il periodo di attesa.

Un ultimo dettaglio, prima di essere in grado di ricevere posta, e' di comunicare al nostro host il suo nome registrato presso il DDNS, e verso cui va indirizzata la posta che vogliamo ricevere: questo nome andra' specificato nel file #sendmail.cw#.


*Conclusioni*

Sono stati illustrati tutti i passi necessari per rendere il nostro computer Linux accessibile via modem, nel rispetto dei protocolli TCP/IP utilizzati in Internet. Il risultato di questa procedura e' l'essere in grado di offrire servizi del tutto analoghi a quanto offerto da un provider, mantenendo lo spirito e l'indipendenza che ha da sempre animato il mondo delle BBS e della telematica amatoriale. La quasi totalita' dei files di configurazione nominati ma non descritti nel dettagli nell'articolo, puo' essere reperita presso [20].


*Riferimenti*

[1]  Olaf Kirch, Linux Network Administratior-s Guide, O'Reilly & Associates
[2]  Terry Dawson, file:/usr/doc/HOWTO/other-formats/html/NET-3-HOWTO.html
[3]  AA.VV., http://www.isc.org/bog-4.9.4/bog.html
[4]  AA.VV., file:/usr/doc/HOWTO/other-formats/html/NIS-HOWTO.html
[5]  Nicolai Langfeldt, file:/usr/doc/HOWTO/other-formats/html/DNS-HOWTO.html
[6]  Egil Kvaleberg, file:/usr/doc/HOWTO/other-formats/html/ISP-Hookup-HOWTO.html
[7]  Greg Hankins, file:/usr/doc/HOWTO/other-formats/html/Serial-HOWTO.html
[8]  Gert Doering, http://www.leo.org/~doering/mgetty/index.html
[9]  Robert Hart, file:/usr/doc/HOWTO/other-formats/html/PPP-HOWTO.html
[10] http://www.apache.org/
[11] http://hoohoo.ncsa.uiuc.edu/cgi/
[12] Donnie Barnes, file:/usr/doc/RedHat/INN-Tips.html
[13] http://www.gigo.com
[14] http://www.average.org/ifmail/
[15] Robert Hart, file:/usr/doc/HOWTO/mini/Mail2News
[16] http://www.sendmail.org/
[17] http://www.greatcircle.com/majordomo/
[18] http://squid.nlanr.net/Squid/
[19] Ambrose Au, file:/usr/doc/HOWTO/mini/IP-Masquerade
[20] http://comel.ing.uniroma1.it/~sandro/lime98/bbs2pop.tgz

