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:
jones+spam
jones+*
jones
*
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 |