[nycphp-talk] email system for website

Edward Potter edwardpotter at
Mon Jan 4 00:31:41 EST 2010

as above.

think 2015.  outsource everything. google sounds fine to me. use the cloud.
php email is solid and simple enough to configure to do a myriad of things.

store everything in a db. don't be too fussy about the design. you're just
crunching emails.

learn iPhone/Android with all that free time u have now.


On Sun, Jan 3, 2010 at 7:31 PM, Gary Mort <garyamort at> wrote:

> On Sun, Jan 3, 2010 at 4:42 PM, Tim Lieberman <tim_lists at>wrote:
>> 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.
> You can use both PHPMail and SwiftMail to do user authenticated delivery of
> email.
> I highly recommend using Google Apps for business for email rather than
> hoping your web service provider is keeping up on keeping their servers out
> of blacklists.  The downside of Google Apps though is you do have an  hourly
> throttle of, I believe, 500 emails an account for free service, and 2000 for
> a paid account.
> As such, doing your own internal queuing process can be useful to stay
> within the throttle.
> Also use subdomains to identify mail and avoid blacklists.  IE send your
> automated anouncements from, send your reminders from
>, if you ever let users forward stuff to each other,
> stick that on it's own domain, or if you give them
> email accounts,
> Reserve for internal use only, person to person
> communication.
> This way if any one system is subverted for a spammers purpose, your other
> email continues to flow.
> The free account is more than sufficient for a site that has yet to take
> off commercially, by the time you hit the limits you should have a plan in
> place that makes it worthwhile to spend $50/year for the business account.
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List

IM/iChat: ejpusa
Follow me:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the talk mailing list