功能请求：为摘要单独设置电子邮件账户

贡献 功能
1

作为一个新手，今天我们的邮箱系统基本 shutdown（停摆），用户无法注册、找回密码或通过邮箱登录。原因是论坛从旧版迁移后，每周摘要邮件开始发送，导致 sidekiq 队列中积压了超过 30 万封邮件。因此，任何尝试通过邮箱登录、注册或找回密码的用户都收不到邮件，结果就是 hosed（彻底完蛋）了……

问题的根源在于我们使用 GMAIL 作为邮件中继服务，而免费的 GMAIL 对此类 SMTP 中继设有发送限制，因此 GMAIL 当天对我们进行了封禁。

我希望未来能增加这一功能（除非已有其他方式解决）。

建议方案

增加一组 app.yml 配置变量，允许管理员为摘要邮件设置不同的邮件中继服务。

在设置过程中，对话框可以提示：“您是否为摘要邮件设置不同的 SMTP 服务器？”用户可以选择使用相同的 SMTP 中继服务。

理由

对于拥有大量摘要邮件活动的大型论坛，最好能提供一个选项，将这些摘要邮件通过不同于关键任务（如密码恢复、登录和注册）所使用的 SMTP 中继服务进行发送。

目前，我们已经关闭了所有摘要邮件。我们也注意到可以设置“仅发送最近 X 天内的摘要”这一限制。今天检查时，默认值是 365 天。不知为何，我们迁移后的服务器积压了超过 30 万封邮件。

讨论

这并非一个严重问题，但我觉得将 摘要邮件 与 关键邮件 区分开来会更好；因为即使 关键邮件 的 队列优先级 更高，如果 SMTP 中继因摘要邮件数量过多而被封锁，那么 关键邮件 也会被一并阻断。

此外，一些论坛可能正经历类似情况，却不清楚为何 SMTP 邮件无法发送；实际上，原因正是上述问题。

感谢您的认真考虑。

TangentialDuck

2 个赞
2

请注意，Discourse 不支持使用免费的 Gmail 发送任何电子邮件。这同样违反了 Google 的服务条款。以这种方式使用 Gmail 已接近于#unsupported-install（不受支持的配置）。

很难理解为何要实施此功能请求；如果您使用了受支持的邮件机制，该事件本就不会发生。

3

这不是真的。

我们拥有 Google 域名，免费邮箱服务多年来一直得到支持，目前依然如此。
@Stephen，请多包涵。运营论坛已近 20 年，我们可不是昨天才“破壳而出”的新手。

1 个赞
4

确实如此，忽视我们邮件指南的社区经常会遇到这个问题。

Google 不允许从 Gmail 账户发送任何事务性邮件，我们曾看到有社区因尝试这样做而永久失去账户。付费的 GSuite 账户对每日事务性邮件数量也有严格限制。您并非首位陷入此困境的人，我们无法协助您通过技术手段绕过 Google 实施的条款。

1 个赞
5

我刚刚登录了我们的 GSuite 账户并查阅了服务条款，您所说的并不属实：

@Stephen，您未免太过急于下结论。我并未要求任何“绕过 Google 服务条款”的功能，因此请勿曲解我的发言。

您总是如此草率行事，甚至对他人@Steven 进行不实指责。或许可以让其他不那么冲动的人来回应我的请求？

6

你在这里的说法有些不一致：

Gmail 并不等于 G-Suite。付费的 G-Suite 账户有 以下限制：

限制类型 限制值
每日消息数量
每日发送限制* 2,000（试用账户为 500）

免费 Gmail 账户始终受限于 500 封邮件的发送上限。

那是 Google 的服务条款，与上述内容无关。“之前一直能用”和“被允许使用”之间显然存在区别。过去七年中，我们见过许多用户尝试这样做，但从未成功过：

关于该主题的更多阅读材料

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

我们有一份 邮件设置指南，其中列出了推荐的邮件服务提供商。你不必完全遵循该指南，但我们无法协助你以非预期的方式使用 Gmail 或 GSuite。

