Linux Professional Institute Learning Logo.
Torna al contenuto principale
  • Home
    • Tutte le Risorse
    • LPI Learning Materials
    • Collabora
    • Publishing Partner
    • Diventa un Publishing Partner
    • FAQ
    • Collaboratori
    • Contatto
  • LPI.org
108.3 Lezione 1
Argomento 105: Shell e Script di Shell
105.1 Personalizzare e utilizzare l'ambiente di shell
  • 105.1 Lezione 1
  • 105.1 Lezione 2
  • 105.1 Lezione 3
105.2 Personalizzare o scrivere semplici script
  • 105.2 Lezione 1
  • 105.2 Lezione 2
Argomento 106: Interfacce Utente e Desktop
106.1 Installare e configurare X11
  • 106.1 Lezione 1
106.2 Desktop grafici
  • 106.2 Lezione 1
106.3 Accessibilità
  • 106.3 Lezione 1
Argomento 107: Attività Amministrative
107.1 Gestire account utente e gruppo e file di sistema correlati
  • 107.1 Lezione 1
  • 107.1 Lezione 2
107.2 Automatizzare le attività di amministrazione del sistema attraverso la pianificazione
  • 107.2 Lezione 1
  • 107.2 Lezione 2
107.3 Localizzazione e internazionalizzazione
  • 107.3 Lezione 1
Argomento 108: Servizi Essenziali di Sistema
108.1 Mantenere l'orario di sistema
  • 108.1 Lezione 1
  • 108.1 Lezione 2
108.2 Logging di sistema
  • 108.2 Lezione 1
  • 108.2 Lezione 2
108.3 Concetti base dei Mail Transfer Agent (MTA)
  • 108.3 Lezione 1
108.4 Gestire stampa e stampanti
  • 108.4 Lezione 1
Argomento 109: Fondamenti di Networking
109.1 Fondamenti dei protocolli Internet
  • 109.1 Lezione 1
  • 109.1 Lezione 2
109.2 Configurazione di rete persistente
  • 109.2 Lezione 1
  • 109.2 Lezione 2
109.3 Risoluzione dei problemi di base di una rete
  • 109.3 Lezione 1
  • 109.3 Lezione 2
109.4 Configurare un client DNS
  • 109.4 Lezione 1
Argomento 110: Sicurezza
110.1 Eseguire attività di amministrazione della sicurezza
  • 110.1 Lezione 1
110.2 Configurare la sicurezza dell'host
  • 110.2 Lezione 1
110.3 Proteggere i dati con la crittografia
  • 110.3 Lezione 1
  • 110.3 Lezione 2
How to get certified
  1. Argomento 108: Servizi Essenziali di Sistema
  2. 108.3 Concetti base dei Mail Transfer Agent (MTA)
  3. 108.3 Lezione 1

108.3 Lezione 1

Certificazione:

LPIC-1

Versione:

5.0

Argomento:

108 Servizi Essenziali di Sistema

Obiettivo:

108.3 Concetti base dei Mail Transfer Agent

Lezione:

1 di 1

Introduzione

Nei sistemi operativi Unix-like, come Linux, ogni utente ha la propria inbox: una posizione speciale sul filesystem che è inaccessibile da altri utenti non root e che memorizza i messaggi personali dell’utente. I nuovi messaggi in arrivo vengono aggiunti alla casella di posta dell’utente dal Mail Transfer Agent (MTA). L’MTA è un programma in esecuzione come servizio di sistema che raccoglie i messaggi inviati da altri account locali così come i messaggi ricevuti dalla rete, inviati da utenti remoti.

Lo stesso MTA è anche responsabile dell’invio di messaggi alla rete, se l’indirizzo di destinazione si riferisce a un account remoto. Lo fa usando una locazione del filesystem come outbox di posta elettronica per tutti gli utenti del sistema: non appena un utente mette un nuovo messaggio nella outbox, l’MTA identificherà il nodo di rete di destinazione dal nome di dominio dato dall’indirizzo email di destinazione — la parte dopo il segno @ — e poi proverà a trasferire il messaggio all’MTA remoto usando il Simple Mail Transfer Protocol (SMTP). SMTP è stato progettato con reti inaffidabili in mente, quindi cercherà di stabilire percorsi di consegna alternativi se il nodo primario di destinazione della posta non è raggiungibile.

