Esto es para una instalación inicial, ¡y de ninguna manera soy un experto en DNS! Así es como tengo las cosas ahora:
Las pruebas de correo saliente funcionan correctamente. Estoy usando MailGun con su subdominio “mg” recomendado. Estoy enviando en el puerto 2525. Tengo la API de MailGun para webhooks ingresada en el campo correspondiente, en Configuración (ellos tienen TRES APIs: ¿es esta la correcta??). También tengo registros MX para el subdominio mg ingresados en mis configuraciones DNS. La validación de MailGun indica que todo funciona correctamente, al igual que mail-tester.com.
La recepción está configurada con un subdominio llamado “inbound”. Si envío un correo desde una cuenta de Gmail a fake@inbound.[midominio].org, puedo ver que ese correo llega al registro del receptor de correo. Si envío, desde Discourse, un correo de prueba a esa misma dirección mediante Configuración > Correo, el correo parece desaparecer: no aparece nada en la papelera de rechazados. Estoy utilizando recepción directa y sencilla de correo entrante para el resto.
Debido a otros errores que cometí yo mismo durante el proceso de configuración, decidí empezar desde cero: eliminé mi droplet, reinstalé Discourse y estoy comenzando de nuevo. Sin embargo, no eliminé la cuenta de MailGun y en realidad estoy usando el mismo webhook de API que antes. ¿Podría ser ese el problema? Sí, estoy usando una nueva clave de API generada por Discourse (la anterior, obviamente, se destruyó cuando eliminé el droplet).
Lo único más que se me ocurre es el punto final en mail-receiver.yml. El mío se ve así: DISCOURSE_MAIL_ENDPOINT: 'https://inbound.[midominio].org/admin/email/handle_mail'
¿Alguna idea sobre dónde está el problema? (Para colmo, hace poco todo funcionaba perfectamente, antes de eliminar el droplet. Al parecer, soy un aprendiz lento ). ¡Gracias a todos!
Esto debería ser el dominio de tu foro, no el de tu correo. ¿Podrías confirmar que tu foro no está en inbound.[midominio].org? Por ejemplo, si meta usara este método, la URL se vería así:
Además… esto no tiene nada que ver con Mailgun, excepto asegurarte de ignorar las instrucciones de Mailgun para agregar registros MX para el dominio. Según:
Nota: los proveedores de correo saliente como Mailgun pueden pedirte que agregues registros MX que apunten a sus servidores. Debes eliminarlos para que los registros MX de tu foro solo apunten al nombre de dominio de tu foro. Los registros SPF y DKIM deben seguir apuntando a los servidores de tu proveedor de correo saliente para que puedas enviar correos.
@tobiaseigen ¡Casi! Realicé el cambio eliminando el subdominio de correo entrante del punto final. Guardé y luego reinicié el receptor de correo (¡porque no sé lo que hago!). Probé. Sin éxito. Luego hice una reconstrucción completa de la aplicación. Después creé dos cuentas nuevas usando direcciones de correo electrónico diferentes. Usé la cuenta de administrador para enviar un mensaje privado (PM) a una de ellas. Eso generó un correo electrónico como se esperaba. Luego respondí al PM a través del correo electrónico. Aquí está el resultado en el registro de correo:
¡De hecho estamos acercándonos! No estoy seguro de qué se trata este error temporal. Han pasado 13 minutos y aún no se entrega en Discourse. Extraño.
Debo mencionar que creé el subdominio “inbound” porque quiero que una dirección de correo electrónico admin@[mydomain].org sea gestionada por un servidor de correo diferente.
Tengo un poco de dificultad para entender tu uso de los nombres de dominio. En mi sitio, el DISCOURSE_MAIL_ENDPOINT y el registro MX para el correo entrante son el mismo dominio, apuntando al servidor de Discourse, como se explica en el OP de Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. Parece que estás intentando usar dominios diferentes.
Generalmente, quieres usar un subdominio como foro.midominio.org para tu Discourse, para separar tu foro de tu sitio web principal y del correo en midominio.org.
Me complace aclararlo y, para simplificar, fingiré que mi dominio es thesite.org. Lo que veo es un problema de SSL en los registros del receptor de correo: <19>Nov 25 19:11:29 receive-mail[160]: Failed to POST the e-mail to https://inbound.thesite.org/admin/email/handle_mail: hostname "inbound.thesite.org" does not match the server certificate (OpenSSL::SSL::SSLError)
Sin embargo, para responder a tu pregunta, tenía dos objetivos, que presumo son extremadamente comunes:
admin@thesite.org se convierte en una dirección para que los usuarios contacten al administrador.
thesite.org lanza el foro (sin subdominio).
Actualmente, mis configuraciones de DNS de Namecheap se ven así (TTL = Auto y Prioridad = 10):
Mis configuraciones en containers/mail-receiver.yml son: MAIL_DOMAIN: inbound.thesite.org DISCOURSE_MAIL_ENDPOINT: 'https://thesite.org/admin/email/handle_mail' DISCOURSE_API_KEY: (contenido) DISCOURSE_API_USERNAME: system ← igual que la clave API
* nota—> Dejé las líneas de LetsEncrypt tal cual (no eliminé el “#”)
Otras configuraciones:
Cambié el nombre de host mediante la línea de comandos a inbound.thesite.org
Correo de contacto = admin@thesite.org
Correo de notificación = noreply@mg.thesite.org
Correo de respuesta por email1 = replies+%{reply_key}@inbound.thesite.org
Correo de respuesta por email2 = %{reply_key}@inbound.thesite.org
Buscar publicación relacionada con clave = ACTIVADO
Sondeo manual = ACTIVADO
Clave API de Mailgun = INGRESADA …pero esto podría ser un problema porque proviene de un intento de instalación anterior
¿Alguna idea sobre cómo proceder a partir de aquí? …¡y un enorme GRACIAS de antemano! También menciono a @pfaffman, ya que ha sido amablemente un recurso que me ha ayudado con luchas pasadas relacionadas con la configuración. Tu guía “Straightforward” también fue extremadamente útil. ¡Saludos!
¿Reconstruiste ambos contenedores, el de correo y el de la aplicación? Creo que la solución sencilla es eliminar lo que intenta asignar un certificado al receptor de correo. ¿Funciona el certificado para el sitio?
Si el sitio de Discourse no está en inbound.thesite.org, ese es el problema. La idea es que el nombre de host del sitio de Discourse y del receptor de correo sea el mismo. Necesitarás consultar Configurar Let’s Encrypt con múltiples dominios para solucionarlo.
Esto va más allá del alcance previsto del manual del receptor de correo. Si esto no es suficiente para ponerte en marcha y tienes presupuesto, no dudes en contactarme.
Así que la pregunta es: ¿se pueden lograr ambos objetivos que definí anteriormente (parecen absurdamente comunes)? ¿Es la única solución redirigir, en la configuración de DNS, a los visitantes que escriben www.thesite.org y/o thesite.org hacia subdomain.thesite.org? Si esto es cierto, entonces tendré que conformarme con cambiar la dirección de correo electrónico visible al público por algo poco atractivo como admin@subdomain.thesite.org.
Puedo aceptar cambiar la dirección de correo electrónico del administrador si es absolutamente necesario. Parece que estamos pasando por alto algo obvio, pero quizás estoy en lo incorrecto (¡probablemente lo esté!).
Si lo que quieres es que el receptor de correo reciba mensajes en un dominio diferente al de tu Discourse, creo que es posible. Lo más sencillo es no usar el certificado de Let’s Encrypt en el receptor de correo.
@pfaffman ¡eres un genio! ¡Funcionó!! Siguiendo la guía Configuración de Let’s Encrypt con múltiples dominios, reconstruir Discourse y luego reconstruir mail-receiver (probablemente uno de los dos no era necesario) fue la clave. ¡Voilà!
Más tarde esta noche, me gustaría copiar y pegar la publicación original “Entrega directa sencilla de correo entrante” en un documento de Google y ofrecer mis sugerencias de edición. Sin culpa de nadie de ustedes, hay partes de la publicación original que no son intuitivas para alguien como yo, que no conoce ni entiende las cosas de la línea de comandos. Creo que los dos objetivos que definí anteriormente son muy comunes para muchas instalaciones, y ahora sé que se puede lograr el objetivo final.
Tengo otras sugerencias para todo el tutorial de configuración. Tengo una lista en curso de ediciones sugeridas para hacer el proceso lo más simple posible.
¡Muchas gracias por ayudarme en esto! ¡Se aprecia muchísimo!