How can I configure IIS 6.0 SMTP to use different TCP Ports for multiple remote domains?
Peter Gibbons
Kind regards,
Peter
Sanford Whiteman
server. The hacks I could see are
ￜ create a different virtual server for each remote domain
ￜ if you know the remote IP addresses, hard-code the mxroutes and use
local port redirection to bounce, for example, 127.0.0.1:2025 to
10.20.30.40:2025, 127.0.0.2:2025 to 20.30.40.50:2026, etc.
-- Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
------------------------------------
Grant Taylor
> How can I configure IIS 6.0 SMTP to use different TCP Ports for
> multiple remote domains?
Carefully.
In short, you configure your Default SMTP Virtual Server to route the
domain(s) that you want to change the destination port to new SMTP
Virtual Server(s) that is configured to connect to the desired
destination port.
I did some testing in a (Windows Server 2003 Web Edition) VM and have
verified that things work (up to the point that messages get dropped in
the appropriate mail queue for the given destination port). (I did not
feel like setting up DNS, so I did everything by IP and tested by
verifying that test messages ended up as .msg files in the appropriate
queue directories.)
In my testing, I was able to send test messages (manually via telneting
to port 25 on localhost and speaking SMTP directly to IIS) and have them
end up in the respective queues depending on the destination domain name.
To do this, I created additional IIS SMTP Servers bound to independent
IPs and configured them to connect to different destination ports. Then
I added "Remote" domains to my Default SMTP Virtual Server and
configured them to use the new IIS SMTP Servers as their smart hosts.
To duplicate my setup, use the following steps.
1) Bind an additional IP to a network adapter for the new
destination port. (I used a new RFC 1918 / 3330 private IP addresses
bound to the Microsoft Loopback Adapter.)
2) Create a new "Home directory" for the new SMTP Virtual Server you
are creating. (I used "C:\Inetpub\mailroot.<port>".)
3) Create a new SMTP Virtual Server
a) Name the new SMTP Virtual Server something appropriate. (I
used "<port>".)
b) Select the new IP address that you bound in step 1.
c) Use the Home directory that you created in step 2.
d) Enter an appropriate Domain name to describe the SMTP Virtual
Server. (I used "<port>".)
e) Configure the new SMTP Virtual Server to connect to the
desired destination port.
4) Add a new "Remote" domain to your Default SMTP Virtual Server.
a) Name the new "Remote" domain name something appropriate. (I
would recommend the actual domain name that you want to route to the
alternate port.)
b) Configure the domain to "Forward all mail..." to SMTP Virtual
Server that you created in step 3. (I would use the raw IP selected in
step 3b in square brackets, i.e. "[192.168.144.120]", so that IIS does
not try to do a DNS lookup to find the smart host (SMTP Virtual Server).)
Repeat step 3 for all additional destination ports that you want to support.
Repeat step 4 for all SMTP Virtual Servers that you want to route
domains to an alternate port. (This is why I chose to name the SMTP
Virtual Server created in step 3 "<port>" that it is for as as many SMTP
Virtual Servers can use the new ""port that you want to.)
Grant. . . .
Sanford Whiteman
I'll throw in that TCP port redirection (my second bullet) is much easier
to configure than multiple VSs, plus it skips the double-spooling when you
route between VSs as well as the SMTP convo overhead. (Not that there
aren't collateral advantages once you have dedicated VSs for what I
imagine is a specialized B2B application of some sort.)
Port redirection method:
[1] netsh portproxy add v4tov4 listenaddress=127.0.0.1 listenport=2525
connectaddress=mx.example1.com connectport=1111
netsh portproxy add v4tov4 listenaddress=127.0.0.2 listenport=2525
connectaddress=mx.example2.com connectport=2222
netsh portproxy add v4tov4 listenaddress=127.0.0.3 listenport=2525
connectaddress=mx.example3.com connectport=3333
etc....
[2] set up IIS Remote Domain for example1.com to send to [127.0.0.1]
set up IIS Remote Domain for example2.com to send to [127.0.0.2]
set up IIS Remote Domain for example3.com to send to [127.0.0.3]
etc....
The "con" of portproxy redirection is that it doesn't continually consult
DNS (it will resolve a hostname when you insert a mapping, but actually
uses the IP). So if a remote server changes IPs, you have to do an `ipv6
renew` to pick up the new IP. But the remote addresses may be largely
static and/or completely under the OP's control anyway; it's impossible to
know what the deeper meaning is of such a request. Guess we'll wait to
hear what the OP says in return.
-- Sandy
Grant Taylor
> Nice writeup, Grant.
Thank you.
> I'll throw in that TCP port redirection (my second bullet) is much
> easier to configure than multiple VSs, plus it skips the double-spooling
> when you route between VSs as well as the SMTP convo overhead.
Agreed.
I was originally thinking rinetd under unix. I was not aware that
similar technology was built in to Windows.
However, what version of Windows is portproxy built in to? (My XP Pro
does not have portproxy and I've currently re-loading my test VM.)
Does it require that the system has IPv6 support?
> Port redirection method:
>
> [1] netsh portproxy add v4tov4 listenaddress=127.0.0.1 listenport=2525
> connectaddress=mx.example1.com connectport=1111
I'd think that the listenport would be 25 as part of the OP's goal is to
have the VS talk to different ports, so having it talk to something
other than 25 out of the gate would sort of make this discussion moot. ;)
> [2] set up IIS Remote Domain for example1.com to send to [127.0.0.1]
I believe this is the same as what I was doing in step 4, correct?
> The "con" of portproxy redirection is that it doesn't continually
> consult DNS (it will resolve a hostname when you insert a mapping, but
> actually uses the IP). So if a remote server changes IPs, you have to
> do an `ipv6 renew` to pick up the new IP. But the remote addresses may
> be largely static and/or completely under the OP's control anyway; it's
> impossible to know what the deeper meaning is of such a request. Guess
> we'll wait to hear what the OP says in return.
This is a common problem when dealing with tools / utilities that
operate on layer 3. They tend to resolve names to IPs and operate with
the IP. Though, this is fairly simple to resolve / work around.
It might also be possible to do a scheduled task that preemptively does
an "ipv6 renew" to re-resolve names to IPs before there is a problem.
Grant. . . .
Sanford Whiteman
> does not have portproxy and I've currently re-loading my test VM.)
You just have to install IPv6. Any XP/2003+ machine supports it.
> I'd think that the listenport would be 25 as part of the OP's goal is to
> have the VS talk to different ports, so having it talk to something
> other than 25 out of the gate would sort of make this discussion moot.
> ;)
Well, yes, *if* it has to talk to any normal public SMTP servers on WKP
25. I don't know what the actual setup is here.
> It might also be possible to do a scheduled task that preemptively does
> an "ipv6 renew" to re-resolve names to IPs before there is a problem.
Could work depending on frequency, though I would say that if one expects
constant change then TCP redirection falls behind a solution that can use
the MX algorithm.
Grant Taylor
> You just have to install IPv6. Any XP/2003+ machine supports it.
I will try that.
Thank you for the pointer. :)
I will say that I don't know how fond I am of the idea that another
protocol has to be installed to use portproxy. On the other hand if
IPv6 is installed, this sure is convenient.
> Well, yes, *if* it has to talk to any normal public SMTP servers on WKP
> 25. I don't know what the actual setup is here.
I think that's a big /if/. I can't think of any reason why there would
be an IIS SMTP Virtual Server that would not be talking to destination
port 25 unless there is another server in the organization that handles
that traffic. Though if there is another server in the organization
that is handling generic SMTP traffic that has been configured to route
specific domains to the SMTP Virtual Server(s) that we are talking
about, I would expect that there is something a bit more complex than
simple IIS SMTP Virtual Servers, say Exchange with SMTP Connectors.
Further if something like Exchange with SMTP Connectors is in place,
this entire exercise becomes fairly moot as it can be configured to do
this its self with out much trouble.
We do need to know more about the OPs environment to have more of a
discussion on the particulars.
> Could work depending on frequency, though I would say that if one
> expects constant change then TCP redirection falls behind a solution
> that can use the MX algorithm.
Agreed.
Grant. . . .
Sanford Whiteman
Maybe IPv6 sounds like IPX/SPX right now, but soon enough it'll be crazy
to have internet-connected hosts without it. :) It's been enabled on all
of our servers just by rote for a while. Anyway, you don't have to
perform any configuration of IPv6 to run portproxy.
> I think that's a big /if/.
You're probably right. Doesn't matter what the listenport is, and 25
would have been more informative.
Still waiting to hear from the OP. Don't you love when that happens?
Grant Taylor
> Maybe IPv6 sounds like IPX/SPX right now, but soon enough it'll be crazy
> to have internet-connected hosts without it. :) It's been enabled on
> all of our servers just by rote for a while. Anyway, you don't have to
> perform any configuration of IPv6 to run portproxy.
Heh. I don't have a problem with IPX/SPX at all. (Just NetBEUI)
I'm a minimalist and tend not to run something unless it's explicitly
needed.
> You're probably right. Doesn't matter what the listenport is, and 25
> would have been more informative.
*nod*
> Still waiting to hear from the OP. Don't you love when that happens?
Yep.
Depending on the thread and how involved I've gotten in it, I've been
known to send emails directly to the purported address of the OP (if it
was remotely valid).
Grant. . . .
Sanford Whiteman
What I meant is that IPv6 may seem as before-its-prime as IPX/SPX is
past-its-prime, but its time is coming -- we have already been warned by
one of our (financial) trading partners that our extranet connections need
to support IPv6 by 2011.
Peter Gibbons
IPv6 has to be installed but does not need to be bound to any adapter.
- Peter
Peter Gibbons
that ist exactly what I was looking for.
My sincere gratitude especially to you and Grant also for the follow-ups.
Best regards,
Peter
Peter Gibbons
your guess is correct. It is a combination of DMZ/Firewall and Exchange
Connectors configuration that brought this up.
- Peter
Sanford Whiteman
Great!
-- Sandy