User Tools

Site Tools


linuxdebian:exim4-dovecot-old

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
linuxdebian:exim4-dovecot-old [2025/09/20 12:51] – created - external edit 127.0.0.1linuxdebian:exim4-dovecot-old [2025/09/22 14:41] (current) – [Autoreply] kurgan
Line 1: Line 1:
-## page was copied from LinuxDebian/Exim4-Dovecot 
 ===== Mail server con Exim4 / Dovecot / Clamav / Spamassassin / Greylistd ===== ===== Mail server con Exim4 / Dovecot / Clamav / Spamassassin / Greylistd =====
 +
 +** Versione obsoleta per Debian 10 **
  
 ==== Aggiornato per Debian 10 e Devuan Beowulf  ==== ==== Aggiornato per Debian 10 e Devuan Beowulf  ====
Line 8: Line 9:
 **4 novembre 2020 - aggiornato per Debian 10 e Devuan Beowulf** Ci sono alcune modifiche alla sintassi del file di config di Dovecot. **4 novembre 2020 - aggiornato per Debian 10 e Devuan Beowulf** Ci sono alcune modifiche alla sintassi del file di config di Dovecot.
  
-**13 maggio 2018 - aggiunto il supporto per le quote in Dovecot** vedi [[../Dovecot-Quota]], non funziona "da solo" ma richiede le modifiche indicate in quella pagina.+**13 maggio 2018 - aggiunto il supporto per le quote in Dovecot** vedi [[Dovecot-Quota]], non funziona "da solo" ma richiede le modifiche indicate in quella pagina.
  
 **17 marzo 2017 - aggiunto il supporto per il rate limit sui mittenti come procedura per limitare lo spam in uscita** **17 marzo 2017 - aggiunto il supporto per il rate limit sui mittenti come procedura per limitare lo spam in uscita**
  
-**8 marzo 2017 - aggiunto supporto automatico per DKIM in uscita.** Vedi [[../Exim4-DKIM]] per come creare le chiavi. In assenza delle chiavi, DKIM in uscita semplicemente non funziona, senza che si rompa nulla.+**8 marzo 2017 - aggiunto supporto automatico per DKIM in uscita.** Vedi [[Exim4-DKIM]] per come creare le chiavi. In assenza delle chiavi, DKIM in uscita semplicemente non funziona, senza che si rompa nulla.
  
-**11 aprile 2013 - aggiunto supporto per Greylistd**. Il supporto per greylistd e` disattivato di default. Per configurare greylistd fare riferimento a ..[[/GreyListd]]+**11 aprile 2013 - aggiunto supporto per Greylistd**. Il supporto per greylistd e` disattivato di default. Per configurare greylistd fare riferimento a [[GreyListd]]
  
 **11 gennaio 2012 - aggiunta gestione user e group nelle pipe**. Aggiunta la possibilita` di definire quale utente e gruppo usare quando si lancia una pipe dal file degli alias (ovvero quando si ha un alias del tipo "|script"). **11 gennaio 2012 - aggiunta gestione user e group nelle pipe**. Aggiunta la possibilita` di definire quale utente e gruppo usare quando si lancia una pipe dal file degli alias (ovvero quando si ha un alias del tipo "|script").
Line 44: Line 45:
   * Prima di tutto vengono controllare le varie RBL, viene verificato che il mittente esista e quando e` possibile viene verificato che anche il destinatario esista. Questi controlli possono causare il rifiuto completo della mail a livello SMTP oppure settare degli headers e una variabile che potranno essere usati nei filtri utente, nella configurazione utente, oppure dal client per trattare lo spam. I controlli vengono saltati in toto (e la mail accettata) se l'host mittente e` in whitelist, se la mail e` inviata da un host della mia LAN o a mezzo di SMTP autenticato, e se il destinatario della mail e` in un elenco di destinatari che per definizione accettano qualsiasi porcheria (VIRTUALS/allowed_recipients).   * Prima di tutto vengono controllare le varie RBL, viene verificato che il mittente esista e quando e` possibile viene verificato che anche il destinatario esista. Questi controlli possono causare il rifiuto completo della mail a livello SMTP oppure settare degli headers e una variabile che potranno essere usati nei filtri utente, nella configurazione utente, oppure dal client per trattare lo spam. I controlli vengono saltati in toto (e la mail accettata) se l'host mittente e` in whitelist, se la mail e` inviata da un host della mia LAN o a mezzo di SMTP autenticato, e se il destinatario della mail e` in un elenco di destinatari che per definizione accettano qualsiasi porcheria (VIRTUALS/allowed_recipients).
  
