iis smtp nntp: I am trying to change our email server to go from our internal exchange
server to a hosted one.

On our Mars machine it is using its own SMTP server. We still have our DNS
server and exchange is still running on that machine but there is no MX
record on these machines and our domain as Network Solutions has an MX
record pointing at the Hosted site.

The problem is with our internal address coming from our Mars machine. We
have our smtp server set as local host in our code and it works fine for
addresses outside of our network. But if Mars sends an email message to
someone internal, it seems to go to our internal exchange server and to our
old mailboxes on that server.

What would cause Mars to send the email to our internal Exchange server?

Thanks,

Tom

[quoted text, click to view]

You cannot send mail "through" an IIS SMTP virtual server to an ostensibly
remote domain if that domain is known as local to an Exchange server
running on the same box. Exchange has an event sink hook specifically for
this purpose.

Other than that exception, mailroutes are governed by DNS and HOSTS files
and whatever proprietary settings used within MTAs themselves (for
example, in IIS SMTP as a simple MTA, adding a Remote Domain entry allows
you to hard-code a mailroute; other MTA vendors have their own equivalent).

[quoted text, click to view]

You lost me on that one.

What I have is 2 DNS servers (Neptune and Earth)

My Web Server is on Mars. I have SMTP configured on this machine from IIS6.
And my DNS entry is pointing at either Neptune or Earth - doesn't matter
which, I get the same result.

Earth also has Exchange running on it (although there is no MX record
anywhere pointing at it as of 2 weeks ago).

Our email is now handled by a hosted company and our MX record at Network
solutions points at the hosted companies server (not our servers anymore).

On Mars I have a program that sends messages fine to anyone. But when it
sends a message to anyone in our domain - it seems to go to our Exchange
server on Earth and puts it in our mailbox there instead of the mailboxes at
our hosted site.

Also on Mars, I try to TELNET to anyone I get a message that it can't relay
to that address. But my email program (which uses localhost as its smtp
server), which is also on Mars, sends the email fine:

Sending to someone outside our company:
telnet mars 25
220 MARS.ftsol.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 re
ady at Tue, 26 Jun 2007 08:44:25 -0700
helo
250 MARS.ftsol.com Hello [10.0.0.25]
mail from:tj@ftsol.com
250 2.1.0 tj@ftsol.com....Sender OK
rcpt to:tjay@dslextreme.com
550 5.7.1 Unable to relay for tjay@dslextreme.com

Sending to someone inside our company:
telnet mars 25
220 MARS.ftsol.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 re
ady at Tue, 26 Jun 2007 08:44:25 -0700
helo
250 MARS.ftsol.com Hello [10.0.0.25]
mail from:noreply@ftsol.com
250 2.1.0 tj@ftsol.com....Sender OK
rcpt to:tj@ftsol.com
550 5.7.1 Unable to relay for tj@ftsol.com

But these same address on the same machine in my program seem to work fine,
except for Exchange on Earth grabbing them.

Tom
[quoted text, click to view]

Also, in the Relay Restrictions screen of the SMTP Virtual Server Properties
on Mars I have Relay set as 127.0.0.1 and checked "Allow all computers which
successfully authenticate to relay, regardless of the list above".

So I assume I shouldn't get this error message below. I get this regardless
of whether I "Telnet Mars 25" from my workstation (where my credentials are
the same as the administrator on the Mars machine) or from Mars itself.

Tom

[quoted text, click to view]

[quoted text, click to view]

Sure you should -- if you don't come from 127.0.0.1 and you aren't
authenticated. See my comment in the other post.

[quoted text, click to view]

I doubt you're passing SMTP AUTH creds over Telnet, so the credentials
are actually immaterial.

[quoted text, click to view]

You didn't document your setup completely the first time around, so
any mention of a "dormant" Exchange installation tipped me off to a
possible problem: Exchange will not pass on messages addressed to a
domain it knows as local to its organization.

Yes, this problem would only occur if mail were going to the Exchange bo=
x
in the *expectation* that it would be relayed. In other words, if
there is a mailroute for your domain -- any mailroute, whether
standard DNS MX-based or a static mailroute of some sort -- that
causes the mail to go "through" 'Earth', it will *stay* at 'Earth'.

[quoted text, click to view]

Well, no. What you have are 2 servers running _various_ daemons. You
should *not* ignore the fact that you have Exchange and IIS SMTP
installed on one of them, because that is a "hot zone" for
troubleshooting.

[quoted text, click to view]

When you directly query 'Neptune' or 'Earth' via NSLOOKUP for the MX
record, what do you get?

Are there remote domains set up within IIS SMTP on 'Mars'?

Is there a Smart Host set up within IIS SMTP on 'Mars'?

