Estoy intentando usar mi propio servidor de solo envío para enviar correos electrónicos. Estoy ejecutando esta pasarela SMTP para usar TLS, por lo que el cliente que utilizo para enviar correos electrónicos requiere un certificado. Estoy utilizando un certificado autofirmado, que es muy fácil de configurar si uso postfix/ssmtp para enviar correos electrónicos, pero no estoy seguro de cómo puedo usar un certificado personalizado en el cliente de correo de Discourse.
Me gustaría corregir mi pregunta. Así que realmente no necesito agregar ningún certificado para que esto funcione, pero aún así falla al comunicarse por TLS. Si lo pruebo con swaks, funciona correctamente. Ejemplo de comando:
@itsbhanusharma AWS SES ofrece 60.000 correos electrónicos al mes de forma gratuita y, por lo que sé, estas llamadas de correo deben solicitarse desde una instancia EC2 para que funcionen; de lo contrario, se cobran como normales. Mi instancia de Discourse está alojada en un droplet de Digital Ocean. Podría estar equivocado, pero esta es mi comprensión y la razón detrás de ello.
Así que, incluso si tu API de SES recibe correos electrónicos desde una dirección IP de DigitalOcean, esto podría generar cargos. Podrías optar por usar otro servicio o configurar Exim en una instancia EC2 para actuar como puente entre tu droplet de DO y AWS SES. No creo que funcione, pero puedes probar.
En teoría, debería funcionar así:
Discourse (en DO) envía correos electrónicos a la dirección IP de Exim en EC2.
EC2 reenvía los correos electrónicos recibidos desde DO a SES.
SES entrega los correos electrónicos al usuario final.
Ya he resuelto el problema de retransmisión ejecutando un servidor SMTP local en EC2, que finalmente reenvía la solicitud SMTP a SES. El problema es que Discourse falla en el intercambio de claves TLS con este servidor SMTP, mientras que aplicaciones como Postfix, Swaks y similares funcionan perfectamente.
¿Hay alguna manera de ver dónde se gestiona este saludo SMTP? ¿Como alguna biblioteca que Discourse esté utilizando en Ruby en segundo plano? No quiero desactivar TLS aquí.
Usar un certificado válido de Let’s Encrypt no ayudó por alguna razón. No sé por qué.
Pero después de configurar esto en app.yaml, los correos electrónicos ahora funcionan.
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Alguien con más conocimiento sobre SMTP podría explicar por qué esto funciona, pero por ahora creo que estoy bien.
Tengo una instancia de EC2 de $5 ejecutándose en AWS que estoy utilizando para retransmitir múltiples dominios. Mover Discourse a EC2 sería un poco más costoso que en Digital Ocean, aunque la diferencia no es mucha (unos pocos dólares en total).
Pero el punto es que, incluso si traslado Discourse a EC2, aún necesitaría ese servicio de retransmisión para soportar el resto de las droplets que tengo en DO para otros dominios que poseo. Así que, ¿por qué no simplemente arreglar Discourse ?
Eso es cierto, pero Discourse no tiene nada que ver con el SES en este caso. Discourse se comunica con un servidor SMTP, que podría ser cualquier cosa (actualmente es un servicio de retransmisión). Me preguntaba cómo es que Postfix, Swaks y demás funcionan perfectamente con este servidor SMTP (desde la misma VPC de DigitalOcean) y Discourse no. Tras establecer esa variable, ya funciona, aunque aún me gustaría saber qué biblioteca utiliza Discourse para el saludo SMTP para poder verificar personalmente si hay algo que podamos mejorar en Discourse.
?