|
|
|
date: Sun, 12 Mar 2006 12:50:29 -0800,
group: microsoft.public.exchange2000.connectivity
back
RE: FQDN: internal vs. Internet
Hello McR,
Thank you for posting.
Actually, it is recommended to use two different FQDNs for internal
communication and external communication. You needn't to change any records.
For example, my internal domain name is corp.domain.com and the external
domain name is domain.com. The external MX record points to mx1.domain.com.
The internal FQDNs of the Exchange servers are ex1.corp.domain.com and
ex2.corp.domain.com.
When an external server needs to send mail to my domain (aaa@domain.com),
its mail server will send a query to the DNS server for my mail server's IP
first. Then the DNS server looks for the MX record in domain.com zone and
gives the answer to the mail servers. After receiving the IP address of my
mail server, the external mail server will establish a connection with the
SMTP virtual server on my server and send the mail out. When my server
receives the mail, it will send a query to the DC. In this query, the
exchange server will ask which server hosts aaa's mailbox. If the mailbox
is not hosted on the server which receives the mail, the server will send
the mail to the target server via internal FQDN ex2.corp.domain.com.
I hope the information is helpful to you. If you have any further
questions, please feel free to let me know. Have a good day.
Sincerely,
John Chen, MCSE, MCSA, MCDBA, MCSD
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Mon, 13 Mar 2006 07:39:24 GMT
author: (John Chen [MSFT])
Re: FQDN: internal vs. Internet
>Indeed, when I telnet to port 25 on the Exchange server, this is the hostname
>I see in the SMTP banner.
>Q: Do I need to replace the internal, AD FQDN with the Intenet FQDN that
>corresponds to the MX record?
Yes, but not because of the 220 banner (the greeting your server gives
on incoming connections). It's because the same variable is used as
the HELO/EHLO when your server initiates outgoing connections. Your
server _must_ complete an EHLO-PTR-A-IP "DNS roundtrip"
to ensure delivery. That is, the PTR for the public IP of the box
must match the HELO sent by that IP; the PTR must also have a
corresponding A record that points back to the originating IP.
Assuming that you're publishing a PTR for the public IP of
mx1.example.com to match the MX-A chain record (you didn't mention
this specifically), but the machine's HELO is ex1.corp.domain.com, you
will fail the round-trip test and thus cannot expect to pass anti-spam
checks at remote servers with strict policies.
One alternative to changing the FQDN would be to change your MX and
PTR to match the FQDN. Another would be to use a secondary virtual
server for outbound mail, and ensure that you pass the roundtrip with
the values on that VS. Tur overall goal should be to boil down your
setup to use the canonical names of the machines involved whenevr
possible. Avoid hostname aliasing, implicit multihoming, and
additional VSs if you want to stay sane.
--Sandy
date: Mon, 13 Mar 2006 03:29:27 -0500
author: Sanford Whiteman
Re: FQDN: internal vs. Internet
>When an external server needs to send mail to my domain (aaa@domain.com),
>its mail server will send a query to the DNS server for my mail server's IP
>first. . .
Yes, but it's not just about incoming mail. You refer to an "internal
FQDN," but there's no such thing, as the FQDN is used for outbound
mail as well (assuming the same virtual server is used for outbound).
If you're presenting a HELO FQDN that doesn't match the PTR of the
public IP, you cannot guarantee the delivery of outbound mail. (If
the HELO is not only not the PTR, but has no accompanying public A
record at all, you're even worse off.) True, as long as your FQDN is
in a public domain space (i.e. under a public TLD and thus capable of
being resolved using the public DNS), there's nothing that forces you
to change *that part* of the roundtrip. But you have to change
*something* to be above suspicion.
--Sandy
date: Mon, 13 Mar 2006 03:36:19 -0500
author: Sanford Whiteman
|
|