El Discourse::InvalidAccess volvió a ocurrir. Esta vez, la longitud del Asunto no es la causa. Sospecho que tiene que ver con que la categoría es una subcategoría restringida. Pero la categoría está configurada para recibir correos electrónicos de direcciones sin cuenta, por lo que esperaría que el correo electrónico se procesara y creara un nuevo tema.
El caso de uso es un CFP (Call for Papers): las personas deberían poder enviar mensajes, pero solo los organizadores deberían poder leer los mensajes y discutirlos. Creo que esto es diferente del caso descrito en Email in to a private category
Recompilé después de un git pull (noop), y ahora parece que funciona con el segundo dominio agregado a relay_domains de Postfix. Antes de esta serie de pruebas, y con el cambio, ya no tenía errores, pero los correos electrónicos no aparecían en absoluto, ni en la categoría ni en los registros de errores.
(Por supuesto, example.net no es lo que realmente está en el archivo de configuración. Lo que hay es el nombre de host del foro y el nombre del dominio principal, ambos configurados en el DNS)
Noté que @mpalmer mencionó hace años que agregar un segundo dominio se podía hacer pero
Así que esperaba que la pequeña configuración de relay_domains no fuera suficiente, pero parece funcionar, dado que haces git pull antes de recompilar. Debe haber alguna peculiaridad en la forma en que se compila el contenedor mail-receiver que falla al actualizar pups…
De alguna manera, el fallo ha vuelto. Esto es un poco ridículo, porque las pruebas anteriores estuvieron bien. Ahora, después de otra reconstrucción, el correo entrante es rechazado de nuevo. Recurrí a repetir el baile de git pull y luego rebuild, pero esta vez no pareció funcionar.
Sospecho que la situación de la subcategoría puede estar influyendo, a menos que algo haya cambiado en la forma en que se maneja el correo entrante con respecto a los permisos de categoría.
La situación ahora es que la gente envía correos electrónicos y recibe correos electrónicos de rechazo, por lo que tengo que copiar y pegar los correos electrónicos rechazados y asignar los temas al remitente original. La ‘experiencia del usuario’ es, por lo tanto, terrible, y la sobrecarga es bastante odiosa.
Realmente no puedo aceptar que el correo entrante sea una categoría pública, este es el propósito de hacer un CFP. Pero Discourse ahora parece incapaz de cumplir este propósito.
Los correos electrónicos de personas sin cuenta son rechazados (pero la categoría está configurada en recibir correos electrónicos de direcciones sin cuenta).
Los correos electrónicos de personas en los grupos autorizados parecen pasar sin problemas.
Los correos electrónicos de personas con cuenta pero sin acceso a la categoría son rechazados.
Me parece que los permisos se comprueban a pesar de la configuración de aceptación predeterminada.
Actualmente estoy revisando el código del contenedor de recepción de correo para ver si encuentro algo allí.
Para aquellos que tienen una cuenta pero no tienen acceso a la categoría, se espera que sean rechazados. La opción Aceptar correos electrónicos de usuarios anónimos sin cuenta solo se aplica a usuarios provisionales, y aquellos con una cuenta existente tienen aplicados los permisos de categoría.
Es extraño que se esté rechazando a personas sin cuenta. ¿Podría deberse a los cambios que hiciste en el receptor de correo?
Al parecer, el rechazo lo maneja el endpoint en /admin/email/smtp_should_reject.json.
Hice el cambio porque los correos electrónicos estaban rebotando. Primero agregué varios correos electrónicos a la dirección de correo entrante (separándolos con |) y eso pareció funcionar.
OK, esto tiene sentido. Pero es un poco confuso. Si “cualquiera” puede enviar correos electrónicos, pero los usuarios existentes no, eso anula el propósito.
Voy a verificar en los correos rechazados si son provisionales o no. Muchas gracias por ayudarme a depurar @JammyDodger.
Creo que tienes razón @JammyDodger, los usuarios nuevos pasan, los usuarios existentes con acceso normal a la categoría pasan, pero las cuentas existentes sin acceso no pueden enviar correos electrónicos a la categoría.
Supongo que una solución alternativa sería crear un grupo CFP sin ninguna notificación para la categoría que comprenda a todos los usuarios existentes. Pero suena muy improvisado y podría tener efectos secundarios de cancelación de notificaciones existentes… No estoy seguro de qué hacer.
Dada una categoría privada con entrada de correo electrónico autorizada para direcciones de correo electrónico desconocidas (es decir, que no pertenecen a ninguna cuenta existente, también conocido como usuario en espera)
\u003e si llega un correo electrónico de una dirección desconocida: se entrega a la categoría privada
\u003e si llega un correo electrónico de una dirección conocida: se entrega si y solo si el usuario es miembro de un grupo autorizado para acceder a la categoría.
Por lo tanto, si desea utilizar la entrada de correo electrónico para una CFP, configure la entrada de correo electrónico de un grupo privado y utilice esa dirección. Los mensajes se pueden “hacer públicos” y convertirlos en un tema en una categoría (privada o no).
