你好，我一直在尝试修复我的 SMTP 问题，邮件无法发送。运行 ./discourse-doctor 命令时，它返回了一个 Net::Timeout 错误。
提前感谢您的帮助。
app.yml 的 SMTP 部分：
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 # （可选，默认为 true）
DISCOURSE_SMTP_AUTHENTICATION: login
我尝试过 telnet，并且成功连接到了 SMTP 域名。
你试过注释掉这一行吗？我认为 465 端口不支持 STARTTLS。
关于端口 465，请参阅 RFC8314：
根据该 RFC，端口 465 和 587 均适用于 SMTP 邮件提交代理（MSA）。
端口 465 要求在建立连接时立即协商 TLS/SSL，而端口 587 则在使用 STARTTLS 时协商 TLS（如果选择使用）。
IANA 注册表已更新，允许合法使用端口 465 用于此目的。
对于 SMTP 邮件中继，仅使用端口 25，因此 STARTTLS 是唯一用于邮件中继的 TLS 方式。
@kyekiller，如果您打算使用端口 465，建议尝试将此设置（设为 false）：
DISCOURSE_SMTP_ENABLE_START_TLS: false
将其注释掉可能帮助不大，因为直接从 Discourse 容器文件中查看，该设置的默认值为 true；因此即使注释掉这一行，它仍会被设置为 true：
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (可选，默认为 true)
希望这能帮到您（HTH）。
另请参阅（来自 RFC）：
当为“submissions”服务（默认端口 465）建立 TCP 连接时，TLS 握手会立即开始。客户端必须实现 [RFC7817] 中描述的证书验证机制。一旦 TLS 会话建立，消息提交协议数据 [RFC6409] 将在 TCP 连接的剩余时间内作为 TLS 应用数据进行交换。（注意：“submissions”服务名称定义于本文档的 第 7.3 节，并遵循通常的约定，即基于隐式 TLS 的服务名称由不带 TLS 的服务名称后加"s"构成。）由于端口 465 的情况（在 第 7.3 节 中讨论），端口 587 上的 STARTTLS 机制已得到相对广泛的部署。这与 IMAP 和 POP 服务不同，在后两者中，服务器端更广泛地部署隐式 TLS 而非 STARTTLS。从长远来看，将 MUA 软件使用的核心协议迁移到隐式 TLS 是可取的，这既是为了保持一致性，也是出于 附录 A 中讨论的其他原因。然而，为了最大化提交过程中的加密使用，在为期数年的过渡期内，同时支持通过 TLS 进行消息提交的两种机制是可取的。因此，客户端和服务器在此过渡期内应同时实现端口 587 上的 STARTTLS 和端口 465 上的隐式 TLS。请注意，如果实现正确，且客户端和服务器均配置为在消息提交前要求成功协商 TLS，则端口 587 上的 STARTTLS 与端口 465 上的隐式 TLS 在安全属性方面并无显著差异。
# smtp 认证机制
smtp_authentication = plain
# 为 smtp 连接启用 TLS 加密
smtp_enable_start_tls = true
# smtp 服务器证书验证模式
# 要禁用，请设置为 'none'
smtp_openssl_verify_mode =
# 根据 RFC 8314 3.3 强制使用隐式 TLS
smtp_force_tls = false
另请参阅：