He mirado el código y me parece que:
authserv_id está habilitadoEmail::AuthenticationResults asignará un veredicto de fallo o aprobación, lo que resulta en una acción de encolar o aceptarlib/new_post_manager.rb - self.post_needs_approval?)¿Es correcta mi razonamiento?
¿Significa esto que los intentos de suplantación probablemente terminarían en revisión?
Más o menos, esto se enviará a la cola de aprobación si DMARC falla, pero si está totalmente ausente, aún se procesará.
Quizás una forma de avanzar sería agregar una configuración explícita del sitio que básicamente diga “el operador del sitio acepta el riesgo” y si está habilitada, permitir el mapeo basado en el correo electrónico.
Estoy un poco confundido por el debate sobre el error frente al comportamiento previsto. Tal como lo he interpretado, por razones de seguridad, no se permite la creación de nuevos temas por correo electrónico si la dirección de correo electrónico coincide con un usuario existente no preparado; esto se debe a que las direcciones de correo electrónico pueden ser falsificadas y, por lo tanto, los usuarios pueden ser suplantados.
Las respuestas son presumiblemente aceptables porque la dirección incluye la clave de respuesta, lo que demuestra que el remitente fue el destinatario del correo electrónico de notificación y, por lo tanto, es probable que sea el usuario real.
Si esa interpretación del comportamiento previsto es correcta, es contradictoria con lo que estoy experimentando actualmente. Si mi usuario tiene permiso para crear en la categoría y envío un correo electrónico desde mi dirección de correo electrónico registrada a la dirección email_in de la categoría, la dirección de correo electrónico se empareja con mi usuario y se crea un nuevo tema por mi usuario.
Esto sucede independientemente de si aceptar correos electrónicos de usuarios anónimos sin cuentas está habilitado, ya que mi usuario tiene permiso para crear.
La situación actual parece ser: (con el correo electrónico en usuarios anónimos habilitado)
(Nota: No probé el punto 4 ahora) Con el correo electrónico en usuarios anónimos habilitado, esperaría que los puntos 3 y 4 se comportaran de la misma manera. Ya sea que ambos sean rechazados para proteger contra la suplantación de identidad o ambos sean aceptados bajo el argumento de que un usuario real no debería tener menos permisos que un usuario anónimo, no deberían tener resultados diferentes.
El OP trata sobre categorías seguras (por ejemplo, una categoría que los anónimos ni siquiera pueden ver). En ese caso, los usuarios en escena serían ciertamente rechazados hoy, ¿no?
Sí, el correo de usuarios en staging/no activados no habría sido (¿debería?) aceptado en mi escenario original.
Acabo de probar esto para confirmar el comportamiento en nuestra instancia (20 commits de retraso, no puedo ver nada relacionado en los cambios). Tenemos que todas las publicaciones de usuarios con nivel de confianza 0 requieren aprobación y no estaba seguro de si eso afectaría la ruta, así que extendí los pasos para probar sin que eso interfiriera.
Estos pasos se relacionan con una categoría donde el grupo de administradores tiene permisos de ver/responder/crear y no se establecen otros permisos, se establece una dirección de correo electrónico y está habilitada la opción accept emails from anonymous users with no accounts (aceptar correos electrónicos de usuarios anónimos sin cuenta).
“>” denota un efecto en lugar de una acción.
Si eso no sucediera, la configuración accept emails from anonymous users with no accounts no tendría ningún propósito en categorías que no tengan everyone (todos) o trust_level_0 (nivel de confianza 0) con permiso de creación.
Creo que esto es equivalente al #4 del OP, donde el OP describe que tanto el #3 como el #4 deberían resultar en un nuevo tema, sin embargo, solo el #4 lo hace.
Con mi publicación anterior (antes de “La situación actual”), mi objetivo principal era discutir este punto de manera más general, lo que parece argumentar que el #3 no debería funcionar porque la forma en que funciona actualmente protege contra la suplantación de identidad de los usuarios.
Sin embargo, como describo en esa publicación, esa protección no existe donde un usuario coincidente tiene permiso de creación.
Sigue siendo un problema en 3.6.0.beta3-latest.