Introduzione

Questa guida illustra come installare e configurare un server mail completo. Fornire una base solida per la gestione della posta elettronica, includendo la ricezione, l'invio, l'accesso tramite client e webmail, la protezione da spam e virus.

Pianificazione

Prima di iniziare, è fondamentale una corretta pianificazione e avere accesso alla configurazione DNS:

• Nome Dominio: È necessario possedere un nome dominio (es. example.com).

• Record DNS: Saranno necessari almeno:

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

  • Configurazione SPF, DKIM e DMARC (consigliato): per migliorare la deliverability e combattere lo spoofing. Se necessario, si consiglia di approfondire tali in guide e/o manuali dedicati.

• 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 (ad esempio ufw) e mantenere il sistema aggiornato.

Componenti Coinvolti

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

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

• 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. Sarà utilizzato Postfix.

• Mail Delivery Agent (MDA) / Submission Agent:

  • Local Delivery Agent: Si occupa della consegna finale dei messaggi nelle caselle di posta elettronica in locale. Spesso è integrato in Postfix o gestito da Dovecot, che fornisce supporto per i protocolli server IMAP e POP3.

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

• 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), coordinati da Amavisd-new.

• Webmail: Un'interfaccia web che permette agli utenti di accedere alla propria posta tramite un browser web. 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

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 (per approfondire consultare la relativa documentazione/manualistica in rete).

Installazione

Mail Transfer Agent (Postfix)

Prima di tutto, occorre installare il Mail Transfer Agent (Postfix) e il server IMAP/POP3 (Dovecot), i quali si occuperanno di ricevere, inoltrare e consegnare le email.

Installare i seguenti pacchetti, digitando nel terminale:

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

verrà presentata una schermata di configurazione. Scegliere:

• Tipo di configurazione del server di posta: Sito Internet (Internet Site).

• Nome di sistema della posta (System mail name): Inserire il proprio dominio di posta principale (es. example.com). Questo è il dominio per il quale il server sarà primariamente responsabile. Non inserire quindi il nome host completo del server (es. mail.example.com), ma il solo dominio.

Installazione Filtri Antispam e Antivirus

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

Per 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. Si utilizzerà Apache2.
Per 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). Nei passaggi successivi saranno installati 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 si raccomanda di mettere in sicurezza l'installazione di MariaDB; digitare nel terminale il seguente comando:

   sudo mysql_secure_installation

   Seguire quindi 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

1. Installare Roundcube digitando nel terminale il seguente comando:

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

2. Durante l'installazione di roundcube, potrebbe essere richiesto di configurare il database. A seconda dei casi sarà possibile selezionare:

   • configurazione automatizzata: quando richiesto scegliere "Sì" per configurare il database con dbconfig-common se si desidera una di base; verranno richiesti il tipo di database, la password dell'utente amministratore del database, inoltre verrà creato un utente e database per Roundcube).

   • configurazione manuale: quando richiesto scegliere "No" e procedere in seguito con la configurazione del database ed i file di configurazione di Roundcube.

   Ai fini di questa guida, procedere con la configurazione automatizzata, se disponibile.

Utility di Test

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

sudo apt install bsd-mailx

Al termine di questi passaggi, tutti i componenti software necessari dovrebbero essere installati. Sarà quindi possibile configurare ciascun componente, come descritto di seguito.

Configurazione

Mail Transfer Agent (Postfix)

