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
Have there been any updates? My email provider also requires that the client automatically establish a TLS connection on connect on port 465.
How do I tell Discourse to use this option?
To be precise, in [swaks](https://linux.die.net/man/1/swaks) this is called --tlsc
--tlsc, --tls-on-connect
Initiate a TLS connection immediately on connection. Following common convention, if this option is specified the default port changes from 25 to 465, though this can still be overridden with the --port option.I think the following is related: a never completed PR for Ruby’s action mailer describes how the action mailer needs to be configured. Specifically, the options tls and ssl need to be added. In Discourse, this could be in production.rb here
PS: I submitted a PR with a proposed fix which can also be used as a work-around
Alguma solução prática para enviar e-mail via SMTPS na porta 465? Não, “mude seu ESP”, “use submission 587” e similares não são soluções para o problema em questão 
Soluções práticas? Não… é uma política bastante comum forçar o uso da porta 587.
Então, qual é o problema?
Você quer dizer do lado do ESP? Claro, mas não do lado do cliente (aqui o servidor Discourse). Ainda estou verificando e reexaminando as opções, então ainda não é conclusivo que “simplesmente não funciona” para mim, mas espero que ninguém tenha tentado forçar 587 do lado do cliente aqui, certo?
Apenas queria apontar isso, pois parece ter se tornado um mal-entendido comum – 587 não é “o futuro” – TLS implícito sobre 465 é.
Fui levado a essa revelação por este post
E, após ler o RFC real de 2018, fica claro – não é que STARTTLS seja o caminho a seguir, é que SMTPS não é o caminho a seguir, e TLS implícito sobre a porta 465 (ou 587) é o que os administradores devem escolher daqui para frente.
O suporte a TLS sobre 465 não deve ser classificado (e provavelmente ter sua prioridade diminuída) como “manutenção de compatibilidade retroativa” ou qualquer noção semelhante.
O mecanismo STARTTLS na porta 587 é relativamente amplamente implantado devido à situação com a porta 465 (discutida na Seção 7.3. Isso difere dos serviços IMAP e POP, onde o TLS implícito é mais amplamente implantado em servidores do que o STARTTLS. É desejável migrar os protocolos principais usados pelo software MUA para TLS implícito ao longo do tempo, por consistência, bem como por razões adicionais discutidas no Apêndice A. No entanto, para maximizar o uso de criptografia para submissão, é desejável suportar ambos os mecanismos para Submissão de Mensagens sobre TLS por um período de transição de vários anos. Como resultado, clientes e servidores DEVEM implementar STARTTLS na porta 587 e TLS implícito na porta 465 durante este período de transição. Observe que não há diferença significativa entre as propriedades de segurança do STARTTLS na porta 587 e do TLS implícito na porta 465 se as implementações estiverem corretas e se o cliente e o servidor estiverem configurados para exigir a negociação bem-sucedida de TLS antes da Submissão de Mensagens.
A transição não é para submissions sobre 587 via STARTTLS, é para submissions via TLS implícito na porta 465 (em oposição a SMTPS sobre a porta 465, que agora está obsoleta).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.