Introduzione

Questa guida illustra come installare e configurare un server mail completo su Ubuntu 22.04 LTS e versioni successive. L'obiettivo è fornire una base solida per la gestione della posta elettronica, includendo la ricezione, l'invio, l'accesso tramite client e webmail, e la protezione da spam e virus.

Pianificazione

Prima di iniziare, è fondamentale una corretta pianificazione:

• Nome Dominio: È necessario possedere un nome dominio (es. example.com) e avere accesso alla sua configurazione DNS.

• Record DNS: Saranno necessari almeno i seguenti record DNS:

  • Un record A per il server mail (es. mail.example.com che punta all'IP pubblico del server).

  • Un record MX per il dominio (es. example.com MX 10 mail.example.com) che indica quale server gestisce la posta per quel dominio.

  • Un record PTR (reverse DNS) per l'IP pubblico del server, che risolva al nome host del server mail (es. mail.example.com). Questo è cruciale per la reputazione e per evitare che le mail vengano respinte come spam.

  • È fortemente consigliato configurare anche SPF, DKIM e DMARC per migliorare la deliverability e combattere lo spoofing. Questi argomenti, data la loro complessità, potrebbero essere trattati in guide separate o in sezioni avanzate.

• Partizionamento del Disco (Consigliato): Se possibile, dedicare partizioni separate può migliorare la gestione e la resilienza:

  • /var/log: Per i file di log.

  • /var/spool/postfix: Dove Postfix gestisce le code di posta.

  • /var/mail o /var/vmail (a seconda della configurazione): Dove vengono memorizzate le caselle di posta degli utenti.

• Risorse del Server: Un server mail, specialmente se con filtri antispam/antivirus, può richiedere una quantità significativa di RAM e CPU, a seconda del volume di posta gestito.

• Sicurezza: Il server dovrà essere accessibile da Internet sulle porte standard (25, 143, 587, 993, ecc.). È cruciale configurare un firewall (es. ufw) e mantenere il sistema aggiornato.

Componenti Coinvolti

La gestione della posta elettronica in rete coinvolge diversi componenti software che lavoreranno in sinergia:

• Un Client di Posta (MUA - Mail User Agent): Il programma utilizzato dagli utenti per leggere, scrivere e inviare messaggi (es. Thunderbird, Outlook, K-9 Mail, o la webmail).

• Un Mail Transfer Agent (MTA): Il cuore del sistema, responsabile della ricezione della posta da altri server (tramite SMTP), dell'instradamento e dell'invio della posta ai server destinatari. In questa guida utilizzeremo Postfix.

• Un Mail Delivery Agent (MDA) / Submission Agent:

  • MDA (Local Delivery Agent): Si occupa della consegna finale dei messaggi nelle caselle di posta locali. Spesso è integrato in Postfix o gestito da Dovecot.

  • Submission Agent: Gestisce l'invio di posta da parte dei client autenticati, tipicamente sulla porta 587 (SMTP Submission). Postfix gestirà anche questo ruolo.

  • Un Server IMAP/POP3 (DA - Delivery Agent): Permette ai client di posta di accedere e scaricare i messaggi dalle caselle di posta. Si utilizzerà Dovecot, che fornisce supporto per i protocolli IMAP (consigliato, mantiene la posta sul server) e POP3 (scarica la posta sul client).

• Filtri Antispam e Antivirus: Software per analizzare le email in transito, identificare e bloccare spam e malware. Si utilizzerà SpamAssassin (per l'antispam) e ClamAV (per l'antivirus), orchestrati da Amavisd-new.

• Webmail: Un'interfaccia web che permette agli utenti di accedere alla propria posta tramite un browser. Si utilizzerà Roundcube.

Il meccanismo di instradamento della posta si basa sull'associazione tra il dominio di posta elettronica (la parte dopo la @ nell'indirizzo email) e i record DNS del dominio. L'MTA interroga i server DNS per trovare il server MX (Mail eXchanger) del dominio destinatario e consegnare il messaggio.