La configurazione principale di Postfix si trova nella directory /etc/postfix/; il file più importante è main.cf. Un altro file utile è /etc/aliases per la gestione degli alias degli utenti di posta elettronica.

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 (ad esempio 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.

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

Le seguenti 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. Configurare 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 già in esecuzione, digitando nel terminale i comandi descritti sotto in tabella:

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.

Delivery Agent (Dovecot - IMAP/POP3)

Dovecot è il software che si utilizzerà per permettere agli utenti di accedere alle proprie caselle di posta tramite i protocolli IMAP (consigliato, la posta rimane sul server) e POP3 (la posta viene scaricata localmente dal client). Dovecot si occuperà anche dell'autenticazione degli utenti e della consegna locale dei messaggi (Local Delivery Agent - LDA) tramite LMTP.

La configurazione di Dovecot è modulare e si trova principalmente in /etc/dovecot/, con i file di configurazione specifici dentro /etc/dovecot/conf.d/.

Configurazione di Base

Molte impostazioni predefinite di Dovecot sono già adeguate per un funzionamento di base. Di seguito alcune delle configurazioni chiave.

Abilitare i protocolli

Per definire su quali interfacce e porte Dovecot deve ascoltare:

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

2. Assicurarsi che le sezioni relative a imap_listener e pop3_listener siano abilitate (non commentate) e configurate per ascoltare su tutte le interfacce o su quelle desiderate (spesso è la configurazione di default).

Il parametro protocols nel file principale /etc/dovecot/dovecot.conf (o in 10-master.conf) definisce quali protocolli sono globalmente abilitati.

1. Verificare o modificare /etc/dovecot/dovecot.conf, digitando nel terminale il seguente comando:

   sudo nano /etc/dovecot/dovecot.conf

2. Assicurarsi che la riga protocols includa imap pop3 lmtp:

protocols = imap pop3 lmtp

Formato e posizione della casella di posta

Dovecot deve essere configurato per individuare la posizione delle email degli utenti e in quale formato sono memorizzate (Maildir è il formato raccomandato).

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

2. Configurare mail_location. L'impostazione più comune per utenti di sistema è Maildir nella home directory dell'utente:

# Formato e percorso della casella di posta. Maildir è raccomandato. # %h si espande alla home directory dell'utente.

mail_location = maildir:~/Maildir

Se si utilizza un percorso diverso per le caselle di posta (es. /var/vmail/%d/%n per domini virtuali), questa impostazione andrà adattata. Per utenti di sistema, ~/Maildir è un buon punto di partenza.

Autenticazione

Dovecot gestirà l'autenticazione degli utenti. Per utenti di sistema, l'autenticazione PAM è solitamente la scelta predefinita e funziona bene.

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

2. Assicurarsi che includa:

   auth_mechanisms = plain login

   e verificare che il backend di autenticazione per gli utenti di sistema sia abilitato.

   • Dovrebbe essere presente una sezione simile a questa (o il file auth-system.conf.ext dovrebbe essere incluso e configurato):

     # Esempio per l'autenticazione degli utenti di sistema (PAM)
     # Questa potrebbe essere in un file incluso come auth-system.conf.ext
     !include auth-system.conf.ext

   • Il cobtenuto del file auth-system.conf.ext dovrebbe essere simile al seguente:

     passdb {
       driver = pam
       # args = dovecot # Il nome del servizio PAM, solitamente /etc/pam.d/dovecot
     }
     userdb {
       driver = passwd
       # Per utenti con UID < 500 (o un altro valore minimo, es. 1000 per utenti normali)
       # args = uid=500 # o uid=1000 a seconda del sistema
     }

Configurazione SSL/TLS

La crittografia è fondamentale. Configurare SSL/TLS per IMAPS e POP3S.

Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/dovecot/conf.d/10-ssl.conf ed impostare:

# Abilita SSL. 'required' forza SSL e disabilita le versioni non criptate.
# Per iniziare, si può usare 'yes' che permette sia versioni criptate che non,
# poi passare a 'required' una volta che tutto funziona.
ssl = yes # o required per forzare SSL

# Percorsi ai file del certificato SSL e della chiave privata.
# È consigliabile usare certificati validi, ad esempio da Let's Encrypt.
# Sostituire con i propri percorsi.
ssl_cert = </etc/ssl/certs/dovecot.pem  # O il percorso del certificato del proprio dominio
ssl_key = </etc/ssl/private/dovecot.key # O il percorso della chiave del proprio dominio

# Protocolli SSL/TLS minimi consentiti. Aggiornare alle best practice.
ssl_min_protocol = TLSv1.2

# Cipher list (consultare le raccomandazioni moderne, es. da Mozilla SSL Config Generator)
# ssl_cipher_list = ...

Integrazione con Postfix (LMTP)

Per la consegna locale dei messaggi da Postfix a Dovecot, utilizzare LMTP (Local Mail Transfer Protocol), che è più efficiente e flessibile rispetto alla chiamata diretta di dovecot-lda.

1. Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/dovecot/conf.d/10-master.conf, quindi assicurarsi che il servizio LMTP sia configurato per ascoltare su un socket UNIX (metodo preferito e più sicuro) o su una porta TCP.

2. Cercare la sezione service lmtp e configurarla come nel seguente esempio:

   service lmtp {
     unix_listener /var/spool/postfix/private/dovecot-lmtp {
       # Impostazioni del listener LMTP via socket UNIX
       mode = 0600
       user = postfix
       group = postfix
     }
   
     # Esempio alternativo: listener LMTP su TCP (meno comune per integrazione locale)
     # inet_listener lmtp {
     #   port = 24 # o altra porta
     # }
   }

Il socket /var/spool/postfix/private/dovecot-lmtp è un percorso comune. La directory /var/spool/postfix/private/ deve essere accessibile a Postfix.
Ora si dovrà configurare Postfix per usare questo socket LMTP.

Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/postfix/main.cf ed aggiungere o modificare la seguente riga:

mailbox_transport = lmtp:unix:private/dovecot-lmtp
# Se si usano domini virtuali, potrebbe essere virtual_transport invece di mailbox_transport

In questo modo si imposta Postfix per passare le email destinate a utenti locali al servizio LMTP di Dovecot tramite il socket UNIX specificato (relativo a /var/spool/postfix/).

Configurazione per l'autenticazione SASL da Postfix

Dovecot può fornire il meccanismo di autenticazione SASL a Postfix, permettendo ai client di autenticarsi per inviare email.

1. Aprire con i privilegi di amministrazione e con un editor di testo il file /etc/dovecot/conf.d/10-master.conf, quindi assicurarsi che il servizio di autenticazione sia configurato per Postfix.

2. Cercare la sezione service auth e assicurarsi che esista un listener per Postfix:

   service auth {
     # ... altre impostazioni ...
     unix_listener /var/spool/postfix/private/auth {
       mode = 0660
       user = postfix
       group = postfix
     }
   
     # Alternativamente, potrebbe essere:
     # unix_listener auth-userdb { # per lookup utente
     #   mode = 0600
     #   user = vmail # o l'utente che Postfix userà per le query
     # }
   }

   La configurazione predefinita di solito crea /var/spool/postfix/private/auth.

3. Ora si dovrà configurare Postfix per usare Dovecot SASL. Modificare /etc/postfix/main.cf aggiungendo o modificando le seguenti righe (alcune potrebbero già esistere o essere state preparate nella sezione Postfix):

   # Autenticazione SMTP (SASL) con Dovecot
   smtpd_sasl_type = dovecot
   smtpd_sasl_path = private/auth  # Relativo a /var/spool/postfix/
   smtpd_sasl_auth_enable = yes
   # Per client più vecchi che potrebbero avere problemi con SASL
   # broken_sasl_auth_clients = yes
   # Non permettere login anonimi
   smtpd_sasl_security_options = noanonymous
   # Per evitare che Postfix tenti di aggiungere @nomehost agli username senza dominio
   smtpd_sasl_local_domain = $myhostname

Avvio e Verifica di Dovecot

Dopo aver apportato le modifiche, riavviare Dovecot per applicarle. Digitare nel terminale i comandi descritti nella tabella sottostante

Per controllare i log di Dovecot (e di Postfix) per eventuali errori, digitare nel terminale il seguente comando:

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

Tra i vari aspetti da considerare:

• Potrebbero esserci log specifici di Dovecot in /var/log/dovecot/ o syslog.

• Per vedere i log di Dovecot con systemd:

  sudo journalctl -u dovecot.service -f

• Si può testare la connessione IMAP/POP3 con un client di posta o con telnet (es.: telnet localhost 143 per IMAP, telnet localhost 110 per POP3, openssl s_client -connect localhost:993 per IMAPS).

Webmail

Roundcube

Per consentire agli utenti di accedere alla propria posta elettronica tramite un browser web, installare e configurare Roundcube, una moderna applicazione di webmail. Roundcube si interfaccerà con il server IMAP (Dovecot) per recuperare le email e con il server SMTP (Postfix) per inviarle. Utilizzare Apache2 come web server e MySQL/MariaDB come database per Roundcube.

Assicurarsi che i pacchetti necessari (Apache2, PHP, MariaDB, Roundcube) siano stati installati come descritto nel paragrafo dedicato all'installazione.

Creazione del Database (MariaDB/MySQL)

Roundcube necessita di un database per memorizzare le impostazioni utente, la rubrica, ecc. Se non è stato fatto durante l'installazione di Roundcube tramite dbconfig-common, creare manualmente il database e l'utente.

1. Accedere al prompt di MariaDB/MySQL come utente root (verrà chiesta la password impostata durante mysql_secure_installation o la password di root del DB):

   sudo mysql -u root -p

2. Una volta dentro il prompt, eseguire i seguenti comandi SQL. Sostituire roundcube_password_segreta con una password robusta:

   CREATE DATABASE roundcubemail CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   CREATE USER 'roundcubeuser'@'localhost' IDENTIFIED BY 'roundcube_password_segreta';
   GRANT ALL PRIVILEGES ON roundcubemail.* TO 'roundcubeuser'@'localhost';
   FLUSH PRIVILEGES;
   EXIT;

I precedenti comandi:

• Creano un database chiamato roundcubemail.

• Creano un utente chiamato roundcubeuser che può connettersi solo da localhost.

• Concedono tutti i privilegi sul database roundcubemail all'utente roundcubeuser.

Configurazione di Roundcube

Se Roundcube è stato installato dai repository, la configurazione principale si trova in /etc/roundcube/config.inc.php. Se questo file non esiste, copiare /etc/roundcube/config.inc.php.sample in /etc/roundcube/config.inc.php.

1. Aprire con i privilegi di amministrazione e con un editor di testo il file di configurazione /etc/roundcube/config.inc.php.

2. Modificare le seguenti direttive principali:

   // Configurazione del Database
   // Assicurarsi che corrisponda a quanto creato nel database
   $config['db_dsnw'] = 'mysql://roundcubeuser:roundcube_password_segreta@localhost/roundcubemail';
   
   // Host IMAP
   // 'localhost' se Dovecot è sulla stessa macchina. Usare 'ssl://localhost' o 'tls://localhost'
   // per connessioni SSL/TLS rispettivamente. La porta 993 è per IMAPS (SSL).
   $config['default_host'] = 'ssl://localhost'; // o 'tls://localhost'
   $config['default_port'] = 993; // o 143 per IMAP non criptato con STARTTLS
   
   // Host SMTP
   // 'localhost' se Postfix è sulla stessa macchina. Usare 'ssl://localhost' o 'tls://localhost'
   // per connessioni SSL/TLS rispettivamente. La porta 465 è per SMTPS (SSL), 587 per Submission (STARTTLS).
   $config['smtp_server'] = 'tls://localhost'; // o 'ssl://localhost'
   $config['smtp_port'] = 587; // o 465
   $config['smtp_user'] = '%u'; // Username dell'utente corrente
   $config['smtp_pass'] = '%p'; // Password dell'utente corrente
   $config['smtp_auth_type'] = 'LOGIN'; // o PLAIN, a seconda di cosa supporta Postfix/Dovecot SASL
   
   // Nome del prodotto (appare nel titolo della pagina)
   $config['product_name'] = 'Webmail Aziendale'; // Personalizzare
   
   // Supporto URL (opzionale)
   // $config['support_url'] = 'http://support.example.com';
   
   // Lingua predefinita (es. 'it_IT' per italiano)
   $config['language'] = 'it_IT';
   
   // Abilitare il logging degli errori SMTP (utile per il debug)
   $config['smtp_log'] = true;
   $config['log_dir'] = '/var/log/roundcube/'; // Assicurarsi che questa directory esista e sia scrivibile da Apache
   $config['temp_dir'] = '/var/tmp/roundcube/'; // Assicurarsi che questa directory esista e sia scrivibile da Apache
   
   // Plugin da abilitare
   // $config['plugins'] = array('archive', 'zipdownload', 'managesieve'); // Esempio
   $config['plugins'] = array(); // Iniziare con pochi o nessun plugin, poi aggiungerli

3. Assicurarsi che le directory specificate in log_dir e temp_dir (es. /var/log/roundcube/ e /var/tmp/roundcube/ o /var/lib/roundcube/temp) esistano e abbiano i corretti permessi di scrittura per l'utente relativo ad Apache (solitamente www-data). A tal fine utilizzare i seguenti comandi:

   sudo mkdir -p /var/log/roundcube /var/tmp/roundcube
   sudo chown www-data:www-data /var/log/roundcube /var/tmp/roundcube
   sudo chmod 750 /var/log/roundcube /var/tmp/roundcube

Dopo aver salvato config.inc.php, Roundcube dovrebbe inizializzare la struttura del database al primo accesso, se non è già stato fatto da dbconfig-common.

Configurazione di Apache2 per Roundcube

Se Roundcube è stato installato dai repository ufficiali, solitamente viene fornito un file di configurazione per Apache in /etc/apache2/conf-available/roundcube.conf.

Abilitare questa configurazione (se non già fatto in precedenza) e il modulo rewrite di Apache con i seguenti comandi:

sudo a2enconf roundcube
sudo a2enmod rewrite
sudo systemctl restart apache2

Il file /etc/apache2/conf-available/roundcube.conf definisce un Alias per accedere a Roundcube, solitamente su /roundcube (es. http://mail.example.com/roundcube). Se si desidera accedere a Roundcube direttamente da un Virtual Host dedicato (es.: https://webmail.example.com), è necessario creare un file di configurazione per un Virtual Host Apache.

Di seguito un esempio di Virtual Host per webmail.example.com in /etc/apache2/sites-available/webmail.example.com.conf:

<VirtualHost *:80>
    ServerName webmail.example.com
    DocumentRoot /usr/share/roundcube/

    # Reindirizza tutto il traffico HTTP a HTTPS
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

    ErrorLog ${APACHE_LOG_DIR}/webmail.example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/webmail.example.com-access.log combined
</VirtualHost>

<VirtualHost *:443>
    ServerName webmail.example.com
    DocumentRoot /usr/share/roundcube/

    # Configurazione SSL
    SSLEngine on
    # Sostituire con i percorsi dei propri certificati SSL (es. Let's Encrypt)
    SSLCertificateFile /etc/letsencrypt/live/webmail.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/webmail.example.com/privkey.pem

    # Opzioni SSL moderne (consultare Mozilla SSL Configuration Generator)
    # SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    # SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...
    # SSLHonorCipherOrder     on
    # SSLCompression          off
    # SSLSessionTickets       off

    # Header di sicurezza
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"

    <Directory /usr/share/roundcube/>
        Options -Indexes +FollowSymLinks
        AllowOverride All # O specifiche direttive se si conoscono
        Require all granted
        # Protezione aggiuntiva per file sensibili se necessario
        # <FilesMatch "\.(php|phtml|inc)$">
        # Require all denied
        # </FilesMatch>
        # <FilesMatch "(config.inc.php|mbox.php|CHANGELOG|INSTALL|README|UPGRADING)">
        # Require all denied
        # </FilesMatch>
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/webmail.example.com-ssl-error.log
    CustomLog ${APACHE_LOG_DIR}/webmail.example.com-ssl-access.log combined
</VirtualHost>

Dopo aver creato il file del Virtual Host:

1. Abilitare il sito:

   sudo a2ensite webmail.example.com.conf

2. Abilitare il modulo SSL di Apache:

   sudo a2enmod ssl

3. Verificare la configurazione di Apache:

   sudo apache2ctl configtest

4. Riavviare Apache:

   sudo systemctl restart apache2

Testare Roundcube

Aprire un browser e navigare all'URL configurato per Roundcube (es. https://webmail.example.com o http://il_tuo_server_ip/roundcube).

Si dovrebbe vedere la pagina di login di Roundcube. Provare ad accedere con un utente di sistema e la sua password.
In caso di problemi controllare i seguenti log:

• Log di Roundcube: /var/log/roundcube/ (se configurato)

• Log di Apache: /var/log/apache2/error.log e /var/log/apache2/webmail.example.com-error.log

• Log di Postfix: /var/log/mail.log

• Log di Dovecot: digitare il comando:

  sudo journalctl -u dovecot.service

Filtri AntiSpam/AntiVirus

Per proteggere il server mail da spam e malware, si integrerà Amavisd-new, che orchestrerà SpamAssassin (per il rilevamento dello spam) e ClamAV (per la scansione antivirus). Postfix invierà le email ad Amavisd-new prima della consegna finale; Amavisd-new le analizzerà e, se pulite, le re-inietterà in Postfix per la consegna.

Assicurarsi che i pacchetti amavisd-new, spamassassin, clamav-daemon e le loro dipendenze siano stati installati come descritto qui.

Configurazione di ClamAV

La parte più importante consiste in:

• Assicurarsi che il demone clamav-daemon sia in esecuzione e che freshclam aggiorni regolarmente le definizioni dei virus. Verificare che freshclam sia attivo per gli aggiornamenti automatici (solitamente lo è di default).

• Assicurarsi che l'utente clamav sia membro del gruppo amavis (o viceversa, a seconda della configurazione di Amavis) per permettere ad Amavis di comunicare con il socket di ClamAV:.

  • Per aggiungere l'utente amavis al gruppo clamav, digitare nel terminale il seguente comando:

      sudo usermod -a -G clamav amavis

    Oppure, se Amavis è gia eseguito come utente amavis e ClamAV come clamav, aggiungere l'utente clamav al gruppo amavis:

     sudo usermod -a -G amavis clamav

  • Verificare quale utente usa Amavis e ClamAV e i permessi del socket di ClamAV (es.: /var/run/clamav/clamd.ctl).

    • Una configurazione comune è che amavis possa accedere al socket di clamd.

  • Riavviare i servizi dopo eventuali modifiche ai gruppi:

      sudo systemctl restart clamav-daemon
      sudo systemctl restart amavis

Configurazione di SpamAssassin

SpamAssassin viene utilizzato da Amavisd-new. Le sue regole si trovano in /etc/spamassassin/local.cf per le personalizzazioni.

Per abilitare l'aggiornamento automatico delle regole di SpamAssassin (tramite sa-update):

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

2. Impostare il parametro CRON=1 per abilitare il job di cron che esegue sa-update.

Il demone spamd non è strettamente necessario se Amavisd-new chiama SpamAssassin come libreria Perl (comportamento comune). Tuttavia se spamd è in esecuzione, assicurarsi che sia configurato correttamente. Per questa guida si assumiame che Amavis chiami SpamAssassin direttamente.

Configurazione di Amavisd-new

Amavisd-new è il collante tra Postfix, SpamAssassin e ClamAV. La sua configurazione principale si trova in /etc/amavis/conf.d/. Modifichiamo il file 15-content_filter_mode e 50-user.

1. Aprire /etc/amavis/conf.d/15-content_filter_mode:

   sudo nano /etc/amavis/conf.d/15-content_filter_mode

2. Assicurarsi che le sezioni per abilitare SpamAssassin e ClamAV siano decommentate (rimuovere # all'inizio delle righe):

   # Abilita SpamAssassin
   @bypass_spam_checks_maps = (
      %bypass_spam_checks,   # controls running of anti-spam code
      \%bypass_spam_checks_acl, # controls running of anti-spam code
   );
   
   # Abilita ClamAV (o altri antivirus)
   @bypass_virus_checks_maps = (
      %bypass_virus_checks, # controls running of anti-virus code
      \%bypass_virus_checks_acl, # controls running of anti-virus code
   );

Queste sono le impostazioni predefinite e solitamente abilitano i controlli.

1. Aprire /etc/amavis/conf.d/50-user per le configurazioni specifiche dell'utente/sito:

   sudo nano /etc/amavis/conf.d/50-user

2. Configurare le seguenti direttive (alcune potrebbero già esistere):

   # Dominio e nome host
   $mydomain = 'example.com'; # Sostituire con il proprio dominio
   $myhostname = "mail.$mydomain"; # Sostituire con FQDN del server mail
   
   # Interfacce di ascolto di Amavis
   # Amavis ascolta su 127.0.0.1:10024 per ricevere posta da Postfix (pre-queue filter)
   # e reinvia la posta a Postfix su 127.0.0.1:10025 (post-queue filter)
   $inet_socket_port = [10024, 10026]; # 10024 per Postfix, 10026 per il re-injection alternativo
   $forward_method = 'smtp:[127.0.0.1]:10025'; # Dove Amavis reinvia la posta a Postfix
   $notify_method  = $forward_method;
   
   # Azioni per spam e virus
   $sa_tag_level_deflt  = 2.0;  # Punteggio per aggiungere gli header X-Spam-*
   $sa_tag2_level_deflt = 6.31; # Punteggio per aggiungere '***SPAM***' all'oggetto
   $sa_kill_level_deflt = 6.31; # Punteggio per bloccare/rifiutare l'email (o metterla in quarantena)
                                # Per iniziare, è meglio non bloccare subito, ma solo taggare
                                # $sa_kill_level_deflt = $sa_tag2_level_deflt + 5; # Esempio per non bloccare
   $sa_spam_subject_tag = '***SPAM*** '; # Prefisso per l'oggetto delle email spam
   
   # Quarantena (opzionale, richiede configurazione aggiuntiva)
   # $QUARANTINEDIR = '/var/virusmails'; # Commentato per ora
   # $virus_quarantine_to = 'virus-quarantine@example.com'; # Notifica per virus in quarantena
   # $spam_quarantine_to  = 'spam-quarantine@example.com';  # Notifica per spam in quarantena
   
   # Log level
   $log_level = 2; # 0-5, 2 è un buon livello per iniziare
   
   # Assicurarsi che Amavis possa trovare ClamAV
   # Questo è solitamente gestito dalla configurazione di ClamAV in 15-av_scanners o simile
   # Esempio per clamd socket:
   # ['ClamAV-clamd',
   #   \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.ctl"],
   # ... ],
   
   # Assicurarsi che l'utente amavis sia nei gruppi giusti
   # (es. 'clamav', 'postfix') per accedere ai socket e comunicare.
   # Questo è stato parzialmente gestito prima.
   # $daemon_user  = 'amavis';
   # $daemon_group = 'amavis';

   • I valori di $sa_tag_level_deflt, $sa_tag2_level_deflt e $sa_kill_level_deflt sono cruciali. Iniziare con un $sa_kill_level_deflt alto (o commentarlo) per evitare di bloccare email legittime (falsi positivi) finché non si è sicuri del comportamento del filtro. È meglio taggare le email e lasciare che gli utenti le filtrino nei loro client di posta, piuttosto che bloccarle aggressivamente all'inizio.

3. Verificare la configurazione di Amavis:

    sudo amavisd-new testkeys

4. Riavviare Amavisd-new:

    sudo systemctl restart amavis
    sudo systemctl enable amavis
    sudo systemctl status amavis

Integrazione di Amavisd-new con Postfix

Ora dobbiamo dire a Postfix di inviare le email ad Amavisd-new per la scansione.

1. Modificare /etc/postfix/main.cf:

   sudo nano /etc/postfix/main.cf

2. Aggiungere o decommentare la seguente riga:

   # Invia le email ad Amavis prima della consegna
   content_filter = smtp-amavis:[127.0.0.1]:10024

3. Poi, dobbiamo configurare Postfix per accettare le email re-iniettate da Amavis. Modificare /etc/postfix/master.cf:

   sudo nano /etc/postfix/master.cf

4. Aggiungere le seguenti sezioni alla fine del file (o assicurarsi che esistano e siano configurate correttamente):

   # Servizio SMTP per Amavisd-new (re-injection)
   # Postfix ascolta sulla porta 10025 per le email processate da Amavis
   127.0.0.1:10025 inet n  -       n       -       -       smtpd
     -o content_filter=                                    # Non filtrare di nuovo le email già processate
     -o local_recipient_maps=
     -o relay_recipient_maps=
     -o smtpd_restriction_classes=
     -o smtpd_delay_reject=no
     -o smtpd_client_restrictions=permit_mynetworks,reject
     -o smtpd_helo_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject
     -o smtpd_data_restrictions=reject_unauth_pipelining
     -o smtpd_end_of_data_restrictions=
     -o mynetworks=127.0.0.0/8
     -o smtpd_error_sleep_time=0
     -o smtpd_soft_error_limit=1001
     -o smtpd_hard_error_limit=1000
     -o smtpd_client_connection_count_limit=0
     -o smtpd_client_connection_rate_limit=0
     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
     # Per Ubuntu 20.04+ e Postfix 3.4+, si può usare smtpd_authorized_xforward_hosts
     # per preservare l'IP originale del client se Amavis lo inoltra.
     # -o smtpd_authorized_xforward_hosts=127.0.0.0/8
   
   # Servizio di pickup alternativo per Amavis (se Amavis è configurato per usarlo, es. porta 10026)
   127.0.0.1:10026 inet n  -       n       -       -       smtpd
     -o content_filter=
     -o smtpd_authorized_xforward_hosts=127.0.0.0/8
     # ... altre opzioni simili al listener 10025 se necessario ...

Dopo aver modificato main.cf e master.cf, ricaricare Postfix:

sudo systemctl reload postfix

Test del Flusso di Posta e dei Filtri

Inviare un'email di test da un account esterno al proprio server di posta (a un utente del server). Controllare i log:

• /var/log/mail.log: Mostrerà il percorso dell'email attraverso Postfix, la consegna ad Amavis (su porta 10024), la re-iniezione da Amavis a Postfix (su porta 10025), e la consegna finale a Dovecot.

• Log di Amavis (spesso in /var/log/mail.log o /var/log/syslog, o configurabile in /var/log/amavis.log): Mostrerà i risultati della scansione di SpamAssassin e ClamAV.

Per testare SpamAssassin, si può inviare un'email contenente la stringa di test GTUBE:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

questa stringa, se presente nel corpo di un'email, dovrebbe farla classificare come spam da SpamAssassin con un punteggio molto alto. L'email dovrebbe essere taggata (es. con ***SPAM*** nell'oggetto) o gestita secondo le regole impostate in Amavis ($sa_kill_level_deflt).

Per testare ClamAV, si può inviare un'email con un file di test EICAR allegato. Il file EICAR è un file innocuo che tutti i software antivirus dovrebbero rilevare come virus di test. Creare un file eicar.com con il seguente contenuto:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Inviare un'email con questo file come allegato. Amavis dovrebbe rilevarlo tramite ClamAV e bloccarlo o metterlo in quarantena.

Controllare gli header delle email ricevute. Dovrebbero esserci header X-Spam-Status, X-Spam-Level, X-Virus-Scanned aggiunti da Amavis, che indicano il risultato delle scansioni.

Sicurezza dei Protocolli di Posta e Autenticazione

La sicurezza è un aspetto fondamentale nella gestione di un server mail. Questa sezione tratterà la protezione delle comunicazioni tramite crittografia (TLS) e l'autenticazione sicura degli utenti (SASL).

Crittografia TLS per SMTP, IMAP e POP3

Transport Layer Security (TLS) e il suo predecessore SSL sono protocolli crittografici che forniscono comunicazioni sicure su una rete. È cruciale utilizzare TLS per proteggere:

• Le credenziali di accesso degli utenti.
• Il contenuto delle email durante il transito tra client e server, e tra server.

Per utilizzare TLS, sono necessari certificati SSL/TLS. Per un server di produzione, è **fortemente raccomandato** utilizzare certificati emessi da una Certificate Authority (CA) riconosciuta, come quelli gratuiti forniti da [Let's Encrypt](https://wiki.ubuntu-it.org/InternetRete/Server/LetsEncrypt). Assumiamo che si disponga di un certificato e di una chiave privata validi per il proprio nome host mail (es. mail.example.com).

Abilitare TLS in Postfix (per SMTP e Submission)

1. Aprire /etc/postfix/main.cf per abilitare TLS:

   sudo nano /etc/postfix/main.cf

2. Aggiungere o modificare le seguenti direttive. Sostituire i percorsi dei certificati con i propri (es. quelli di Let's Encrypt):

   # Impostazioni TLS Generali
   # Livello di sicurezza per le connessioni SMTP in entrata (porta 25)
   # 'may' permette TLS ma non lo richiede (opportunistic TLS).
   # 'encrypt' richiede TLS per tutte le connessioni (può bloccare server remoti che non supportano TLS).
   # 'dane' abilita la validazione DANE se configurata.
   smtpd_tls_security_level = may
   
   # Livello di sicurezza per le connessioni SMTP in uscita (quando Postfix è client)
   smtp_tls_security_level = may # Per la compatibilità, 'may' è un buon inizio.
                                  # 'dane' o 'verify' offrono maggiore sicurezza se il server remoto lo supporta.
   
   # Percorsi ai file del certificato e della chiave del server
   smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
   smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
   smtpd_tls_dh1024_param_file = /etc/postfix/dhparams.pem # Generare se non esiste (vedi sotto)
   
   # Log TLS (per debug)
   smtpd_tls_loglevel = 1
   smtp_tls_loglevel = 1
   
   # Opzioni di sicurezza TLS
   smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 # Consentire solo protocolli moderni
   smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
   smtpd_tls_ciphers = high
   smtpd_tls_mandatory_ciphers = high
   smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
   smtpd_tls_eecdh_grade = strong # o ultra per curve più forti se supportate dai client
   tls_high_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
   tls_preempt_cipherlist = yes
   
   # Abilitare TLS per il servizio Submission (porta 587)
   # Questo sarà configurato in master.cf per sovrascrivere le impostazioni globali.

3. Generare i parametri Diffie-Hellman (se smtpd_tls_dh1024_param_file è specificato e il file non esiste):

   • Per 2048 bit (raccomandato):

       sudo openssl dhparam -out /etc/postfix/dhparams.pem 2048

   • Assicurarsi che il file sia leggibile solo da root:

       sudo chmod 600 /etc/postfix/dhparams.pem

4. Ora, configurare il servizio Submission (porta 587) in /etc/postfix/master.cf per richiedere l'autenticazione SASL e forzare TLS:

   sudo nano /etc/postfix/master.cf

5. Modificare o aggiungere la sezione submission:

   submission inet n       -       n       -       -       smtpd
     -o syslog_name=postfix/submission
     -o smtpd_tls_security_level=encrypt  # Richiede TLS per la submission
     -o smtpd_sasl_auth_enable=yes
     -o smtpd_sasl_type=dovecot
     -o smtpd_sasl_path=private/auth
     -o smtpd_sasl_security_options=noanonymous
     -o smtpd_sasl_local_domain=$myhostname
     -o smtpd_client_restrictions=permit_sasl_authenticated,reject
     # -o smtpd_sender_restrictions=reject_sender_login_mismatch # Opzionale, lega mittente a utente SASL
     -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
     -o milter_macro_daemon_name=ORIGINATING # Per i milter (es. Amavis, OpenDKIM)

   • Opportunistic TLS (porta 25) vs Mandatory TLS (porta 587):
     Sulla porta 25 (comunicazione server-to-server), TLS è solitamente "opportunistico" (smtpd_tls_security_level = may). Questo significa che se entrambi i server supportano TLS, la connessione verrà crittografata; altrimenti, avverrà in chiaro.
     Forzare TLS sulla porta 25 (encrypt) potrebbe impedire la ricezione di email da server più vecchi.
     Sulla porta 587 (Submission, client-to-server), TLS dovrebbe essere obbligatorio (encrypt) per proteggere le credenziali degli utenti.

6. Ricaricare Postfix:

   sudo systemctl reload postfix

Abilitare TLS in Dovecot (per IMAPS e POP3S)

Abbiamo già visto le basi per SSL/TLS in Dovecot nella sezione dedicata a Dovecot (/etc/dovecot/conf.d/10-ssl.conf). Ricapitoliamo:

sudo nano /etc/dovecot/conf.d/10-ssl.conf

Assicurarsi che:

ssl = yes # o required per forzare solo connessioni SSL/TLS

# Percorsi ai certificati (sostituire con i propri)
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem

# Protocolli minimi e cipher list (come già discusso)
ssl_min_protocol = TLSv1.2
# ssl_cipher_list = ... (consultare Mozilla SSL Config Generator)
# ssl_prefer_server_ciphers = yes
# ssl_dh = </etc/dovecot/dh.pem # Generare se necessario (vedi sotto)

Se si usa ssl_dh, generare i parametri Diffie-Hellman per Dovecot (se non già fatto o se diversi da quelli di Postfix):

• Per 4096 bit (raccomandato per Dovecot se supportato):

  sudo openssl dhparam -out /etc/dovecot/dh.pem 4096

• Assicurarsi che il file sia leggibile:

  sudo chmod 644 /etc/dovecot/dh.pem

  O permessi più restrittivi se Dovecot gira come utente specifico

  • Se ssl = yes è impostato in Dovecot, i servizi IMAPS (porta 993) e POP3S (porta 995) dovrebbero essere automaticamente disponibili. Se ssl = required, le porte non criptate (143, 110) accetteranno solo connessioni STARTTLS o verranno disabilitate a seconda di altre configurazioni (disable_plaintext_auth).

• Riavviare Dovecot:

   sudo systemctl restart dovecot

Autenticazione SMTP (SASL) con Postfix e Dovecot

Simple Authentication and Security Layer (SASL) è un framework per fornire autenticazione e sicurezza dei dati nei protocolli di connessione. Verrà utilizzato per permettere agli utenti di autenticarsi con il server Postfix per inviare email.

Abbiamo già configurato le parti essenziali:

• Dovecot: Il servizio auth in /etc/dovecot/conf.d/10-master.conf fornisce un socket (/var/spool/postfix/private/auth) che Postfix può usare.

• Postfix:

  • In /etc/postfix/main.cf, le direttive smtpd_sasl_type = dovecot e smtpd_sasl_path = private/auth dicono a Postfix di usare il servizio SASL di Dovecot.

  • In /etc/postfix/master.cf, per il servizio submission (porta 587), abbiamo abilitato SASL (smtpd_sasl_auth_enable = yes) e specificato che solo gli utenti autenticati possono inviare (permit_sasl_authenticated).

Assicurarsi che l'utente postfix possa accedere al socket di autenticazione di Dovecot. I permessi (mode = 0660, user = postfix, group = postfix) sul listener unix_listener /var/spool/postfix/private/auth in 10-master.conf di Dovecot dovrebbero essere corretti.

Considerazioni sulla Sicurezza della Comunicazione Inter-Server (SMTP porta 25)

Mentre possiamo (e dovremmo) forzare TLS per le connessioni dai client al nostro server (Submission, IMAPS, POP3S), la comunicazione tra il nostro server e altri server mail su Internet (porta 25) è più complessa:

• Opportunistic TLS: Come menzionato, Postfix per default usa "opportunistic TLS" (smtp_tls_security_level = may per le connessioni in uscita, smtpd_tls_security_level = may per quelle in entrata). Questo significa che se l'altro server supporta STARTTLS, la connessione verrà crittografata. Altrimenti, avverrà in chiaro. Questo è lo standard attuale per la maggior parte del traffico email.

• DANE (DNS-based Authentication of Named Entities): È una tecnologia più avanzata (RFC 6698) che usa record DNS (TLSA) per pubblicare informazioni sui certificati TLS. Se DANE è configurato e Postfix è impostato su smtp_tls_security_level = dane (o dane-only), Postfix verificherà il certificato del server remoto tramite DNS, offrendo una maggiore protezione contro attacchi man-in-the-middle. L'implementazione di DANE richiede un'infrastruttura DNSSEC.

• MTA-STS (SMTP MTA Strict Transport Security): È uno standard più recente (RFC 8461) che permette ai domini di pubblicare policy che richiedono TLS per le email in entrata e specificano come i certificati devono essere validati.

Per la maggior parte delle configurazioni, iniziare con opportunistic TLS (may) è una scelta sicura e compatibile. L'adozione di DANE e MTA-STS è in crescita ma non ancora universale.

La vecchia guida menzionava la difficoltà di una PKI globale. Questo è ancora vero. Mentre TLS protegge il "canale" tra due server che comunicano, non garantisce l'autenticità del server remoto a meno che non si usino meccanismi come DANE o policy di verifica dei certificati più stringenti (che possono rompere la compatibilità).

La protezione del contenuto del messaggio end-to-end, indipendentemente dalla sicurezza del canale, è affrontata da tecnologie come GPG/OpenPGP o S/MIME, come discusso nella prossima sezione.

Protezione dei Messaggi con GnuPG (GPG)

Mentre TLS protegge la comunicazione tra client e server e tra server, non protegge il contenuto del messaggio end-to-end una volta che questo è memorizzato sui server o se un intermediario compromesso intercetta la comunicazione tra server che non usano TLS. Per garantire la confidenzialità (il messaggio può essere letto solo dal destinatario) e l'integrità/autenticità (il messaggio non è stato alterato e proviene effettivamente dal mittente dichiarato) del contenuto stesso dell'email, si può utilizzare la crittografia a chiave asimmetrica.

GnuPG (GPG), l'implementazione GNU di OpenPGP, è lo strumento standard per questo scopo su sistemi Linux.

GPG è solitamente preinstallato sulle versioni moderne di Ubuntu. Se non lo fosse, si può installare con:

sudo apt install gpg

La maggior parte dei client di posta moderni (es. Thunderbird con l'estensione Enigmail/OpenPGP, KMail, Evolution) offrono integrazione con GPG per semplificare la cifratura, decifratura e firma dei messaggi.

Concetti Fondamentali

• Coppia di Chiavi: Ogni utente genera una coppia di chiavi:

  • Una chiave privata, da conservare gelosamente e protetta da una passphrase robusta. Serve per decifrare i messaggi ricevuti e per firmare i messaggi inviati.

  • Una chiave pubblica, da distribuire liberamente. Serve agli altri per cifrare i messaggi da inviargli e per verificare le firme apposte da lui.

• Cifratura: Per inviare un messaggio confidenziale a qualcuno, si cifra il messaggio con la chiave pubblica del destinatario. Solo il destinatario, con la sua chiave privata corrispondente, potrà decifrarlo.

• Firma Digitale: Per garantire autenticità e integrità, si firma un messaggio (o il suo hash) con la propria chiave privata. Chiunque abbia la chiave pubblica del mittente può verificare la firma.

Esempio Pratico: Scambio di Messaggi Cifrati/Firmati

Supponiamo che l'utente pippo@example.com voglia scambiare messaggi protetti con pluto@prova.edu.

Generazione della Coppia di Chiavi (da fare per entrambi gli utenti)

L'utente pippo genera la sua coppia di chiavi, digitare nel terminale il seguente comando:

gpg --full-generate-key

GPG guiderà attraverso una serie di domande:

• Tipo di chiave: Scegliere l'opzione predefinita (es. "RSA and RSA" o "ECC and ECC"). Gli algoritmi moderni come RSA (con lunghezza di chiave di almeno 3072 o 4096 bit) o EdDSA (es. Ed25519 per la firma) e Curve25519 (per la cifratura) sono raccomandati. La vecchia guida menzionava ElGamal, che è meno comune oggi.

• Dimensione della chiave: Per RSA, scegliere almeno 3072 bit, preferibilmente 4096.

• Durata di validità della chiave: Si può impostare una scadenza o scegliere che non scada.

• Nome reale, indirizzo email, commento: Inserire le informazioni richieste. L'indirizzo email dovrebbe corrispondere a quello che si userà per la posta.

• Passphrase: Scegliere una passphrase robusta per proteggere la chiave privata.

L'utente pluto eseguirà lo stesso comando per generare la propria coppia di chiavi.

Visualizzare le Chiavi

• Per visualizzare le chiavi pubbliche nel proprio portachiavi (keyring):

  gpg --list-keys

• Per visualizzare le chiavi private:

  gpg --list-secret-keys

Esportare e Scambiare le Chiavi Pubbliche

pippo esporta la sua chiave pubblica:

gpg --export --armor -o pippo-pubkey.asc pippo@example.com

L'opzione --armor crea un output testuale ASCII (formato Radix-64), facile da scambiare. pippo-pubkey.asc conterrà la chiave pubblica.
pippo deve inviare questo file pippo-pubkey.asc a pluto (es. come allegato email, o tramite un keyserver pubblico).

Allo stesso modo, pluto esporterà la sua chiave pubblica (pluto-pubkey.asc) e la invierà a pippo.

Importare la Chiave Pubblica del Destinatario

pippo importa la chiave pubblica di pluto (supponendo abbia ricevuto il file pluto-pubkey.asc):

gpg --import pluto-pubkey.asc

Dopo l'importazione, è buona norma verificare il fingerprint della chiave con pluto attraverso un canale sicuro (es. telefono, di persona) per assicurarsi che la chiave sia autentica e non manomessa, e poi firmarla localmente per indicare che ci si fida di essa:

gpg --fingerprint pluto@prova.edu

Dopo la verifica del fingerprint:

gpg --edit-key pluto@prova.edu

Dentro il prompt di gpg, digitare 'sign' e seguire le istruzioni, poi 'save'.

Anche pluto importerà e verificherà/firmerà la chiave pubblica di pippo.

Cifrare e Firmare un Messaggio (Pippo invia a Pluto)

pippo vuole inviare il contenuto del file messaggio.txt a pluto, cifrandolo e firmandolo:

-s o --sign: Firma il messaggio.
-e o --encrypt: Cifra il messaggio.
-r pluto@prova.edu o --recipient pluto@prova.edu: Specifica il destinatario (GPG userà la sua chiave pubblica per cifrare).
-a o --armor: Crea un output testuale ASCII.
-o messaggio-protetto.asc: Specifica il file di output.
gpg --sign --encrypt --armor -r pluto@prova.edu -o messaggio-protetto.asc messaggio.txt
# Alternativa più breve: gpg -sea -r pluto@prova.edu -o messaggio-protetto.asc messaggio.txt

pippo ora può inviare il file messaggio-protetto.asc (o il suo contenuto) a pluto@prova.edu.

Decifrare e Verificare un Messaggio (Pluto riceve da Pippo)

pluto riceve messaggio-protetto.asc e lo decifra:

-d o --decrypt: Decifra il messaggio.
-o messaggio-originale.txt: Specifica il file di output per il contenuto decifrato.
gpg --decrypt -o messaggio-originale.txt messaggio-protetto.asc

GPG chiederà a pluto la passphrase della sua chiave privata per decifrare il messaggio. Durante la decifratura, GPG verificherà automaticamente anche la firma. L'output mostrerà:

gpg: Good signature from "Pippo <pippo@example.com>"

Se la firma è valida, significa che il messaggio proviene effettivamente da pippo e non è stato alterato. Se la firma fosse non valida (messaggio alterato o chiave del mittente errata), GPG mostrerebbe:

gpg: BAD signature from "Pippo <pippo@example.com>"

Il contenuto decifrato sarà in messaggio-originale.txt.

Questo esempio illustra l'uso da riga di comando. I client di posta elettronica con integrazione GPG automatizzano gran parte di questi passaggi, rendendo il processo più trasparente per l'utente finale.

Ulteriori risorse

• Sito ufficiale del progetto Postfix

• Sito ufficiale del progetto Dovecot

• Sito ufficiale del progetto SquirrelMail

CategoryHomepage CategoryNuoviDocumenti