مساعدة مطلوبة، أنا عالق في تصحيح إعدادات البريد الإلكتروني (Infomaniak/Brevo)

أهلاً!

أقوم بتثبيت Discourse لجمعيتنا الصغيرة غير الربحية. لقد اخترت الحصول على مثيل سحابي Ubuntu 22.04 في سحابة عامة من Infomaniak والحصول على رسائل البريد الإلكتروني الخاصة بالمعاملات من Brevo لأن لديهم 300 بريد إلكتروني شهريًا في خطتهم المجانية.

لقد مررت بالعديد من المشاكل، واحدة تلو الأخرى، لإعداد الخادم، وقد ساعدتني الوثائق والمشاركات هنا كثيرًا…

ولكن

لقد وصلت الآن إلى نقطة لا أعرف كيف أتقدم.

  1. يمكن الوصول إلى المثيل الخاص بي على النطاق الفرعي forum.aether-labs.fr الخاص بنا.

  2. حسابي في Brevo يعمل بشكل صحيح، حيث نجحت في إرسال رسائل بريد إلكتروني من noreply@forum.aether-labs.fr من Thunderbird.

  3. لكنني لا أتلقى بريد المسؤول الأول الخاص بي للتحقق من الحساب.

لذلك قرأت بالتفصيل المنشور استكشاف أخطاء البريد الإلكتروني في تثبيت Discourse جديد (لا يوجد رابط بسبب قاعدة المستخدم الجديد) وجربت أشياء.

  1. يبدو أن حاوية التطبيق (؟) تنجح في الوصول إلى منفذ خادم SMTP الخاص بـ Brevo.
root@server-1:/var/discourse#
root@server-1:/var/discourse# ./launcher enter app
x86_64 arch detected.
root@server-1-app:/var/www/discourse#
root@server-1-app:/var/www/discourse# openssl s_client -connect smtp-relay.sendinblue.com:587 -starttls smtp
CONNECTED(00000003)depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1depth=0 CN = *.sendinblue.com
verify return:1
---
Certificate chain
 0 s:CN = *.sendinblue.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGODCCBSCgAwIBAgIQf3BN6DJXk+R4MhMClPwXSzANBgkqhkiG9w0BAQsFADCB
jzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQD
Ey5TZWN0aWdvIFJTQSBEb21haW4gVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENB
MB4XDTIyMTIwMTAwMDAwMFoXDTIzMTIxMzIzNTk1OVowGzEZMBcGA1UEAwwQKi5z
ZW5kaW5ibHVlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKym
RK7t+EAo9Vtl+7laiPy2QTvaxT7WLrLGNGzSzorOBTKkjpjEOveSaa9SMav+qX/T
n4Q/eVQdjggQqFrUAYAN7aXa83K9zYMrSAzsPzg/k3O5iXl3GC5KT3yF9IzNNso0
oljczFaYDdhLr6iovk03DXQB0hMmfX3RLJyqYmyGEshoJwSAMTfW06Iob25JFVG7
tKngYEQMx/IC/WsFKuJ8t2AKaK7xZyEklQqJ95j9lzbfP27VNIkfcZ3DjMDK3shL
xgkpsys8LiH5P1MUAEq4fmOE9IIkewGYMAuKSRyzH1DdgeDvMW8RYcVwGmAfEjQ4
W/515j9q6f1OLQPK1zUCAwEAAaOCAwEwggL9MB8GA1UdIwQYMBaAFI2MXsRUrYrh
d+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBQt3X5DvoJzqs7qZ1t/7m1fRPcJGTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKwYDVR0RBCQwIoIQKi5zZW5kaW5i
bHVlLmNvbTIOc2VuZGluYmx1ZS5jb20wggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkB
ZwB1AK33vvp8/xDIi509nB4+GGq0Zyldz7EMJMqFhjTr3IKKAAABhM6AGCkAAAQD
AEYwRAIgLXDREGRQg02jNvL1Vvuwmbc8G1OpnwgHOsWKB/Gi5hQCIEmjtO9/O9DQ
nBNawCpH/ppW57f49W90ecV0Ng2qHWs9AHcAejKMVNi3LbYg6jjgUh7phBZwMhOF
TTvSK8E6V6NS61IAAAGEzoAX8gAABAMASDBGAiEAzTTpiWsKzHjVN7czz0Iw+TW8
17jAlGb8/LvgNuyb+yoCIQD4W8vpQd7aoLwFL1ZuuEh3zhrDL/iNa1FbnPTXrCSx
hQB1AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1uAAABhM6AF8EAAAQD
AEYwRAIgaLYUtDrQms9/CbKsZIsJ0ootg6Swnori9rmkiQlZklwCICerSmuiXVAg
nthR3zAcjsEd4o1hXgMjEjM3ct4T1WDLdMA0GCSqGSIb3DQEBCwUAA4IBAQC+X/Us
keEDvt4AG0j9CgcP+QrZliJMsKNz7YR8Mt+NJiXr69Kg/hZNvw5aToCgjgbPlzPj
cs4i/6plivGmBsH94qIcl+PbHm1wJFSodDvahKuP0xZbBcynel9cIeCLRfYLr8nI
qJnB7sqK3Fpda98EY4x5kYbbiKJ2CaMABD8WZBEbJglTY3cmZkpI6m76sEgrlVm+
O+jp2fw7cFda+vzUmBmd8z1i7dZbB7Oj4Wy/SjT0SPbousz7JXXBh2YDiIzLBfvt
8mhjeQmLZMCnvL74zxFfuB44v4X0SIfQPjSgZy8vTYYMrSn40pzLbL1np7t+jpEb
ratD0fgmtozDRDWw
-----END CERTIFICATE-----
subject=CN = *.sendinblue.com

issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5482 bytes and written 476 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: FF96A2562FFDC00C5948FE7E6123CE9CD4CFB4939A4546728F60584ED2EC12EB
    Session-ID-ctx:
    Master-Key: 287A2ECAB44E3F1EB919B4AD0EF98981A05F866381485781BB46AFEA2F361E987C31E57DA1098B01F69B75679E07E430
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 6d 30 ab bf 0a 44 79 06-0a 1a 67 1a 25 b5 f8 05   m0...Dy...g.%...
    0010 - 8e 33 6c 9a db 35 cd 9e-64 d6 a3 44 59 36 d4 e1   .3l..5..d..DY6..
    0020 - 69 b2 46 6a d5 7a 22 25-c2 36 bd bc ef ca d8 bf   i.Fj.z"%.6......
    0030 - 1c e2 b5 31 4e ab 43 cf-ea a0 1a b8 39 69 cd 5c   ...1N.C.....9i.\
    0040 - 15 b5 94 17 9c 70 d0 9d-ff 7c 7f e9 3f c8 87 a2   .....p...|..?...
    0050 - d0 12 5d a2 2b 6c e3 54-aa 33 10 fa b5 08 57 9f   ..].+l.T.3....W.
    0060 - 64 ce cc 08 53 24 f1 5c-4f 6b 4c 19 f1 f8 83 be   d...S$.\OkL.....
    0070 - 97 11 17 3f 83 5f 9f 9c-16 73 86 98 c8 d6 72 a8   ...?._...s....r.
    0080 - 44 7a bd 43 e3 40 44 a5-f4 6d 7f 36 19 e4 f3 84   Dz.C.@D..m.6....
    0090 - ec 3f 0b 65 0c 53 ef 73-ef 43 19 8c 34 27 87 40   .?.e.S.s.C..4'.@
    00a0 - 7e 52 5f 6f 7a 2d e6 08-a6 fc 6f 77 a9 47 f3 fa   ~R_oz-....ow.G..
    00b0 - eb 56 ac 1d f0 42 de 45-37 22 ec 5e 13 48 09 41   .V...B.E7".^.H.A

    Start Time: 1700936536
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
250 STARTTLS
^C
root@server-1-app:/var/www/discourse#
root@server-1-app:/var/www/discourse#

