山魈状态：排队答案

【问题标题】：Mandrill Status: queued山魈状态：排队
【发布时间】：2015-11-17 07:21:02
【问题描述】：

我正在测试 Mandrill API 并向我的 GMail 帐户发送了一封电子邮件。在 API 日志中，它说：

“状态”：“排队”

根据https://mandrill.zendesk.com/hc/en-us/articles/205582717-Why-does-a-delivered-message-say-queued-：

大多数时候 Mandrill 发送电子邮件的速度比收件人服务器快得多能够接受或处理它

GMail 无法处理我发送的一封电子邮件？

【问题讨论】：

在您发送请求后，如果您再次调用以读取该消息的信息，它是否仍然显示已排队（也许尝试等待一分钟，看看它是否仍然显示）？当你第一次发送请求时，我确信他们会排队，但我认为这会很快改变

标签： mandrill

【解决方案1】：

Mandrill API 中的排队响应与来自接收服务器的排队响应不同。

当您通过 Mandrill 发送消息时，您首先将其中继到 Mandrill，Mandrill 对其进行处理，然后 Mandrill 将其中继到接收服务器。这一切都发生得很快，但两个中继步骤是分开且不同的。您链接到的知识库文章提供了有关最后一步的更多详细信息，中继到接收服务器，不是 Mandrill API 的queued 状态。

Mandrill API 可能会因多种原因回复 queued，包括您是否添加了附件，或者您是否在单个 API 调用中发送给多个收件人。

如果没有看到实际的 API 调用，很难说为什么你会收到queued 响应。但是，如果您使用的是示例消息/发送 API 调用，您将需要删除您实际上没有设置的所有可选参数。例如，样本有假附件，并指定了一个子账户。附件将导致调用异步处理。子帐户可能不存在，然后会导致调用失败。因此，如果是这种情况，请尝试删除所有这些可选参数。如果不是，请提供您正在进行的 API 调用，其中敏感数据已编辑（API 密钥、实际电子邮件地址）。

【讨论】：

在我的情况下，错误是由于附件字段引起的，我将其删除并开始工作。如果您为 Mandrill 工作，请 Kaitlin，您可以在文档中添加一些评论吗？
@McSas; the attachement docs 中提到了这一点：Messages that include attachments will be queued and the attachments processed through a series of virus scanning engines to help ensure that the attachments are safe for recipients. 我真的希望在 API 文档中提到这一点。他们听起来好像你应该获得queued 状态的唯一时间是如果你通过async = true。
抱歉这么晚才问。有没有办法仅使用 API 或以任何方式使用 NODEJ 来获取消息的状态，无论是排队还是传递等？

【解决方案2】：

原因可能是每小时/每月配额已结束，或者您为单个公共 IP 服务器使用相同的多个帐户。

【讨论】：