%% intromail.tex
%%
%% Copyright (C) 2008-2017 Simone Piccardi and Truelite Srl.
%%
%% This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
%% International License. To view a copy of this license, visit
%% \url{http://creativecommons.org/licenses/by-sa/4.0/} or send a letter to
%% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
%%
%% Corsi GNU/Linux: Dispense dei corsi GNU/Linux di Truelite
%%
%% S. Piccardi Apr. 2008
%% 
%% intromail.tex: sezione SMTP e altro
%%

%%
%% INIZIO: Sezione specifica da non includere in AGL
%%
\ifx\lpispecificsection\undefined

\chapter{La posta elettronica}
\label{cha:mail_services}


\section{Il \textit{Cos'è la posta elettronica}}
\label{sec:mail_intro}

La posta elettronica è uno dei primi servizi che sono stati realizzati sui
sistemi Unix, per consentire agli utenti di inviarsi messaggi. Essa nasce,
insieme con i servizi di bacheca elettronica (le \textit{network news}), ben
prima di Internet, quando le connessioni avvenivano solo per collegamenti
telefonici diretti fra server e la rete come la conosciamo oggi non
esisteva. Ma ancora oggi la posta elettronica, insieme alle pagine web,
costituisce uno dei principali servizi che si trovano su internet.

Benché il concetto di posta elettronica, con l'invio di un messaggio da un
mittente ad un destinatario, sia estremamente semplice, il servizio è in
realtà uno dei più complessi e prevede per la sua realizzazione la presenza di
numerosi attori e di diversi programmi sia sul lato server che su quello
client. In questa prima sezione faremo una panoramica sulle caratteristiche
del servizio e sulle modalità con cui questo viene implementato.

\else
\relax
%%
%% FINE: Sezione specifica da non includere in AGL
%%
\fi

\subsection{La struttura del servizio della posta elettronica}
\label{sec:mail_structure}

Come per la posta ordinaria, quella che in gergo informatico viene detta
\textit{snail mail}, anche il servizio di gestione della posta elettronica
prevede la presenza di diverse infrastrutture deputate alla spedizione,
all'inoltro, alla ricezione e allo smistamento dei vari messaggi.

\itindbeg{Mail~User~Agent (MUA)} 
\itindbeg{Mail~Transport~Agent (MTA)} 

Il meccanismo è analogo a quello della posta ordinaria, un utente che invia la
posta (il mittente, o ``\textit{sender}'') deve utilizzare un apposito
programma, denominato \textit{Mail User Agent} (o MUA), che serve ad
``\textsl{imbucare}'' la propria posta elettronica presso un altro programma,
denominato \textit{Mail Transport Agent} (o MTA), che è quello che si incarica
del trasporto della stessa fino al destinatario (il cosiddetto
\textit{recipient}) svolgendo cioè il ruolo del servizio postale.  Per questo
in genere si parla di ``\textsl{client di posta}'' per indicare un
\textit{Mail User Agent} e di ``\textsl{server di posta}'' per indicare un
\textit{Mail Transport Agent}, anche se vederemo che in realtà per gestire la
posta elettronica oltre agli MTA esistono altri tipi di server, dedicati ad
altri compiti.

\itindend{Mail~User~Agent (MUA)}
\itindend{Mail~Transport~Agent (MTA)}


\begin{figure}[!htb]
  \centering
  \includegraphics[scale=0.75]{../mailservices/images/MailLocalSending}
  \caption{La posta elettronica nel caso di \textsl{trasporto locale}.}
  \label{fig:mail_local_delivery}
\end{figure}

Il caso più semplice di gestione della posta elettronica, illustrato in
fig.~\ref{fig:mail_local_delivery}, è il cosiddetto \textsl{trasporto locale}
(o \textit{local delivery}) in cui all'interno di una macchina si vuole
inviare un messaggio ad un altro utente della macchina stessa. Questo caso è
tipico del funzionamento ordinario dei sistemi Unix in cui alcuni servizi,
come \textit{cron}, usano proprio la posta elettronica per eseguire delle
notifiche agli utenti.

Un qualunque MTA deve essere in grado di eseguire questo compito, ed in
effetti nel corso del tempo sono stati sviluppati diversi server a questo
scopo. Il primo di questi, ancora molto usato è \textit{Sendmail}, che però,
essendo nato come progetto cresciuto disordinatamente a cui sono state
aggiunte progressivamente estensioni su estensioni ha sofferto a lungo di
scarsa gestibilità del codice con gravi problemi di sicurezza ed è tuttora
afflitto da una complessità eccessiva nella configurazione.

Per questo a vario titolo sono stati sviluppati altri server MTA, come
\textit{Exim}, \textit{Qmail}, \textit{Courier MTA}, \textit{Postfix}, che
permettessero di superare i vari limiti di \textit{Sendmail}. Inoltre nel caso
si voglia effettuare soltanto un inoltro locale esistono degli MTA, come
\texttt{ssmtp}, dedicati allo svolgimento esclusivo di questo compito, che si
possono installare tutte le volte che non sono necessarie le altre
funzionalità e si deve ridurre al minimo l'uso delle risorse sulla macchina.

Inoltre per l'esecuzione dell'inoltro locale può entrare in gioco un ulteriore
componente, anch'esso illustrato in fig.~\ref{fig:mail_local_delivery}, detto
\textit{Local Delivery Agent} o LDA, che si incarica di svolgere il ruolo del
postino nella consegna finale del messaggio nella \textsl{casella postale} del
destinatario, e che può essere utilizzato per compiere delle ulteriori
funzioni nella consegna finale del messaggio, come ad esempio suddividere i
messaggi in cartelle a seconda dell'argomento, del mittente, scartare messaggi
indesiderati, ecc.

\begin{figure}[!htb]
  \centering
  \includegraphics[scale=0.75]{../mailservices/images/MailDirectSending}
  \caption{La posta elettronica nel caso di invio diretto da un server di
    posta.}
  \label{fig:mail_server_server}
\end{figure}

In generale però il compito principale di un \textit{Mail Transport Agent} è
quello di curare il trasporto della posta per i destinatari remoti, ed è
questa la parte più complessa. In genere questo compito viene svolto
attraverso la rete come illustrato in fig.~\ref{fig:mail_server_server},
contattando, con gli opportuni protocolli, il server di posta del
destinatario, a cui viene poi delegata la consegna della posta alla casella
postale di quest'ultimo.

Il protocollo più utilizzato per il trasporto della posta è il cosiddetto
\textit{Simple Mail Transfer Protocol} (SMTP)
\ifx\lpispecificsection\undefined (che vedremo in sez.~\ref{sec:mail_SMTP})
\else\relax\fi attraverso il quale un server MTA può inviare i messaggi da
consegnare ad un altro server MTA, o ricevere gli stessi da un
client. Esistono comunque delle alternative, ad esempio prima della diffusione
di internet, quando la trasmissione dei dati veniva effettuata attraverso
collegamenti temporanei via modem, la posta veniva trasferita appoggiandosi ad
altri protocolli come UUCP.\footnote{l'\textit{Unix to Unix CoPy} è un
  servizio di comunicazione che consentiva di inviare dati ed eseguire comandi
  su collegamenti temporanei (come linee telefoniche in \textit{dial-up});
  oggi è ancora utilizzabile essendo stato incapsulato su TCP/IP, ma
  sostanzialmente dismesso, anche se può presentare vantaggi non indifferenti
  rispetto a SMTP consentendo il trasferimento di più messaggi in blocco.}

Nel caso illustrato in fig.~\ref{fig:mail_server_server} il \textit{Mail
  Transport Agent} ed il \textit{Mail User Agent} sono semplicemente due
programmi residenti sulla stessa macchina e possono quindi anche parlarsi
direttamente. Vedremo in sez.~\ref{sec:mail_commands} come sia possibile
inviare messaggi direttamente con comandi generici indipendenti dal server MTA
che si sta usando, che a seconda dei casi possono anche immetterli
direttamente sulle code di spedizione di quest'ultimo.

Questa configurazione, che era quella classica utilizzata agli albori di
internet, quando la posta si poteva spedire soltanto avendo un account su un
server collegato alla rete, oggi viene usata sempre meno, dato che la posta si
spedisce direttamente lavorando sulla propria stazione di lavoro, sulla quale
normalmente non viene installato un server per la ricezione diretta della
posta.

\begin{figure}[!htb]
  \centering
  \includegraphics[scale=0.75]{../mailservices/images/MailSending}
  \caption{Schema del funzionamento della posta elettronica nel caso di invio
    da una workstation.}
  \label{fig:mail_workstation_server}
\end{figure}

In questo caso, illustrato in fig.~\ref{fig:mail_workstation_server}, è
compito del client di posta essere in grado di parlare opportunamente con il
server di posta per richiedere l'invio. In genere viene usato lo stesso
protocollo SMTP utilizzato nella comunicazione fra server di posta su
Internet, solo che di norma in questo caso il server a cui ci si rivolge è
posto all'interno della stessa rete della macchina da cui si effettua la
spedizione.

%%
%% INIZIO: Sezione specifica da non includere in AGL
%%
\ifx\lpispecificsection\undefined

In realtà è sempre possibile installare un server di posta sulla macchina
stessa del mittente, riportandosi alla situazione di
fig.~\ref{fig:mail_server_server}. Questo ha il vantaggio che, in caso di
macchina scollegata dalla rete, la posta in uscita verrà mantenuta in coda dal
server, che provvederà ad inviarla non appena la connessione sarà
disponibile.\footnote{in realtà oggi una configurazione del genere per una
  macchina casalinga deve comunque prevedere la configurazione del proprio
  server di posta per il reinvio verso il server del provider, in quanto è
  molto probabile che un invio diretto dalla propria macchina incorra in un
  rifiuto a causa delle misure di prevenzione contro la diffusione dello
  spam.} Qualora (come è comune su sistemi non Unix) non si disponga di un
server mail locale, si potrà comunque contattare il server che il proprio
provider mette a disposizione.

Abbiamo già visto fin dal caso del trasporto locale che, come avviene per un
servizio postale nel mondo reale, il compito di un \textit{Mail Transport
  Agent} non è soltanto quello di inoltrare verso la destinazione i messaggi
che gli vengono affidati (cioè ``\textsl{svuotare}'' la buca delle lettere),
ma anche quello di consegnare quelli che riceve per i propri utenti nella
casella di posta del destinatario (cioè ``\textsl{riempire}'' la cassetta
della posta).

Una volta che il messaggio arrivi al server di posta del destinatario questo
dovrà provvedere a depositarlo nella casella di posta (la cosiddetta
\textit{mailbox}) dell'utente, anche attraverso l'uso di \textit{Local
  Delivery Agent}. In generale a questo livello tutti gli MTA prevedono
ulteriori funzionalità come la possibilità di ricevere messaggi per diversi
\textit{alias} dell'utente finale, o di reinviare gli stessi ad un altro
indirizzo di posta.

Si tenga presente inoltre che non è detto che la comunicazione avvenga
direttamente fra il server di posta del mittente e quello del destinatario,
infatti \ifx\lpispecificsection\undefined come vedremo in
sez.~\ref{sec:mail_SMTP} \else\relax\fi il protocollo SMTP supporta il
reinoltro della posta ed il passaggio fra server intermedi. Ad esempio per gli
utenti con connessioni temporanee (o che spengono la macchina dopo aver finito
di lavorare) è sempre opportuno far eseguire, anche quando si ha un server di
posta in locale, il passaggio (chiamato in gergo \textit{relay}) dal server
del provider, che essendo sempre in rete oltre a ritrasmettere il messaggio in
caso di problemi temporanei di connessione, sarà anche in grado di ricevere
eventuali messaggi di errore da parte della destinazione, che altrimenti
rischierebbero di essere persi.

Il meccanismo di funzionamento della posta elettronica prevede infatti che una
volta che un messaggio sia stato accettato da un server di posta questo debba
fare del suo meglio per consegnarlo a destinazione, tentando anche più volte
qualora la destinazione sia temporaneamente irraggiungibile.  Il protocollo
però prevede anche che se, per un qualche motivo, la consegna non è possibile,
questo fallimento debba essere notificato al mittente del messaggio, e se il
server di quest'ultimo non è attivo questo non è possibile.

Infine una ultima caratteristica del servizio, che spesso viene ignorata, è
che la spedizione della posta elettronica è un evento asincrono, per cui sono
tranquillamente ammissibili (ed anche preventivati) ritardi non trascurabili
fra la spedizione e la ricezione. Il fatto che in genere la ricezione sia
praticamente immediata non significa che questo sia garantito, anzi lo
standard prevede che possa passare un tempo fino ad un massimo di tre giorni
prima che al mittente venga notificato un eventuale problema di spedizione
rimasta in sospeso.

Finora ci siamo concentrati sull'invio dei messaggi di posta, ma quando
entrano in gioco le necessità relative alla ricezione degli stessi da parte
dei destinatari finali la struttura del servizio illustrata in precedenza è
incompleta, in quanto essa è può essere applicata solo agli utenti che hanno a
disposizione un account che gli consenta di leggere la posta sul server,
permanentemente collegato ad internet, che la riceve.

\begin{figure}[!htb]
  \centering
  \includegraphics[scale=0.75]{../mailservices/images/MailReceiving}
  \caption{Schema del funzionamento della posta elettronica nel caso di
    ricezione da parte di un utente con connessione non permanente.}
  \label{fig:mail_server_client}
\end{figure}

In generale i normali utenti di un servizio di posta elettronica non
dispongono di una tale struttura, ma si collegano dalla propria macchina di
lavoro per intervalli di tempo limitato, e pertanto il servizio di fruizione
della posta elettronica ricevuta deve eseguito in una modalità diversa,
facendo ricorso ad un analogo di quello che è il \textsl{fermoposta} per la
posta ordinaria, secondo le modalità di gestione illustrate nello schema in
fig.~\ref{fig:mail_server_client}.

Quando si opera su una stazione di lavoro infatti, anche qualora si fosse
installato su di essa un server di posta,\footnote{se lo si fa, lo si fa solo
  per la gestione della posta in uscita, non di quella in ingresso.} questo
non potrà effettuare la ricezione dei messaggi, poiché essendo la macchina
attiva e collegata ad internet per tempi limitati, non sarebbe in grado di
rispondere in maniera costante alle richieste, inoltre quando si lavora in una
organizzazione all'interno di una rete locale la macchina non dovrebbe neanche
essere raggiungibile da internet.  Questo comporta che la lettura dei messaggi
deve passare attraverso l'uso di un server remoto che si incarichi di ricevere
e salvare i messaggi in una casella di posta, dalla quale possano essere
riletti in un tempo successivo.

Dato che in questo caso non si ha un accesso diretto alla propria mailbox,
come accade quando il \textit{Mail User Agent} viene eseguito direttamente sul
server, un client di posta non può leggerne direttamente il contenuto. Per
risolvere questo problema ci sono sostanzialmente due alternative. La prima è
quella di usare il proprio client per interrogare il server che riceve la
posta, utilizzando un opportuno protocollo di ricezione che consenta di
ottenere il contenuto dei messaggi presenti nella propria casella direttamente
via rete.

La seconda possibilità, che può permettere un uso più efficiente delle
connessioni quando il tempo di collegamento è un costo, è quella di usare un
opportuno programma di lettura che, utilizzando sempre uno di questi
protocolli per la ricezione, sia grado di scaricare i messaggi dal server
remoto e portarli in locale. Un esempio di questo tipo di programmi, citato
anche in fig.~\ref{fig:mail_server_client}, è \texttt{fetchmail}, che è in
grado di scaricare i messaggi anche da più server, trasmettendoli poi ad un
\textit{Mail Transport Agent} locale. In questo modo i messaggi saranno
direttamente disponibili sulla propria macchina, e potranno essere acceduti
con comodo in un secondo tempo.

Si noti come in entrambi i casi sia comunque necessario che sul server che
riceve la posta sia stato installato un opportuno programma che fornisca il
servizio di consegna della posta via rete. Per la realizzazione del servizio
di ricezione sono stati definiti due diversi protocolli di comunicazione, il
POP (\textit{Post Office Protocol}) e l'IMAP (\textit{Internet Message Access
  Protocol}) che devono ovviamente essere supportati sia lato client che lato
server, tratteremo in dettaglio l'argomento in sez.~\ref{sec:mail_pop_imap}.


\subsection{Il protocollo SMTP}
\label{sec:mail_SMTP}

Il \textit{Simple Mail Transfer Protocol} (da qui in avanti SMTP) è il
protocollo standard per la trasmissione della posta elettronica su internet,
standardizzato nell'\href{http://www.ietf.org/rfc/rfc2821.txt}{RFC~2821} in
cui sono state raccolte la varie specifiche presenti in vari RFC
precedenti.\footnote{per la precisione questo RFC rimpiazza l'originale
  \href{http://www.ietf.org/rfc/rfc821.txt}{RFC~821} del 1982 e le successive
  estensioni.}  La trasmissione dei dati avviene su connessioni TCP ed al
protocollo è stata riservata la porta 25.

Il protocollo SMTP è uno dei primi protocolli utilizzati su internet, e nasce
in un periodo in cui ancora il grosso della posta veniva trasmesso con UUCP su
collegamenti temporanei, come complemento a quest'ultimo in caso di macchine
dotate di connessione permanente.  Il protocollo è relativamente semplice e
consente soltanto l'invio di posta da un server al successivo secondo un
modello di ``\textit{store and forward}'' in cui chi riceve la posta, se non è
il destinatario finale, si deve curare di registrarla temporaneamente per poi
eseguirne l'inoltro verso la destinazione in un momento successivo. Come
accennato in sez.~\ref{sec:mail_structure} per la ricezione della posta sono
stati definiti altri protocolli come POP e IMAP, che tratteremo in
sez.~\ref{sec:mail_pop_imap}.

Questo significa che SMTP permette di eseguire l'inoltro della posta
elettronica da una rete all'altra facendo anche uso di server intermedi che
possono posti sia sulla propria rete locale che su internet. Si possono cioè
usare sia server di ``\textit{relay}'' per l'invio, su cui raccogliere i
messaggi in uscita per un successivo inoltro, che server di
``\textit{gateway}'' per la ricezione, su cui raccogliere i messaggi in arrivo
da smistare su una rete interna.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=13cm]{../mailservices/images/SMTP_diagram}
  \caption{Schema del protocollo SMTP.}
  \label{fig:mail_SMTP_protocol}
\end{figure}

In fig.~\ref{fig:mail_SMTP_protocol} si è illustrato un possibile schema di
utilizzo del protocollo SMTP per l'invio di un messaggio di posta elettronica
da un mittente ad un destinatario. In questo esempio il protocollo viene
utilizzato sia dal client di posta del mittente per la spedizione del
messaggio al suo server SMTP di uscita, che da questo per contattare il server
SMTP del destinatario ed inviargli il messaggio. Benché sia comune creare una
connessione per ogni messaggio inviato, il protocollo supporta anche l'invio
di messaggi multipli all'interno di una singola connessione.

Un esempio di una sessione in cui si esegue una transazione SMTP per l'invio
di un semplice messaggio di posta è quella seguente, che si è eseguita
manualmente contattando direttamente il server sulla porta 25 con il comando
\texttt{telnet}. Nell'esempio si sono evidenziati i comandi che sono stati
scritti sul client usando un font inclinato colorato in rosso, mentre il testo
ordinario è quanto ricevuto come risposta dal server:

\begin{Console}
220 holland.truelite.it ESMTP Postfix (Debian GNU/Antani)
\textbf{HELO truelite.it}
250 holland.truelite.it
\textbf{MAIL FROM: piccardi@truelite.it}
250 2.1.0 Ok
\textbf{RCPT TO: piccardi@softwarelibero.it}
250 2.1.5 Ok
\textbf{DATA}
354 End data with <CR><LF>.<CR><LF>
\textbf{From: piccardi@truelite.eu}
\textbf{To: piccardi@softwarelibero.it}
\textbf{Subject: prova}

\textbf{Prova}
\textbf{.}
250 2.0.0 Ok: queued as 2C2F81C03EF6
\textbf{QUIT}
221 2.0.0 Bye
\end{Console}

Come si può notare una volta effettuato il collegamento è cura del server
inviare un messaggio di ingresso. Questo, come tutti i messaggi inviati dal
server, è preceduto da un valore numerico che indica il \textsl{codice} del
messaggio. In genere il messaggio iniziale del server riporta, come
nell'esempio, il nome a dominio dello stesso e la versione del demone SMTP
utilizzata e vedremo in sez.~\ref{sec:postfix_base_config} come questo possa
essere completamente personalizzato nella configurazione del server.

Prima di poter iniziare la transazione SMTP vera e propria è richiesto che il
client si presenti al server con un comando di benvenuto. Di questo esistono
due versioni, quella originaria, stabilita fin dalla prima versione del
protocollo, è \texttt{HELO}, che deve essere seguita da un nome che permetta
l'identificazione del client (in genere si usa il proprio nome a dominio). Nei
server moderni questo comando viene fornito esclusivamente per compatibilità,
infatti l'\href{http://www.ietf.org/rfc/rfc2821.txt}{RFC~2821} richiede che si
utilizzi preferenzialmente la nuova versione, \texttt{EHLO}.

L'uso del comando \texttt{EHLO} indica al server che il client è in grado di
gestire le estensioni del protocollo, ed in questo caso il server risponderà,
oltre che con un \texttt{Ok}, anche con una lista dei comandi estesi presenti,
se lo si fosse fatto nel caso precedente si sarebbe avuto come risposta
qualcosa del tipo:
\begin{Console}
220 holland.truelite.it ESMTP Postfix (Debian GNU/Antani)
\textbf{EHLO truelite.it}
250-holland.truelite.it
250-PIPELINING
250-SIZE 40960000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
\end{Console}

Benché non ne sia previsto un utilizzo diretto per l'invio della posta, è
comunque sempre opportuno indicare come argomento del comando di benvenuto
(\texttt{HELO} o \texttt{EHLO} che sia) un dominio valido.  Alcuni server
infatti effettuano dei controlli (vedremo come farlo con Postfix in
sez.~\ref{sec:postfix_base_config}) che questo sia corretto, esista e abbia
una risoluzione sia diretta che inversa, e non accettano la posta se questi
non hanno successo.

Una volta dato il comando di presentazione si può dare inizio alla transazione
SMTP vera e propria, richiedendo l'invio di un messaggio. Si tenga presente
che la transazione può essere interrotta in uno qualunque dei passi previsti
con il comando \texttt{RSET}. Il primo passo per iniziare la transazione si
effettua con il comando \texttt{MAIL}, che permette di indicare quello che
viene chiamato \itindex{envelope~sender} l'\textit{envelope sender}, cioè
l'indirizzo di posta elettronica del mittente come viene visto a livello di
server SMTP.  Questo deve essere specificato nella forma generica:
\begin{Example}
MAIL FROM: <nomemittente@dominio.it>
\end{Example}
dove l'indirizzo può essere indicato con o senza l'uso dei delimitatori
``\texttt{<}'' e ``\texttt{>}''.\footnote{per la descrizione della sintassi
  esatta con cui si può esprimere dell'indirizzo del mittente si consulti
  l'\href{http://www.ietf.org/rfc/rfc2821.txt}{RFC~2821} e le altre fonti ivi
  citate.}

In realtà la posta elettronica prevede, come avviene anche per la posta
normale, che l'indirizzo del mittente si possa scrivere sia sulla busta su cui
sarà letto dal postino (e questo è appunto \itindex{envelope~sender}
l'\textit{envelope sender}) che all'interno del messaggio stesso in una
apposita intestazione. E come nella realtà e nell'esempio precedente non è
detto che questi siano uguali (torneremo su questo anche in
sez.~\ref{sec:mail_message_struct}).

Si tenga presente però che \itindex{envelope~sender} l'\textit{envelope
  sender} è l'indirizzo di posta che viene usato dal server SMTP per
notificare al mittente gli eventuali errori incontrati nell'invio del
messaggio, quanto si è scritto come mittente all'interno del messaggio stesso
non viene in genere preso in considerazione. È pertanto più che opportuno che
si indichi come \itindex{envelope~sender} \textit{envelope sender} un
indirizzo reale su un dominio valido, in modo che le risposte possano tornare
indietro. Si tenga conto inoltre che alcuni server SMTP rifiutano di accettare
posta qualora si indichino domini inesistenti (di nuovo vedremo come farlo con
\textit{Postfix} in sez.~\ref{sec:postfix_base_config}).

Al comando \texttt{MAIL} devono seguire una o più indicazioni dei destinatari
del messaggio, ciascuno dei quali deve essere specificato con l'uso del
comando \texttt{RCPT}; se cioè ci sono più destinatari si deve ripetere più
volte il comando \texttt{RCPT}. In questo caso la forma del comando deve
essere sempre nella forma:
\begin{Example}
RCPT TO: <nomedestinatario@altrodominio.it>
\end{Example}
dove per il formato dell'indirizzo di posta valgono le stesse considerazioni
precedenti. 

Si tenga presente che quando un server accetta della posta da inoltrare per un
utente che sta su un altro server non è in grado di fare nessun controllo
sulla esistenza dell'utente stesso; il messaggio sarà accettato ed in caso di
errore si riceverà una notifica dello stesso sempre via posta
elettronica. Qualora invece il messaggio sia diretto ad un utente sul dominio
gestito dal server stesso si potrà avere immediatamente una notifica di errore
se l'utente non esiste.

Una volta definiti mittente e destinatari si può passare all'invio del corpo
del messaggio. Questo si fa attraverso l'uso del comando \texttt{DATA}. Il
protocollo SMTP originale supporta esclusivamente l'invio di un messaggio di
testo in codice ASCII elementare a 7 bit (cioè senza caratteri di
controllo). Se, come nell'esempio, si usa un server con la versione estesa del
protocollo (presentandosi con un \texttt{EHLO}) che supporta l'estensione
\texttt{8BITMIME}, si potrà eseguire una trasmissione codificata attraverso
una richiesta esplicita data dall'uso del parametro aggiuntivo
\texttt{BODY=8BITMIME} del comando \texttt{MAIL}. In generale però la posta
viene inviata sempre in ASCII standard a 7 bit, codificando opportunamente il
contenuto.

Qualunque sia la codifica scelta il testo del messaggio (sul cui formato
torneremo in sez.~\ref{sec:mail_message_struct}) deve essere inviato sulla
connessione a partire dalla riga seguente il comando \texttt{DATA}. Tutte le
righe scritte di seguito al comando \texttt{DATA} vengono considerate testo
del messaggio fintanto che non si incontra una riga che contiene soltanto il
carattere ``\texttt{.}'' che viene scartata ed usata come indicazione di
conclusione del messaggio; il comando \texttt{DATA} cioè viene sempre
terminato dalla sequenza di caratteri ``\texttt{<CR><LF>.<CR><LF>}''

Una volta completata la scrittura del messaggio sulla connessione questo viene
accettato dal server e la transazione si può considerare terminata, sarà
possibile iniziarne un'altra per spedire un altro messaggio, o chiudere la
connessione come si è fatto nell'esempio precedente. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|c|p{10cm}|}
    \hline
    \textbf{Comando} & \textbf{Significato} \\
    \hline
    \hline
    \texttt{HELO} & comando di benvenuto, richiede l'inizio di una
                    sessione SMTP standard.\\
    \texttt{EHLO} & comando di benvenuto, richiede l'inizio di una
                    sessione SMTP estesa, con la notifica delle estensioni
                    supportate dal server\\
    \texttt{MAIL} & inizia una transazione SMTP ed imposta 
                    \itindex{envelope~sender} l'\textit{envelope sender}, deve
                    essere seguito 
                    dall'indirizzo di posta del mittente, pertanto assume
                    sempre la forma ``\texttt{MAIL FROM: indirizzo}''.\\ 
    \texttt{RCPT} & imposta l'\textit{envelope recipient}, deve essere 
                    seguito dall'indirizzo di posta del destinatario, pertanto
                    assume la forma ``\texttt{RCPT TO: indirizzo}''.\\ 
    \texttt{DATA} & segnala l'inizio dei dati del messaggio, che seguono  
                    dalla riga seguente.\\
    \texttt{RSET} & abortisce la transazione SMTP corrente.\\
    \texttt{QUIT} & chiude il collegamento al server.\\
    \texttt{NOOP} & operazione nulla.\\
    \texttt{VRFY} & chiede la verifica di un indirizzo utente.\\
    \hline
  \end{tabular}
  \caption{I comandi standard minimi richiesti dal protocollo \texttt{SMTP}.}
  \label{tab:smtp_protocol_command}
\end{table}

Oltre a quelli illustrati finora il protocollo SMTP prevede una serie di
comandi di base, illustrati in tab.~\ref{tab:smtp_protocol_command}, che
qualunque server deve implementare per potersi dire conforme allo standard, a
questi se ne possono aggiungere altri, relativi ad estensioni che possono
essere o meno presenti (o abilitate), come la cifratura della connessione
(attivata dal comando \texttt{STARTTLS}) o le sessioni autenticate (da
effettuare con il comando \texttt{AUTH}) (torneremo su questi più avanti, in
sez.~\ref{sec:postfix_auth_ssl}).

Si tenga presente che benché si siano indicati i comandi in maiuscolo, come
tradizionalmente vengono espressi, lo standard stabilisce esplicitamente che
essi debbano del tutto indipendenti dal tipo di lettere (maiuscole, minuscole,
o anche miscuglio dei due) con cui li si scrivono; l'unica parte \textit{case
  sensitive} all'interno dei comandi SMTP è quella relativa alla parte locale
