Hilfe benötigt, ich stecke bei der Konfiguration der E-Mail-Zustellung fest (Infomaniak/Brevo)

Hallo!

Ich installiere Discourse für unseren kleinen gemeinnützigen Verein. Ich habe mich entschieden, eine Ubuntu 22.04 Cloud-Instanz in einem Public Cloud von Infomaniak zu verwenden und unsere Transaktions-E-Mails über Brevo zu versenden, da diese in ihrem kostenlosen Plan 300 E-Mails/Monat anbieten.

Ich bin auf mehrere Probleme gestoßen, eines nach dem anderen, um den Server einzurichten, und die Dokumentation und die Beiträge hier haben mir sehr geholfen…

ABER
Jetzt bin ich an einem Punkt angelangt, an dem ich nicht weiter weiß.

  1. Meine Instanz ist über die Subdomain forum.aether-labs.fr erreichbar.

  2. Mein Brevo-Konto funktioniert korrekt, da ich erfolgreich E-Mails von noreply@forum.aether-labs.fr über Thunderbird senden kann.

  3. Aber ich erhalte meine erste Admin-E-Mail zur Validierung des Kontos nicht.

Ich habe also den Beitrag Troubleshoot email on a new Discourse install (kein Link wegen Regel für neue Benutzer) im Detail gelesen und Dinge ausprobiert.

  1. Der App-Container (scheint?) erfolgreich den Brevo SMTP-Server-Port zu erreichen.
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: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
---
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
HR8BAf8EBAMCBaAwDAYDVR0TAQH/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#

Das letzte Log ist 250 STARTTLS anstelle von 250 DSN, wie im früheren Beitrag angegeben, und es scheint für mich als Nicht-Experten in Ordnung zu sein.

  1. Aber der discourse-doctor kann keine E-Mail senden und meldet, dass der Port geschlossen ist (ich habe es mit 587, 2525 und 465 ohne starttls versucht).
==================== MAIL TEST ====================
Für einen robusten Test, holen Sie sich eine Adresse von http://www.mail-tester.com/
Oder senden Sie einfach eine Testnachricht an sich selbst.
E-Mail-Adresse für Mailtest? ('n' zum Überspringen) [contact@aether-labs.fr]: test-f2ps9wb2f@srv1.mail-tester.com
Sende Mail an test-f2ps9wb2f@srv1.mail-tester.com. . .
Teste Senden an test-f2ps9wb2f@srv1.mail-tester.com unter Verwendung von smtp-relay.sendinblue.com:587, Benutzername:forum@aether-labs.fr mit Plain Auth.
======================================== ERROR ========================================
Verbindung zu Port 587 fehlgeschlagen.
====================================== SOLUTION =======================================
Das wahrscheinlichste Problem ist, dass Ihr Server ausgehenden SMTP-Verkehr blockiert.
Wenn Sie einen Dienst wie Mailgun oder Sendgrid verwenden, versuchen Sie es mit Port 2525.
=======================================================================================

Daher, da (4) zeigt, dass der ausgehende SMTP-Verkehr nicht blockiert ist, weiß ich nicht, wie ich weitermachen soll und welche Konfiguration ich ändern muss, um eine korrekte Konfiguration der Transaktions-E-Mails zu erhalten.

Sie könnten sich beim Anbieter Ihrer VM erkundigen, ob Ihre ausgehenden Ports blockiert sind.

Danke @pfaffman!
Ich habe ihnen gerade eine E-Mail geschickt.

Aber die Tatsache, dass

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

funktioniert, ist seltsam. Wenn ich smtp-relay.sendinblue.com:586 eingebe, erhalte ich keine Ergebnisse. Ich würde also vermuten, dass der Datenverkehr nicht blockiert wird, oder? Ich meine, die Pakete erreichen smtp-relay.sendinblue.com:587, wenn es Antworten gibt…

Der Support teilte mir mit, dass alles in Ordnung sei und die ausgehenden Ports nicht blockiert seien.

Ich habe dann versucht, E-Mails über OpenSSL vollständig zu versenden, und ja, es gelang mir, mir eine E-Mail von innerhalb des Docker-Containers zu senden.

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

