我查看了代码，我的理解如下：
- 如果启用了
authserv_id Email::AuthenticationResults会分配fail或pass的裁决，从而导致enqueue或accept操作- 带有
enqueue操作的帖子将被标记为待审核/批准（lib/new_post_manager.rb - self.post_needs_approval?）
我的推理正确吗？
这是否意味着欺骗尝试很可能会被标记为待审核？
差不多，如果 DMARC 失败，它将被发送到批准队列，但如果完全缺失，它仍将通过。
也许一种推进方式是添加一个明确的站点设置，基本上说“站点运营商接受风险”，如果启用，则允许基于电子邮件进行映射。
1 个赞
我对错误与预期行为的争论感到有些困惑。我的理解是，出于安全原因，如果电子邮件地址与现有的非暂存用户匹配，则不允许通过电子邮件创建新主题；这是因为电子邮件地址可以被伪造，因此用户可能被冒充。
回复被认为是可接受的，因为地址包含回复密钥，这表明发件人是通知电子邮件的收件人，因此很可能是真实用户。
如果对预期行为的这种解释是正确的，那么它与我实际遇到的情况相矛盾。如果我的用户有权在类别中创建，并且我从我的注册电子邮件地址向该类别的 email_in 地址发送电子邮件，则电子邮件地址将与我的用户匹配，并由我的用户创建新主题。
无论是否启用了“允许没有帐户的匿名用户发送电子邮件”，都会发生这种情况，因为我的用户确实拥有创建权限。
在启用了“匿名用户”中的电子邮件的情况下，当前情况似乎是：
- 从没有用户的地址接收电子邮件；创建暂存用户，创建新主题**。
- “ ” “ 地址与暂存用户匹配；匹配暂存用户，创建新主题**。
- “ ” “ 地址与具有创建权限的真实用户匹配；匹配真实用户，创建新主题**。
- “ ” “ 地址与没有创建权限的真实用户匹配；匹配真实用户，拒绝新主题**。
（注意：我刚才没有测试 4）在启用了“匿名用户”中的电子邮件的情况下，我期望 3 和 4 的行为始终相同。无论是都拒绝以防止冒充，还是都接受，因为真实用户不应比匿名用户拥有更少的权限，它们不应有不同的结果。
OP 全部是关于安全类别（例如匿名用户甚至看不到的类别）。在这种情况下，分阶段用户今天肯定会被拒绝，对吗？
是的，在我的原始场景中，来自已暂存/未激活用户的邮件本不应（应该？）被接受。
1 个赞
我刚刚在我们的实例上测试了这一点以确认行为（落后 20 个提交，看不到更改中的任何相关内容）。我们要求所有信任级别为 0 的用户发帖都需要审核，我不确定这是否会影响路由，所以我扩展了步骤以在没有此干扰的情况下进行测试。
这些步骤都与一个分类有关，该分类的管理员组具有查看/回复/创建权限，并且没有设置其他权限，设置了电子邮件地址，并且启用了“接受来自没有账户的匿名用户的电子邮件”。
“>”表示效果而不是操作。
- 从没有用户的地址发送电子邮件
-
暂存用户被创建，新帖子进入审核队列
- 批准帖子
-
私有分类中创建新主题
- 将暂存用户的信任级别更改为 1
- 从同一地址发送另一封电子邮件
-
私有分类中创建新主题
如果那没有发生，“接受来自没有账户的匿名用户的电子邮件”设置将对不具有“所有人”或“trust_level_0”创建权限的分类没有意义。
我相信这相当于 OP 中的 #4，其中 OP 描述 #3 和 #4 都应该会创建一个新主题，但只有 #4 才会。
在我之前的帖子（“当前情况”之前）中，我主要想更广泛地讨论这一点，这似乎表明 #3 不应该起作用，因为它的工作方式可以防止用户被冒充。
然而，正如我在该帖子中所描述的，当匹配的用户具有创建权限时，这种保护就不存在了。
在 3.6.0.beta3-latest 上仍然存在此问题。