Besoin d'aide, je suis bloqué dans la configuration des e-mails (Infomaniak/Brevo)

Bonjour !

J’installe Discourse pour notre petite association à but non lucratif. J’ai choisi d’avoir une instance cloud Ubuntu 22.04 dans un Cloud Public d’Infomaniak et d’avoir nos e-mails transactionnels chez Brevo car ils ont 300 e-mails/mois dans leur plan gratuit.

J’ai rencontré plusieurs problèmes, un par un, pour configurer le serveur, et la documentation ainsi que les posts ici m’ont beaucoup aidé…

MAIS
Maintenant, j’ai atteint un point où je ne sais pas comment avancer.

  1. Mon instance est accessible sur le sous-domaine forum.aether-labs.fr

  2. Mon compte chez Brevo fonctionne correctement, car j’ai réussi à envoyer des e-mails depuis noreply@forum.aether-labs.fr depuis Thunderbird

  3. Mais je ne reçois pas mon premier e-mail administrateur pour valider le compte.

J’ai donc lu en détail le post Troubleshoot email on a new Discourse install (pas de lien car règle des nouveaux utilisateurs) et j’ai essayé des choses.

  1. Le conteneur de l’application (semble ?) réussir à atteindre le port du serveur SMTP de 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: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
thR3zAcjsEd4o1hXgMjEjM3ct4T1WDLdMA0GCSqGSIb3DQEBCwUAA4IBAQC+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#

Le dernier log est 250 STARTTLS au lieu de 250 DSN spécifié dans l’ancien post et cela semble correct pour le non-expert que je suis.

  1. Mais le discourse-doctor ne parvient pas à envoyer d’e-mail et indique que le port est fermé (j’ai essayé avec 587, 2525 et 465 sans 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.
=======================================================================================

Donc, comme (4) le montre, il semble que le trafic SMTP sortant ne soit pas bloqué, je ne sais pas comment continuer et quelle configuration changer pour avoir une configuration correcte des e-mails transactionnels.

Vous pourriez vérifier auprès du fournisseur de votre machine virtuelle si vos ports sortants sont bloqués.

Merci @pfaffman !
Je viens de leur envoyer un e-mail.

Mais le fait que

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

fonctionne est étrange, si je mets smtp-relay.sendinblue.com:586 je n’ai pas les résultats, donc je devrais deviner que le trafic n’est pas bloqué, n’est-ce pas ? Je veux dire, les paquets atteignent bien smtp-relay.sendinblue.com:587 s’il y a des réponses…

Donc, le support m’a dit que tout allait bien avec la configuration et que les ports sortants n’étaient pas bloqués.

J’ai donc essayé d’envoyer l’e-mail via openssl complètement, et oui, j’ai réussi à m’envoyer un e-mail depuis l’intérieur du conteneur Docker.

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

EHLO jai
AUTH PLAIN
AGZvcnVtQGFldGhlci1sYWJ... # coupé pour la sécurité
mail from: noreply@forum.aether-labs.fr
rcpt to: test-j0erqjxm2@srv1.mail-tester.com
data
subject: test smtp from inside


ok
.

… mais la commande discourse-doctor me dit toujours que la connexion à smtp-relay.sendinblue.com:587 a échoué.

J’ai donc lu le script discourse-doctor, et j’ai vu que le test est lié à un job rake appelé emails:test, que j’ai trouvé dans lib/tasks/emails.rake et j’ai vu que ce message se produit lorsque « l’exécution a expiré ».

Y a-t-il une option pour changer la valeur du délai d’attente avant de considérer l’exécution comme expirée ?

Edit : ok, donc si je modifie app/services/email_settings_validator.rb et que je mets manuellement le délai d’attente à 30, la connexion est ok, mais l’envoi d’e-mail échoue toujours (lié à TestMailer, je suppose que je ne peux pas augmenter celui-là…)

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

Étant donné que je suis vraiment au minimum requis par Discourse dans cette instance (1 VCPU + 2 Go de RAM), j’essaierai peut-être aussi de passer à quelque chose de mieux (comme 2 VCPU + 4 Go de RAM).

Avez-vous dans l’environnement :

DISCOURSE_SMTP_ENABLE_START_TLS: true

C’est la valeur par défaut, vous n’en devriez donc pas avoir besoin, mais peut-être l’avez-vous désactivée ?

C’est réglé sur vrai, oui !
(J’ai modifié mon message précédent avec mon expérience sur les timeouts…)

Combien de temps faut-il à la commande openssl pour se connecter et négocier TLS ?

presque 10 sec

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

Wow, c’est une période absurdement longue.

Cela prend-il autant de temps depuis le système hôte ?

Je viens de faire le test
~10 sec depuis docker
\u003c 1 sec depuis l’hôte (certainement le temps que j’appuie sur ctrl+D pour arrêter, c’est vraiment presque instantané)

C’est raisonnable.

Il semble que vous ayez un problème fondamental avec le réseau des conteneurs… ces deux commandes devraient prendre le même temps :

(depuis l’hôte) :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

(via 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 « J'aime »

Ce n’est pas :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

… dois-je désinstaller / réinstaller docker ?
J’ai seulement fait quelques commandes apt et l’ai laissé par défaut depuis docker-ce, donc je ne sais pas ce qui pourrait mal tourner…

Le seul mod que j’ai fait a été d’ajouter le dns comme suggéré dans un autre post car j’avais d’abord des erreurs “hôte inconnu”

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

OK, ça marche !

J’ai modifié mon /etc/docker/daemon.json pour que Google (8.8.8.8) soit le premier et non le dernier, et j’ai obtenu un temps de réponse décent pour STARTTLS… et discourse-doctor a réussi à envoyer des e-mails :slight_smile:

Merci beaucoup pour votre temps @supermathie et @pfaffman

J’ajouterai une note sur l’autre publication pour dire que Google devrait être le premier de la liste !

Toutes les suggestions ne sont pas applicables à tous les cas. C’est aussi un peu le danger d’adopter les conseils de quelqu’un d’autre simplement parce qu’ils ont fonctionné pour lui.

Dans votre cas, il semble que les serveurs de noms Google soient plus fiables que ceux fournis par votre FAI, vous devriez donc les utiliser.

2 « J'aime »

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