Autenticazione Utenti

In questa guida, la configurazione principale si concentrerà sull'utilizzo di utenti di sistema locali UNIX (quelli creati con adduser o useradd) per l'autenticazione. L'integrazione con backend di autenticazione esterni come LDAP o database SQL è possibile con Postfix e Dovecot, ma esula dallo scopo principale di questa guida di base e richiederebbe configurazioni aggiuntive.

Installazione

Prima di procedere con l'installazione dei pacchetti, è consigliabile Aggiornare la lista dei pacchetti.

Mail Transfer Agent (Postfix)

Iniziamo installando il Mail Transfer Agent (Postfix) e il server IMAP/POP3 (Dovecot).

1. Installare i seguenti pacchetti, digitando nel terminale:

   sudo apt install postfix postfix-doc dovecot-core dovecot-imapd dovecot-pop3d dovecot-lmtpd

Installazione Filtri Antispam e Antivirus

Ora installare i software per la protezione da spam e virus: SpamAssassin, ClamAV e Amavisd-new (che li orchestra).

Installare i pacchetti, digitare nel terminale il seguente comando:

sudo apt install amavisd-new spamassassin spamc pyzor razor dcc-client clamav-daemon clamav-freshclam libclamunrar9 libdbi-perl libdbd-mysql-perl libberkeleydb-perl

Installazione Web Server e PHP

Per la webmail (Roundcube), è necessario un web server e PHP. In questa guida si utilizzerà Apache2. Installare i pacchetti, digitare nel terminale il seguente comando:

sudo apt install apache2 libapache2-mod-php php php-cli php-common php-gd php-curl php-intl php-mbstring php-mysql php-pear php-xml php-zip

Installazione Database e Webmail

Roundcube necessita di un database per memorizzare le sue impostazioni e i dati degli utenti (come la rubrica). Installare 'MariaDB (un fork di MySQL) e Roundcube.

MariaDB

1. Se non si dispone già di un server MariaDB/MySQL, digitare nel terminale il seguente comando:

   sudo apt install mariadb-server mariadb-client

2. Dopo l'installazione, è fortemente consigliato mettere in sicurezza l'installazione di MariaDB, digitare nel terminale il seguente comando:

   sudo mysql_secure_installation

   seguire le istruzioni a schermo.

3. Creare un database e un utente specifici per Roundcube, operazione che si vedrà nella sezione dedicata alla configurazione della webmail.

Roundcube

Ora installare Roundcube, digitare nel terminale il seguente comando:

sudo apt install roundcube roundcube-core roundcube-mysql roundcube-plugins

Utility di Test

Infine, installare una semplice utility da riga di comando per testare l'invio di email, digitando il comando:

sudo apt install bsd-mailx

Al termine di questi passaggi, tutti i componenti software necessari dovrebbero essere installati. Le prossime sezioni guideranno attraverso la configurazione di ciascun componente.

Mail Transfer Agent

Postfix è il Mail Transfer Agent (MTA) che si occuperà di ricevere, inoltrare e consegnare le email. La sua configurazione principale si trova nella directory /etc/postfix/, e il file più importante è main.cf. Un altro file utile è /etc/aliases per la gestione degli alias di posta.

File /etc/aliases

Il file /etc/aliases permette di definire alias per gli indirizzi email. Ad esempio, si può reindirizzare la posta destinata a postmaster@example.com o root@example.com a un utente di sistema reale.

Esempio di contenuto per /etc/aliases:

• Alias di sistema fondamentali (solitamente già presenti):

  mailer-daemon: postmaster
  postmaster: root
  nobody: root
  hostmaster: root
  usenet: root
  news: root
  webmaster: root
  www: root
  ftp: root
  abuse: root

• Alias personalizzati:

  • La posta per 'info@example.com' viene consegnata all'utente di sistema 'utentealpha'

      info: utentealpha

  • La posta per 'supporto@example.com' viene consegnata agli utenti 'utentebeta' e 'utentegamma'

      supporto: utentebeta, utentegamma

  • La posta per 'root' viene inoltrata anche a un indirizzo email esterno (sconsigliato per root senza cautela)

      root: utentesistema, admin@altroprovider.com

