Ethsim2
(Ethan )
1
我注意到 Discourse 正在拒绝传入的电子邮件，并显示：
无法处理邮件：访问被拒绝
传入邮件本身似乎工作正常。消息到达了邮件接收器，且 SPF、DKIM 和 DMARC 均通过验证。随后，Discourse 通过 Jobs::ProcessEmail 对其进行处理。
该行为似乎取决于 MIME/正文内容：
- 简单/纯文本邮件 → 已接受
- 包含 Outlook 签名、表格和/或内联图片的邮件 → 被拒绝，并显示
访问被拒绝
被拒绝邮件的日志显示故障发生在 Email::Processor#process! 中。
Discourse 应用版本：
4143157a17dc3ff63c909c64d0cf578243d38861
此安装最近已迁移/恢复到另一台服务器，但传入的 SMTP 投递功能正常，且该行为似乎与更丰富的邮件正文特定相关。
如有需要，我可以提供经过脱敏处理的原始 MIME 消息以及更多 IncomingEmail/Email::Receiver 诊断信息。
Ethsim2
(Ethan )
2
更新：我现在已经复现了导致我看到 Access Denied 错误的原因，并提了一个 PR：
我最初观察到的重要部分是：
- 简单/纯文本的传入邮件 → 被接受
- 包含嵌入媒体的富文本邮件 → 被拒绝并显示
Access Denied
被拒绝的消息作为“待审核/陌生人”用户在一个允许陌生人传入邮件的类别中进行处理。
自从 #42079 之后，NewPostManager 会在缺少图片大小元数据时直接从帖子内容中检测嵌入媒体。这正确地导致这些消息进入 :contains_media 审核路径。
然而，在将帖子入队进行审核之前，NewPostManager.default_handler 会执行正常的类别主题创建 Guardian 检查。
对于待审核的传入邮件用户，即使 Email::Receiver 已经接受了该类别的陌生人邮件路径并传入了 skip_validations，该检查仍可能失败。
这产生了我看到的错误：
Email::Receiver::InvalidPost: Access Denied
我为来自陌生人的包含媒体的邮件添加了一个端到端的接收器回归测试。
在当前的 main 分支上，在修复之前，测试复现了：
Email::Receiver::InvalidPost: Access Denied
我还测试了 #42079 之前的相同情况，其中传入邮件被接受，确认这是由该更改引入的回归问题。
该 PR 保留了预期的媒体审核功能，而不是绕过它。经过修复后，传入邮件作为 ReviewableQueuedPost 入队，其审核原因保持为：
contains_media
相关的 Email::Receiver 和 NewPostManager 规范在本地通过：
261 个示例，0 个失败
因此，这似乎解释了我上面报告的 Access Denied 行为，包括为什么纯文本邮件有效，而包含嵌入媒体的富文本邮件无效。