Exchange 2003 SMTP Gateway server

You have two options.

1. A frontend server. This would be an Exchange server that sits in front of the others, and has all the scanning applications installed on it. This would NOT be in the DMZ as the number of ports to open on the firewall make it like swiss cheese.

Remember that email address information is held in the active directory with Exchange 2003, so you don't have a separate database with the email addresses on it.

2. A separate relay server. Windows 2003 makes a very good relay server and needs light configuration to get it to relay email in. It can be put in to the DMZ if required as the only ports that need to be open are 25. This machine would not be a member of the domain.

With both solutions you can use SMTP Connectors to route the email to non-Exchange servers. Exchange will find its own way to email that is hosted by itself.

However, one of the nice features with Exchange 2003 is its ability to filter out non-existent users. With SP1 for Windows 2003 installed, you can also block against directory harvest attacks as well.
If you use a separate gateway, then you loose that feature, so I would look at a third party tool that can do LDAP lookups on the email addresses and filter that way.

Simon.

What exactly does a front end server do?  I know I read something about a back end server holds the mailboxes.  Is the front end server a bridgehead server?

I don't need a server to scan email or filter it.  I have all of those capabilities already. Any scanning or filtering would be redundant.  

Basically they way we have it now it mail comes into our firewall and routes it to an AV scanner.  It relays the mail to our Exchange 5.5 gateway server and it forwards the mail to one of five servers.  Four of the servers have different email addresses.  Maybe the SMTP server is what I need.  I guess in AD what I will have to do is create separate OUs for users who need their mail forwarded to a different address.  My only concern would be the impact on our domain controllers.  That could be a lot of activity on our GC servers.  We average about 800 messages an hour.  

I was looking at appliances but they are overkill and not many offer alias features which is what I really need.  

A frontend is usually used for offloading Outlook Web Access and other web services, such as OMA, RPC over HTTPS etc. It used to provide a single point of entry for the Exchange environment. Being part of the Exchange org allows it to route email correctly.

If you put in a basic SMTP server, then that server will have to direct all email to one of the backends, which then distributes the email to the relevant server.

Simon.

I guess one thing I don't want to do is put all of the load on our current Exchange 2003 bridgehead server.  I am sure it can handle it but I don't want a single point of failure plus it is easier to troubleshoot when there is a gateway in the middle.  

One thought I had was to create another Exchange server and and make it the bridgehead server.  Then I could setup multiple SMTP connectors and assign a cost and address space to each of the address spaces to which I would direct mail.  I could then setup a smarthost to the sendmail and Exchange servers.  The questions I have are 1) Is this feasible?  2) Are smarthosts for outbound only?

I get the feeling a basic SMTP server would not really serve my purpose here.  I think a front end server may not do it either.  We don't use OWA.  

An Exchange server being used a bridgehead is basically a frontend server. Frontends are mainly used for OWA, but they can work as the single point of entry for everything else.

Unless you spend a lot of money on multiple internet connections, multiple servers and have the DNS set correctly, then you will always have a single point of failure.
What is comes down to is whether the funds are there to reduce the single points of failure with redundancy everything. In many cases they aren't.

I can usually justify a backup internet connection - but in many cases that will totally useless if the problem is at the telephone exchange. Here in the UK everything comes across the last mile that BT (British Telecom) provide. If the problem is in that last mile, or further upstream then you are stuffed.

Backup servers are a little more difficult to justify. Where the client is concerned then I will use a backup MX service from the ISP or another service provider. If I can't get them access to email within 4 hours (hardware availability permitting) then I am having a very bad day.

SMTP Connectors are OUTBOUND only. They play no role in inbound email.
Even if you setup a connector for the other domains - if those domains are in the Exchange org, Exchange will recognise them and direct them to the relevant server itself - ignoring the SMTP connector.

The type of service that you have with Exchange 5.5 is being introduced with Exchange 12. That brings in the concept of edge services that sits on a workgroup member in the DMZ. There is no equivalent in Exchange 2003 though.

Simon.

The unique thing to my situation is the other exchange servers using the different domain name space are not in my Exchange org.  They are in their own org and maybe their own domain.  I don't know I have no access to those servers.  We just have to route their mail.  So my thinking is I create contacts for those people and create a secondary SMTP address.  I create a SMTP connector for each domain name space then when the message comes in as abc.def.com it will see the SMTP address of abc.def.com and 123.abc.def.com.  It will try abc.def.com first and then try 123.abc.def.com and it will see the connector for 123.abc.def.com and forward it to a smart host I have configured for the connector.  Then their 123.abc.def.com server will receive the message.  I think this will work.  Does anyone have an opinion on this?  

Thanks for the help.