Name Router 3.0 Manager Guide. The Name Router is a mail routing agent, which maps logical RFC-822 addresses onto physical ones. It does so using the localpart of the address as well as the domains. For example, a logical address might be andrew.jones@math.ucd.ie, indicating Andrew Jones of the Math Department in University College Dublin, Ireland. Note that no machine with the name 'math.ucd.ie' may exist. This user may actually have a login code AJONES on the IRLEARN node in UCD. The Name Router would map the address andrew.jones@math.ucd.ie onto ajones@irlearn.ucd.ie and return it to the mail system for delivery. The Name Router contains an entry for each user who is registered to use this 'pseudo-domain' form of addressing. The Name Router will also do partial mapping. On the localpart, it will assume a structure of Forename.Initial.Surname, or if only one '.' is present, Forename.Surname, or if no '.' just Surname. On the domain parts, it will perform a best right-justified match. For example, if andrew.c.jones@math.ucd.ie is entered in the database then mail sent to any of the addresses below will be matched: andr.jones@math.ucd.ie a.c.jones@ucd.ie a.jones@math.ucd.ie jones@ie Name Router Directory Structure. The Name Router programs reside in a directory indicated by the logical name NAME_ROUTER. This directory contains the executables, command files and database files. Messages in transit are stored in other directories depending on which mail interface is being used. The Name Database. The Name Database is an indexed sequential file, which is keyed on the surname of the user. The other fields are the domains, and the target address. The database is normally prepared using a sequential text file, and then the MAKE-DATABASE program converts this into ISAM format. Choice of Mail Delivery System. Currently, Name Router will interface with one of two different mail systems. The first is the PMDF system, written by Ned Freed of Harvey Mudd College in the US. This is a widely used mailer, which supports a wide variety of transports. For more information on PMDF, contact Ned Freed . The Name Router is defined as a separate channel, and the Name Router programs read the messages from the PMDF_ROOT:[QUEUE] directory directly. The output is fed back into PMDF via the BIT_GATEWAY channel which must be set up. The alternative interface uses a BSMTP file format. Messages are input as BSMTP files in the NAME_ROUTER_IN directory, and output as BSMTP files in the NAME_ROUTER_OUT directory. This allows Name Router to be interfaced to the Software Tools Mailer, or to Bitnet mailers on remote machines which use BSMTP file transfer as the transport mechanism. Installation of Name Router. Name Router is installed via the standard VMSINSTAL procedure. Each question is preceded by a short explanation, and the installation procedure itself is quite straightforward. Building the Name Database. The file NAMES.TXT-TEMPLATE is a sample Name Router definition file. Each entry occupies one line. The fields are free format, separated by one or more spaces or tab characters. The fields are: Forname Initial Surname Domains Target-address. Note that if any of the fields are to be blank (and effectively will match any corresponding field of a message) you must use a dot "." character for the field. Blank lines are allowed, and any line beginning with a "!" character is considered a comment. You should create a NAMES.TXT file in this format, containing the entries for your users. You can then generate the database NAMES.DAT by the following: $ Run NAME_ROUTER:MAKE-DATABASE Interfacing to PMDF Ensure that the BIT_GATEWAY channel is set up on your PMDF system. You do NOT need to be running JNET or any Bitnet software for this channel to operate. It simply inputs BSMTP messages for PMDF to route. Consult the PMDF manual for instructions on how to set this up. Edit the file PMDF_ROOT:[TABLE]PMDF.CNF and set up a route rule and channel definition for the Name Router. For example, if you wanted all traffic ending with .ucd.ie which did not match an existing route rule to go to the Name Router, you would put in the following route rule: .ucd.ie $U%$H.ucd.ie@name-router and define the channel as name_router 822 name-router You should now be able to test your implementation by sending a message through PMDF. You should see first a NAME_ROUTER Master job start in MAIL$BATCH, followed by a BIT_GATEWAY Master. The installation is finished. Interfacing to BSMTP During the installation, you will be prompted for the names of two directories. The input directory is where files intended for the Name Router are placed in BSMTP format. You should ensure that whatever entity places these files there activates the procedure NAME-ROUTER.COM to process them. Alternatively you could run NAME-ROUTER.COM at regular intervals. The output directory is where Name Router places files that have been processed. The envelope addresses will have been changed to the physical addresses of the recipients. These files can now be forwarded to a mailer that handles BSMTP. You should edit the file NAME-ROUTER.COM and insert commands at the end to activate whatever entity should deliver the messages (e.g. a SEND/FILE command for a remote Bitnet mailer). Modifying Name Router command files. If you wish to change the options that you entered during the installation phase, you may modify the NAME-ROUTER.COM and NR_STARTUP.COM files. Logical names used in NR_STARTUP.COM The following logical names are set up in NR_STARTUP. NAME_ROUTER Directory containing Name Router files. (*) NAME_ROUTER_IN Directory for input BSMTP files. (*) NAME_ROUTER_OUT Directory for outgoing BSMTP files. (*) logicals only used where BSMTP access is being used. Commands in NAME-ROUTER.COM The main command used is the ROUTE command which is defined as a foreign command within the command file. The following qualifiers are used: /ORGANIZATION Organization domain name (optional). /LOCAL_NAME domain name for local node (mandatory). /REJECT_ILLEGALS send rejection messages to sender for nonrouteable messages. /NOTIFY_POSTMASTER send rejection messages to local postmaster for nonrouteable messages. /PMDF Use PMDF mailer for input and output messages (if omitted, BSMTP is assumed). /LOG Log all messages routed. /DEFAULT Default mapping string for unrouteable messages. The default mapping is built from the localpart of the incoming address. The incoming address is of the form forename.initial.surname@address, where 'initial' and 'forname' are optional. You can convert this using match strings as follows: $F Forename. $I Initial letter of forename. $M Middle Initial. $S Surname If for example, a message is addressed to michael.j.williams@urg.company.ie, and cannot be routed, then the above strings will take the values $F = "michael" $I = "m" $M = "J" $S = "williams" You could then route such names to a default machine with an assumed username convention of _ by using the default mapping: $I_$S@vax1.company.ie Note that if you use a default mappings, then the settings of /NOTIFY and /REJECT will be irrelevent as Name Router will never fail to route an incoming message (the mailer may generate a failer message further down the line, if the default mapping does not yield a valid mailbox).