Ayuda necesaria, estoy bloqueado depurando la configuración de correo electrónico (Infomaniak/Brevo)

Hola!

Estoy instalando discourse para nuestra pequeña asociación sin fines de lucro. He elegido obtener una instancia en la nube de Ubuntu 22.04 en un servicio de nube pública de Infomaniak y tener nuestros correos electrónicos transaccionales en Brevo porque tienen 300 correos/mes en su plan gratuito.

He pasado por varios problemas, uno por uno, para configurar el servidor, y la documentación y las publicaciones aquí me ayudaron mucho…

PERO
Ahora he llegado a un punto en el que no sé cómo avanzar.

  1. Mi instancia es accesible en el subdominio de nuestro foro.aether-labs.fr

  2. Mi cuenta en Brevo funciona correctamente, ya que logro enviar correos electrónicos desde noreply@forum.aether-labs.fr desde Thunderbird

  3. Pero no recibo mi primer correo electrónico de administrador para validar la cuenta.

Así que leí en detalle la publicación Troubleshoot email on a new Discourse install (sin enlace debido a la regla de usuario nuevo) y probé cosas.

  1. El contenedor de la aplicación (parece que) logra alcanzar el puerto del servidor 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
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
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# 

El último registro es 250 STARTTLS en lugar de 250 DSN especificado en la publicación anterior y parece estar bien para un no experto como yo.

  1. Pero el discourse-doctor no puede enviar correos electrónicos y dice que el puerto está cerrado (he probado con 587, 2525 y 465 sin starttls)
==================== PRUEBA DE CORREO ====================
Para una prueba robusta, obtén una dirección de http://www.mail-tester.com/
O simplemente envíate un mensaje de prueba.
¿Dirección de correo para la prueba de correo? ('n' para omitir) [contact@aether-labs.fr]: test-f2ps9wb2f@srv1.mail-tester.com
Enviando correo a test-f2ps9wb2f@srv1.mail-tester.com. . . 
Probando el envío a test-f2ps9wb2f@srv1.mail-tester.com usando smtp-relay.sendinblue.com:587, nombre de usuario:forum@aether-labs.fr con autenticación simple.
======================================== ERROR ========================================
La conexión al puerto 587 falló.
====================================== SOLUCIÓN =======================================
El problema más probable es que tu servidor tenga bloqueado el tráfico SMTP saliente.
Si estás utilizando un servicio como Mailgun o Sendgrid, intenta usar el puerto 2525.
=======================================================================================

Así que, dado que (4) parece que el tráfico SMTP saliente no está bloqueado, no sé cómo continuar y qué configuración cambiar para tener una configuración correcta de los correos electrónicos transaccionales.

Es posible que desees consultar con el proveedor de tu VM para ver si tus puertos de salida están bloqueados.

¡Gracias @pfaffman!
Les acabo de enviar un correo electrónico.

Pero el hecho de que

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

funcione es extraño, si pongo smtp-relay.sendinblue.com:586 no obtengo resultados, así que supongo que el tráfico no está bloqueado, ¿verdad? Quiero decir, los paquetes llegan a smtp-relay.sendinblue.com:587 si hay respuestas…

Así que el soporte me dijo que todo estaba bien con la configuración y que los puertos de salida no estaban bloqueados.

Así que intenté enviar el correo a través de openssl por completo, y sí, logré enviarme un correo desde dentro del contenedor de docker.

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

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

ok
.

… pero el comando discourse-doctor todavía me dice que la conexión a smtp-relay.sendinblue.com:587 falló.

Así que leí el script discourse-doctor, y vi que la prueba está vinculada a un trabajo de rake llamado emails:test, que encontré en lib/tasks/emails.rake y vi que este mensaje ocurre cuando la “ejecución expiró”.

¿Hay alguna opción para cambiar el valor del tiempo de espera antes de considerar que la ejecución expiró?

Editar: ok, así que si edito app/services/email_settings_validator.rb y pongo manualmente el tiempo de espera a 30, la conexión está bien, pero el envío de correo todavía falla (vinculado a TestMailer, supongo que no debería aumentar ese…)

root@server-1-app:/var/www/discourse# rake emails:test[test-j0erqjxm2@srv1.mail-tester.com]
Probando el envío a test-j0erqjxm2@srv1.mail-tester.com usando smtp-relay.sendinblue.com:587, nombre de usuario:forum@aether-labs.fr con autenticación plain.
Conexión exitosa al servidor SMTP.
Enviando a test-j0erqjxm2@srv1.mail-tester.com. . . 
Fallo al enviar el correo.
ejecución expiró

Dado que estoy realmente en los requisitos mínimos de discourse en esta instancia (1 VCPU + 2GB RAM), también podría intentar actualizar a algo mejor (como 2 VCPU + 4GB RAM).

¿Tienes en el entorno:

DISCOURSE_SMTP_ENABLE_START_TLS: true

Es el valor predeterminado, así que no deberías necesitarlo, pero ¿quizás lo desactivaste?

¡Está configurado en verdadero, sí!
(He editado mi mensaje anterior con mi experimento con tiempos de espera…)

¿Cuánto tiempo tarda el comando openssl en conectarse y negociar TLS?

casi 10 segundos

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

Vaya, es un tiempo absurdamente largo.

¿Tarda lo mismo desde el sistema anfitrión?

Acabo de hacer la prueba
~10 segundos desde docker
\u003c1 segundo desde el host (seguramente el tiempo que tardo en presionar ctrl+D para detener, es realmente casi instantáneo)

Esto es razonable.

Parece que tienes algo fundamentalmente roto con la red de contenedores… estos dos comandos deberían tomar la misma cantidad de tiempo:

(desde el 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

(a través de 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 me gusta

no es :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

… ¿debería desinstalar / reinstalar docker?
Solo hice algunos comandos apt y lo dejé por defecto desde docker-ce, así que no sé qué puede estar mal…

El único mod que hice fue agregar el dns como se sugiere en otro post porque primero tuve errores de “host desconocido”

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

¡OK, funciona!

Cambié mi /etc/docker/daemon.json para que google (8.8.8.8) esté primero y no último, y obtuve un tiempo de respuesta decente para STARTTLS… y discourse-doctor envió correos electrónicos correctamente :slight_smile:

Muchas gracias por tu tiempo @supermathie y @pfaffman

¡Añadiré una nota en la otra publicación para decir que google debería ser el primero en la lista!

No todas las sugerencias son aplicables a todos los casos. Ese es también el peligro de adoptar el consejo de otra persona solo porque funcionó para ellos.

En tu caso, parece que los servidores de nombres de Google son más confiables que los proporcionados por tu ISP, por lo que deberías usarlos.

2 Me gusta

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