SMTP email issue Net::Timeout

Hello, I’ve been trying to fix my smtp issue and it doesn’t send emails and when I run the ./discourse-doctor command it gives me an Net::Timeout error.

Thanks in advance for the help.

app.yml smtp section

DISCOURSE_SMTP_ADDRESS: plesk.oxide.host
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: no-reply@kyekillerbot.xyz
DISCOURSE_SMTP_PASSWORD: password
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
DISCOURSE_SMTP_AUTHENTICATION: login

I have tried telnet, but it connects to the smtp domain successfully .

Have you tried commenting this line? I don’t think the port 465 supports STARTTLS

As far as port 465, see,RFC8314

https://tools.ietf.org/html/rfc8314

Based on this RFC, both ports 465 and 587 are valid ports for an SMTP mail submission agent (MSA).

Port 465 requires negotiation of TLS/SSL at connection setup and port 587 uses STARTTLS if one chooses to negotiate TLS.

The IANA registry has been updated to allow legitimate use of port 465 for this purpose.

For an SMTP mail relay, only port 25 is used so STARTTLS is the only way to do TLS with mail relay.

@kyekiller , you should consider trying this setting (set to false) if you are going to use port 465:

DISCOURSE_SMTP_ENABLE_START_TLS: false

Commenting it out will probably not help much, since directly from the Discourse container files, the default for this setting is true; so commenting out this line, it will still be set to true:

#DISCOURSE_SMTP_ENABLE_START_TLS: true    # (optional, default true)

HTH

See also (from RFC):

When a TCP connection is established for the “submissions” service (default port 465), a TLS handshake begins immediately. Clients MUST implement the certificate validation mechanism described in [RFC7817]. Once the TLS session is established, Message Submission protocol data [RFC6409] is exchanged as TLS application data for the remainder of the TCP connection. (Note: The “submissions” service name is defined in Section 7.3 of this document and follows the usual convention that the name of a service layered on top of Implicit TLS consists of the name of the service as used without TLS, with an “s” appended.) 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.

Note, there are two TLS related default settings from the Discourse defaults:

# smtp authentication mechanism
smtp_authentication = plain

# enable TLS encryption for smtp connections
smtp_enable_start_tls = true

# mode for verifying smtp server certificates
# to disable, set to 'none'
smtp_openssl_verify_mode =

# force implicit TLS as per RFC 8314 3.3
smtp_force_tls = false

See also: