مشكلة مهلة SMTP مستمرة مع Spacemail على Discourse (VPS، Docker)

الدعم
1

مرحباً بفريق دعم ومجتمع Discourse،

لقد كنت أواجه صعوبة لعدة أيام في حل مشكلة رسائل البريد الإلكتروني الصادرة من نسخة Discourse الخاصة بي. أقوم بتشغيل Discourse في حاوية Docker على خادم VPS من نوع Spaceship (فينيكس، الولايات المتحدة). مزود البريد الإلكتروني الخاص بي هو Spacemail (SMTP).

المشكلة:

  • لا يمكن لـ Discourse إرسال رسائل البريد الإلكتروني. كل محاولة لإرسال بريد إلكتروني تجريبي تؤدي إلى خطأ في انتهاء المهلة:

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

    • أو: execution expired

  • تستمر المشكلة بغض النظر عما إذا كنت أستخدم mail.spacemail.com أو smtp.spacemail.com كخادم SMTP.

ما جربته:

  • التحقق من جميع إعدادات SMTP (العنوان، المنفذ 465 لـ SSL، البريد الإلكتروني الكامل كاسم مستخدم، كلمة المرور الصحيحة) مع دعم Spaceship/Spacemail.

  • إعادة تعيين وإعادة إدخال كلمة مرور SMTP عدة مرات.

  • التأكد من دعم Spacemail أنه لا توجد قيود أو حظر من جانبهم.

  • نجاح اختبار Telnet من خادم VPS إلى mail.spacemail.com على المنفذ 465 (يتم فتح الاتصال، لا توجد مشكلة في جدار الحماية).

  • تغيير MTU لشبكة Docker إلى 1400 كما هو مقترح في منتديات Discourse وإعادة تشغيل Docker وحاوية Discourse.

  • تجربة كل من destroy/start و rebuild كامل لتطبيق Discourse.

  • التحقق من أن Redis و PostgreSQL وجميع الخدمات الأخرى تعمل بشكل صحيح في الحاوية.

  • التحقق من أن جميع سجلات DNS (MX، SPF، DKIM) تم إعدادها وانتشارها.

  • الاختبار من متصفحات وأجهزة متعددة لاستبعاد المشكلات من جانب العميل.

  • نجاح إرسال واستقبال رسائل البريد الإلكتروني باستخدام نفس حساب Spacemail في Gmail (يعمل SMTP خارج Discourse).

البيئة:

  • Discourse يعمل في Docker على خادم Ubuntu 22.04 VPS (Spaceship، Phoenix، US)

  • مزود SMTP: Spacemail

  • إعدادات SMTP: SSL، المنفذ 465، mail.spacemail.com (تمت تجربة smtp.spacemail.com أيضًا)

  • جميع سجلات DNS صحيحة ومنتشرة

السجلات:

  • لا توجد أخطاء في سجلات Discourse باستثناء انتهاء مهلة إرسال البريد الإلكتروني.

  • Redis والخدمات الأخرى تعمل دون تعارض.

  • تتزامن مهلات عامل Unicorn مع محاولات إرسال البريد الإلكتروني.

سياق إضافي: اليوم وحده، قضيت حوالي 7 ساعات في العمل مع دعم Spacemail عبر الدردشة المباشرة لحل هذه المشكلة. على الرغم من جهودهم وتأكيدهم على أن كل شيء تم إعداده بشكل صحيح من جانبهم، إلا أن المشكلة لا تزال قائمة.

ما أحتاجه:

  • أي نصائح حول ما يجب التحقق منه أو تجربته؟

  • هل هناك طريقة للحصول على سجلات تصحيح أخطاء SMTP أكثر تفصيلاً من Discourse؟

  • هل واجه أي شخص مشكلة مماثلة مع Spacemail أو مزود آخر؟

شكراً جزيلاً لوقتكم ودعمكم!

2

هل يمكنك تأكيد أنك اتبعت التثبيت الرسمي؟

3

نعم، لقد اتبعت دليل التثبيت الرسمي لـ Discourse باستخدام Docker. إذا احتجت، يمكنني تقديم تفاصيل حول إعدادي أو أي تعديلات اضطررت لإجرائها لبيئة الخادم الافتراضي الخاص بي.

4

تفاصيل سجل الأخطاء:

عند محاولة إرسال رسائل البريد الإلكتروني من Discourse، أتلقى باستمرار خطأ انتهاء المهلة في سجلات المهام:

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

هل جربت Troubleshoot email on a new Discourse install
آسف لأن هذا كان صعبًا جدًا بالنسبة لك. لا ينبغي أن يكون الأمر بهذه الصعوبة!

8

نعم، لقد فعلت ذلك… ثم قمت بإنشاء حساب المسؤول عبر أمر SSH. بعد ذلك، رأيت الخطأ: ‘Job exception: Net::ReadTimeout’

9