1 个赞
7

是的，在我发帖之前我就已经知道所有这些了，@Steven。

在我看来，你确实应该避免低估那些在马赛克浏览器出现之前就已在线的人的知识，并且在回复时要谨慎。不要通过对他人的指责性言论而破坏 Discourse 以及科技本身的乐趣。

起初你告诉我“根本没有免费的 Gmail”（我知道这是错误的），并指责我从事某些恶意活动；随后你又去做了功课，发现 GSuite 有每天 2,500 封的限制，而我早已知晓这一点，因为我多年来一直管理这个 GSuite 账户。

当你如此草率地采取行动、指责他人做坏事且在细节上出错时，你应该道歉。

发布一个简单的功能请求，却不得不回应这种负面情绪，这真的毫无乐趣可言。

8

这表明你使用的是 Gmail 而非 Gsuite，这违反了规定。许多人，尤其是那些不了解系统管理的人，试图使用 Gmail，但这违反了服务条款。告知人们这一点是明智之举，并非刻薄或无礼。

但你使用的是 Gsuite，这完全没问题。从你最初的帖子中无法判断这一点。因此，你似乎受到了不公平的对待。

不过，正如你所描述的，Gsuite 实际上无法在高流量的论坛上正常运行。你正在请求一项新功能，以使 Discourse 能够与限制每天发送 2500 封邮件的邮件服务配合使用。

创建一个实现该功能的插件是可能的，但并不容易。我怀疑，对于熟悉 Discourse 开发的人来说，这需要几天的工作量。

解决方案是改用能够发送你所需邮件量的邮件服务。

2 个赞
9

跟进一下，此主题为重复内容。关于支持多个 SMTP 服务的需求此前已有人提出：

此处用例略有不同，但该问题源于摘要配置错误。Unix.com 拥有 138,062 名用户，即使对于密码重置等关键任务，每日 2000 封邮件的上限也仅能支持 1.8% 的用户进行日常交互。

编辑：将 2500 更正为 2000，以反映实际限制

1 个赞
10

这就是为什么，@pfaffman，对于所有在线用户来说，最好不要急于对他人的技术或其动机做出指责性的言论。通常，我们在扣动扳机、开始“开火”之前，应该先提出问题，哈哈。

是的，我说了 GMAIL 而不是 GSUITE，但当我几十年前创建这个域名时，还没有 GSUITE，它当时只被称为 GMAIL。此外，我没有使用任何精确术语的原因是，我的功能请求与 GMAIL 毫无关系。那完全是个旁支的讨论。

如果我想（或者你想），我们可以去任何服务器，就像这里许多人能做的那样，输入 apt install postfix 或 apt install sendmail，在 15 分钟或更短时间内，我们就能搭建并运行自己的 SMTP 中继。

请不要把话题从“将大量流量从摘要处理流程中移开”转移到关于 GMail 与 GSuite 与 blah blah 的讨论上。apt install postfix 非常简单。

问题在于可靠性。这是基础中的基础。

将 关键任务邮件 与 摘要邮件 运行在同一个 SMTP 中继上，并不是我想要的运行方式，所以我提出了这个功能请求。

让我们把讨论保持在焦点上，即我所请求的内容，因为我在构建 关键任务应用 方面确实有所建树。

重申一遍：

我不希望我的 关键任务邮件 与 摘要邮件 共用同一个 SMTP 中继，我认为这是一个好主意，能让系统更加稳健。

让我们停止关于 GMAIL、GSuite 或 MonkeyMail…… blah blah 的非常旁支的讨论。很抱歉我甚至提到了它，因为邮件服务器与我的功能请求无关。

慢一点。对他人友善……如果有人发布了什么内容，而你不理解或感到困惑，那就提问；不要攻击别人，@Steven。

我可以在 10 分钟内搭建一个 SMTP 中继。我们都可以。apt install postfix 搞定……如果我想使用 GSuite 或 postfix 或 donkey kong mail，那是我的事，与他人无关。正如我所说……

