Spacemail에서 Discourse(VPS, Docker) 사용 시 지속되는 SMTP 타임아웃 문제

[errorexee (Error.EXE)]

Discourse 지원팀/커뮤니티 여러분께,

Discourse 인스턴스에서 발신되는 이메일 관련 문제를 해결하기 위해 며칠 동안 애를 쓰고 있습니다. Spaceship VPS(미국 피닉스)에서 Docker 컨테이너로 Discourse를 실행 중이며, 메일 제공사는 Spacemail(SMTP)입니다.

문제:

• Discourse가 이메일을 보낼 수 없습니다. 테스트 이메일 전송을 시도할 때마다 타임아웃 오류가 발생합니다:

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

  • 또는: execution expired

• SMTP 서버로 mail.spacemail.com을 사용하든 smtp.spacemail.com을 사용하든 문제가 지속됩니다.

시도해 본 조치:

• Spaceship/Spacemail 지원팀과 함께 모든 SMTP 설정(주소, SSL용 포트 465, 전체 이메일 주소를 사용자 이름으로 사용, 올바른 비밀번호)을 확인했습니다.

• SMTP 비밀번호를 여러 번 초기화하고 다시 입력했습니다.

• Spacemail 지원팀에서 자사 측에 제한이나 차단이 없음을 확인받았습니다.

• VPS에서 mail.spacemail.com의 포트 465로 Telnet을 시도했는데 성공했습니다(연결이 열리며, 방화벽 문제는 없음).

• Discourse 포럼에서 제안한 대로 Docker 네트워크 MTU를 1400으로 변경하고 Docker 및 Discourse 컨테이너를 재시작했습니다.

• Discourse 앱의 destroy/start와 전체 rebuild를 모두 시도했습니다.

• 컨테이너 내에서 Redis, PostgreSQL 및 기타 모든 서비스가 정상적으로 실행 중인지 확인했습니다.

• 모든 DNS 레코드(MX, SPF, DKIM)가 설정되고 전파되었는지 확인했습니다.

• 클라이언트 측 문제를 배제하기 위해 여러 브라우저와 기기로 테스트했습니다.

• 동일한 Spacemail 계정으로 Gmail에서 이메일을 성공적으로 주고받았습니다(Discourse 외부에서는 SMTP가 정상 작동함).

환경:

• Ubuntu 22.04 VPS(Spaceship, 미국 피닉스)에서 Docker로 실행 중인 Discourse

• SMTP 제공사: Spacemail

• SMTP 설정: SSL, 포트 465, mail.spacemail.com (smtp.spacemail.com도 시도함)

• 모든 DNS 레코드가 정확하며 전파됨

로그:

• 이메일 전송 시 타임아웃 오류를 제외하고는 Discourse 로그에 오류가 없습니다.

• Redis 및 기타 서비스가 충돌 없이 실행 중입니다.

• Unicorn 워커 타임아웃이 이메일 전송 시도와 일치합니다.

추가 정보: 오늘 하루에만 Spacemail 지원팀과 라이브 채팅으로 이 문제를 해결하기 위해 약 7시간을 보냈습니다. 그들의 노력에도 불구하고 자사 측에서 모든 것이 올바르게 설정되어 있다고 확인해 주었지만, 문제는 여전히 지속되고 있습니다.

필요한 도움:

• 추가로 확인하거나 시도해 볼 수 있는 사항에 대한 조언이 있을까요?

• Discourse에서 더 자세한 SMTP 디버그 로그를 가져올 방법이 있을까요?

• Spacemail 또는 다른 제공사에서 비슷한 문제를 경험하신 분이 있을까요?

귀하의 시간과 지원에 진심으로 감사드립니다!

[tobiaseigen]

공식 설치 지침을 따랐는지 확인해 주시겠어요?

[errorexee (Error.EXE)]

네, Docker용 공식 Discourse 설치 가이드를 따랐습니다. 필요하시면 제 환경 설정에 대한 세부 정보나 VPS 환경에 맞게 적용한 조정 사항을 공유해 드릴 수 있습니다.

[errorexee (Error.EXE)]

오류 로그 세부 정보:

Discourse에서 이메일을 보내려 하면 작업(job) 로그에 일관되게 타임아웃 오류가 발생합니다:

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가 정상적으로 작동하므로 이 문제는 Discourse의 SMTP 통신 또는 인증에 특이한 것으로 보입니다.

전체 스택 트레이스나 추가 세부 정보가 필요하시면 제공할 수 있습니다.

[tobiaseigen]

저는 그 VPS에 대해 전혀 익숙하지 않습니다. 만약 지금 셋업의 가장 초기 단계에 있다면, 계속 벽에 머리를 부딪히기보다는 새 서버로 처음부터 다시 시작해보는 것이 좋습니다. 그래도 해결되지 않는다면 다른 프로바이더를 시도해 보세요.

[errorexee (Error.EXE)]

시도해 본 것:

1. Zap-Hosting
2. Ultra-Host
3. 그리고 지금의 spaceship. 여기에는 DNS 레코드, 도메인, 메일박스가 모두 있습니다.

[tobiaseigen]

Troubleshoot email on a new Discourse install? 를 시도해 보셨나요?

이 문제로 인해 많이 고생하셨네요. 이렇게 어려울 일이 아니어야 합니다!

[errorexee (Error.EXE)]

네, 했습니다… 그 다음 SSH 명령어로 관리자 계정을 생성했습니다. 그러고 나서 'Job exception: Net::ReadTimeout’라는 오류를 확인했습니다.

[errorexee (Error.EXE)]

실시된 문제 해결 단계 요약:

• 공식 Docker 설치 가이드를 사용하여 Spaceship VPS(미국 피닉스)에 Discourse를 설치했습니다.

• SSH 명령을 통해 관리자 계정을 생성했습니다.

• Spacemail을 사용하여 SMTP를 설정했습니다 (mail.spacemail.com, 포트 465, SSL, 전체 이메일 주소를 사용자 이름으로 사용, 올바른 비밀번호).

• SMTP 비밀번호를 여러 번 초기화하고 다시 입력했습니다.

• SMTP 서버로 mail.spacemail.com과 smtp.spacemail.com을 모두 시도했습니다.

• Spacemail 지원팀과 확인한 결과, 상대방 측에는 제한이나 차단이 없음을 확인했습니다.

• 모든 DNS 레코드(MX, SPF, DKIM)가 정확하고 전파되었는지 확인했습니다.

• 같은 Spacemail 계정으로 Gmail에서 이메일을 성공적으로 보내고 받을 수 있었습니다 (Discourse 외부에서는 SMTP가 정상 작동함).

• VPS에서 telnet과 openssl을 사용하여 SMTP 연결을 테스트했습니다 (TLS 핸드셰이크와 SMTP 배너를 성공적으로 수신함).

• Docker 네트워크 MTU를 1400으로 변경하고 Docker와 Discourse 컨테이너를 재시작했습니다.

• 컨테이너 내에서 Redis, PostgreSQL 및 기타 모든 서비스가 올바르게 실행 중인지 확인했습니다.

• 각 변경 사항 후 Discourse 앱의 destroy/start 및 전체 재빌드를 모두 시도했습니다.

• 로그를 확인한 결과: 이메일 전송 시 Net::ReadTimeout 오류만 발생하고, 다른 오류는 없었습니다.

• Discourse 관리자 인터페이스에서 “SMTP 사용”이 활성화되어 있는지 확인했습니다.

• 이 문제를 해결하기 위해 Spaceship/Spacemail 지원팀과 라이브 채팅으로 며칠 동안 약 7시간을 보냈습니다.

이 모든 단계를 거쳤음에도 Discourse는 여전히 이메일을 보내지 못하고 항상 Net::ReadTimeout 오류를 반환합니다.

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: “” –> 특수 문자를 사용 중입니다
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

---

[NateDhaliwal]

포트 587 또는 2525(587을 먼저 시도해 보세요)을 시도해 보셨나요? 해당 포트가 작동합니까? 587은 설치 가이드에 언급된 포트입니다.

[errorexee (Error.EXE)]

제안해 주셔서 감사합니다. 제 메일 제공업체(Spacemail)는 SMTP의 경우 공식적으로 SSL을 사용하는 포트 465만 지원합니다. 하지만 문제 해결을 위해 지원팀과 함께 STARTTLS를 사용하는 포트 587도 테스트해 보았으나, 타임아웃 문제는 여전히 지속되고 있습니다.

[Lilly (Lillian)]

지난주에 다른 이메일 제공업체 2곳으로 표준 설치를 두 번 진행했고, 정상 작동하는 것을 알고 있습니다. spacemail이 실제 트랜잭션 이메일에는 적합하지 않다고 추정합니다.

