I am working on a business marketing website. The criteria is that we have to send around 80,000 (say) newsletters per day to different email addresses. But my hosting company allowed me to send only 10,000 (say) emails from one IP per day. So to solve this issue my client provided me with 8 different IPs. I am having following questions:
I don't know how to send each and every newsletter from different IPs, means first from first IP, second from second IP and so on?
As I'm a PHP developer and not an expert at server end, can I accomplish this through my PHP script only or do I have to write a shell script to run at my server?
Is there any algorithm to accomplish such type of problem?
Had similiar problem couple years ago. I resosolved it in simple way. Create table in SQL, or create a class and serialize it. Class or SQL have to contain mails addresses (if You have some kind of volatile content then also mail content), do a class to send mail in certain order, and do object of this class on each ip. That depends what kind of config You have on server. I had a easy way cause all of IPs had its own folder with content, so I just put there code to do object, and just redirected couple of times the website, since it had to be done by web. If You have can have it by CLI there is pretty chance that You could do it by include or similar.
This way is pretty lame, I know it, but didn't want to do something more sophisticated at that time. Later on I wrote a class to manage mail connections via SMTP, so I could chose with mail from witch account would be send. That is better way, but not all servers could support it.
Another way is to do a cron job and do baskets of mail to send portions over the time. (this way was most common on servers that I was repairing).
Another way is to do a bouncing effect on servers with IP. Probably You could do also some shell scripting and invoke it via php script.
Well, I think that there are better ways, but it really depends on server config.
PS. Forgotten to mention, that code can be invoked by AJAX.
Related
In relation to an earlier question I'm looking for an alternative way to send an order from my website to the division in my company that processes the order.
Currently I use PHP mail(), but frequently this gives problems. Big delays occur. Are there alternatives to PHP mail() that pushes the order to my company? So I prefer not to poll the website.
mail() is fine for simple stuff, but often you want a more robust library that has solved the mail problem in PHP.
My personal choice is Swift Mailer.
Also from reading your other question, could this be of benefit
Your app writes the order email to database, in a queue.
You have a Cron running, that sends say 30 emails every 10 minutes.
It then removes the last sent 30, ready to be processed again in 10 minutes.
The advantage is that when you have a queue of emails to be sent out, they can be processed in batches, and also you will have a copy in the database if the mail fails. It will be easier to query the database then chase up the mailed that was undelivered (or delivered late).
Currently I use PHP mail(), but frequently this gives problems.
I'll bet you a lot of money it does NOT frequently give problems.
I have never come across problems in PHP's mail function. I have seen problems with bad php.ini settings for mail, and a host of problems with the programs which process mail after it has left PHP. Your use of the word "frequently" implies that it works some of the time, so, in the absence of frequent updates to php.ini, the problems are all on your mail handling infrastructure.
Indeed - I would recommend you go have a look at the PHP bug list - there will be lots of reports about problems getting mail from scripts to users inboxes - but none of them will be due to a failure of the PHP code.
So if the problem is elsewhere, using a replacement SMTP client will have no effect whatsoever (unless you configure it to bypass the bad MTA).
Understanding how email works, and why it fails, is far from trivial. When you add in to the mix, the lengths some people go to (usually undocumented) to prevent spam, it starts to become very complicated. Even if you had given precise details of your infrastructure and configuration, it would be difficult to even hazard a guess as to where why and how it is failing.
Certainly, you need to start by looking at your email logs and headers and checking your MTA and MUA configurations to start to resolve the problem.
C.
There is inherent insecurity in using SMTP to transmit orders. Not to mention the delays caused by all the routing, spam-checking, etc. that is caused by using the mail server. Are you sure you need to email the order? Wouldn't something more along the lines of a server-to-server HTTP transfer, perhaps XML-based, be a better option?
You could use a second server in the processing division that would receive the order from your web server via a protected (firewalled) connection that would process the order, in this case making it available to the person in the order processing division who reads and deals with the order.
My company has a website built with PHP. We use the built-in PHP email functionality to send thousands of emails to subscribers on a daily basis.
This is a terrible idea. It chokes out our server, and takes hours to complete the whole batch.
Now I've looked at mass mailing services like MailChimp (which would replace our current system of sending the same email to many people), but what I think I'd really like to do is to set up a somewhat-sophisticated notification system.
Rather than send a mass email to each person each time something important happens, I'd like clients to be able to customize the rate and content of the emails that they receive.
Even using this new idea, we're talking about A LOT of emails being sent.
So my question is very specific: I have a rough idea of how to build the system internally, but what is the best way to send out all of these emails?
Bullet points to consider:
Sometimes emails' contents are identical across recipients, but many of them will be customized per-user (they choose what they get notified about, and sometimes it is aggregated).
I want a system that is not going to choke the server, and will complete in a decent amount of time. I don't mind going with a third-party service (even a paid one) if that is what it is going to take.
The system should hook into PHP easily, or the API or whatever should be relatively easy for me to call from your typical web server.
We have a dedicated server and full control over it (so we can install apps, services, whatever).
Any kind of detailed tracking information (opens, clicks, etc) is a huge plus.
These emails are sometimes time-sensitive (so can't take all day to send).
Thoughts? Tips? Point me in the right direction?
EDIT
To clarify:
I can do these on my own:
maintain user list
handle email content generation based on user preferences
And need something else (app, third-party service, w/e) to:
accept email content and addresses and actually send the emails out
provide tracking data (opens, clicks, etc). The more detail the better.
I'm leaning towards a third-party service, since I'm not sure any app can avoid choking the server when sending thousands of emails (though I wouldn't consider myself an email expert so I could be wrong).
We use the built-in PHP email functionality to send thousands of emails to subscribers on a daily basis.
This is a terrible idea. It chokes out our server, and takes hours to complete the whole batch.
Why do you think that your problems are anything to do with the built-in PHP email function? It's a very thin wrapper around 'mail' or a simple SMTP client depending on what platform you are running on.
When you say it chokes your server - do you mean your email server? Your web server? something else?
There's nowhere near enough information here to make a proper diagnosis but it looks like the problems are of your own making - sure, there are lots of people out there who promise to sort all your problems for you if only you buy their latest product/service. But there's a very good chance that this isn't going to solve your current problems.
Can you tell us:
what OS the PHP is running on
how you invoke the code to create the emails
what the mail config in the php.ini file is
what type of MTA are you using? On what OS?
how is youe MTA copnfigured - does it deliver directly or via a smart relay?
which server is getting "choked"?
What anti-spam measures do you have in place for outgoing mail?
Then tell us what you've done to diagnose the fault and why you think its specifically on sending mails.
C.
I'd recommend using the third party mailing service Silverpop, or something like it. We've used them for a few years and have been fairly satisfied. They already have relationships with the major email clients (AOL, Yahoo!, Gmail, etc.) and they do a good job of telling you if the stuff you're sending is likely to be classified as SPAM.
They have a fairly extensive API that uses XML HTTP/HTTPS requests that can tie in to existing systems. You can use it to remotely trigger emails, schedule mailings, customize email contents, set up, manage and query huge lists of recipients, run batch processes, etc.
It isn't a perfect service, but compared to a lot of others out there, they do pretty well. I have had very few complaints about them thus far.
I usually got around this by having a mail "sending" function that dumped the emails into a queue (database table) with a job that ran every couple of minutes, grabbed the next x emails in the queue, sent those out and marked them as succeeded. That's the simple bones of it. You can then add on handling for email failures, returned mail, etc in version 2.
Use Google AppEngine if you are worried about scalability & customization: it provides an email API and you can interface anything to it provided it is through an HTTP interface.
Of course, this is just a suggestion - disregard if this doesn't fit.
Quite possibly not ideal, but if you're looking at large scale transmission there are commercial solutions such as Port 25's PowerMTA that can be set up to effectively transmit the contents of a given folder.
As such, you'd simply use PHP to create the personalised MIME formatted raw data for each outbound email and place these in a temporary directory prior to transmission. (I've written such a system in the past and you'd be surprised at the PHP's ability to grind out the emails, even with quite complex text & HTML emails with images as inline-attachments, etc.) Once you were ready to transmit, you'd then move the files en-masse to the PowerMTA monitored folder and it would take care of the transmission.
Depending on how you look at it the benefit/problem with such a solution is that you'll need to build trust relationships with people such as AOL, MSN/Hotmail, etc. to ensure that your mail server isn't blacklisted due to user's reporting email as SPAM. (That said, this will likely be a factor with any DIY solution.)
Why not keep your PHP system and use a third party SMTP service? Some reliable companies offer the use of e-mailing-only machines at reasonable prices, e.g. Dewahost who I am planning to use.
Also see the question Third Party Email Senders and my answer there.
Check out Campaign Enterprise for a possible in-house solution.
One of my friend uses http://www.tailoredmail.com but i havn't used it personally
I know this is an older question, but I just wanted to suggest SendGrid which is essentially an "Email Server as a Service" allowing you to send emails with cost per email.
I want to send data to an emailaddress and save it into a MySQL database (PHP).
What is the easiest way to do this? (no form post, no curl etc., just email)
there are a few ways.
use a postfix alias script, basically, postfix receives your mail, and then runs it through a script of your choosing. The contents of the mail appear in STDIN - then you can do as you please with the contents of the mail.
Use a custom mail server like apache james, that is designed to process mail, and 'do something with it'
{A good one I found recently was in the google labs - http://freshmeat.net/projects/subethasmtp} - looked really good.
pls bear in mind that email is not a guaranteed protocol, if you are trying to do app-to-app messaging, then there are probably better ways!
Hope this helps., ace
If your server doesn't have imap but you have an outside system which does have cron you can write a page that checks the email account and loads the data into MySQL then set up a script on a machine that does have cron to wget the mysql page once every X minutes where X is how frequently you want to load data.
Alternately if you know the emails will load quickly you can set up small one field table in your DB with a time stamp. Each time your PHP script runs it checks the time stamp and if it's more than 5 minutes old it calls the email loading script before loading the web page.
If you can access the email using POP just have a process checking the email with POP functions and sending everything to your database
Also you could use php IMAP support
Assuming you know how to save the data to mysql already, you will need access to a mail server, either your own, a webhosts, or you could use a free one such as Gmail, or Hotmail.
You can then use PHP's IMAP functions (which can access POP too) to access the mail. Articles which may help you with this: PHP imap info and a tutorial on creating PHP webmail
There is a slicehost step-by-step tutorial that takes a unix based machine, installs postfix on it, sets it up to use MySQL and configures it to accept virtual users and serve/receive email from multiple domains.
The set up is clean, fast and secure. Life is good, eh?
http://articles.slicehost.com/email
Perhaps you should look at www.dbmail.org
Is there a way to configure a server or a script to execute a php script when an email is received?
In theory this could be extended to other protocols, such as XMPP or SMS, etc.
What I have in mind is a user could send a message to checking-in#example.org and this would trigger a script which would then do whatever needed to be done, either irrelevant to the message (an automated message that gets sent whenever some other even occurs, like a server having issues) or related to the message (like it could store the subject in a database that other users could view as an RSS feed).
I know that most list-serve software have a means of sending commands (like unsubscribe), but I'm not sure how complicated the process is and if it is feasible to have something like this on a server-script level.
Would this need to occur at the IMAP/SMTP level, or could it be done closer to the script or HTTP server?
Just to give some context, one of the things I'm considering is a message-based clock in server for one of my work sites. Users could IM/email/text that they are at their scheduled location and this could trigger a script that would update a DB, rather then send the managers a direct message they need to log. This would just be one option (a web-based method is already in the works), but we want to make it as platform/protocol independent as possible. But if we can achieve that, we can look at implementing it for many other day-to-day needs.
Another way of asking might be: is there a way to have "discovery" of users from a server-script app or does something need to be doing a constant check to relevant sources to see such changes?
If you control your own machine you can configure it to pipe the e-mail through a filter. Simplest would be to setup a new account and setup a .forward or alias
The following examples are for Sendmail, but (all?) Unix e-mail programs offer a similar service.
Setting up an alias (option 1)
Look in the directory /etc on your server for your alias file. Add the line:
script: "|/path/toyourscript/pipe.php"
Using a .forward file (option 2)
Create a .forward file in your main home directory.
"|/path/toyourscript/pipe.php"
or:
myemail#example.com,"|/path/toyourscript/pipe.php"
If you are on shared hosting then most hosting providers also provide the possiblity to "pipe" e-mails received to a particular account through a script instead of storing them in a mailbox. Check the CPanel setup.
Use a cron job to check for emails through a pop3 interface. If an "interesting" mail is found, run your php script.
Note that the cron script can be in PHP too.
As jldupont said, it is easy to do ith php itself, simple reading the smtp continuosly with a cronjob.
Otherwise, you could use a daemon, in python for example.
Both ways allow you to do an important thing: check if the sender of the email is a your user (you have the users in a db, right?), or a spambot (nomatter what kind of anti-spam you use, soon or later, checking-in#example.org will be full of spam)
I have a php script that does some processing (creates remittance advice PDFs, self-billing invoices, Sage CSV file etc...) and at the end outputs a screen with a form, in which the names and e-mail addresses of the people paid appear. User makes a selection of names by clicking check boxes and then there is a Send button which sends out emails with remittance advices and self-billing invoices attached. This all works nicely, BUT they now decided that when they click the Send button, they would like the e-mails to be sent NOT straight-away, but at 6.00pm.
Is it possible to set the dispatch time of the message in the SMTP header? Can the MS Exchange server be configured so that e-mails from a particular sender will be held until a certain time before they get sent? IT Support dept. claim it used to be possible in the old days of dial-up connections when it was simply cheaper to send stuff at night... but that this functionality was removed. Is this true? I have no idea how hard is the task at hand. It seems very straightforward and I guess it really is a task for the IT support guys to handle. But maybe I am wrong?
If this can not be set up at the Exchange server side, how could I go about achieving the requested functionality? And, no, this is not an exact duplicate of this question. I had a look at that but it didn't seem to answer my questions. Any help greatly appreciated!
Edit
Apache running on MS Windows Server 2003. Database is Oracle 10g. There will be no CRON set up. The email queue table would need to store all attachments too. I would like to avoid doing this at all cost. No way to specify dispatch time in header?
You could save those emails into a database. And then create a cronjob PHP file that executes every few minutes to check if there are emails to be sent in the "queue" database.
Here's a tutorial on something like this.
Windows (non-server editions, at least) has a "Scheduled Tasks" control panel item similar to CRON. Just from looking at it briefly, you can probably write a PHP script which sends your mail "now," but run it using the CLI at whatever time you want to send the mail using Scheduled Tasks.
Actually you can do this. If you are using an exchange 2003 server, you can set up a different SMTP connector. Under the delivery options there is a way to change it from send always any scheudle you pick.
Here is a nice tutorial for setting one up.
link text
One thing you will need to do is when you create the new SMTP connector, set it up with a different port to listen on. That way you can send to that one instead of the standard connector.