Anhaltendes SMTP-Timeout-Problem mit Spacemail auf Discourse (VPS, Docker)

Unterstützung
1

Hallo Discourse Support/Community,

Ich kämpfe seit mehreren Tagen damit, ein Problem mit ausgehenden E-Mails von meiner Discourse-Instanz zu lösen. Ich betreibe Discourse in einem Docker-Container auf einem Spaceship VPS (Phoenix, US). Mein E-Mail-Anbieter ist Spacemail (SMTP).

Problem:

  • Discourse kann keine E-Mails senden. Jeder Versuch, eine Test-E-Mail zu senden, führt zu einem Timeout-Fehler:
    • Net::ReadTimeout with #<TCPSocket:(closed)>
    • Oder: execution expired
  • Das Problem besteht unabhängig davon, ob ich mail.spacemail.com oder smtp.spacemail.com als SMTP-Server verwende.

Was ich versucht habe:

  • Alle SMTP-Einstellungen (Adresse, Port 465 für SSL, vollständige E-Mail-Adresse als Benutzername, korrektes Passwort) mit dem Spacemail-Support überprüft.
  • Das SMTP-Passwort mehrmals zurückgesetzt und neu eingegeben.
  • Mit dem Spacemail-Support bestätigt, dass es von deren Seite keine Einschränkungen oder Sperrungen gibt.
  • Telnet vom VPS zu mail.spacemail.com auf Port 465 ist erfolgreich (Verbindung wird geöffnet, kein Firewall-Problem).
  • Die Docker-Netzwerk-MTU auf 1400 geändert, wie in Discourse-Foren vorgeschlagen, und Docker sowie den Discourse-Container neu gestartet.
  • Sowohl destroy/start als auch einen vollständigen rebuild der Discourse-App versucht.
  • Überprüft, ob Redis, PostgreSQL und alle anderen Dienste im Container korrekt laufen.
  • Überprüft, ob alle DNS-Einträge (MX, SPF, DKIM) eingerichtet und propagiert sind.
  • Von mehreren Browsern und Geräten getestet, um clientseitige Probleme auszuschließen.
  • Erfolgreich E-Mails mit demselben Spacemail-Konto in Gmail gesendet und empfangen (SMTP funktioniert außerhalb von Discourse).

Umgebung:

  • Discourse läuft in Docker auf einem Ubuntu 22.04 VPS (Spaceship, Phoenix, US)
  • SMTP-Anbieter: Spacemail
  • SMTP-Einstellungen: SSL, Port 465, mail.spacemail.com (auch smtp.spacemail.com versucht)
  • Alle DNS-Einträge sind korrekt und propagiert

Protokolle:

  • Keine Fehler in den Discourse-Protokollen außer dem Timeout beim Senden von E-Mails.
  • Redis und andere Dienste laufen ohne Konflikte.
  • Unicorn-Worker-Timeouts fallen mit den E-Mail-Sendeversuchen zusammen.

Zusätzlicher Kontext: Allein heute habe ich etwa 7 Stunden damit verbracht, dieses Problem mit dem Spacemail-Support per Live-Chat zu beheben. Trotz ihrer Bemühungen und der Bestätigung, dass auf ihrer Seite alles korrekt eingerichtet ist, besteht das Problem weiterhin.

Was ich brauche:

  • Gibt es Ratschläge, was ich sonst noch überprüfen oder versuchen könnte?
  • Gibt es eine Möglichkeit, detailliertere SMTP-Debug-Protokolle von Discourse zu erhalten?
  • Sind ähnliche Probleme mit Spacemail oder einem anderen Anbieter aufgetreten?

Vielen Dank für Ihre Zeit und Unterstützung!

2

Können Sie bestätigen, dass Sie die offizielle Installation befolgt haben?

3

Ja, ich habe die offizielle Discourse-Installationsanleitung für Docker befolgt. Wenn Sie möchten, kann ich Details zu meiner Einrichtung oder zu Anpassungen, die ich für meine VPS-Umgebung vornehmen musste, bereitstellen.

4

Fehlerprotokolldetails:

Beim Versuch, E-Mails von Discourse zu senden, erhalte ich in den Job-Protokollen durchweg einen Timeout-Fehler:

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'
... (vollständiger Stacktrace auf Anfrage erhältlich)

