Aiuto necessario, sono bloccato nel debug della configurazione email (Infomaniak/Brevo)

Ciao!

Sto installando Discourse per la nostra piccola associazione no-profit. Ho scelto di avere un’istanza cloud Ubuntu 22.04 in un Public Cloud da Infomaniak e di avere le nostre email transazionali in Brevo perché hanno 300 email/mese nel loro piano gratuito.

Ho incontrato diversi problemi, uno per uno, per configurare il server, e la documentazione e i post qui mi hanno aiutato molto…

MA
Ora ho raggiunto un punto in cui non so come andare avanti.

  1. La mia istanza è accessibile sul sottodominio del nostro forum.aether-labs.fr

  2. Il mio account Brevo funziona correttamente, poiché riesco a inviare email da noreply@forum.aether-labs.fr da Thunderbird

  3. Ma non ricevo la mia prima email di amministratore per convalidare l’account.

Quindi ho letto in dettaglio il post Troubleshoot email on a new Discourse install (nessun link perché regola per nuovi utenti) e ho provato delle cose.

  1. Il container dell’app (sembra?) riuscire a raggiungere la porta del server SMTP di 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
bHVlLmNvbYIOc2VuZGluYmx1ZS5jb20wggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkB
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#

L’ultimo log è 250 STARTTLS invece di 250 DSN specificato nel post precedente e sembra a posto per un non esperto come me.

  1. Ma discourse-doctor non riesce a inviare email e dice che la porta è chiusa (ho provato con 587, 2525 e 465 senza 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.
=======================================================================================

Quindi, poiché da (4) sembra che il traffico SMTP in uscita non sia bloccato, non so come procedere e quale configurazione cambiare per avere una configurazione corretta delle email transazionali.

Potresti verificare con il provider della tua VM se le tue porte in uscita sono bloccate.

Grazie @pfaffman!
Ho appena inviato loro un’email.

Ma il fatto che

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

funzioni è strano, se metto smtp-relay.sendinblue.com:586 non ottengo risultati, quindi supporrei che il traffico non sia bloccato, giusto? Voglio dire, i pacchetti raggiungono smtp-relay.sendinblue.com:587 se ci sono risposte…

Quindi il supporto mi ha detto che andava tutto bene con la configurazione e che le porte in uscita non erano bloccate.

Quindi ho provato a inviare un’e-mail tramite openssl completamente, e sì, sono riuscito a inviarmi un’e-mail dall’interno del container docker.

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

EHLO jai
AUTH PLAIN
AGZvcnVtQGFldGhlci1sYWJ... # tagliato per sicurezza
mail from: noreply@forum.aether-labs.fr
rcpt to: test-j0erqjxm2@srv1.mail-tester.com
data
subject: test smtp from inside


ok
.

… ma il comando discourse-doctor mi dice ancora che la connessione a smtp-relay.sendinblue.com:587 è fallita.

Quindi ho letto lo script discourse-doctor e ho visto che il test è collegato a un job rake chiamato emails:test, che ho trovato in lib/tasks/emails.rake e ho visto che questo messaggio si verifica quando l’“esecuzione è scaduta”.

C’è un’opzione per modificare il valore di timeout prima di considerare scaduta l’esecuzione?

Modifica: ok, quindi se modifico app/services/email_settings_validator.rb e imposto manualmente il timeout a 30, la connessione è ok, ma l’invio dell’e-mail fallisce ancora (collegato a TestMailer, immagino che non dovrei aumentare questo…)

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

Dato che sono davvero al minimo dei requisiti di discourse in questa istanza (1 VCPU + 2GB RAM), potrei anche provare ad aggiornare a qualcosa di meglio (come 2 VCPU + 4GB RAM).

Hai nell’env:

DISCOURSE_SMTP_ENABLE_START_TLS: true

È il valore predefinito, quindi non dovresti averne bisogno, ma forse l’hai disattivato?

È impostato su true, sì!
(Ho modificato il mio messaggio precedente con il mio esperimento con i timeout…)

Quanto tempo impiega il comando openssl per connettersi e negoziare TLS?

quasi 10 secondi

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

Wow, è un tempo assurdamente lungo.

Ci vuole lo stesso tempo dal sistema host?

Ho appena fatto il test
~10 secondi da docker
<1 secondo dall’host (certamente il tempo per me di premere ctrl+D per fermare, è davvero quasi istantaneo)

Questo è ragionevole.

Sembra che tu abbia qualcosa di fondamentalmente rotto con il networking dei container… questi due comandi dovrebbero richiedere lo stesso tempo:

(dall’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

(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 Mi Piace

non è :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

… dovrei disinstallare / reinstallare docker?
Ho solo eseguito alcuni comandi apt e l’ho lasciato di default da docker-ce, quindi non so cosa possa essere sbagliato…

L’unico mod che ho fatto è stato aggiungere il dns come suggerito in un altro post perché prima avevo errori di “host sconosciuto”

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

OK, funziona!

Ho modificato il mio /etc/docker/daemon.json in modo che Google (8.8.8.8) sia il primo e non l’ultimo, e ho ottenuto un tempo di risposta decente per STARTTLS… e discourse-doctor ha inviato correttamente le email :slight_smile:

Grazie mille per il tuo tempo @supermathie e @pfaffman

Aggiungerò una nota sull’altro post per dire che Google dovrebbe essere il primo nell’elenco!

Non tutti i suggerimenti sono applicabili a tutti i casi. Questo è anche un po’ il pericolo di adottare i consigli di qualcun altro solo perché ha funzionato per loro.

Nel tuo caso, sembra che i nameserver di Google siano più affidabili di quelli forniti dal tuo ISP, quindi dovresti usarli.

2 Mi Piace

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