dual homing with a new domain 1

[reallywildstuff]

This problem involves hosting multiple domains on a dual-homed Exchange 2000 server. I am not a novice but have not setup a dual-homed environment on Exchange before. On top of that, it's not about just swapping a working single-nic solution to dual-nic, it's about adding another domain at the same time. Details follow.

Exchange 2000 has a nic with an internal LAN IP address and a recipient policy for "@existing.com". There is an SMTP Virtual Server defined on the internal LAN IP - this SMTP server sends mail out the door sometimes. It also passes mail back and forth between people inside the LAN.

It does NOT host any Internet e-mail - that task is handled by a third-party hosting company. Outlook clients inside the LAN establish SMTP and POP sessions with the third party provider to collect their Internet E-mail. I did _not_ set this up this way, this is what I'm trying to fix.

Looking for a phased-in solution that incorporates our firewall's capabilities and a second nic in the Exchange box (i am aware of the security risks associated with having Exchange on the Internet, everybody's just going to have deal with that for the moment, maybe I'll put a Linux spam killer in-between later). I would like to setup a different test domain to test the Exchange server's ability to host Internet mail and deliver it in the dual-homed topology.

To that end:

a) a second nic with a public ip address on the DMZ behind our firewall
b) a test domain (test.com)
c) MX 10 record for test.com = mail.test.com
d) A record of mail.test.com = public IP of the 2nd nic

I can ping the A record by name and IP. I have allowed traffic on port 25 into and out of the DMZ. I am certain that I have seutp the public routing part of this equation properly.

When I setup a virutal SMTP server as "mail.test.com" and bind it to the public IP I can get responses out of the mail server using web-based open-relay and "does my mail server work?"-type tools on the web - it responds, doesn't relay etc.

However, I can't ever get it to actually accept and deliver mail - I get a return NDR "no such user". I am unable to successfully deliver mail to myself@test.com despite:

a) setting up an SMTP connector between the two SMTP servers...I am not sure if I'm doing this correctly, should the address space be * or test.com or...?

Also, "bridgehead" refers to a "military fortification that protects the end of a bridge that is closest to the enemy", strictly by definition it seems like "Local Bridgeheads" on the SMTP connection should be the Public IP Server, but after reading Micro$oft's documentation I'm now thinking that "Local Bridgehead" = Internal SMTP server...correct?

During one of my tests of the SMTP connector part of the equation, I managed to stop the internal SMTP server from being able to push any mail out the door at all. I had to tear all my changes down because I didn't know what the problem was.

b) manually defining a new e-mail address @test.com on my AD account

c) in addition to a) above, setting up a new recipient policy.

Twice now I have tried to setup @test.com as a recipient policy that only applies to my AD account, however it invariably creates @test.com addresses for everyone in the OU and better than _that_ it makes the @test.com address the default e-mail (so people come screaming down the hall "this e-mail I sent says my address is username@test.com oh my God! and similar).

There are several steps here that I'm not getting, i.e.: how do I tell Exchange to accept mail for test.com? Is that ONLY through a "Recipient Policy" - even if I have the e-mail address defined in the "E-mail addresses" tab of an AD user?

Can you make recipient policies that only apply to one person? Is this about disabling the Recipient Update Service?

Once I get the public SMTP server to accept mail for the test.com domain, I will need it to accept mail for two more domains as well (existing.com and aliasforexisting.com), but when I experimented with creating a third SMTP servers it said there was already an SMTP server defined on that public IP...how is this done?

Pending a working solution, I have brought everything back down to zero (internal smtp only), so if somebody could just tell me how to do it from scratch (instead of trying to fix my rambling above) that would be super.

Thanks in advance.

 

[Marcs41]

pfff.

In short: Your server will resolve addresses for the domain specified in the default recipient policy.
It does NOT matter what an individual mailbox's default SMTP address is.
If you have multiple domains, you either set the defaults manually, and uncheck the 'inherit..' checkbox.

You can apply recipient policies to one user, a group, etc.. just beware if they overlap!

Your Virtual SMTP server will send mail OUT, using the mailboxes default SMTP address.

Marc
_{If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all.
Free Tip: The F1 Key does NOT destroy your PC!}

 

[reallywildstuff]

This worked, but now it's showing info in the header of a received message that it shouldn't...

I created a Recipient Policy but left the filter blank, that seemed to do what I wanted it to, which was "nothing" except "accept mail for test.com". Don't know why when I previously set the filter to only my AD Account it went ahead and applied it to everybody but regardless...

I defined the address "myusername@test.com" in my e-mail addresses tab in AD.

I recreated the SMTP Virtual Server on the public NIC, named it mail.test.com.

At this point the public server would accept mail, however it was holding mail for delivery in the que "messages awaiting directory lookup".

Then I created the SMTP Connector, defined the internal as the Bridgehead, and the messages came thru. Fine.

I followed these directions (I have been):

http://www.microsoft.com/technet/pr...ing/685314f3-4abe-4f5d-9c74-63a920c3343a.mspx

But now when I send messages to a web-based e-mail account, the headers indicate the originating smtp server as my Internal Virtual Server name, with an attached IP of our firewall's WAN connection, i.e. even with the Connector, Exchange seems to be sending outbound messages thru the internal SMTP and not the external.

I thought the point of the Connector was to force mail out of the SMTP server of my choice?

Thanks for the h*lp.

 

[Marcs41]

That is a bit tricky to explain in 2 words, but there is a lot of reading about it on the Exchange pages. Basically, the one connector defines the physical connection, the other on connects and names the connection with your settings (Virtual). This is also where you can apply masquarading if you wish if you want to change what gets send out. Beware, if you do this, some reverse lookups may refuse mail from you.

Marc
_{If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all.
Free Tip: The F1 Key does NOT destroy your PC!}

 

[reallywildstuff]

sorry, i'm trying to understand what you wrote:

"the one connector" - i only have the one SMTP connector at this time

"the other on" - the other "one"? Don't have another...

You mention Exchange pages, what keywords would you suggest I focus on?

Thank you -

ReallyWildStuff

 

[Marcs41]

hmm, I was a bit unclear about that one.

I was referring to the connector in the routing groups for the 'one' and to the Virtual SMTP server as the other.

In the books, help or net, the keyword would obviously be connector(s) and SMTP

Marc
_{If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all.
Free Tip: The F1 Key does NOT destroy your PC!}

 

[reallywildstuff]

I am still researching this entire setup, but only recently (without configuration changes) the firewall has started to block "IP Spoofs" in the DMZ coming from the internal IP address and destined for other mail server's port 25 - these are all "Read" Return Receipts.

The internal ip address of the exchange server isn't defined in the access rules for the dmz, so the firewall drops the connection. Eventually the receipt gets delivered, i assume it eventually goes out the internal smtp server.

So at the moment, while most mail appears to be flowing out of WAN gateway/internal SMTP server, other mail (return receipts) are attempting to flow out of the external smtp server but still showing as originating from the internal ip address.