Questo comando legge il file /etc/aliases e crea/aggiorna il file aliases.db che Postfix utilizza effettivamente.

File /etc/postfix/main.cf

Questo è il file di configurazione principale di Postfix. Aprire il file con i privilegi di amministrazione e un editor di testo (es. nano):

sudo nano /etc/postfix/main.cf

Di seguito sono riportate le direttive fondamentali e alcune raccomandazioni. Molte di queste potrebbero essere già presenti o impostate correttamente dalla fase di installazione (Sito Internet). Verificare e adattare secondo le proprie necessità, sostituendo example.com con il proprio dominio e mail.example.com con il Fully Qualified Domain Name (FQDN) del proprio server mail.

Impostazioni Generali

# Messaggio di benvenuto (banner) SMTP. È buona norma non rivelare la versione di Postfix.
smtpd_banner = $myhostname ESMTP

# Nome host completo del server (FQDN)
myhostname = mail.example.com

# Dominio di posta principale
mydomain = example.com

# Dominio da cui sembrano provenire le email inviate localmente senza un dominio specificato.
# Usare $mydomain è una scelta comune.
myorigin = $mydomain

# Domini per cui questo server accetta posta (destinazioni locali).
# Assicurarsi che il proprio dominio, il nome host e localhost siano inclusi.
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# Reti considerate "locali" o fidate. Postfix permetterà il relay da queste reti.
# Includere la rete locale se i client inviano posta tramite questo server senza autenticazione SMTP
# (non raccomandato per connessioni esterne). Per un server esposto su Internet,
# l'autenticazione SMTP (SASL) è il metodo preferito per permettere il relay.
# Esempio: mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.1.0/24
# Per una configurazione iniziale sicura, limitarsi a localhost:
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

# Interfacce di rete su cui Postfix deve ascoltare per le connessioni in entrata.
# 'all' per ascoltare su tutte le interfacce disponibili.
inet_interfaces = all
# Se si vuole ascoltare solo su IPv4 (e non IPv6), si può usare:
# inet_protocols = ipv4
# Per default, Postfix usa 'all' (IPv4 e IPv6 se disponibili).
inet_protocols = all

# Mappa degli alias.
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

# Limite sulla dimensione dei messaggi (in byte). 0 per illimitato (non consigliato).
# Esempio per 50MB:
message_size_limit = 52428800

# Limite sulla dimensione della casella di posta (mailbox_size_limit).
# Se si usa Dovecot per la consegna locale e le quote, questa impostazione di Postfix
# potrebbe essere meno rilevante o gestita da Dovecot. 0 per illimitato.
mailbox_size_limit = 0

# Percorso per la consegna locale (mailbox). Dovecot gestirà la consegna effettiva.
# Questo sarà spesso sovrascritto/gestito dalla configurazione di Dovecot (es. tramite LMTP o LDA).
# Per ora, commentare o assicurarsi che non sia in conflitto con Dovecot.
# home_mailbox = Maildir/

Restrizioni SMTP (Anti-Spam e Sicurezza di Base)

Queste restrizioni aiutano a prevenire abusi e a ridurre lo spam. L'ordine è importante.

# Restrizioni per il client che si connette (fase CONNECT)
smtpd_client_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination  # Fondamentale per prevenire open relay
    # Aggiungere qui RBLs (Real-time Blackhole Lists) se desiderato, es:
    # reject_rbl_client zen.spamhaus.org
    # reject_rbl_client b.barracudacentral.org

# Restrizioni sul comando HELO/EHLO
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_invalid_helo_hostname
    reject_non_fqdn_helo_hostname
    reject_unknown_helo_hostname # Può essere troppo restrittivo, valutare
    # check_helo_access hash:/etc/postfix/helo_access # Per blocchi specifici

