>I know a lot has been discussed in this topic, but I still don't find any >solution.
You keep ruling out the solutions you do find, which is not quite the same... :-) >What I want to do is send a lot of mails triggered from a web page using >php. Bad Idea. PHP was never designed to send a "lot" of email. Use mailing list software for that. If you persist in using a hammer as a screw driver, you're going to continue to be disappointed. >I've found diferent solutions but all of them has some problem: >1) using set_time_limit() to allow the script to run longer while sending >e-mails, my prefered solution but I won't let someone waiting a lot of time >with a loading browser because they'll stop, reload, and at best, just not >like it. So, I would like to launch a background process changing the >set_time_limit() in that process (if needed), the problem is that I wasn't >able to run a background process in PHP, were you ? I know I could use at >(atd) to run a background process but in my shared server, there's no at >available. PHP cannot fork. You could maybe write a shell script to do the fork, if your host lets you use http://php.net/exec >2) Queuing instead of sending. I've seen that some people improved the >'sending' (well, it's not sending anymore) by queuin only. Then some people >tell me that sendmails always queue and I'm a bit confused. Does sendmail >queue or sends mails ? sendmail can queue email or send email immediately, and you can affect that in php.ini, but you don't have access to that (below) so this question is kinda pointless anyway... >if it queue, why is it send imediatly if the queue >is procesed once an hour or so ? I don't care if my mails are procesed once It all depends what your ISP felt like putting into php.ini for the sendmail arguments about how quickly it should process the message. >an hour for this mails, I don't need them to be sent imediatly. I can't >change sendmail configuration (since it's a shared server) and I wouldn't >want to because I have other 'mail cases' when I want to send the mails >imediatly. I can't change the way PHP calls sendmail (again, it's a shared >server) but I'm using PHPMailer and I can change the way PHPMailer uses >sendmail, will `/usr/sbin/sendmail -O DeliveryMode=q` queue the mails I'm >sending ? If that's actually letting you call sendmail, you're on the right track. I believe there are more flags you need when you invoke sendmail to make it queue, but you can read "man sendmail" as easily as I can to figure that out... -i and -t seem to be in my brain as "good" things to use with PHP for whatever reason. YMMV. But you are *STILL* firing up sendmail for every *SINGLE* email. That's rather like starting up your email client on your desktop. Making and sending a new email. And then *quitting* and *restarting* for EVERY SINGLE EMAIL. You ain't gonna get mass quantities of email piped through if you fire up sendmail every single email that goes out... >3) Someone told me to do it using cron, do you have any idea of how to do it >with cron ? cron is just a higher-level approach to atd, and if you've ruled out atd, you've ruled out cron probably. To be 100% sure, can you log in with SSH (is any ISP still using telnet?) and do: crontab -l If you can, you can probably read "man 5 crontab" and do "crontab -e" to set up a cron job. If you can't do SSH and "crontab -l" you can't use cron, almost for sure. But using "cron" will spread the emails out, but still not be sending them very efficiently... It will "work" up to a point and increase the volume you can handle, but it's still damned expensive on the server resources to fire up sendmail and quit it for *EACH* email... If you really mean "bulk" email, you *should* be using an SMTP server and talking to it directly to open up one (1) connection to SMTP, and spew out a *LOT* of emails through it, and then closing that one connection. Contrast that with firing up sendmail every email, and it's a no-brainer. Problem is, your ISP *probably* does not have SMTP set up as something you can directly "talk" to easily, in order to make it harder for spammers to operate... I *might* be possible, but you'll never know until you try. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
