Beanstalk でも同じ問題に対処しなければなりませんでした。まず、本番環境で「raise_delivery_errors」をオフにしてから、ActionMailer::Base のオーバーライド メソッドを実装しました。これにより、特定の配信の設定をその場で変更できるようになりました。このような:
AccountMailer.raise_errors do
AccountMailer.deliver_welcome_email(@account)
end
これにより、配信の例外を表示する正確なタイミングを制御し、そのようなエラーが発生してはならないものを壊している場合の問題を回避することができました。通常、そのオーバーライドを配置したい場所は 1 つまたは 2 つだけです。私たちの場合、パスワードのリセットの電子メール/招待が配信されなかったことをユーザーに知らせることが重要な場合は、パスワードを忘れた場合とユーザーを招待する機能です。バックグラウンドで実行されているジョブ内のどこかに配信の例外があることは、誰の助けにもなりません。
それが整った後、flash[:alert] を設定してリダイレクトする ApplicationController に、rescue_from を追加しました。
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