[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