A mailing list is set up by creating a file in $MAILVAR/lists.  The
file name is the lists' name (LIST) in all-lowercase (case-insensitive
matching is done by converting to lowercase before comparison).  The
file contains a list of mail addresses (typically one per line) which
are parsed to pull out the destination addresses.  This means the
users' full names can be given just as in any valid RFC822 address.
The local account which owns the file will by default receive messages
sent to LIST-owner and LIST-request.  This can be explicitly overridden
in the aliases file.  Mail to the list will go out with LIST-owner as
the sender, so list bounce messages will return to the LIST-owner
address.  Archives of the list can be created by adding a file name
address (a local pathname starting with "/") to the LIST file.  The
archive file is written with the ownership of the owner of the LIST
file (NB!! see below).  Forwarding the mailing list into a newsgroup
can be done using a mail to news script (two generations are provided
in utils/distribute and utils/mail2news).

See the guides/aliases file for further information on aliasing.

Security considerations:

A LIST file must not be group or world writable, and the MAILVAR/lists
directory must also not be group or world writable and must be owned by
root or by the owner of the LIST file.  Otherwise the file is declared
insecure and all addresses in the file get the least possible privilege
associated (the "nobody" uid).  This can cause various things to break,
for example mailing list archival, or the -owner and -request features
if "nobody" is not a valid account.

There is a mechanism to override using the modes on a file/directory
as an indicator of its safeness.  Turning on the sticky bit on a file
or directory tells the mailer to treat it as if it was only owner-writable
independent of its actual modes.  This allows MAILVAR/lists to be
group or world-writable and sticky-bitted if you want your general
user population to be able to create mailing lists.


About large lists, and memory consumption:

Internal list expansion (thru the  $MAILVAR/lists/LISTNAME -mechanism)
is a sure way to expand router process memory usage.

You can decrease the memory requirement dramatically, if you can
feed all the addresses in the envelope, or via   utils/listexpand.c
utility (alpha-test tool on 1-Sep-94)..

You don't need to worry about it, unless your list is 100+ recipients,
only then the memory usage starts to bloat seriously..
