自托管的邮件回复在最新更新后停止工作

支持
1

我的论坛不再响应通过电子邮件发送的回复。

通过电子邮件回复的功能此前一直运行良好，但似乎该功能在 9 月 29 日左右停止工作。

我对此时间点没有确凿的证据，因为论坛并不活跃，但毫无疑问现在该功能已无法使用，且论坛日志显示 9 月 29 日之后未收到任何消息。

被拒绝的邮件日志中最近的一条记录也是 9 月 29 日。所有被拒绝的消息都来自一次性地址，且内容看起来像垃圾邮件——因此这似乎按预期正常工作。

退信日志为空或显示“未找到日志”。

论坛生成的消息（由已登录用户的活动触发）仍在发送（我至少能收到这些），但由于上述原因，活动水平甚至比平时更低。几乎所有活跃用户更喜欢通过电子邮件而非基于浏览器的交互。

我使用自己的微软托管邮箱地址或 Gmail 地址向论坛帖子邮件通知发送测试回复邮件，但并未收到退信警告。这些邮件只是凭空消失，没有任何痕迹。论坛邮件日志中也没有任何相关记录。

论坛错误日志显示 9 月 29 日有几条警告（黄色感叹号图标），内容为“无法处理电子邮件：Email::Receiver::BadDestinationAddress 收到…"，这些警告看似无害，与之前记录的类似事件没有区别。我推测这仅仅是被拒绝的垃圾邮件。

10 月 1 日记录了一个实际错误：

消息

ActionDispatch::Http::MimeNegotiation::InvalidType（“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” 不是有效的 MIME 类型）
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

回溯

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

环境

HTTP HOSTS: nzarchitecture.net.nz

不过，我不确定这是否相关，而且自那以后日志中未再出现其他错误或致命错误（以浅红色或深红色叉号图标表示）。

当我在 www.mail-tester.com 上测试时，我的两个邮箱地址均未被标记为垃圾邮件或列入黑名单，且使用这些地址与真人沟通也未遇到任何问题。

论坛使用 Mailgun，但我推测这仅用于发送批量邮件，因此 Mailgun 账户或 API 密钥的任何问题不应影响传入消息？碰巧的是，当我登录 Mailgun 账户时，并未发现 Mailgun 存在明显问题或错误消息。

我假设如果论坛仍能正常发送邮件，那么 Mailgun API 密钥应该是正常的。

自通过电子邮件回复功能正常工作以来，论坛设置未作任何更改，且我看到“通过电子邮件回复”设置复选框仍处于选中状态。

论坛托管在 Digital Ocean 上。Digital Ocean 设置中未更改该域名的 DNS 设置，且论坛的 MX 记录似乎正常/未更改。

自问题出现以来，论坛已更新至 2.8.0 beta 7 版本（过程中可能进行了重建），但并无改善。

我遗漏了什么？
可能哪里出错了？
如何让通过电子邮件回复的功能重新正常工作？

1 个赞
2

该错误似乎无关。

一般来说，测试“邮件接收”比测试“通过邮件回复”更容易。请检查“启用手动轮询”和“邮件接收”设置，向工作人员类别添加一个电子邮件地址，然后尝试使用与论坛管理员账户相同的电子邮件地址向该地址发送邮件。

然后，检查“管理 - 邮件 - 退回/已接收/已拒绝”，以了解具体情况。

您的“通过邮件回复地址”配置是否正确？

5 个赞
3

你好，谢谢 Richard。

我可以确认“手动轮询已启用”和“电子邮件收件”设置仍处于启用状态。

我已将我的 Gmail 地址作为自定义地址添加到员工类别中，但我找不到通过论坛向员工发送消息的方法？所有“联系我们”链接均在论坛设置文本中配置为 mailto: 链接，直接指向我的个人日常邮箱地址——点击其中一个链接只会打开我的电子邮件应用程序，并自动填充我的个人直接邮箱地址，这意味着论坛将无法收到该消息。

4

不，您应该在类别设置中设置类似 staff@nzarchitecture.net.nz 的地址，然后使用您的 Gmail 向该地址发送消息。

5

好的。

我尝试了完全相同的操作，但在任何退回/接收/拒绝日志中都没有出现任何记录。

6

您的邮件服务器已设置为 Digital Ocean。

image
image745×151 10.5 KB

您是否在他们那里有邮件服务器？

7

这是运行邮件接收器的 Droplet 的 IP 地址。

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

