Alternative for PHP mail

问题:

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.

回答1:

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

回答2:

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.

回答3:

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.