dell'indirizzo di posta elettronica, cioè il nome che viene prima del
carattere ``\texttt{@}''.

Come si può notare dall'esempio di transazione illustrato in precedenza, il
protocollo prevede che a ciascun comando sia data una adeguata risposta da
parte del server. A ciascuna di queste risposte è prefisso un opportuno codice
di risposta, cui segue, separato da uno spazio, un testo con la spiegazione
del codice. Qualora detto testo debba essere riprodotto su più righe (come nel
secondo esempio) il codice numerico viene ripetuto per tutte le righe ed il
separatore viene convertito ad un ``\texttt{-}'' tranne che per la riga
finale.

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|c|p{8cm}|}
    \hline
    \textbf{Codice} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{1yz} & risposta positiva preliminare: il comando è accettato ma la
                   richiesta è sospesa e richiede un ulteriore comando per
                   indicare se proseguire o interrompere (non viene usato
                   nell'SMTP di base).\\
    \texttt{2yz} & risposta positiva definitiva: il comando è stato accettato
                   e l'azione richiesta completata con successo, si può
                   eseguire una ulteriore richiesta.\\
    \texttt{3yz} & risposta positiva temporanea: il comando è stato accettato
                   ma la richiesta è sospesa in attesa di ulteriori dati.\\
    \texttt{4yz} & risposta negativa temporanea: il comando è stato rifiutato
                   ma la condizione di errore è considerata temporanea, per
                   cui la richiesta potrà essere ripetuta.\\
    \texttt{5yz} & risposta negativa definitiva: il comando è stato rifiutato
                   e la condizione di errore è considerata definitiva, è
                   inutile cercare di ripetere la richiesta.\\
    \hline
  \end{tabular}
  \caption{Le tipologie dei codici di risposta del protocollo SMTP.}
  \label{tab:mail_smtp_code_types}
\end{table}
 
I codici di risposta sono classificabili in base al valore delle loro prime
due cifre. La prima cifra indica il significato generale della risposta, se
questa è positiva o negativa, e se lo è in maniera temporanea, permanente o
preliminare, secondo quanto illustrato in tab.~\ref{tab:mail_smtp_code_types}.
La seconda cifra viene usata per classificare gli argomenti a cui la risposta
fa riferimento (sintassi, connessione di rete o sistema di posta), come
illustrato in tab.~\ref{tab:mail_smtp_code_categories}.

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|c|l|}
    \hline
    \textbf{Codice} &\textbf{Significato}\\
    \hline
    \hline
    \texttt{x0z} & sintassi    \\
    \texttt{x1z} & informazione\\
    \texttt{x2z} & connessione \\
    \texttt{x3z} & indefinito \\
    \texttt{x4z} & indefinito \\
    \texttt{x5z} & posta elettronica\\
    \hline
  \end{tabular}
  \caption{Le categorie dei codici di risposta del protocollo SMTP.}
  \label{tab:mail_smtp_code_categories}
\end{table}

In generale per un client di posta sono sufficienti i valori numerici, il
testo è a esclusivo uso dell'utente ed in genere dipende dall'implementazione.
La strutturazione precedente consente ai client di posta di avere una
informazione generale usando la prima cifra ed una un po' più dettagliata
utilizzando anche la seconda. Il codice completo descrive i singoli errori.
Si sono riportati i principali codici di risposta del protocollo in
tab.~\ref{tab:mail_smtp_codes}, l'elenco completo è disponibile
nell'\href{http://www.ietf.org/rfc/rfc2821.txt}{RFC~2821}.

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|c|l|}
    \hline
    \textbf{Codice} & \textbf{Significato}\\
    \hline
    \hline
    \texttt{220} & Servizio pronto.\\
    \texttt{221} & Servizio in chiusura della connessione.\\
    \texttt{250} & Azione richiesta completata con successo.\\
%    \texttt{251} & .\\
%    \texttt{252} & .\\
    \texttt{354} & iniziare ad immettere il corpo del messaggio.\\
    \texttt{421} & servizio indisponibile, chiusura della connessione.\\
    \texttt{450} & azione richiesta abortita, casella postale indisponibile.\\
    \texttt{451} & azione richiesta abortita, errore locale nell'esecuzione.\\
    \texttt{452} & azione richiesta abortita, spazio insufficiente per lo
                   stoccaggio.\\ 
    \texttt{500} & errore di sintassi.\\
    \texttt{501} & errore di sintassi nei parametri.\\
    \texttt{502} & comando non implementato.\\
    \texttt{503} & sequenza dei comandi errata.\\
    \texttt{504} & parametro del comando non implementato.\\
    \texttt{550} & azione richiesta rifiutata, casella postale indisponibile.\\
