Sometimes big delay when using PHP mail()

I have a website which processes orders from a Windows application. This works as follows:

1. User clicks "Order now" in the windows app
2. App uploads a file with POST to a PHP script
3. The script immediately calls the PHP mail() function (order is not stored in a db)

This works fine most of the time. However, sometimes a big delay occurs (several days). Customers calls why the product has not yet been delivered.

E-mail headers of delayed mail follows:

The delay seems to occur here:

Received: (from @localhost)
by ---- (8.13.8/8.13.8/Submit) id o4J9lA7M031307;
Wed, 19 May 2010 11:47:10 +0200

I've reported this issue various times to the web hosting service that hosts my website. They say the delay does not occur in their network (impossible).

But they do confirm that the e-mail is first seen in their mail server on May 26, which is 7 days after the mail has been composed. The order is marked with the timestamp of the user's local PC, which also matches May 19 (so it's not a PC clock problem)

It's also interesting to see that all delayed mails (orders were placed on different days) come in at once. So I suddenly receive 14 e-mail in my mailbox from various days.

Any idea were this delay may be introduced? Could there be a bug in my PHP code that causes this? (I cannot believe I can introduce a loop of 7 days in my PHP code)

You're right - its nothing to do with PHP.

Normally, slow mail problems are all about DNS issues - but that is not the problem here.

Whenever I've configured an MTA (Mail Transport Agent) I'd have told it to give up long before 7 days had expired.

It's also interesting to see that all delayed mails (orders were placed on different days) come in at once.

Sounds like either the MTA is only configured to dequeue mail every 7 days (!) or something went wrong and it took 7 days for your hosting company to fix it.

They say the delay does not occur in their network

Time to find a new hosting company.

C.

email just isn't very reliable way of sending information like this.

Chances are there were just some short term issue on one of the 2 servers involved that meant attempts to send the email encountered problems.

Mail servers will often wait a while before retrying, (though I would have expected a much shorter time than 6 days for the initial retry). The reason you are probably getting a little burst of them is that all the retries finally get through together.

It does seem a little odd that it would wait so long to retry though.

You would probably have to look at your mail server logs to see if they were having any problems around the time that message was sent.

There's also this:

X-Virus-Scanned: by amavisd-new

This would indicate that there's at least ONE more step after accepting the mail originally. amavis itself would most likely be passing the mail on to ClamAV, Spamassassin, etc... and any one of those could for some reason be introducing delay.

Given the 8.13 version number on the webserver's SMTP, it's most likely Sendmail. If you have any kind of access to the server, check the outgoing mail queue with 'mailq', if you have the rights, or have the admins there do it for you. Since the delay's occurring somewhere within the server, at some point it should be getting stuffed into sendmail's pending queue, and that will also have the delay reason attached.