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
Gibt es praktische Lösungen für den Versand von E-Mails über SMTPS auf Port 465? Nein, „ändern Sie Ihren ESP“, „verwenden Sie Submission 587“ und ähnliches sind keine Lösungen für das fragliche Problem 
Praktische Lösungen? Nein… es ist eine ziemlich übliche Richtlinie, die Verwendung von 587 zu erzwingen.
Was ist also das Problem?
Sie meinen auf der ESP-Seite? Sicher, aber nicht auf der Client-Seite (hier Discourse-Server). Ich überprüfe und überprüfe die Optionen immer noch, daher ist es noch nicht schlüssig, dass es für mich “einfach nicht funktioniert”, aber ich hoffe, niemand hat versucht, 587 auf der Client-Seite zu erzwingen, oder?
Ich wollte das nur anmerken, da es anscheinend ein häufiges Missverständnis geworden ist – 587 ist nicht „die Zukunft“ – implizites TLS über 465 ist es.
Ich wurde durch diesen Beitrag zu dieser Erkenntnis geführt.
Und nach der Lektüre der tatsächlichen RFC von 2018 ist klar – es ist nicht so, dass STARTTLS der Weg nach vorn ist, sondern dass SMTPS nicht der Weg nach vorn ist, und implizites TLS über Port 465 (oder 587) ist das, was Administratoren in Zukunft wählen sollten.
Die Unterstützung von TLS über 465 sollte nicht als „Aufrechterhaltung der Abwärtskompatibilität“ oder ähnliches eingestuft werden (und wahrscheinlich zurückgestellt werden).
Der STARTTLS-Mechanismus auf Port 587 ist aufgrund der Situation mit Port 465 (siehe Abschnitt 7.3) relativ weit verbreitet. Dies unterscheidet sich von IMAP- und POP-Diensten, bei denen implizites TLS auf Servern weiter verbreitet ist als STARTTLS. Es ist wünschenswert, Kernprotokolle, die von MUA-Software verwendet werden, im Laufe der Zeit auf implizites TLS umzustellen, sowohl aus Gründen der Konsistenz als auch aus den zusätzlichen Gründen, die in Anhang A erörtert werden. Um die Nutzung von Verschlüsselung für die Übermittlung zu maximieren, ist es jedoch wünschenswert, beide Mechanismen für die Nachrichtenübermittlung über TLS für einen Übergangszeitraum von mehreren Jahren zu unterstützen. Daher sollten Clients und Server während dieses Übergangszeitraums sowohl STARTTLS auf Port 587 als auch implizites TLS auf Port 465 implementieren. Es ist zu beachten, dass es keinen signifikanten Unterschied zwischen den Sicherheitseigenschaften von STARTTLS auf Port 587 und implizitem TLS auf Port 465 gibt, wenn die Implementierungen korrekt sind und wenn sowohl der Client als auch der Server so konfiguriert sind, dass sie eine erfolgreiche Aushandlung von TLS vor der Nachrichtenübermittlung erfordern.
Der Übergang ist nicht zu submissions über 587 via STARTTLS, sondern zu submissions via implizitem TLS auf Port 465 (im Gegensatz zu SMTPS über Port 465, das jetzt veraltet ist).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.