# Restrizioni sul mittente (MAIL FROM)
smtpd_sender_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_non_fqdn_sender
    reject_unknown_sender_domain
    # check_sender_access hash:/etc/postfix/sender_access # Per blocchi specifici

# Restrizioni sul destinatario (RCPT TO)
# reject_unauth_destination è la più importante qui per evitare open relay,
# ma è già in smtpd_client_restrictions o smtpd_relay_restrictions.
# Molte altre restrizioni sul destinatario sono spesso meglio gestite in smtpd_relay_restrictions.
smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    # Aggiungere altre restrizioni se necessario, come:
    # reject_non_fqdn_recipient
    # reject_unknown_recipient_domain
    # check_recipient_access hash:/etc/postfix/recipient_access # Per blocchi specifici

# Restrizioni sul relay (più specifico per decidere se inoltrare la posta)
# Questa è una direttiva cruciale.
smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

# Limita il numero di destinatari per messaggio.
smtpd_recipient_limit = 100

# Forza TLS per i client che si autenticano (Submission)
# Questa configurazione sarà dettagliata nella sezione Sicurezza.
# Per ora, assicurarsi che non ci siano direttive in conflitto.

Configurazione per l'integrazione con Amavis (Antispam/Antivirus)

Questa parte sarà fondamentale per passare le email attraverso Amavisd-new per la scansione. Verrà solitamente configurato un content_filter che instrada le email ad Amavis su una porta specifica (es. 10024) e Amavis le re-inietta in Postfix su un'altra porta (es. 10025) dopo la scansione.

# Integrazione con Amavisd-new (dopo che Amavis è stato configurato)
# Questa configurazione verrà attivata/dettagliata nella sezione dedicata ad Amavis.
# Per ora, si può lasciare commentata o prepararla.
# content_filter = smtp-amavis:[127.0.0.1]:10024

Configurazione per l'autenticazione SMTP (SASL) con Dovecot

Per permettere ai client di posta di inviare email attraverso il server, è necessaria l'autenticazione SMTP. Configurar Postfix per usare Dovecot SASL.

Questa parte sarà dettagliata nella sezione sulla sicurezza e l'autenticazione.

# Impostazioni per SASL (verranno dettagliate in seguito)
# smtpd_sasl_type = dovecot
# smtpd_sasl_path = private/auth
# smtpd_sasl_auth_enable = yes
# broken_sasl_auth_clients = yes # Per compatibilità con client più vecchi
# smtpd_sasl_security_options = noanonymous
# smtpd_sasl_local_domain = $myhostname

Salvare il file main.cf dopo le modifiche.

Verifica della configurazione e avvio/riavvio di Postfix

Dopo aver modificato main.cf, è buona norma verificare la presenza di errori di sintassi, digitare nel terminale il seguente comando:

sudo postfix check

Se non vengono mostrati errori, è possibile applicare le modifiche ricaricando o riavviando Postfix. Per applicare le modifiche a un Postfix già in esecuzione, digitare nel terminale il seguente comando:

sudo systemctl reload postfix

Per avviare Postfix se non è in esecuzione, o per un riavvio completo:

sudo systemctl restart postfix

Per verificare lo stato del servizio Postfix:

sudo systemctl status postfix

E per abilitare l'avvio automatico di Postfix al boot del sistema:

sudo systemctl enable postfix

I log di Postfix si trovano principalmente in /var/log/mail.log. Controllare questo file per messaggi di errore o informazioni sul flusso della posta:

sudo tail -f /var/log/mail.log

Ulteriori considerazioni sulla sicurezza (HELO/EHLO)

La sezione smtpd_helo_restrictions già proposta copre questi aspetti. È importante che sia impostato:

smtpd_helo_required = yes
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname

questa può essere una restrizione forte e potrebbe bloccare server legittimi ma mal configurati. Valutare con cautela e monitorare i log.Le restrizioni smtpd_client_restrictions, smtpd_helo_restrictions, smtpd_sender_restrictions, e smtpd_recipient_restrictions (o smtpd_relay_restrictions) lavorano insieme per proteggere il server.

