Having problems hosting multiple SMTP servers on Windows 2..

Hello Sandy!

Thanks for your reply! Well, I'm a little confused by your answer. The
short reason is that I'm clearly not as knowlegable as you in this
stuff. I'm not exactly sure what I need to do to fix this? When you
say "you need to match the EHLO (the VS FQHN) to the PTR for the
originating IP" I'm not sure how to do that? Part of my problem is
that don't really understand what EHLO means..(I think I understand
most, but not all, of the remaining part of your reply). I'm running
Windows 2000 servers and I have my own (2) name servers. Do I need to
make dns changes? Or do I need to re-think which domains I'm using to
send the emails from the website (i'm not married to
smtp.clickforlessons.com - i just created it recently anyway)

It's funny you mentioned that it would use the IP from the NIC, cuz
that's exactly what it's doing. In fact, I have a dual NIC server and
it's using the 2 IPs that are bound to the each NIC. It actually uses
either of those two (rather unpredictibly). I actually started to type
that fact in my original message but later removed it thinking how
crazy I sounded... Anyway, I can't believe it's switching IP's like
that, isn't that the point of SMTP (to keep the IP that you have setup
in the SMTP server)?

I feel as if I'm really close to resolving this...

Thanks!
Dave
 >> Stay informed about: Having problems hosting multiple SMTP servers on Windows 2.. 

>When you say "you need to match the EHLO (the VS FQHN) to the PTR for the
>originating IP" I'm not sure how to do that? Part of my problem is
>that don't really understand what EHLO means...

EHLO <fully_qualified_hostname_of_client>

is the RFC-specified way an (E)SMTP client says, "Hello, I am
<fully_qualified_hostname>" when it's connecting to a remote server.

This command is sent right after the remote server has sent its own
"Hello," the RFC-specified banner that looks like

220 <fully_qualified_hostname_of_server>

So the text after the 220 is referred to in shorthand as "the 220,"
while the text after the EHLO is referred to as "the EHLO."

Figuring out what each of these strings _should_ be in a given SMTP
conversation is actually quite easy, but people seem to find
innumerable ways to muck it up. And IIS' habit of "rounding down"
to the primary IP for outbound connections encourages such screwups.
Your confusion is understandable.

As I was saying earlier, the client's EHLO should be the canonical
(e.g., "primary" or "true") hostname associated with the IP that the
client uses to connect. The published PTR of that IP is accepted to
be the canonical hostname for these purposes (that's essentially what
a PTR "is," anyway). Since, as you now know, the IP used to connect
will be the primary IP bound to a NIC, and not its secondary/tertiary
IPs, you need to put the primary IP's PTR in IIS' 'Fully Qualified
Domain Name' field under Properties-Delivery-Advanced Delivery. This
field is used as the EHLO. It is a misnomer, as I see it, since the
field as used by the SMTP protocol refers not to a DNS zone/domain but
to a hostname, but I digress. . . for this discussion, "FQDN" =
"FQHN."

>(I think I understand>most, but not all, of the remaining part of your reply). I'm running
>Windows 2000 servers and I have my own (2) name servers. Do I need to
>make dns changes? Or do I need to re-think which domains I'm using to
>send the emails from the website (i'm not married to
>smtp.clickforlessons.com - i just created it recently anyway)

You just need to be aware of your IP binding order and determine
whether you want to reshuffle the IPs so that a new IP is the primary
one, or leave the current one in place and match to that. Whichever
IP is primary becomes the IP of _outgoing_ connections from the SMTP
virtual server (and, in fact, of outgoing connections from _any_ SMTP
virtual server bound to any IP on that NIC). So, think about how the
machine will look to the outside. If the primary IP's PTR starts with
"www" in it, that might look less professional than having the primary
IP be one that has "smtp" in its PTR. But either one will work fine,
and no remote server will make any value judgments, as long as the PTR
for that IP matches the EHLO sent -> the PTR has a corresponding A
record -> that A record points back to the IP. That's a roundtrip.

But see below for the other issues vis-a-vis physically multihomed
servers.

>It's funny you mentioned that it would use the IP from the NIC, cuz
>that's exactly what it's doing.

Yep, I knew that right away.

>In fact, I have a dual NIC server and it's using the 2 IPs that are bound to the each NIC. It actually uses
>either of those two (rather unpredictibly). I actually started to type
>that fact in my original message but later removed it thinking how
>crazy I sounded... Anyway, I can't believe it's switching IP's like
>that, isn't that the point of SMTP (to keep the IP that you have setup
>in the SMTP server)?

Well, yes and no. The main purpose -- in fact, the only practical
purpose when you have one NIC -- of running multiple IP-bound virtual
servers under IIS SMTP is to have many different _listening_ IPs that
can each use the well-known port 25, outside servers can connect
directly to each one, and each one can have its own policies for
message size, allowed senders/recipients, and so on. That's a great
feature. But it doesn't have any guaranteed relevance to the IP used
for _outgoing_ connections.

What you're seeing overall is a combination of these two factors:

1) Generic client socket IP binding in IIS. Outbound sessions from
IIS use a classic systems programming directive called INADDR_ANY.
This instructs the TCP/IP stack to bind to the primary IP (well,
technically, it allows the TCP/IP stack to choose its own IP, instead
of it being specifically dictated by the application, and the stack's
default behavior is as observed). Windows applications don't have to
do this: it's quite possible for even a basic TCP/IP app to request a
client-side binding to a particular IP. But IIS does not, so you get
that "rounding down" effect.

2) Automatic interface metrics. Each physical interface in Windows
has a weight assigned to it that will dictate its preference when
routing tables do not otherwise apply. You have your two NICs both
set to "automatic metric." This means that you will see both NICs --
that is, each one's primary IP -- used for outbound connections in a
seemingly willy-nilly fashion. That's the "crazy" behavior you're
seeing, and you are really seeing it! The only way to control this is
to manually set metrics for the interfaces, so that only one will be
used for outbound connections to unknown remote servers.

This may seem contrary to an original idea you had that you would get
some simple load-balancing going over both NICs. You should probably
rethink this; it's not quite that simple.

First of all, if your NIC vendor offers any kind of
bonding-plus-failover "team" option (I know Intel, Broadcom, and 3Com
do), you can just create a "team" that will then present itself as one
virtual interface, with only one list of IPs. That will establish
that you will only have one possible outgoing IP, and you'll still get
load-balancing with failover. If you can do this, I'd say go for it.

Second option would be to dedicate one NIC to all incoming connections
traffic and the other to outgoing connections. Set up one NIC with an
interface metric of 1 and the other with metric 2. Bind just one IP to
the one with metric 1. That becomes your outgoing IP, because the
stack will always choose that NIC for outgoing connections. Bind your
other IPs to the NIC with metric 2. This will be the NIC that
receives incoming connections to those IPs. This will work, but it's
certainly non-standard. I'd really try to "virtualize" the NICs into
a team first.

Let me know if this pretty technical stuff is making you feel worse or
better.

--Sandy
 >> Stay informed about: Having problems hosting multiple SMTP servers on Windows 2..