|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T p
Length: 29702 (0x7406)
Types: TextFile
Names: »part.7«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z«
└─⟦bcd2bc73f⟧
└─⟦this⟧ »design/part.7«
Part 7: Directing.
All addresses that resolve <next_host> to our local host
will be processed through the ``director'' subsystem. This
subsystem will ``direct'' local addresses elsewhere, or to
their destinations on the local host. Examples of actions
that come under the heading of directors are: expanding
mailing lists, aliasing, forwarding and resolving a local
address to a specific mailbox on the local host.
As with routing and transport, the director subsystem is driver
based, allowing much flexibility. The director configuration
file format and several examples of the use of drivers are given
in following sections.
Section 7.1: Local form addresses.
Local-form addresses come in four styles: name form, pipe-forms,
file-forms and mailing-list-form. These are defined as:
<pipe_form> = |<word> or "|[^"]+"
<file_form> = <absolute_file> or <user_file> or <home_file>
<mailing_list_form> = :include:<file_form> or
":include:[^"]+"
<name_form> = not a <pipe_form> or <file_form> or
<mailing_list_form>
<absolute_file> = /<word> or "/[^"]+"
<user_file> = ~<word>/<word> or "~[^/"]+/[^"]+"
<home_file> = ~/<word> or "~/[^"]+"
A <name_form> is passed to directors to uncover their meaning.
A <pipe_form> defines a string that is to be executed as a
shell command with the message on standard input. A <file_form>
defines a file where the message should be appended. Finally,
a <mailing_list_form> defines a file from whence new recipient
addresses should be extracted. <mailing_list_form> addresses
are passed to director drivers as well, though there are special
restrictions on them.
There are many restrictions on where local addresses other than
<name_form> addresses can come from. They cannot be given as
the input recipient addresses from the sender and they may be
restricted by direct file entries. Drivers should detect unsecure
cases, such as publicly writable files or files in publicly
writable directories and disallow non <name_form> addresses.
Section 7.2: The director file.
The director file describes the use of director drivers and the
order that they are called. Its format follows the standard
described in Part 5.
The following list defines the current set of generic attributes:
caution
type: boolean
If set then be cautious of addresses produced by this
director. If the nobody attribute is not set, then
reject file, shell command or :include:filename-style
mailing list addresses.
default_group
type: string
If the driver does not associate a group to an address
returned by it, then associate the group id for this
group name. This will override the gid set by a
default_user attribute.
default_home
type: string
If the driver does not associate a home directory with
an address returned by it, then use this home direc-
tory. The value will be expanded to form the actual
directory pathname. At the present time, the $user
variable is not available for this expansion. If the
string exapansion fails, it is ignored.
default_user
type: string
If the driver does not associate a user or group to an
address returned by it, then associate the user id and
group id of this user.
driver
type: string
The driver attribute names a specific set of low-level
functions which will do the work of directing local
mail. This attribute is required.
nobody
type: boolean
If set, then access files, or run shell commands as the
user specified by the nobody attribute, for addresses
flagged with caution by either the caution generic
attribute or by the driver. Association of nobody with
an address overrides the default_user, default_group,
set_user and set_group attributes. This attribute is
set by default.
owner
type: string
Names the address to be sent mail if an error occurs in
processing the addresses produced by this director.
This string is expanded with the variable $user set to
the local-form address passed to the director. Com-
monly the value will be ``owner-$user''. If this
string expansion fails, it is ignored.
sender_okay
type: boolean
If set, then it is always okay for this attribute to
produce an address equal to the sender. This effec-
tively turns on the me too flag for this director.
This should generally be set for forwarding directors
and should not be set for aliasing and mailing list
directors.
set_group
type: string
Associate the gid for this group with the addresses
returned by the driver. This overrides any gid set by
the set_user attribute.
set_home
type: string
Associate this home directory with all addresses
returned by the driver. This will be expanded in the
same manner as default_home.
set_user
type: string
Associate the uid and gid for this user with addresses
returned by the driver. This overrides any values set
by the driver.
Director drivers have the option of flagging addresses with
`caution', or `unsecure'. Addresses flagged with `caution' by a
driver behave as if the director had the `caution' attribute set.
For addresses flagged with `unsecure' by a driver, the nobody
attribute is ignored and non name-form addresses are rejected.
Section 7.3: Director drivers.
Following sections give details about specific director
drivers. But before we look at drivers we need to examine in
more detail how these drivers are used.
When a local-form address is parsed it is passed to the
director subsystem which will return two lists: a list of
addresses it fully resolved to a transport, and a list of
addresses produced that require further resolution.
When a driver returns that no expansion was found, the next
director file entry is used. If no more director file entries
exist, then we failed to deliver to the local address.
When a driver returns an expansion for further resolution the
addresses are parsed to determine if they are in remote or
local form. If in local form and the form is one of
<file_form>, <pipe_form> or <mailing_list_form> then the
address is rejected if the driver flagged the source as
`unsecure', or if it was flagged for `caution' and the `nobody'
attribute is turned off.
If a <file_form> or <pipe_form> address is accepted then it
is placed on the list of fully resolved addresses associated
with the ``pipe'' or ``file'' transport, whichever is appropriate.
If a <mailing_list_form> address is accepted then it is
generally handled by the mailing-list director drivers.
Mailing-form addresses are left on the list of addresses to
be resolved.
As a special case, a <name_form> address produced by a director
that has the same name as the input <name_form> will be passed to
the driver for the next director file entry. This would allow,
for example, the following sequence: an alias for the user foo
wishes to send to /usr/save/foo as well as to the user foo; the
user foo wishes to send to another address foo@remote and also
to his mailbox. The aliasfile line would be:
foo: /usr/save/foo, foo
and the forwardfile would be:
foo@remote, foo
If this occurs for the last director entry in the director
file, the address (e.g., foo above) is treated as an unknown
address. This feature will also work if the <name_form> produced
has a <target> part which matches a known name for the local host
and the <remainder> part matches the input <name_form> address.
Also, it is always okay for the sender address to be produced
this way, independently of the setting of the `sender_okay'
attribute or the `me too' flag (see Section 9.6).
Section 7.3.1: The aliasfile driver.
The base standard for the format of the aliases and forward
files should be the format that is used by sendmail(8). This
format is simple yet powerful enough for most needs.
A sendmail-compatible aliases file consists of relations
between alias names and the lists of entities to that the
aliases expand.
The following rules define a sendmail-compatible aliases file
format:
<aliases> = (<alias_def> or <include_file> or <comment>)*
<alias_def> = <alias_name>:<alias>(,<alias>)*
<comment> = #[^\n]* or [\n]
<alias_name> = <local_part> or <mailbox_file>
<alias> = <address>
An <alias_def> can be continued across several lines by
beginning continuation lines with at least one white space
character. A <comment> can be included within an <alias_def>
and is ignored.
The following is a sample alias file for a machine nsavax:
# Sample aliasing file for nsavax
root: brown, casey # redirect root's mail
postmaster: brown # brown maintains netnews and mail
netnews: brown
north: north, fawn # copy fawn on all north's mail
# post important information to network
msgs: local-msgs@ciacray, local-msgs@nscprofs,
local-msgs@nsavax
local-msgs: "|/usr/ucb/msgs -s" # deliver to msgs program
# administrivia
rnews: |/usr/lib/news/uurec # read news messages from mail
# aliases for accessing users on the local network
nsavax-users: :include:/usr/lib/mail/nsavax-users
ciacray-users: :include:/usr/lib/mail/ciacray-users
nscprofs-users: :include:/usr/lib/mail/nscprofs-users
# mail to everybody on the local network
everybody: nsavax-users, ciacray-users, # well, almost everybody
nscprofs-users
# save mail to mailing list requests and send to moderator
funding-request: /usr/log/funding-req, reagan@nscprofs
covert-bugs-request: /usr/log/covert-bugs-req, james.bond@ciacray
# broadcast to mailing lists, and save a copy
funding: :include:/usr/list/funding, # excludes congress
/usr/log/funding
covert-bugs: :include:/usr/list/covert-bugs, # includes kgb
/usr/log/covert-bugs
The aliasfile driver searches for matches between a <name_form>
address on input and an <alias_name> for the alias file
entries. If found, it returns the associated list.
It has the following <driver_attribute>:
file
type: string
Define the name of the file containing the database.
interval
type: number
A sleep interval between open retries, in seconds. On
systems which have 1 second granularities on wakeup
times and where, as a result, sleep times can be nearly
0 seconds, this number should be at least 2.
modemask
type: number
A mask, ala umask(2), defining the maximum permissive-
ness allowed for the permissions on the alias file.
For example, a modemask of 022 disallows write access
to all but the file owner.
optional
type: boolean
If set, then if the open fails, assume an empty alias
file. This is useful for optional databases. For
example, in a networking environment, workstations may
be configured with the option of having a private alias
file, without the necessity of creating such a file on
each host.
owners
type: string
A list of permissible owners for the alias file.
owngroups
type: string
A list of permissible owning groups for the alias file.
proto
type: string
Names the protocol used in opening and searching the
database. Possibilities are discussed below.
reopen
type: boolean
If this attribute is on, the alias file will be closed
and reopened after each call to the driver. This is
useful for systems that have a shortage of file
descriptors yet wish to access a large number of data-
bases.
retries
type: number
the maximum count of open retries. This should be
greater than zero if the system does not have an atomic
rename(2) system call, as the alias file may not always
exist while being modified.
tryagain
type: boolean
If set, then if the open fails, the resolution of local
addresses will be attempted at a later time. This is
useful in a networking environment where failure to
open a database (such as a remote YP database) may be a
result of a server machine being down or temporarily
inaccessible.
If any of the attributes `modemask', `owners' or `owngroups'
reject the file as a possibile security problem, all addresses
returned are flagged with `caution'.
NOTE: as mentioned in the pathalias router driver section,
the proto attribute may go away in the future, to be
replaced by software that automatically determines
the best protocol to use.
A sample sendmail-compatible entry in the director file is:
# don't perform any authentication on the alias file
aliases: driver=aliasfile;
file=/usr/lib/aliases, proto=dbm
Section 7.3.2: The forwardfile driver.
Sendmail-compatible forward files have the same structure as
mailing lists. This format is:
{<address>({, }<address>)*}
Where newlines can be included wherever whitespace is allowed,
and where a `#' character begins a comment that ends at the
end of the line. Comments are treated as whitespace.
An example forward file for the user james.bond on nsavax is:
# send to my own machine, but keep a copy here
# if it doesn't make it there.
bond%british-ss@ciacray, james.bond
A useful forward file is:
# I am on vacation, save away my mail, but tell people
# I won't be back for a while
hustead,
"|mailx -s 'Yep, gone fishing!' \"$SENDER\" < $HOME/.fish"
that will save to Hustead's mailbox file and will also execute
the following shell command:
mailx -s 'Yep, gone fishing!' "$SENDER" < $HOME/.fish
where the shell variables $HOME and $SENDER are available from
the environment as the user's home directory and the sender
address, respectively. Note that if the ignore_write_errors
attribute is not turned on, this example will cause mail to
be returned to the sender stating that a write error occured
on the pipe to mailx. To prevent this, the line could also be
changed to:
"|cat>/dev/null;\
mailx -s 'Yep, gone fishing' \"$SENDER\"<$HOME/.fish
where the `cat>/dev/null' will read stdin, preventing a write
error on the pipe.
The current <driver_attributes> for the forwardfile driver are:
caution
type: string
This string defines a list of users and directories
which should cause addresses to be flagged with cau-
tion. Each entry in the list is expanded individually.
If this string expansion fails, it is ignored. Typi-
cally, this string is ``root'', thus preventing file
and shell command from being performed as the
superuser.
checkowner
type: boolean
If set, then one of the permissible owners will be the
user associated with the forward file.
file
type: string
The name of a file containing the forward information
for a user. This string will be expanded with the
local name passed to the director available as $user
and any associated home directory available as $HOME.
If this string expansion fails, it is ignored.
forwardto
type: boolean
If set, then the file must begin with ``Forward to ''
to be considered a forward file. Also, only the first
line is scanned for addresses. This ``feature'' mimics
the capability found in some systems for hiding for-
warding information in user mailboxes.
modemask
type: number
A mode mask defining the maximum permissiveness allowed
for the permissions on a forward file. Analogous to
the modemask attribute for the aliasfile driver.
owners
type: string
Specifies a list of user who may own the forward file.
owngroups
type: string
Specifies a list of groups who may own the forward
file.
unsecure
type: string
This string defines a list of users and directories
which should cause addresses to be flagged with
unsecure. This will prevent delivery to shell commands
or files. Each list entry is expanded. If this string
expansion fails, it is ignored.
If none of the attributes `owners', `owngroups' or `checkowner'
is given, no checks are made on ownership restrictions. The
default modemask is 0, effectively disabling checks for file mode
restrictions.
NOTE: unless the file attribute contains $home or begins with
~/ the forward file driver can be used to provide forward
files for users or names that are not listed in the passwd
file. In this case, $user merely expands to the address
passed to the forwardfile driver. This feature can be
used for setting up forwarding for obsolete accounts or
mailing list directories.
An example of useful forwardfile director file entries is:
# put forwarding addresses for obsolete accounts under
# the /u/obsolete directory. These will contain only
# forwarding addresses. This is maintained by users in
# the group "admin" or "staff".
obsolete: driver=forwardfile; file=/u/obsolete/$user,
owngroups=admin:staff
# handle per-user forward files in each user's home
# directory. This is roughly compatible with BSD
# sendmail, though performs some access checks, and
# is very cautious of directories which are remotely
# accessible. Root's .forward entries will operate
# from the nobody uid.
dotforward: driver=forwardfile, nobody;
file=~/.forward, unsecure=~uucp:~ftp,
caution=root, checkowner, owners=root,
modemask=022
# allow the "Forward to " feature to be used from user's
# mailbox files.
forwardto: driver=forwardfile, nobody;
file=/usr/spool/mail/$user, caution=root,
checkowner, modemask=002
Section 7.3.3: The mailing-list drivers.
Mailing-list drivers come in two forms, one form for mailing-lists
derived by aliasing drivers, and another form for mailing-lists
derived by forwarding drivers. The reason for having two forms
is that security options take different forms depending on
where mailing-lists come from. Also, by having them separately
recognized it is possible to allow pipes and files in mailing-
lists from alias files but not from forward files. Note that if
a new driver is written that does not comply to the standards for
alias drivers and forwarding drivers, and that can produce mailing
lists, a new mailing-list driver may need to be written as well.
The format of a mailing list file is the same as that of a forward
file, a simple list of <address> values, with optional comments.
The driver attributes are common to both of the mailing-list
drivers:
copyowners
type: boolean
If set, attributes related to ownership restrictions
are taken from the director which produced the mailing
list address.
copysecure
type: boolean
The modemask is copied from the director which produced
the mailing list address.
interval
type: number
The sleep interval, in seconds, between retries.
match_director
type: string
Names the specific director that this entry matches
expansions of. This can be used to assign different
attributes from alternate uses of the aliasfile and
forwardfile directors.
modemask
type: number
The maximum permissiveness of file modes.
owners
type: string
A list of allowed owners.
owngroups
type: string
A list of allowed owning groups.
retries
type: number
The maximum count of open retries.
Section 7.3.4: The user director.
The user director directs mail to a mailbox for known user
on the local host. It will succeed if the <name_form> address
matches a user on the system and will put an entry on the list
of fully-resolved addresses.
The driver attributes are:
prefix
type: string
The prefix, if non-NULL, must be found in the front of
the username for this driver to be used. This prefix
is removed from the username prior to determining if it
is a valid user on the local host. This can be used to
set up an alternate name for each user on the system
which is not matched by aliasing or forwarding direc-
tor. Commonly, prefix will be set to ``real-'' for one
of the directors, so that mail can be guaranteed to be
delivered to a user's mailbox file on a specific host
by mailing to an address such as
``real-tron@namei.uucp.'' If a match is found, the
actual username is given to the transport.
transport
type: string
The name of the transport to associate with the
address.
A typical user director entry in the director file is:
user: driver=user; transport=local
This will associate any mail destined for a user on the
local host with the local transport.
By making the user driver a driver it becomes possible to
configure precedence in potentially useful ways. For example, a
publicly writable alias file or mailing list directory might
exist to allow users to create alternate names for themselves.
By putting the director entry for this alias file after even the
mailbox director entry, many potential problems are solved, such
that it would not be possible for an entry in this public alias
file to override a real user's mailbox. The same could be done
for a publicly accessible directory of mailing lists or obsolete
accounts, accessed through the forwardfile driver.
Section 7.3.5: The smart user driver.
It may be that you wish all mail to <name_form> values that you
don't recognize to be sent elsewhere. For example, there could
be a host in your domain that knows where most of the domain's
users reside. The smart user driver is a convenient way of
handling this case, by redirecting mail for unknown users
to another host. Note that this must be the last director
entry, if it is used, because it is non-discriminatory.
The possible driver attributes for the smart user driver are:
new_user - defines the new address to direct mail
to. This string will be expanded as described
in Section 5.2, with $user set to the passed
local address name, and $HOME being any
associated home directory.
well_formed_only - a boolean. If set, the smartuser
driver only matches an address if it contains
characters exclusively from the set of
letters, digits, whitespace, and `-' (dash),
`_' (underscore), and `.' (dot).
NOTE: If the well_formed_only attribute is on, use of $user
in new_user will have groups of one or more whitespace
and dot characters collapsed into exactly one dot. If
it is off, $user will be enclosed in double-quotes, with
backslash escapes where appropriate. This prevents the
the value of $user from changing the form of the address.
A sample entry is:
smartuser: driver=smartuser;
new_user=$user@gateway.domain,
well_formed_only
With this entry, the input addresses:
john
and John Q. Public
will become:
john@gateway.domain
and John.Q.Public@gateway.domain
respectively. If well_formed_only had not been set, the second
address would have been:
"John Q. Public"@gateway.domain
whereas the input address:
\unusual"address"in\deed
would become:
"\\unusual\"address\"in\\deed"@gateway.domain
Addresses which are produced by the smartuser driver are flagged
as such and will not themselves be matched by the smartuser
driver. Thus, infinite loops will not occur if gateway.domain,
from the example, happens to be the local host.
It is possible to set the new_user value in the config file
(described in Section 9.3). This is done by setting the config
file attribute smart_user. For example, the config file could
contain the following:
smart_user = $user@gateway.domain
Then, if the entry in the director file was:
smart_user: driver=smart_user; well_formed_only
the configuration would be essentially the same as in the second
smart_host example above. This makes it possible to share copies
of the director file among several machines, with the smart user
configuration specific to one machine being set in its private
configuration file.
This config file attribute is used only if the new_user attribute
is not given in the smart_user entry.
Section 7.4: A sample director configuration.
Here is a sample of a fairly standard director configuration,
which allows for one alias file, forward files, forwarding
information stored in mailbox files, resolution of local users
with or without a prefix of "real-", a mailing list directory,
and automatic forwarding of otherwise unknown users to a
remote host:
# @(#)/usr/lib/smail/directors 1.10.2 1/7/88 13:68:12
# the first two directors handle :include:filename form
# addresses from alias and forward files.
# handle mailing list addresses from aliases. We aren't always
# as careful with these addresses, so set caution.
aliasinclude:
# generic director attributes:
driver=aliasinclude, caution;
# driver-specific attributes:
copyowners, # copy possible owners from parent addr
copysecure # copy security limits from parent addr
# handle mailing list files from forward files.
# all permissions and restrictions come from the
# parent address.
forwardinclude:
# generic director aliases:
driver=forwardinclude;
# driver-specific attributes
copyowners, copysecure
# perform alias expansions from the file /usr/lib/aliases
# It should be owned by root, in the group admin or staff
# and should not be globally writable.
# Send errors to addresses of the form owner-<alias-name>
aliases:
# generic director attributes:
driver=aliasfile,
set_user=postmast, # do things as the mail administrator
owner=owner-$user;
# driver-specific attributes:
file=/usr/lib/aliases, # file containing the aliases
proto=lsearch, # small file, linear is search okay
owners=root, # the file should be owned by root
owngroups=admin:staff, # acceptible groups
modemask=002 # should not be generally writable
# handle .forward files in user home directories. Be careful
# of root and extra careful of directories which are
# remotely accessible. Root or the user own the files, but
# they should not be writable by other than the owner.
dotforward:
# generic director attributes:
driver=forwardfile,
sender_okay, # turn on `me too' processing
owner=postmaster; # errors go to the postmaster
# driver-specific attributes:
caution=root, # don't access things as root
unsecure=~ftp:~uucp, # catch remotely accessible directories
owners=root, # root can own a forward file
checkowner, # or a user can own his own file
modemask=022 # only owner should be able to write
# old-style forwarding information stored in user mailbox files
# same care as with .forward files, though there is no worry about
# remotely accessible directories. Note that usernames must
# be mapped into lower case to find the correct mailbox file
oldforward:
# generic director attributes:
driver=forward,
owner=postmast; # errors go to the postmaster
# driver-specific attributes:
file=/usr/spool/mail/${lc:user}, # BSD/V7 mail directory
forwardto, # file must start with "Forward to "
caution=root, # don't access things as root
owners=root, # root can own a mailbox file
checkowner, # or a use can own his own mailbox file
modemask=022 # only owner should be able to wrtie
# send to users' mailboxes
user:
# generic director attributes:
driver=user;
# driver-specific attributes:
transport=local # `local' delivers to mailbox files
# match the real- form for local users and deliver to the
# user's mailbox file
real-user:
# generic director attributes:
driver=user;
# driver-specific attributes:
transport=local, # `local' delivers to mailbox files
prefix="real-" # match, for example, real-root
# mailing lists can be put in the directory /usr/lib/lists/
# with names such as info-kgb. Names supplied in upper case
# are mapped onto lower case.
mailing_lists:
# generic director attributes:
driver=forwardfile,
caution; # always access things as `nobody'
# driver-specific attributes:
file=/usr/lib/lists/${lc:user} # mailing list directory
# anything else, we send off to be carefully examined
smartuser: driver=smaratuser;
new_user=$user@nsavax.nsa.gov,
well_formed_only
\f