NYCPHP Meetup

NYPHP.org

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

inforequest sm11szw02 at sneakemail.com
Mon Aug 16 17:37:04 EDT 2004


David Sklar sklar-at-sklar.com |nyphp 04/2004| wrote:

>> 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
>
>
> _______________________________________________
> New York PHP Talk
> Supporting AMP Technology (Apache/MySQL/PHP)
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.newyorkphp.org
>
Your ISP will also appreciate your batching the send requests and 
scheduling the actual sends. You will be able to accommodate all sorts 
of unexpected events, and do your own logging. You may also want to 
build-in some checks along the way, based on constants you can adust as 
you see fit (based on growth, usage patterns, or whatever) - for 
example, at cron time if #pending > X (expected max usage) then pause 
process and alert you, if pending headers are not as expected, pause and 
alert,  (you wrote the header, so your regex should confirm it matches 
at send time), send max Y messages per hour, etc etc. Build in the 
controls now and you will be less sorry later when it gets hijacked or 
your ISP has a system-level emergency, or a user makes a mistake or you 
decide to add restrictions or you go over bandwidth budget or whatever.

Unless absolutely necessary, IMHO best not to just pass control commands 
from user-acceeible script to system level process. Why set up a trust 
when you don't need to?


-=john andrews

-- 
CONSERVATIVE, n. A statesman who is enamored of existing evils, as distinguished from the Liberal, who wishes to replace them with others.Ambrose Bierce




More information about the talk mailing list