Re: Fixed but no idea why.

Hi;

First off, thank you for the detailed explanation. That makes this a
lot clearer.

I put mail.windward.net as the FQDN because of posts in this NG saying
that was necessary so spam filters do not throw away messages as they
would be coming from a box that is not a MX record for us.

Our topology is that the IIS SMTP server box is outside our firewall
(going to a co-lo facility soon) while our exchange box is inside our
firewall. So they have distinct IP addresses.

Do I not need to set the FQDN? Or is that necessary as the box has an
IP address that is not in our MX.

thanks - dave


On Tue, 21 Feb 2006 00:26:20 -0500, Sanford Whiteman
<sandy@xxxxxxxxxxxxxxxxxxxxx> wrote:

Ok, here is what I think is happening (thank you to a MS PSS tech for
this). I entered maail.windward.net as the FQDN for the SMTP server so
when it sends mail, reverse DNS checks will work.

The only reason this would be necessary is if both your IIS and
Exchange boxes are getting NATted to the same public IP, and your
firewall can't handle any other setup.

IF the above is true, what you've done is sensible. The canonical
name of the server's public IP is mail.example.com, so that's what you
want it to answer with (220 hostname) and what you want to announce
itself as (EHLO/HELO hostname). It's also the hostname you have as
the PTR for that server's public IP. IMO, if your firewall is truly
this broken, there is absolutely no reason to alter the IIS behavior,
or to expect any other options to exist. The more round-trip-safe
your setup, the more likely it is that you will be able to send mail
to the outside world. If you want more flexibility, that should come
from your firewall.

If the first paragraph above is NOT true, then there was no reason not
to give your IIS box its own canonical hostname and standardize your
PTR, A, 220 and EHLO against that hostname.

However, that entry also tells the SMTP server who it is and therefore
any mail to windward.net it won't send because it is windward.net.

Yes, if you call the machine mail.example.com, and the MX record
specifies mail.example.com as the MX for your domain, then the
resolution of this name will take place locally. And it absolutely
should, even if you don't think of the SMTP settings as being as
"intimate" with _themselves_ as the SMTP settings are with HOSTS and
DNS.

The same would be true if the Windows name of the machine were
mail.example.com, even if the IIS SMTP FQDN setting were not (the
Windows name is used by default in this field, with good reason, since
it forces some amount of uniqueness). In both cases, you're choosing
to say that the machine _is_ host <hostname> at a hard-coded level,
overriding remote DNS resolution, at least within the context of IIS.
So to get mail off the box, you need to override this at another
hard-coded level that takes precedence: the hard-coded Remote Domain.

Since you hadn't mentioned that you were calling this machine by
another machine's name (the very name of the machine you were
expecting it to find off-box), it's natural that we weren't able to
get to the meat of the problem.

I think that field in the properties should be split in to two fields.

I don't think so at all. As I note above, you want your system to be
as round-trip-safe as possible to/from the outside, meaning as few
"one-off" settings as possible. Introducing additional bells and
whistles will just make your setup harder to manage. So, if you're
ready to call the machine mail.example.com, you must assume that
subsequent behavior on that box will "believe" this setting and call
the machine by that name. There's _nothing_ that says the FQDN is
cosmetic; rather, the IIS documentation introduces the setting as
"involved in the processing of MX records." Which indeed it is!

Furthermore, the method of forcing off-box mailrouting is quite
simple, as you have seen: a Remote Domain. This is the method used by
anyone running a dedicated IIS MX in front of an Exchange box to
prevent DNS loop conditions. Since you're not using this machine as
an MX, you normally wouldn't have had any such looping worries. I'm
thus interested to find the answer to my very first query above, that
is: why did you need to have this machine impersonate the other
machine's canonical hostname?

--Sandy


david@at-at-at@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com
.

Relevant Pages

  • Re: SSL through firewall
    ... I'm getting throught the firewall to port 80 without a problem. ... No IIS isn't setup that way, it's just the deafult Exchange install. ... FQDN ...
    (microsoft.public.exchange.connectivity)
  • Re: server change for mindprod.com
    ... install and not have lost any of my data. ... For networking, few people know the secret of Red Had networking. ... DHCP) and add your FQDN here. ... get a hostname later; both hostname and hostname -f will return the same ...
    (comp.lang.java.programmer)
  • Re: Windows authentication query
    ... Kerberos Authentication works find with FQDN. ... a client on the internet would not be able to connect to ... :> install IIS, only the NetBIOS name of the IIS server is registered with ...
    (microsoft.public.inetserver.iis.security)
  • Re: Windows authentication query
    ... Yes, ideally setting the SPN should be fine, but it did not work. ... > install IIS, only the NetBIOS name of the IIS server is registered with ... > FQDN) with the KDC. ... IIS server in the list of sites that would be available in the intranet. ...
    (microsoft.public.inetserver.iis.security)
  • RE: Strange IIS Security issue
    ... 303650 Intranet Site Is Identified as an Internet Site When You Use an FQDN ... David Dietz -- IIS Support Professional ... |>site) without Anonymous access so I have set-up this one ...
    (microsoft.public.inetserver.iis.security)