Differences

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

--- doc:appunti:linux:sa:postfix [2018/02/27 12:48] – [Rimuovere messagi dalla coda] niccolo
+++ doc:appunti:linux:sa:postfix [2024/02/26 10:18] (current) – [Socket in /var/run/ e nel chroot di Postfix: problema con tmpfs] niccolo
@@ Line 116: / Line 116: @@
 In questo caso l'aggiunta di un dominio **richiede il reload di Postfix**, mentre l'aggiunta di un alias richiede solo la ricompilazione del **''virtual_alias_maps.db''**.
+==== Problema virtual_alias_domains, myorigin e mydestination ====
+Dopo che un indirizzo è stato valutato come locale (quando il dominio è contenuto in **virtual_alias_domains**), viene consultata la **virtual_alias_maps** per identificare l'**account Unix** a cui consegnare il messaggio. La mappa contiene infatti righe di questo tipo:
+<file>
+nome.cognome@domain.tld    login_name
+</file>
+A tutti gli effetti si ha quindi un **destinatario locale non qualificato**; in questo caso il destinatario viene qualificato automaticamente con **$myorigin**, diventando l'indirizzo **%%login_name@$myorigin%%**. È quindi necessario che **$myorigin** sia contenuto in **$mydestination** perché la consegna venga effettuata.
+Il pacchetto Postfix di Debian configura **myorigin = /etc/mailname** e giustamente mette lo stesso mailname anche in **mydestination**. Se però si desidera un **virtual domain con lo stesso nome**, otterremo il seguente warning nei file di log:
+<file>
+warning: do not list domain mydomain.org in BOTH mydestination and virtual_alias_domains
+</file>
+Se esiste un virtual domain con quel nome, la soluzione più corretta è utilizzare un **nome ad-hoc** per **myorigin** e aggiungerlo **mydestination**:
+<file>
+#myorigin = /etc/mailname
+myorigin = mail.mydomain.org
+mydestination = mail.mydomain.org localhost.localdomain localhost
+</file>
+:!: **ATTENZIONE 1**: Il contenuto di **myorigin** viene usato anche per qualificare l'//envelope sender// dei messaggi generati automaticamente (ad esempio dal tool ''vacation''). È opportuno quindi che si tratti di un dominio completo, altrimenti è probabile che il messaggio venga rifiutato dal ricevente con l'errore **//Sender address rejected: need fully-qualified address//**. Non è strettamente necessario che si tratti di un dominio che riceve mail (cioè con record MX), in genere dovrebbe essere sufficiente che un mittente valido sia indicato nell'header ''From:''.
+:!: **ATTENZIONE 2**: Il contenuto di **myorigin** viene usato anche per qualificare i messaggi di errore **MAILER-DAEMON@**, è opportuno quindi che consenta di individuare il sistema di origine piuttosto che un dominio email. Quindi anche in questo caso si suggerisce di usare qualcosa del tipo ''mail.mydomain.org''.
 ===== Crittografia TLS =====
@@ Line 207: / Line 236: @@
 </code>
-===== Autenticazione SMTP =====
+===== Autenticazione SMTP con SASL su PAM =====
+Questa autenticazione si basa sul sistema PAM (in pratica loing e password di **/etc/shadow**) tramite il demone **/usr/sbin/saslauthd**. La catena di autenticazione è la seguente:
+  *  Postfix => saslauthd => PAM => /etc/shadow
+Questa implementazione è fornita dal pacchetto **sasl2-bin** e va sotto il nome **Cyrus SASL**. In alternativa è possibile appoggiare Postfix all'autenticazione **Courier** oppure a quella **Dovecot**, si tratta di sistemi POP/IMAP che offrono possibilità aggiuntive, come quella di poter fare l'autenticazione con utenti virtuali usando l'indirizzo email invece del login Unix. Per istruzioni su queste due alternative vedere **[[#autenticazione_smtp_su_courier_authdaemon|Autenticazione SMTP su Courier Authdaemon]]** oppure **[[postfix_spamassassin_clamav_dovecot#postfix_sasl_over_dovecot_auth|Postfix SASL su Dovecot]]**.
 Installare i pacchetti **sasl2-bin** e **libsasl2-modules**.
@@ Line 223: / Line 258: @@
 <code>
-/etc/init.d/saslauthd stop
+systemctl stop saslauthd.service
 rmdir /var/run/saslauthd
+mkdir -p /var/spool/postfix/var/run/saslauthd
+chown root:sasl /var/spool/postfix/var/run/saslauthd
+chmod 0710 /var/spool/postfix/var/run/saslauthd
 ln -s /var/spool/postfix/var/run/saslauthd /var/run
-/etc/init.d/saslauthd start
+systemctl start saslauthd.service
 </code>
@@ Line 269: / Line 307: @@
 </file>
-Riavviare postfix con ''/etc/init.d/postfix restart''.
+Riavviare postfix con ''systemctl restart postfix.service''.
 Verificare che l'autenticazione sia annunciata, deve comparire la stringa **''AUTH LOGIN PLAIN''**:
@@ Line 309: / Line 347: @@
 Il parametro di cui sopra è implicito se si attiva **''smtpd_tls_security_level = encrypt''**.
 ===== Autenticazione SMTP su Courier Authdaemon =====
+**ATTENZIONE**: se si utilizza l'**autenticazione Dovecot** invece di **Courier**, la configurazione è diversa (e anche un po' più semplice), vedere **[[postfix_spamassassin_clamav_dovecot#postfix_sasl_over_dovecot_auth|Postfix SASL over Dovecot Auth]]**.
 Postfix può utilizzare l'autenticazione fornita da **Courier Authdaemon** invece di appoggiarsi al demone **''saslauthd''** e al sottostante sistema //PAM//. Questo può tornare utile ad esempio se è attiva l'autenticazione **''/etc/courier/userdb''** che utilizza l'indirizzo di posta elettronica come login, al posto dello username Unix.
@@ Line 320: / Line 360: @@
 </file>
-**ATTENZIONE:** Postfix (da **Debian 5 Lenny** in poi) gira in ambiente chroot (**''/var/spool/postfix/''**), così anche ''saslauthd''; pertanto il socket di Authdaemon deve trovarsi in esso. Questa ricetta è stata verificata su **Debian 9 Stretch**, verificare il proprietario e i permessi di ''/var/run/courier/authdaemon'' e aggiustare di conseguenza.
+**ATTENZIONE:** Postfix (da **Debian 5 Lenny** in poi) gira in ambiente chroot (**''/var/spool/postfix/''**), così anche ''saslauthd''; pertanto il socket di Authdaemon deve trovarsi in esso. La directory ''authdaemon'' appartiene a **''courier:courier''** (almeno in Debian Stretch), nel nostro caso deve essere accessibile a saslauthd che viene eseguito da postfix.
+Questa ricetta è stata verificata su **Debian 9 Stretch**, verificare il proprietario e i permessi della directory originale ''/var/run/courier/authdaemon'' prima di spostarla nel chroot e aggiustare di conseguenza. Ad esempio per Debian 8 Jessie sostituire gruppo e utente //courier// con //daemon//.
 <code>
@@ Line 328: / Line 370: @@
 chmod 0755 /var/spool/postfix/var/run/courier/authdaemon/
-dpkg-statoverride --add courier courier 755 /var/spool/postfix/var/run/courier/authdaemon
+dpkg-statoverride --add courier courier 750 /var/spool/postfix/var/run/courier/authdaemon
 adduser postfix courier
 </code>
-La directory ''authdaemon'' appartiene a **''courier:courier''** (almeno in Debian Stretch), nel nostro caso deve essere accessibile a saslauthd che viene eseguito da postfix.
 È necessario rendere disponibile il socket sia alla **posizione originale** (per i servizi Courier POP/IMAP) sia nel **chroot di Postfix**. Il sistema più moderno è un **mount bind**. Invece di aggiungere una entry in ''/etc/fstab'', vedere più avanti come montare in automatico la directory con il sistema di init **systemd**.
@@ Line 352: / Line 392: @@
 ==== Socket in /var/run/ e nel chroot di Postfix: problema con tmpfs ====
+Per **Debian 12 Bookworm** vedere la pagina dedicata **[[postfix_courier_authdaemon_debian_12]]**.
 Nelle moderne distribuzioni Debian (da 7 Wheezy in poi) la directory **''/var/run/''** viene creata in tmpfs e quindi al reboot è totalmente vuota. Questo è un problema perché la soluzione con il link simbolico vista al paragrafo precedente non sopravvive al reboot. Una soluzione poco elegante è modificare lo script **''/etc/init.d/courier-authdaemon''**, in modo che crei il link prima di avviare il servizio; inoltre questo è sconsigliato se si utilizza il moderno **systemd** (a partire da Debian 8 Jessie).
-Quindi la **soluzione ottimale** è utilizzare un **mount bind** della directory che contiene il socket e **incaricare systemd** di effettuare il mount prima di avviare Postfix. Il punto di montaggio deve essere creato come visto nel paragrafo precedente, la //mount unit// va creata in **/etc/systemd/system/**, deve avere il nome esatto **var-spool-postfix-var-run-courier-authdaemon.mount** e contiene:
+La **soluzione ottimale** è utilizzare un **mount bind** della directory che contiene il socket e **incaricare systemd** di effettuare il mount prima di avviare Postfix. Il punto di montaggio deve essere creato come visto nel paragrafo precedente, la //mount unit// va creata in **/etc/systemd/system/**, deve avere il nome esatto **var-spool-postfix-var-run-courier-authdaemon.mount** e contiene:
 <file>
 [Unit]
 Description=Mount Courier Authdaemon into Postfix chroot
-Requires=courier-authdaemon.service
+Wants=courier-authdaemon.service
-After=courier-authdaemon.service
+# A stronger dependency may cause a Systemd ordering cycle problem.
+#Requires=courier-authdaemon.service
+#After=courier-authdaemon.service
 [Mount]
@@ Line 381: / Line 425: @@
 Al successivo reboot troveremo il socket authdaemon disponibile nel chroot di Postfix.
-===== Smarthost =====
+===== Smarthost (relayhost) =====
 Per consegnare tutta la posta in uscita ad un relay SMTP si aggiunge in **''/etc/postfix/main.cf''**:
 <file>
-relayhost = smtp.example.org
+relayhost = smtp.example.org:587
 </file>
-Se lo smarthost richiede autenticazione con login e password questi sono i parametri necessari:
+Nell'esempio sopra si utilizza il servizio **submission** sulla porta **TCP/587**, se non viene specificata la porta verrà utilizzato **snmp** su porta **TCP/25**.
+**ATTENZIONE**: secondo le specifiche più recenti ([[https://tools.ietf.org/html/rfc6409|RFC 6409]]) l'invio autenticato deve avvenire sulla porta **submission**, pertanto molti server di posta non accettano più l'autenticazione sulla porta **smtp**. Se il server che funge da relayhost è basato su Postfix, la necessità dell'autenticazione è determinata dal parametro **smtpd_sasl_auth_enable**. Esso viene impostato in **main.cf** relativamente al servizio **smtp** oppure in **master.cf** relativamente al servizio **submission** (nella apposita sezione), se il relayhost vuole rifiutare il submission ai client non autenticati, deve usare l'opzione ''smtpd_client_restrictions=permit_sasl_authenticated,reject''.
+Lo smarthost generico viene dichiarato con questa direttiva:
 <file>
 relayhost = smtp.example.org
+</file>
+Se lo smarthost richiede autenticazione con login e password, questi sono i parametri necessari a configurare Postfix come client. Gli stessi parametri sono necessari ogni qual volta Postfix deve agire come client autenticato, ad esempio quando si stabiliscono dei transport specifici per sender o per recipient.
+<file>
+# Enable SASL authentication in the Postfix SMTP client.
 smtp_sasl_auth_enable = yes
+# Credentials for SASL authentication to remote hosts.
 smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+# Filter the remote SMTP server's list of offered SASL mechanisms.
 smtp_sasl_mechanism_filter = plain, login
-smtp_sasl_security_options =
+# We use (encrypted) plaintext passwords; the default is noplaintext, noanonymous.
+smtp_sasl_security_options = noanonymous
+# The default SMTP TLS security level for the Postfix SMTP client: may or encrypt.
 smtp_tls_security_level = may
 </file>
-L'opzione **''smtp_tls_security_level''** definisce se deve essere usata una connessione TLS.
+L'opzione **smtp_tls_security_level** definisce se deve essere usata una connessione crittografata TLS; con **may** è facoltativa, per renderela obbligatoria va impostato su **encrypt**. È possibile rendere la cifratura obbligatoria solo se siamo certi che la nostra installazione agirà da client verso server che dispongono tutti di TLS, può essere il caso se utilizziamo sempre un solo relayhost. Ad oggi (fine 2023) una buona percentuale di mail exchanger primari (MX di domini mail) non supportano alcuna crittografia.
+Ricordarsi che per utilizzare SSL si deve installare il pacchetto **libsasl2-modules**.
+L'opzione **smtp_sasl_mechanism_filter** non è strettamente necessaria in quanto abbiamo già definito la lista meccanismi supportati in **/etc/postfix/sasl/smtpd.conf**, che sono ''mech_list: PLAIN LOGIN''.
+L'opzione **smtp_sasl_security_options** deve essere specificata, altrimenti il valore predefinito **noplaintext, noanonymous** impedirebbe di usare il //mechanism plain// (viene effettivamente trasmessa la password, ma su canale cifrato).
 Le credenziali per l'autenticazione vanno messe nel file **''/etc/postfix/sasl_passwd''** che deve essere compilato con **''postmap''**:
 <file>
-smtp.example.org login:password
+smtp.example.org login_name:password
+</file>
+Se non si installa il pacchetto **libsasl2-modules** l'errore nei log è qualcosa di simile:
+<file>
+warning: SASL authentication failure: No worthy mechs found
+SASL authentication failed; cannot authenticate to server smtp.example.org[10.11.12.13]: no mechanism available
 </file>
@@ Line 445: / Line 516: @@
 somedomain.com         OK
 </file>
+===== Esempio di RBL zen.spamhaus.org =====
+In generale le RBL (real-time blackhole list) sono in effetti delle **[[wpit>DNSBL|DNS-based Blackhole List]]** cioè utilizzano il meccanismo del DNS per scoprire se un indirizzo IP è nella blacklist o meno.
+Il funzionamento di **zen.spamhaus.org** è spiegato nella pagina **[[https://www.spamhaus.org/faq/section/DNSBL%20Usage#366|Frequently Asked Questions]]**, vediamo ad esempio come verificare lo stato dell'indirizzo IP **194.44.61.82**. Anzitutto si deve invertire l'ordine degli ottetti e fare una query DNS sul nome **82.61.44.194.zen.spamhaus.org**. È possibile effettuare da riga di comando Unix una richiesta per un **record di tipo A** (è la richiesta che effettua in automatico Postfix):
+<code>
+dig +short 82.61.44.194.zen.spamhaus.org @dns.provider.tld
+.0.0.4
+.0.0.3
+</code>
+anzitutto notiamo che la richiesta è stata inoltrata al server DNS **dns.provider.tld**, la risposta è stata positiva, con ben due risultati. I codici 127.0.0.x sono in effetti una convenzione di ciascuna RBL per significare lo stato dell'indirizzo IP; nel nostro caso risulta elencato sia in **Spamhaus SBL CSS** che in **CBL**.
+Per avere un responso più descrittivo è possibile chiedere il **record di tipo TXT**:
+<code>
+dig +short -t TXT 82.61.44.194.zen.spamhaus.org @127.0.0.1
+"https://www.spamhaus.org/query/ip/194.44.61.82"
+"https://www.spamhaus.org/sbl/query/SBLCSS"
+</code>
+Attenzione al server DNS utilizzato! Alcuni server DNS pubblici e gratuiti (specificatamente quello di **Google 8.8.8.8**) non rispondono a questo tipo di query. Purtroppo un risultato negativo viene interpretato da Postifix come //indirizzo IP pulito//. È opportuno installare un server DNS locale per una maggiore efficienza delle interrogazioni.
+===== smtpd_sender_restrictions =====
+FIXME: Unificare con il paragrafo successivo.
 Se si gestiscono numerosi domini locali è possibile fare un controllo sull'esistenza dell'indirizzo mittente, in pratica si rifiutano messaggi che hanno un mittente inesistente. Questo controllo è opportuno farlo **solo per i domini locali**, perché richiede un'interrogazione al server MX del mittente: host remoti potrebbero non gradire continue interrogazioni.
@@ Line 461: / Line 559: @@
 ===== Restrizioni sull'indirizzo mittente =====
-Si vuole impedire l'invio di posta da parte di clienti autenticati se l'indirizzo mittente non è un indirizzo locale.
+Il controllo qui descritto va fatto solo sul servizio **submission** da parte di **connessioni autenticate** che chiedono il relay di un messaggio. Trattandosi di utenti con un account locale è possibile fare la verifica dell'indirizzo mittente e **rifiutare messaggi da parte di indirizzi non esistenti**.
+**Non è possibile** fare tale controllo sulla normale **porta SMTP** (posta in arrivo da internet), perché la verifica del mittente richiederebbe una **interrogazione sul server MX del mittente**, non sempre possibile o accettata.
 <file>
@@ Line 490: / Line 590: @@
 ^ reject                                  | Rifiuta tutti gli altri mittenti.  |
-I messaggi rifiutati saranno evidenziati nel log con i seguenti messaggi (rispettivamente per indirizzi non validi di domini locali oppure per mittenti non locali rifiutati):
+I messaggi rifiutati saranno evidenziati nel log con i seguenti errori (rispettivamente per indirizzi non validi di domini locali oppure per mittenti non locali rifiutati):
 <code>
@@ Line 497: / Line 597: @@
 </code>
+Con **Postfix 2.11** la verifica dell'esistenza di un mittente viene fatta con un meccanismo analogo al comando **VRFY** del protocollo **SMTP**, in realtà lo scambio dati avviene via **Unix socket** con il processo **verify** lanciato al bisogno (vedere la riga opportuna in **/etc/postfix/master.cf**). Il processo verify resta in esecuzione solo per un paio di minuti e produce una cache delle risposte memorizzata in **/var/lib/postfix/verify_cache.db**.
+Esiste il [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578862|bug #578862]], almeno fino a Postfix 2.11 (Debian 8 Jessie). Il file con la cache viene creato **/var/lib/postfix/verify_cache.db**, ma il processo ''verify'' esegue successivamente un ''chroot'' in **/var/spool/postfix/** e pertanto produce un errore poiché tenta di chiudere l'inesistente file **/var/spool/postfix/var/lib/postfix/verify_cache.db**:
+<code>
+postfix/verify[22229]: close database /var/lib/postfix/verify_cache.db:
+    No such file or directory (possible Berkeley DB bug)
+</code>
+Pare che il bug non abbia conseguenze (parola dell'autore di Postfix), per chi tuttavia preferisse non vederlo è possibile risolvere con un link simbolico:
+<code bash>
+mkdir -p /var/spool/postfix/var/lib/postfix
+chown postfix.postfix /var/spool/postfix/var/lib/postfix
+cp -p /var/lib/postfix/verify_cache.db /var/spool/postfix/var/lib/postfix/
+ln -sf /var/spool/postfix/var/lib/postfix/verify_cache.db /var/lib/postfix/
+chown -h postfix.postfix /var/lib/postfix/verify_cache.db
+</code>
 ===== Restrizioni per localhost (es. PHP) =====
@@ Line 533: / Line 651: @@
-===== Relay to network =====
+===== Relay from network =====
 Per accettare la posta e farne il relay da un particolare indirizzo IP o network si usa la direttiva **mynetworks** di **''/etc/postfix/main.cf''**:
 <file>
-mynetworks = 127.0.0.0/8 192.168.2.0/24 82.61.251.143
+mynetworks = 127.0.0.0/8 192.168.2.0/24 82.61.251.143 [2b03:3610:cb00:124::1]/64
 </file>
+Notare che gli indirizzip IPv6 vanno racchiusi fra parentesi quadrate.
 ===== Modifica degli header =====
@@ Line 559: / Line 678: @@
 ===== Sender rewrite =====
-È possibile riscrivere l'indirizzo di provenienza di una mail, utile soprattutto per le mail generate in automatico da account locale, che altrimenti potrebbero avere indirizzi brutti e poco graditi ai filtri antispam, del tipo **root@localhost** oppure **nagios@hostname**.
+È possibile riscrivere l'indirizzo di provenienza di una mail, utile soprattutto per le mail generate in automatico da account locale, che altrimenti potrebbero avere indirizzi brutti e poco graditi ai filtri antispam, del tipo **root@localhost** oppure **nagios@mail.mydomain.org**.
 Postfix dispone della direttiva **''sender_canonical_maps''**; basta aggiungere in main.cf qualcosa del genere:
@@ Line 571: / Line 690: @@
 <file>
-root user@domain.tld
+root                    user@domain.tld
+root@mail.mydomain.org  user@domain.tld
 </file>
@@ Line 578: / Line 698: @@
 ===== Destinatari locali non qualificati =====
-Ad un destinatario privo di dominio (es. **backup** o **root**) viene aggiunto il dominio specificato dall'opzione **''myorigin''**, in Debian questo equivale al contenuto del file **''/etc/mailname''**.
+Ad un destinatario privo di dominio (es. **backup** o **root**) viene aggiunto il dominio specificato dall'opzione **myorigin**, in Debian questo equivale al contenuto del file **''/etc/mailname''**.
-Questa riscrittura avviene prima di applicare il contenuto di **''/etc/aliases''**. Pertanto gli alias specificati in ''/etc/aliases'' funzionano solo se il dominio specificato in ''/etc/mailname'' è uno di quelli riconosciuti come locali, cioè inclusi nell'opzione **''mydestination''**.
+Questa riscrittura avviene prima di applicare il contenuto di **/etc/aliases**. Pertanto gli alias specificati in ''/etc/aliases'' funzionano solo se il nome host specificato in ''/etc/mailname'' è uno dei domini riconosciuti come locali, cioè inclusi nell'opzione **''mydestination''**.
 ===== Messaggi di notifica a postmaster locale =====
@@ Line 606: / Line 726: @@
 </file>
-===== Delay Warning =====
+===== Relay by recipient or domain =====
-Per impostazione predefinita Postfix non avvisa dei ritardi di consegna dei messaggi, se si vuole attivare questa opzione si imposta il parametro seguente:
-<file>
-delay_warning_time = 4h
-</file>
-===== Relay domains =====
 To relay mail for non-local domains (domains not in ''mydestination'' and not in local virtual domains), use the **''relay_domains''** setting:
@@ Line 621: / Line 734: @@
 relay_domains = www.mydomain.org, mydomain.org
 </file>
+**WARNING**: The receiving mail server will eventually check the SPF record and thus the relaying server should be placed into the SPF authorized hosts for the relayed domains.
 If you want to relay mail to a specific host - eventually not the one listed in MX records - you must provide a specific **transport map**, writing a file **''/etc/postfix/transport''** with something like this:
@@ Line 640: / Line 755: @@
 user@local.domain  smtp:remote.realay.host
 </file>
+If the relay host requires authentication, you may need to configure the Postfix client behaviour, see the **[[#smarthost_relayhost|relayhost paragraph]]**.
+===== Relay by sender address =====
+It is possibile to select a different relay path for messages based on sender address. Add the directive **sender_dependent_relayhost_maps** to **main.cf**:
+<code>
+sender_dependent_relayhost_maps = hash:/etc/postfix/sender_dependent_relayhost_maps
+</code>
+Each line of the file must contain an expression matching the full sender address or the entire domain (preceeded by the **@**), and the name or address of the relay host:
+<file>
+username@rigacci.org     relay2.rigacci.org
+@domain2.org             relay3.rigacci.org
+</file>
+Remember to recompile the file whenever you change it using **postmap** (no need to reload Postfix).
+All the standard requirements for a relay host are necessary: the relay host must be listed into the **SPF record** of the mail domain and the relay host should accept the original sender (e.g. via the **mynetworks** Postfix directive).
+If the relay host requires authentication, you may need to configure the Postfix client behaviour, see the **[[#smarthost_relayhost|relayhost paragraph]]**.
 ===== HELO hostname =====
@@ Line 652: / Line 792: @@
 # If we don't have the name registered as an A record, use an IP literal:
 #smtp_helo_name = [78.47.31.140]
+</file>
+===== Lifetime dei messaggi =====
+Un messaggio che non riesca a ad arrivare a destinazione, ma che non abbia un errore fatale, resta nella coda per **maximal_queue_lifetime** (valore predefinito 5 giorni). Probabilmente 5 giorni sono troppi, perché il mittente viene notificato del problema troppo tardi. Vedere più avanti anche il parametro **delay_warning_time**.
+I messaggi di errore hanno un lifetime a parte, definito dal parametro **bounce_queue_lifetime**. Anche in questo caso il valore predefinito di 5 giorni potrebbe essere eccessivo.
+<file>
+# The message is considered undeliverable if a temporary error
+# persists for more than "maximal_queue_lifetime" (default: 5d).
+maximal_queue_lifetime = 1d
+# A bounce message becomes undeliverable if queued for more
+# than "bounce_queue_lifetime" (default: 5d).
+bounce_queue_lifetime = 6h
+</file>
+===== Delay Warning =====
+Per impostazione predefinita Postfix non avvisa dei ritardi di consegna dei messaggi, se si vuole attivare questa opzione si imposta il parametro seguente:
+<file>
+delay_warning_time = 4h
 </file>
@@ Line 761: / Line 925: @@
 <file>
-postfix-mx/anvil[919]: statistics: max connection rate 8/60s for (62.48.51.61:25:110.52.2.253) at Oct 15 23:26:21
+postfix-mx/anvil[919]: statistics:
-postfix-mx/anvil[919]: statistics: max connection count 8 for (62.48.51.61:25:110.52.2.253) at Oct 15 23:26:21
+    max connection rate 8/60s for (62.48.51.61:25:110.52.2.253) at Oct 15 23:26:21
+postfix-mx/anvil[919]: statistics:
+    max connection count 8 for (62.48.51.61:25:110.52.2.253) at Oct 15 23:26:21
 </file>
@@ Line 778: / Line 944: @@
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 </file>
+===== Debug =====
+Un sistema rapido per tracciare i problemi rispetto ad **uno o più host specifici**, è quello di aggiungere la seguente direttiva in **/etc/postfix/main.cf**, che **aumenta il livello di debug** solo per quelle specifiche connessioni:
+<file>
+debug_peer_list = 192.168.10.12 10.0.0.13 [2a01:4f8:a017:6779::1]
+debug_peer_level = 2
+</file>
+====== Problemi SSL ======
+Se un server remoto tenta di stabilire una connessione cifrata, ma incontra qualche problema, si può riscontrare questo errore nel log:
+<code>
+postfix/smtpd[1630564]: SSL_accept error from unknown[124.132.32.203]: lost connection
+</code>
+Se si ha l'impostazione **smtpd_tls_security_level = may**, il server remoto dovrebbe riprovare senza crittografia, ma in caso di server difettosi può essere impossibile ricevere mail da quell'host.
+Una soluzione temporanea può essere quella di inibire il flag STARTTLS in risposta al comando EHLO, cioè non annunciare SSL a quel particolare host. Questo comportamento si ottiene con una riga in main.cf:
+<file>
+# Discard some EHLO features for specific servers.
+# E.g. disable starttls with broken servers.
+smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/smtpd_discard_ehlo_keywords
+</file>
+E il relativo file **smtpd_discard_ehlo_keywords** che contiene effettivamente l'esclusione:
+<file>
+.132.32.203 starttls
+</file>
+Il file va compilato con postmap, ecc.
 ====== Postgrey ======
@@ Line 794: / Line 997: @@
 Le opzioni si configurano in **''/etc/default/postgrey''**. Eventuali indirizzi whitelist si aggiungono in **''/etc/postgrey/whitelist_clients''** e **''etc/postgrey/whitelist_recipients''**.
+Un messaggio rifiutato temporaneamente genera questa riga in **/var/log/maio.log**:
+<code>
+postgrey[760]: action=greylist, reason=new,
+    client_name=server.example.org, client_address=123.123.123.123/32,
+    sender=niccolo@domain.tld, recipient=user@example.org
+</code>
+Quando invece il messaggio viene accettato questo è il log:
+<code>
+postgrey[760]: action=pass, reason=triplet found,
+    client_name=server.example.org, client_address=123.123.123.123/32,
+    sender=niccolo@domain.tld, recipient=user@example.org
+</code>
+Con il tool **postgreyreport** è possibile interrogare il database di postgrey (in **/var/lib/postgrey/postgrey.db**) in relazione al **mail.log**
+<code>
+cat /var/log/mail.log | postgreyreport --show_tries
+</code>