Hm. Tengo la misma configuración de Vultr que @MathiasFoster y @jryans aquí, y me encontré con el mismo problema (Net::OpenTimeout). ufw allow https hizo que mi correo entrante funcionara.
Pero ahora el sitio no envía ningún correo. Antes de configurar el correo entrante, el correo saliente había estado funcionando bien.
No tengo nada complicado:
notification_email es admin@tasat.org.
El correo saliente usa smtp.titan.email en Hostinger.
En skipped email, estoy viendo \u003creplies+verp-14c9cc6eb915b08d4983c90c744ba4b4@forum.tasat.org\u003e: Sender address rejected: not owned by user admin@tasat.org
Soy nuevo en la elaboración de correos electrónicos. ¿Debería quitar forum. de las cadenas de mail_receiver.yml y hacer que “replies@tasat.org” sea un alias de envío de “admin@tasat.org”…?
El receptor de correo es independiente de Discourse y del envío de correos electrónicos, solo actúa como un servidor de correo electrónico simple configurado únicamente para recibir correos electrónicos, utilizando la API de Discourse para insertar esos correos electrónicos en Discourse.
Lo único que se me ocurre que podría afectar el envío al configurarlo es establecer la dirección de correo electrónico de respuesta, aunque eso solo debería establecer Reply-To en los correos electrónicos salientes y no afectar la dirección del remitente.
Solo para confirmar, parece que tienes estos (entre otros) en app.yml:
Y esto en dirección de correo electrónico de respuesta:
replies+%{reply_key}@forum.tasat.org
¿Es correcto?
Si es así, ¿los correos electrónicos de notificación que no aceptan respuestas siguen funcionando? Creo que la verificación de correo electrónico es un ejemplo de eso, por lo que podrías intentar crear una cuenta y ver si ese correo electrónico se envía correctamente.
Con esa configuración, lo que debería suceder para los correos electrónicos que pueden aceptar respuestas es que el correo electrónico enviado utiliza: De: admin@tasat.org (también dirección del remitente) Reply-To: replies+abc123@forum.tasat.org
Normalmente, Reply-To no se trata como parte de la información del remitente, solo proporciona una dirección predeterminada a la que dirigirse cuando las personas responden, pero quizás Hostinger sí lo trate como tal. Es posible que puedas agregar un alias de envío para replies@forum.tasat.org.
Creo que Vultr (o tal vez solo instalar Docker cuando ufw está presente) tiene algunas reglas que impiden que los contenedores se comuniquen entre sí, lo que significa que el receptor de correo no puede conectarse a Discourse. ufw allow https evita eso.
En la red predeterminada, solo si un contenedor se conecta directamente a otro contenedor por dirección IP local, esa es la dirección IP local del propio contenedor.
Cuando el receptor de correo busca el nombre de dominio de tu Discourse, no obtendrá esa IP local, por lo que tendrá que salir de su red Docker y pasará por ufw al menos una vez para llegar a Discourse.
Esa es una situación separada, aunque relacionada. Son conexiones que entran desde el exterior y Docker agrega reglas para permitir el paso de puertos expuestos.
No estoy muy familiarizado con las reglas de cadenas de netfilter/iptables, pero creo que lo anterior muestra:
Si la conexión proviene de docker0, es decir, de la red docker predeterminada, regresa a la cadena anterior (detiene el procesamiento de reglas en esa cadena).
De lo contrario, si la conexión proviene de cualquier cosa que no sea docker0, si también es https o http, especifica DNAT haciendo que pase a la cadena FORWARD.
Por lo tanto, con la disposición que se muestra en el otro tema, lo que sucede es que si el tráfico https o http proviene del exterior, se dirige a docker. Sin embargo, si el tráfico proviene de la red docker, se devolverá y será rechazado o descartado por la cadena INPUT.
Lo que hace ufw allow https es agregar una regla a la cadena INPUT que la acepta. De esa manera, cuando la conexión se devuelve a la cadena INPUT como se mencionó anteriormente, será aceptada y encontrará docker escuchando, siendo finalmente enrutada al contenedor.
¡Gracias por las respuestas! He tenido que ausentarme un poco, pero estoy volviendo a esto…
Sí, eso es lo que tengo por el momento.
Cuando intento crear una cuenta ahora, el botón de enviar no hace nada. Como si supiera que no va a funcionar. (Y no aparece nada en “Omitidos” ni en ningún otro lugar).
Editar: He configurado “replies@tasat.org” como un alias de envío para admin@tasat.org, y he confirmado que funciona para enviar y recibir. También he confirmado la entrega de un correo electrónico enviado desde un cliente externo dirigido a replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org
En aras de intentar algo, cambié reply by email address:
de replies+%{reply_key}@forum.tasat.org
a replies+%{reply_key}@tasat.org
Pero no cambia los resultados.
No llega a mail-tester. Todos los intentos de envío terminan en “omitidos” con una variedad de este mensaje:
553 5.7.1 <replies+verp-8c79cd4e83023bda6df0624c2cacd36e@tasat.org>:
La dirección del remitente ha sido rechazada: no pertenece al usuario admin@tasat.org
¿Quizás esto sea interesante? Cuando ejecuto discourse-doctor, el correo saliente falla de la siguiente manera:
==================== PRUEBA DE CORREO ====================
Para una prueba robusta, obtén una dirección de http://www.mail-tester.com/
Enviando correo a REDACTED . .
Probando el envío a admin@tasat.org usando smtp.titan.email:587,
nombre de usuario:admin@tasat.org con autenticación simple.
Conexión al servidor SMTP exitosa.
Enviando a admin@tasat.org. . .
El correo no se envió.
Razón: 553 5.7.1 <replies+verp-3cc19f7b135e6f56219e030999db9e29@tasat.org>:
La dirección del remitente ha sido rechazada: no pertenece al usuario admin@tasat.org
Enviar directamente a la dirección replies+ (o a una dirección forum.tasat.org) desde un cliente de correo funciona; sigue el alias “replies” y termina en la bandeja de entrada de administración. ¿De dónde viene el rechazo?
Eché un vistazo a la sección del artículo “Evitar que el correo electrónico del host saliente interfiera”. No tengo la ruta /etc/postfix, pero aquí está mi salida de netstat:
EDITAR IMPORTANTE – Recibí respuesta de soporte de Titan esta noche: “La dirección de respuesta y la dirección del remitente deben ser las mismas o el correo electrónico no se enviará.” Así que supongo que toda la solución de problemas queda en el olvido y tengo que buscar un nuevo host de correo electrónico que no imponga ese requisito.
El siguiente tema (enlazado en la parte inferior de ese documento) también tiene información sobre el manejo de rebotes para esos y otros:
Yo mismo uso el plan flexible de Mailgun (completamente dentro de la asignación gratuita), pero sé que ha habido confusión en torno a sus precios y potencialmente las cosas han cambiado para los nuevos usuarios desde que me uní. Lo último que vi (no tengo idea si todavía es cierto), era posible pasar a flexible después de que terminara la prueba, simplemente era increíblemente confuso.
Correcto.
Puedes cambiar a mailgun flex, aunque hacen que sea difícil de averiguar. Aproximadamente una vez al mes les envío un correo electrónico preguntando por qué es tan difícil de encontrar.
@Simon_Manning y @pfaffman – gracias de nuevo por sus aportaciones y consejos, me pusieron en el camino correcto.
Decidí probar MailerSend, ya que su plan gratuito actual es bastante generoso. Debería ser suficiente para nuestro esfuerzo sin fines de lucro durante algún tiempo. Las cosas están en marcha y funcionando bien hasta ahora
