Persistent SMTP Timeout Issue with Spacemail on Discourse (VPS, Docker)

Support
1

Hello Discourse Support/Community,

I have been struggling for several days to resolve an issue with outgoing emails from my Discourse instance. I am running Discourse in a Docker container on a Spaceship VPS (Phoenix, US). My mail provider is Spacemail (SMTP).

Issue:

  • Discourse cannot send emails. Every attempt to send a test email results in a timeout error:

    • Net::ReadTimeout with #<TCPSocket:(closed)>

    • Or: execution expired

  • The problem persists regardless of whether I use mail.spacemail.com or smtp.spacemail.com as the SMTP server.

What I have tried:

  • Verified all SMTP settings (address, port 465 for SSL, full email as username, correct password) with Spaceship/Spacemail support.

  • Reset and re-entered the SMTP password multiple times.

  • Confirmed with Spacemail support that there are no restrictions or blocks on their side.

  • Telnet from the VPS to mail.spacemail.com on port 465 is successful (connection opens, no firewall issue).

  • Changed the Docker network MTU to 1400 as suggested in Discourse forums and restarted Docker and the Discourse container.

  • Tried both destroy/start and full rebuild of the Discourse app.

  • Checked that Redis, PostgreSQL, and all other services are running correctly in the container.

  • Verified that all DNS records (MX, SPF, DKIM) are set up and propagated.

  • Tested from multiple browsers and devices to rule out client-side issues.

  • Successfully sent and received emails using the same Spacemail account in Gmail (SMTP works outside Discourse).

Environment:

  • Discourse running in Docker on Ubuntu 22.04 VPS (Spaceship, Phoenix, US)

  • SMTP provider: Spacemail

  • SMTP settings: SSL, port 465, mail.spacemail.com (also tried smtp.spacemail.com)

  • All DNS records are correct and propagated

Logs:

  • No errors in Discourse logs except for the timeout on email sending.

  • Redis and other services are running without conflict.

  • Unicorn worker timeouts coincide with email sending attempts.

Additional context: Today alone, I have spent about 7 hours working with Spacemail support via live chat to troubleshoot this issue. Despite their efforts and confirmation that everything is set up correctly on their end, the problem persists.

What I need:

  • Any advice on what else to check or try?

  • Is there a way to get more detailed SMTP debug logs from Discourse?

  • Has anyone encountered a similar issue with Spacemail or another provider?

Thank you very much for your time and support!

2

Can you confirm you followed the official install?

3

Yes, I followed the official Discourse installation guide for Docker. If you need, I can provide details about my setup or any adjustments I had to make for my VPS environment.

4

Error log details:

When attempting to send emails from Discourse, I consistently receive a timeout error in the job logs:

Job exception: Net::ReadTimeout
net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
net-protocol-0.2.2/lib/net/protocol.rb:209:in `readline'
net-smtp-0.5.1/lib/net/smtp.rb:1017:in `recv_response'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `block in do_start'
net-smtp-0.5.1/lib/net/smtp.rb:1027:in `critical'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `do_start'
net-smtp-0.5.1/lib/net/smtp.rb:642:in `start'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:318:in `block (2 levels) in perform'
... (full stacktrace available on request)

Description: This error occurs every time Discourse tries to send an email. The Net::ReadTimeout indicates that Discourse is waiting for a response from the SMTP server (Spacemail), but does not receive it in time. All network and TLS tests (openssl, telnet) succeed, and SMTP works in external clients, so the issue seems to be specific to Discourse’s SMTP communication or authentication.

If you need the full stacktrace or more details, I can provide them.

5

I am not familiar at all with that vps. If you are right at the beginning of your setup you can try starting over with a new server rather than continuing to hit your head against the wall. Maybe try a different provider if that still doesn’t work.

6

I Tried:

  1. Zap-Hosting
  2. Ultra-Host
  3. And now spaceship, where i have all of DNS Records, domain, mailbox.
7

Have you tried Troubleshoot email on a new Discourse install?

Sorry this has been such a struggle for you. Shouldn’t be so hard!

8

Yes, I did… Then I created the admin account via SSH command. After that, I saw the error: ‘Job exception: Net::ReadTimeout’

9

Summary of troubleshooting steps taken:

  • Installed Discourse on a Spaceship VPS (Phoenix, US) using the official Docker install guide.

  • Created the admin account via SSH command.

  • Configured SMTP with Spacemail (mail.spacemail.com, port 465, SSL, full email as username, correct password).

  • Reset and re-entered the SMTP password multiple times.

  • Tried both mail.spacemail.com and smtp.spacemail.com as SMTP servers.

  • Verified with Spacemail support that there are no restrictions or blocks on their side.

  • Confirmed all DNS records (MX, SPF, DKIM) are correct and propagated.

  • Successfully sent and received emails using the same Spacemail account in Gmail (SMTP works outside Discourse).

  • Tested SMTP connection from the VPS using telnet and openssl (TLS handshake and SMTP banner received successfully).

  • Changed Docker network MTU to 1400 and restarted Docker and the Discourse container.

  • Checked that Redis, PostgreSQL, and all other services are running correctly in the container.

  • Tried both destroy/start and full rebuild of the Discourse app after each change.

  • Checked logs: only Net::ReadTimeout errors when sending emails, no other errors.

  • Made sure “Enable SMTP” is enabled in the Discourse admin interface.

  • Spent several days and about 7 hours in live chat with Spaceship/Spacemail support troubleshooting this issue.