核心要点……（再次强调）

对于非常繁忙的服务器来说，将 关键任务邮件 放在与 摘要通道 不同的服务器上会更加可靠。这只是基础知识。

apt install postfix 会创建一个 SMTP 中继。我请求增加一个功能，允许将 关键任务邮件（密码重置、注册邮件、邮件登录）与 摘要邮件 放在不同的通道上，以提高可靠性和性能。

11

@Steven

这并非重点，有些跑题了。

附注：实际上，我们曾经拥有超过 50 万名用户，但我已经清理掉了它们 :slight_smile:

我指的是将“关键任务邮件”与摘要邮件流量通过不同的通道（SMTP 中继）发送。

显然，这是一个简单的概念，而且很容易理解为什么使用两个通道会更好？

这场讨论已经远远偏离了我提出功能请求的初衷。

真后悔我居然发帖问了…… :frowning:

在我看来，我原帖之后的这场讨论已经严重偏离了主题。

12

你不应该低估任何试图帮助你的人。没有人是反对你。

3 个赞
13

这是我关于此主题的最后一篇帖子。

关于 GSuite 的话题（这完全不是我的功能请求的重点）

  • 用户在 24 小时内可发送的最大消息数量为 10,000 条。不过，具体数量可能因您的 G Suite 账户中的用户许可证数量而异。
  • 已注册的 G Suite 用户在 24 小时内无法向超过 10,000 个唯一收件人中继消息。

参考：Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

然而，这对我来说完全离题了；因为即使 GSuite 允许每天通过 SMTP 中继发送超过 10 亿封邮件，我仍然希望为 关键任务邮件 和 摘要邮件 设置不同的 SMTP 中继通道。

这才是重点。

谢谢。请在未来的升级中考虑这一点。我认为添加此功能相对容易。

此功能请求与 个性 无关，也与 电子邮件服务提供商 的优劣或细节无关。

我的功能请求是关于可靠性，以及确保 关键任务邮件 不会进入 摘要通道。

完毕…… :slight_smile:

14

开发 Discourse 的人拥有能正常工作的邮件系统。他们不会为了那些想要使用多个不可靠邮件系统的人添加此功能。如果你想要，可以开发一个插件，但这会很难开发且难以维护。

安装 Postfix 可能很容易，但如今要运行一个功能正常的邮件服务器，比我当年将 Sendmail 和 uucp 移植到 Linux 时要困难得多。如果运行邮件服务器很容易，你早就拥有一个能正常工作的邮件服务器了，也就不会想要两个了。

我并非这么认为，但也许你在 Discourse 插件开发方面比我懂得更多。

3 个赞
15

一个简单可行的变通方法是，如果摘要邮件引发诸多问题，可以直接全局“禁用”它。最佳建议可能已经有人提出过了，我唯一能建议的是使用不施加任何限制的邮件服务商，例如 Mailgun。这样，大家都会满意（除非你有某些限制，导致必须使用特定的邮件服务商）。

4 个赞
16

我同意，@neounix 最初发布的内容存在很多不一致之处，后续回复中的许多细节也发生了变化。

上述内容中我加粗的部分，免费账户的限制在本主题的其他地方已有记录。即使是“免费”的 G Suite 老账户 也存在这些限制。如果这是一个付费的 G Suite 账户，那么上述评论具有误导性，这也解释了我的回应。

再次强调，你并未说明具体使用的是哪项服务。如果是免费层的旧版 Google Apps，那么 每位用户每天的收件人限制为 500 人，与免费 Gmail 产品相同。如果你使用的是付费 G Suite 账户，则应使用 Google SMTP 中继服务，其限制为每位用户每天 1 万次，虽然更好，但依然不够理想，尤其是面对超过 13 万需要请求密码重置的用户时。很高兴听到你在迁移过程中清理了一些用户，但我不确定这实际有多大意义。

