= Mail server con Exim4 / Dovecot / Clamav / Spamassassin / Greylistd = == Aggiornato per Debian 11 e Debian 12 == '''Novembre 2024 - Aggiornato per Debian 12, le differenze con la config di Debian 11 sono indicate dove necessario, il file di config di Exim è disponibile in due versioni per Debian 11 e 12''' '''Le vecchie versioni sono disponibili consultando la pagina [[../Exim4-Dovecot-OLD]] e le sue modifiche. La versione di Exim in Debian 11 e Debian 12 è radicalmente diversa dalle precedenti ergo non è compatibile con le precedenti.''' '''Gennaio 2022 - Aggiornato per Debian 11 e Devuan Chimaera''' Ci sono importanti modifiche in Exim ed ho integrato Sieve nella config di Dovecot. '''Giugno 2022 - Aggiunta una whitelist specifica dedicata al greylisting''' Utile per saltare il greylisting per quei domini che sappiamo essere puliti o per quelli che, come Google o Office365, hanno mille mila SMTP server e quindi continuano a ricadere nel greylisting per più volte di seguito. '''Giugno 2023 - Modificata gestione delle RBL''' Ora se Spamhaus decide che non vuole più rispondere alle mie query perché secondo loro sto facendo troppo traffico (o perché sto usando ipv6 e loro si sono incartati) e mi risponde con un codice di errore, ovvero 127.255.255.X al posto dei classici 127.0.x.x, Exim dovrebbe lasciare passare tutto (quindi anche lo spam) che è sempre meglio che bloccare tutto come faceva prima, bloccando tutte le email buone. In altri termini, ora una risposta di tipo 127.255.255.X da parte di Spamhaus viene considerata come "lascia passare la mail" e non come "blocca la mail". Notare che Spamhaus non dovrebbe rispondere in questo modo a meno che non si sia incasinata o non ritenga che fate troppo traffico. Questa e` una configurazione di un mail server completo, con supporto per diversi domini, antivirus e antispam, con supporto per filtri Sieve. Le configurazioni sono realizzate su files di testo e non su database in quanto ritengo che sia piu` facile, per piccole installazioni che possono essere gestite da un sistemista che sa come editare un file di testo, evitare di usare un database e una interfaccia web per la configurazione. == Descrizione tecnica == Questo sistema deve fornire un mail server con funzione di filtraggio dei virus e dello spam, supporto per client pop3 e imap4, filtri Sieve e Managesieve (integrabile con client Sieve quali per esempio quello incluso in Roundcube webmail) e gestione di diversi domini virtuali. La configurazione e` fatta tutta su files di testo, ed e` studiata per essere semplice da gestire, ovvero per aggregare tutti i dati in pochi files per ogni dominio virtuale. Usando dei programmi come Dovecot ed Exim, che sono molto configurabili, e` possibile fare in modo che tutti e due accedano agli stessi files, e li usino "assieme", exim per decidere come fare il delivery della mail, e dovecot per autenticare gli utenti pop3 e imap4. Per lo storage della mail ho scelto di usare maildir, perche` e` molto piu` performante di mailbox, e se si vuole usare imap secondo me la velocita` e` fondamentale. Prevedendo di usare solo pop3, oppure accontentandosi di prestazioni scarse in imap, si puo` anche usare il formato mailbox. La mail viene comunque tutta tenuta in files e directory di proprieta` dell'utente "mail" sotto /var/vmail//. Gli utenti mail in questo setup sono totalmente svincolati dagli utenti locali della macchina. Usando questa configurazione un mail server che abbia soltanto un dominio deve comunque essere configurato in modo che il dominio sia virtuale, e gli utenti locali della macchina non abbiano nulla a che fare con gli utenti della mail. I motivi di questa scelta sono diversi: prima di tutto gli utenti della macchina (per come e` configurato exim) non hanno ne` l'antivirus ne` l'antispam, inoltre gli utenti della macchina accederebbero in pop3 e imap usando la stessa password di login, e questo e` decisamente male dal punto di vista della sicurezza. Tra l'altro al momento Dovecot e` configurato in modo da non riconoscere proprio gli utenti della macchina, quindi questi non potrebbero proprio ricevere la mail in pop3 o imap4, ma solo leggerla localmente in shell. == Funzionamento del sistema antispam e antivirus == Idealmente, avrei voluto permettere ad ogni singolo utente di scegliere cosa fare dello spam, permettendogli di scegliere se bloccare (nel senso di rifiutare la mail a livello di protocollo SMTP rifiutandola con una permanent failure), oppure marcare con un header X-Spam-qualcosa le mail di spam, oppure non fare proprio il controllo antispam. Purtroppo questo e` un problema quando ci sono degli alias in gioco, perche` al momento in cui faccio il check (cioe` alla fine del blocco "DATA" dell'smtp) non sono in grado di determinare se il destinatario ultimo di una mail che viene diretta ad un alias vuole o no la funzione antispam/antivirus, per saperlo dovrei espandere l'alias fino agli indirizzi finali, e se questi sono piu` di uno e richiedono comportamenti diversi, ancora non saprei come comportarmi. Per uscire da questa impasse ci sono due soluzioni: una delle due e` quella di non fare il controllo antispam al momento della connessione SMTP entrante ma farlo al momento del delivery locale (questo metodo pero` mi impedisce di rifiutare il messaggio, ma mi costringe ad accettarlo e poi eventualmente cancellarlo) e l'altra e` quella che ho usato e che spiego nel dettaglio qui sotto. Quando una mail arriva al sistema, passa per una serie di ACL che ne controllano la validita` e decidono cosa farne. * 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}}}. Può essere creato un file (il nome di default è /etc/exim4/nogrey.list) che contiene indirizzi ip (o intere reti) che non verranno sottoposte al greylisting. Questa funzione è utile per evitare di tenere in greylist per lungo tempo mittenti che hanno multipli server SMTP e che fanno rotazione dei server. L'elenco può essere gestito a mano oppure può essere generato usando uno script per raccogliere gli indirizzi ip usati dai mittenti. Per la configurazione del demone greylistd e per l'uso del file di whitelist fate riferimento a questa pagina: ../GreyListd * Poi viene fatto il check antivirus, a meno che l'host mittente non sia in whitelist, la mail non sia inviata da un host della mia LAN o a mezzo di SMTP autenticato, oppure il destinatario della mail non sia un utente che ha impostato nella sua configurazione che non vuole il controllo antivirus. Se il destinatario e` un alias o un domain_alias il controllo AV viene sempre fatto. Nota: il controllo AV non viene fatto sulla mail USCENTE verso altri domini, ma solo su quella ENTRANTE. * Poi viene fatto il check antispam, a meno che l'host mittente non sia in whitelist, la mail non sia inviata da un host della mia LAN o a mezzo di SMTP autenticato, o il destinatario della mail non sia in un elenco di destinatari che per definizione accettano qualsiasi porcheria. Nota: il controllo antispam non viene fatto sulla mail USCENTE verso altri domini, ma solo su quella ENTRANTE. * Se il punteggio dell'antispam supera la soglia di rifiuto definita a livello di sistema, la mail viene rifiutata durante la sessione SMTP. * Se il punteggio dell'antispam supera la soglia di marcatura definita a livello di sistema, la mail viene marcata per essere poi trattata da filtri utente, specifiche configurazioni dell'utente, o dal client. * Se il destinatario della mail ha impostato una soglia per il rifiuto dello spam a livello SMTP, e il messaggio la supera, viene rifiutato a livello SMTP. Attenzione, perche` se il destinatario e` un utente vale la soglia impostata per l'utente, se e` un alias vale la soglia impostata per l'alias, se e` un domain_alias vale la soglia per l'intero dominio impostata appunto nel file domain_aliases. Se ci sono diversi destinatari, conta l'impostazione del primo della lista. Questo sistema e` tutt'altro che perfetto, ma non si puo` fare diveramente a questo livello. A questo punto la mail viene accettata a livello di SMTP, ma lo spam puo` ancora essere trattato a livello di utente, e questa volta non ci sono problemi nell'identificare il destinatario, quindi ogni destinatario "finale" (dopo che sono stati elaborati alias e domain_alias) puo` fare dello spam quello che vuole. Le possibilita` che ha sono: * Accettarlo comunque (nel messaggio ci sono degli header che possono essere usati per decidere cosa fare a livello di MUA) * Marcarlo come spam nel subject in caso superi una certa soglia di spammosita` (utile per i MUA stupidi come Outlook Express) * Buttarlo via completamente nel caso superi una certa soglia di spammosita` * Salvarlo in un folder IMAP specificato nella configurazione del singolo utente (diverso per ogni utente) * Gestire lo spam nei filtri utente (se ha il diritto di usarli) come meglio crede, usando le variabili impostate da spamassassin. == Rate limit contro lo spam uscente == Capita spesso che qualche malware rubi le password della mail da un client, e che l'account sottratto venga usato per inviare spam dal nostro mail server, facendoci finire in tutte le blacklist del mondo. Per cercare di limitare questo rischio, questa configurazione dispone di un sistema di rate limit, che funziona in due modi: * Se un mittente usa l'autenticazione SMTP, il rate limit si applica all'account, indipendentemente dall'indirizzo ip o dagli indirizzi ip da cui si collega. In pratica, se un utente autenticato manda troppe email per unita` di tempo, gli viene impedito l'invio. * Se il mittente non si autentica (e quindi, per definizione, viene da un host per il quale e` consentito il relay) allora il limite viene applicato all'indirizzo ip dell'host mittente. In ogni caso, superato il limite, viene inviata una mail di allarme ad un indirizzo definito nella configurazione di exim, per segnalare l'anomalia. E` importante reagire immediatamente a questi allarmi, provvedendo a fermare la coda, cancellare lo spam in uscita, e prendere provvedimenti per impedire che il problema continui. Cosi` facendo riduciamo la possibilita` di finire in blacklist. Il rate limit e` configurato a un valore di default dentro al file di configurazione di exim, e puo` essere variato per ogni utente autenticato (vedasi in fondo gli esempi di configurazione degli account utente, le voci ratelimit_limit e ratelimit_time). Il rate limit invece non puo` essere variato per gli host non autenticati, almeno in questa versione della configurazione. Se occorre "sbloccare" il limiite per un host autorizzato al relay la soluzione piu` immediata e` mettere questo host in whitelist, operazione che rimuove qualsiasi limite di invio da questo host. == Nuovo in Debian 12 - Controllo SPF ed eventuale rifiuto == In Debian 12 Exim è stato compilato per default con il supporto per la verifica del record SPF (in ricezione), e gestione del risultato nelle ACL. Nel file di configurazione per Debian 12 di exim che trovate allegato qui, ho attivato il controllo del record SPF del mittente. È una cosa in test, volendo potete eliminarla commentando le righe relative nelle ACL. Attualmente, se funziona correttamente, rifiuta le email che falliscono il controllo SPF soltanto se il mittente ha configurato il suo record spf con la stringa "-all" alla fine, ovvero il mittente stesso vuole che i destinatari rifiutino le mail che non passano il test. In ogni altro caso accetta la mail segnando nei log un warning. Questa parte è da collaudare e poi da migliorare, inserirò prossimamente un parametro di configurazione come per le altre funzioni come per dire il greylisting o l'uso delle RBL. == Pacchetti == I pacchetti usati sono: {{{ dovecot-imapd dovecot-pop3d exim4-daemon-heavy dovecot-managesieved dovecot-sieve spamassassin razor libmail-dkim-perl clamav-daemon }}} Se vi serve solo l' MX secondario potete evitare di installare Dovecot, pero` poi dovrete modificare la configurazione di Exim in modo da non appoggiarsi all'autenticatore di Dovecot. == Configurazione di Dovecot versione 2.3.x con Sieve == Dovecot va configurato per servire pop3 e imap4 usando delle maildir. Lavora sempre come uid "mail" e gid "mail", per qualsiasi utente di qualsiasi dominio. Legge le password in chiaro (necessario per poter usare autenticazioni in cui la password non viaggia in chiaro sulla linea) da un file di testo. Se si vuole usare mailbox, basta cambiare la parola "maildir" in "mailbox" (ovviamente anche exim andra` adattato per lavorare in mailbox e non in maildir). La configurazione ` in /etc/dovecot/dovecot.conf. Vale la pena di leggersi la documentazione perche` questa configurazione e` funzionante ma minimale, ci sono mille features che possono essere messe a punto come meglio credete. Soprattutto, leggete le parti che riguardano i tweak per la compatibilita` con i client imap rognosi. (vedasi la documentazione su http://www.dovecot.org) Se volete attivare il supporto SSL, occorre generare dei certificati, siano essi "buoni" o fatti in casa. Per generare al volo dei certificati fatti in casa si puo` eseguire uno script che ha lo scopo di generare una coppia certificato/chiave e di metterla dove Dovecot si aspetta di trovarla. Prima modificare (volendo) la configurazione per metterci due cose sensate, modificare mkcert.sh per allungare la validita` da un anno a quanto volete voi, e poi eseguire mkcert, come indicato qui di seguito: {{{ vim /usr/share/dovecot/dovecot-openssl.cnf mkdir /etc/dovecot/ssl cd /usr/share/dovecot ./mkcert.sh }}} Se si usano certificati firmati da una CA valida, non dovrebbero sorgere problemi di sorta. Dovecot usa tranquillamente i certificati nello stesso formato in cui sono compresi da apache2, per esempio. L'unico punto complesso riguarda il "chaining" dei certificati. Se la CA che usiamo non e` una CA riconosciuta "direttamente", ma richiede un chaining dei certificati allora dobbiamo avere cura di mettere nel file pem dei certificati (in /etc/ssl/certs) tutti i certificati in sequenza. Dovrete in ogni caso generare il file {{{dh.pem}}} con i parametri Diffie-Hellman, sia che usiate un certificato autogenerato oppure uno "ufficiale" . Questa operazione è lunga specie per una lunghezza di 4096 bit. Se ne avete uno già generato, potete riutilizzarlo. Per generarlo usate questo comando: {{{ openssl dhparam 4096 > /etc/dovecot/dh.pem }}} Se avete un minimo di traffico IMAP (diciamo dai 20 utenti in su con molte cartelle) è il caso di aumentare alcuni limiti di sistema riguardo agli inodes e alla funzione "inotify", molto usata da Dovecot. Per farlo, usiamo sysctl. (Magari controllate prima che non ci siano gia` impostazioni a riguardo; il default con Debian 12 e` 30189 e 128): {{{ echo "fs.inotify.max_user_watches=65535" >> /etc/sysctl.d/dovecot-local.conf echo "fs.inotify.max_user_instances=1024" >> /etc/sysctl.d/dovecot-local.conf sysctl -f --system }}} Questo e` il file {{{/etc/dovecot/dovecot.conf}}}, in versione "monolitica" che non utilizza alcuna altra configurazione (ne` i files dentro conf.d ne` la configurazione del database, in questo caso) {{{ ## ## usa questi protocolli (le versioni "s" sono comprese, quindi ## imap include imaps e pop3 include pop3s) ## protocols = imap pop3 sieve ## aumento il numero massimo di processi, per facilitare il login di molta gente assieme. ## aumento anche la RAM massima usata da un processo, per evitare che certe ricerche vadano in OOM. ## dovrebbe essere fatto in modo piu` chirurgico, leggendo il manuale e non alla vecchia come faccio io ## in quanto in Dovecot ogni tipo di processo puo` avere limiti diversi. ## Il default è 100 processi ovvero 100 connessioni contemporanee, che spesso sono poche. ## http://wiki2.dovecot.org/LoginProcess #default_process_limit=512 #default_client_limit=2048 #default_vsz_limit = 1 G ## ## Disabilita IPV6 (volendo) ## # listen=* ## ## autenticatori che accetto (tolgo ntlm, nel caso lo rimettero`) ## # auth_mechanisms = plain login digest-md5 cram-md5 apop ntlm auth_mechanisms = plain login digest-md5 cram-md5 apop ## ## Consenti l'autenticazione plaintext sempre, anche senza SSL. ## Non e` sicuro ma lo uso in locale con la webmail ## disable_plaintext_auth = no ## ## Consenti di usare l' UID 8 per accedere alla mail ## (visto che tutta la mia mail dei virtual domanins e` di questo utente) ## first_valid_uid = 8 last_valid_uid = 8 first_valid_gid = 8 last_valid_gid = 8 ## ## Carica il certificato e la chiave privata per SSL da qui: ## ssl_cert = dh.pem" ## ssl_dh=//sieve. # il file del filtro attivo e` di default ".dovecot.sieve" ma lo rinomino in "dovecot-sieve" # senza il "." all'inizio altrimenti viene confuso con una cartella imap che ovviamente non esiste. plugin { sieve = ~/dovecot.sieve } ## ## LDA (per usare i filtri sieve, uso l' LDA di Dovecot richiamato da Exim) ## lda_original_recipient_header = X-Original-To lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes protocol lda { mail_plugins = $mail_plugins sieve } ## ## Configurazioni generali del sistema di autenticazione ## service auth { user = Debian-exim # questo socket e` quello su cui si autentica Exim per l' SMTP autenticato unix_listener auth-client { mode = 0666 } } ## ## Configurazione dell'autenticazione degli utenti su file di testo ## diviso in due parti: ## - passdb definisce da che database (files di testo in questo caso) leggo username ## e password e in che formato li leggo ## - userdb definisce dove si trova la mail e come la si accede a seconda ## di che utente sei (in questa config e` uguale per tutti, tranne che per ## il percorso dei files della maildir, infatti uso un driver "static") ## passdb { args = username_format=%n scheme=plain /etc/vmail/users/%d driver = passwd-file } userdb { args = uid=mail gid=mail home=/var/vmail/%d/%n mail=maildir:/var/vmail/%d/%n driver = static } ## ## configurazioni del protocollo imap ## protocol imap { imap_client_workarounds = mail_max_userip_connections = 30 } ## ## configurazioni del protocollo pop ## protocol pop3 { pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s pop3_uidl_format = %08Xu%08Xv } ## ## Configurazione dell'utente di default per i socket ## del servizio stats. Questa modifica si rende necessaria ## se si usa dovecot-lda con un utente che non sia "dovecot" ## (per esempio "mail") altrimenti dovecot-lda non riesce a ## scrivere le stats e riporta warning ad ogni mail consegnata ## ## Questa modifica è necessaria da Debian 10 / Devuan Beowulf in poi. ## (versione di Dovecot 2.3.4.1) ## service stats { unix_listener stats-reader { user = mail group = mail mode = 0660 } unix_listener stats-writer { user = mail group = mail mode = 0660 } } }}} == Configurazione di Exim == Prima di tutto, occorre fare alcune operazioni a livello di file system: * Creare la directory /var/vmail che conterra` la mail degli utenti dei domini virtuali e poi darle permessi 770 e assegnarla all'utente mail gruppo mail. {{{ mkdir /var/vmail chown mail:mail /var/vmail chmod 770 /var/vmail }}} * Creare la directory /etc/vmail e le sottodirectory che conterranno tutte le configurazioni dei domini virtuali. Creare il file /etc/vmail/domain_aliases, vuoto, per evitare di avere errori. Questo file potra` poi essere usato o meno, a seconda delle necessita`. Il suo uso e` spiegato piu` avanti. {{{ mkdir /etc/vmail mkdir /etc/vmail/users mkdir /etc/vmail/aliases mkdir /etc/vmail/filters mkdir /etc/vmail/autoreply touch /etc/vmail/domain_aliases }}} * 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. * Facoltativamente, puliamo /etc/exim4 dalle porcherie del compilatore di config di Debian (che non usiamo) e teniamo tutto da una parte. Se non lo faccio non cambia nulla, Exim userà la config che abbiamo fatto noi {{{/etc/exim4.conf}}} e ignorerà quella autogenerata. NOTA: se riavviamo Exim per qualsiasi motivo prima di avere creato il file di config nostro e dopo aver eliminato i files nativi debian, systemd si incazza. {{{ mkdir /etc/exim4/old mv /etc/exim4/* /etc/exim4/old/ }}} * Creiamo una directory per le chiavi dkim, che e` bene che ci sia anche se non vogliamo usarla. (Io la uso comunque, senza DKIM oramai non mandi la mail a nessuno dei big) {{{ mkdir /etc/exim4/dkim }}} 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: {{{ #!/bin/bash # script per inviare email in caso di allarme # questo script blocca il delivery delle mail in coda # e poi invia una mail che viene inviata saltando il blocco # del delivery. # parametri: # $1 = destinatario (e mittente) della mail di allarme # $2 = username dell'utente che ha sforato il limite # $3 = indirizzo ip da cui si collega l'utente # $4 = Sender rate al momento dello sforo # $5 = Periodo di tempo preso in considerazione # $6 = Limite massimo imposto #From: "Exim RATE LIMIT ALERT" <$1> exim -odf $1 << EOF To: <$1> Subject: Exim RATE LIMIT ALERT Content-Type: text/plain; charset=utf-8 Allarme di rate limit dall' host `hostname -f` Un utente o un host (autorizzato al relay) ha superato il limite imposto di invio di email per unità di tempo. Utente autenticato: $2 Indirizzo ip dal quale si collega: $3 Rateo attuale di invio: $4 email su un tempo di $5 Rateo limite di invio: $6 email su un tempo di $5 Nota: se il campo "utente autenticato" non è vuoto questo significa che l'utente in questione ha sforato il limite di invio. Probabilmente è stata rubata la sua password, specie se il traffico viene da un IP esterno straniero. Se il campo "utente autenticato" è vuoto, allora l'indirizzo IP indicato sopra, che è autorizzato al relay senza autenticazione, ha sforato il limite di invio, segno che l'host potrebbe essere infetto da un malware che manda spam. EOF ### touch /tmp/exim_queue_only }}} 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 11 e Devuan Chimaera (versione 4.94 di Exim) [[attachment:exim4.conf.v494.txt]] * Lo trovate qui per Debian 12 e Devuan Daedalus (versione 4.96 di Exim) [[attachment:exim4.conf.v496.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`: {{{ # how often should we run the queue QUEUEINTERVAL='5m' }}} === NOTE su Exim: === * Le scansioni antivirus e antispam NON vengono fatte per gli utenti veri (quelli in /etc/passwd) della macchina. L'idea e` che questo sistema nasce per servire la mail solo agli utenti virtuali. * per fare test, sono comodi i seguenti comandi: || {{{exim4 -bP}}} || Dump nella configurazione che Exim ha in memoria, compresi i valori di default || || {{{exim4 -bs -d}}} || Sessione smtp "in console" con debug molto dettagliato || || {{{exim4 -be -d+expand 'espressione'}}} || per testare una espressione (espansioni di variabili, if, e quant'altro). Notare gli apici singoli intorno all'espressione, fondamentali || || {{{exim -bt }}} || Per testare i le regole di routing delle mail. Exim finge di mandare una mail a quell'indirizzo e ci mostra con che router e trasporto la manderebbe (sia locale che remoto) || || {{{exim4 -bh . -d}}} || Esegue una sessione smpt in console fingendo che sia provienente dall'indirizzo ip e porta indicati. || === NOTE sul concetto di variabile TAINTED introdotta in Exim 4.94 e peggiorato in 4.96 === L'idea è che per evitare potenziali falle di sicurezza ora Exim si rifiuta di fare operazioni che coinvolgono files (aprire un file, creare un file, ecc) usando come riferimento dei valori che sono stati ricevuti dall'esterno (per esempio parti di un indirizzo email di un destinatario). Siccome il mio setup è tutto basato su files, ovviamente questa modifica ha totalmente distrutto la mia configurazione e ha richiesto due o tre giorni di lavoro per capire e per ricostruire la configurazione usando dei metodi per "untaint" ovvero per validare le variabili che uso per operare sui files. In pratica ci sono alcune funzioni (tipicamente sono funzioni di search) che permettono di "untaint" le variabili. Purtroppo al momento la documentazione di Exim e` ancora lacunosa e soprattutto manca un "riassunto" che comprenda un elenco delle funzioni che non vanno con variabili tainted, di quelle che vanno, e di quelle che se le usi generano valori "untainted". Uno straccio di documentazione, che è il punto da cui sono partito per capire, si trova qui, al paragrafo 5, per un totale di 10 righe: http://exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_address_and_local_part_lists.html#SECTlistresults Io '''spero''' che in un futuro ci sarà una pagina di documentazione dedicata a questo importante cambiamento. Personalmente ho provato a inserire in giro per il mio file di config dei commenti (cercate "TAINT") relativi ai punti dove devo applicare trucchi per poter "untaint"-are le variabili. == Configurazione di Spamassassin == * Editare il file {{{/etc/defaul/spamd}}} ed impostare ENABLED=1 (in Debian 11, e` {{{/etc/defaul/spamassassin}}}) * Debnian 11: Volendo, in fondo, mettere CRON=1 per ricevere aggiornamenti alle regole di spamassassin (nota: questa opzione funziona ancora anche in debian 12, anche se in Debian 12 c'e` un timer in systemd che possiamo usare al posto di questa configurazione) * Debian 12: volendo possiamo usare il comando {{{systemctl enable --now spamassassin-maintenance.timer}}} invece di usare CRON=1 come indicato nella riga precedente. * Se si vuole usare spamd attraverso un socket e non attraverso una connessione tcp a localhost, e` possibile farlo modificando {{{/etc/default/spamassassin}}} in modo da aggiungere alle opzioni quella per usare il socket (socketpath=xxx). In questo modo la riga OPTIONS diventa: {{{ OPTIONS="--create-prefs --max-children 5 --helper-home-dir --socketpath=/var/run/spamd.ctl" }}} Questa configurazione e` piu` sicura in quanto non usa il tcp ma solo un socket locale, pero` ovviamente impedisce di usare exim su una macchina e spamassassin su un'altra (o su un pool di altre macchine, opzione valida per fare load balancing). E` importante ricordare che se si usa il socket occorre dirlo anche ad Exim, modificando exim.conf. La configurazione qui allegata usa il socket. * E` opportuno modificare il file {{{/etc/spamassassin/local.cf}}} per disattivare il check delle RBL da parte di spamassassin, in quanto il check e` gia` fatto da Exim prima di passare le mail a spamassassin. Inoltre e` possibile nello stesso file modificare i punteggi dati ai vari filtri. Il mio attuale e` modificato per aumentare il punteggio di Razor e diminuire quello di Habeas, il quale viene puntualmente abusato. Anche la configurazione del report, che viene incluso poi da Exim come header nelle mail, e` stata modificata in modo da averne uno piu` "stringato" rispetto all'originale. {{{ # disattivazione check RBL skip_rbl_checks 1 # Report personalizzato (MOLTO piu` ridotto dell'originale) clear_report_template report _TESTSSCORES_ (_SCORE_ points, _REQD_ required) # modifiche dei punteggi score HABEAS_SWE 0.1 score RAZOR2_CF_RANGE_51_100 3.0 # score RDNS_NONE 0.0 }}} * Debian 11: Eseguire {{{/etc/init.d/spamassassin start}}} per avviare il demone spamd (ovviamente al reboot partira` da solo) * Debian 12: Eseguire {{{systemctl restart spamd}}} In questo setup, spamassassin (in realta` il demone spamd) viene sempre chiamato dall'utente "mail", quindi per qualsiasi utente di qualsiasi dominio il database bayesiano sara` sempre lo stesso, e si trovera` nella home dell'utente mail sotto una directory con nome ".spamassassin". == Configurazione di Razor == * Editare il file {{{/etc/razor/razor-agent.conf}}} modificandolo come segue: {{{ logfile = sys-syslog logic_method = 4 ignorelist = 1 report_headers = 0 }}} * Configurare Razor per la prima volta, come utente "mail", visto che poi girera` sempre come utente "mail". {{{ # su - mail -s /bin/bash $ razor-admin -create $ razor-admin -discover $ razor-admin -register }}} Le configurazioni di Razor saranno salvate sotto la home dell'utente mail, nella directory ".razor". == Configurazione di Clamav == '''NOTA: Clamav allo stato attuale (2022) è pressoché inutile, a meno di non usare signature di terze parti a pagamento. È anche decisamente ingordo di RAM e CPU.''' Dopo aver installato clamd (questa config usa clamd e non clamscan), occorre aggiungere l'utente "clamav" al gruppo "Debian-exim" e al gruppo "mail" dentro /etc/group, altrimenti clamd non puo` accedere ai files che exim gli passa da scansionare. {{{ adduser clamav mail adduser clamav Debian-exim }}} Per ridurre l'uso di ram nel file {{{/etc/clamav/clamav.conf}}} impostare {{{ConcurrentDatabaseReload no}}} Dopo aver fatto questa modifica riavviare clamd e freshclam. == 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}}}. 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. == Scripting per insegnare al filtro bayesiano di Spamassassin (facoltativo e poco collaudato) == Volendo e` possibile installare un sistema per insegnare al filtro bayesiano di Spamassassin. Dal momento che noi di default rifiutiamo lo spam, non avremo mai delle mail buone indicate come "SPAM" (falsi positivi) nella nostra inbox, saranno tutte state rimandate al mittente con un errore. Questo e` un limite intrinseco nella scelta di rifiutare lo spam, ma a me va bene cosi`. Comunque, ci resta la possibilita` di ricevere dello spam che il filtro non ha identificato correttamente (falsi negativi), e per questi possiamo provare a insegnare al filtro bayesiano come trattarli. Questo sistema richiede che l'utente crei una cartella IMAP denominata "SPAM" sotto la sua cartella principale (NON SOTTO LA INBOX!) in modo che nella gerarchia delle directory sul server questa venga creata come {{{/var/vmail/dominio/utente/.SPAM}}}. Lo script qui allegato, che va messo in crontab, cerca tutte le directory denominate ".SPAM" nel percorso sopra indicato, e ne "processa" il contenuto, passando le mail che ci sono dentro a Spamassassin per insegnargli che questo e` spam, dopodiche` cancella le email in questione. In pratica cosi` facendo l'utente deve solo spostare lo spam che riceve nella cartella SPAM, e il sistema provvedera` ad imparare che quelle mail sono spam, e poi a cancellarle. Questo e` lo script {{{/usr/local/sbin/sa-learn-from-maildir}}}: {{{ #! /bin/sh # insegna a spamsassassin leggendo la mail dai folder imap. # adattato dallo script originale che si trova qui: http://wiki.yobi.be/wiki/Spamassassin [ -x /usr/bin/sa-learn ] || exit 0 # Cerco i folder di nome "SPAM" (che diventa ".SPAM") all'interno del root # folder di ogni utente (per questo uso il maxdepth). Non cercare oltre # questa profondita` velocizza il processo, e a me sta bene avere il folder SPAM sotto la root # per ogni utente e non dove pare a lui. for i in $(find /var/vmail/ -maxdepth 3 -name .SPAM -type d); do if [ -d $i/cur ]; then # Get the mails to train spamassassin for f in $i/cur/*; do if [ -e $f ]; then # Debian-exim does not have read access to the mails so we pipe them cat $f|su - -s /bin/bash Debian-exim -c "sa-learn --spam" |grep -v "Learned tokens from" rm -f $f fi done fi; done exit 0 }}} Questo script va reso eseguibile da root, e poi richiamato da cron, tipo cosi`: {{{ # learn dello spam ogni ora 15 * * * * root /usr/local/sbin/sa-learn-from-maildir }}} == Configurazione degli utenti dei domini virtuali == 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". 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: * '''virus''' "virus=off" disattiva il check antivirus, qualsiasi altro valore o l'assenza della variabile lo attiva * '''smap_smtp_deny''' indica la soglia alla quale il messaggio deve essere rifiutato a livello smtp. Occorre ricordare che questa soglia e` uguale al punteggio di spamassassin moltiplicato per 10 (quindi il classico "5" di default vale 50) * '''spam_blackhole''' indica la soglia alla quale il messaggio viene buttato via senza segnalare nulla al mittente ne` al destinatario. Anche qui come sopra la soglia va moltiplicata per 10. * '''spam_subject''' indica la soglia alla quale il subject va modificato per inserirvi una indicazione del fatto che la mail e` considerata spam. Anche qui come sopra la soglia va moltiplicata per 10. * '''spam_folder''' indica il nome del folder imap nel quale va salvato lo spam qualora si usi una configurazione dove lo spam viene marcato dal sistema ma non rifiutato. Nota che qui non va inserita una soglia numerica, la soglia e` determinata a livello di sistema. * '''ratelimit_time''' indica l'intervallo di tempo nel quale si applica il limite al numero di email inviate dall'utente. Va indicato apponendo al numero una lettera che indica ore (h), minuti (m), secondi (s). Per esempio, "5m" sono 5 minuti. * '''ratelimit_limit''' indica il numero massimo di email che l'utente puo` inviare nell'unita` di tempo impostata in ratelimit_time. Quello che segue e` un esempio di file di configurazione per un dominio, contenente diversi utenti con diversi parametri. {{{ utente1:password1:virus=off utente2:password2:spam_smtp_deny=50 spam_blackhole=50 spam_subject=20 utente3:password3 utente4:password4:spam_subject=20 spam_blackhole=50 utente5:password5:spam_folder=Junk }}} Nei nomi utente e nelle password NON SI POSSONO USARE i ":" che sono riservati alla separazione dei campi fra loro. == Configurazione degli alias dei domini virtuali == Per avere degli alias nel dominio virtuale "pippo.com", occorre creare un file {{{/etc/vmail/aliases/pippo.com}}}. Questo file contiene un alias seguito da ":" e poi da tanti indirizzi mail quanti si vuole, sia appartenenti al dominio che no, eventualmente seguiti da ":" e dalla variabile "spam_smtp_deny=xx" per decidere a quale soglia rifiutare lo spam diretto all'alias a livello SMTP (vedasi la spiegazione del controllo dello spam e dei virus e delle relative limitazioni). Tutti gli indirizzi mail a destra del ":" vanno necessariamente messi completi di dominio, anche se si riferiscono al dominio locale. Una riga contenente "*:" alla fine del file ridirige qualsiasi indirizzo che non sia stato precedentemente elencato o che non esista come utente (quindi qualsiasi indirizzo "sbagliato") agli utenti indicati a destra del ":". E` possibile anche usare il file degli alias per eseguire delle pipe a script, i quali ricevono la mail in stdin. E` importante ricordarsi che gli script non devono dare output, altrimenti questo output torna come mail al mittente, e che devono avere exit code 0, altrimenti Exim considera la mail come non consegnata. Suggerisco a riguardo di studiare la documentazione di Exim. Nella definizione di un alias che manda a una pipe, si usa il formato "|/path/to/script" come destinatario. Di default lo script viene eseguito con l' utente Debian-exim, gruppo Debian-exim (che e` quello con cui gira Exim). Volendo eseguirlo con un utente diverso, e` possibile definire i parametri aggiuntivi pipe_user e pipe_group, come si puo` vedere nell'esempio (indirizzo "script2"). Per esempio: {{{ gigi: luigi@pippo.com info: luigi@pippo.com, ubaldo@pippo.com, clodovalvolo@altrodominio.it:spam_smtp_deny=60 script1: |/opt/applicazione/script1.pl script2: |/opt/applicazione/script2.pl : pipe_user=utente pipe_group=gruppo *: poveroutentecheleggetuttalamailconindirizzierrati@pippo.com }}} == Configurazione degli alias di dominio dei domini virtuali == Per finire, e` possibile indicare dei domini come "alias" di altri domini. Poniamo che una ditta abbia "pippo.com", "pippo.it" e "pippo.info". dopo aver definito tutti gli utenti e gli alias in "pippo.com", se vuole che gli stessi identici utenti siano raggiungibili anche sugli altri domini che ha, puo` creare un file {{{/etc/vmail/domain_aliases}}} e metterci dentro tante righe ognuna delle quali contiene a sinistra dei ":" il dominio a cui arriva la mail e a destra il dominio (uno solo!) a cui deve essere ridiretta. Anche in questo caso e` possibile indicare come terzo parametro il comportamento che si vuole ottenere dall'antispam. Per esempio: {{{ pippo.it:pippo.com pippo.info:pippo.com:spam_smtp_deny=60 }}} Va notato che in questo caso non e` necessario che esistano files di utenti per i domini "ausiliari" (pippo.it e pippo.info) dentro a {{{/var/vmail/users}}}, tuttavia se esiste un file di utenti per uno di questi domini, all'arrivo di una mail per questo dominio il sistema prima verifichera` se esiste l' utente destinatario della mail nel file degli utenti, e se esiste gli mandera` la mail, poi se non lo trova ridirigera` la mail secondo il file domain_aliases all'utente omonimo in "pippo.com". == 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.) 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. == Auto daily alias == In questa configurazione, su suggerimento di Nutella, ho inserito un router di nome "auto_daily_alias" che ha lo scopo di accettare, giorno per giorno, qualsiasi indirizzo di un utente di un dominio locale (niente alias, solo utenti) seguito da un meno (-) e dalla data odierna in formato "ggmmaaaa". Per esempio, il giorno 29/8/2006 se mando una mail a "pippo-29082006@dominio.it" questa mail arrivera` a "pippo@dominio.it". Il giorno dopo, pero`, questo indirizzo non sara` piu` valido. L'idea e` che se dovete iscrivervi a qualche servizio che richiede un indirizzo mail di verifica, e volete pero` che non vi spammino a morte per i prossimi 50 anni, potete fornirgli un indirizzo che e` valido solo fino alla mezzanotte di oggi e poi mai piu`. Questo servizio e` disponibile automaticamente per tutti gli utenti dei domini virtuali. == Autoreply == 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//}}} (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. == Black e white lists == E` possibile creare una white list di hosts remoti dai quali si accetta sempre la mail, questa e` composta da un file con un host per riga. Il file si chiama /etc/exim4/white.list (a meno che non venga modificato il suo nome in exim4.conf) e in sua assenza la funzione e` disattivata. Allo stesso modo e` possibile creare una black list di host dai quali non accettiamo MAI la mail, in NESSUN CASO. Il file si chiama /etc/exim4/black.list. E` possibile inoltre creare una lista di indirizzi locali (destinatari delle mail) ai quali la mail viene recapitata comunque, saltando tutti i controlli sulle RBL e sullo spam (ma non sui virus). Questi indirizzi vanno indicati, uno per riga, nel file /etc/vmail/allowed_recipients. == Configurazione filtri per gli utenti dei virtuali == E` possibile impostare dei filtri per gli utenti dei domini virtuali, nella forma di "forward files" o di filtri (Exim filter o Sieve Filter) creando un file per ogni utente, con nome {{{/etc/vmail/filters//}}}. Questi files, che e` opportuno per motivi di sicurezza che NON siano creabili dagli utenti stessi ma solo dal sysadmin, possono servire per qualsiasi cosa si possa fare con un filtro di Exim. Per come e` fatto ora il sistema, eventuali delivery su file system (file, directory o anche pipe) sono fatti dall'utente "mail" gruppo "mail", per consistenza con il delivery che viene fatto normalmente dagli utenti dei domini virtuali. (al momento ho testato solo il delivery su directory). Il motivo principale per cui ho creato questi filtri e` quello di suddividere direttamente in vari folder i messaggi in base a regole, per esempio per smistare i messaggi in vari folder IMAP a seconda della mailing list a cui appartengono. Volendo, sono disponibili una serie di variabili da usare nei filtri. Quelle "personalizzate" di questa configurazione sono: * acl_m2 Indica il punteggio di spamassassin moltiplicato per 10 * acl_m3 Contiene la descrizione breve dei test di spamassassin e dei loro risultati * acl_m4 Contiene l'oggetto della mail con "[SPAM]" aggiunto in testa * acl_m5 Contiene il valore "1" se uno qualsiasi dei controlli antispam nel sistema (mittente, RBL, soglia di sistema di spamassassin) ha dato esito positivo (la mail e` considerata spam), altrimenti non e` proprio settata. Un esempio di filtro per dividere i messaggi in folders e` questo: (ovviamente vanno messi a posto i path con i dati giusti al posto di e ) {{{ # Exim filter # Questo e` sempre bene metterlo per evitare loops in caso di errori. if error_message then finish endif # Check se il list_id e` "xxx" allora scrivi nel folder della lista "xxx" if $header_List-id: contains "xxx xxx xxx" then save /var/vmail///.Lista_XXX/ endif # Qui si possono mettere altri check per altre liste }}} == Tweaks generali del sistema == Se usate findutils (locate e updatedb) e` il caso di configurare updatedb in modo da ignorare le directory contenenti le maildir per non affogarlo in migliaia di files inutili. Vedasi il file {{{/etc/updatedb.conf}}}. == Statistiche == Nutella mi passa questo suggerimento per le statistiche: {{{ exigrep -l "virtualdomain.com" /var/log/exim/exim_mainlog | eximstats -options-of-your-choice > reportfile }}} Per fare statistiche sullo spam fermato dai vari sistemi (spamassassin, RBL, eccetera) si possono usare comandi del tipo: {{{ exigrep -l "sorbs" /var/log/exim4/mainlog.* | wc }}} Mettendo il dominio della lista (per esempio "sorbs", o "spamhaus") per identificare i messaggi bloccati dalle varie RBL; il risultato va diviso per 2. Per i messaggi bloccati dal spamassassin su puo` usare la stringa "spam score too high"; in questo caso il risultato va diviso per 3. Per i messaggi contenenti virus si puo` usare la stringa "This message contains a virus"; il risultato va diviso per 2. == Pulizia delle maildir PERICOLOSO == ''' questi script sono potenzialmente pericolosi, vanno rivisti e si puo` usare doveadm. questa roba e` obsoleta NON USATELA ''' Per tenere piu` o meno pulite le mie maildir, uso degli script banali messi in cron: il primo ha lo scopo di cancellare (solo da un account specifico) tutte le mail piu` vecchie di 180 giorni, e usa archivemail per farlo. Tra l'altro, archivemail puo` anche essere usato per archiviare (e non cancellare e basta, che e` come dire archiviare nel gufo) le mail. Questa che segue e` una riga in {{{/etc/crontab}}} {{{ # pulizia delle mailbox dell'account bofh, la roba viene cancellata dopo 180 giorni 30 03 * * 7 mail archivemail --delete /var/vmail/kurgan.org/bofh/.* }}} Il secondo script cancella le mail marcate come "cancellate" dal client IMAP. Attenzione: non sono sicuro che funzioni sempre e non sono sicuro che non cancelli roba che non deve cancellare, perche` non so se la regexp sia perfetta oppure ogni tanto si perda qualcosa, o peggio includa qualcosa che non deve. Suggerisco di usare (in dovecot 2.x) il comando doveadm che ha una funzione apposta. Devo ancora studiarlo a fondo, pero`. {{{ # pulizia delle mail marcate per la cancellazione 40 03 * * 7 mail find /var/vmail/ -regex ".*:.*,.*T.*[a-z]$" -type f -exec rm \{} \; }}} Un altro script puo` essere utile se si vuole cancellare automaticamente la roba dalla directory imap ".Spam", supponendo che gli utenti abbiano la configurazione che riceve lo spam e lo salva in quella directory. {{{ # Eliminazione dello spam dopo 15 giorni 30 22 * * * mail find /var/vmail/ -type d -name .Junk -exec archivemail --delete --quiet -d 15 \{} \; }}} == Configurazione di Exim per uno smarthost == Se si vuole che Exim mandi la mail tramite uno smarthost e non direttamente, occorre andare nella sezione "routers" del file exim.conf, commentare tutto il primo router in alto, chiamato "dnslookup" e sostituirlo con questo qui sotto. In questo esempio lo smarthost e` "smtp.pappappero.it", ovviamente occorre mettere lo smarthost che si vuole usare. {{{ smarthost: driver = manualroute domains = ! +local_domains : ! $primary_hostname : ! localhost : ! lsearch;VIRTUALS/domain_aliases transport = remote_smtp route_list = * smtp.pappappero.it no_more }}} Se si vuole mandare mail via smarthost solo per alcuni domini, e` possibile farlo inserendo due router in sequenza: lo smarthost prima e poi il dnslookup. La parte del dnslookup non e` modificata rispetto a quella che trovate nel file di configurazione "standard" allegato a questa pagina del wiki. Questo e` un esempio per mandare la mail a tiscali (ed altri due domini, separati da ":") attraverso lo smarthost "smtp.pappappero.it" e al resto del mondo direttamente: {{{ smarthost: driver = manualroute domains = tiscali.it : secondodominio.it : terzodominio.com transport = remote_smtp route_list = * smtp.pappappero.it no_more dnslookup: driver = dnslookup domains = ! +local_domains : ! $primary_hostname : ! localhost : ! lsearch;VIRTUALS/domain_aliases transport = remote_smtp ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 no_more }}} == Configurazione per uno smarthost autenticato == Per mandare mail tramite uno smarthost autenticato la procedura e` allucinantemente complessa. Occorre modificare diverse configurazioni: * Quella dell'autenticatore (o degli autenticatori) che useremo. * Il router relativo allo smarthost (e` quello che abbiamo visto appena qui sopra) * Il trasporto SMTP usato dal router dello smarthost Prima di tutto occorre indovinare quali autenticatori piacciono al remoto. Si puo` chiederlo con uno "ehlo xxx" al remoto e vedere che sistemi di auth gradisce. Dopo averlo scoperto, occorre modificare un autenticatore fra quelli locali in modo da includere una configurazione "client", in quanto nella config che uso gli autenticatori sono configurati solo come "server". A seconda di quali autenticatori vogliamo modificare, cambia la sintassi da usare, giusto per rendere le cose piu` facili. Veniamo al dunque: prendendo come esempio quello precedente (smtp.pappappero.it) dovremo: * Modificare il trasporto "remote_smtp" aggiungendo una riga che dice: {{{ hosts_require_auth = smtp.pappappero.it }}} * Creare e un autenticatore con username e password da usare in modo "client". Ecco alcuni esempi di autenticatori client: {{{ cram: driver = cram_md5 public_name = CRAM-MD5 client_name = username client_secret = password plain: driver = plaintext public_name = PLAIN client_send = ^username^password login: driver = plaintext public_name = LOGIN client_send = : username : password }}} '''Nota bene:''' In Exim gli autenticatori possono essere di tipo "server", di tipo "client" o tutti e due i tipi assieme. Per esempio gli autenticatori con driver "dovecot" sono solo di tipo server, mentre quelli con driver "plaintext" sono sia client che server. Non si deve definire due volte un autenticatore con lo stesso public_name (una volta server e una client) se il suo driver supporta tutte e due le funzioni, altrimenti si crea un conflitto. In altri termini: se vi serve un autenticatore che faccia sia funzioni client che funzioni server, e il suo driver supporta tutti e due i modi, esso va definito una sola volta, con i parametri di configurazione indicati sia per la funzione server che per quella client. Altrimenti se ne definiscono due diversi anche con lo stesso public_name. Per esempio, se per la funzione server usiamo il driver dovecot, per la funzione client possiamo (e dobbiamo) definire un autenticatore separato con il driver plaintext (o altro driver) avendo cura di non settare nessun parametro server. == Conversione mailbox in maildir == Se dovesse servire convertire delle mailbox da un vecchio server in maildir, si puo` fare con mb2md. Prima di tutto installare il pacchetto {{{mb2md}}} e quindi convertirle con la sintassi: {{{ mb2md -s /file/della/mailbox -d /var/vmail/dominio/utente }}} Attenzione: la destinazione deve essere per forza un path completo, e lo script va eseguito da utente mail altrimenti i files generati nelle maildir sono di root e poi mail (ovvero dovecot) non puo` piu` modificarli. == 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). * ''' 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/ 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. * Pare che Dovecot, quando autentica su file di testo, si incasini se nello username c'e` un underscore, e in questo caso non riconosca piu` la password (anzi, attenzione, che accetta una password VUOTA!). Occorre indagare nei sorgenti di Dovecot, quando ne avro` voglia... cioe` mai. Apparentemente questo comportamento non e` sempre vero. In alcuni casi l'ho visto funzionare bene. Non sono sicuro che questo bug ci sia davvero o che dipenda da qualche casino esterno (file di config corrotti?) * ''' BUG RISOLTO, almeno spero:''' Devo modificare la configurazione separando la lista "+local_domains" in due parti, una per i domini veramente locali (la macchina stessa, o localhost) e uno per i virtuali, avendo cura di correggere dappertutto nella config dove occorre che appaiano tutti e due i "tipi" di domini, e dove solo l'uno o solo l'altro. Mi sono accorto di questo problema perche` ci sono errori nel panicolog se qualcuno cerca di mandarmi una mail a "tizio@localhost" o simili cazzate. Non crea problemi, ma fa` errori che finiscono nel paniclog ed e` fastidioso.