andrew@stl.stc.co.uk (Andrew Macpherson) (01/02/91)
This Paper which I presented at UKUUG Cambridge last month introduces a
way of using CNAMES to provide MTS routing. I recognise that UKUUG papers
are not exactly high on most library aquisition lists, and I think the ideas
might be useful to someone reading this newsgroup. It's only six pages so
Here it is:
\documentstyle[12pt,a4]{article}
\author{Andrew Macpherson\\ Distributed Systems Dept\\ STC Technology Ltd \\
$<$A.Macpherson@stl.stc.co.uk$>$}
\title{Dataless Sendmail Configurations}
\begin{document}
\maketitle
\begin{quote}
\begin{center}
{\sc Abstract}
\end{center}
Configuration management of a mail system is complex. As the number
of nodes grows, any change which requires access to each host within
the system becomes increasingly unreasonable.
A system has been devised using dataless sendmail configuration files
which permits rapid re-configuration of a large mail system through
modifying data in the centrally managed Domain Name System\nocite{BIND}.
{}\cite{RFC-882}
\begin{center}
{\small \copyright 1990 STC Plc}
\end{center}
\end{quote}
%\tableofcontents
\section{Aims and Objectives}
The configuration management of a mailsite devolves naturally to three
levels. The outermost is the site's interface to the
outside world. Within the second level are the mailhosts; {\em
i.e.} those hosts on the site with filestore for mailboxes (and with
possibly POP or P7 servers). Finally there are workstations, which
ideally should be considered as ``dataless nodes,'' after the model
propounded by the Athena Project. These levels correspond to the
degree of complexity in the required mail configurations.
The interface to the world tends to have the most complex world-view.
At this level the major routing decisions are made and, if
appropriate, the final barrier of internal node hiding is applied.
This is also the point at which authorisation and billing controls can
be effective without impeding the internal flow of information.
However for sites which naturally live within a single community such as
the Internet, with easy access to and from all hosts, such
functionality may be required at the mailhost level.
The requirements placed upon the mailhosts / Message Stores are much
simpler. These must recognise which users they serve and accept mail
for them. Mailhosts are the ``sinks'' of the mail system, typically
accepting mail addressed to a set of client hosts, rather than letting
the clients expose the bugs in the older versions of network lock
servers. Some intrinsic resilience is gained when there is only a
single point of delivery.
It is also part of the mailhost's internal function to act as a
relay-node for the site's internal Message Transfer System (MTS), and to
pass ``external'' mail to the outer layer for relay outwith the domain.
If the mailhost is a sink, then the workstation is purely a source of
new messages. It has no requirement to be able to accept mail from
the system, and beyond the perusal of a mailbox by the current user
none should come to it. In particular it should have no responder
program {\em (d{\ae}mon)} to receive network mail. The workstation
does require some minimal capability to deliver the messages
originated locally to the ``nearest'' MTA for injection into the
general delivery system.
This paper is concerned with these two inner layers of the MTS within
a site. The consideration leading to the discussion is the need to
reduce the general maintenance effort required. Ideally the effort
should be small and linear on the number of hosts or even mailhosts.
If this effort is reduced to little more than that required to
register the arrival of the host and assign its Internet Number then
the exercise may be considered successful. It should also be possible
to attach mail clients to a mailbox server without requiring
privileged access to that server. Finally it is highly desirable that
the vendor supplied binaries can be deployed directly, rather than
replacing them with local programs which may not observe the vendor
supported locking process.
\section{Current Technology}
It is possible to build a configuration based upon a special
``hostname'' to automatically route locally generated mail to a
mailhost. Sun's YP\footnote{It's NIS these days\ldots}
system extends this to a cluster of hosts. The ``mailhost'' name is
only locally defined, as the YP system is in effect a filter
inserting local data between the application and the Name Servers for
the domain. This scheme is flawed in its realisation, primarily in
that information must be maintained in multiple tables --- the Local
DNS needs records to direct network mail to the mailhost, and the
Sendmail configuration must recognise the hosts for which it should accept
mail. Secondly SUN's standard configuration for clients delivers to NFS
mounted
mailboxes directly thus exercising the lock daemon. By default these
client sendmails are started as network listeners. Finally the YP
domain can only extend to a mailhost and its clients, for the local
magic mailhost alias must be confined to those machines, or different
configuration files must be used for each set of clients.
Another possibility is the use of the UK-2.1 {\em et seq.\ }
configuration package. This suffers from complexity for the servers,
and the client configurations built are even less satisfactory than
the YP approach above. I believe that this package is more suited to
the outer level routers in this model of the MHS.
\section{Nameservers, some Background}
The Domain Name System is a distributed directory of more limited scope
than the X.500 directory {\cite{X500-DNS}}. It may be used to record
a number of useful things in the context of electronic mail.
\begin{description}
\item[Address information] The addresses of a target host are stored
in the DNS. Unlike {\verb+/etc/hosts+} all the addresses are
readily available, and the lookup sorts them into the most useful
order for the local network configuration.
\item[Name Translation] A host has only one name. It may have many
aliases, encoded in the DNS as CNAME records. Historically the
different names are used to address a specific network connection,
but there are other possibilities.
\item[MX records] The Mail eXchange record is used to build a
conceptual black hole\footnote{I think this a good analog for
mail systems in general} near the named host, possibly even
diverting mail away from it to a mailbox server. The set of MX
records lists the hosts which have bi-lateral agreements with the
target host for mail forwarding. As with a black hole, once the
message has entered it may only go deeper, or split and be ejected
totally. It cannot remain in a stable orbit.
\item[MG records] Mail Group records --- These form a way of
publishing mailing lists. No standard tools use them yet.
\item[MB records] Mail Box records do the same job as sendmail's
aliases in translating from a domain-level address to a specific
mailbox. As with MG this is not used.
\end{description}
Of these the Address record is mandatory, and MX is required for those
hosts which might be addressed in mail. The DNS must be updated when
adding a host to the network.
\section{DNS distortions}
In the terminology of X.400, the CNAME records are MTS re-direction,
and MX records, which return an ordered set of addresses, correspond
to RTS alternates.
\begin{figure}[htb]
\begin{center}
\unitlength=1mm
\linethickness{0.4pt}
\begin{picture}(111.00,65.00)(0,5)
\put(10.00,50.00){\circle*{4.00}}
\put(20.00,50.00){\circle*{4.00}}
\put(30.00,50.00){\circle*{4.00}}
\put(40.00,60.00){\circle*{4.00}}
\put(50.00,60.00){\circle*{4.00}}
\put(60.00,60.00){\circle*{4.00}}
\put(70.00,50.00){\circle*{4.00}}
\put(80.00,50.00){\circle*{4.00}}
\put(90.00,50.00){\circle*{4.00}}
\put(30.00,30.00){\circle*{5.20}}
\put(50.00,40.00){\circle*{5.20}}
\put(70.00,30.00){\circle*{5.20}}
\put(50.00,10.00){\circle*{5.20}}
\put(10.00,50.00){\line(1,-1){20.00}}
\put(20.00,50.00){\line(1,-2){10.00}}
\put(30.00,50.00){\line(0,-1){20.00}}
\put(40.00,60.00){\line(1,-2){10.00}}
\put(50.00,40.00){\line(0,1){20.00}}
\put(60.00,60.00){\line(-1,-2){10.00}}
\put(70.00,30.00){\line(0,1){20.00}}
\put(80.00,50.00){\line(-1,-2){10.00}}
\put(70.00,30.00){\line(1,1){20.00}}
\put(50.00,10.00){\line(0,1){30.00}}
\put(70.00,30.00){\line(-1,-1){20.00}}
\put(50.00,10.00){\line(-1,1){20.00}}
\put(30.00,30.00){\line(1,0){38.00}}
\put(70.00,30.00){\line(-2,1){20.00}}
\put(50.00,40.00){\line(-2,-1){20.00}}
\put(6.00,23.00){\dashbox{2.00}(105.00,21.00)[rc]{Mail Hosts }}
\put(50.00,70.00){\makebox(0,0)[cc]{Client Workstations}}
\put(60.00,10.00){\makebox(0,0)[lc]{External Access Gateway}}
\end{picture}
\end{center}
\caption{Mail connectivity on the local Net}
\label{fig:model}
\end{figure}
In setting out to use the DNS to advantage we required a picture of
the connectivity we wished to enable. In Figure {\ref{fig:model}} the
solid circles correspond to hosts within the MTS, and the lines to the
possible mailpaths. The clients may only correspond with their
mailhost. The mailhosts within the domain may communicate freely, but
all external communication is focused through the gateway to enforce
the various site policies (including for communication with other
parts of the corporation).
Early client configurations required the destination mailhost to be
configured into the file, in much the same way as the YP
magic token was required. They achieved the first level objective of
only communicating with their mailhost, but failed the basic
requirements of minimal effort and attachment to mailhost.
The DNS can of course be applied. The obvious change is to add an
overriding MX record to divert all mail addressed for the client to
its mailhost. A satisfactory configuration for the clients may be
constructed on this basis: the clients are instructed to send all mail
{\em to themselves\/ } over an SMTP channel. The initial lookup of
the MX record causes the connection to be made instead to the mailhost.
This level of use allowed a standard client configuration to be
deployed without regard to its attachment host in the local MTS. The
mailserver still had to be configured with knowledge as to which hosts
it serviced.
\section{A Rose by any other name}
The magic token approach used in the YP configurations was flawed by
its lack of scope. With DNS there is little cost involved in
providing very many names for a host. Within a management domain
({\em e.g.} a DNS zone), it is possible to define a magic token for
use to locate the appropriate server. If the token is {\bf mail.\ }
then a server might have the following aliases:
\begin{center}
\begin{tabular}{ll}
& mail.server \\
& mail.client1 \\
server $\leftarrow$ & mail.client2 \\
& mail.client3 \\
& mail.client4 \\
\end{tabular}
\end{center}
The server can use the magic token to resolve responsibility for a
message dynamically without needing to be reconfigured for each new
mailclient:
\begin{verbatim}
R$*@$+ $:$1@$[mail.$2$:$2$] IDA defaulting
- or -
R$*@$+ $:$1@$[mail.$2$]
R$*@mail.$* $1@@2 Lookup failed
\end{verbatim}\nocite{IDA}
Similarly the client can use the same magic token to determine its
server directly.
\section{Local Information}
If the hostnaming structure in force corresponds to:
\begin{center}
\verb+host.division.corporation.country+
\end{center}
\noindent
and the publicly visible mail names are to appear as
\begin{center}
\verb+user@division.corporation.country+
\end{center}
\noindent
in the classic site hiding manner, these techniques can be used to
produce totally dataless sendmail configuration files for both clients
and mailhosts. This has been done as an exercise. Whilst it is
possible to employ a YP map to locate a user site-wide on those hosts
which support it, in general replies to mail have to be relayed via
that mailhost which answers directly for
{\verb+division.corporation.country+}. In practice it is reasonable
to define the local domain in the mailhost configuration, even though
it must be changed when it is exported to other divisions.
\section{Thanks}
The author wishes to thank Matthew J Allen for the minimalist
sendmail configuration files on which this work was based.
\section{Availability}
The dataless client and mailhost configuration files are available for
public retrieval:
\bigskip
\noindent
\begin{tabular}{|l|l|l|l|l|}\cline{1-2}\cline{4-5}
FTAM & Parameters & \quad & NiFTP & Parameters\\\cline{1-2}\cline{4-5}
Host & stl.stc.co.uk && Host & stl.stc.co.uk \\
Login & ANON && Login & guest \\
Password & {\em not required} && Password & $<$your e-mail address$>$ \\
File & Exports/9012.cf.tar.Z && File & Exports/9012.cf.tar.Z \\
Mode & Binary && Mode & Binary \\\cline{4-5}
X121 & {23423710012217} \\
TSEL & {0103H} \\\cline{1-2}
\end{tabular}
\begin{tabular}{l|l}
\end{tabular}
\bibliography{bcustom,x500}
\bibliographystyle{alpha}
\end{document}
--
Andrew.Macpherson@stl.stc.co.uk -- PSI%234237100122::Andrew.Macpherson
"There is nothing quite so worthwhile as simply messing about in boats"