Internet Service Provider con Debian
|
Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.
Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione. |
 Versioni Compatibili Debian 5 "lenny" Debian 6 "squeeze" Debian 7 "wheezy" |
Introduzione
In questa guida cercheremo di raccogliere tutte le informazioni per arrivare a un'installazione di Debian che fornisca i seguenti servizi, comuni presso qualsiasi Internet Service Provider:
- hosting di più domini web sullo stesso server
- spazio web e database MySQL separato per ogni dominio
- accesso via FTP alle directory root di ogni dominio in maniera separata
- fornitura di indirizzi mail personalizzati "@nomedominio.tld"
- fornitura di un sistema di webmail
Nota: questa guida non è adatta per chi ha necessità di installare un solo dominio e un solo servizio di posta sul suo server, ma è pensata per chi ha necessità di agire come un Virtual Internet Service Provider, con fornitura di servizi a terzi.
Prerequisiti
|
ATTENZIONE Non proseguite senza aver completato l'installazione e la configurazione di tutti i prerequisiti richiesti |
Si consideri di partire con un'installazione minimale di Debian effettuata da CD netinstall. Il server dovrà possedere un indirizzo IP pubblico e un FQDN (vedi Wikipedia).
Si configuri il file /etc/apt/sources.list in modo che contenga solo i repository ufficiali (vedi guide sul wiki) e si aggiorni il server con le ultime patch:
# apt-get update # apt-get upgrade
Può essere utile impostare anche un server NTP esterno per sincronizzare l'ora del nostro server con un'autorità nazionale: Impostare e modificare data e ora.
Poichè il server andrà quasi sicuramente gestito da remoto occorrerà installare e configurare anche l'accesso SSH (OpenSSH: configurazione di base) con autenticazione via chiave: Ssh e autenticazione tramite chiavi.
Installazione ambiente LAMP
Un ambiente LAMP è un acronimo per indicare un ambiente composto da Linux + Apache + MySQL + PHP. Per l'installazione e la configurazione di un ambiente LAMP si segua la guida omonima presente sul wiki: Installare un ambiente LAMP: Linux, Apache2, SSL, MySQL, PHP5.
Nota: il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.
Installazione Virtual Host di Apache
Arrivati a questo punto ci troviamo con un server web perfettamente funzionante, ma che ancora non sa come gestire i diversi domini che andranno ospitati sul server.
Per configurare Apache con il supporto ai Virtual Hosts si segua la guida sul wiki: Apache e Virtual Hosts: configurare Apache2 per ospitare più siti web.
Nota: il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.
Protezione del web server Apache
Poichè il nostro server sarà esposto al web 24 ore al giorno dovremo premunirci installando alcune protezioni. Un buono spunto per incominciare può essere la guida: Hardening di un web server Apache.
Potrebbe essere una buona idea implementare anche alcuni sistemi di monitoraggio, ad esempio quelli trattati nelle guide seguenti:
Fail2ban
Impedire attacchi SSH brute-force con Denyhosts
Configurazione dei record DNS
Per fare in modo che i PC connessi a internet possano sapere che tutti i siti configurati sono ospitati su un server che risponde a un solo indirizzo IP pubblico (che supponiamo sia 1.2.3.4) è necessario configurare i record DNS di ogni dominio in questo modo:
www => 1.2.3.4 A ftp => 1.2.3.4 A @ => 1.2.3.4 A mail => 1.2.3.4 MXE
Con questa configurazione attiveremo quindi tre sottodomini, uno per il web (www), uno per l'FTP (ftp) e uno per il mailserver del dominio (mail).
Installazione FTP server
L'installazione di un server FTP con utenti virtuali permetterà ad ogni proprietario di un dominio ospitato sul nostro server di accedere via FTP allo spazio web a sua disposizione, senza poter navigare all'interno del filesystem del server e all'interno degli spazi web riservati agli altri domini. Per l'installazione di un server FTP con utenti virtuali si segua la guida: Installare un server FTP con utenti virtuali su MySQL oppure Installare un server vsFTPd con utenti virtuali su MySQL.
Installazione del server di posta
Schema di funzionamento
I software utilizzati per configurare il server di posta saranno i seguenti:
- Postfix per inviare e ricevere mail da internet e effettuare i primi controlli basilari
- Dovecot per archiviare le mail sul server e fornire agli utenti accesso alle loro caselle tramite POP3 e IMAP
- Roundcube come interfaccia Webmail
- MySQL come database backend per archiviare informazioni su domini, account utente e email forwarding
- AMaViS per effetuare la scansione delle mail in arrivo utilizzando ClamAV e SpamAssassin
- Clam Antivirus come controllo antivirus
- SpamAssassin come filtro antispam
Una volta a regime, il server di posta sarà configurato in questa maniera:
- una email viene spedita attraverso il nostro SMTP sulla porta 25. Postfix accetta la connessione e effettua alcuni controlli:
- il mittente è in blacklist o in whitelist?
- la mail proviene da un utente autenticato sul server e può superare i controlli di relay?
- il destinatario è un utente valido del sistema?
- Postfix inoltra la mail sul protocollo TCP alla porta 10024, dove AMaViS effettua il controllo del contenuto. AMaViS è configurato per aggiungere alcuni header alla mail, in modo che gli utenti possano filtrarla o meno come spam.
- La mail viene poi girata a SpamAssassin per un controllo antispam più accurato
- Poi interviene ClamAV, che ne controlla il contenuto alla ricerca di virus
- Dopo questi controlli AMaViS restituisce la mail a Postfix sulla porta TCP 10025
- Postfix è configurato per non controllare il traffico in arrivo su questa porta e gira la mail a Dovecot senza ulteriori controlli
- Dovecot salva la mail sul server in formato Maildir
- L'utente può ora leggere la sua email attraverso i protocolli POP3 o IMAP
Domini locali e virtuali
Normalmente Postfix lavora con i cosiddetti Domini Locali, configurati nella direttiva mydestination del suo file di configurazione, e con gli utenti di sistema, elencati nel file /etc/passwd.
Questo comporta che ogni utente possa ricevere la posta di tutti i domini. Supponiamo di avere la direttiva:
mydestination = example1.com, example2.com, example3.com
Questo semplice setup fa sì che l'utente di sistema johndoe riceva le email indirizzate a:
johndoe@example1.com johndoe@example2.com johndoe@example3.com
Non è possibile impedire la ricezione della posta indirizzata a un singolo dominio e questo, unitamente al fatto che gestire molti utenti in questa maniera è inefficiente, rende il sistema poco pratico.
Questi problemi possono essere evitati facendo uso dei cosiddetti Domini Virtuali, che a loro volta gestiranno utenti virtuali e alias virtuali di posta. Nel corso della guida vedremo come questa tecnica sarà implementata attraverso alcune direttive Postfix e con il supporto di un database MySQL.
Preparazione del sistema
Controlliamo che il nostro /etc/hosts sia impostato correttamente:
- Sbagliato:
20.30.40.50 mailserver42 mailserver42.example.com
- Corretto:
20.30.40.50 mailserver42.example.com mailserver42
Installazione dei pacchetti necessari
Incominciamo con l'installare il server Postfix con la sua estensione per il supporto a MySQL:
# aptitude install postfix postfix-mysql
Questo comando installerà automaticamente anche il pacchetto postfix e rimuoverà Exim, il mail server installato di default da Debian.
Quando richiesti dall'installer di Postfix, scegliete "Sito internet" come tipo di configurazione e inserite il FQDN (Fully Qualified Domain Name) del vostro server.
Rimuoviamo poi i resti di Exim eventualmente rimasti nel sistema:
# apt-get --purge remove 'exim4*'
Poichè intendiamo offrire ai nostri utenti anche i servizi POP3 e IMAP dobbiamo installare il demone Dovecot:
# apt-get install dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-managesieved
Alcuni pacchetti utilizzati in questa guida per la scansione degli allegati di posta elettronica non sono inclusi nella sezione main dei repository di Debian (ad esempio unrar e lha); per poterli installare dobbiamo prima modificare il nostro /etc/apt/sources.list aggiungendo la sezione non-free:
deb http://ftp.debian.org/debian/ wheezy main contrib non-free
Aggiorniamo la lista dei pacchetti disponibili:
# aptitude update
e installiamo i pacchetti necessari al filtraggio dello spam e alla scansione delle email:
# aptitude install amavisd-new spamassassin clamav-daemon lha arj unrar zoo nomarch cpio lzop cabextract
AMaViS è ora installato nel nostro sistema, insieme a una serie di pacchetti per la scansione delle email.
Dato che vogliamo offrire anche un servizio di Webmail, installeremo anche il pacchetto Roundcube:
# apt-get install roundcube roundcube-plugins
Rispondete così alle domande che vi vengono poste dall'installer:
- Configurare Roundcube con dbconfig-common: sì
- Database: MySQL
- Database's administrative user's password: la password di root di MySQL
- Password di database per Roundcube: inventare una password forte
Infine installiamo il client mail Pop3 / Imap mutt, che funziona da console e che può essere utile per testare la nostra configurazione strada facendo
# aptitude install mutt
e un tool preziosissimo, SWAKS (SWiss Army Knife for Smtp):
# apt-get install swaks
|
|
ATTENZIONE DEPRECATO: al posto di Roundcube è possibile installare una diversa interfaccia webmail, Squirrelmail: |
# aptitude install squirrelmail
L'installazione di Squirrelmail su Debian Squeeze incontra un problema:
# aptitude install squirrelmail
The following packages have unmet dependencies:
apache2-mpm-prefork: Conflicts: apache2-mpm which is a virtual package.
apache2-mpm-worker: Conflicts: apache2-mpm which is a virtual package.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) apache2-mpm-worker [Not Installed]
Accept this solution? [Y/n/q/?]
ma la soluzione proposta da aptitude è corretta; rispondiamo quindi con Y alla domanda.
Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.
Creazione del certificato SSL
Creiamo il certificato da utilizzare per i servizi SSL:
# openssl req -new -x509 -days 3650 -nodes -newkey rsa:4096 -out /etc/ssl/certs/mailserver.pem -keyout /etc/ssl/private/mailserver.pem
e proteggiamolo:
# chmod 600 /etc/ssl/private/mailserver.pem
Preparazione del database
Creazione del database
Come prima cosa creeremo un nuovo database MySQL, che chiameremo mailserver:
# mysqladmin -p create mailserver
Ci verrà chiesta la passord dell'utente root di MySQL e poi sarà creato il nuovo database.
Aggiunta di un utente MySQL con privilegi limitati
Per ragioni di sicurezza creiamo un nuovo utente mySQL con privilegi limitati verso il database mailserver:
# mysql -p
Vedremo il prompt trasformarsi in mysql>, la shell di MySQL, e saremo pronti per creare l'utente mailuser con password mailuser2009:
mysql> GRANT SELECT ON mailserver.*
TO 'mailuser'@'127.0.0.1'
IDENTIFIED BY 'mailuser2009';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
Creazione delle tabelle del database
A questo punto dobbiamo creare all'interno del database le tabelle per archiviare le informazioni sui domini, sugli alias, i forwarding e le mailbox degli utenti.
Connettiamoci di nuovo a MySQL e scegliamo il database mailserver e creiamo la prima tabella, per registrare i domini virtuali:
# mysql -p mailserver
mysql> CREATE TABLE `virtual_domains` ( `id` int(11) NOT NULL auto_increment, `name` varchar(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
La tabella successiva conterrà le informazioni sugli utenti virtuali di Postfix; sarà utilizzata per autenticare le richieste POP3, SMTP, IMAP e Webmail. L'indirizzo email dell'utente sarà utilizzato anche come username per il login:
mysql> CREATE TABLE `virtual_users` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `password` varchar(32) NOT NULL, `email` varchar(100) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Il campo email conterrà l'indirizzo mail/username; il campo password conterrà un hash MD5 della password degli utenti. L'attributo unique key sul campo email ci eviterà di creare per errore due indirizzi email identici.
Come ultima cosa creiamo una tabella per gli alias, necessaria per forwardare le email da un indirizzo a un altro:
mysql> CREATE TABLE IF NOT EXISTS `virtual_aliases` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `source` varchar(100) NOT NULL, `destination` varchar(100) NOT NULL, PRIMARY KEY (`id`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Sono state impostate alcune foreign keys: servono per collegare i record delle tabelle virtual_aliases e virtual_users con i record nella tabella virtual_domains. Questo ci permetterà di mantenere consistenti i dati nel database, perchè non potremo creare utenti virtuali o alias virtuali non collegati ad alcun dominio virtuale.
Il suffisso ON DELETE CASCADE significa che rimuovendo un dominio virtuale saranno cancellate anche tutti gli utenti virtuali e gli alias collegati al dominio, evitando di lasciare nel database dei record orfani.
Esempio di contenuto delle tabelle
----------------- virtual_domains ----------------- id | name 1 | example.com 2 | foobar.org --------------------------------- virtual_users --------------------------------- id | domain_id | email | password 1 | 1 | john@example.com | 14cbfb845af1f030e372b1cb9275e6dd 2 | 1 | steve@example.com | a57d8c77e922bf756ed80141fc77a658 3 | 2 | kerstin@foobar.org | 5d6423c4ccddcbbdf0fcfaf9234a72d0 ----------------------------------- virtual_aliases ----------------------------------- id | domain_id | source | destination 1 | 1 | steve@example.com | devnull@workaround.org 2 | 2 | kerstin@foobar.org | kerstin42@yahoo.com 3 | 2 | kerstin@foobar.org | kerstin@mycompany.com
Mappatura di Postfix verso MySQL
Il database è ora pronto per essere riempito con informazioni sugli account utente, ma dobbiamo ancora istruire Postfix affinché possa recuperare le informazioni archiviate nel database.
Verifichiamo innanzitutto che la direttiva mydestination nel file di configurazione di Postfix non contenga riferimenti ai domini che creeremo all'interno del database:
# nano /etc/postfix/main.cf
La riga deve apparire come segue:
mydestination = mailserver.example.com, localhost, localhost.example.com
ma non deve contenere l'indicazione del dominio:
mydestination = example.com
altrimenti Postfix cercherà di smistare la posta del dominio senza passare dalla mappatura su Postfix.
virtual_mailbox_domains
Incominciamo con il dire a Postfix quali domini virtuali stiamo gestendo. Per fare in modo che Postfix utilizzi MySQL per definire una mappatura abbiamo bisogno di un file di configurazione, quindi per prima cosa ne creeremo uno:
# nano /etc/postfix/mysql-virtual-mailbox-domains.cf
con contenuto pari al seguente:
user = mailuser password = mailuser2009 hosts = 127.0.0.1 dbname = mailserver query = SELECT 1 FROM virtual_domains WHERE name='%s'
|
NOTA Potrebbe venirvi la tentazione di scrivere "localhost" al posto di "127.0.0.1" nel file precedente. Non va fatto!! "localhost" farà sì che Postfix cerchi il file socket MySQL, non trovandolo perchè gira in una chroot hail. Al contrario "127.0.0.1" utilizzerà una connessione TCP sulla porta 3306, che risponderà anche se Postfix funziona all'interno di una gabbia chroot |
Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura:
# postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
Il comando postconf -e aggiunge la riga specificata al file di configurazione di Postfix /etc/postfix/main.cf e attiva istantaneamente la nuova impostazione, senza richiedere il riavvio di Postfix.
Da adesso Postfix cercherà le informazioni sui domini virtuali all'interno del database.
Verifichiamo che tutto funzioni, creando il nostro primo dominio virtuale:
# mysql -p mailserver mysql> INSERT INTO virtual_domains (id, name) VALUES (1, 'example.com'); exit
e interrogando Postfix:
# postmap -q example.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
Dovremmo ottenere come risultato 1.
Note
- Se otteniamo l'errore
postmap: warning: connect to mysql server 127.0.0.1: Access denied...significa che abbiamo dei problemi con l'accountmailuserche utilizziamo per la connessione a MySQL. Occorre verificare i privilegi di questo utente in MySQL. - Se otteniamo l'errore
postmap: warning: connect to mysql server 127.0.0.1: Can't connect to MySQL server on '127.0.0.1'significa che il demone MySQL non è in funzione o che non è in ascolto su 127.0.0.1. Occorre verificare la configurazione aprendo il file/etc/mysql/my.cnf
virtual_mailbox_maps
Ora dobbiamo definire la mappatura tra l'indirizzo email dell'utente e il percorso sull'hard disk della corrispondente mailbox dell'utente.
Poichè la consegna delle email sarà compito del demone Dovecot, a Postfix occorre solo controllare se un certo indirizzo email è valido.
Incominciamo con il creare il primo record nella tabella virtual_users:
mysql>
INSERT INTO virtual_users (id, domain_id, email, password)
VALUES (1, 1, 'john@example.com', MD5('summersun'));
Il percorso della mailbox sarà fisso, nella forma /var/vmail/$DOMAIN/$USER e non è perciò importante archiviare o recuperare questa informazione dal database.
Creiamo il file di configurazione per questa mappatura:
# nano /etc/postfix/mysql-virtual-mailbox-maps.cf
e diamogli come contenuto:
user = mailuser password = mailuser2009 hosts = 127.0.0.1 dbname = mailserver query = SELECT 1 FROM virtual_users WHERE email='%s'
Istruiamo Postfix a tenere in conto la nuova mappatura:
# postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
e verifichiamo che tutto funzioni correttamente:
# postmap -q john@example.com mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
Come prima, dovremmo ottenere come risultato 1.
virtual_alias_maps
La mappatura virtual_alias_maps è usata per forwardare le email da un indirizzo ad un altro.
Aggiungiamo come prima cosa alcuni forward al nostro database:
mysql>
INSERT INTO virtual_aliases (id, domain_id, source, destination)
VALUES (1, 1, 'john@example.com', 'john@example.com'),
(2, 1, 'john@example.com', 'devnull@workaround.org');
Quindi creiamo un altro file di configurazione:
# nano /etc/postfix/mysql-virtual-alias-maps.cf
con contenuto:
user = mailuser password = mailuser2009 hosts = 127.0.0.1 dbname = mailserver query = SELECT destination FROM virtual_aliases WHERE source='%s'
Assicuriamoci che Postfix utilizzi questa mappatura:
# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf
e verifichiamo che tutto funzioni correttamente:
# postmap -q john@example.com mysql:/etc/postfix/mysql-virtual-alias-maps.cf
Dovremmo ottenere i due indirizzi di forward john@example.com,devnull@workaround.org
email-to-email mapping
Prima di configurare Postfix per la mappatura virtual_alias_maps c'è ancora una cosa di cui dobbiamo preoccuparci. C'è uno particolare tipo di email forward chiamato catchall alias. Il catchall alias cattura tutte le email di un dominio per le quali non è definito un account.
Creiamo l'ultimo file di mappatura necessario:
# nano /etc/postfix/mysql-email2email.cf
e diamogli come contenuto:
user = mailuser password = mailuser2009 hosts = 127.0.0.1 dbname = mailserver query = SELECT email FROM virtual_users WHERE email='%s'
Verifichiamo che gli utenti con un account valido non vedano le loro email trattate come catchall alias:
# postmap -q john@example.com mysql:/etc/postfix/mysql-email2email.cf
Il risultato dovrebbe essere lo stesso indirizzo email: john@example.com
A questo punto possiamo istruire Postfix a utilizzare le ultime mappature definite:
# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
Perfetto!
Tutte le mappature sono state definite e il database è pronto per essere riempito con domini e utenti.
Proibire l'invio di email con mittenti arbitrari
Nella configurazione impostata fino ad adesso ogni utente autenticato sul server SMTP può spedire email da qualsiasi indirizzo. Pur essendo una configurazione perfettamente funzionante, le impostazioni necessitano a mio avviso di qualche miglioramento.
Iniziamo con l'aggiungere le seguenti linee al file:
# nano /etc/postfix/main.cf
smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cf smtpd_sender_restrictions = reject_unknown_sender_domain,reject_non_fqdn_sender,reject_sender_login_mismatch
Quindi creiamo un nuovo file:
# nano /etc/postfix/mysql-sender-login-maps.cf
con contenuto:
user = mailuser password = mailuser2009 hosts = 127.0.0.1 dbname = mailserver query = ( SELECT GROUP_CONCAT( a.`destination` ) FROM `virtual_aliases` a, `virtual_domains` d WHERE a.`source`='%s' AND a.`domain_id`=d.`id` AND d.`name`='%d' ) UNION ( SELECT `email` FROM `virtual_users` WHERE `email`='%s' )
A questo punto possiamo testare la configurazione aggiunta:
# postmap -q email@domian.tld mysql:/etc/postfix/mysql-sender-login-maps.cf
Dovremmo ottenere come risultato il nostro indirizzo email o i nostri alias, a seconda di come abbiamo configurato l'utente.
Da questo momento in poi ogni utente potrà inviare email utilzzando il proprio indirizzo email o uno dei propri alias come mittente e non potrà più inviare email con mittenti arbitrari.
Protezione dei file di configurazione
Poichè la password di connessione al database è archiviata nei file di configurazione appena creati, facciamo in modo che solo l'utente root possa leggerli:
# chgrp postfix /etc/postfix/mysql-*.cf # chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf
Configurazione di Postfix per Dovecot
Nel capitolo precedente abbiamo fatto in modo che Postfix venisse a conoscenza di quali mail è autorizzato a ricevere.
Ma come vanno trattate queste mail?
Il nostro obiettivo è archiviare le mail sull'hard disk del server; normalmente questo compito è svolto dallo stesso Postfix, che al suo interno ha un piccolo mail delivery agent (MDA) chiamato virtual. Poichè però abbiamo deciso di utilizzare Dovecot per fornire accesso POP3 e IMAP agli utenti, utilizzeremo anche il suo local delivery agent (chiamato Dovecot LDA), che è a mio avviso più ricco e funzionale di virtual.
Per fare in modo che Postfix utilizzi questo agent dobbiamo aggiungere un servizio in coda al file /etc/postfix/master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient}
Nota: la seconda riga deve essere indentata con degli spazi e non con il TAB.
A questo punto non resta che riavviare Postfix:
# service postfix restart
e fare in modo che utilizzi il servizio appena creato per lo smistamento delle email, modificando il file /etc/postfix/main.cf nella maniera vista in precedenza:
# postconf -e virtual_transport=dovecot # postconf -e dovecot_destination_recipient_limit=1
Da adesso in poi Postfix smisterà le email in arrivo al programma di Dovecot /usr/lib/dovecot/deliver.
Configurazione di Dovecot
E' ora di configurare Dovecot, che svolgerà i seguenti compiti:
- ricevere le email da Postfix e salvarle su disco
- controllare le quote disco
- eseguire regole e filtri user-based
- mettere a disposizione i protocolli POP3 e IMAP per gli utenti
Prima di iniziare, però, è bene concedere un occhio alla sicurezza creando un nuovo utente di sistema a cui attribuiremo la proprietà di tutte le mailboxes. Con il comando seguente creeremo l'utente vmail con UID 5000 e il gruppo vmail con GID 5000. Ovviamente è bene controllare che i valori UID e GID non siano già in uso nel sistema; altrimenti sarà possibile utilizzare un qualsiasi valore non in uso compreso tra 1000 e 65000:
# groupadd -g 5000 vmail # useradd -g vmail -u 5000 vmail -d /var/vmail -m
Assicuriamoci che la directory abbia i giusti permessi:
# chown -R vmail:vmail /var/vmail # chmod u+w /var/vmail
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in /etc/dovecot.
Fino a Debian Squeeze la configurazione di Dovecot era tutta contenuta in due file; da Debian Wheezy la configurazione è stata spezzata in una trentina di file, contenuti tutti nella directory /etc/dovecot/conf.d. Il file di configurazione principale /etc/dovecot/dovecot.conf non richiede alcuna modifica e attraverso la direttiva
!include conf.d/*.conf
carica tutti i file presenti in /etc/dovecot/conf.d/ che terminano in ".conf" in sequenza. Quindi "10-auth.conf" sarà caricato per primo e "90-quota.conf" per ultimo. Il grosso vantaggio di questa situazione è che potremo modificare o rimpiazzare parti della configurazione senza sovrascriverla interamente; lo svantaggio è che la migrazione da una versione precedente di Dovecot può diventare un'operazione difficoltosa.
Fino a Debian Squeeze
Inziamo con il file principale.
/etc/dovecot/dovecot.conf
Cerchiamo la linea protocols e definiamo i protocolli che vogliamo offrire agli utenti. Di default troveremo:
protocols = imap imaps pop3 pop3s
Dovecot avvierà quindi i servizi POP3 e IMAP e i loro equivalenti su una connessione crittata SSL.
Sebbene sia un'impostazione meno sicura, probabilmente avremo bisogno di impostare la direttiva:
disable_plaintext_auth = no
Questa impostazione permetterà le password in plaintext su connessioni non sicure (non SSL). Di default la direttiva è impostata su yes per motivi di sicurezza; impostarla a no abbasserà la sicurezza della transazione, ma permetterà il funzionamento anche di alcuni client di una certa Corporation famosa, che non rispettano alcuni standard dei protocolli IMAP e POP3 e che altrimenti avrebbero problemi. Per lamentele rivolgetevi a Microsoft e non floodate il bugzilla di Dovecot.
Un'altra importante direttiva è:
mail_location = maildir:/var/vmail/%d/%n/Maildir
che imposta il percorso e il formato delle mailboxes degli utenti in una forma standard:
/var/vmail/DOMAIN/USER/Maildir
Nel file dovrebbe già essere presente una sezione chiamata namespace private, ma dovrebbe risultare commentata con #.
Lasciamola commentata e cerchiamo la sezione chiamata auth default. In primo luogo dobbiamo modificare il meccanismo di autenticazione:
mechanisms = plain login
Scorrendo la sezione troveremo i diversi backends che Dovecot può utilizzare per accedere ai dati delle mail degli utenti. All'interno di questo elenco dobbiamo configurare il backend SQL:
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
che dice a Dovecot che le password sono archiviate in un database SQL, e successivamente:
userdb static {
args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
}
che indica a Dovecot dove sono situate tutte le mailboxes.
Ricordiamoci anche di commentare l'autenticazione pam, disabilitandola, dato che non utilizzeremo questo tipo di password check:
# passdb pam {
# Commentare tutte le linee
# }
L'utente viene autenticato attraverso la sezione passdb sql section, dopo di che viene indirizzato alla mailbox secondo le direttive della voce userdb static. Utilizzare la direttiva userdb sql non è necessario dato che tutte le mailboxes hanno un percorso fisso.
Probabilmente vorremo anche commentare la sezione chiamata passdb pam per evitare cheper recapitare le email Dovecot cerchi anche tra i system users.
Ora cerchiamo la sezione chiamata socket listen. Qui è dove vengono definiti i socket file che verranno usati per interagire con il meccanismo di autenticazione di Dovecot. Impostiamola come segue:
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
La sezione master è necessaria per fornire al Delivery Agent di Dovecot accesso alle informazioni sugli utenti. La sezione client crea un socket all'interno della directory chroot di Postfix: una parte di Postfix gira infatti di default in un ambiente chroot all'interno della directory /var/spool/postfix.
L'ultima sezione da modificare è quella marcata come protocol lda. Il servizio LDA (local delivery agent) di Dovecot è più potente e scalabile di quello built-in di Postfix: permette ad esempio le quote e i filtraggi Sieve. Modifichiamo quindi la sezione come segue:
protocol lda {
log_path = /var/log/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@example.com
mail_plugins = cmusieve
}
Si noti che in Debian Squeeze il plugin di Sieve ha cambiato nome e la sezione va quindi modificata come segue:
protocol lda {
log_path = /var/log/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@example.com
mail_plugins = sieve
}
Cambiate ovviamente l'indirizzo email del postmaster. L'impostazione log_path è facoltativa, ma può essere d'aiuto nel debuggare eventuali comportamenti inaspettati di certi filtri server-side. Prepariamo il file di log con i corretti permessi:
# touch /var/log/dovecot-deliver.log # chown vmail:adm /var/log/dovecot-deliver.log # chmod 640 /var/log/dovecot-deliver.log
Poichè il log dovecot-deliver.log può crescere molto velocemente di dimensione potrebbe essere opportuno impostare un file di configurazione per logrotate:
# nano /etc/logrotate.d/dovecot-deliver
con il seguente contenuto:
/var/log/dovecot-deliver.log {
weekly
rotate 14
compress
create 640 vmail adm
}
Modificate inoltre il file /etc/dovecot/dovecot-sql.conf e cambiate le seguenti impostazioni:
driver = mysql connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009 default_pass_scheme = PLAIN-MD5 password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
|
Suggerimento A partire da Debian Squeeze affinché Dovecot resti in ascolto sia su IPv4 sia su IPv6 è necessario aggiungere al file /etc/dovecot/dovecot.conf anche la riga:
listen = [::] * |
Infine riavviamo Dovecot:
# /etc/init.d/dovecot restart
Nel file di log /var/log/mail.log dovremmo vedere:
dovecot: Dovecot v1.0.rc15 starting up dovecot: auth-worker(default): mysql: Connected to 127.0.0.1 (mymailserver)
Prima di mandare la nostra prima email di test occorre ancora correggere i permessi su alcuni file di configurazione, in modo che l'utente vmail, l'utente con cui gira Postfix, possa accedere alla configurazione di Dovecot:
# chgrp vmail /etc/dovecot/dovecot.conf # chmod g+r /etc/dovecot/dovecot.conf
Infine facciamo in modo che solo l'utente root abbia i permessi per leggere il file dove abbiamo archiviato la password di connessione al database MySQL:
# chown root:root /etc/dovecot/dovecot-sql.conf # chmod go= /etc/dovecot/dovecot-sql.conf
Da Debian Wheezy
Diamo uno sguardo ai file presenti nella directory di configurazione conf.d.
10-auth.conf
Se ci aspettiamo di dover servire client che utilizzano Microsoft Outlook come applicazione per la posta elettronica, dovremo cambiare il meccanismo di autenticazione in:
auth_mechanisms = plain login
Alla fine del file troveremo elencati i vari backend di autenticazione che Dovecot può utilizzare. Di default utilizza l'autenticazione tramite system users, ma a noi interessa abilitare un database MySQL, quindi modifichiamo la sezione come segue:
#!include auth-system.conf.ext !include auth-sql.conf.ext #!include auth-ldap.conf.ext #!include auth-passwdfile.conf.ext #!include auth-checkpassword.conf.ext #!include auth-vpopmail.conf.ext #!include auth-static.conf.ext
auth-sql.conf.ext
Modifichiamo ora il file di configurazione SQL.
Commentiamo la sezione standard "userdb" e aggiungiamo:
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/vmail/%d/%n
}
Attenzione: deve esserci attiva una sola sezione "userdb".
Attenzione: c'è un'altra sezione molto simile, ma utilizza "%u" al posto di "%d/%n". Occorre stare attenti a non confonderle, perchè la differenza di variabili influenza il percorso di memorizzazione delle maildir.
10-mail.conf
Cambiamo la direttiva mail_location in
mail_location = maildir:/var/vmail/%d/%n/Maildir
Questa sarà la directory dove Dovecot cercherà le email di ogni specifico utente. Ad esempio l'utente john@example.org avrà le sue email archiviate in /var/vmail/example.org/john/Maildir.
Cambiamo la direttiva auth_socket_path in
auth_socket_path = /var/run/dovecot/auth-master
Cerchiamo la sezione namespace inbox. Se abbiamo già archiviato email sul server e stiamo aggiornando il nostro sistema da Squeeze a Wheezy, allora dobbiamo modificare la direttiva separator in:
separator = .
per mantenere la retrocompatibilità della configurazione.
10-master.conf
Nella sezione service auth dobbiamo inserire:
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
Gli altri servizi possono essere lasciati come sono.
10-ssl.conf
In precedenza abbiamo creato un certificato SSL per i servizi Pop3 3 Imaps. Questo è il momento di dire a Dovecot dove si trovano questi certificati, inserendo:
ssl_cert = </etc/ssl/certs/mailserver.pem ssl_key = </etc/ssl/private/mailserver.pem
15-lda.conf
In questo file dobbiamo abilitare il plugin sieve, che, in parole povere, è un sistema per gestire le regole email a livello server. Cerchiamo la sezione protocol lda verso la fine del gile e aggiungiamo sieve alla lista dei plugin:
protocol lda {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
}
/etc/dovecot/dovecot-sql.conf.ext
Questo file è richiamato dal file /etc/dovecot/conf.d/auth-sql.conf.ext e dice a Dovecot come accedere al database MySQL e dove trovare le informazioni sugli account. Accertiamoci che contenga le linee:
driver = mysql connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009 default_pass_scheme = PLAIN-MD5 password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
ponendo attenzione a inserire le credenziali MySQL create in precedenza.
Protezione dei file
Impostiamo le giuste credenziali per il file di configurazione principale:
# chgrp vmail /etc/dovecot/dovecot.conf # chmod g+r /etc/dovecot/dovecot.conf
per lo spool di Postfix:
# chown postfix:postfix /var/spool/postfix/private/auth # chmod 666 /var/spool/postfix/private/auth
e proteggiamo il file di configurazione SQL in modo che nessuno possa scoprire la password del database:
# chown root:root /etc/dovecot/dovecot-sql.conf.ext # chmod go= /etc/dovecot/dovecot-sql.conf.ext
Infine riavviamo Dovecot:
# service dovecot restart
e verifichiamo dai log che non ci siano errori:
# tail -f /var/log/mail.log ... dovecot: master: Dovecot v2.1.7 starting up (core dumps disabled)
Test della configurazione
Apriamo un altro terminale e controlliamo i log della posta in tempo reale:
# tail -f /var/log/mail.log
Dal primo terminale aperto proviamo a inviare una semplice prima mail di prova:
# echo test | mail john@example.org
Nei log dovremmo trovare qualcosa di simile:
Oct 20 17:42:32 sirius postfix/pickup[22273]: A6F8EB55: uid=0 from=<root> Oct 20 17:42:32 sirius postfix/cleanup[22582]: A6F8EB55: message-id=<20131020154232.A6F8EB55@sirius.localdomain> Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: from=<root@sirius.workaround.org>, size=287, nrcpt=1 (queue active) Oct 20 17:42:32 sirius dovecot: auth-worker(22635): mysql(127.0.0.1): Connected to database mailserver Oct 20 17:42:32 sirius dovecot: lda(john@example.org): msgid=<20131020154232.A6F8EB55@sirius.localdomain>: saved mail to INBOX Oct 20 17:42:32 sirius postfix/pipe[22586]: A6F8EB55: to=<john@example.org>, relay=dovecot, delay=0.14, delays=0.04/0/0/0.1, dsn=2.0.0, status=sent (delivered via dovecot service) Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: removed
All'interno della directory principale di archiviazione, Dovecot dovrebbe aver creato tutta la struttura di directory per il dominio e per l'utente di test:
# find /var/vmail /var/vmail/ /var/vmail/example.org /var/vmail/example.org/john /var/vmail/example.org/john/Maildir /var/vmail/example.org/john/Maildir/dovecot.index.log /var/vmail/example.org/john/Maildir/cur /var/vmail/example.org/john/Maildir/dovecot-uidvalidity.5263f9e8 /var/vmail/example.org/john/Maildir/new /var/vmail/example.org/john/Maildir/new/1382283752.M737526P22632.sirius,S=352,W=362 /var/vmail/example.org/john/Maildir/dovecot-uidvalidity /var/vmail/example.org/john/Maildir/tmp /var/vmail/example.org/john/Maildir/dovecot-uidlist /var/vmail/example.org/john/Maildir/dovecot.index.cache
Invio di email tramite telnet
Installiamo innanzitutto il pacchetto telnet:
# aptitude install telnet
Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server:
# telnet localhost smtp
Dovremmo ottenere come risposta:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailtest ESMTP Postfix (Debian/GNU)
Ottimo. Postfix è funzionante e possiamo proseguire nella sessione di invio della mail:
ehlo example.com 250-my-new-mailserver 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from:<steve@example.com> 250 2.1.0 Ok rcpt to:<john@example.com> 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> Hi John, just wanted to drop you a note. . 250 2.0.0 Ok: queued as A9D64379C4 quit
Un controllo al file di log /var/log/mail.log dovrebbe confermarci che la mail è stata correttamente inviata:
postfix/smtpd[...]: connect from localhost[127.0.0.1] postfix/smtpd[...]: 5FF712A6: client=localhost[127.0.0.1] postfix/cleanup[...]: 5FF712A6: message-id=<...> postfix/qmgr[...]: 5FF712A6: from=<steve@example.com>, size=364, nrcpt=1 (queue active) postfix/pipe[...]: 5FF712A6: to=<john@example.com>, relay=dovecot, ..., status=sent (delivered via dovecot service) postfix/qmgr[...]: 5FF712A6: removed postfix/smtpd[...]: disconnect from localhost[127.0.0.1]
L'invio della mail si è concluso felicemente. Postfix ha determinato correttamente che il dominio di destinazione è uno dei nostri domini virtuali e ha inoltrato la mail al servizio Dovecot.
Controllo della mailbox dell'utente
E' il momento di verificare la corretta ricezione della mail:
$ cd /var/vmail/example.com/john/Maildir $ find . ./cur ./new ./new/1179521979.V801I2bbf7M15352.mailtest ./tmp $ mutt -f . q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help 1 N May 18 steve@example.c (0.1K) Press ENTER to read the email: From: steve@example.com To: undisclosed-recipients: ; Hi John, just wanted to drop you a note.
La mail è arrivata correttamente. Premiamo q due volte per uscire da mutt.
Test del server POP3
Il Post Office Protocol (detto anche POP) è un protocollo che ha il compito di permettere, mediante autenticazione, l'accesso ad un account di posta elettronica presente su di un host per scaricare le e-mail del relativo account. Il pop (nella versione 3) rimane in attesa sulla porta 110 dell'host (di default, ma può anche essere diversa) per una connessione TCP da parte di un client. I messaggi di posta elettronica, per essere letti, devono essere scaricati sul computer, anche se è possibile lasciarne una copia sull'host. Il protocollo POP3 non prevede alcun tipo di cifratura, quindi le password utilizzate per l'autenticazione fra server e client passano in chiaro.
Stabiliamo una connessione POP3 con il nostro server:
$ telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready.
user john@example.com
+OK
pass summersun
+OK Logged in.
list
+OK 1 messages:
1 474
.
retr 1
+OK 474 octets
Return-Path: <steve@example.com>
X-Original-To: john@example.com
Delivered-To: john@example.com
Received: from example.com (localhost [127.0.0.1])
by ... (Postfix) with ESMTP id 692DF379C7
for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
Message-Id: <...>
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
From: steve@example.com
To: undisclosed-recipients:;
Hi John,
just wanted to drop you a note.
.
quit
+OK Logging out.
Connection closed by foreign host.
Effettuata questa prima verifica di funzionamento, sarà possibile utilizzare un qualsiasi email client per le operazioni quotidiane.
Test del server IMAP
L'Internet Message Access Protocol (IMAP), a volte anche chiamato Interactive Mail Access Protocol, è un protocollo di comunicazione per la ricezione di e-mail. Il significato "Interactive Mail Access Protocol" è stato valido fino alla versione 3, dalla quarta in poi è cambiato in "Internet Message Access Protocol". Il protocollo è stato inventato da Mark Crispin nel 1986 come alternativa più moderna all'utilizzatissimo POP. La porta predefinita del demone IMAP sull'host è la 143. Se si utilizza una connessione sicura tramite SSL, allora la porta è la 993.
Entrambi i protocolli permettono ad un client di accedere, leggere e cancellare le e-mail da un server, ma con alcune differenze. Il protocollo POP 3 scarica la posta direttamente sul PC, eventualmente cancellandola dal server; con il protocollo IMAP è possibile conservare copia delle proprie e-mail sul server, e scaricarle in un secondo momento da altri computer.
Per verificare il corretto funzionamento del server IMAP possiamo utilizzare il client mutt:
$ mutt -f imap://john@example.com@localhost
Oppure, in alternativa, aprire una connessione IMAP attraverso telnet:
$ telnet localhost imap2
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
1 login john@example.com summersun
1 OK Logged in.
2 list "" "*"
* LIST (\HasNoChildren) "." "INBOX"
2 OK List completed.
3 select "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1180039205] UIDs valid
* OK [UIDNEXT 3] Predicted next UID
3 OK [READ-WRITE] Select completed.
4 fetch 1 all
* 1 FETCH (FLAGS (\Seen) INTERNALDATE .........
4 OK Fetch completed.
5 fetch 1 body[]
* 1 FETCH (BODY[] {474}
Return-Path: <steve@example.com>
X-Original-To: john@example.com
Delivered-To: john@example.com
Received: from example.com (localhost [127.0.0.1])
by ... (Postfix) with ESMTP id 692DF379C7
for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
Message-Id: <...>
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
From: steve@example.com
To: undisclosed-recipients:;
Hi John,
just wanted to drop you a note.
)
5 OK Fetch completed.
6 logout
* BYE Logging out
6 OK Logout completed.
Test dei server POP3s e IMAPs
La via più veloce per testare i servizi POP3s e IMAPs, gli equivalenti dei servizi visti in precedenza, ma con TLS/SSL abilitato, è utilizzare il client mutt:
$ mutt -f imaps://john@example.com@localhost
Dovecot all'atto dell'installazione genera un certificato self-signed. Potete decidere di utiizzarlo, oppure di generarne un secondo personalizzato:
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
-keyout /etc/ssl/private/dovecot.pem
Durante la generazione del certificato vi saranno poste alcune domande:
Generating a 1024 bit RSA private key .........++++++ ............................++++++ writing new private key to '/etc/ssl/certs/dovecot.pem' ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:Hamburg Locality Name (eg, city) []:Hamburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:workaround email service Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:mailtest.workaround.org Email Address []:postmaster@workaround.org
L'impostazione più importante è la definizione del Common Name, dove va inserito il fully-qualified name (FQDN) del mail server. Il certificato generato sarà valido per 10 anni (3650 giorni).
Infine impostiamo i corretti permessi sul file certificato:
# chmod o= /etc/ssl/private/dovecot.pem
e riavviamo Dovecot per fargli prendere il nuovo certificato:
# /etc/init.d/dovecot restart
Autenticazione su SMTP
Open relays server
Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:
- il destinatario è un utente del mail server
- il mittente sta inviando la mail dal nostro local network, definito dalla direttiva
mynetworksdi Postfix - il mittente si è autenticato sul server
Per motivi di sicurezza dovrebbe essere sempre impedito l'invio di email da parte di utenti che non si sono autenticati sul server e che provengono da reti sconosciute. In caso contrario uno spammer potrebbe facilmente sfruttare il nostro server per inviare milioni di email spam: questo porterebbe ad uno spreco di banda e, soprattutto, all'inserimento dell'IP del nostro server in tutte le blacklist del mondo, bloccando anche la posta dei nostri utenti autorizzati. Un server che si comporta in questo modo, permettendo l'invio di mail a tutti, è chiamato open relay.
Configurazione di Postfix per l'autorizzazione SMTP
Impostare la direttiva smtpd_recipient_restrictions correttamente è importantissimo. Normalmente è possibile definire le reti abilitate al relay sul nostro mail server attraverso la direttiva mynetworks contenuta nel file main.cf:
# postconf -e mynetworks=192.168.50.0/24
Purtroppo questa direttiva non è applicabile nel caso di un server che voglia agire da ISP, permettendo la spedizione e la ricezione delle email anche agli utenti che si connettono dal'esterno della nostra rete.
La soluzione è rendere gli utenti fidati attraverso la richiesta di una username e di una password, in mancanza dei quali il relaying sarà proibito dal server.
Questo è il momento in cui entra in gioco l'autenticazione SMTP.
Dalla versione 2.3 di Postfix è possibile fare in modo che sia Postfix stesso a richiedere a Dovecot la verifica del nome utente e della password. E siccome abbiamo già configurato Dovecot, avremo bisogno solo di alcune configurazioni extra in Postfix:
# postconf -e smtpd_sasl_type=dovecot # postconf -e smtpd_sasl_path=private/auth # postconf -e smtpd_sasl_auth_enable=yes # postconf -e smtpd_tls_security_level=may # postconf -e smtpd_tls_auth_only=yes # postconf -e smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem # postconf -e smtpd_tls_key_file=/etc/ssl/private/mailserver.pem # postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enableabilita l'autenticazione SMTPsmtpd_recipient_restrictionsdefinisce le regole che sono controllate per permettere il relay. Nel nostro caso il relay è permesso se:permit_mynetworks: l'utente proviene dalla nostra rete, oppurepermit_sasl_authenticated: l'utente si è autenticato, oppurereject_unauth_destination: la mail è destinata a un utente di un nostro dominio virtuale
NOTA: la direttiva postconf -e smtpd_tls_auth_only=yes è da utilizzarsi solo se vogliamo che i nostri utenti siano costretti a utilizzare SSL per scaricare e inviare la loro posta.
Riavviamo infine Postfix:
# /etc/init.d/postfix restart
Test della configurazione
Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:
$ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailtest ESMTP Postfix (Debian/GNU) ehlo example.com 250-mailtest 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg== 235 2.0.0 Authentication successful quit 221 2.0.0 Bye
L'autenticazione ha funzionato.
|
|
Nota Se abbiamo impostato la password di john a qualcosa di diverso da summersun dobbiamo ricavarne l'hash Base64 in questo modo: $> perl -MMIME::Base64 -e \
'print encode_base64("john\@example.com\0john\@example.com\0password")';
|
Ora possiamo testare l'invio di una mail attraverso il nostro client di posta. Per verificare il corretto funzionamento controlliamo i file di log:
# tail -f /var/log/mail.log
Dovremmo trovare qualcosa di simile:
postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
postfix/qmgr[3963]: 1234567890: from=<john@example.com>, size=830, nrcpt=1 (queue active)
postfix/smtpd[4032]: disconnect from ...
postfix/smtp[4041]: 1234567890: to=<devnull@workaround.org>,
relay=torf.workaround.org[212.12.58.129]:25, delay=6,
delays=0.09/0.08/5.6/0.23, dsn=2.0.0, status=sent
(250 OK id=1HsPC3-0008UJ-O5)
postfix/qmgr[3963]: 2EAE8379CB: removed
In caso di errore dovremmo invece vedere qualcosa di simile a questo:
postfix/smtpd[4032]: connect from ...[10.20.30.40] postfix/smtpd[4032]: warning: ...[10.20.30.40]: SASL PLAIN authentication failed: postfix/smtpd[4032]: lost connection after AUTH from ...[10.20.30.40] postfix/smtpd[4032]: disconnect from ...[10.20.30.40]
In fase di installazione Postfix genera automaticamente un certificato SSL, ma potrebbe essere utile crearne uno personalizzato, nella stessa maniera vista in precedenza:
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
-keyout /etc/ssl/private/postfix.pem
L'impostazione più importante è la definizione del Common Name, dove va inserito il fully-qualified name (FQDN) del mail server.
A generazione avvenuta impostiamo i corretti permessi sul file:
# chmod o= /etc/ssl/private/postfix.pem
e comunichiamo a Postfix di utilizzare il nuovo certificato:
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem # postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem
Di default Postfix permette l'invio in chiaro dei dati di autenticazione SMTP, ma possiamo impostare la trasmissione crittata agendo su due parametri:
# postconf -e smtpd_use_tls=yes # postconf -e smtpd_tls_auth_only=no
In questo modo Postfix offre (ma non richiede obbigatoriamente) la crittazione dei dati di login.
Se vogliamo proibire le connessioni SMTP non crittate, possiamo impostare le direttive smtpd_tls_security_level = encrypt o smtpd_tls_wrappermode = yes. Possiamo anche impostare smtpd_tls_security_level = may (la cosiddetta opportunistic TLS connection).
Una volta terminate le modifiche possiamo testare la corretta configurazione del nostro mail server per quanto riguarda la protezione dai tentativi di relay:
# telnet relay-test.mail-abuse.org
Con questo comando contatteremo un ottimo servizio che cercherà di inviare alcune mail attraverso il nostro server. Lasciamogli qualche minuto e aspettiamo che compaia la dicitura:
System appeared to reject relay attempts
Filtrare spam e virus con AMaViS
Configurazione di Spamassassin
Verifichiamo che il demone di SpamAssassin sia attivo, aprendo il file:
# nano /etc/default/spamassassin
e modificando la riga:
ENABLED=0
in
ENABLED=1
Avviamo SpamAssassin e abilitiamo l'aggiornamento automatico delle regole:
# sa-update && service spamassassin restart
Controlliamo che il servizio di aggiornamento automatico si sia abilitato, verificando che in /etc/default/spamassassin ci sia la riga:
CRON=1
Verifichiamo che SpamAssassin sia attivo:
# netstat -ntpl | grep spamd tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2459/spamd.pid
Cambiare o aggiungere i seguenti parametri nel file /etc/spamassassin/local.cf come segue:
# permette di avere un unico database bayes anziché uno in ogni home degli user bayes_path /etc/spamassassin/bayes/bayes bayes_file_mode 0666
Successivamente creare la cartella specificata /etc/spamassassin/bayes con i permessi corretti:
# mkdir /etc/spamassassin/bayes # chmod 777 /etc/spamassassin/bayes
Controllare se ci sono problemi nella configurazione con il comando:
# spamassassin --lint
che dovrebbe restituire una riga vuota.
Configurazione di AMaViS
AMaViS (A Mail Virus Scanner) è un'interfaccia tra Postfix, SpamAssassin e un virus scanner come ClamAV.
Installiamo i file necessari:
# apt-get install amavisd-new clamav-daemon clamav-testfiles clamav-freshclam
La configurazione si AMaViS è divisa in alcuni files nella directory /etc/amavis/conf.d.
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file:
# nano /etc/amavis/conf.d/15-content_filter_mode
rimuovendo il commento # dalle linee @bypass_...:
@bypass_virus_checks_maps = (
\%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re)
E' buona cosa dare un occhio anche al file /etc/amavis/conf.d/20-debian_defaults, ma non cambiate questo file. Se avete bisogno di inserire delle personalizzazioni, utilizzate il file /etc/amavis/conf.d/50-user.
$sa_spam_subject_tag: se questa linea viene lasciata non commentata, allora ogni email ritenuta da AMaViS sospetta di spam avrà questa stringa inserita nell'oggetto della mail. Se non vogliamo alterare l'oggetto della mail possiamo impostarla a$sa_spam_subject_tag=undef. I client email potranno comunque riconoscere lo spam controllando l'headerX-Spam-Status$sa_tag_level_deflt: un messaggio con un punteggio spam uguale o maggiore a questo valore sarà taggata con lo spam header$sa_tag2_level_deflt: i messaggi con un punteggio spam uguale o superiore saranno marcati come spam$sa_kill_level_deflt: dovrebbe essere impostato allo stesso valore di$sa_tag2_level_deflt$final_spam_destiny: il valore raccomandato èD_PASS$spam_quarantine_to: dove vengono mandate in quarantena le mail di spam. Il valore suggerito èundef
Un corretto file 50-user potrebbe essere:
$sa_spam_subject_tag = undef; $spam_quarantine_to = undef; $sa_tag_level_deflt = undef; $final_spam_destiny = D_PASS; 1; # ensure a defined return
Riavviamo AMaViS per fargli digerire le modifiche:
# /etc/init.d/amavis restart
Verifichiamo che AMaViS sia in ascolto sulla porta 10024:
# netstat -nap | grep 10024
dovrebbe restituire:
tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 12345/amavisd
Se otteniamo questa linea significa che AMaViS è in funzione correttamente, in attesa di sessioni SMTP. In caso contrario conviene controllare il file di log /var/log/mail.log.
Integrazione di AMaViS con Postfix
Ogni email inviata sarà ricevuta dal server Postfix, in ascolto sulla porta TCP 25 (SMTP). Ogni mail accettata da Postfix sarà inoltrata a AMaViS sulla porta TCP 10024 (SMTP). AMaViS controllerà il contenuto della mail e, se ritenuta non pericolosa, restituirà la mail a Postfix sulla porta TCP 10025 (SMTP). Senza effettuare altri controlli Postfix inoltrerà la mail al destinatario.
Per fare in modo che Postfix inoltri le mail in arrivo a AMaViS occorre modificare alcune direttive:
# postconf -e content_filter=smtp-amavis:[127.0.0.1]:10024 # postconf -e receive_override_options=no_address_mappings
Abbiamo bisogno innanzitutto di definire il servizio smtp-amavis nel file /etc/postfix/master.cf e abbiamo inoltre bisogno che Postfix si metta in ascolto sulla porta TCP 10025 per ricevere le mail di ritorno da AMaViS. Modifichiamo quindi il file /etc/postfix/master.cf:
# nano /etc/postfix/master.cf
aggiungendo le linee:
smtp-amavis unix - - n - 5 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o smtp_tls_note_starttls_offer=no
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-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
-o local_header_rewrite_clients=
-o smtpd_milters=
Quindi riavviamo Postfix:
# postfix reload
Un parametro in particolare di questa configurazione ha bisogno di alcune spiegazioni. La direttiva receive_override_options è impostata su no_address_mappings. Questo disablita tutti i nostri alias virtuali. Subito dopo la mail è inviata al servizio smtp-amavis e infine ritorna sul servizio 127.0.0.1:10025, su cui sono settate diverse opzioni. Una di queste opzioni è ancora receive_override_options, ma questa volta il suo valore è diverso e quindi, finalmente, Postfix prende in considerazione i nostri alias virtuali. Può sembrare complicato, ma è l'unica strada per evitare che i nostri alias siano valutati due volte, portando a una doppia spedizione di ogni email.
L'utente clamav deve appartenere al gruppo di sistema amavis, in modo che i due servizi possano comunicare tra loro:
# adduser clamav amavis # /etc/init.d/clamav-daemon restart
AMaViS cercherà di scoprire se una certa mail è in arrivo (spedita da internet verso uno dei nostri domini) o in uscita (spedita dal nostro server verso internet) controllando l'impostazione @acl_local_domains. Dobbiamo perciò dire a AMaViS come controllare se un certo dominio e uno dei nostri domini virtuali. Modifichiamo quindi il file /etc/amavis/conf.d/50-user aggiungendo, prima della linea 1; le linee:
@lookup_sql_dsn = (
['DBI:mysql:database=mailserver;host=127.0.0.1;port=3306',
'mailuser',
'mailuser2009']);
$sql_select_policy = 'SELECT name FROM virtual_domains WHERE CONCAT("@",name) IN (%k)';
- La direttiva
@lookup_sql_dsndefinisce come AMaViS può accedere al database - La direttiva
$sql_select_policyimposta la query che viene eseguita per determinare se il dominio in scansione è uno dei nostri domini virtuali.
Riavviamo AMaViS:
# /etc/init.d/amavis restart
e proviamo a spedire una mail a john@example.com. Se esaminiamo gli header di questa mail noteremo le linee aggiunte da AMaViS durante la scansione:
X-Virus-Scanned: Debian amavisd-new at mymailserver X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-9999 required=6.31 tests=[none]
I nostri utenti potranno filtrare lo spam basandosi su queste informazioni. La linea X-Spam-Status sarà impostata a Yes se il punteggio spam supera quello definito nella direttiva $sa_tag2_level_deflt. La linea X-Spam-Level contiene un certo numero di * che definiscono il punteggio spam. Un esempio reale è il seguente:
X-Spam-Status: Yes, hits=16.0 tagged_above=-9999.0 required=6.31
tests=BAYES_99, FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_ID,
RCVD_IN_BL_SPAMCOP_NET, UNDISC_RECIPS, URIBL_OB_SURBL, WORK_AT_HOME
X-Spam-Level: ***************
X-Spam-Flag: YES
Come ultima cosa modifichiamo i permessi del file in modo che nessun utente non autorizzato possa leggere la password del nostro database:
# chmod 640 /etc/amavis/conf.d/50-user
Testiamo il funzionamento di ClamAV:
# clamdscan /usr/share/clamav-testfiles/ /usr/share/clamav-testfiles/clam.pdf: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.chm: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.sis: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.impl.zip: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-nsis.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.tar.gz: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.bz2.zip: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.7z: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-yc.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.ole.doc: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.newc.cpio: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-aspack.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.ppt: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.ea05.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.ea06.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.html: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-upack.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.bz2: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.bin-be.cpio: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.cab: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.mbox.base64: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.arj: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.binhex: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-fsg.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.mbox.uu: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.odc.cpio: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.tnef: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-mew.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-upx.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-pespin.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam_ISmsi_ext.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.mail: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-wwpack.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam_IScab_ext.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam_ISmsi_int.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.zip: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam-petite.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.szdd: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.d64.zip: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam_IScab_int.exe: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.bin-le.cpio: ClamAV-Test-File FOUND /usr/share/clamav-testfiles/clam.exe.rtf: ClamAV-Test-File FOUND ----------- SCAN SUMMARY ----------- Infected files: 44 Time: 1.478 sec (0 m 1 s)
Ora proviamo a inviare una mail infetta attraverso Postfix, per vedere se AMaViS e ClamAV si comportano come ci aspettiamo:
# swaks -t john@example.org --attach - --server localhost --suppress-data < /usr/share/clamav-testfiles/clam.exe
Tra le altre righe in /var/log/mail.log dovremmo trovare una cosa del genere:
29 23:16:23 sirius amavis[4558]: (04558-02) Blocked INFECTED (ClamAV-Test-File) {DiscardedOutbound,Quarantined}, LOCAL [::1]:44226 [::1] <root@mailserver.example.org> -> <john@example.org>, quarantine: C/virus-ClS0k87Qzm4Q, Queue-ID: 6608ED6B, Message-ID: <20131029221623.6608ED6B@sirius.localdomain>, mail_id: ClS0k87Qzm4Q, Hits: -, size: 1547, 128 ms
segno che ClamAV è intervenuto correttamente, bloccando l'email infetta.
La mail infetta è stata spostata in /var/lib/amavis/virusmails/C/virus-ClS0k87Qzm4Q per essere eventualmente analizzata.
Possiamo impostare uno script per pulire la quarantena attraverso cron:
#!/bin/dash
[ -d /var/lib/amavis/virusmails ] && {
find /var/lib/amavis/virusmails/. -type f -name 'virus-*' -ctime +7 -de$
find /var/lib/amavis/virusmails/. -type f -ctime +30 -delete
}
exit 0
Autenticazione di Postfix su un server SMTP remoto
Se ci fosse la necessità di impostare un relay dal nostro server di posta Postfix verso un server SMTP esterno, è possibile utilizzare questa guida:
Postfix e autenticazione su SMTP remoto
Amministrare gli utenti virtuali
GRSoft Mail Manager
A questo indirizzo: http://www.grs-service.ch/pub/grs_mminstallation.html è possibile trovare un'interfaccia per la gestione degli account mail. GRSoft Mail Manager è scritto in PHP e non richiede dipendenze per funzionare.
- Scaricate il file e scompattatelo in una sottodirectory di
/var/www/, ad esempio/var/www/mailmanager - Aprite un browser e navigate verso l'indirizzo: http://ip.del.nostro.server/mailmanager/install.php
- Seguite le istruzioni per l'installazione. Allo Step 3 viene richiesta una coppia di credenziali MySQL con privilegi sufficienti per scrivere una tabella all'interno del database utilizzato in questa guida
- Alla fine dell'installazione seguite le istruzioni per rimuovere i files non più necessari
L'interfaccia permette la definizione di un Super User e di uno o più amministratori per ogni dominio virtuale che verrà creato.
Mail Admin Tool
Un'interfaccia alternativa può essere scaricata a questo indirizzo: Mail Admin Tool.
Broatcast Mail Administrator
La peculiarità di questa interfaccia alternativa è che rende possibile impostare il numero massimo di indirizzi email che ogni dominio può avere. In questo modo possiamo ad esempio avere un dominio con caselle email illimitate e un altro dominio con 5 caselle disponibili. L'interfaccia è scaricabile da qui: Broatcatst Mail Administrator
ISPwebAdmin (web interface): introduzione
|
|
ATTENZIONE Interfaccia obsoleta e non più sviluppata. Si consiglia di utilizzare GRSoft Mail Manager |
E' disponibile un'ulteriore interfaccia web per amministrare i domini virtuali, gli utenti virtuali e gli alias. L'interfaccia si chiama ISPWebAdmin ed è disponibile per il download all'indirizzo: [Download]
Installazione
Per poter utilizzare ISPWebAdmin è necessario aggiungere alcune tabelle SQL al database per poter archiviare gli username e le password degli amministratori abilitati alla gestione degli account. Apriamo quindi la shell di MySQL:
# mysql -p mailserver
e digitiamo la query:
CREATE TABLE IF NOT EXISTS `admins` ( `id` int(11) NOT NULL auto_increment, `username` varchar(40) NOT NULL, `pwhash` varchar(32) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Quindi creiamo un utente amministratore che possa effettuare il login nell'interfaccia web:
INSERT INTO mailserver.admins (username,pwhash) VALUES ('john', MD5('doe'));
Installiamo e configuriamo alcuni requisiti per l'interfaccia:
# aptitude install python-virtualenv # apt-get build-dep python-mysqldb # su -s /bin/bash vmail cd /var/vmail mkdir ispwebadmin cd ispwebadmin wget http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz virtualenv . . bin/activate
A questo punto siamo pronti per effettuare l'installazione dell'interfaccia:
easy_install ispwebadmin*.tar.gz paster make-config ispwebadmin run.ini
Il secondo comando creerà un file run.ini che conterrà le impostazioni specifiche per la nostra installazione. Per modificare queste impostazioni (che saranno trattate nel paragrafo successivo) possiamo aprire il file con il nostro editor preferito:
nano run.ini
Ora siamo pronti per avviare la nostra web application:
paster serve run.ini
Su un server, però, non è conveniente avere dei servizi da avviare manualmente. Vediamo quindi come creare un servizio che funzioni in background e che sia avviato automaticamente all'avvio del server.
Per creare il nuovo servizio utilizzeremo il sistema runit di Debian Lenny:
# aptitude install runit # mkdir /etc/sv/ispwebadmin # cd /etc/sv/ispwebadmin
Creiamo ora un file /etc/sv/ispwebadmin/run
# nano /etc/sv/ispwebadmin/run
contenente:
#!/bin/sh exec 2>&1 echo 'ISPwebAdmin starting.' cd /var/vmail/ispwebadmin sudo -u vmail PYTHON_EGG_CACHE=/var/vmail/ispwebadmin/.python-eggs bin/paster serve run.ini
Rendiamo eseguibile il file:
# chmod u+x /etc/sv/ispwebadmin/run
e creiamo il symlink corretto:
# ln -s /etc/sv/ispwebadmin /etc/service/
Da questo momento il servizio potrà essere utilizzato nel modo seguente:
- Stato:
sv status /etc/service/ispwebadmin - Arresto:
sv stop /etc/service/ispwebadmin - Avvio:
sv start /etc/service/ispwebadmin
Se vogliamo avere un log di questo servizio possiamo creare un file
# nano /etc/sv/ispwebadmin/log/run
contenente:
#!/bin/sh -e LOG=/var/log/runit-ispwebadmin test -d "$LOG" || mkdir -p -m2750 "$LOG" exec svlogd -tt "$LOG"
Il file di log si troverà in /var/log/runit-ispwebadmin.
Configurazione del file run.ini
Il file creato con il comando paster make-config run.ini contiene alcune impostazioni che possono essere personalizzate per adattarle alla configurazione del nostro mail server. Prima di avviare la web interface è consigliato aprire il file e controllare queste impostazioni:
- '
[server:main] -> host: l'indirizzo IP dove il web server è in ascolto. E' possibile impostare "0.0.0.0" per indicare tutte le interfacce di rete [server:main] -> port: la porta TCP dove il web server è in ascolto[app:main] -> ispwebadmin.maildir_location: il percorso dove sono archiviate le mail boxes degli utenti. Nel corso di questo tutorial è stato utilizzato/var/vmail[app:main] -> ispwebadmin.postmaster: l'indirizzo email utilizzato come abuse@ e postmaster@ per i nuovi domini creati. E' richiesto un account del genere per ogni dominio creato. Questa impostazione è opzionale.[app:main] -> sqlalchemy.url: la stringa che definisce come effettuare la connessione al database. Ad esempio:
mysql://root:seoroct3@mailserver.example.com/mailserver?charset=utf8
Impostazione dei record DNS
DNS è l'acronimo per domain name system, il protocollo che permette la traduzione di nomi come www.workaround.org in indirizzi IP come 212.12.58.129 e viceversa. Se intendiamo ricevere la posta di un dominio dobbiamo essere incaricati della sua zona. Normalmente la configurazione di una zona prevede la creazione di alcuni record DNS:
IN TXT "v=spf1 ip4:212.12.58.128/27 -all" IN MX 10 mx1.workaround.org IN MX 20 mx2.workaround.org IN MX 30 mx3.workaround.org IN MX 40 mx4.workaround.org IN A 212.12.58.129
- IN rappresenta la classe dei record DNS. In internet è sempre IN.
La seconda colonna descrive il tipo di record:
- TXT = Text record (può avere fino a 255 caratteri). Utilizzato per SPF, che sarà descritto più avanti
- MX = Mail Exchanger record (indica i mail server del dominio)
- A = Address record (E' il record di default)
Come fanno gli altri server a trovare il nostro mail server?
Un server che abbia nella sua coda una mail indirizzata al nostro dominio per prima cosa esegue un DNS lookup per trovare un record MX per il dominio. Se ottiene più di una risposta contatterà prima il server con la priorità più alta (= il numero più basso) e successivamente, se non dovesse ottenere risposta, tutti gli altri in ordine di priorità.
Per verificare il corretto funzionamento dei nostri record DNS installiamo alcuni tool:
# aptitude install dnsutils
quindi verifichiamo la corretta risposta dei server DNS:
$> dig +short workaround.org mx 30 mx3.workaround.org. 40 mx4.workaround.org. 10 mx1.workaround.org. 20 mx2.workaround.org. $> dig +short mx1.workaround.org 212.12.58.158
Per ricevere le mail indirizzate al nostro dominio abbiamo quindi bisogno di un record MX nella nostra zona. Poichè però un record MX può puntare solo a un hostname e non a un indirizzo IP avremo bisogno anche di un record A.
Guerra allo spam con le Realtime Black Lists (RBL)
Una delle tecniche più comuni per combattere gli spammer è il ricorso alle blacklist. Esistono diverse liste che possono essere usate liberamente: i loro amministratori hanno politiche di blacklisting diverse, alcune più aggressive, altre meno.
Tra i servizi di blacklisting più utilizzati vanno citati:
- SORBS (dnsbl.sorbs.net)
- SpamCop (bl.spamcop.net)
- SpamHaus (zen.spamhaus.org)
- UCEprotect (dnsbl-1.uceprotect.net)
Se decidete di fare uso di una o più di queste blacklist, la sezione smtpd_recipient_restrictions del vostro /etc/postfix/main.cf diventerà così:
smtpd_recipient_restrictions = permit_mynetworks reject_rbl_client dnsbl.sorbs.net reject_rbl_client bl.spamcop.net reject_rbl_client zen.spamhaus.org reject_rbl_client dnsbl-1.uceprotect.net reject_unauth_destination
Alcune altre utili restrizioni possono essere:
reject_unknown_client_hostname: esegue una doppia verifica DNS tra l'IP e l'hostname del mittentereject_unknown_sender_domain: controlla se il dominio del mittente esiste reralmente. Per effettuare la verifica esegue un controllo sui record MX e A del dominio del mittentereject_unauth_pipelining: elimina le connessioni al nostro server che cercano di utilizzare il metodo delle pipeline per spedire quante più mail possibili nel minor tempo possibile
E' possibile anche impostare delle regole per il blocco automatico di alcuni domini riconosciuti come spammer; la lista dei domini è personalizzabile tramite un semplice file di testo.
Innanzitutto aggiungiamo la sezione:
smtpd_client_restrictions =
permit_mynetworks
check_client_access hash:/etc/postfix/access
permit
prima della sezione:
smtpd_recipient_restrictions
Quindi creiamo il file contenente la lista dei domini da bloccare o da autorizzare senza ulteriori controlli:
# nano /etc/postfix/access
e riempiamolo con la nostra lista:
yahoo.com.tw REJECT hinet.com REJECT pchome.com.tw REJECT yahoo.co.jp REJECT yam.com REJECT inet.net REJECT ferdy.it OK
In questo caso abbiamo bloccato alcuni domini e autorizzato il dominio ferdy.it a inviarci mail senza nessun ulteriore controllo. Quindi facciamo in modo che Postfix si crei il database relativo:
# postmap /etc/postfix/access
Questo comando andrà ripetuto ad ogni modifica del file.
SPF per ridurre ancora di più lo spam
SPF, acronimo per Sender Policy Framework, è un sistema attraverso il quale il proprietario di un dominio può definire quali indirizzi IP sono autorizzati a inviare le sue mail.
$> dig +short workaround.org txt "v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"
Questa riga significa che se qualcuno invia una mail con mittente ...@workaround.org noi dovremmo accettarla solo se proviene da uno degli indirizzi IP specificati nel record TXT della zona del dominio in questione. Se la mail proviene da un atro IP significa che non è stata spedita da un server di workaround.org e che con tutta probabilità si tratta di spam.
Molte organizzazioni e molti siti hanno già i loro record SPF, che possiamo utilizzare per ridurre la quantità di spam in arrivo sui nostri server. Per utilizzare correttamente i record SPF dovremo quindi:
- impostare un record TXT nella nostra zona per definire quali indirizzi IP sono autorizzati a inviare mail a nome nostro
- controllare le voci SPF dei server mittenti e respingere la mail in arrivo da IP non autorizzati
Impostare una voce SPF
Per aggiungere un record TXT come mostrato nel paragrafo precedente dovremo ovviamente avere il pieno controllo della nostra zona DNS, oppure chiedere al nostro ISP che lo faccia per noi.
Per creare una corretta stringa TXT è consigliabile andare sul sito di OpenSPF e utilizzare il wizard apposito; quindi copincolliamo la stringa risultante e utilizziamola come record TXT per il nostro dominio.
Verificare i record SPF degli altri mail server
Fortunatamente esiste un pacchetto Debian che rende il controllo dei record SPF una cosa molto semplice. Iniziamo con l'installazione del pacchetto:
# apt-get install tumgreyspf
tumgreyspf è un policy daemon scritto in Python che effettua sia il greylisting sia il controllo SPF delle email in entrata. Per attivarlo basta semplicemente aggiungere una linea alla nostra direttiva smtpd_recipient_restrictions. Ad esempio:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
[ ... ]
check_policy_service unix:private/tumgreyspf
reject_unauth_destination
Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file /etc/postfix/master.cf:
tumgreyspf unix - n n - - spawn
user=tumgreyspf argv=/usr/bin/tumgreyspf
Ora riavviamo Postfix:
# postfix reload
Verifica del funzionamento di SPF
SPF okay
Controlliamo il file /var/log/mail.log. Ogni nuova mail in arrivo dovrebbe adesso avere una nuova riga aggiunta da tumgreyspf. Se il controllo SPF è risultato positivo, dovremmo avere qualcosa come:
tumgreyspf[24672]: sender SPF authorized: QUEUE_ID=""; identity=mailfrom; client-ip=26.21.244.31; helo=squedge2.squ.edu.om; envelope-from=…@squ.edu.om; receiver=…@workaround.org;
Questo significa che il mittente …@squ.edu.om è stato autorizzato all'invio della mail dopo un controllo dei record SPF.
SPF fail
Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere:
tumgreyspf[24672]: SPF fail - not authorized: QUEUE_ID=""; identity=mailfrom; client-ip=41.234.18.141; helo=gmx.de; envelope-from=…gmx.de; receiver=…christoph-haas.de;
La mail è stata respinta.
SPF softfail
Un altro caso è quando il record SPF del dominio del mittente non contiene la regola FAIL (-all), ma la regola SOFTFAIL (~all). Nei nostri log troveremo qualcosa del genere:
tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID=""; identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au; envelope-from=…@rollouts.com; receiver=…@workaround.org
Purtroppo una regola SOFTFAIL non respinge la mail in arrivo, ma fa almeno in modo che il destinatario sia avvertito del problema, aggiungendo un'informazione all'header della mail:
Received-SPF: Softfail (domain owner discourages use of this host) identity=mailfrom; client-ip=61.146.93.243; helo=mail.163gd.com; envelope-from=…@cantv.net; receiver=…@christoph-haas.de;
In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.
No SPF information
Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere:
Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom; client-ip=80.65.65.222; helo=mail.unze.ba; envelope-from=…@gmail.com; receiver=…@christoph-haas.de;
Quote
Il nostro mail server non ha spazio infinito, soprattutto se usiamo il protocollo IMAP e gli utenti apprezzano la comodità di avere le mail sempre a disposizione sul server. Perciò vorremo probabilmente limitare lo spazio che un utente può occupare. Dovecot può impostare la dimensione della mailbox di un utente e il numero di email della sue cartelle virtuali.
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.
Debian Lenny
Lenny: Attivare il plugin quota di Dovecot
Ci sono tre punti nel file /etc/dovecot/dovecot.conf dove occorre specificare l'abilitazione del plugin:
protocol imap {
mail_plugins = quota imap_quota
}
protocol pop3 {
mail_plugins = quota
}
protocol lda {
mail_plugins = quota
}
Lenny: Impostare una quota globale
Il caso più semplice è quello in cui si intende impostare una quota limite comune e uguale per tutti gli utenti, ad esempio 1GB di spazio con non più di 1000 email archiviabili.
Nel file /etc/dovecot/dovecot.conf dovremo impostare:
plugin {
quota = maildir:storage=1000000:messages=1000
}
ricordando che i valori per lo storage sono espressi in KB.
Lenny: Impostare una quota utente
Se intendiamo impostare per alcuni utenti delle quote diverse da quelle globali, allora dobbiamo impostare la quota all'interno della tabella dei virtual_users. Utilizziamo la seguente query per aggiungere due colonne alla nostra tabella virtual_users:
mysql> ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL, ADD `quota_messages` INT NOT NULL ;
Inoltre dovremo abilitare la direttiva user sql nel file /etc/dovecot/dovecot.conf, disabilitando la direttiva user static suggerita all'inizio del tutorial:
#userdb static {
# args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
#
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
Infine dovremo aggiungere al file /etc/dovecot/dovecot-sql.conf la linea:
user_query = SELECT CONCAT('/var/vmail/',CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1))) AS home, 5000 AS uid, 5000 AS gid, CONCAT('maildir:storage=',quota_kb,':messages=',quota_messages) AS quota FROM virtual_users WHERE email='%u';
Lenny: Cosa succede se un utente supera la quota
La gestione delle quote in Dovecot non è molto user-friendly. Il mittente non riceve un avviso se è vicino a superare la quota limite; in compenso, quando l'ha superata, le sue mail torneranno indietro con oggetto "Automatically rejected mail" e corpo della mail "Your message to <john@example.com> was automatically rejected: Quota exceeded".
Debian Squeeze
A partire da Dovecot 1.1, di default su Squeeze, la gestione delle quote è cambiata notevolmente.
Squeeze: Impostazione delle Quote root
Dobbiamo innanzitutto aprire il file di configurazione di Dovecot:
# nano /etc/dovecot/dovecot.conf
recarci alla sezione plugin { } e definire le quote root. Ad esempio:
plugin {
quota = maildir:User quota
#quota2 = fs:Disk quota
#quota3 = ...
}
In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.
Squeeze: Quote rules
A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota:
plugin {
# Quota root
quota = maildir:User quota
# Quote rules
# 1 - Dimensione massima 2 GB
quota_rule = *:storage=2GB
# 2 - Dimensione Cestino 200 MB
quota_rule2 = Trash:storage=200MB
# 3 - Dimensione cartella Spam 200MB
quota_rule3 = Spam:storage=200MB
}
Squeeze: Cosa succede se un utente supera la quota
In Squeeze possiamo finalmente configurare Dovecot in modo che invii un messaggio personalizzato agli utenti che hanno superato la loro quota disco. All'interno della solita sezione del file di configurazione di Dovecot aggiungiamo la riga:
plugin {
quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
Squeeze: messaggio di avvertimento
In Squeeze possiamo anche configurare Dovecot in modo che avvii un comando esterno quando la quota di un certo utente supera una certa percentuale. Come al solito dobbiamo recarci nella sezione plugin { } del file di configurazione di Dovecot e aggiungere le seguenti linee:
plugin {
quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95
quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80
}
Nell'esempio precedente, lo script quota-warning.sh è eseguito una prima volta quando l'utente raggiunge l'80% del suo spazio disco e una seconda volta quando raggiunge il 95%.
Lo script va creato a mano:
# nano /usr/local/bin/quota-warning.sh
con contenuto:
#!/bin/sh PERCENT=$1 FROM="webmaster@example.com" qwf="/tmp/quota.warning.$$" echo "From: $FROM To: $USER To: postmaster@domain.org Subject: Hai raggiunto il $PERCENT% del tuo spazio su disco! Content-Type: text/plain; charset="UTF-8" La tua mailbox ha raggiunto il $PERCENT% dello spazio disponibile. Sei pregato di eliminare le mail che non ti occorrono." >> $qwf cat $qwf | /usr/sbin/sendmail -f $FROM "$USER" rm -f $qwf exit 0
Rendiamo lo script eseguibile:
# chmod 750 /usr/local/bin/quota-warning.sh
e siamo a posto.
Accesso tramite Webmail
Squirrelmail
Questo passaggio è facoltativo, ma ormai praticamente tutti i provider offrono ai loro utenti un mezzo per poter controllare le email da un browser.
Per questo motivo durante l'iniziale installazione dei pacchetti abbiamo scelto anche il pacchetto squirrelmail: SquirrelMail è un pacchetto per posta via web aderente agli standard, scritto in PHP. Include supporto integrato in PHP puro per i protocolli IMAP e SMTP ed è progettato per una massima compatibilità con i vari browser. SquirrelMail non richiede molte cose ed è facile da configurare ed installare. Gira sopra qualsiasi server IMAP. SquirrelMail ha tutte le funzioni che si possono desiderare in un client di posta elettronica, incluso un forte supporto MIME, gestione di rubriche e cartelle (Fonte: Debian package).
Per impostarlo dobbiamo inannzitutto aggiungere la sua configurazione a quella di Apache:
$> ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf $> apache2ctl restart
Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail:
$> squirrelmail-configure
Selezioniamo l'opzione 3 (Folder Defaults) e impostiamo l'opzione 1 (Default Folder Prefix) a 'none'. Già che ci siamo possiamo anche navigare all'interno del menu di configurazione e impostare anche il nome corretto per la nostra organizzazione.
A questo punto visitando il sito: http://ip.del.nostro.server/squirrelmail possiamo effettuare il login con le credenziali di uno dei nostri virtual user e iniziare ad usare la webmail.
Permettere il cambio password all'utente
Può essere molto comodo dare all'utente la possibilità di cambiarsi la password per conto suo, senza stressare il sistemista di turno. La cosa più semplice è permetterglielo attraverso la webmail. Squirrelmail di default non prevede questa funzione, ma per fortuna esiste un ottimo plugin che fa al caso nostro. Andiamo quindi alla pagina del plugin (http://squirrelmail.org/plugin_view.php?id=25) e scarichiamolo. Quindi copiamolo nella directory:
/usr/share/squirrelmail/plugins
e scompattiamolo:
# tar zxvf change_sqlpass-3.3-1.2.tar.gz
Prima di modificarne la configurazione dobbiamo compiere alcune operazioni propedeutiche:
# apt-get install php-mdb2 squirrelmail-compatibility # pear install DB
Ora siamo pronti per configurare il plugin appena scaricato:
# cd /usr/share/squirrelmail/plugins/change_sqlpass # cp config.php.sample config.php # vi config.php
- Modifichiamo la riga:
$csp_dsn = 'mysql://root:password@localhost/mailserver';
inserendo le credenziali per l'accesso al database mailserver.
- Modifichiamo la riga:
$lookup_password_query = 'SELECT count(*) FROM virtual_users WHERE email = "%1" AND password = %4';
inserendo la query corretta per la ricerca dell'utente virtuale.
- Modifichiamo la riga:
'UPDATE virtual_users SET password = %4 WHERE email = "%1"',
inserendo la query corretta per la modifica della password dell'utente virtuale.
- Inseriamo il corretto metodo di crittazione usato dal nostro database:
$password_encryption = 'MD5';
- Correggiamo la stringa:
$csp_salt_static = '';
e salviamo il file.
Quindi riconfiguriamo Squirrelmail:
# cd ../../config/ # ./conf.pl
e attiviamo il plugin:
8. Plugins x. change_sqlpass Save S and exit Q.
Effettuando il login nella nostra webmail, sotto la voce "Opzioni" troveremo la funzione "Cambia password".
Roundcube
In alternativa (o affiancato) a Squirrelmail possiamo offrire il più moderno e eye-candy Roundcube, anch'esso presente nei repository di Debian. Per installarlo basta un comando:
- Lenny:
# apt-get -t lenny-backports install roundcube
- Squeeze:
# apt-get install roundcube
Rispondiamo di sì alla domanda dell'installer se configurare o meno un database con dbconfig-common e scegliamo come database il solito MySQL. Ci verrà poi richiesta la password di amministratore di MySQL e l'installazione terminerà.
Ora modifichiamo il file di configurazione:
# nano /etc/roundcube/main.inc.php
modificando la linea:
$rcmail_config['default_host'] = 'localhost';
Quindi modifichiamo il file che definisce il Virtual Host di Roundcube:
# nano /etc/roundcube/apache.conf
e decommentiamo le linee:
Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /roundcube /var/lib/roundcube
Installiamo i driver MDB2:
# pear install MDB2_Driver_mysql
Riavviamo Apache:
/etc/init.d/apache2 restart
e facciamo login nella nostra webmail all'indirizzo: http:// your-domain/roundcube
Filtri server-side: Sieve
Arrivati a questo punto siamo in possesso di un mail server completamente funzionale, che tagga addirittura le mail di spam; però il compito di filtrare le mail taggate come spam è lasciato al client di posta dell'utente finale.
Utilizzando Sieve, un mail filter simile a procmail (che non utilizziamo perchè non lavora con le mailbox virtuali) possiamo fare in modo che le mail taggate da SpamAssassin come "spam" vengano spostate automaticamente in un folder chiamato "Spam".
Iniziamo creando un file di configurazione per Sieve:
# nano /var/vmail/globalsieverc
contenente:
require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
fileinto "spam";
stop;
}
e verifichiamo che sia leggibile dall'utente vmail:
# chown vmail /var/vmail/globalsieverc
Quindi modifichiamo la configurazione di Dovecot e inseriamo un plugin per il global filtering delle mail:
# nano /etc/dovecot/dovecot.conf
cercando la sezione plugin { } e inserendo:
sieve_global_path = /var/vmail/globalsieverc
Riavviamo Dovecot:
# /etc/init.d/dovecot restart
Test del filtro antispam
Inviamo al nostro utente una mail di spam:
# sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt
Nei log di Doecot dovremmo trovare una linea simile alla seguente:
deliver(john@example.com): 2009-07-01 01:00:22 Info: msgid=<GTUBE1.1010101@example.net>: saved mail to spam
E' da notare il folder "Spam" sarà visibile solo agli utenti che gestiscono la posta tramite IMAP, dato che il protocollo POP3 non è un grado di gestire folder differenti da "Inbox". Gli utenti che utilizzano il protocollo POP3 avranno tre alternative:
- sottoscrivere manualmente anche il folder "Spam"
- modificare il file
/var/vmail/example.com/john/Maildir/subscriptionsaggiungendo "spam" tra i folder disponibili - utilizzare Squirrelmail periodicamente per controllare il folder Spam
Managesieve
Managesieve è un'interfaccia low-level per amministrare gli script di Sieve. Per abilitarla è necessario aggiungere managesieve alla linea protocols del nostro file /etc/dovecot/dovecot.conf; nella sezione protocol managesieve dovremmo trovare la linea sieve=~/.dovecot.sieve già impostata. Con questa impostazione il filtro Sieve per il nostro utente sarà posizionato in /var/mail/example.com/john/.dovecot.sieve.
Managesieve client
Sicuramente i nostri utenti non avranno voglia di impararsi il linguaggio di filtering di Sieve e avranno quindi bisogno di una maniera comoda di amministrare i loro filtri. Questo può essere fatto attraverso il plugin avelsieve di Squirrelmail:
# aptitude install avelsieve
Il pacchetto di Debian ha in alcune versioni un errore sulla porta di ascolto del demone Sieve; se la vostra versione è affetta da questo bug, al primo tentativo di login su Squirrelmail vi troverete davanti al messaggio:
Could not log on to timsieved daemon on your IMAP server localhost:4190
Il plugin avelsieve si è messo in ascolto sulla porta sbagliata... Apriamo il suo file di configurazione:
# nano /usr/share/squirrelmail/plugins/avelsieve/config/config.php
e modifichiamo come segue la sezione incriminata:
/* ======================================================================== */ /* =================== ManageSieve Backend Options ======================== */ /* ======================================================================== */ /* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */ /** DEBIAN CHANGE: Despite upstream's intention Debian changed this default * distribution wide to 4190 which is thus default here. */ global $sieveport; $sieveport = 4190;
Effettuando ora il login su Squirrelmail noteremo una nuova voce di menu chiamata "Filters" da cui potremo impostare tutte le regole che vogliamo.
Eliminare le email vecchie
Con il protocollo IMAP è possibile che alcuni client marchino le email come "cancellate" senza però eliminarle fisicamente dal server. L'utente non le vede più, ma queste continuano a occupare spazio sul nostro server. E' conveniente perciò impostare uno script che elimini queste mail in maniera automatica:
find /var/vmail -type f -ctime +7 -name '*,ST' -delete
Con questo comando, che possiamo inserire nel crontab del server, vengono eliminate tutte le email cancellate e più vecchie di 7 giorni.
Ulteriori armi contro lo Spam
Possiamo aggiungere altri due filtri collaborativi contro lo spam seguendo queste due guide:
Troubleshooting
Se abbiamo problemi nell'inviare o ricevere mail possiamo:
- controllare il file di log
/var/log/mail.log; quasi tutti i problemi sono elencati in questo file, con messaggi di errore più o meno chiari - eseguire il comando
postfix check: se l'output è vuoto significa che Postfix è configurato bene - verificare la coda delle mail con il comando
postqueue -p -v - impostare l'immediata spedizione di tutte le mail in coda:
mailq -q - verificare il funzionamento di Amavis:
# /etc/init.d/amavisd-new stop # /etc/init.d/amavisd-new debug
Credits
Questa guida è basata sull'originale di Christoph Haas pubblicata sul sito Workaround.org.
| Guida scritta da: Ferdybassi 22:22, 2 apr 2011 (CEST) |  Debianized 20%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |