Hi Team,
Using email service from godaddy and smtp ssl port 465 in config, but sending mail fails with
Job exception: end of file reached.
For me 465 works with email client such as thunderbird. What can be done to make email work with discourse on port 465.
Running SMTP on other port such as 3535 works well. If I go with non secure port will security of my email contents and credentials get compromised?
Regards
Manish
This sounds like a problem with your mail provider or the server running Discourse (such as a firewall issue). It is not a problem with Discourse itself.
Also note that port 465 hasnât been for SMTPS for so long that the IETF has removed its registration as a well-known port. You should use port 25 or 587 with STARTTLS.
Hi Matt,
I am able to telnet port 465 from discourse server and no firewall is configured for now.
Email providers still supports 465 for secure connection for client which does not support STARTTLS. However thatâs not the case here, so I can move to port 25 with STARTTLS on.
Regards
Manish
Sad to here this.
My email service provider does not support for port 587.
Your ESP needs to be dragged, kicking and screaming, into the 21st century.
I have been googling for this, to see if I should use port 465 or not.
Can you confirm as of 2018, if the recommended and safe settings is to use port 587 with STARTTLS (DISCOURSE_SMTP_ENABLE_START_TLS env for dockers) ?
Sendgrid still offers port 465 âfor SSL connectionsâ as they say. I was thinking in using it.
Sendgrid use 587 too. Use 587 with starttls. TLS is effectively the successor to SSL.
Thereâs a January 2018 IETF RFC which recommends use of port 465 for âimplicitâ TLS. A motivation for this is the increasing trend for mandatory encryption, which renders STARTTLS somewhat redundant. RFC 8314 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
Ci sono stati aggiornamenti? Anche il mio provider di posta richiede che il client stabilisca automaticamente una connessione TLS al momento della connessione sulla porta 465.
Come posso dire a Discourse di utilizzare questa opzione?
Per essere precisi, in [swaks](https://linux.die.net/man/1/swaks) questa opzione è chiamata --tlsc
--tlsc, --tls-on-connect
Avvia immediatamente una connessione TLS al momento della connessione. Seguendo la convenzione comune, se questa opzione è specificata la porta predefinita cambia da 25 a 465, sebbene ciò possa comunque essere sovrascritto con l'opzione --port.
Penso che quanto segue sia correlato: una PR mai completata per Action Mailer di Ruby descrive come Action Mailer debba essere configurato. Nello specifico, è necessario aggiungere le opzioni tls e ssl. In Discourse, questo potrebbe essere inserito in production.rb qui
PS: Ho inviato una PR con una correzione proposta che può anche essere utilizzata come soluzione temporanea.
Ci sono soluzioni pratiche per inviare e-mail tramite SMTPS sulla porta 465? No, âcambia il tuo ESPâ, âusa submission 587â e simili non sono soluzioni al problema in questione 
Soluzioni pratiche? No⌠è una politica abbastanza comune forzare lâuso della 587.
Quindi, qual è il problema?
Intendi dal lato ESP? Certo, ma non dal lato client (qui server Discourse). Sto ancora controllando e ricontrollando le opzioni, quindi non è ancora conclusivo che âsemplicemente non funzionaâ per me, ma spero che nessuno abbia cercato di forzare il 587 dal lato client qui, giusto?
Volevo solo sottolineare questo dato che sembra essere diventato un malinteso comune: 587 non è âil futuroâ, lo è la TLS implicita sulla porta 465.
Sono giunto a questa rivelazione tramite questo post
E dopo aver letto lâRFC effettiva del 2018 è chiaro: non è che STARTTLS sia la strada da percorrere, è che SMTPS non è la strada da percorrere, e la TLS implicita sulla porta 465 (o 587) è ciò che gli amministratori dovrebbero scegliere in futuro.
Il supporto alla TLS sulla porta 465 non dovrebbe essere classificato (e probabilmente de-prioritizzato) come âmantenimento della compatibilitĂ retroattivaâ o qualsiasi nozione simile.
Il meccanismo STARTTLS sulla porta 587 è relativamente diffuso a causa della situazione con la porta 465 (discusso nella Sezione 7.3. Questo differisce dai servizi IMAP e POP dove la TLS implicita è piĂš diffusa sui server rispetto a STARTTLS. Ă auspicabile migrare nel tempo i protocolli principali utilizzati dal software MUA alla TLS implicita, per coerenza e per le ragioni aggiuntive 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, client e server DOVREBBERO implementare sia STARTTLS sulla porta 587 che TLS implicita 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 TLS implicita sulla porta 465 se le implementazioni sono corrette e se sia il client che il server sono configurati per richiedere la negoziazione riuscita di TLS prima dellâinvio del messaggio.
La transizione non è a submissions sulla porta 587 tramite STARTTLS, ma a submissions tramite TLS implicita sulla porta 465 (al contrario di SMTPS sulla porta 465 che ora è deprecato).