%    \texttt{551} & .\\
    \texttt{552} & azione richiesta abortita, ecceduto lo spazio disponibile.\\
    \texttt{553} & azione richiesta rifiutata, casella postale non
                   consentita.\\ 
    \texttt{554} & transazione fallita. \\
    \hline
  \end{tabular}
  \caption{I principali codici di risposta del protocollo SMTP.}
  \label{tab:mail_smtp_codes}
\end{table}

Abbiamo già incontrato alcuni dei codici di tab.~\ref{tab:mail_smtp_codes}
nell'esempio di transazione SMTP illustrata in precedenza, in particolare i
codici relativi all'inizio (\texttt{220}) e alla fine (\texttt{221}) della
connessione, quelli (\texttt{250}) di accettazione dei vari comandi, o di
richiesta (\texttt{354}) dei dati del messaggio.

Negli esempi precedenti si sono però presentati soltanto codici di successo;
in realtà la vera utilità dei codici è in caso di errore, in quanto questi
servono ad indicare la causa dell'errore. Fra questi è fondamentale tenere
presente la distinzione fra codici di errore temporanei (quelli con valore
\texttt{4yz}) e quelli definitivi (con valore \texttt{5yz}) in quanto questi
richiedono un diverso comportamento da parte di un server di posta. 

