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"

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.

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-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'account mailuser che 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:

# 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 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/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 mynetworks di 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_enable abilita l'autenticazione SMTP
• smtpd_recipient_restrictions definisce le regole che sono controllate per permettere il relay. Nel nostro caso il relay è permesso se:
  • permit_mynetworks: l'utente proviene dalla nostra rete, oppure
  • permit_sasl_authenticated: l'utente si è autenticato, oppure
  • reject_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'header X-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

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_dsn definisce come AMaViS può accedere al database
• La direttiva $sql_select_policy imposta 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

Amministrare gli utenti virtuali

ISPwebAdmin (web interface): introduzione

E' disponibile un'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 -U root -p

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

Un'interfaccia alternativa

A questo indirizzo: http://www.grs-service.ch/pub/grs_mminstallation.html è possibile trovare un'interfaccia alternativa per la gestione degli account mail. GRSoft Mail Manager è scritto in PHP e non richiede dipendenze per funzionare.

1. Scaricate il file e scompattatelo in una sottodirectory di /var/www/, ad esempio /var/www/mailmanager
2. Aprite un browser e navigate verso l'indirizzo: http://ip.del.nostro.server/mailmanager
3. 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

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.

SPF per ridurre lo spam

SPF, acronimo per Sender Policy Framework, è un sistema attraverso il quale il proprietaario 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_sender_restrictions (o smtpd_recipient_restrictions). A esempio:

smtpd_sender_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    [ ... ]
    check_policy_service unix:private/tumgreyspf
    [ ... ]
    permit

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.

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
}

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.

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';

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

Accesso tramite Webmail

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.

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:

1. sottoscrivere manualmente anche il folder "Spam"
2. modificare il file /var/vmail/example.com/john/Maildir/subscriptions aggiungendo "spam" tra i folder disponibili
3. 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

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.

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.

---

--Ferdybassi 22:22, 2 apr 2011 (CEST)