我能理解你的沮丧，你的测试未能捕获会被排队的摘要邮件。这导致任何试图重置密码并重新登录账户的人在一段时间内实际上无法使用服务。

你在上文中有几次暗示我断章取义，但在我看来，你的回应与你提供的信息是一致的。如果你不同意，我表示歉意，但重读这些帖子后，仍然不清楚你具体使用的是哪款产品。

顺便提一下，我是 @Stephen，而不是 @Steven —— 你正在标记并通知一位完全不同的用户。

3 个赞
17

如果是这样，欢迎通过在 Marketplace 发布带有预算的帖子来资助它。此外，上面还有一些关于减少邮件量的非常不错的建议☝，建议充分利用它们。

3 个赞
18

目前，我们最终决定完全关闭摘要功能；以下是更新后的背景故事：

我们还有一个测试服务器，由于 Discourse 在安装时默认启用每周摘要（时间跨度为 365 天），即“开箱即用”配置，该测试服务器在上周末也意外触发了摘要发送（这是我们未曾预料到的），哈哈。

因此，在尚未意识到会发生（或可能发生）这种情况之前，我尝试对测试服务器进行备份，但系统拒绝执行并报错。我记不清管理员控制台中具体的错误信息了，但记得有一条线索指向邮件队列。

根据这条线索，我查看了 sidekiq，果然发现队列中有超过 30 万条摘要消息，这源于默认摘要配置中的“启用”状态以及“最近 365 天”的设置。

于是，我从命令行清除了邮件队列，再次进入备份管理面板，备份便顺利完成了。

由于 Discourse 的邮件系统基于 sidekiq 构建，这很可能就是为什么为 关键任务 邮件和 摘要 邮件设置不同渠道（不同邮件服务器）会变得棘手的原因。我意识到这并不像我最初设想的那样简单（仅仅在环境中配置两个邮件服务器）。

接下来是搞笑的部分……哈哈

起初，我认为默认禁用摘要功能（而不是默认启用并设置 365 天的登录窗口）是个好主意；但随后我意识到错误全在我自己，在 Meta 论坛上提出这样的建议并不合适，哈哈。

Discourse 安装时，默认将所有迁移用户（来自我们旧的 vB3 论坛）的 last_seen_at 字段设置为大约 50 年前。

我进入数据库，手动将所有用户的“最后访问时间”改为 10 天前！哈哈。当时我完全不了解摘要配置，以为所有用户显示为 50 年前最后访问是迁移过程中的错误。哈哈……我错了。这其实是有充分理由的。

Discourse 因此触发了一个庞大的每周摘要处理流程，导致我们的生产环境和测试环境上的 sidekiq 不堪重负；这是因为我在测试服务器上执行了“最后访问时间改为 10 天前”的数据库修改“黑客操作”，并将其导出到了生产环境。正是这个错误导致了此次问题。

由于大多数人不会像我一样进入 PostgreSQL 进行各种“黑客操作”，例如：

UPDATE users SET last_seen_at = '今天减去 10 天'

……在涉及大量用户的旧论坛迁移中……

所以他们不会遇到这种大规模的摘要问题。

哈哈

我为因我对 users 表执行 UPDATE 黑客操作而引发的所有紧张局面表示歉意。

尽管如此，我认为将 关键任务 邮件和 摘要 邮件分配到两个不同的邮件服务器是合理的。但查看 sidekiq 后，我目前还不清楚是否有简单的方法来实现这一点，因为我（目前）对 sidekiq 还没有经验。

不过，我可以建议迁移人员：如果您正在将论坛迁移到 Discourse（这确实是个好主意），请保持 users 表中 last_seen_at 字段的默认值即可 :slight_smile:

1 个赞
19

我通常建议在测试实例和外部网络之间部署 Mailhog。它非常适合这种场景。

4 个赞
20

我将在我的预发布实例中添加 DISCOURSE_DISABLE_DIGEST_EMAILS。不过，由于禁发邮件的设置仅针对非管理员用户，因此这并非一个大问题。

2 个赞