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) or         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, or PMDF-LAN         Lotus Notes  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 restartutility 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, or PMDF-LAN Lotus Notes         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 -appendutility). 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.