|
|
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: 6925 (0x1b0d)
Types: TextFile
Names: »part.4«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z«
└─⟦bcd2bc73f⟧
└─⟦this⟧ »design/part.4«
Part 4: An overview of a typical smail process
This section gives an overview of the steps involved in
processing a message. We first present an overview of the
typical steps involved in processing a mail message. We
also follow an mail message as it passes through smail.
We examine smail actions in detail in later parts of this
document. One should become familiar with this example before
reading the later parts. One should also remember that
the example presented is not the only possible action path
that one can encounter.
Section 4.1: The process.
1. Process the header, as described in Section 2.2.
2. Obtain the input recipient <address> strings. These either
come from the header, as described in Section 3.1, or from
some other source, such as arguments given when invoking the
mailer. Call this list of input address strings <in>.
3. Clear three lists: name them <remote_addresses>,
<local_addresses> and <out>. Each element of
<remote_addresses> contains a <target>, and <remainder>.
Each element of <out> contains a <next_host>, <next_address>,
and <transport>. Each element of <local_addresses> is a
string.
4. Parse the <in> addresses for <target> and <remainder>,
using the rules in Section 3.2. Insert <in> addresses that
were in local form in <local_addresses>, and for all other
addresses, insert the <target> and <remainder> as an entry
in <remote_addresses>.
5. If there are entries in <local_addresses> call the directors,
that are described in part 7, to produce a list of resolved
addresses and a list of new <address> strings. Insert the
resolved addresses with associated <next_address> and
<transport>. If there are new <address> strings insert them
in <in> and goto step 4.
6. For all <remote_addresses> compute a <route> and <next_address>
for the associated <target> using routers, that are described
in part 6. For <target> values that are the local host,
copy <remainder> to an <address> and insert in <in>.
7. For all remaining <remote_addresses>, compute the <next_host>
and <transport> using rules in Section 6.1.2, and insert in <out>.
8. If <in> contains addresses from step 6, goto step 4.
11. All recipient addresses have been resolved to the <out> list.
For each entry in <out>, call the associated <transport> as
described in Section 8.4. To make transports more efficient,
addresses in <out> are grouped together by <transport>.
Section 4.2: The life of a mail message.
This example assumes the use of the director file in Section 7.4,
with the file /usr/lib/aliases being the example alias file in
Section 7.3.1 and with the example forward file from Section 7.3.2.
Also assumed is the router file in Section 6.1, with the pathalias
file being the example file in Section 6.3.
We will follow the processing of the following message that was
submitted by a local user ( ``bush'' ) who requested that recipient
addresses be taken from the header of the message:
From: bush poindexter
To: msgs, james.bond
Subject: Let's be careful
Cc: tron@uts.amdahl.com
Bcc: nsavax-users
let's be quiet guys, and make sure we don't
accidentally leak anything. For example,
don't put any extra addresses in your
mail messages.
In processing the header we note that several of the addresses
are in local form and should be put into the local domain. We
also note that the addresses in the From: field are not separated
by commas.
In addition, since more than one address is given in the From:
field, we will need to generate a Sender: field to identify the
true sender.
Finally, after address extraction, the Bcc: field will be removed
from the message.
After processing, and adding more headers, the header will
look like:
Received: by nsavax.nsa.gov with smail id12345-65432;
Mon, 17 Aug 87 16:45:22 EST
Message-ID: <id12345-6532@nsavax.nsa.gov>
Date: Mon, 17 Aug 87 16:42:22 EST
Sender: bush@nsavax.nsa.gov (J. Bush)
From: bush@nsavax.nsa.gov, poindexter@nsavax.nsa.gov
To: msgs@nsavax.nsa.gov, james.bond@nsavax.nsa.gov
Subject: Let's be careful
Cc: tron@uts.amdahl.com
The list of recipients computed from this header and the
Bcc: field is:
msgs@nsavax.nsa.gov, james.bond@nsavax.nsa.gov,
tron@uts.amdahl.com, nsavax-users@nsavax.nsa.gov
After parsing, none of these is in local form, so we
try to route on all of them.
In routing we find that three addresses are local and one
is remote. We compute the following attributes for the
remote address:
<next_host>: seismo
<route>: amdahl
<next_address>: amdahl!uts.amdahl.com!tron
transport: uux
After reparsing the <remainder> values from the other
addresses, we find that they are all in local form. So
we call the directors to resolve them.
In following the address ``msgs'', we note that there is an
entry in the aliases file that turns into the list of addresses:
local-msgs@nsavax, local-msgs@ciacray,
local-msgs@nscprofs
After routing these, we note that local-msgs@ciacray and
local-msgs@nscprofs are remote addresses one hop away over
wash-net, and local-msgs@nsavax is local. The local address
local-msgs is then found in the aliases file to be aliased to:
"|/usr/ucb/msgs -s"
Since this is the form of a pipe, the command "/usr/ucb/msgs -s"
will be executed using the bourne shell and the message will
be supplied on the standard input. A From_ line will be
prepended to the message in a local form:
From bush Mon Aug 17 16:42:24 1987
The address james.bond is a local user with a .forward file
containing:
bond%british-ss@ciacray, +james.bond
This then becomes a remote address to the host ciacray
and the message is sent to the local host's mailbox file for
james.bond.
The address nsavax-users is expanded to the addresses in
the file /usr/lib/mail/nsavax-users to the address:
brown
This address is not aliased or forwarded, so it is resolved
to the local transport, that will issue a command to deliver
using /bin/mail.
As a summary, from the input message, we deliver to the
following destinations:
1. local mailboxes: james.bond, brown
2. command: /usr/ucb/msgs -s
3. remote addresses:
local-msgs @ ciacray via wash-net,
local-msgs @ nscprofs via wash-net,
bond%british-ss @ ciacray via wash-net,
amdahl!uts.amdahl.com!tron @ seismo via uux
With the transport file from Section 8.3, this turns into
the following set of commands:
/bin/mail james.bond brown
/usr/bin/uux - -r -abush seismo!rmail (amdahl!uts.amdahl.com!tron)
/etc/washnet-send /usr/tmp/mail.2394 -fbush
ciacray local-msgs nscprofs local-msgs
ciacray bond%british-ss
\f