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
Any practical solutions for sending e-mail over SMTPS on port 465? No, “change your ESP” , “use submission 587” and similar are not solutions to the problem in question 
Practical solutions? No… it is quite common policy to force to use 587.
So, what is the issue?
You mean on the ESP side? Sure, but not on the client (here Discourse server) side. I am still checking and rechecking options so it’s not yet conclusive that it “just doesn’t work” for me but I hope nobody tried to force 587 on the client side here, right?
Just wanted to point this out since it seems to have become a common misunderstanding – 587 is not “the future” – implicit TLS over 465 is.
I was lead to this revelation by this post
And upon reading the actual RFC from 2018 it’s clear – it’s not that STARTTLS is the way forward, it’s that SMTPS is not the way forward, and implicit TLS over port 465 (or 587) is what administrators should choose going forward.
Supporting TLS over 465 should not be classed (and likely de-prioritized) as “maintaining backwards compatibility” or any similar notion.
The STARTTLS mechanism on port 587 is relatively widely deployed due to the situation with port 465 (discussed in Section 7.3. This differs from IMAP and POP services where Implicit TLS is more widely deployed on servers than STARTTLS. It is desirable to migrate core protocols used by MUA software to Implicit TLS over time, for consistency as well as for the additional reasons discussed in Appendix A. However, to maximize the use of encryption for submission, it is desirable to support both mechanisms for Message Submission over TLS for a transition period of several years. As a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period. Note that there is no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465 if the implementations are correct and if both the client and the server are configured to require successful negotiation of TLS prior to Message Submission.
The transition is not to submissions over 587 via STARTTLS, it’s to submissions via implicit TLS on port 465 (as opposed to SMTPS over port 465 which is now deprecated).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.