-  * Se la mail e` arrivata fino a qui, viene fatto il controllo del greylisting  a mezzo di greylistd. Il controllo e` disabilitato di default, e quindi normalmente viene semplicemente saltato e si procede al passo successivo. Per abilitare il controllo occorre, nel file di configurazione {{{exim4.conf}}} modificare (nella parte iniziale) la variabile {{{GREYLISTING=disabled}}} mettendoci ''GREYLISTING=enabled''. Occorre ovviamente anche avere configurato greylistd correttamente, come indicato qui: ..[[/GreyListd]]+  * Se la mail e` arrivata fino a qui, viene fatto il controllo del greylisting  a mezzo di greylistd. Il controllo e` disabilitato di default, e quindi normalmente viene semplicemente saltato e si procede al passo successivo. Per abilitare il controllo occorre, nel file di configurazione ''exim4.conf'' modificare (nella parte iniziale) la variabile ''GREYLISTING=disabled'' mettendoci ''GREYLISTING=enabled''. Occorre ovviamente anche avere configurato greylistd correttamente, come indicato qui: [[GreyListd]]
  
   * Poi viene fatto il check antivirus, il quale viene fatto **sempre** a meno che il destinatario della mail non sia un utente che ha impostato nella sua configurazione che non vuole il controllo antivirus. Questa feature (la disabilitazione del controllo antivirus) l'ho messa perche` potrebbe servire in casi molto particolari, ma consiglio vivamente di non usarla e lasciare che il controllo antivirus avvenga sempre. Se il destinatario e` un alias o un domain_alias il controllo AV viene sempre fatto.   * Poi viene fatto il check antivirus, il quale viene fatto **sempre** a meno che il destinatario della mail non sia un utente che ha impostato nella sua configurazione che non vuole il controllo antivirus. Questa feature (la disabilitazione del controllo antivirus) l'ho messa perche` potrebbe servire in casi molto particolari, ma consiglio vivamente di non usarla e lasciare che il controllo antivirus avvenga sempre. Se il destinatario e` un alias o un domain_alias il controllo AV viene sempre fatto.
Line 300: Line 301:
 </code> </code>
   * Tutti i files dentro /etc/vmail dovranno essere leggibili (e non scrivibili) dal gruppo "Debian-exim" (con la maiuscola!) che e` il gruppo con cui di  default gira Exim4 in Debian. I files che contengono le password devono essere NON LEGGIBILI da tutti.   * Tutti i files dentro /etc/vmail dovranno essere leggibili (e non scrivibili) dal gruppo "Debian-exim" (con la maiuscola!) che e` il gruppo con cui di  default gira Exim4 in Debian. I files che contengono le password devono essere NON LEGGIBILI da tutti.
-Il consiglio e` quello di fare un {{{chown root.Debian-exim}}} e poi un ''chmod 640'' dei files.+Il consiglio e` quello di fare un ''chown root.Debian-exim'' e poi un ''chmod 640'' dei files.
  
 Poi, eliminare tutte le porcherie che Debian mette nella directory ''/etc/exim4'' (se vi piace, conservatele da qualche parte) e crearci dentro un unico file di configurazione monolitico che almeno cosi` ci si capisce qualcosa. Creiamo anche la directory per le chiavi dkim, che e` bene che ci sia anche se poi non la usiamo. Poi, eliminare tutte le porcherie che Debian mette nella directory ''/etc/exim4'' (se vi piace, conservatele da qualche parte) e crearci dentro un unico file di configurazione monolitico che almeno cosi` ci si capisce qualcosa. Creiamo anche la directory per le chiavi dkim, che e` bene che ci sia anche se poi non la usiamo.
Line 312: Line 313:
 Occorre creare lo script che invia email di allarme in caso di superamento del rate limit. Questo script, che si chiama ''/etc/exim4/ratelimitalert.sh'' deve essere eseguibile, e contiene quanto segue: Occorre creare lo script che invia email di allarme in caso di superamento del rate limit. Questo script, che si chiama ''/etc/exim4/ratelimitalert.sh'' deve essere eseguibile, e contiene quanto segue:
 <code> <code>
