PMDF Obsolete Features
PMDF-OBS-6.0

There are many BITNET mailer gateways and more are added every month. A list of all registered mailer gateways is maintained by the BITNET Network Information Center. A current copy of the list can be obtained on BITNET systems by using the Jnet command:

$ SEND LISTSERV@BITNIC SEND DOMAIN NAMES

In addition to the actual gateways, lots of BITNET sites operate a mailer that accepts mail in BSMTP format, even if they do not operate a mailer gateway. Information about what form of mail (regular NJE or BSMTP) each site prefers is listed in the xmailer names file. You can obtain a current copy of this file with the command:

$ SEND LISTSERV@PUCC SEND XMAILER NAMES

Copies of both of these files are part of the PMDF for OpenVMS distribution --- the distribution copies are kept in the PMDF table directory, (i.e., PMDF_TABLE:domains.names and PMDF_TABLE:xmailer.names). However, these files rapidly become dated and it is always preferable to work with current copies if possible.

A DCL procedure is provided with PMDF for OpenVMS that will convert the DOMAIN NAMES and XMAILER NAMES files into a format that can be inserted directly into the configuration file. This procedure, PMDF_COM:bitnet_domains.com, reads these two files and produces the following output files:

gates.rules

Rewrite rules for BSMTP systems suitable for insertion into either the configuration file or the domain database.

gates.chans

Channel definitions for the configuration file that are used by the gates.rules rewrite rules.

bitnet.rules

Rewrite rules for regular NJE systems suitable for conversion into a domain database.

tcpip.rules

Rewrite rules for BITNET systems and domains that are reachable via TCP/IP instead of BITNET. This file only contains meaningful output if the ON_INTERNET flag is set to 1 (see below).

gateway.rules

A set of rewrite rules for BSMTP systems suitable for insertion in configuration files on remote systems that are going to use a central gateway.

bgateway.rules

A set of rewrite rules for all regular NJE BITNET systems suitable for insertion in configuration files on remote systems that are going to use a central gateway.

domain.dat

A domain database containing the same rules bitnet.rules contains. This is optional and can be suppressed; see below.

When you execute the PMDF CONFIGURE utility and configure your system for BITNET, a bitnet_domains_driver.com file will be created in the PMDF table directory, PMDF_TABLE:. The commands in this file set various DCL symbols which set site specific parameters and then execute the bitnet_domains.com procedure located in the PMDF com directory, PMDF_COM:. These DCL symbols, as well as others not set by the PMDF configuration utility, are described below. If you wish to set or change one of these symbols, make the correction in your bitnet_domains_driver.com command file rather than in bitnet_domains.com, which is replaced whenever PMDF is upgraded. If, for some reason, you choose not to run the PMDF configuration utility, then copy bitnet_domains_driver.template to bitnet_domains_driver.com and edit that. Innosoft strongly recommends that you use the supplied PMDF CONFIGURE utility.

• ON_INTERNET should be set to 1 if your system is actually on the Internet. If you system is not on the Internet ON_INTERNET must be set to 0. For example, if you are on the Internet, use the following declaration

         $ ON_INTERNET = 1 
  

• HANDLES_MX should be set to 1 if your system's TCP/IP implementation and configuration can handle MX records. HANDLES_MX should be set to 0 otherwise. This setting is only meaningful if ON_INTERNET is 1. For example, to declare that your configuration can handle MX records, use the declaration

         $ HANDLES_MX = 1 
  

• TCP_DAEMON should be equated to the name of the TCP/IP daemon you use; e.g.,

         $ TCP_DAEMON = "TCP-DAEMON" 
  

• INTERNET_GATEWAY should be set to 1 if your system is going to act as a gateway from BITNET to the Internet. This should be set even if your site does not intentionally gateway messages from BITNET to the Internet but does have the capacity to do so. If this capability does not exist INTERNET_GATEWAY should be set to 0. For example, if you operate a gateway from BITNET to the Internet, use the following declaration

         $ INTERNET_GATEWAY = 1 
  

• If INTERNET_GATEWAY is set to 1 you must set INTERNET_GATEWAY_HOST to the name of the Internet host with which BITNET addresses emitted onto the Internet will be qualified. This is usually the TCP/IP name for your local host name, but not always. More generally, it is the host that will be used to gateway replies from the Internet back onto BITNET. For example, if ymir.claremont.edu is the name of the Internet to BITNET gateway you wish to use, use the following declaration

         $ INTERNET_GATEWAY_HOST = "ymir.claremont.edu" 
  

• If you set INTERNET_GATEWAY to 1, set INTERNET_CHANNELS to be a list of the channels that connect to the Internet. This list must not include channels that connect to the Internet via BITNET. If set, this parameter should translate to a list of channel names separated by "/". Do not begin or end the list with "/" as you do for some of the symbols below.
• SKIP_DOMAIN should be set to the list of domains whose BITNET gateways you never want to use. You should list your own domain if you are the BITNET gateway for it, along with any domains you wish to avoid (for whatever reason). Begin each domain name with a backslash, and terminate the entire list with a trailing backslash; e.g.,

         $ SKIP_DOMAIN = "/.CLAREMONT.EDU/.HAC.com/" 
  

