Restricciones en "Custom incoming email address" (solo para sitios alojados, ¿quizás?)

Hola Comunidad de Discourse —

Lo siguiente es algo que he observado a través de prueba y error, pero para lo cual no he visto documentación ni he encontrado una advertencia o error.

En nuestro sitio, que está alojado por Discourse (¡por lo cual estamos muy agradecidos!), configurar una dirección de correo electrónico entrante personalizada para una categoría solo parece funcionar si la dirección de correo electrónico está prefijada por “foo+” (donde ‘foo’ es el slug general de nuestro sitio).

Específicamente, a menudo configuro una nueva categoría, establezco lo que considero una dirección de correo electrónico intuitiva para ella, envío un correo de prueba a esa dirección, y nunca recibo un rebote ni lo veo aparecer en los registros de correos electrónicos recibidos o rechazados de nuestro sitio. Luego, finalmente recuerdo mis experiencias anteriores, configuro la dirección como foo+\u003csome name\u003e, ejecuto otra prueba y funciona inmediatamente.

Si no me lo estoy imaginando, esto parece comprensible como un medio para que Discourse distinga los correos destinados a un sitio alojado de otro, pero quería verificar si estoy en lo correcto. O, si no lo estoy, ver si hay otras explicaciones de por qué mis elecciones iniciales de dirección de correo electrónico parecen ir a /dev/null.

¡Gracias!
-Brad

1 me gusta

Puede parecer simple/reductivo decirlo en voz alta, pero la dirección de correo electrónico personalizada solo funciona si se entrega realmente al sitio.

Por lo tanto, no puedes poner cualquier cosa allí, la dirección debe entregarse al sitio para tener alguna posibilidad de funcionar.

No hay forma de que Discourse pueda verificar esa dirección para asegurarse de que suceda, por lo que la responsabilidad recae en el administrador para asegurarse de que suceda.

En nuestro hosting, recomiendo aprovechar algunas direcciones que hemos predispuesto para que se entreguen en tu sitio:

  • {CUALQUIER COSA}@{TU PREFIJO}.discoursemail.com
  • {CUALQUIER COSA}@{tu.nombre.de.sitio.hostname}
2 Me gusta

Gracias @supermathie

Para nuestro sitio (alojado), no me di cuenta de que …@{OUR PREFIX}.discoursemail.com era una opción y solo había intentado usar …@discoursemail.com como nombre de host porque es lo que usa la dirección predeterminada de “aceptar correos electrónicos entrantes” (y he actualizado mi consulta original arriba para intentar aclarar esto, ya que omití el nombre de host en la pregunta original). Lo probaré, ¡gracias por el consejo!

Aunque entiendo que Discourse no puede verificar las direcciones de correo electrónico para las instancias de Discourse autoalojadas, ¿sería posible que las instancias alojadas generaran una advertencia o error si la dirección de correo electrónico no tuviera un formato esperado? (¿o un formato esperado al usar una dirección …discoursemail.com?

Gracias de nuevo,
-Brad

1 me gusta

No hay ningún límite para el “formato esperado” más allá de “dirección de correo electrónico válida”, por lo que esto no es factible.

Esto podría ser algo que podríamos hacer.

3 Me gusta

¡Gracias de nuevo por la respuesta!

Creo que has confirmado mi sospecha de que este es un problema específico de los sitios de Discourse alojados como el nuestro. No sé qué nivel de esfuerzo se requeriría para que dichos sitios verifiquen que las direcciones …discoursemail.com introducidas en este campo son válidas, pero una característica así me habría ahorrado una buena cantidad de tiempo y frustración durante los últimos años al configurar nuevas listas de correo y alias, preguntándome por qué no funcionaban. Me imagino que también ayudaría a otros.

Alternativamente, incluso una pequeña sugerencia (tool tip) en ese campo para un sitio alojado que indique que una dirección legal debe ser slug+...@discoursemail.com o ...@slug.discoursemail.com sería de gran ayuda. Aunque no sé si hacer esa sugerencia específica para los sitios de Discourse alojados hace que ese enfoque sea inviable.

-Brad

Esto no es cierto — la restricción es que el correo electrónico debe ser entregado (no dirigido) a una de estas direcciones para que funcione. Un ejemplo es la siguiente configuración que nosotros y muchos de nuestros clientes usamos:

  • (en Discourse) configurar la categoría Postings para aceptar correo electrónico entrante enviado a postings@contoso.com
  • (en el servidor de correo de contoso.com) configurar postings@contoso.com para reenviar a {CUALQUIER COSA}@contoso.discoursemail.com
  • resultado final: el correo dirigido a postings@contoso.com se envía a la categoría Postings

Esto funciona de manera efectiva igual que:

  • (en Discourse) configurar la categoría Postings para aceptar correo electrónico entrante enviado a postings@contoso.discoursemail.com
  • resultado final: el correo dirigido a postings@contoso.discoursemail.com se envía a la categoría Postings
1 me gusta

@supermathie — Buen punto sobre que la dirección de entrega sea más relevante que la dirección a la que se dirige el correo.

Refinando mi solicitud anterior, creo que una advertencia al intentar introducir direcciones de correo entrante que coincidan con los patrones @discoursemail.com o @*.discoursemail.com, pero que no empiecen con slug+… o terminen con @slug.discoursemail.com, seguiría siendo valiosa para advertir sobre las comunidades alojadas por Discourse.

Esto aún permitiría tu primer caso (ya que no tiene discoursemail.com como sufijo) y al mismo tiempo me advertiría sobre intentar configurar una dirección slug-users@discouresmail.com, que es el tipo de patrón al que siempre recurría y luego me confundía cuando los correos a ella se descartaban silenciosamente.

(Tenga en cuenta que tu segundo caso tampoco generaría una advertencia, asumiendo que contoso es el slug de tu comunidad).

— Brad

Este tema se cerró automáticamente después de 2 días. Ya no se permiten nuevas respuestas.