Mail stalling at 300 everytime

[peta]

deleted

[Darcy]

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

[DW]

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

[peta]

deleted

[DW]

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 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) 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

[peta]

deleted

[peta]

hi dean

I have no idea if this will help you help me!

sensative information has been deleted

cheers

peta

[DW]

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.

Regards

[peta]

deleted

[DW]

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

[peta]

deleted

[peta]

deleted

[peta]

deleted

[DW]

Peta, have you given up?  I'm back now for today (next ~12 hrs).

Regards

[peta]

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