The Linux Mail User HOWTO
  Eric S. Raymond, <esr@thyrsus.com>
  v2.2, 7 maggio 1999

  Questo documento è un'introduzione al mondo della posta elettronica
  (email) sotto Linux.  Si focalizza sulle questioni a livello utente e
  su tipiche configurazioni per macchine Linux casalinghe e per piccole
  aziende connesse alla rete attraverso un ISP.  È utile da leggere se
  si intende comunicare localmente o con siti remoti attraverso la posta
  elettronica.  Probabilmente _n_o_n serve leggere questo documento se non
  si scambia posta elettronica con altri utenti sul proprio sistema e
  con altri siti.  Per informazioni sulla configurazione e l'amminis­
  trazione della posta, si veda il Mail Administrator HOWTO.  Traduzione
  di Giovanni Bortolozzo, borto (at) pluto.linux.it.
  ______________________________________________________________________

  Indice Generale


  1. Introduzione
     1.1 Nuove versioni di questo documento
     1.2 Requisiti hardware per i programmi di email
     1.3 Sorgenti dei programmi di email

  2. Mail User Agent
     2.1 Impostare il proprio editor per la posta
     2.2 mutt
     2.3 elm
     2.4 pine
     2.5 Netscape
     2.6 rmail/smail e vm di Emacs.
     2.7 BSD mail
     2.8 Altri agenti utente

  3. Argomenti avanzati
     3.1 Alias
     3.2 Forwarding
     3.3 Risposta automatica
     3.4 Mailing list
     3.5 Filtrare la posta
     3.6 Gestire gli spam

  4. Altre fonti di informazione
     4.1 USENET
     4.2 Libri
     4.3 Messaggi USENET periodici
     4.4 Dove NON cercare aiuto

  5. Administrivia
     5.1 Commenti e critiche
     5.2 Informazioni di copyright (in inglese)
     5.3 Liberatoria standard
     5.4 Ringraziamenti


  ______________________________________________________________________

  11..  IInnttrroodduuzziioonnee

  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 <http://metalab.unc.edu/LDP/HOWTO/ISP-
  Hookup-HOWTO.html>.)

  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.


  11..11..  NNuuoovvee vveerrssiioonnii ddii qquueessttoo ddooccuummeennttoo

  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>.


  11..22..  RReeqquuiissiittii hhaarrddwwaarree ppeerr ii pprrooggrraammmmii ddii eemmaaiill

  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.


  11..33..  SSoorrggeennttii ddeeii pprrooggrraammmmii ddii eemmaaiill

  Il software che sarà necessario per il supporto email è probabilmente
  preinstallato nella propria distribuzione di Linux.  Si troveranno
  degli aggiornamenti sul Metalab Linux Archive
  <http://metalab.unc.edu/pub/Linux>, specialmente nella sottodirectory
  mail <http://metalab.unc.edu/pub/Linux/system/mail>.


  22..  MMaaiill UUsseerr AAggeenntt

  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).


  22..11..  IImmppoossttaarree iill pprroopprriioo eeddiittoorr ppeerr llaa ppoossttaa

  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.


  22..22..  mmuutttt

  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.


  22..33..  eellmm

  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
  <http://metalab.unc.edu/pub/Linux/system/mail>.  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.


  22..44..  ppiinnee

  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.


  22..55..  NNeettssccaappee

  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).


  22..66..  rrmmaaiill//ssmmaaiill ee vvmm ddii EEmmaaccss..

  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.


  22..77..  BBSSDD mmaaiill

  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.


  22..88..  AAllttrrii aaggeennttii uutteennttee

  È noto che anche i seguenti funzionano sotto Linux.  Si consulti
  «archie» per trovarli...

  ·  mush    - mail user's shell, molto potente per il filtraggio e il
     batch processing

  ·  mh      - mail handler, solo un altro mail user agent

  Non ne so abbastanza su mh e mush per descriverli in dettaglio.
  Entrambi hanno un'interfaccia abbastanza complessa e sono pensati per
  utenti sofisticati.



  33..  AArrggoommeennttii aavvaannzzaattii


  33..11..  AAlliiaass

  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.


  33..22..  FFoorrwwaarrddiinngg

  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.


  33..33..  RRiissppoossttaa aauuttoommaattiiccaa

  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.


  33..44..  MMaaiilliinngg lliisstt

  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
  <http://www.catalog.com/vivian/mailing-list-software.html> abbastanza
  completa di tali pacchetti.

  Per maggiori informazioni sui gestori delle mailing list, si
  consultino le risorse a List-Managers Mailing List
  <http://www.greatcircle.com/list-managers/>, tra cui la FAQ (nota:
  questa lista _n_o_n è appropriata per domande su come fare le cose).


  33..55..  FFiillttrraarree llaa ppoossttaa

  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
  <http://www.faqs.org/faqs/mail/setup/unix/part3/index.html> 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).


  33..66..  GGeessttiirree ggllii ssppaamm

  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! <http://spam.abuse.net/>.  La
  pagina Death To Spam!
  <http://www.mindworkshop.com/alchemy/nospam.html> è particolarmente
  efficace per i metodi per fermare o tracciare gli spam.


  44..  AAllttrree ffoonnttii ddii iinnffoorrmmaazziioonnee



  44..11..  UUSSEENNEETT

  Esistono numerosi gruppi Usenet devoti alla questioni tecniche delle
  posta elettronica:


  ·  comp.mail.elm Il sistema di posta ELM.

  ·  comp.mail.mh Il sistema Rand Message Handling.

  ·  comp.mail.mime Multipurpose Internet Mail Extensions.

  ·  comp.mail.misc Discussioni generali sulla posta elettronica.

  ·  comp.mail.multi-media Multimedia Mail.

  ·  comp.mail.mush La Mail User's Shell (MUSH).

  ·  comp.mail.sendmail L'agente BSD sendmail.

  ·  comp.mail.smail L'agente di posta smail.

  ·  comp.mail.uucp La posta in ambiente uucp.


  44..22..  LLiibbrrii


  La seguente è un insieme non inclusivo di libri che possono aiutare...


  ·  ``_S_e_n_d_m_a_i_l" della O'Reilly and Associates è il riferimento
     definitivo su sendmail-v8 e sendmail+IDA.  È un libro «da avere»
     per chiunque speri di ottenere qualcosa da sendmail senza impazzire
     nel processo.

  ·  "_T_h_e _I_n_t_e_r_n_e_t _C_o_m_p_l_e_t_e _R_e_f_e_r_e_n_c_e" della Osborne è un buon libro di
     riferimento che spiega i diversi servizi disponibili su Internet ed
     è una grande fonte di informazioni su news, posta e diverse altre
     risorse di Internet.
  ·  "_T_h_e _L_i_n_u_x _N_e_t_w_o_r_k_i_n_g _A_d_m_i_n_i_s_t_r_a_t_o_r_s_' _G_u_i_d_e" di Olaf Kirch di LDP è
     disponibile in rete ed è pure pubblicato (almeno) da O'Reilly e
     SSC.  È una buona guida per imparare tutto quel che si può
     immaginare di dover sapere sul networking di Unix.


  44..33..  MMeessssaaggggii UUSSEENNEETT ppeerriiooddiiccii

  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.


  44..44..  DDoovvee NNOONN  cceerrccaarree aaiiuuttoo

  Non c'è niente di speciale sulla configurazione e l'uso della posta
  sotto Linux, rispetto ad altri Unix.  Di conseguenza, quasi
  sicuramente _N_O_N è 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 _T_U_T_T_E le vostre domande.

  _S_e _s_i _i_n_v_i_a _u_n _m_e_s_s_a_g_g_i_o _i_n _c_o_m_p_._o_s_._l_i_n_u_x_._* _c_o_n _u_n_a _d_o_m_a_n_d_a _n_o_n
  _s_p_e_c_i_f_i_c_a _s_u _L_i_n_u_x _s_i _s_t_a _c_e_r_c_a_n_d_o _a_i_u_t_o _n_e_l _p_o_s_t_o _s_b_a_g_l_i_a_t_o_.  _G_l_i
  _e_s_p_e_r_t_i _d_i _p_o_s_t_a _e_l_e_t_t_r_o_n_i_c_a _b_a_z_z_i_c_a_n_o _n_e_i _p_o_s_t_i _i_n_d_i_c_a_t_i _i_n
  _p_r_e_c_e_d_e_n_z_a _e _g_e_n_e_r_a_l_m_e_n_t_e _n_o_n _n_e_i _g_r_u_p_p_i _s_u _L_i_n_u_x_.

  _I_n_v_i_a_r_e _m_e_s_s_a_g_g_i _n_e_l_l_a _g_e_r_a_r_c_h_i_a _L_i_n_u_x _c_o_n _d_o_m_a_n_d_e _n_o_n _s_p_e_c_i_f_i_c_h_e _s_u
  _L_i_n_u_x _s_p_r_e_c_a _i_l _v_o_s_t_r_o _e _l_'_a_l_t_r_u_i _t_e_m_p_o_._._. _e _f_r_e_q_u_e_n_t_e_m_e_n_t_e _v_i _r_i_t_a_r_d_a
  _l_'_o_t_t_e_n_i_m_e_n_t_o _d_i _u_n_a _r_i_s_p_o_s_t_a _a_l_l_a _v_o_s_t_r_a _d_o_m_a_n_d_a_.


  55..  AAddmmiinniissttrriivviiaa


  55..11..  CCoommmmeennttii ee ccrriittiicchhee


  (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 <mailto:linux-howto@metalab.unc.edu>).


  55..22..  IInnffoorrmmaazziioonnii ddii ccooppyyrriigghhtt ((iinn iinngglleessee))


  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 _a_l_l information provided in the HOWTOS is
  disseminated.  If you have questions, please contact the Linux HOWTO
  coordinator, at linux-howto@metalab.unc.edu.


  55..33..  LLiibbeerraattoorriiaa ssttaannddaarrdd

  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.


  55..44..  RRiinnggrraazziiaammeennttii

  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.