|
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: 7000 (0x1b58) Types: TextFile Names: »part.1«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit └─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z« └─⟦bcd2bc73f⟧ └─⟦this⟧ »design/part.1«
Part 1: The format of an input letter. An input message is formed of optional UN*X ``From_'' lines, an optional RFC822-style header and an optional message body. An example input message follows: From uucp Tue Mar 24 01:26:02 1987 remote from namei >From kgbvax!gavrilov Tue Mar 24 01:10:23 1987 remote from walldrug Received: by walldrug.uucp; id AA98293; (Version 1.414--1981) Tue, 24 Mar 87 01:26:02 Received: by kgbvax; id AA91283; Tue, 24 Mar 87 01:10:02 From: gavrilov@kgbvax.uucp (A. I. Gavrilov) To: les@sdc.amdahl.com, brown@nsavax.nsa.gov Subject: secret ingredients in Charmin Tissues Please send secret ingredients in Charmin Tissues. Greatly appreciate response. -- A. I. Gavrilov The sections below describe the methods of reading through messages to break them up into sections and extract some basic information from them. Section 1.1: Reading through the UN*X ``From_'' lines. The UN*X From_ (pronounced ``from space'') lines are generated by the first and intermediate hosts transmitting over the UUCP transport layer. These From_ lines can be used to generate a return path to the sender, for use in returning mail to the originator of a message on errors, and for the use by older mail software in generating reply addresses. Note: the underscore character in ``From_'' represents the space character. This is used to differentiate between the From: header field and the From_ line. The format of a From_ line is: {>}From <path> <ctime>{ remote from <host>} where: <path> = generally a UUCP-style address <ctime> = date as returned by the ctime(3) function <host> = name of the host which transmitted the message Newer mailers (such as delivermail, sendmail and smail) will build up one From_ line for each message, which contains a path from the previous hop site back to the originator of the article and the previous hop site itself as in the example: From a!b!c!dbell Sun Feb 3 04:05:06 1987 remote from namei This line suggests that the letter was sent by ``dbell'' on system ``c'', thru system ``b'', then system ``a'' and was finally received by system ``namei''. In the general case, there can be several From_ lines. This is the case where mail is sent using older user agent software (such as the v6/v7/System V /bin/mail program) where headers are never read for information in transportation and where a From_ line is always added, before being sent to a remote host, in the form: From user Sun Feb 3 04:05:06 1987 remote from host Where user is the login name of the user that invoked the mailer command, or the name for the effective user of the invoking program, and host is the name of the host transporting the mail. In mail that came from a remote host, the user generally corresponds to the owner of the UUCP software and is of no value. Also, these older mailers will often add a '>' character to the front of all other From_ lines in the message. The algorithm used in reading the From_ lines is to scan forward through the message until a line is reached that is not of the correct form for a From_ line. For each line, extract the <host> and add it to a string of hosts that are separated by `!'. For the last From_ line, extract the <path>, convert it to a proper `!' route and append the route to the end of the string of hosts, separated by a `!'. If any From_ line does not contain a ``remote from <host>'' pattern at the end, then the path information that has been so far built cannot be used. This is because one segment is missing, and we cannot easily intuit this missing information. If the last From_ line does not contain a ``remote from <host>'' pattern, then the path information should be completely replaced by the value of the <path> taken from that line. If there is no host information associated with that path, then this return path is of no value. Example: From uucp Wed Jan 1 05:06:07 1981 remote from mars >From daemon Sun Dec 22 08:22:36 1973 remote from jupiter >From uranus!mike Sat Mar 18 12:12:08 1965 remote from saturn This corresponds to a sender address of: mars!jupiter!saturn!uranus!mike Example: From uucp Sat Apr 1 00:00:00 1999 remote from nowhere >From host!user Fri Mar 31 23:59:59 1999 This corresponds to a partial sender address of ``host!user''. Since the last From_ line contained no ``remote from <host>'' pattern, the previous path information cannot be used. Section 1.2: Reading through the header. The format of the optional header is as a collection of logical header fields of the form: <field_name>:{<first_line>}( <continuation_line>)* where: <field_name> = case independent name of header field <first_line> = first line of the field contents <continuation_line> = continuation of the field contents NOTE: some white space precedes each <continuation_line>. NOTE: <field_name> consists of one or more of ASCII characters not including control characters, white space, or `:'. The entire header consists of all lines after the From_ lines up to a line that does not match this form. When reading in the article, the software should form a list of all header fields as they are important in the processing of mail. Example: From: davidl@ny-studio.nbc.com (David Letterman) To: johnnyc@burbank.nbc.com (Heressss... Johnny!), edm@burbank.nbc.com (Mr Sweepstakes himself) Subject: got my own show now. Bye. (Heh! Heh!) The header here is the first four lines, divided into three header fields, with the second header field containing two physical lines. The message body is properly separated by one blank line from the header. Remember that From_ lines are not required in a message. Example: From bill Wed Jan 15 15:14:13 1982 remote from old-machine Ack! Ackpth! This example contains no header fields. The message is from old-machine!bill, and the message body is ``Ack! Ackpth!''. Example: From uucp Thu Jan 13 06:10:12 1986 remote from walldrug >From amdahl!tron Wed Jan 12 02:03:04 1986 remote from namei From: tron@amdahl.com (Ronald S. Karr) To: brown@nsavax.uucp (C. Edward Brown) Subject: some stuff that may not be of any interest at all. gosh, this isn't a properly formed message, but it should be possible to read it correctly Here the Subject header field is two physical lines long and the message body begins with ``gosh, ...''. Note the path back to tron@amdahl.com is ``walldrug!namei!amdahl!tron''. Section 1.3: Reading through the message body. After the header has been read, the message body can be read, the message body is all remaining text in the article. It's content should be left untransformed. The text may need to be modified if there is a change in line terminator or a change in character set. \f