|
|
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