MTA Locale e Remoto

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.

Note

Al giorno d’oggi il metodo più comune per inviare e ricevere email è attraverso un account ospitato su un server remoto, per esempio il server email centralizzato di una società che ospita tutti gli account dei dipendenti o un servizio email personale, come Gmail di Google. Invece di raccogliere i messaggi consegnati localmente, l’applicazione client di posta elettronica si connette alla casella di posta remota e recupera i messaggi da lì. I protocolli POP3 e IMAP sono comunemente usati per recuperare i messaggi dal server remoto, ma possono essere usati anche altri protocolli proprietari non standard.

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:

  • Mantenere la coda di messaggi in uscita da inviare. Per ogni messaggio in coda, l’MTA locale valuterà l’MTA di destinazione dall’indirizzo del destinatario.

  • Comunicare con demoni MTA remoti usando SMTP. L’MTA locale dovrebbe essere in grado di usare il Simple Mail Transfer Protocol (SMTP) sullo stack TCP/IP per ricevere, inviare e reindirizzare messaggi da/a altri demoni MTA remoti.

  • Mantenere una casella di posta individuale per ogni account locale. L’MTA di solito memorizza i messaggi nel formato mbox: un singolo file di testo contenente tutti i messaggi di posta elettronica in sequenza.

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.

MTA in Linux

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

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

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.

Tip

A causa di problemi di sicurezza la maggior parte delle distribuzioni Linux non installa un MTA di default. Per testare gli esempi dati in questa lezione, assicurati che ci sia un MTA in funzione su ogni macchina e che accetti connessioni sulla porta TCP 25. Per motivi di sicurezza, questi sistemi non dovrebbero essere esposti a connessioni in entrata da Internet durante i test.

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:

$ nc lab2.campus 25
220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:16:07 GMT
HELO lab1.campus
250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you
MAIL FROM: emma@lab1.campus
250 2.1.0 emma@lab1.campus... Sender ok
RCPT TO: dave@lab2.campus
250 2.1.5 dave@lab2.campus... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: Recipient MTA Test

Hi Dave, this is a test for your MTA.
.
250 2.0.0 xAG0G7Y0000595 Message accepted for delivery
QUIT
221 2.0.0 lab2.campus closing connection

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:

$ cat /var/spool/mail/dave
From emma@lab1.campus  Sat Nov 16 00:19:13 2019
Return-Path: <emma@lab1.campus>
Received: from lab1.campus (lab1.campus [10.0.3.134])
	by lab2.campus (8.15.2/8.15.2) with SMTP id xAG0G7Y0000595
	for dave@lab2.campus; Sat, 16 Nov 2019 00:17:06 GMT
Date: Sat, 16 Nov 2019 00:16:07 GMT
From: emma@lab1.campus
Message-Id: <201911160017.xAG0G7Y0000595@lab2.campus>
Subject: Recipient MTA Test

Hi Dave, this is a test for your 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:

$ nc lab2.campus 25
220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:31:44 GMT
HELO lab1.campus
250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you
MAIL FROM: emma@lab1.campus
250 2.1.0 emma@lab1.campus... Sender ok
RCPT TO: henry@lab3.campus
550 5.7.1 henry@lab3.campus... Relaying denied

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:

$ sendmail dave@lab2.campus
From: emma@lab1.campus
To: dave@lab2.campus
Subject: Sender MTA Test

Hi Dave, this is a test for my MTA.
.

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:

# mailq
		/var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
xAIK3D9S000453       36 Mon Nov 18 20:03 <emma@lab1.campus>
                 (Deferred: Connection refused by lab2.campus.)
					 <dave@lab2.campus>
		Total requests: 1

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:

