<esr@thyrsus.com>Lo scopo di questo documento è di spiegare come funziona l'email e di rispondere ad alcune delle domande che sembrano corrispondere alla definizione di «domande poste più di frequente» a proposito del software di email sotto Linux.
Le moderne distribuzioni di Linux forniscono, non appena installate, una impostazione preconfigurata ed usabile della posta elettronica, solitamente tramite l'ultima versione di sendmail-v8. Questo HOWTO assumerà che si possieda tale impostazione ed una connessione ad Internet funzionante.
(Per informazioni su come impostare una connessione PPP o SLIP ad un ISP, si veda l' ISP Hookup HOWTO.)
Di conseguenza, diversamente dalle versioni 1.x di Vince Skahan, questo HOWTO si focalizza sulle questioni utente e sull'architettura; molte parti relative a UUCP, sendmail IDA e altre importanti questioni precedenti sono state tagliate.
Questo documento sarà inviato mensilmente nel newsgroup comp.os.linux.answers. Si dovrebbe essere in grado di visionarne l'ultima versione sul World Wide Web a http://metalab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html.
Per la posta sotto Linux non ci sono requisiti hardware specifici. Se si possiede l'hardware necessario per connettersi ad Internet, questo può supportare l'email attraverso quella connessione.
Il software che sarà necessario per il supporto email è probabilmente preinstallato nella propria distribuzione di Linux. Si troveranno degli aggiornamenti sul Metalab Linux Archive, specialmente nella sottodirectory mail.
Questa sezione contiene informazioni relative agli «agenti utente» (mail user agent o MUA), termine che indica il software che l'utente vede e usa. Questo software fa affidamento sugli «agenti di trasporto» (mail transport agent o MTA) descritti nel Mail Administrator's HOWTO (il quale contiene pure la configurazione degli agenti utente e trucchi per la risoluzione dei problemi per gli amministratori).
Per fornire assistenza alla composizione della posta i mail user agent chiamano un qualche editor. Quale sia l'editor predefinito dipende da alcune cose. Molti rispettano una convenzione retaggio della preistoria di Unix; se esiste, il contenuto della variabile d'ambiente VISUAL è preso come il nome dell'editor preferito. Se VISUAL non è impostata, è controllata la variabile EDITOR.
Valori comuni per EDITOR comprendono «vi» e «emacs». Ma se si è come me, un tipo che ha sempre un Emacs in esecuzione, la cosa più utile a cui impostare EDITOR è il valore «emacsclient». Lo si usi con le seguenti righe nel proprio file .emacs:
(autoload 'server-edit "server" nil t) (server-edit)
Il programma emacsclient, quando viene eseguito, prova a stabilire una comunicazione con un'istanza di Emacs che già è in esecuzione e invia il file temporaneo contenente il messaggio di posta ad Emacs per poterlo modificare. L'effetto di questa cosa è che quando il proprio mailer chiama l'editor, viene aperta una finestra di composizione della posta dentro al proprio Emacs.
Quando si è pronti per restituire il file al mailer per la spedizione, si digiti C-x #. Il buffer di posta scompare dalla schermata e l'istanza di emacsclient chiamata dal proprio mailer termina, restituendo il controllo al mailer.
È possibile avere più istanze di emacsclient aperte contemporaneamente senza per questo confondere Emacs. Comunque, chiamare un altro Emacs mentre è in esecuzione una sessione emacsclient può confondere emacsclient tanto che dopo non sarà più in grado di trovare alcuna istanza. Se questo succede, si chiudano tutte le istanze di Emacs e se ne riavvii solo una.
Questo è quello che io uso e raccomando. È un discendente di elm ed ha per default comandi simili. Può essere un client POP3 e IMAP e include un supporto eccellente per MIME e PGP. C'è una home page di Mutt a http://www.mutt.org.
Mutt rispetta la convenzione EDITOR/VISUAL.
Elm è stato il primo mailer moderno orientato allo schermo, ma è rimasto stagnante per anni ed ora è stato destituito da Mutt. Alcune versioni di elm contengono il supporto per POP3. Per maggiori informazioni, si vedano i sorgenti e le istruzioni di installazione di elm nella directory degli agenti utente di posta a Metalab. Ecco alcuni punti che talvolta ossessionano la gente:
No, l'elm grezzo non supporta il PGP. Ci sono alcune patch per il supporto del PGP, ma il supporto PGP di Mutt è superiore. Se si vuole usare il PGP, io raccomando Mutt.
Elm rispetta la convenzione EDITOR/VISUAL.
Pine è un agente utente progettato per i novizi; include la possibilità di leggere le news e supporto per il protocollo di posta remota IMAP. Un sacco di gente lo consiglia per i nuovi utenti. Io trovo che abbia un insieme di comandi piuttosto povero, configurabilità limitata e un editor nativo difficile da capire. Comunque possiede al suo interno un eccellente supporto per IMAP. Se lo si vuole provare, la distribuzione è disponibile a http://www.washington.edu/pine.
Pine rispetta la convenzione EDITOR/VISUAL.
Il browser Netscape ha al suo interno le funzionalità per gestire POP3 e IMAP e quindi può essere usato come agente utente per la posta. Io non lo raccomando; non è specializzato per essere un MUA e quindi non offre molti servizi che i MUA reali hanno (come la gestione degli alias e del PGP).
Netscape fornisce un proprio mini editor, lo stesso che si usa nel browser (e.g. per i campi testo nei form).
Emacs ha un modo chiamato «smail» che può spedire la posta e un altro chiamato «rmail» per leggerla. Il modo smail può essere abbastanza utile, poiché si può comporre la posta dentro un completo ambiente Emacs (ma si veda anche la discussione su emacsclient in questo documento).
Il modo rmail, d'altra parte, non è raccomandato. Ogni volta che lo
si esegue, converte l'inbox nel formato BABYL; e questa cosa agli
strumenti per la posta ordinari non piacerà affatto (se succede, si
lanci M-x unrmail dalla riga di comando di Emacs).
Esiste un lettore di posta (mailreader) per emacs chiamato «vm» che scrive e legge le mailbox (caselle di posta) in formato V7 standard. Non è distribuito con GNU Emacs, ma si può trovare la sua homepage a http://www.wonderworks.com/vm/.
smail/rmail/vm di Emacs non rispettano la convenzione EDITOR/VISUAL. Invece, si usa l'Emacs nel quale sono inglobati.
Se semplicemente si digita «mail» nella shell di Linux o di un qualsiasi altro Unix moderno, si invocherà una qualche variante del programma «BSD mail». Ha un'interfaccia orientata alla riga originariamente progettata per l'uso sulle TTY. A questo punto, è solo di interesse storico.
BSD Mail ha inventato la convenzione EDITOR/VISUAL.
È noto che anche i seguenti funzionano sotto Linux. Si consulti «archie» per trovarli...
Non ne so abbastanza su mh e mush per descriverli in dettaglio. Entrambi hanno un'interfaccia abbastanza complessa e sono pensati per utenti sofisticati.
Un «alias» è un modo per impostare un indirizzo fittizio che semplicemente diriga la posta ad un altro indirizzo (unico). Ci sono due tipi di alias: alias MUA e alias MTA.
Un alias MUA è qualcosa che si imposta nel proprio MUA, una specie di scorciatoia personale. Gli altri non saranno in grado di vedere ed usare tale alias. Per esempio, si potrebbe scrivere
alias esr Eric S. Raymond <esr@thyrsus.com>
nel proprio file di configurazione di mutt. Questo dirà a mutt che quando vede «esr» nella riga di indirizzo, si dovrà comportare come se si fosse digitato «esr@thyrsus.com». Oppure si può scrivere «mutt esr» e l'indirizzo espanso verrà automaticamente inserito nella riga «to».
Un alias MTA è qualcosa che viene espanso dal proprio MTA; sarà usabile da tutti, sia nella propria macchina che in altre. Per creare alias MTA si modifica un file di sistema, solitamente, ma non sempre, /etc/aliases (la posizione dipende dal proprio MTA). Potrebbe essere istruttivo dare un'occhiata al file /etc/aliases nel proprio sistema; dovrebbe contenere numerosi alias standard come «postmaster».
Il proprio MTA potrebbe permettere che la destinazione di un alias sia un nome di file, che sarà trattato come una mailbox alla quale aggiungere le mail (questo è utile per archiviare le mail). Può pure permettere che la destinazione sia un programma, nel qual caso le mail a quell'alias saranno passate ad un istanza del programma nel suo standard input.
Gli alias MTA solitamente richiedono i privilegi dell'amministratore per poter essere impostati. Ma è desiderabile per gli utenti essere in grado di impostare il forwading («reinoltro») delle proprie mail senza l'intervento dell'amministratore.
Per supportare questa cosa, la maggior parte degli MTA seguono
l'esempio di sendmail e cercano un file chiamato
.forward nella home directory dell'utente. Il
contenuto di questo file è interpretato come la destinazione di un
alias al quale si vogliono ricevere tutte le proprie mail. L'uso più
comune di questa possibilità è quello di redirigere tutta la posta in
un account su un'altra macchina.
Un altro uso comune del file .forward è quella di passare la
posta ad un programma «vacation». Un programma vacation (vacanza)
legge tutta la posta entrante e genera automaticamente una risposta
preconfezionata; sono così chiamati perché la forma più comune di
risposta preconfezionato è per informare il mittente che si è in
vacanza e non si sarà raggiungibili prima di una certa data.
Non c'è un programma vacation standard che sia universalmente usato. E questo per due buone ragioni: la prima è che tale programma è facile da scrivere come uno script shell di una regola di filtraggio (si veda sotto); e la seconda è che i programmi vacation non interagiscono bene con le mailing list.
Ci si dovrebbe temporaneamente deiscrivere da tutte le mailing list prima di impostare la risposta automatica; altrimenti tutti i membri delle mailing list saranno sommersi dai messaggi del programma vacation. Questo è considerato un comportamento molto maleducato e garantirà un atteggiamento abbastanza gelido al ritorno.
Una mailing list è un indirizzo fittizio che invia la posta a più di un utente.
Nella sua forma più semplice, una mailing list è semplicemente un alias MTA con più di un recipiente. Alcune piccole mailing list sono mantenute in questo modo. Sendmail viene in aiuto supportando una sintassi in /etc/aliases che include in contenuto di un dato file di mailing list come lato destinatario di un alias. Qualcosa di simile a questo:
admin-list: ":include:/usr/home/admin/admin-list"
con il vantaggio che il file admin-list può risiedere da qualche parte nello spazio di utente senza privilegi (root è necessario solamente per impostare l'inclusione originale). Alcuni altri MTA hanno possibilità simili.
Queste semplici liste sono comunemente dette «mail reflector» (riflettori di posta). Ci sono un paio di problemi con questi «riflettori». Il primo è che i messaggi di rimbalzo generati da tentativi di broadcast falliti arrivano a tutti gli utenti. Un altro è che tutte le iscrizioni e deiscrizioni devo essere fatte manualmente dall'amministratore della mailing list.
Un tipo di software chiamato «gestore di mailing list» si è evoluto per risolvere questi ed altri problemi a loro legati. La sua funzione più importante è di permettere agli utenti della mailing list di iscriversi e deiscriversi senza passare per l'amministratore della lista.
Un gestore di mailing list mantiene le proprie informazioni sulla lista di utenti e si aggancia all'MTA attraverso un alias di programma in /etc/aliases. Per esempio, se la admin-list di prima passa attraverso il gestore di mailing list SmartList su un programma sendmail, una porzione del file /etc/aliases potrebbe essere simile a questa:
admin-list: "|/usr/home/smartlist/bin/flist admin-list" admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request"
Si noti che questa è una coppia di alias. È convenzione per le reali mailing list di avere un indirizzo di richiesta da usare per le richieste di iscrizione e deiscrizione degli utenti. È considerato scortese e ignorante inviare richieste di iscrizioni/deiscrizioni all'indirizzo principale di tale lista -- quindi non farlo.
Il robot dietro all'indirizzo di richiesta può offrire altre possibilità oltre all'iscrizione/deiscrizione. Potrebbe rispondere a richieste di aiuto, permettere di sapere chi è iscritto alla list o dare un accesso automatico agli archivi della lista. Può pure permettere agli amministratori della lista di restringere l'invio di messaggi solo a membri noti, impostare la lista ad iscrivere automaticamente i non membri quando inviano per la prima volta un messaggio e impostare diverse opzioni sulle politiche di sicurezza. I gestori delle mailing list si differenziano principalmente nel progetto e nella gamma di queste funzionalità secondarie.
Sfortunatamente, il formato per inviare comandi ai robot delle mailing list non sono standard. Alcuni si aspettano comandi nella riga oggetto, altri ignorano l'oggetto e si aspettano i comandi nel corpo del messaggio. Si deve prestare attenzione alla mail di risposta che si ottiene quando ci si iscrive per la prima volta; è una buona idea salvare tali mail in una mailbox per riferimenti futuri.
I più importati gestori di mailing list da conoscere sono majordomo, listserv, listproc e smartlist; majordomo è il più popolare con un margine considerevole. Nel web esiste una lista abbastanza completa di tali pacchetti.
Per maggiori informazioni sui gestori delle mailing list, si consultino le risorse a List-Managers Mailing List, tra cui la FAQ (nota: questa lista non è appropriata per domande su come fare le cose).
Un filtro per la posta è un programma che risiede tra l'utente e il suo agente di distribuzione locale (local delivery agent) e che automaticamente smista o rifiuta la posta prima che l'utente possa vederla.
I filtri per la posta hanno diversi usi. Il più importante è il filtraggio degli spam, smistamento su diverse mailbox a seconda dell'argomento o del mittente e risposta automatica.
Tipicamente, si imposta un filtraggio della posta mettendo un alias di programma per il programma di filtro nel proprio file .forward e scrivendo un file con le regole di filtraggio. Il formato e la posizione delle regole di filtraggio variano a seconda del programma di filtraggio.
Le caratteristiche dei tre maggiori filtri per la posta (procmail, mailagent e deliver) sono ben riassunte nella parte 3 dell'Email Software Survey di Chris Lewis. Il più popolare fra questi (a dispetto della sintassi piuttosto brutta delle sue regole) è procmail, universalmente presente nei sistemi Linux (e, infatti, è generalmente usato come agente di distribuzione locale di sistema).
Gli spam sono talvolta noti come «UCE» (Unsolicited Commercial Email) o `UBE' (Unsolicited Bulk Email). Come indicano questi nomi, è una forma disgustosa di pubblicità che riempie la propria mailbox con lettere di nessun interesse (il termine «spam» proviene da una gag del Flying Circus dei Monty Python nella quale un coro di Vichinghi ripeteva all'infinito il cantico «Spam spam spam spam...»).
La maggior parte degli spam sembrano essere solleciti per schemi piramidali, pubblicità pornografiche o (noiosi) tentativi di vendere programmi per inviare spam. Alcuni spam (come il «MAKE MONEY FAST» o la cartolina hoax di Craig Shergold) sono stati così persistenti da divenire leggendari. Gli spam tendono ad essere sia verbosi che ignoranti. Sono una perdita di tempo e un enorme spreco della larghezza di banda della rete.
L'epidemia spam sembra aver raggiunto il picco a metà del 1997 e poi ha cominciato lentamente a declinare, ma sono ancora una noia seria. Se si è inondati di spam, si rimanga educati. Si dia un'occhiata alla pagina Fight Spam on the Internet!. La pagina Death To Spam! è particolarmente efficace per i metodi per fermare o tracciare gli spam.
Esistono numerosi gruppi Usenet devoti alla questioni tecniche delle posta elettronica:
La seguente è un insieme non inclusivo di libri che possono aiutare...
Come già menzionato, il messaggio periodico di Chris Lewis sul software di email per Unix, è disponibile su ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc nei file chiamati «UNIX_Email_Software_Survey_*». Una versione HTML è a http://www.faqs.org/faqs/mail/setup/unix/. Comunque mentre scrivo questo documento nel 1999, tale messaggio non è stato seriamente aggiornato dal 1996.
Non c'è niente di speciale sulla configurazione e l'uso della posta sotto Linux, rispetto ad altri Unix. Di conseguenza, quasi sicuramente NON è bene postare domande generiche sulla posta nei newsgroup comp.os.linux.*.
A meno che il proprio messaggio non sia veramente specifico su Linux (ie, «per piacere ditemi quali instradamenti sono già compilati nella versione di smail 3.1.28 della SLS 1.03») si dovrebbe chiedere aiuto in uno dei newsgroup o mailing list indicate in precedenza.
Lasciatemelo ripetere.
Non c'è virtualmente alcuna ragione di inviare ancora qualsiasi cosa relativa alla posta nella gerarchia comp.os.linux. Esistono newsgroup nella gerarchia comp.mail.* per rispondere a TUTTE le vostre domande.
Se si invia un messaggio in comp.os.linux.* con una domanda non specifica su Linux si sta cercando aiuto nel posto sbagliato. Gli esperti di posta elettronica bazzicano nei posti indicati in precedenza e generalmente non nei gruppi su Linux.
Inviare messaggi nella gerarchia Linux con domande non specifiche su Linux spreca il vostro e l'altrui tempo... e frequentemente vi ritarda l'ottenimento di una risposta alla vostra domanda.
(Questa sezione l'ha scritta Vince, ma la mia politica è la stessa.)
Sono interessato a qualsiasi commento, sia positivo che negativo, sul contenuto di questo documento. Mi si contatti se si trovano errori o omissioni ovvie.
Leggo, ma necessariamente non rispondo, tutte le email che ricevo. Richieste per miglioramenti saranno considerate e attuate a seconda della combinazione giornaliera di tempo libero, merito della richiesta e pressione sanguigna :-)
I flame finiranno bellamente in /dev/null quindi non preoccupatevi.
In particolare, lo standard sul filesystem di Linux per i percorsi è una cosa in evoluzione. Quanto c'è in questo documento è qui solo a titolo illustrativo ed è basato sullo standard corrente al momento di scrivere quella parte del documento e sui percorsi usati nella distribuzioni o «kit» da me visti. Invito a consultare la propria distribuzione di Linux per i percorsi da usare.
Commenti riguardo il formato corrente del documento dovrebbero andare al coordinatore degli HOWTO - inviare una mail a linux-howto@metalab.unc.edu).
The Mail-HOWTO is copyrighted (c)1999 Eric S. Raymond. Copyright is retained for the purpose of enforcing the Linux Documentation Project license terms.
A verbatim copy may be reproduced or distributed in any medium physical or electronic without permission of the author. Translations are similarly permitted without express permission if it includes a notice on who translated it.
Short quotes may be used without prior consent by the author. Derivative work and partial distributions of the Mail-HOWTO must be accompanied with either a verbatim copy of this file or a pointer to the verbatim copy.
Commercial redistribution is allowed and encouraged; however, the maintainer would appreciate being notified of any such distributions (as a courtesy).
In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents.
We further want that all information provided in the HOWTOS
is disseminated. If you have questions, please contact the Linux
HOWTO coordinator, at linux-howto@metalab.unc.edu.
Naturalmente, sconfesso qualsiasi potenziale affidabilità per il contenuto di questo documento. L'uso dei concetti, esempi e/o altro contenuto di questo documento è interamente a proprio rischio.
Questo documento è stato originariamente scritto da Vince Skahan. Io l'ho riscritto per il moderno mondo ISP-centrico nel quale UUCP è poco più che un ricordo.
Nel maggio 1999, il nome è stato cambiato da «The Linux Electronic Mail HOWTO» per evitare collisioni con il Mail HOWTO di Guylhem Aznar, che è diventato il Mail Administrator HOWTO.