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
¿Ha habido alguna actualización? Mi proveedor de correo electrónico también requiere que el cliente establezca automáticamente una conexión TLS al conectarse en el puerto 465.
¿Cómo le indico a Discourse que utilice esta opción?
Para ser precisos, en [swaks](https://linux.die.net/man/1/swaks) esto se llama --tlsc
--tlsc, --tls-on-connect
Iniciar una conexión TLS inmediatamente al establecer la conexión. Siguiendo la convención común, si se especifica esta opción, el puerto predeterminado cambia de 25 a 465, aunque esto aún puede anularse con la opción --port.
Creo que lo siguiente está relacionado: un PR nunca completado para Action Mailer de Ruby describe cómo debe configurarse Action Mailer. Específicamente, se deben agregar las opciones tls y ssl. En Discourse, esto podría estar en production.rb aquí
PD: He enviado un PR con una solución propuesta que también puede usarse como solución temporal.
¿Alguna solución práctica para enviar correos electrónicos a través de SMTPS en el puerto 465? No, “cambia tu ESP”, “usa submission 587” y similares no son soluciones al problema en cuestión 
¿Soluciones prácticas? No… es una política bastante común forzar el uso del 587.
Entonces, ¿cuál es el problema?
¿Te refieres al lado de la ESP? Claro, pero no al lado del cliente (aquí el servidor Discourse). Todavía estoy revisando y volviendo a revisar opciones, así que aún no es concluyente que “simplemente no funcione” para mí, pero espero que nadie haya intentado forzar 587 en el lado del cliente aquí, ¿verdad?
Solo quería señalar esto ya que parece haberse convertido en un malentendido común: 587 no es “el futuro”, sino el TLS implícito sobre 465.
Llegué a esta revelación a través de esta publicación.
Y al leer el RFC real de 2018, queda claro: no es que STARTTLS sea el camino a seguir, sino que SMTPS no es el camino a seguir, y el TLS implícito sobre el puerto 465 (o 587) es lo que los administradores deberían elegir en el futuro.
El soporte de TLS sobre 465 no debería clasificarse (y probablemente despriorizarse) como “mantenimiento de compatibilidad con versiones anteriores” o cualquier noción similar.
El mecanismo STARTTLS en el puerto 587 está relativamente muy desplegado debido a la situación con el puerto 465 (discutido en la Sección 7.3. Esto difiere de los servicios IMAP y POP, donde el TLS implícito está más ampliamente desplegado en los servidores que STARTTLS. Es deseable migrar los protocolos centrales utilizados por el software MUA al TLS implícito con el tiempo, por coherencia y por las razones adicionales discutidas en el Apéndice A. Sin embargo, para maximizar el uso de la encriptación para la entrega, es deseable soportar ambos mecanismos para la entrega de mensajes sobre TLS durante un período de transición de varios años. Como resultado, los clientes y servidores DEBERÍAN implementar tanto STARTTLS en el puerto 587 como TLS implícito en el puerto 465 durante este período de transición. Tenga en cuenta que no hay una diferencia significativa entre las propiedades de seguridad de STARTTLS en el puerto 587 y TLS implícito en el puerto 465 si las implementaciones son correctas y si tanto el cliente como el servidor están configurados para requerir la negociación exitosa de TLS antes de la entrega de mensajes.
La transición no es a submissions sobre 587 a través de STARTTLS, sino a submissions a través de TLS implícito en el puerto 465 (en contraposición a SMTPS sobre el puerto 465, que ahora está obsoleto).