Previous | Contents | Index |
When using a PMDF database, (i.e., a database created with
PMDF's CRDB
or crdb
utility), on OpenVMS and
UNIX you must create a directory to hold the database files. (On NT,
the appropriate directory is created during the PMDF installation.) On
OpenVMS systems, use the command:
$ CREATE/DIR pmdf_root:[directories]/OWNER=[SYSTEM] |
# mkdir -mu=rwx,go= /pmdf/directories # chown pmdf /pmdf/directories |
.dat
"; on UNIX and
NT, the database consists of several files whose name is the actual
pseudo domain name with the appropriate file type appended. For
example, if the pseudo domain name is x.y
, the
corresponding database file would be
pmdf_root:[directories]x$y.dat
on an OpenVMS system. On a
UNIX system, the database would be represented by the files
/pmdf/directories/x.y.idx
,
/pmdf/directories/x.y.lck
, and
/pmdf/directories/x.y.pbl
. On an NT system, the database
would be represented by the files
C:\pmdf\directories\x.y.idx
,
C:\pmdf\directories\x.y.lck
, and
C:\pmdf\directories\x.y.pbl
.
3.2.5.1 Database Entries
When using a PMDF database for a pseudo domain, each entry in the
database consists of a mailbox name in the pseudo domain and the
corresponding "real" address.
For example, suppose the pseudo domain is example.com
, the
one mailbox within this pseudo domain is john.doe
, and the
real address corresponding to this mailbox is
ariel@example.com
. To set up this domain, start with a
text file containing the line:
john.doe ariel@example.com |
example$com.txt
, process this file with the PMDF
CRDB
utility as follows:
$ PMDF CRDB/DUPLICATES example$com.txt - $_ pmdf_root:[directories]example$com.dat_tmp $ RENAME pmdf_root:[directories]example$com.dat_tmp - $_ pmdf_root:[directories]example$com.dat |
example.com.txt
, use the commands
# pmdf crdb -duplicates example.com.txt /pmdf/directories/example.com |
example.com.txt
, use the commands
C:\> pmdf crdb -duplicates example.com.text \pmdf\directories\example.com |
3.2.5.2 Default Entries
Special entries can be used to implement default redirections. Such
entries are only used when no other entry matches the mailbox. The
primary default rule has a single asterisk, *
, as the
mailbox:
* *@host.domain |
host.domain
using the original mailbox
specification. An entry of the form
* newmailbox@host.domain |
newmailbox
is
used as the mailbox.
Two other special entries are available. The first is the special
mailbox *%*
, which matches any mailbox specification
containing a percent sign. This is useful for matching and handling
percent-routed addresses. The second special entry is *!*
,
which matches any mailbox containing an exclamation point. Both of
these rules will be tried before the *
rule is attempted.
3.2.5.3 Wildcard Entries
Other than the default entries listed above, the only other type of
wildcard entries supported are ones where the subaddress is wildcarded.
For example:
mailbox+* newmailbox@host.domain |
3.2.5.4 Subaddresses
The way that directory channel lookups handles subaddresses is as
follows. First, the entire address including the subaddress is looked
up. Second, the subaddress is replaced with the wildcard (asterisk) and
that is looked up. And finally the subaddress is stripped altogether
and just the mailbox is looked up.
For example, if you have an address such as "jones+spam", the complete list of variants looked up in a directory channel database is as follows:
3.2.5.5 Duplicate Entries
Databases created with CRDB or crdb
can contain duplicate
mailboxes (if the /DUPLICATES
or -duplicates
qualifier is used). The directory
channel uses this
capability to provide an informative way of handling ambiguous
addresses. An error message is returned when the mailbox extracted from
an address matches a set of duplicate entries. The addresses associated
with the duplicates should be unambiguous entries associated with the
pseudo domain. This list of possible addresses is returned as part of
the error message so the recipient of the error can select an
appropriate address to use in future messages.
For example, suppose that the example.com
pseudo domain is
set up to contain entries for first names, last names, and dotted
combinations of first names and last names. There are bound to be
ambiguities in such a scheme for some common names. Specifically,
suppose that entries for John Smith, Jane Smith, and John Jones are
implemented. The entries for the names John and Smith would then be
ambiguous. Therefore, instead of listing an actual address for these
entries it would be more appropriate to list the unambiguous
equivalents in the directory. This leads to a set of entries that might
look like this:
john.smith smithjo@vaxa.example.com john john.smith@example.com smith john.smith@example.com jane.smith smithja@vaxa.example.com jane smithja@vaxa.example.com smith jane.smith@example.com john.jones jj0u887@vaxb.example.com john john.jones@example.com jones jj0u887@vaxb.example.com |
A message sent to smith@example.com
would then produce an
error message, but the message would recommend that either
john.smith@example.com
or
jane.smith@example.com
be used to disambiguate the address.
Note that PMDF contains no automatic facility to produce such databases; detection and resolution of ambiguities must be done by user-supplied programs.
Previous | Next | Contents | Index |