山d状态:已排队

本文介绍了山d状态:已排队的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在测试Mandrill API，并向我的GMail帐户发送了一封电子邮件.在API日志中，显示为:

I'm testing the Mandrill API and sent an email to my GMail account. In the API logs, it says:

状态":已排队"

"status": "queued"

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

大多数情况下，Mandrill可以比收件人服务器更快地发送电子邮件 能够接受或处理它

most times Mandrill can send email much faster than recipient servers are able to accept or process it

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

GMail is not able to handle my one email that I sent?

推荐答案

Mandrill API中的排队响应与来自收件人服务器的排队响应不同.

A queued response in the Mandrill API is not the same as a queued response from a recipient server.

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

When you send a message through Mandrill, you first relay it to Mandrill, Mandrill processes it, and then Mandrill relays it to the recipient server. This all happens quite quickly, but the two relaying steps are separate and distinct. The KB article you've linked to is providing additional details on that last step, relaying to recipient servers, not a queued status for the Mandrill API.

Mandrill API可能会以queued响应的原因有很多，包括您是否添加了附件或是否在单个API调用中发送给大量收件人.

There are a number of reasons the Mandrill API may respond with queued including if you've added attachments or if you're sending to a bunch of recipients in a single API call.

在没有看到实际的API调用的情况下，很难说出为什么您会收到queued响应.但是，如果您使用的是示例消息/发送API调用，则需要删除所有未实际设置的可选参数.例如，该示例具有伪造的附件，并指定了一个子帐户.附件将导致呼叫被异步处理.该子帐户可能不存在，然后将导致呼叫失败.因此，请尝试删除所有这些可选参数.如果没有，请提供您正在编辑的API调用，其中包含已删除的敏感数据(API密钥，实际电子邮件地址).

Without seeing the actual API call that's being made, it's hard to say why you're getting a queued response. But if you're using the sample messages/send API call, you'll want to remove all of the optional parameters that you're not actually setting. For example, the sample has fake attachments, and a subaccount specified. The attachment will cause the call to be processed async. The subaccount probably doesn't exist, and would then cause the call to fail. So if that's the case, try removing all of those optional params. If not, please provide the API call you're making with sensitive data redacted (API key, actual email addresses).