NYCPHP Meetup

NYPHP.org

[nycphp-talk] broadcast emailer: is this sane strategy

David Sklar sklar at sklar.com
Mon Aug 16 17:23:40 EDT 2004


> When they click Send -- this is the part that I think merits some thinking
> -- I've decided to do a sort of poor man's fork. That is, I write the
> message body to a temporary file; then I execute myself with an exec()
> call with args $to, $subject, $message_filename and redirect any output to
> /dev/null; then I say "see ya later" to the browser.
> 
> If I'm in CLI mode, I open the message file, to do the db query, loop
> through the result sending mail with PEAR::Mail/sendmail, and log some
> things along the way, then email a report to the user.
> 
> This will be on a shared server. To keep Evil Spammer from getting a hold
> of it, I will be in cgi-wrapped mode with execute permissions set to only
> me. And the web interface will require authentication of course.

If you're able to in your shared server environment and you(r users) can 
stand a few minute delay perhaps after they click "Send" you could do it 
this way: have the web page save info about who gets sent what to the 
db. Then every 3/5/10/whatever minutes, have cron run a process that 
scans the db for messages to be sent, sends them, and then updates the 
db with log info. No submit button delays for the user, you don't have 
to worry about cgi-wrapping, and you still get all the nice log info to use.

David





More information about the talk mailing list