Guide@Debianizzati.Org

Internet Service Provider con Debian: differenze tra le versioni

Pagina Discussione

Internet Service Provider con Debian (visualizza wikitesto)

Versione delle 08:38, 31 mar 2016

40 706 byte aggiunti ,  31 mar 2016
nessun oggetto della modifica
Nessun oggetto della modifica
 
(150 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Lenny|Squeeze}}
{{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 10: Riga 12:


== Prerequisiti ==
== Prerequisiti ==
{{Warningbox|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 [http://it.wikipedia.org/wiki/FQDN Wikipedia]).<br/>
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 [http://it.wikipedia.org/wiki/FQDN Wikipedia]).<br/>
Si configuri il file <code>/etc/apt/sources.list</code> in modo che contenga solo i repository ufficiali (vedi [http://guide.debianizzati.org/index.php/Categoria:Repository guide sul wiki]) e si aggiorni il server con le ultime patch:
Si configuri il file <code>/etc/apt/sources.list</code> in modo che contenga solo i [[repository ufficiali]] (vedi [[:Categoria:Repository|guide sul wiki]]) e si aggiorni il server con le ultime patch:
<pre>
<pre>
# apt-get update
# apt-get update
Riga 18: 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 ===
Un ambiente LAMP è un acronimo per indicare un ambiente composto da '''L'''inux + '''A'''pache + '''M'''ySQL + '''P'''HP. 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]].<br/>
Un ambiente LAMP è un acronimo per indicare un ambiente composto da '''L'''inux + '''A'''pache + '''M'''ySQL + '''P'''HP. 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]].<br/>
'''''Nota''''': il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.
'''''Nota''''': il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.


== Installazione Virtual Host di Apache ==
=== 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.<br/>
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.<br/>
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]].<br/>
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]].<br/>
'''''Nota''''': il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.
'''''Nota''''': il resto della guida sarà basato sulla precedente configurazione, si consiglia quindi di annotare le eventuali modifiche apportate.


== Protezione del web server Apache ==
=== 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]].
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]].
<br/>
<br/>
Riga 38: Riga 41:
[[Impedire attacchi SSH brute-force con Denyhosts]]
[[Impedire attacchi SSH brute-force con Denyhosts]]


== Configurazione dei record DNS ==
=== 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 <code>1.2.3.4</code>) è necessario configurare i ''record DNS'' di ogni dominio in questo modo:
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 <code>1.2.3.4</code>) è necessario configurare i ''record DNS'' di ogni dominio in questo modo:
<pre>
<pre>
Riga 48: Riga 51:
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'').
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 ==
=== 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]].
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 ==
== Installazione del server di posta ==
Riga 56: Riga 59:
* ''Postfix'' per inviare e ricevere mail da internet e effettuare i primi controlli basilari
* ''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
* ''Dovecot'' per archiviare le mail sul server e fornire agli utenti accesso alle loro caselle tramite POP3 e IMAP
* ''Squirrelmail'' come interfaccia Webmail
* ''Roundcube'' come interfaccia Webmail
* ''MySQL'' come database backend per archiviare informazioni su domini, account utente e email forwarding
* ''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
* ''AMaViS'' per effetuare la scansione delle mail in arrivo utilizzando ClamAV e SpamAssassin
Riga 106: Riga 109:
Incominciamo con l'installare il server Postfix con la sua estensione per il supporto a MySQL:
Incominciamo con l'installare il server Postfix con la sua estensione per il supporto a MySQL:
<pre>
<pre>
# aptitude install postfix-mysql
# aptitude install postfix postfix-mysql
</pre>
</pre>
Questo comando installerà automaticamente anche il pacchetto <code>postfix</code> e rimuoverà ''Exim'', il mail server installato di default da Debian.
Questo comando installerà automaticamente anche il pacchetto <code>postfix</code> e rimuoverà ''Exim'', il mail server installato di default da Debian.
Riga 112: Riga 115:
Quando richiesti dall'installer di Postfix, scegliete "Sito internet" come tipo di configurazione e inserite il FQDN (Fully Qualified Domain Name) del vostro server.
Quando richiesti dall'installer di Postfix, scegliete "Sito internet" come tipo di configurazione e inserite il FQDN (Fully Qualified Domain Name) del vostro server.
<br/>
<br/>
Rimuoviamo poi i resti di Exim eventualmente rimasti nel sistema:
<pre>
# apt-get --purge remove 'exim4*'
</pre>
Poichè intendiamo offrire ai nostri utenti anche i servizi POP3 e IMAP dobbiamo installare il demone Dovecot:
Poichè intendiamo offrire ai nostri utenti anche i servizi POP3 e IMAP dobbiamo installare il demone Dovecot:
<pre>
<pre>
# aptitude install dovecot-pop3d dovecot-imapd
# apt-get install dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-managesieved
</pre>
</pre>
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 <code>/etc/apt/sources.list</code> aggiungendo la sezione '''non-free''':
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 <code>/etc/apt/sources.list</code> aggiungendo la sezione '''non-free''':
<pre>
<pre>
deb http://ftp.debian.org/debian/ lenny main contrib non-free
deb http://ftp.debian.org/debian/ wheezy main contrib non-free
</pre>
</pre>
Aggiorniamo la lista dei pacchetti disponibili:
Aggiorniamo la lista dei pacchetti disponibili:
Riga 130: Riga 137:
AMaViS è ora installato nel nostro sistema, insieme a una serie di pacchetti per la scansione delle email.
AMaViS è ora installato nel nostro sistema, insieme a una serie di pacchetti per la scansione delle email.
<br/>
<br/>
Dato che vogliamo offrire anche un servizio di Webmail, installeremo anche il pacchetto Squirrelmail:
Dato che vogliamo offrire anche un servizio di Webmail, installeremo anche il pacchetto Roundcube:
<pre>
# apt-get install roundcube roundcube-plugins
</pre>
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
<br/>
Infine installiamo il client mail Pop3 / Imap <code>mutt</code>, che funziona da console e che può essere utile per testare la nostra configurazione strada facendo
<pre>
# aptitude install mutt
</pre>
e un tool preziosissimo, SWAKS (SWiss Army Knife for Smtp):
<pre>
# apt-get install swaks
</pre>
<br/>
<br/>
{{Warningbox|DEPRECATO: al posto di Squirrelmail è possibile installare una diversa interfaccia webmail, Roundcube:}}
<pre>
<pre>
# aptitude install squirrelmail
# aptitude install squirrelmail
Riga 150: Riga 177:
ma la soluzione proposta da aptitude è corretta; rispondiamo quindi con Y alla domanda.
ma la soluzione proposta da aptitude è corretta; rispondiamo quindi con Y alla domanda.
<br/>
<br/>
Infine installiamo il client mail Pop3 / Imap <code>mutt</code>, che funziona da console e che può essere utile per testare la nostra configurazione strada facendo
<br/>
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>
<pre>
# aptitude install mutt
# chmod 600 /etc/ssl/private/mailserver.pem
</pre>
</pre>
Ora che tutti i pacchetti base sono stati installati, è tempo di preparare il database di appoggio.


