NYCPHP Meetup

[Jake McGraw]

On Sun, Jan 3, 2010 at 4:42 PM, Tim Lieberman <tim_lists at o2group.com> wrote:
> 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.

This is a good suggestion, I'd also recommend logging the email text
(database or text log) and putting some kind of sanity check on the
number of emails your app is sending out at any time.


>
> I think the most important task is to separate the composition of mail from
> the queuing of mail cleanly, so that you retain flexibility.
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>