File /etc/postfix/ldap-aliases.cf

È il corrispondente file di configurazione per i servizi LDAP e contiene le seguenti direttive:

server_host = nome completo del server LDAP

search_base = dc=miodominio,dc=com

dove ovviamente è necessario sostituire miodominio e com con il proprio basedn del dominio di ricerca LDAP.

Avvio di postfix

Ora può essere il servizio postfix del MTA con il comando:

/etc/init.d/postfix start 

Tutti i log files inerenti lo startup dei servizi postfix ed i relativi accessi sono contenuti nei files /var/log/mail.warn, /var/log/mail.err, /var/log/mail.info.

Ulteriore livello sicurezza

Par aggiungere un maggiore livello sicurezza, un'ulteriore direttiva da utilizzare nel file main.cf per limitare lo spam è la direttiva:

• smtp_helo_restrictions = reject_invalid_hostname , reject_non_fqdn_hostname , reject_unknown_hostname , permit_nak*ed_ip_address , permit

Questa restrizione opera nel modo seguente :

• rifiuta l'accesso al servizio per client che non rispondono al messaggio di benvenuto del server Postfix con un nome host valido (gli spammers lo fanno spesso per risparmiare tempo);
• rifiuta l'accesso al servizio MTA se il nome host passato di seguito al comando helo non è un fqdn hostname (cioè della forma mail.example.com);

• rifiuta l'accesso al servizio MTA se l'hostname che segue il comando helo non può essere risolto (questo capita quando lo spammer mette di seguito al comando helo una stringa casuale, allora l'MTA interroga un DNS per risolvere il nome host immesso, se non lo trova rifiuta l'accesso);

• consente l'accesso se di seguito al comando helo viene concatenato un IP.

La direttiva permit in fondo alla stringa, dice che al di fuori delle restrizioni applicate tutto il resto viene accettato.

DA

Per la configurazione del DA (delivery agent) si proceda come segue:

1. Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/dovecot/dovecot.conf.

2. Impostare il parametro protocols come segue:

   protocols = pop3 pop3s imap imaps

   questo abiliterà i servizi pop3(s) e imap(s) alla'avvio di dovecot.

3. Avviare il DA basta eseguire il comando:

   sudo /etc/init.d/dovecot start

4. Attraverso l'output del comando:

   '''ps -A|grep dovecot''' noterete che il servizio

   è possibile verificare che il programma si sia avviato con successo.

Web mail

Il servizio di posta elettronica fruibile dal browser web, webmail, richiede che siano installati il web server e il programma SquirrelMail per l'accesso alle mailboxe attraverso il browser web.

1. Installare i pacchetti apache2, squirrelmail.

2. Per predisporre squirrelmail alla gestione della posta elettronica in modalità protetta (attraverso l'uso di certificati con SSL server-side), digitare il comando per generare un certificato per il server web:

   sudo apache2-ssl-certificate -days 3650

   dove 3650 è la durata di validità del certificato (10 anni, modificabile a seconda delle proprie esigenze).

3. Per creare un nuovo virtual host aprire con i privilegi di amministrazione e con un editor di testo modificare il file /etc/apache2/sites-enabled/000-default nel seguente modo:

   <VirtualHost 192.168.0.1>
   SSLCertificateFile /etc/apache2/ssl/apache.pem
   DocumentRoot /usr/share/squirrelmail
   ServerName webmail.example.com
   </VirtualHost>

   dove si sosituiranno 192.168.0.1 e webmail.example.com con IP e alias name del server di posta web.

Per sperimentare l'accesso attraverso imap da browser web (nell'esempio qui sotto Firefox), digitare i comandi:

sudo /etc/init.d/dovecot start

sudo /etc/init.d/apache2 start

sudo firefox https://webmail.example.com:80

MailScanner

Per ottenere un ulteriore livello di protezione sul proprio MTA e DA è possibile associare una scansione antivirus ed un filtro anti-spam che effettuino il controllo di ogni messaggio di posta smistato dal vostro sistema. Nell'esempio al già presente MailScanner viene utilizzato l'antivirus Clamav.

