|
|
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: 11892 (0x2e74)
Types: TextFile
Names: »part.3«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦2fafebccf⟧ »EurOpenD3/mail/smail3.1.19.tar.Z«
└─⟦bcd2bc73f⟧
└─⟦this⟧ »design/part.3«
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