Jason Seifer - Latest Comments in Receiving Email with Rails

Re: Receiving Email with Rails

phegaro — Wed, 13 Jan 2010 13:04:32 -0000

After looking at this we went with a model where we had a daemon that would just sit there and poll frequently to an IMAP server. We are using a google apps account to do this and it makes this much easier. You dont have to run your own mail server, you can just poll as frequent or non frequent as you want and if you really want instant you can turn on IMAP IDLE support and then you can get the mail as they come in. Since there is only one daemon running we no longer have this problem.

Re: Receiving Email with Rails

Me — Wed, 13 Jan 2010 12:55:33 -0000

Is this true?

Re: Receiving Email with Rails

Jose — Mon, 09 Nov 2009 13:42:14 -0000

I have several webapps needing this service hosted on the same server (each app receiving mail sent to a different domain).

I'm thinking of creating a separate Rails project just to do the mail receiving. The domain info would be stored in the model so the webapps can separate their mail from each other.

Does this sound reasonable?

Re: Receiving Email with Rails

Stevie Graham — Thu, 05 Nov 2009 11:43:45 -0000

Great article. Only I would use an unless statement, rather than if and a boolean negation operator. more ruby like and more readable IMHO.

i.e.,

unless mail.to.nil?
BEANSTALK = Beanstalk::Pool.new(['127.0.0.1:11300'])
…
end

Re: Receiving Email with Rails

phegaro — Fri, 25 Sep 2009 14:37:24 -0000

I thought the mail_receiver.rb file will be lauched for each email received and then will stick the email in the queue. I realize that it does not do much but it is creating a ruby process and letting it exit for each email. Is that a high overhead on a system?

Re: Receiving Email with Rails

Jason Seifer — Fri, 25 Sep 2009 07:43:57 -0000

Doing it this way specifically avoids spinning up a new process each time as you're running it as a daemon. You wind up having one process running constantly that processes each one as they come in.

Re: Receiving Email with Rails

phegaro — Fri, 25 Sep 2009 03:40:10 -0000

Some of the other information that i have read talks about how doing it this way means that a new ruby process is started and killed for each email that comes into the system. According to the math above that would mean that you have about 833 processes being created/deleted per minute on the server. Are you guys having issues with that model?

It seems the polling model avoids this but not sure if the tradeoff for less processes is worth the loss in responsiveness and can we just poll more often to get rid of the issue? Like once ever minute?

Re: Receiving Email with Rails

morgancurrie — Fri, 24 Apr 2009 03:36:06 -0000

how do you guys deal with stripping the quoted original message out of the reply?
in one of my apps users can reply to message notifications by e-mail and the mail processor parses out their comments and posts them in the thread. we've taken to writing a new regexp every time we come across a new e-mail client and falling back on cutting everything after something like "=== Post your comments above this line ===". any better ideas?

Re: Receiving Email with Rails

technoweenie — Fri, 24 Apr 2009 03:33:55 -0000

Piping emails to a ruby process can present some scaling issues. Each email is basically another ruby process that loads rubygems, tmail, mms2r, etc. It's probably better to just have postfix dump emails to a maildir and have tmail read them in a little ruby daemon: http://tmail.rubyforge.org/... . I handled all of our email processing fine with ruby pipes for awhile. But when I moved to our current host, they were quick to suggest using a maildir.

I didn't know about mms2r, but I'll take a look at that. I think I parse the mail parts manually with tmail right now, blah :)

Re: Receiving Email with Rails

giles bowkett — Fri, 24 Apr 2009 03:14:59 -0000

hey jason - also check out Astrotrain on github. it receives e-mail and issues xmpp or http in response. blatant plug for my employer but it's what enables Tender to turn e-mails into support discussions. like how Tripit turns e-mails into itineraries automagically.