Previous | Next | Contents | Index |
Figure 11-1 Sample PMDF Site EXAMPLE.COM
Example 11-1 shows a sample configuration of PMDF-MTA as an e-mail
firewall using the PMDF CONFIGURE FIREWALL
utility, and
Example 11-2 shows a corresponding checklist file. The sample site
EXAMPLE.COM, first introduced in Figure 4-1, is now assumed to have
added another node, gate.example.com, that sits between the PMDF-MTA
mailhub system naples.example.com and the Internet, as shown in
Figure 11-1. The gate.example.com system will not have any users,
except for the system manager who will log on periodically to check for
postmaster messages, etc.
The naples.example.com system, also known as merely example.com, is
assumed to have been reconfigured using the PMDF CONFIGURE
utility to route all messages to the Internet out by way of
gate.example.com, e.g., by answering:
Does this system need to route mail to a firewall [N]? YES Domain name for firewall system []? gate.example.com |
Note that the firewall system is informed about the domains and IP addresses of the internal systems with which it can expect to communicate directly, example.com (also known as naples.example.com, assumed to have IP address 192.168.1.1), milan.example.com (assumed to have IP address 192.168.1.8), and more generally is told that any IP number in the subnet 192.168.1.0 should be assumed to be internal. The non-example.com domain otherco.com (assumed to correspond to the subnet 192.168.5.0) is also assumed to be behind the firewall.
The firewall configuration utility asks a question about stripping off
certain tracking headers. This can be an issue for sites that are
concerned about exposing internal system names in those tracking
headers. (Note that stripping Received:
and
Message-ID:
headers should be avoided unless absolutely
necessary, since they provide important information used, for instance,
in detecting and short-circuiting mail loops, for detecting forged
messages, and for correlating messages when questions or problems
arise.) In particular, in a setup such as that shown for the sample
example.com site, which has an internal PMDF mailhub system example.com
as well as the PMDF firewall system gate.example.com, note that there
is a much better solution than complete trimming of such headers;
configuration options on the PMDF mailhub and PMDF firewall systems can
be used to control what names appear in such headers generated by PMDF
in the first place. And problematic headers appearing in messages that
originated elsewhere but that pass through either PMDF system can often
be handled with more fine tuned approaches as they pass through the
PMDF system.
Whenever appropriate, each prompt also supplies a default answer which
is enclosed within square brackets. Simply pressing return,
[RETURN], selects the default answer. You can use the
backslash character, \
, to clear a default answer.
Remember that the values in this sample are for purposes of example only. Be sure to use the values appropriate for your system when you perform the actual configuration.
Example 11-1 Example PMDF-MTA Configuration as a Firewall |
---|
$ PMDF CONFIGURE FIREWALL PMDF Internet Firewall Configuration File Creation Utility, V6.7 This utility creates an initial PMDF configuration file (PMDF_TABLE:PMDF.CNF), an initial PMDF aliases file (PMDF_TABLE:ALIASES.), an initial PMDF security configuration file (PMDF_TABLE:SECURITY.CNF), an initial PMDF mappings file (PMDF_TABLE:MAPPINGS.) and an initial PMDF option file (PMDF_TABLE:OPTION.DAT) for a system acting as an E-mail firewall on the Internet. For best results the various network products PMDF is going to be attached to should be installed and operational when this procedure is run. This is by no means required, but the defaults provided by this procedure cannot be selected intelligently without having various software packages available to interrogate. Important note: No changes are made to existing PMDF configuration information until all questions have been answered. This utility can be aborted at any prompt by entering CTRL/C. The files output by this utility can optionally be redirected to a different location so they will have no impact on the existing PMDF configuration. Do you wish to continue [Y]? y Do you wish to have a detailed explanation printed before each question [N]? y Part One: Determining local host's name(s). Enter the 'most official' name for this sytem. This should be the official domain name in most cases. This is the name that will appear in mail addresses on this system, among other things. Official local host name of the firewall [GATE.EXAMPLE.COM]? gate.example.com Enter the domain or subdomain your systems are part of, if there is one and it is consistent. For example, if your system's domain name is HMCVAX.EXAMPLE.COM, and in general all your systems are part of the .EXAMPLE.COM domain, enter '.EXAMPLE.COM'. If your system is not part of a domain or if your use of domain name is not consistent, just press CR. Default domain or subdomain for this system/OpenVMS cluster [none]? example.com Enter the DECnet node name for the local host. This usually should be the actual node name and not the DECnet OpenVMS cluster alias. DECnet node name for the local host [GATE]? GATE Enter the SCS (OpenVMS cluster) node name for the local host. SCS (OpenVMS cluster) node name for the local host [GATE]? GATE Enter any aliases for the local host; these names are rewritten to the official local host name with rewrite rules. Any other aliases for the local host [RETURN if no more]? [RETURN] Enter YES if you want to include the other nodes in this OpenVMS cluster in this configuration. Enter NO if you do not. YES is an appropriate response in an entirely homogeneous OpenVMS cluster, NO can be appropriate in a heterogeneous OpenVMS cluster. Include other OpenVMS cluster members in configuration [Y]? n This firewall system either routes all mail addressed to your internal domains to some internal system; or mail addressed to the firewall go to users who logged on the firewall system. Enter Yes if you have users on the firewall system, or No if all mail is routed somewhere else. Are there mail users on this firewall system [N]? n Enter a valid user@host type of address for the firewall Postmaster. Depending on your needs, this address can be on a system different from the firewall system. This address will receive notifications of bounced or deferred mail as well as various other types of status and error reports. This address is also the one that will receive user queries about electronic mail. A user@host style address for the local Postmaster [SYSTEM@gate.example.com]? system@gate.example.com system@gate.example.com Part Two: The external TCP/IP networking. This system has one or more names it is known by on TCP/IP. Enter the most 'official' of these names, preferably a name the system is registered under in the Domain Name System. Name of this system on TCP/IP [GATE.EXAMPLE.COM]? gate.example.com PMDF needs to know the IP addresses for all the interfaces used by TCP/IP on this system or homogeneous OpenVMS cluster. These addresses are needed so that PMDF can recognize domain literals references to this system. Such recognition is mandated by RFC1123. Enter each IP address separately in a.b.c.d format, pressing CR between each one. When you've entered them all just enter a CR by itself to end the list. IP addresses for this system [RETURN if no more]? 192.168.1.10 IP addresses for this system [RETURN if no more]? [RETURN] Part Three: Internal TCP/IP connections PMDF needs to know about internal TCP/IP usage. For instance, this information is used to segregate incoming messages from internal vs. external sources. Your configuration file will automatically contain the rules necessary to reach external Internet domains, so it is not necessary to tell PMDF about external Internet systems. If your site satisfies any of the following conditions: (+) POP or IMAP users, (+) other internal TCP/IP systems, (+) connect to non-Internet TCP/IP systems, then you will need to answer YES. If you do answer YES, you will then be asked for the names of these systems or domains so that they can be added to your configuration and mappings files. Answer NO if there is no TCP/IP use behind this firewall. Are there any internal systems reachable via TCP/IP [Y]? y Is this firewall system set up to lookup the internal systems by: (1) Doing host lookups with MX records (name server required) (2) Doing host lookups without MX records (name server required) (3) No name server; using TCP/IP package for host lookups MX (Mail eXchange) records are special entries in the TCP/IP Domain Name Service database that redirect mail destined for systems not directly attached to the TCP/IP network to an intermediate gateway system that is directly attached. If your TCP/IP package is configured to use a name server which includes MX records for your internal systems, you should answer 1; this is the most common case. Otherwise if you have the internal systems in your name server but have a special requirement to ignore MX records for internal systems, then answer 2. Answer 3 if the internal systems can not be found by name server lookups and instead can only be seen by doing host table lookups. Choose one of the above options [1]? 1 TCP/IP networks typically provide access to one or more systems or entire domains. This should only include systems or domains that are accessible via TCP/IP inside your firewall; systems reached through DECnet or NJE do not count. Enter each system or domain specification (e.g. system names such as 'brandnew.company.com' or domains such as '.mycompany.com') separately, pressing CR between each one. When you've entered them all just enter a CR by itself to end the list. Internal system or domain reachable via TCP/IP [RETURN if no more]? example.com Internal system or domain reachable via TCP/IP [RETURN if no more]? naples.example.com Internal system or domain reachable via TCP/IP [RETURN if no more]? example.com Internal system or domain reachable via TCP/IP [RETURN if no more]? .otherco.com Internal system or domain reachable via TCP/IP [RETURN if no more]? [RETURN] PMDF needs to know the IP address of each internal system or subnet. For instance, this information is used to distinguish between internal and external systems for doing SMTP relay blocking. Enter each IP address separately in a.b.c.d, or a.b.0.0 or a.b.c.0 format, pressing CR between each one. When you've entered them all just enter a CR by itself to end the list. IP addresses for your internal system or network [RETURN if no more]? 192.168.1.7 IP addresses for your internal system or network [RETURN if no more]? 192.168.1.8 IP addresses for your internal system or network [RETURN if no more]? 192.168.1.0 IP addresses for your internal system or network [RETURN if no more]? 192.168.5.0 IP addresses for your internal system or network [RETURN if no more]? [RETURN] PMDF has the ability to automatically convert shortform names appearing on the right hand side of the at sign in an address into fully qualified domain names. These addresses are then routed to TCP/IP automatically. This convenience is especially appropriate when a system is only connected via TCP/IP and not via other networks. For example, if you were to specify a default domain of EXAMPLE.COM and the address USER@NAPLES was used, where NAPLES has no other special meaning, this address will be rewritten as USER@NAPLES.EXAMPLE.COM and routed via TCP/IP. Enter nothing if you don't want to have shortform addresses handled in this way. Default (internal) domain to attach to shortform host names [none]? example.com Enter YES if all messages to your internal systems are to be routed via a (preferably) PMDF-MTA system acting as a mailhub. Enter NO otherwise. Are all internal messages routed to a mailhub [N]? y Enter the fully qualified TCP/IP name of the mailhub system. Enter TCP/IP name of the mailhub []? example.com Part Four: Internal DECnet connections Answer YES if this system is attached to DECnet network containing one or more remote nodes PMDF should provide access to. Answer NO if this host is not attached to such a network. Is this system attached to any others using DECnet [Y]? n Part Five: Security Configuration. Enter YES if you would like to allow external users to submit mail using password and NO if you do not. Do you want to allow authenticated external users to relay mail [Y]? y Enter YES if you would like to check passwords against LDAP source and NO if you do not. Do you want to check passwords against LDAP [N]? n Enter YES if you would like to check passwords against MessageStore/ popstore user profiles, which is the fastest, and NO if you do not. Do you want to check passwords against MessageStore/popstore user profiles [Y]? y Enter YES if you would like to check passwords against PMDF password database and NO if you do not. Do you want to check passwords against PMDF password database [Y]? y Enter YES if you would like to check passwords against the operating system one (e.g. /etc/passwd), and NO if you do not. Do you want to check passwords against operating system [Y]? y Enter YES if you would like to allow unprotected passwords for internal users and NO if you do not. Do you want to allow unprotected password for internal users [Y]? y Enter YES if you would like to support for pre-standard unprotected password submission used by Outlook Express and Netscape 4.0x and NO if you do not. Do you want to support pre-standard password submission used by Outlook Express and Netscape 4.0x [N]? n Part Six: Customizations If you want to log message traffic through this system, then answer YES. Turning on logging would create log files in your PMDF log directory - mail.log_current, mail.log_yesterday and mail.log It is your responsibility to archive/delete the mail.log file periodically or these files can consume your disk space. Do you wish to enable message logging [N]? n As a firewall, you might want to eliminate the names of internal nodes from outgoing mail. PMDF can selectively trim off possible header lines which contain such information. If you choose to trim off the headers, the following will be eliminated from mail outgoing on the external tcp channel: Received: X400-Received: MR-Received: Message-id: Do you wish to get rid of all *received: headers for outgoing mail [Y]? n Part Seven: Process and write files Enter the name of the configuration file you want to have output. The default action is to produce a real configuration file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue. Configuration file to output [PMDF_TABLE:PMDF.CNF]? [RETURN] Enter the name of the aliases file you want to have output. This file contains system-wide local address aliases PMDF will recognize; special aliases are required for proper operation of some channels. The default action is to produce a real alias file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue, or if you want to preserve an existing aliases file. Alias file to output [PMDF_TABLE:ALIASES.]? [RETURN] Enter the name of the PMDF option file you want to have output. The default action is to produce a real PMDF option file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue. Option file to output [PMDF_TABLE:OPTION.DAT]? [RETURN] Enter the name of the mapping file you want to have output. The default action is to create a real mapping file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue. Mapping file to output [PMDF_TABLE:MAPPINGS]? [RETURN] Enter the name of the security configuration file you want to have output. The default action is to create a real security.cnf file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue. Security configuration file to output [PMDF_TABLE:security.cnf]? Enter the name of the option file for the incoming TCP/IP channel. The default action is to create a real channel option file; you might want to choose another file name if you are not sure you have properly answered all the questions in the preceding dialogue. (Incoming) tcp channel option file to output [PMDF_TABLE:TCP_LOCAL_OPTION]? [RETURN] This procedure generates a checklist file that contains the list of steps you must perform in order to complete your PMDF configuration. This procedure does *NOT* perform these steps itself; you must do them manually. PMDF checklist file name [PMDF_TABLE:FIREWALL.CHECKLIST]? [RETURN] All configuration questions have been answered. This question gives you a last chance to change your mind before any files are written. Answer NO if you are not sure you want to generate the configuration you have specified. Answer YES if you do. Do you wish to generate the configuration files [Y]? y Generating the PMDF configuration file... Generating PMDF_TABLE:TCP_LOCAL_OPTION Generating the PMDF mapping file Generating the PMDF aliases file... Generating the PMDF option file... Generating the PMDF security configuration file... Generating the PMDF firewall configuration checklist file... *********************************************************************** * * To complete your PMDF configuration, carry out the steps * detailed in the checklist file PMDF_TABLE:FIREWALL.CHECKLIST. * *********************************************************************** Enter Yes if you want to see the checklist now. You can still type the file out later if you say No. Do you want to see the checklist now [Y]? n Enter YES if you would now like to configure the PMDF Dispatcher. If you answer NO, then you can configure it later with the command $ PMDF CONFIGURE DISPATCHER Configure the PMDF Dispatcher [Y]? n $ |
Example 11-2 Example Checklist File for Firewall Configuration |
---|
$ TYPE PMDF_TABLE:firewall.checklist Checklist for completing the setup of the PMDF firewall configuration. Written by SYSTEM, 1-NOV-2012 13:54:13 This file was created by the PMDF configuration generator V6.7 (1) If you have not already set up your MAIL$BATCH queue or added the PMDF startup procedures to your system startup, then be sure to do so. Setting up MAIL$BATCH is crucial to the operstion of PMDF. Modifying the system startup can, of course, be done after you have verified the proper operation of PMDF. Refer to the "Post-Installation tasks" section of the first chapter of the PMDF Installation Guide & Release Notes. (2) Setup the PMDF SMTP server. To do this consult the TCP/IP Channels chapter of the PMDF System Manager's Guide. To use the generic multithreaded TCP/IP, you need to disable any other SMTP server you are currently be running and also configure the PMDF Service Dispatcher with the command PMDF CONFIGURE DISPATCHER Note that all other steps outlined in the TCP/IP Channels chapter have been taken care of for you by the configure procedure. |
Previous | Next | Contents | Index |