1. Installare i pacchetti clamav-daemon, clamav-freshclam.

2. Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/MailScanner/MailScanner.conf per modificarne i parametri nel seguente modo:

   VirusScanner''' = clamav
   %org-name%''' = Nome della vostra Azienda
   %report-dir%''' = /etc/MailScanner/reports/it
   QuarantineInfections''' = no
   Information Header Value''' = Informazioni personali dell'azienda
   Warning Is Attachment''' = no
   Notices Include Full Headers''' = yes
   Spam List''' = ORDB-RBL SBL+XBL EasyNet-DNSBL BLITZEDALL SORBS-DNSBL spamcop.net

   salvare e quindi chiudere il file.

3. Riavviate MailScanner con il comando:

   #/etc/init.d/mailscanner restart

4. È possibile controllare il corretto avvio in /var/log/syslog e tramite il comando:

   ps -A|grep mailscanner

Migliorare le prestazioni

Il settaggio delle prestazioni dipende da alcuni parametri del mail server, seguono alcuni cenni:

• Process availability: per rispondere ai picchi di carico di Postfix è possibile modificare il numero massimo dei processi nel file /etc/postfix/main.cf:

  default_process_limit = 100

• CPU speed: se il carico sul processore supera il 50% e tramite il comando top o altra applicazione risultasse imputabile ai processi di Postfix è possibile che sia necessario l'utilizzo di un processore più potente.

• DNS lookup time: poichè il primo passo per inoltrare e-mail sono query DNS, se il tempo di risposta per una query DNS è alto occorre ottimizzare il DNS o meglio ancora implementare un caching NS interno per velocizzare le risoluzioni.

• Disk I/O speed: usare dischi SCSI (postfix usa code di mail in /var/spool/mail e sposta i dati da una coda all'altra) e montare le partizioni con l'opzione noatime (postfix non usa i timestamps).

Sicurezza dei protocolli di posta

Protocollo SMTP

Il protocollo SMTP non è stato progettato per essere sicuro. Per spedire un messaggio di posta elettronica non è necessaria alcuna autenticazione da parte dell'utente, pertanto chiunque può tentare di sfruttare problemi di sicurezza di un server SMTP.

È possibile utilizzare meccanismi di protezione per aumentare la sicurezza dei server SMTP, in particolare per crittografare un'intera sessione?
L'uso dei certificati digitali così come quello della Strong Authentication con SASL è possibile attraverso opportuni moduli messi a disposizione dai programmi di posta stessi, il problema è (per fare l'esempio della protezione tramite certificati) che ciò che verrà crittografato è il traffico fra il client ed il proprio server di posta, ma al di fuori del proprio server (ovvero fino al server SMTP che smista la posta per il dominio del destinatario) le comunicazioni avverranno in chiaro. Questo a meno che anche il dominio remoto non utilizzi un sistema di certificati come il proprio.

Questo perchè la protezione di una sessione SMTP con certificati richiede che tutte le entità che comunicano abbiano un certificato verificabile da una Root CA. Se anche uno solo dei propri destinatari non avrà un certificato, allora la comunicazione fra il proprio server di posta ed il server di posta di quel dominio avverrà in modo non protetto.

Considerazioni analoghe possono essere fatte per i metodi di autenticazione forte che utilizzano la libreria SASL.

Pertanto l'implementazione di meccanismi di protezione delle intere sessioni di posta è subordinata all'implementazione di una PKI globale (cioè estesa a tutti i domini di posta da noi raggiungibili) nel caso dei certificati digitali e di un protocollo SMTP che richieda l'autenticazione di default nel caso di SASL.

Questo richiederà probabilmente un nuovo standard per le comunicazioni di posta.

Pertanto occorre valutare se vale la pena implementare all'interno della propria azienda la protezione delle sessioni SMTP con questi metodi. Questo potrebbe fare al proprio caso si vuole proteggere le comunicazioni interne, ma quelle con l'esterno resteranno sempre esposte al rischio di attacchi e violazioni.

