NYCPHP Meetup

[Tim Lieberman]

On Jan 3, 2010, at 4:24 PM, matt at atopia.net wrote:
>
> My final option, which I like best, is to create an email queue  
> table that can be populated in many ways. For instant actions, I can  
> populate it with triggers, and for passive emails, I can populate it  
> with a cron. Then, I have a single multi threaded perl script read  
> from the queue and generate the emails, and then maintain the queue.


This seems a bit like overkill.  After all, queueing email for  
delivery is exactly the job that sendmail et al were designed to do.

Your typical email message can be templated as a simple sprintf()- 
style format string, which you can keep in the filesystem, or  
database, or whatever.  There are also plenty of libraries you can use  
for composition, if you prefer (SwiftMailer and Zend_Mail come to mind).

Then you'll want some code to generate email content, and some code to  
pass it off for delivery.

The last bit (passing it off for delivery) should probably be more  
than a call to mail() -- but to start, just write a sensible  
abstraction that wraps mail().  If you later find you need something  
more involved (for instance, you want to use an external SMTP server,  
or you find some real need to write your own queuing system as you  
described), you can swap out the implementation pretty easily.

I think the most important task is to separate the composition of mail  
from the queuing of mail cleanly, so that you retain flexibility.