$ cat /var/spool/mail/dave
From emma@lab1.campus  Mon Nov 18 20:07:39 2019
Return-Path: <emma@lab1.campus>
Received: from lab1.campus (lab1.campus [10.0.3.134])
	by lab2.campus (8.15.2/8.15.2) with ESMTPS id xAIK7clC000432
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
	for <dave@lab2.campus>; Mon, 18 Nov 2019 20:07:38 GMT
Received: from lab1.campus (localhost [127.0.0.1])
	by lab1.campus (8.15.2/8.15.2) with ESMTPS id xAIK3D9S000453
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
	for <dave@lab2.campus>; Mon, 18 Nov 2019 20:03:13 GMT
Received: (from emma@localhost)
	by lab1.campus (8.15.2/8.15.2/Submit) id xAIK0doL000449
	for dave@lab2.campus; Mon, 18 Nov 2019 20:00:39 GMT
Date: Mon, 18 Nov 2019 20:00:39 GMT
Message-Id: <201911182000.xAIK0doL000449@lab1.campus>
From: emma@lab1.campus
To: dave@lab2.campus
Subject: Sender MTA Test

Hi Dave, this is a test for my MTA.

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.

Il Comando mail e i Mail User Agent (MUA)

È 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:

$ mail -s "Maintenance fail" henry@lab3.campus <<<"The maintenance script failed at `date`"

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.

Personalizzazione della Consegna

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 percorso completo (che inizia con /) a un file. I messaggi inviati all’alias corrispondente saranno aggiunti al file.

  • Un comando per elaborare il messaggio. La <destinazione> deve iniziare con un carattere pipe e, se il comando contiene caratteri speciali (come spazi vuoti), deve essere racchiuso tra doppi apici. Per esempio, l’alias subscribe: |subscribe.sh in lab2.campus inoltrerà tutti i messaggi inviati a subscribe@lab2.campus allo standard input del comando subscribe.sh. Se sendmail è in esecuzione in restricted shell mode, i comandi consentiti — o i collegamenti ad essi — dovrebbero essere in /etc/smrsh/.

  • Un file di inclusione. Un singolo alias può avere più destinazioni (separate da virgole), quindi può essere più pratico tenerle in un file esterno. La parola chiave :include: deve indicare il percorso del file, come in :include:/var/local/destinations.

  • Un indirizzo esterno. Gli alias possono anche inoltrare i messaggi a indirizzi e-mail esterni.

  • Un altro alias.

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:

$ cat ~/.forward
emma@lab1.campus

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.

Esercizi Guidati

  1. Senza ulteriori opzioni o argomenti, il comando mail henry@lab3.campus entra nella modalità di input in modo che l’utente possa digitare il messaggio a henry@lab3.campus. Dopo aver finito il messaggio, quale tasto chiuderà la modalità di input e invierà l’email?

  2. Quale comando può eseguire l’utente root per elencare i messaggi non consegnati che hanno avuto origine sul sistema locale?

  3. Come può un utente senza privilegi usare il metodo standard MTA per inoltrare automaticamente tutta la sua posta in arrivo all’indirizzo dave@lab2.campus?

Esercizi Esplorativi

  1. Usando il comando mail fornito da mailx, quale comando invierà un messaggio a emma@lab1.campus con il file logs.tar.gz come allegato e l’output del comando uname -a come corpo della mail?

  2. L’amministratore di un servizio di posta elettronica vuole monitorare i trasferimenti di e-mail attraverso la rete, ma non vuole riempire la sua casella di posta con messaggi di prova. Come potrebbe questo amministratore configurare un alias di posta elettronica a livello di sistema per reindirizzare tutte le e-mail inviate all’utente test al file /dev/null?

  3. Quale comando, oltre a newaliases, potrebbe essere usato per aggiornare il database degli alias dopo aver aggiunto un nuovo alias a /etc/aliases?

Sommario