Per fare un esempio concreto, se si sta gestendo un sistema di posta fra N aziende consociate che si scambiano dati sensibili, allora potrebbe essere creata una PKI ed utilizzare i certificati emessi per garantire l'integrità e la confidenzialità delle informazioni scambiate durante le sessioni. Tuttavia deve essere chiaro che tutte le sessioni di posta con domini esterni a tali consociate non saranno protette.

Protocolli POP3 e IMAP

E per quanto riguarda i protocolli POP3 e IMAP, le cose sono addirittura peggiori. I client POP3 e IMAP nella loro configurazione standard inviano le credenziali di autenticazione dell'utente di posta in chiaro sulla rete, pertanto chiunque sarà in grado di catturarle avrà una facile base di accesso al proprio sistema.

La protezione tramite SASL o certificati digitali è sempre possibile, ma come spiegato per essere realmente utile dovrebbe riguardare tutti i domini da cui viene riceveta la posta, non soltanto il il proprio.

Tuttavia se non è possibile assicurare una protezione globale di un'intera sessione di posta, la crittografia a chiave pubblica rende comunque possibile proteggere almeno i dati scambiati in un messaggio, cioè il contenuto di tale messaggio oltre che file allegati. Questo è l'argomento del seguente capitolo.

Protezione di messaggi con GPG

GPG (Gnu Privacy Guard) è un programma che utilizza la crittografia a chiave asimmetrica per garantire la confidenzialità e l'integrità delle informazioni scambiate in un messaggio di posta.

GPG è installabile attraverso il pacchetto gpg e attraverso di esso sarà possibile crittografare il contenuto di un messaggio di posta utilizzando la chiave pubblica dell'utente al quale si vuole spedire e firmare il file crittografato con la propria chiave privata in modo da assicurarne l'autenticità.

Supponiamo di avere l'utenti pippo@example.com che vuole spedire un messaggio protetto all'utente pluto@prova.edu.

1. L'utente pippo crea la sua coppia di chiavi privata/pubblica con il comando:

   gpg --gen-key

   selezionando 1 come algoritmo (ElGamal) per poter utilizzare le chiavi per la cifratura e la firma.

2. pippo visualizza le chiavi create con il comando:

   gpg --list-keys

3. pippo esporta la sua chiave pubblica nel repository comune utilizzando i comandi:

   gpg --export -o pippo

   sftp pippo@publickeys:/keys/pippo

4. pippo preleva la chiave pubblica di pluto@prova.edu dalla directory /keys sul server publickeys (che funge da repository comune di tutte le chiavi pubbliche degli utenti del sistema di posta comune) e la importa nel suo DB delle chiavi (generato con gpg --gen-key):

   sftp pippo@publickeys:/keys/pluto

   gpg --import pluto

   questo metterà la chiave di pluto nella directory corrente di pippo.

5. pippo ora crittografa il messaggio di posta contenuto nel file README.txt con la chiave pubblica di pluto e lo firma con la sua chiave privata:

   gpg -se -r pluto README.txt

6. pippo spedisce il messaggio README.txt.gpg a pluto@prova.edu usando il suo mail server.

7. pluto importa la chiave pubblica di pippo con il comando:

   sftp pluto@publickeys:/keys/pippo

   gpg --import pippo

8. L'utente pluto va a decifrare il messaggio con il comando:

   gpg -o README.txt -d README.txt.gpg 

9. Se pippo visualizza un messaggio del tipo:

   '''Good signature...'''

   allora vuol dire che il messaggio non è stato alterato durante la consegna, altrimenti in caso di compromissione visualizzerà un messaggio del tipo:

   '''Bad Signature...'''

Ulteriori risorse

• Sito ufficiale del progetto Postfix

• Sito ufficiale del progetto Dovecot

• Sito ufficiale del progetto SquirrelMail

CategoryServer CategoryDaRevisionare