我们发送通讯/批量邮件（当然是双重select）。 我们自动删除邮件列表中的硬反弹（邮箱不可用，用户未知，主机未知…）。
但是，由于用户的邮箱已满/用户超过配额，会生成大量“未送达”邮件。 所以电子邮件地址仍然存在，但邮箱已满。
所以最常见的两种情况可能是
a）用户仍在使用他的账户，并在不久的将来删除一些电子邮件，所以他不再超过配额，可以再次收到电子邮件。
b）用户放弃了他的账户（无论出于何种原因），它已经满了，就是这样。 它永远不会再被使用…
所以第一个场景告诉我不要从我们的邮件列表中删除电子邮件地址，第二个场景告诉我应该删除它。 当然，我不知道。
在“我的邮件服务器/ IP地址的声誉”方面，最好的策略是什么？ 我是否应该在接下来的几天/几周内发送邮件，如果邮件还没有正常工作，我应该把它当作b）吗？
我会假设大多数ESP会在一段时间后删除不活动/完整的电子邮件地址，所以他们会变硬反弹吗？ 或者ESP会阻止经常向邮箱发送邮件？
邮件传递延迟时，您的邮件服务器应该重试。 在失败前1,3,6,12和24小时之后，请使用较不积极的重试策略。 您也可以在2天和4天后重试。 如果时事通讯时间敏感，则可能需要更短的重试时间。 在临时失败后，如邮箱已满，您不太可能因重试而受到处罚。 您可能会受到惩罚和积极的重试策略。 我看到服务器每分钟重试几次，直到他们成功。
一些组织会将临时故障传递给专门处理重试的第二台服务器。 如果你这样做，不要继续传递给不同的服务器。
如果您每个月发送一次以上的邮件，请考虑暂时暂停从重试服务器退出的地址。 由于长期的临时故障（交付成功率），处理地址反弹的时间有多长。 考虑放弃几个月来失败的地址。
你将积累死亡地址，因为并非所有的组织都会反弹死亡地址。 考虑发送消息，要求用户每年重新selectjoin。 虽然您可能不想立即放弃用户，但是如果两年或更长时间没有响应，您可能需要放弃。
编辑：Overquota /满邮箱是不是你会得到邮件延期的唯一原因。 您应该按照上面列出的合理时间表重试所有延期。 如果服务器繁忙，服务器将推迟连接。 灰名单将推迟来自未列入白名单的新服务器的消息。 我的服务器还推迟了各种策略检查失败的服务器发送的消息：SPF，rDNS（IP地址），rDNS（如果IP地址不匹配，HELO / EHLO）等。我的灰名单是每个networking块，但是我的策略列表是由服务器完成的。 如果他们没有列入白名单，我的策略列表将适用于Microsoft控制的服务。 否则，我的政策清单一直在捕捉垃圾邮件机器人和垃圾邮件。
RFC1893 – 增强的邮件系统状态码：
3.3 Mailbox Status (...) X.2.2 Mailbox full The mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity. The general semantics implies that the recipient can delete messages to make more space available. This code should be used as a persistent transient failure.