⟦45ee47fdd⟧

TextFile

Part 3:  Addresses.

	Various operations on addresses are required in the process of
	deciding how to route and deliver mail.  The following sections
	describe these basic operations and will be referred to in
	later when we discuss the requirements for routing, aliasing
	and delivery.


Section 3.1:  Parsing header fields for addresses.

	The mailer may be required to parse the header itself to
	determine where to send the message.  In the following
	discussion on how to accomplish this parsing, a header is
	assumed to have been processed as described in part 2, so that
	all addresses are separated by something other than white
	space.


Section 3.1.1:  What headers are to be used.

	If there exist any Resent-To:, Resent-Cc: or Resent-Bcc:
	headers, then these should be used, otherwise, To:, Cc: or Bcc:
	headers should be used to scan for addresses (see Section 2.1).


Section 3.1.2:  Requirements for the scanning algorithm.


Section 3.1.2.1:  Forms of tokens.

	Full RFC822 is free form so lexical analysis is used to break a
	field into tokens.  A token is one of:

	    <quoted_literal> = "[^"]*"

	    <domain_literal> = `[' a bunch of chars `]'

	    <text_literal> = [^["%@!<>,.:; ]+

	    <comment> = `(' anything including balanced parentheses `)'

	NOTE:  Any character can be included in a <quoted_literal>,
	       <domain_literal>, <comment> or <text_literal> by
	       preceding the character with a back-slash ( `\' ).

	NOTE:  <comment> tokens and white space delimit tokens but are
	       otherwise ignored.

	Examples:

	    Count   Token type		Example

	      1	    <quoted_literal>	"John Q. Public"
	      1	    <quoted_literal>	"| tr \" '"
	      1	    <domain_literal>	[111.0.0.1]
	      1	    <domain_literal>	[the [ and \] chars]
	      3	    <text_literal>	John Q Public
	      3	    <text_literal>	John (The generic) Q Public
	      1	    <text_literal>	John\ Q\.\ Public


Section 3.1.2.2:  Classes of tokens.

	Tokens are grouped together to form patterns.  Typical groups
	are:

	    <domain_part> = <domain_literal> or <text_literal>

	    <word> = <quoted_literal> or <text_literal>

	    <non_operator> = <domain_part> or <word>

	    <any> = <domain_part> or <word> or [%@!<>,:;.]

	Examples:

	    <domain_part> tokens:  [10.31.16.8]  nsavax  uucp

	    <word> tokens:  "Ted Hustead Jr."  walldrug

	    <any> tokens:  name  :  @  "gosh!"  [hi mom]


Section 3.1.2.3:  Extraction of addresses from address lists.

	Addresses may need to be extracted from header fields.  There
	are three basic forms of <address>'s that can be extracted:

	    <address> = <simple_address> or <route_addr> or <mutant_form>

	    <simple_address> = <non_operator>([!%@]<non_operator>)*

	    <route_addr> = @<domain>(,@<domain>)*:<address>

	    <mutant_form> = (<domain>!)+<route_addr>

	    <domain> = <domain_part>(.<domain_part>)*

	The <mutant_form> represents an addressing form often seen when
	mail is received from the ARPAnet through several steps in
	the UUCP zone.  The <route_addr> should be converted to a
	!-route immediately and appended to the (<domain>!)+ string.

	Caveats:
		A <simple_address> or <domain> could conceivably begin
		or end with a `.', even though the above rules do not
		take that into account.  Note that RFC822 allows dots
		only as separators, though the extensions in RFC976 do
		mention the use dots in this fashion for domain names.

	Examples:

		Address				Form

		Charles.E.Brown@kgbvax		<simple_address>
		ihnp4!amdahl!namei!kevin	<simple_address>
		walldrug!hustead@namei.uucp	<simple_address>
		@walldrug:gavrilov@nsavax	<route_addr>
		@namei,@amdahl:amd!Phil.Ngai	<route_addr>
		kgbvax!glotz!@namei:maggie@amdahl <mutant_form>

	To extract all <simple_address>'s and <route_addr>'s from a
	list of addresses, use the following patterns to determine
	the parts that resolve to an <address> or <route_addr>:

		<address_list> = <address_form>(,<address_form>)*

		<address_form> = <group_form> or <route_addr_form>
				 or <simple_address>

	where <group_form> and <route_addr_form> can be used to extract
	addresses using the following patterns:

		<route_addr_form> = [^,<:]+[<]<addr_or_route_addr>[>]

		<group_form> = [^,<:]+:<group>;{@<non_operator>}

		<addr_or_route_addr> = <route_addr_form> or <route_addr>
				    or <simple_address> or <mutant_form>

		<group> = {<group_addr>(,<group_addr>)}

		<group_addr> = <route_addr_form> or <simple_address>

	Note:  A <route_addr> in a header field must be enclosed in
	       angle brackets, or it will be parsed as a group containing
	       one address, but with no group terminator.

	Example:

	    Given <address_list> =
		amd!phil, gnu%hoptoad@sun.com, amdahl.com!muts12!muts!gam

	    The <address>'s are:

		amd!phil
		gnu%hoptoad@sun.com
		amdahl.com!muts12!muts!gam

	Example:

	    Given <address_list> =
		a big group: Wilt . (The Stilt) Chamberlain@NBA.US,
			"honey"@remote-host.arpa,
			Yep! it's a route-addr <@somewhere:john.doe@nowhere>
			Hi Maggie <kgbvax!glotz!@namei:maggie@amdahl>
			;@odd-list,
		<@nearby,@farther:one%last@address>

	    The <address>'s are:

		Wilt.Chamberlain@NBA.US
		"honey"@remote-host.arpa
		@somewhere:john.doe@nowhere
		kgbvax!glotz!@namei:maggie@amdahl
		@nearby,@farther:one%last@address


Section 3.2:  Computing the target and remainder from an address.

	The rules in this section are to be applied recursively to an
	address until a local address is produced or an address resolves
	to a remote host.  The rules are used to produce a next target,
	hereafter referred to as <target>, and a remainder address,
	hereafter referred to as <remainder>.  The <target> is a host
	to which the message is to be sent, while the <remainder>
	is the recipient address that is to be given to the <target>
	host.

	    <target> = <domain_part>

	    <remainder> = <any>+  (unless otherwise defined)

	    <local_part> = <word>(.<word>)*

	    <address> = selected from the following in order of precedence:

	    1.	@<target>,<remainder>

		    <target> matches the first domain in the route part
		    of a <route_addr>.

	    2.	@<target>:<remainder>

		    <target> matches the only remaining domain in the
		    route part of a <route_addr>.

	    3.	<remainder>@<target>

		where	<remainder> = <simple_address>

		    The basic RFC822 addr.  The only difficultly is that
		    <remainder> is not necessarily a <local-part> form.

	    4.	<target>!<remainder>

		    <target> is the first address in a !-route.

	    5.	<remainder>%<target>

		    This is a non-standard alias for the RFC822 addr.
		    Precedence varies from installation from
		    installation.  Though the sendmail configurations I
		    have seen put it after host!remainder.

	    6.	<local_part>

		    This is a local address form.  The <target> is
		    the local host.

	    Examples:

		<address>:   @berkeley.edu,@css.gov:host!les%[131.8]@amdahl
		<target>:    berkeley.edu
		<remainder>: @css.gov:host!les%[131.8]@amdahl

		<address>:   @css.gov:curds!les%[131.8]@amdahl.uucp
		<target>:    css.gov
		<remainder>: curds!les%[131.8]@amdahl.uucp

		<address>:   curds!les%[131.8]@amdahl.uucp
		<target>:    amdahl.uucp
		<remainder>: curds!les%[131.8]

		<address>:   tron@amdahl@uts.amdahl.com
		<target>:    uts.amdahl.com
		<remainder>: tron@amdahl

		<address>:   curds!les%[131.8]
		<target>:    curds
		<remainder>: les%[131.8]

		<address>:   uts.amdahl.com!amdahl!tron
		<target>:    uts.amdahl.com
		<remainder>: amdahl!tron

		<address>:   les%[131.8]
		<target>:    [131.8]
		<remainder>: les

		<address>:   tron%amdahl%uts.amdahl.com
		<target>:    uts.amdahl.com
		<remainder>: tron%amdahl

		The following are in local form.  The complete address
		is the <remainder> and the <target> is the local host:

		<address>:   les
		<address>:   Oliver.North
		<address>:   "Sherlock Holmes' Older Brother"
		<address>:   "|cat /etc/passwd | mail chongo@amdahl.com"


Section 3.3:  Computing the next address given a remainder and a route.

	In Section 4.1 we will discuss the computation of a <route> and a
	<next_host> from a <target>.  In this section, we will assume
	that a <route> and <next_host> is known.  We will use these
	to compute the final value required for a transport agent to
	deliver a message.  That is, we will compute the address that
	the <next_host> is to deliver the message. This value is called
	the <next_address>.

	The <next_host> and <route> are computed from a <target>.
	<next_host> represents the next host that the message is
	to be sent in order for it to reach the target.  The <route>
	is a !-separated list of hosts and domains defining the path
	from <next_host> to <target>.  The <next_host> may be the
	local host, in that case <target> represents the local host.
	Also, the <next_host> and <target> may be the same remote host,
	in that case the <route> contains no hosts and is called
	``null''.

	The rules below define the method of generating the <next_address>
	from the <next_host>, <remainder> and <route>.

	1.  If <next_host> is null
	    and <remainder> == <local_part>

	    then <address> resolved to a local address on the local
	    host.

	2.  If <next_host> is null

	    then <target> routed to the local host.  Apply the rules
	    in section 3.2 on the <remainder> to determine a new
	    <target> and <remainder>.  Then a new <route> and <next_host>
	    must be computed.  When done, reapply the rules in this
	    section.

	3.  If <route> is not null

	    then <remainder> must be transformed into a !-route.  This
	    must be done to ensure that the final computed address does
	    not contain mismatched operators.

	    NOTE:  This transformation may also be required for some
		   recipient hosts who do not understand more than
		   !-route addresses.

	    To do this transformation on <remainder> to form a new
	    <remainder>, apply the following set of rules:

	    a.	Set <process> to the value of <remainder>.  Set
		<bang_route> to an empty string.

	    b.  Apply <process> to the rules in section 3.2 to obtain a
		new <target> and a <remainder>.

	    c.	If <bang_route> is not the empty string, append `!'.

	    d.	If <process> was not in local address form, then append
		<target> to <bang_route>, set <process> to <remainder>
		and go back to step b.

	    e.	If <process> was in local address form, then append
		<remainder> to <bang_route>.  Then, set <remainder> to
		<bang_route> and proceed to step 4.

	    Example:
		<remainder> in:  @cmu.edu,@css.gov:curds!les%whey@namei.uucp
		<remainder> out: cmu.edu!css.gov!namei.uucp!curds!whey!les

	4.  Given <remainder> in a suitable form compute <next_address>:

		<next_address> = <remainder>  if <route> is null
	    or	<next_address> = <route>!<remainder>

	Examples:

	    The examples below assume that <route> and <next_host> have
	    been filled in by the router.  Sometimes the router may also 
	    alter the <remainder> as defined in Section 4.1:

	    A simple case:
		<address>:	 tron@amdahl.com
		<target>:	 amdahl.com
		<remainder>:     tron
		<route>:	 namei!amdahl
		<next_host>:     glotz
		<next_address>:  namei!amdahl!tron

	    In the following case, the <remainder> was modified by the
	    router (see Section 4.1 for more information):
		<address>:	 root%bar@seismo.css.gov
		<target>:	 seismo.css.gov
		<remainder>:     root%bar@seismo.css.gov
		<route>:	 namei!amdahl!seismo!%s
		<next_host>:     glotz
		<next_address>:  namei!amdahl!seismo!seismo.css.gov!bar!root

	    In the following example, no <route> was returned, so that
	    we will be sending directly to the target host, though under
	    a different name determined by the router:
		<address>:	 @kray.rsrch.kgb.comm,@kyber:root@kyber-cc
		<target>:	 kray.rsrch.kgb.comm
		<remainder>:     @kyber:root@kyber-cc
		<route> is null
		<next_host>:     kray
		<next_address>:  @kyber:root@kyber-cc
\f
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦45ee47fdd⟧ TextFile

Derivation

TextFile