Beschreibung: Dieser Fehler tritt jedes Mal auf, wenn Discourse versucht, eine E-Mail zu senden. Der Net::ReadTimeout zeigt an, dass Discourse auf eine Antwort vom SMTP-Server (Spacemail) wartet, diese aber nicht rechtzeitig erhält. Alle Netzwerk- und TLS-Tests (openssl, telnet) sind erfolgreich und SMTP funktioniert in externen Clients. Das Problem scheint daher spezifisch für die SMTP-Kommunikation oder Authentifizierung von Discourse zu sein.

Wenn Sie den vollständigen Stacktrace oder weitere Details benötigen, kann ich diese gerne bereitstellen.

5

Ich bin mit diesem VPS überhaupt nicht vertraut. Wenn Sie ganz am Anfang Ihrer Einrichtung stehen, können Sie versuchen, mit einem neuen Server neu zu beginnen, anstatt sich weiter den Kopf an der Wand zu stoßen. Versuchen Sie es vielleicht mit einem anderen Anbieter, wenn das immer noch nicht funktioniert.

6

Ich habe versucht:

  1. Zap-Hosting
  2. Ultra-Host
  3. Und jetzt Spaceship, wo ich alle DNS-Einträge, Domain und Mailbox habe.
7

Haben Sie es unter Troubleshoot email on a new Discourse install versucht?

Entschuldigen Sie, dass es so ein Kampf für Sie war. Das sollte nicht so schwer sein!

8

Ja, das habe ich… Dann habe ich das Administratorkonto über einen SSH-Befehl erstellt. Danach sah ich den Fehler: „Job-Ausnahme: Net::ReadTimeout“

9

Zusammenfassung der unternommenen Fehlerbehebungsschritte:

  • Discourse auf einem Spaceship VPS (Phoenix, US) mit der offiziellen Docker-Installationsanleitung installiert.

  • Administratorkonto über SSH-Befehl erstellt.

  • SMTP mit Spacemail (mail.spacemail.com, Port 465, SSL, vollständige E-Mail als Benutzername, korrektes Passwort) konfiguriert.

  • Das SMTP-Passwort mehrmals zurückgesetzt und neu eingegeben.

  • Sowohl mail.spacemail.com als auch smtp.spacemail.com als SMTP-Server ausprobiert.

  • Mit dem Spacemail-Support verifiziert, dass es von deren Seite keine Einschränkungen oder Sperrungen gibt.

  • Bestätigt, dass alle DNS-Einträge (MX, SPF, DKIM) korrekt sind und propagiert wurden.

  • Erfolgreich E-Mails mit demselben Spacemail-Konto in Gmail gesendet und empfangen (SMTP funktioniert außerhalb von Discourse).

  • SMTP-Verbindung vom VPS mit telnet und openssl getestet (TLS-Handshake und SMTP-Banner erfolgreich empfangen).

  • MTU des Docker-Netzwerks auf 1400 geändert und Docker sowie den Discourse-Container neu gestartet.

  • Überprüft, ob Redis, PostgreSQL und alle anderen Dienste im Container korrekt laufen.

  • Sowohl destroy/start als auch vollständiges Rebuild der Discourse-App nach jeder Änderung versucht.

  • Protokolle überprüft: Nur Net::ReadTimeout-Fehler beim Senden von E-Mails, keine anderen Fehler.

  • Sichergestellt, dass “SMTP aktivieren” in der Discourse-Adminoberfläche aktiviert ist.

  • Mehrere Tage und etwa 7 Stunden im Live-Chat mit dem Spaceship/Spacemail-Support verbracht, um dieses Problem zu beheben.

Trotz all dieser Schritte kann Discourse immer noch keine E-Mails senden und gibt immer einen Net::ReadTimeout-Fehler zurück.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet `mail.spacemail.com` 465
Trying 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: “” –> Ich verwende Sonderzeichen
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
nnzi9sR4SQlEzDG0OSThJ7rj+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
dvCWl2S/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 „Gefällt mir“
10

Versuchen Sie die Ports 587 oder 2525 (versuchen Sie zuerst 587). Funktionieren diese? 587 ist der Port, der im Installationshandbuch erwähnt wird.

1 „Gefällt mir“
11

