In questo capitolo viene spiegato come impostare il sistema per l'uso della posta e delle news, un argomento che, a causa della sua complessità, se viene trattato in forma generale rischia di diventare incomprensibile per chi vi si accosta per la prima volta. Questo è dovuto al fatto che esiste una grande molteplicità di situazioni possibili (sia per quanto riguarda le tipologie di collegamento sia per quanto riguarda le modalità di lavoro) e che non si tratta di configurare un singolo programma ma di mettere insieme un sofisticato gruppo di programmi che cooperano al funzionamento del sistema. Per questo motivo l'argomento viene trattato illustrando un esempio che descrive una possibile configurazione per un PC di uso domestico collegato a Internet tramite un provider, una situazione molto comune che, pur non presentando particolari difficoltà, può rivelarsi abbastanza spinosa da gestire se non si sa dove mettere le mani.
Oltre alle impostazioni di sistema, viene descritta la configurazione necessaria per due tra i più diffusi e apprezzati programmi per la posta e le news: mutt e tin. I programmi in se stessi non vengono descritti, anche perché sono semplici da usare e ben documentati. Naturalmente, sia mutt sia tin non sono scelte obbligate e l'utente è libero di installare gli applicativi che preferisce; in particolare, chi non ama i programmi in modo testo potrà trovare valide alternative sotto X.
In breve, i programmi richiesti per la configurazione descritta in questo capitolo sono:
sendmail
fetchmail
m4
mutt
tin
Di questi, solo sendmail e m4 sono già presenti nel sistema base; gli altri possono essere installati dalla collezione dei package.
Prima di proseguire, vorrei ricordare ancora una volta che nessuno dei programmi presentati in questo capitolo è una scelta obbligata; esistono numerose altre alternative a ognuno di essi ma, comunque, costituiscono un buon punto di partenza. Anche la strategia utilizzata per l'invio e la ricezione della posta non è l'unica. Ognuno poi la può modificare a seconda della propria configurazione e delle proprie esigenze.
All'estremo opposto dei programmi e della strategia illustrati in questo capitolo c'è l'utilizzo di un programma tuttofare come Netscape Communicator: con questo tipo di programma si può navigare su Internet, ricevere e inviare posta e leggere le news; inoltre la sua configurazione è molto semplice. Lo svantaggio di questo tipo di approccio è che Netscape è un sistema chiuso, che non coopera con gli altri programmi di NetBSD.
Un altro approccio molto seguito è quello di leggere la posta e le news utilizzando le apposite modalità di emacs. Emacs non ha certo bisogno di presentazioni per gli appassionati di Unix ma, per chi non lo sapesse, si tratta di un editor avanzato (veramente chiamarlo editor è un po' riduttivo) che si trasforma in un vero e proprio ambiente di lavoro all'interno del quale è possibile leggere la posta e le news ed effettuare molte altre operazioni. La configurazione di emacs per la posta e le news è descritta nel manuale del programma.
Nel seguito di questo capitolo si farà riferimento a un host collegato a Internet tramite un collegamento seriale PPP via modem con un provider. I dati per la configurazione sono:
l'host locale si chiama "ape" e la rete è "insetti.net", per cui il FQDN (Fully Qualified Domain Name) è "ape.insetti.net".
Il nome dell'utente id esempio su ape è "carlo".
Il provider utilizzato si chiama BigNet.
Il server di posta del provider è "mail.bignet.it"
Il nome di login presso il provider dell'utente "carlo" è "alan" e la sua password è "pZY9o".
Prima di incominciare, un po' di terminologia:
(mail user agent): programma che permette di scrivere e leggere la posta. Per esempio: mutt, elm e pine ma anche il semplice mail preinstallato.
(mail transfer agent): programma che provvede a inoltrare la posta, trasferendola da un computer a un altro ma anche in locale. Il MTA è il programma che decide il percorso che la posta deve seguire per arrivare a destinazione. Sui sistemi BSD (ma non solo) lo standard è sendmail.
(mail delivery agent): programma, solitamente usato dal MTA, che serve per la consegna della posta: per esempio per mettere fisicamente i messaggi nella casella postale dell'utente destinatario. Per esempio, sendmail utilizza uno o più MDA per consegnare la posta.
La figura Figura 12-1 illustra il sistema di posta che si vuole organizzare. Tra la rete domestica (o anche l'host singolo) e il provider vi è una connessione PPP via modem. Le "bolle" con il bordo spesso si riferiscono a comandi lanciati esplicitamente dall'utente; le restanti "bolle" sono i programmi lanciati in automatico. I numerini cerchiati si riferiscono alle varie fasi logiche del processo di gestione del ciclo della posta:
Nella fase (1) la posta viene recuperata (scaricata) dal server POP del provider mediante fetchmail, che usa sendmail per metterla nella casella postale dell'utente.
Nella fase (2) l'utente esegue mutt (o un altro client di sua scelta) per leggere la posta, rispondere ai messaggi ricevuti e scriverne di nuovi.
Nella fase (3) l'utente invia la posta da mutt. I messaggi vengono accumulati nell'area di spool.
Nella fase (4) l'utente chiama sendmail per trasferire i messaggi al server SMTP del provider da dove verranno spediti ai destinatari.
Il collegamento con il provider deve essere attivo solamente durante le fasi (1) e (4); per le restanti operazioni può tranquillamente essere chiuso.
Quando un MTA, sendmail in questo caso, riceve un messaggio di posta da spedire, se si tratta di un mesaggio locale lo spedisce direttamente. Altrimenti, se il messaggio è destinato a un altro dominio deve procurarsi l'indirizzo del server di posta del dominio in questione. Per fare ciò il MTA si appoggia al servizio DNS (descritto nel Capitolo 11; il server DNS del dominio di destinazione conosce l'indirizzo del server di posta (record MX) e lo fornisce al MTA che, a questo punto, può spedire il messaggio al server destinatario.
Il MTA più diffuso, almeno in ambiente BSD, è sendmail. Il comportamento di sendmail è controllato dal file di configurazione, /etc/mail/sendmail.cf e da una serie di file accessori. In generale, a meno di non essere degli esperti, non è consigliabile scrivere o modificare questo file direttamente; il file di configurazione si può generare automaticamente utilizzando un insieme di macro M4 che facilita molto il compito.
Nota: nelle versioni di NetBSD precedenti la 1.5 i file di configurazione di sendmail si trovavano in /etc anziché in /etc/mail.
Anche utilizzando le macro, la configurazione di sendmail è un argomento piuttosto ostico (a dir poco) e nel seguito mi limito a mostrare un esempio base, che può essere usato come punto di partenza e modificato per gestire la propria posta in presenza di configurazioni differenti. Per un collegamento a Internet via modem, il file presentato può essere usato tale e quale senza bisogno di alcuna modifica (salvo naturalmente inserire i propri dati al posto di quelli del'esempio).
Il primo problema da risolvere è che la rete domestica è del tutto fittizia, ossia non esiste realmente su Internet, e quindi i nomi e gli indirizzi interni non hanno senso per il mondo esterno. In breve, l'host "ape.insetti.net" non è raggiungibile da nessun altro host di Internet e se si manda un'e-mail con il nome locale dell'host nel mittente nessuno potrà rispondere (non solo, ma alcuni destinatari rifiuteranno il messaggio perché il mittente è inesistente). Il vero indirizzo, quello visibile da tutti, è quello assegnato dal provider. Quindi bisognerà trasformare l'indirizzo locale "carlo@ape.insetti.net" nell'indirizzo assegnato dal provider: "alan@bignet.it". Di questo si occuperà sendmail, opportunamente configurato, al momento di trasferire la posta.
Il secondo aspetto da considerare, è che conviene istruire sendmail per fargli inviare la posta al mail server del provider. Nella configurazione descritta in questa sezione, infatti, sendmail non si mette direttamente in contatto con i server di posta dei destinatari dei nostri messaggi (come descritto all'inizio di questa sezione), ma si appoggia solo sul server del provider, utilizzandolo come relay. Questo rende molto più veloce l'invio della posta, demandando tutto il lavoro di ricerca e di collegamento al server di posta del provider.
Nota: si dice che un server di posta agisce da relay quando si occupa di inoltrare posta che non è di sua competenza diretta. In questo caso il server di posta relay agisce da intermediario, provvedendo a inoltrare la posta al server destinatario (o a un altro server relay).
Poiché la connessione con il provider non è sempre attiva si può disabilitare l'avvio di sendmail come demone in /etc/rc.conf con la riga 'sendmail=NO'. La posta locale verrà comunque spedita correttamente, mentre per trasferire la posta al provider sarà necessario lanciare sendmail manualmente (quando il collegamento con il provider è attivo, naturalmente).
Incominciamo quindi il lavoro di configurazione di sendmail.
Questo tipo di configurazione utilizza il file /etc/mail/genericstable contenente le regole di riscrittura esplicite per gli indirizzi interni alla rete locale.
Per prima cosa, quindi, bisogna creare il file genericstable. Per esempio:
carlo: alan@bignet.it root: alan@bignet.it news: alan@bignet.it
Per motivi di efficienza genericstable deve essere trasformato con il comando:
# /usr/sbin/sendmail -bi -oA/etc/mail/genericstable
Ora è il momento di creare il prototipo che verrà utilizzato per generare il nuovo file di configurazione di sendmail. La prima cosa da fare è portarsi nella directory dove verrà creato il nuovo file di configurazione:
# cd /usr/share/sendmail/m4
Supponiamo di chiamare il prototipo mycf.mc. Il contenuto del file è il seguente:
divert(-1)dnl include(`../m4/cf.m4')dnl VERSIONID(`mycf.mc creato da carlo@ape.insetti.net May 18 2001')dnl OSTYPE(bsd4.4)dnl dnl # Impostazioni per masquerading. Vengono riscritti gli dnl # indirizzi del tipo dnl # carlo@ape.insetti.net dnl # carlo@ape GENERICS_DOMAIN(ape.insetti.net ape)dnl FEATURE(genericstable)dnl FEATURE(masquerade_envelope)dnl define(`SMART_HOST',`mail.bignet.it')dnl FEATURE(redirect)dnl FEATURE(nocanonify)dnl dnl # La feature seguente serve soprattutto se sendmail viene usato dnl # insieme a fetchmail. Fetchmail chiama sendmail per spedire la dnl # posta. Se sendmail non riesce a risolvere il nome del mittente dnl # la posta non viene consegnata. Per esempio: dnl # MAIL FROM:<www-owner@netbsd.org> SIZE=2718 dnl # 501 <www-owner@netbsd.org>... Sender domain must exist FEATURE(`accept_unresolvable_domains')dnl dnl # accept_unqualified_senders accontenta alcuni MUA, che inviano dnl # la posta come dnl # MAIL FROM:<carlo> FEATURE(`accept_unqualified_senders')dnl dnl # La posta per il mailer `smtp' viene messa in coda: sendmail non dnl # tenta di inviarla direttamente (il flag `e' indica `expensive'). dnl # Sendmail inizia a lamentarsi dopo 16 ore di mancata consegna. define(`SMTP_MAILER_FLAGS',`e')dnl define(`confCON_EXPENSIVE',`True')dnl define(`confTO_QUEUEWARN', `16h')dnl dnl # Per gli utenti europei define(`confDEF_CHAR_SET',`ISO-8859-1')dnl dnl # Abilitare le due linee seguenti per utilizzare procmail per dnl # la consegna della posta locale. Vedere anche la riga dnl # con MAILER(procmail) dnl # define(`PROCMAIL_MAILER_PATH', /usr/pkg/bin/procmail)dnl dnl # FEATURE(local_procmail)dnl dnl # I due mailer seguenti devono sempre essere definiti MAILER(local)dnl MAILER(smtp)dnl dnl # Abilitare opzionalmente la riga seguente (non e' necessaria dnl # per usare procmail) dnl # MAILER(procmail)dnl
Nota: nell'esempio precedente, le linee che iniziano con "dnl" sono dei commenti e non sono quindi necessarie per la generazione del file di configurazione (il simbolo "dnl" indica a m4 di ignorare il resto della linea, e compare anche al termine delle varie direttive (allo scopo di evitare eventuali effetti indesiderati).
Le linee relative all'uso di procmail sono lasciate commentate (ossia l'uso di procmail è disabilitato).
Questa configurazione indica di trasformare gli indirizzi del tipo "ape.insetti.net" andando a trovare i nomi reali nel file /etc/mail/genericstable. Inoltre viene specificato che la posta deve essere inviata all'host "mail.bignet.it". Il significato delle opzioni è descritto in dettaglio nel file /usr/share/sendmail/README.
Per creare il proprio file personalizzato è sufficiente inserire i propri dati modificando solo due righe dell'esempio precedente, e cioè:
GENERICS_DOMAIN(ape.insetti.net ape)dnl define(`SMART_HOST',`mail.bignet.it')dnl
Generiamo il nuovo file di configurazione, salvando prima quello precedente:
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak # m4 mycf.mc > /etc/mail/sendmail.cf
Nota: in /usr/share/sendmail/cf c'è il file netbsd-proto.mc, che viene utilizzato per creare la versione /etc/mail/sendmail.cf che viene distribuita di default con NetBSD. Non dovrebbe essere mai necessario, ma con il comando make lo si può costruire.
Un altro file importante è /etc/mail/aliases, che però può essere mantenuto con la configurazione di default. Bisogna comunque dare il comando:
# newaliases
Ora tutto è pronto per spedire la posta.
Adesso che la configurazione di sendmail è completa si può procedere a alcune semplici verifiche, per confermare che tutto funzioni correttamente. Come primo test si può spedire un messaggio in locale:
$ sendmail -v carlo Subject: test Prova . carlo... Connecting to local... carlo... Sent
Seguire lo schema dell'esempio, lasciando una linea vuota dopo Subject: e concludendo il messaggio con una linea contenente un solo punto. Il messaggio inviato dovrebbe essere leggibile utilizzando il client di posta; in particolare si verifichi il contenuto del campo
From: alan@bignet.it
nel quale ci deve essere stata la riscrittura dell'indirizzo.
Una seconda verifica importante è il test delle regole di riscrittura impostate nel file di configurazione di sendmail. Per fare ciò si esegue sendmail in modalità test: sendmail legge un indirizzo e mostra tutti i passaggi effettuati per trasformarlo. In questa modalità si possono anche effettuare altri tipi di test nonché visualizzare varie informazioni.
Avviare sendmail in modalità test usando l'opzione -bt
$ /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> >
Per visualizzare l'aiuto, utilizzare il comando '?'.
Per prima cosa verifichiamo il corretto funzionamento del file genericstable dando questo comando:
/map generics carlo map_lookup: generics (carlo) returns alan@bignet.it
Fin qui tutto bene: sendmail ha trovato il nome locale e il suo corrispondente reale nella mappa generics.
Ora verifichiamo la riscrittura del mittente nell'envelope dando i comandi:
/tryflags ES /try smtp carlo@ape.insetti.net
Il risultato dovrebbe essere simile al seguente:
Trying envelope sender address carlo@ape.insetti.net for mailer smtp rewrite: ruleset 3 input: carlo @ ape . insetti . net rewrite: ruleset 96 input: carlo < @ ape . insetti . net > rewrite: ruleset 96 returns: carlo < @ ape . insetti . net . > rewrite: ruleset 3 returns: carlo < @ ape . insetti . net . > rewrite: ruleset 1 input: carlo < @ ape . insetti . net . > rewrite: ruleset 1 returns: carlo < @ ape . insetti . net . > rewrite: ruleset 11 input: carlo < @ ape . insetti . net . > rewrite: ruleset 51 input: carlo < @ ape . insetti . net . > rewrite: ruleset 51 returns: carlo < @ ape . insetti . net . > rewrite: ruleset 61 input: carlo < @ ape . insetti . net . > rewrite: ruleset 61 returns: carlo < @ ape . insetti . net . > rewrite: ruleset 94 input: carlo < @ ape . insetti . net . > rewrite: ruleset 93 input: carlo < @ ape . insetti . net . > rewrite: ruleset 3 input: alan @ bignet . it rewrite: ruleset 96 input: alan < @ bignet . it > rewrite: ruleset 96 returns: alan < @ bignet . it > rewrite: ruleset 3 returns: alan < @ bignet . it > rewrite: ruleset 93 returns: alan < @ bignet . it > rewrite: ruleset 94 returns: alan < @ bignet . it > rewrite: ruleset 11 returns: alan < @ bignet . it > rewrite: ruleset 4 input: alan < @ bignet . it > rewrite: ruleset 4 returns: alan @ bignet . it Rcode = 0, addr = alan@bignet.it >
Come si può vedere l'indirizzo locale è stato riscritto in quello reale, che comparirà nei messaggi quando lasciano il sistema.
Un risultato equivalente si può ottenere con il comando:
/try smtp carlo
Per verificare la riscrittura del mittente nell'intestazione, ripetiamo i comandi precedenti cambiando i flag; il risultato è equivalente.
/tryflags HS /try smtp carlo@ape.insetti.net
A partire dalla versione 1.4 di NetBSD sendmail non viene richiamato direttamente:
$ ls -l /usr/sbin/sendmail lrwxr-xr-x 1 root wheel 21 Nov 1 01:14 /usr/sbin/sendmail@ -> /usr/sbin/mailwrapper
Lo scopo di mailwrapper è di semplificare l'uso di MTA alternativi a sendmail (per esempio postfix) ma, per farsi un'idea precisa di cosa si tratta, consiglio la lettura delle pagine di manuale mailwrapper(8) e mailer.conf(5), che sono molto chiare.
La posta viene ricevuta all'indirizzo presso il provider; a questo punto è necessario trasferirla (fisicamente) in locale. fetchmail è un programma che recupera la posta da un server di posta remota e la inoltra al sistema locale per la consegna (solitamente mediante sendmail). fetchmail è semplice da usare e da configurare; dopo averlo installato è sufficiente creare il file .fetchmailrc nella propria home directory (c'è dentro la password, attenzione ai permessi...). Ecco un esempio:
poll mail.bignet.it protocol POP3 username alan there with password pZY9o is carlo here flush mda "/usr/sbin/sendmail -oem %T"
Nota: la riga con "mda ..." serve solo se sendmail non è attivo come demone sul sistema. Inoltre si noti che il server di posta specificato in questo file potrebbe essere diverso dal relay usato da sendmail.
Per trasferire la posta basta dare il comando:
$ fetchmail
e poi la si può leggere con mutt.
mutt è un programma di posta che riceve molti consensi, sia perché è leggero sia perché è semplice da usare e potente al tempo stesso. mutt ha una pagina di manuale molto scarna; la vera documentazione si trova in /usr/pkg/share/doc/mutt/, in particolare in manual.txt.
La configurazione di mutt avviene tramite il file .muttrc, che deve essere creato nella propria home directory (di solito copiando il file di esempio fornito con mutt e poi modificandolo). L'esempio seguente mostra come modificare alcune righe del file per ottenere i seguenti effetti:
Salvare i messaggi inviati.
Definire una directory per la posta in arrivo e in uscita salvata da mutt (verrà messa nella subdirectory ~/Mail nei file incoming e outgoing).
Definire alcuni colori.
Definire un alias.
set copy=yes set edit_headers set folder="~/Mail" unset force_name set mbox="~/Mail/incoming" set record="~/Mail/outgoing" unset save_name bind pager <up> previous-page bind pager <down> next-page color normal white black color hdrdefault blue black color indicator white blue color markers red black color quoted cyan black color status white blue color error red white color underline yellow black mono quoted standout mono hdrdefault underline mono indicator underline mono status bold alias pippo Pippo Verdi <pippo.verdi@pluto.net>
Per lanciare mutt è sufficiente dare il comando
$ mutt
Nota: a seconda del terminale mutt supporta l'uso di colori diversi per i diversi elementi delle schermate. Sotto X si può usare xterm-color. Per esempio:
TERM=xterm-color mutt
Questa sezione descrive una semplice strategia per ricevere e leggere la posta. La connessione con il provider viene attivata solo per il tempo necessario al trasferimento della posta, che viene poi letta offline.
Attivare la connessione con il provider.
Dare il comando fetchmail.
Chiudere la connessione con il provider.
Leggere la posta con mutt.
Una volta scritta e inviata la posta con mutt, la si deve inviare al server del provider con sendmail. L'invio della posta da mutt, che si effettua con il comando y, si limita a accodare le missive nello spool; a questo punto, se sendmail non è attivo come demone bisogna provvedere a chiamarlo esplicitamente. I passi da seguire sono:
Scrivere la posta con mutt, dare il comando di invio e uscire da mutt.
Attivare la connessione con il provider.
Dare il comando /usr/sbin/sendmail -q -v per trasferire la posta al provider.
Chiudere la connessione con il provider.
Quando si incomincia a usare la posta, generalmente non si hanno esigenze molto sofisticate e, pertanto, la configurazione standard descritta sopra è più che sufficiente. Con il passare del tempo, però, per molti utenti il volume di posta giornaliera cresce e si differenzia. A questo punto diventa necessario organizzare razionalmente i messaggi, separandoli in "caselle" diverse e ci si accorge di dover compiere un gran numero di operazioni manuali ripetitive ogni giorno per smistare la posta. Per esempio, chi si iscrive a mailing list può trovarsi a dover smistare quotidianamente un notevole numero di messaggi, per traferirli dalla mailbox di default all'apposita mailbox dedicata alla mailing list.
Perché effettuare a mano operazioni che possono essere agevolmente svolte da un programma? Esistono vari strumenti aggiuntivi che si inseriscono nel flusso normale della posta e consentono di effettuare varie elaborazioni sulla posta in base a configurazioni prefissate dall'utente. Tra i tool più conosciuti e usati troviamo:
procmail, un mail delivery agent e filtro avanzato per la posta locale, che consente di elaborare automaticamente la posta in base a regole predisposte dall'utente ridefinendone, per esempio, la destinazione. Quel che è meglio, però, è che si integra completamente con sendmail.
metamail, uno strumento per elaborare gli allegati (attachment) contenuti nei messaggi di posta elettronica.
formail, un programma per riformattare i messaggi di posta.
Nel seguito di questa sezione verrà descritto un esempio d'uso di procmail, senza scendere però nei dettagli della configurazione e delle caratteristiche del programma, poiché si tratta di uno strumento che ha una grandissima varietà di usi. Ci si limiterà, quindi, a descrivere la configurazione di sendmail e procmail per un caso molto comune: lo smistamento della posta proveniente da mailing list. Per questo tipo di configurazione si farà in modo che sendmail utilizzi procmail come mailer locale; procmail, dal suo canto, leggerà un apposito file di configurazione contenente le regole di smistamento della posta.
Per prima cosa bisogna installare procmail, ricorrendo al sistema dei package (mail/procmail).
Poi bisogna configurare sendmail perché usi procmail. Per far ciò è sufficiente togliere il commento dalle linee relative a procmail dal file di configurazione di sendmail già descritto:
define(`PROCMAIL_MAILER_PATH', /usr/pkg/bin/procmail)dnl FEATURE(local_procmail)dnl MAILER(procmail)dnl
La prima riga specifica il percorso del programma procmail e deve essere cambiata a seconda di dove è stato installato (il che si può determinare con il comando which procmail). La seconda riga indica a sendmail di usare procmail come mailer locale e la terza aggiunge procmail all'elenco dei mailer di sendmail (questa riga è opzionale).
Infine si crea il file di configurazione di procmail, .procmailrc, nelle propria home directory. Questo file contiene le regole per la consegna della posta in locale ed è utilizzato dal programma per decidere la destinazione dei messaggi.
A titolo di esempio si immagini di essere iscritti a una mailing list sulle rose, il cui indirizzo è <roses@flowers.org>. Supponiamo, inoltre, che tutti i messaggi che arrivano da questa mailing list contengano, nell'intestazione, la stringa
Delivered-To: roses@flowers.orgIl file di configurazione di procmail ha un aspetto di questo tipo:
PATH=/bin:/usr/bin:/usr/pkg/bin MAILDIR=$HOME/Mail LOGFILE=$MAILDIR/from :0 * ^Delivered-To: roses@flowers.org roses_list
Il file precedente contiene una sola regola di smistamento, che inizia con la riga ":0". La configurazione precedente ridirige tutta la posta proveniente dalla mailing list nella mailbox di nome "roses_list" che l'utente avrà opportunamente creato nella directory $MAILDIR. Si noti che $MAILDIR è la stessa directory indicata nella direttiva del file di configurazione di Mutt
set folder="~/Mail"
I messaggi provenienti dalla mailing list vengono identificati dalla riga:
* ^Delivered-To: roses@flowers.org
contenuta nell'intestazione. I rimanenti messaggi andranno nella mailbox di default.
La mailing list è, naturalmente, solo un esempio, e procmail può essere usato per smistare qualunque tipo di messaggio in base, per esempio, alla provenienza, al contenuto, ecc.
Per controllare che procmail venga usato come mailer locale da sendmail si può eseguire quest'ultimo in modalità test nel modo seguente:
$ /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> >
Ora si richiede l'elenco dei mailer noti a sendmail con il comando
> =M
Nell'output dovrebbe comparire una riga di questo tipo:
mailer 3 (local): P=/usr/pkg/bin/procmail S=EnvFromL/HdrFromL ...
Come sempre, per ulteriori dettagli e per farsi un'idea più precisa delle potenzialità di procmail, consultare la pagina di manuale di procmail(1), procmailrc(5) e procmailex(5), quest'ultima contenente esempi di configurazione.
Prima di passare ai newsgroup ho deciso di inserire questo piccolo "trucco" con la posta perché può essere utile: si tratta di verificare interattivamente la veridicità di un indirizzo di posta.
Nota: non tutti i server accettano il comando VRFY, che può essere disabilitato.
Supponiamo di voler verificare l'utente carlo@dominio.com: il metodo è il seguente:
$ telnet dominio.com smtp Trying aa.bb.cc.dd... Connected to dominio.com. Escape character is '^]'. 220 dominio.com ESMTP Sendmail 8.9.3/8.9.3; Fri, 30 Apr 1999 VRFY carlo 250 Carlo Rossi VRFY abcde 550 abcde... User unknown ^] telnet> quit Connection closed.
Con il termine news si indica l'insieme degli articoli dei newsgroup di USENET, un servizio disponibile su Internet. Ogni newsgroup raccoglie articoli relativi a uno specifico argomento. Il meccanismo di lettura degli articoli è diverso rispetto alle mailing list. Quando ci si iscrive a una mailing list, gli articoli ci vengono inviati tramite posta e per leggerli (e rispondere) si usa un programma di posta (come, per esempio, mutt). La consultazione delle news avviene invece in modo diretto, utilizzando un programma detto newsreader come, per esempio, tin, che consente di effettuare la sottoscrizione ai gruppi che ci interessano e di seguirne i thread.
thread: un thread è una sequenza di messaggi (risposte e controrisposte) derivanti da un messaggio che potremmo definire "iniziale". In pratica, qualcuno invia un messaggio al gruppo, altri inviano una risposta al messaggio originale, altri ancora (o magari gli stessi) rispondono a quelli che hanno risposto e così via, fino a creare una struttura ramificata di mesaggi e risposte. Senza un newsreader è impossibile districarsi nel groviglio (leggi "sequenza logica") dei thread.
Una volta installato il programma l'unica cosa da fare è impostare il nome del server NNTP, scrivendolo nel file /usr/pkg/etc/nntp/server. Per esempio:
news.bignet.it
Fatto questo si può lanciare il programma con il comando rtin. Sullo schermo comparirà una serie di scritte di questo tipo:
$ rtin Connecting to news.bignet.it... news.bignet.it InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (posting ok). Reading groups from active file... Checking for new groups... Reading attributes file... Reading newsgroups file... Creating newsrc file... Autosubscribing groups... Reading newsrc file...
Bisogna avere pazienza quando ci si collega per la prima volta, perché tin scarica una lista infinita di newsgroup alla quale ci si può iscrivere: l'operazione dura parecchi minuti. Terminato lo scaricamento compare la schermata del programma, solitamente vuota. Per vedere l'elenco dei gruppi premere y. Per sottoscriversi a un gruppo, portarsi sul nome del gruppo e premere s.
Per velocizzare gli avvii successivi si può usare il comando rtin -Q. In questo modo si evita la ricerca di nuovi newsgroup, si caricano solo i gruppi attivi (-n) e non si caricano le descrizioni dei gruppi(-d): naturalmente non sarà possibile usare il comando y (yank) durante la sessione con tin. Quando si avvia tin in questo modo il programma non è in grado di sapere quali newsgroup sono moderati.
Nota: se ci si collega a Internet tramite un provider con un computer che non appartiene quindi a un "vero" dominio, quando si invia un messaggio l'indirizzo in testa al messaggio sarà sbagliato (perché inesistente). Per risolvere il problema si può usare l'opzione "mail_address" nel file di configurazione di tin (~/.tin/tinrc) oppure si può impostare la variabile di ambiente REPLYTO.