Internet Service Provider con Debian
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
- 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
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.
Installazione del server di posta
Schema di funzionamento
I software utilizzati per configurare il server di posta saranno i seguenti:
- Postfix (2.5.5) per inviare e ricevere mail da internet e effettuare i primi controlli basilari
- Dovecot (1.0.15) per archiviare le mail sul server e fornire agli utenti accesso alle loro caselle tramite POP3 e IMAP
- Squirrelmail (1.4.15) come interfaccia Webmail
- MySQL (5.0.51a) come database backend per archiviare informazioni su domini, account utente e email forwarding
- AMaViS (2.6.1) per effetuare la scansione delle mail in arrivo utilizzando ClamAV e SpamAssassin
- Clam Antivirus (0.94) come controllo antivirus
- SpamAssassin (3.2.5) 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.
Installazione dei pacchetti necessari
Incominciamo con l'installare il server Postfix con la sua estensione per il supporto a MySQL:
# aptitude install 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.
Poichè intendiamo offrire ai nostri utenti anche i servizi POP3 e IMAP dobbiamo installare il demone Dovecot:
# aptitude install dovecot-pop3d dovecot-imapd
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/ lenny 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 Squirrelmail:
# aptitude install squirrelmail
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
Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.
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.
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'
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' e verifichiamo che tutto funzioni correttamente: <pre> # 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.
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/deliver -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:
# postfix reload
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
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in /etc/dovecot. 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.
L'utente viene autenticato attraaverso 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/vmail/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@example.com
mail_plugins = cmusieve
}
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.
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/vmail/dovecot-deliver.log {
weekly
rotate 14
compress
}
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';
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
Test della configurazione
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_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
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
AMaViS (A Mail Virus Scanner) è un'interfaccia tra Postfix, SpamAssassin e un virus scanner come ClamAV. 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_....
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 - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-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
-o local_header_rewrite_clients=
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
<pre>
<br/>
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 <code>@acl_local_domains</code>. Dobbiamo perciò dire a AMaViS come controllare se un certo dominio e uno dei nostri domini virtuali. Modifichiamo quindi il file <code>/etc/amavis/conf.d/50-user</code> aggiungendo, prima della line <code>1;</code> le linee:
<pre>
@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 o= /etc/amavis/conf.d/50-user