Vielen Dank für Ihren Vorschlag. Mein Mailbox-Anbieter (Spacemail) unterstützt offiziell nur Port 465 mit SSL für SMTP. Ich habe jedoch im Rahmen der Fehlerbehebung (zusammen mit dem Support) auch Port 587 mit STARTTLS getestet, aber das Timeout-Problem besteht weiterhin.

12

Ich habe letzte Woche zweimal eine Standardinstallation mit zwei verschiedenen E-Mail-Anbietern durchgeführt und weiß, dass es funktioniert. Ich vermute, dass Spacemail nicht für tatsächliche Transaktions-E-Mails geeignet ist.

obwohl ich keine Ahnung habe, ob das funktioniert

4 „Gefällt mir“
13

Auf Seiten von Spaceship oder Spacemail ist nichts blockiert. Ich habe gestern sieben Stunden damit verbracht, dies mit deren Support zu besprechen, und sie haben bestätigt, dass alle notwendigen Ports offen sind und SMTP von ihrer Seite aus funktioniert. Sie haben mich für weitere Fehlerbehebungen hierher geschickt. Außerdem wird Port 2525 von Spacemail nicht unterstützt, daher kann ich ihn nicht als Alternative nutzen.

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 „Gefällt mir“
15

Ich bin mir nicht sicher, ob das hilft, da Sie bereits den Zugriff auf den Port per Telnet überprüft haben, aber Sie könnten versuchen, eine E-Mail mit Swaks zu senden (dafür sollte ein Ubuntu-Paket verfügbar sein). Ich finde es sehr hilfreich zur Fehlersuche bei E-Mail-Problemen.

16

Versuchen Sie es vielleicht mit einem Transaktions-E-Mail-Dienst wie Brevo oder Mailgun? Wenn es funktioniert, möchten Sie diesen vielleicht stattdessen verwenden. Soweit ich sehen kann, und wie Lilly sagte, sehe ich keinen Hinweis darauf, dass es sich um einen Transaktions-E-Mail-Dienst handelt.

Ich habe gerade ihren Support gefragt und sie sagten:

Obwohl Spacemail Transaktions-E-Mails nicht direkt unterstützt, können Sie das SMTP-Protokoll verwenden, um Ihre Spacemail-Postfach mit Ihrem Kontaktformular oder jedem Tool zu verbinden, das automatisch E-Mails versendet.

1 „Gefällt mir“
17

Das Problem liegt auf der Seite des Raumschiffs. Denn ich habe GOOGLE SMTP ausprobiert, und es funktioniert, und ich habe eine Test-E-Mail erhalten.
Heute habe ich dies über den Raumschiff-Support an die Raumschiff-Techniker weitergeleitet. Ich werde Sie informieren, wenn weitere Details von Ihnen benötigt werden.

2 „Gefällt mir“
18

Dies ist (meiner Meinung nach) ein fehlinformierter Ansatz ihrerseits aufgrund des absoluten Durcheinanders um Port 465.

Port 465 (SMTPS) wird in VPS-Umgebungen SEHR häufig als Anti-Spam-Maßnahme blockiert, da es der historische Port für die MTA-MTA-TLS-Kommunikation ist. Heutzutage wurde er für SUBMISSIONS neu zugewiesen (reassigned) (SUBMISSION + implizites TLS), aber ich gehe nicht davon aus, dass VPS-Anbieter ihn jemals wieder freigeben werden, da es immer MTAs geben wird, die auf diesem Port auf MTA-MTA-Verkehr lauschen.

Port 587 (SUBMISSION) ist ausdrücklich der MUA-MTA-Mail-Submission-Port und sollte für die authentifizierte Mail-Einreichung in Kombination mit STARTTLS verwendet werden.

Dennoch wird Port 587 immer noch manchmal von schlecht informierten VPS-Anbietern blockiert.

Ungeachtet meiner Tirade darüber sehe ich, dass Sie eine Verbindung zu diesem Port herstellen können. Was passiert also, wenn Sie manuell eine E-Mail vom VPS und vom Container über Port 465 senden?

2 „Gefällt mir“
19

@errorexee Konnten Sie Ihr Problem lösen?

1 „Gefällt mir“
20

Dieses Thema wurde 14 Tage nach der letzten Antwort automatisch geschlossen. Neue Antworten sind nicht mehr möglich.