=== Preparazione del database ===
=== Preparazione del database ===
Riga 284: 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 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/>
Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura:
Adesso dobbiamo fare in modo che Postfix utilizzi questa mappatura:
<pre>
<pre>
Riga 364: Riga 400:
dbname = mailserver
dbname = mailserver
query = SELECT destination FROM virtual_aliases WHERE source='%s'
query = SELECT destination FROM virtual_aliases WHERE source='%s'
</pre>
Assicuriamoci che Postfix utilizzi questa mappatura:
<pre>
# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf
</pre>
</pre>
e verifichiamo che tutto funzioni correttamente:
e verifichiamo che tutto funzioni correttamente:
Riga 404: Riga 444:
Iniziamo con l'aggiungere le seguenti linee al file:
Iniziamo con l'aggiungere le seguenti linee al file:
<pre>
<pre>
# nano /etc/postfix/main.cf:
# nano /etc/postfix/main.cf
</pre>
</pre>
<pre>
<pre>
Riga 416: Riga 456:
con contenuto:
con contenuto:
<pre>
<pre>
user = mailserver
user = mailuser
password = password
password = mailuser2009
hosts = 127.0.0.1
hosts = 127.0.0.1
dbname = mailserver
dbname = mailserver
Riga 427: Riga 467:
</pre>
</pre>
Dovremmo ottenere come risultato il nostro indirizzo email o i nostri alias, a seconda di come abbiamo configurato l'utente.<br/>
Dovremmo ottenere come risultato il nostro indirizzo email o i nostri alias, a seconda di come abbiamo configurato l'utente.<br/>
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.
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 ====
==== Protezione dei file di configurazione ====
Riga 444: 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 450: 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 476: Riga 516:
# chmod u+w /var/vmail
# chmod u+w /var/vmail
</pre>
</pre>
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in <code>/etc/dovecot</code>. Inziamo con il file principale.
Siamo pronti per iniziare. I files di configurazione di Dovecot si trovano in <code>/etc/dovecot</code>.
<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 <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>
!include conf.d/*.conf
</pre>
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.


==== /etc/dovecot/dovecot.conf ====
==== Fino a Debian Squeeze ====
Inziamo con il file principale.
 
===== /etc/dovecot/dovecot.conf =====


Cerchiamo la linea <code>protocols</code> e definiamo i protocolli che vogliamo offrire agli utenti. Di default troveremo:
Cerchiamo la linea <code>protocols</code> e definiamo i protocolli che vogliamo offrire agli utenti. Di default troveremo:
Riga 519: Riga 568:
</pre>
</pre>
che indica a Dovecot dove sono situate tutte le mailboxes.
che indica a Dovecot dove sono situate tutte le mailboxes.
<br/>
Ricordiamoci anche di commentare l'autenticazione pam, disabilitandola, dato che non utilizzeremo questo tipo di password check:
<pre>
# passdb pam {
# Commentare tutte le linee
# }
</pre>
<br/>
<br/>
L'utente viene autenticato attraverso la sezione <code>passdb sql</code> section, dopo di che viene indirizzato alla mailbox secondo le direttive della voce <code>userdb static</code>. Utilizzare la direttiva <code>userdb sql</code> non è necessario dato che tutte le mailboxes hanno un percorso fisso.
L'utente viene autenticato attraverso la sezione <code>passdb sql</code> section, dopo di che viene indirizzato alla mailbox secondo le direttive della voce <code>userdb static</code>. Utilizzare la direttiva <code>userdb sql</code> non è necessario dato che tutte le mailboxes hanno un percorso fisso.
Riga 612: Riga 668:
</pre>
</pre>


=== Test della configurazione ===
==== Da Debian Wheezy ====
 
Diamo uno sguardo ai file presenti nella directory di configurazione ''conf.d''.
==== Invio di email tramite telnet ====


Installiamo innanzitutto il pacchetto telnet:
===== 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:
<pre>
<pre>
# aptitude install telnet
auth_mechanisms = plain login
</pre>
</pre>
Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server:
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:
<pre>
<pre>
# telnet localhost smtp
#!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
</pre>
</pre>
Dovremmo ottenere come risposta:
 
===== auth-sql.conf.ext =====
Modifichiamo ora il file di configurazione SQL.
<br/>
Commentiamo la sezione standard "userdb" e aggiungiamo:
<pre>
<pre>
Trying 127.0.0.1...
userdb {
Connected to localhost.
  driver = static
Escape character is '^]'.
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n
220 mailtest ESMTP Postfix (Debian/GNU)
}
</pre>
</pre>
Ottimo. Postfix è funzionante e possiamo proseguire nella sessione di invio della mail:
Attenzione: deve esserci attiva una sola sezione "userdb".
<br/>
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
<pre>
<pre>
ehlo example.com
mail_location = maildir:/var/vmail/%d/%n/Maildir
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
</pre>
</pre>
Un controllo al file di log <code>/var/log/mail.log</code> dovrebbe confermarci che la mail è stata correttamente inviata:
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/>
Cambiamo la direttiva ''auth_socket_path'' in
<pre>
<pre>
postfix/smtpd[...]: connect from localhost[127.0.0.1]
auth_socket_path = /var/run/dovecot/auth-master
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]
</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.
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>
separator = .
</pre>
per mantenere la retrocompatibilità della configurazione.


==== Controllo della mailbox dell'utente ====
===== 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.


E' il momento di verificare la corretta ricezione della mail:
===== 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>
<pre>
$ cd /var/vmail/example.com/john/Maildir
ssl_cert = </etc/ssl/certs/mailserver.pem
$ find
ssl_key = </etc/ssl/private/mailserver.pem
.
</pre>
./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
===== 15-lda.conf =====
To: undisclosed-recipients: ;
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>
protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}
</pre>


Hi John,
===== /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:
just wanted to drop you a note.
<pre>
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>
La mail è arrivata correttamente. Premiamo <code>q</code> due volte per uscire da <code>mutt</code>.
ponendo attenzione a inserire le credenziali MySQL create in precedenza.


==== Test del server POP3 ====
===== Protezione dei file =====
Impostiamo le giuste credenziali per il file di configurazione principale:
<pre>
# chgrp vmail /etc/dovecot/dovecot.conf
# chmod g+r /etc/dovecot/dovecot.conf
</pre>
per lo spool di Postfix:
<pre>
# chown postfix:postfix /var/spool/postfix/private/auth
# chmod 666 /var/spool/postfix/private/auth
</pre>
e proteggiamo il file di configurazione SQL in modo che nessuno possa scoprire la password del database:
<pre>
# chown root:root /etc/dovecot/dovecot-sql.conf.ext
# chmod go= /etc/dovecot/dovecot-sql.conf.ext
</pre>
Infine riavviamo Dovecot:
<pre>
# service dovecot restart
</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>


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.
=== Test della configurazione ===
<br/>
Apriamo un altro terminale e controlliamo i log della posta in tempo reale:
Stabiliamo una connessione POP3 con il nostro server:
<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>
 
==== Invio di email tramite telnet ====
 
Installiamo innanzitutto il pacchetto telnet:
<pre>
# aptitude install telnet
</pre>
Poi stabiliamo una connessione TCP sulla porta SMTP del nostro server:
<pre>
# telnet localhost smtp
</pre>
Dovremmo ottenere come risposta:
<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
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
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 781: 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/>
<pre>
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.
$ mutt -f imaps://john@example.com@localhost
<br/>
</pre>
Per verificare il corretto funzionamento del server IMAP possiamo utilizzare il client ''mutt'':
Dovecot all'atto dell'installazione genera un certificato self-signed. Potete decidere di utiizzarlo, oppure di generarne un secondo personalizzato:
<pre>
<pre>
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
$ mutt -f imap://john@example.com@localhost
    -keyout /etc/ssl/private/dovecot.pem
</pre>
</pre>
Durante la generazione del certificato vi saranno poste alcune domande:
Oppure, in alternativa, aprire una connessione IMAP attraverso telnet:
<pre>
<pre>
Generating a 1024 bit RSA private key
$ telnet localhost imap2
.........++++++
Trying 127.0.0.1...
............................++++++
Connected to localhost.
writing new private key to '/etc/ssl/certs/dovecot.pem'
Escape character is '^]'.
-----
* OK Dovecot ready.
Country Name (2 letter code) [AU]:DE
1 login john@example.com summersun
State or Province Name (full name) [Some-State]:Hamburg
1 OK Logged in.
Locality Name (eg, city) []:Hamburg
2 list "" "*"
Organization Name (eg, company) [Internet Widgits Pty Ltd]:workaround email service
* LIST (\HasNoChildren) "." "INBOX"
Organizational Unit Name (eg, section) []:
2 OK List completed.
Common Name (eg, YOUR name) []:mailtest.workaround.org
3 select "INBOX"
Email Address []:postmaster@workaround.org
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
</pre>
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
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).
* 1 EXISTS
<br/>
* 0 RECENT
Infine impostiamo i corretti permessi sul file certificato:
* OK [UIDVALIDITY 1180039205] UIDs valid
<pre>
* OK [UIDNEXT 3] Predicted next UID
# chmod o= /etc/ssl/private/dovecot.pem
3 OK [READ-WRITE] Select completed.
</pre>
4 fetch 1 all
e riavviamo Dovecot per fargli prendere il nuovo certificato:
* 1 FETCH (FLAGS (\Seen) INTERNALDATE .........
<pre>
4 OK Fetch completed.
# /etc/init.d/dovecot restart
5 fetch 1 body[]
</pre>
* 1 FETCH (BODY[] {474}
 
Return-Path: <steve@example.com>
=== Autenticazione su SMTP ===
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:;


==== Open relays server ====
Hi John,


Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:
just wanted to drop you a note.
* 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
5 OK Fetch completed.
* il mittente si è autenticato sul server
6 logout
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''.
* BYE Logging out
6 OK Logout completed.
</pre>


==== Configurazione di Postfix per l'autorizzazione SMTP====
==== Test dei server POP3s e IMAPs ====


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>:
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'':
<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/>
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>
<pre>
# postconf -e smtpd_sasl_type=dovecot
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \
# postconf -e smtpd_sasl_path=private/auth
    -keyout /etc/ssl/private/dovecot.pem
# 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
Durante la generazione del certificato vi saranno poste alcune domande:
* <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
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/>
Infine impostiamo i corretti permessi sul file certificato:
<pre>
# chmod o= /etc/ssl/private/dovecot.pem
</pre>
e riavviamo Dovecot per fargli prendere il nuovo certificato:
<pre>
# /etc/init.d/dovecot restart
</pre>
</pre>


==== Test della configurazione ====
=== Autenticazione su SMTP ===
 
==== Open relays server ====


Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:
Normalmente Postfix accetta una email solo se è verificato uno di questi criteri:
<pre>
* il destinatario è un utente del mail server
$ telnet localhost smtp
* il mittente sta inviando la mail dal nostro local network, definito dalla direttiva <code>mynetworks</code> di Postfix
Trying 127.0.0.1...
* il mittente si è autenticato sul server
Connected to localhost.
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''.
Escape character is '^]'.
 
220 mailtest ESMTP Postfix (Debian/GNU)
==== Configurazione di Postfix per l'autorizzazione SMTP====
ehlo example.com
 
250-mailtest
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>:
250-PIPELINING
<pre>
250-SIZE 10240000
# postconf -e mynetworks=192.168.50.0/24
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
</pre>
</pre>
L'autenticazione ha funzionato.
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.
{{Box | Nota |Se abbiamo impostato la password di john a qualcosa di diverso da ''summersun'' dobbiamo ricavarne l'hash Base64 in questo modo:
<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>
<pre>
$> perl -MMIME::Base64 -e \
# postconf -e smtpd_sasl_type=dovecot
    'print encode_base64("john\@example.com\0john\@example.com\0password")';
# 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>
</pre>
}}
* <code>smtpd_sasl_auth_enable</code> abilita l'autenticazione SMTP
Ora possiamo testare l'invio di una mail attraverso il nostro client di posta. Per verificare il corretto funzionamento controlliamo i file di log:
* <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>
<pre>
# tail -f /var/log/mail.log
# /etc/init.d/postfix restart
</pre>
</pre>
Dovremmo trovare qualcosa di simile:
 
==== Test della configurazione ====
 
Proviamo la nostra configurazione con una connessione telnet sulla porta SMTP:
<pre>
<pre>
postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
$ telnet localhost smtp
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
Trying 127.0.0.1...
postfix/qmgr[3963]: 1234567890: from=<john@example.com>, size=830, nrcpt=1 (queue active)
Connected to localhost.
postfix/smtpd[4032]: disconnect from ...
Escape character is '^]'.
postfix/smtp[4041]: 1234567890: to=<devnull@workaround.org>,
220 mailtest ESMTP Postfix (Debian/GNU)
    relay=torf.workaround.org[212.12.58.129]:25, delay=6,
ehlo example.com
    delays=0.09/0.08/5.6/0.23, dsn=2.0.0, status=sent
250-mailtest
    (250 OK id=1HsPC3-0008UJ-O5)
250-PIPELINING
postfix/qmgr[3963]: 2EAE8379CB: removed
250-SIZE 10240000
</pre>
250-VRFY
In caso di errore dovremmo invece vedere qualcosa di simile a questo:
250-ETRN
<pre>
250-ENHANCEDSTATUSCODES
postfix/smtpd[4032]: connect from ...[10.20.30.40]
250-8BITMIME
postfix/smtpd[4032]: warning: ...[10.20.30.40]: SASL PLAIN authentication failed:
250 DSN
postfix/smtpd[4032]: lost connection after AUTH from ...[10.20.30.40]
auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==
postfix/smtpd[4032]: disconnect from ...[10.20.30.40]
235 2.0.0 Authentication successful
quit
221 2.0.0 Bye
</pre>
</pre>
In fase di installazione Postfix genera automaticamente un certificato SSL, ma potrebbe essere utile crearne uno personalizzato, nella stessa maniera vista in precedenza:
L'autenticazione ha funzionato.
{{Box | Nota |Se abbiamo impostato la password di john a qualcosa di diverso da ''summersun'' dobbiamo ricavarne l'hash Base64 in questo modo:
<pre>
<pre>
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
$> perl -MMIME::Base64 -e \
     -keyout /etc/ssl/private/postfix.pem
     'print encode_base64("john\@example.com\0john\@example.com\0password")';
</pre>
</pre>
L'impostazione più importante è la definizione del <code>Common Name</code>, dove va inserito il fully-qualified name (FQDN) del mail server.<br/>
}}
A generazione avvenuta impostiamo i corretti permessi sul file:
Ora possiamo testare l'invio di una mail attraverso il nostro client di posta. Per verificare il corretto funzionamento controlliamo i file di log:
<pre>
<pre>
# chmod o= /etc/ssl/private/postfix.pem
# tail -f /var/log/mail.log
</pre>
</pre>
e comunichiamo a Postfix di utilizzare il nuovo certificato:
Dovremmo trovare qualcosa di simile:
<pre>
<pre>
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
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
</pre>
In caso di errore dovremmo invece vedere qualcosa di simile a questo:
<pre>
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]
</pre>
In fase di installazione Postfix genera automaticamente un certificato SSL, ma potrebbe essere utile crearne uno personalizzato, nella stessa maniera vista in precedenza:
<pre>
# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
    -keyout /etc/ssl/private/postfix.pem
</pre>
L'impostazione più importante è la definizione del <code>Common Name</code>, dove va inserito il fully-qualified name (FQDN) del mail server.<br/>
A generazione avvenuta impostiamo i corretti permessi sul file:
<pre>
# chmod o= /etc/ssl/private/postfix.pem
</pre>
e comunichiamo a Postfix di utilizzare il nuovo certificato:
<pre>
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem
</pre>
</pre>
Riga 954: 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 970: 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>.
<br/>
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file:
<pre>
<pre>
ENABLED=0
# nano /etc/amavis/conf.d/15-content_filter_mode
</pre>
</pre>
in
rimuovendo il commento <code>#</code> dalle linee <code>@bypass_...</code>:
<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/>
Il virus scanner ClamAV è già configurato per default e va solo abilitato modificando il file:
<pre>
# nano /etc/amavis/conf.d/15-content_filter_mode
</pre>
rimuovendo il commento <code>#</code> dalle linee <code>@bypass_...</code>:
<pre>
<pre>
@bypass_virus_checks_maps = (
@bypass_virus_checks_maps = (
Riga 1 037: 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 061: 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 109: 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>
</pre>
 
Testiamo il funzionamento di ClamAV:
=== Amministrare gli utenti virtuali ===
 
====ISPwebAdmin (web interface): introduzione ====
E' disponibile un'interfaccia web per amministrare i domini virtuali, gli utenti virtuali e gli alias. L'interfaccia si chiama ISPWebAdmin ed è disponibile per il download all'indirizzo: [[http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz 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:
<pre>
<pre>
# mysql -p mailserver
# 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>
</pre>
e digitiamo la query:
 
Ora proviamo a inviare una mail infetta attraverso Postfix, per vedere se AMaViS e ClamAV si comportano come ci aspettiamo:
<pre>
<pre>
CREATE TABLE IF NOT EXISTS `admins` (
# swaks -t john@example.org --attach - --server localhost --suppress-data < /usr/share/clamav-testfiles/clam.exe
`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;
</pre>
</pre>
Quindi creiamo un utente amministratore che possa effettuare il login nell'interfaccia web:
 
Tra le altre righe in <code>/var/log/mail.log</code> dovremmo trovare una cosa del genere:
<pre>
<pre>
INSERT INTO mailserver.admins (username,pwhash) VALUES ('john', MD5('doe'));
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>
</pre>
Installiamo e configuriamo alcuni requisiti per l'interfaccia:
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>
<pre>
# aptitude install python-virtualenv
#!/bin/dash
# apt-get build-dep python-mysqldb
[ -d /var/lib/amavis/virusmails ] && {
# su -s /bin/bash vmail
        find /var/lib/amavis/virusmails/. -type f -name 'virus-*' -ctime +7 -de$
cd /var/vmail
        find /var/lib/amavis/virusmails/. -type f -ctime +30 -delete
mkdir ispwebadmin
}
cd ispwebadmin
exit 0
wget http://workaround.org/sites/default/files/ispwebadmin-1.0.2.tar_.gz
virtualenv .
. bin/activate
</pre>
</pre>
A questo punto siamo pronti per effettuare l'installazione dell'interfaccia:
 
<pre>
=== Autenticazione di Postfix su un server SMTP remoto ===
easy_install ispwebadmin*.tar.gz
Se ci fosse la necessità di impostare un relay dal nostro server di posta Postfix verso un server SMTP esterno, è possibile utilizzare questa guida:<br/>
paster make-config ispwebadmin run.ini
[[Postfix_e_autenticazione_su_smtp_remoto| Postfix e autenticazione su SMTP remoto]]
</pre>
 
Il secondo comando creerà un file <code>run.ini</code> 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:
=== Amministrare gli utenti virtuali ===
 
==== GRSoft Mail Manager ====
A questo indirizzo: http://www.grs-service.ch/pub/grs_mminstallation.html è possibile trovare un'interfaccia per la gestione degli account mail. GRSoft Mail Manager è scritto in PHP e non richiede dipendenze per funzionare.
# Scaricate il file e scompattatelo in una sottodirectory di <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 =====
 
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:
<pre>
<pre>
nano run.ini
# mysql -p mailserver
</pre>
</pre>
Ora siamo pronti per avviare la nostra web application:
e digitiamo la query:
<pre>
<pre>
paster serve run.ini
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;
</pre>
</pre>
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.
Quindi creiamo un utente amministratore che possa effettuare il login nell'interfaccia web:
<br/>
Per creare il nuovo servizio utilizzeremo il sistema <code>runit</code> di Debian Lenny:
<pre>
<pre>
# aptitude install runit
INSERT INTO mailserver.admins (username,pwhash) VALUES ('john', MD5('doe'));
# mkdir /etc/sv/ispwebadmin
# cd /etc/sv/ispwebadmin
</pre>
</pre>
Creiamo ora un file <code>/etc/sv/ispwebadmin/run</code>
Installiamo e configuriamo alcuni requisiti per l'interfaccia:
<pre>
<pre>
# nano /etc/sv/ispwebadmin/run
# 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
</pre>
</pre>
contenente:
A questo punto siamo pronti per effettuare l'installazione dell'interfaccia:
<pre>
<pre>
#!/bin/sh
easy_install ispwebadmin*.tar.gz
exec 2>&1
paster make-config ispwebadmin run.ini
echo 'ISPwebAdmin starting.'
cd /var/vmail/ispwebadmin
sudo -u vmail PYTHON_EGG_CACHE=/var/vmail/ispwebadmin/.python-eggs bin/paster serve run.ini
</pre>
</pre>
Rendiamo eseguibile il file:
Il secondo comando creerà un file <code>run.ini</code> 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:
<pre>
<pre>
# chmod u+x /etc/sv/ispwebadmin/run
nano run.ini
</pre>
</pre>
e creiamo il symlink corretto:
Ora siamo pronti per avviare la nostra web application:
<pre>
<pre>
# ln -s /etc/sv/ispwebadmin /etc/service/
paster serve run.ini
</pre>
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.
<br/>
Per creare il nuovo servizio utilizzeremo il sistema <code>runit</code> di Debian Lenny:
<pre>
# aptitude install runit
# mkdir /etc/sv/ispwebadmin
# cd /etc/sv/ispwebadmin
</pre>
Creiamo ora un file <code>/etc/sv/ispwebadmin/run</code>
<pre>
# nano /etc/sv/ispwebadmin/run
</pre>
contenente:
<pre>
#!/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
</pre>
Rendiamo eseguibile il file:
<pre>
# chmod u+x /etc/sv/ispwebadmin/run
</pre>
e creiamo il symlink corretto:
<pre>
# ln -s /etc/sv/ispwebadmin /etc/service/
</pre>
</pre>
Da questo momento il servizio potrà essere utilizzato nel modo seguente:
Da questo momento il servizio potrà essere utilizzato nel modo seguente:
Riga 1 206: 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 218: Riga 1 546:
</pre>
</pre>


=== Un'interfaccia alternativa ===
=== Impostazione dei record DNS ===
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 ===
''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:
''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:
<pre>
<pre>
Riga 1 259: Riga 1 580:
</pre>
</pre>
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.
Per ricevere le mail indirizzate al nostro dominio abbiamo quindi bisogno di un record MX nella nostra zona. Poichè però un record MX può puntare solo a un hostname e non a un indirizzo IP avremo bisogno anche di un record A.
=== SPF per ridurre lo spam ===
=== Guerra allo spam con le Realtime Black Lists (RBL) ===
''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.
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.
<br/>
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 <code>smtpd_recipient_restrictions</code> del vostro <code>/etc/postfix/main.cf</code> diventerà così:
<pre>
<pre>
$> dig +short workaround.org txt
smtpd_recipient_restrictions =
"v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"
  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
</pre>
</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.
Alcune altre utili restrizioni possono essere:
* <code>reject_unknown_client_hostname</code>: esegue una doppia verifica DNS tra l'IP e l'hostname del mittente
* <code>reject_unknown_sender_domain</code>: controlla se il dominio del mittente esiste reralmente. Per effettuare la verifica esegue un controllo sui record MX e A del dominio del mittente
* <code>reject_unauth_pipelining</code>: 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.
<br/>
<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:
Innanzitutto aggiungiamo la sezione:
* impostare un record TXT nella nostra zona per definire quali indirizzi IP sono autorizzati a inviare mail a nome nostro
<pre>
* controllare le voci SPF dei server mittenti e respingere la mail in arrivo da IP non autorizzati
smtpd_client_restrictions =
 
      permit_mynetworks
==== Impostare una voce SPF ====
      check_client_access hash:/etc/postfix/access
 
      permit
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.
</pre>
<br/>
prima della sezione:
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:
<pre>
<pre>
# apt-get install tumgreyspf
smtpd_recipient_restrictions
</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>. A esempio:
Quindi creiamo il file contenente la lista dei domini da bloccare o da autorizzare senza ulteriori controlli:
<pre>
<pre>
smtpd_recipient_restrictions =
# nano /etc/postfix/access
    permit_mynetworks,
</pre>
    permit_sasl_authenticated,
e riempiamolo con la nostra lista:
    [ ... ]
<pre>
    check_policy_service unix:private/tumgreyspf
yahoo.com.tw REJECT
    [ ... ]
hinet.com REJECT
    permit
pchome.com.tw REJECT
yahoo.co.jp REJECT
yam.com REJECT
inet.net REJECT
ferdy.it OK
</pre>
In questo caso abbiamo bloccato alcuni domini e autorizzato il dominio ferdy.it a inviarci mail senza nessun ulteriore controllo.
<br/>
Inseriamo alcuni ulteriori controlli sull'header e sul body della mail, aggiungendo la sezione:
<pre>
# 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>
Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file <code>/etc/postfix/master.cf</code>:
<pre>
<pre>
tumgreyspf unix  -      n      n      -      -      spawn
/^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/
    user=tumgreyspf argv=/usr/bin/tumgreyspf
REJECT IFRAME vulnerability exploit
</pre>
</pre>
Ora riavviamo Postfix:
Quindi facciamo in modo che Postfix si crei il database relativo:
<pre>
<pre>
# postfix reload
# postmap /etc/postfix/access
</pre>
</pre>
Questo comando andrà ripetuto ad ogni modifica del file.
==== Un esempio di main.cf ====
<pre>
###############################
# Configurazioni iniziali
###############################
# Messaggio di benvenuto
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no


==== Verifica del funzionamento di SPF ====
# 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


===== SPF okay =====


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.


===== SPF fail =====
######################################
# Configurazione
######################################


Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere:
myhostname = mail01.xxxxx.org
<pre>
alias_maps = hash:/etc/aliases
tumgreyspf[24672]: SPF fail - not authorized: QUEUE_ID=""; identity=mailfrom;
alias_database = hash:/etc/aliases
  client-ip=41.234.18.141; helo=gmx.de;
myorigin = /etc/mailname
  envelope-from=…gmx.de;
mydestination = mail01.xxxxx.org, localhost.xxxxx.org, , localhost.xxxxxyy.com, localhost
  receiver=…christoph-haas.de;
relayhost =
</pre>
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/24
La mail è stata respinta.
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
queue_directory = /var/spool/postfix


===== 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:
<pre>
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
</pre>
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>
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>
In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.


===== No SPF information =====
#######################################
# 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
 
 


Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere:
###################
<pre>
# Regole Antispam
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 ===
# Verifico correttezza header e body
header_checks = pcre:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks


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.
# Abilito a spedire solo gli utenti presenti in MySQL
<br/>
smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cf
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.


==== Debian Lenny ====
# Restrizioni helo
===== Lenny: Attivare il plugin quota di Dovecot =====
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


Ci sono tre punti nel file <code>/etc/dovecot/dovecot.conf</code> dove occorre specificare l'abilitazione del plugin:
# Restrizioni sui mittenti abilitati
<pre>
smtpd_sender_restrictions =
protocol imap {
        permit_mynetworks
  mail_plugins = quota imap_quota
        permit_sasl_authenticated
}
        #reject_unknown_address
protocol pop3 {
        #reject_unauth_destination
  mail_plugins = quota
        reject_unauth_pipelining
}
reject_unknown_sender_domain
protocol lda {
reject_non_fqdn_sender
  mail_plugins = quota
reject_sender_login_mismatch
}
 
</pre>
# 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


===== 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>
plugin {
  quota = maildir:storage=1000000:messages=1000
}
</pre>
ricordando che i valori per lo storage sono espressi in KB.


===== Lenny: Impostare una quota utente =====
#########################
# Configurazione Dovecot
#########################


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:
virtual_transport = dovecot
<pre>
dovecot_destination_recipient_limit = 1
mysql>
smtpd_sasl_type = dovecot
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
smtpd_sasl_path = private/auth
ADD `quota_messages` INT NOT NULL ;
smtpd_sasl_auth_enable = yes
</pre>
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>
#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>
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 =====


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".
###############################
# Integrazione con AMaViS
###############################


==== Debian Squeeze ====
content_filter = smtp-amavis:[127.0.0.1]:10024
A partire da Dovecot 1.1, di default su Squeeze, la gestione delle quote è cambiata notevolmente.
receive_override_options = no_address_mappings
</pre>


===== Squeeze: Impostazione delle Quote root =====
=== SPF per ridurre ancora di più lo spam ===
Dobbiamo innanzitutto aprire il file di configurazione di Dovecot:
''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>
# nano /etc/dovecot/dovecot.conf
$> dig +short workaround.org txt
"v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"
</pre>
</pre>
recarci alla sezione <code>plugin { }</code> e definire le quote root. Ad esempio:
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 ====
 
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.
<br/>
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:
<pre>
<pre>
plugin {
# apt-get install tumgreyspf
  quota = maildir:User quota
  #quota2 = fs:Disk quota
  #quota3 = ...
}
</pre>
</pre>
In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.
<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: Quote rules =====
A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota:
<pre>
<pre>
plugin {
smtpd_recipient_restrictions =
  # Quota root
    permit_mynetworks,
  quota = maildir:User quota
    permit_sasl_authenticated,
  # Quote rules
    [ ... ]
  # 1 - Dimensione massima 2 GB
    check_policy_service unix:private/tumgreyspf
  quota_rule = *:storage=2GB
    reject_unauth_destination
  # 2 - Dimensione Cestino 200 MB
  quota_rule2 = Trash:storage=200MB
  # 3 - Dimensione cartella Spam 200MB
  quota_rule3 = Spam:storage=200MB
}
</pre>
</pre>
===== Squeeze: Cosa succede se un utente supera la quota =====
Per definire il programma chiamato dalle policies occorre anche aggiungere due righe al file <code>/etc/postfix/master.cf</code>:
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 {
tumgreyspf unix  -      n      n      -      -      spawn
  quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
    user=tumgreyspf argv=/usr/bin/tumgreyspf
</pre>
</pre>
 
Ora riavviamo Postfix:
===== 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 {
# postfix reload
  quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95
  quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80
}
</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%.
 
<br/>
==== Verifica del funzionamento di SPF ====
Lo script va creato a mano:
 
===== SPF okay =====
 
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>
<pre>
# nano /usr/local/bin/quota-warning.sh
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>
</pre>
con contenuto:
Questo significa che il mittente <code>…@squ.edu.om</code> è stato autorizzato all'invio della mail dopo un controllo dei record SPF.
<pre>
#!/bin/sh


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


echo "From: $FROM
Se il controllo SPF fallisce dovremmo ottenere qualcosa del genere:
To: $USER
<pre>
To: postmaster@domain.org
tumgreyspf[24672]: SPF fail - not authorized: QUEUE_ID=""; identity=mailfrom;
Subject: Hai raggiunto il $PERCENT% del tuo spazio su disco!
  client-ip=41.234.18.141; helo=gmx.de;
Content-Type: text/plain; charset="UTF-8"
  envelope-from=…gmx.de;
  receiver=…christoph-haas.de;
</pre>
La mail è stata respinta.


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


cat $qwf | /usr/sbin/sendmail -f $FROM "$USER"
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:
rm -f $qwf
<pre>
 
tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID="";
exit 0
  identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au;
  envelope-from=…@rollouts.com; receiver=…@workaround.org
</pre>
</pre>
Rendiamo lo script eseguibile:
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>
# chmod 750 /usr/local/bin/quota-warning.sh
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>
e siamo a posto.
In questo modo il mail client dell'utente finale può ancora filtrare la mail come spam.


=== Accesso tramite Webmail ===
===== No SPF information =====
==== Squirrelmail ====
 
Questo passaggio è facoltativo, ma ormai praticamente tutti i provider offrono ai loro utenti un mezzo per poter controllare le email da un browser.
Se il dominio remoto non ha record SPF, nei nostri log risulterà qualcosa del genere:
<br/>
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/>
Per impostarlo dobbiamo inannzitutto aggiungere la sua configurazione a quella di Apache:
<pre>
<pre>
$> ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf
Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom;
$> apache2ctl restart
  client-ip=80.65.65.222; helo=mail.unze.ba;
  envelope-from=…@gmail.com; receiver=…@christoph-haas.de;
</pre>
</pre>
Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail:
 
<pre>
=== Quote ===
$> squirrelmail-configure
 
</pre>
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.
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/>
<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.
La configurazione delle quote cambia a seconda che si stia utilizzando Debian Lenny o Debian Squeeze.


==== Roundcube ====
==== Debian Lenny ====
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: Attivare il plugin quota di Dovecot =====
* '''Lenny''':
 
Ci sono tre punti nel file <code>/etc/dovecot/dovecot.conf</code> dove occorre specificare l'abilitazione del plugin:
<pre>
<pre>
# apt-get -t lenny-backports install roundcube
protocol imap {
  mail_plugins = quota imap_quota
}
protocol pop3 {
  mail_plugins = quota
}
protocol lda {
  mail_plugins = quota
}
</pre>
</pre>
* '''Squeeze''':
 
===== 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 roundcube
plugin {
  quota = maildir:storage=1000000:messages=1000
}
</pre>
</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à.
ricordando che i valori per lo storage sono espressi in KB.
<br/>
 
Ora modifichiamo il file di configurazione:
===== 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>
# nano /etc/roundcube/main.inc.php
mysql>
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
ADD `quota_messages` INT NOT NULL ;
</pre>
</pre>
modificando la linea:
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>
$rcmail_config['default_host'] = 'localhost';
#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>
Quindi modifichiamo il file che definisce il Virtual Host di Roundcube:
Infine dovremo aggiungere al file <code>/etc/dovecot/dovecot-sql.conf</code> la linea:
<pre>
<pre>
# nano /etc/roundcube/apache.conf
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>
e decommentiamo le linee:
 
<pre>
===== Lenny: Cosa succede se un utente supera la quota =====
    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
 
    Alias /roundcube /var/lib/roundcube
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".
</pre>
 
Installiamo i driver MDB2:
==== 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>
# pear install MDB2_Driver_mysql
# nano /etc/dovecot/dovecot.conf
</pre>
</pre>
Riavviamo Apache:
recarci alla sezione <code>plugin { }</code> e definire le quote root. Ad esempio:
<pre>
<pre>
/etc/init.d/apache2 restart
plugin {
  quota = maildir:User quota
  #quota2 = fs:Disk quota
  #quota3 = ...
}
</pre>
</pre>
e facciamo login nella nostra webmail all'indirizzo: <code>http:// your-domain/roundcube</code>
In questa guida utilizzeremo solamente una gestione delle quote legata alle dimensioni delle maildir.


=== Filtri server-side: Sieve ===
===== Squeeze: Quote rules =====
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.
A questo punto, nella stessa sezione del file di configurazione possiamo definire le nostre regole di quota:
<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".
<br/>
Iniziamo creando un file di configurazione per Sieve:
<pre>
<pre>
# nano /var/vmail/globalsieverc
plugin {
</pre>
  # Quota root
contenente:
  quota = maildir:User quota
<pre>
  # Quote rules
require ["fileinto"];
  # 1 - Dimensione massima 2 GB
# Move spam to spam folder
  quota_rule = *:storage=2GB
if header :contains "X-Spam-Flag" ["YES"] {
  # 2 - Dimensione Cestino 200 MB
   fileinto "spam";
  quota_rule2 = Trash:storage=200MB
  stop;
  # 3 - Dimensione cartella Spam 200MB
   quota_rule3 = Spam:storage=200MB
}
}
</pre>
</pre>
e verifichiamo che sia leggibile dall'utente <code>vmail</code>:
===== 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>
# chown vmail /var/vmail/globalsieverc
plugin {
  quota_exceeded_message = Spazio su disco esaurito. Contattare il webmaster per ricevere istruzioni.
</pre>
</pre>
Quindi modifichiamo la configurazione di Dovecot e inseriamo un plugin per il global filtering delle mail:
 
===== 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>
# nano /etc/dovecot/dovecot.conf
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>
cercando la sezione <code>plugin { }</code> e inserendo:
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%.
<br/>
Lo script va creato a mano:
<pre>
<pre>
sieve_global_path = /var/vmail/globalsieverc
# nano /usr/local/bin/quota-warning.sh
</pre>
</pre>
Riavviamo Dovecot:
con contenuto:
<pre>
<pre>
# /etc/init.d/dovecot restart
#!/bin/sh
</pre>
 
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


==== Test del filtro antispam ====
exit 0
Inviamo al nostro utente una mail di spam:
<pre>
# sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt
</pre>
</pre>
Nei log di Doecot dovremmo trovare una linea simile alla seguente:
Rendiamo lo script eseguibile:
<pre>
<pre>
deliver(john@example.com): 2009-07-01 01:00:22 Info: msgid=<GTUBE1.1010101@example.net>: saved mail to spam
# chmod 750 /usr/local/bin/quota-warning.sh
</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:
e siamo a posto.
# sottoscrivere manualmente anche il folder "Spam"
# 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 ====
==== Debian Wheezy ====
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>.
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>.


=== Managesieve client ===
=== Accesso tramite Webmail ===
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:
==== 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/>
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/>
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>
Inoltre dobbiamo variare un parametro; lo facciamo utilizzando il tool di configurazione di Squirrelmail:
<pre>
<pre>
# aptitude install avelsieve
$> squirrelmail-configure
</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:
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>
Could not log on to timsieved daemon on your IMAP server localhost:4190
/usr/share/squirrelmail/plugins
</pre>
</pre>
Il plugin avelsieve si è messo in ascolto sulla porta sbagliata... Apriamo il suo file di configurazione:
e scompattiamolo:
<pre>
<pre>
# nano /usr/share/squirrelmail/plugins/avelsieve/config/config.php
# tar zxvf change_sqlpass-3.3-1.2.tar.gz
</pre>
</pre>
e modifichiamo come segue la sezione incriminata:
Prima di modificarne la configurazione dobbiamo compiere alcune operazioni propedeutiche:
<pre>
<pre>
/* ======================================================================== */
# apt-get install php-mdb2 squirrelmail-compatibility
/* =================== ManageSieve Backend Options ======================== */
# pear install DB
/* ======================================================================== */
</pre>
/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */
Ora siamo pronti per configurare il plugin appena scaricato:
 