آخر سجل هو 250 STARTTLS بدلاً من 250 DSN المحدد في المنشور السابق ويبدو أنه جيد بالنسبة لي كشخص غير خبير.

  1. لكن discourse-doctor لا يمكنه إرسال البريد الإلكتروني ويقول إن المنفذ مغلق (لقد جربت مع 587 و 2525 و 465 بدون starttls).
==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Or just send a test message to yourself.
Email address for mail test? ('n' to skip) [contact@aether-labs.fr]: test-f2ps9wb2f@srv1.mail-tester.com
Sending mail to test-f2ps9wb2f@srv1.mail-tester.com. . .
Testing sending to test-f2ps9wb2f@srv1.mail-tester.com using smtp-relay.sendinblue.com:587, username:forum@aether-labs.fr with plain auth.
======================================== ERROR ========================================
Connection to port 587 failed.
====================================== SOLUTION =======================================
The most likely problem is that your server has outgoing SMTP traffic blocked.
If you are using a service like Mailgun or Sendgrid, try using port 2525.
=======================================================================================

لذلك، كما هو الحال في (4)، يبدو أن حركة مرور SMTP الصادرة ليست محظورة، ولا أعرف كيف أواصل وما هي الإعدادات التي يجب تغييرها للحصول على إعداد صحيح لرسائل البريد الإلكتروني الخاصة بالمعاملات.

قد تحتاج إلى التحقق مع مزود جهازك الافتراضي لمعرفة ما إذا كانت منافذك الصادرة محظورة.

شكرا @pfaffman!
لقد أرسلت لهم بريدًا إلكترونيًا للتو.

ولكن حقيقة أن

openssl s_client -connect smtp-relay.sendinblue.com:587 -starttls smtp

يعمل هو أمر غريب، إذا وضعت smtp-relay.sendinblue.com:586 لا أحصل على النتائج، لذلك أظن أن حركة المرور ليست محظورة، أليس كذلك؟ أعني، تصل الحزم إلى smtp-relay.sendinblue.com:587 إذا كانت هناك استجابات…

لذا أخبرني فريق الدعم أن كل شيء على ما يرام مع الإعداد وأن منافذ الإرسال غير محظورة.

لذا حاولت إرسال بريد إلكتروني عبر openssl بالكامل، ونجحت في إرسال بريد إلكتروني لنفسي من داخل حاوية docker.

root@server-1-app:/var/www/discourse#  openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587

EHLO jai
AUTH PLAIN
AGZvcnVtQGFldGhlci1sYWJ... # تم الاقتطاع للأمان
mail from: noreply@forum.aether-labs.fr
rcpt to: test-j0erqjxm2@srv1.mail-tester.com
data
subject: test smtp from inside


ok
.

… لكن الأمر discourse-doctor لا يزال يخبرني أن الاتصال بـ smtp-relay.sendinblue.com:587 فشل.

لذا قرأت البرنامج النصي discourse-doctor، ورأيت أن الاختبار مرتبط بمهمة rake تسمى emails:test، والتي وجدتها في lib/tasks/emails.rake ورأيت أن هذه الرسالة تحدث عندما “تنتهي المهلة”.

هل هناك خيار لتغيير قيمة المهلة قبل اعتبار انتهاء التنفيذ؟

تعديل: حسنًا، لذا إذا قمت بتحرير app/services/email_settings_validator.rb ووضعت المهلة يدويًا إلى 30، يكون الاتصال جيدًا، لكن إرسال البريد لا يزال يفشل (مرتبط بـ TestMailer، أعتقد أنني قد لا أزيد هذا…)

root@server-1-app:/var/www/discourse# rake emails:test[test-j0erqjxm2@srv1.mail-tester.com]
Testing sending to test-j0erqjxm2@srv1.mail-tester.com using smtp-relay.sendinblue.com:587, username:forum@aether-labs.fr with plain auth.
SMTP server connection successful.
Sending to test-j0erqjxm2@srv1.mail-tester.com. . .
Sending mail failed.
execution expired

