Sending an email to 2400+ users

[henry2]

I'm managing a CMS (PHP-Fusion) based site.

I need to send an email message to all 2400+ currently registered users. (To announce the end of a much-too-long period of maintenance: "The site if finally on the air again!"[smilestopper])

There is a PHP-Fusion add-in that does this, and I've heard it works great -- for small numbers of users

My concern is warnings I've seen that one should avoid sending out large numbers of emails all at once, for
fear of overwhelming downstream processes --specifically, the host email server-- and/or of being declared a spammer. I see advice to send out large mailings in small batches, or to space them out, "throttling" the output.

I've examined the code of the add-in. It appears to transmit messages as fast as it can retrieve the next member address from the database -- no throttling. I've been thinking of hacking the code to include a 1 - 5 second delay between messages. At the same time, I noticed that the code doesn't seem to pay much attention to send errors and may not report them at all.

It is important that I have confidence that messages are actually sent to all users, and that we're not blacklisted.

What's the real story? Should I add a delay? Is it possible sending too many messages too fast would result in unsent messages? How would I know, if the error code in the add-in doesn't tell me?

Bonus question: I apparently have a choice to tell the code to transmit messages using Sendmail, SMTP, or plain "Mail" (I guess that's the default PHP routine.) How do I choose? What's best?

TIA,

Henry

[explorador]

Talk to your hosting company as each one has a different limit. They usually set a limit of X emails per hour. Remember always away from that number on at least 100 emails because contact forms and replies also count. This is only about you sending emails regarding your hosting company.

The other side is how you send the emails and your procedure... meaning anyone could send 50 emails per hour and still be spam. Make clear the guidelines and add the unsubscribe thing.

Other than that, I would recommend phplist as you can configure it to meet the limitations of your hosting provider and keep track of sent, received, bounced and read emails. Or you can write your own code keeping in mind a delay and emails per hour limit. I personally work with sendmail having no problems so far yet.

[henry2]

explorador:

Thanks for your response.

My web host company says "1000 outgoing emails per day". OK, that seems in line with what I've seen elsewhere for similar hosting accounts.

Thanks for suggesting phplist. It looks like a package that offers just what I need. I don't have time to write my own code. If there isn't an existing appropriate add-in for PHP-Fusion, it seems best to start over with a stand-alone package. I need to get this done and move on to more important tasks.

One question about phplist: From the feature list, it appears to implement sophisticated throttling. Do you know how phplist accomplishes batch sends that might last several days? Is it as simple as executing php "sleep(n);" between transmissions? I know php has a limit on the length of time a particular PHP task may run. If time spent in "sleep" doesn't count against that limit, then everything ought to work smoothly.

Thanks,
Henry

[piatkow]

One thing to avoid is partitioning your mailing list and sending several messages in quick succession. That will trigger spam warnings with recipient email providers and may lead to non delivery of messages, even if you are white listed by the recipients.

Hopefully your service provider doesn't limit the number of recipients in a single mailing but it was one of the reasons that caused me to decide to abandon the cheap hosting deal I had taken up in the early days and pay commercial rates for a commercial level of service.

[cmendla]

One thing that is a pain is that if you have users like AOL users, then can hit the "This is spam" button way too fast.

You might want to get a throwaway domain to send the emails from like www.mydomain-mail.com instead of your real domain of 'www.mydomain.com'

Also, there are some emailing services out there that seem to be pretty decent. However, it appears that this is a one time shot for you.

[henry2]

piatkow:

Thanks for your response.

I'm not sure I understand your point about partitioning and quick succession. Do you mean that "partitioning per recipient domain"? If so, yes, I imagine that some domains would scream "spam" upon receiving a bang-bang-bank of emails from the same source.

We ARE limited by our cheap service to 1000 emails a day. Because we do mass mailings so rarely --this is our first time in 3 years-- we don't see this as a problem.

----

cmendia:

We're not too worried about people discarding our messages, and you are correct, this is a one-shot deal for us, and we're self-funded, so we'll need to find a way to struggle through this as best we can with what we have.

Thanks!

Henry

[cmendla]

Henry - It sounds like you might be non profit. If so, some of the bulk emailing services will provide quite a few emails at no charge. It might be worth checking out.

[henry2]

cmendla:

Thanks for the idea!

We have no official status whatsoever, just some guys with a common interest doing a public service we think is important. So we might have a problem convincing a service we deserve special treatment.

It really isn't necessary... we'll figure out something.

Thanks,

Henry

[enigma1]

My opinion is to add a module like down for maintenance where you switch off critical aspects of the site and posting the necessary info during the maintenance period and don't send emails out.

[henry2]

enigma1:

Thanks for your suggestions.

PHPFusion has a maintenance mode, but due to the nature of the security breach it seemed best to completely disable the site except for a single HTML file to which all accesses were directed by .htaccess.

I think the issue of sending emails out versus not sending is one of those that have good reasons in both directions, and could be discussed endlessly.

Thanks,

Henry