views:

2397

answers:

4

This is a problem I'm sure is easy to fix, but I've been banging my head on it all day.

I'm developing a new web site for a client. The web site resides at (this is an example) website.com. I have a PHP form script to email visitors' requests to [email protected].

When I coded this on a staging server on a different domain, all worked fine. When I moved it to website.com, the mail messages never arrived. The web server is on a virtual host with a major ISP.

Here's what I've learned since then: My client's mail server is Microsoft Exchange on a box physically in their office. Whenever someone on the outside world emails [email protected], the mail arrives. But if the web server sends to the same email address, it fails every time. This is not a PHP problem. I secure shell in to the web server and have tested this both with sendmail and the UNIX mail application. I've also tested it by emailing various email accounts from the shell. I can email myself, for example, just nobody at the website.com domain.

In short, when I'm logged in to website.com, mail to [email protected], [email protected], [email protected] all fail. All other addresses work fine. What I've discovered is those dropped emails are routed to the web server's "catchall" account where they sit in its inbox.

I've done an MX lookup on website.com. The MX record points to mailsec.website.com. I can telnet to mailsec.website.com port 25 and see the SMTP server.

It appears to me that website.com isn't doing an MX lookup when it's sending mail to [email protected]. My theory is that it recognizes the domain as local, sees that there's no "requests" user account to deliver it to, and drops the mail into the catchall account. What I want is to force sendmail to do the MX lookup and send the message on to the Exchange server. I'm at wit's end here. I can't figure out how to do this.

For that matter, I may be way off base here and have misdiagnosed this entirely. Internet mail and MX has always seemed a black art to me, and my ignorance is certainly showing in this question.

+5  A: 

I think the problem is that sendmail (your process) is talking to the local sendmail daemon. The local sendmail daemon thinks that because it is website.com, it should know how to deliver the email. Unfortunately, the actual address in the to field does not exist on the web server and thus it dumps it in the "catchall" mail box. You should talk to your ISP and have them update their sendmail configuration so that mail addressed to [email protected] gets forward to the mail exchanger instead of being handled locally.

tvanfosson
+1  A: 

tvanfosson basically has it, but as a temporary workaround, you should be able to change your script so that it mails '[email protected]', and then the mail will get delivered to the actual mail server.

genehack
A: 

Edit the tsm.cf file (in /etc/mail/ or similar) to include

FEATURE(relay_entire_domain)

between the DOMAIN() and MAILER() lines. Since you're editing the file, you may want to also improve security with

define(`confPRIVACY_FLAGS',``noexpn,novrfy'')

After changing the tsm.cf file (or any sendmail config file), restart or SIGHUP the sendmail process.

This change is necessary because the WWW and MX servers for the domain do not exist in the same process space; this FEATURE triggers sendmail to process messages for the domain using it's external delivery mechanism.

The edited portion of the tsm.cf file should look similar to this:

DOMAIN(website.com)dnl
FEATURE(relay_entire_domain)dnl
define(`confPRIVACY_FLAGS',``noexpn,novrfy'')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
A: 

I'm having the exact same issue. The above responses, I'm guessing, did not fix your issue. Were you ever able to remedy this issue? I appreciate you getting back to me if you did. [email protected]