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

[ Post a follow-up to this message ]

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

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).

--Sandy

[ Post a follow-up to this message ]

"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote
in message news:op.tuikxxax6c17zw@gw02.broadleaf.local... 
>
> 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.

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
>
> 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).
>
> --Sandy

[ Post a follow-up to this message ]

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

"tshad" <t@home.com> wrote in message
news:%23VUGmwAuHHA.3480@TK2MSFTNGP04.phx.gbl...
>
> "Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote
> in message news:op.tuikxxax6c17zw@gw02.broadleaf.local... 
>
> 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 
>
>

[ Post a follow-up to this message ]

> So  I  assume  I  shouldn't get this error message below.

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.

> 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.

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

--Sandy

[ Post a follow-up to this message ]

> You lost me on that one.

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'.

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

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.

> 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 matt=
er
> which, I get the same result.

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'?

> ...there  is no MX record anywhere pointing at [Earth] as of 2 weeks
> ago

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.

> 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:

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.

--Sandy

[ Post a follow-up to this message ]

"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote
in message news:op.tuj9hinp6c17zw@gw02...
> You lost me on that one.

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?

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

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).

> 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.

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

> set type=mx
> fs.com
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.

> ...there  is no MX record anywhere pointing at [Earth] as of 2 weeks
> ago

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.

> 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:

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

[ Post a follow-up to this message ]

[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.]

> 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?

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.

> 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?

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.

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

As above.

>  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).

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?

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

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

> Are there remote domains set up within IIS SMTP on 'Mars'?
>
> No.  Just one domain.

The (Default) Local domain, you mean?

> Is there a Smart Host set up within IIS SMTP on 'Mars'?
>
> No.  Not sure what this does - but it isn't set.

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'.)

> 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?

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).

> 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?

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.

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

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

> 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?

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.

All other domains should be considered remote.

Your  SMTP  server has the capacity to relay for remote domains, which
include hardcoded 'Remote Domains' in IIS SMTP as well as the implicit
'All Other Domains'. The server may require that you come from a given
IP   address   to   relay  to  those  domains,  or  that  you  have  a
username/password  to  relay  to  those domains... but what determines
whether  you are relaying is not what IP you are coming from, but what
domain you are going to.

--Sandy

[ Post a follow-up to this message ]

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
"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote
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.]

> 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?

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.

> 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?

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.

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

As above.

>  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).

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?

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

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

> Are there remote domains set up within IIS SMTP on 'Mars'?
>
> No.  Just one domain.

The (Default) Local domain, you mean?

> Is there a Smart Host set up within IIS SMTP on 'Mars'?
>
> No.  Not sure what this does - but it isn't set.

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'.)

> 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?

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).

> 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?

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.

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

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

> 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?

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.

All other domains should be considered remote.

Your  SMTP  server has the capacity to relay for remote domains, which
include hardcoded 'Remote Domains' in IIS SMTP as well as the implicit
'All Other Domains'. The server may require that you come from a given
IP   address   to   relay  to  those  domains,  or  that  you  have  a
username/password  to  relay  to  those domains... but what determines
whether  you are relaying is not what IP you are coming from, but what
domain you are going to.

--Sandy

[ Post a follow-up to this message ]

"tshad" <t@home.com> wrote in message
news:OlFqtKeuHHA.3668@TK2MSFTNGP03.phx.gbl... 
[vbcol=seagreen]
> 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.

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"

[ Post a follow-up to this message ]