- #!/bin/bash+#!/bin/bash
 # script per inviare email in caso di allarme # script per inviare email in caso di allarme
 # questo script blocca il delivery delle mail in coda # questo script blocca il delivery delle mail in coda
Line 361: Line 362:
  
  
-Il file exim4.conf lo devo allegare perche` contiene una serie di parentesi graffe che mandano in crisi il renderer del markup language del wiki; lo trovate qui per Debian 8, 9 e 10 e Devuan 1, 2 e 3 (Jessie, Ascii, Beowulf) [[attachment:exim4.conf-deb8910-devuan123.txt]]+Il file exim4.conf lo devo allegare perche` contiene una serie di parentesi graffe che mandano in crisi il renderer del markup language del wiki; lo trovate qui per Debian 8, 9 e 10 e Devuan 1, 2 e 3 (Jessie, Ascii, Beowulf) {{ :linuxdebian:exim4-dovecot-old:exim4.conf-deb8910-devuan123.txt |}}
  
-Nella configurazione allegata uso dei retry molto frequenti per velocizzare l'invio di email a destinatari che usino la greylist. Questo pero` richiede che Exim esegua il run della coda piu` spesso dei 30 minuti standard in Debian. Per ridurre questo tempo, occorre  modificare il file {{{/etc/default/exim4}}} modificando il valore ''QUEUEINTERVAL'', cosi`:+Nella configurazione allegata uso dei retry molto frequenti per velocizzare l'invio di email a destinatari che usino la greylist. Questo pero` richiede che Exim esegua il run della coda piu` spesso dei 30 minuti standard in Debian. Per ridurre questo tempo, occorre  modificare il file ''/etc/default/exim4'' modificando il valore ''QUEUEINTERVAL'', cosi`:
 <code> <code>
 # how often should we run the queue # how often should we run the queue
Line 439: Line 440:
 </code> </code>
  
-Occorre anche verificare che nel file {{{/etc/clamav/clamd.conf}}} vi sia la direttiva ''AllowSupplementaryGroups true'' altrimenti clamd ignora i gruppi ai quali l'abbiamo appena aggiunto (Dalla versione 0.99.2 e` di default a TRUE e probabilmente verra` rimossa, quindi non e` piu` necessario) +Occorre anche verificare che nel file ''/etc/clamav/clamd.conf'' vi sia la direttiva ''AllowSupplementaryGroups true'' altrimenti clamd ignora i gruppi ai quali l'abbiamo appena aggiunto (Dalla versione 0.99.2 e` di default a TRUE e probabilmente verra` rimossa, quindi non e` piu` necessario) 
-Per usare le signature di Google Safe Browsing, nel file {{{/etc/clamav/freshclam.conf}}} impostare ''SafeBrowsing true''+Per usare le signature di Google Safe Browsing, nel file ''/etc/clamav/freshclam.conf'' impostare ''SafeBrowsing true''
  
 Dopo aver fatto questa modifica riavviare clamd e freshclam. Dopo aver fatto questa modifica riavviare clamd e freshclam.
Line 447: Line 448:
 ==== Configurazione del greylisting (facoltativo) ==== ==== Configurazione del greylisting (facoltativo) ====
  
-Per abilitare il supporto al greylisting occorre configurare greylistd (come indicato qui: ..[[/GreyListd]]) e poi modificare file di configurazione {{{/etc/exim4/exim4.conf}}} (nella parte iniziale) impostando la variabile {{{GREYLISTING}}} che di default e` {{{disabled}}}, a ''enabled''.+Per abilitare il supporto al greylisting occorre configurare greylistd (come indicato qui: [[GreyListd]]) e poi modificare file di configurazione ''/etc/exim4/exim4.conf'' (nella parte iniziale) impostando la variabile ''GREYLISTING'' che di default e` ''disabled'', a ''enabled''.
 Vale la pena di soffermarsi sul fatto che se usiamo un MX secondario oltre al primario e vogliamo abilitare il greylisting, e` fondamentale configurare i due MX per avere le stesse regole di greylisting (o se non altro per avere il greylisting tutti e due) altrimenti e` inutile metterlo solo su uno dei due: le mail che vorremmo bloccare con il greylisting verranno fatte passare per l'altro. E` anche opportuno mettere l' MX secondario in whitelist in modo che non sia mai soggetto a greylisting da parte del primario. In ogni caso e` una buona idea mettere il proprio MX secondario in whitelist. Vale la pena di soffermarsi sul fatto che se usiamo un MX secondario oltre al primario e vogliamo abilitare il greylisting, e` fondamentale configurare i due MX per avere le stesse regole di greylisting (o se non altro per avere il greylisting tutti e due) altrimenti e` inutile metterlo solo su uno dei due: le mail che vorremmo bloccare con il greylisting verranno fatte passare per l'altro. E` anche opportuno mettere l' MX secondario in whitelist in modo che non sia mai soggetto a greylisting da parte del primario. In ogni caso e` una buona idea mettere il proprio MX secondario in whitelist.
  
