大家好，
是否可以为每千个社区优化摘要发送周期？每周一，Discourse 会在 1-2 秒内发送数千封邮件，导致我们的自定义邮件服务器出现垃圾邮件问题。
如何重置每个账户的“last_digest_time”，并将其与其他数千个账户同步？
我们的目标是将每日摘要数量从周一的 5000 封减少到 100-200 封。我们使用 Discourse 已有四年，也许问题出在我们频繁升级到最新版本的某个环节。
另外，是否有关于如何访问 Docker 镜像中的 PostgreSQL 数据库，以及需要在数据库中更新哪些记录的提示？
提前感谢！
你可以在 Rails 控制台中执行。
cd /var/discourse
./launcher enter app
rails c
然后你可以执行类似以下的操作：
User.all.each do |u|
执行任意操作
end
但你最好直接修复你的邮件服务器。
你有什么想法？服务器只是将邮件发送到目的地，然后这些邮件被对方归入垃圾邮件。如果有人在一秒钟内给我发送 2000 封邮件，我也会这么做。
请使用信誉良好的邮件发送服务。
如果您自行托管 SMTP 服务器，就会陷入常见的陷阱。像 Mailgun 和 SendGrid 这样的邮件投递公司采用多种技术，确保其服务器受到信任，并被目标网络视为可靠。因此，文档建议您使用这些产品，而不是自行托管。
没错——虽然您只是间歇性地发送这些消息，但信誉良好的第三方邮件服务可以可靠地每小时向第三方邮箱投递数十万封电子邮件。
很遗憾，如果您坚持自行运行邮件服务器，我们无法提供任何协助。如果您决定不遵循这些建议，即意味着您接受由此带来的额外复杂性。
SMTP 一切正常，包括 DMARC、SPF 和 DKIM。我从 2005 年就开始使用自己的 SMTP 服务。那时候还没有那些毫无意义的“印钞机”式服务。试想一下，如果明天有人开始对空气收费……
那么，让我们回到问题本身。我知道，对于高级测试人员来说，最轻松的做法就是把我打发到某个地方，或者推荐某种付费服务。能否有人帮忙解决一下 Discourse 中的一个严重 bug？我仍然不认同 Discourse 应该在 1 秒内发送 10,000 封邮件。它应该采用轮转服务或类似机制，对账户之间的“last_digest_timestamp”进行规范化处理。
我并非受雇于 CDCK，也不因向您推荐任何第三方服务而获得任何经济利益。
如果您不愿遵循我们的建议和文档，那是您的选择。在这种情况下，您将脱离我们在此为社区提供的免费支持路径，因此您唯一的替代方案是通过 Marketplace 联系顾问。
这并非 Discourse 的问题，该问题源于您的邮件服务器 IP 未被视作可信。我们无法帮您修复此问题，而您也拒绝考虑为此目的而存在的各种解决方案。
这是否意味着你同意在几秒钟内处理 Discourse 的 1 万个字符？
是的，我与发送量是此十倍以上的社区合作，许多运营大型社区的人都在这一规模甚至更大的量级上运作。
您目前的邮件需求似乎已超过您对该协议的专业掌握程度，难以可靠地实现大规模邮件投递，这正是事务性邮件公司存在的原因。这里没有人是在为“大规模邮件”做广告——这仅仅是高容量邮件投递所面临的挑战。
您可以让邮件服务器暂存邮件并分散发送。这实际上是您的邮件服务器的问题，而非 Discourse 的问题。我从 20 世纪 90 年代初开始运营邮件服务器，直到大约 2005 年，当时垃圾邮件变得难以应对。如今情况更加困难。
祝您好运
我有一些速率限制。即使你不这样做，典型的 SMTP 服务器也为你预设好了配置。如今的邮件服务器更智能，可以轻松检测你发送邮件之间的间隔。
是的，因为他们使用了你之前提到的服务。你仍然没有理解这些服务与个人 SMTP 服务之间的区别。他们拥有庞大的 IP 池，并模拟不同的发件人。这对从事“硬性”垃圾邮件发送的公司来说是个好技巧。当然，他们会为这项服务付费。
我不明白为什么人们要在 Discourse 上使用这些“赚钱机器”，毕竟 Discourse 本身并不发送垃圾邮件。哎呀……抱歉……由于一个 bug，它可能因为 @Stephensays 声称这是“正确行为”，而在周一的 1 秒内发送 10 万封邮件。
好吧，我觉得没必要和头顶戴着皇冠 
的人聊天。是的，Discourse 很棒，非常感谢你们的贡献。
我希望没有 的普通用户也能在这里提出一些想法。
根据 Discourse 团队在上方提供的答复，他们认为 Discourse 本身不存在任何问题。我通过直接修改数据库的“脏”方式解决了这个问题。以下是我的解决方案：
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
请更新 SQL 查询中的 last_emailed_at 范围。我在 3 月 16 日这一天有 4000 条 last_emailed_at 记录。因此，现在所有用户都已通过 30 秒间隔优化为 3 天的范围。
Discourse 并非设计用于搭配个人 SMTP 服务使用。很抱歉之前没有解释清楚；它确实可以工作，但对于有常规邮件活动的社区来说，这并不是一个好主意。这是电子邮件现状的局限，我们都在尽力应对。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.