ملخص خطوات استكشاف الأخطاء وإصلاحها التي تم اتخاذها:

  • تثبيت Discourse على خادم VPS (Spaceship VPS) في (Phoenix, US) باستخدام دليل التثبيت الرسمي لـ Docker.

  • إنشاء حساب المسؤول عبر أمر SSH.

  • تكوين SMTP مع Spacemail (mail.spacemail.com, port 465, SSL, البريد الإلكتروني الكامل كاسم مستخدم، كلمة المرور الصحيحة).

  • إعادة تعيين وإعادة إدخال كلمة مرور SMTP عدة مرات.

  • تجربة كل من mail.spacemail.com و smtp.spacemail.com كخوادم SMTP.

  • التحقق مع دعم Spacemail من عدم وجود قيود أو حظر من جانبهم.

  • التأكد من صحة جميع سجلات DNS (MX, SPF, DKIM) وانتشارها.

  • إرسال واستقبال رسائل البريد الإلكتروني بنجاح باستخدام نفس حساب Spacemail في Gmail (SMTP يعمل خارج Discourse).

  • اختبار اتصال SMTP من خادم VPS باستخدام telnet و openssl (تم استلام مصافحة TLS وشعار SMTP بنجاح).

  • تغيير MTU لشبكة Docker إلى 1400 وإعادة تشغيل Docker وحاوية Discourse.

  • التحقق من أن Redis و PostgreSQL وجميع الخدمات الأخرى تعمل بشكل صحيح داخل الحاوية.

  • تجربة كل من destroy/start وإعادة بناء كاملة لتطبيق Discourse بعد كل تغيير.

  • التحقق من السجلات: فقط أخطاء Net::ReadTimeout عند إرسال رسائل البريد الإلكتروني، ولا توجد أخطاء أخرى.

  • التأكد من تمكين “Enable SMTP” في واجهة مسؤول Discourse.

  • قضاء عدة أيام وحوالي 7 ساعات في الدردشة المباشرة مع دعم Spaceship/Spacemail لاستكشاف هذه المشكلة وإصلاحها.

على الرغم من كل هذه الخطوات، لا يزال Discourse غير قادر على إرسال رسائل البريد الإلكتروني ويظهر دائمًا خطأ Net::ReadTimeout.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet mail.spacemail.com 465
محاولة الاتصال بـ 198.177.121.32… متصل بـ mail.spacemail.com.
حرف الهروب هو ‘^\]’.

