ListMailPRO Email Marketing Software Forums
ListMailPRO Email Marketing Software Forums => General Help & How-To => Topic started by: peta on November 22, 2005, 04:31:26 pm
-
deleted
-
I have the same problem.
I went to send out 1775 emails and it stopped sending with 1475 messages left. Now I am not sure how to get it restarted without sending out duplicates!
Thank you
-
Greetings! :)
How ever, having tested my email to a very small number of internal users I am trying to send out the list, which is about 57000 long.
It keeps stopping at exactly 300 mails, no matter if I use smtp or PHP.
There are a few things this could be but from the sounds of it, since it happens with both SMTP and PHP mail, I suspect your server could have the ever-feared hard limit on PHP script execution time. This is a rare setting that will prevent you from emailing large lists wtih ListMail.
Did your other script use PHP? If it did, and since this is such a rare setting, this may not be the case. There are a few other things to look at. One, PHP mail is prone to problems with large list email as it takes up excessive server resources and processes. When a limit is reached the server could automatically 'kill' the script. Two, SMTP can have limits on the number of messages sent per connection. Try setting your "Reconnect to SMTP every X emails" setting to "250". While this is lower than normal it will help us determine if this is the problem.
I went to send out 1775 emails and it stopped sending with 1475 messages left. Now I am not sure how to get it restarted without sending out duplicates!
If a mailing stalls and you re-login to ListMail you should see a header within the program stating that an email is in queue. Browse around ListMail, or refresh the page, to make sure that the # of messages remaining are not still counting down. If they aren't, the mailing has probably stalled completely and should be resumed. Do this by hitting "Resume" at the far right of the email queue header next to the queue you would like to resume.
To avoid duplicates, do not hit Refresh on the send mail screen and do not hit Resume before you have confirmed the messages are not still counting down (sending).
Regards
-
deleted
-
I have tried setting Reconnect to SMTP every X emails" setting to "250". This made no difference. I also recalibrated the counter so I can see every ten emails, and in fact it sends out 310.
Good job :) You seem to know a fair amount about how it all works.
After making sure the attach folder (http://listmailpro.com/help/attach.html) is configured correctly, try enabling the "SMTP Debug Log" on the Send Email page. When the mailing fails, you can check the log by clicking the link or by manually obtaining it from the ListMail/attach folder. If the SMTP server doesn't report any errors the problem is probably due to script timeout.
Also, as a matter of interest I have set up the bounce.cgi, which has been tested using the test button, and all works fine.... how ever I have found a huge number of bounce backs filling up the bounce email box!! Is this to be expected? (not the bounce backs, but the non-deletion of them Smile )
bounce.cgi cannot work at the same address as an existing mailbox. To properly configure, test, and use bounce.cgi, a mailbox with the same email address as an alias pointing to bounce.cgi should not exist. If a test reported success, I would think that you have chosen the mailbox method of bounce processing as opposed to the bounce.cgi option. If email to an address is sent to bounce.cgi (via an email alias (http://listmailpro.com/help/cgi.html)) there will be no messages left anywhere.
DIT Having just sent out 310 emails, how on earth can that generate over 11 megabytes of bounce backs?? Is it possible that the sending mail page is not updating after 310 mails, but the full 57000 are being sent out? The resume suggests that there is still for example 50,000 mails left to send... I am puzzled.
This IS possible. When Stop is pressed in the browser the script might run for an additional minute or two before finally stopping. I advise opening a 2nd ListMail browser window when sending. From the 2nd login you can refresh a standard page or browse around the program to check the remaining messages in queue, shown in the header that automatically appears. If the number remaining is still decreasing it is not a good time to Resume your mailing. I will be implementing some protections against resuming too soon in next update.
In the php.ini file on the server I have set the script time to 24hours (in seconds)... So I am hoping that this is not the problem.
Even with a setting in here the ListMail PHP script should be able to set the maximum execution time higher. I recommend disabling PHP "safe_mode" for your domain - it's likely to fix this. :)
Regards
-
deleted
-
hi dean
I have no idea if this will help you help me!
sensative information has been deleted
cheers
peta
-
Your config looks ok. Safe mode is off for the entire server. If you recently modified that value, you may need to restart the web service. "service httpd restart". At this point I do not know what else I can suggest as this is not something I have experienced before. Are you in full control of this server? If so, I can login as administrator and do some troubleshooting such as watching all relevant log files while sending a test email. You can securely submit your information here (http://listmailpro.com/support?t=other).
Regards
-
deleted
-
I was hoping we could see the apache access_log and/or error_log when the ListMail script fails.
You reported no funny messages in ListMail's SMTP logs. What about at the very end of the log file, does it appear ListMail stopped part way through sending a single message, or just after (successfully) sending the last message?
What is your SMTP Reconnect set at? Maybe it should be higher - we could be reaching a connection limit (though, ListMail closes each connection before opening a new one..) Try a Reconnect every 2500 emails and see if it runs longer than when set lower.
Sounds like some of your subscribers won't be happy.. :( I guess this was an urgent email. With access to ListMail I can help you out with a test list of several thousand addresses all pointing to my own server for testing.
If you don't want to give me administrator access, there is a fair amount of troubleshooting I can do with ListMail and FTP access.
Regards
-
deleted
-
deleted
-
deleted
-
Peta, have you given up? I'm back now for today (next ~12 hrs).
Regards
-
Hi Dean.... sorry to have kinda dropped out .... started getting some real hassel from a disgruntled recipient on our completely legal optin email list. Thought it best to duck behind the parapit while the problem was sorted out. I still think that this mail package is superb, but I didn't want to leave a trail for a time waster to enjoy, also I realised that I has posted info that maybe in retrospect was unprofessional of me.
I'm still very keen indeed to get the package sorted out, but I couldn't leave the door open for ever on the off chance that you would have time to have a look.
I think I can conclusively say that the problem is not with the server. It is a bug in the programme. or alternatively the installation instructions maybe ambiguos.
If you can guarentee that you can sort the problem (given that the server scipts don't time out, and that there is not restriction on the number of emails sent, this I have proved to myself beyond a reaosnable doubt) then I am sure I can pursaude my boss to pay the support fee.
But it has to be door open, door closed.... i.e. a proper time frame that we adhere to. At the end of the day I'm pretty sure that all we'll be doing is helping you debug this version of your excellent application, so paying a fee for that will be.. er how can I put it... unfair. But, I woudl like to have it sorted, rather than ask for a refund.
Our server hosts 500 domains, so it's not a some small fry eneterprise that can afford to experiement with security... I am sure you undersatand.
I thank you for your attention, and look forward to your reply.... maybe we should continue this via PM.
all the best
peta
-
Hi Peta,
Glad to hear you're still willing to give ListMail a chance. I understand that the issue you're having has affected you in a very frustrating manner.
You can email me at dean@listmailpro.com if you would prefer. I don't expect you to pay for assistance with this which is why I referred you to the "Other" type Tech Support request, which is free.
I understand your position regarding security and I normally would not need to access your server directly with administrator access.
To set you a little more at ease (I hope) I have done well over 250 installs with varying degrees of access (including admin/root access dozens of times). I also have 3 of my own dedicated servers running hosting for a select few clients (and therefore have no need to 'use' your server in any way). I am a firm believer in legitimate business being just as good (or better) than illegitimate business. My ListMailPRO business is my main source of income right now and I would never do anything to jeopardize my reputation. Please be assured that I will never touch anything unrelated to ListMailPRO. I may, however, notify you of any problems, hack attempts, etc. I stumble across in the logs while I'm investigating the ListMail issue.
If you would prefer, I can start by using FTP access to the domain along with ListMail access to do some testing. This way you would not be putting your entire server at "risk" (no offense taken - the only true security is to never give out your info). With just client access to the domain running ListMail I could use a simple test script to try to determine if the time limit in place on the server can be overridden. WIth this access I can also check for ListMail -> SMTP errors.
I understand that it would appear that ListMailPRO is the problem here. This is, however, out of a very large number of installations a very rare issue. The only thing ListMail can do is try to set the PHP limit to 0 (Unlimited). It will then be up to the server settings to ensure that the script runs as necessary. Please securely submit FTP and ListMail info here (https://www.listmailpro.com/members/?typ=other) so that I can get started ASAP.
The suggestion I made before (safe mode off) has solved the 30 second timeout issue in the majority of cases. The only time it might not help is if the server admin has placed a certain 'maximum running time' limit with an 'auto-kill' feature on the server to protect against runaway scripts. This is not uncommon on hosts running a very large number of sites/clients per server. Can you ask your technical support staff whether or not there is a hard limit on the amount of time a PHP script can run?
Regards
-
Hi Dean
thanks for your kind and exhaustive reply, its a rather late at night here, so I'll not go into details, but believe me I'm very much looking forward to your input and nodoubt resolution of the challenge we have.
thanks again for your kind and helpful support. I'll be in touch in the next day or so.
best wishes
peta