Mandrill：在假设可交付性之前我要等待多长时间？

Posted 2023-02-25

【中文标题】Mandrill：在假设可交付性之前我要等待多长时间？

【英文标题】：Mandrill: How long do I wait before assuming deliverability?

【发布时间】：2014-05-02 21:43:03

【问题描述】：

我已经设置了一个 Mandrill 网络钩子，它会在电子邮件硬退回或被拒绝时更新我的​​应用程序，因此我不会在我的数据库中保留那个特定的电子邮件地址。它的工作方式是这样的：用户给我一个地址，我向他发送确认信息，如果我在 30 分钟内没有收到 Mandrill 的 webhook 的消息，我认为没关系。

所以我用不存在的地址进行了一些测试，但结果并不理想。在我认为它们很好之后很久，它们中的大多数看起来都已经交付了几个小时。

另外，我没有考虑接收 webhook 批次的延迟。根据出站活动日志，一封邮件在下午 2:01 被退回，但 webhook 历史记录显示一批邮件仅在下午 2:52 发送。

我的问题是：为了让 Mandrill 有足够的时间检测硬退回/拒绝，然后向我发送 webhook 批次，我应该将我的应用程序的可交付性假设延迟多长时间？由于高峰时间或其他特殊事件的处理延迟，我可以忍受 5% 的不良电子邮件过去，但似乎我的 30 分钟根本不足以捕捉任何东西......

【问题讨论】：

运气好吗？我正在尝试同样的事情......

很抱歉，我没有找到单独使用 Mandrill 的方法。一些发往虚假 Gmail 帐户的邮件会在几天内保持“递送”状态。这可能是特定于 Gmail 的问题，但我无法编写代码解决它。我最终使用了付费电子邮件验证器 API，无论该帐户是否存在，它都能立即回复我。一个糟糕的解决方案，但它当时似乎完成了工作。

请注意，mandrill 通常会阻止“秘密”队列中的电子邮件并且从不发送它们，即使它们被 API 报告为“已发送”并在 mandrill UI 中“已发送”。我 1 天前才发现这个，所以我想你可能想知道。

@tbuteler 您介意说一下您使用的服务以及它是否运作良好吗？此外，似乎如果您查看来自 mandrill 事件的消息或通过 API 检查 smtp_events 并在其中找到 250 或类似内容，则可以安全地假设它已交付...... ...不幸的是，发生这种情况时似乎没有生成一个偶数...所以他们的“发送”实际上没有任何意义...而且几乎不可能与那里的任何人交谈，即使是通过电子邮件，所以我有点怀疑。 ..

我们使用了来自my-addr.com 的付费服务，我想。它非常便宜，但速度也非常慢，所以我只通过队列调用他们的 API。但是，我根本无法认可它，因为对我来说，这样的服务如何存在仍然是个谜：我到处读到，没有邮件服务能够可靠或真实地揭示哪些帐户存在或不存在，这就是我想要实施的原因基于实际可交付性的解决方案。反正我的猜测是 Mandrill 不想让我们知道这件事，肯定和垃圾邮件有关。

【参考方案1】：

不是您要寻找的答案，但 Mandrill 不允许您这样做。检查电子邮件是否已送达的唯一方法是轮询 Mandrill（使用 message/info.json API）。要查看消息是否已送达，您必须检查 smtp_events 并查找以 250 开头的 diag 事件。正如您已经体验过的，从送达到可以通过API。根据我的经验，正常情况下大约需要 10 分钟，但可能需要很多很多小时（这是退回的电子邮件以及立即发送的电子邮件的情况）。

如果知道电子邮件何时送达对您很重要，我建议您切换到其他电子邮件提供商。 There are plenty of different ones 在那里。我个人使用过Amazon SES。它们比 Mandrill 便宜，您可以在大约一秒钟后收到交货通知。请注意，Amazon SES 比 Mandrill 更简单一些（它们不支持打开/点击跟踪、模板、专用 IP 等），因此它可能不适合您。

【讨论】：

最后，一个更明确的答案，虽然我早就放弃了。