(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
متصل (00000003)
العمق=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
التحقق من الإرجاع: 1
العمق=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
التحقق من الإرجاع: 1
العمق=0 CN = *.spacemail.com
التحقق من الإرجاع: 1
---
سلسلة الشهادات
0 s:CN = *.spacemail.com
i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
a:PKEY: rsaEncryption, 2048 (بت)؛ 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 (بت)؛ 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 (بت)؛ 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 (بت)؛ sigalg: RSA-SHA384
v:NotBefore: Feb 1 00:00:00 2010 GMT؛ NotAfter: Jan 18 23:59:59 2038 GMT
---
شهادة الخادم
-----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
dvCWl2S/VViXrfdDh2g3CEJ36fA61fak8zZuRqQ/D8qpxgAAAZdghNBMAAAEAwBH
MEUCIFwL6ylPjJme/WFO/xYNOoHIa6Qsod+6aZhCwPI1LODMAiEA+ljJB2bm4c2f
iD3IyuNzzR5cwDrgofUQZJftzXwq7W0AdgAZhtTHKKpv/roDb3gqTQGRqs4tcjEP
rs5dcEEtJUzH1AAAAZdghM+2AAAEAwBHMEUCIQCwY+9LQ8itV7FcOB5tcj9JsbL/
8oVh8ksyJP9uDfevjQIgGN/Nix3skQI2nJm6hOZDptJzt2ZkBv22ebwoFHmoGPgA
dvAOV5S8866pPjMbLJkHs/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-----
الموضوع=CN = *.spacemail.com
المصدر=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
---
لم يتم إرسال أسماء CA لشهادة العميل
تجزئة توقيع الخادم: SHA256
نوع توقيع الخادم: RSA-PSS
مفتاح الخادم المؤقت: X25519, 253 بت
---
تمت قراءة 7057 بايت وكتابة 400 بايت في مصافحة SSL
التحقق: موافق
---
جديد، TLSv1.3، التشفير هو TLS_AES_256_GCM_SHA384
مفتاح الخادم العام هو 2048 بت
إعادة التفاوض الآمنة غير مدعومة
الضغط: لا شيء
التوسع: لا شيء
لم يتم التفاوض على ALPN
لم يتم إرسال البيانات المبكرة
رمز التحقق: 0 (موافق)
---
---
وصول تذكرة جلسة جديدة بعد المصافحة:
جلسة SSL:
البروتوكول: TLSv1.3
التشفير: TLS_AES_256_GCM_SHA384
معرف الجلسة: 8FACA20AB7071487B74738E7FA28813C1CA106651D80EB46D271486C67E4432B
معرف الجلسة-ctx:
استئناف PSK: F99B4B27314220CB53DEE7B1D852B2AE360D39472E1F020806FAC5D40A72F206636EA0B50545C9F1875BCACB5FD35F07
معرف PSK: لا شيء
تلميح معرف PSK: لا شيء
اسم مستخدم SRP: لا شيء
تلميح مدة صلاحية جلسة TLS: 7200 (ثانية)
تذكرة جلسة TLS:
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

وقت البدء: 1758479949
المهلة: 7200 (ثانية)
رمز التحقق: 0 (موافق)
سر رئيسي ممتد: لا
الحد الأقصى للبيانات المبكرة: 0
---
قراءة R BLOCK
220 SpaceMail.com Mail Node
إعجاب واحد (1)
10

جرب المنافذ 587 أو 2525 (جرب 587 أولاً)، هل تعمل؟ 587 هو المنفذ المذكور في دليل التثبيت.

إعجاب واحد (1)
11

شكراً لاقتراحك. مزود خدمة البريد الإلكتروني الخاص بي (Spacemail) يدعم رسميًا المنفذ 465 فقط مع SSL لبروتوكول SMTP. ومع ذلك، لقد اختبرت أيضًا المنفذ 587 مع STARTTLS كجزء من استكشاف الأخطاء وإصلاحها (بالتعاون مع الدعم)، لكن مشكلة المهلة لا تزال قائمة.

12

لقد قمت بالتثبيت القياسي مرتين الأسبوع الماضي باستخدام مزودي بريد إلكتروني مختلفين، وأعلم أنه يعمل. أشك في أن spacemail غير مناسب للبريد الإلكتروني المعاملاتي الفعلي.

على الرغم من أنه ليس لدي أي فكرة عما إذا كان هذا يعمل

4 إعجابات
13

لا يوجد أي شيء محظور من جانب Spaceship أو Spacemail. لقد قضيت سبع ساعات في مناقشة هذا الأمر مع دعمهم بالأمس، وأكدوا أن جميع المنافذ الضرورية مفتوحة وأن SMTP يعمل من جانبهم. أرسلوني إلى هنا لمزيد من استكشاف الأخطاء وإصلاحها. أيضًا، لا يدعم Spacemail المنفذ 2525، لذلك لا يمكنني استخدامه كبديل.

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

لست متأكدًا مما إذا كان ذلك يساعد نظرًا لأنك قمت بالفعل بالتحقق من الوصول إلى المنفذ عبر telnet، ولكن يمكنك محاولة إرسال بريد إلكتروني باستخدام Swaks (يجب أن تكون هناك حزمة Ubuntu متاحة له). أجد أنه مفيد جدًا لتصحيح مشاكل البريد الإلكتروني.

16

ربما تجرب خدمة بريد إلكتروني للمعاملات مثل Brevo أو Mailgun؟ إذا نجحت، فقد ترغب في استخدامها بدلاً من ذلك. على حد علمي، كما قالت ليلي، لا أرى أي مؤشر على أنها خدمة بريد إلكتروني للمعاملات.

لقد سألت دعمهم للتو وقالوا:

بينما لا يدعم Spacemail رسائل البريد الإلكتروني للمعاملات بشكل مباشر، يمكنك استخدام بروتوكول SMTP لربط صندوق بريد Spacemail الخاص بك بنموذج الاتصال الخاص بك أو بأي أداة ترسل رسائل البريد الإلكتروني تلقائيًا.

إعجاب واحد (1)
17

المشكلة ستكون في جانب المركبة الفضائية. لأنني جربت GOOGLE SMTP، وقد نجح وحصلت على بريد إلكتروني تجريبي.
اليوم، قمت بإعادة توجيه هذا إلى فنيي المركبة الفضائية عبر دعم المركبة الفضائية. سأعلمك إذا كانت هناك أي تفاصيل مطلوبة منك مباشرة.

إعجابَين (2)
18

هذا (في رأيي) نهج خاطئ من جانبهم بسبب الفوضى المطلقة حول المنفذ 465.

المنفذ 465 (SMTPS) محظور بشكل متكرر جدًا في بيئات VPS كإجراء لمكافحة البريد العشوائي نظرًا لأنه المنفذ التاريخي المستخدم لاتصال MTA-MTA TLS. في الوقت الحاضر، تم إعادة تعيينه إلى SUBMISSIONS (SUBMISSION + ضمني TLS) ولكنني لا أتوقع أن يقوم مزودو VPS بإلغاء حظره أبدًا نظرًا لوجود دائمًا MTAs تستمع لحركة مرور MTA-MTA على هذا المنفذ.

المنفذ 587 (SUBMISSION) هو بشكل صريح منفذ إرسال البريد MUA-MTA وهو ما يجب استخدامه لإرسال البريد الموثق بالاشتراك مع STARTTLS.

حتى مع ذلك، لا يزال المنفذ 587 محظورًا أحيانًا من قبل مزودي VPS غير المستنيرين.

بصرف النظر عن تذمري بشأن هذا، أرى أنه يمكنك الاتصال بهذا المنفذ، فماذا يحدث إذا أرسلت بريدًا يدويًا من VPS ومن الحاوية عبر المنفذ 465؟

إعجابَين (2)
19

@errorexee هل تمكنت من حل مشكلتك؟

إعجاب واحد (1)
20

تم إغلاق هذا الموضوع تلقائيًا بعد 14 يومًا من آخر رد. لم تعد الردود الجديدة مسموحًا بها.