Should ActionMailer raise_delivery_errors be true or false in production?

If true, it will send an error message to the user. If false delivery errors are not noticed.

What is the recommended way to handle this?

+4
source share
4 answers

Most likely, you will encounter delivery errors at some point in the life cycle of the email program.

I would recommend either

  • raise_delivery_errors = true

    Catch a bug and provide some feedback to the user

  • raise_delivery_errors = false # Don't catch anything, just ignore the reject

Depending on which mail program selects one of the above.

+3
source

We just put the application into production, and our ISP mail server often returns "451 spool busy" errors when trying to send mail.

Not a single answer was good for us: if we return an error to the user, we pass them a problem with the infrastructure; if we do not, they will not receive their invitation / confirmation / notification / everything, and no one knows why.

Instead, we decided to configure delayed_job and always send mail through it; it starts automatically, and we can see (from the table of the job queue in the database) if messages accumulate. (It was very easy to configure - the hardest part was that the workflow worked, and it was a simple addition to our Monit configuration.)

(Bonus: here is the initializer that I wrote to postpone mail in production, but still send it directly during development and testing: http://gist.github.com/178125 )

+6
source

You should at least tell the user (and yourself) that something went wrong, otherwise they (and you) will not understand whether the delivery occurred, or the mail just got stuck in the spam folder.

If you don’t get a lot of errors, you can just let 500 errors go through, although this can be a bit unpleasant for the user. It is better to catch and register an exception and allow the user to retry.

0
source

If you run postfix on the local server, if the email can be sent successfully to the postfix (which should always happen), then there will be no problem.

0
source

All Articles