[quoted text, click to view]

If true, then what you are saying is that neither 'Neptune' or 'Earth'
_as DNS servers_ think that Earth handles mail for your domain. That
means that if there is still a mailroute to Earth, it is a static
mailroute.

As mentioned before, a Remote Domain in IIS SMTP creates a static
mailroute that can override DNS. An unexpected HOSTS entry, or
incorrect DNS A in an internal zone, can create an unwanted mailroute
as well (even if DNS MX records are correct).

Another way you can get a non-MX mailroute is if your IIS 6 SMTP on
'Mars' is using 'Earth' as its Smart Host. A Smart Host becomes the
next hop for all mail. If that Smart Host happens to think a certain
domain is local, it will never forward the mail off-box. Be sure this
is not the case.

[quoted text, click to view]

Loopback Address !=3D IP Address.

If you connect to 'Mars' via 127.0.0.1, your source address is
127.0.0.1. If you connect via 1.2.3.4, your source address is 1.2.3.x.

If you only allow relay for 127.0.0.1, that would explain the
different results.

[quoted text, click to view]

You didn't document your setup completely the first time around, so
any mention of a "dormant" Exchange installation tipped me off to a
possible problem: Exchange will not pass on messages addressed to a
domain it knows as local to its organization.

I understand that if you have Exchange on your DNS server that you don't
need an MX record. But if I point at Neptune as the DNS Server why does
Exchange still pick it up when Exchnage is on Earth?

Yes, this problem would only occur if mail were going to the Exchange box
in the *expectation* that it would be relayed. In other words, if
there is a mailroute for your domain -- any mailroute, whether
standard DNS MX-based or a static mailroute of some sort -- that
causes the mail to go "through" 'Earth', it will *stay* at 'Earth'.

What if the MX record on Earth says to go to x.net (outside my network), are
you are saying that Exchange will still grab it?

[quoted text, click to view]

Well, no. What you have are 2 servers running _various_ daemons. You
should *not* ignore the fact that you have Exchange and IIS SMTP
installed on one of them, because that is a "hot zone" for
troubleshooting.

I have Exchange on Earth and nothing on Neptune - what do you mean hot zone.

Actually, on Neptune SMTP seems to be there - even though we didn't install
it directly. What is interesting here is that even though SMTP is install -
IIS is not showing it in the IIS Management Console (even after we
uninstalled and reinstalled it).

[quoted text, click to view]

When you directly query 'Neptune' or 'Earth' via NSLOOKUP for the MX
record, what do you get?

Can't check what was there before as we have already added an MX record into
our DNS server already. It is now:
*********************************************
C:\Documents and Settings\ts>nslookup
Default Server: neptune.fs.com
Address: 10.0.0.8

[quoted text, click to view]
Server: neptune.fs.com
Address: 10.0.0.8

fs.com MX preference = 10, mail exchanger = smtp15.msoutlookonline.net
smtp15.msoutlookonline.net internet address = 207.5.72.90
*************************************************************

Are there remote domains set up within IIS SMTP on 'Mars'?

No. Just one domain.

Is there a Smart Host set up within IIS SMTP on 'Mars'?

No. Not sure what this does - but it isn't set.

[quoted text, click to view]

If true, then what you are saying is that neither 'Neptune' or 'Earth'
_as DNS servers_ think that Earth handles mail for your domain. That
means that if there is still a mailroute to Earth, it is a static
mailroute.

Correct. There is no MX record at all. So that means it is a static
mailroute? What does that mean? How does it know to go to Earth for the
mailroute? Is it something that Exchange does to tell the network that
Exchange is the mailroute?

As mentioned before, a Remote Domain in IIS SMTP creates a static
mailroute that can override DNS. An unexpected HOSTS entry, or
incorrect DNS A in an internal zone, can create an unwanted mailroute
as well (even if DNS MX records are correct).

How does an A record in DNS create an unwanted mailroute?

Another way you can get a non-MX mailroute is if your IIS 6 SMTP on
'Mars' is using 'Earth' as its Smart Host. A Smart Host becomes the
next hop for all mail. If that Smart Host happens to think a certain
domain is local, it will never forward the mail off-box. Be sure this
is not the case.

I don't have Smart Host set up - I don't think.

[quoted text, click to view]

Loopback Address != IP Address.

If you connect to 'Mars' via 127.0.0.1, your source address is
127.0.0.1. If you connect via 1.2.3.4, your source address is 1.2.3.x.

If you only allow relay for 127.0.0.1, that would explain the
different results.

I figured that one out. I had 127.0.0.1 as the only address that can relay
from Mars. That was really confusing. I guess I don't understand relaying
well enough.

