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

⟦53ef2b07b⟧ TextFile

    Length: 25701 (0x6465)
    Types: TextFile
    Names: »part.0«

Derivation

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

TextFile

Part 0:  Introduction.

	There is a need in the UUCP community for a mailer that
	will fully understand RFC822/RFC976 syntax while also being
	able to handle addresses in the more traditional UUCP styles.
	It is also desirable to have the mailer do transformations
	on these more free-form addresses to make them somewhat
	more palatable to user agents.

	We believe that a mailer should:

	o  scan for recipient addresses in the header fields of
	   a message (as an option)

	o  leave conforming header fields alone

	o  use heuristics to decipher the addresses within
	   non-conforming header fields and to transform header
	   fields for better conformance

	o  handle RFC822 route-addrs in a reasonable fashion

	o  resolve all reasonable RFC822/RCC976 conforming addresses,
	   as well as a large set non-standard address forms such as
	   !-routes, local-part%domain as well as mixed-form
	   addresses such as !-routes followed by route-addrs.

	o  route using data from a varied set of sources, such as 
	   pathalias database files, in core tables, remote network
	   daemons, the output of other programs, etc.

	o  transmit over multiple transport media and protocols, such
	   as UUCP, SMTP or a site-dependent transport programs and
	   protocols

	o  provide sendmail compatible local address aliasing and
	   mail forwarding

	o  return errors to the originator or, if this fails, to
	   the postmaster

	o  produce error messages that are easy to understand

	o  be simple to configure for simple sites, and straight
	   forward to configure for more complex sites

	o  not require the use of configuration files or databases
	   to meet the requirements of common sites

	o  be portable to many machines

	o  be freely available so that smail can be easily distributed 
	   to as many machines as possible, and thus improve mail delivery 
	   over a wider part of the UUCP and other networks

	The authors of this document have noted that the currently
	available mail delivery programs that we know of (sendmail,
	mmdf, smail2.3, sendmail/smail2.3, and uumail) do not
	meet the needs stated above.

	Below is a summary of the strengths and weaknesses that we
	see in the above mentioned packages:

	o   sendmail:  offers a powerful set of capabilities for
	    transforming addresses given as arguments and included
	    in headers.  It has a powerful aliasing and forwarding 
	    capability.  It has the following shortcomings:

	    o	does not independently rewrite UUCP From_ lines
		and Sender: and From: header fields  (reported to
		have been corrected in later versions)

	    o   it does not easily use file-based routing databases

	    o	sendmail configuration files are difficult to read,
		understand and maintain  (you know something is
		wrong when people are driven to create sendmail
		config file generator languages!)

	    o   sendmail command arguments and it's configuration
		files are poorly documented

	    o   Many non-BSD sites refuse to use sendmail for valid
		or bogus reasons.
		
	o   mmdf:  an extremely powerful set of utilities. Unless you
	    need this much power and flexibility and security, it is
	    not worth the time it takes to understand it.  There are
	    too many required configuration files.

	o   smail 2.3:  a useful program.  The latest version has
	    only rudimentary aliasing and forwarding.  However, it
	    is not currently capable of obtaining addresses from
	    header fields or changing addresses in headers to conform
	    in any way.  It also does not handle enough addressing
	    forms, such as RFC822 route-addrs.

	o   sendmail/smail 2.3:  by combining sendmail and smail we get
	    the better of both worlds, but we also lose some performance.
	    We also lose much of sendmail's power for using multiple
	    transports.


