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
Des solutions pratiques pour l’envoi d’e-mails via SMTPS sur le port 465 ? Non, « changez votre ESP », « utilisez la soumission 587 » et similaires ne sont pas des solutions au problème en question 
Solutions pratiques ? Non… il est assez courant d’imposer l’utilisation du port 587.
Alors, quel est le problème ?
Vous voulez dire du côté de l’ESP ? Bien sûr, mais pas du côté du client (ici le serveur Discourse). Je vérifie et revérifie encore les options, donc il n’est pas encore concluant que cela « ne fonctionne tout simplement pas » pour moi, mais j’espère que personne n’a essayé de forcer le 587 côté client ici, n’est-ce pas ?
Je voulais juste signaler cela car il semble y avoir un malentendu courant : le port 587 n’est pas « l’avenir » — le TLS implicite sur le port 465 l’est.
J’ai été amené à cette révélation par cet article.
Et après avoir lu la RFC officielle de 2018, c’est clair : ce n’est pas que STARTTLS soit la voie à suivre, c’est que SMTPS n’est pas la voie à suivre, et que le TLS implicite sur le port 465 (ou 587) est ce que les administrateurs devraient choisir à l’avenir.
Le support du TLS sur le port 465 ne devrait pas être classé (et probablement dépriorisé) comme « maintien de la compatibilité ascendante » ou toute notion similaire.
Le mécanisme STARTTLS sur le port 587 est relativement largement déployé en raison de la situation avec le port 465 (discuté dans la section 7.3. Cela diffère des services IMAP et POP où le TLS implicite est plus largement déployé sur les serveurs que STARTTLS. Il est souhaitable de migrer les protocoles de base utilisés par les logiciels MUA vers le TLS implicite au fil du temps, pour la cohérence ainsi que pour les raisons supplémentaires discutées dans l’annexe A. Cependant, pour maximiser l’utilisation du chiffrement pour la soumission, il est souhaitable de prendre en charge les deux mécanismes pour la soumission de messages via TLS pendant une période de transition de plusieurs années. En conséquence, les clients et les serveurs DOIVENT implémenter STARTTLS sur le port 587 et le TLS implicite sur le port 465 pendant cette période de transition. Notez qu’il n’y a pas de différence significative entre les propriétés de sécurité de STARTTLS sur le port 587 et le TLS implicite sur le port 465 si les implémentations sont correctes et si le client et le serveur sont configurés pour exiger une négociation réussie de TLS avant la soumission de messages.
La transition ne se fait pas vers les soumissions sur le port 587 via STARTTLS, mais vers les soumissions via TLS implicite sur le port 465 (par opposition à SMTPS sur le port 465 qui est maintenant obsolète).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.