• SKIP_XMAILER should be set to the list of systems for which you already have rewrite rules (and hence for which you don't need any more). This would probably include all BITNET systems that are part of your local VAXcluster, for example. Separate each system name with a backslash and terminate the entire list with a trailing backslash; e.g.,

         $ SKIP_XMAILER = "CBROWN/ECHMC/HMCVAX/SIF/YMIR/" 
  

  Do not include any pseudo-domains in the system names (e.g., ".BITNET"). The system names should be as they appear in the XMAILER NAMES file.
• FORCE_BITNET can be set to a list of domain names that you want routed via BITNET regardless of their TCP/IP connectivity status. Begin each domain name with a backslash and terminate the list with a trailing backslash; e.g.,

         $ FORCE_BITNET = "/.TULANE.EDU/OHIO-STATE.EDU/" 
  

• FORCE_INTERNET can be set to a list of domain names that you want routed via the Internet regardless of what their entries in DOMAIN NAMES say. Begin each domain name with a backslash and terminate the list with a trailing backslash; e.g.,

         $ FORCE_INTERNET = "/.SRI.NIC/.RUTGERS.EDU/" 
  

• FORCE_INTERBIT can be set to a list of domain names that you want routed to the INTERBIT gateway regardless of what their entries in DOMAIN NAMES say. Begin each domain name with a backslash and terminate the list with a trailing backslash; e.g.,

         $ FORCE_INTERBIT = "/.ACME.com/.STATEU.EDU/" 
  

• BITNET_ALIAS should be set to your BITNET system name if it is not the same as your official host name; e.g.,

         $ BITNET_ALIAS = "YMIR.BITNET" 
  

  The specification of the trailing pseudo-domain .BITNET is recommended.
• BITNET_QUEUE should be set to the name of the batch queue used to process jobs handling the various BITNET channels. This is typically a queue that runs on a system where Jnet or ANJE software is installed. If no special queue is specified these jobs will run in the normal PMDF batch queue or queues.
• BITNET_CHANNEL_TYPE should be set to "bit_" for Jnet channels or to "anje_" for ANJE channels; e.g.,

         $ BITNET_CHANNEL_TYPE = "bit_" 
  

• Normally BITNET shortform names may be used anywhere in PMDF; they are automatically converted into their .BITNET form. This can present problems if these names conflict with local shortform names, especially if these names are handled by default rules. The BITNET_LOCAL_CHANNEL parameter provides a mechanism for selectively disabling the ability to use BITNET shortform names. Normally this parameter is blank. If set, this parameter should translate to a list of the channel names, separated by /, where BITNET shortform names are to be considered to be valid. If any list is specified it must include your local BITNET channel; e.g., "bit_local" for Jnet or "anje_local" for ANJE. It probably should also include your BITNET gateway channel (bit_gateway) as well, if you have one. Do not begin or end the list with "/" as you do for some of the other lists in bitnet_domains_driver.com.
• PERIOD controls the periodicity of service the channels generated by the procedure bitnet_domains.com receive from the periodic delivery batch job. Since BITNET gateway channels are serviced immediately by default, delivery failures are rare, and there are a lot of gateway channels (which means checking them all is time consuming), the period is usually set to 3, which means that only every third periodic delivery batch job will check these queues. To declare a period of 2, use the declaration

         $ PERIOD = 2 
  

• DO_CRDB_BR should be set to 1 if you want to have CRDB automatically run on bitnet.rules to produce a domain.dat file:

         $ DO_CRDB_BR = 1 
  

  You can set both DO_CRDB_BR and DO_CRDB_GR if you want bitnet.rules and gates.rules to be combined in a single domain.dat file.
• DO_CRDB_GR should be set to 1 if you want to have CRDB automatically run on gates.rules to produce a domain.dat file:

         $ DO_CRDB_GR = 1 
  

  You can set both DO_CRDB_BR and DO_CRDB_GR if you want bitnet_rules and gates.rules, to be combined in a single domain.dat file.
• GATEWAY_USER_NAME should be set to the user tag your gateway uses. If you do not operate a BITNET gateway GATEWAY_USER_NAME should be set to either MAILER or SMTPUSER; e.g.,

         $ GATEWAY_USER_NAME = "MAILER" 
  

• GATEWAY_SYSTEM_NAME should be set to the name of your BITNET gateway system; e.g.,

         $ GATEWAY_SYSTEM_NAME = "ymir.claremont.edu" 
  

  If you do not operate a BITNET gateway, GATEWAY_SYSTEM_NAME should be set to the name of the local system that is running PMDF.
• CHANNEL_KEYWORD_OPTIONS may be set to any additional channel keywords (or rightslist identifiers) which should be applied to every bit_ channel); e.g.,

         $ CHANNEL_KEYWORD_OPTIONS = "notices 3 6 9 12" 
  

  Note that in most, if not all, cases a defaults channel can be used to apply keywords to all bit_ channels.

  Once you have up-to-date copies of DOMAIN NAMES and XMAILER NAMES and have made any desired edits to bitnet_domains_driver.com, you can run the procedure as follows:

  $ SET DEFAULT PMDF_TABLE:
  $ @bitnet_domains_driver.com
  

  The resulting file should be included at the end of your PMDF configuration file, pmdf.cnf by using the include command <file-spec i.e.,

  <PMDF_TABLE:gates.chans 
  

  This file is included automatically when you use the PMDF for OpenVMS configuration utility to generate the configuration.

  The rewrite rules in gates.rules can either be added to the domain database domain.dat using CRDB or they can be included by the PMDF configuration file (again, using the include command <file-spec). If you set ON_INTERNET to 1, the file tcpip.rules should be included by your configuration as well. It is automatically included if you use the PMDF configuration utility to generate your configurations.

  The files gateway.rules and bgateway.rules are not intended for use on the gateway system. They are designed to be added to the rewrite rules on a remote system running PMDF that wishes to use as a gateway the gateway system that produced gateway.rules.

  ---

  Previous | Next | Contents