In genere infatti quando un codice di errore viene incontrato in una
transazione SMTP eseguita da un client questo semplicemente lo riporta
direttamente all'utente. Ma quando è un server SMTP che incontra una
condizione di errore nell'inoltro di un messaggio verso la destinazione si
pone il problema di quale azione eseguire come risposta. 

Lo standard prevede che in caso di errore temporaneo il server, che si è
assunto la responsabilità dell'inoltro della posta elettronica, debba
riprovare ad eseguire la transazione in un periodo successivo; nel caso di
Postfix questo avviene di default per intervalli di quattro ore. Solo in caso
di perdurare della condizione di errore temporanea per intervalli di tempo
prolungati (oltre cinque giorni) si dovrà considerare il fallimento
definitivo.\footnote{per questi tempi lo standard non dà prescrizioni precise,
  si limita ad indicare un periodo di almeno 30 minuti per la ripetizione
  della transazione e di 4/5 giorni come periodo totale di attesa; l'unica
  prescrizione al proposito è che entrambi i periodi devono essere
  configurabili.}

In questo caso, come in quello di rilevamento immediato di una condizione di
errore definitiva il server stesso dovrà procedere all'invio di un messaggio
di notifica dell'impossibilità di consegnare la posta (il cosiddetto
\textit{bounce}) al mittente del messaggio, che così potrà essere avvisato
dell'errore. Dato che anche questi messaggi possono a loro volta incontrare
problemi di consegna, per evitare l'innescarsi di un circolo vizioso è
richiesto che l'indirizzo del mittente sia annullato, si dovrà avere cioè un
comando \texttt{MAIL} nella forma:
\begin{Verbatim}[xleftmargin=1.5cm]
MAIL FROM: <>
\end{Verbatim}
l'indirizzo del mittente vuoto quindi non deve essere mai scartato, in quanto
è un indirizzo valido usato proprio per i messaggi di
errore.\footnote{purtroppo esistono server di posta configurati per non
  inoltrare messaggi di questo tipo, con la conseguenza di non consentire che
  i propri utenti vengano avvisati di eventuali errori di inoltro.}


