Analisei o código e parece-me que:
authserv_id estiver ativadoEmail::AuthenticationResults atribuirá um veredito de falha ou aprovação, o que resulta em uma ação de enfileirar ou aceitarlib/new_post_manager.rb - self.post_needs_approval?)O meu raciocínio está correto?
Isso significa que as tentativas de spoofing provavelmente acabariam em revisão?
Mais ou menos, isso será enviado para a fila de aprovação se o DMARC falhar, mas se estiver totalmente ausente, ainda assim será processado.
Talvez uma maneira de avançar seria adicionar uma configuração explícita do site que basicamente diga “o operador do site aceita o risco” e, se habilitado, permitir o mapeamento com base no e-mail.
Estou um pouco confuso com o debate sobre bug versus comportamento intencional. A maneira como interpretei é que, por razões de segurança, a criação de novos tópicos por e-mail não é permitida se o endereço de e-mail corresponder a um usuário existente não preparado; isso ocorre porque os endereços de e-mail podem ser falsificados e, portanto, os usuários podem ser impersonados.
As respostas são presumivelmente aceitáveis porque o endereço inclui a chave de resposta, demonstrando que o remetente foi o destinatário do e-mail de notificação e, portanto, é provável que seja o usuário real.
Se essa interpretação do comportamento intencional estiver correta, ela é contraditória com o que estou realmente experimentando. Se o meu usuário tem permissão para criar na categoria e eu envio um e-mail do meu endereço de e-mail registrado para o endereço email_in da categoria, o endereço de e-mail é correspondido ao meu usuário e um novo tópico é criado pelo meu usuário.
Isso acontece independentemente de aceitar e-mails de usuários anônimos sem contas estar habilitado, já que meu usuário tem permissão para criar.
A situação atual parece ser: (com e-mail em usuários anônimos habilitado)
(Nota: Eu não testei o 4 agora) Com e-mail em usuários anônimos habilitado, eu esperaria que 3 e 4 se comportassem da mesma maneira. Quer ambos sejam rejeitados para proteger contra impersonação ou ambos aceitos com base no fato de que um usuário real não deveria ter menos permissões do que um usuário anônimo, eles não deveriam ter resultados diferentes.
O OP é todo sobre categorias seguras (por exemplo, uma categoria que anônimos nem sequer podem ver). Nesse caso, os usuários em estágio seriam certamente rejeitados hoje, não?
Sim, e-mails de usuários em staging/não ativados não teriam sido (deveriam?) aceitos no meu cenário original.
Acabei de testar isso para confirmar o comportamento em nossa instância (20 commits atrás, não consigo ver nada relacionado nas alterações). Temos todas as postagens de usuários com nível de confiança 0 exigindo aprovação e eu não tinha certeza se isso afetaria a rota, então estendi os passos para testar sem que isso interferisse.
Esses passos se relacionam a uma categoria onde o grupo de administradores tem permissão de ver/responder/criar e nenhuma outra permissão é definida, um endereço de e-mail é definido e aceitar e-mails de usuários anônimos sem conta está habilitado.
“>” denota um efeito em vez de uma ação.
Se isso não acontecesse, a configuração aceitar e-mails de usuários anônimos sem conta não teria propósito em categorias que não têm todos ou nível_de_confiança_0 com permissão de criação.
Acredito que isso seja equivalente ao #4 no OP, onde o OP descreve que tanto o #3 quanto o #4 deveriam resultar em um novo tópico, no entanto, apenas o #4 o faz.
Com minha postagem anterior (antes de “A situação atual”), eu estava principalmente visando discutir este ponto de forma mais geral, o que parece argumentar que o #3 não deveria funcionar porque a maneira como funciona atualmente protege contra usuários serem personificados.
No entanto, como descrevo nessa postagem, essa proteção não existe onde um usuário correspondente tem permissão de criação.
Ainda é um problema no 3.6.0.beta3-latest.