⟦a35e9048a⟧

TextFile

\chapter {PP Tables}\label{sect:tables}

This chapter describes the purpose and syntax of the various tables
used by PP.
There are five basic tables used by PP, the \file{aliases} table, the
\file{users} table, the \file{domain} table, the \file{channel}
table and the \file{or} table.  How these are combined and used to
deliver and route messages is described below.

There are also a set of tables containing authorisation information
and a family of tables that provide mappings between X.400 O/R names
and RFC 822 domain names.  Specific channels may also have their own
tables containing the information they require.

\section{Basic operation of the tables}

When a message arrives, \pgm{submit} identifies if it is to be
delivered by the local MTA or if it is to be routed to a remote
host/MTA.

If the message is to be delivered by the local MTA, \pgm{submit}
references the \file{aliases} table to translate any aliases to the
real addresses they point to; and then looks at the \file{users} table
to determine which local channel is appropriate for that address (for
example, ordinary 822-local or structured local).

If the message is for a remote host/MTA, \pgm{submit} references
either the \file{domain} table to discover the fully-qualified for
RFC822 style addresses, or the \file{or} table for X.400 style
addresses.  If necessary the address is mapped from one form to
another (e.g.  RFC822 to X.400) by use of the mapping tables
{\file{or2rfc}} and {\file{rfc2or}}.  This produces the canonical name
for the host. The {\file{channel}} table is then used to determine a
list of channels that can be used to reach the host in question.

At this stage the channels are ordered in the preferred of use and
then checked in order for authorisation until a channel/mta/user
succeeds. Once this is achieved the necessary reformatting channels
are calculated and the message is then accepted.


\section	{The general syntax of table entries.}

In general, entries in the tables are in the form
\begin{quote}\small\begin{verbatim}
<key> ":" <value>
\end{verbatim}\end{quote}
The only special character is \verb|:| which if it appears on the LHS
must be preceded by a backslash ``$\backslash$'' to escape it. All other
characters are copied verbatim. However, some tables undergo further
processing and may need other escape sequences.

The purposes and details of the various tables now follow.

\section {The aliases table}\index{tables, alias}

The \file{aliases} table governs the handling of aliases for
user names. It is used for several reasons. These include:
\begin{itemize}
\item	Mapping non-users to usernames. (e.g. postmaster to some user)
\item	Redirecting users who have moved (e.g. fred to fred@foo.edu)
\item	Rewriting users addresses (e.g. jpo to j.onions)
\item	Mapping aliases. (e.g. j.p.onions to j.onions)
\end{itemize}
It is constructed as follows:

\begin{quote}\begin{verbatim}
<key> ":" <type>  <value>
\end{verbatim}\end{quote}

\begin{describe}
\item[\verb+type+]
Describes the user name or address.  This may be one of:
\begin{describe}
\item[\verb+alias+:]
local user name is specified, but this name does {\em not} replace the
original value. Aliases are not expanded for originators whereas
synonyms are.
\item[\verb+synonym+:]
local user name is specified, and this name replaces the original
value.
\item[\verb+822+:]
remote RFC822 user address is specified
\item[\verb+x400+:]
remote X400 user address is specified

\item[\verb+822-synonym+:]
\item[\verb+x400-synonym+:] these two values are used when one MTA is being
used to look like more than one mail hub.  This feature and these two
values are described in section~\ref{sect:multihub}.

\end{describe}

\end{describe}

A value resulting from searching this table is then used as the key
for repeated search.  This continues until no value is found. The last
value to be derived will indicate which delivery channel is
appropriate; if the final value is for a local address then that value
will be used as a key to lookup the \file{users} table;
if the final value is an RFC822 address an RFC822 delivery channel
will be used; or if the final value is an X400 address an X400
delivery channel will be used.

The format is best illustrated by a sample extract of the table as
shown in Figure~\ref{example:alias}.

\tagrind[hbtp]{alias}{Example Alias Table}{example:alias}

The table includes an entry for a local alias \verb+mailgroup-request+
The value \verb+Irene.Hassell+ is used as a key for a further search,
but will not replace the alias in the message header; if no match is
found, and since the entry is of type \verb|alias|, the address is
assumed to be a local one and used for accessing the \file{user}
table. Also, if a local submission arrives from
\verb|mailgroup-request| then checking and authorisation will be done
on the basis of \verb|mailgroup-request| rather than
\verb|Irene.Hassell|.