Despite all these steps, Discourse still cannot send emails and always returns a Net::ReadTimeout error.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet ``mail.spacemail.com`` 465Trying 198.177.121.32…Connected to ``mail.spacemail.com``.Escape character is ‘^]’.

(app.yml) ENV:
env:LC_ALL: en_US.UTF-8LANG: en_US.UTF-8LANGUAGE: en_US.UTF-8

DISCOURSE_DEFAULT_LOCALE: en

UNICORN_WORKERS: 4

DISCOURSE_HOSTNAME: citygaming.icu

DISCOURSE_DEVELOPER_EMAILS: ‘info@citygaming.icu’

DISCOURSE_SMTP_ADDRESS: mail.spacemail.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: info@citygaming.icu
DISCOURSE_SMTP_PASSWORD: “” –> Im using special characters
DISCOURSE_SMTP_ENABLE_START_TLS: false
DISCOURSE_SMTP_SSL: true
DISCOURSE_SMTP_DOMAIN: citygaming.icu
DISCOURSE_NOTIFICATION_EMAIL: forum@citygaming.icu

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse#  openssl s_client -connect mail.spacemail.com:465
CONNECTED(00000003)
depth=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN = *.spacemail.com
verify return:1
---
Certificate chain
 0 s:CN = *.spacemail.com
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Jun 11 00:00:00 2025 GMT; NotAfter: Jun 27 23:59:59 2026 GMT
 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
 2 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
 3 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Feb  1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGhzCCBO+gAwIBAgIRALFmOQOqKiGafcbqHk5JTvcwDQYJKoZIhvcNAQEMBQAw
YDELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBQdWJsaWMgU2VydmVyIEF1dGhlbnRpY2F0aW9uIENBIERWIFIz
NjAeFw0yNTA2MTEwMDAwMDBaFw0yNjA2MjcyMzU5NTlaMBoxGDAWBgNVBAMMDyou
c3BhY2VtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKh
nzi9sR4SQlEzDG0OSThJ7rj+zNyhq9KTYZtLLxSPtcI6ggnjOa0AbahjA5UXxjkT
RTWZfStyGucwK/eTL8pjU8aXl64vUFZK/jF0xiKcWFZ0J15+iqrP5zcv+yoHA9LE
OwelNDUE+c2/EDEhLbIqaIeKKxsS5aQ0JiTENfux/JbzcoI7vUsqJUsFiLCk7ane
+wc0viVE5YPTqc96VVhiuJu2IHwVSK6IsUXndbDXRQbkbwxORiX15pY83u3+uiiB
b/ZRfRILOZ29uYPsx3GH7Vqm4yJ7Iev4ueZ6z6Vd+lznH9iv8TZIWkWfxJ0oCDLm
ZMRe+DojBpAk/00+UtcCAwEAAaOCAwAwggL8MB8GA1UdIwQYMBaAFGjAEhYYDq/O
9oemMlejRlFdywcnMB0GA1UdDgQWBBS0oqCQUczn3dZIyiDOM+8KV4WqfTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURWUjM2LmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKQYDVR0RBCIwIIIPKi5zcGFjZW1h
aWwuY29tgg1zcGFjZW1haWwuY29tMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgA
dgCWl2S/VViXrfdDh2g3CEJ36fA61fak8zZuRqQ/D8qpxgAAAZdghNBMAAAEAwBH
MEUCIFwL6ylPjJme/WFO/xYNOoHIa6Qsod+6aZhCwPI1LODMAiEA+ljJB2bm4c2f
iD3IyuNzzR5cwDrgofUQZJftzXwq7W0AdgAZhtTHKKpv/roDb3gqTQGRqs4tcjEP
rs5dcEEtJUzH1AAAAZdghM+2AAAEAwBHMEUCIQCwY+9LQ8itV7FcOB5tcj9JsbL/
8oVh8ksyJP9uDfevjQIgGN/Nix3skQI2nJm6hOZDptJzt2ZkBv22ebwoFHmoGPgA
dgAOV5S8866pPjMbLJkHs/eQ35vCPXEyJd0hqSWsYcVOIQAAAZdghM9yAAAEAwBH
MEUCIDIR5KyuY2IHnP8pnEUCIKAGNFcSvEjY0Z3NIExZTL9rAiEAoMphPacQ7X1D
KACpJ06ijnzmZ2siXehW9oVOJCsd5K8wDQYJKoZIhvcNAQEMBQADggGBACbbMQWM
wFCA6UdMsFyK/5oU9O5YT7Bpo0MvhOADjGZNe37DsEMfjc4asr0Sx8VaXoPJUlV5
HKoPr13lkpG6HI6TXfFzr/uUbn6aUjMoEqjuAKTWh5leggMwXqxw7fRA8NKEpI/d
VcRiZW/I3JXvYiE2PmJawcum7pU8RuuEFyOq/9i47WkLtPyCvuMk8wkzHbxOU4ie
MYFvTvlbYoaZm9x95xAtkch3xF5MBPK9TLdgawNYrdJ4uXVYBebvx2ZSX7qr/AY8
T6AEdRtiuANfCqC0vXShDqG3hE+yeonza1ntUCKzVHvQVZTlXa12GNaxbczrw3Hd
D0tk6Xkx8K7YTq3dXoYzKYt+Lg2OFTpV13m26O9FYI5cwqI0CasiBdCvd/DpHBv/
iaPWNxLa2iyR/TSQyLkvWZmqStwrgg+dykA/nsD1fUq7X0qCmqxL2iUE9+ZZ3Mi3
JtgSj9qKdUYBSpfCX3h+8bPG5j4pretcVh7Ve81jCu1n2NwY0b9stGWx2A==
-----END CERTIFICATE-----
subject=CN = *.spacemail.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 7057 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 8FACA20AB7071487B74738E7FA28813C1CA106651D80EB46D271486C67E4432B
    Session-ID-ctx: 
    Resumption PSK: F99B4B27314220CB53DEE7B1D852B2AE360D39472E1F020806FAC5D40A72F206636EA0B50545C9F1875BCACB5FD35F07
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 23 bd a5 51 88 3e 2e 7f-eb 8d 81 00 95 7a a7 8b   #..Q.>.......z..
    0010 - ce 97 c1 5e 12 02 2a 46-de d9 96 d7 06 f0 b1 47   ...^..*F.......G
    0020 - 1d 79 69 7f 8e 9d f4 4a-6a cb ec 00 42 70 d6 6b   .yi....Jj...Bp.k
    0030 - a1 37 1b 9d 61 47 4a e1-16 13 bc bb e7 ee f8 de   .7..aGJ.........
    0040 - 26 fb c1 00 b0 15 76 f0-80 a3 14 8b 10 f2 c7 ab   &.....v.........
    0050 - 5c 54 cb b3 16 e2 d2 ab-36 97 c9 82 14 1d 45 d4   \T......6.....E.
    0060 - d7 4d c0 fc 9e 77 e3 44-c8 87 16 13 3a 1f c2 02   .M...w.D....:...
    0070 - 65 03 51 14 bf ab d0 0e-51 e5 9e 95 07 ef 33 f5   e.Q.....Q.....3.
    0080 - 48 9c 89 8e d9 8e 1f ea-38 3a 21 2a c1 64 44 a8   H.......8:!*.dD.
    0090 - b2 9a 69 f2 ca fa 9e 57-12 14 36 32 fb 40 b1 06   ..i....W..62.@..
    00a0 - 9e a4 b8 21 19 90 65 f8-6d ce 2d 6f 53 e0 72 23   ...!..e.m.-oS.r#
    00b0 - 5b ca b8 f8 79 bd 07 9e-97 95 d4 d3 d5 f6 25 93   [...y.........%.
    00c0 - 33 02 71 1d 55 be 9c d3-14 32 bb 9b 4e 65 67 78   3.q.U....2..Negx

    Start Time: 1758479949
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
220 SpaceMail.com Mail Node
1 Like
10

Try ports 587 or 2525 (try 587 first), do those work? 587 is the port mentioned in the install guide.

1 Like
11

Thank you for your suggestion. My mailbox provider (Spacemail) officially supports only port 465 with SSL for SMTP. However, I have also tested port 587 with STARTTLS as part of troubleshooting (together with support), but the timeout issue still persists.

12

i did standard install twice last week with 2 different email providers, and i know it works. i suspect spacemail isn’t suitable for actual transactional email.

although i have no idea about if this works

3 Likes
13

Nothing is blocked on the part of Spaceship or Spacemail. I spent seven hours discussing this with their support yesterday, and they confirmed that all necessary ports are open and SMTP is working from their side. They sent me here for further troubleshooting. Also, port 2525 is not supported by Spacemail, so I cannot use it as an alternative.

14

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# sudo ufw status
Status: active

To Action From

443/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22022/tcp ALLOW Anywhere
465/tcp ALLOW Anywhere
443/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
22022/tcp (v6) ALLOW Anywhere (v6)
465/tcp (v6) ALLOW Anywhere (v6)

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse#

1 Like
15

Not sure if that helps since you already checked accessing the port via telnet, but you could try sending a mail with Swaks (there should be an Ubuntu package available for it). I find it quite helpful to debug email problems.

16

Perhaps try a transactional email service like Brevo or Mailgun? If it works, then you may want to use that instead. From what I can see, like what Lilly said, I see no indication that it is a transaction email service.

I just asked their support and they said:

While Spacemail does not directly supports transactional emails, you can use the SMTP protocol to connect your Spacemail mailbox to your contact form or any tool that sends emails automatically.

1 Like