Sto eseguendo una configurazione di test (attualmente 2.4.0.beta4) a casa su un mini-PC locale con Ubuntu 16.04 LTS. L’ho installato utilizzando l’eccellente guida all’installazione in 30 minuti. Dispone di un FQDN. L’invio di email tramite un mailbox del mio provider con SMTP sulla porta 587 e autenticazione in chiaro ha funzionato senza problemi per oltre un anno.
Ho appena realizzato di non aver ricevuto alcuna notifica via email da qualche tempo, come “nuova versione disponibile”. Controllando Amministratore > Email > Scartati, vedo che tutto viene bloccato con:
550-Bad HELO: localhost.localdomain non esiste - Si prega di consultare la RFC 2821
Ripercorrendo la cronologia del mailbox, questo problema potrebbe essere iniziato con la versione 2.4.0.beta2. Ma potrebbe anche essere dovuto a un cambiamento di policy del mio provider intorno alla stessa data (fine luglio 2019). Non sono sicuro da dove iniziare. Da dove proviene questo localhost.localdomain? Durante l’installazione ho dovuto modificare solo app.yml, e questo file mostra correttamente il mio FQDN in DISCOURSE_HOSTNAME:
Non avevo mai sentito parlare di Mailgun. Intendi mailgun.com, il “Servizio API per email transazionali”? Per darti un’idea del mio livello di conoscenza: so vagamente cos’è un’API, ma non saprei come utilizzarla. Potrei però provare a usare SMTP per inviare a un’altra casella di posta presso un altro ISP. Farò rapporto qui domani.
Mailgun fornirà le credenziali SMTP se ti registri. Sono sicuro che puoi capire tutto seguendo semplicemente le loro istruzioni durante la registrazione.
@itsbhanusharma, @jtbayly Grazie! Sono appena riuscito a inviare un messaggio di prova tramite Mailgun. Quindi il problema era una nuova policy sul server SMTP del mio ISP. Potrei continuare a usare Mailgun.
Alcuni server SMTP, come Postfix, hanno un’opzione per verificare questo rispetto all’indirizzo IP del client. localhost.localdomain si risolve nell’indirizzo IP del server SMTP; probabilmente è presente nel suo file hosts. Sembra che gli ISP stiano abilitando questa funzione nella loro battaglia contro gli spammer.
Funziona con Mailgun perché Mailgun non esegue questo controllo. Ma rimane comunque un “HELO errato”.
Per fare un confronto, ho inviato un’e-mail utilizzando un client di posta (Sylpheed) sullo stesso sistema. Funziona, anche con la casella di posta del mio ISP, e sembra utilizzare:
HELO HL80L
HL80L è il nome della mia rete locale. Non è ancora un FQDN, ma almeno non appare come un evidente falso al server del mio ISP.
Quindi forse questo è qualcosa che deve essere migliorato. Ma disclaimer: non sono un esperto di SMTP.
A proposito, l’ho fatto funzionare di nuovo tramite la casella di posta del mio ISP inserendo un MTA come relay intermedio. Si tratta di un’app basata su Postfix sul mio NAS. Utilizza HELO mydomain.tld
Controllo se abbiamo rotto qualcosa durante il passaggio a Debian 10 o l’aggiornamento a Rails 6. Nel frattempo, impostare DISCOURSE_SMTP_DOMAIN in app.yml dovrebbe funzionare. Penso che dovremmo impostare come valore predefinito quello di DISCOURSE_HOSTNAME se il dominio SMTP non è impostato esplicitamente.
Grazie, @gerhard! DISCOURSE_SMTP_DOMAIN non era presente nel mio app.yml, ma ho fatto un bel respiro profondo, l’ho aggiunto e sì, ha funzionato. Posso di nuovo utilizzare la casella di posta del mio provider. Sul lato ricevente, nell’intestazione trovo:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
Nel frattempo ho scoperto che sia la RFC 2821 che il suo successore RFC 5321, sezione 4.1.4 affermano che:
Un server SMTP PUÒ verificare che il nome di dominio nell’argomento del comando EHLO corrisponda effettivamente all’indirizzo IP del client. Tuttavia, se la verifica fallisce, il server NON DEVE rifiutare l’accettazione di un messaggio per questo motivo. Le informazioni acquisite durante il tentativo di verifica servono solo per la registrazione e il tracciamento. Si noti che questo divieto si applica solo alla corrispondenza del parametro con il suo indirizzo IP; vedere la Sezione 7.9 per una discussione più approfondita sul rifiuto di connessioni in arrivo o di messaggi di posta.
Tuttavia, molti MTA come Postfix e Exim sembrano avere ancora un’impostazione opzionale per eseguire tale verifica. Probabilmente gli amministratori la abilitano nella continua battaglia contro lo spam.