<pre>
/** DEBIAN CHANGE: Despite upstream's intention Debian changed this default
# cd /usr/share/squirrelmail/plugins/change_sqlpass
*  distribution wide to 4190 which is thus default here.
# cp config.php.sample config.php 
*/
# vi config.php
global $sieveport;
</pre>
$sieveport = 4190;
* Modifichiamo la riga:
<pre>
$csp_dsn = 'mysql://root:password@localhost/mailserver';
</pre>
inserendo le credenziali per l'accesso al database mailserver.
* Modifichiamo la riga:
<pre>
$lookup_password_query = 'SELECT count(*) FROM virtual_users WHERE email = "%1" AND password = %4';
</pre>
inserendo la query corretta per la ricerca dell'utente virtuale.
* Modifichiamo la riga:
<pre>
'UPDATE virtual_users SET password = %4 WHERE email = "%1"',
</pre>
inserendo la query corretta per la modifica della password dell'utente virtuale.
* Inseriamo il corretto metodo di crittazione usato dal nostro database:
<pre>
$password_encryption = 'MD5';
</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.
* Correggiamo la stringa:
 
=== 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>
<pre>
find /var/vmail -type f -ctime +7 -name '*,ST' -delete
$csp_salt_static = '';
</pre>
</pre>
Con questo comando, che possiamo inserire nel crontab del server, vengono eliminate tutte le email cancellate e più vecchie di 7 giorni.
e salviamo il file.
 