If I didn't have the relay entry set up and tried to send mail to anyone
(inside our network or not) it didn't go. If I am on Mars and try to send
mail from telnet, it would get an Unable to relay message when I put in the
"rcpt to" entry - even if going to someone inside our internal network. How
am I relaying if I am on the same machine as the SMTP server?

Thanks,

Tom


--Sandy

[Can you please use a newsreader that is capable of quoting? Your
software interleaves quotes and new text at the same level, which is
very difficult to read.]

[quoted text, click to view]

I didn't say that if you have Exchange on your DNS server you don't
need an MX record. I implied that if you have Exchange on your *SMTP*
server, you don't need an MX record, because all the mail going
through that server will automatically be sorted by Exchange into
'local' and 'remote' bins.

Nonetheless, you *should* use valid MX records internally unless
technical circumstances make it easier to only publish MX externally
and use static mailroutes internally. The advantage of using MX
records when you can is that the DNS MX failover algorithm can be
useful for internal fault-tolerance, while static mailrouting often
does not allow you to have a list of preferred and alternate servers.
But this is sort of off-topic for now.

[quoted text, click to view]

No, the machine running Exchange has no ability to reach out and
proactively grab anything: mail needs to be going to it because of a
published mailroute. What I'm continually pointing out -- and this may
not in fact be your problem here -- is that people who think they have
a 'dormant' or 'retired' messaging platform are often surprised that
that platform still remembers its local domains when you try to send
through the server that is (still) hosting the platform.

This applies to Exchange, Notes... any messaging suite.

[quoted text, click to view]

As above.

[quoted text, click to view]

Lo and behold! So both 'Neptune' and 'Earth' are not DNS servers
proper. They are multi-purpose servers. And they both have a hidden
installation of IIS SMTP: that's pretty suspicious that they both
would have this problem. The metabase is not going to spontaneously
corrupt on both machines. Are you sure that you never installed
Exchange on 'Neptune' as well (even if you later uninstalled it)? This
would account for the hidden IIS Virtual Server. The hiding is a
feature of the Exchange install.

How many Exchange servers do you see in System Manager?

[quoted text, click to view]

Okay, this result solidifies that your DNS is in order as seen from
'Mars'. The mailrouting must be outside of DNS (as expected).

[quoted text, click to view]

The (Default) Local domain, you mean?

[quoted text, click to view]

Okay, good. (A Smart Host is what you use when, for one example, you
want to consolidate direct remote delivery on one central outbound
SMTP server. You have web servers, etc. set their Smart Host to the
outbound SMTP server, which means they won't attempt direct remote
delivery to any outside domains, they'll just pass on the message to
the outbound SMTP server to do it for them because the central server
is 'smarter'.)

[quoted text, click to view]

Exchange can't 'tell' the network anything proactively, can't grab
anything off the wire. With a simple Exchange Org _where no other
servers except the Exchange box ever act as SMTP client or server_,
DNS is used for mailrouting.

However, as installations get more complex and more machines (like web
servers) act as SMTP clients and servers, admins often create static
mailroutes either to save bandwidth, simplify mailflow, or, in one
common case, to enable the use of private IP ranges (when the DNS
entries point to public IPs, firewalls can prevent "loopback" traffic
from entering on the internal interface, going to those public IPs on
the external i/f, and reentering the firewall, so the firewall needs
to be avoided by hardcoding mailroutes using private IPs).

[quoted text, click to view]

MX records simply point to hostnames. The hostname may not be resolved
on your DNS server, even if the MX record is. (If you don't host the
DNS zone that the MX record is in, it will by definition not be
resolved authoritatively by your DNS server.)

So if you have 'domain.com MX mail.otherdomain.com' everything might
look fine. And you look up mail.otherdomain.com on your DNS server and
(to you) it shows 1.2.3.4 as you expect.

But if the server who looks up your MX record to deliver messages has
a 'more local' entry for mail.otherdomain.com than the one you test
with, they'll use what _they_ think mail.otherdomain.com is. If the
server has a HOSTS entry, or if the server's DNS resolver has a
cached, broken, and/or alternate copy of the otherdomain.com zone,
they may resolve mail.otherdomain.com to a different IP than you
expect.

[quoted text, click to view]

It's easy to tell: Delivery-Advanced-Smart Host.

[quoted text, click to view]

Whether you are relaying or not has _nothing_ to do with your source
IP being the loopback 127.0.0.1, the primary IP address assigned to
the NIC, or any other IP address.

You are relaying if you are sending mail with a RCPT TO: domain
(a.k.a. envelope recipient domain) that is not known as a local domain
to your SMTP server. Local domains are those domains for which the
_mailboxes_ are assumed to exist on the SMTP server itself... those
domains for which there is no further SMTP 'hop' before delivery to an
end user.

