The Case of the Disappearing mail()

I just solved—for at least the second time, probably more—a tricky mail delivery problem. Each time it comes up, it's hard to figure out the terms to search for in Google to come up with a solution. The symptoms are as follows: Mail is being sent from a PHP application to one or more addresses. The app could be Drupal, a custom app… anything that uses mail() to do its dirty work. If the mail addresses are on the same domain as the PHP app, the mail delivery fails silently—PHP reports successful delivery, but the mail never arrives. If the addresses are on different domains, the mail is delivered successfully.

I have seen this most commonly in a hosting environment (such as MediaTemple) that uses Plesk and Qmail. The key is that the mail server is in a different environment. A common scenario is a Google Apps mail installation (Gmail), but any other mail hosting will behave the same way. What is happening is that mail gets sent from the app located at http://example.com/ successfully. The mail is being routed to info@example.com. Normally, the MX record on the domain name server is consulted, it finds the external mail system, and the mail gets delivered successfully. However, in this case, PHP's mail() asks Qmail to deliver the message. Qmail says, "Hey! This mail is for example.com! That's me!" The DNS record is never used, and the mail gets routed locally; not what we want.

The Solution (for Plesk)

The solution is simple, though finding it is difficult. The server needs to be told that it does not handle mail for this domain. This information is stored in Qmail's "virtualdomains" file, but in a Plesk environment, the correct way to handle this is a single button press.

In the mail administration area, click this shiny "Switch Off" button. Qmail will be automatically reconfigured, and mail delivery will work once again. voilà! For the searchers out there, here's the log file that is generated when this behavior is being exhibited:

May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: Handlers Filter before-queue for qmail started ...
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: from=anonymous@rapiddg.com
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: to=info@rapiddg.com
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: hook_dir = '/var/qmail//handlers/before-queue'
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: recipient[3] = 'info@rapiddg.com'
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: handlers dir = '/var/qmail//handlers/before-queue/recipient/info@rapiddg.com'
May  8 08:29:32 rapiddg qmail: 1241796572.918522 new msg 11867118
May  8 08:29:32 rapiddg qmail: 1241796572.918569 info msg 11867118: bytes 349 from  qp 22028 uid 48
May  8 08:29:32 rapiddg qmail-queue-handlers[22027]: starter: submitter[22028] exited normally
May  8 08:29:32 rapiddg qmail-local-handlers[22029]: Handlers Filter before-local for qmail started ...
May  8 08:29:32 rapiddg qmail: 1241796572.925466 starting delivery 7: msg 11867118 to local 1-info@rapiddg.com
May  8 08:29:32 rapiddg qmail: 1241796572.925504 status: local 1/10 remote 0/20
May  8 08:29:32 rapiddg qmail-local-handlers[22029]: from=anonymous@rapiddg.com
May  8 08:29:32 rapiddg qmail-local-handlers[22029]: to=info@rapiddg.com
May  8 08:29:32 rapiddg qmail-local-handlers[22029]: cannot reinject message to 'info@rapiddg.com'
May  8 08:29:32 rapiddg qmail: 1241796572.932069 delivery 7: failure: This_address_no_longer_accepts_mail./
May  8 08:29:32 rapiddg qmail: 1241796572.932108 status: local 0/10 remote 0/20