DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: T p

⟦22cb06424⟧ TextFile

    Length: 6925 (0x1b0d)
    Types: TextFile
    Names: »part.4«

Derivation

└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
    └─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z« 
        └─⟦bcd2bc73f⟧ 
            └─⟦this⟧ »design/part.4« 

TextFile

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