Posta Off-Line HOW-TO <author><htmlurl url="http://www.eurolink.it/˜mirko/" name="Mirko Caserta">, <tt><htmlurl url="mailto:ik0zsn@amsat.org" name="ik0zsn@amsat.org"></tt> <date>Aprile 1997 <abstract> Questo documento si prefigge di descrivere come configurare la propria macchina Linux per utilizzare al meglio i servizi di posta elettronica nel caso in cui non si abbia a disposizione una connessione permanente alla rete Internet ma piuttosto ci si debba collegare ad un provider (generalmente via modem in PPP o SLIP tramite rete telefonica commutata) che fornisce i servizi SMTP e POP3. In particolare, lo scopo di questo documento consiste nell'incoraggiare l'utente di Eudora a passare in modo definitivo ad un sistema di messaggistica basato su un software (o una serie di software) che gira sotto Linux (ma non solo visto che quasi tutti i pacchetti qui trattati lavorano anche sotto altri UNIX). </abstract>  <toc>  <sect>Introduzione Provate ad indovinare quale è il servizio Internet più utilizzato in tutto il mondo? Si, è proprio la posta elettronica. Effettivamente l'email è di un'utilità spaventosa: permette di scambiare messaggi con persone in tutto il mondo (chiaramente devono avere anche loro accesso ai servizi di email) includendo file e quindi documenti, filmati, immagini, suoni, ecc. Uno dei motivi per cui ho scritto questo documento risiede nel fatto che quando ho iniziato ad usare Linux, ciò che ancora mi legava a Windows 95 e Eudora (ebbene si, devo confessarlo) era la posta elettronica. Se avessi avuto questa documentazione all'epoca, probabilmente avrei lasciato definitivamente Windows 95 molto prima! Inoltre ho una memoria pessima per cui tendo a scrivere tutto ciò che andrebbe altrimenti perso, anche le cose più banali e semplici. Quindi perchè non farne una documentazione utile a tutti? <sect1>Prerequisiti Se vi siete posti il problema di utilizzare la posta elettronica allora probabilmente sapete già di cosa si tratta. Magari siete anche in grado di prelevare le versioni più recenti di tutti i software che fanno al nostro caso da un sito ftp come sunsite.unc.edu o uno dei suoi mirror. O almeno avete un cdrom con una distribuzione di Linux che contiene tali software. O ancora avete su cdrom il sunsite o un altro sito che contiene software a iosa per Linux. Come? Sei sicuro di si? Aspetta... hai installato il supporto per il TCP/IP nel kernel? E quello per il PPP? E la seriale è configurata correttamente? E il modem? E la versione di <tt/pppd/ che hai è compatibile con la versione del kernel che usi attualmente? E riesci a collegarti in PPP o SLIP al tuo provider in modo corretto? Come? Davvero? Davvero hai risposto si a tutte le domande? Bene, allora vai pure avanti. In caso contrario consiglio vivamente una visita alla <tt><url url="http://www.dei.unipd.it/it/linux/pluto" name="home page del PLUTO"></tt> ed alla documentazione disponibile in linea grazie ai collaboratori del PLUTO. Nel mondo reale le cose non sono così drastiche come le ho descritte qui sopra poichè la distribuzione di Linux che hai installato probabilmente ha già provveduto a risolvere gran parte dei problemi che potresti incontrare. Per chi cerca un'interfaccia user friendly alla configurazione di <it/pppd/ (e non solo) consiglio il pacchetto <it/linuxconf/ che ho avuto modo di provare una volta e mi è sembrato molto ben fatto. Per chi usa la Red Hat invece c'è <tt/netcfg/ che permette di configurare una interfaccia PPP in modo simile a <it/linuxconf/ (o viceversa, dipende da chi ha copiato l'altro). Non pensare che ti voglia scoraggiare con quanto ho detto sopra. Semplicemente non vorrei che considerassi questo documento troppo globale. Qui si parla solo di <bf/posta off-line/. Inoltre ho un pessimo vizio: non scrivo mai riguardo cose che non conosco :) per cui se c'è qualcuno che si vuole fare avanti e spiegarci come usare IMAP, UUCP, ecc si faccia avanti. Quasi dimenticavo... condizione essenziale perchè tu possa usare la posta elettronica è la conoscenza degli indirizzi dei server POP3 e SMTP del tuo provider. <sect1>Disclaimer Inutile dire che potrei aver scritto cose inesatte in questo documento (spero di non aver preso delle grosse cantonate! Mica mi avete preso per un wizard?!?) per cui vi prego di non assalirmi ma, piuttosto, scrivetemi cosa correggere, aggiungere, modificare, eliminare, disintegrare, e così via... <sect1>Copyleft Questo documento è sottoposto ai termini della <it/GNU General Public Licence/ disponibile via ftp da <tt><htmlurl url="ftp://prep.ai.mit.edu/pub/gnu/COPYING" name="ftp://prep.ai.mit.edu/pub/gnu/COPYING"></tt>. <sect1>Altre risorse in rete Lo scopo di questo documento non è spiegare cosa sia la posta elettronica in generale e come configurare il proprio sistema operativo per usarla al meglio. Ci sono altri documenti che trattano quest'argomento in modo esplicito ed esaustivo. In particolare consiglio: <itemize> <item><it/"The Linux Electronic Mail HOWTO"/ di Vince Skahan <item><it/"Queue-R-Mail-HOWTO: Queue Remote Mail + Deliver Local Mail"/ di Leif Erlingsson <item><it/"Linux PPP HOWTO"/ di Al Longyear </itemize> Il sito ufficiale di questi HOWTO è <tt><url url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO" name="sunsite.unc.edu"></tt> o uno dei suoi mirror. Per quanto riguarda la connessione con i provider Italiani c'è il <it/"Provider Italiani HOWTO"/ di Alberto Menegazzi, prelevabile dal <url url="http://www.psico.unipd.it/ildp/altri/index.html" name="sito web di ILDP">. Presso questo stesso URL troverai questo HOWTO. L'ultima versione del <it/Posta Off-Line HOWTO/ è sempre disponibile all'indirizzo <htmlurl url="http://www.eurolink.it/˜mirko/po/" name="http://www.eurolink.it/˜mirko/po/"> Marco d'Itri <htmlurl url="mailto:md@linux.it" name="(md@linux.it)">, come i migliori sostenitori di Linux, si è immoltato sull'altare sacrificale (che animali sacrificheranno mai 'sti guru di Linux? GNU forse? ...si, lo so che potrei anche risparmiarmele queste battute...) e mi ha autorizzato a pubblicare il suo indirizzo email in modo da poter essere contattato per le problematiche relative ad <it/uso e configurazione di UUCP/. <sect1>Ringraziamenti Vorrei ringraziare per la collaborazione, in rigoroso ordine alfabetico: <itemize> <item>Arrigo Benedetti (benedett@dsi.unimo.it) <item>Daniele Carbonetti (ftplinux@rtmol.it) <item>Ciro Cattuto (ciro@stud.unipg.it) <item>Marco D'Itri (md@linux.it) <item>Alberto Menegazzi (flash.egon@iol.it) <item>Daniele Sanna (dsanna@mbox.vol.it) </itemize> Un particolare ringraziamento va a Linus Torvalds, il LDP, l'ILDP, il gruppo PLUTO e l'intera comunità di Linux (ho dimenticato di citare il pianeta Terra e gli abitanti di Marte forse...). <sect1>Glossario Capisco che molte cose in questo glossario e nel resto del documento possono sembrare ovvie ma, credetemi, non lo sono per l'utente alle prime armi. <bf>Email:</bf> Electronic Mail, ovvero <it/"Posta Elettronica"/. <bf>ISP:</bf> Internet Service Provider. Letteralmente <it/"Fornitore di Servizi Internet"/. In poche parole è quell'organizzazione alla quale dobbiamo sborsare una certa quantità di soldi per farci mantenere la casella postale quando siamo lontani da Internet. Un buon ISP ci da anche la possibilità di spedire la posta con il protocollo SMTP. <bf>Mailbox:</bf> la casella postale dove risiedono i messaggi destinati a noi, in attesa di essere prelevati e letti (qualcuno usa anche rispondere di tanto in tanto). La casella postale è in pratica costituita da un file contenente messaggi archiviati e suddivisi in un particolare formato costituito da <it/header/ e <it/corpo/ del messaggio. Gli header forniscono le informazioni tecniche riguardo il messaggio (da chi proviene, a chi è destinato, data e ora, ecc) mentre il corpo del messaggio contiene in genere il testo vero e proprio. <bf>MDA:</bf> Mail Delivery Agent, ovvero <it/"Agente di smistamento della posta"/. Si tratta del software che si occupa di far arrivare al giusto utente i messaggi una volta che sono arrivati sulla macchina di destinazione. Per esempio <tt/procmail/ e <tt/deliver/ sono dei MDA. <bf>MTA:</bf> Mail Transport Agent, ovvero <it/"Agente di trasporto della posta"/. Si tratta del software che ci permette di trasportare la posta attraverso la rete. Per esempio <tt/sendmail/, <tt/smail/, <tt/qmail/, <tt/exim/ sono dei MTA. <bf>MUA:</bf> Mail User Agent, ovvero <it/"Agente di posta dell'utente"/. Niente a che vedere con il SISMI o il SISDE... si tratta semplicemente del software che usiamo per gestire la posta dal lato utente (es: <tt/pine/, <tt/elm/, <tt/XFMail/, <tt/TkRat/, ecc). <bf>POP:</bf> Post Office Protocol. Letteralmente <it/"Protocollo dell'Ufficio Postale"/. Lo si usa per ricevere la posta da un server remoto. I dettagli sono negli RFC 1725, 1225, 1081. Una versione precedente al POP3, il protocollo POP2, è discussa nello RFC 937. <bf>Provider:</bf> vedi ISP. <bf>RFC:</bf> Request For Comments. Letteralmente <it/"Richieste di commenti"/. Quando bisogna definire un nuovo standard riguardo i protocolli usati su Internet, qualcuno si prende la briga di scrivere un RFC contenente le specifiche da usare. Se l' RFC viene approvato diventa uno standard. <bf>SMTP:</bf> Simple Mail Transfer Protocol. Letteralmente <it/"Semplice Protocollo per il Trasferimento della Posta"/ (andate a farglielo capire a quelli di <tt/sendmail/... mi riferisco alla parola <it/semplice/ naturalmente). Lo usiamo per spedire posta al mondo esterno. I dettagli sono negli RFC 819, 821 e 822. <sect>Ricevere la posta Molti ISP oggi forniscono accesso alla mailbox tramite il protocollo POP3. In questo documento tratteremo unicamente tale protocollo dato che gli altri sono usati meno spesso. Inoltre non ci addentreremo nei dettagli di tale protocollo in quanto non è compito di questo documento farlo. Volendo descrivere in breve il protocollo POP3 potremmo dire che il server è in costante ascolto sulla porta TCP/IP 110. Nel momento in cui c'è una connessione da parte di un client su tale porta, il server richiede un'autenticazione (generalmente del tipo <it/nome utente + password/ in chiaro), quindi da accesso alla mailbox tramite una serie di comandi che servono principalmente a <itemize> <item>controllare quanti e quali messaggi si trovano nella mailbox <item>prelevare i messaggi <item>cancellare i messaggi </itemize> In genere queste operazioni vengono svolte tutte in modo automatico da un apposito software. Vediamo quali tra questi sono i più usati e come configurarli. <sect1>Popclient L'ultima versione di popclient è prelevabile via ftp da <url url="ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop" name="sunsite.unc.edu">. Nel momento in cui scrivo la versione corrente è la 3.0 ed il file relativo si chiama <tt>popclient-3.0.tar.gz</tt>. Per un'uso base di popclient basta chiamarlo con le seguenti opzioni: <tscreen>popclient -3 -u utente -p password -o /path/per/la/mia/mailbox nomehost</tscreen> Dunque, vediamo un po' di analizzare questa linea di comando: <itemize> <item><tt/-3/ sta ad indicare che usiamo il protocollo POP3; <item><tt/-u/ deve essere seguito dal nostro nome-utente (il login); <item><tt/-p/ deve essere seguito dalla nostra password sull'host remoto; <item><tt/-o/ indica il percorso completo per la nostra mailbox (il file dove si trova la posta sul nostro computer, non quello remoto). Di solito il percorso è <tt>/var/spool/mail/nome-utente</tt> dove <tt/nome-utente/ è il nostro login sulla macchina Linux locale; <item><tt/nomehost/ deve essere sostituito dal nome del server POP3. </itemize> Facciamo un esempio: Il mio nome-utente è <tt/pippo/, la password <tt/baudo/, la mia mailbox sulla macchina locale si trova sotto <tt>/var/spool/mail/pippo</tt> ed il nome dell'host cui devo collegarmi per prelevare la posta è <tt/katia.rai.it/ ... dunque: <tscreen>popclient -3 -u pippo -p baudo -o /var/spool/mail/pippo katia.rai.it</tscreen> <tt/popclient/ per default cancella la posta sull'host remoto dopo averla scaricata. Per disabilitare questa funzione aggiungi <tt/-k/ tra le opzioni. Come mi ha fatto giustamente notare Alberto Menegazzi (flash.egon@iol.it), <tt/fetchmail/ sostituisce <tt/popclient/, dal quale deriva. E' anche bene fare presente che <tt/fetchmail/, a differenza di <tt/popclient/, ha bisogno di un MDA locale per cui, se abbiamo modificato la configurazione di <tt/sendmail/ per l'uso della coda (come spiegato successivamente), ci troveremmo in difficoltà e l'unica soluzione consiste nell'interfacciare <tt/fetchmail/ a <tt/procmail/ inceve che a <tt/sendmail/. Scusa il giro di parole :) Per interfacciare direttamente <tt/popclient/ a <tt/procmail/ dobbiamo usare l'opzione <tt/-c/ invece di <tt/-o/ per cui un esempio di sintassi corretta potrebbe essere: <tscreen>popclient -3 -u pippo -p baudo -c katia.rai.it | procmail</tscreen> Per ulteriori spiegazioni: <itemize> <item>lanciare <tt/popclient/ senza opzioni per avere un elenco delle opzioni passabili da linea di comando; <item><tt>man popclient</tt> per avere una descrizione dettagliata di tutte le funzioni. </itemize> <sect1>Fetchpop L'ultima versione di fetchpop è prelevabile via ftp da <url url="ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop" name="sunsite.unc.edu">. Nel momento in cui scrivo la versione corrente è la 1.9 (ci sono già in giro delle patch per risolvere alcuni bug di questa versione) ed il file relativo si chiama <tt>fetchpop1.9.tar.gz</tt>. Uno dei vantaggi di fetchpop consiste nella possibilità di essere interfacciato direttamente a procmail (maggiori dettagli su procmail successivamente) usando l'opzione <tt/-p/ sulla linea di comando. Per poter usare <tt/fetchpop/ dovremo farlo partire una prima volta senza parametri sulla linea di comando. Ci verranno chiesti nell'ordine: indirizzo del server POP3, login e password sul server POP3, tempo di inattività espresso in secondi che passa prima di controllare nuovamente l'arrivo di nuova posta quando <tt/fetchpop/ viene lanciato come daemon (opzione <tt/-d/). All'ultima domanda rispondere con 300 che è il valore minimo specificabile, tanto dal momento che usiamo la posta off-line non useremo mai l'opzione <tt/-d/. Non fate caso all'errore che si verifica dopo aver inserito quest'ultimo parametro: è normale in quanto fetchpop cerca di collegarsi al server POP3 e non ci riesce (a meno che non siamo collegati in quel momento). A questo punto <tt/fetchpop/ si è creato un file nella nostra home directory chiamato <tt/.fetchhost/ dove risiedono le informazioni che gli abbiamo dato in questa prima fase. D'ora in poi sarà sufficiente essere collegati alla rete e chiamare <tt/fetchpop/ con le opzioni <tt/-r/ e <tt/-a/ per poter ricevere la nostra posta, inclusi i messaggi eventualmente già letti (opzione <tt/-a/) e, allo stesso tempo, rimuovere i messaggi sul server dopo averli prelevati (opzione <tt/-r/). Quindi la sintassi corretta sarà: <tscreen><verb> fetchpop -a -r </verb></tscreen> e, nel caso vogliamo usare procmail: <tscreen><verb> fetchpop -a -r -p </verb></tscreen> Per ulteriori spiegazioni: <itemize> <item>lanciare <tt/fetchpop -h/ per avere un elenco delle opzioni su linea di comando; <item><tt>man fetchpop</tt> per avere una descrizione dettagliata di tutte le funzioni. </itemize> <sect1>Fetchmail Probabilmente in questo momento <tt/fetchmail/ è il migliore client in circolazione. Ritengo giusto tradurre e riportare le parti salienti del file README: <tscreen><verb> ---------------------------------------------------------------------------- fetchmail è un programma di utilità per il forwarding/prelievo della posta con POP2, POP3, APOP e IMAP, completo, robusto e ben documentato, inteso per essere usato su collegamenti TCP/IP su-richiesta (come connessioni SLIP o PPP). Esso preleva la posta da server remoti e la invia al sistema di smistamento locale della tua macchina, in modo da permettere a MUA come elm o Mail di leggerla. Questa sono le caratteristiche principali di fetchmail. Quelle uniche di fetchmail sono marcate con **. * Supporto per i protocolli **POP2, POP3, **APOP, **IMAP. ** Supporto Kerberos per l'autenticazione dell'utente. ** La macchina viene auto-scandagliata in modo da trovare un server funzionante se non è stato specificato alcun server per la connessione. Così non hai bisogno di sapere in anticipo quali tipi di server stanno girando sulla macchina; l'opzione verbose ti può mostrare quale sta funzionando. ** Smistamento tramite SMTP alla porta 25 della macchina client. Questo significa che la posta viene automaticamente inviata all'MDA locale come se fosse normalmente arrivata dall'esterno via SMTP. ** Timeout se la connessione con il server viene a mancare. ** Supporto per prelevare e forwardare da caselle postali multiple che garantisce di non causare loop con la posta. * Semplice controllo tramite linea di comando o file di controllo di esecuzione libero-dal-formato. * Modo Daemon -- fetchmail può essere lanciato in background per richiedere la posta da uno o più server ad un intervallo specificato. * Gli header From:, To:, Cc:, e Reply-To: sono riscritti in modo che nomi utenti relativi alla macchina di fetchmail diventino indirizzi Internet completamente qualificati (l'originale Inglese rende meglio: fully-qualified Internet addresses, ndt). Questo fa in modo che le risposte funzionino correttamente. (Sarebbe stata una funzione unica di fetchmail se non l'avessi aggiunta a fetchpop). * Stretto rispetto degli RFC rilevanti e buone opzioni di debugging. Potresti usare fetchmail per fare un debug sulle implementazioni di un server. * Pagina di manuale scritta con cura, comprensiva ed aggiornata, la quale descrive non solo i modi di operazione ma anche (**) come diagnosticare i problemi più comuni e cosa fare riguardo server deficienti. * Codice sorgente a prova di bomba, semplice e ben sperimentato -- l'autore ne fa uso tutti i giorni e non ha mai perso un messaggio, anche nelle versioni sperimentali. * Larga comunità di utenti -- fetchmail ha ereditato una significativa base di utenti dalla comunità di popclient, scritto da Carl Harris. Questo significa che il feedback è rapido e i bachi sono scovati e corretti rapidamente. Puoi facilmente prelevare l'ultima versione di fetchmail via FTP da: ftp://ftp.ccil.org/pub/esr/fetchmail-1.9.tar.gz Oppure puoi prelevarla dalla home page dell'autore: http://www.ccil.org/~esr ---------------------------------------------------------------------------- </verb></tscreen> Bene, spero di averti convinto che <tt/fetchmail/ vale la pena di essere usato nei casi in cui un semplice client POP non è sufficiente. In ogni caso tieni presente il problema già accennato alla fine della sezione relativa a <tt/popclient/: <tt/fetchmail/ ha bisogno di un MDA locale per consegnare la posta quindi, se hai configurato <tt/sendmail/ per l'uso della coda (opzione defer), dovrai usare <tt/procmail/ come MDA. Inoltre alcuni server POP recenti non implementano più il comando LAST (gli utenti di Italia On Line lo sanno bene) per cui per loro si impone l'uso di <tt/fetchmail/. Se hai scaricato il pacchetto con i sorgenti dall'URL indicato qui sopra, allora probabilmente vorrai installarlo. Niente di più semplice! L'autore di fetchmail è un hacker riconosciuto <footnote>attenzione a non confondere la parola hacker con cracker!</footnote> e, come tale, sa come rendere più facile la vita di quelli che non lo sono :) Facciamo un <tt>cd /usr/src</tt> e un <tt>tar vxzf /percorso/per/fetchmail-1.9.tar.gz</tt> in modo da ritrovarci il pacchetto originale scompattato sotto <tt>/usr/src/fetchmail-1.9</tt> Ora entriamo nella directory di <tt/fetchmail/ e digitiamo <tt>configure</tt> Lo script farà un po' di ricerche sulle caratteristiche del nostro sistema e, alla fine, ci riporterà al prompt. Dopo esserci assicurati che il nostro sistema abbia flex versione 2.5.3 o maggiore (è necessario per la compilazione) scrivamo semplicemente <tt/make/ La compilazione dura molto poco (sul mio P60 con 16MB di RAM meno di un minuto). A questo punto basta diventare root e digitare <tt>make install</tt> per installare il programma in <tt>/usr/local/bin</tt> e la pagina di manuale in <tt>/usr/local/man/man1</tt>. Per cambiare queste directory bisogna modificare il Makefile dopo aver lanciato <tt>configure</tt> e prima di aver fatto partire la compilazione con <tt/make/. Per finire dobbiamo andarci a creare il file <tt>~/.fetchmailrc</tt> dandogli i giusti permessi con: <tscreen><verb> chmod go-rwx,u=rw ~/.fetchmailrc </verb></tscreen> Un esempio di <tt>~/.fetchmailrc</tt> è: <tscreen><verb> poll host_remoto with protocol POP3: user tizio there with password secret1 is caio here; </verb></tscreen> In questo modo stiamo dicendo a <tt/fetchmail/ di usare tutti i default (leggi la pagina di manuale al riguardo) e collegarsi al server <it/host_remoto/ per prelevare tramite il protocollo POP3 la posta di <it/tizio/, il quale ha come password <it/secret1/ e sulla macchina locale ha come login <it/caio/. Per ulteriori spiegazioni: <itemize> <item><tt/fetchmail --help/ per avere un elenco delle opzioni su linea di comando; <item><tt>man fetchmail</tt> per avere una descrizione dettagliata di tutte le funzioni. </itemize> <sect1>Smistare la posta in arrivo, ovvero procmail Nell'ambito della gestione della posta off-line, procmail può rivelarsi di estremo aiuto nel caso in cui il volume di email quotidiano superi il normale (non è raro che si verifichi un caso simile: basta iscriversi ad un paio di mailing list dal traffico intenso). Procmail può smistare automaticamente la posta nei folder appropriati filtrando in base a qualsiasi parte di un messaggio (intestazione, uno dei campi dell'intestazione, corpo del messaggio, ecc) oppure può inviarla in pasto (ovvero tramite un pipe) ad un altro programma che potrebbe occuparsi ad esempio di archiviare i messaggi secondo un certo criterio e magari inserendo dei campi opportuni per determinati scopi... insomma le possibilità sono davvero infinite, l'unico limite è la fantasia. Per dire a procmail come smistare la posta andiamo a crearci il file <tt>~/.procmailrc</tt> Il file <tt>~/.procmailrc</tt> è composto da una serie di regole. Per semplificare le cose, diciamo che ogni regola inizia con una riga contenente <tt>:0</tt> seguita da una o più righe che descrivono una condizione (tali righe iniziano con un asterisco seguito da una espressione regolare estesa compatibile con <tt/egrep/), quindi da un'altra riga che descrive l'azione da compiere se le condizioni sono verificate. Vediamo un esempio pratico: <tscreen><verb> :0 * ^From.*tizio * ^Subject:.*patagarro patagarro </verb></tscreen> Se il messaggio viene da <it/tizio/ ed ha come soggetto <it/patagarro/, allora mettilo nella mailbox <it/patagarro/. Altro esempio: <tscreen><verb> :0: * Pluto-meeting `date +%m-%y`/Pluto-meeting </verb></tscreen> Se gli header del messaggio contengono la parola magica <it/Pluto-meeting/ allora mettili in una folder che ha come nome la data corrente nel formato mese-anno più <tt>/Pluto-meeting</tt> <tscreen><verb> :0 * From.*print-server | lpr </verb></tscreen> In questo caso i messaggi provenienti da <it/print-server/ vengono inviati direttamente in pasto alla stampante. Per ulteriori spiegazioni: <itemize> <item><tt>man procmail</tt> per avere una descrizione dettagliata di tutte le funzioni <item><tt>man procmailrc</tt> per avere una descrizione del formato del file <tt>~/.procmailrc</tt> <item><tt>man procmailex</tt> per avere una serie di esempi da usare nel file <tt>~/.procmailrc</tt> <item><tt>man grep</tt> per avere una descrizione delle espressioni regolari estese compatibili con <tt/egrep/ </itemize> <sect1>Un cenno su IMAP Come avevo già accennato nell'introduzione, è mia intenzione parlare per il momento solo di POP3. Ma voglio fare una piccola eccezione e farvi leggere questo articolo molto interessante scritto da Luca Polo e da me pescato su <tt/it.comp.linux/: <tscreen><verb> ---------------------------------------------------------------------------- > Mi avete incuriosito :-) Cos'è l'IMAP 4? Diamine, ma è soltanto il buon vecchio Internet Message Access Protocol versione 4!! :-) Praticamente un super-superset di POP, ma più orientato verso un effettivo client-server (con POP si ha un download, punto), supporto multi-client (io leggo la posta da più macchine in posti diversi), multi-server, ecc. Un altro punto di forza sta nel fatto che è il server IMAP a gestire MIME & Co. (client molto più semplici, e inoltre c'è solo una macchina da tenere aggiornata); inoltre, mediante il protocollo ACAP in fase di sviluppo alla Carnegie Mellon, anche i file di configurazione (personalizzazioni, bookmark, alias) possono risiedere sul server, così anche loro risultano indipendenti dalla singola macchina. La pacchia degli amministratori di sistema, insomma... :-P Poi... beh, guardatevi http://www.imap.org/ Lì c'è tutto, compresi tutti i client conosciuti o in fase di sviluppo; poi ditemi se non vale la pena tenerlo d'occhio... BTW, i server IMAP di mia conoscenza sono anche POP server (alcuni dicono che siano perfino molto meglio del "classico" qpopper). Saluti, Luca Polo -- / Luca Polo : jake@gest.unipd.it || System administrator \ | (http://www.gest.unipd.it/~jake for || Ist. di Ingegneria Gestionale | \ address and phone numbers) || Universita` di Padova, Italy / ---------------------------------------------------------------------------- </verb></tscreen> <sect>Leggere la posta (ovvero i MUA) <sect1>Pine Uno dei problemi più frequenti con <tt/pine/ nell'uso off-line è il fatto che esso mostra nel campo <tt/From:/ dei messaggi che spediamo il nostro nome e cognome (andandoli a prendere da <tt>/etc/passwd</tt> credo) seguito da un indirizzo email costituito dal nostro login sulla macchina locale più il nome dell'host locale. Per esempio se il mio login sulla mia macchina Linux a casa è <tt/mirko/ ed il nome della macchina è <tt/blackhole/, <tt/pine/ mostrerà nel campo <tt/From:/ una cosa del genere: <tscreen> From: Mirko Caserta <mirko@blackhole> </tscreen> Ovviamente un tale indirizzo su Internet non ha un granchè come significato perchè <tt/blackhole/ non è un nome di dominio registrato. A questo punto ci sono due soluzioni: una legata a <tt/sendmail/ e al relativo uso di un database di utenti locali (a tal proposito vedi la sezione <it/Un database di utenti locali: perchè e come/), ed un'altra di uso piu' generale e slegata da <tt/sendmail/. L'ultima soluzione, anche se non molto igienica in termini di sicurezza (ma che tuttavia potrebbe risultare indispensabile in alcuni casi), consiste nel ricompilare <tt/pine/ con l'opzione per poter modificare l'header <tt/From:/ Niente di impossibile anche per l'utente appena giunto nel mondo di Linux. Cominciamo andando a prendere l'ultima versione di Pine da uno di questi URL: <itemize> <item><tt><htmlurl url="ftp://ftp.cac.washington.edu/pine" name="ftp://ftp.cac.washington.edu/pine"></tt> <item><tt><htmlurl url="http://www.cac.washington.edu/pine" name="http://www.cac.washington.edu/pine"></tt> </itemize> Al momento in cui scrivo, la versione corrente è la 3.95 ed il nome del relativo file è <tt/pine395.tgz/ Portiamoci nella directory <tt>/usr/src</tt> e scompattiamo il file appena prelevato con: <tscreen> tar vxzf pine395.tgz </tscreen> Quindi andiamo nella directory <tt>/usr/src/pine3.95/pine/osdep</tt> e modifichiamo il file <tt/os-lnx.h/ Alla riga 71 dovremmo trovare: <tscreen><verb> /* #define ALLOW_CHANGING_FROM /* comment out to not allow changing From */ </verb></tscreen> Modifichiamola in modo che diventi: <tscreen><verb> #define ALLOW_CHANGING_FROM /* comment out to not allow changing From */ </verb></tscreen> <tt/#define/ deve trovarsi incollato al margine sinistro dello schermo, altrimenti non funzionerà. Ora facciamo un <tt>cd ../..</tt> in modo da tornare in <tt>/usr/src/pine3.95</tt> e diamo il comando <tscreen> build lnx </tscreen> Dopo un bel po' di messaggi strani circa la compilazione, il prompt dovrebbe fare capolino ed informarci che tutto è andato a buon fine (beh, almeno sulla mia macchina Linux 2.0.12 con librerie aggiornate, ecc, è andato tutto ok senza fare nemmeno una piega). Sotto <tt>/usr/src/pine3.95/bin</tt> dovremmo trovare la nostra versione di <tt/pine/. Copiamola al posto della vecchia versione (di solito <tt>/usr/bin/pine</tt>) senza dimenticare di aver prima fatto una copia di backup (non si sa mai... hai presente una certa legge di Murphy?). Volendo possiamo anche installarci la versione appena compilata di <tt/pico/ (l'editor di testi interno di <tt/pine/) sempre sotto <tt>/usr/bin/pico</tt> Ora facciamo partire <tt/pine/ e, dal menù principale, scegliamo <bf/S/ (Setup), quindi <bf/C/ (Config). Scorriamo l'elenco delle opzioni in giù fino a trovare <tt/Customized-hdrs/. Il valore corrente dovrebbe essere il default, quindi <tt>No Value Set</tt>. Usiamo <bf/A/ (Add Value) per aggiungere un valore, quindi specifichiamo: <tscreen><verb> From: Nome Cognome <nome.utente@mio.provider.it> </verb></tscreen> ovviamente sostituendo il nostro nome, cognome ed indirizzo di posta elettronica a quelli dell'esempio. Fine!! Ce l'abbiamo fatta! Per fare le cose in modo più puntiglioso potremmo anche aggiungere sempre con il comando <bf/A/ (Add Value) al campo <tt/Customized-hdrs/ i valori: <tscreen><verb> Reply-to: Nome Cognome <nome.utente@mio.provider.it> Return-Path: Nome Cognome <nome.utente@mio.provider.it> </verb></tscreen> anche se personalmente sconsiglio vivamente di specificare i campi <tt/Reply-to:/ e <tt/Return-Path:/ a meno che non ci sia una <bf/reale necessità/. <sect1>XFMail XFMail è probabilmente il MUA più interessante in questo momento per chi lavora sotto X in quanto ha un'interfaccia utente molto user-friendly, supporta i protocolli POP3 ed IMAP e ha un sistema di filtraggio della posta tipo procmail incorporato. Fino a qualche tempo fa la grave lacuna di questo MUA era la mancanza di un editor decente, mancanza che è stata colmata nella versione 1.0. L'URL di XFMail è <tt><htmlurl url="http://burka.netvision.net.il/xfmail/xfmail.html" name="http://burka.netvision.net.il/xfmail/xfmail.html"></tt> Dall'URL sopraindicato puoi prelevare sia i sorgenti di XFMail (avrai bisogno dell'ultima versione della libreria XForms per compilare), sia alcune versioni precompilate per Linux (sia per librerie statiche che dinamiche). L'ultima versione al momento in cui scrivo è la 1.0 ma gli autori ci tengono a far presente che il numero della versione non significa che si tratta di qualcosa di stabile. Da notare l'opzione <it/Send offline/ presente nella configurazione (menù <it/Misc/ -> <it/Config/ -> <it/Send/) che permette di mantenere i messaggi da spedire nella cartella <it/outbox/. Quando saremo collegati in rete basterà scegliere <it/Send all/ dal menù <it/Send/. In questo modo possiamo anche evitarci di configurare <tt/sendmail/ dal momento che XFMail ci permette di inviare la posta direttamente al server SMTP del provider. <sect1>TkRat Recentemente mi sono imbattuto in un altro MUA per X molto interessante: <tt/TkRat/. Attualmente è alla versione 1.0 ma dispone già di numerose funzioni molto interessanti. Non mancano le opzioni per poter lavorare comodamente off-line senza la necessità di dover configurare appositamente <tt/sendmail/ (dal menù <it/Amministrazione/ scegli <it/Preferenze/, quindi seleziona la sezione <it/Spedizione/ e alla voce <it/Modo consegna/ imposta <it/Differita/). Non dimenticare di impostare nella configurazione di TkRat il tuo indirizzo email reale per fare in modo che le risposte vengano spedite al giusto indirizzo (dal menù <it/Amministrazione/ scegli <it/Preferenze/, quindi seleziona la sezione <it/Componi messaggio/ e alla voce <it/Rispondi-A Standard/ imposta il tuo indirizzo email reale). Altro punto a vantaggio di <tt/TkRat/ è l'interfaccia utente completamente in Italiano (c'è anche l'help in linea in italiano!). Compilare i sorgenti ed installare l'intero pacchetto è un gioco da ragazzi grazie ad <tt/autoconf/. L'URL consigliato dall'autore del software per prelevare l'ultima versione di <tt/TkRat/ è <htmlurl url="http://www.dtek.chalmers.se/~maf/ratatosk/" name="http://www.dtek.chalmers.se/~maf/ratatosk/"> Presso questo stesso URL troverai l'elenco delle caratteristiche più interessanti di <tt/TkRat/. <sect>Spedire la posta, ovvero sendmail Beh, a dire il vero ci sono diversi MTA, tra cui <tt/smail/, <tt/qmail/, ed altri ma, non avendo mai avuto modo di provarli, mi soffermerò solo su <tt/sendmail/. <tt/sendmail/ è forse uno dei software più complicati da configurare nella nostra galassia; in compenso ci permette di avere un sistema di gestione della posta all'altezza di qualsiasi situazione, tanto che è spesso sprecato in molti casi per i quali basterebbe un ben più semplice MTA. In ogni caso, per una configurazione base di <tt/sendmail/ ci viene in aiuto <tt/m4/ che, con le sue macro, ci permette di creare in maniera estremamente semplice un file di configurazione adatto al nostro caso specifico. <bf/Nota bene:/ <tt/sendmail/ è un software che avrà sempre dei buchi (bug o bacarozzi che dir si voglia) riguardanti la sicurezza, per cui consiglio vivamente di prelevare l'ultima versione disponibile (anche perchè tutte le prove sono state fatte sulla versione 8.8.3 e non posso assicurare che quanto è qui descritto funzioni anche con le versioni precedenti) da uno di questi URL: <itemize> <item><tt><htmlurl url="http://www.sendmail.org/" name="www.sendmail.org"></tt> <item><tt><htmlurl url="ftp://ftp.sendmail.org/" name="ftp.sendmail.org"></tt> sotto la directory <tt>/pub/sendmail/</tt> </itemize> <sect1>Creazione del file sendmail.cf con m4 Per far capire a <tt/sendmail/ che operiamo off-line, dobbiamo andare a modificare il file di configurazione che di solito si chiama <tt>/etc/sendmail.cf</tt> Dal momento che non avrebbe molto senso andare a modificare a mano tale file, vediamo come possiamo piuttosto generarne uno nuovo usando <tt/m4/ (ovviamente devi avere <tt/m4/ installato e funzionante). Come prima cosa andiamo a prendere via <tt/ftp/ l'ultima versione di <tt/sendmail/ da <tt><htmlurl url="ftp://ftp.sendmail.org/pub/sendmail/" name="ftp://ftp.sendmail.org/pub/sendmail/"></tt> quindi andiamo a scompattare il file appena prelevato sotto <tt>/usr/src</tt> con il comando <tscreen><verb> tar vxzf /percorso/per/sendmail.x.x.x.tar.gz </verb></tscreen> A questo punto, per semplificarci la vita, creiamo un link simbolico in modo da far risultare la directory di <tt/sendmail/ come <tt>/usr/src/sendmail</tt> in questo modo: <tscreen><verb> ln -s /usr/src/sendmail-x.x.x /usr/src/sendmail </verb></tscreen> Ovviamente le <tt/x/ usate nel path di <tt/sendmail/ stanno ad indicare il numero della versione e dovranno essere sostituite!!! Ora andiamo nella directory <tt>/usr/src/sendmail/cf/cf</tt> e creiamoci il file con le indicazioni per <tt/m4/ chiamandolo <tt>linux-offline.mc</tt> ed avente come contenuto quanto segue: <tscreen><verb> include(`../m4/cf.m4') VERSIONID(`linux per uso off-line')dnl OSTYPE(linux) FEATURE(nouucp)dnl FEATURE(always_add_domain)dnl MAILER(local)dnl MAILER(smtp)dnl define(confDELIVERY_MODE, defer) define(`SMART_HOST', mio_smtp_host) define(confUSERDB_SPEC, /etc/userdb.db) FEATURE(notsticky) </verb></tscreen> Le due linee che contengono <tt>define(confUSERDB_SPEC, /etc/userdb.db)</tt> e <tt>FEATURE(notsticky)</tt> devono essere inserite solo se vogliamo usare il database di utenti locali (vedi la sezione <it>Un database di utenti locali: perchè e come</it>). Inoltre <tt/mio_smtp_host/ deve essere sostituito con il nome del server SMTP del provider. Ti faccio anche notare che quell'apostrofo al contrario che si trova ad esempio prima di <tt>linux per uso off-line')dnl</tt> è molto importante: è diverso dal semplice apostrofo e corrisponde in ASCII al codice 96 (decimale). Ora facciamo una copia di riserva del file <tt>/etc/sendmail.cf</tt> e generiamone uno nuovo con il comando: <tscreen><verb> m4 linux-offline.mc > /etc/sendmail.cf </verb></tscreen> <sect1>Creazione del file sendmail.cf e /etc/aliases con make Per i più esperti, ecco in regalo un <tt/Makefile/ da mettere in <tt>/etc/mail</tt> per compilare automaticamente <tt/sendmail.cf/ e gli alias. Prima però bisogna togliere da sendmail.mc la riga con l'include(), quindi si deve creare un link simbolico con il comando: <tscreen><verb>ln -s /etc/sendmail.cf /etc/mail/sendmail.cf</verb></tscreen> Segue il contenuto del file <tt>/etc/mail/Makefile</tt>: <tscreen><verb> ------------------------ taglia qui ------------------------ M4LIB=/usr/lib/sendmail.cf HOSTNAME=wonderland all: cfg sendmail.cf: $(HOSTNAME).mc m4 $(M4LIB)/m4/cf.m4 $(HOSTNAME).mc > sendmail.cf # Queste righe sono un esempio di come applicare automaticamente delle patch # patch --silent < $(M4LIB)/smartdom.diff patch --silent < # $(M4LIB)/selective-masq.diff rm -rf sendmail.cf.orig /etc/aliases: /etc/aliases.db /etc/aliases.db: /etc/aliases sendmail -bi cfg: sendmail.cf /etc/aliases test: cfg sendmail -bt -C./sendmail.cf #-oQ/tmp/mqueue clean: rm sendmail.cf /etc/aliases.db ------------------------ taglia qui ------------------------ </verb></tscreen> <sect1>Ultimi ritocchi a sendmail Una volta generato il file <tt/sendmail.cf/ facciamo ripartire <tt/sendmail/ ed il gioco è fatto... o quasi :) In genere la distribuzione di Linux che abbiamo installato fa in modo che al boot della macchina, da uno degli script nella directory <tt>/etc/rc.d</tt>, parta <tt/sendmail/. Ora, dal momento che quelli che creano le distribuzioni di Linux danno per assunto che ognuno di noi sia collegato in rete con una T1 da casa, fanno partire <tt/sendmail/ per default con l'opzione <tt/-q/, la quale dice a <tt/sendmail/ di processare immediatamente la coda dei messaggi in uscita oltre che ad certo intervallo di tempo. Per evitare che ciò succeda, individuiamo in quale file viene fatto partire <tt/sendmail/ ed eliminiamo l'opzione -q (che generalmente è seguita anche dall'intervallo di tempo per processare la coda, per esempio 15m sta per 15 minuti). Per individuare il file, portiamoci nella directory <tt>/etc/rc.d</tt> e facciamo una <tscreen><verb> grep sendmail * </verb></tscreen> Nella Red Hat, la directory in questione è <tt>/etc/rc.d/init.d</tt> ed il file si chiama <tt/sendmail.init/ A questo punto ogni messaggio che inviamo a <tt/sendmail/, sia direttamente, sia via SMTP sulla porta locale, viene messo in una coda nella directory <tt>/var/spool/mqueue</tt> e la coda verrà processata (i messaggi verranno inviati) solo con il comando <tscreen><verb> sendmail -q -v </verb></tscreen> Per vedere il contenuto della coda digita <tt/mailq/ L'opzione <tt/-v/ serve a dire a <tt/sendmail/ di visualizzare cosa combina durante l'invio dei messaggi, mentre <tt/-q/ serve proprio ad indicargli di processare la coda. Se vogliamo avere un log di cosa combina <tt/sendmail/ possiamo farlo partire in questo modo: <tscreen><verb> sendmail -q -v >> /var/log/sendmail </verb></tscreen> Un'ultima cosa: per compilare <tt/sendmail/ ed installarlo al posto della versione attuale: <tscreen><verb> cd /usr/src/sendmail/src makesendmail makesendmail install </verb></tscreen> <sect1>Un database di utenti locali: perchè e come Come abbiamo già visto con <tt/pine/, uno dei problemi più ricorrenti nell'uso della posta off-line consiste nel fatto che il campo <tt/From:/ automaticamente generato dal nostro MUA non corrisponde al nostro indirizzo Internet reale. Per ovviare a questo problema basterebbe inserire un header del tipo <tt/Reply-to:/ con il nostro indirizzo effettivo, ma chi riceverà la nostra posta continuerà a vedere nel campo <tt/From:/ un indirizzo sbagliato che, se un nostro amico memorizza in un elenco credendolo corretto, sarebbe semplicemente inutile e ci farebbe anche perdere un sacco di tempo e messaggi. La soluzione consiste nel creare un database di utenti locali in cui ad una chiave consistente in un certo login corrisponde un indirizzo email reale. Per fare ciò dobbiamo avere precedentemente specificato nel file per <tt/m4/ (vedi la sezione <it>Creazione del file <tt>/etc/sendmail.cf</tt> con <tt>m4</tt></it>) le righe: <tscreen><verb> define(confUSERDB_SPEC, /etc/userdb.db) FEATURE(notsticky) </verb></tscreen> Inoltre dobbiamo avere installato il pacchetto <it/db/ di Berkeley dal momento che questo sistema non funziona con DBM. Puoi prelevare i sorgenti da <htmlurl url="ftp://ftp.cs.berkeley.edu/pub/4bsd/db.tar.gz" name="ftp://ftp.cs.berkeley.edu/pub/4bsd/db.tar.gz"> ma non ne avrai bisogno se stai utilizzando una distribuzione abbastanza recente come ad esempio la Red Hat 4.0. Ora andiamo ad editare il file <tt>/etc/userdb</tt> in questo modo: <tscreen><verb> login:mailname nome.utente@mio.provider.it nome.utente@mio.provider.it:maildrop login </verb></tscreen> Si tratta di sostituire <it/login/ con il nostro login sulla macchina locale e <it/nome.utente@mio.provider.it/ con il nostro indirizzo Internet reale. Quindi un esempio concreto potrebbe essere: <tscreen><verb> mirko:mailname ik0zsn@amsat.org ik0zsn@amsat.org:maildrop mirko </verb></tscreen> Usa TAB per separare i campi. Ora generiamo il database con: <tscreen><verb> makemap btree /etc/userdb.db < /etc/userdb </verb></tscreen> Facciamo ripartire <tt/sendmail/ ed il gioco è fatto. Ora, ad esempio con Berkeley's Mail, i messaggi in uscita avranno l'indirizzo corretto nell'header <tt/From:/ e <tt/Return-Path:/ Come avrai già notato, con <tt/pine/ invece non è cambiato un bel niente e si ostina a indicare un indirizzo scorretto. La soluzione viene dalla documentazione di <tt/sendmail/ (dalle FAQ per essere più esatti) e la riporto esattamente così com'è, limitandomi a tradurla. <tscreen><verb> ====================================================================== Data: 19 Luglio 1996 Soggetto: Q3.6 -- Come posso far funzionare il database di utenti locali con Pine o con FEATURE(always_add_domain)? L'incompatibilita` di base tra Pine e il database di utenti risiede in come Pine scrive il tuo indirizzo nella intestazione dei messaggi. Molti MUA scrivono il tuo indirizzo come "From: user", mentre Pine, per ragioni date nella sua documentazione, scrive l'indirizzo come "From: user@FQDN" (FQDN=fully qualified domain name, ovvero il nome di dominio completo di una macchina su Internet). Usando la macro di m4 "always_add_domain" si ha lo stesso effetto. Data questa differenza, il database di utenti locali non riscrive queste intestazioni. Una soluzione a questo problema consiste nell'apportare la seguente modifica nel file sendmail.mc compilato da m4 nel tuo /etc/sendmail.cf (oppure ovunque il tuo file sendmail.cf risiede) dopo che hai installato il database di utenti locali e l'hai fatto funzionare con altri MUA: All'inizio della sezione dove imposti le variabili di configurazione, aggiungi quanto segue: # Define our userdb file for FQDN rewrites Kuserdb btree -o /etc/userdb.db Ed un po' piu` in seguito, prima delle righe "MAILER()", ma dopo che altre opzioni di configurazione siano state specificate: LOCAL_RULE_1 ######################################################## ### Local Ruleset 1, rewrite sender header & envelope ## ######################################################## #Thanks to Bjart Kvarme <bjart.kvarme@usit.uio.no> S1 R$- $1 < @ $j . > user => user@localhost R$- < @ $=w . > $* $: $1 < @ $2 . > $3 ?? $1 user@localhost ? R$+ ?? $+ $: $1 ?? $(userdb $2 : mailname $: @ $) R$+ ?? @ $@ $1 Not found R$+ ?? $+ $>3 $2 Found, rewrite # NOTA BENE ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ # Usa il tasto Tab in queste regioni in modo da avere tre # colonne (la linea con "mailname" ha solo 2 colonne). Ora il database di utenti dovrebbe riscrivere i messaggi spediti con Pine o qualsiasi altro MUA che vuole avere un indirizzo completamente qualificato (FQDN). Se con il metodo appena descritto non hai ancora risolto il problema, prova ad aggiungere quanto segue sia al file di configurazione di sistema pine.conf, pine.conf.fixed, o al tuo file di configurazione personale .pinerc: user-domain=localhost Sappiamo che questo ha risolto il problema a molte persone. Ad ogni modo, una soluzione piu` elegante (leggi: basata su m4) per la versione 8 di sendmail deve essere ancora creata. ====================================================================== </verb></tscreen> <sect1>Makemap non supporta il tipo btree. E adesso? Potrebbe succedere che <tt/makemap/ ti dice di non supportare il tipo <it/btree/ rifiutandosi di generare il database. Cosa fare in questo caso? Soluzione: ricompilare <tt/makemap/ con il supporto per i database di tipo <it/btree/. I sorgenti di <tt/makemap/ sono nella distribuzione di <tt/sendmail/, quindi se abbiamo seguito le istruzioni precedenti dovremmo ritrovarci il tutto sotto <tt>/usr/src/sendmail/makemap</tt> Per poter compilare <tt/makemap/ con il supporto per il tipo <it/btree/ dobbiamo avere installato il pacchetto <tt/db/ di Berkeley (vedi la sezione <it>Un database di utenti locali: perchè e come</it>). L'unica difficoltà nel compilare <tt/makemap/ consiste nel far funzionare il makefile. Dal momento che su ogni sistema le cose potrebbero cambiare (librerie diverse, ecc) ti riporto il makefile che ho usato con successo (per dovere di cronaca al momento delle prove avevo la Red Hat 4.0). Chiamalo semplicemente <tt/Makefile/ dopo avere rinominato quello già presente nella directory e lancia <tt/make/ quindi, se la compilazione è andata a buon fine, fai qualche prova con il tuo nuovo <tt/makemap/ ed infine installalo con <tt/make install/ <tscreen><verb> ------------------------ taglia qui ------------------------ O= -O SRCDIR= ../src DBMDEF= -DNDBM -DNEWDB ENVDEF= INCDIRS=-I${SRCDIR} -I/usr/include LDOPTS= LIBDIRS=-L/usr/lib LIBS= -ldb -lgdbm BINDIR= /usr/sbin OBJADD= ############ Non modificare al di sotto di questa linea ############## CFLAGS= -I. $O ${INCDIRS} ${DBMDEF} ${ENVDEF} OBJS= makemap.o ${OBJADD} LINKS= ${DESTDIR}/usr/ucb/newaliases ${DESTDIR}/usr/ucb/mailq BINOWN= bin BINGRP= bin BINMODE=555 ALL= makemap makemap.0 all: ${ALL} makemap: ${BEFORE} ${OBJS} ${CC} -o makemap ${LDOPTS} ${OBJS} ${LIBDIRS} ${LIBS} NROFF= groff -Tascii MANDOC= -mandoc makemap.0: makemap.8 ${NROFF} ${MANDOC} makemap.8 > makemap.0 install: install-makemap install-docs install-makemap: makemap install -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} makemap ${BINDIR} install-docs: makemap.0 clean: rm -f ${OBJS} makemap makemap.0 ${OBJS}: ${SRCDIR}/conf.h ------------------------ taglia qui ------------------------ </verb></tscreen> </article>