[cullenking]

Another option for bounce handling is to setup a client/server architecture. Continuing with the rails example: since directly spawning a rake task from a postfix hook will slaughter your machine if you get any decent amount of emails due to loading the whole rails stack each time, what I have chosen to do is this:

Postfix pipes the bounced email through command line to a simple client that shoves the body over a socket to a server process which has my full stack running. It then shoves the email into a resque queue to be handled by my normal job queue.

There are many ways to skin this beast, however if you need/want realtime response to emails, maybe to facilitate reply to notifications email to add a comment, and you get any decent volume of traffic, you want your postfix hook to be as fast as possible.

[igor_a]

I think this would be the next step for me. For now our performance isn't a big issue and bounces are processed in background cron job once per several minutes. For now volumes of bounces are not so high as you have, so we are just fine with spawning application. Thanks for commenting.

[cullenking]

Cool - when we send out our newsletters to users, about 70,000 total active emails, we get a solid 1000 bounces in the first hour or so. Bounces decrease each time we newsletter, since we flag users with a bounce_count, and if it reaches 2, or the bounce is a 5xx (permanent error), we don't email them anymore. But, 1000 full stack loads in an hour on our mailserver would crush it!

[igor_a]

Nope, you've get me wrong - we start application every 5 minutes to process mailbox not for every email.

[seanp2k2]

>"Another option for bounce handling is to setup a client/server architecture." funny because e-mail already /is/ client-server architecture, but also server<-> server architecture.

rube goldberg software design :\