Guida operativa basata su un caso verificato. Flusso di invio Roundcube → Postfix → Amavis → Gmail verificato con risposta SMTP 250 e TLSv1.2.
Problema da verificare
Quando un utente segnala che la posta inviata da Roundcube non arriva, il primo passo è seguire il messaggio attraverso tutte le fasi. La comparsa del messaggio nella cartella Inviati non è una prova di recapito al provider remoto.
Catena di consegna
La pipeline nel caso documentato era Roundcube → submission Postfix → filtro Amavis → Postfix in uscita → server MX destinatario. La diagnostica corretta associa tutti i log tramite il queue ID, anche quando il filtro introduce un nuovo ID.
Verifica dei log
grep 'QUEUE_ID' /var/log/mail.log
postqueue -p
postconf -n | grep -E 'content_filter|relayhost|smtp_tls'
# Se journald gestisce i log:
journalctl -u postfix --since '30 minutes ago' --no-pagerChe cosa dimostra la risposta 250
Nei log dell'intervento una connessione cifrata TLSv1.2 è terminata con dsn=2.0.0, status=sent (250 2.0.0 OK). Questa è la prova dell'accettazione da parte dell'MX remoto, non della successiva classificazione Inbox/Junk.
Controllare anche autenticazione e reputazione
Per SPF, DKIM e DMARC serve analizzare gli header ricevuti, non soltanto il log Postfix. Nel caso non era disponibile nello stesso test una prova di dkim=pass; non va dedotta da status=sent.
Lezione
Separare il trasporto SMTP, il filtro antispam e la consegna nella casella. Le verifiche aiutano a evitare modifiche inutili a Postfix quando il problema riguarda invece filtri del provider destinatario.
Approfondimenti correlati
Comandi e percorsi riportano segnaposto generici; verificare versioni e backup prima di applicarli in produzione.