\subsection{La struttura dei messaggi di posta elettronica.}
\label{sec:mail_message_struct}


\section{I client per la posta elettronica.}
\label{sec:mail_clients}

Tratteremo in questa sezione i principali client di posta elettronica
disponibili come software libero, a partire dai programmi a riga di comando
più minimali usati principalmente negli script, passando poi a illustrare le
caratteristiche principali di \textit{Mail User Agent} sofisticati a riga di
comando come \texttt{mutt} o grafici come \texttt{thunderbird}, nell'ottica di
illustrare le loro configurazione di base e come si inseriscono nella
architettura della posta elettronica illustrata in
sez.~\ref{sec:mail_structure}.

\else
\relax
%%
%% FINE: Sezione specifica da non includere in AGL
%%
\fi

\subsection{La posta elettronica sulla riga di comando}
\label{sec:mail_commands}

Come accennato in sez.~\ref{sec:mail_structure} la posta elettronica può
essere gestita anche soltanto localmente, il servizio infatti nasce ben prima
di Internet e della possibilità di collegare in rete fra loro dei computer,
come possibilità, presente sui sistemi multiutente come Unix, di mandarsi
messaggi fra utenti diversi della stessa macchina.

Esistono pertanto una serie di programmi che consentono di leggere ed inviare
posta dalla riga di comando, e la funzionalità di invio di messaggi di posta
viene utilizzata da vari demoni di sistema, come \texttt{cron}, quando è
necessario utilizzare una qualche forma di comunicazione asincrona con gli
utenti, non potendo avere la certezza che questi siano collegati e
contattabili direttamente.

