Problema email SMTP Net::Timeout

Ciao, ho cercato di risolvere il problema SMTP ma non riesce a inviare email. Quando eseguo il comando ./discourse-doctor, ricevo un errore Net::Timeout.

Grazie in anticipo per l’aiuto.

Sezione SMTP di app.yml

DISCOURSE_SMTP_ADDRESS: plesk.oxide.host
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: no-reply@kyekillerbot.xyz
DISCOURSE_SMTP_PASSWORD: password
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opzionale, valore predefinito true)
DISCOURSE_SMTP_AUTHENTICATION: login

Ho provato telnet, ma si connette con successo al dominio SMTP.

Hai provato a commentare questa riga? Non credo che la porta 465 supporti STARTTLS.

Per quanto riguarda la porta 465, vedi RFC8314

Secondo questa RFC, sia la porta 465 che la 587 sono porte valide per un agente di invio SMTP (MSA).

La porta 465 richiede la negoziazione di TLS/SSL all’avvio della connessione, mentre la porta 587 utilizza STARTTLS se si sceglie di negoziare TLS.

Il registro IANA è stato aggiornato per consentire l’uso legittimo della porta 465 per questo scopo.

Per un relay di posta SMTP, viene utilizzata solo la porta 25, quindi STARTTLS è l’unico modo per implementare TLS con il relay della posta.

@kyekiller, dovresti provare a impostare questa opzione (su false) se intendi utilizzare la porta 465:

DISCOURSE_SMTP_ENABLE_START_TLS: false

Commentarla probabilmente non aiuterà molto, poiché direttamente dai file di configurazione del contenitore Discourse, il valore predefinito di questa impostazione è true; quindi, commentando questa riga, rimarrà comunque impostata su true:

#DISCOURSE_SMTP_ENABLE_START_TLS: true    # (opzionale, default true)

Spero ti sia utile (HTH)

Vedi anche (dalla RFC):

Quando viene stabilita una connessione TCP per il servizio “submissions” (porta predefinita 465), inizia immediatamente un handshake TLS. I client DEVONO implementare il meccanismo di validazione dei certificati descritto in [RFC7817]. Una volta stabilita la sessione TLS, i dati del protocollo di invio messaggi [RFC6409] vengono scambiati come dati applicativi TLS per il resto della connessione TCP. (Nota: il nome del servizio “submissions” è definito nella Sezione 7.3 di questo documento e segue la convenzione usuale secondo cui il nome di un servizio sovrapposto a Implicit TLS consiste nel nome del servizio utilizzato senza TLS, con una “s” aggiunta alla fine.) Il meccanismo STARTTLS sulla porta 587 è relativamente ampiamente diffuso a causa della situazione relativa alla porta 465 (discussa nella Sezione 7.3). Ciò differisce dai servizi IMAP e POP, dove Implicit TLS è più ampiamente implementato sui server rispetto a STARTTLS. È auspicabile migrare nel tempo i protocolli principali utilizzati dal software MUA verso Implicit TLS, sia per coerenza che per le ulteriori ragioni discusse nell’Appendice A. Tuttavia, per massimizzare l’uso della crittografia per l’invio, è auspicabile supportare entrambi i meccanismi per l’invio di messaggi tramite TLS per un periodo di transizione di diversi anni. Di conseguenza, i client e i server DOVREBBERO implementare sia STARTTLS sulla porta 585 che Implicit TLS sulla porta 465 per questo periodo di transizione. Si noti che non vi è alcuna differenza significativa tra le proprietà di sicurezza di STARTTLS sulla porta 587 e Implicit TLS sulla porta 465 se le implementazioni sono corrette e se sia il client che il server sono configurati per richiedere una negoziazione riuscita di TLS prima dell’invio del messaggio.

Nota: ci sono due impostazioni predefinite relative a TLS nelle configurazioni predefinite di Discourse:

# meccanismo di autenticazione SMTP
smtp_authentication = plain

# abilita la crittografia TLS per le connessioni SMTP
smtp_enable_start_tls = true

# modalità per la verifica dei certificati del server SMTP
# per disabilitare, impostare su 'none'
smtp_openssl_verify_mode =

# forza Implicit TLS come da RFC 8314 3.3
smtp_force_tls = false

Vedi anche: