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

⟦51ff56bb1⟧ TextFile

    Length: 7000 (0x1b58)
    Types: TextFile
    Names: »part.1«

Derivation

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

TextFile

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