בעיית ניתוק SMTP מתמשכת עם Spacemail ב-Discourse (VPS, Docker)

תמיכה
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

האם אתה יכול לאשר שעקבת אחר ההתקנה הרשמית?

3

כן, עקבתי אחר המדריך הרשמי להתקנת Discourse עבור Docker. אם תצטרך, אוכל לספק פרטים על ההגדרה שלי או כל התאמה שביצעתי לסביבת ה-VPS שלי.

4

פרטי יומן השגיאות:

בעת ניסיון לשלוח מיילים מ-Discourse, אני מקבל באופן עקבי שגיאת זמן קצוב (timeout) ביומני המשימות:

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'
... (גזע מחסנית מלא זמין לפי בקשה)

תיאור: שגיאה זו מתרחשת בכל פעם ש-Discourse מנסה לשלוח דוא"ל. ה-Net::ReadTimeout מצביע על כך ש-Discourse ממתין לתגובה משרת ה-SMTP (Spacemail), אך אינו מקבל אותה בזמן. כל בדיקות הרשת ו-TLS (openssl, telnet) מצליחות, ו-SMTP עובד בלקוחות חיצוניים, כך שהבעיה נראית ספציפית לתקשורת ה-SMTP או לאימות של Discourse.

אם תזדקקו לגזע המחסנית המלא או לפרטים נוספים, אוכל לספק אותם.

5

אני כלל לא מכיר את ה-vps הזה. אם אתה ממש בתחילת ההגדרה שלך, אתה יכול לנסות להתחיל מחדש עם שרת חדש במקום להמשיך להיתקל בקשיים. אולי נסה ספק אחר אם זה עדיין לא עובד.

6

ניסיתי:

  1. Zap-Hosting
  2. Ultra-Host
  3. ועכשיו Spaceship, שם יש לי את כל רשומות ה-DNS, הדומיין, תיבת הדואר.
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

כן, עשיתי זאת… ואז יצרתי את חשבון המנהל באמצעות פקודת SSH. לאחר מכן, ראיתי את השגיאה: ‘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
10

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

לייק 1
11

תודה על הצעתך. ספק שירותי הדואר האלקטרוני שלי (Spacemail) תומך רשמית רק בפורט 465 עם SSL עבור SMTP. עם זאת, בדקתי גם את פורט 587 עם STARTTLS כחלק מהפתרון בעיות (יחד עם התמיכה), אך בעיית הזמן הקצוב עדיין נמשכת.

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

4 לייקים
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.

שום דבר לא חסום מצד Spaceship או Spacemail. ביליתי שבע שעות בדיון על כך עם התמיכה שלהם אתמול, והם אישרו שכל היציאות הדרושות פתוחות ו-SMTP פועל מצידם. הם שלחו אותי לכאן להמשך פתרון בעיות. כמו כן, יציאה 2525 אינה נתמכת על ידי Spacemail, כך שאיני יכול להשתמש בה כחלופה.

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
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

אולי כדאי לנסות שירות אימייל טרנזקציונלי כמו Brevo או Mailgun? אם זה עובד, אז אולי תרצה להשתמש בזה במקום זאת. ממה שאני יכול לראות, כמו מה שלילי אמרה, אני לא רואה שום אינדיקציה שזה שירות אימייל טרנזקציונלי.

שאלתי את התמיכה שלהם והם אמרו:

בעוד ש-Spacemail אינו תומך ישירות באימיילים טרנזקציונליים, אתה יכול להשתמש בפרוטוקול SMTP כדי לחבר את תיבת הדואר שלך ב-Spacemail לטופס יצירת הקשר שלך או לכל כלי ששולח אימיילים באופן אוטומטי.

לייק 1
17

הבעיה תהיה בצד החללית. מכיוון שניסיתי GOOGLE SMTP, וזה עובד וקיבלתי אימייל בדיקה.
היום, העברתי את זה לטכנאי החללית דרך התמיכה של החללית. אודיע לך אם יידרשו פרטים נוספים ישירות ממך.

2 לייקים
18

This is (IMO) a misinformed approach on their part due to the absolute mess around port 465.

Port 465 (SMTPS) is VERY frequently blocked in VPS environments as an anti-spam measure as it’s the historic port used for MTA-MTA TLS communication. Nowadays it’s been reassigned to SUBMISSIONS (SUBMISSION + implicit TLS) but I don’t anticipate VPS providers ever unblocking it due to the fact there will always be MTAs listening for MTA-MTA traffic on this port.

Port 587 (SUBMISSION) is explicitly the MUA-MTA mail submission port and is what should be used for authenticated mail submission in combination with STARTTLS.

Even so, port 587 is still sometimes blocked by ill-informed VPS providers.

Notwithstanding my rant about this, I see you can connect to that port, so what happens if you manually send mail from the VPS and from the container via port 465?

2 לייקים
19

@errorexee האם הצלחת לפתור את הבעיה שלך?

לייק 1
20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.