Manage Learn to apply best practices and optimize your operations.

How to configure firewall ports for webmail system implementation

Network security expert Mike Chapple explains why he always recommends placing any server accessible from the Internet into the DMZ.

A reader previously asked you; "If public mail servers are located in a DMZ, what is the procedure for channeling internal mail through the firewall?" What you explained in this article is exactly what my company is implementing. Under such a network structure, how could I implement a webmail system? Is it secure to configure the firewall to open port 80 and port 433 and allow direct access to my internal mail server without going through the DMZ? If not, what other options do I have?
There isn't a clear-cut answer to your question, as this is a topic of debate in the security and email communities. Generally speaking, I'm a member of the camp that recommends always placing any server accessible from the Internet into the DMZ. If you're going to allow users to access webmail without requiring a VPN connection, this is definitely my first choice. Placing the webmail server in the DMZ limits the ability of an attacker to use the webmail server to compromise the internal network.

However, there are several factors that complicate the answer to this question. Many email systems, especially Microsoft Exchange, make it quite difficult to separate the webmail front end from the email back end. They require punching so many holes in the firewall -- to allow communication between the two systems -- that they limit the effectiveness of placing them in different network zones.

If you have some flexibility in your network topology, one potential workaround is to create a separate email network zone that is firewalled from both the DMZ and your internal network, and then place both the email and webmail servers in that zone. You may then allow client access there over traditional "fat client" ports from the internal network and webmail ports from the Internet.

This was last published in April 2009

Dig Deeper on Enterprise network security