NP Subscriber 2.0 Email Block Issue

[Glenn]

I wrote to this forum several months ago with what, at the time, seemed like a small isolated issue with Subscriber not working with my own email address (ie. would not mail me a confirmation email). However, since that time, I have 70 confirmed subscribers and about 70 unconfirmed subscribers, and I suspect that many if not all of those unconfirmed are simply not getting the confirmation email.

Aside from asking generally if ANYONE can offer any suggestions as to why Subscriber is selectively chosing who and who not to send confirming email, is there any way I can go behind the scenes to view the email addresses of those awaiting confirmation??? If maybe I can see some commonality or pattern to them, it might help with figuring out what the problem is..Otherwise, I am just scratching my head..Thanks

[Admin-BS]

I know that on my general mailing list, I have slightly more unconfirmed addresses than I have confirmed. It is possible that a number of these were people that just wanted to see the confirmation process for the script, but a majority are probably invalid addresses that somebody just entered. They are valid enough to pass the basic name@some.thing filter, but still aren't real.

It doesn't make any sense to me why anything specific to the script would cause problems with certain addresses. You can see for yourself what addresses aren't confirmed to see if there is actually any pattern. All of this information is stored in confirm.txt in the same directory as subscriber.cgi.

I hope this might shed some light on the situation.

[Glenn]

I would absolutely agree with you on this one--it doesn't make sense that the script is the culprit--I will try to take a look at confirm.txt--As I mentioned, my own (and my wife's) email addresses are being blocked, as are others I know of with a "xxx@verizon.net email address. If this relates to Verizon, or to the web host godaddy, I just don't know. I do know that I registered that very email address on npscripts.com, and received the confirmation email right away (and therefore perhaps its more likely something with godaddy)--so, I am extremely frustrated by this one..I do really appreciate you candid and quick response in trying to help me..Thank you so much..and if you (or anyone out there) can think of anything that may pin point this issue, I would be forever grateful.

[Admin-BS]

Yes... It does seem to be something related to the host. On this site I, obviously, use the Pro version of Subscriber. But, for all intents and purposes, the basic subscription process is the same as the free version, especially all of the mailing routines. Plus, add on since it works seemingly some of the time, it does seem to be related to something with your host apparently not wanting to send mail to certain domains.

[Glenn]

OK-bear with me if you could just a little more. I went to my ftp client into the directory structure, and found no files entitled confirm.txt., or banned.txt, or even var.txt. --and yet, somewhere, at least some of this information is being stored because I can access it or statistics about it in the admin panel..Is this not really odd...??

Because of this, it prompts another question. I do know that godaddy will not allow certain operations within cgi directory--that's why I had to create the subscribers.txt file in a directory (data) outside the cgi directory. Should I therefore direct the cgi script to the data directory (and perhaps create the appropriate txt file within it--and if so, on line such as:

open(FILE,"+>confirm.txt");

..should I change it to: open(FILE,"+>/home/content/b/o/u/bousquets/html/data/confirm.txt");

..and likewise for banned.txt and vars.txt??? This may or may not have anything to do with my issue, but I can't help but think there may be some connection...Unfortunately, without a visible confirm.txt file, I have no way of viewing the email addresses...Anyway, just a thought. Thanks again for everything...

[Admin-BS]

I suppose it couldn't hurt to try that. Just make sure you are replacing only the filename, and not any of the symbols in front of it.

I glanced around some results on Google, and it seems that GoDaddy is known to have some problems when it comes to paths within CGI scripts. Seems that they have all scripts run in a wrapper that has been known to mangle paths.

http://www.google.com/search?q=godaddy+sbox

A couple of the results to that search are where I got this information. There seems to be some common complaining about GoDaddy's CGI capabilities in general, and the path problems in particular.

[Glenn]

