我想插一句……我遇到了同样的问题，但情况比原帖作者的经历更令人恼火。我也在使用 GSuite，并为 Discourse 配置了单独的“应用密码”。不过我注意到，我的问题并非由每日邮件数量或 SMTP 速率限制引起。发生该问题的论坛在发帖、摘要邮件等方面几乎没有任何活动。实际情况是，偶尔会出现 SMTP 认证失败的情况……这与 Google 方面的一个缺陷有关：每隔一段时间（大约每 3 到 5 个月一次），SMTP 认证会在几分钟内失败。通常，当我的邮件客户端遇到这种情况时，我只需等待 5 分钟再试，一切便神奇地恢复正常。但在 Discourse 中，一次失败就会让它陷入疯狂：即使队列中只有几条消息，它也会开始过度反应，反复尝试为队列中的每条消息登录。结果就是触发了一轮 SMTP 认证“闪电战”，进而激活了 Gmail 内部的另一种暴力攻击防护机制，很快 Gmail 就会停止处理登录尝试并报错。因此，此时无论密码是否正确，也无论 Gmail 的认证问题是否已解决，都无济于事——因为 Discourse 已经彻底失控，导致你被锁定。
别再只关注速率限制了，不如把重点放在以下方面：
- 提升效率：例如，在单个 TCP 连接上发送多封邮件。这是标准做法，可减少活跃套接字数量和网络开销。
- 实施合理的递增重试延迟机制：如果 SMTP 认证失败，完全没有必要在如此短的时间内再次尝试。当 SMTP 认证失败时，要么禁用邮件发送并在管理员界面显示警告，提示 SMTP 认证失败；要么设置一个严肃的延迟机制，例如第二次尝试在 60 秒后进行，第三次在 5 分钟后，第四次在 30 分钟后，依此类推。
目前，我不得不基本更改 SMTP 设置以禁用邮件，然后重新构建应用，等待 24 小时，再恢复设置，最后再次重新构建。即使在管理员设置中提供一个简单的复选框来禁用邮件发送，也比现在的情况好上一千倍。