[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
I messaggi di posta elettronica non vengono sempre recapitati presso l'elaboratore che si utilizza abitualmente. Questa è la situazione tipica in cui ci si trova quando si è collegati a Internet tramite un ISP, per mezzo di una linea commutata. Di solito si ottiene un accesso (account) presso un elaboratore dell'ISP e questo diventa solitamente anche il recapito per la posta elettronica.
Il problema è comunque generale: si può avere la necessità di scaricare la posta ricevuta presso un recapito remoto.
La prima idea che può venire in mente può essere quella di usare il protocollo TELNET e leggere così la posta remota. Ma questa non è la soluzione corretta. Per trasferire la posta da un recapito a un altro, si usa solitamente il protocollo POP3 (a volte POP2) oppure IMAP. Come si può immaginare, si tratta di un servizio che deve essere gestito da un demone.
Il modo con cui vengono scaricati messaggi e inseriti nel sistema locale ha dei risvolti importanti. Infatti, questi messaggi possono essere scaricati in un file locale, che normalmente corrisponde alla cartella della posta in ingresso dell'utente, il quale può leggerla attraverso mail o un altro programma che sfrutta lo stesso meccanismo. In alternativa, i messaggi potrebbero essere inseriti nel sistema locale attraverso un servizio SMTP, che in tal caso però, dovrebbe essere attivato necessariamente.
Quando la posta elettronica è giunta presso un recapito remoto, senza essere stata ridiretta da lì attraverso un alias o un forward per il suo proseguimento, può essere prelevata per mezzo di vari protocolli, tra cui i più importanti sono POP2, POP3 e IMAP.
Il prelievo fatto in questo modo, può tradursi poi:
nello scarico dei messaggi in un file locale che rappresenta la cartella della posta in ingresso dell'utente per cui si svolge l'operazione;
nell'invio dei messaggi attraverso l'MDA locale;
nell'invio dei messaggi attraverso un servente SMTP locale, o comunque uno più «vicino».
Ognuna delle scelte possibili ha dei vantaggi e degli svantaggi. Il primo tipo di operazione, non richiede la presenza di un servente SMTP locale e nemmeno di un MDA, cioè di un Mail delivery agent, per la consegna locale del messaggio. Così si presta perfettamente all'uso presso nodi isolati che possono connettersi a Internet attraverso una linea commutata, che solo allora trasmettono e ricevono la posta elettronica.
Il secondo tipo di operazione richiede la presenza di un MDA, composto generalmente da un programma in grado di ricevere i messaggi attraverso lo standard input, che poi sia in grado di recapitarli localmente ed eventualmente di farli proseguire altrove attraverso gli alias e i forward eventuali. In pratica però, l'MDA a cui si fa riferimento è quasi sempre Sendmail, o un altro sistema compatibile. Il vantaggio di questa scelta è che per attuarla non occorre attivare il servizio SMTP, cioè non è necessario che Sendmail sia stato avviato come demone in ascolto della porta SMTP.
L'ultimo caso richiede invece che localmente sia presente un MTA completo, in grado di ricevere le connessioni SMTP.
I motivi per cui non si riceve la posta direttamente nel nodo locale, possono essere vari: la connessione con l'esterno potrebbe essere discontinua, come nel caso di un collegamento PPP attraverso linea commutata; il sistema remoto presso cui giunge la posta per qualche motivo, potrebbe avere delle politiche che impediscono il proseguimento dei messaggi (il forward); il sistema locale potrebbe essere irraggiungibile dall'esterno a causa delle politiche di sicurezza adottate, per cui, la posta elettronica potrebbe non essere trasferita localmente, lasciando l'onere a ogni nodo di prelevarsela da un servente principale.
Negli ultimi due tipi di trasferimento, il programma che lo fa interviene come se fosse un MTA vero e proprio. In tal senso, potrebbe essere attivato periodicamente attraverso il sistema Cron, a intervalli brevi, oppure come un demone.
Il prelievo della posta remota è un'operazione personale dell'utente che ha l'accesso presso il sistema remoto. Il programma che si usa per accedere a uno di questi servizi che lo permettono, deve identificarsi in qualche modo; di solito si tratta di fornire l'identità dell'utente remoto e la parola d'ordine.
Il fatto di lasciare viaggiare la parola d'ordine in chiaro, attraverso la rete, è un problema da non trascurare: finché la connessione è diretta (o quasi, come nel caso di una linea commutata), il problema è minimo; quando la connessione attraversa più nodi, il problema diventa delicato.
Oltre a questo, occorre considerare che le informazioni delicate come le parole d'ordine non possono apparire in una riga di comando, perché sarebbero leggibili semplicemente analizzando l'elenco dei processi attivi. Per questo, quando si vuole automatizzare il processo di recupero della posta remota senza dover ogni volta inserire la parola d'ordine, questa può essere annotata soltanto in un file di configurazione, protetto opportunamente contro ogni accesso da parte di altri utenti.
IMAP toolkit è una raccolta di demoni per i servizi di trasferimento della posta locale verso i clienti che lo richiedono, mostrando le credenziali necessarie. Si tratta precisamente dei programmi ipop3d, ipop2d e imapd. Permettono rispettivamente di utilizzare i protocolli POP3, POP2 e IMAP. Sono gestiti normalmente dal supervisore dei servizi di rete. (1)
Nell'esempio seguente, vengono mostrate le righe di /etc/inetd.conf in cui si dichiara il loro possibile utilizzo per quanto riguarda il caso particolare di Inetd:
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd |
In alcune distribuzioni GNU questi tre demoni potrebbero fare parte di un pacchetto unico, mentre in altri casi i pacchetti potrebbero essere distinti in base al servizio particolare che viene offerto.
Popclient (2) è un programma molto semplice che permette di scaricare la posta da un recapito remoto utilizzando il protocollo POP2 o POP3, inserendola in un file che corrisponda alla cartella della posta in ingresso dell'utente nel nodo locale, oppure passandola a un MDA (Mail delivery agent) che faccia sostanzialmente la stessa cosa. In questo modo, una volta scaricata, la posta può essere letta con un programma tradizionale come Mailx.
È importante sottolineare che per questo scopo, non è necessario che sia attivo un servente SMTP locale. (3)
popclient è l'eseguibile che compie tutto il lavoro di Popclient. Può essere predisposto anche un file di configurazione, che permette l'automazione delle operazioni.
popclient [opzioni] [host_remoto]
Nelle opzioni della riga di comando, si può osservare che non è stata indicata la possibilità di inserire la parola d'ordine. Infatti, non è possibile; per non dover inserire la parola d'ordine ogni volta che si scarica la posta, è necessario predisporre un file di configurazione.
Popclient può essere configurato in modo personale attraverso il file ~/.poprc. In tal modo, l'utente può predisporre tutti i dati necessari ad automatizzare la connessione senza la necessità di utilizzare script o comandi pieni di opzioni. In particolare, attraverso il file personalizzato di configurazione, si può predisporre anche la parola d'ordine necessaria a prelevare la posta.
L'esempio seguente riguarda il caso in cui si voglia prelevare la posta dal nodo weizen.mehl.dg, utilizzando il protocollo POP3, con un nominativo-utente «tizio» e la parola d'ordine «tazza», depositando i messaggi nel file /home/tizio/mail/inbox:
# .poprc
server weizen.mehl.dg \
proto pop3 \
user tizio \
pass tazza \
localfolder /home/tizio/mail/inbox
|
Si può leggere eventualmente la pagina di manuale popclient(1).
Fetchmail (4) è un sistema di recupero della posta remota molto complesso. Permette di inserire i messaggi ottenuti nel sistema di consegna locale attraverso un MDA come Sendmail; oppure può utilizzare direttamente il protocollo SMTP per ottenere lo stesso risultato, o per inserire i messaggi in un sistema di trasporto più vicino (quale quello di una rete locale).
Può funzionare anche come demone personale (di un utente) in modo da provvedere regolarmente allo scarico dei messaggi.
Fetchmail ha il vantaggio di poter utilizzare una grande varietà di protocolli fatti per questo scopo. In linea di massima ci si può concentrare sui soliti POP2, POP3 e IMAP, ma è bene tenere presente che le possibilità sono maggiori, nel caso si presentasse l'occasione.
L'eseguibile fetchmail può essere gestito molto bene attraverso la riga di comando, ma è consigliabile anche la sua configurazione attraverso il file ~/.fetchmailrc, che permette di agevolare le operazioni di routine.
fetchmail [opzioni] host_remoto
Se si pone un conflitto tra quanto specificato tramite le opzioni della riga di comando e le direttive del file di configurazione, le prime prendono il sopravvento.
Il file di configurazione di Fetchmail è molto importante. È interessante notare che non esiste un file di configurazione generale, ma solo quelli dei singoli utenti; infatti, il recupero della posta elettronica è un'operazione personale.
Prima di analizzare la sintassi che può essere utilizzata al suo interno, si può notare che i commenti vengono espressi nel modo consueto, attraverso il simbolo # che li introduce, dove poi tutto quello che segue, fino alla fine della riga, viene ignorato. Così anche le righe bianche e quelle vuote vengono ignorate.
Ogni direttiva del file ~/.fetchmailrc contiene tutte le specifiche riferite al recupero della posta elettronica da un servente determinato. Queste direttive possono impiegare più righe, senza la necessità di indicare simboli di continuazione, distinguendosi perché iniziano con la parola chiave poll, oppure skip.
Una direttiva poll rappresenta un servente da interpellare, mentre una direttiva skip, uno da saltare. Di fatto non serve una direttiva skip, ma può essere utile per evitare di cancellarla, riservando per il futuro la possibilità di riutilizzarla rimettendo la parola chiave poll.
Le direttive sono composte da una serie di parole chiave che rappresentano delle opzioni, a volte accompagnate da un argomento. Alcune parole chiave sono speciali, in quanto, pur non avendo alcun significato, sono utili per facilitare la lettura delle direttive. Tali parole sono: and, with, has, wants e options. Nello stesso modo, possono essere usati la virgola, il punto e virgola, i due punti, che vengono ignorati ugualmente.
All'interno di ogni direttiva, deve essere rispettato un certo ordine nell'indicazione delle opzioni. Se ne distinguono due tipi: opzioni del servente e opzioni dell'utente. Le opzioni del servente devono apparire prima di quelle dell'utente.
Per comprendere il senso di queste direttive, è bene fare mente locale al formato generale semplificato, che queste possono avere.
poll servente [protocol protocollo] [username utente_remoto] [password parola_d'ordine]
Gli argomenti delle opzioni che rappresentano delle stringhe, possono essere racchiusi tra apici doppi, in modo da poter contenere simboli particolari, come gli spazi (specialmente quando si tratta di indicare le parole d'ordine).
Opzioni del servente
Opzioni dell'utente
Segue la descrizione di alcuni esempi.
poll roggen.brot.dg protocol pop3 username tizio password "frase segreta" |
Rappresenta la scansione del servente roggen.brot.dg con il protocollo POP3, utilizzando il nominativo-utente tizio che richiede la parola d'ordine frase segreta (che appare opportunamente tra virgolette).
poll roggen.brot.dg protocol pop3 username tizio password "frase segreta" poll schwarz.brot.dg username tizio1 password "ciao ciao" |
Qui si prevede la scansione di due serventi, dove nel secondo caso non viene specificato il protocollo e anche il nominativo utilizzato risulta differente dal primo.
poll roggen.brot.dg
protocol pop3
username tizio
password "frase segreta"
poll schwarz.brot.dg
username tizio1
password "ciao ciao"
|
Come nell'esempio precedente, ma più strutturato e più facile da leggere.
poll roggen.brot.dg protocol pop3
username tizio password "frase segreta" is tizio here
username caio password "ciao caio" is caio2 here
username pippo password "marameo maramao" is pippo here
|
In questo caso, per uno stesso servente sono stati indicati diversi utenti remoti e locali. Per intendere il senso, si osservi che l'utente remoto caio corrisponde all'utente locale caio2.
|
Evidentemente, per ottenere un tale risultato, è necessario che l'utente che avvia Fetchmail conosca tutte le parole d'ordine di questi utenti. |
Trattando l'argomento del trasferimento della posta remota, non bisogna dimenticare i programmi MUA (Mail user agent) che si arrangiano a scaricarsela. L'esempio più semplice di questo genere di programmi è Balsa.
Utilizzando un MUA di questo tipo, se si dispone di un elaboratore connesso saltuariamente a Internet, non serve alcun sistema di gestione della posta elettronica locale e nemmeno alcun programma per scaricarla dal recapito presso il fornitore di accesso, salve naturalmente le esigenze di altri programmi.
Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini --daniele @ swlibero.org1) IMAP toolkit software libero con licenza speciale
3) È questo punto che può rendere vantaggioso l'utilizzo di Popclient al posto di Fetchmail.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome messaggi_giunti_presso_recapiti_remoti.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]