views:

169

answers:

3

If true it will send an error message to the user. If false delivery errors wont be noticed.

What's the recommended way to handle this?

A: 

Chances are you are going to run into delivery errors at some point in the mailer's lifecycle.

I would recommend either

  • raise_delivery_errors = true # Catch the error, and provide some sort of feedback to the user
  • raise_delivery_errors = false # Don't catch anything, just ignore the failure

Depending on what your mailer does choose one of the above.

Ryan Neufeld
A: 

You should at least let the user (and yourself) know that something went wrong, otherwise they (and you) will have no idea whether the delivery failed or the mail was just stuck in a spam folder.

If you don't get many errors, you can just let the 500 error go through, although that can be a bit unpleasant for the user. Better is to catch & log the exception and let the user retry.

klochner
+1  A: 

We just put an app in production, and our ISP's mail server frequently returns "451 spool busy" errors when we try to send mail.

Neither answer was good for us: if we return an error to the user, we're passing on our infrastructure problem to them; if we don't, they don't get their invitation/confirmation/notification/whatever, and no one knows why.

Instead, we decided to set up delayed_job, and always send mail through it; it retries automatically, and we can see (from the job queue table in the database) if messages are piling up. (It was really simple to set up, too - the hardest part was making sure that the worker thread was running, and that was a simple addition to our Monit configuration.)

(Bonus: here's an initializer I wrote to delay mail in production, but still send it directly in development and test: http://gist.github.com/178125)

Bryan Stearns