geoff@Fernwood.MPK.CA.US (Geoff Goodfellow) (07/13/89)
[The following blurb is the result of an ~11pm-1am fueling at The Oasis (a local
burger/pizza/beer garden) between Geoff Goodfellow & Paul Vixie. Comments?]
ASSUMPTIONS & RULES FOR TRANSITING UUCP/SMTP MESSAGES
Assumptions:
1. UUCP(!) style addresses are not guaranteed to always be unique and/or
registered in the uucp maps.
2. SMTP(@) rfqdm style address are unique and registered in the DNS.
3. The envelope of a UUCP message is always touched as a message transits
a system, by prepending the transited systems name to the front.
Header Treatment Rules:
1. Headers are treated the same regardless of transport.
2. Headers should not be touched as messages transit systems UNLESS
the message is transiting from the UUCP(!) to the SMTP(@) environment.
3. While transiting a message from the UUCP(!) to the SMTP(@) environment,
3a. IF the header contains an (@) style address with a rfqdm address on the
right of it THEN do not touch it;
3b. IF the header contains an (@) style address with a non-rfqdm address on
the right of it THEN do some type of %ification to the non-rfqdm
address and append the rfqdm (@) address of the transited system;
3c. IF the header does not contain an (@) style address THEN replace
the header "From:" address with envelope "From " address and
append the rfqdm (@) address of the transited system.
Notes:
DNS = Internet Domain Name System.
rfqdm = Registered Fully Qualified Domain address in the DNS.
An (@) style address is an address with an @-sign in it.
You cannot assume an (@) style address is a rfqdm name without checking its
validity with the DNS when transiting messages from UUCP -> SMTP, as there
are hosts which will assign themselves a DNS style name without registering
it in a DNS server connected to the Internet. (Use of the PSEUDODOMAIN
function in IDA Sendmail permits bypassing DNS lookups on bogus top-level
domains such as .uucp, .bitnet, .janet, et al and then proceed
directly to rule 3b).
Some systems prepend their name to headers as a message transits them
(in violation of rule 2). This inconsistiency is fixed by copying
the envelope "From ", which is always augmented as a message transits
a system (assumption 3) into the "From:" header field (rule 3c).
There is no attempt to fix or clean-up bad/invalid headers or short-circuit
routing. garbage in ==> garbage out (with the exception for rule 3c's
handeling of "From:" when transiting a message from !-land into @-land).
Some Rule Examples (fernwood.mpk.ca.us is the UUCP -> SMTP gateway host)
2. z!foo --> z!foo
x!y!z!foo --> x!y!z!foo
x!y!z.com!foo --> x!y!z.com!foo
3a. foo@z.com --> foo@z.com
3b. foo@z.uucp --> foo%z.uucp@fernwood.mpk.ca.us
bar@z.bitnet --> bar%z.bitnet@fernwood.mpk.ca.us
foo@z --> foo%z@fernwood.mpk.ca.us
foo@bogus.com --> foo%bogus.com@fernwood.mpk.ca.us
3c. Envelope: x!y!z!foo
Header: x!z!foo --> x!y!z!foo@fernwood.mpk.ca.us
Envelope: x.com!y!z!foo
Header: x.com!y!z!foo --> x.com!y!z!foo@fernwood.mpk.ca.us