108.3 Lezione 1

Gli account utente tradizionali nelle macchine collegate in rete costituiscono lo scenario di scambio di posta elettronica più semplice, dove ogni nodo della rete esegue il proprio demone MTA. Nessun altro software oltre all’MTA è richiesto per inviare e ricevere messaggi di posta elettronica. In pratica, tuttavia, è più comune usare un account di posta elettronica remoto e non avere un servizio MTA locale attivo (cioè usare invece un’applicazione client di posta elettronica per accedere all’account remoto).

A differenza degli account locali, un account di posta elettronica remoto — chiamato anche remote mailbox — richiede l’autenticazione dell’utente per garantire l’accesso alla casella di posta dell’utente e all’MTA remoto (in questo caso, chiamato semplicemente SMTP server). Mentre l’utente che interagisce con una casella di posta e un MTA locali è già identificato dal sistema, un sistema remoto deve verificare l’identità dell’utente prima di gestire i suoi messaggi attraverso IMAP o POP3.

Quando un demone MTA è in esecuzione sul sistema locale, gli utenti locali possono inviare un’email ad altri utenti locali o a utenti su una macchina remota, a condizione che il loro sistema abbia anche un servizio MTA che accetti connessioni di rete. La porta TCP 25 è la porta standard per la comunicazione SMTP, ma possono essere usate anche altre porte, a seconda dello schema di autenticazione e/o crittografia utilizzato (se presenti).

Lasciando da parte i metodi che coinvolgono l’accesso a caselle di posta remote, una rete di scambio di e-mail tra normali account utente Linux può essere implementata a condizione che tutti i nodi della rete abbiano un MTA attivo che sia in grado di eseguire i seguenti compiti:

Normalmente, gli indirizzi email specificano un nome di dominio come luogo, per esempio lpi.org in info@lpi.org. Quando questo è il caso, l’MTA del mittente interrogherà il servizio DNS per il corrispondente record MX. Il record DNS MX contiene l’indirizzo IP dell’MTA che gestisce l’email per quel dominio. Se lo stesso dominio ha più di un record MX specificato nel DNS, l’MTA dovrebbe provare a contattarli secondo i loro valori di priorità. Se l’indirizzo del destinatario non specifica un nome di dominio o il dominio non ha un record MX, allora la parte dopo il simbolo @ sarà trattata come l’host dell’MTA di destinazione.

Gli aspetti di sicurezza devono essere considerati se gli host MTA saranno visibili agli host su Internet. Per esempio, è possibile per un utente sconosciuto usare l’MTA locale per impersonare un altro utente e inviare email potenzialmente dannose. Un MTA che inoltra ciecamente un’email è conosciuto come un open relay, quando può essere usato come intermediario per mascherare potenzialmente il vero mittente del messaggio. Per prevenire questi abusi, la raccomandazione è di accettare connessioni solo da domini autorizzati e di implementare uno schema di autenticazione sicuro.

Inoltre, ci sono molte diverse implementazioni di MTA per Linux, ognuna delle quali si concentra su aspetti specifici come compatibilità, prestazioni, sicurezza, ecc. Tuttavia, tutti gli MTA seguono gli stessi principi di base e forniscono caratteristiche simili.

Il tradizionale MTA disponibile per i sistemi Linux è Sendmail, un MTA molto flessibile e di uso generale usato da molti sistemi operativi Unix-like. Alcuni degli altri MTA comuni sono Postfix, qmail e Exim. La ragione principale per scegliere un MTA alternativo è quella di implementare funzionalità avanzate più facilmente, poiché configurare server di posta elettronica personalizzati in Sendmail può essere un compito complicato. Inoltre, ogni distribuzione può avere il suo MTA preferito, con impostazioni predefinite appropriate per le configurazioni più comuni. Tutti gli MTA sono intesi come sostituti di Sendmail, quindi tutte le applicazioni compatibili con Sendmail dovrebbero poter funzionare indipendentemente dall’MTA utilizzato.

Se l’MTA è in funzione ma non accetta connessioni di rete, sarà in grado di consegnare i messaggi email solo sulla macchina locale. Per l’MTA sendmail, il file /etc/mail/sendmail.mc dovrebbe essere modificato per accettare connessioni non locali. Per farlo, la voce

dovrebbe essere modificata con l’indirizzo di rete corretto e il servizio dovrebbe essere riavviato. Alcune distribuzioni Linux, come Debian, possono offrire strumenti di configurazione per aiutare a portare il server di posta elettronica con un set predefinito di funzioni comunemente usate.