نظرًا لأنني عند الحد الأدنى من متطلبات discourse في هذه النسخة (1 VCPU + 2GB RAM)، فقد أحاول أيضًا الترقية إلى شيء أفضل (مثل 2 VCPU + 4GB RAM).

هل لديك في البيئة:\n\n\nDISCOURSE_SMTP_ENABLE_START_TLS: true\n\n\nإنها القيمة الافتراضية، لذا لا يجب أن تحتاج إليها، ولكن ربما قمت بإيقاف تشغيلها؟

إنها مضبوطة على صحيح، نعم!
(لقد قمت بتعديل رسالتي السابقة بتجربتي مع المهلات الزمنية…)

ما هي المدة التي يستغرقها الأمر openssl للاتصال والتفاوض على TLS؟

حوالي 10 ثوانٍ

real	0m9.798s
user	0m0.007s
sys	0m0.010s

واو، هذا وقت طويل بشكل سخيف.

هل يستغرق الأمر نفس القدر من الوقت من النظام المضيف؟

لقد أجريت الاختبار للتو
~10 ثوانٍ من دوكر
< ثانية واحدة من المضيف (بالتأكيد الوقت الذي استغرقته للضغط على Ctrl+D للإيقاف، إنه سريع جدًا تقريبًا)

هذا معقول.

يبدو أن لديك شيئًا معطلاً بشكل أساسي في شبكات الحاويات … يجب أن يستغرق هذان الأمران نفس القدر من الوقت:

(من المضيف):point_down:t3:

○ → time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 </dev/null > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.277s
user	0m0.007s
sys	0m0.011s

(عبر docker):point_down:t3:

○ → docker run --rm discourse/base:2.0.20231023-1945 bash -c 'time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 </dev/null' > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.239s
user	0m0.006s
sys	0m0.000s
إعجاب واحد (1)

ليس الأمر كذلك :sob:

root@server-1:/var/discourse# time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 < /dev/null > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.126s
user	0m0.003s
sys	0m0.007s
root@server-1:/var/discourse# docker run --rm discourse/base:2.0.20231023-1945 bash -c 'time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 < /dev/null' > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m8.125s
user	0m0.007s
sys	0m0.000s

… هل يجب علي إلغاء تثبيت / إعادة تثبيت دوكر؟
لقد قمت فقط ببعض أوامر apt وتركتها افتراضية من docker-ce، لذلك لا أعرف ما الذي يمكن أن يكون خاطئًا …
التعديل الوحيد الذي قمت به هو إضافة نظام أسماء النطاقات كما هو مقترح في موضوع آخر لأنني واجهت أولاً أخطاء “المضيف غير معروف”

root@server-1:/var/discourse# cat /etc/docker/daemon.json
{
  "dns": ["83.166.143.51", "83.166.143.52", "8.8.8.8"]
}

حسنًا، لقد نجح الأمر!

لقد قمت بتغيير /etc/docker/daemon.json الخاص بي بحيث يكون Google (8.8.8.8) هو الأول وليس الأخير، وحصلت على وقت استجابة لائق لـ STARTTLS… وتمكن discourse-doctor من إرسال رسائل البريد الإلكتروني بنجاح :slight_smile:

شكرًا جزيلاً لوقتكما @supermathie و @pfaffman

سأضيف ملاحظة في المنشور الآخر لإخبارهم بأن Google يجب أن يكون الأول في القائمة!

ليست كل الاقتراحات قابلة للتطبيق على جميع الحالات. هذا أيضًا نوع من الخطر في تبني نصيحة شخص آخر لمجرد أنها نجحت معهم.

في حالتك، يبدو أن خوادم أسماء جوجل أكثر موثوقية من تلك التي يوفرها مزود خدمة الإنترنت الخاص بك، لذلك يجب عليك استخدامها.

إعجابَين (2)

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