Internet Service Provider con Debian: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
 
(104 versioni intermedie di 4 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Lenny|Squeeze|Wheezy}}
{{Versioni compatibili|Lenny|Squeeze|Wheezy}}
{{Warningbox|La guida NON è compatibile con Jessie. E' in fase di realizzazione una nuova guida.}}
<br/>
== Introduzione ==
== 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:
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:
Riga 19: Riga 21:
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]].
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]].
<br/>
<br/>
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]].
Poichè il server andrà quasi sicuramente gestito da remoto occorrerà installare e configurare anche l'accesso SSH ([[SSH | guida su SSH]]) con autenticazione via chiave.


=== Installazione ambiente LAMP ===
=== Installazione ambiente LAMP ===
Riga 155: Riga 157:
<br/>
<br/>
<br/>
<br/>
{{Warningbox|DEPRECATO: al posto di Roundcube è possibile installare una diversa interfaccia webmail, Squirrelmail:}}
{{Warningbox|DEPRECATO: al posto di Squirrelmail è possibile installare una diversa interfaccia webmail, Roundcube:}}
<pre>
<pre>
# aptitude install squirrelmail
# aptitude install squirrelmail
Riga 177: Riga 179:
<br/>
<br/>
Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.
Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.
=== Creazione del certificato SSL ===
Creiamo il certificato da utilizzare per i servizi SSL:
<pre>
# openssl req -new -x509 -days 3650 -nodes -newkey rsa:4096 -out /etc/ssl/certs/mailserver.pem -keyout /etc/ssl/private/mailserver.pem
</pre>
e proteggiamolo:
<pre>
# chmod 600 /etc/ssl/private/mailserver.pem
</pre>