Line 503: Line 504:
 Alla fine, se vogliamo che funzioni qualcosa, occorre definire almeno un dominio virtuale. Alla fine, se vogliamo che funzioni qualcosa, occorre definire almeno un dominio virtuale.
  
-Per creare un dominio virtuale che abbia degli utenti, e` sufficiente creare un file con il nome del dominio dentro a {{{/etc/vmail/users/}}} Per esempio, ''/etc/vmail/users/pippo.com'' e` il file che contiene gli utenti del dominio "pippo.com".+Per creare un dominio virtuale che abbia degli utenti, e` sufficiente creare un file con il nome del dominio dentro a ''/etc/vmail/users/'' Per esempio, ''/etc/vmail/users/pippo.com'' e` il file che contiene gli utenti del dominio "pippo.com".
  
 Questo file e` composto di tante righe quante sono gli utenti, ognuna delle quali contiene username, password (in chiaro), ed eventualmente variabili che dicono come comportarsi con la scansione antivirus e antispam per l'utente. Queste variabili, facoltative, sono separate dalla password con un carattere ":" e sono separate fra di loro da spazi. Al momento esistono le seguenti variabili: Questo file e` composto di tante righe quante sono gli utenti, ognuna delle quali contiene username, password (in chiaro), ed eventualmente variabili che dicono come comportarsi con la scansione antivirus e antispam per l'utente. Queste variabili, facoltative, sono separate dalla password con un carattere ":" e sono separate fra di loro da spazi. Al momento esistono le seguenti variabili:
Line 559: Line 560:
 ==== Configurazione server smtp autenticato ==== ==== Configurazione server smtp autenticato ====
  
-In questa configurazione esiste anche la possibilita` di accettare sessioni smtp autenticate dagli utenti che magari sono fuori ufficio. Per farlo, ci sono due possibilita`. Il vecchio sistema (disponibile ma obsoleto) consente di autenticare gli utenti SMTP su un file di testo. Il file in questione e` {{{/etc/exim4/passwd.smtp}}}, e va modificato inserendo una riga con ''username:password'' per ogni utente che si vuole che usi l'smtp autenticato. (In questo caso probabilmente e` sufficiente inserire una sola coppia di username e password per ogni dominio e poi comunicarla a tutti gli utenti del dominio.)+In questa configurazione esiste anche la possibilita` di accettare sessioni smtp autenticate dagli utenti che magari sono fuori ufficio. Per farlo, ci sono due possibilita`. Il vecchio sistema (disponibile ma obsoleto) consente di autenticare gli utenti SMTP su un file di testo. Il file in questione e` ''/etc/exim4/passwd.smtp'', e va modificato inserendo una riga con ''username:password'' per ogni utente che si vuole che usi l'smtp autenticato. (In questo caso probabilmente e` sufficiente inserire una sola coppia di username e password per ogni dominio e poi comunicarla a tutti gli utenti del dominio.)
  
 Il nuovo sistema consente ad Exim di autenticare sul backend di autenticazione usato da Dovecot. In pratica Exim chiede a Dovecot di verficare username e password per l'utente. In questo modo e` sufficiente inserire un utente nella configurazione "standard" (dentro a /etc/vmail/users) per consentirgli anche si usare SMTP autenticato con lo stesso username e password. A riguardo di questo, c'e` un bug in Exim 4.69 (versione di Debian Lenny) per cui exim va in segfault se in Dovecot sono presenti piu` di 6 sistemi di autenticazione diversi. Il report e la patch sono disponibili qui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551106, e comunque nella configurazione che uso qui il problema non si presenta, almeno spero. Il nuovo sistema consente ad Exim di autenticare sul backend di autenticazione usato da Dovecot. In pratica Exim chiede a Dovecot di verficare username e password per l'utente. In questo modo e` sufficiente inserire un utente nella configurazione "standard" (dentro a /etc/vmail/users) per consentirgli anche si usare SMTP autenticato con lo stesso username e password. A riguardo di questo, c'e` un bug in Exim 4.69 (versione di Debian Lenny) per cui exim va in segfault se in Dovecot sono presenti piu` di 6 sistemi di autenticazione diversi. Il report e la patch sono disponibili qui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551106, e comunque nella configurazione che uso qui il problema non si presenta, almeno spero.