Una volta che l’MTA è in funzione e accetta connessioni dalla rete, i nuovi messaggi email gli vengono passati con comandi SMTP che vengono inviati attraverso una connessione TCP. Il comando nc — un’utilità di rete che legge e scrive dati generici attraverso la rete — può essere usato per inviare comandi SMTP direttamente all’MTA. Se il comando nc non è disponibile, sarà installato con il pacchetto ncat o nmap-ncat, a seconda del sistema di gestione dei pacchetti in uso. Scrivere comandi SMTP direttamente all’MTA ti aiuterà a capire meglio il protocollo e altri concetti generali di posta elettronica, ma può anche aiutare a diagnosticare problemi nel processo di consegna della posta.

Se per esempio l’utente emma sull’host lab1.campus vuole inviare un messaggio all’utente dave sull’host lab2.campus, allora può usare il comando nc per connettersi direttamente all’MTA lab2.campus, assumendo che sia in ascolto sulla porta TCP 25:

Una volta stabilita la connessione, l’MTA remoto si identifica e poi è pronto a ricevere i comandi SMTP. Il primo comando SMTP nell’esempio, HELO lab1.campus, indica lab1.campus come iniziatore dello scambio. I prossimi due comandi, MAIL FROM: emma@lab1.campus e RCPT TO: dave@lab2.campus, indicano il mittente e il destinatario. Il messaggio email vero e proprio inizia dopo il comando DATA e finisce con un punto su una linea a sé. Per aggiungere un campo subject all’email, dovrebbe essere nella prima riga dopo il comando DATA, come mostrato nell’esempio. Quando il campo oggetto è usato, ci deve essere una linea vuota che lo separa dal contenuto dell’email. Il comando QUIT termina la connessione con l’MTA sull’host lab2.campus.

Sull’host lab2.campus, l’utente dave riceverà un messaggio simile a You have new mail in /var/spool/mail/dave non appena entri in una sessione di shell. Questo file conterrà il messaggio email grezzo inviato da emma e le intestazioni aggiunte dall’MTA:

L’intestazione Received: mostra che il messaggio da lab1.campus è stato ricevuto direttamente da lab2.campus. Per impostazione predefinita, gli MTA accettano solo messaggi a destinatari locali. Il seguente errore si verificherà probabilmente se l’utente emma cerca di inviare un’email all’utente henry sull’host lab3.campus, ma usando l’MTA di lab2.campus invece dell’MTA corretto di lab3.campus:

I codici di risposta SMTP che iniziano con 5, come il messaggio Relaying denied, indicano un errore. Ci sono situazioni legittime in cui il relaying è desiderabile, come quando gli host che inviano e ricevono email non sono sempre connessi: un MTA intermedio può essere configurato per accettare email destinate ad altri host, agendo come un server SMTP relay che può inoltrare messaggi tra gli MTA.

La capacità di instradare il traffico e-mail attraverso server SMTP intermedi scoraggia il tentativo di connettersi direttamente all’host indicato dall’indirizzo e-mail del destinatario, come mostrato negli esempi precedenti. Inoltre, gli indirizzi email spesso hanno un nome di dominio come posizione (dopo la @), quindi il nome effettivo dell’host MTA corrispondente deve essere recuperato tramite DNS. Pertanto, si raccomanda di delegare il compito di identificare l’host di destinazione appropriato all’MTA locale o al server SMTP remoto, quando si usano caselle di posta remote.

Sendmail fornisce il comando sendmail per eseguire molte operazioni relative alla posta elettronica, inclusa l’assistenza nella composizione di nuovi messaggi. Richiede anche all’utente di digitare a mano le intestazioni delle email, ma in un modo più amichevole rispetto all’usare direttamente i comandi SMTP. Quindi un metodo più adeguato per l’utente emma@lab1.campus per inviare un messaggio email a dave@lab2.campus sarebbe:

Anche qui, il punto in una riga, da solo, termina il messaggio. Il messaggio dovrebbe essere immediatamente inviato al destinatario, a meno che l’MTA locale non sia stato in grado di contattare l’MTA remoto. Il comando mailq, se eseguito da root, mostrerà tutti i messaggi non consegnati. Se per esempio l’MTA a lab2.campus non ha risposto, allora il comando mailq elencherà il messaggio non consegnato e la causa del fallimento:

La posizione predefinita per la coda di posta in uscita è /var/spool/mqueue/, ma diversi MTA possono usare diverse posizioni nella directory /var/spool/. Postfix, per esempio, creerà un albero di directory sotto /var/spool/postfix/ per gestire la coda. Il comando mailq è equivalente a sendmail -bp, e dovrebbero essere presenti indipendentemente dall’MTA installato nel sistema. Per assicurare la retrocompatibilità, la maggior parte degli MTA fornisce questi tradizionali comandi di amministrazione della posta.

Se l’host primario di destinazione dell’email — quando è fornito da un record DNS MX per il dominio — non è raggiungibile, l’MTA proverà a contattare le voci con priorità inferiore (se ce ne sono specificate). Se nessuna di esse è raggiungibile, il messaggio rimarrà nella coda di posta in uscita locale per essere inviato in seguito. Se configurato per farlo, l’MTA può controllare periodicamente la disponibilità degli host remoti ed eseguire un nuovo tentativo di consegna. Se si usa un MTA compatibile con Sendmail, un nuovo tentativo avrà luogo immediatamente con il comando sendmail -q.

Sendmail memorizzerà i messaggi in arrivo in un file chiamato come il proprietario della casella di posta corrispondente, per esempio /var/spool/mail/dave. Altri MTA, come Postfix, possono memorizzare i messaggi in arrivo in posizioni come /var/mail/dave, ma il contenuto del file è lo stesso. Nell’esempio, il comando sendmail è stato usato nell’host del mittente per comporre il messaggio, quindi le intestazioni grezze del messaggio mostrano che l’email ha fatto dei passi in più prima di raggiungere la destinazione finale:

Dal basso verso l’alto, le linee che iniziano con Received: mostrano il percorso del messaggio. Il messaggio è stato inviato dall’utente emma con il comando sendmail dave@lab2.campus emesso su lab1.campus, come indicato dal primo header Received:. Poi, sempre su lab1.campus, l’MTA usa ESMTPS — un superset dell’SMTP, che aggiunge estensioni di crittografia — per inviare il messaggio all’MTA su lab2.campus, come indicato dall’ultimo (in alto) header Received:

L’MTA finisce il suo lavoro dopo che il messaggio viene salvato nella casella di posta dell’utente. È comune eseguire qualche tipo di filtraggio delle e-mail, come il blocco dello spam o l’applicazione di regole di filtraggio definite dall’utente. Questi compiti sono eseguiti da applicazioni di terze parti che lavorano insieme all’MTA. L’MTA potrebbe per esempio chiamare l’utilità SpamAssassin per contrassegnare i messaggi sospetti usando le sue caratteristiche di analisi del testo.

Anche se possibile, non è conveniente leggere direttamente il file della casella di posta. Si raccomanda invece di utilizzare un programma client di posta elettronica (per esempio Thunderbird, Evolution o KMail), che analizzerà il file e gestirà in modo appropriato i messaggi. Tali programmi offrono anche caratteristiche extra, come scorciatoie per azioni comuni, sottocartelle della posta in arrivo, ecc.

È possibile scrivere un messaggio di posta elettronica direttamente nel suo formato grezzo, ma è molto più pratico usare un’applicazione client — conosciuta anche come MUA (Mail User Agent) — per velocizzare il processo ed evitare errori. Il MUA si occupa del lavoro "sotto il cofano", cioè, il client di posta elettronica presenta e organizza i messaggi ricevuti e gestisce la corretta comunicazione con l’MTA dopo che l’utente ha composto un’email.

Ci sono molti tipi distinti di Mail User Agent. Applicazioni desktop come Mozilla Thunderbird e Evolution di Gnome supportano sia account email locali sia remoti. Anche le interfacce Webmail possono essere viste come un tipo di MUA, in quanto fanno da intermediari tra l’utente e il sottostante MTA. I client di posta elettronica non sono limitati alle interfacce grafiche: i client di posta elettronica per console sono ampiamente utilizzati per accedere alle caselle di posta non integrate con un’interfaccia grafica e per automatizzare i compiti relativi alla posta elettronica all’interno di script di shell.

Originariamente, il comando Unix mail era inteso solo per condividere messaggi tra utenti del sistema locale (il primo comando mail risale alla prima edizione di Unix, rilasciata nel 1971). Quando gli scambi di email in rete divennero più importanti, altri programmi furono creati per gestire il nuovo sistema di consegna e gradualmente sostituirono il vecchio programma mail.