Il programma deputato tradizionalmente alla lettura della posta elettronica è
\index{comando!\texttt{mail}} \texttt{mail}, che consente sia di leggere che
di inviare posta elettronica. In realtà del programma esistono diverse
versioni che replicano il comportamento del programma originale installato a
partire dalla versione 1 dello Unix della AT\&T, ed in genere su una
distribuzione Linux si trova installato o la versione di BSD (che può essere
invocato anche come \index{comando!\texttt{mailx}} \texttt{mailx}) o una
versione alternativa derivata anch'essa dal comando di BSD chiamata
\textit{Heirloom-mailx}. Purtroppo le due versioni differiscono nell'uso di
alcune opzioni più avanzate ed occorre tenere presente quale si sta usando,
per entrambe comunque si può invocare il comando sia come \texttt{mail} che
come \texttt{mailx}.

In generale il comando \texttt{mail} consente anche di leggere e scrivere la
posta interattivamente sul terminale ma l'interfaccia è molto spartana e poco
utilizzabile per cui per questo compito gli si preferiscono altri
programmi. Se invocato senza opzioni o argomenti legge la posta (locale)
dell'utente che lo avvia, ma si può richiedere la lettura della posta di un
altro utente (posto che si abbia la capacità di farlo) specificandolo come
argomento per l'opzione \texttt{-u}. Si può anche far leggere la posta da un
file in formato \textit{mbox} indicandone il pathname come argomento per
l'opzione \texttt{-f}. 

