MX Records: separate web and email servers

[Kevin Darcy]

dimavan at gmail.com wrote:
> Hello,
>
> Due to the nature of this question, I was not quite sure where to post
> it. Apologies if this is the wrong group.
>
> The setup in question involves web and mail hosting for a given domain
> name ("example.com"). Website and email are hosted on two separate
> servers. DNS records for the domain name specify the web server's IP
> address for the "example.com" A record, the mail server's IP address
> for the "mail.example.com" A record. The latter ("mail.example.com")
> is also specified as the domain's only MX record. Simple and standard
> setup thus far.
>
> The web server is provided by a third party hosting company, and is by
> default configured to handle email for the said domain name. As the
> web server isn't actually used for email, no mailboxes or aliases have
> been created. My problem is this: when an email is sent from a script
> on the web server to any address @example.com, it is automatically
> handled by the web server itself, and does enter the outside world.
> The web server immediately generates an NDR, and the email doesn't go
> anywhere. It's obvious that in this case, the MX record isn't used by
> the web server to look up the domain's true mail destination.
>
> What are my options? What, if any, is standard practice in this
> particular case?
>
> Thanks in advance for any help, or recommendations of other groups
> where I may receive some.
>
>   
Generally, user-written scripts which send mail don't function as a 
full-fledged MTA (Mail Transfer Agents). Thus, they don't do DNS lookups 
to determine where to deliver that mail. If this particular script *is* 
doing a DNS lookup, then it should follow RFC 2821, Section 5, which 
mandates that an MX record, if present, should take precedence over an A 
record.

What's more likely is that the script is just submitting the mail to the 
local MTA  (sendmail, postfix, qmail or whatever), which, as you 
described, is misconfigured to *accept* the domain, but doesn't have the 
necessary mailboxes, forwarding entries, etc. set up. You need the 
script to submit its messages to an MTA that isn't misconfigured for 
this particular domain, either by "normalizing" the config of the local 
MTA, or pointing the script at some other MTA entirely (possibly that of 
a third party).

Or, if you're really amibitious, as described above, you could add some 
RFC 2821 smarts to the script itself. But, the algorithm is non-trivial 
and you'd have to decide what to do if the remote gateway is unavailable 
(queue up and retry later?). Writing a skeleton MTA in script form would 
probably be overkill for what you're trying to accomplish.

                                                                         
                           - Kevin