PMDF System Manager's Guide
4.1.4 Restrictions on Mailing List Aliases
There are some important restrictions that should be observed when
using mailing list aliases:
- The addresses in the mailing list file should be formatted as pure
RFC 822 addresses, e.g.,
user@host. Do not try to use DECnet or
other routing conventions that you can get away with in the rewrite
rules table. Not only can such things fail, they can not produce a
visible error (see the next item). Source routes are the only exotica
that are permitted.
- Certain types of bogus addresses in a list alias will not
generate a "bad address" return message. Specifically, if,
for a given address in the list, the system name is illegal or there is
a syntax error in the address specification, then the copy of the
message to that address can be silently dropped and no one will be the
wiser. If the mailing list file associated with an alias does not
exist, then mail to the list itself can be dropped. However, errors in
the mailbox part of the address (e.g., "no such
user") will be handled correctly. System managers should take care
to test each list they set up to insure that all the recipient
addresses are correct. The PMDF TEST/REWRITE/CHECK_EXPANSIONS (OpenVMS)
pmdf test -rewrite -check_expansions (UNIX and Windows)
utility provide a way to do this. Lists should be checked periodically
and also whenever extensive changes are made.
- PMDF reads the alias file only as each program using PMDF
initializes itself. This means that if you are using a permanently
resident server (such as the multi-threaded SMTP server, PMDF-XGS
channels, PMDF-LAN Lotus Notes channels, or PMDF-MR MRIF channels) you
should be sure to stop and restart the server each time a mailing list
alias definition is changed in the alias file (or any of the files the
alias file includes). (The
pmdf restart utility provides a
simple way to restart any such PMDF detached processes.) On the other
hand, mailing list files referenced by the alias file are read and
reread as needed, so servers need not be restarted when one of these
mailing list files is changed.
- Each PMDF process sees the alias database existing as of when it
first needed to access the database. This means that if you are using a
permanently resident server (such as the multi-threaded SMTP server,
PMDF-XGS channels, PMDF-LAN Lotus Notes channels, or PMDF-MR MRIF
channels) you should be sure to stop and restart the server each time a
mailing list alias definition's left hand side is changed in the alias
database, and each time a mailing list definition's right hand side is
changed if a new alias database file has been created (but not
if an existing alias database file was updated "in place"
using the PMDF CRDB/APPEND or
pmdf crdb -append utility).
On the other hand, mailing list files referenced by the alias file are
read and reread as needed, so servers need not be restarted when one of
these mailing list files is changed.
- The alias file is always read into memory in its entirety each
time PMDF is used. All files included by the primary alias file are
also loaded into memory. (Mailing list files are not loaded into
memory.) The use of a huge alias file can eat up lots of memory.
Liberal use of the mailing list reference operator, <, to reference
long lists is recommended. Long lists of addresses coded directly into
the alias file or any files it includes should be avoided. Use of an
alias database for large numbers of aliases is also recommended.
- Be sure to observe the length restrictions associated with aliases
when defining mailing lists, particularly as mailing list definitions
can get rather long. Aliases in the alias database can contain up to 32
characters in a short database, up to 80 characters in a long database,
and up to 252 characters in a huge database. In the cases of a short
database the translation value can contain up to 80 characters; in the
case of a long database the translation value can contain up to 256
characters; in the case of a huge database the translation value can
contain up to 1024 characters. In some cases failing to observe length
restrictions can lead to addresses being silently dropped from lists.
Aliases in the alias file can contain up to 60 characters (referring
here to the left hand side of the definition). The right hand side of
an alias file definition is not specifically limited; however, each
physical line is limited to 1024 characters---use the backslash line
continuation character to continue a long definition over multiple
physical lines. Thus note that particularly long mailing list
definitions (definitions involving quite a few of the optional
parameters) can, for reasons of length, need to be stored in a huge
records alias database or in the alias file, rather than an alias
database of shorter records.