Section 0.1:  Syntax forms.

	The rules given in this section define syntax forms used in form 
	matching, scanning and transformation rules.  Deviations from 
	these rules are noted in the sections where the deviations occur.

	Literal text:
		Text that is not enclosed in angle-brackets ( `<' and
		`>' ) and that does not contain an operators from the
		list of ``<>{}[]*()''.  Unless otherwise stated, case
		is not significant in matching alphabetic characters.
		White space in a pattern will match any non-zero amount
		of white space unless specifically stated otherwise.

		White space is one or more TAB or SPACE characters.  It
		can include newlines unless a syntax form deals with
		newlines explicitly.

		Examples:

		    Received:

		    remote from

	Quoted literal:
		Any characters between a grave (backward single quote),
		and an accent (forward single quote) matches exactly
		the character string between the two single quotes.

		Example:

		    `yep!'
		    `['

	Character classes:
		Ed(1)-style character classes are given in square
		brackets, ( `[' and `]' ).  A character class matches
		one character in the list of characters inside the
		braces.  If two characters in the list are separated by
		a dash ( `-' ), then any ASCII chars in the range from
		the first to the second will match.  Also, if the list
		begins with a circumflex ( `^' ), then any ASCII
		character, other than newline, that is not given in the
		list will match.

		As an addition to character class syntax, the sequence
		`\n' matches a newline, and the sequence `\t' matches
		a tab.

		Examples:

		    [^A-Za-z0-9]

			this will match any ASCII character that is
			not a letter or a number

		    [,!%@]

			this will match `,' `!' `%' or `@'

	Repetition:  A pattern followed by an asterisk ( `*' ) represents
		zero or more repetitions for that pattern.  A pattern
		followed by a plus sign ( `+' ) represents one or more
		repetitions of the pattern.

	Named pattern:
		A name enclosed in angle brackets ( `<' and `>')
		matches a pattern that is defined elsewhere in the
		form:

		    <name> = pattern

		where ``pattern'' can be a syntax form as described in
		this section, or an English description of what will
		match.

		Example:

		    remote from <host>
		    <host> = [^ \t]*

			the pattern matches the text ``remote from ''
			followed by <host> that matches any non-space
			characters up to a newline.

	Optional pattern:  A pattern enclosed in curly braces
		( `{' and `}' ) will match zero or one occurrences of
		that pattern.

		Examples:

		    From <path> <date> {remote from <host>}

			the ``remote from <host>'' is optional
			for a match

	Grouped patterns:  A sequence of patterns enclosed in parentheses
		( `(' and `)' ) represent an indivisible pattern and
		the entire group can be followed by an asterisk to
		represent repetition of the group.

		Example:

		    Cc:{(<address>{,})*<address>}

			The <address> list is separated by optional commas
			and note that the list itself is optional

	Or:	Unless otherwise noted, the word ``or'' is used to
		denote alternate patterns that can be matched.

		Example:

		    (a or b or c)+

			will match any of:  a  ca  abacab


Section 0.2: Definition of terms

	The terms defined below are used throughout this document.  
	The numbers beside each term refer to sections or parts of
	this document where that term is used and/or explained in 
	detail.  An integer refers to a complete part, while a dot 
	separated list refers to a section.  These numbers serve as
	a guide for further reading and are by no means complete.

!-route (bang route) :		3.1.2.3
	A path from a host to a user where each successive part of
	path is separated from its predecessor by a bang character
	( `!' ).

Alias :				7.3.1
	A collection of addresses that are tied to a name in local
	form.  Each host can have associated with it a list of aliases,
	and when a local address is received that matches the name
	of an alias, the message is delivered to the collection of
	addresses associated with that alias.

Alias file :			7.3.1
	A file that associates a local form recipient address with a
	list of addresses that are to be considered recipients of a
	message in place of the given local address.

Bang route :			3.1.2.3
	See !-route.

BSD :				6.3.1, 7.3.2, 9.6.1
	The Berkeley Software Distribution is an interesting variant
	of UN*X that is distributed by the University of California
	at Berkeley.  These versions of UN*X are also known as
	4BSD, or 4.xBSD. where x is 0, 1, 2, 3, ...

Config file :			9.3
	A file that can redefine the values for a number of smail
	variables.  This file is loaded at run time.

Character class :		0.1
	A set of characters that can form a single character match
	in a syntax form.

Continuation character :	5.1.1
	The character \ at the end of a line in some data files will
	cause the context of which line to be continued on the next.
	Generally, a line is continued by having the next line begin
	with a TAB or SPACE character, so a continuation character
	is rarely needed.  These violate RFC822 so they are not used
	in headers.

Copyleft :			abstract, n-2
	A term coined by Richard M. Stallman of the Free Software
	Foundation to denote a particular set of lawbol copyright
	language.  The basic idea behind a copyleft is to forbid
	anyone from from denying anyone else the right to redistribute
	copylefted software.

/dev/null :			sqr(-1)
	Where flames are best directed and where 0 and 1 bits are
	obtained for hardware shift operations.

Delivery agent :		8
	A program, or a set of functions, that moves a message from one
	place to another.  I.e., from host to host over some media, such
	as phone lines, an Ethernet cable, fiber-optic link or CB radio.

Director :			7
	Something that transforms (or ``directs'') local form addresses
	into addresses associated with transports, or into more addresses
	to be processed.  A director is specified by a single director entry 
	in the director file.

Director driver :               7.3
	A set of smail subroutines that do the actions of a director.
	It is possible for several director entries to refer to a
	single director driver.

Director entry :		7.2
	A set of lines in the director file that define a specific instance
	of a director.  A director entry names a director driver, specifies 
	values to be passed to a director driver, and establishes its 
	operating mode.

Director file :                 7.2
	A file that contains one or more director entries.  The
	director file defines the steps used in deciding what to do
	with a local form recipient address.  Some possibilities are:
	process the address through an aliases file to replace the
	address with a different set of recipient addresses; query a
	remote server across a network for user-name (or full name) to
	address mappings; forward the message to a new set of addresses
	defined in a per-user forward file; or produce the name of a
	mailbox file to receive the message (normally delivery).

Driver :			5.5, 6.3, 7.3, 8.5
	A set of smail subroutines that handle the low level requirements
	for a specific function such as a director, router or transport.

Domain :			3.1.2.3
	A reference to host or collection of hosts within an absolute
	hierarchy.  See RFC822 and RFC920 for more information on
	mail domains and domain requirements.

Domain-literal :		3.1.2.1
	Characters enclosed in brackets ( `[' and `]' ).  This forms
	a single token within an address.

Forward file :			7.3.2
	A file associated with a specific user on a machine that
	specifies a list of addresses to use for messages that are
	sent to that user.

Forward to :			7.3.2
	A configurable capability allowing forwarding of mail by
	placing the single line ``Forward to <address_list>'' in a mailbox
	file.

Free Software Foundation :	0.2
	The Free Software Foundation produces a wide verity of useful
	copylefted programs from editors to compilers, and from mailers
	(such as this one!) to an eventual goal of a complete
	Un*x-compatible software system.  For more information write to:
	Free Software Foundation, 1000 Mass Ave, Cambridge MA 02138, USA.

From_ (from space) lines :	1.1
	A set of lines at the beginning of a message that can be used
	to build a !-route back to the sender of the message.
	NOTE: The ``_'' character refers to a space and not an underscore!

Fully Qualified:		2.2
	A domain is fully qualified when the last part is a top level
	domain, such as .com, .edu, .jpn or a pseudo domains .arpa or .uucp.

Grade :				9.3, 9.1.2, 9.5, 5.2, 8.5.1.2
	A priority assigned to a given mail message.  When smail scans
	a spool directory for work, the oldest message of the highest
	priority will be processed first.

Grouped pattern :		0.1
	A sequence of patterns enclosed in parentheses in a syntax
	form.  Used to group patterns to be operated on by operators 
	such as * and +.

GNU :				abstract, 0.2, n-2
	GNU stands for GNU's not Un*x.  The G in GNU is not silent.

Header :                        1.2
	A collection of lines after the optional From_ lines and before
	the body of a message that specify important addressing and
	debugging information, as well as any other keyed information
	that a user wishes to put at the top of a message.  The form is
	as a collection of header fields that begin with a field name
	ending in a colon ( `:' ) and end before the next header field
	or before the message body.

Header field :			1.2
	One field from a header.  It is defined as one or more lines
	from the header where the first line begins with a fieldname
	followed by a colon ( `:' ) and where successive lines are
	non blank and begin with a white space character, i.e., a
	tab or a space.

Host :				3.2
	Some object that can transport and receive mail.

:include: file:			7.1, 7.3.1
	A file referred to by the aliases file or another :include: file.
	Contains a list of files, addresses, pipes and :include: files.

Literal text :			0.1
	Characters within a syntax form that must match exactly,
	though generally ignoring case, for a pattern match to occur.

Local address :			3.2
	An address that specifies a recipient on the local host.

Local address form :		3.2
	An address form that does not supply a host or domain, and thus
	only contains a local part.

Local part :			3.2
	The local part of an address that refers to a specific user, pipe
	or filename in absence of a sitename or domain.

Logging :			9.2
	The act of writing or updating a log file.

Log file :			9.2
	Smail has 3 mail types of log files.  A panic log file
	records panic events that should recevied the immediate
	attention.  A transaction log file records smail activity
	and debugging information.  A per-message log file records
	the process of smail processing an individual mail message.

Mailer :                        0
	A mailer is a collection of one or more programs that receive
	mail messages from either user agents, or from extern systems
	via some transport.  The mailer performed the required parsing
	and processing of the mail message and either hands it off to a
	transport for external transmission and possibly performs local
	mail delivery.  On a typical 4.3BSD system the mailers are
	/bin/rmail and /usr/lib/sendmail.

Mailing list :			7.3.3
	A mailing list is a file which contains a list of addresses.  A
	mailing list file can be referenced in an alias or forward file
	using the address form :include:/path/file.  The forward file
	mechanism is also generalized to support mailing lists which are
	defined simply by defining a plain text file in a directory
	setup for this purpose.  For this case, a local form address
	which matches the basename of the mailing list is expanded into
	the list of addresses contained in the file.

Message :			1
	The complete collection of characters that are being sent from
	the sender of a message to the various recipients.  A message
	consists of an optional set of From_ lines, an optional header
	and an optional message body.  The first two parts of a message,
	the From_ lines and header may be modified by mail transport
	and mail delivery programs.

Message body :			1.3
	The collection of characters in a message that are after the
	optional From_ lines and header.  This contains the unformated
	text that the sender is sending to the recipients of the
	message.

Message ID :			2.3.2
	A unique identifier for a message that is specified in a
	header.  This is generally assigned by the host to which the
	message was originally submitted.

Method file :			6.1.3
	A file that defines a table of associations between hosts and
	transports.

Name server :			6.1.2
	A program or facility that provides a host or domain resolution
	service.  An example is the Berkeley BIND program.

Named pattern :			0.1
	A name tied to part of a syntax form.

Next host :			3.3
	Often a message must pass through a list of hosts to go from the
	local host to a target host.  The next host is the first in this
	list of hosts.

Operator :			3.1.2
	In an address, a character from the set [%@!<>,:;].  An operator
	forms a distinct token when it is outside of a quoted text
	literal or domain literal and when not preceded by a backslash.

Path :
	An alternate name for a route.  Often the word path is used when
	refering to routes over a UUCP network, for historical reasons.

Pathalias :			6.3.1
	A program by Peter Honeyman that converts the Usenet maps into
	the pathalias database.

Pathalias database :            6.3.1
	A database produced by the pathalias program.  Alternately a
	database in the same format as that produced by the pathalias
	program.  Such a database associates hosts and domains with
	routes that can be used for determining where to send a message.

Precedence :			9.3, 9.1.2, 9.5, 5.2, 8.5.1.2
	A symbolic name for a grade (see Grade).  A grade can be
	assigned to a message by giving a string within a Precedence:
	header field which matches a known precedence with a
	corresponding grade value.

Quoted-literal :		3.1.2.1
	Characters inside double quotes.  This is a token form within
	an address.

Received field :                2.3.1
	A tracing/debugging field in the header.  Each site through
	which a message travels should add a Received: field to the
	message stating the name of the host, the date, the time and a
	message id.  Received fields can also be counted to determine
	how many sites a message has passed through since originally
	submitted.  This can be useful in detecting infinite loops, by
	noting when this count is unusually high.

Recipient :                     7, 8
	The user, program or file appointed as a receiver of a message.  
	These are specified using many addressing combinations.  However, 
	in general a recipient can be specified using a local name and 
	a domain in the form: local-part@domain-reference.

Recursion :			0.2
	See Tail recursion.

Remainder :			3.2
	The address which remains after the target is removed from an
	address.  This is nominally the address which is to be given to
	the target host.

Remote :			6
	Relating to users or addresses not on the local host.

Remote address :		3.2
	An address that specifies a recipient on a remote host.

Remote address form :		3.2
	An address form that supplies a host or domain.

RFC819:				n-1
	ARPANET Request For Comment document number 819.  Useful for
	understanding the domain naming convention.

RFC821:				n-1
	ARPANET Resuest for Comment document number 821.  This document
	deals with the SMTP protocol.

RFC822:				n-1
	ARPANET Request For Comment document number 822.  The mail format
	standard in given in RFC822.

RFC882:				n-1
	ARPANET Request For Comment document number 882.  Domain name
	concepts and facilities are discussed in this document.

RFC920:				n-1
	ARPANET Request For Comment document number 920.  The requirements
	for domains are found in RFC920.

RFC976:				n-1
	ARPANET Request For Comment document number 976.  The UUCP
	mail interchange format standard is given in RFC976.

Route :				3.1.2.3, 3.2, 6
	A sequence of hosts and domains through that a message must
	travel to reach a recipient.  For mail over UUCP, routes are
	generally in !-route form (also called `!'-path form in this
	document).  See the entry for !-route.  The name `route' also
	refers to the first part of a route-addr.  See the entry for
	route-addr for this interpretation.

Route-addr :			3.2
	A peculiar syntax used in RFC822 to state specifically the
	path to be used in sending mail from a host to the destination.
	An example route-addr is:
 
		<@kgbvax,@walldrug,@namei,@amdahl:rick@seismo>
 
	Route-addr gets its name because it begins with a route to get 
	to the destination host and ends in a normal form address.

Router :			6
	Something that computes where to send a mail message given the 
	address of a recipient.

Router driver :			6.1.2, 6.3
	A set of smail subroutines that do the actions of a router.
	It is possible for several router entries to refer to a
	single router driver.

Router entry :			6.1
	A set of lines in the router file that define a specific instance
	of a router.  A router entry names a router driver, specifies
	values to be passed to a router driver, and establishes how
	it is to be used.

Router file :			6.1
	A file containing one or more router entries and which defines
	the order in which they are used in routing recipient addresses.

Shell command :			8.5.1
	A command that is to be executed by a command processor such
	as a UN*X shell program.

Smail :				0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...
	Originally a program by Chris Seiwald and Mark Horton of AT&T.
	Later versions were also co-authored by Larry Auton of AT&T.  The 
	newest version is being written by Ronald S. Karr and Landon Noll,
	both of Amdahl Corporation with some review by Larry Auton and
	Richard Stallman of the Free Software Foundation.

Smail package :			0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...
	A package that includes the program smail, pathalias and map
	processing programs and other administrative routines.

Smart host :			6.3.6
	A host that supposedly has more or better routing information
	than your local host might have.  Thus, a smart-host is sent
	mail that other hosts cannot route.

Smart user host :		7.3.5
	A host that supposedly knows more domain users than other
	host in the domain.  As a result, mail is sent to this host
	when other hosts in the domain received mail for local form
	addresses that are not understood.

SMTP :				8.5.3, 8.1, 8.3, 9.6
	Simple Mail Transfer Protocol defined in Stanford Research
	Institute's Network Information Center (SRI-NIC) Request
	For Comment document number 821.

Spool directory :		9.1.3, 9.3
	A directory in that mail messages are spooled.  Processing
	occurs on the data that is in spool files in spool directories.
	This avoids the loss of mail because of either system failures
	during delivery, or system failures during the processing of
	addresses.  There can be several spool directories so that errors
	in writing to one will not result in the loss of messages unless
	writes to all available spool directories generate errors.

Syntax form :			0.1
	A string used in this document that describes a pattern of
	some kind.

Tail recursion:
	See Tail recursion.

Target :			3.2
	The most significant domain specified in an address.

Text-literal :			3.1.2.1
	In an address, a set of characters that are not operators,
	square brackets or double quotes.  This is a token form within
	an address.

Transport :			8
	Something that moves a message from one location to another.

Transport driver :		8.5
	A set of smail subroutines that do the actions of a transport.
	It is possible for several transport entries to refer to a
	single director transport.

Transport entry :               8.3
	A set of lines in the transport file that define a specific
	instance of a transport.  A transport entry names a transport
	driver, specifies values to be passed to a transport driver,
	and establishes its operating mode.

Transport file :		8.3
	A file containing one or more transport entries.

Transport instance :		8.4.1
	The use of the word instance here comes from the Smalltalk
	computer language, from Xerox PARC.  For smail it refers to a
	structure that groups together a list of addresses that are to
	be sent in one call to a transport.

UN*X :				0.2
	UN*X is not a trademark of anyone.

Uuname :                        6.3.2
	The uuname program prints the names of the UUCP neighbor sites
	found in the UUCP L.sys database.

Uuname driver :			6.3.2
	A router driver that determines if an address refers to a UUCP
	neighbor by obtaining a list of neighbors from a program such as
	the uuname program.

USENET :                        6.3
	A world wide network of sites that exchange news and articles on
	numerous topics.

USENET maps :			6.3, 6.4
	A database of sites in the UUCP zone, describing their
	connectivity.  This database is published to the USENET
	newsgroup comp.mail.maps.  This database is used by pathalias to
	form a pathalias database describing optimal paths from the
	local host to all other sites on USENET.

User agent :			0.2, 2
	A program that allows a user to send, receive and reply to mail
	messages.  On a typical System V machine, the user agents would
	be /bin/mail and /usr/bin/mailx.

User smart host :		7.3.5
	See Smart user host.

UUCP :                          0.2, 2, 3, 5, 8, 9,
	The Unix to Unix Copy Package (UUCP) that is available as a
	transport facility on most UN*X systems.  This package contains
	programs for file transfer to remote hosts and remote command
	execution over asynchronous serial lines.

UUCP Zone :
	The collection of sites that transfer mail through direct
	connections using the UUCP package to other sites in a worldwide
	UUCP network.

UUX :				8.3
	The remote command execution facility for UUCP.
\f