최초 관리자 계정 생성 시 발생하는 문제

[image] This is my current configuration and I cannot create the first admin account because its not sending the activation email. I have used SMTP with my provider and it works, the issue is with discourse I have tried the same credentials with thunderbird and it worked. I have tried my doctor also as this topic suggests. These are the results [image]

이것이 작동하는지는 전혀 모르겠지만

@errorexee

Spaceship VPS

[errorexee (Error.EXE)]

Spaceship이나 Spacemail 쪽에서는 아무것도 차단되어 있지 않습니다. 어제 그들의 지원팀과 7시간 동안 이 문제에 대해 논의했으며, 모든 필요한 포트가 열려 있고 SMTP가 그들의 측에서 정상적으로 작동한다고 확인받았습니다. 그들은 추가적인 문제 해결을 위해 저를 이곳으로 보냈습니다. 또한, Spacemail은 포트 2525를 지원하지 않으므로 이를 대안으로 사용할 수 없습니다.

[errorexee (Error.EXE)]

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#

[schneeland]

telnet으로 포트 접근을 이미 확인하셨기 때문에 도움이 될지는 모르겠지만, Swaks로 메일을 보내보는 것을 시도해 보실 수 있습니다 (Ubuntu용 패키지도 제공될 것입니다). 이메일 문제를 디버깅할 때 꽤 유용하다고 생각합니다.

[NateDhaliwal]

Brevo나 Mailgun 같은 트랜잭션 이메일 서비스를 사용해 보는 건 어떨까요? 잘 작동한다면 그걸 대신 사용해도 좋을 것 같습니다. 제가 볼 때, Lilly가 말한 대로 트랜잭션 이메일 서비스라는 어떤 흔적도 보이지 않습니다.

방금 그들의 지원팀에 문의해 보았더니 이렇게 답변했습니다:

Spacemail은 트랜잭션 이메일을 직접 지원하지 않지만, SMTP 프로토콜을 사용하여 Spacemail 메일박스를 연락처 폼이나 이메일을 자동으로 보내는 어떤 도구와 연결할 수 있습니다.

[errorexee (Error.EXE)]

문제는 우주선(스페이스십) 측에 있을 것 같습니다. 구글 SMTP를 시도해 보았으며, 작동했고 테스트 이메일도 정상적으로 수신되었습니다.
오늘 이 내용을 우주선 기술자에게 우주선 지원을 통해 전달했습니다. 귀하에게서 직접 필요한 세부 사항이 있으면 알려드리겠습니다.

[supermathie (Michael Brown)]

@errorexee

제 메일박스 제공업체(Spacemail)는 SMTP에 대해 공식적으로 SSL이 적용된 포트 465만 지원합니다. 하지만 트러블슈팅 과정(지원팀과 함께)의 일환으로 STARTTLS와 함께 포트 587도 테스트해 보았으나, 타임아웃 문제는 여전히 지속되고 있습니다.

(제 생각에는) 포트 465를 둘러싼 절대적 혼란 때문에, 이는 그들의 잘못된 정보에 기반한 접근 방식입니다.

포트 465(SMTPS)는 MTA-MTA 간 TLS 통신에 사용되던 역사적 포트이기 때문에, 스팸 방지 조치로 VPS 환경에서 매우 자주 차단됩니다. 오늘날에는 이 포트가 SUBMISSION(SUBMISSION + 임플리시트 TLS)용으로 재할당되었지만, 이 포트에서 MTA-MTA 트래픽을 대기하는 MTA가 항상 존재할 것이기 때문에 VPS 제공업체가 이를 해제할 것이라고 기대하지 않습니다.

포트 587(SUBMISSION)은 명시적으로 MUA-MTA 메일 제출 포트이며, STARTTLS와 조합하여 인증된 메일 제출에 사용되어야 하는 포트입니다.

그럼에도 불구하고, 포트 587은 여전히 잘 모르는 VPS 제공업체들에 의해 때때로 차단됩니다.

이러한 불평을 제쳐두고, 해당 포트에 연결할 수 있다는 것을 확인했으므로, VPS와 컨테이너에서 수동으로 포트 465를 통해 메일을 전송하면 어떤 일이 발생합니까?

[tobiaseigen]

@errorexee 문제가 해결되었나요?