What is the best way to handle email exceptions in a Rails application using Postmarkapp?

Question

I use Postmark to handle all email in my Rails 3 application using the postmark-rails stone.

From time to time, the user enters a wrong email or nonexistent, which ends with the distribution of hardbounces. Postmark throws Postmark::InvalidMessageError to fix this problem, which my users get as an error not describing 500.

I would like to handle these errors in my flexible interface, and I was wondering what the best strategy would be. I now have several mailers with dozens of them all, so I don’t want to add begin-raise blocks to all of these methods. Adding this start-raise to controllers also doesn't seem like the most elegant solution.

I read about adding a rescue_from block to my ApplicationController , but then I do not know how to handle this in the interface (perhaps by calling a method that uses the errors method?)

I would like to listen to your thoughts before doing plumbing.

Any ideas?

Answer 1

We had to deal with the same issue at Beanstalk. First of all, we turned off "raise_delivery_errors" during the production process, then we implemented an override method for ActionMailer :: Base, which allowed us to change this setting on the fly for specific deliveries. Like this:

 AccountMailer.raise_errors do AccountMailer.deliver_welcome_email(@account) end 

This allowed us to control exactly when we want delivery exceptions to occur and avoid problems when such errors broke what they did not need. Usually there is only one or two places where you want to put this override. In our case, it is the function "Forget password" and "Invite user" when it is important to inform users that their password reset has not been sent by e-mail / invitation. Having delivery exceptions somewhere inside the background work doesn't help anyone.

After that, we added rescue_from to our ApplicationController, which will set flash [: alert] and redirect back.

 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 refers to a controller that uses the Postmark API to re-enable failures. You can find more information about this here:

http://developer.postmarkapp.com/developer-bounces.html

So, after you have all this, your end user can have a pretty good experience with delivery errors, which is not usually considered in web applications. This is similar to Beanstalk:

And not only the user can see that his email has bounced, he can also respond:

Hope this helps.

Ilya Sabanin http://twitter.com/isabanin