EHLO jai
AUTH PLAIN
AGZvcnVtQGFldGhlci1sYWJ... # aus Sicherheitsgründen gekürzt
mail from: noreply@forum.aether-labs.fr
rcpt to: test-j0erqjxm2@srv1.mail-tester.com
data
subject: test smtp from inside

ok
.

… aber der Befehl discourse-doctor meldet immer noch, dass die Verbindung zu smtp-relay.sendinblue.com:587 fehlgeschlagen ist.

Ich habe mir dann das Skript discourse-doctor angesehen und festgestellt, dass der Test mit einem Rake-Job namens emails:test verknüpft ist, den ich in lib/tasks/emails.rake gefunden habe. Dort sah ich, dass diese Meldung erscheint, wenn die “Ausführung abgelaufen” ist.

Gibt es eine Option, den Timeout-Wert zu ändern, bevor die Ausführung als abgelaufen betrachtet wird?

Bearbeiten: ok, wenn ich app/services/email_settings_validator.rb bearbeite und den Timeout manuell auf 30 setze, ist die Verbindung in Ordnung, aber das Senden der E-Mail schlägt immer noch fehl (ich vermute, das hängt mit TestMailer zusammen, den ich wohl nicht erhöhen kann…)

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

Da ich mit dieser Instanz wirklich am Minimum der Anforderungen von Discourse bin (1 VCPU + 2 GB RAM), werde ich vielleicht auch versuchen, auf etwas Besseres aufzurüsten (wie 2 VCPU + 4 GB RAM).

Haben Sie in der Umgebung:

DISCOURSE_SMTP_ENABLE_START_TLS: true

Dies ist der Standardwert, Sie sollten ihn also nicht benötigen, aber vielleicht haben Sie ihn deaktiviert?

Es ist auf true gesetzt, ja!
(Ich habe meine vorherige Nachricht mit meinen Experimenten mit Timeouts bearbeitet…)

Wie lange dauert die Verbindung und TLS-Aushandlung mit dem openssl-Befehl?

fast 10 Sekunden

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

Wow, das ist eine absurd lange Zeit.

Dauert es vom Hostsystem aus genauso lange?

Ich habe gerade den Test gemacht
~10 Sek. von Docker
\u003c 1 Sek. vom Host (sicherlich die Zeit für mich, Strg+D zu drücken, um zu stoppen, es ist wirklich fast augenblicklich)

Das ist vernünftig.

Es scheint, als hätten Sie ein grundlegendes Problem mit dem Container-Netzwerk… diese beiden Befehle sollten die gleiche Zeit benötigen:

(vom Host):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

(über 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 „Gefällt mir“

Das ist nicht :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

… soll ich Docker deinstallieren / neu installieren?
Ich habe nur ein paar apt-Befehle ausgeführt und es bei der Standardeinstellung von docker-ce belassen, daher weiß ich nicht, was falsch sein könnte…

Die einzige Änderung, die ich vorgenommen habe, war das Hinzufügen der DNS, wie in einem anderen Beitrag vorgeschlagen, da ich zuerst “unknown host”-Fehler hatte

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

OK, es funktioniert!

Ich habe meine /etc/docker/daemon.json geändert, sodass Google (8.8.8.8) an erster Stelle und nicht an letzter steht, und ich habe eine angemessene Antwortzeit für STARTTLS erhalten… und discourse-doctor konnte erfolgreich E-Mails senden :slight_smile:

Vielen Dank für deine Zeit, @supermathie und @pfaffman.

Ich werde in dem anderen Beitrag eine Notiz hinzufügen, um zu sagen, dass Google an erster Stelle in der Liste stehen sollte!

Nicht alle Vorschläge sind in allen Fällen anwendbar. Das ist auch die Gefahr, wenn man den Rat eines anderen übernimmt, nur weil er für ihn funktioniert hat.

In Ihrem Fall scheinen die Google-Nameserver zuverlässiger zu sein als die Ihres Internetanbieters, daher sollten Sie diese verwenden.

2 „Gefällt mir“

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