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
关于通过端口 465 的 SMTPS 发送电子邮件的实用解决方案？否，“更改您的 ESP”、“使用 587 提交”以及类似的都不是所问问题的解决方案 
实际解决方案？不……强制使用 587 是相当普遍的策略。
那么，问题是什么？
您是指 ESP 端吗？当然可以，但不能在客户端（此处为 Discourse 服务器）端。我仍在检查和重新检查选项，所以这还不能最终确定它对我来说“就是不行”，但我希望这里没有人试图在客户端强制使用 587，对吧？
只是想指出这一点，因为它似乎已成为一种普遍的误解——587 不是“未来”——而是 465 上的隐式 TLS。
我通过这篇帖子了解到这一[启示]。
在阅读了2018 年的实际 RFC 后，情况很清楚——并不是 STARTTLS 是前进的方向，而是 SMTPS 不是前进的方向，而是在 465 端口（或 587 端口）上的隐式 TLS 是管理员未来应选择的方式。
支持 465 上的 TLS 不应被归类为（甚至可能不被优先考虑）“维护向后兼容性”或任何类似的概念。
端口 587 上的 STARTTLS 机制由于 465 端口的情况（在第 7.3 节讨论）得到了相对广泛的部署。这与 IMAP 和 POP 服务不同，在这些服务中，服务器上隐式 TLS 的部署比 STARTTLS 更广泛。希望随着时间的推移，将 MUA 软件使用的核心协议迁移到隐式 TLS，以保持一致性以及解决附录 A 中讨论的其他原因。然而，为了最大限度地利用加密进行提交，希望在过渡期内支持 STARTTLS 上的消息提交和隐式 TLS 上的消息提交这两种机制。因此，客户端和服务器在此过渡期内应在端口 587 上实现 STARTTLS，并在端口 465 上实现隐式 TLS。 请注意，如果实现正确，并且客户端和服务器都配置为在消息提交前成功协商 TLS，那么端口 587 上的 STARTTLS 和端口 465 上的隐式 TLS 在安全属性上没有显著差异。
过渡不是通过 STARTTLS 在 587 上进行“提交”，而是通过 465 上的隐式 TLS 进行“提交”（而不是现在已弃用的 465 上的 SMTPS）。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.