Question

I've been trying to figure out the best way to handle incoming email in a rails applications. I realize "best practices" is quite subjective, so I'll start by stating that my primary concerns are scalability and efficiency. This is an issue primarily because my use will involve handling potentially large attachments.

Seems like just yesterday the accepted method was to use ActionMailer to receive the email, but recently I've stumbled across several articles saying this is inefficient as it spawns a new rails instance with each email (horrible at high volumes).

Most recently, this article has been getting my attention: http://jasonseifer.com/2009/04/24/receving-email-with-rails

The post talks about a slimmed down version of the ActionMailer system that isn't forced to spawn an entire rails instance, but the comments talk about several other options like a dedicated mail directory (maildir?) and imap/pop retrieval.

My question is: Does anyone have any thoughts on what the best option would currently be for processing incoming email in a rails application (including attachments)?

Was it helpful?

Solution

I maintain the Fetcher plugin for download email from an IMAP server which I use with cron. I used to use a daemon but that was tough to keep running (even with monit) because Ruby would hang. Cron is OK for my workload but it does spawn a Rails process once a minute.

For processing attachments, check out the MMS2R library. It has a nice interface for getting the files out of an email.

The other approach I've had recommended to me is to fire off an HTTP post for each message received. Then you can scale your web tier to handle it.

Shameless plug: you may want to check out Mike Mondragon and my PeepCode book on receiving email with Ruby.

OTHER TIPS

You could try to use a service like http://cloudmailin.com/

For relaying email from Postfix to your Rails app via HTTP, I just wrote an article on how we're doing it.

It's actually quite simple, but we're also leveraging Postfix's ability to defer email if it can't be relayed. I haven't seen that elsewhere so far. See http://www.doorkeeperhq.com/developer/smtp-to-web-api for details.

in mms2r the MMS2R#default_media just returns the largest video attachment if it exists, or the largest image attachment if it exists, or the largest text attachment if it exists, in that order. MMS2R#default_text returns the largest text/plain attachment if it exists. You can also access any of the attachments directly through mms2r's media hash, e.g. MMS2R#media. MMS2R#media is keyed by mimetype, that value referenced by the key is an array of media of that type. So if there were two jpeg attachements in an email processed by MMS2R, you would access them as an array by keying the media hash with image/jpeg, e.g. MMS2R#media['image/jpeg']

When MMS2R first processes an email, any attachment it finds is decoded and stored in an array of media of that type. As I said, that array is then keyed by mimetype in the MMS2R#media hash.

Buy the book, I need to pay my mortgage PeepCode book on receiving email with Ruby.

I recently wrote a daemon which receives mail from Postfix using LMTP (it uses EventMachine and is pretty fast and robust) and saves it to MongoDB. In that sense it eliminates the middle man (IMAP server + IMAP client). That approach gives pretty much limitless scalability and redundancy. Other backends support (MySQL, Redis, etc.) can be added in practically no time.

received

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top