|
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