OK--Well, I tried changing the path to confirm.txt to a place outside cgi directory, and the script indeed wrote to it..of course, the kicker is that I don't have the 90 other emails that were in limbo in the other confirm.txt, which must exist in some phantom form in the sbox environment==cause I can't find it anywhere...which leads to leaving godaddy and heading to bluehost...HOWEVER (and this was apparently another problem that godaddy presented w/o me knowing), bluehost can process 500 emails an hour (godaddy was I believe 200)--anything more, and subscribers get dumped and the script fails. I am told I need to have a way to tell the script to mail less than 500 per hour (I currently have 958--manyof which will bounce because I brought them in from a prior script-subscribeMe lite.) Anyone know how I can get NPSubscriber to work...I miss the old days when nobody needed to worry about viruses, worms, etc. and all you needed was a simple script, an apache server, and you could fire off all the emails you wanted...As alway, any assistance would be greatly appreciated.

PS=Am I crazy, or am I really the only one who has a mailing list of 950 people, and simply want to send them all a special offer now and then..

[Admin-BS]

First off, sorry for the rather long delay in answering this, but I've been pretty occupied the past couple of days.

The only solution to this I can think of right now would be to put in a pause between each mail sent out. That is, the script sends out an email to the first subscriber, pauses for a certain amount of time, sends out the second, pauses, and continues until all have been sent.

The simple thing would be just pause for 1 second after each one, because this would mean that the most emails you would send out in an hour would be 3600. But, this is well over your limit, so pausing for about 8 seconds should work better (that's an average of 7.5 emails a minute, so 450 in an hour).

To implement this, open up subscriber.cgi and search for "sub send" (this is the message sending function). Go down through the lines in that function, and find "close (MAIL);" followed by a }. Between those two lines, insert "sleep 8;" so that your code looks like:

Code: Select all

close (MAIL);
sleep 8;
}

This should cause it to pause for a second after each sendmail call. I haven't fully tested this, but in a quick test locally, it seemed to work. This will more than likely cause a timeout on your browser, but the send will probably still be running on the server.

[Savoryentree]

I'm testing out NP Subscriber version 2.0. I'm having a similar problem where the stats screen says I have 1 subscriber and 3 unconfirmed (I'm using 4 of my own verious e-mail addresses to test). The confirmations aren't going to my primary e-mail ISP. Do some ISPs block anything from certain host sites? Since I'm not mass mailing (yet), I want to work this out so I don't "lose" anybody.
PS - If I turn confirmation off, I just don't get any test messages I send out to myself!

[Admin-BS]

Have you been able to send out any mail at all with the script? Or is it again just seemingly being spotty?

It is technically possible that, if you're on shared hosting, your IP is on a spam blacklist because of somebody else that shares hosting with you. You can check this at a site like http://rbls.org.

[Glenn]

First off-thanks a ton for the suggestion of 2/6 Admin-BS. I really appreciate your support on this issue. Unfortunately, putting that delay in yielded poor results. I received an email at my lycos account, but not at my work address. So, I would guess the script hung somewhere in the process. I think batching might be the only solution and, as many web hosts are getting extreme heat about spam and infectious traffic, this is likely going to be a widespread issue.

As for Savoryentree's entry, as much as I can empathize with your plight, I at least don't feel alone or crazy. I am going to switch web hosts and see if the new environment makes a difference. If you come across anything that can definitively explain why this is happening, please share it--I will do likewise. Thanks all.

[Jeff]

I am still having the problem of having only some e-mail addresses receiving my notifications. I occasionally run tests, swapping out the subscribers.txt for a temporary one which contains 4 addresses of those who work on my site (and which I know I can send e-mail to from my host). One person in the group gets the test e-mail, no one else does!

Several customers have complained that they are not receiving their newsletters. I'm not sure if it's a sleep issue or the "\@" issue. Or my host - Netfirms.

Any other thoughts would be appreciated, thanks!

http://www.savoryentree.com

[Admin-BS]

This is apparently another issue where I honestly don't know what the problem is exactly. Are you saying that you also have the issue where apparently the outgoing email address is being formatted as add\@ress in the email?