Re: SMTP Service not functioning on IIS 5
- From: "Sanford Whiteman" <swhitemanlistens-software@xxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 09 Jun 2007 21:29:17 -0400
I used the FQDN of the domain because it made sense to me for an
intranet site, i.e. the home page for this domain. I've been using
AD since 2000 and I've never had a problem with doing this, but I
didn't know there was anything inherently risky about it
Well, AD DCs will auto-register an A RR for the domain FQDN with their
IP(s) -- unless you overtly block this autoregistration by making
static entries. While the domain A RR entry is the least important of
the locator records (viewable in NETLOGON.DNS), as it is only used if
a client can't or won't use the more robust SRV RR type, it is
nonetheless part of the server location process and not having it will
bite you if you introduce downlevel clients. At any rate, that's
*almost* 100% likely to be unrelated to your SMTP service problem (I
cannot dismiss it entirely, but let's forget it for now).
why shouldn't a browser request for a domain name bring up an
intranet home page like an external website?
Because the DNS zones "federated" with your AD domain are crucial to
AD operation. They are not just any old zones. That's kind of like
(though, I admit, not as extreme) saying "How come I can't have a
website called '_ldap._tcp.corp.domain.com' anymore, now that I said
that domain.com is the top of my AD hierarchy?" One main difference,
of course, is that the underscores are illegal in public hostnames, so
you would tend to avoid them even if all the end users are using your
MS DNS servers and are inside your firewall. The A record for plain
'corp.domain.com' _looks_ like a regular, publicly referenceable
hostname, but IME it is best to reserve it for AD's needs, even if at
the point of AD implementation you don't have any clients that need
those A records. I would use intranet.corp.domain.com instead, which
is not reserved at all. But that's just me, and again, I think this is
off the SMTPSVC topic.
I configured the LDAP routing because AD stores the information on
containers for mailboxes and usernames and can resolve recipients.
What does it do that I am thinking it doesn't? Perhaps an
explanation would help, but I will turn it off as suggested and try
it out.
LDAP routing is for list explosion on the server. It doesn't, for
counterexample, maintain or reject unknown recipients. It is only
useful in purpose-built mailing list environments.
The masquerade domain was added to help in troubleshooting. Since
it puts the masquerade domain in the "Mail From" part of the header,
I figured it might help at some point.
You'd use the masquerade if, for example, you knew that internal
clients were generating mail with invalid right-hand-side data --
perhaps using an private TLD like username@xxxxxxxxxx -- and you
needed to massage the data so that your mail would not be rejected for
having an invalid sender.
With the smart host, this was something I was testing to see if it
would work. My thinking was that if mail was being sent out and not
going anywhere from the SMTP service, if it went to Exchange and was
delivered ok, then I'd have an idea that mail was at least being
sent out properly and there might be some other issue from the IIS
box.
I would say that having a known-good secondary server that takes over
for your probably-bad primary is certainly *worse* for troubleshooting
the primary, even if it's better for overall delivery. That someone
received a test message becomes info useless without additional
diagnostics.
I'd be able to check the headers and see what server it came from.
True. Though I think at this point you should be concentrating on
logs, not headers. Logs are always the better friend, IME.
Aaaaanyway, I would recommend that you uninstall and reinstall the
SMTP service, if you haven't already. If that doesn't work, uninstall
again, get Metabase Explorer and delete all SMTPSVC keys, then
reinstall (back up beforehand, obviously). Also ensure that nothing
else on the box is attempting to listen on TCP 25. The error that
you're seeing suggests a corrupt or unusable base installation for
reasons outside of the SMTP config itself.
--Sandy
.
- References:
- Re: SMTP Service not functioning on IIS 5
- From: Sanford Whiteman
- Re: SMTP Service not functioning on IIS 5
- From: Jeff
- Re: SMTP Service not functioning on IIS 5
- Prev by Date: Re: IIS 5's SMTP and Stopping NDR's ?
- Next by Date: Re: Properly configuring SMTP Service
- Previous by thread: Re: SMTP Service not functioning on IIS 5
- Next by thread: Re: IIS Service Stops unexpectidly
- Index(es):
Relevant Pages
|
