活动摘要邮件文本中缺少空格字符

我刚给自己发送了一些预览摘要,因为我通常不会收到它们。

我注意到电子邮件中的标题和文本有一些随机但一致的空格字符丢失。这些空格在论坛内容中并未丢失,但在多个生成的预览摘要中却持续丢失,在各种电子邮件客户端中查看时都是如此。

我尝试删除并重新添加原始空格,但无效。

摘录:

我查看了从其他 Discourse 论坛收到的摘要,没有在其他地方看到这种情况。

有人遇到过这种情况吗?或者知道这是怎么回事吗?

这会不会是字体/显示问题?您检查过底层的原始内容吗?

嗯。我不确定如何诊断字体/显示问题。电子邮件在 Windows 和 Linux 的多个邮件客户端和浏览器中显示相同。

我已将 .json 添加到论坛帖子 URL,并且“topic_slug”或“cooked”内容没有任何问题……

我是否还能在原始内容中检查其他内容?

1 个赞

您需要检查原始电子邮件,而不是帖子。

1 个赞

好的 - 我查看了原始电子邮件,在 HTML 版本缺少空格的地方,文本版本有正确的空格。但是,文本版本缺少其他空格字符。毫无规律可言。

也许是在从旧平台复制/粘贴受影响的主题的过程中出现了字符编码故障? 编辑:不对。它还在继续处理当前帖子,也处理其他电子邮件——不仅仅是摘要。

最近的 Discourse 摘要(包含当前帖子)没有出现同样的问题,所以我不会太担心,除非我看到它继续下去。 编辑:它还在继续。

(题外话:为了关注这些事情,我现在希望我能每天强制将一份全面的摘要发送到我的管理员帐户——无论我是否一直登录。)

能否将其中一封电子邮件作为附件转发给我?

编辑:已完成

好的,这是我在原始文本电子邮件中看到的内容:

[误/虚假信息开始压倒文明][2]

生成式人工智能的阴暗面在于,它能够大规模生产错误信息(由于捏造)和虚假信息(即为了达到某个目的而故意制造假新闻)。以权威来源的风格渲染网页非常简单,而深度伪造技术的进步将使视频故事的补充更容易。除了 Vinge 的用假信息掩盖信息的“彩虹尽头”(我不认为这是一种解决方案)之外,是否有科幻作家思考过这个问题以及如何解决?

注意:

  • to overwhelm :white_check_mark:
  • a paperback :white_check_mark:
  • Renderingof :x:
  • Asidefrom :x:

以及 HTML 版本中的内容:


<a href="https://forum.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style="text-decoration: none; font-weight: bold; color: #006699;; font-weight:400;line-height:1.3;margin:0;padding:0;text-decoration:none">
<strong >误/虚假信息开始压倒文明</strong>
…
渲染网页的风格类似于权威来源非常简单,而深度伪造技术的进步将使视频故事的补充更容易。除了

注意:

  • tooverwhelm :x:
  • apaperback :x:
  • Rendering of :white_check_mark:
  • Aside from :white_check_mark:

在最原始(即编码)形式中,这些错误仍然存在:

[误/虚假信息开始压倒文明][2]

生成式人工智能的阴暗面在于,它能够大规模生产错误信息(由于捏造)和虚假信息(即为了达到某个目的而故意制造假新闻)。渲染网页的风格类似于权威来源非常简单,而深度伪造技术的进步将使视频故事的补充更容易。除了 Vinge 的用假信息掩盖信息的(彩虹尽头),我不认为这是一种解决方案,是否有科幻作家思考过这个问题以及如何解决?
Ken

<a href=3D"https://foru=
m.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style=
3D"text-decoration: none; font-weight: bold; color: #006699;; font-weight:=
400;line-height:1.3;margin:0;padding:0;text-decoration:none"
                         <strong >误/虚假信息开始压倒文明</strong>

这些不在原始/已处理版本中:

000000d0: 5265 6e64 6572 696e 6720 6f66 2077 6562  渲染网页
000000e0: 2070 6167 6573 2069 6e20 7468 6520 7374   页面风格
000000f0: 796c 6520 6f66 2061 7574 686f 7269 7461  权威
00000100: 7469 7665 2073 6f75 7263 6573 2069 7320  来源是
00000110: 7374 7261 6967 6866 6f72 7761 7264 2c20  直截了当,
00000120: 616e 6420 7072 6f67 7265 7373 2069 6e20  并且进展
00000130: 6465 6570 2066 616b 6573 2077 696c 6c20  深度伪造
00000140: 6d61 6b65 2076 6964 656f 2073 746f 7279  将使视频故事
00000150: 2063 6f6d 706c 656d 656e 7473 2065 6173   补充更容易
00000160: 6965 722e 2020 4173 6964 6520 6672 6f6d  。 除

不是我不相信你 :smiley:

所以……电子邮件正文,无论是文本部分还是 HTML 部分,偶尔都会删除空格。而且不是在同一个地方!

我推测这些错误可能是在以下四个地方之一引入的:

  • 在 Discourse 中生成电子邮件时
  • 将电子邮件传输到电子邮件提交服务器时
  • 将电子邮件传输到中间/最终服务器时
  • 传递到用户邮箱时

从头开始可能最容易。

您能否让 Discourse 将邮件提交到一个本地 MTA,您可以在 MTA 发送给您的“实际”电子邮件交付服务器之前检查队列中的邮件?

谢谢你的分析,Michael!

我不是高级邮件管理员——我运行的是典型的推荐的自安装,通过 MailerSend.net 进行实际的出站邮件发送,并且已经仔细配置了 DKIM/DMARC 等以使其正常工作。根据我所读到的内容,集成 sendmail 或 Postfix 等本地 MTA 是一种高级操作,在大多数情况下不被推荐……我有点担心弄乱它并可能破坏现有的工作流程。:grimacing:

是否有我可以考虑的、易于恢复的、用于故障排除的 MTA 实现?

上方编辑中所述,此问题不仅存在于管理员复制粘贴的内容中,也存在于用户当前发布的内容中——并且现在已在 summary、user_replied 和 user_posted 电子邮件中观察到。

MailerSend 支持已确认,当他们从 Discourse 收到请求时,空格字符确实丢失——因此错误似乎出在 Discourse 生成电子邮件的过程中……?

供参考,在预览生成的摘要时,空格字符并没有丢失——只有在作为电子邮件接收时才会丢失。


与此同时,我遇到了这个摘要电子邮件问题,其他用户从二月份开始也报告了此问题:

这些重复的帖子确实存在于生成的摘要预览中。

编辑于 2024-04-26:重复摘要问题已确定。在修复之前,我已通过更改设置缓解了该问题,但这似乎与本主题无关。 发出的电子邮件仍然缺少空格字符。


我已通过命令行更新并重建,以查看是否能解决任何问题,但没有效果。

如果并非所有在 tests-passed 分支上更新到最新版本的人都遇到了这些问题,我可以在我的设置中检查哪些方面?

如果你能暂时禁用你的服务器和mailsend之间的TLS,你就可以检查实际的通信流量,这将显示Discourse是否发送了空格,从而一劳永逸地解决这个问题。

如果你不能,你可以尝试MITM流量,但这更复杂。

如果以上两种方法都不奏效,在这种情况下,我会配置一个本地的postfix,但不是配置它直接发送邮件,而是让它像Discourse一样将邮件发送到你的mailsend账户。

这样你就可以让Discourse通过任何一种方式发送邮件,并且你可以在邮件发送出去之前检查postfix队列中的邮件。

谢谢 Michael——我是“在线检查”新手,但我发现了以下问题。

MailerSend 需要 TLS 和 587 端口。所以:

  • 我创建了一个备用的 app.yml,用于将邮件发送到端口 2525 的免费 mailtrap.io 账户
  • 设置 DISCOURSE_SMTP_ENABLE_START_TLS = false
  • 使用以下命令应用更改:
cd /var/discourse
./launcher destroy app
./launcher start app
  • 设置 Wireshark 通过 tcpdump 监控远程流量

Wireshark 中的电子邮件内容数据包以及在 Mailtrap 收到的未加密电子邮件中,到目前为止没有丢失空格字符。使用我的原始配置连续运行的特定测试摘要会出现空格丢失,而使用 mailtrap 版本则不会。这是否表明问题是由 TLS 加密引入的?

编辑: 我突然想到,我没有充分利用 Mailtrap 的测试设置。我后来向 Mailtrap 运行了几个加密的预览摘要——使用端口 587 和启用的 TLS——并且没有看到任何丢失的空格字符。我现在在想,尽管 MailerSend 告诉我收到的请求中存在问题,但它可能还是发生在他们那边?不确定该让他们检查什么,但我计划将这些发现反馈给他们。

2 个赞

(以防万一有帮助:我快速查看了我的设置,没有发现问题。所以我想知道你是否有影响你设置的主题或插件。我所做的是访问 mail-tester.com 获取一个临时目的地,然后使用 Admin->Emails->Preview Summary 将摘要发送到临时目的地,然后点击 mail-tester 查看 HTML 和纯文本版本。尝试使用相同的策略看看是否有任何不同可能值得一试。)

谢谢,Ed——要访问 mail-tester,我的电子邮件必须通过我的 MailerSend 中继,而这正是我试图从链中移除的。但你的评论促使我回到 Mailtrap 并使用 TLS 加密进行测试,我已经编辑了我之前的帖子。

1 个赞

我也觉得很有可能。

为了进行可靠的测试,接下来我会手动通过您的 MailerSend 帐户使用 openssl s_client 提交您捕获的纯文本电子邮件之一。