If you are using a firewall, you’ll need to configure it properly so ListManager can send and receive mail, and so its web interface is visible.
Typically, users have one of two types of secure networks:
- A router/firewall combo is positioned at the gateway to the Internet. The immediate network sits right behind it.
- A router/firewall combo is positioned as the gateway to the Internet, with two separate networks branching out of it: one, into a "trusted, internal" branch and the other, a "non-trusted/DMZ" branch.
In general, we recommend deploying ListManager behind a firewall in a DMZ, so that the machine is separate from the trusted, internal network, and its access to the internal network is severely restricted. Regardless of your network configuration, it can be configured so that ListManager can work properly behind your firewall. If some of the terms are new to you, please scroll to the bottom of the page for a glossary.
Steps to Have ListManager Work Through Your Firewall
1. Determine how you'd like ListManager to coexist with your mail server. Generally, it is easier to have your mail server and ListManager on separate machines, with a different IP address assigned to each, because you don’t need to make any changes to your mail server. You can also have all incoming mail go to ListManager first, which can be configured to forward all non-ListManager mail to another mail server. Some mail servers can be configured to accept all mail, then forward ListManager’s mail to it. Consult Mail Server Coexistence for more details on how ListManager can coexist with your mail server.
2. Obtain a set of external IP addresses from your backbone provider or Internet service provider (ISP). You must have AT LEAST one. Ideally, you'll have (at least) one for your mail server, and one for ListManager. Assign one external address to be used for ListManager.
3. Have your ISP make a DNS record for your ListManager IP address. Domain Name Service, or DNS, is a service used to resolve Internet hostnames, such as lyris.com, into their respective IP numbers, and vice-versa. Most users' DNS servers are managed by their backbone providers or ISP, so it’s nothing more than giving your provider the right information regarding the proper Resource Records that need to be added to your existing domain. You already have a DNS record if you’re running a mail server and/or web server.
For example, let’s say you own example.com, and you’d like to use the IP address 216.11.22.1 for ListManager. You would tell your ISP, or backbone provider, that 216.11.22.1 should be lists.example.com, or whatever domain you’d like for it to be. Generally, if you own yourdomain.com, then you would create a subdomain like lists.yourdomain.com, or newsletter.yourdomain.com, in order to have a nice domain name for your new ListManager server.
We recommend that your ISP also create a reverse DNS record for your domain. Forward DNS ensures that your domain resolves to your IP address. In our example above, lists.example.com would resolve to 216.11.22.1. Reverse DNS ensures your IP address resolves to your domain name—that 216.11.22.1 resolves to lists.example.com, for example. Some mail servers refuse to receive mail from hostnames that do not have reverse DNS.
Your ISP may ask you what you want your MX record to be. Your MX record states where mail for the domain should arrive. Tell your ISP to set the MX record as to be the same name as your ListManager domain (e.g., lists.domain.com). We don’t recommend that you forward ListManager mail from your main mail server to ListManager, hence why it’s important that the domain have its own MX record.
4. Assign an internal, static IP address for your ListManager machine. The machine behind the firewall should be assigned a non-routable, private IP address from one of the private address pools in existence today. Commonly used addresses are, 192.168.1.1, 10.1.0.1, 192.168.10.1, etc. Anything that starts with a 192.168. or 10.1. is considered private.
5. Configure your firewall. Depending on your firewall, one of the following methods should work for you. Note that the following is not a substitute for your firewall’s documentation; it outlines general procedures you’ll need to perform. Consult your firewall manufacturer if you have questions about your firewall.
Assign the ListManager IP address to your firewall and DNAT port 25 and port 80 to the machine behind the firewall which will be running ListManager.
For example, if you have an IP assigned to the firewall as 216.11.22.1, you would then forward all port 25 and 80 requests that arrive at that IP address to your internal IP, 192.168.1.1, port 25 and port 80. All requests to port 25 and 80 on216.11.22.1 will automatically get routed to the internal address. All other port requests will be dropped or accepted, depending on your default policy rule in the firewall ruleset, or ACL (Access Control List).
If you happen to have a DMZ, and a separate, trusted internal network that houses your workstations, then all that you have to do is simply assign the machine to your DMZ, and perform the exact same steps for the firewall at the entrance of your DMZ as you would in the first example, where we only had a single firewall.
6. Start ListManager. It may complain about not having reverse DNS on its own IP address, but that will not keep it from running properly. Please do be sure it has reverse DNS on the external IP address, however--otherwise, other mail servers may reject your mail.
7. Go to Utilities: Administration: Sites, and edit any sites you have, so that the Internet Host Name field for each site is the name of your new ListManager machine. Also assign the IP addresses ListManager should use for SMTP and NNTP on each site. These should be the internal IP addresses assigned to the machine.
8. Go to Utilities: Administration: Server: Server Settings: Machine Settings: IP Addresses, and specify what IP addresses ListManager should bind to for DNS lookups. This should be the external IP address assigned to the machine.
Glossary
Network Address Translation, or NAT, is the process of mangling packet headers to direct the payload of data to different points along a network. The basic principle of Network Address Translation is that for every packet that enters a specific interface, such as an Ethernet card, the ownership of that packet is in the hands of the firewall/router, and with that, we can alter the source and destinations of the individual headers; in effect, changing the outcome of the data packets to how we see fit. This is typically done through packet filtering means at the firewall interface. Most firewalls have GUI setup interfaces, while some only allow configuration through ANSI-based interfaces, and some are even managed using standard editors and config files alone.
Destination Network Address Translation, or DNAT, is the process where we can alter the packet’s destination. In essence, as long as we have the packet, we can alter the header to our liking—in effect, sending the packet and all subsequent packets to any destination we choose.
Domain Name Service, or DNS, is a service used to resolve Internet hostnames, such as yahoo.com, into their respective IP numbers, and vice-versa. Most of our clients’ DNS servers are managed by their backbone providers, so it’s nothing more than giving their provider the right information regarding the proper Resource Records that need to be added to their existing domain.
MX Record The DNS record that specifies where mail for a domain should arrive. For instance, email for example.com might be routed to mail.example.com by using an MX record. If no MX is specified, the mail will be sent to the IP addressed specified for the host.
Reverse DNS The ability to resolve an IP address to a domain name.