L'uso più comune del comando \texttt{mail} è però quello che lo vede
utilizzato per inviare messaggi di posta all'interno di script o
nell'invocazione di comandi sulla shell. La sintassi di base del comando
infatti è di leggere il testo del messaggio da inviare dallo \textit{standard
  input} prendendo l'indirizzo di posta del destinatario come argomento. Si
può poi impostare l'oggetto del messaggio come parametro per l'opzione
\texttt{-s}, ma si ricordi, se questo contiene degli spazi, di indicarlo
esplicitamente come stringa proteggendolo dalla interpretazione della
shell. Un esempio di uso del comando potrebbe essere allora:
\begin{Console}
piccardi@hain:~$ \textbf{echo prova | mail -s "Prova messaggio" piccardi@truelite.it}
\end{Console}
%$
che invierà il messaggio ``\texttt{prova}'' al destinatario indicato usando
come mittente l'utente corrente. 

Si tenga presente che in questo caso l'indirizzo di posta del mittente viene
costruito sulla base del nome utente di chi ha lanciato il comando, a cui
verrà aggiunto il nome a dominio della macchina, e non è detto che questo sia
un indirizzo valido al di là della macchina stessa.  Con
\texttt{heirloom-mailx} comunque si può usare l'opzione \texttt{-r} per
indicare esplicitamente l'indirizzo di posta da utilizzare come mittente.

Il comando consente poi di specificare eventuali indirizzi in copia (CC), con
una lista separata da virgole degli stessi passata come argomento dell'opzione
\texttt{-c}. Per inviare il messaggio in copia nascosta (BCC) bisognerà invece
passare la lista come argomento dell'opzione \texttt{-b}. Altre opzioni comuni
del comando sono \texttt{-E}, che evita l'invio di un messaggio vuoto, e
\texttt{-d} che fa stampare al comando una serie di informazioni di debug.

L'uso di ulteriori opzioni dipende dalla versione del comando che si sta
utilizzando, ad esempio per \texttt{bsd-mailx} l'opzione \texttt{-a} consente
di aggiungere intestazioni ad hoc per il messaggio che si invia, mentre con
\texttt{heirloom-mailx} viene usata per indicare un file da aggiungere come
allegato al messaggio che si invia. Per i dettagli si rimanda alla lettura
delle rispettive pagine di manuale.


%%
%% INIZIO: Sezione specifica da non includere in AGL
%%
\ifx\lpispecificsection\undefined


\subsection{Un MUA evoluto in console: \texttt{mutt}}
\label{sec:mutt_mua}


\subsection{\textit{Thunderbird} e la posta dall'interfaccia grafica}
\label{sec:gui_mua}


\else
\relax
%%
%% FINE: Sezione specifica da non includere in AGL
%%
\fi

% LocalWords:  news client snail sender MTA recipient agent transport fig LDA
% LocalWords:  local delivery cron ssmtp sez UUCP dial TCP SMTP spam mailbox
% LocalWords:  relay fetchmail RFC store and forward IMAP gateway telnet HELO
% LocalWords:  truelite EHLO it Postfix RSET envelope FROM RCPT TO tab AUTH
% LocalWords:  bounce mutt thunderbird BSD mailx mbox pathname shell sendmail
% LocalWords:  echo heirloom BCC debug bsd MUA mail Exim Qmail Courier simple
% LocalWords:  transfer protocol

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "mailserv"
%%% End: 
