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.
Related
I will start by saying that I am not having an issue with sending successful emails with PHPMailer. It is working as intended in that regard. The PHPMailer script is working and this may very well not even be a PHPMailer related issue. However, there is a 20 second "processing" delay that is happening everytime I attempt to run the very basic script.
This essentially botches any kind of front-end experience which is causing an issue for my intended use case (a contact form). Note that my testing was done solely on the provided Github recommended example code, no external code was added beyond necessary configuration.
The script is sending a basic singluar email. No batch or mass sending is required. My code and PHPMailers debug log are posted below. Please check out the debug log - after the initial connection is open, there is a 20 second delay between connection opened and the first "220" status. I am not versed enough to understand exactly what this means and I was hoping to get some clarity on that. A simple google search does provide that 220 means Domain Service is Ready. But what is really happening in these 20 seconds? What is causing the hang? 20 seconds is too long to send a single email.
I have been researching delays on SMTP and PHPMailer issues for over a week now and I cannot find any good information that provides a straight forward answer to this issue. I have however found recommendations to:
Use a localhost to recieve mail. (I cannot do this, I don't have the capability to run my own mail server 24/7)
Design a Mail Queue and batch send on a different thread(cron job, etc) - Note that I have done this before for a much larger project. But considering this use case is going to be for a basic contact form, I feel like that is a bit overkill. Maintaining a database to send a singular email should not be necessary. I also have no need for mass sending. Every email will always be a singular email and ideally it would be recieved immediately, not on timed intervals, ie. cron job.
Your Web Hosting is garbage. (It is likely bad) I don't really have experience with who is the best or the worst. I am hosted through Hostinger and unfortunately I am essentially locked in for 4 years without taking a loss.
--
Is there anyone that understands what is actually hapenning here? Maybe another person that had a similar issue? Someone that can take the debug logs at more than face value and could provide any clarity on what is causing the 20 second delay on every single of the script. Or any potential solutions that allow me to continue using SMTP but without the delay. It is almost always exactly 20-21 seconds.
(Currently when manually disabling SMTP from the script, it eliminates the 20 second delay, but it essentially reverts the code to scrictly use the php mail() function, which I hear is bad practice. I would love to be able to retain best practice, which I hear is SMTP/PHPMailer)
This is an anti-spam technique called “greetdelay”, and will be a deliberate choice implemented by your mail service provider. The SMTP spec says that clients must wait for the server to respond before starting an SMTP transaction. Badly-behaved clients (such as spam scripts) don’t wait, and the server will drop the connection and possibly block subsequent connections from that IP if they start talking too soon.
PHPMailer is well-behaved (it will wait, as you’re seeing), however this really highlights that SMTP is not a good thing to use during interactive HTTP request processing, which is mentioned in the PHPMailer docs.
The right solution to this is to run a local mail server to act as a relay. Submission will be effectively instant as far as your page is concerned, and the mail server will handle onward delivery, including the greetdelay. It will also handle more complicated problems like greylisting, network outages, mail server throttling, etc.
Mail servers like postfix are not difficult to configure to act this way, but that’s really suited to docs, tutorials, or a question on server fault. I’m not clear why you can’t do this. If you have root access to your own VM, and you already know that outbound SMTP traffic is permitted, it should not be a problem.
When an order is placed, the order details are sent via email to the customer and seller but it takes too long to send the email due to which the order placement takes time. What should be done to make the process faster?
I guess you should implement a Queue, for example [https://laravel.com/docs/5.2/queues]
Install a local mail server (I'd recommend postfix) and send to it from PHPMailer using SMTP. That is the fastest way of getting a message on its way. It means that your script does not have to deal with DNS lookups, remote connections, authentication, and it hands off control to the mail server that deals with all those things asynchronously, including queuing, retrying, bouncing etc.
You can implement queuing in PHP, but it's really the wrong tool for the job. Regardless of the implementation, it will be much, much slower and more error-prone than using a mail server, and more to the point, it's software that you will need to write, test and maintain.
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.
I assume I will need to point MX records at my server (LAMP), -- what processes the incoming e-mail message?
Are there any existing PHP libraries to do this?
You don't want to use PHP as a mail server. You've got two options:
Set up a classic email server (postfix, sendmail, exim, etc) that delivers new messages to a local mailbox. Use IMAP or POP to access that mailbox from PHP, and pull messages out of it. Alternatively, this same method may be used with (virtually) any remote mail service as well, thus relieving you of the duty of administering a mail server. (Which you'll likely find to be not worth it for the sake of one mailbox.) This method would usually be run via cron every few minutes, so you're not going to get "instant" activation if that's a requirement.
Set up a classic email server (postfix, sendmail, exim, etc) and use procmail or similar to intercept messages at delivery time, and pipe them to a PHP script. This method will fire the script the instant the email arrives, so you'll have no lag time like in #1. However, it's more difficult to configure (especially if you haven't maintained a mail server before) and won't work with most external hosted email services.
Use a pipe alias to receive the emails.
I would recommend you to do processing in Perl (python is also ok, but Perl has very similar syntax to PHP), which is much more suitable for the task. You can also find a lot of libraries through CPAN there.
http://search.cpan.org/~rjbs/Email-Simple-2.100/lib/Email/Simple.pm
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.