The next entry indicates that \verb+a.dacruz+ and \verb+alina+ are
both synonyms for \verb+Alina.DaCruz+.  Here, the user's address will
be converted to Alina.DaCruz, and this value will be used in future
table searches.

An entry is given for a remote RFC 822 user, \verb|jpo|. The value
\verb|jpo@uk.ac.nott.cs| would be parsed and routed on an RFC 822
delivery channel.

Then follows an entry for a remote X400 user, \verb|pc|: The value
\begin{quote}\small\begin{verbatim}
"/I=Peter/S=Cowen/OU=cs/O=nott/PRMD=uk.ac/ADMD=gold 400/C=gb/"
\end{verbatim}\end{quote}
would be parsed and routed on an X.400 delivery channel.  The quotes
({\tt "}) are needed as the entry contains a space which is normally a
separator.


\section{The users table}\index{table, users}

The \file{users} table determines the local delivery channel for a
particular local user.  It is formatted in the form:

\begin{verbatim}
<username> ":" <channel> [ <mta> ] 
               ["," <channel> [ <mta> ] ...]
\end{verbatim}

\begin{describe}
\item[\verb+Channel+:] specifies the name of a local delivery channel
on \verb+mta+.

\item[\verb+Mta+:] is the local machine on which the mailbox resides. 
If no mta is indicated, the channel may be used for delivery by any
local machine.

\end{describe}

A user can have several channels for local delivery.
For example, in figure~\ref{example:users} \verb+John.Taylor+ can have
his mail delivered either by the \pgm{822-local} channel or by the
\pgm{slocal} channel. 
Which of these two channels is actually used for delivery depends on
the format of the message being delivered.
This allows a user to have, for instance, X.400 format mail delivered
by one channel, and RFC822 mail by another channel.

\tagrind[hbtp]{users}{Example Users Table}{example:users}

Figure~\ref{example:users} illustrates how the various local users
will receive mail 
and on which machines their mailboxes reside.
An entry for a distribution list is also shown, and the entry for
\verb+warning+ shows the \pgm{shell} channel rather than a local
delivery channel.

\section {The domain table}\index{table, domain}

The \file{domain} table is used by submit to derive a fully-qualified
domain from any aliases or short-form names. See
Section~\ref{tablebuild:domain} on page~\pageref{tablebuild:domain} for a
description of how to go about constructing this table. The value
found on the RHS is used again as a LHS key until the LHS and RHS are
identical - at this stage the fully qualified name has been found and
the \file{channel} table will be consulted.

The table may include not only MTA or host names, but partial
domains.  If a full match on a host name is not found in the
\file{domain} table, the constituent dot-separated parts of the host
name - that is, the domains which comprise the name - will be used as
keys for repeated searches of the table. If a key is found for a
partial match then a second parameter on the RHS is checked for. This
is a range specifying how many subdomains are allowed for this
domain. 

Entries in the table may also contain the keyword \verb+local+.
This indicates that the domain is a local hub.
This feature is described in section~\ref{sect:multihub}.

So an entry in the domain is of the form:
\begin{quote}\small\begin{verbatim}
<aliasname> ":" <fullname> 
<fullname>  ":" <fullname> 
<partial> ":" <name> <lowerbound>":"<upperbound>
<fullname> ":" <fullname> 
\end{verbatim}\end{quote}

The lowerbound and the ``:'' may be missing, in which case the default
lower bound is set to \verb|0|. If the whole parameter is missing both
upper and lower bounds are taken as \verb|0|.  The special value
\verb|*| is used to indicate any number of domains for the upperbound.
This allows for wildcarding domains such as those obtained from the
NRS partial domain table, or for nameserver hosts. It also allows
wildcards not to be used as valid addresses, by insisting on at least
one domain component. The following example will illustrate some uses
of the syntax:
\begin{quote}\small\begin{verbatim}
edu:edu 1:*
fr:fr *
cs.nott.ac.uk:cs.nott.ac.uk 1
cs.ucl.ac.uk:cs.ucl.ac.uk
\end{verbatim}\end{quote}
This implies the following actions:
\begin{itemize}
\item The \verb|edu| domain will match all domain names with the most
significant component of \verb|edu| and at least one subdomain. Thus,
\verb|ucbarpa.berkeley.edu|, \verb|prep.ai.mit.edu| and \verb|foo.edu|
would all be matched by this entry. However an address of
\verb|user@edu| would not be matched.

\item The \verb|fr| domain matches all domain names with the most
significant component of \verb|fr|. This includes \verb|fr| itself.

\item The \verb|cs.nott.ac.uk| domain will match the explicit name
\verb|cs.nott.ac.uk| and will allow at most one domain component below
that, such as \verb|john.cs.nott.ac.uk|.

\item The \verb|cs.ucl.ac.uk| domain will only match the exact domain
name \verb|cs.ucl.ac.uk|. No subdomains at all are allowed by this
entry.
\end{itemize}
In this way the routing for a host can be determined from the tables
by resolving the host's top level domain, and then obtaining relaying
information for that top level domain.

An example is shown in Figure~\ref{example:domain}.

\tagrind[hbtp]{domain}{Example Domain Table}{example:domain}

\section{The O/R address table}\index{tables, X.400 O/R}\label{sect:ortables}

The \file{or} family of tables provide mappings between x.400 O/R names and
RFC 822 domain names, to be used by channels concerned with conversion 
in accordance with the RFC 987. Lines are encoded in the form: 

\begin{quote}\small\begin{verbatim}
<key> ":" <value> <value> ...
\end{verbatim}\end{quote}

In the \verb|<key>| field, the character ``:'' and ``.'' must be
preceded by a ``$\backslash$'' character.

Values are separated by white space, and so any space characters, must
similarly be preceded by either ``$\backslash$'' or else the value
should be encapsulated in double quotes.

The characters ``$\backslash$'' and ``.''  in a \verb|<value>|
field must always be preceded by a ``$\backslash$''.

The \file{or}\index{or} table is used to evaluate O/R Addresses.  The
\verb+<key>+ is encoded as dmn-orname (see RFC 987).  The default
algorithm for O/R Name analysis should be considered as
``tree-walking''.  The O/R address components are sorted, and
components are looked up: first level 1; then level 1 + level 2 and so
on.  So repeated lookups are carried out, using this table.

The RHS has four possible encodings:

\begin{describe}

\item[\verb+valid+]
This means that this part of the tree is OK.

\item [\verb+mta <mtaname>+]
This identifies the mta \verb|<mtaname>| as being associated with this
vertex of the tree.  This \verb|<mtaname>| is a key to the PP channel
tables.  The search should NOT stop at this point, as further tree
searching may determine a more optimal site.

\item [\verb+alias <dmn-orname>+]
This identifies an alias, and indicates that all O/R components matched
so far, should be replaced with those identified on the RHS, and the
search should now resume from the root.

\item [\verb+local+]
This identifies a local O/R Address.  The remainder of the O/R Address
should be used to determine a local mailbox.
\end{describe}

Figure~\ref{example:or} gives an example which shows the validity of
some Country, ADMD, and PRMD values, and indicates which MTAs will
deal with which PRMDs.  The MTA value given here is internal to the PP
lookup system, providing a unique key with which to reference the
channel table.

\tagrind[hbtp]{or}{Example Or Table}{example:or}

\section {The channel table}\index{channel}\index{tables, channel}

Every remote host/MTA has an entry in this table - \pgm{submit} uses
it to discover the channel and in some cases relaying host, that must
be used to send to the host in question.  See
Section~\ref{tablebuild:channel} on page~\pageref{tablebuild:channel}
for a method of building this table. The format of an entry has the
form:

\begin{verbatim}
<key> ":" [ <mtaname> ] "("<channel>")" 
          ["," [ <mtaname> ] "("<channel>")" ...] 
\end{verbatim}

\begin{describe}
\item[\verb+key+:] is the fully qualified
name derived from the \file{domain} table.
\item[\verb+mtaname+/\verb+channel+:] the \verb+mtaname+ derived from
this lookup will be used as a key in the appropriate \verb+channel+ table.
If there is no \verb|mtaname| present, then the
mta key is reached directly through that channel. This sort of action
is appropriate if the channel uses external information (such as the
DNS) to look up the domain.
\end{describe}

There may be a number of possible channels for each host.
Figure~\ref{example:channel} illustrates an extract of this table.

\tagrind[hbtp]{chantbl}{Example Channel Table}{example:channel}

An entry with an empty RHS is allowed and indicates that this is a
valid domain name, but not a valid delivery route. This is usually
used to allow checking to proceed when the address should be mapped to
a different form of address.

\section{One MTA locally supporting multiple organizations} \label{sect:multihub}

In some situations one may want PP to behave like two or more distinct
mail hubs e.g. \verb+cs.nott.ac.uk+ and {\verb+physics.nott.ac.uk+}.
This behaviour is possible using the \verb+822-synonym+ and
\verb+x400-synonym+ keywords in the \file{aliases} table and the
\verb+local+ keyword in the \file{domain} table.

To get this behaviour, the following actions should be followed.

First create, in separate files, the \file{aliases} and the
\file{users} tables for each other hub.  These files should have the names
of the form \verb+hubname-aliases+ and \verb+hubname-users+.  So for
\verb+physics.nott.ac.uk+, create the \file{aliases} table
\verb+physics-aliases+ and the \file{users} table \verb+physics-users+.

Then place one entry for each local hub in the \file{domain} table.
This entry should have the form:

\begin{quote}\small\begin{verbatim}
<fullname> ":" <fullname> <lower>":"<upper> "local" <hubname>
\end{verbatim}\end{quote}

Note that the default local hub (\verb+cs.nott.ac.uk+) should have a
null \verb+hubname+.

Now for \verb+physics.nott.ac.uk+ create the following entry in the
table:

\begin{quote}\small\begin{verbatim}
physics.nott.ac.uk : physics.nott.ac.uk 0 local physics
\end{verbatim}\end{quote}

Finally an entry for each user in each hub should be placed in the
main \file{aliases} file.
This entry should have the type \verb+822-synonym+ or
\verb+x400-synonym+.

With these actions taken, PP will then act like two or more hubs.

For example, if a message came in for \verb+jpo@physics.nott.ac.uk+
then the lookup in the \file{domain} table would identify this as a
local address for the hub with the name \verb+physics+.
PP would then lookup the tables \verb+physics-aliases+ and
\verb+physics-users+ to find out how to deliver the message.

If \verb+jpo+ sent out a message, his user agent would probably fill
in his address in terms of the default local hub (\verb+cs.nott.ac.uk+
in this case).  PP could then correct this address to refer to the
right hub by looking up the information placed in the main
\file{aliases} file (\verb+822-synonym+ and
\verb+x400-synonym+ entries).

Another use of the \verb+x400-synonym+ and \verb+822-synonym+ comes
about when a user moves.  In which case, the mail administrator could
redirect that users mail by simply putting a relevant
\verb+822-synonym+ or \verb+x400-synonym+ entry in the aliases file.
This entry should be of the form:

\begin{verbatim}
<oldaddress> ":" "822-synonym" <newaddress>
\end{verbatim}

\section{RFC 987 mapping tables}

These mappings are used in gateways to convert between X.400 addressing
and RFC822 addressing. The mappings involved are not algorithmic
making neccessary the use of such tables.

\subsection{The O/R to RFC 822 Table} 

The table \file{or2rfc}, exemplified in Figure~\ref{example:or2rfc},
is for mapping OR names into RFC 822 addresses.  The \verb+<key>+ is
encoded as domain-syntax (see RFC 987 and RFC 1026) and
\verb+value+ as dmn-orname.  The longest possible match is sought.

\tagrind[hbtp]{or2rfc}{Example Or2rfc Table}{example:or2rfc}

\subsection{The RFC 822 to O/R table}
Performing exactly the reverse operation is
\file{rfc2or}\index{rfc2or}, which has the \verb+<key>+ encoded as
dmn-orname and the \verb+<value>+ as domain-syntax. An example of the
format is given in Figure~\ref{example:rfc2or}.

\tagrind[hbtp]{rfc2or}{Example Rfc2or Table}{example:rfc2or}

\subsection{The known RFC 1148 gateway table}

The \file{rfc1148gate} table has the same syntax as the \file{rfc2or}
table.  It's entries represent gateways between X.400 and RFC 822 (via
RFC 1148). This tables is used in the cases where RFC822 messages are
relayed across an X.400 link. In such cases mapping to X.400 addresses
may not always make sense as there will effectively be routing
information encapsulated in the address. Normally this would cause the
message to fail. However, if it is known that the destination is an
RFC1148 gateway, then the mapping can proceed in the expectation that
the other end can unwrap the message.

An example RFC1148 gateway file is shown in
Figure~\ref{examp:rfc1148g}.

\tagrind[hbpt]{rfc1148g}{Example RFC 1148 gateway table}{examp:rfc1148g}

\section {The 822 local table}\index{tables, channels, local}

The \file{ch.local}\index{ch.local} table is an example of a table
accessed by different channels - both 822-local and slocal channels use it
in order to find out where to deposit mail to a specific mailbox
address, to be dealt with by the user agent.  The format is:

\begin{verbatim}
name ":" <unix ID> [<home directory> [<file>]]
\end{verbatim}

The unix ID is either a password username, or a userid groupid pair
separated by a slash. If this is the case, no password entry is looked
up and at least a home directory must be given.

If no directory component is present, then the user's directory
will be taken from the \file{/etc/passwd} file.
If no mailbox is present, the system default is used.

For example:

\begin{quote}\small\begin{verbatim}
Alina.DaCruz:alina /cs/research/dsa/users/vs1/alina
John.Taylor:jtaylor /cs/research/dsa/users/vs1/jtaylor
Postie.Pat:pp /cs/research/dsa/vs2/pp
bug-filer:32767/1001 /usr/spool/mail bugs
\end{verbatim}\end{quote}

\section {The X.400 (1984/1988) outbound table}\index{tables}\index{channels}
\index{X.400 84, X.400 88}\label{tab:X.400(84)out}

This table is used by the outbound X.400 channels, allowing them to map the
host name to the information needed for addressing and connecting
to the remote MTA\index{ch.x400out84}.  The key in this table is the
value representing the mta derived from the ``mtaname'' field of the 
\file{channel} table. The value is a set of \verb+key=value+ fields
separated by white space and/or commas.

\begin{quote}\small\begin{verbatim}
mta key:rmta=xx,rpass=xx,rpsap='"591"/Janet=000005110000',
\end{verbatim}\end{quote}

The \verb+mta key+ is the key from the address lookup. This is the
remote host to which the outgoing connection it to be made.
The following keys are recognised in the value field:

\begin{describe}
\item[\verb+lmta+:]	The name of the local mtaname to pass in the
RTS connect parameters. This defaults to local site name if not set.

\item[\verb+lpass+:]	The passwd of the local site to pass in the
RTS connect parameters. This defaults to the default password specified
in the tailor file.

\item[\verb+rmta+:]	The name of the remote mta to pass in the RTS
connect parameters. If this is not set, then no authentication will be
specified in the RTS connect.

\item[\verb+rpass+:]	The name of the remote password to pass in the
RTS connect parameters. The is no default for this and it should be
set if the \verb+rmta+ is set.

\item[\verb+rpsap+:]	The remote presentation address. This is
specified in the string encoded format. Note that session selectors
and presentation selectors should always be absent in the 1984 RTS.

\item[\verb+lpsap+:]	The local presentation address. This is only
necessary if you need to claim to originate from a specific selector
or network address. Normally this parameter is not specified.

\item[\verb+mode+:]	The mode of RTS connection. This is either
\verb+mon+ for monologue (the default) or \verb+twa+ for two way
alternate. This only governs the mode passed initially, it does not
imply that the channel will work in TWA mode.

\item[\verb+type+:]	The type of RTS connection. This is one of the
following:

\[\begin{tabular}{|l | l|}
\hline
	\multicolumn{1}{|c|}{\bf Value} &
		\multicolumn{1}{|c|}{\bf Meaning} \\
\hline
	\tt 1984 & Use the 1984 protocol mode (default). \\
	\tt 1988-X410 & Use the 1988 X.410 mode protocol, \\
	\tt 1988-normal & Use the 1988 normal mode protocol. \\
	\tt 1988 & Use the 1988 normal mode protocol. \\
\hline
\end{tabular}\]

Obviously, this information is dependent on the capabilities of the
channel (a 1984 based channel will not be able to use the 1988
protocol).

\item[\verb+trynext+:] A key to another entry in the table. If a
connection using the current information fails, lookup this key and
try making a connection using that data.

\item[\verb+tracing+:] The style of tracing information to use. It may
take one of the following values:

\[\begin{tabular}{|l | p{0.6\textwidth}|}
\hline
	\multicolumn{1}{|c|}{\bf Value} &
		\multicolumn{1}{|c|}{\bf Meaning} \\
\hline
	\tt admd & Remove all but the first tracing component. \\
	\tt nointernal & Remove all internal tracing components. \\
	\tt local-internal & Keep only internal trace related to this
				PRMD. \\
	\tt all & keep all tracing information\\
\hline
\end{tabular}\]

The \verb|admd| mode should only be used when talking to a
particularly restrictive ADMD. Again, it depends on the capabilities
of the channel how closely this information can be followed.

\item[\verb+rname+:]	The ``real'' name of the mta. This is an entry
that is suitable for lookup in the domain table. It is not used for
the outbound channel.

\item[\verb+other+:]	Other information. This is a string and is
interpreted by the channel to allow other types of operation to be
specified. It is not currently used in the X.400 outbound channel.
\end{describe}

If an entry with a key \verb|default|\index{default} exists in the
table, then this may be used to set default setting for all entries.
The value \verb|default| is looked up first and values filled in from
that setting - then the real entry is looked up and those values
override the default entry.

An example is shown if Figure~\ref{example:x400out} (lines are folded
for clarity).

\tagrind[hbtp]{x400out-examp}{Example X.400 Outbound Channel Table}{example:x400out}

\section {The X.400 (1984/1988) inbound table}\label{tab:X.400(84)in}

This table\index{ch.x400in84, ch.x400in88} is used by the inbound
X.400 channels, 
and allows the channels to obtain the MTA name and other information
from the OSI calling address. The syntax is the same as the X.400
outbound table, only the key is different.

The key here is the information given in the session connection of the
remote calling host; the values are as indicated for the outbound
table.  It is encoded in the string encoding for presentation
addresses using no macro substitution. Therefore, the keys look pretty
horrible. It is usual to maintain these tables with keys in macro form
and run them through the utility \pgm{nsapexpand} to expand the macros.

The matching of incoming information with an entry in this table provides the
major security checking.  Again an entry \verb|default| in the table
may be used to default many of the fields.

An example is shown in Figure~\ref{example:x400in} (again lines are
folded for clarity).

\tagrind[hbtp]{x400in-examp}{Example X.400 inbound Channel table}{example:x400in}

\section {The list table}\index{table, list}\label{sect:list}

The \file{ch.list} table is used by the \pgm{list} channel to
expand local distribution lists.
Entries in this table have the format:

\begin{verbatim}
<listname> ":" [<moderator> "|" ...] "," 
       file=<filename> | <mail address> "|" ... "," 
       description
\end{verbatim}

\begin{describe}

\item[\verb+listname+:] 
The name of the distribution list e.g \verb+listname+ or in X.400
perhaps \verb+/S=listname/+.  Note that in order for the list to form
a valid local address, the local part of the name, \verb+listname+ in
the above examples, must have an entry in the local \file{users}
table, specifying that messages addressed to the list should be
delivered via the list channel.

\item[\verb+moderator+:]\index{moderator}
 The unix ids/login names of the moderators of the list.  This element
of the table entry is purely for the use of the distribution list
management tool, \pgm{mlist} (see {\em The PP Manual: Volume~3 --
Users Guide}).  Anyone with one of the specified uids
may use \pgm{mlist} to modify the contents of the list.

\item[\verb+filename+:]
The file containing the members of the list.  If \verb+filename+ is
not a fully qualified pathname, the required file will be assumed to
be under the \file{tbldfldir} directory structure.  The format of such
files is one member's address per line.
Note that the file must exist for \pgm{mlist} to be able to be used on
the corresponding list.

\item[\verb+mail address+:] An address of a member of the list.
Note that because they are specified in the list table itself,
\pgm{mlist} cannot be used to modify such members.

\item[\verb+description+:] A short description of the purpose of the list.
This description is output by \pgm{mlist} when requested.
\end{describe}

Note that in order to form a valid entry in the list table, each entry
must be on one line and must contain three and only three commas.

Comment line in tables start with a \verb+#+.
The list table extends this mechanism further.
Comment lines that are printed by \pgm{mlist} start with \verb+#Comment:+.
This allows the list table to have two levels of comments,
one for the editor of the list table and one for the user of \pgm{mlist}.

\tagrind[hbtp]{lists-examp}{Example List Table}{example:lists}

If you have a large sendmail alias file to convert, you may find the utility 
\man make-lists(8) in the \file{Tools} directory. This utility attempts to
convert lists of names into a format suitable for use in the list channel
of PP. Note: It does {\em not} convert all alias table entries, only lists.

\section {The shell table}\index{table, shell}\label{sect:shell}

The \file{ch.shell} table is referenced by the \pgm{shell} channel
when converting from the recipient address to the commands to execute
in its place.  Entries in this table have the format:

\begin{verbatim}
<address> ":" <user id> "," [<timeout period>] 
             "," <command line to execute>
\end{verbatim}

\begin{describe}

\item[\verb+address+:] specifies the  recipient address e.g
\verb+shellprog+ or  the X.400 form \verb+/S=shellprog/+.
Note that in order for this to form a valid local address, the local
part, \verb+shellprog+ in the examples, must have an entry in the
local \file{users} table, specifying that messages sent to the address
should be delivered via the shell channel.

\item[\verb+user id+:] specifies the user to run as when executing the
commands.  This id is resolved using \file{/etc/passwd}\index{/etc/passwd}.

\item[\verb+timeout period+:]
specifies how long, in seconds, the commands should be allowed to run
before the \pgm{shell} channel kills them off.  If the timeout period
is not specified, the commands are allowed to run for the default
period of time, five minutes.  If the period is zero then the
\pgm{shell} channel will not kill the commands off.

\item[\verb+command line+:]
specifies the command line to execute.  If the program name is not a
fully qualified pathname, the program is assumed to be under the
directory specified by {\em chandir}.  Arguments of the form
\verb+$(key)+ will be expanded as described in
Table~\ref{tab:expansions} on page~\pageref{tab:expansions}.

\end{describe}

When running, the shell channel pipes all the message body parts, in
order, to the program's standard input.
The shell channel understands an exit code of 0 as success and
otherwise as failure.

An example of a shell table is shown in Figure~\ref{example:shell}.

\tagrind[hbtp]{shell-examp}{Example Shell Table}{example:shell}


\section	{Supporting unix style mailboxes}\label{sect:local}

By default, the \pgm{822-local} delivers in an MMDF style mailbox
format. That is there is a delimeter string, the message then another
delimeter string.

If however, you require the more traditional unix style mailbox format
(A line starting with a \verb*|From | line up to the next such) then
this is easy to emulate by having the \pgm{shell} channel call the
standard unix mail program \pgm{/bin/mail} in the same manner as
\pgm{sendmail} calls it to deliver messages. However, make sure this
has not been overwritten by the PP replacement for this program.

This can be achieved by a channel configuration such as
\begin{quote}\small\begin{verbatim}
j.onions:jpo,,/bin/unixmail -d jpo
\end{verbatim}\end{quote}

It could also be achieved in the \file{.mailfilter} file with a syntax
like
\begin{quote}\small\begin{verbatim}
pipe "/bin/unixmail -d jpo";
\end{verbatim}\end{quote}

Finally, the \file{.mailfilter} has an emulation of the this form of
delivery, accessible with the keyword \verb|unixfile|. This is
described in more detail in {\em Volume 5}.

\section{Authentication}\label{sect:authen}

Components of PP must do appropriate checking that they are being
invoked correctly.  Note that authentication is complementary to
authorisation.  It is also a pre-requisite.

\subsection {Submit Authentication}

Submit needs to verify the source of an inbound message.  For messages from
an inbound channel (protocol server) accessing the MTA Abstract Service, this
means verification of the UID of the channel (typically to be ``root'' or
``pp'').  For the MTS Abstract Service, the identity of the P1 originator must
be verified.  These two verifications use the same mechanism.  There are two
cases:

\begin {enumerate}
\item Submission from a local process using pipes.  In this case, the uid of
the invoking process is available, and can be the basis for authentication.

\item For remote submission, the uid is not available, and so a password
based mechanism is used.   This may also be used locally.
\end {enumerate}

A password, and the corresponding name is carried in the initial protocol
handshake.  This may be overridden for later messages.

Each (inbound) channel has an ``auth-table'' variable, which
identifies a table which is used in the manner described below.  The
authentication table has three columns.  These have meaning:

\begin {enumerate}
\item String encoded address, in the preferred format of the channel
\begin {itemize}
\item X.400 O/R Address
\item RFC 822 address
\end {itemize}

\item List of valid UIDs

\item Password (as in /etc/passwd)
\end {enumerate}

Example files:

\begin{quote}\small\begin {verbatim}
#
# Start of dummy 822 file
#
S.Kille@cs.ucl.ac.uk:steve|aiohpefcn

#
# Dummy X.400 file
#
/g=steve/s=kille/ou=cs/o=ucl/prmd=uk.ac/admd=gold 400/c=gb/:steve,pp
/i=j/s=onions/o=nott/prmd=uk.ac/admd=gold 400/c=gb/:jonions
\end{verbatim}\end{quote}


\input{auth}

\section{Qmgr Authentication}

The \pgm{MTAconsole} can connect to the \pgm{qmgr} in two distinct
modes. These are
\begin{describe}
\item[\verb|no authentication|:] In this mode, no authentication is
done for the user.

\item[\verb|weak authentication|:] In this mode a name and password
are passed across in the bind, so there is some limited authentication
of the initiator.
\end{describe}

When an incoming call is received by the qmgr, authentication
information is checked in the \file{auth.qmgr}\index{auth.qmgr} table.
The format of this table is
\begin{quote}\small\begin{verbatim}
<name> ":" "passwd=" <encrytped-password> "," "rights=" <rights>
\end{verbatim}\end{quote}

These parameters are interpreted in the following way:
\begin{describe}
\item[\verb|name|:] This is the name given in the bind parameters. If
the connection was bound with no authentication, the name \verb|anon|
is used for the lookup. If the name is not found in the table, then if
the user bound with authentication, the request is refused. If the
user bound without authentication, and the name \verb|anon| is not
present in the table, then limited access is allowed.

\item[\verb|passwd|:] This value takes an encrypted passwd, which can
be generated with the utility \pgm{mkpasswd}\index{mkpasswd}. The
password passed in the bind information is encrypted and compared
against this value if present. If no \verb|passwd| field is present,
then a passwd is not required.

\item[\verb|rights|:] This value is used to indicate the rights that
the initiator will be allowed. It may be one of the following values:
\[\begin{tabular}{|l | p{0.6\textwidth} |}
\hline
	\multicolumn{1}{|c|}{\bf Value} &
		\multicolumn{1}{|c|}{\bf Meaning} \\
\hline
	\tt none & The association is refused. \\
	\tt limited & The initiator is allowed to examine the queue
			but not to change any parameters. \\
	\tt full & The initiator is allowed to examine the queue and
		modify queue paramters \\
\hline
\end{tabular}\]

If it is missing, then limited access is assumed.
\end{describe}

For example
\begin{quote}\small\begin{verbatim}
anon:rights=none
admin:passwd=YNKJHgaawczz,rights=limited
pp:passwd=YNKcyeOsT6Fqc,rights=full
\end{verbatim}\end{quote}

In this case the following is true:

\begin{describe}
\item[\verb|anon|:] Unauthenticated users are not allowed any access
to the qmgr.

\item[\verb|admin|:] The user admin, with the correct password is
allowed to view the queue.

\item[\verb|pp|:] The user pp, with the correct password, is allowed
full access to control the queue manager.
\end{describe}

By arranging permissions differently loose to highly restricted access
is possible.

If no table is specified limited access is allowed for any connection.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦a35e9048a⟧ TextFile

Derivation

TextFile
