自从升级到 2.4.0.beta4 后，所有使用 Rackspace 发送外部邮件的安装都无法发送外部邮件。鉴于外部邮件服务器同样是 Rackspace，我推测其 SSL/TLS 设置是正确的（而且，无论如何，它们在各大邮件客户端中似乎都能正常工作）。也许这个讨论帖与此相关。
不过，在应用最近的更新后（我不确定具体是哪项变更），错误不再与上述讨论帖中提到的相同，而是变成了以下错误：
Jobs::HandledExceptionWrapper: Wrapped Net::ReadTimeout: Net::ReadTimeout with #<TCPSocket:(closed)>
我推测这是一个 bug。
编辑：另一个相关讨论帖
能否尝试在 Docker 容器内部连接到 SMTP 服务器？
SMTP with StartTLS（默认配置，除非您在 app.yml 中修改了 DISCOURSE_SMTP_ENABLE_START_TLS）：
openssl s_client -connect <hostname>:<port> -starttls smtp
SMTP
openssl s_client -connect <hostname>:<port>
使用 -starttls 标志时，它仅返回“CONNECTED”。不使用 -starttls 时：
root@omnifora-com-app:/var/www/discourse# openssl s_client -connect secure.emailsrvr.com:465
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
139636332590208:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2156:
---
Certificate chain
0 s:OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
3 s:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG5jCCBc6gAwIBAgIRAMWoQ0lmf1VC8Ch8zZZTHm0wDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTYwNAYD
VQQDEy1DT01PRE8gUlNBIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIg
Q0EwHhcNMTkwMTEwMDAwMDAwWhcNMjAwMzEwMjM1OTU5WjBZMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFTATBgNVBAsTDEVzc2VudGlhbFNTTDEd
MBsGA1UEAxMUc2VjdXJlLmVtYWlsc3J2ci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDZzFpkI/ujPCuNZpHLueu+/iqUsc5U7+yYa9d6xIbkh2BN
u+OpBNCTn4ACa0a3EaqRVyceUUh8TodUPtkZYLZO6iqwl2eOd8h3NXxtRlyaj0Hz
uSOlRbA5CiVZ4H1Ia8k/DVh+r1Rk6Da/f52wBJE8ICFgm7Uyrjtfcc90gBk+7i4I
y1aNwKW/nqmqQBEiTeyUF2kJiTovtorQo7zaedPefm2VUoKyxe/8jl7qA7F9+1p0
XvvWrc3/vqEEZR6tmcAF8tmp0MSkMnt3klwg/xopVn5nPq52t6fLRXA0aLFBUHzT
U82Iw1Weg+gUVi77ONDIabfYuCqqEgpnAyeUhh8hAgMBAAGjggNvMIIDazAfBgNV
HSMEGDAWgBSQr2o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUFJzBKVTbToPC
UoxWxXfRAJGz+YswDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYBBAGyMQEC
AgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNvbS9DUFMw
CAYGZ4EMAQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2RvY2Eu
Y29tL0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcmww
gYUGCCsGAQUFBwEBBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNy
dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMDkGA1UdEQQy
MDCCFHNlY3VyZS5lbWFpbHNydnIuY29tghh3d3cuc2VjdXJlLmVtYWlsc3J2ci5j
b20wggGABgorBgEEAdZ5AgQCBIIBcASCAWwBagB3ALvZ37wfinG1k5Qjl6qSe0c4
V5UKq1LoGpCWZDaOHtGFAAABaDf6Nt0AAAQDAEgwRgIhAJDqOzt2LWqviVrjKGFL
UCPuu/HWeuILG/7VuDwJWWYYAiEAvCaXH3lSCRWOgGquaz9lW3uITCuKQP0TOOMv
JPbcN/IAdwBep3P531bA57U2SH3QSeAyepGaDIShEhKEGHWWgXFFWAAAAWg3+jcn
AAAEAwBIMEYCIQCxU8IX94IoSwsrpo6zJoUMO4uNGuTkpLSY0h/KWbspqQIhAIy4
XfY5RtTTLpB3EFLXMyQSL9/gyNpfJ1OtbYtOkL0pAHYA8JWkWfIA0YJAEC0vk4iO
rUv+HUfjmeHQNKawqKqOsnMAAAFoN/o5AAAABAMARzBFAiAePxbn6JuVUkYjBVnF
MPHeqyqAaYpdwyGxaC3Cz4WZhAIhAPFXU3e0+7GkNMjXFPQ6UMd55zeUJcxakFIt
ggm7ioLYMA0GCSqGSIb3DQEBCwUAA4IBAQAkLuNWuHt5GOXkzJlys09mg22+MnhF
4y+abm7F54stsv0A2Gc4my4bEXOZ4ozf0g1Yjb/ZVlSVrNC125CSnXd6bEcesjcn
c3oxO+9dFCQGMH4CZPVSoDKBk41+VP9IcnfibhSzV8wFXQh+Tt1OpRoNgqM888Es
JvYP9B2OgDvQFnDNAcJXM5fgX1CilyXqPtz2QYDNVgN8tuRSRPlaGTkZgGMsCO12
GjxLD5UGsxh5c08KSRgd4Uv6BRH/hE62spqvmDUDzuU+Qx9N4/Tz2ocv8LI8GlqV
RYOe+6lLe8t33yH0dnRWKGrpT8gWkul1qLHI9I7LYZMvMKdcxl8oBBGF
-----END CERTIFICATE-----
subject=OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
issuer=C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6414 bytes and written 319 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1569003408
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
问题似乎又出现了：
Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: dh key too small
（至少在过去的几千次失败中是这样。）
另外：生日快乐，@gerhard。
该错误表明 SMTP 服务器配置不当，使用了 OpenSSL 认为过小的 DH 密钥。
这对 Rackspace 来说似乎不太可能，不过我可以试着拉他们的一位技术人员加入此事。
嗯，这个错误来自 OpenSSL，据我所知，我们使用的是 Debian / Ruby 提供的默认配置？
看起来新版本的基准镜像打包了一个最终弃用了旧的不安全签名算法的 OpenSSL 版本。
我们公司的内网中有一台旧的 Windows CA，它使用了 MD5，导致我在升级后 Discourse 安装中的 HTTPS 完全失效。Nginx 报错“SSL_CTX_use_certificate:ca md too weak”，并拒绝加载 HTTPS 证书。
RHEL 和 CentOS 有一种遗留机制可以重新启用这些算法，但我没在 Debian/Ubuntu 中找到类似的兼容性设置。
我相信会有更多人遇到这个问题，因为市面上还存在大量旧的不安全证书，但恐怕除了更换证书外别无他法。关于邮件问题，建议您直接联系 Rackspace。
这是给 @gerhard 的问题
我相当确定这是一个 bug。我曾请 Rackspace 的技术人员调查此事，他提供了关于其 DH 密钥的以下信息：
以下是公开可用的信息：
CA = Comodo Limited CA
Certificate Key Size = 2048 bit
Domain Name = mx1.emailsrvr.com 和 mx2.emailsrvr.com
Email server hostname = secure.emailsrvr.com
Mail Host Software (Identify the software and version is running on the MTA) =
ecelerity 2.2.3.49
Cipher Strength = AES256-SHA
我认为 2048 位密钥不应被（准确地）视为“太小”。
来自 U.S. | Let There Be Change | Accenture
目前推荐的 DH 参数最小长度为 2048 位。等于或低于 1024 位的都被认为是不安全的。
好的，让我们使用一个较旧版本的 Debian 来查看 DH 密钥：
docker run --rm -it debian:stretch
apt update && apt install -y openssl
openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"
是的，DH 密钥确实太小了：
Server Temp Key: DH, 1024 bits
我认为这应该是 Rackspace 需要修复的问题。作为临时解决方案，您可以编辑 /etc/ssl/openssl.cnf 文件，删除文件末尾的 CipherString = DEFAULT@SECLEVEL=2。重启容器后，Sidekiq 应该会应用新的 OpenSSL 设置。
openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
Server Temp Key: DH, 1024 bits
回到与 Rackspace 的对话。
来自 Rackspace 的更新：
感谢您的耐心，也感谢您将此问题告知我们。我们可以确认，我们当前的 DH 密钥长度为 1024 位。我们的产品与工程团队已确认需要提升该密钥长度，并已制定修复计划。
我目前无法提供确切的修复发布时间，但目标是在本月内完成。一旦我们完成 DH 密钥长度的升级，我们将及时向您提供更新。
再次感谢您提醒我们此事！如果您还有其他问题或疑虑，请随时告知我们！
一旦我收到 DH 密钥已升级的通知，我将在此线程中更新信息。
那个补丁让我解决了问题，但这并不太令人乐观 
下次重新构建时它又会消失，对吧？
好吧，希望 Rackspace 能在你需要重建之前修复这个问题。否则，你可以在 app.yml 中使用 sed 命令修改 openssl.cnf，从而使其成为永久性的更改。
来自 Rackspace 的更新：
感谢您的耐心等待。DH 密钥大小已更新，现在与证书密钥大小一致。请进行测试，如果您有任何其他问题或疑虑，请随时告知我们！
已验证：
openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
Server Temp Key: DH, 2048 bits
我进一步验证了现在确实可以再次从我的 Discourse 安装发送邮件。因此（至少对于 Rackspace 而言），此问题已解决。