[nycphp-talk] email system for website

Paul A Houle paul at
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 mailing list