El dominio está verificado en SES, no necesitas el parámetro de autenticación SMTP.
Además, es posible que debas sacar tu cuenta de SES del modo sandbox si aún no lo has hecho y solicitar un aumento de límite. La condición de sandbox se aplica por región.
Todavía no entiendo por qué no se envían correos electrónicos a través de AWS SES.
Cuando envío un correo de prueba desde la página de administración de nuestro Discourse, simplemente dice “enviado”. También intento una solicitud de contraseña olvidada, que sigue el proceso correctamente, pero nunca llega ningún correo electrónico.
No creo que SES registre los envíos, así que no puedo verificar si siquiera está recibiendo los correos.
Lo único que podría causar un problema es que nuestra dirección de respuesta use una cuenta de gmail.com en lugar de nuestro dominio del sitio.
¿Alguien ha encontrado esta combinación o escenario antes?
Esa es la dirección de correo electrónico que aparecerá en la línea de remitente. Debe ser una dirección del dominio desde el cual SES enviará los correos. SES no enviará correos que fingan provenir de Gmail. No tienes control sobre gmail.com, por lo que SES no enviará correos con esa dirección en la línea de remitente. notification_email debe ser algo@tudominioverificado
Yo también uso SES y funciona bien para mí. La única diferencia que puedo observar en comparación es que la línea DISCOURSE_SMTP_AUTHENTICATION: login no existe en mi configuración. Además, tanto DISCOURSE_SMTP_ENABLE_START_TLS: true como DISCOURSE_SMTP_PORT: 587 están comentados, aunque eso no debería marcar ninguna diferencia.
Las únicas tres líneas que modifico en el archivo app.yml son la dirección SMTP, el nombre de usuario y la contraseña. El resto está comentado tal cual viene de una instalación nueva, utilizando los valores por defecto. Después de reconstruir, solo necesito asegurarme de que la configuración del sitio notification email esté establecida en una dirección que utilice un dominio verificado en SES. Ya no uso comillas en la contraseña, pero en mis instalaciones anteriores sí lo hacía y funcionaba bien de cualquier manera.
Sí, valdría la pena probar cambiando la dirección de respuesta para usar una dirección que emplee el dominio verificado de SES, como se recomienda en la respuesta anterior, solo para ver si eso hace que se envíe correctamente.
Si no funciona, verificaría si tu host está bloqueando algunos puertos y quizás volvería a comprobar que las credenciales de SES se generaron correctamente. Veo que has confirmado arriba que tu dominio está verificado en SES.
La dirección de respuesta está en el mismo dominio que la dirección de origen, sí, pero en algunos casos no es el mismo subdominio (aunque sigue siendo el mismo dominio raíz). Ambos casos funcionan bien para mí.
Estoy seguro de que lo notaste: ¿has verificado la dirección de correo saliente que usa Discourse para enviar? Si es notify@tudominioverificado, debes ir a SES, en la segunda fila bajo ‘Gestión de identidades’, agregar y luego verificar el correo de envío. Nada se enviará hasta que hagas esto. Sin alarmas, sin sirenas, simplemente no se envía.
Que la respuesta sea de Gmail está genial. Eso es lo que hice. Luego, los correos de autorización para los miembros estaban siendo bloqueados como spam porque el campo ‘De’ y ‘Responder a’ no coincidían.
Finalmente, escribí una función Lambda simple de AWS (me tomó una semana aprender cómo) que reenvía los correos entrantes a la API de Discourse. Muy limpio. Sin POSTFIX.