=== Ulteriori armi contro lo Spam ===
Possiamo aggiungere altri due filtri collaborativi contro lo spam seguendo queste due guide:
<br/>
<br/>
* [[Pyzor]]
Quindi riconfiguriamo Squirrelmail:
* [[Razor]]
<pre>
# cd ../../config/
# ./conf.pl
</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".


=== Troubleshooting ===
==== Roundcube ====
Se abbiamo problemi nell'inviare o ricevere mail possiamo:
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:
* 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
* '''Lenny''':
* eseguire il comando <code>postfix check</code>: se l'output è vuoto significa che Postfix è configurato bene
<pre>
* verificare la coda delle mail con il comando <code>postqueue -p -v</code>
# apt-get -t lenny-backports install roundcube
* impostare l'immediata spedizione di tutte le mail in coda: <code>mailq -q</code>
</pre>
* verificare il funzionamento di Amavis:
* '''Da Squeeze in poi''':
<pre>
<pre>
# /etc/init.d/amavisd-new stop
# apt-get install roundcube
# /etc/init.d/amavisd-new debug
</pre>
</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à.
=== Credits ===
Questa guida è basata sull'originale di Christoph Haas pubblicata sul sito [http://http://workaround.org/ Workaround.org].
<br/>
<br/>
Ora modifichiamo il file di configurazione:
<pre>
# nano /etc/roundcube/main.inc.php
</pre>
modificando le linee:
<pre>
$rcmail_config['default_host'] = 'localhost';
$rcmail_config['force_https'] = true;
</pre>
{{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>
    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/>
<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
</pre>
== Statistiche e report ==
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/>
{{Autori
|Autore = [[Utente:Ferdybassi|Ferdybassi]] 22:22, 2 apr 2011 (CEST)
|Verificata_da =
: risca 10:52, 6 apr 2014 (CEST)
|Numero_revisori = 1
}}


----
--[[Utente:Ferdybassi|Ferdybassi]] 22:22, 2 apr 2011 (CEST)
[[Categoria: Mail server]]
[[Categoria: Mail server]]
[[Categoria: Web server]]
[[Categoria: Web server]]
[[Categoria: Antispam&Content filtering]]
[[Categoria: Antispam&Content filtering]]
Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/26227...40745"