#LANGUAGE it <
> <> <> = Introduzione = Questa guida illustra come installare e configurare un server mail. È utile prendersi il tempo necessario per pianificare un corretto partizionamento del disco, possibilmente dedicando una partizione per `/var/log` e una per `/var/spool/mail`. La gestione della posta elettronica in rete coinvolge tre attori : * un client di posta, che è il programma deputato alla formattazione dei messaggi di posta; * un Mail Transport Agent, MTA, che è un server che si occupa di instradare la posta al destinatario; * un delivery agent, DA, che è il server che si occupa di consegnare la posta al destinatario. Il meccanismo di instradamento è basato sull'associazione fra dominio di posta elettronica e dominio DNS. Pertanto, il MTA per consegnare la posta verso il destinatario utilizzerà interrogazioni DNS per effettuare la localizzazione del DA del destinatario. Nei sistemi UNIX, il MTA usa il protocollo SMTP mentre i DA usano i protocolli POP3 o IMAP. La fondamentale differenza fra i protocolli per il DA è che POP3 è progettato per il download dei messaggi sulla postazione client del destinatario, mentre IMAP consente di mantenerli sul server. Entrambe i protocolli presentano vantaggi e svantaggi. Inoltre, la configurazione qui presentata è arricchita con filtri anti-spam non nativi di '''postfix''' (si usa il prodotto '''spamassassin''') e con un software in grado di coordinare la scansione asincrona dei messaggi di posta attraverso l'uso dei filtri anti-spam e antivirus (questo prodotto è '''mailscanner'''). Verrà esaminata sia la configurazione del MTA per lo smistamento dei messaggi di utenti locali UNIX (ovvero gli utenti di sistema definiti con il comando '''adduser'''), che quella che utilizza come backend un DB LDAP (ovvero un servizio di directory standardizzato con gestione degli account di utenti di rete). = Installazione = [[AmministrazioneSistema/InstallareProgrammi|Installare]] i pacchetti necessari digitando nel [[AmministrazioneSistema/RigaDiComando|terminale]]:{{{ sudo apt-get install postfix postfix-ldap spamassassin dovecot-pop3d dovecot-imapd mailscanner }}} {{{#!wiki note Si ricorda che '''!MailScanner''' è disponibile solo per '''Ubuntu 12.04'''.}}} Per installare '''!MailScanner''' in versioni precedenti o successive alla 12.04 digitare questi ulteriori comandi:{{{ sudo apt-get install libconvert-binhex-perl libconvert-tnef-perl libdbd-sqlite3-perl libfilesys-df-perl libio-stringy-perl libmime-tools-perl libnet-cidr-perl libole-storage-lite-perl libsys-syslog-perl}}}{{{ wget https://launchpad.net/ubuntu/+archive/primary/+files/mailscanner_4.74.16-1_all.deb}}}{{{ sudo dpkg -i mailscanner_4.74.16-1_all.deb }}} = Mail transfer agent = I file di configurazione si trovano nella directory `/etc/postfix` e il file fondamentale è `main.cf`. Un altro file importante nella configurazione di postfix è `/etc/aliases`, che contiene tutti gli alias degli utenti di posta elettronica. == File /etc/aliases == Supponendo di avere un utente di sistema '''prova''', è possibile definire nel file `/etc/aliases` un alias come segue:{{{ p.miodominio.com: prova }}} che indica semplicemente che l'utente di sistema '''prova''' è identificato dal sistema MTA come '''p.miodominio.com'''. == File /etc/postfix/ldap-aliases.cf == È il corrispondente file di configurazione per i servizi LDAP e contiene le seguenti direttive:{{{ server_host = nome completo del server LDAP search_base = dc=miodominio,dc=com }}} dove ovviamente è necessario sostituire '''miodominio''' e '''com''' con il proprio ''basedn'' del dominio di ricerca LDAP. == File /etc/postfix/main.cf == Per configurare '''postfix''', aprire il file `/etc/postfix/main.cf` e modificare il messaggio di benvenuto: {{{ smtpd_banner = nostro messaggio di benvenuto }}} Quindi modificare le righe seguenti di conseguenza: {{{ myhostname = FQDN di questo server (es : wilcoyote.example.com) mydomain = dominio di posta (=dominio DNS nel caso di LAN) alias_maps = hash:/etc/aliases,ldap:/etc/postfix/ldap-aliases.cf }}} L'ultima stringa dice al MTA che deve controllare, per la risoluzione dei nomi utente, prima il file `/etc/aliases` e poi il database LDAP referenziato dalle direttive nel file `/etc/aliases`. Di seguito vengono riportate le direttive presenti nel file: * '''myorigin = $mydomain'''<
>indica che si invia posta soltanto per il proprio dominio * '''mydestination = dominio di posta, localhost.localdomain, localhost'''<
>(N.B. dominio di posta = dominio DNS nel caso di LAN) indica che si accetta posta indirizzata soltanto al proprio dominio o a localhost (127.0.0.1). * '''inet_interfaces = all'''<
>indica che il MTA all'avvio sta in ascolto su tutte le interfacce di rete. * '''smtpd_client_restrictions = reject_maps_rbl , reject_unknown_client , permit'''<
>iniziano le restrizioni d'accesso native di postfix: questa indica di non accettare posta indirizzata o provenienete da siti di possibili spammers (indicati nella direttiva '''maps_rbl_domains''') e di non accettare connessioni da clients che non hanno record A in DNS. * '''smtpd_sender_restrictions = reject_unknown_sender_domain , reject_non_fqdn_sender , permit'''<
>questa restrizione evita lo smistamento di posta proveniente da un mittente ignoto. * '''smtpd_recipient_restrictions = reject_unauth_destination , reject_non_fqdn_recipient , reject_unknown_recipient_domain , permit'''<
>questa restrizione non permette di effettuare il relay (ovvero non permette di inviare posta elettronica da mittenti che non siano di questo sito) e di non smistare posta proveniente da un mittente ignoto.<
>(N.B. La restrizione '''reject_unauth_destination''' dice al server di posta di impedire l'open relay e sostituisce la direttiva '''check_relay_domains'''). * '''smtpd_helo_restrictions = reject_invalid_hostname , reject_non_fqdn_hostname , reject_unknown_hostname , permit'''<
>queste restrizioni dicono di non accettare il saluto dal client che non risponda con un hostname esistente nel DNS (respingere se l'hostname presentato è invalido , non è nel formato FQDN o non ha record A o PTR nè MX nel DNS). Queste restrizioni sono molto importanti, poichè ad oggi molti spammers fanno uso di comandi helo-faked per velocizzare la spedizione di spam. * '''maps_rbl_domains = rbl.maps.vix.com,dul.maps.vix.com,relays.mail-abuse.org'''<
>questa restrizione indica di non smistare posta proveniente da o indirizzata verso i domini elencati. == Avvio di postfix == Ora può essere il servizio postfix del MTA con il comando:{{{ /etc/init.d/postfix start }}} Tutti i log files inerenti lo startup dei servizi '''postfix''' ed i relativi accessi sono contenuti nei files `/var/log/mail.warn`, `/var/log/mail.err`, `/var/log/mail.info`. == Ulteriore livello sicurezza == Par aggiungere un maggiore livello sicurezza, un'ulteriore direttiva da utilizzare nel file `main.cf` per limitare lo spam è la direttiva: * '''smtp_helo_restrictions = reject_invalid_hostname , reject_non_fqdn_hostname , reject_unknown_hostname , permit_nak*ed_ip_address , permit''' Questa restrizione opera nel modo seguente : * rifiuta l'accesso al servizio per client che non rispondono al messaggio di benvenuto del server Postfix con un nome host valido (gli spammers lo fanno spesso per risparmiare tempo); * rifiuta l'accesso al servizio MTA se il nome host passato di seguito al comando helo non è un fqdn hostname (cioè della forma mail.example.com); * rifiuta l'accesso al servizio MTA se l'hostname che segue il comando ''helo'' non può essere risolto (questo capita quando lo spammer mette di seguito al comando ''helo'' una stringa casuale, allora l'MTA interroga un DNS per risolvere il nome host immesso, se non lo trova rifiuta l'accesso); * consente l'accesso se di seguito al comando ''helo'' viene concatenato un IP. La direttiva '''permit''' in fondo alla stringa, dice che al di fuori delle restrizioni applicate tutto il resto viene accettato. {{{#!wiki note Restrizioni di questo tipo sono comunque da utilizzare con moderazioni perchè potrebbero impedire al servizio di funzionare correttamente.}}} = DA = Per la configurazione del DA (delivery agent) si proceda come segue: 0. Aprire con i [[AmministrazioneSistema/Sudo|privilegi di amministrazione]] e con un [[Ufficio/EditorDiTesto|editor di testo]] il file `/etc/dovecot/dovecot.conf`. 0. Impostare il parametro '''protocols''' come segue:{{{ protocols = pop3 pop3s imap imaps }}}questo abiliterà i servizi pop3(s) e imap(s) alla'avvio di dovecot. 0. Avviare il DA basta eseguire il comando:{{{ sudo /etc/init.d/dovecot start }}} 0. Attraverso l'output del comando:{{{ '''ps -A|grep dovecot''' noterete che il servizio }}}è possibile verificare che il programma si sia avviato con successo. = Web mail = Il servizio di posta elettronica fruibile dal browser web, '''webmail''', richiede che siano installati il web server e il programma '''!SquirrelMail''' per l'accesso alle mailboxe attraverso il browser web. 0. [[AmministrazioneSistema/InstallareProgrammi|Installare]] i pacchetti [[apt://apache2,squirrelmail|apache2, squirrelmail]]. 0. 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). 0. Per creare un nuovo ''virtual host'' aprire con i [[AmministrazioneSistema/Sudo|privilegi di amministrazione]] e con un [[Ufficio/EditorDiTesto|editor di testo]] modificare il file `/etc/apache2/sites-enabled/000-default` nel seguente modo: {{{ SSLCertificateFile /etc/apache2/ssl/apache.pem DocumentRoot /usr/share/squirrelmail ServerName webmail.example.com }}}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'''. 0. [[AmministrazioneSistema/InstallareProgrammi|Installare]] i pacchetti [[apt://clamav-daemon,clamav-freshclam|clamav-daemon, clamav-freshclam]]. 0. Aprire con i [[AmministrazioneSistema/Sudo|privilegi di amministrazione]] e con un [[Ufficio/EditorDiTesto|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. 0. Riavviate '''!MailScanner''' con il comando:{{{ #/etc/init.d/mailscanner restart }}} 0. È 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''' è [[AmministrazioneSistema/InstallareProgrammi|installabile]] attraverso il pacchetto [[apt://gpg|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à. {{{#!wiki note Per maggiori informazioni consultare la pagina [[Sicurezza/GnuPg|GnuPg]]. Viene qui riportato un esempio pratico in cui due utenti si scambiano messaggi crittati tramite '''GPG'''.}}} Supponiamo di avere l'utenti '''pippo@example.com''' che vuole spedire un messaggio protetto all'utente '''pluto@prova.edu'''. 0. 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. 0. '''pippo''' visualizza le chiavi create con il comando:{{{ gpg --list-keys }}} 0. '''pippo''' esporta la sua chiave pubblica nel repository comune utilizzando i comandi:{{{ gpg --export -o pippo}}}{{{ sftp pippo@publickeys:/keys/pippo }}} 0. '''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. 0. '''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 }}} 0. '''pippo''' spedisce il messaggio '''README.txt.gpg''' a '''pluto@prova.edu''' usando il suo mail server. 0. '''pluto''' importa la chiave pubblica di pippo con il comando:{{{ sftp pluto@publickeys:/keys/pippo}}}{{{ gpg --import pippo }}} 0. L'utente '''pluto''' va a decifrare il messaggio con il comando:{{{ gpg -o README.txt -d README.txt.gpg }}} 0. 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 = * [[http://www.postfix.org/|Sito ufficiale del progetto Postfix]] * [[http://www.dovecot.org/|Sito ufficiale del progetto Dovecot]] * [[http://www.squirrelmail.org/|Sito ufficiale del progetto SquirrelMail]] ---- CategoryServer CategoryDaRevisionare