Line 571: Line 572:
 ==== Autoreply ==== ==== Autoreply ====
  
-Nota: questa soluzione, seppure funzionante, e` resa obsoleta dall'uso di filtri Sieve con Dovecot. (Vedasi [[../Dovecot-Sieve]])+Nota: questa soluzione, seppure funzionante, e` resa obsoleta dall'uso di filtri Sieve con Dovecot. (Vedasi [[Dovecot-Sieve]])
 E` possibile attivare un risponditore automatico in stile "vacation" che risponde alle mail di un utente tramite un messaggio con un subject preimpostato e un testo libero. Per farlo, occorre creare un file con nome ''/etc/vmail/autoreply/<dominio>/<utente>'' (ad esempio, /etc/vmail/autoreply/pippo.it/prova per l'utente "prova@pippo.it"). All'interno di quel file, va scritto il testo della risposta automatica, che puo` essere lungo quanto si vuole e composto di piu` righe senza problemi. L'autoreply e` limitato a una risposta al giorno per mittente, questo limite e` impostabile solo nella configurazione ed e` valido per tutti gli utenti, non si puo` differenziare per singolo utente. Per disattivare l'autoreply, va cancellato o rinominato il file. E` possibile attivare un risponditore automatico in stile "vacation" che risponde alle mail di un utente tramite un messaggio con un subject preimpostato e un testo libero. Per farlo, occorre creare un file con nome ''/etc/vmail/autoreply/<dominio>/<utente>'' (ad esempio, /etc/vmail/autoreply/pippo.it/prova per l'utente "prova@pippo.it"). All'interno di quel file, va scritto il testo della risposta automatica, che puo` essere lungo quanto si vuole e composto di piu` righe senza problemi. L'autoreply e` limitato a una risposta al giorno per mittente, questo limite e` impostabile solo nella configurazione ed e` valido per tutti gli utenti, non si puo` differenziare per singolo utente. Per disattivare l'autoreply, va cancellato o rinominato il file.
  
Line 746: Line 747:
 ===== BUGS ===== ===== BUGS =====
  
-  * Se Exim mai dovesse riportare, durante una sessione SMTP con TLS, l' errore "{{{TLS error on connection from XXX [x.x.x.x] (recv): A TLS fatal alert has been received.: Bad record MAC}}}", allora la soluzione pare che sia inserire nella config di exim (parte principale, quella all'inizio) il comando "''gnutls_compat_mode''" (senza alcun parametro).+  * Se Exim mai dovesse riportare, durante una sessione SMTP con TLS, l' errore "TLS error on connection from XXX [x.x.x.x] (recv): A TLS fatal alert has been received.: Bad record MAC", allora la soluzione pare che sia inserire nella config di exim (parte principale, quella all'inizio) il comando "''gnutls_compat_mode''" (senza alcun parametro).
  
   * ** BUG  RISOLTO, almeno spero:** I due routers "virtual_spam_owl" e "virtual_spam_add_subject" non fanno un check dell'esistenza del file VIRTUALS/users/<domain> prima di farci un lsearch sopra, quindi vanno in errore di brutto se per caso questo file manca per un dominio che pero` esiste. Il caso evidente e` se si ha un dominio aliasato in VIRTUALS/domain_aliases che pero` non ha utenti locali. In questo caso e` necessario creare un file di utenti per il dominio, lasciandolo vuoto.   * ** BUG  RISOLTO, almeno spero:** I due routers "virtual_spam_owl" e "virtual_spam_add_subject" non fanno un check dell'esistenza del file VIRTUALS/users/<domain> prima di farci un lsearch sopra, quindi vanno in errore di brutto se per caso questo file manca per un dominio che pero` esiste. Il caso evidente e` se si ha un dominio aliasato in VIRTUALS/domain_aliases che pero` non ha utenti locali. In questo caso e` necessario creare un file di utenti per il dominio, lasciandolo vuoto.
linuxdebian/exim4-dovecot-old.1758372660.txt.gz · Last modified: by 127.0.0.1