PMDF Installation Guide
OpenVMS Edition


Previous Next Contents Index


Chapter 11
E-mail Firewall Example Configuration

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