Al giorno d’oggi, il comando mail più comunemente usato è fornito dal pacchetto mailx, che è compatibile con tutte le moderne funzionalità di posta elettronica. Nella maggior parte delle distribuzioni Linux, il comando mail è solo un collegamento simbolico al comando mailx. Altre implementazioni, come il pacchetto GNU Mailutils, forniscono fondamentalmente le stesse caratteristiche di mailx. Ci sono, tuttavia, leggere differenze tra loro, specialmente per quanto riguarda le opzioni della riga di comando.

Indipendentemente dalla loro implementazione, tutte le varianti moderne del comando mail operano in due modalità: modalità normale e modalità di invio. Se viene fornito un indirizzo email come argomento al comando mail, esso entrerà in modalità di invio, altrimenti entrerà in modalità normale (lettura). In questa ultima modalità, i messaggi ricevuti sono elencati con un indice numerico, così l’utente può fare riferimento a essi individualmente quando digita comandi nel prompt interattivo. Per esempio il comando print 1 può essere usato per visualizzare il contenuto del messaggio numero 1. I comandi interattivi possono essere abbreviati, così comandi come print, delete o reply possono essere sostituiti rispettivamente da p, d o r. Il comando mail considererà sempre l’ultimo messaggio ricevuto o l’ultimo visualizzato quando il numero di indice del messaggio è omesso. Il comando quit o q terminerà il programma.

La modalità invio è particolarmente utile per inviare messaggi email automatici. Può essere usata per esempio per inviare un’email all’amministratore di sistema se uno script di manutenzione programmata non riesce ad eseguire il suo compito. In modalità invio, mail userà il contenuto dello standard input come corpo del messaggio:

In questo esempio l’opzione -s è stata aggiunta per includere un campo subject al messaggio. Il corpo del messaggio è stato fornito dal reindirizzamento di Hereline allo standard input, ma il contenuto di un file o l’output di un comando potrebbe anche essere convogliato nell'stdin del programma. Se nessun contenuto è fornito da un reindirizzamento allo standard input, allora il programma aspetterà che l’utente inserisca il corpo del messaggio. In questo caso, la pressione del tasto Ctrl+D terminerà il messaggio. Il comando mail uscirà immediatamente dopo che il messaggio sarà stato aggiunto alla coda di uscita.

Per impostazione predefinita, gli account di posta elettronica su un sistema Linux sono associati agli account di sistema standard. Per esempio, se l’utente Carol ha il nome di login carol sull’host lab2.campus, allora il suo indirizzo email sarà carol@lab2.campus. Questa associazione uno-a-uno tra account di sistema e caselle di posta può essere estesa con metodi standard forniti dalla maggior parte delle distribuzioni Linux, in particolare il meccanismo di routing delle email fornito dal file /etc/aliases.

Un alias di posta elettronica è un destinatario di posta elettronica "virtuale" i cui messaggi in ricezione sono reindirizzati a caselle di posta locali esistenti o ad altri tipi di destinazioni di archiviazione o elaborazione dei messaggi. Gli alias sono utili per esempio per mettere i messaggi inviati a postmaster@lab2.campus nella mailbox di Carol, che è una normale mailbox locale nel sistema lab2.campus. Per fare ciò, la linea postmaster: carol dovrebbe essere aggiunta al file /etc/aliases in lab2.campus. Dopo aver modificato il file /etc/aliases, il comando newaliases dovrebbe essere eseguito per aggiornare il database degli alias del MTA e rendere effettive le modifiche. I comandi sendmail -bi o sendmail -I possono anche essere usati per aggiornare il database degli alias.

Gli alias sono definiti uno per riga, nel formato <alias>: <destinazione>. Oltre alle normali caselle di posta locali, indicate dal nome utente corrispondente, sono disponibili altri tipi di destinazione:

Un utente locale senza privilegi può definire degli alias per la propria posta elettronica modificando il file .forward nella sua directory principale. Poiché gli alias possono influenzare solo la propria casella di posta, è necessaria solo la parte <destination>. Per inoltrare tutte le email in arrivo ad un indirizzo esterno, per esempio, l’utente dave in lab2.campus potrebbe creare il seguente file ~/.forward:

Inoltrerà tutti i messaggi email inviati a dave@lab2.campus a emma@lab1.campus. Come per il file /etc/aliases, altre regole di reindirizzamento possono essere aggiunte a .forward, una per riga. Tuttavia, il file .forward deve essere scrivibile solo dal suo proprietario e non è necessario eseguire il comando newaliases dopo averlo modificato. I file che iniziano con un punto non appaiono nei normali elenchi di file, il che potrebbe rendere l’utente ignaro degli alias attivi. Pertanto, è importante verificare se il file esiste quando si diagnosticano problemi di consegna delle email.