Actually, this reader seems to have dropped that for some reason and I can't
seem to figure out where to set it. I am using Outlook Express at the
moment.

Tom
[quoted text, click to view]
in message news:op.tuli57v96c17zw@gw02.broadleaf.local...
[Can you please use a newsreader that is capable of quoting? Your
software interleaves quotes and new text at the same level, which is
very difficult to read.]

[quoted text, click to view]

I didn't say that if you have Exchange on your DNS server you don't
need an MX record. I implied that if you have Exchange on your *SMTP*
server, you don't need an MX record, because all the mail going
through that server will automatically be sorted by Exchange into
'local' and 'remote' bins.

Nonetheless, you *should* use valid MX records internally unless
technical circumstances make it easier to only publish MX externally
and use static mailroutes internally. The advantage of using MX
records when you can is that the DNS MX failover algorithm can be
useful for internal fault-tolerance, while static mailrouting often
does not allow you to have a list of preferred and alternate servers.
But this is sort of off-topic for now.

[quoted text, click to view]

No, the machine running Exchange has no ability to reach out and
proactively grab anything: mail needs to be going to it because of a
published mailroute. What I'm continually pointing out -- and this may
not in fact be your problem here -- is that people who think they have
a 'dormant' or 'retired' messaging platform are often surprised that
that platform still remembers its local domains when you try to send
through the server that is (still) hosting the platform.

This applies to Exchange, Notes... any messaging suite.

[quoted text, click to view]

As above.

[quoted text, click to view]

Lo and behold! So both 'Neptune' and 'Earth' are not DNS servers
proper. They are multi-purpose servers. And they both have a hidden
installation of IIS SMTP: that's pretty suspicious that they both
would have this problem. The metabase is not going to spontaneously
corrupt on both machines. Are you sure that you never installed
Exchange on 'Neptune' as well (even if you later uninstalled it)? This
would account for the hidden IIS Virtual Server. The hiding is a
feature of the Exchange install.

How many Exchange servers do you see in System Manager?

[quoted text, click to view]

Okay, this result solidifies that your DNS is in order as seen from
'Mars'. The mailrouting must be outside of DNS (as expected).

[quoted text, click to view]

The (Default) Local domain, you mean?

[quoted text, click to view]

Okay, good. (A Smart Host is what you use when, for one example, you
want to consolidate direct remote delivery on one central outbound
SMTP server. You have web servers, etc. set their Smart Host to the
outbound SMTP server, which means they won't attempt direct remote
delivery to any outside domains, they'll just pass on the message to
the outbound SMTP server to do it for them because the central server
is 'smarter'.)

[quoted text, click to view]

Exchange can't 'tell' the network anything proactively, can't grab
anything off the wire. With a simple Exchange Org _where no other
servers except the Exchange box ever act as SMTP client or server_,
DNS is used for mailrouting.

However, as installations get more complex and more machines (like web
servers) act as SMTP clients and servers, admins often create static
mailroutes either to save bandwidth, simplify mailflow, or, in one
common case, to enable the use of private IP ranges (when the DNS
entries point to public IPs, firewalls can prevent "loopback" traffic
from entering on the internal interface, going to those public IPs on
the external i/f, and reentering the firewall, so the firewall needs
to be avoided by hardcoding mailroutes using private IPs).

[quoted text, click to view]

MX records simply point to hostnames. The hostname may not be resolved
on your DNS server, even if the MX record is. (If you don't host the
DNS zone that the MX record is in, it will by definition not be
resolved authoritatively by your DNS server.)

So if you have 'domain.com MX mail.otherdomain.com' everything might
look fine. And you look up mail.otherdomain.com on your DNS server and
(to you) it shows 1.2.3.4 as you expect.

But if the server who looks up your MX record to deliver messages has
a 'more local' entry for mail.otherdomain.com than the one you test
with, they'll use what _they_ think mail.otherdomain.com is. If the
server has a HOSTS entry, or if the server's DNS resolver has a
cached, broken, and/or alternate copy of the otherdomain.com zone,
they may resolve mail.otherdomain.com to a different IP than you
expect.

[quoted text, click to view]

It's easy to tell: Delivery-Advanced-Smart Host.

[quoted text, click to view]

Whether you are relaying or not has _nothing_ to do with your source
IP being the loopback 127.0.0.1, the primary IP address assigned to
the NIC, or any other IP address.

You are relaying if you are sending mail with a RCPT TO: domain

[quoted text, click to view]

Tools | Options | Send tab, then under News Sending Format click Plain Text
Settings, then check the box that reads "Indent the original text with
(dropdown - choices are > | :) when replying or forwarding"