我们不得不在 Beanstalk 中处理同样的问题。首先,我们在生产中关闭了“raise_delivery_errors”,然后我们为 ActionMailer::Base 实现了一个覆盖方法,它允许我们为特定的交付动态更改该设置。像这样:
AccountMailer.raise_errors do
AccountMailer.deliver_welcome_email(@account)
end
这使我们能够控制我们希望何时出现交付异常,并在此类错误破坏了它们不应该破坏的东西时避免出现问题。通常只有一两个地方需要覆盖。在我们的例子中,它是忘记密码和邀请用户功能,当让用户知道他们的密码重置电子邮件/邀请未送达至关重要时。在后台运行的作业中某处出现交付异常对任何人都没有帮助。
完成之后,我们向 ApplicationController 添加了一个 rescue_from 来设置 flash[:alert] 并重定向回来。
def postmark_delivery_error(exception)
if address = derive_email_from_postmark_exception(exception)
link = %Q[<a href="#{ reactivate_email_bounce_path(address) }">reactivating</a>]
msg = "We could not deliver a recent message to “#{ address }”. The email was disabled due to a hard bounce or a spam complaint. You can try #{ link } it and try again."
else
msg = "We could not deliver a recent message. The email was disabled due to a hard bounce or a spam complaint. Please contact support."
end
flash[:alert] = msg
redirect_to :back
end
reactivate_email_bounce_path 链接到使用 Postmark API 重新激活退回的控制器。您可以在此处找到有关它的更多详细信息:
http://developer.postmarkapp.com/developer-bounces.html
因此,在您完成所有这些之后,您的最终用户可以在处理交付错误时获得非常好的体验,而这在 Web 应用程序中通常不会解决。在 Beanstalk 中看起来像这样:
不仅用户可以看到他的电子邮件被退回,他还可以自己做出反应:
希望这可以帮助。
伊利亚·萨巴宁
http://twitter.com/isabanin