=== Preparazione del database ===
=== Preparazione del database ===
Riga 306: Riga 318:
query = SELECT 1 FROM virtual_domains WHERE name='%s'
query = SELECT 1 FROM virtual_domains WHERE name='%s'
</pre>
</pre>
{{Box|NOTA|Potrebbe venirvi la tentazione di scrivere "localhost" al posto di "127.0.0.1" nel file precedente. Non va fatto!! "localhost" farà sì che Postfix cerchi il file socket MySQL, non trovandolo perchè gira in una chroot hail. Al contrario "127.0.0.1" utilizzerà una connessione TCP sulla porta 3306, che risponderà anche se Postfix funziona all'interno di una gabbia chroot}}
{{Box|NOTA|Potrebbe venirvi la tentazione di scrivere "localhost" al posto di "127.0.0.1" nel file precedente. Non va fatto!! "localhost" farà sì che Postfix cerchi il file socket MySQL, non trovandolo perchè gira in una chroot jail. Al contrario "127.0.0.1" utilizzerà una connessione TCP sulla porta 3306, che risponderà anche se Postfix funziona all'interno di una gabbia chroot}}
<br/>
<br/>
Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura:
Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura:
Riga 472: Riga 484:
<pre>
<pre>
dovecot  unix  -      n      n      -      -      pipe
dovecot  unix  -      n      n      -      -      pipe
    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient}
</pre>
</pre>
'''Nota''': la seconda riga deve essere indentata con degli spazi e non con il TAB.
'''Nota''': la seconda riga deve essere indentata con degli spazi e non con il TAB.
Riga 478: Riga 490:
A questo punto non resta che riavviare Postfix:
A questo punto non resta che riavviare Postfix:
<pre>
<pre>
# postfix reload
# service postfix restart
</pre>
</pre>
e fare in modo che utilizzi il servizio appena creato per lo smistamento delle email, modificando il file <code>/etc/postfix/main.cf</code> nella maniera vista in precedenza:
e fare in modo che utilizzi il servizio appena creato per lo smistamento delle email, modificando il file <code>/etc/postfix/main.cf</code> nella maniera vista in precedenza:
Riga 506: Riga 518:
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in <code>/etc/dovecot</code>.
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in <code>/etc/dovecot</code>.
<br/>
<br/>
Fino a Debian Squeeze la configurazione di Dovecot era tutta contenuta in due file; da Debian Wheezy la configurazione è stata spezzata in una trentina di file, contenuti tutti nella directory <tt>/etc/dovecot/conf.d</tt>. Il file di configurazione principale <tt>/etc/dovecot/dovecot.conf</tt> non richiede alcuna modifica e attraverso la direttiva
Fino a Debian Squeeze la configurazione di Dovecot era tutta contenuta in due file; da Debian Wheezy la configurazione è stata spezzata in una trentina di file, contenuti tutti nella directory <code>/etc/dovecot/conf.d</code>. Il file di configurazione principale <code>/etc/dovecot/dovecot.conf</code> non richiede alcuna modifica e attraverso la direttiva
<pre>
<pre>
!include conf.d/*.conf
!include conf.d/*.conf
</pre>
</pre>
carica tutti i file presenti in <tt>/etc/dovecot/conf.d/</tt> che terminano in ".conf" in sequenza. Quindi "10-auth.conf" sarà caricato per primo e "90-quota.conf" per ultimo. Il grosso vantaggio di questa situazione è che potremo modificare o rimpiazzare parti della configurazione senza sovrascriverla interamente; lo svantaggio è che la migrazione da una versione precedente di Dovecot può diventare un'operazione difficoltosa.
carica tutti i file presenti in <code>/etc/dovecot/conf.d/</code> che terminano in ".conf" in sequenza. Quindi "10-auth.conf" sarà caricato per primo e "90-quota.conf" per ultimo. Il grosso vantaggio di questa situazione è che potremo modificare o rimpiazzare parti della configurazione senza sovrascriverla interamente; lo svantaggio è che la migrazione da una versione precedente di Dovecot può diventare un'operazione difficoltosa.


==== Fino a Debian Squeeze ====
==== Fino a Debian Squeeze ====
Riga 694: Riga 706:
mail_location = maildir:/var/vmail/%d/%n/Maildir
mail_location = maildir:/var/vmail/%d/%n/Maildir
</pre>
</pre>
Questa sarà la directory dove Dovecot cercherà le email di ogni specifico utente. Ad esempio l'utente <tt> john@example.org</tt> avrà le sue email archiviate in <tt>/var/vmail/example.org/john/Maildir</tt>.
Questa sarà la directory dove Dovecot cercherà le email di ogni specifico utente. Ad esempio l'utente <code> john@example.org</code> avrà le sue email archiviate in <code>/var/vmail/example.org/john/Maildir</code>.
<br/>
<br/>
Cambiamo la direttiva ''auth_socket_path'' in
<pre>
auth_socket_path = /var/run/dovecot/auth-master
</pre>
Cerchiamo la sezione ''namespace inbox''. Se abbiamo già archiviato email sul server e stiamo aggiornando il nostro sistema da Squeeze a Wheezy, allora dobbiamo modificare la direttiva ''separator'' in:
Cerchiamo la sezione ''namespace inbox''. Se abbiamo già archiviato email sul server e stiamo aggiornando il nostro sistema da Squeeze a Wheezy, allora dobbiamo modificare la direttiva ''separator'' in:
<pre>
<pre>
Riga 702: Riga 718:
per mantenere la retrocompatibilità della configurazione.
per mantenere la retrocompatibilità della configurazione.


=== Test della configurazione ===
===== 10-master.conf =====
Nella sezione ''service auth'' dobbiamo inserire:
<pre>
# Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
</pre>
Gli altri servizi possono essere lasciati come sono.


==== Invio di email tramite telnet ====
===== 10-ssl.conf =====
In precedenza abbiamo creato un certificato SSL per i servizi Pop3 3 Imaps. Questo è il momento di dire a Dovecot dove si trovano questi certificati, inserendo:
<pre>
ssl_cert = </etc/ssl/certs/mailserver.pem
ssl_key = </etc/ssl/private/mailserver.pem
</pre>


Installiamo innanzitutto il pacchetto telnet:
===== 15-lda.conf =====
In questo file dobbiamo abilitare il plugin ''sieve'', che, in parole povere, è un sistema per gestire le regole email a livello server. Cerchiamo la sezione ''protocol lda'' verso la fine del gile e aggiungiamo ''sieve'' alla lista dei plugin:
<pre>
<pre>
# aptitude install telnet
protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}
</pre>
</pre>
Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server:
 
===== /etc/dovecot/dovecot-sql.conf.ext =====
Questo file è richiamato dal file <code> /etc/dovecot/conf.d/auth-sql.conf.ext</code> e dice a Dovecot come accedere al database MySQL e dove trovare le informazioni sugli account. Accertiamoci che contenga le linee:
<pre>
<pre>
# telnet localhost smtp
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';
</pre>
</pre>
Dovremmo ottenere come risposta:
ponendo attenzione a inserire le credenziali MySQL create in precedenza.
 
===== Protezione dei file =====
Impostiamo le giuste credenziali per il file di configurazione principale:
<pre>
<pre>
Trying 127.0.0.1...
# chgrp vmail /etc/dovecot/dovecot.conf
Connected to localhost.
# chmod g+r /etc/dovecot/dovecot.conf
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)
</pre>
</pre>
Ottimo. Postfix è funzionante e possiamo proseguire nella sessione di invio della mail:
per lo spool di Postfix:
<pre>
<pre>
ehlo example.com
# chown postfix:postfix /var/spool/postfix/private/auth
250-my-new-mailserver
# chmod 666 /var/spool/postfix/private/auth
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
</pre>
</pre>
Un controllo al file di log <code>/var/log/mail.log</code> dovrebbe confermarci che la mail è stata correttamente inviata:
e proteggiamo il file di configurazione SQL in modo che nessuno possa scoprire la password del database:
<pre>
<pre>
postfix/smtpd[...]: connect from localhost[127.0.0.1]
# chown root:root /etc/dovecot/dovecot-sql.conf.ext
postfix/smtpd[...]: 5FF712A6: client=localhost[127.0.0.1]
# chmod go= /etc/dovecot/dovecot-sql.conf.ext
postfix/cleanup[...]: 5FF712A6: message-id=<...>
</pre>
postfix/qmgr[...]: 5FF712A6: from=<steve@example.com>, size=364, nrcpt=1 (queue active)
Infine riavviamo Dovecot:
postfix/pipe[...]: 5FF712A6: to=<john@example.com>, relay=dovecot, ..., status=sent (delivered via dovecot service)
<pre>
postfix/qmgr[...]: 5FF712A6: removed
# service dovecot restart
postfix/smtpd[...]: disconnect from localhost[127.0.0.1]
</pre>
e verifichiamo dai log che non ci siano errori:
<pre>
# tail -f /var/log/mail.log
... dovecot: master: Dovecot v2.1.7 starting up (core dumps disabled)
</pre>
 
=== Test della configurazione ===
Apriamo un altro terminale e controlliamo i log della posta in tempo reale:
<pre>
# tail -f /var/log/mail.log
</pre>
Dal primo terminale aperto proviamo a inviare una semplice prima mail di prova:
<pre>
# echo test | mail john@example.org
</pre>
Nei log dovremmo trovare qualcosa di simile:
<pre>
Oct 20 17:42:32 sirius postfix/pickup[22273]: A6F8EB55: uid=0 from=<root>
Oct 20 17:42:32 sirius postfix/cleanup[22582]: A6F8EB55: message-id=<20131020154232.A6F8EB55@sirius.localdomain>
Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: from=<root@sirius.workaround.org>, size=287, nrcpt=1 (queue active)
Oct 20 17:42:32 sirius dovecot: auth-worker(22635): mysql(127.0.0.1): Connected to database mailserver
Oct 20 17:42:32 sirius dovecot: lda(john@example.org): msgid=<20131020154232.A6F8EB55@sirius.localdomain>: saved mail to INBOX
Oct 20 17:42:32 sirius postfix/pipe[22586]: A6F8EB55: to=<john@example.org>, relay=dovecot, delay=0.14, delays=0.04/0/0/0.1, dsn=2.0.0, status=sent (delivered via dovecot service)
Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: removed
</pre>
All'interno della directory principale di archiviazione, Dovecot dovrebbe aver creato tutta la struttura di directory per il dominio e per l'utente di test:
<pre>
# find /var/vmail
/var/vmail/
/var/vmail/example.org
/var/vmail/example.org/john
/var/vmail/example.org/john/Maildir
/var/vmail/example.org/john/Maildir/dovecot.index.log
/var/vmail/example.org/john/Maildir/cur
/var/vmail/example.org/john/Maildir/dovecot-uidvalidity.5263f9e8
/var/vmail/example.org/john/Maildir/new
/var/vmail/example.org/john/Maildir/new/1382283752.M737526P22632.sirius,S=352,W=362
/var/vmail/example.org/john/Maildir/dovecot-uidvalidity
/var/vmail/example.org/john/Maildir/tmp
/var/vmail/example.org/john/Maildir/dovecot-uidlist
/var/vmail/example.org/john/Maildir/dovecot.index.cache
</pre>
</pre>
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 ====
==== Invio di email tramite telnet ====


E' il momento di verificare la corretta ricezione della mail:
Installiamo innanzitutto il pacchetto telnet:
<pre>
<pre>
$ cd /var/vmail/example.com/john/Maildir
# aptitude install telnet
$ find
</pre>
.
Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server:
./cur
<pre>
./new
# telnet localhost smtp
./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.
</pre>
</pre>
La mail è arrivata correttamente. Premiamo <code>q</code> due volte per uscire da <code>mutt</code>.
Dovremmo ottenere come risposta:
 
==== 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.
<br/>
Stabiliamo una connessione POP3 con il nostro server:
<pre>
<pre>
$ telnet localhost pop3
Trying 127.0.0.1...
Trying 127.0.0.1...
Connected to localhost.
Connected to localhost.
Escape character is '^]'.
Escape character is '^]'.
+OK Dovecot ready.
220 mailtest ESMTP Postfix (Debian/GNU)
user john@example.com
</pre>
+OK
Ottimo. Postfix è funzionante e possiamo proseguire nella sessione di invio della mail:
pass summersun
<pre>
+OK Logged in.
ehlo example.com
list
250-my-new-mailserver
+OK 1 messages:
250-PIPELINING
1 474
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.
.
.
retr 1
250 2.0.0 Ok: queued as A9D64379C4
+OK 474 octets
quit
Return-Path: <steve@example.com>
</pre>
X-Original-To: john@example.com
Un controllo al file di log <code>/var/log/mail.log</code> dovrebbe confermarci che la mail è stata correttamente inviata:
Delivered-To: john@example.com
<pre>
Received: from example.com (localhost [127.0.0.1])
postfix/smtpd[...]: connect from localhost[127.0.0.1]
    by ... (Postfix) with ESMTP id 692DF379C7
postfix/smtpd[...]: 5FF712A6: client=localhost[127.0.0.1]
    for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
postfix/cleanup[...]: 5FF712A6: message-id=<...>
Message-Id: <...>
postfix/qmgr[...]: 5FF712A6: from=<steve@example.com>, size=364, nrcpt=1 (queue active)
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
postfix/pipe[...]: 5FF712A6: to=<john@example.com>, relay=dovecot, ..., status=sent (delivered via dovecot service)
From: steve@example.com
postfix/qmgr[...]: 5FF712A6: removed
To: undisclosed-recipients:;
postfix/smtpd[...]: disconnect from localhost[127.0.0.1]
</pre>
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.


Hi John,
==== Controllo della mailbox dell'utente ====


just wanted to drop you a note.
E' il momento di verificare la corretta ricezione della mail:
<pre>
$ cd /var/vmail/example.com/john/Maildir
$ find
.
.
quit
./cur
+OK Logging out.
./new
Connection closed by foreign host.
./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.
</pre>
</pre>
Effettuata questa prima verifica di funzionamento, sarà possibile utilizzare un qualsiasi email client per le operazioni quotidiane.
La mail è arrivata correttamente. Premiamo <code>q</code> due volte per uscire da <code>mutt</code>.


==== Test del server IMAP ====
==== Test del server POP3 ====


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.<br/>
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.
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.
<br/>
<br/>
Per verificare il corretto funzionamento del server IMAP possiamo utilizzare il client ''mutt'':
Stabiliamo una connessione POP3 con il nostro server:
<pre>
<pre>
$ mutt -f imap://john@example.com@localhost
$ telnet localhost pop3
</pre>
Trying 127.0.0.1...
Oppure, in alternativa, aprire una connessione IMAP attraverso telnet:
<pre>
$ telnet localhost imap2
Trying 127.0.0.1...
Connected to localhost.
Connected to localhost.
Escape character is '^]'.
Escape character is '^]'.
* OK Dovecot ready.
+OK Dovecot ready.
1 login john@example.com summersun
user john@example.com
1 OK Logged in.
+OK
2 list "" "*"
pass summersun
* LIST (\HasNoChildren) "." "INBOX"
+OK Logged in.
2 OK List completed.
list
3 select "INBOX"
+OK 1 messages:
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1 474
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
.
* 1 EXISTS
retr 1
* 0 RECENT
+OK 474 octets
* OK [UIDVALIDITY 1180039205] UIDs valid
Return-Path: <steve@example.com>
* OK [UIDNEXT 3] Predicted next UID
X-Original-To: john@example.com
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
Delivered-To: john@example.com
Received: from example.com (localhost [127.0.0.1])
Received: from example.com (localhost [127.0.0.1])
        by ... (Postfix) with ESMTP id 692DF379C7
    by ... (Postfix) with ESMTP id 692DF379C7
        for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
    for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
Message-Id: <...>
Message-Id: <...>
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
Riga 871: Riga 931:


just wanted to drop you a note.
just wanted to drop you a note.
)
.
5 OK Fetch completed.
quit
6 logout
+OK Logging out.
* BYE Logging out
Connection closed by foreign host.
6 OK Logout completed.
</pre>
</pre>
Effettuata questa prima verifica di funzionamento, sarà possibile utilizzare un qualsiasi email client per le operazioni quotidiane.


==== Test dei server POP3s e IMAPs ====
==== Test del server IMAP ====


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'':
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.<br/>
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.
<br/>
Per verificare il corretto funzionamento del server IMAP possiamo utilizzare il client ''mutt'':
<pre>
<pre>
$ mutt -f imaps://john@example.com@localhost
$ mutt -f imap://john@example.com@localhost
</pre>
</pre>
Dovecot all'atto dell'installazione genera un certificato self-signed. Potete decidere di utiizzarlo, oppure di generarne un secondo personalizzato:
Oppure, in alternativa, aprire una connessione IMAP attraverso telnet:
<pre>
<pre>
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
$ telnet localhost imap2
    -keyout /etc/ssl/private/dovecot.pem
Trying 127.0.0.1...
</pre>
Connected to localhost.
Durante la generazione del certificato vi saranno poste alcune domande:
Escape character is '^]'.
<pre>
* OK Dovecot ready.
Generating a 1024 bit RSA private key
1 login john@example.com summersun
.........++++++
1 OK Logged in.
............................++++++
2 list "" "*"
writing new private key to '/etc/ssl/certs/dovecot.pem'
* LIST (\HasNoChildren) "." "INBOX"
-----
2 OK List completed.
Country Name (2 letter code) [AU]:DE
3 select "INBOX"
State or Province Name (full name) [Some-State]:Hamburg
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
Locality Name (eg, city) []:Hamburg
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:workaround email service
* 1 EXISTS
Organizational Unit Name (eg, section) []:
* 0 RECENT
Common Name (eg, YOUR name) []:mailtest.workaround.org
* OK [UIDVALIDITY 1180039205] UIDs valid
Email Address []:postmaster@workaround.org
* OK [UIDNEXT 3] Predicted next UID
</pre>
3 OK [READ-WRITE] Select completed.
L'impostazione più importante è la definizione del <code>Common Name</code>, dove va inserito il fully-qualified name (FQDN) del mail server. Il certificato generato sarà valido per 10 anni (3650 giorni).
4 fetch 1 all
<br/>
* 1 FETCH (FLAGS (\Seen) INTERNALDATE .........
Infine impostiamo i corretti permessi sul file certificato:
4 OK Fetch completed.
<pre>
5 fetch 1 body[]
# chmod o= /etc/ssl/private/dovecot.pem
* 1 FETCH (BODY[] {474}
</pre>
Return-Path: <steve@example.com>
e riavviamo Dovecot per fargli prendere il nuovo certificato:
X-Original-To: john@example.com
<pre>
Delivered-To: john@example.com
# /etc/init.d/dovecot restart
Received: from example.com (localhost [127.0.0.1])
</pre>
        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:;


=== Autenticazione su SMTP ===
Hi John,


==== Open relays server ====
just wanted to drop you a note.
)
5 OK Fetch completed.
6 logout
* BYE Logging out
6 OK Logout completed.
</pre>


Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:
==== Test dei server POP3s e IMAPs ====
* il destinatario è un utente del mail server
* il mittente sta inviando la mail dal nostro local network, definito dalla direttiva <code>mynetworks</code> 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====
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'':
 
Impostare la direttiva <code>smtpd_recipient_restrictions</code> correttamente è importantissimo. Normalmente è possibile definire le reti abilitate al relay sul nostro mail server attraverso la direttiva <code>mynetworks</code> contenuta nel file <code>main.cf</code>:
<pre>
<pre>
# postconf -e mynetworks=192.168.50.0/24
$ mutt -f imaps://john@example.com@localhost
</pre>
</pre>
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.
Dovecot all'atto dell'installazione genera un certificato self-signed. Potete decidere di utiizzarlo, oppure di generarne un secondo personalizzato:
<br/>
<pre>
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.
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
    -keyout /etc/ssl/private/dovecot.pem
</pre>
Durante la generazione del certificato vi saranno poste alcune domande:
<pre>
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
</pre>
L'impostazione più importante è la definizione del <code>Common Name</code>, dove va inserito il fully-qualified name (FQDN) del mail server. Il certificato generato sarà valido per 10 anni (3650 giorni).
<br/>
<br/>
Questo è il momento in cui entra in gioco l'autenticazione SMTP.
Infine impostiamo i corretti permessi sul file certificato:
<br/>
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:
<pre>
<pre>
# postconf -e smtpd_sasl_type=dovecot
# chmod o= /etc/ssl/private/dovecot.pem
# 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
</pre>
</pre>
* <code>smtpd_sasl_auth_enable</code> abilita l'autenticazione SMTP
e riavviamo Dovecot per fargli prendere il nuovo certificato:
* <code>smtpd_recipient_restrictions</code> definisce le regole che sono controllate per permettere il relay. Nel nostro caso il relay è permesso se:
** <code>permit_mynetworks</code>: l'utente proviene dalla nostra rete, oppure
** <code>permit_sasl_authenticated</code>: l'utente si è autenticato, oppure
** <code>reject_unauth_destination</code>: la mail è destinata a un utente di un nostro dominio virtuale
 
Riavviamo infine Postfix:
<pre>
<pre>
# /etc/init.d/postfix restart
# /etc/init.d/dovecot restart
</pre>
</pre>


==== Test della configurazione ====
=== 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 <code>mynetworks</code> 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====


Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:
Impostare la direttiva <code>smtpd_recipient_restrictions</code> correttamente è importantissimo. Normalmente è possibile definire le reti abilitate al relay sul nostro mail server attraverso la direttiva <code>mynetworks</code> contenuta nel file <code>main.cf</code>:
<pre>
<pre>
$ telnet localhost smtp
# postconf -e mynetworks=192.168.50.0/24
Trying 127.0.0.1...
</pre>
Connected to localhost.
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.
<br/>
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.
<br/>
Questo è il momento in cui entra in gioco l'autenticazione SMTP.
<br/>
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:
<pre>
# postconf -e smtpd_sasl_type=dovecot
# postconf -e smtpd_sasl_path=private/auth
# postconf -e smtpd_sasl_auth_enable=yes
# postconf -e smtpd_tls_security_level=may
# postconf -e smtpd_tls_auth_only=yes
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/mailserver.pem
# postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
</pre>
* <code>smtpd_sasl_auth_enable</code> abilita l'autenticazione SMTP
* <code>smtpd_recipient_restrictions</code> definisce le regole che sono controllate per permettere il relay. Nel nostro caso il relay è permesso se:
** <code>permit_mynetworks</code>: l'utente proviene dalla nostra rete, oppure
** <code>permit_sasl_authenticated</code>: l'utente si è autenticato, oppure
** <code>reject_unauth_destination</code>: la mail è destinata a un utente di un nostro dominio virtuale
NOTA: la direttiva <code>postconf -e smtpd_tls_auth_only=yes</code> è da utilizzarsi '''solo''' se vogliamo che i nostri utenti siano costretti a utilizzare SSL per scaricare e inviare la loro posta.
<br/>
<br/>
Riavviamo infine Postfix:
<pre>
# /etc/init.d/postfix restart
</pre>
 
==== Test della configurazione ====
 
Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:
<pre>
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)
220 mailtest ESMTP Postfix (Debian/GNU)
Riga 1 044: Riga 1 165:
==== Configurazione di Spamassassin ====
==== Configurazione di Spamassassin ====


Verifichiamo che il demone di SpamAssassin sia attivo, aprendo il file:
<pre>
# nano /etc/default/spamassassin
</pre>
e modificando la riga:
<pre>
ENABLED=0
</pre>
in
<pre>
ENABLED=1
</pre>
Avviamo SpamAssassin e abilitiamo l'aggiornamento automatico delle regole:
<pre>
# sa-update && service spamassassin restart
</pre>
Controlliamo che il servizio di aggiornamento automatico si sia abilitato, verificando che in <code>/etc/default/spamassassin</code> ci sia la riga:
<pre>
CRON=1
</pre>
Verifichiamo che SpamAssassin sia attivo:
<pre>
# netstat -ntpl | grep spamd
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2459/spamd.pid
</pre>
Cambiare o aggiungere i seguenti parametri nel file /etc/spamassassin/local.cf come segue:
Cambiare o aggiungere i seguenti parametri nel file /etc/spamassassin/local.cf come segue:
<pre>
<pre>
Riga 1 060: Riga 1 206:
</pre>
</pre>
che dovrebbe restituire una riga vuota.<br/>
che dovrebbe restituire una riga vuota.<br/>
Verifichiamo che il demone di SpamAssassin sia attivo, aprendo il file:
 
==== Configurazione di AMaViS ====
AMaViS (A Mail Virus Scanner) è un'interfaccia tra Postfix, SpamAssassin e un virus scanner come ClamAV.
<br/>
Installiamo i file necessari:
<pre>
<pre>
# nano /etc/default/spamassassin
# apt-get install amavisd-new clamav-daemon clamav-testfiles clamav-freshclam
</pre>
</pre>
e modificando la riga:
La configurazione si AMaViS è divisa in alcuni files nella directory <code>/etc/amavis/conf.d</code>.
<pre>
ENABLED=0
</pre>
in
<pre>
ENABLED=1
</pre>
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 <code>/etc/amavis/conf.d</code>.
<br/>
<br/>
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file:
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file:
Riga 1 127: Riga 1 269:
aggiungendo le linee:
aggiungendo le linee:
<pre>
<pre>
smtp-amavis unix -      -      n    -      2 smtp
smtp-amavis unix -      -      n    -      5 smtp
     -o smtp_data_done_timeout=1200
     -o smtp_data_done_timeout=1200
     -o smtp_send_xforward_command=yes
     -o smtp_send_xforward_command=yes
    -o smtp_tls_note_starttls_offer=no
     -o disable_dns_lookups=yes
     -o disable_dns_lookups=yes
     -o max_use=20
     -o max_use=20
Riga 1 151: Riga 1 294:
     -o smtpd_client_connection_count_limit=0
     -o smtpd_client_connection_count_limit=0
     -o smtpd_client_connection_rate_limit=0
     -o smtpd_client_connection_rate_limit=0
     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
     -o local_header_rewrite_clients=
     -o local_header_rewrite_clients=
    -o smtpd_milters=
</pre>
</pre>
Quindi riavviamo Postfix:
Quindi riavviamo Postfix:
Riga 1 199: Riga 1 343:
Come ultima cosa modifichiamo i permessi del file in modo che nessun utente non autorizzato possa leggere la password del nostro database:
Come ultima cosa modifichiamo i permessi del file in modo che nessun utente non autorizzato possa leggere la password del nostro database:
<pre>
<pre>
# chmod o= /etc/amavis/conf.d/50-user
# chmod 640 /etc/amavis/conf.d/50-user
</pre>
Testiamo il funzionamento di ClamAV:
<pre>
# clamdscan /usr/share/clamav-testfiles/
/usr/share/clamav-testfiles/clam.pdf: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.chm: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.sis: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.impl.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-nsis.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tar.gz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bz2.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.7z: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-yc.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ole.doc: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.newc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-aspack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ppt: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea05.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea06.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.html: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-upack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.bz2: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-be.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.cab: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.mbox.base64: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.arj: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.binhex: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-fsg.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.mbox.uu: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.odc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tnef: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-mew.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-upx.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-pespin.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.mail: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-wwpack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-petite.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.szdd: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.d64.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-le.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.rtf: ClamAV-Test-File FOUND
----------- SCAN SUMMARY -----------
Infected files: 44
Time: 1.478 sec (0 m 1 s)
</pre>
 
Ora proviamo a inviare una mail infetta attraverso Postfix, per vedere se AMaViS e ClamAV si comportano come ci aspettiamo:
<pre>
# swaks -t john@example.org --attach - --server localhost --suppress-data < /usr/share/clamav-testfiles/clam.exe
</pre>
 
Tra le altre righe in <code>/var/log/mail.log</code> dovremmo trovare una cosa del genere:
<pre>
29 23:16:23 sirius amavis[4558]: (04558-02) Blocked INFECTED (ClamAV-Test-File) {DiscardedOutbound,Quarantined}, LOCAL [::1]:44226 [::1] <root@mailserver.example.org> -> <john@example.org>, quarantine: C/virus-ClS0k87Qzm4Q, Queue-ID: 6608ED6B, Message-ID: <20131029221623.6608ED6B@sirius.localdomain>, mail_id: ClS0k87Qzm4Q, Hits: -, size: 1547, 128 ms
</pre>
segno che ClamAV è intervenuto correttamente, bloccando l'email infetta.
<br/>
La mail infetta è stata spostata in <code>/var/lib/amavis/virusmails/C/virus-ClS0k87Qzm4Q</code> per essere eventualmente analizzata.
 
<br/>
Possiamo impostare uno script per pulire la quarantena attraverso <code>cron</code>:
<pre>
#!/bin/dash
[ -d /var/lib/amavis/virusmails ] && {
        find /var/lib/amavis/virusmails/. -type f -name 'virus-*' -ctime +7 -de$
        find /var/lib/amavis/virusmails/. -type f -ctime +30 -delete
}
exit 0
</pre>
</pre>


Riga 1 208: Riga 1 427:
=== Amministrare gli utenti virtuali ===
=== Amministrare gli utenti virtuali ===


====ISPwebAdmin (web interface): introduzione ====
==== GRSoft Mail Manager ====
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: [[http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz Download]]
A questo indirizzo: http://www.grs-service.ch/pub/grs_mminstallation.html è possibile trovare un'interfaccia per la gestione degli account mail. GRSoft Mail Manager è scritto in PHP e non richiede dipendenze per funzionare.
# Scaricate il file e scompattatelo in una sottodirectory di <code>/var/www/</code>, ad esempio <code>/var/www/mailmanager</code>
# Aprite un browser e navigate verso l'indirizzo: http://ip.del.nostro.server/mailmanager/install.php
# Seguite le istruzioni per l'installazione. Allo Step 3 viene richiesta una coppia di credenziali MySQL con privilegi sufficienti per scrivere una tabella all'interno del database utilizzato in questa guida
# Alla fine dell'installazione seguite le istruzioni per rimuovere i files non più necessari
L'interfaccia permette la definizione di un Super User e di uno o più amministratori per ogni dominio virtuale che verrà creato.
 
==== Mail Admin Tool ====
Un'interfaccia alternativa può essere scaricata a questo indirizzo: [http://mat.ssdata.dk/ Mail Admin Tool].
 
==== Broatcast Mail Administrator ====
La peculiarità di questa interfaccia alternativa è che rende possibile impostare il numero massimo di indirizzi email che ogni dominio può avere. In questo modo possiamo ad esempio avere un dominio con caselle email illimitate e un altro dominio con 5 caselle disponibili. L'interfaccia è scaricabile da qui: [http://www.blog.broatcast.de/broatcast-mail-administrator Broatcatst Mail Administrator]
 
==== ISPwebAdmin (web interface): introduzione ====
{{Warningbox|Interfaccia obsoleta e non più sviluppata. Si consiglia di utilizzare GRSoft Mail Manager}}
E' disponibile un'ulteriore interfaccia web per amministrare i domini virtuali, gli utenti virtuali e gli alias. L'interfaccia si chiama ISPWebAdmin ed è disponibile per il download all'indirizzo: [[http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz Download]]


==== Installazione ====
===== 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:
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:
Riga 1 300: Riga 1 534:
Il file di log si troverà in <code>/var/log/runit-ispwebadmin</code>.
Il file di log si troverà in <code>/var/log/runit-ispwebadmin</code>.


==== Configurazione del file <code>run.ini</code> ====
===== Configurazione del file <code>run.ini</code> =====


Il file creato con il comando <code>paster make-config run.ini</code> 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:
Il file creato con il comando <code>paster make-config run.ini</code> 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:
Riga 1 311: Riga 1 545:
mysql://root:seoroct3@mailserver.example.com/mailserver?charset=utf8
mysql://root:seoroct3@mailserver.example.com/mailserver?charset=utf8
</pre>
</pre>
=== 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.
# Scaricate il file e scompattatelo in una sottodirectory di <code>/var/www/</code>, ad esempio <code>/var/www/mailmanager</code>
# Aprite un browser e navigate verso l'indirizzo: http://ip.del.nostro.server/mailmanager/install.php
# Seguite le istruzioni per l'installazione. Allo Step 3 viene richiesta una coppia di credenziali MySQL con privilegi sufficienti per scrivere una tabella all'interno del database utilizzato in questa guida
# Alla fine dell'installazione seguite le istruzioni per rimuovere i files non più necessari


=== Impostazione dei record DNS ===
=== Impostazione dei record DNS ===
Riga 1 404: Riga 1 631:
</pre>
</pre>
In questo caso abbiamo bloccato alcuni domini e autorizzato il dominio ferdy.it a inviarci mail senza nessun ulteriore controllo.
In questo caso abbiamo bloccato alcuni domini e autorizzato il dominio ferdy.it a inviarci mail senza nessun ulteriore controllo.
Quindi facciamo in modo che Postfix si crei il database relativo:
<br/>
Inseriamo alcuni ulteriori controlli sull'header e sul body della mail, aggiungendo la sezione:
<pre>
<pre>
# postmap /etc/postfix/access
# Verifico correttezza header e body
header_checks = pcre:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
</pre>
e creando i due file relativi:
<pre>
# nano /etc/postfix/header_checks
</pre>
con contenuto (da scrivere in una riga sola):
<pre>
/^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|ht[at]|inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
\{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x
REJECT Allegato "$2" con estensione proibita ".$4"
</pre>
<pre>
# nano /etc/postfix/body_checks
</pre>
<pre>
/^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/
REJECT IFRAME vulnerability exploit
</pre>
Quindi facciamo in modo che Postfix si crei il database relativo:
<pre>
# postmap /etc/postfix/access
</pre>
</pre>
Questo comando andrà ripetuto ad ogni modifica del file.
Questo comando andrà ripetuto ad ogni modifica del file.


=== SPF per ridurre ancora di più lo spam ===
==== Un esempio di main.cf ====
''SPF'', acronimo per ''Sender Policy Framework'', è un sistema attraverso il quale il proprietario di un dominio può definire quali indirizzi IP sono autorizzati a inviare le sue mail.
<pre>
<pre>
$> dig +short workaround.org txt
###############################
"v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"
# Configurazioni iniziali
</pre>
###############################
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.
 
<br/>
# Messaggio di benvenuto
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:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
* impostare un record TXT nella nostra zona per definire quali indirizzi IP sono autorizzati a inviare mail a nome nostro
biff = no
* controllare le voci SPF dei server mittenti e respingere la mail in arrivo da IP non autorizzati


==== Impostare una voce SPF ====
# appending .domain is the MUA's job.
append_dot_mydomain = no


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.
# Uncomment the next line to generate "delayed mail" warnings
<br/>
#delay_warning_time = 4h
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 ====
readme_directory = no


Fortunatamente esiste un pacchetto Debian che rende il controllo dei record SPF una cosa molto semplice. Iniziamo con l'installazione del pacchetto:
<pre>
# apt-get install tumgreyspf
</pre>
<code>tumgreyspf</code> è 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 <code>smtpd_recipient_restrictions</code>. Ad esempio:
<pre>
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    [ ... ]
    check_policy_service unix:private/tumgreyspf
    reject_unauth_destination
</pre>
Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file <code>/etc/postfix/master.cf</code>:
<pre>
tumgreyspf unix  -      n      n      -      -      spawn
    user=tumgreyspf argv=/usr/bin/tumgreyspf
</pre>
Ora riavviamo Postfix:
<pre>
# postfix reload
</pre>


==== Verifica del funzionamento di SPF ====


===== SPF okay =====
#############################
# Configurazione SSL
#############################


Controlliamo il file <code>/var/log/mail.log</code>. Ogni nuova mail in arrivo dovrebbe adesso avere una nuova riga aggiunta da <code>tumgreyspf</code>. Se il controllo SPF è risultato positivo, dovremmo avere qualcosa come:
# TLS parameters
<pre>
smtpd_tls_cert_file = /etc/ssl/certs/mailserver.pem
tumgreyspf[24672]: sender SPF authorized: QUEUE_ID=""; identity=mailfrom;
smtpd_tls_key_file = /etc/ssl/private/mailserver.pem
  client-ip=26.21.244.31; helo=squedge2.squ.edu.om;
smtpd_use_tls = yes
  envelope-from=…@squ.edu.om;
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
  receiver=…@workaround.org;
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
</pre>
smtpd_tls_security_level = may
Questo significa che il mittente <code>…@squ.edu.om</code> è stato autorizzato all'invio della mail dopo un controllo dei record SPF.
smtpd_tls_auth_only = no


===== SPF fail =====


Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere:
<pre>
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;
</pre>
La mail è stata respinta.


===== SPF softfail =====
######################################
# Configurazione
######################################


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:
myhostname = mail01.xxxxx.org
<pre>
alias_maps = hash:/etc/aliases
tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID="";
alias_database = hash:/etc/aliases
  identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au;
myorigin = /etc/mailname
  envelope-from=…@rollouts.com; receiver=…@workaround.org
mydestination = mail01.xxxxx.org, localhost.xxxxx.org, , localhost.xxxxxyy.com, localhost
</pre>
relayhost =
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:
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/24
<pre>
mailbox_command = procmail -a "$EXTENSION"
Received-SPF: Softfail (domain owner discourages use of this host) identity=mailfrom;
mailbox_size_limit = 0
  client-ip=61.146.93.243; helo=mail.163gd.com;
recipient_delimiter = +
  envelope-from=…@cantv.net; receiver=…@christoph-haas.de;
inet_interfaces = all
</pre>
inet_protocols = ipv4
In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.
queue_directory = /var/spool/postfix


===== No SPF information =====


Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere:
<pre>
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;
</pre>


=== Quote ===
#######################################
# Configurazione utenti virtuali MySQL
#######################################
 
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf


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.
<br/>
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.


==== Debian Lenny ====
===== Lenny: Attivare il plugin quota di Dovecot =====


Ci sono tre punti nel file <code>/etc/dovecot/dovecot.conf</code> dove occorre specificare l'abilitazione del plugin:
###################
<pre>
# Regole Antispam
protocol imap {
###################
  mail_plugins = quota imap_quota
}
protocol pop3 {
  mail_plugins = quota
}
protocol lda {
  mail_plugins = quota
}
</pre>


===== Lenny: Impostare una quota globale =====
# Verifico correttezza header e body
header_checks = pcre:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks


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.
# Abilito a spedire solo gli utenti presenti in MySQL
Nel file <code>/etc/dovecot/dovecot.conf</code> dovremo impostare:
smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cf
<pre>
plugin {
  quota = maildir:storage=1000000:messages=1000
}
</pre>
ricordando che i valori per lo storage sono espressi in KB.


===== Lenny: Impostare una quota utente =====
# Restrizioni helo
smtpd_helo_required = yes
smtpd_helo_restrictions =
        permit_mynetworks
        #reject_unknown_client
        #reject_invalid_hostname
        #reject_unauth_pipelining
        #reject_unknown_hostname
        #reject_non_fqdn_hostname


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:
# Restrizioni sui mittenti abilitati
<pre>
smtpd_sender_restrictions =
mysql>
        permit_mynetworks
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
        permit_sasl_authenticated
ADD `quota_messages` INT NOT NULL ;
        #reject_unknown_address
</pre>
        #reject_unauth_destination
Inoltre dovremo abilitare la direttiva <code>user sql</code> nel file <code>/etc/dovecot/dovecot.conf</code>, disabilitando la direttiva <code>user static</code> suggerita all'inizio del tutorial:
        reject_unauth_pipelining
<pre>
reject_unknown_sender_domain
#userdb static {
reject_non_fqdn_sender
# args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
reject_sender_login_mismatch
#
 
# Blocco alcuni domini spammer
smtpd_client_restrictions =
permit_mynetworks
        #check_client_access hash:/etc/postfix/access
        #reject_invalid_hostname
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client multi.uribl.com
        reject_rbl_client dsn.rfc-ignorant.org
        reject_rbl_client dul.dnsbl.sorbs.net
        reject_rbl_client list.dsbl.org
        reject_rbl_client sbl-xbl.spamhaus.org
        reject_rbl_client bl.spamcop.net
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client combined.rbl.msrbl.net
        reject_rbl_client rabl.nuclearelephant.com
        #reject_unknown_client
        permit
# Restrizioni sui destinatari
smtpd_recipient_restrictions =  
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
        check_client_access hash:/etc/postfix/access
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client multi.uribl.com
        reject_rbl_client dsn.rfc-ignorant.org
        reject_rbl_client dul.dnsbl.sorbs.net
        reject_rbl_client list.dsbl.org
        reject_rbl_client sbl-xbl.spamhaus.org
        reject_rbl_client bl.spamcop.net
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client combined.rbl.msrbl.net
        reject_rbl_client rabl.nuclearelephant.com
reject_rbl_client dnsbl-1.uceprotect.net
        reject_unknown_sender_domain
        reject_unauth_pipelining
        check_policy_service unix:private/tumgreyspf
        reject_non_fqdn_sender
        reject_non_fqdn_recipient
        reject_non_fqdn_hostname
        reject_invalid_hostname
 
# Non piu' di 200 destinatari al minuto
smtpd_client_recipient_rate_limit = 200
 
# Non piu' di 50 destinatari per ogni messaggio
smtpd_recipient_limit = 50


userdb sql {
# Numero di destinatari in eccesso prima che scatti il blocco
    args = /etc/dovecot/dovecot-sql.conf
smtpd_recipient_overshoot_limit = 21
}
</pre>
Infine dovremo aggiungere al file <code>/etc/dovecot/dovecot-sql.conf</code> la linea:
<pre>
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';
</pre>


===== Lenny: Cosa succede se un utente supera la quota =====
# Numero di errori massimi di un client prima di essere disconnesso
smtpd_hard_error_limit = 20


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".
# Impedisco invio mail ad alcuni utenti locali
authorized_submit_users = !www-data, static:all


==== Debian Squeeze ====
A partire da Dovecot 1.1, di default su Squeeze, la gestione delle quote è cambiata notevolmente.


===== Squeeze: Impostazione delle Quote root =====
 
Dobbiamo innanzitutto aprire il file di configurazione di Dovecot:
#########################
<pre>
# Configurazione Dovecot
# nano /etc/dovecot/dovecot.conf
#########################
 
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
 
 
 
###############################
# Integrazione con AMaViS
###############################
 
content_filter = smtp-amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
</pre>
</pre>
recarci alla sezione <code>plugin { }</code> e definire le quote root. Ad esempio:
 
=== SPF per ridurre ancora di più lo spam ===
''SPF'', acronimo per ''Sender Policy Framework'', è un sistema attraverso il quale il proprietario di un dominio può definire quali indirizzi IP sono autorizzati a inviare le sue mail.
<pre>
<pre>
plugin {
$> dig +short workaround.org txt
  quota = maildir:User quota
"v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"
  #quota2 = fs:Disk quota
  #quota3 = ...
}
</pre>
</pre>
In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.
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.
<br/>
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 ====


===== Squeeze: Quote rules =====
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.
A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota:
<br/>
<pre>
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.
plugin {
 
  # Quota root
==== Verificare i record SPF degli altri mail server ====
  quota = maildir:User quota
 
  # Quote rules
Fortunatamente esiste un pacchetto Debian che rende il controllo dei record SPF una cosa molto semplice. Iniziamo con l'installazione del pacchetto:
  # 1 - Dimensione massima 2 GB
  quota_rule = *:storage=2GB
  # 2 - Dimensione Cestino 200 MB
  quota_rule2 = Trash:storage=200MB
  # 3 - Dimensione cartella Spam 200MB
  quota_rule3 = Spam:storage=200MB
}
</pre>
===== Squeeze: Cosa succede se un utente supera la quota =====
In Squeeze possiamo finalmente configurare Dovecot in modo che invii un messaggio personalizzato agli utenti che hanno superato la loro quota disco. All'interno della solita sezione del file di configurazione di Dovecot aggiungiamo la riga:
<pre>
<pre>
plugin {
# apt-get install tumgreyspf
  quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
</pre>
</pre>
 
<code>tumgreyspf</code> è 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 <code>smtpd_recipient_restrictions</code>. Ad esempio:
===== Squeeze: messaggio di avvertimento =====
In Squeeze possiamo anche configurare Dovecot in modo che avvii un comando esterno quando la quota di un certo utente supera una certa percentuale. Come al solito dobbiamo recarci nella sezione <code>plugin { }</code> del file di configurazione di Dovecot e aggiungere le seguenti linee:
<pre>
<pre>
plugin {
smtpd_recipient_restrictions =
  quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95
    permit_mynetworks,
  quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80
    permit_sasl_authenticated,
}
    [ ... ]
    check_policy_service unix:private/tumgreyspf
    reject_unauth_destination
</pre>
</pre>
Nell'esempio precedente, lo script <code>quota-warning.sh</code> è eseguito una prima volta quando l'utente raggiunge l'80% del suo spazio disco e una seconda volta quando raggiunge il 95%.
Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file <code>/etc/postfix/master.cf</code>:
<br/>
Lo script va creato a mano:
<pre>
<pre>
# nano /usr/local/bin/quota-warning.sh
tumgreyspf unix  -      n      n      -      -      spawn
    user=tumgreyspf argv=/usr/bin/tumgreyspf
</pre>
</pre>
con contenuto:
Ora riavviamo Postfix:
<pre>
<pre>
#!/bin/sh
# postfix reload
</pre>


PERCENT=$1
==== Verifica del funzionamento di SPF ====
FROM="webmaster@example.com"
qwf="/tmp/quota.warning.$$"


echo "From: $FROM
===== SPF okay =====
To: $USER
To: postmaster@domain.org
Subject: Hai raggiunto il $PERCENT% del tuo spazio su disco!
Content-Type: text/plain; charset="UTF-8"


La tua mailbox ha raggiunto il $PERCENT% dello spazio disponibile. Sei pregato di eliminare le mail che non ti occorrono." >> $qwf
Controlliamo il file <code>/var/log/mail.log</code>. Ogni nuova mail in arrivo dovrebbe adesso avere una nuova riga aggiunta da <code>tumgreyspf</code>. Se il controllo SPF è risultato positivo, dovremmo avere qualcosa come:
<pre>
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;
</pre>
Questo significa che il mittente <code>…@squ.edu.om</code> è stato autorizzato all'invio della mail dopo un controllo dei record SPF.


cat $qwf | /usr/sbin/sendmail -f $FROM "$USER"
===== SPF fail =====
rm -f $qwf


exit 0
Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere:
</pre>
Rendiamo lo script eseguibile:
<pre>
<pre>
# chmod 750 /usr/local/bin/quota-warning.sh
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;
</pre>
</pre>
e siamo a posto.
La mail è stata respinta.
 
===== SPF softfail =====


=== Accesso tramite Webmail ===
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:
==== Squirrelmail ====
<pre>
Questo passaggio è facoltativo, ma ormai praticamente tutti i provider offrono ai loro utenti un mezzo per poter controllare le email da un browser.
tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID="";
<br/>
  identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au;
Per questo motivo durante l'iniziale installazione dei pacchetti abbiamo scelto anche il pacchetto <code>squirrelmail</code>: ''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: [http://packages.debian.org/search?keywords=squirrelmail Debian package]).
  envelope-from=…@rollouts.com; receiver=…@workaround.org
<br/>
Per impostarlo dobbiamo inannzitutto aggiungere la sua configurazione a quella di Apache:
<pre>
$> ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf
$> apache2ctl restart
</pre>
</pre>
Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail:
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:
<pre>
<pre>
$> squirrelmail-configure
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;
</pre>
</pre>
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.
In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.
<br/>
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.


===== No SPF information =====


===== Permettere il cambio password all'utente =====
Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere:
Può essere molto comodo dare all'utente la possibilità di cambiarsi la password per conto suo, senza stressare il sistemista di turno. La cosa più semplice è permetterglielo attraverso la webmail. Squirrelmail di default non prevede questa funzione, ma per fortuna esiste un ottimo plugin che fa al caso nostro. Andiamo quindi alla pagina del plugin (http://squirrelmail.org/plugin_view.php?id=25) e scarichiamolo. Quindi copiamolo nella directory:
<pre>
<pre>
/usr/share/squirrelmail/plugins
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;
</pre>
</pre>
e scompattiamolo:
 
=== 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.
<br/>
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.
 
==== Debian Lenny ====
===== Lenny: Attivare il plugin quota di Dovecot =====
 
Ci sono tre punti nel file <code>/etc/dovecot/dovecot.conf</code> dove occorre specificare l'abilitazione del plugin:
<pre>
<pre>
# tar zxvf change_sqlpass-3.3-1.2.tar.gz
protocol imap {
  mail_plugins = quota imap_quota
}
protocol pop3 {
  mail_plugins = quota
}
protocol lda {
  mail_plugins = quota
}
</pre>
</pre>
Prima di modificarne la configurazione dobbiamo compiere alcune operazioni propedeutiche:
 
===== Lenny: Impostare una quota globale =====
 
Il caso più semplice è quello in cui si intende impostare una quota limite comune e uguale per tutti gli utenti, ad esempio 1GB di spazio con non più di 1000 email archiviabili.
Nel file <code>/etc/dovecot/dovecot.conf</code> dovremo impostare:
<pre>
<pre>
# apt-get install php-mdb2 squirrelmail-compatibility
plugin {
# pear install DB
  quota = maildir:storage=1000000:messages=1000
}
</pre>
</pre>
Ora siamo pronti per configurare il plugin appena scaricato:
ricordando che i valori per lo storage sono espressi in KB.
 
===== Lenny: Impostare una quota utente =====
 
Se intendiamo impostare per alcuni utenti delle quote diverse da quelle globali, allora dobbiamo impostare la quota all'interno della tabella dei virtual_users. Utilizziamo la seguente query per aggiungere due colonne alla nostra tabella virtual_users:
<pre>
<pre>
# cd /usr/share/squirrelmail/plugins/change_sqlpass
mysql>
# cp config.php.sample config.php 
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
# vi config.php
ADD `quota_messages` INT NOT NULL ;
</pre>
</pre>
* Modifichiamo la riga:
Inoltre dovremo abilitare la direttiva <code>user sql</code> nel file <code>/etc/dovecot/dovecot.conf</code>, disabilitando la direttiva <code>user static</code> suggerita all'inizio del tutorial:
<pre>
<pre>
$csp_dsn = 'mysql://root:password@localhost/mailserver';
#userdb static {
#  args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
#
 
userdb sql {
    args = /etc/dovecot/dovecot-sql.conf
}
</pre>
</pre>
inserendo le credenziali per l'accesso al database mailserver.
Infine dovremo aggiungere al file <code>/etc/dovecot/dovecot-sql.conf</code> la linea:
* Modifichiamo la riga:
<pre>
<pre>
$lookup_password_query = 'SELECT count(*) FROM virtual_users WHERE email = "%1" AND password = %4';
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';
</pre>
</pre>
inserendo la query corretta per la ricerca dell'utente virtuale.
 
* Modifichiamo la riga:
===== Lenny: Cosa succede se un utente supera la quota =====
 
La gestione delle quote in Dovecot non è molto user-friendly. Il mittente non riceve un avviso se è vicino a superare la quota limite; in compenso, quando l'ha superata, le sue mail torneranno indietro con oggetto "Automatically rejected mail" e corpo della mail "Your message to <john@example.com> was automatically rejected: Quota exceeded".
 
==== Debian Squeeze ====
A partire da Dovecot 1.1, di default su Squeeze, la gestione delle quote è cambiata notevolmente.
 
===== Squeeze: Impostazione delle Quote root =====
Dobbiamo innanzitutto aprire il file di configurazione di Dovecot:
<pre>
<pre>
'UPDATE virtual_users SET password = %4 WHERE email = "%1"',
# nano /etc/dovecot/dovecot.conf
</pre>
</pre>
inserendo la query corretta per la modifica della password dell'utente virtuale.
recarci alla sezione <code>plugin { }</code> e definire le quote root. Ad esempio:
* Inseriamo il corretto metodo di crittazione usato dal nostro database:
<pre>
<pre>
$password_encryption = 'MD5';
plugin {
  quota = maildir:User quota
  #quota2 = fs:Disk quota
  #quota3 = ...
}
</pre>
</pre>
* Correggiamo la stringa:
In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.
 
===== Squeeze: Quote rules =====
A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota:
<pre>
<pre>
$csp_salt_static = '';
plugin {
</pre>
  # Quota root
e salviamo il file.
  quota = maildir:User quota
<br/>
  # Quote rules
Quindi riconfiguriamo Squirrelmail:
  # 1 - Dimensione massima 2 GB
  quota_rule = *:storage=2GB
  # 2 - Dimensione Cestino 200 MB
  quota_rule2 = Trash:storage=200MB
  # 3 - Dimensione cartella Spam 200MB
  quota_rule3 = Spam:storage=200MB
}
</pre>
===== Squeeze: Cosa succede se un utente supera la quota =====
In Squeeze possiamo finalmente configurare Dovecot in modo che invii un messaggio personalizzato agli utenti che hanno superato la loro quota disco. All'interno della solita sezione del file di configurazione di Dovecot aggiungiamo la riga:
<pre>
<pre>
# cd ../../config/
plugin {
# ./conf.pl
  quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
</pre>
</pre>
e attiviamo il plugin:
<pre> 
8. Plugins
x. change_sqlpass
Save S and exit Q.
</pre>
Effettuando il login nella nostra webmail, sotto la voce "Opzioni" troveremo la funzione "Cambia password".


==== Roundcube ====
===== Squeeze: messaggio di avvertimento =====
In alternativa (o affiancato) a Squirrelmail possiamo offrire il più moderno e eye-candy Roundcube, anch'esso presente nei repository di Debian. Per installarlo basta un comando:
In Squeeze possiamo anche configurare Dovecot in modo che avvii un comando esterno quando la quota di un certo utente supera una certa percentuale. Come al solito dobbiamo recarci nella sezione <code>plugin { }</code> del file di configurazione di Dovecot e aggiungere le seguenti linee:
* '''Lenny''':
<pre>
<pre>
# apt-get -t lenny-backports install roundcube
plugin {
  quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95
  quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80
}
</pre>
</pre>
* '''Squeeze''':
Nell'esempio precedente, lo script <code>quota-warning.sh</code> è eseguito una prima volta quando l'utente raggiunge l'80% del suo spazio disco e una seconda volta quando raggiunge il 95%.
<pre>
# apt-get install roundcube
</pre>
Rispondiamo di sì alla domanda dell'installer se configurare o meno un database con ''dbconfig-common'' e scegliamo come database il solito MySQL. Ci verrà poi richiesta la password di amministratore di MySQL e l'installazione terminerà.
<br/>
<br/>
Ora modifichiamo il file di configurazione:
Lo script va creato a mano:
<pre>
<pre>
# nano /etc/roundcube/main.inc.php
# nano /usr/local/bin/quota-warning.sh
</pre>
</pre>
modificando la linea:
con contenuto:
<pre>
<pre>
$rcmail_config['default_host'] = 'localhost';
#!/bin/sh
</pre>
 
Quindi modifichiamo il file che definisce il Virtual Host di Roundcube:
PERCENT=$1
<pre>
FROM="webmaster@example.com"
# nano /etc/roundcube/apache.conf
qwf="/tmp/quota.warning.$$"
</pre>
 
e decommentiamo le linee:
echo "From: $FROM
<pre>
To: $USER
    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
To: postmaster@domain.org
    Alias /roundcube /var/lib/roundcube
Subject: Hai raggiunto il $PERCENT% del tuo spazio su disco!
Content-Type: text/plain; charset="UTF-8"
 
La tua mailbox ha raggiunto il $PERCENT% dello spazio disponibile. Sei pregato di eliminare le mail che non ti occorrono." >> $qwf
 
cat $qwf | /usr/sbin/sendmail -f $FROM "$USER"
rm -f $qwf
 
exit 0
</pre>
</pre>
Installiamo i driver MDB2:
Rendiamo lo script eseguibile:
<pre>
<pre>
# pear install MDB2_Driver_mysql
# chmod 750 /usr/local/bin/quota-warning.sh
</pre>
</pre>
Riavviamo Apache:
e siamo a posto.
<pre>
 
/etc/init.d/apache2 restart
==== Debian Wheezy ====
</pre>
A partire da Debian Wheezy, la configurazione (può essere identica a quella per Squeeze) deve essere inserita nel file <code>/etc/dovecot/conf.d/90-quota.conf</code>.
e facciamo login nella nostra webmail all'indirizzo: <code>http:// your-domain/roundcube</code>


=== Filtri server-side: Sieve ===
=== Accesso tramite Webmail ===
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.
==== Squirrelmail ====
Questo passaggio è facoltativo, ma ormai praticamente tutti i provider offrono ai loro utenti un mezzo per poter controllare le email da un browser.
<br/>
<br/>
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".
Per questo motivo durante l'iniziale installazione dei pacchetti abbiamo scelto anche il pacchetto <code>squirrelmail</code>: ''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: [http://packages.debian.org/search?keywords=squirrelmail Debian package]).
<br/>
<br/>
Iniziamo creando un file di configurazione per Sieve:
Per impostarlo dobbiamo inannzitutto aggiungere la sua configurazione a quella di Apache:
<pre>
<pre>
# nano /var/vmail/globalsieverc
$> ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf
$> apache2ctl restart
</pre>
</pre>
contenente:
Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail:
<pre>
<pre>
require ["fileinto"];
$> squirrelmail-configure
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
  fileinto "spam";
  stop;
}
</pre>
</pre>
e verifichiamo che sia leggibile dall'utente <code>vmail</code>:
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.
<br/>
A questo punto visitando il sito: http://ip.del.nostro.server/squirrelmail possiamo effettuare il login con le credenziali di uno dei nostri virtual user e iniziare ad usare la webmail.
 
 
===== Permettere il cambio password all'utente =====
Può essere molto comodo dare all'utente la possibilità di cambiarsi la password per conto suo, senza stressare il sistemista di turno. La cosa più semplice è permetterglielo attraverso la webmail. Squirrelmail di default non prevede questa funzione, ma per fortuna esiste un ottimo plugin che fa al caso nostro. Andiamo quindi alla pagina del plugin (http://squirrelmail.org/plugin_view.php?id=25) e scarichiamolo. Quindi copiamolo nella directory:
<pre>
<pre>
# chown vmail /var/vmail/globalsieverc
/usr/share/squirrelmail/plugins
</pre>
</pre>
Quindi modifichiamo la configurazione di Dovecot e inseriamo un plugin per il global filtering delle mail:
e scompattiamolo:
<pre>
<pre>
# nano /etc/dovecot/dovecot.conf
# tar zxvf change_sqlpass-3.3-1.2.tar.gz
</pre>
</pre>
cercando la sezione <code>plugin { }</code> e inserendo:
Prima di modificarne la configurazione dobbiamo compiere alcune operazioni propedeutiche:
<pre>
<pre>
sieve_global_path = /var/vmail/globalsieverc
# apt-get install php-mdb2 squirrelmail-compatibility
# pear install DB
</pre>
</pre>
Riavviamo Dovecot:
Ora siamo pronti per configurare il plugin appena scaricato:
<pre>
<pre>
# /etc/init.d/dovecot restart
# cd /usr/share/squirrelmail/plugins/change_sqlpass
# cp config.php.sample config.php 
# vi config.php
</pre>
</pre>
 
* Modifichiamo la riga:
==== Test del filtro antispam ====
Inviamo al nostro utente una mail di spam:
<pre>
<pre>
# sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt
$csp_dsn = 'mysql://root:password@localhost/mailserver';
</pre>
</pre>
Nei log di Doecot dovremmo trovare una linea simile alla seguente:
inserendo le credenziali per l'accesso al database mailserver.
* Modifichiamo la riga:
<pre>
<pre>
deliver(john@example.com): 2009-07-01 01:00:22 Info: msgid=<GTUBE1.1010101@example.net>: saved mail to spam
$lookup_password_query = 'SELECT count(*) FROM virtual_users WHERE email = "%1" AND password = %4';
</pre>
</pre>
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:
inserendo la query corretta per la ricerca dell'utente virtuale.
# sottoscrivere manualmente anche il folder "Spam"
* Modifichiamo la riga:
# modificare il file <code>/var/vmail/example.com/john/Maildir/subscriptions</code> aggiungendo "spam" tra i folder disponibili
# utilizzare Squirrelmail periodicamente per controllare il folder Spam
 
==== Managesieve ====
Managesieve è un'interfaccia low-level per amministrare gli script di Sieve. Per abilitarla è necessario aggiungere <code>managesieve</code> alla linea <code>protocols</code> del nostro file <code>/etc/dovecot/dovecot.conf</code>; nella sezione <code>protocol managesieve</code> dovremmo trovare la linea <code>sieve=~/.dovecot.sieve</code> già impostata. Con questa impostazione il filtro Sieve per il nostro utente sarà posizionato in <code>/var/mail/example.com/john/.dovecot.sieve</code>.
 
=== 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:
<pre>
<pre>
# aptitude install avelsieve
'UPDATE virtual_users SET password = %4 WHERE email = "%1"',
</pre>
</pre>
Il pacchetto di Debian ha in alcune versioni un errore sulla porta di ascolto del demone Sieve; se la vostra versione è affetta da questo bug, al primo tentativo di login su Squirrelmail vi troverete davanti al messaggio:
inserendo la query corretta per la modifica della password dell'utente virtuale.
* Inseriamo il corretto metodo di crittazione usato dal nostro database:
<pre>
<pre>
Could not log on to timsieved daemon on your IMAP server localhost:4190
$password_encryption = 'MD5';
</pre>
</pre>
Il plugin avelsieve si è messo in ascolto sulla porta sbagliata... Apriamo il suo file di configurazione:
* Correggiamo la stringa:
<pre>
<pre>
# nano /usr/share/squirrelmail/plugins/avelsieve/config/config.php
$csp_salt_static = '';
</pre>
</pre>
e modifichiamo come segue la sezione incriminata:
e salviamo il file.
<br/>
Quindi riconfiguriamo Squirrelmail:
<pre>
<pre>
/* ======================================================================== */
# cd ../../config/
/* =================== ManageSieve Backend Options ======================== */
# ./conf.pl
/* ======================================================================== */
</pre>
/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */
e attiviamo il plugin:
 
<pre> 
/** DEBIAN CHANGE: Despite upstream's intention Debian changed this default
8. Plugins
*  distribution wide to 4190 which is thus default here.
x. change_sqlpass
*/
Save S and exit Q.
global $sieveport;
$sieveport = 4190;
</pre>
</pre>
Effettuando ora il login su Squirrelmail noteremo una nuova voce di menu chiamata "Filters" da cui potremo impostare tutte le regole che vogliamo.
Effettuando il login nella nostra webmail, sotto la voce "Opzioni" troveremo la funzione "Cambia password".


=== Eliminare le email vecchie ===
==== Roundcube ====
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:
In alternativa (o affiancato) a Squirrelmail possiamo offrire il più moderno e eye-candy Roundcube, anch'esso presente nei repository di Debian. Per installarlo basta un comando:
* '''Lenny''':
<pre>
<pre>
find /var/vmail -type f -ctime +7 -name '*,ST' -delete
# apt-get -t lenny-backports install roundcube
</pre>
</pre>
Con questo comando, che possiamo inserire nel crontab del server, vengono eliminate tutte le email cancellate e più vecchie di 7 giorni.
* '''Da Squeeze in poi''':
 
<pre>
=== Ulteriori armi contro lo Spam ===
# apt-get install roundcube
Possiamo aggiungere altri due filtri collaborativi contro lo spam seguendo queste due guide:
</pre>
Rispondiamo di sì alla domanda dell'installer se configurare o meno un database con ''dbconfig-common'' e scegliamo come database il solito MySQL. Ci verrà poi richiesta la password di amministratore di MySQL e l'installazione terminerà.
<br/>
<br/>
* [[Pyzor]]
Ora modifichiamo il file di configurazione:
* [[Razor]]
<pre>
 
# nano /etc/roundcube/main.inc.php
=== Troubleshooting ===
</pre>
Se abbiamo problemi nell'inviare o ricevere mail possiamo:
modificando le linee:
* controllare il file di log <code>/var/log/mail.log</code>; quasi tutti i problemi sono elencati in questo file, con messaggi di errore più o meno chiari
<pre>
* eseguire il comando <code>postfix check</code>: se l'output è vuoto significa che Postfix è configurato bene
$rcmail_config['default_host'] = 'localhost';
* verificare la coda delle mail con il comando <code>postqueue -p -v</code>
$rcmail_config['force_https'] = true;
* impostare l'immediata spedizione di tutte le mail in coda: <code>mailq -q</code>
</pre>
* verificare il funzionamento di Amavis:
{{Suggerimento|Se il server su cui è installato Roundcube è diverso da quello su cui girano Postfix e Dovecot, dovrete impostare correttamente Roundcube affinchè possa connettersi al server remoto: <nowiki>$rcmail_config['smtp_server'] = 'tls://12.34.56.78';</nowiki>}}
Quindi modifichiamo il file che definisce il Virtual Host di Roundcube:
<pre>
# nano /etc/roundcube/apache.conf
</pre>
e decommentiamo le linee:
<pre>
<pre>
# /etc/init.d/amavisd-new stop
    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
    Alias /roundcube /var/lib/roundcube
</pre>
Installiamo i driver MDB2:
<pre>
# pear install MDB2_Driver_mysql
</pre>
Riavviamo Apache:
<pre>
/etc/init.d/apache2 restart
</pre>
e facciamo login nella nostra webmail all'indirizzo: <code>http:// your-domain/roundcube</code>
 
===== Personalizzazione di Roundcube =====
Per essere più professionali nella nostra offerta, possiamo personalizzare alcune voci di Roundcube. Apriamo il suo file di configurazione:
<pre>
# nano /etc/roundcube/main.inc.php
</pre>
e modifichiamo le righe:
<pre>
#$rcmail_config['product_name'] = ‘RoundCube Webmail’;
$rcmail_config['product_name'] = ‘Il mio nome Webmail’;
</pre>
Quindi andiamo in <code>/var/lib/roundcube/skins/classic <oppure larry>/images</code> e sostituiamo il file <code>roundcube_logo.png</code> con una PNG contenente il nostro logo.
 
=== Filtri server-side: Sieve per Roundcube ===
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.
<br/>
Utilizzando Sieve, un mail filter simile a procmail (che non utilizziamo perchè non lavora con le mailbox virtuali) possiamo fare in modo che i nostri utenti riescano a impostare dei filtri e delle regole ''server-side''.
<br/>
Roundcube è già pienamente compatibile con Sieve, dobbiamo solo informarlo della sua installazione:
<pre>
# cp /usr/share/roundcube/plugins/managesieve/config.inc.php.dist /etc/roundcube/plugins/managesieve/config.inc.php
</pre>
Ora apriamo il file di configurazione del plugin:
<pre>
# nano /etc/roundcube/plugins/managesieve/config.inc.php
</pre>
e impostiamo la corretta porta TCP dove Dovecot si aspetta le connessioni da Sieve:
<pre>
$rcmail_config['managesieve_port'] = 4190;
</pre>
Quindi abilitiamo il plugin ''managesieve'' in RoundCube:
<pre>
# nano /etc/roundcube/main.inc.php
</pre>
<pre>
$rcmail_config['plugins'] = array('managesieve');
</pre>
A questo punto, dalla schermata ''Impostazioni'' di ''Roundcube'' ogni utente troverà una nuova scheda chiamata ''Filtri'', dove potrà impostare tutti i filtri che gli interessano.
<br/>
Creiamo un file di configurazione per Sieve:
<pre>
# nano /var/vmail/globalsieverc
</pre>
contenente:
<pre>
require ["fileinto"];
 
# Sposto lo spam in un folder apposito
if header :contains "X-Spam-Flag" ["YES"] {
fileinto "Junk";
stop;
}
</pre>
e verifichiamo che sia leggibile dall'utente <code>vmail</code>:
<pre>
# chown vmail /var/vmail/globalsieverc
</pre>
Quindi modifichiamo la configurazione di Dovecot e inseriamo un plugin per il global filtering delle mail:
<pre>
# nano /etc/dovecot/conf.d/15-lda.conf
</pre>
e decommentando la voce:
<pre>
  mail_plugins = $mail_plugins sieve
</pre>
<pre>
# nano /etc/dovecot/conf.d/90-sieve.conf
</pre>
<pre>
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_before = /var/vmail/globalsieverc
}
</pre>
Riavviamo Dovecot:
<pre>
# /etc/init.d/dovecot restart
</pre>
 
=== Filtri server-side: Sieve per Squirrelmail ===
Managesieve è un'interfaccia low-level per amministrare gli script di Sieve. Per abilitarla è necessario aggiungere <code>managesieve</code> alla linea <code>protocols</code> del nostro file <code>/etc/dovecot/dovecot.conf</code>; nella sezione <code>protocol managesieve</code> dovremmo trovare la linea <code>sieve=~/.dovecot.sieve</code> già impostata. Con questa impostazione il filtro Sieve per il nostro utente sarà posizionato in <code>/var/mail/example.com/john/.dovecot.sieve</code>.
 
<br/>
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:
<pre>
# aptitude install avelsieve
</pre>
Il pacchetto di Debian ha in alcune versioni un errore sulla porta di ascolto del demone Sieve; se la vostra versione è affetta da questo bug, al primo tentativo di login su Squirrelmail vi troverete davanti al messaggio:
<pre>
Could not log on to timsieved daemon on your IMAP server localhost:4190
</pre>
Il plugin avelsieve si è messo in ascolto sulla porta sbagliata... Apriamo il suo file di configurazione:
<pre>
# nano /usr/share/squirrelmail/plugins/avelsieve/config/config.php
</pre>
e modifichiamo come segue la sezione incriminata:
<pre>
/* ======================================================================== */
/* =================== ManageSieve Backend Options ======================== */
/* ======================================================================== */
/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */
 
/** DEBIAN CHANGE: Despite upstream's intention Debian changed this default
*  distribution wide to 4190 which is thus default here.
*/
global $sieveport;
$sieveport = 4190;
</pre>
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:
<pre>
find /var/vmail -type f -ctime +7 -name '*,ST' -delete
</pre>
Con questo comando, che possiamo inserire nel crontab del server, vengono eliminate tutte le email cancellate e più vecchie di 7 giorni.
 
=== Ulteriori armi contro lo Spam ===
Possiamo aggiungere altri due filtri collaborativi contro lo spam seguendo queste due guide:
<br/>
* [[Pyzor]]
* [[Razor]]
 
== Il mio server è stato blacklistato! ==
Ci siamo prodigati per proteggere il nostro mailserver, ma è accaduto lo stesso: il nostro indirizzo IP è stato inserito in una o più blacklist.
<br/>
Che cosa possiamo fare?
# Verificare in quali blacklist siamo stati inseriti; possiamo utilizzare alcuni tool online che in pochi attimi ci daranno il responso:
* [http://mxtoolbox.com/blacklists.aspx MxToolbox]
* [http://whatismyipaddress.com/blacklist-check What Is my IP address]
# Scrivere ai gestori della blacklist chiedendo la rimozione del nostro IP: non funzionerà, ma almeno potremo dire di averci provato!
# Verificare come è successo, analizzando tutta la configurazione e scandagliando i log
# Avvertire i clienti dell'inconveniente, invitandoli a controllare a loro volta le loro configurazioni e le loro postazioni
# In attesa che il nostro IP venga sbloccato, se possediamo più indirizzi IP possiamo configurare un secondo IP virtuale sulla nostra scheda di rete e inoltrare tutto il traffico di posta verso questo nuovo indirizzo, con il comando:
<pre>
# iptables -t nat -A POSTROUTING -p tcp --dport 25 -j SNAT --to-source NUOVO.INDIRIZZO.IP.ALIAS
</pre>
{{Warningbox|Se non abbiamo risolto il problema alla radice, in breve tempo anche il nuovo indirizzo IP finirà blacklistato}}
<br/>
Se abbiamo localizzato il dominio che sta inviando spam dal nostro mailserver, possiamo temporaneamente disabilitarlo dall'invio di nuove mail, dopo averlo comunicato agli intestatari.
<br/>
Per farlo dobbiamo modificare il file di configurazione di Postfix:
<pre>
# nano /etc/postfix/main.cf
</pre>
aggiungendo la sezione:
<pre>
smtpd_sender_restrictions =
      check_sender_access hash:/etc/postfix/sender_access
</pre>
Quindi creiamo il file:
<pre>
# nano /etc/postfix/sender_access
</pre>
di contenuto simile a questo:
<pre>
janedoe@acme.local REJECT
acme.com REJECT
bugsbunny@acme.com OK
</pre>
Infine informiamo Postfix:
<pre>
# postmap /etc/postfix/sender_access
</pre>
e riavviamo il demone:
<pre>
# /etc/init.d/postfix restart
</pre>
 
== Troubleshooting ==
Se abbiamo problemi nell'inviare o ricevere mail possiamo:
* controllare il file di log <code>/var/log/mail.log</code>; quasi tutti i problemi sono elencati in questo file, con messaggi di errore più o meno chiari
* eseguire il comando <code>postfix check</code>: se l'output è vuoto significa che Postfix è configurato bene
* verificare la coda delle mail con il comando <code>postqueue -p -v</code>
* impostare l'immediata spedizione di tutte le mail in coda: <code>mailq -q</code>
* verificare il funzionamento di Amavis:
<pre>
# /etc/init.d/amavisd-new stop
# /etc/init.d/amavisd-new debug
# /etc/init.d/amavisd-new debug
</pre>
</pre>


=== Credits ===
== Statistiche e report ==
Questa guida è basata sull'originale di Christoph Haas pubblicata sul sito [http://http://workaround.org/ Workaround.org].
Il pacchetto <code>pflogsumm</code> (Postfix Log Summary) è comodo per avere un sommario di ciò che succede sul nostro mailserver:
<pre>
# apt-get install pflogsumm
</pre>
Per utilizzarlo basta indicargli il percorso del file di log di Postfix:
<pre>
# pflogsumm /var/log/mail.log
 
messages
 
    129  received
    331  delivered
      1  forwarded
      8  deferred  (59  deferrals)
      3  bounced
    586  rejected (63%)
      0  reject warnings
      0  held
      0  discarded (0%)
 
  3108k  bytes received
  3967k  bytes delivered
    36  senders
    28  sending hosts/domains
    229  recipients
    147  recipient hosts/domains
</pre>
 
== Gestire una Mailing List ==
Nel caso volessimo installare anche un servizio per la gestione di mailing list, possiamo appoggiarci a <code>Mailman</code>, probabilmente il più diffuso mailing list manager open-source.
<br/>
Configureremo un virtual host con hostname <code>lists.example.com</code> in cui installeremo Mailman. <code>lists.example.com</code> sarà anche la parte destra dell'indirizzo delle mailing list che creeremo in Mailman, quindi ogni mailing list avrà un indirizzo del tipo <code><nome_lista>@lists.example.com</code>.
 
=== Installazione di Mailman ===
Mailman si appoggerà a Apache per il suo frontend.
<br>
Installiamo il software:
<pre>
# apt-get install mailman
</pre>
Durante l'installazione ci verranno poste le seguenti domande:
<pre>
Languages to support: <-- it (Italian)
</pre>
<pre>
Missing site list
Mailman needs a so-called "site list", which is the list from which password reminders and such are sent out from.
This list needs to be created before mailman will start.
To create the list, run "newlist mailman" and follow the instructions on-screen.
Note that you also need to start mailman after that, using /etc/init.d/mailman start. <-- Ok
</pre>
 
=== Configurazione di Mailman ===
Mailman ha già un suo file di configurazione per Apache quasi pronto. Dobbiamo solo copiarlo nella directory corretta:
<pre>
# cp /etc/mailman/apache.conf /etc/apache2/sites-available/mailman.conf
</pre>
e modificare alcune cose:
<pre>
# nano /etc/apache2/sites-available/mailman.conf
</pre>
Alla fine del file, dopo la sezione commentata del virtual host già presente (da lasciare commentata!), aggiungiamo la configurazione del nostro virtual host:
<pre>
[...]
<VirtualHost *:80>
ServerName lists.example.com
DocumentRoot /var/www/lists
ErrorLog /var/log/apache2/lists-error.log
CustomLog /var/log/apache2/lists-access.log combined
 
<Directory /var/lib/mailman/archives/>
    Options FollowSymLinks
    AllowOverride None
</Directory>
 
Alias /pipermail/ /var/lib/mailman/archives/public/
Alias /images/mailman/ /usr/share/images/mailman/
ScriptAlias /admin /usr/lib/cgi-bin/mailman/admin
ScriptAlias /admindb /usr/lib/cgi-bin/mailman/admindb
ScriptAlias /confirm /usr/lib/cgi-bin/mailman/confirm
ScriptAlias /create /usr/lib/cgi-bin/mailman/create
ScriptAlias /edithtml /usr/lib/cgi-bin/mailman/edithtml
ScriptAlias /listinfo /usr/lib/cgi-bin/mailman/listinfo
ScriptAlias /options /usr/lib/cgi-bin/mailman/options
ScriptAlias /private /usr/lib/cgi-bin/mailman/private
ScriptAlias /rmlist /usr/lib/cgi-bin/mailman/rmlist
ScriptAlias /roster /usr/lib/cgi-bin/mailman/roster
ScriptAlias /subscribe /usr/lib/cgi-bin/mailman/subscribe
ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo
</VirtualHost>
</pre>
L'ultima direttiva <code>ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo</code> è opzionale; ha senso se non abbiamo nessun file index nella root del virtual host e vogliamo che digitando <code>http://lists.example.com/</code> si venga diretti automaticamente verso <code>http://lists.example.com/listinfo</code>.
<br/>
Quindi creiamo la document root <code>/var/www/lists</code>, abilitiamo il nuovo Virtual Host e riavviamo Apache:
<pre>
# mkdir /var/www/lists
# a2ensite mailman.conf
# /etc/init.d/apache2 restart
</pre>
Dato che stiamo usando un Virtual Host, dobbiamo sistemare alcune variabili nella configurazione di Mailman in <code>/etc/mailman/mm_cfg.py</code>:
<pre>
# nano /etc/mailman/mm_cfg.py
</pre>
<pre>
[...]
DEFAULT_URL_PATTERN = 'http://%s/'
[...]
DEFAULT_EMAIL_HOST = 'lists.example.com'
[...]
DEFAULT_URL_HOST = 'lists.example.com'
[...]
</pre>
 
=== Configurazione di Postfix ===
Ora dobbiamo configurare Postfix. Impostiamo alcune direttive per Mailman:
<pre>
# postconf -e 'relay_domains = lists.example.com'
# postconf -e 'mailman_destination_recipient_limit = 1'
</pre>
Quindi apriamo il file:
<pre>
# nano /etc/postfix/master.cf
</pre>
e controlliamo che siano presenti le seguenti linee (di default dovrebbero esserci):
<pre>
[...]
mailman  unix  -      n      n      -      -      pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}
[...]
</pre>
Ora dobbiamo associare il dominio <code>lists.example.com</code> al corretto ''transport'' <code>mailman:</code>. Questa operazione è possibile in diversi modi: nel nostro setup non abbiamo configurato i transport di Postfix all'interno del database MySQL degli utenti virtuali, quindi procederemo con la configurazione attraverso un file di testo.
<br/>
Iniziamo con introdurre la direttiva seguente nella configurazione di Postfix:
<pre>
# postconf -e 'transport_maps = hash:/etc/postfix/transport'
</pre>
Quindi creiamo il file
<pre>
# nano /etc/postfix/transport
</pre>
e diamogli il contenuto:
<pre>
lists.example.com      mailman:
</pre>
Creiamo l'hash del file:
<pre>
# postmap -v /etc/postfix/transport
</pre>
e riavviamo Postfix:
<pre>
# /etc/init.d/postfix restart
</pre>
 
=== Creazione della prima lista ===
Prima di avviare Mailman, è necessario creare una lista chiamata <code>mailman</code>; è obbligatoria, senza di questa Mailman non partirà:
<pre>
# newlist --urlhost=lists.example.com --emailhost=lists.example.com mailman
</pre>
Solitamente gli switch <code>--urlhost</code> e <code>--emailhost</code> non sono necessari, dal momento che abbiamo già configurato il file <code>/etc/mailman/mm_cfg.py</code>, ma per sicurezza sono solito indicarli esplicitamente.
<br/>
Dovremo rispondere ad alcune domande:
<pre>
Enter the email of the person running the list: <-- Indicare l'amministratore della lista, ad esempio amministratore@example.com
Initial mailman password: <-- La password per amministrare la lista
</pre>
Prima di poter utilizzare la lista dovremo modificare il file <code>/etc/aliases</code> come indicato da Mailman, cioè aggiungendo le seguenti linee:
<pre>
## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:        "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"
</pre>
Infine premiamo Enter e chiudiamo la procedura di creazione della lista:
<pre>
Hit enter to notify mailman owner... <-- ENTER
</pre>
Apriamo quindi <code>/etc/aliases</code> e modifichiamolo come suggerito:
<pre>
# nano /etc/aliases
</pre>
<pre>
[...]
## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:        "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"
</pre>
Quindi aggiorniamo la configurazione degli alias e riavviamo Postfix:
<pre>
# newaliases
# /etc/init.d/postfix restart
</pre>
Ora siamo pronti per avviare Mailman:
<pre>
# /etc/init.d/mailman start
</pre>
 
=== Amministrazione di Mailman ===
Da questo momento possiamo amministrare le liste attraverso l'interfaccia web di Mailman, raggiungibile all'indirizzo:
<pre>
http://lists.example.com/admin
</pre>
 
=== Creazione di nuove liste ===
Possiamo creare nuove mailing list con questa procedura:
<pre>
# newlist --urlhost=lists.example.com --emailhost=lists.example.com testlist2
</pre>
<pre>
Enter the email of the person running the list: <-- amministratore2@example.com
Initial testlist2 password: <-- Password dell'amministratore
To finish creating your mailing list, you must edit your /etc/aliases (or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:
 
## testlist2 mailing list
testlist2:              "|/var/lib/mailman/mail/mailman post testlist2"
testlist2-admin:        "|/var/lib/mailman/mail/mailman admin testlist2"
testlist2-bounces:      "|/var/lib/mailman/mail/mailman bounces testlist2"
testlist2-confirm:      "|/var/lib/mailman/mail/mailman confirm testlist2"
testlist2-join:        "|/var/lib/mailman/mail/mailman join testlist2"
testlist2-leave:        "|/var/lib/mailman/mail/mailman leave testlist2"
testlist2-owner:        "|/var/lib/mailman/mail/mailman owner testlist2"
testlist2-request:      "|/var/lib/mailman/mail/mailman request testlist2"
testlist2-subscribe:    "|/var/lib/mailman/mail/mailman subscribe testlist2"
testlist2-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe testlist2"
 
Hit enter to notify testlist2 owner... <-- ENTER
</pre>
Quindi modifichiamo:
<pre>
# nano /etc/aliases
</pre>
aggiungendo
<pre>
[...]
## testlist2 mailing list
testlist2:              "|/var/lib/mailman/mail/mailman post testlist2"
testlist2-admin:        "|/var/lib/mailman/mail/mailman admin testlist2"
testlist2-bounces:      "|/var/lib/mailman/mail/mailman bounces testlist2"
testlist2-confirm:      "|/var/lib/mailman/mail/mailman confirm testlist2"
testlist2-join:        "|/var/lib/mailman/mail/mailman join testlist2"
testlist2-leave:        "|/var/lib/mailman/mail/mailman leave testlist2"
testlist2-owner:        "|/var/lib/mailman/mail/mailman owner testlist2"
testlist2-request:      "|/var/lib/mailman/mail/mailman request testlist2"
testlist2-subscribe:    "|/var/lib/mailman/mail/mailman subscribe testlist2"
testlist2-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe testlist2"
</pre>
Infine:
<pre>
# newaliases
# /etc/init.d/postfix restart
</pre>
 
== Credits ==
Questa guida è basata sull'originale di Christoph Haas pubblicata sul sito [http://workaround.org/ Workaround.org].
<br/>
<br/>
<br/>
<br/>
Riga 1 873: Riga 2 660:
{{Autori
{{Autori
|Autore = [[Utente:Ferdybassi|Ferdybassi]] 22:22, 2 apr 2011 (CEST)
|Autore = [[Utente:Ferdybassi|Ferdybassi]] 22:22, 2 apr 2011 (CEST)
|Verificata_da =
: risca 10:52, 6 apr 2014 (CEST)
|Numero_revisori = 1
}}
}}


Versione attuale delle 08:38, 31 mar 2016

Edit-clear-history.png 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.


Debian-swirl.png Versioni Compatibili

Debian 5 "lenny"
Debian 6 "squeeze"
Debian 7 "wheezy"
Warning.png ATTENZIONE
La guida NON è compatibile con Jessie. E' in fase di realizzazione una nuova guida.



Introduzione

In questa guida cercheremo di raccogliere tutte le informazioni per arrivare a un'installazione di Debian che fornisca i seguenti servizi, comuni presso qualsiasi Internet Service Provider:

  • hosting di più domini web sullo stesso server
  • spazio web e database MySQL separato per ogni dominio
  • accesso via FTP alle directory root di ogni dominio in maniera separata
  • fornitura di indirizzi mail personalizzati "@nomedominio.tld"
  • fornitura di un sistema di webmail

Nota: questa guida non è adatta per chi ha necessità di installare un solo dominio e un solo servizio di posta sul suo server, ma è pensata per chi ha necessità di agire come un Virtual Internet Service Provider, con fornitura di servizi a terzi.

Prerequisiti

Warning.png ATTENZIONE
Non proseguite senza aver completato l'installazione e la configurazione di tutti i prerequisiti richiesti


Si consideri di partire con un'installazione minimale di Debian effettuata da CD netinstall. Il server dovrà possedere un indirizzo IP pubblico e un FQDN (vedi Wikipedia).
Si configuri il file /etc/apt/sources.list in modo che contenga solo i repository ufficiali (vedi guide sul wiki) e si aggiorni il server con le ultime patch: 

# apt-get update
# apt-get upgrade

Può essere utile impostare anche un server NTP esterno per sincronizzare l'ora del nostro server con un'autorità nazionale: Impostare e modificare data e ora.
Poichè il server andrà quasi sicuramente gestito da remoto occorrerà installare e configurare anche l'accesso SSH ( guida su SSH) con autenticazione via chiave.

Installazione ambiente LAMP

Un ambiente LAMP è un acronimo per indicare un ambiente composto da Linux + Apache + MySQL + PHP. Per l'installazione e la configurazione di un ambiente LAMP si segua la guida omonima presente sul wiki: Installare un ambiente LAMP: Linux, Apache2, SSL, MySQL, PHP5.
Nota: il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.

Installazione Virtual Host di Apache

Arrivati a questo punto ci troviamo con un server web perfettamente funzionante, ma che ancora non sa come gestire i diversi domini che andranno ospitati sul server.
Per configurare Apache con il supporto ai Virtual Hosts si segua la guida sul wiki: Apache e Virtual Hosts: configurare Apache2 per ospitare più siti web.
Nota: il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.

Protezione del web server Apache

Poichè il nostro server sarà esposto al web 24 ore al giorno dovremo premunirci installando alcune protezioni. Un buono spunto per incominciare può essere la guida: Hardening di un web server Apache.
Potrebbe essere una buona idea implementare anche alcuni sistemi di monitoraggio, ad esempio quelli trattati nelle guide seguenti:
Fail2ban
Impedire attacchi SSH brute-force con Denyhosts

Configurazione dei record DNS

Per fare in modo che i PC connessi a internet possano sapere che tutti i siti configurati sono ospitati su un server che risponde a un solo indirizzo IP pubblico (che supponiamo sia 1.2.3.4) è necessario configurare i record DNS di ogni dominio in questo modo: 

www => 1.2.3.4 A
ftp => 1.2.3.4 A
@   => 1.2.3.4 A
mail => 1.2.3.4 MXE

Con questa configurazione attiveremo quindi tre sottodomini, uno per il web (www), uno per l'FTP (ftp) e uno per il mailserver del dominio (mail).

Installazione FTP server

L'installazione di un server FTP con utenti virtuali permetterà ad ogni proprietario di un dominio ospitato sul nostro server di accedere via FTP allo spazio web a sua disposizione, senza poter navigare all'interno del filesystem del server e all'interno degli spazi web riservati agli altri domini. Per l'installazione di un server FTP con utenti virtuali si segua la guida: Installare un server FTP con utenti virtuali su MySQL oppure Installare un server vsFTPd con utenti virtuali su MySQL.

Installazione del server di posta

Schema di funzionamento

I software utilizzati per configurare il server di posta saranno i seguenti:

  • Postfix per inviare e ricevere mail da internet e effettuare i primi controlli basilari
  • Dovecot per archiviare le mail sul server e fornire agli utenti accesso alle loro caselle tramite POP3 e IMAP
  • Roundcube come interfaccia Webmail
  • MySQL come database backend per archiviare informazioni su domini, account utente e email forwarding
  • AMaViS per effetuare la scansione delle mail in arrivo utilizzando ClamAV e SpamAssassin
  • Clam Antivirus come controllo antivirus
  • SpamAssassin come filtro antispam

Una volta a regime, il server di posta sarà configurato in questa maniera:

  • una email viene spedita attraverso il nostro SMTP sulla porta 25. Postfix accetta la connessione e effettua alcuni controlli:
    • il mittente è in blacklist o in whitelist?
    • la mail proviene da un utente autenticato sul server e può superare i controlli di relay?
    • il destinatario è un utente valido del sistema?
  • Postfix inoltra la mail sul protocollo TCP alla porta 10024, dove AMaViS effettua il controllo del contenuto. AMaViS è configurato per aggiungere alcuni header alla mail, in modo che gli utenti possano filtrarla o meno come spam.
  • La mail viene poi girata a SpamAssassin per un controllo antispam più accurato
  • Poi interviene ClamAV, che ne controlla il contenuto alla ricerca di virus
  • Dopo questi controlli AMaViS restituisce la mail a Postfix sulla porta TCP 10025
  • Postfix è configurato per non controllare il traffico in arrivo su questa porta e gira la mail a Dovecot senza ulteriori controlli
  • Dovecot salva la mail sul server in formato Maildir
  • L'utente può ora leggere la sua email attraverso i protocolli POP3 o IMAP

Domini locali e virtuali

Normalmente Postfix lavora con i cosiddetti Domini Locali, configurati nella direttiva mydestination del suo file di configurazione, e con gli utenti di sistema, elencati nel file /etc/passwd.
Questo comporta che ogni utente possa ricevere la posta di tutti i domini. Supponiamo di avere la direttiva: 

mydestination = example1.com, example2.com, example3.com

Questo semplice setup fa sì che l'utente di sistema johndoe riceva le email indirizzate a: 

johndoe@example1.com
johndoe@example2.com
johndoe@example3.com

Non è possibile impedire la ricezione della posta indirizzata a un singolo dominio e questo, unitamente al fatto che gestire molti utenti in questa maniera è inefficiente, rende il sistema poco pratico.

Questi problemi possono essere evitati facendo uso dei cosiddetti Domini Virtuali, che a loro volta gestiranno utenti virtuali e alias virtuali di posta. Nel corso della guida vedremo come questa tecnica sarà implementata attraverso alcune direttive Postfix e con il supporto di un database MySQL.

Preparazione del sistema

Controlliamo che il nostro /etc/hosts sia impostato correttamente:

  • Sbagliato:
20.30.40.50   mailserver42 mailserver42.example.com
  • Corretto:
20.30.40.50   mailserver42.example.com mailserver42

Installazione dei pacchetti necessari

Incominciamo con l'installare il server Postfix con la sua estensione per il supporto a MySQL: 

# aptitude install postfix postfix-mysql

Questo comando installerà automaticamente anche il pacchetto postfix e rimuoverà Exim, il mail server installato di default da Debian.
Quando richiesti dall'installer di Postfix, scegliete "Sito internet" come tipo di configurazione e inserite il FQDN (Fully Qualified Domain Name) del vostro server.
Rimuoviamo poi i resti di Exim eventualmente rimasti nel sistema: 

# apt-get --purge remove 'exim4*'

Poichè intendiamo offrire ai nostri utenti anche i servizi POP3 e IMAP dobbiamo installare il demone Dovecot: 

# apt-get install dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-managesieved

Alcuni pacchetti utilizzati in questa guida per la scansione degli allegati di posta elettronica non sono inclusi nella sezione main dei repository di Debian (ad esempio unrar e lha); per poterli installare dobbiamo prima modificare il nostro /etc/apt/sources.list aggiungendo la sezione non-free: 

deb http://ftp.debian.org/debian/ wheezy main contrib non-free

Aggiorniamo la lista dei pacchetti disponibili: 

# aptitude update

e installiamo i pacchetti necessari al filtraggio dello spam e alla scansione delle email: 

# aptitude install amavisd-new spamassassin clamav-daemon lha arj unrar zoo nomarch cpio lzop cabextract

AMaViS è ora installato nel nostro sistema, insieme a una serie di pacchetti per la scansione delle email.
Dato che vogliamo offrire anche un servizio di Webmail, installeremo anche il pacchetto Roundcube: 

# apt-get install roundcube roundcube-plugins

Rispondete così alle domande che vi vengono poste dall'installer:

  • Configurare Roundcube con dbconfig-common: sì
  • Database: MySQL
  • Database's administrative user's password: la password di root di MySQL
  • Password di database per Roundcube: inventare una password forte


Infine installiamo il client mail Pop3 / Imap mutt, che funziona da console e che può essere utile per testare la nostra configurazione strada facendo 

# aptitude install mutt

e un tool preziosissimo, SWAKS (SWiss Army Knife for Smtp): 

# apt-get install swaks



Warning.png ATTENZIONE
DEPRECATO: al posto di Squirrelmail è possibile installare una diversa interfaccia webmail, Roundcube: 


# aptitude install squirrelmail

L'installazione di Squirrelmail su Debian Squeeze incontra un problema: 

# aptitude install squirrelmail

The following packages have unmet dependencies:
  apache2-mpm-prefork: Conflicts: apache2-mpm which is a virtual package.
  apache2-mpm-worker: Conflicts: apache2-mpm which is a virtual package.
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     apache2-mpm-worker [Not Installed]                 

Accept this solution? [Y/n/q/?]

ma la soluzione proposta da aptitude è corretta; rispondiamo quindi con Y alla domanda.

Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.

Creazione del certificato SSL

Creiamo il certificato da utilizzare per i servizi SSL: 

# openssl req -new -x509 -days 3650 -nodes -newkey rsa:4096 -out /etc/ssl/certs/mailserver.pem -keyout /etc/ssl/private/mailserver.pem

e proteggiamolo: 

# chmod 600 /etc/ssl/private/mailserver.pem

Preparazione del database

Creazione del database

Come prima cosa creeremo un nuovo database MySQL, che chiameremo mailserver: 

# mysqladmin -p create mailserver

Ci verrà chiesta la passord dell'utente root di MySQL e poi sarà creato il nuovo database.

Aggiunta di un utente MySQL con privilegi limitati

Per ragioni di sicurezza creiamo un nuovo utente mySQL con privilegi limitati verso il database mailserver: 

# mysql -p

Vedremo il prompt trasformarsi in mysql>, la shell di MySQL, e saremo pronti per creare l'utente mailuser con password mailuser2009: 

mysql> GRANT SELECT ON mailserver.*
       TO 'mailuser'@'127.0.0.1'
       IDENTIFIED BY 'mailuser2009';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye

Creazione delle tabelle del database

A questo punto dobbiamo creare all'interno del database le tabelle per archiviare le informazioni sui domini, sugli alias, i forwarding e le mailbox degli utenti.
Connettiamoci di nuovo a MySQL e scegliamo il database mailserver e creiamo la prima tabella, per registrare i domini virtuali: 

# mysql -p mailserver

mysql>
CREATE TABLE `virtual_domains` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

La tabella successiva conterrà le informazioni sugli utenti virtuali di Postfix; sarà utilizzata per autenticare le richieste POP3, SMTP, IMAP e Webmail. L'indirizzo email dell'utente sarà utilizzato anche come username per il login: 

mysql>
CREATE TABLE `virtual_users` (
  `id` int(11) NOT NULL auto_increment,
  `domain_id` int(11) NOT NULL,
  `password` varchar(32) NOT NULL,
  `email` varchar(100) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `email` (`email`),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Il campo email conterrà l'indirizzo mail/username; il campo password conterrà un hash MD5 della password degli utenti. L'attributo unique key sul campo email ci eviterà di creare per errore due indirizzi email identici.
Come ultima cosa creiamo una tabella per gli alias, necessaria per forwardare le email da un indirizzo a un altro: 

mysql>
CREATE TABLE IF NOT EXISTS `virtual_aliases` (
  `id` int(11) NOT NULL auto_increment,
  `domain_id` int(11) NOT NULL,
  `source` varchar(100) NOT NULL,
  `destination` varchar(100) NOT NULL,
  PRIMARY KEY  (`id`),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Sono state impostate alcune foreign keys: servono per collegare i record delle tabelle virtual_aliases e virtual_users con i record nella tabella virtual_domains. Questo ci permetterà di mantenere consistenti i dati nel database, perchè non potremo creare utenti virtuali o alias virtuali non collegati ad alcun dominio virtuale.
Il suffisso ON DELETE CASCADE significa che rimuovendo un dominio virtuale saranno cancellate anche tutti gli utenti virtuali e gli alias collegati al dominio, evitando di lasciare nel database dei record orfani.

Esempio di contenuto delle tabelle

-----------------
virtual_domains
-----------------
id 	|	name
1	|	example.com
2	|	foobar.org


---------------------------------
virtual_users
---------------------------------
id	|	domain_id	|	email			|	password
1	|	1		|	john@example.com	|	14cbfb845af1f030e372b1cb9275e6dd
2	|	1		|	steve@example.com	|	a57d8c77e922bf756ed80141fc77a658
3	|	2		|	kerstin@foobar.org	|	5d6423c4ccddcbbdf0fcfaf9234a72d0


-----------------------------------
virtual_aliases
-----------------------------------
id	|	domain_id	|	source			|	destination
1	|	1		|	steve@example.com	|	devnull@workaround.org
2	|	2		|	kerstin@foobar.org	|	kerstin42@yahoo.com
3	|	2		|	kerstin@foobar.org	|	kerstin@mycompany.com

Mappatura di Postfix verso MySQL

Il database è ora pronto per essere riempito con informazioni sugli account utente, ma dobbiamo ancora istruire Postfix affinché possa recuperare le informazioni archiviate nel database.
Verifichiamo innanzitutto che la direttiva mydestination nel file di configurazione di Postfix non contenga riferimenti ai domini che creeremo all'interno del database: 

# nano /etc/postfix/main.cf

La riga deve apparire come segue: 

mydestination = mailserver.example.com, localhost, localhost.example.com

ma non deve contenere l'indicazione del dominio: 

mydestination = example.com

altrimenti Postfix cercherà di smistare la posta del dominio senza passare dalla mappatura su Postfix.

virtual_mailbox_domains

Incominciamo con il dire a Postfix quali domini virtuali stiamo gestendo. Per fare in modo che Postfix utilizzi MySQL per definire una mappatura abbiamo bisogno di un file di configurazione, quindi per prima cosa ne creeremo uno: 

# nano /etc/postfix/mysql-virtual-mailbox-domains.cf

con contenuto pari al seguente: 

user = mailuser
password = mailuser2009
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s'
Info.png NOTA
Potrebbe venirvi la tentazione di scrivere "localhost" al posto di "127.0.0.1" nel file precedente. Non va fatto!! "localhost" farà sì che Postfix cerchi il file socket MySQL, non trovandolo perchè gira in una chroot jail. Al contrario "127.0.0.1" utilizzerà una connessione TCP sulla porta 3306, che risponderà anche se Postfix funziona all'interno di una gabbia chroot


Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura: 

# postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Il comando postconf -e aggiunge la riga specificata al file di configurazione di Postfix /etc/postfix/main.cf e attiva istantaneamente la nuova impostazione, senza richiedere il riavvio di Postfix.
Da adesso Postfix cercherà le informazioni sui domini virtuali all'interno del database.
Verifichiamo che tutto funzioni, creando il nostro primo dominio virtuale: 

# mysql -p mailserver
mysql> INSERT INTO virtual_domains (id, name) VALUES (1, 'example.com');
exit

e interrogando Postfix: 

# postmap -q example.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Dovremmo ottenere come risultato 1.

Note

  • Se otteniamo l'errore postmap: warning: connect to mysql server 127.0.0.1: Access denied... significa che abbiamo dei problemi con l'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'

Assicuriamoci che Postfix utilizzi questa mappatura: 

# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf

e verifichiamo che tutto funzioni correttamente: 

# postmap -q john@example.com mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Dovremmo ottenere i due indirizzi di forward john@example.com,devnull@workaround.org

email-to-email mapping

Prima di configurare Postfix per la mappatura virtual_alias_maps c'è ancora una cosa di cui dobbiamo preoccuparci. C'è uno particolare tipo di email forward chiamato catchall alias. Il catchall alias cattura tutte le email di un dominio per le quali non è definito un account.
Creiamo l'ultimo file di mappatura necessario: 

# nano /etc/postfix/mysql-email2email.cf

e diamogli come contenuto: 

user = mailuser
password = mailuser2009
hosts = 127.0.0.1
dbname = mailserver
query = SELECT email FROM virtual_users WHERE email='%s'

Verifichiamo che gli utenti con un account valido non vedano le loro email trattate come catchall alias: 

# postmap -q john@example.com mysql:/etc/postfix/mysql-email2email.cf

Il risultato dovrebbe essere lo stesso indirizzo email: john@example.com
A questo punto possiamo istruire Postfix a utilizzare le ultime mappature definite: 

# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf

Perfetto!
Tutte le mappature sono state definite e il database è pronto per essere riempito con domini e utenti.

Proibire l'invio di email con mittenti arbitrari

Nella configurazione impostata fino ad adesso ogni utente autenticato sul server SMTP può spedire email da qualsiasi indirizzo. Pur essendo una configurazione perfettamente funzionante, le impostazioni necessitano a mio avviso di qualche miglioramento.
Iniziamo con l'aggiungere le seguenti linee al file: 

# nano /etc/postfix/main.cf

smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cf
smtpd_sender_restrictions = reject_unknown_sender_domain,reject_non_fqdn_sender,reject_sender_login_mismatch

Quindi creiamo un nuovo file: 

# nano /etc/postfix/mysql-sender-login-maps.cf

con contenuto: 

user = mailuser
password = mailuser2009
hosts = 127.0.0.1
dbname = mailserver
query = ( SELECT GROUP_CONCAT( a.`destination` ) FROM `virtual_aliases` a, `virtual_domains` d WHERE a.`source`='%s' AND a.`domain_id`=d.`id` AND d.`name`='%d' ) UNION ( SELECT `email` FROM `virtual_users` WHERE `email`='%s' )

A questo punto possiamo testare la configurazione aggiunta: 

# postmap -q email@domian.tld mysql:/etc/postfix/mysql-sender-login-maps.cf

Dovremmo ottenere come risultato il nostro indirizzo email o i nostri alias, a seconda di come abbiamo configurato l'utente.
Da questo momento in poi ogni utente potrà inviare email utilzzando il proprio indirizzo email o uno dei propri alias come mittente e non potrà più inviare email con mittenti arbitrari.

Protezione dei file di configurazione

Poichè la password di connessione al database è archiviata nei file di configurazione appena creati, facciamo in modo che solo l'utente root possa leggerli: 

# chgrp postfix /etc/postfix/mysql-*.cf
# chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf

Configurazione di Postfix per Dovecot

Nel capitolo precedente abbiamo fatto in modo che Postfix venisse a conoscenza di quali mail è autorizzato a ricevere.
Ma come vanno trattate queste mail? Il nostro obiettivo è archiviare le mail sull'hard disk del server; normalmente questo compito è svolto dallo stesso Postfix, che al suo interno ha un piccolo mail delivery agent (MDA) chiamato virtual. Poichè però abbiamo deciso di utilizzare Dovecot per fornire accesso POP3 e IMAP agli utenti, utilizzeremo anche il suo local delivery agent (chiamato Dovecot LDA), che è a mio avviso più ricco e funzionale di virtual.
Per fare in modo che Postfix utilizzi questo agent dobbiamo aggiungere un servizio in coda al file /etc/postfix/master.cf: 

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient}

Nota: la seconda riga deve essere indentata con degli spazi e non con il TAB.
A questo punto non resta che riavviare Postfix: 

# service postfix restart

e fare in modo che utilizzi il servizio appena creato per lo smistamento delle email, modificando il file /etc/postfix/main.cf nella maniera vista in precedenza: 

# postconf -e virtual_transport=dovecot
# postconf -e dovecot_destination_recipient_limit=1

Da adesso in poi Postfix smisterà le email in arrivo al programma di Dovecot /usr/lib/dovecot/deliver.

Configurazione di Dovecot

E' ora di configurare Dovecot, che svolgerà i seguenti compiti:

  • ricevere le email da Postfix e salvarle su disco
  • controllare le quote disco
  • eseguire regole e filtri user-based
  • mettere a disposizione i protocolli POP3 e IMAP per gli utenti

Prima di iniziare, però, è bene concedere un occhio alla sicurezza creando un nuovo utente di sistema a cui attribuiremo la proprietà di tutte le mailboxes. Con il comando seguente creeremo l'utente vmail con UID 5000 e il gruppo vmail con GID 5000. Ovviamente è bene controllare che i valori UID e GID non siano già in uso nel sistema; altrimenti sarà possibile utilizzare un qualsiasi valore non in uso compreso tra 1000 e 65000: 

# groupadd -g 5000 vmail
# useradd -g vmail -u 5000 vmail -d /var/vmail -m

Assicuriamoci che la directory abbia i giusti permessi: 

# chown -R vmail:vmail /var/vmail
# chmod u+w /var/vmail

Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in /etc/dovecot.
Fino a Debian Squeeze la configurazione di Dovecot era tutta contenuta in due file; da Debian Wheezy la configurazione è stata spezzata in una trentina di file, contenuti tutti nella directory /etc/dovecot/conf.d. Il file di configurazione principale /etc/dovecot/dovecot.conf non richiede alcuna modifica e attraverso la direttiva 

!include conf.d/*.conf

carica tutti i file presenti in /etc/dovecot/conf.d/ che terminano in ".conf" in sequenza. Quindi "10-auth.conf" sarà caricato per primo e "90-quota.conf" per ultimo. Il grosso vantaggio di questa situazione è che potremo modificare o rimpiazzare parti della configurazione senza sovrascriverla interamente; lo svantaggio è che la migrazione da una versione precedente di Dovecot può diventare un'operazione difficoltosa.

Fino a Debian Squeeze

Inziamo con il file principale.

/etc/dovecot/dovecot.conf

Cerchiamo la linea protocols e definiamo i protocolli che vogliamo offrire agli utenti. Di default troveremo: 

protocols = imap imaps pop3 pop3s

Dovecot avvierà quindi i servizi POP3 e IMAP e i loro equivalenti su una connessione crittata SSL.
Sebbene sia un'impostazione meno sicura, probabilmente avremo bisogno di impostare la direttiva: 

disable_plaintext_auth = no

Questa impostazione permetterà le password in plaintext su connessioni non sicure (non SSL). Di default la direttiva è impostata su yes per motivi di sicurezza; impostarla a no abbasserà la sicurezza della transazione, ma permetterà il funzionamento anche di alcuni client di una certa Corporation famosa, che non rispettano alcuni standard dei protocolli IMAP e POP3 e che altrimenti avrebbero problemi. Per lamentele rivolgetevi a Microsoft e non floodate il bugzilla di Dovecot.
Un'altra importante direttiva è: 

mail_location = maildir:/var/vmail/%d/%n/Maildir

che imposta il percorso e il formato delle mailboxes degli utenti in una forma standard: 

/var/vmail/DOMAIN/USER/Maildir

Nel file dovrebbe già essere presente una sezione chiamata namespace private, ma dovrebbe risultare commentata con #.
Lasciamola commentata e cerchiamo la sezione chiamata auth default. In primo luogo dobbiamo modificare il meccanismo di autenticazione: 

mechanisms = plain login

Scorrendo la sezione troveremo i diversi backends che Dovecot può utilizzare per accedere ai dati delle mail degli utenti. All'interno di questo elenco dobbiamo configurare il backend SQL: 

passdb sql {
   args = /etc/dovecot/dovecot-sql.conf
}

che dice a Dovecot che le password sono archiviate in un database SQL, e successivamente: 

userdb static {
   args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
}

che indica a Dovecot dove sono situate tutte le mailboxes.
Ricordiamoci anche di commentare l'autenticazione pam, disabilitandola, dato che non utilizzeremo questo tipo di password check: 

# passdb pam {
# Commentare tutte le linee
# }


L'utente viene autenticato attraverso la sezione passdb sql section, dopo di che viene indirizzato alla mailbox secondo le direttive della voce userdb static. Utilizzare la direttiva userdb sql non è necessario dato che tutte le mailboxes hanno un percorso fisso.
Probabilmente vorremo anche commentare la sezione chiamata passdb pam per evitare cheper recapitare le email Dovecot cerchi anche tra i system users.

Ora cerchiamo la sezione chiamata socket listen. Qui è dove vengono definiti i socket file che verranno usati per interagire con il meccanismo di autenticazione di Dovecot. Impostiamola come segue: 

socket listen {
    master {
        path = /var/run/dovecot/auth-master
        mode = 0600
        user = vmail
    }

    client {
        path = /var/spool/postfix/private/auth
        mode = 0660
        user = postfix
        group = postfix
    }
}

La sezione master è necessaria per fornire al Delivery Agent di Dovecot accesso alle informazioni sugli utenti. La sezione client crea un socket all'interno della directory chroot di Postfix: una parte di Postfix gira infatti di default in un ambiente chroot all'interno della directory /var/spool/postfix.

L'ultima sezione da modificare è quella marcata come protocol lda. Il servizio LDA (local delivery agent) di Dovecot è più potente e scalabile di quello built-in di Postfix: permette ad esempio le quote e i filtraggi Sieve. Modifichiamo quindi la sezione come segue: 

protocol lda {
    log_path = /var/log/dovecot-deliver.log
    auth_socket_path = /var/run/dovecot/auth-master
    postmaster_address = postmaster@example.com
    mail_plugins = cmusieve
}

Si noti che in Debian Squeeze il plugin di Sieve ha cambiato nome e la sezione va quindi modificata come segue: 

protocol lda {
    log_path = /var/log/dovecot-deliver.log
    auth_socket_path = /var/run/dovecot/auth-master
    postmaster_address = postmaster@example.com
    mail_plugins = sieve
}

Cambiate ovviamente l'indirizzo email del postmaster. L'impostazione log_path è facoltativa, ma può essere d'aiuto nel debuggare eventuali comportamenti inaspettati di certi filtri server-side. Prepariamo il file di log con i corretti permessi: 

# touch /var/log/dovecot-deliver.log
# chown vmail:adm /var/log/dovecot-deliver.log
# chmod 640 /var/log/dovecot-deliver.log


Poichè il log dovecot-deliver.log può crescere molto velocemente di dimensione potrebbe essere opportuno impostare un file di configurazione per logrotate: 

# nano /etc/logrotate.d/dovecot-deliver

con il seguente contenuto: 

/var/log/dovecot-deliver.log {
        weekly
        rotate 14
        compress
        create 640 vmail adm
}

Modificate inoltre il file /etc/dovecot/dovecot-sql.conf e cambiate le seguenti impostazioni: 

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
Bulb.png Suggerimento
A partire da Debian Squeeze affinché Dovecot resti in ascolto sia su IPv4 sia su IPv6 è necessario aggiungere al file /etc/dovecot/dovecot.conf anche la riga: 
listen = [::] *


Infine riavviamo Dovecot: 

# /etc/init.d/dovecot restart

Nel file di log /var/log/mail.log dovremmo vedere: 

dovecot: Dovecot v1.0.rc15 starting up
dovecot: auth-worker(default): mysql: Connected to 127.0.0.1 (mymailserver)

Prima di mandare la nostra prima email di test occorre ancora correggere i permessi su alcuni file di configurazione, in modo che l'utente vmail, l'utente con cui gira Postfix, possa accedere alla configurazione di Dovecot: 

# chgrp vmail /etc/dovecot/dovecot.conf
# chmod g+r /etc/dovecot/dovecot.conf

Infine facciamo in modo che solo l'utente root abbia i permessi per leggere il file dove abbiamo archiviato la password di connessione al database MySQL: 

# chown root:root /etc/dovecot/dovecot-sql.conf
# chmod go= /etc/dovecot/dovecot-sql.conf

Da Debian Wheezy

Diamo uno sguardo ai file presenti nella directory di configurazione conf.d.

10-auth.conf

Se ci aspettiamo di dover servire client che utilizzano Microsoft Outlook come applicazione per la posta elettronica, dovremo cambiare il meccanismo di autenticazione in: 

auth_mechanisms = plain login

Alla fine del file troveremo elencati i vari backend di autenticazione che Dovecot può utilizzare. Di default utilizza l'autenticazione tramite system users, ma a noi interessa abilitare un database MySQL, quindi modifichiamo la sezione come segue: 

#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext
auth-sql.conf.ext

Modifichiamo ora il file di configurazione SQL.
Commentiamo la sezione standard "userdb" e aggiungiamo: 

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n
}

Attenzione: deve esserci attiva una sola sezione "userdb".
Attenzione: c'è un'altra sezione molto simile, ma utilizza "%u" al posto di "%d/%n". Occorre stare attenti a non confonderle, perchè la differenza di variabili influenza il percorso di memorizzazione delle maildir.

10-mail.conf

Cambiamo la direttiva mail_location in 

mail_location = maildir:/var/vmail/%d/%n/Maildir

Questa sarà la directory dove Dovecot cercherà le email di ogni specifico utente. Ad esempio l'utente john@example.org avrà le sue email archiviate in /var/vmail/example.org/john/Maildir.
Cambiamo la direttiva auth_socket_path in 

auth_socket_path = /var/run/dovecot/auth-master

Cerchiamo la sezione namespace inbox. Se abbiamo già archiviato email sul server e stiamo aggiornando il nostro sistema da Squeeze a Wheezy, allora dobbiamo modificare la direttiva separator in: 

separator = .

per mantenere la retrocompatibilità della configurazione.

10-master.conf

Nella sezione service auth dobbiamo inserire: 

# Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }

Gli altri servizi possono essere lasciati come sono.

10-ssl.conf

In precedenza abbiamo creato un certificato SSL per i servizi Pop3 3 Imaps. Questo è il momento di dire a Dovecot dove si trovano questi certificati, inserendo: 

ssl_cert = </etc/ssl/certs/mailserver.pem
ssl_key = </etc/ssl/private/mailserver.pem
15-lda.conf

In questo file dobbiamo abilitare il plugin sieve, che, in parole povere, è un sistema per gestire le regole email a livello server. Cerchiamo la sezione protocol lda verso la fine del gile e aggiungiamo sieve alla lista dei plugin: 

protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}
/etc/dovecot/dovecot-sql.conf.ext

Questo file è richiamato dal file /etc/dovecot/conf.d/auth-sql.conf.ext e dice a Dovecot come accedere al database MySQL e dove trovare le informazioni sugli account. Accertiamoci che contenga le linee: 

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailuser2009
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

ponendo attenzione a inserire le credenziali MySQL create in precedenza.

Protezione dei file

Impostiamo le giuste credenziali per il file di configurazione principale: 

# chgrp vmail /etc/dovecot/dovecot.conf
# chmod g+r /etc/dovecot/dovecot.conf

per lo spool di Postfix: 

# chown postfix:postfix /var/spool/postfix/private/auth
# chmod 666 /var/spool/postfix/private/auth

e proteggiamo il file di configurazione SQL in modo che nessuno possa scoprire la password del database: 

# chown root:root /etc/dovecot/dovecot-sql.conf.ext
# chmod go= /etc/dovecot/dovecot-sql.conf.ext

Infine riavviamo Dovecot: 

# service dovecot restart

e verifichiamo dai log che non ci siano errori: 

# tail -f /var/log/mail.log
... dovecot: master: Dovecot v2.1.7 starting up (core dumps disabled)

Test della configurazione

Apriamo un altro terminale e controlliamo i log della posta in tempo reale: 

# tail -f /var/log/mail.log

Dal primo terminale aperto proviamo a inviare una semplice prima mail di prova: 

# echo test | mail john@example.org

Nei log dovremmo trovare qualcosa di simile: 

Oct 20 17:42:32 sirius postfix/pickup[22273]: A6F8EB55: uid=0 from=<root>
Oct 20 17:42:32 sirius postfix/cleanup[22582]: A6F8EB55: message-id=<20131020154232.A6F8EB55@sirius.localdomain>
Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: from=<root@sirius.workaround.org>, size=287, nrcpt=1 (queue active)
Oct 20 17:42:32 sirius dovecot: auth-worker(22635): mysql(127.0.0.1): Connected to database mailserver
Oct 20 17:42:32 sirius dovecot: lda(john@example.org): msgid=<20131020154232.A6F8EB55@sirius.localdomain>: saved mail to INBOX
Oct 20 17:42:32 sirius postfix/pipe[22586]: A6F8EB55: to=<john@example.org>, relay=dovecot, delay=0.14, delays=0.04/0/0/0.1, dsn=2.0.0, status=sent (delivered via dovecot service)
Oct 20 17:42:32 sirius postfix/qmgr[22274]: A6F8EB55: removed

All'interno della directory principale di archiviazione, Dovecot dovrebbe aver creato tutta la struttura di directory per il dominio e per l'utente di test: 

# find /var/vmail
/var/vmail/
/var/vmail/example.org
/var/vmail/example.org/john
/var/vmail/example.org/john/Maildir
/var/vmail/example.org/john/Maildir/dovecot.index.log
/var/vmail/example.org/john/Maildir/cur
/var/vmail/example.org/john/Maildir/dovecot-uidvalidity.5263f9e8
/var/vmail/example.org/john/Maildir/new
/var/vmail/example.org/john/Maildir/new/1382283752.M737526P22632.sirius,S=352,W=362
/var/vmail/example.org/john/Maildir/dovecot-uidvalidity
/var/vmail/example.org/john/Maildir/tmp
/var/vmail/example.org/john/Maildir/dovecot-uidlist
/var/vmail/example.org/john/Maildir/dovecot.index.cache

Invio di email tramite telnet

Installiamo innanzitutto il pacchetto telnet: 

# aptitude install telnet

Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server: 

# telnet localhost smtp

Dovremmo ottenere come risposta: 

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)

Ottimo. Postfix è funzionante e possiamo proseguire nella sessione di invio della mail: 

ehlo example.com
250-my-new-mailserver
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:<steve@example.com>
250 2.1.0 Ok
rcpt to:<john@example.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Hi John,
just wanted to drop you a note.
.
250 2.0.0 Ok: queued as A9D64379C4
quit

Un controllo al file di log /var/log/mail.log dovrebbe confermarci che la mail è stata correttamente inviata: 

postfix/smtpd[...]: connect from localhost[127.0.0.1]
postfix/smtpd[...]: 5FF712A6: client=localhost[127.0.0.1]
postfix/cleanup[...]: 5FF712A6: message-id=<...>
postfix/qmgr[...]: 5FF712A6: from=<steve@example.com>, size=364, nrcpt=1 (queue active)
postfix/pipe[...]: 5FF712A6: to=<john@example.com>, relay=dovecot, ..., status=sent (delivered via dovecot service)
postfix/qmgr[...]: 5FF712A6: removed
postfix/smtpd[...]: disconnect from localhost[127.0.0.1]

L'invio della mail si è concluso felicemente. Postfix ha determinato correttamente che il dominio di destinazione è uno dei nostri domini virtuali e ha inoltrato la mail al servizio Dovecot.

Controllo della mailbox dell'utente

E' il momento di verificare la corretta ricezione della mail: 

$ cd /var/vmail/example.com/john/Maildir
$ find
.
./cur
./new
./new/1179521979.V801I2bbf7M15352.mailtest
./tmp
$ mutt -f .
q:Quit  d:Del  u:Undel  s:Save  m:Mail  r:Reply  g:Group  ?:Help
   1 N   May 18 steve@example.c (0.1K)
Press ENTER to read the email:

From: steve@example.com
To: undisclosed-recipients: ;

Hi John,

just wanted to drop you a note.

La mail è arrivata correttamente. Premiamo q due volte per uscire da mutt.

Test del server POP3

Il Post Office Protocol (detto anche POP) è un protocollo che ha il compito di permettere, mediante autenticazione, l'accesso ad un account di posta elettronica presente su di un host per scaricare le e-mail del relativo account. Il pop (nella versione 3) rimane in attesa sulla porta 110 dell'host (di default, ma può anche essere diversa) per una connessione TCP da parte di un client. I messaggi di posta elettronica, per essere letti, devono essere scaricati sul computer, anche se è possibile lasciarne una copia sull'host. Il protocollo POP3 non prevede alcun tipo di cifratura, quindi le password utilizzate per l'autenticazione fra server e client passano in chiaro.
Stabiliamo una connessione POP3 con il nostro server: 

$ telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready.
user john@example.com
+OK
pass summersun
+OK Logged in.
list
+OK 1 messages:
1 474
.
retr 1
+OK 474 octets
Return-Path: <steve@example.com>
X-Original-To: john@example.com
Delivered-To: john@example.com
Received: from example.com (localhost [127.0.0.1])
    by ... (Postfix) with ESMTP id 692DF379C7
    for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
Message-Id: <...>
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
From: steve@example.com
To: undisclosed-recipients:;

Hi John,

just wanted to drop you a note.
.
quit
+OK Logging out.
Connection closed by foreign host.

Effettuata questa prima verifica di funzionamento, sarà possibile utilizzare un qualsiasi email client per le operazioni quotidiane.

Test del server IMAP

L'Internet Message Access Protocol (IMAP), a volte anche chiamato Interactive Mail Access Protocol, è un protocollo di comunicazione per la ricezione di e-mail. Il significato "Interactive Mail Access Protocol" è stato valido fino alla versione 3, dalla quarta in poi è cambiato in "Internet Message Access Protocol". Il protocollo è stato inventato da Mark Crispin nel 1986 come alternativa più moderna all'utilizzatissimo POP. La porta predefinita del demone IMAP sull'host è la 143. Se si utilizza una connessione sicura tramite SSL, allora la porta è la 993.
Entrambi i protocolli permettono ad un client di accedere, leggere e cancellare le e-mail da un server, ma con alcune differenze. Il protocollo POP 3 scarica la posta direttamente sul PC, eventualmente cancellandola dal server; con il protocollo IMAP è possibile conservare copia delle proprie e-mail sul server, e scaricarle in un secondo momento da altri computer.
Per verificare il corretto funzionamento del server IMAP possiamo utilizzare il client mutt: 

$ mutt -f imap://john@example.com@localhost

Oppure, in alternativa, aprire una connessione IMAP attraverso telnet: 

$ telnet localhost imap2
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
1 login john@example.com summersun
1 OK Logged in.
2 list "" "*"
* LIST (\HasNoChildren) "." "INBOX"
2 OK List completed.
3 select "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1180039205] UIDs valid
* OK [UIDNEXT 3] Predicted next UID
3 OK [READ-WRITE] Select completed.
4 fetch 1 all
* 1 FETCH (FLAGS (\Seen) INTERNALDATE .........
4 OK Fetch completed.
5 fetch 1 body[]
* 1 FETCH (BODY[] {474}
Return-Path: <steve@example.com>
X-Original-To: john@example.com
Delivered-To: john@example.com
Received: from example.com (localhost [127.0.0.1])
        by ... (Postfix) with ESMTP id 692DF379C7
        for <john@example.com>; Fri, 18 May 2007 22:59:31 +0200 (CEST)
Message-Id: <...>
Date: Fri, 18 May 2007 22:59:31 +0200 (CEST)
From: steve@example.com
To: undisclosed-recipients:;

Hi John,

just wanted to drop you a note.
)
5 OK Fetch completed.
6 logout
* BYE Logging out
6 OK Logout completed.

Test dei server POP3s e IMAPs

La via più veloce per testare i servizi POP3s e IMAPs, gli equivalenti dei servizi visti in precedenza, ma con TLS/SSL abilitato, è utilizzare il client mutt: 

$ mutt -f imaps://john@example.com@localhost

Dovecot all'atto dell'installazione genera un certificato self-signed. Potete decidere di utiizzarlo, oppure di generarne un secondo personalizzato: 

# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
    -keyout /etc/ssl/private/dovecot.pem

Durante la generazione del certificato vi saranno poste alcune domande: 

Generating a 1024 bit RSA private key
.........++++++
............................++++++
writing new private key to '/etc/ssl/certs/dovecot.pem'
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Hamburg
Locality Name (eg, city) []:Hamburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:workaround email service
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:mailtest.workaround.org
Email Address []:postmaster@workaround.org

L'impostazione più importante è la definizione del Common Name, dove va inserito il fully-qualified name (FQDN) del mail server. Il certificato generato sarà valido per 10 anni (3650 giorni).
Infine impostiamo i corretti permessi sul file certificato: 

# chmod o= /etc/ssl/private/dovecot.pem

e riavviamo Dovecot per fargli prendere il nuovo certificato: 

# /etc/init.d/dovecot restart

Autenticazione su SMTP

Open relays server

Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:

  • il destinatario è un utente del mail server
  • il mittente sta inviando la mail dal nostro local network, definito dalla direttiva 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_tls_security_level=may
# postconf -e smtpd_tls_auth_only=yes
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/mailserver.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/mailserver.pem
# postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
  • smtpd_sasl_auth_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

NOTA: la direttiva postconf -e smtpd_tls_auth_only=yes è da utilizzarsi solo se vogliamo che i nostri utenti siano costretti a utilizzare SSL per scaricare e inviare la loro posta.

Riavviamo infine Postfix: 

# /etc/init.d/postfix restart

Test della configurazione

Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP: 

$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailtest ESMTP Postfix (Debian/GNU)
ehlo example.com
250-mailtest
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==
235 2.0.0 Authentication successful
quit
221 2.0.0 Bye

L'autenticazione ha funzionato.

Info.png Nota
Se abbiamo impostato la password di john a qualcosa di diverso da summersun dobbiamo ricavarne l'hash Base64 in questo modo: 
$> perl -MMIME::Base64 -e \
    'print encode_base64("john\@example.com\0john\@example.com\0password")';

Ora possiamo testare l'invio di una mail attraverso il nostro client di posta. Per verificare il corretto funzionamento controlliamo i file di log: 

# tail -f /var/log/mail.log

Dovremmo trovare qualcosa di simile: 

postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
postfix/qmgr[3963]: 1234567890: from=<john@example.com>, size=830, nrcpt=1 (queue active)
postfix/smtpd[4032]: disconnect from ...
postfix/smtp[4041]: 1234567890: to=<devnull@workaround.org>,
    relay=torf.workaround.org[212.12.58.129]:25, delay=6,
    delays=0.09/0.08/5.6/0.23, dsn=2.0.0, status=sent
    (250 OK id=1HsPC3-0008UJ-O5)
postfix/qmgr[3963]: 2EAE8379CB: removed

In caso di errore dovremmo invece vedere qualcosa di simile a questo: 

postfix/smtpd[4032]: connect from ...[10.20.30.40]
postfix/smtpd[4032]: warning: ...[10.20.30.40]: SASL PLAIN authentication failed:
postfix/smtpd[4032]: lost connection after AUTH from ...[10.20.30.40]
postfix/smtpd[4032]: disconnect from ...[10.20.30.40]

In fase di installazione Postfix genera automaticamente un certificato SSL, ma potrebbe essere utile crearne uno personalizzato, nella stessa maniera vista in precedenza: 

# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
    -keyout /etc/ssl/private/postfix.pem

L'impostazione più importante è la definizione del Common Name, dove va inserito il fully-qualified name (FQDN) del mail server.
A generazione avvenuta impostiamo i corretti permessi sul file: 

# chmod o= /etc/ssl/private/postfix.pem

e comunichiamo a Postfix di utilizzare il nuovo certificato: 

# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem

Di default Postfix permette l'invio in chiaro dei dati di autenticazione SMTP, ma possiamo impostare la trasmissione crittata agendo su due parametri: 

# postconf -e smtpd_use_tls=yes
# postconf -e smtpd_tls_auth_only=no

In questo modo Postfix offre (ma non richiede obbigatoriamente) la crittazione dei dati di login.
Se vogliamo proibire le connessioni SMTP non crittate, possiamo impostare le direttive smtpd_tls_security_level = encrypt o smtpd_tls_wrappermode = yes. Possiamo anche impostare smtpd_tls_security_level = may (la cosiddetta opportunistic TLS connection).
Una volta terminate le modifiche possiamo testare la corretta configurazione del nostro mail server per quanto riguarda la protezione dai tentativi di relay: 

# telnet relay-test.mail-abuse.org

Con questo comando contatteremo un ottimo servizio che cercherà di inviare alcune mail attraverso il nostro server. Lasciamogli qualche minuto e aspettiamo che compaia la dicitura: 

System appeared to reject relay attempts

Filtrare spam e virus con AMaViS

Configurazione di Spamassassin

Verifichiamo che il demone di SpamAssassin sia attivo, aprendo il file: 

# nano /etc/default/spamassassin

e modificando la riga: 

ENABLED=0

in 

ENABLED=1

Avviamo SpamAssassin e abilitiamo l'aggiornamento automatico delle regole: 

# sa-update && service spamassassin restart

Controlliamo che il servizio di aggiornamento automatico si sia abilitato, verificando che in /etc/default/spamassassin ci sia la riga: 

CRON=1

Verifichiamo che SpamAssassin sia attivo: 

# netstat -ntpl | grep spamd
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2459/spamd.pid

Cambiare o aggiungere i seguenti parametri nel file /etc/spamassassin/local.cf come segue: 

# permette di avere un unico database bayes anziché uno in ogni home degli  user
bayes_path /etc/spamassassin/bayes/bayes 
bayes_file_mode 0666

Successivamente creare la cartella specificata /etc/spamassassin/bayes con i permessi corretti: 

# mkdir /etc/spamassassin/bayes
# chmod 777 /etc/spamassassin/bayes

Controllare se ci sono problemi nella configurazione con il comando: 

# spamassassin --lint

che dovrebbe restituire una riga vuota.

Configurazione di AMaViS

AMaViS (A Mail Virus Scanner) è un'interfaccia tra Postfix, SpamAssassin e un virus scanner come ClamAV.
Installiamo i file necessari: 

# apt-get install amavisd-new clamav-daemon clamav-testfiles clamav-freshclam

La configurazione si AMaViS è divisa in alcuni files nella directory /etc/amavis/conf.d.
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file: 

# nano /etc/amavis/conf.d/15-content_filter_mode

rimuovendo il commento # dalle linee @bypass_...: 

@bypass_virus_checks_maps = (
    \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re)

E' buona cosa dare un occhio anche al file /etc/amavis/conf.d/20-debian_defaults, ma non cambiate questo file. Se avete bisogno di inserire delle personalizzazioni, utilizzate il file /etc/amavis/conf.d/50-user.

  • $sa_spam_subject_tag: se questa linea viene lasciata non commentata, allora ogni email ritenuta da AMaViS sospetta di spam avrà questa stringa inserita nell'oggetto della mail. Se non vogliamo alterare l'oggetto della mail possiamo impostarla a $sa_spam_subject_tag=undef. I client email potranno comunque riconoscere lo spam controllando l'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     -       5  smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o smtp_tls_note_starttls_offer=no
    -o disable_dns_lookups=yes
    -o max_use=20

127.0.0.1:10025 inet n  -       -     -       -  smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
    -o local_header_rewrite_clients=
    -o smtpd_milters=

Quindi riavviamo Postfix: 

# postfix reload

Un parametro in particolare di questa configurazione ha bisogno di alcune spiegazioni. La direttiva receive_override_options è impostata su no_address_mappings. Questo disablita tutti i nostri alias virtuali. Subito dopo la mail è inviata al servizio smtp-amavis e infine ritorna sul servizio 127.0.0.1:10025, su cui sono settate diverse opzioni. Una di queste opzioni è ancora receive_override_options, ma questa volta il suo valore è diverso e quindi, finalmente, Postfix prende in considerazione i nostri alias virtuali. Può sembrare complicato, ma è l'unica strada per evitare che i nostri alias siano valutati due volte, portando a una doppia spedizione di ogni email.

L'utente clamav deve appartenere al gruppo di sistema amavis, in modo che i due servizi possano comunicare tra loro: 

# adduser clamav amavis
# /etc/init.d/clamav-daemon restart


AMaViS cercherà di scoprire se una certa mail è in arrivo (spedita da internet verso uno dei nostri domini) o in uscita (spedita dal nostro server verso internet) controllando l'impostazione @acl_local_domains. Dobbiamo perciò dire a AMaViS come controllare se un certo dominio e uno dei nostri domini virtuali. Modifichiamo quindi il file /etc/amavis/conf.d/50-user aggiungendo, prima della linea 1; le linee: 

@lookup_sql_dsn = (
    ['DBI:mysql:database=mailserver;host=127.0.0.1;port=3306',
     'mailuser',
     'mailuser2009']);

$sql_select_policy = 'SELECT name FROM virtual_domains WHERE CONCAT("@",name) IN (%k)';
  • La direttiva @lookup_sql_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 640 /etc/amavis/conf.d/50-user

Testiamo il funzionamento di ClamAV: 

# clamdscan /usr/share/clamav-testfiles/
/usr/share/clamav-testfiles/clam.pdf: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.chm: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.sis: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.impl.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-nsis.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tar.gz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bz2.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.7z: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-yc.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ole.doc: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.newc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-aspack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ppt: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea05.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea06.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.html: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-upack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.bz2: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-be.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.cab: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.mbox.base64: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.arj: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.binhex: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-fsg.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.mbox.uu: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.odc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tnef: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-mew.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-upx.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-pespin.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.mail: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-wwpack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-petite.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.szdd: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.d64.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-le.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.rtf: ClamAV-Test-File FOUND
----------- SCAN SUMMARY -----------
Infected files: 44
Time: 1.478 sec (0 m 1 s)

Ora proviamo a inviare una mail infetta attraverso Postfix, per vedere se AMaViS e ClamAV si comportano come ci aspettiamo: 

# swaks -t john@example.org --attach - --server localhost --suppress-data < /usr/share/clamav-testfiles/clam.exe

Tra le altre righe in /var/log/mail.log dovremmo trovare una cosa del genere: 

29 23:16:23 sirius amavis[4558]: (04558-02) Blocked INFECTED (ClamAV-Test-File) {DiscardedOutbound,Quarantined}, LOCAL [::1]:44226 [::1] <root@mailserver.example.org> -> <john@example.org>, quarantine: C/virus-ClS0k87Qzm4Q, Queue-ID: 6608ED6B, Message-ID: <20131029221623.6608ED6B@sirius.localdomain>, mail_id: ClS0k87Qzm4Q, Hits: -, size: 1547, 128 ms

segno che ClamAV è intervenuto correttamente, bloccando l'email infetta.
La mail infetta è stata spostata in /var/lib/amavis/virusmails/C/virus-ClS0k87Qzm4Q per essere eventualmente analizzata.


Possiamo impostare uno script per pulire la quarantena attraverso cron: 

#!/bin/dash
[ -d /var/lib/amavis/virusmails ] && {
        find /var/lib/amavis/virusmails/. -type f -name 'virus-*' -ctime +7 -de$
        find /var/lib/amavis/virusmails/. -type f -ctime +30 -delete
}
exit 0

Autenticazione di Postfix su un server SMTP remoto

Se ci fosse la necessità di impostare un relay dal nostro server di posta Postfix verso un server SMTP esterno, è possibile utilizzare questa guida:
Postfix e autenticazione su SMTP remoto

Amministrare gli utenti virtuali

GRSoft Mail Manager

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

  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/install.php
  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
  4. Alla fine dell'installazione seguite le istruzioni per rimuovere i files non più necessari

L'interfaccia permette la definizione di un Super User e di uno o più amministratori per ogni dominio virtuale che verrà creato.

Mail Admin Tool

Un'interfaccia alternativa può essere scaricata a questo indirizzo: Mail Admin Tool.

Broatcast Mail Administrator

La peculiarità di questa interfaccia alternativa è che rende possibile impostare il numero massimo di indirizzi email che ogni dominio può avere. In questo modo possiamo ad esempio avere un dominio con caselle email illimitate e un altro dominio con 5 caselle disponibili. L'interfaccia è scaricabile da qui: Broatcatst Mail Administrator

ISPwebAdmin (web interface): introduzione

Warning.png ATTENZIONE
Interfaccia obsoleta e non più sviluppata. Si consiglia di utilizzare GRSoft Mail Manager


E' disponibile un'ulteriore interfaccia web per amministrare i domini virtuali, gli utenti virtuali e gli alias. L'interfaccia si chiama ISPWebAdmin ed è disponibile per il download all'indirizzo: [Download]

Installazione

Per poter utilizzare ISPWebAdmin è necessario aggiungere alcune tabelle SQL al database per poter archiviare gli username e le password degli amministratori abilitati alla gestione degli account. Apriamo quindi la shell di MySQL: 

# mysql -p mailserver

e digitiamo la query: 

CREATE TABLE IF NOT EXISTS `admins` (
`id` int(11) NOT NULL auto_increment,
`username` varchar(40) NOT NULL,
`pwhash` varchar(32) NOT NULL,
PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

Quindi creiamo un utente amministratore che possa effettuare il login nell'interfaccia web: 

INSERT INTO mailserver.admins (username,pwhash) VALUES ('john', MD5('doe'));

Installiamo e configuriamo alcuni requisiti per l'interfaccia: 

# aptitude install python-virtualenv
# apt-get build-dep python-mysqldb
# su -s /bin/bash vmail
cd /var/vmail
mkdir ispwebadmin
cd ispwebadmin
wget http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz
virtualenv .
. bin/activate

A questo punto siamo pronti per effettuare l'installazione dell'interfaccia: 

easy_install ispwebadmin*.tar.gz
paster make-config ispwebadmin run.ini

Il secondo comando creerà un file run.ini che conterrà le impostazioni specifiche per la nostra installazione. Per modificare queste impostazioni (che saranno trattate nel paragrafo successivo) possiamo aprire il file con il nostro editor preferito: 

nano run.ini

Ora siamo pronti per avviare la nostra web application: 

paster serve run.ini

Su un server, però, non è conveniente avere dei servizi da avviare manualmente. Vediamo quindi come creare un servizio che funzioni in background e che sia avviato automaticamente all'avvio del server.
Per creare il nuovo servizio utilizzeremo il sistema runit di Debian Lenny: 

# aptitude install runit
# mkdir /etc/sv/ispwebadmin
# cd /etc/sv/ispwebadmin

Creiamo ora un file /etc/sv/ispwebadmin/run 

# nano /etc/sv/ispwebadmin/run

contenente: 

#!/bin/sh
exec 2>&1
echo 'ISPwebAdmin starting.'
cd /var/vmail/ispwebadmin
sudo -u vmail PYTHON_EGG_CACHE=/var/vmail/ispwebadmin/.python-eggs bin/paster serve run.ini

Rendiamo eseguibile il file: 

# chmod u+x /etc/sv/ispwebadmin/run

e creiamo il symlink corretto: 

# ln -s /etc/sv/ispwebadmin /etc/service/

Da questo momento il servizio potrà essere utilizzato nel modo seguente:

  • Stato: sv status /etc/service/ispwebadmin
  • Arresto: sv stop /etc/service/ispwebadmin
  • Avvio: sv start /etc/service/ispwebadmin

Se vogliamo avere un log di questo servizio possiamo creare un file 

# nano /etc/sv/ispwebadmin/log/run

contenente: 

#!/bin/sh -e
LOG=/var/log/runit-ispwebadmin
test -d "$LOG" || mkdir -p -m2750 "$LOG"
exec svlogd -tt "$LOG"

Il file di log si troverà in /var/log/runit-ispwebadmin.

Configurazione del file run.ini

Il file creato con il comando paster make-config run.ini contiene alcune impostazioni che possono essere personalizzate per adattarle alla configurazione del nostro mail server. Prima di avviare la web interface è consigliato aprire il file e controllare queste impostazioni:

  • '[server:main] -> host: l'indirizzo IP dove il web server è in ascolto. E' possibile impostare "0.0.0.0" per indicare tutte le interfacce di rete
  • [server:main] -> port: la porta TCP dove il web server è in ascolto
  • [app:main] -> ispwebadmin.maildir_location: il percorso dove sono archiviate le mail boxes degli utenti. Nel corso di questo tutorial è stato utilizzato /var/vmail
  • [app:main] -> ispwebadmin.postmaster: l'indirizzo email utilizzato come abuse@ e postmaster@ per i nuovi domini creati. E' richiesto un account del genere per ogni dominio creato. Questa impostazione è opzionale.
  • [app:main] -> sqlalchemy.url: la stringa che definisce come effettuare la connessione al database. Ad esempio:
mysql://root:seoroct3@mailserver.example.com/mailserver?charset=utf8

Impostazione dei record DNS

DNS è l'acronimo per domain name system, il protocollo che permette la traduzione di nomi come www.workaround.org in indirizzi IP come 212.12.58.129 e viceversa. Se intendiamo ricevere la posta di un dominio dobbiamo essere incaricati della sua zona. Normalmente la configurazione di una zona prevede la creazione di alcuni record DNS: 

IN  TXT  "v=spf1 ip4:212.12.58.128/27 -all"
IN  MX      10 mx1.workaround.org
IN  MX      20 mx2.workaround.org
IN  MX      30 mx3.workaround.org
IN  MX      40 mx4.workaround.org
IN  A    212.12.58.129
  • IN rappresenta la classe dei record DNS. In internet è sempre IN.

La seconda colonna descrive il tipo di record:

  • TXT = Text record (può avere fino a 255 caratteri). Utilizzato per SPF, che sarà descritto più avanti
  • MX = Mail Exchanger record (indica i mail server del dominio)
  • A = Address record (E' il record di default)

Come fanno gli altri server a trovare il nostro mail server?

Un server che abbia nella sua coda una mail indirizzata al nostro dominio per prima cosa esegue un DNS lookup per trovare un record MX per il dominio. Se ottiene più di una risposta contatterà prima il server con la priorità più alta (= il numero più basso) e successivamente, se non dovesse ottenere risposta, tutti gli altri in ordine di priorità.
Per verificare il corretto funzionamento dei nostri record DNS installiamo alcuni tool: 

# aptitude install dnsutils

quindi verifichiamo la corretta risposta dei server DNS: 

$> dig +short workaround.org mx
30 mx3.workaround.org.
40 mx4.workaround.org.
10 mx1.workaround.org.
20 mx2.workaround.org.

$> dig +short mx1.workaround.org
212.12.58.158

Per ricevere le mail indirizzate al nostro dominio abbiamo quindi bisogno di un record MX nella nostra zona. Poichè però un record MX può puntare solo a un hostname e non a un indirizzo IP avremo bisogno anche di un record A.

Guerra allo spam con le Realtime Black Lists (RBL)

Una delle tecniche più comuni per combattere gli spammer è il ricorso alle blacklist. Esistono diverse liste che possono essere usate liberamente: i loro amministratori hanno politiche di blacklisting diverse, alcune più aggressive, altre meno.
Tra i servizi di blacklisting più utilizzati vanno citati:

  • SORBS (dnsbl.sorbs.net)
  • SpamCop (bl.spamcop.net)
  • SpamHaus (zen.spamhaus.org)
  • UCEprotect (dnsbl-1.uceprotect.net)

Se decidete di fare uso di una o più di queste blacklist, la sezione smtpd_recipient_restrictions del vostro /etc/postfix/main.cf diventerà così: 

smtpd_recipient_restrictions =
   permit_mynetworks
   reject_rbl_client dnsbl.sorbs.net
   reject_rbl_client bl.spamcop.net
   reject_rbl_client zen.spamhaus.org
   reject_rbl_client dnsbl-1.uceprotect.net
   reject_unauth_destination

Alcune altre utili restrizioni possono essere:

  • reject_unknown_client_hostname: esegue una doppia verifica DNS tra l'IP e l'hostname del mittente
  • reject_unknown_sender_domain: controlla se il dominio del mittente esiste reralmente. Per effettuare la verifica esegue un controllo sui record MX e A del dominio del mittente
  • reject_unauth_pipelining: elimina le connessioni al nostro server che cercano di utilizzare il metodo delle pipeline per spedire quante più mail possibili nel minor tempo possibile

E' possibile anche impostare delle regole per il blocco automatico di alcuni domini riconosciuti come spammer; la lista dei domini è personalizzabile tramite un semplice file di testo.
Innanzitutto aggiungiamo la sezione: 

smtpd_client_restrictions =
       permit_mynetworks
       check_client_access hash:/etc/postfix/access
       permit

prima della sezione: 

smtpd_recipient_restrictions

Quindi creiamo il file contenente la lista dei domini da bloccare o da autorizzare senza ulteriori controlli: 

# nano /etc/postfix/access

e riempiamolo con la nostra lista: 

yahoo.com.tw REJECT
hinet.com REJECT 
pchome.com.tw REJECT
yahoo.co.jp REJECT
yam.com REJECT
inet.net REJECT
ferdy.it OK

In questo caso abbiamo bloccato alcuni domini e autorizzato il dominio ferdy.it a inviarci mail senza nessun ulteriore controllo.
Inseriamo alcuni ulteriori controlli sull'header e sul body della mail, aggiungendo la sezione: 

# Verifico correttezza header e body
header_checks = pcre:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

e creando i due file relativi: 

# nano /etc/postfix/header_checks

con contenuto (da scrivere in una riga sola): 

/^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|ht[at]|inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
\{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x
REJECT Allegato "$2" con estensione proibita ".$4"

# nano /etc/postfix/body_checks

/^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/
REJECT IFRAME vulnerability exploit

Quindi facciamo in modo che Postfix si crei il database relativo: 

# postmap /etc/postfix/access

Questo comando andrà ripetuto ad ogni modifica del file.

Un esempio di main.cf

###############################
# Configurazioni iniziali
###############################

# Messaggio di benvenuto
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no



#############################
# Configurazione SSL
#############################

# TLS parameters
smtpd_tls_cert_file = /etc/ssl/certs/mailserver.pem
smtpd_tls_key_file = /etc/ssl/private/mailserver.pem
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_security_level = may
smtpd_tls_auth_only = no



######################################
# Configurazione 
######################################

myhostname = mail01.xxxxx.org
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail01.xxxxx.org, localhost.xxxxx.org, , localhost.xxxxxyy.com, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/24
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
queue_directory = /var/spool/postfix



#######################################
# Configurazione utenti virtuali MySQL
#######################################

virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf



###################
# Regole Antispam
###################

# Verifico correttezza header e body
header_checks = pcre:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

# Abilito a spedire solo gli utenti presenti in MySQL
smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cf

# Restrizioni helo
smtpd_helo_required = yes
smtpd_helo_restrictions =
        permit_mynetworks
        #reject_unknown_client
        #reject_invalid_hostname
        #reject_unauth_pipelining
        #reject_unknown_hostname
        #reject_non_fqdn_hostname

# Restrizioni sui mittenti abilitati
smtpd_sender_restrictions = 
        permit_mynetworks
        permit_sasl_authenticated
        #reject_unknown_address
        #reject_unauth_destination
        reject_unauth_pipelining
	reject_unknown_sender_domain
	reject_non_fqdn_sender
	reject_sender_login_mismatch

# Blocco alcuni domini spammer
smtpd_client_restrictions =
	permit_mynetworks
        #check_client_access hash:/etc/postfix/access
        #reject_invalid_hostname
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client multi.uribl.com
        reject_rbl_client dsn.rfc-ignorant.org
        reject_rbl_client dul.dnsbl.sorbs.net
        reject_rbl_client list.dsbl.org
        reject_rbl_client sbl-xbl.spamhaus.org
        reject_rbl_client bl.spamcop.net
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client combined.rbl.msrbl.net
        reject_rbl_client rabl.nuclearelephant.com
        #reject_unknown_client
        permit
	
# Restrizioni sui destinatari
smtpd_recipient_restrictions = 
	permit_mynetworks
	permit_sasl_authenticated
	reject_unauth_destination
        check_client_access hash:/etc/postfix/access
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client multi.uribl.com
        reject_rbl_client dsn.rfc-ignorant.org
        reject_rbl_client dul.dnsbl.sorbs.net
        reject_rbl_client list.dsbl.org
        reject_rbl_client sbl-xbl.spamhaus.org
        reject_rbl_client bl.spamcop.net
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client combined.rbl.msrbl.net
        reject_rbl_client rabl.nuclearelephant.com
	reject_rbl_client dnsbl-1.uceprotect.net
        reject_unknown_sender_domain
        reject_unauth_pipelining
        check_policy_service unix:private/tumgreyspf
        reject_non_fqdn_sender
        reject_non_fqdn_recipient
        reject_non_fqdn_hostname
        reject_invalid_hostname

# Non piu' di 200 destinatari al minuto
smtpd_client_recipient_rate_limit = 200

# Non piu' di 50 destinatari per ogni messaggio
smtpd_recipient_limit = 50

# Numero di destinatari in eccesso prima che scatti il blocco
smtpd_recipient_overshoot_limit = 21

# Numero di errori massimi di un client prima di essere disconnesso
smtpd_hard_error_limit = 20

# Impedisco invio mail ad alcuni utenti locali
authorized_submit_users = !www-data, static:all



#########################
# Configurazione Dovecot
#########################

virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes



###############################
# Integrazione con AMaViS
###############################

content_filter = smtp-amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

SPF per ridurre ancora di più lo spam

SPF, acronimo per Sender Policy Framework, è un sistema attraverso il quale il proprietario di un dominio può definire quali indirizzi IP sono autorizzati a inviare le sue mail. 

$> dig +short workaround.org txt
"v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"

Questa riga significa che se qualcuno invia una mail con mittente ...@workaround.org noi dovremmo accettarla solo se proviene da uno degli indirizzi IP specificati nel record TXT della zona del dominio in questione. Se la mail proviene da un atro IP significa che non è stata spedita da un server di workaround.org e che con tutta probabilità si tratta di spam.
Molte organizzazioni e molti siti hanno già i loro record SPF, che possiamo utilizzare per ridurre la quantità di spam in arrivo sui nostri server. Per utilizzare correttamente i record SPF dovremo quindi:

  • impostare un record TXT nella nostra zona per definire quali indirizzi IP sono autorizzati a inviare mail a nome nostro
  • controllare le voci SPF dei server mittenti e respingere la mail in arrivo da IP non autorizzati

Impostare una voce SPF

Per aggiungere un record TXT come mostrato nel paragrafo precedente dovremo ovviamente avere il pieno controllo della nostra zona DNS, oppure chiedere al nostro ISP che lo faccia per noi.
Per creare una corretta stringa TXT è consigliabile andare sul sito di OpenSPF e utilizzare il wizard apposito; quindi copincolliamo la stringa risultante e utilizziamola come record TXT per il nostro dominio.

Verificare i record SPF degli altri mail server

Fortunatamente esiste un pacchetto Debian che rende il controllo dei record SPF una cosa molto semplice. Iniziamo con l'installazione del pacchetto: 

# apt-get install tumgreyspf

tumgreyspf è un policy daemon scritto in Python che effettua sia il greylisting sia il controllo SPF delle email in entrata. Per attivarlo basta semplicemente aggiungere una linea alla nostra direttiva smtpd_recipient_restrictions. Ad esempio: 

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    [ ... ]
    check_policy_service unix:private/tumgreyspf
    reject_unauth_destination

Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file /etc/postfix/master.cf: 

tumgreyspf unix  -      n       n       -       -       spawn
    user=tumgreyspf argv=/usr/bin/tumgreyspf

Ora riavviamo Postfix: 

# postfix reload

Verifica del funzionamento di SPF

SPF okay

Controlliamo il file /var/log/mail.log. Ogni nuova mail in arrivo dovrebbe adesso avere una nuova riga aggiunta da tumgreyspf. Se il controllo SPF è risultato positivo, dovremmo avere qualcosa come: 

tumgreyspf[24672]: sender SPF authorized: QUEUE_ID=""; identity=mailfrom;
   client-ip=26.21.244.31; helo=squedge2.squ.edu.om;
   envelope-from=…@squ.edu.om;
   receiver=…@workaround.org;

Questo significa che il mittente …@squ.edu.om è stato autorizzato all'invio della mail dopo un controllo dei record SPF.

SPF fail

Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere: 

tumgreyspf[24672]: SPF fail - not authorized: QUEUE_ID=""; identity=mailfrom;
   client-ip=41.234.18.141; helo=gmx.de;
   envelope-from=…gmx.de;
   receiver=…christoph-haas.de;

La mail è stata respinta.

SPF softfail

Un altro caso è quando il record SPF del dominio del mittente non contiene la regola FAIL (-all), ma la regola SOFTFAIL (~all). Nei nostri log troveremo qualcosa del genere: 

tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID="";
   identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au;
   envelope-from=…@rollouts.com; receiver=…@workaround.org

Purtroppo una regola SOFTFAIL non respinge la mail in arrivo, ma fa almeno in modo che il destinatario sia avvertito del problema, aggiungendo un'informazione all'header della mail: 

Received-SPF: Softfail (domain owner discourages use of this host) identity=mailfrom;
   client-ip=61.146.93.243; helo=mail.163gd.com;
   envelope-from=…@cantv.net; receiver=…@christoph-haas.de;

In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.

No SPF information

Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere: 

Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom;
   client-ip=80.65.65.222; helo=mail.unze.ba;
   envelope-from=…@gmail.com; receiver=…@christoph-haas.de;

Quote

Il nostro mail server non ha spazio infinito, soprattutto se usiamo il protocollo IMAP e gli utenti apprezzano la comodità di avere le mail sempre a disposizione sul server. Perciò vorremo probabilmente limitare lo spazio che un utente può occupare. Dovecot può impostare la dimensione della mailbox di un utente e il numero di email della sue cartelle virtuali.
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.

Debian Lenny

Lenny: Attivare il plugin quota di Dovecot

Ci sono tre punti nel file /etc/dovecot/dovecot.conf dove occorre specificare l'abilitazione del plugin: 

protocol imap {
  mail_plugins = quota imap_quota
}
protocol pop3 {
  mail_plugins = quota
}
protocol lda {
  mail_plugins = quota
}
Lenny: Impostare una quota globale

Il caso più semplice è quello in cui si intende impostare una quota limite comune e uguale per tutti gli utenti, ad esempio 1GB di spazio con non più di 1000 email archiviabili. Nel file /etc/dovecot/dovecot.conf dovremo impostare: 

plugin {
  quota = maildir:storage=1000000:messages=1000
}

ricordando che i valori per lo storage sono espressi in KB.

Lenny: Impostare una quota utente

Se intendiamo impostare per alcuni utenti delle quote diverse da quelle globali, allora dobbiamo impostare la quota all'interno della tabella dei virtual_users. Utilizziamo la seguente query per aggiungere due colonne alla nostra tabella virtual_users: 

mysql>
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
ADD `quota_messages` INT NOT NULL ;

Inoltre dovremo abilitare la direttiva user sql nel file /etc/dovecot/dovecot.conf, disabilitando la direttiva user static suggerita all'inizio del tutorial: 

#userdb static {
#  args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
#

userdb sql {
    args = /etc/dovecot/dovecot-sql.conf
}

Infine dovremo aggiungere al file /etc/dovecot/dovecot-sql.conf la linea: 

user_query = SELECT CONCAT('/var/vmail/',CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1))) AS home, 5000 AS uid, 5000 AS gid, CONCAT('maildir:storage=',quota_kb,':messages=',quota_messages) AS quota FROM virtual_users WHERE email='%u';
Lenny: Cosa succede se un utente supera la quota

La gestione delle quote in Dovecot non è molto user-friendly. Il mittente non riceve un avviso se è vicino a superare la quota limite; in compenso, quando l'ha superata, le sue mail torneranno indietro con oggetto "Automatically rejected mail" e corpo della mail "Your message to <john@example.com> was automatically rejected: Quota exceeded".

Debian Squeeze

A partire da Dovecot 1.1, di default su Squeeze, la gestione delle quote è cambiata notevolmente.

Squeeze: Impostazione delle Quote root

Dobbiamo innanzitutto aprire il file di configurazione di Dovecot: 

# nano /etc/dovecot/dovecot.conf

recarci alla sezione plugin { } e definire le quote root. Ad esempio: 

plugin {
  quota = maildir:User quota
  #quota2 = fs:Disk quota
  #quota3 = ...
}

In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.

Squeeze: Quote rules

A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota: 

plugin {
  # Quota root
  quota = maildir:User quota
  # Quote rules
  # 1 - Dimensione massima 2 GB
  quota_rule = *:storage=2GB
  # 2 - Dimensione Cestino 200 MB
  quota_rule2 = Trash:storage=200MB
  # 3 - Dimensione cartella Spam 200MB
  quota_rule3 = Spam:storage=200MB
}
Squeeze: Cosa succede se un utente supera la quota

In Squeeze possiamo finalmente configurare Dovecot in modo che invii un messaggio personalizzato agli utenti che hanno superato la loro quota disco. All'interno della solita sezione del file di configurazione di Dovecot aggiungiamo la riga: 

plugin {
   quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
Squeeze: messaggio di avvertimento

In Squeeze possiamo anche configurare Dovecot in modo che avvii un comando esterno quando la quota di un certo utente supera una certa percentuale. Come al solito dobbiamo recarci nella sezione plugin { } del file di configurazione di Dovecot e aggiungere le seguenti linee: 

plugin {
  quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95
  quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80
}

Nell'esempio precedente, lo script quota-warning.sh è eseguito una prima volta quando l'utente raggiunge l'80% del suo spazio disco e una seconda volta quando raggiunge il 95%.
Lo script va creato a mano: 

# nano /usr/local/bin/quota-warning.sh

con contenuto: 

#!/bin/sh

PERCENT=$1
FROM="webmaster@example.com"
qwf="/tmp/quota.warning.$$"

echo "From: $FROM
To: $USER
To: postmaster@domain.org
Subject: Hai raggiunto il $PERCENT% del tuo spazio su disco!
Content-Type: text/plain; charset="UTF-8"

La tua mailbox ha raggiunto il $PERCENT% dello spazio disponibile. Sei pregato di eliminare le mail che non ti occorrono." >> $qwf

cat $qwf | /usr/sbin/sendmail -f $FROM "$USER"
rm -f $qwf

exit 0

Rendiamo lo script eseguibile: 

# chmod 750 /usr/local/bin/quota-warning.sh

e siamo a posto.

Debian Wheezy

A partire da Debian Wheezy, la configurazione (può essere identica a quella per Squeeze) deve essere inserita nel file /etc/dovecot/conf.d/90-quota.conf.

Accesso tramite Webmail

Squirrelmail

Questo passaggio è facoltativo, ma ormai praticamente tutti i provider offrono ai loro utenti un mezzo per poter controllare le email da un browser.
Per questo motivo durante l'iniziale installazione dei pacchetti abbiamo scelto anche il pacchetto squirrelmail: SquirrelMail è un pacchetto per posta via web aderente agli standard, scritto in PHP. Include supporto integrato in PHP puro per i protocolli IMAP e SMTP ed è progettato per una massima compatibilità con i vari browser. SquirrelMail non richiede molte cose ed è facile da configurare ed installare. Gira sopra qualsiasi server IMAP. SquirrelMail ha tutte le funzioni che si possono desiderare in un client di posta elettronica, incluso un forte supporto MIME, gestione di rubriche e cartelle (Fonte: Debian package).
Per impostarlo dobbiamo inannzitutto aggiungere la sua configurazione a quella di Apache: 

$> ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf
$> apache2ctl restart

Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail: 

$> squirrelmail-configure

Selezioniamo l'opzione 3 (Folder Defaults) e impostiamo l'opzione 1 (Default Folder Prefix) a 'none'. Già che ci siamo possiamo anche navigare all'interno del menu di configurazione e impostare anche il nome corretto per la nostra organizzazione.
A questo punto visitando il sito: http://ip.del.nostro.server/squirrelmail possiamo effettuare il login con le credenziali di uno dei nostri virtual user e iniziare ad usare la webmail.


Permettere il cambio password all'utente

Può essere molto comodo dare all'utente la possibilità di cambiarsi la password per conto suo, senza stressare il sistemista di turno. La cosa più semplice è permetterglielo attraverso la webmail. Squirrelmail di default non prevede questa funzione, ma per fortuna esiste un ottimo plugin che fa al caso nostro. Andiamo quindi alla pagina del plugin (http://squirrelmail.org/plugin_view.php?id=25) e scarichiamolo. Quindi copiamolo nella directory: 

/usr/share/squirrelmail/plugins

e scompattiamolo: 

# tar zxvf change_sqlpass-3.3-1.2.tar.gz

Prima di modificarne la configurazione dobbiamo compiere alcune operazioni propedeutiche: 

# apt-get install php-mdb2 squirrelmail-compatibility
# pear install DB

Ora siamo pronti per configurare il plugin appena scaricato: 

# cd /usr/share/squirrelmail/plugins/change_sqlpass
# cp config.php.sample config.php   
# vi config.php
  • Modifichiamo la riga:
$csp_dsn = 'mysql://root:password@localhost/mailserver';

inserendo le credenziali per l'accesso al database mailserver.

  • Modifichiamo la riga:
$lookup_password_query = 'SELECT count(*) FROM virtual_users WHERE email = "%1" AND password = %4';

inserendo la query corretta per la ricerca dell'utente virtuale.

  • Modifichiamo la riga:
'UPDATE virtual_users SET password = %4 WHERE email = "%1"',

inserendo la query corretta per la modifica della password dell'utente virtuale.

  • Inseriamo il corretto metodo di crittazione usato dal nostro database:
$password_encryption = 'MD5';
  • Correggiamo la stringa:
$csp_salt_static = '';

e salviamo il file.
Quindi riconfiguriamo Squirrelmail: 

# cd ../../config/
# ./conf.pl

e attiviamo il plugin: 

   
8. Plugins
x. change_sqlpass
Save S and exit Q.

Effettuando il login nella nostra webmail, sotto la voce "Opzioni" troveremo la funzione "Cambia password".

Roundcube

In alternativa (o affiancato) a Squirrelmail possiamo offrire il più moderno e eye-candy Roundcube, anch'esso presente nei repository di Debian. Per installarlo basta un comando:

  • Lenny:
# apt-get -t lenny-backports install roundcube
  • Da Squeeze in poi:
# apt-get install roundcube

Rispondiamo di sì alla domanda dell'installer se configurare o meno un database con dbconfig-common e scegliamo come database il solito MySQL. Ci verrà poi richiesta la password di amministratore di MySQL e l'installazione terminerà.
Ora modifichiamo il file di configurazione: 

# nano /etc/roundcube/main.inc.php

modificando le linee: 

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['force_https'] = true;
Bulb.png Suggerimento
Se il server su cui è installato Roundcube è diverso da quello su cui girano Postfix e Dovecot, dovrete impostare correttamente Roundcube affinchè possa connettersi al server remoto: $rcmail_config['smtp_server'] = 'tls://12.34.56.78';


Quindi modifichiamo il file che definisce il Virtual Host di Roundcube: 

# nano /etc/roundcube/apache.conf

e decommentiamo le linee: 

    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
    Alias /roundcube /var/lib/roundcube

Installiamo i driver MDB2: 

# pear install MDB2_Driver_mysql

Riavviamo Apache: 

/etc/init.d/apache2 restart

e facciamo login nella nostra webmail all'indirizzo: http:// your-domain/roundcube

Personalizzazione di Roundcube

Per essere più professionali nella nostra offerta, possiamo personalizzare alcune voci di Roundcube. Apriamo il suo file di configurazione: 

# nano /etc/roundcube/main.inc.php

e modifichiamo le righe: 

#$rcmail_config['product_name'] = ‘RoundCube Webmail’;
$rcmail_config['product_name'] = ‘Il mio nome Webmail’;

Quindi andiamo in /var/lib/roundcube/skins/classic <oppure larry>/images e sostituiamo il file roundcube_logo.png con una PNG contenente il nostro logo.

Filtri server-side: Sieve per Roundcube

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 i nostri utenti riescano a impostare dei filtri e delle regole server-side.
Roundcube è già pienamente compatibile con Sieve, dobbiamo solo informarlo della sua installazione: 

# cp /usr/share/roundcube/plugins/managesieve/config.inc.php.dist /etc/roundcube/plugins/managesieve/config.inc.php

Ora apriamo il file di configurazione del plugin: 

# nano /etc/roundcube/plugins/managesieve/config.inc.php

e impostiamo la corretta porta TCP dove Dovecot si aspetta le connessioni da Sieve: 

$rcmail_config['managesieve_port'] = 4190;

Quindi abilitiamo il plugin managesieve in RoundCube: 

# nano /etc/roundcube/main.inc.php

$rcmail_config['plugins'] = array('managesieve');

A questo punto, dalla schermata Impostazioni di Roundcube ogni utente troverà una nuova scheda chiamata Filtri, dove potrà impostare tutti i filtri che gli interessano.
Creiamo un file di configurazione per Sieve: 

# nano /var/vmail/globalsieverc

contenente: 

require ["fileinto"];

# Sposto lo spam in un folder apposito
if header :contains "X-Spam-Flag" ["YES"] {
fileinto "Junk";
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/conf.d/15-lda.conf

e decommentando la voce: 

  mail_plugins = $mail_plugins sieve

# nano /etc/dovecot/conf.d/90-sieve.conf

plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_before = /var/vmail/globalsieverc
}

Riavviamo Dovecot: 

# /etc/init.d/dovecot restart

Filtri server-side: Sieve per Squirrelmail

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.


Sicuramente i nostri utenti non avranno voglia di impararsi il linguaggio di filtering di Sieve e avranno quindi bisogno di una maniera comoda di amministrare i loro filtri. Questo può essere fatto attraverso il plugin avelsieve di Squirrelmail: 

# aptitude install avelsieve

Il pacchetto di Debian ha in alcune versioni un errore sulla porta di ascolto del demone Sieve; se la vostra versione è affetta da questo bug, al primo tentativo di login su Squirrelmail vi troverete davanti al messaggio: 

Could not log on to timsieved daemon on your IMAP server localhost:4190

Il plugin avelsieve si è messo in ascolto sulla porta sbagliata... Apriamo il suo file di configurazione: 

# nano /usr/share/squirrelmail/plugins/avelsieve/config/config.php

e modifichiamo come segue la sezione incriminata: 

/* ======================================================================== */
/* =================== ManageSieve Backend Options ======================== */
/* ======================================================================== */
/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */

/** DEBIAN CHANGE: Despite upstream's intention Debian changed this default
*  distribution wide to 4190 which is thus default here.
*/
global $sieveport;
$sieveport = 4190;

Effettuando ora il login su Squirrelmail noteremo una nuova voce di menu chiamata "Filters" da cui potremo impostare tutte le regole che vogliamo.

Eliminare le email vecchie

Con il protocollo IMAP è possibile che alcuni client marchino le email come "cancellate" senza però eliminarle fisicamente dal server. L'utente non le vede più, ma queste continuano a occupare spazio sul nostro server. E' conveniente perciò impostare uno script che elimini queste mail in maniera automatica: 

find /var/vmail -type f -ctime +7 -name '*,ST' -delete

Con questo comando, che possiamo inserire nel crontab del server, vengono eliminate tutte le email cancellate e più vecchie di 7 giorni.

Ulteriori armi contro lo Spam

Possiamo aggiungere altri due filtri collaborativi contro lo spam seguendo queste due guide:

Il mio server è stato blacklistato!

Ci siamo prodigati per proteggere il nostro mailserver, ma è accaduto lo stesso: il nostro indirizzo IP è stato inserito in una o più blacklist.
Che cosa possiamo fare?

  1. Verificare in quali blacklist siamo stati inseriti; possiamo utilizzare alcuni tool online che in pochi attimi ci daranno il responso:
  1. Scrivere ai gestori della blacklist chiedendo la rimozione del nostro IP: non funzionerà, ma almeno potremo dire di averci provato!
  2. Verificare come è successo, analizzando tutta la configurazione e scandagliando i log
  3. Avvertire i clienti dell'inconveniente, invitandoli a controllare a loro volta le loro configurazioni e le loro postazioni
  4. In attesa che il nostro IP venga sbloccato, se possediamo più indirizzi IP possiamo configurare un secondo IP virtuale sulla nostra scheda di rete e inoltrare tutto il traffico di posta verso questo nuovo indirizzo, con il comando:
# iptables -t nat -A POSTROUTING -p tcp --dport 25 -j SNAT --to-source NUOVO.INDIRIZZO.IP.ALIAS
Warning.png ATTENZIONE
Se non abbiamo risolto il problema alla radice, in breve tempo anche il nuovo indirizzo IP finirà blacklistato



Se abbiamo localizzato il dominio che sta inviando spam dal nostro mailserver, possiamo temporaneamente disabilitarlo dall'invio di nuove mail, dopo averlo comunicato agli intestatari.
Per farlo dobbiamo modificare il file di configurazione di Postfix: 

# nano /etc/postfix/main.cf

aggiungendo la sezione: 

smtpd_sender_restrictions = 
      check_sender_access hash:/etc/postfix/sender_access

Quindi creiamo il file: 

# nano /etc/postfix/sender_access

di contenuto simile a questo: 

janedoe@acme.local REJECT
acme.com REJECT
bugsbunny@acme.com OK

Infine informiamo Postfix: 

# postmap /etc/postfix/sender_access

e riavviamo il demone: 

# /etc/init.d/postfix restart

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

Statistiche e report

Il pacchetto pflogsumm (Postfix Log Summary) è comodo per avere un sommario di ciò che succede sul nostro mailserver: 

# apt-get install pflogsumm

Per utilizzarlo basta indicargli il percorso del file di log di Postfix: 

# pflogsumm /var/log/mail.log

messages

    129   received
    331   delivered
      1   forwarded
      8   deferred  (59  deferrals)
      3   bounced
    586   rejected (63%)
      0   reject warnings
      0   held
      0   discarded (0%)

   3108k  bytes received
   3967k  bytes delivered
     36   senders
     28   sending hosts/domains
    229   recipients
    147   recipient hosts/domains

Gestire una Mailing List

Nel caso volessimo installare anche un servizio per la gestione di mailing list, possiamo appoggiarci a Mailman, probabilmente il più diffuso mailing list manager open-source.
Configureremo un virtual host con hostname lists.example.com in cui installeremo Mailman. lists.example.com sarà anche la parte destra dell'indirizzo delle mailing list che creeremo in Mailman, quindi ogni mailing list avrà un indirizzo del tipo <nome_lista>@lists.example.com.

Installazione di Mailman

Mailman si appoggerà a Apache per il suo frontend.
Installiamo il software: 

# apt-get install mailman

Durante l'installazione ci verranno poste le seguenti domande: 

Languages to support: <-- it (Italian)

Missing site list
Mailman needs a so-called "site list", which is the list from which password reminders and such are sent out from.
This list needs to be created before mailman will start.
To create the list, run "newlist mailman" and follow the instructions on-screen.
Note that you also need to start mailman after that, using /etc/init.d/mailman start. <-- Ok

Configurazione di Mailman

Mailman ha già un suo file di configurazione per Apache quasi pronto. Dobbiamo solo copiarlo nella directory corretta: 

# cp /etc/mailman/apache.conf /etc/apache2/sites-available/mailman.conf

e modificare alcune cose: 

# nano /etc/apache2/sites-available/mailman.conf

Alla fine del file, dopo la sezione commentata del virtual host già presente (da lasciare commentata!), aggiungiamo la configurazione del nostro virtual host: 

[...]
<VirtualHost *:80>
ServerName lists.example.com
DocumentRoot /var/www/lists
ErrorLog /var/log/apache2/lists-error.log
CustomLog /var/log/apache2/lists-access.log combined

<Directory /var/lib/mailman/archives/>
    Options FollowSymLinks
    AllowOverride None
</Directory>

Alias /pipermail/ /var/lib/mailman/archives/public/
Alias /images/mailman/ /usr/share/images/mailman/
ScriptAlias /admin /usr/lib/cgi-bin/mailman/admin
ScriptAlias /admindb /usr/lib/cgi-bin/mailman/admindb
ScriptAlias /confirm /usr/lib/cgi-bin/mailman/confirm
ScriptAlias /create /usr/lib/cgi-bin/mailman/create
ScriptAlias /edithtml /usr/lib/cgi-bin/mailman/edithtml
ScriptAlias /listinfo /usr/lib/cgi-bin/mailman/listinfo
ScriptAlias /options /usr/lib/cgi-bin/mailman/options
ScriptAlias /private /usr/lib/cgi-bin/mailman/private
ScriptAlias /rmlist /usr/lib/cgi-bin/mailman/rmlist
ScriptAlias /roster /usr/lib/cgi-bin/mailman/roster
ScriptAlias /subscribe /usr/lib/cgi-bin/mailman/subscribe
ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo
</VirtualHost>

L'ultima direttiva ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo è opzionale; ha senso se non abbiamo nessun file index nella root del virtual host e vogliamo che digitando http://lists.example.com/ si venga diretti automaticamente verso http://lists.example.com/listinfo.
Quindi creiamo la document root /var/www/lists, abilitiamo il nuovo Virtual Host e riavviamo Apache: 

# mkdir /var/www/lists
# a2ensite mailman.conf
# /etc/init.d/apache2 restart

Dato che stiamo usando un Virtual Host, dobbiamo sistemare alcune variabili nella configurazione di Mailman in /etc/mailman/mm_cfg.py: 

# nano /etc/mailman/mm_cfg.py

[...]
DEFAULT_URL_PATTERN = 'http://%s/'
[...]
DEFAULT_EMAIL_HOST = 'lists.example.com'
[...]
DEFAULT_URL_HOST = 'lists.example.com'
[...]

Configurazione di Postfix

Ora dobbiamo configurare Postfix. Impostiamo alcune direttive per Mailman: 

# postconf -e 'relay_domains = lists.example.com'
# postconf -e 'mailman_destination_recipient_limit = 1'

Quindi apriamo il file: 

# nano /etc/postfix/master.cf

e controlliamo che siano presenti le seguenti linee (di default dovrebbero esserci): 

[...]
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}
[...]

Ora dobbiamo associare il dominio lists.example.com al corretto transport mailman:. Questa operazione è possibile in diversi modi: nel nostro setup non abbiamo configurato i transport di Postfix all'interno del database MySQL degli utenti virtuali, quindi procederemo con la configurazione attraverso un file di testo.
Iniziamo con introdurre la direttiva seguente nella configurazione di Postfix: 

# postconf -e 'transport_maps = hash:/etc/postfix/transport'

Quindi creiamo il file 

# nano /etc/postfix/transport

e diamogli il contenuto: 

lists.example.com      mailman:

Creiamo l'hash del file: 

# postmap -v /etc/postfix/transport

e riavviamo Postfix: 

# /etc/init.d/postfix restart

Creazione della prima lista

Prima di avviare Mailman, è necessario creare una lista chiamata mailman; è obbligatoria, senza di questa Mailman non partirà: 

# newlist --urlhost=lists.example.com --emailhost=lists.example.com mailman

Solitamente gli switch --urlhost e --emailhost non sono necessari, dal momento che abbiamo già configurato il file /etc/mailman/mm_cfg.py, ma per sicurezza sono solito indicarli esplicitamente.
Dovremo rispondere ad alcune domande: 

Enter the email of the person running the list: <-- Indicare l'amministratore della lista, ad esempio amministratore@example.com
Initial mailman password: <-- La password per amministrare la lista

Prima di poter utilizzare la lista dovremo modificare il file /etc/aliases come indicato da Mailman, cioè aggiungendo le seguenti linee: 

## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

Infine premiamo Enter e chiudiamo la procedura di creazione della lista: 

Hit enter to notify mailman owner... <-- ENTER

Apriamo quindi /etc/aliases e modifichiamolo come suggerito: 

# nano /etc/aliases

[...]
## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

Quindi aggiorniamo la configurazione degli alias e riavviamo Postfix: 

# newaliases
# /etc/init.d/postfix restart

Ora siamo pronti per avviare Mailman: 

# /etc/init.d/mailman start

Amministrazione di Mailman

Da questo momento possiamo amministrare le liste attraverso l'interfaccia web di Mailman, raggiungibile all'indirizzo: 

 http://lists.example.com/admin

Creazione di nuove liste

Possiamo creare nuove mailing list con questa procedura: 

# newlist --urlhost=lists.example.com --emailhost=lists.example.com testlist2

Enter the email of the person running the list: <-- amministratore2@example.com
Initial testlist2 password: <-- Password dell'amministratore
To finish creating your mailing list, you must edit your /etc/aliases (or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:

## testlist2 mailing list
testlist2:              "|/var/lib/mailman/mail/mailman post testlist2"
testlist2-admin:        "|/var/lib/mailman/mail/mailman admin testlist2"
testlist2-bounces:      "|/var/lib/mailman/mail/mailman bounces testlist2"
testlist2-confirm:      "|/var/lib/mailman/mail/mailman confirm testlist2"
testlist2-join:         "|/var/lib/mailman/mail/mailman join testlist2"
testlist2-leave:        "|/var/lib/mailman/mail/mailman leave testlist2"
testlist2-owner:        "|/var/lib/mailman/mail/mailman owner testlist2"
testlist2-request:      "|/var/lib/mailman/mail/mailman request testlist2"
testlist2-subscribe:    "|/var/lib/mailman/mail/mailman subscribe testlist2"
testlist2-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe testlist2"

Hit enter to notify testlist2 owner... <-- ENTER

Quindi modifichiamo: 

# nano /etc/aliases

aggiungendo 

[...]
## testlist2 mailing list
testlist2:              "|/var/lib/mailman/mail/mailman post testlist2"
testlist2-admin:        "|/var/lib/mailman/mail/mailman admin testlist2"
testlist2-bounces:      "|/var/lib/mailman/mail/mailman bounces testlist2"
testlist2-confirm:      "|/var/lib/mailman/mail/mailman confirm testlist2"
testlist2-join:         "|/var/lib/mailman/mail/mailman join testlist2"
testlist2-leave:        "|/var/lib/mailman/mail/mailman leave testlist2"
testlist2-owner:        "|/var/lib/mailman/mail/mailman owner testlist2"
testlist2-request:      "|/var/lib/mailman/mail/mailman request testlist2"
testlist2-subscribe:    "|/var/lib/mailman/mail/mailman subscribe testlist2"
testlist2-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe testlist2"

Infine: 

# newaliases
# /etc/init.d/postfix restart

Credits

Questa guida è basata sull'originale di Christoph Haas pubblicata sul sito Workaround.org.



Guida scritta da: Ferdybassi 22:22, 2 apr 2011 (CEST) Swirl-auth40.png Debianized 40%
Estesa da:
Verificata da:
risca 10:52, 6 apr 2014 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Internet_Service_Provider_con_Debian&oldid=40745"