8

过去 5 个月已发生变化

image
image1123×176 3.28 KB

9

我知道是怎么回事。又是那个@#(($* LetsEncrypt 的问题，它在 9 月 30 日导致了半个互联网许多事物瘫痪。

只需重新构建邮件接收器的 Docker 容器即可。

6 个赞
10

哈哈哈哈，是的。我忘了那回事。哈哈

3 个赞
12

您必须关注 @RGJ 发布的话题。

这应该能解决您的问题。

4 个赞
13

啊，好的。这听起来很有希望！
我该如何重新构建“邮件接收器 Docker 容器”？这是否不同于通过仪表板更新论坛时发生的“Docker 管理器”重新构建？

我只需按照这个操作吗？如何手动将 Discourse 和 Docker 镜像更新至最新版本？ - 操作指南 / 管理员 - Discourse Meta

14

您需要登录到网站的命令行界面。

这不是通过论坛管理后台进行的。

15

您好，我按照该链接中的说明成功重新构建了邮件接收器 Docker 容器：Direct-delivery incoming email for self-hosted sites - howto / sysadmin - Discourse Meta

为此，我不得不升级/扩容我的 Digital Ocean droplet，因为即使删除了主机上存储的所有备份等文件，磁盘空间仍不足以进行重建。

重建后，我能够向 staff@nzarchitecture.net.nz 发送该消息，论坛日志此次已确认收到。
然而，当我尝试通过电子邮件回复我已收到通知的论坛现有主题时，虽然入站消息现在已被确认，但它们并未出现在论坛上，且所有消息在电子邮件日志中均显示为“邮件投递失败”警告。

入站消息未出现在“退信邮件”日志中，但全部出现在“拒收邮件”日志中，并带有警告 [Email::Receiver::BadDestinationAddress]——包括我自己的管理员邮箱账户，我希望其目的地地址不会突然变为无效。

16

您最近重新构建过邮件接收器吗？

3 个赞
17

是的——大约半小时前做了这件事，导致了上面的帖子。
我刚刚又进行了一次完整的重建，（但愿如此）一切似乎又恢复正常了。

1 个赞
18

可能是因为没有设置强制 HTTPS，而重建解决了这个问题。

1 个赞
19

实际上，我刚刚在仪表盘中看到了关于此问题的确切警告，因此点击了提供的便捷链接进入相应设置并勾选了该选项。

我并未意识到强制 HTTPS 对于接收传入邮件是强制要求的。

缺乏强制 HTTPS 也可能导致使用 Facebook 登录时出现问题——我最近收到 Facebook 的通知，称我的网站违反了其服务条款并已被暂停。我的 Facebook 应用开发者控制面板中没有显示任何操作项，因此我提出了申诉，但回复称由于我的论坛 URL 生成了未指明的错误，他们无法验证该网站。

1 个赞
20

看来勾选“强制 HTTPS"选项对 Facebook 登录毫无帮助。Facebook 技术支持仍表示，该网站的落地页会为他们生成“您的连接不是私密连接 NET::ERR_CERT_COMMON_NAME_INVALID"的安全警告。

根据错误页面显示，证书的颁发者是“R3”——谷歌搜索表明这与 Let’s Encrypt 有关，而正是 Let’s Encrypt 的证书过期问题触发了重建 Discourse 安装的需求。

这是巧合吗？这是否表明最新的 Discourse 版本（2.8.0 beta 7）仍存在证书问题？还是说这是与托管服务/Digital Ocean 无关的独立问题？

21

我自己在谷歌上的笨拙搜索让我得以使用 https://www.whynopadlock.com/ 测试我的 URL，其结果将我引向了这位 Let’s Encrypt 用户发布的 帖子：

Let’s Encrypt 最近将其中间证书从 “Let’s Encrypt Authority X3” 更新为 “R3”。

如果您使用的是行为规范的 ACME 客户端，它会在您上次续期时自动开始使用新的中间证书。您应该不会察觉到任何差异。

在您的情况下，也许您一直硬编码中间证书。如果是这样，您需要使用新的中间证书，您可以在 Chains of Trust - Let's Encrypt 上找到：https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

当前版本的 Discourse 是否可能错误地“硬编码了中间证书”？

“中间证书”是否是 Discourse 管理员现在需要管理的对象？如果是，该如何操作？

请告诉我我是否已经偏离主题——我不确定这是否属于同一问题的一部分。