Introduzione

Questa guida illustra come installare e configurare un server mail completo. L'obiettivo è 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:

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

  • 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 (es. Thunderbird, Outlook, K-9 Mail, o 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. In questa guida sarà utilizzato Postfix.

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

  • 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), 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

Durante l'installazione di postfix, 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 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.

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

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 sul 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. Vediamo 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). Dovrebbe essere già così 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:

# Protocolli abilitati. imaps e pop3s sono abilitati automaticamente se SSL è configurato.

protocols = imap pop3 lmtp

Formato e posizione della casella di posta

Dovecot deve sapere dove trovare le 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 file auth-system.conf.ext dovrebbe contenere qualcosa come:

     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, 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 ad esempio così:

   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

Questo dice a Postfix di 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, 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, aggiungere o modificare 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

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

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

CategoryHomepage CategoryNuoviDocumenti