[nycphp-talk] email system for website
Paul A Houle
paul at devonianfarm.com
Mon Jan 4 11:33:28 EST 2010
Matt Juszczak wrote:
> So how about this:
> For things like password recovery, private message notifications,
> welcome emails, etc. that are initiated by the user and are only sent
> to one user, I'll do those in the code base (the negative being I have
> to code that twice, in both front ends).
> For things like thread subscriptions, user subscriptions, alerts,
> etc., which could potentially go to multiple users, I'll do those in
> the background with a cron.
> Does this make sense?
Sure, but I'd also send "high priority" and "low priority" emails
through separate systems (sendmail/postfix/whatever instances.)
It's highly desirable that people get email verification and
password recovery messages as quickly as possible. If these get
delayed, you run into all sorts of wetware problems, such as people
losing their motivation to complete the registration process.
If you've got, say, 250k outbound bulk messages in your queue,
however, the delivery of messages could be delayed by minutes, hours,
or even days.
With two separate mail servers, you can avoid all of these
headaches. Personally, I like running the "high priority" mail server
on the same machine as the web server, and running bulk mail on a
dedicated machine. You can go be a fashionable virtualization-head if
you wish, but I'll warn you that heavily loaded mail servers use
fsync() in a way that interacts very badly with database servers and web
More information about the talk