Example 20-4 Example PMDF-MR V6.0 configuration for Message Router TS replacement
$ SET DEFAULT PMDF_TABLE:
$ PMDF CONFIGURE MR
PMDF-MR Configuration Utility, Version 6.0
This utility creates an initial pair of databases for mapping PMDF
RFC 822-style addresses to Message Router X.400-style addresses
and back again. Use this utility to assign RFC 822-style domain
names to your Message Router user agents and gateways so that they
can interoperate with all of your other PMDF channels.
At various stages of this procedure you will need to supply
RFC 822-style domain names. Be sure that the names you choose
are within a domain or subdomain over which you have administrative
authority, and are not currently being used for anything else.
Important note: No changes are made to existing PMDF-MR database
information until all questions have been answered. This utility
can be aborted at any prompt by entering a CTRL/Z. The files
output by this utility may optionally be redirected to a different
location so they will have no impact on the existing PMDF-MR
databases.
You have a history file from a previous run of the configure utility.
Do you want to use answers from the previous run as defaults [N]? RETURN
Do you wish to continue [Y]? RETURN
Do you wish to have a detailed explanation printed before each question [N]? y
In addition to acting as a gateway to Message Router, PMDF-MR
has the ability to act as a replacement for Message Router
for any agent that is built using the MRIF API interface. Agents
using this interface include:
ALL-IN-1 Integrated Office System V3.0 or later/Office Server [A1]
MAILworks Server for OpenVMS (aka ALL-IN-1 Mail) [AM]
Properly implemented Message Router gateways from non-Digital
vendors may be supported as well.
This capability is especially useful on AXP systems, where native
Message Router support is not available.
This phase of this procedure will generate the necessary channel
definitions and option files. This is equivalent to defining
mailboxes using the MRMAN utility.
If you need Message Router emulation facilities you should enter
YES, otherwise enter NO.
Do you wish to set up any Message Router replacement mailboxes [N]? y
Enter a domain name to be associated with a Message Router mailbox.
(you will be asked to enter the name of the MR mailbox later).
Each Message Router User Agent or Gateway mailbox needs to have its
own unique domain name so that PMDF can recognize it on incoming
mail and direct the mail to the proper channel queue.
Domain name for replacement MR mailbox [RETURN if no more]? a1.nomr.acme.com
Enter the name of the replacement Message Router mailbox to
generate. This corresponds to the name you would normally enter in
MRMAN. If there are no more User Agent or Gateway mailboxes then
just hit RETURN.
Name of one replacement MR mailbox []? A1
Enter the password for the previously specified mailbox. This
must be the password you have set for Mailworks in X4MAN using the
SET MR_PASSWORD command, or the password set for ALL-IN-1 by the
ALL-IN-1 MANAGER which can be displayed within ALL-IN-1 with the
SM MM DS command.
Password for replacement MR mailbox []? a1secret
Enter whatever logical name is associated with the VMS mailbox used
by Message Router to notify software agents of pending mail. This is
the equivalent of the /NOTIFY qualifier in MRMAN. If no notification
mailbox exists simply enter a RETURN.
For ALL-IN-1/Office Server the logical name OA$NOTIFY_MBX should normally
be used.
MailWorks typically uses MUAS$NOTIF_FETCH_MBX for its notification mailbox.
Logical name for VMS mailbox used for notifications []? OA$NOTIFY_MBX
Domain name for replacement MR mailbox [RETURN if no more]? am.nomr.acme.com
Name of one replacement MR mailbox []? AM
Password for replacement MR mailbox []? amsecret
Logical name for VMS mailbox used for notifications []? MUAS$NOTIF_FETCH_MBX
Domain name for replacement MR mailbox [RETURN if no more]? RETURN
Message Router user agents may include a node name as part of the
address routing information they emit. Enter the node name used by
your user agents. This is usually the DECnet node name, or a cluster
alias.
System's node name [NOMR]? NOMR
Message Router routing information often includes local DECnet
node names of other nodes in the cluster or cluster aliases.
These are normally used if you want compatibility with old Message
Router mailbox addresses that include synonyms for the local DECnet
node name.
Local node name or other null routes []? RETURN
Enter Message Router mailboxes which are synonyms for routing messages
to PMDF. These are normally used if you want compatibility with
old Message Router addressing like user@host.domain@PMDF@NODE, in which
PMDF is the Message Router mailbox name and NODE could be the node
name or the cluster alias. In this case PMDF@NODE should be entered
as an answer to this question. If you have old addresses such as
user@host.domain@XYZ, which you now want PMDF to process, then
XYZ should be entered as an answer to this question.
If you used to use such addresses which now you still
want the PMDF-MR replacement to accept for compatibility reasons
enter them here and PMDF-MR will recognize them.
Message Router mailbox synonyms for PMDF [RETURN if no more]? PMDF
Message Router mailbox synonyms for PMDF [RETURN if no more]?
You have configured PMDF-MR to serve as a replacement for Message
Router, using PMDF-MR's emulation capabilities. PMDF-MR is also
capable of handling a real Message Router. If this configuration
only needs to act as a Message Router replacement, answer NO to
this question. If this configuration needs to provide traditional
Message Router gateway functionality in addition to emulation,
then answer YES to this question.
Do you wish to provide traditional MR gateway functionality [N]? n
The FAX domain name is the domain name PMDF-FAX uses for sending
plain text e-mail to FAX. Normally this is the domain name defined
for this purpose when FAX_CONFIGURE.COM is run. Making this domain
name known to PMDF-MR makes it possible to use more convenient and
conventional address formats to send to PMDF-FAX. For example, when
PMDF-MR is made aware of this domain name, a FAX address in ALL-IN-1
MAIL might look like this:
*fn\19096215319@*o\Innosoft@*at\Dan Newman@FAX
This address actually conforms rather closely to the conventions for
X.400 addresses in ALL-IN-1 MAIL. But without the special conversion
rules an address like this would be required:
"/FN=19096215319/O=Innosoft/AT=Dan Newman/"@text-fax.local-domain@PMDF
There is nothing wrong with this address; however, it is overly complex
and it is not in a format natural to ALL-IN-1 MAIL.
This domain name is optional; if you just hit RETURN no special
handling for FAX addresses will be set up. Do not define this
domain name for use in conjunction with anything other than PMDF-FAX;
the processing done is quite specific to PMDF-FAX.
Domain name for PMDF-FAX plain text []? RETURN
The X400 domain name is the domain name PMDF-X400 uses for sending
X.400 messages. Normally this is the domain name defined for this
purpose when X400_CONFIGURE.COM is run. Making this domain name
known to PMDF-MR makes it possible to use more convenient and
conventional address formats to send to PMDF-X400.
This domain name is optional; if you just hit RETURN no special
handling for X.400 addresses will be set up. Do not define this
domain name for use in conjunction with anything other than
PMDF-X400; the processing done is quite specific to PMDF-X400.
Domain name for PMDF-X400 []? RETURN
The printer channel domain name is the official host name associated
with the printer channel defined in the PMDF configuration file.
Making this domain name known to PMDF-MR makes it possible to use
more convenient and conventional address formats to send to the
printer channel.
This domain name is optional; if you just hit RETURN no special
handling for printer channel addresses will be set up. Do not define
this domain name for use in conjunction with anything other than
a PMDF printer channel; the processing done is quite specific to
the PMDF printer channel.
Domain name associated with the PMDF printer channel []? RETURN
Message Router free form names (FFNs) are often used to store the full
name of each user. In the RFC822 world personal name fields serve
a similar function. Enter YES to have free form names converted to
personal names. Entering NO blocks this conversion. (Note that both
free form names and personal names are only included for legibility;
they have no effect on the function of the address.)
Convert Message Router Free Form Names to RFC822 personal names [Y]? RETURN
Message Router telephone numbers (TNs) are often used to store user
phone numbers. In the RFC822 world personal name fields are often
used in this way. Enter YES to have telephone numbers converted to
personal names. Entering NO blocks this conversion. (Note that both
telephone numbers and personal names are only included for legibility;
they have no effect on the function of the address.)
Convert Message Router phone numbers to RFC822 personal names [Y]? n
Message Router free form names (FFNs) are often used to store the full
name of each user. In the RFC822 world personal name fields serve
a similar function. Enter YES to have 822 personal names converted
into Message Router free form names automaticallly. Note that this
may improve the display of PMDF-MR messages in ALL-IN-1, which in
some contexts only displays the free form name and not the rest of the
address.
Convert 822 personal names into Message Router Free Form Names [Y]? RETURN
Message Router free form names (FFNs) are often used to store the full
name of each user. In the RFC822 world personal name fields normally
serve a similar function. However, due to the problems some mailers
have handling personal names, RFC822 comments are sometimes used for
personal name information. This convention unfortunately conflicts
with other uses for comments, notably as a means of tranferring
per-address attribute information. Enter YES to have RFC822 comment
strings converted to free form names automatically. This will only
be done after any configured attempts to convert personal name
information have been tried and failed.
Convert 822 comments into Message Router Free Form Names [N]? RETURN
Message Router organization names (Os) are often used to store the
name of the organization the address is from. In the RFC822 world
the nonstandard Organization: header performs a similar function for
message From: addresses. Enter YES to have the organization specified
in the From: address converted into an Organization: header. Entering
NO blocks this conversion. (Note that this header is only included
because it is convenient for users; it has no other effects.)
Retain organization specification in From: address as Organization: header [Y]?
RETURN
The PMDF address of the local PostMaster is used when blank addresses
(which are allowed in RFC822 but not in X.400) are encountered that
must be converted into Message Router addresses. Please enter a full
domain address for the local PostMaster. Do not use shortform host
names since there is no guarantee that the address will be interpreted
in the context where the shortform name is valid.
RFC822 address of local PostMaster []? postmaster@nomr.acme.com
On VAX, this gateway can flatten WPS-PLUS and DX messages into ASCII
using a special utility. This utility is built from libraries provided as
part of various Message Router product sets, notably the Message Router
VMS Mail Gateway (MRGATE). If you intend to link this Document Conversion
Facility (DCF) utility to convert messages in these special formats to
ASCII, answer YES. If you answer NO, WPS-PLUS and DX message bodyparts
will not be converted.
IMPORTANT NOTE: The above described DCF facility is available ONLY
on the VAX architecture. For Alpha AXP systems running
PMDF-MR, you must answer NO to this question. In that
case (or if you prefer on VAX) the following will apply:
If not converted to ASCII, WPS-PLUS and DX message bodyparts will be
extracted and labelled appropriately for MIME. You can then use a PMDF
CONVERSION channel together with document conversion software such
as CDA Library or KeyPAK to perform more comprehensive conversion than
flattening to ASCII text.
Flatten WPS-PLUS and DX messages to ASCII automatically [N]? RETURN
Enter the name of the file to which the text form of the PMDF to
MR mapping should be written. This file will be created automatically
by this configuration procedure. Any old versions of the file will be
superseded.
PMDF to MR mapping text file [PMDF_ROOT:[TABLE]TO_MRIF.TXT]? RETURN
Enter the name of the file to which the text form of the MR to PMDF
mapping should be written. This file will be created automatically by
this configuration procedure. Any old versions of the file will be
superseded.
MR to PMDF mapping text file [PMDF_ROOT:[TABLE]FROM_MRIF.TXT]? RETURN
Enter the name of the file to output the database form of the PMDF to
MR mapping to. This file will be created automatically by this
configuration procedure. Any old versions of the file will be
superseded. This file name must agree with the PMDF_TO_MR_DATABASE
logical for it to be employed by the gateway.
PMDF to MR mapping database [PMDF_ROOT:[TABLE]TO_MRIF.DAT]? RETURN
Enter the name of the file to output the database form of the MR to
PMDF mapping to. This file will be created automatically by this
configuration procedure. Any old versions of the file will be
superseded. This file name must agree with the PMDF_FROM_MR_DATABASE
logical for it to be actually used by the gateway.
MR to PMDF mapping database [PMDF_ROOT:[TABLE]FROM_MRIF.DAT]? RETURN
Enter the name of the file to contain the PMDF configuration rewrite
rules created by this procedure. This file should subsequently be
included in your PMDF configuration file.
Rewrite rules text file [PMDF_ROOT:[TABLE]MR.RULES]? RETURN
Enter the name of the file to write the channel block definition
for the PMDF-MR channel to. This file will be created automatically
by this configuration procedure. Any old versions of the file will be
superseded.
Channel definitions text file [PMDF_ROOT:[TABLE]MR.CHANS]? RETURN
This procedure generates a checklist file that contains the list
of actions you must perform in order to make the PMDF-MR gateway
operational. This procedure does *NOT* perform these operations
itself; you must do them manually.
PMDF-MR checklist file name [PMDF_ROOT:[TABLE]MR.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]? RETURN
Generating PMDF to MR mapping text file...
PMDF to MR mapping text file is complete.
Generating MR to PMDF mapping text file...
MR to PMDF mapping text file is complete.
Generating the MR.RULES file...
MR.RULES file is complete.
Generating the MR.CHANS file...
MR.CHANS file is complete.
Generating the setup checklist...
Checklist file is complete.
Converting the PMDF to MR mapping text file to a database...
Entries converted: 26
Exceptions generated: 0
Entries too long to fit: 0
PMDF to MR mapping conversion is complete.
Converting the MR to PMDF mapping text file to a database...
Entries converted: 64
Exceptions generated: 0
Entries too long to fit: 0
MR to PMDF mapping conversion is complete.
Generating options files...
Options files are complete.
***********************************************************************
*
* To complete your PMDF-MR configuration, carry out the steps
* detailed in the setup checklist PMDF_ROOT:[TABLE]MR.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
$
Example 20-5 Example checklist file for PMDF-MR V6.0 configuration for Message Router TS replacement
$ TYPE mr.checklist
Checklist for setting up your PMDF-MR gateway.
Written by SYSTEM, 4-FEB-2000 16:50
This file was created by the PMDF-MR configuration generator V6.0.
(1) Add the contents of the MR.RULES file to the existing set of
rewrite rules in your PMDF configuration file by adding the line
<PMDF_ROOT:[TABLE]MR.RULES
to the rewrite rules section of your PMDF.CNF file; it should be
be added before any general TCP/IP rewrite rules (e.g., .COM,
.EDU, etc. normally included as <PMDF_TABLE:INTERNET.RULES).
It should start in column one with no surrounding blank lines
added by you.
Note: if you find the lines
!
! Rewrite rules for PMDF-MR
!
!<PMDF_TABLE:MR.RULES
around the middle of your PMDF.CNF file, merely
uncomment the line "!<PMDF_TABLE:MR.RULES" and, if
necessary, change the file name so that it reads
!
! Rewrite rules for PMDF-MR
!
<PMDF_ROOT:[TABLE]MR.RULES
(2) Include the channel definition in your configuration file:
by adding the line
<PMDF_ROOT:[TABLE]MR.CHANS
to the very end of your PMDF_TABLE:PMDF.CNF file; it should
start in column one and be preceded by a single blank line.
Note: if you find the lines
!
! PMDF-MR channels
!
!<PMDF_TABLE:MR.CHANS
towards the end of your PMDF.CNF file, merely
uncomment the "!<PMDF_TABLE:MR.CHANS" line and, if
necessary, change the file name so that it reads
!
! PMDF-MR channels
!
<PMDF_ROOT:[TABLE]MR.CHANS
(3) To effect Message Router emulation, logical names are used
to point to PMDF-MR emulation images:
(a) Shut down the product or component. In ALL-IN-1 this means
that the sender and fetcher must both be stopped. In
MailWorks use the X4MAN utility's STOP command to stop all
running MailWorks servers.
(b) The necessary logicals must be defined to point at the
replacement images. In the case of ALL-IN-1 one of the
following definitions will suffice:
$ DEFINE/SYST/EXEC MRAPPSHAR PMDF_EXE:MRAPPSHAR_EMUL.EXE ! VAX
$ DEFINE/SYST/EXEC MRAXPSHAR PMDF_EXE:MRAPPSHAR_EMUL.EXE ! AXP
These definitions can be DEFINE/table=LNM$GROUP_nnnnnn to confine
it to the group where ALL-IN-1 sender and fetcher run in
if necessary to avoid activating PMDFSHR.EXE as part of user
ALL-IN-1 sessions.
In the case of MailWorks the definition should be:
$ DEFINE/SYST/EXEC MUAS$MRIF_SHR PMDF_EXE:MUAS$MRIF_SHR_EMUL.EXE
The DEFINE commands used above should also be added to the
system startup procedure so that they are performed before the
affected products are started. For instance, you may put such
definitions in the site-supplied file PMDF_COM:PMDF_SITE_STARTUP.COM
to have the definitions performed during the regular PMDF startup.
(c) Restart the affected product or products.
For ALL-IN-1, you need to restart the sender and
fetcher. For Mailworks, you need to restart the
Mailworks server using the X4MAN utility's START command.
REMEMBER: Stop and restart these whenever you make changes
to PMDF configuration files.
(4) If you are running a domain name system (DNS) nameserver, you
will need to insert MX or A record(s) for the gateway into your
database. If you are using host tables, make sure to add host
aliases for the gateway.
The names to be added are:
a1.nomr.acme.com
am.nomr.acme.com
(5) For proper handling of attachments, you should consider
enabling mappings such as those demonstrated in the sample file
PMDF_TABLE:MR_MAPPINGS.SAMPLE. To enable these mappings, you may
start by cutting and pasting the contents of the sample file into
the PMDF_TABLE:MAPPINGS. file. Modify the mapping entries, if
necessary, to correspond to the Message Router label tags in
actual use at your site.
That's all!