Questa lezione tratta il ruolo e l’uso dei Mail Transfer Agent nei sistemi Linux. L’MTA fornisce un metodo standard per la comunicazione tra gli account utente e può essere combinato con altri software per fornire funzionalità extra. La lezione ha discusso i seguenti argomenti:

  • Concetti sulle tecnologie, caselle di posta e protocolli relativi alla posta elettronica.

  • Come gli MTA di Linux scambiano messaggi in rete.

  • I client di posta elettronica della console e i MUA (Mail User Agent).

  • Aliasing e inoltro delle email locali.

Le tecnologie, i comandi e le procedure affrontate sono state:

  • SMTP e protocolli correlati.

  • MTA disponibili per Linux: Sendmail, Postfix, qmail, Exim.

  • Comandi MTA e MUA: sendmail e mail.

  • File e comandi amministrativi: mailq, /etc/aliases, newaliases, ~/.forward.

Risposte agli Esercizi Guidati

  1. Senza ulteriori opzioni o argomenti, il comando mail henry@lab3.campus entra nella modalità di input in modo che l’utente possa digitare il messaggio a henry@lab3.campus. Dopo aver finito il messaggio, quale tasto chiuderà la modalità di input e invierà l’email?

    Premendo Ctrl+D il programma si chiuderà e invierà l’e-mail.

  2. Quale comando può eseguire l’utente root per elencare i messaggi non consegnati che hanno avuto origine sul sistema locale?

    Il comando mailq o sendmail -bp.

  3. Come può un utente senza privilegi usare il metodo standard MTA per inoltrare automaticamente tutta la sua posta in arrivo all’indirizzo dave@lab2.campus?

    L’utente dovrebbe aggiungere dave@lab2.campus al file ~/.forward.

Risposte agli Esercizi Esplorativi

  1. Usando il comando mail fornito da mailx, quale comando invierà un messaggio a emma@lab1.campus con il file logs.tar.gz come allegato e l’output del comando uname -a come corpo della mail?

    uname -a | mail -a logs.tar.gz emma@lab1.campus

  2. L’amministratore di un servizio di posta elettronica vuole monitorare i trasferimenti di e-mail attraverso la rete, ma non vuole riempire la sua casella di posta con messaggi di prova. Come potrebbe questo amministratore configurare un alias di posta elettronica a livello di sistema per reindirizzare tutte le e-mail inviate all’utente test al file /dev/null?

    La linea test: /dev/null all’interno di /etc/aliases reindirizzerà tutti i messaggi inviati alla casella di posta locale test al file /dev/null.

  3. Quale comando, oltre a newaliases, potrebbe essere usato per aggiornare il database degli alias dopo aver aggiunto un nuovo alias a /etc/aliases?

    Il comando sendmail -bi o sendmail -I.

Linux Professional Institute Inc. Tutti i diritti riservati. Visita il sito Learning Materials: https://learning.lpi.org
Quest'opera è sotto la licenza 'Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License'.

Prossima Lezione

108.4 Gestire stampa e stampanti (108.4 Lezione 1)

Leggi la prossima Lezione

Linux Professional Institute Inc. Tutti i diritti riservati. Visita il sito Learning Materials: https://learning.lpi.org
Quest'opera è sotto la licenza 'Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License'.

LPI è una organizzazione non-profit.

© 2023 Linux Professional Institute (LPI) è lo standard di certificazione globale e l'organizzazione di supporto alla carriera per i Professionisti Open Source. Con più di 200,000 titolari di Certificazione, è il primo e il più grande ente di Certificazione Open Source e Linux vendor-neutral. LPI ha professionisti certificati in oltre 180 Paesi, offre i suoi Esami in più lingue e ha centinaia di Partner di formazione in tutto il mondo.

La nostra missione è promuovere l'uso dell'Open Source supportando le persone che vi lavorano.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Contattaci
  • Privacy & Cookie Policy

Trovato un errore? Per favore scrivi a contattaci.

© 1999–2023 The Linux Professional Institute Inc. Tutti i diritti riservati.